Fiziksel olarak farklı konumlarda otomatik yük devretme ile yüksek düzeyde kullanılabilir MySQL mimarisi

Veri merkezleri arasında MySQL için yüksek kullanılabilirlikli (HA) çözümler araştırıyorum.

Aynı fiziksel ortamda bulunan sunucular için, aktif bir pasif yaklaşım kullanarak kalp atışı (kayan VIP) ile çift master'ı tercih ettim. Kalp atışı hem seri bağlantı hem de ethernet bağlantısı üzerindedir.

Nihayetinde amacım, veri merkezleri arasında aynı düzeyde kullanılabilirliği sağlamak. Her iki veri merkezi arasında manuel müdahale olmadan dinamik olarak yük devretme ve yine de veri bütünlüğünü korumak istiyorum.

Üstte BGP olurdu. Her iki konumda bulunan ve her iki taraf arasındaki veritabanlarına yönlendirme potansiyeli olan web kümeleri. Internet bağlantısı site 1'de kesilirse, istemciler site 2'den Web kümesine ve ardından her iki site arasındaki bağlantı hala devam ediyorsa site 1'deki veritabanına yönlendirilir.

Bu senaryoda, fiziksel bağlantının (seri) olmaması nedeniyle beynin bölünme olasılığı daha yüksektir. WAN her iki site arasında düşerse, VIP her iki sitede sona erecek ve çeşitli hoş olmayan senaryoların desync'i sunabileceği yerdi.

Gördüğüm bir diğer potansiyel sorun, bu altyapıyı gelecekte üçüncü bir veri merkezine ölçeklendirmede zorluk.

Ağ katmanı bir odak noktası değildir. Mimari bu aşamada esnektir. Yine, odak noktam veri bütünlüğünü korumak ve MySQL veritabanları ile otomatik yük devretme için bir çözümdür. Geri kalanını muhtemelen bunun etrafında tasarlardım.

İki farklı fiziksel site arasında MySQL HA için kanıtlanmış bir çözüm önerebilir misiniz?

Bunu okumak için zaman ayırdığınız için teşekkür ederiz. Önerilerinizi okumak için sabırsızlanıyorum.

"CAP" teoremi problemiyle karşılaşacaksınız. Aynı anda tutarlılık, kullanılabilirlik ve bölüm toleransınız olamaz.

DRBD / MySQL HA, blok cihaz seviyesinde senkron replikasyona dayanır. Her iki düğüm de kullanılabilirken veya geçici bir arıza varsa, yeniden başlatıldığında vb. Bir ağ bölümü aldığınızda sorunlar başlar.

İki veri merkezinde çalışırken ağ bölümleri son derece olasıdır. Esasen, hiçbir taraf bir bölümü başarısız olan diğer düğümden ayırt edemez. İkincil düğüm, devralınması (birincil başarısız) olup olmadığını (bağlantı koptu) bilmiyor.

Makineleriniz aynı konumdayken, bu sorunu çözmek için ikincil bir iletişim kanalı (genellikle bir seri kablo veya çapraz ethernet) ekleyebilirsiniz - böylece ikincil, birincilin gerçekten ne zaman aşağı olduğunu bilir ve bir ağ bölümü değildir .

Bir sonraki sorun performans. Makineleriniz düşük gecikmeli bir bağlantıya sahip olduğunda (örn. Gigabit ethernet - ancak bazı kişiler özel yüksek hızlı ağlar kullandığında) DRBD iyi ** performans verebilirken, ağda daha fazla gecikme süresi olursa, işlem yapmak daha uzun sürer *** . Bunun nedeni, ikincil sunucunun (çevrimiçi olduğunda), yazma işlemlerinin dayanıklılığını sağlamak için uygulamaya "Tamam" demeden önce tüm yazma işlemlerini onaylamasını beklemesi gerektiğidir.

Bunu farklı veri merkezlerinde yaparsanız, yakın olsalar bile genellikle birkaç milisaniye gecikme süresine sahip olursunuz.

** İyi bir yerel IO denetleyicisinden hala çok daha yavaş

*** Yük devretme sırasında gerekli olan kirli olmayan bir kapatma işleminden düzgün / otomatik olarak kurtarılmadığından MyISAM'ı yüksek kullanılabilirlikli bir DRBD sistemi için kullanamazsınız.

İki (veya daha fazla) veri merkezindeki tüm sunucuları birbirine bağlamak için bir VLAN kullanmaya ne dersiniz? Daha sonra otomatik yük devretme için CARP kullanabilirsiniz. Her şeyi senkronize tutmak için veritabanı çoğaltmasını kullanın.

Veri merkezlerine sahipseniz, her veri merkezinin birden fazla WAN bağlantısı bulunduğundan emin olabilirsiniz.

İlk adımınız, mevcut HA çözümünüzü Küme üyelik katmanı olarak OpenAIS kullanan bir sürüme yükseltmek olmalıdır: bu size çok fazla esneklik sağlar ve siteler arasında düşük gecikme süreleri verildiğinde, bunlara erişebilirsiniz. PaceMaker ve RHEL Clustering bunu desteklemektedir.

Otomatik veri merkezi yük devretme için, bir bağlayıcı olarak davranmak için gerçekten üçüncü bir siteye ihtiyacınız vardır, aksi takdirde siteleriniz siteler arası yönlendirme sorunları ve uzak site hatası arasında ayrım yapamaz. Microsoft'un alanı kapsayan şaşırtıcı derecede iyi web yayınları var:

Windows Server 2008 çok siteli kümeleme

Açıkçası teknolojinin tamamı Linux etki alanı ile eşleşmiyor, ancak kavramlar aynı.

Üzgünüm bu bir yana bir ağ, ama yolda bir düşünce ...

Bahsettiğiniz bölünmüş beyin senaryosu için, bunun gerçekleşme olasılığını azaltmak için iki site arasında yedekli bağlantılarınız olabilir.

En küçük yönlendirilebilir blok 4k, a / 22 olduğu için muhtemelen BGP'yi kullanamayacağınızı unutmayın. Muhtemelen DNS tabanlı bir çözüme ihtiyaç vardır.

Doğru bir cevap vermek, sahip olduğunuz veri miktarına, buna sığdırmak istediğiniz sunucuların miktarına, vb. Bağlı olarak zor olabilir.

MySQL ile birden fazla site için kanıtlanmış bir çözüm yoktur. Ama işe yarayan bir çözüm var. Bazılarının belirttiği gibi, evet DRDB iyi çalışıyor ancak kurulumunuza bağlı olarak sınırı veya olası sorunu var.

Hiç üçüncü bir siteye (başka bir veri merkezine) ihtiyacınız olacak mı? Eğer öyleyse, bunu yapmak için ne kadar zaman ve paraya ihtiyacınız olacak?

Her master / slave / dns sunucusu, yedeklemeler, ... eklediğinizde, kendinizi yönetmek için bir sunucu eklersiniz, sunucu sayısı açısından yönetim kapasiteniz nedir? Bu sayıyı tanımlayabilirseniz, yönetimin bir darboğaz haline gelmemesi için bazı olası çözümleri atmanız ve sayılarınıza uyacak çözümlerle çalışmanız gerekebilir.

Veri merkezlerinin sık sık düşmediği düşünüldüğünde, birden fazla site yük dengeleme ve bazı DNS korsanlığı anlamına gelir, bu aynı veri merkezinde mi olacak? Eğer öyleyse, bir veri merkezi herhangi bir nedenden ötürü çökerse, DNS ve yük dengelemenizin iyi bir kısmı bu veri merkezinde olacağı için sorun yaşarsınız.

Yani bu bölünmüş beyin durumunu planlamanız gerekebilir. Her olası kurulum için tükürük beyni durumunu çözmenin yolu farklıdır. Ayrıca, her bir çözüm X miktarını alır.
Başından itibaren 3 veri merkezini kullanmayı planlamak çok daha kolay olabilir. Ben MySQL uzmanı değilim ama üretimde hiç sorun yaşarsanız 2 Master 3 daha kolay olduğunu duydum.

Size yardımcı olabilecek bir şey Zeus gibi bazı ağ satıcı tarafından sunulan yük dengeleme hizmettir, bir göz burada muhtemelen çok daha fazla bu tür bir hizmet sunan yoktur. Eminim bir fiyata gelir ama bazen başka şeyleri kısmanıza izin verir.

İyi şanslar!

DRBD, uzak veri merkezleri için önerilen bir çözüm değildir, çünkü veritabanınızın ve çoğaltmanızın hızını etkileyebilecek bant genişliği gerektirir. Önerilen çözüm Master - Master Replication'dır. Bununla ilgili tek sorun, otomatik artış alanlarının kademelendirilmesi gerektiğidir.

MySQL için gerçekten bir HA çözümüne ihtiyacınız varsa, DRBD arıza durumunda size veri bütünlüğü sağlayamadığından MySQL Kümesi ile gitmeniz gerekir.

MySQL ve onun artıları ve eksileri seçenekleri ile ilgili blog gönderileri buldum. http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html

Seri kablo eksikliğini aşmak gerçekten çok kolay, karanlık çağlardan modem denilen bir şey kullanıyorsunuz - her iki ucunda da bir tane var ve daha sonra PPP bağlantısı üzerinden Heartbeat'ı çalıştırıyorsunuz. Çerçeve rölesini de kullanabilirsiniz. Her iki yöntem de layer1 / 2 yedekli yollarla ilgili endişelerinizi düzeltir.

Ancak söyleniyor - DRBD yaklaşık 300µs (0.3ms thats not) gecikme ile herhangi bir bağlantı üzerinden çalışan çok hızlı bir şekilde saçma olur.

Başarısızlık yapmak için standart MySQL çoğaltma ve PPP & eth üzerinden LinuxHA kullanarak daha iyi hizmet olacaktır.

En azından geçmişte müşteriler için yaptığım şey bu.