Arsitektur untuk MySQL yang sangat tersedia dengan failover otomatis di lokasi yang beragam secara fisik

Saya telah meneliti solusi ketersediaan tinggi (HA) untuk MySQL di antara pusat data.

Untuk server yang berlokasi di lingkungan fisik yang sama, saya lebih suka dual master dengan detak jantung (VIP mengambang) menggunakan pendekatan pasif aktif. Detak jantung melebihi koneksi serial maupun koneksi ethernet.

Pada akhirnya, tujuan saya adalah mempertahankan tingkat ketersediaan yang sama tetapi di antara pusat data. Saya ingin failover secara dinamis antara kedua pusat data tanpa intervensi manual dan tetap mempertahankan integritas data.

Akan ada BGP di atas. Cluster web di kedua lokasi, yang akan berpotensi untuk merutekan ke database antara kedua belah pihak. Jika koneksi Internet turun di situs 1, klien akan merutekan melalui situs 2, ke kluster Web, dan kemudian ke database di situs 1 jika tautan antara kedua situs masih naik.

Dengan skenario ini, karena kurangnya hubungan fisik (serial) ada kemungkinan lebih besar dari otak terpecah. Jika WAN turun di antara kedua situs, VIP akan berakhir di kedua situs, di mana berbagai skenario yang tidak menyenangkan dapat memperkenalkan desync.

Masalah potensial lain yang saya lihat adalah kesulitan meningkatkan infrastruktur ini ke pusat data ketiga di masa depan.

Lapisan jaringan bukan fokus. Arsitekturnya fleksibel pada tahap ini. Sekali lagi, fokus saya adalah solusi untuk menjaga integritas data serta failover otomatis dengan database MySQL. Saya mungkin akan merancang sisanya di sekitar ini.

Dapatkah Anda merekomendasikan solusi yang terbukti untuk MySQL HA antara dua situs yang berbeda secara fisik?

Terima kasih telah meluangkan waktu untuk membaca ini. Saya berharap dapat membaca rekomendasi Anda.

Anda akan menghadapi masalah teorema "CAP". Anda tidak dapat memiliki konsistensi, ketersediaan dan toleransi partisi pada saat yang bersamaan.

DRBD / MySQL HA bergantung pada replikasi sinkron pada level perangkat blok. Ini baik-baik saja ketika kedua node tersedia, atau jika salah satu menderita kesalahan sementara, reboot dll, maka kembali. Masalahnya dimulai ketika Anda mendapatkan partisi jaringan.

Partisi jaringan sangat mungkin ketika Anda menjalankan dua pusat data. Pada dasarnya, tidak ada pihak yang dapat membedakan partisi dari node lain yang gagal. Node sekunder tidak tahu apakah ia harus mengambil alih (primer gagal) atau tidak (tautannya hilang).

Ketika mesin Anda berada di lokasi yang sama, Anda dapat menambahkan saluran komunikasi sekunder (biasanya kabel serial, atau crossover ethernet) untuk mengatasi masalah ini - sehingga sekunder tahu kapan primernya benar-benar turun, dan itu bukan partisi jaringan .

Masalah selanjutnya adalah kinerja. Sementara DRBD dapat memberikan kinerja ** yang layak ketika mesin Anda memiliki koneksi latensi rendah (misalnya gigabit ethernet - tetapi beberapa orang menggunakan jaringan kecepatan tinggi khusus), semakin banyak latensi yang dimiliki jaringan, semakin lama waktu yang diperlukan untuk melakukan transaksi *** . Ini karena perlu menunggu server sekunder (saat online) untuk mengakui semua penulisan sebelum mengatakan "OK" ke aplikasi untuk memastikan daya tahan penulisan.

Jika Anda melakukan ini di pusat data yang berbeda, Anda biasanya memiliki latensi milidetik lagi, bahkan jika mereka dekat.

** Masih jauh lebih lambat daripada kontroler IO lokal yang layak

*** Anda tidak dapat menggunakan MyISAM untuk sistem DRBD ketersediaan tinggi karena tidak pulih dengan benar / otomatis dari shutdown yang tidak bersih, yang diperlukan selama kegagalan.

Bagaimana dengan menggunakan VLAN untuk mengikat semua server di dua (atau lebih) pusat data secara bersamaan. Anda kemudian dapat menggunakan CARP untuk failover otomatis. Gunakan replikasi basis data untuk menjaga semuanya tetap sinkron.

Jika Anda memiliki pusat data, Anda dapat memastikan setiap pusat data memiliki beberapa uplink WAN.

Tahap pertama Anda harus memutakhirkan solusi HA Anda saat ini menjadi yang menggunakan OpenAIS sebagai lapisan keanggotaan Cluster: ini akan memberi Anda banyak fleksibilitas, dan diberi tautan latensi rendah antar situs, mungkin bisa dijangkau secara keseluruhan. PaceMaker dan RHEL Clustering mendukung ini.

Untuk failover pusat data otomatis, Anda benar-benar membutuhkan situs ketiga untuk bertindak sebagai tie-breaker, jika tidak, situs Anda tidak akan dapat membedakan antara masalah perutean antar-situs dan kegagalan situs jarak jauh. Microsoft memiliki beberapa pemain web yang luar biasa bagus meliputi area ini:

Windows Server 2008 multi-situs clustering

Jelas teknologi yang tepat tidak memetakan ke domain Linux, tetapi konsepnya sama.

Maaf ini adalah jaringan lain selain, tetapi pemikiran untuk jalan ...

Untuk skenario otak terbelah yang Anda sebutkan, Anda bisa memiliki tautan yang berlebihan antara dua situs sekaligus untuk mengurangi kemungkinan ini terjadi.

Perhatikan bahwa Anda mungkin tidak dapat menggunakan BGP, karena blok routable terkecil adalah 4k, a / 22, semoga berhasil. Mungkin diperlukan solusi berbasis DNS.

Memberikan jawaban yang benar mungkin sulit tergantung pada jumlah data yang Anda miliki, jumlah server yang Anda inginkan, dll. Yang sedang berkata, jawaban saya mungkin bukan satu, atau setidaknya yang Anda cari.

Tidak ada solusi yang terbukti untuk beberapa situs dengan MySQL. Tetapi ada solusi yang berhasil. Seperti yang ditunjukkan beberapa orang, ya DRDB tidak berfungsi dengan baik tetapi memiliki keterbatasan atau kemungkinan masalah tergantung dari pengaturan Anda.

Apakah Anda memerlukan situs ketiga (pusat data lain)? Jika demikian, berapa banyak waktu dan uang yang harus Anda lakukan ini?

Mempertimbangkan setiap kali Anda menambahkan server master / slave / dns, cadangan, ... Anda menambahkan sendiri server untuk dikelola, berapa kapasitas manajemen Anda dalam hal jumlah server? Jika Anda dapat menentukan angka ini, Anda mungkin harus membuang beberapa solusi yang mungkin dan bekerja ke arah yang sesuai dengan nomor Anda sehingga manajemen tidak menjadi hambatan.

Mengingat pusat data tidak sering turun, beberapa situs berarti penyeimbangan beban dan beberapa peretasan DNS, apakah ini akan berada di pusat data yang sama? Jika demikian, jika satu pusat data turun karena alasan apa pun Anda akan mengalami masalah karena bagian yang baik dari DNS dan loadbalancing Anda akan berada di pusat data ini.

Jadi, Anda mungkin harus merencanakan situasi otak yang terpecah itu. Untuk hampir setiap pengaturan yang mungkin, cara untuk menyelesaikan situasi otak yang berbeda berbeda. Juga, setiap solusi membutuhkan jumlah waktu X.
Mungkin juga jauh lebih mudah untuk merencanakan untuk menggunakan 3 pusat data dari awal. Saya bukan ahli MySQL tetapi saya pernah mendengar bahwa dalam produksi lebih mudah untuk memiliki 3 Master daripada 2 jika Anda pernah mengalami masalah.

Satu hal yang dapat membantu Anda adalah layanan load balancing yang ditawarkan oleh beberapa vendor jaringan seperti Zeus, lihat di sini. Mungkin ada lebih banyak lagi yang menawarkan layanan semacam ini. Saya yakin itu ada harganya, tetapi kadang-kadang memungkinkan Anda mengurangi beberapa hal lainnya.

Semoga berhasil!

DRBD bukan solusi yang disarankan untuk pusat data jarak jauh, karena membutuhkan bandwidth yang dapat memengaruhi kecepatan basis data dan replikasi Anda. Solusi yang disarankan adalah Master - Master Replication. Satu-satunya masalah dengan ini adalah Anda bidang kenaikan otomatis perlu terhuyung-huyung.

Jika Anda membutuhkan solusi HA untuk MySQL, Anda harus menggunakan MySQL Cluster karena DRBD tidak dapat memberi Anda integritas data jika terjadi kegagalan.

Saya telah menemukan posting blog tentang opsi yang tersedia di MySQL dan pro dan kontra. http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html

Mengatasi kekurangan kabel serial sebenarnya sangat mudah, Anda menggunakan sesuatu dari zaman kegelapan yang disebut modem - Anda memiliki satu di setiap ujung dan kemudian jalankan Heartbeat melalui tautan PPP. Anda juga dapat menggunakan frame relay. Kedua metode akan memperbaiki kekhawatiran yang Anda miliki dengan jalur redundant layer1 / 2.

Namun demikian, DRBD berjalan di tautan apa pun dengan latensi lebih dari 300μs (perhatikan 0,3ms) menjadi sangat konyol.

Anda akan lebih baik dilayani dengan menggunakan replikasi MySQL standar, dan LinuxHA melalui PPP & eth untuk melakukan overs gagal.

Setidaknya itulah yang telah saya lakukan untuk klien di masa lalu.