HA Proxy Galera

HA Proxy encapsulate a Galera cluster for High-Availability solution.

Ada banyak aplikasi PHP di luar sana yang secara naas belum bisa pindah dari MySQL ke PostgreSQL. Aplikasi seperti WordPress dan Magento. Untuk aplikasi-aplikasi kritikal tersebut, diperlukan adanya redundansi untuk menjamin data. Untungnya, sekarang sudah ada produk Galera Cluster yang bisa mencapai itu. Produk ini menjadikan serangkaian MySQL Server untuk memiliki replikasi data yang sama.

Eh, tapi kayaknya kalau nanti PHP7 sudah resmi, mereka bakal dipaksa menggunakan ADODB, deh. Abstraksi ADODB memungkinkan SQL yang portabel. Hmm… sepertinya alasan ini nantinya bakal tidak ada.

Atau, mungkin Anda tertarik mengetahui bagaimana layanan MySQL Object (DBaaS) pada AWS dibuat? Atau, bagaimana layanan DBaaS pada OpenStack dibuat?

Ah, sudahlah, apa pun alasan supaya artikel ini ditulis supaya menjaga semangat ngeblog. Sejujurnya, saya menulis tutorial ini karena mood lagi naik akibat mendapatkan banyak Pokémon unik tadi siang di Perpustakaan Pusat UI.

Konfigurasi Peladen

Supaya tidak pusing, saya jelaskan dalam contoh kali ini ada 4 peladen. Satu peladen untuk HAProxy (harusnya dua, tapi saya malas). Lalu, tiga peladen menjadi peladen MySQL. Saya memilih untuk menggunakan MariaDB karena gratis dan mudah konfigurasi Galera-nya.

Peladen HAPROXY (selanjutnya dalam artikel akan saya sebut HAProxy)

  • IP 1: 192.168.1.12
  • IP 2: 192.168.101.1

IP 1 adalah IP eksternal yang digunakan untuk berhubungan dengan aplikasi. IP 2 adalah IP internal dalam jaringan lokal basisdata. Perhatikan baik-baik! Implementasi pusat data yang baik seharusnya memisahkan antara jaringan aplikasi, jaringan basisdata, jaringan administrasi, dan jaringan lainnya. Walau pun keempat peladen ini dijalankan pada VirtualBox sekalipun, tetap saya pisahkan untuk menunjukkan arsitektur yang benar.

Ada tiga peladen yang akan digunakan sebagai peladen basisdata. Saya akan namakan MariaDB1 (192.168.101.10), MariaDB2 (192.168.101.11), dan MariaDB3 (192.168.101.12). Walau pun nantinya setiap peladen bisa ditulisi, saya akan menggunakan peladen MariaDB1 sebagai awalan.

Berhubung saya malas, saya akan kurang detail menjelaskan. Silakan tinggalkan komentar bila kurang jelas. Saya menggunakan Debian Jessie sebagai sistem operasi dasar. Lalu, saya memilih menggunakan MariaDB 10.1 karena dia sudah mendukung langsung Galera Cluster.

Memasang MariaDB

Lakukan ini pada setiap peladen MariaDB: MariaDB1, MariaDB2, dan MariaDB3. Pokoknya, identik!

Memasang Peladen MariaDB

Aktifkan repositori MariaDB. Sebagai contoh dengan menggunakan Perkakas Konfigurasi Repositori kali ini saya ambil cermin Biznet karena yang sebelumnya Kartolo. Buatlah berkas /etc/apt/sources.list.d/mariadb.list yang berisi:

Atau cara lainnya:

Setelah itu, impor kunci publik repositori MariaDB:

MariaDB versi 10.1 sudah memasang Galera secara baku. Jadi, perintah pemasangan menjadi lebih mudah, cukup:

Setelah itu, matikan layanan MariaDB:

Atau, kalau Anda nyentrik atau punya alasan idealisme lainnya sehingga tidak menggunakan SystemD:

Setelah ini, konfigurasi Galera.

Berkas yang Identik

Debian Jessie menggunakan konfigurasi /etc/mysql/debian.cnf untuk menyediakan pengguna internalnya. Pengguna internal ini yang digunakan oleh Debian dalam mengonfigurasi peladen MySQL. Salin berkas tersebut dari MariaDB1 ke MariaDB2 dan MariaDB3 sehingga ketiganya memiliki /etc/mysql/debian.cnf yang identik.

Hanya berkas ini yang tidak identik karena dibuat secara otomatis oleh Debian pada saat pemasangan. Tetapi, kita perlu ketiga peladen memiliki konfigurasi yang identik. Itu sebabnya, satu berkas yang berbeda ini yang perlu disamakan.

Buat Konfigurasi untuk Kluster Galera

Pada ketiga peladen (MariaDB1, MariaDB2, MariaDB3) buat konfigurasi /etc/mysql/conf.d/galera.cnf

Silakan ganti nama berkas galera.cnf dengan nama lain kalau Anda mau. Silakan ganti “apakek_cluster” sesuai selera Anda untuk mendapatkan nama kluster yang jauh lebih baik.

Aktifkan Salah Satu Peladen Terlebih Dahulu

Lakukan langkah ini di salah satu peladen yang akan dimulai pertama kali. Bisa jadi karena pemasangan baru seperti saat ini. Atau, bisa jadi ada mati lampu sehingga menyebabkan seluruh kluster mati. Atau, laptop Anda baru dinyalakan kembali. Intinya, lakukan langkah ini pada saat tidak ada satu pun peladen yang menyala dan kluster ini baru mau dinyalakan dulu.

Bila pada kasus mati lampu atau peladen mati mendadak (crash), periksa berkas /var/lib/mysql/grastate.dat pada masing-masing peladen untuk memilih mana peladen dengan data terbaru. Sehingga, peladen tersebutlah yang dimulai pertama kali.

Bila Anda menggunakan SystemD, gunakan skrip ini:

Atau, demi alasan idealisme atau apa pun sehingga Anda membuang SystemD dan menggunakan sistem init lainnya:

Pada saat ini seharusnya sudah berjalan:

Kalau 0, berarti Anda ada salah konfigurasi di suatu tempat.

Jalankan Peladen MariaDB Sisanya

Pada dua peladen sisanya, MariaDB dijalankan dengan cara normal:

Atau

Seharusnya, apabila tidak ada kerusakan, pada akhirnya akan ada tiga peladen.

Sampai saat ini, Galera sudah selesai dibuat. Anda lakukan operasi SQL pada salah satu peladen mana pun hasilnya akan sama.

BONUS TUGAS

Terakhir, untuk tugas. Silakan buat satu pengguna Admin Super yang bisa membuat basis data dan penggunanya. Pengguna ini harus bisa mengakses dari luar.

Konfigurasi HAProxy

Pada salah satu peladen MariaDB (MariaDB1/MariaDB2/MariaDB3), buat sebuah pengguna HAProxy di basisdata. Pengguna ini akan mengkueri basisdata untuk mengecek keberlangsungan masing-masing peladen.

Ganti nama pengguna haproxy dengan sesuatu yang lebih kreatif. Demi keamanan, jangan cuma copas saja di sini!

Lalu, masuk pada peladen HAProxy dan pasang HAProxy di sana:

Lalu, buat konfigurasi HAProxy. Caranya, tambahkan baris-baris ini pada berkas konfigurasi /etc/haproxy/haproxy.cfg

Ganti nama pengguna haproxy dengan sesuatu yang lebih kreatif. Demi keamanan, jangan cuma copas saja di sini!

Lalu, jalankan ulang HAProxy. (Pada titik ini saya sudah malas membuat dua versi)

Selesai.

Optimasi

Bonus untuk landasan pemikiran. Berikut arsitektur-arsitektur alternatif yang bisa dibuat untuk memenuhi kebutuhan.

  1. Ganti HAProxy dengan perangkat keras router atau load-balancer.
  2. Pasang HAProxy pada setiap peladen aplikasi agar menghilangkan bottleneck jaringan. Jadi, hubungan antara aplikasi dan basisdata menjadi M:N. Kalau pakai ini, HAProxy lebih baik bind ke localhost jangan ke IP. Jadi, akses per aplikasi langsung ke localhost. Ini pondasi arsitektur layanan mikro (microservice architecture).
    HAProxy per apps

    HAProxy per apps

  3. Partisi peladen-peladen aplikasi untuk mengakses hanya salah peladen dalam kluster.
  4. Tambah jumlah peladen dalam kluster.

Jumlah kluster 3 itu adalah demi memenuhi konsep kuorum.

Optimasi Lebih Lanjut yang Belum Sempat Ditulis Karena Saya Ingin Mencari Pokémon Lagi Riset Lebih Lanjut

Ada riset lanjutan yang dapat membuat arsitektur aplikasi lebih terskalakan. Yakni, membuat sebuah peladen obyek penyimpan (storage object) semacam Amazon S3 dengan menggunakan OpenStack Swift dengan menggunakan CEPH. Atau, implementasi sederhana dengan GlusterFS atau NFS. Silakan kembangkan lebih lanjut agar aplikasi Anda lebih terskalakan.

Gunakan Puppet, Ansible, Chef, atau konfigurator apa pun yang lebih baik. Kalau arsitektur sudah skala besar seperti ini, mengubah peladen satu persatu itu sudah mustahil bila tanpa ada kesalahan. Buat tutorial ini menjadi cookbook/rule yang bisa secara dinamis di-deploy.

Semoga bermanfaat.

Bacaan Lebih Lanjut