Menggunakan set yang seimbang untuk mengklusterkan MySQL di Linux

  • Artikel

Penting

Komputer virtual klasik akan dihentikan pada 1 Maret 2023.

Jika Anda menggunakan sumber IaaS dari ASM, harap menyelesaikan migrasi sebelum 1 Maret 2023. Kami mendorong Anda untuk beralih lebih cepat untuk memanfaatkan banyak peningkatan fitur di Azure Resource Manager.

Untuk mengetahui informasi selengkapnya, lihat Migrasikan sumber IaaS Anda ke Azure Resource Manager sebelum 1 Maret 2023.

Catatan

Azure memiliki dua model penyebaran yang berbeda untuk membuat dan bekerja dengan sumber daya: Azure Resource Manager dan klasik. Artikel ini membahas tentang menggunakan model penyebaran klasik. Microsoft merekomendasikan agar sebagian besar penyebaran baru menggunakan model Resource Manager. Templat Resource Manager tersedia jika Anda perlu menyebarkan kluster MySQL.

Mulai 15 November 2017, komputer virtual hanya akan tersedia di portal Azure.

Artikel ini mengeksplorasi dan mengilustrasikan berbagai pendekatan yang tersedia untuk menyebarkan layanan berbasis Linux yang sangat tersedia di Microsoft Azure, menjelajahi ketersediaan tinggi MySQL Server sebagai primer. Video yang mengilustrasikan pendekatan ini tersedia di Channel 9.

Kami akan menguraikan solusi ketersediaan tinggi MySQL shared-nothing, two-node, single-master berdasarkan DRBD, Corosync, dan Pacemaker. Hanya satu simpul yang menjalankan MySQL pada satu waktu. Membaca dan menulis dari sumber daya DRBD juga terbatas hanya pada satu simpul pada satu waktu.

Tidak perlu solusi VIP seperti LVS, karena Anda akan menggunakan set seimbang beban dalam Microsoft Azure untuk menyediakan fungsionalitas round-robin dan deteksi titik akhir, penghapusan, dan pemulihan VIP yang lancar. VIP adalah alamat IPv4 yang dapat dirutekan secara global yang ditetapkan oleh Microsoft Azure ketika Anda pertama kali membuat layanan cloud.

Ada kemungkinan arsitektur lain untuk MySQL, termasuk Kluster NBD, Percona, Galera, dan beberapa solusi middleware, termasuk setidaknya satu tersedia sebagai VM pada VM Depot. Selama solusi ini dapat direplikasi pada unicast vs. multicast atau siaran dan tidak mengandalkan penyimpanan bersama atau beberapa antarmuka jaringan, skenario harus mudah disebarkan pada Microsoft Azure.

Arsitektur pengklusteran ini dapat diperluas ke produk lain seperti PostgreSQL dan OpenLDAP dengan cara yang sama. Misalnya, prosedur penyeimbangan beban ini dengan berbagi tidak ada yang berhasil diuji dengan OpenLDAP multi-master, dan Anda dapat menontonnya di blog Channel 9 kami.

Bersiaplah

Anda memerlukan sumber daya dan kemampuan berikut:

  • Akun Microsoft Azure dengan langganan yang valid, dapat membuat setidaknya dua VM (XS digunakan dalam contoh ini)
  • Jaringan dan subnet
  • Grup afinitas
  • Sekumpulan ketersediaan
  • Kemampuan untuk membuat VHD di wilayah yang sama dengan layanan cloud dan melampirkannya ke VM Linux

Lingkungan yang diuji

  • Ubuntu 13.10
    • DRBD
    • Microsoft SQL Server MySQL
    • Corosync dan Pacemaker

Grup afinitas

Buat grup afinitas untuk solusi dengan masuk ke portal Azure, memilih Pengaturan, dan membuat grup afinitas. Sumber daya yang dialokasikan yang dibuat nanti akan ditetapkan ke grup afinitas ini.

Jaringan

Jaringan baru dibuat, dan subnet dibuat di dalam jaringan. Contoh ini menggunakan jaringan 10.10.10.0/24 dengan hanya satu subnet /24 di dalamnya.

Komputer virtual

VM Ubuntu 13.10 pertama dibuat dengan menggunakan gambar Galeri Ubuntu yang Didukung dan disebut hadb01. Layanan awan baru dibuat dalam proses, yang disebut hadb. Nama ini menggambarkan sifat bersama yang seimbang dengan beban yang akan dimiliki layanan ketika lebih banyak sumber daya ditambahkan. Pembuatan hadb01 tidak menemukan dan diselesaikan dengan menggunakan portal. Titik akhir untuk SSH dibuat secara otomatis, dan jaringan baru dipilih. Sekarang Anda dapat membuat set ketersediaan untuk VM.

Setelah VM pertama dibuat (secara teknis, ketika layanan cloud dibuat), buat VM kedua, hadb02. Untuk VM kedua, gunakan VM Ubuntu 13.10 dari Gallery dengan menggunakan portal, tetapi gunakan layanan cloud yang ada, hadb.cloudapp.net, alih-alih membuat yang baru. Jaringan dan set ketersediaan harus dipilih secara otomatis. Titik akhir SSH juga akan dibuat.

Setelah kedua VM dibuat, perhatikan port SSH untuk hadb01 (TCP 22) dan hadb02 (secara otomatis ditetapkan oleh Azure).

Penyimpanan terlampir

Pasang disk baru ke VM dan buat disk 5 GB dalam prosesnya. Disk dihosting dalam kontainer VHD yang digunakan untuk disk sistem operasi utama Anda. Setelah disk dibuat dan dilampirkan, tidak perlu memulai ulang Linux karena kernel akan melihat perangkat baru. Perangkat ini biasanya /dev/sdc. Periksa dmesg outputnya.

Pada setiap VM, buat partisi dengan menggunakan cfdisk (primer, partisi Linux) dan tulis tabel partisi baru. Jangan membuat sistem file pada partisi ini.

Menyiapkan kluster

Gunakan APT untuk menginstal Corosync, Pacemaker, dan DRBD pada kedua VM Ubuntu. Untuk melakukannya dengan apt-get, jalankan kode berikut:

sudo apt-get install corosync pacemaker drbd8-utils.

Jangan instal MySQL saat ini. Skrip penginstalan Debian dan Ubuntu akan menginisialisasi direktori data MySQL pada /var/lib/mysql, tetapi karena direktori akan digantikan oleh sistem file DRBD, Anda perlu menginstal MySQL nanti.

Verifikasi (dengan menggunakan /sbin/ifconfig) bahwa kedua VM menggunakan alamat di subnet 10.10.10.0/24 dan bahwa mereka dapat melakukan ping satu sama lain berdasarkan nama. Anda juga dapat menggunakan ssh-keygen dan ssh-copy-id untuk memastikan kedua VM dapat berkomunikasi melalui SSH tanpa memerlukan kata sandi.

Menyiapkan DRBD

Buat sumber daya DRBD yang menggunakan partisi yang mendasarinya /dev/sdc1 untuk menghasilkan /dev/drbd1 sumber daya yang dapat diformat dengan menggunakan ext3 dan digunakan dalam simpul primer dan sekunder.

  1. Buka /etc/drbd.d/r0.res dan salin definisi sumber daya berikut pada kedua VM:

     resource r0 {
   on `hadb01` {
     device  /dev/drbd1;
     disk   /dev/sdc1;
     address  10.10.10.4:7789;
     meta-disk internal;
   }
   on `hadb02` {
     device  /dev/drbd1;
     disk   /dev/sdc1;
     address  10.10.10.5:7789;
     meta-disk internal;
   }
 }

  2. Inisialisasi sumber daya dengan menggunakan drbdadm pada kedua VM:

     sudo drbdadm -c /etc/drbd.conf role r0
 sudo drbdadm up r0

  3. Pada VM utama (hadb01), paksa kepemilikan (utama) sumber daya DRBD:

     sudo drbdadm primary --force r0

Jika Anda memeriksa konten /proc/drbd (sudo cat /proc/drbd) pada kedua VM, Anda akan melihat Primary/Secondary di hadb01 dan Secondary/Primary di hadb02, konsisten dengan solusi pada saat ini. Disk 5 GB disinkronkan melalui jaringan 10.10.10.0/24 tanpa biaya kepada pelanggan.

Setelah disk disinkronkan, Anda dapat membuat sistem file di hadb01. Untuk tujuan pengujian, kami menggunakan ext2, tetapi kode berikut akan membuat sistem file ext3:

mkfs.ext3 /dev/drbd1

Memasang sumber daya DRBD

Anda sekarang siap untuk memasang sumber daya DRBD pada hadb01. Debian dan turunan menggunakan /var/lib/mysql sebagai direktori data MySQL. Karena Anda belum menginstal MySQL, buat direktori dan pasang sumber daya DRBD. Untuk melakukan opsi ini, jalankan kode berikut pada hadb01:

sudo mkdir /var/lib/mysql
sudo mount /dev/drbd1 /var/lib/mysql

Menyiapkan MySQL

Sekarang Anda siap untuk menginstal MySQL di hadb01:

sudo apt-get install mysql-server

Untuk hadb02, Anda memiliki dua opsi. Anda dapat menginstal mysql-server, yang akan membuat /var/lib/mysql, mengisinya dengan direktori data baru, lalu menghapus konten. Untuk melakukan opsi ini, jalankan kode berikut pada hadb02:

sudo apt-get install mysql-server
sudo service mysql stop
sudo rm –rf /var/lib/mysql/*

Opsi kedua adalah failover ke hadb02 dan kemudian menginstal mysql-server di sana. Skrip penginstalan akan melihat penginstalan yang ada dan tidak akan menyentuhnya.

Jalankan kode berikut pada hadb01:

sudo drbdadm secondary –force r0

Jalankan kode berikut pada hadb02:

sudo drbdadm primary –force r0
sudo apt-get install mysql-server

Jika Anda tidak berencana untuk failover DRBD sekarang, opsi pertama lebih mudah meskipun bisa dibilang kurang elegan. Setelah menyiapkan ini, Anda dapat mulai mengerjakan database MySQL Anda. Jalankan kode berikut pada hadb02 (atau server mana pun yang aktif, menurut DRBD):

mysql –u root –p
CREATE DATABASE azureha;
CREATE TABLE things ( id SERIAL, name VARCHAR(255) );
INSERT INTO things VALUES (1, "Yet another entity");
GRANT ALL ON things.\* TO root;

Peringatan

Pernyataan terakhir ini secara efektif menonaktifkan autentikasi untuk pengguna akar dalam tabel ini. Ini harus digantikan oleh pernyataan GRANT tingkat produksi Anda dan hanya disertakan untuk tujuan ilustrasi.

Jika Anda ingin membuat kueri dari luar VM (yang merupakan tujuan panduan ini), Anda juga perlu mengaktifkan jaringan untuk MySQL. Pada kedua VM, buka /etc/mysql/my.cnf dan buka bind-address. Ubah alamat dari 127.0.0.1 menjadi 0.0.0.0. Setelah menyimpan file, terbitkan sudo service mysql restart di primer Anda saat ini.

Membuat set mySQL dengan beban seimbang

Kembali ke portal, buka hadb01, dan pilih Titik Akhir. Untuk membuat titik akhir, pilih MySQL (TCP 3306) dari daftar drop-down dan pilih Buat set beban baru yang seimbang. Beri nama titik lb-mysqlakhir yang seimbang beban . Atur Waktu ke 5 detik, minimum.

Setelah Anda membuat titik akhir, buka hadb02, pilih Titik Akhir, dan buat titik akhir. Pilih lb-mysql, lalu pilih MySQL dari daftar drop-down. Anda juga dapat menggunakan Azure CLI untuk langkah ini.

Anda sekarang memiliki semua yang Anda butuhkan untuk pengoperasian manual kluster.

Menguji set dengan beban seimbang

Pengujian dapat dilakukan dari mesin luar dengan menggunakan klien MySQL apa pun, atau dengan menggunakan aplikasi tertentu, seperti phpMyAdmin yang berjalan sebagai situs web Azure. Dalam hal ini, Anda menggunakan alat baris perintah MySQL pada kotak Linux lain:

mysql azureha –u root –h hadb.cloudapp.net –e "select * from things;"

Failover secara manual

Anda dapat mensimulasikan failover dengan mematikan MySQL, mengalihkan primer DRBD, dan memulai MySQL lagi.

Untuk melakukan tugas ini, jalankan kode berikut pada hadb01:

service mysql stop && umount /var/lib/mysql ; drbdadm secondary r0

Kemudian, pada hadb02:

drbdadm primary r0 ; mount /dev/drbd1 /var/lib/mysql && service mysql start

Setelah gagal secara manual, Anda dapat mengulangi kueri jarak jauh dan kueri tersebut akan berfungsi dengan sempurna.

Menyiapkan Corosync

Corosync adalah infrastruktur kluster yang mendasari yang diperlukan agar Pacemaker berfungsi. Untuk Heartbeat (dan metodologi lain seperti Ultramonkey), Corosync adalah pemisahan fungsi CRM, sementara Pacemaker tetap lebih mirip dengan Heartbeat dalam fungsionalitas.

Batasan utama untuk Corosync di Azure adalah corosync lebih memilih multicast daripada siaran daripada komunikasi unicast, tetapi jaringan Microsoft Azure hanya mendukung unicast.

Untungnya, Corosync memiliki mode unicast yang berfungsi. Satu-satunya batasan nyata adalah bahwa karena semua simpul tidak berkomunikasi di antara mereka sendiri, Anda perlu menentukan simpul dalam file konfigurasi Anda, termasuk alamat IP mereka. Kita dapat menggunakan file contoh Corosync untuk Unicast dan mengubah alamat ikatan, daftar simpul, dan direktori pengelogan (Ubuntu menggunakan /var/log/corosync saat file contoh menggunakan /var/log/cluster), dan mengaktifkan alat kuorum.

Catatan

Gunakan direktif berikut transport: udpu dan alamat IP yang ditentukan secara manual untuk kedua simpul.

Jalankan kode berikut pada /etc/corosync/corosync.conf untuk kedua simpul:

totem {
  version: 2
  crypto_cipher: none
  crypto_hash: none
  interface {
    ringnumber: 0
    bindnetaddr: 10.10.10.0
    mcastport: 5405
    ttl: 1
  }
  transport: udpu
}

logging {
  fileline: off
  to_logfile: yes
  to_syslog: yes
  logfile: /var/log/corosync/corosync.log
  debug: off
  timestamp: on
  logger_subsys {
    subsys: QUORUM
    debug: off
    }
  }

nodelist {
  node {
    ring0_addr: 10.10.10.4
    nodeid: 1
  }

  node {
    ring0_addr: 10.10.10.5
    nodeid: 2
  }
}

quorum {
  provider: corosync_votequorum
}

Salin file konfigurasi ini pada VM dan mulai Corosync di kedua simpul:

sudo service start corosync

Tak lama setelah memulai layanan, kluster harus ditetapkan di cincin saat ini, dan kuorum harus dibentuk. Kita dapat memeriksa fungsionalitas ini dengan meninjau log atau dengan menjalankan kode berikut:

sudo corosync-quorumtool –l

Anda akan melihat output yang mirip dengan gambar berikut:

corosync-quorumtool -l sample output

Menyiapkan Pacemaker

Pacemaker menggunakan kluster untuk memantau sumber daya, menentukan kapan utama turun, dan mengalihkan sumber daya tersebut ke sekunder. Sumber daya dapat ditentukan dari sekumpulan skrip yang tersedia atau dari skrip LSB (seperti init), di antara pilihan lainnya.

Kami ingin Pacemaker "memiliki" sumber daya DRBD, titik pemasangan, dan layanan MySQL. Jika Pacemaker dapat mengaktifkan dan menonaktifkan DRBD, pasang dan lepaskan, lalu mulai dan hentikan MySQL dalam urutan yang tepat ketika sesuatu yang buruk terjadi dengan primer, penyiapan selesai.

Ketika Anda pertama kali menginstal Pacemaker, konfigurasi Anda harus cukup sederhana, seperti:

node $id="1" hadb01
  attributes standby="off"
node $id="2" hadb02
  attributes standby="off"

  1. Periksa konfigurasi dengan menjalankan sudo crm configure show.

  2. Kemudian buat file (seperti /tmp/cluster.conf) dengan sumber daya berikut:

     primitive drbd_mysql ocf:linbit:drbd \
       params drbd_resource="r0" \
       op monitor interval="29s" role="Master" \
       op monitor interval="31s" role="Slave"

 ms ms_drbd_mysql drbd_mysql \
       meta master-max="1" master-node-max="1" \
         clone-max="2" clone-node-max="1" \
         notify="true"

 primitive fs_mysql ocf:heartbeat:Filesystem \
       params device="/dev/drbd/by-res/r0" \
       directory="/var/lib/mysql" fstype="ext3"

 primitive mysqld lsb:mysql

 group mysql fs_mysql mysqld

 colocation mysql_on_drbd \
        inf: mysql ms_drbd_mysql:Master

 order mysql_after_drbd \
        inf: ms_drbd_mysql:promote mysql:start

 property stonith-enabled=false

 property no-quorum-policy=ignore

  3. Muat file ke dalam konfigurasi. Anda hanya perlu melakukan ini dalam satu simpul.

     sudo crm configure
   load update /tmp/cluster.conf
   commit
   exit

  4. Pastikan Pacemaker dimulai pada boot di kedua simpul:

     sudo update-rc.d pacemaker defaults

  5. Dengan menggunakan sudo crm_mon –L, verifikasi bahwa salah satu node Anda telah menjadi master untuk kluster dan menjalankan semua sumber daya. Anda dapat menggunakan mount dan ps untuk memeriksa apakah sumber daya sedang berjalan.

Cuplikan layar berikut menunjukkan crm_mon dengan satu simpul dihentikan (keluar dengan memilih Ctrl+C):

crm_mon node stopped

Cuplikan layar ini menunjukkan kedua simpul, satu master, dan satu budak:

crm_mon operational master/slave

Pengujian

Anda siap untuk simulasi failover otomatis. Ada dua cara untuk melakukan ini: lembut dan keras.

Cara lunak menggunakan fungsi matikan kluster: crm_standby -U `uname -n` -v on. Jika Anda menggunakan ini pada master, budak mengambil alih. Ingatlah untuk mengatur ini kembali ke off. Jika tidak, crm_mon akan menampilkan satu simpul yang siaga.

Cara yang sulit adalah mematikan VM utama (hadb01) melalui portal atau dengan mengubah runlevel pada VM (yaitu, menghentikan, mematikan). Ini membantu Corosync dan Pacemaker dengan menandakan bahwa master akan turun. Anda dapat menguji ini (berguna untuk jendela pemeliharaan), tetapi Anda juga dapat memaksa skenario dengan membekukan VM.

STONITH

Dimungkinkan untuk mengeluarkan penonaktifan VM melalui Azure CLI sebagai pengganti skrip STONITH yang mengontrol perangkat fisik. Anda dapat menggunakan /usr/lib/stonith/plugins/external/ssh sebagai dasar dan mengaktifkan STONITH dalam konfigurasi kluster. Azure CLI harus diinstal secara global, dan pengaturan dan profil penerbitan harus dimuat untuk pengguna kluster.

Kode sampel untuk sumber daya tersedia di GitHub. Ubah konfigurasi kluster dengan menambahkan yang berikut ini ke sudo crm configure:

primitive st-azure stonith:external/azure \
  params hostlist="hadb01 hadb02" \
  clone fencing st-azure \
  property stonith-enabled=true \
  commit

Catatan

Skrip tidak melakukan pemeriksaan naik/turun. Sumber daya SSH asli memiliki 15 pemeriksaan ping, tetapi waktu pemulihan untuk Azure VM mungkin lebih bervariasi.

Batasan

Batasan berikut berlaku:

  • Skrip sumber daya DRBD linbit yang mengelola DRBD sebagai sumber daya di Pacemaker menggunakan drbdadm down saat mematikan simpul, bahkan jika simpul hanya berlangsung siaga. Ini tidak ideal karena budak tidak akan menyinkronkan sumber daya DRBD saat master akan menulis. Jika master tidak gagal dengan baik, budak dapat mengambil alih status sistem file yang lebih lama. Ada dua cara potensial untuk memecahkan ini:
    • Memberlakukan drbdadm up r0 di semua node kluster melalui pengawas lokal (tidak terkluster)
    • Mengedit skrip DRBD linbit, memastikan bahwa down tidak dipanggil /usr/lib/ocf/resource.d/linbit/drbd
  • Penyeimbang beban membutuhkan setidaknya lima detik untuk merespons, sehingga aplikasi harus sadar kluster dan lebih toleran terhadap batas waktu. Arsitektur lain, seperti antrean dalam aplikasi dan middleware kueri, juga dapat membantu.
  • Penyetelan MySQL diperlukan untuk memastikan bahwa penulisan dilakukan dengan kecepatan yang dapat dikelola dan cache disiram ke disk sesering mungkin untuk meminimalkan kehilangan memori.
  • Performa tulis tergantung pada interkoneksi VM di sakelar virtual karena ini adalah mekanisme yang digunakan oleh DRBD untuk mereplikasi perangkat.