Ey Habr! Makalenin çevirisini dikkatinize sunuyorum. Andrew Beekhof'un yazısı.
Birçok kişi iki düğümlü kümeleri tercih ediyor çünkü kavramsal olarak daha basit görünüyorlar ve aynı zamanda üç düğümlü benzerlerine göre %33 daha ucuzlar. Her ne kadar iki düğümden oluşan iyi bir kümeyi bir araya getirmek oldukça mümkün olsa da, çoğu durumda, dikkate alınmayan senaryolar nedeniyle böyle bir yapılandırma, pek çok açık olmayan sorun yaratacaktır.
Yüksek kullanılabilirliğe sahip herhangi bir sistem oluşturmanın ilk adımı, bireysel arıza noktalarını bulmak ve ortadan kaldırmaya çalışmaktır; genellikle şu şekilde kısaltılır: SPoF (tek başarısızlık noktası).
Herhangi bir sistemde olası tüm kesinti risklerini ortadan kaldırmanın imkansız olduğunu akılda tutmakta fayda var. Bu, riske karşı tipik bir savunmanın, sistem karmaşıklığının artmasına ve yeni başarısızlık noktalarının ortaya çıkmasına yol açan bir miktar fazlalık getirmek olduğu gerçeğinden kaynaklanmaktadır. Bu nedenle, başlangıçta bir uzlaşmaya varırız ve ilgili ve dolayısıyla giderek daha az olası olaylar zincirine değil, bireysel başarısızlık noktalarıyla ilişkili olaylara odaklanırız.
Dengeler göz önüne alındığında, yalnızca SPoF'u aramakla kalmıyoruz, aynı zamanda riskleri ve sonuçları da dengeliyoruz; bunun sonucunda neyin kritik olduğu ve neyin kritik olmadığı sonucunun her dağıtım için farklılık gösterebilmesi mümkün oluyor.
Herkesin bağımsız enerji hatlarına sahip alternatif elektrik tedarikçilerine ihtiyacı yoktur. Her ne kadar paranoya en az bir müşteri için, izleme sırasında arızalı bir transformatör tespit edildiğinde işe yaradı. Müşteri, arızalı trafo patlayana kadar elektrik şirketini uyarmaya çalışan telefon görüşmeleri yaptı.
Doğal bir başlangıç noktası sistemde birden fazla düğümün bulunmasıdır. Ancak sistem, bir arızanın ardından hizmetleri hayatta kalan düğüme taşımadan önce, genellikle taşınan hizmetlerin başka yerde etkin olmadığından emin olması gerekir.
Bir hata her iki düğümün de aynı statik web sitesine hizmet vermesiyle sonuçlanırsa, iki düğümlü kümenin hiçbir dezavantajı yoktur. Ancak, her iki tarafın da paylaşılan bir iş kuyruğunu bağımsız olarak yönetmesi veya çoğaltılmış bir veritabanına veya paylaşılan dosya sistemine koordinesiz yazma erişimi sağlaması durumunda işler değişir.
Bu nedenle, tek düğüm hatasından kaynaklanan veri bozulmasını önlemek için, adı verilen bir şeye güveniyoruz. "ayrışma" (eskrim).
Ayrışma ilkesi
Ayrışma ilkesinin temelinde şu soru yatmaktadır: Rakip bir düğüm veri bozulmasına neden olabilir mi? Veri bozulmasının olası bir senaryo olması durumunda, düğümü hem gelen isteklerden hem de kalıcı depolamadan yalıtmak iyi bir çözüm olacaktır. İlişkiyi kesmeye yönelik en yaygın yaklaşım, hatalı düğümlerin bağlantısını kesmektir.
Diyeceğim iki ayrışma yöntemi kategorisi vardır. direkt и dolaylı, ancak aynı şekilde çağrılabilirler aktif и pasif. Doğrudan yöntemler, bir IPMI (Akıllı Platform Yönetim Arayüzü) veya iLO (sunuculara fiziksel erişim olmadığında sunucuları yönetmeye yönelik bir mekanizma) cihazıyla etkileşim gibi hayatta kalan eşlerin yaptığı eylemleri içerirken, dolaylı yöntemler başarısız olanlara dayanır. düğümün bir şekilde sağlıksız bir durumda olduğunu (veya en azından diğer üyelerin iyileşmesini engellediğini) fark etmesini ve sinyal vermesini sağlar. başarısız düğümün bağlantısını kesme ihtiyacı hakkında.
Quorum, hem doğrudan hem de dolaylı yöntemleri kullanırken yardımcı olur.
Doğrudan ayrışma
Doğrudan ayrışma durumunda, ağ arızası durumunda ayrışma yarışlarını önlemek için yeter sayıyı kullanabiliriz.
Çekirdek kavramıyla, düğümlerin ayrışmayı ve/veya kurtarmayı başlatıp başlatmamaları gerektiğini otomatik olarak bilmeleri için sistemde (eşlerine bağlanmadan bile) yeterli bilgi bulunur.
Yeterli çoğunluk olmadığında, bir ağ bölünmesinin her iki tarafı da haklı olarak diğer tarafın öldüğünü varsayacak ve diğerini ayırmaya çalışacaktır. En kötü durumda, her iki taraf da kümenin tamamını kapatmayı başarır. Alternatif bir senaryo ise ölüm eşleşmesidir; düğümlerin sonsuz bir döngüsü ortaya çıkar, eşlerini görmez, onları yeniden başlatır ve yalnızca eşleri aynı mantığı izlediğinde yeniden başlatmak için kurtarmayı başlatır.
Bağlantının kesilmesiyle ilgili sorun, en sık kullanılan cihazların, kurtarma için hedeflemek istediğimiz aynı arıza olayları nedeniyle kullanılamaz hale gelmesidir. Çoğu IPMI ve iLO kartı, kontrol ettikleri ana bilgisayarlara kurulur ve varsayılan olarak aynı ağı kullanır, bu da hedef ana bilgisayarların diğer ana bilgisayarların çevrimdışı olduğuna inanmasına neden olur.
Ne yazık ki IPMI ve iLo cihazlarının çalışma özellikleri, ekipman satın alınırken nadiren dikkate alınır.
Dolaylı ayrışma
Yeter sayısı aynı zamanda dolaylı ayrışmayı yönetmek için de önemlidir; yeter sayısı doğru yapılırsa hayatta kalanların, kayıp düğümlerin belirli bir süre sonra güvenli bir duruma geçeceğini varsaymalarına olanak tanıyabilir.
Bu yapılandırmayla, çekirdek kaybı olmazsa donanım izleme zamanlayıcısı her N saniyede bir sıfırlanır. Zamanlayıcının (genellikle N'nin birkaç katı) süresi dolarsa, cihaz gereksiz bir kapatma işlemi gerçekleştirir (kapatma değil).
Bu yaklaşım çok etkilidir ancak yeterli çoğunluk olmadığında küme içinde onu yönetmek için yeterli bilgi yoktur. Ağ kesintisi ile eş düğüm hatası arasındaki farkı söylemek kolay değildir. Bunun önemli olmasının nedeni, iki durum arasında ayrım yapma yeteneğiniz olmadığında, her iki durumda da aynı davranışı seçmek zorunda kalmanızdır.
Bir mod seçmenin sorunu, kullanılabilirliği en üst düzeye çıkaracak ve veri kaybını önleyecek bir eylem planının bulunmamasıdır.
- Bir eş düğümün etkin olduğunu ancak aslında başarısız olduğunu varsaymayı seçerseniz küme, başarısız eş düğümden kaynaklanan hizmet kaybını telafi etmek için çalışmakta olan hizmetleri gereksiz yere durduracaktır.
- Bir düğümün kapalı olduğunu, ancak bunun yalnızca bir ağ arızası olduğunu ve aslında uzaktaki düğümün işlevsel olduğunu varsaymaya karar verirseniz, o zaman en iyi ihtimalle, sonuçta ortaya çıkan veri kümelerinin gelecekte manuel olarak mutabakatına kaydolmuş olursunuz.
Hangi buluşsal yöntemi kullanırsanız kullanın, her iki tarafın da başarısız olmasına veya kümenin hayatta kalan düğümleri kapatmasına neden olacak bir hata yaratmak önemsizdir. Yeter sayıyı kullanmamak, kümeyi cephaneliğindeki en güçlü araçlardan birinden gerçekten mahrum bırakır.
Başka bir alternatif yoksa, en iyi yaklaşım kullanılabilirliği feda etmektir (burada yazar CAP teoremine atıfta bulunmaktadır). Bozuk verilerin yüksek oranda bulunmasının kimseye faydası yoktur ve farklı veri kümelerini manuel olarak uzlaştırmak da eğlenceli değildir.
nisap
Çoğunluk kulağa harika geliyor, değil mi?
Tek dezavantajı, N üyeli bir kümede yer alabilmek için, kalan düğümlerinizin N/2+1'i arasında bir bağlantıya sahip olmanız gerekir. Bir düğüm başarısız olduktan sonra iki düğümlü bir kümede bu mümkün değildir.
Bu da bizi sonuçta iki düğümle ilgili temel soruna getiriyor:
Çekirdek, iki düğüm kümesinde bir anlam ifade etmez ve bu olmadan, kullanılabilirliği en üst düzeye çıkaran ve veri kaybını önleyen eylem planını güvenilir bir şekilde belirlemek imkansızdır.
Çapraz kabloyla bağlanan iki düğümden oluşan bir sistemde bile, ağ kesintisi ile diğer düğümdeki arıza arasında kesin bir ayrım yapmak imkansızdır. Bir ucun devre dışı bırakılması (bunun olasılığı elbette düğümler arasındaki mesafeyle orantılıdır), bağlantının sağlığının ortak düğümün sağlığına eşit olduğu varsayımını geçersiz kılmak için yeterli olacaktır.
İki düğümlü küme çalışmasını sağlama
Bazen müşteri üçüncü bir düğüm satın alamaz veya almak istemez ve biz de bir alternatif aramak zorunda kalırız.
Seçenek 1 - Yinelenen ayrışma yöntemi
Bir düğümün iLO veya IPMI cihazı bir arıza noktasını temsil eder çünkü arızalanırsa hayatta kalanlar onu düğümü güvenli bir duruma getirmek için kullanamaz. 3 veya daha fazla düğümden oluşan bir kümede, yeter sayıyı hesaplayarak ve bir donanım gözlemcisi (daha önce tartışıldığı gibi dolaylı bir ayırma mekanizması) kullanarak bunu azaltabiliriz. İki düğüm olması durumunda bunun yerine ağ güç dağıtım birimlerini (PDU'lar) kullanmalıyız.
Bir başarısızlıktan sonra mağdur ilk olarak birincil ayırma cihazıyla (yerleşik iLO veya IPMI) iletişim kurmaya çalışır. Bu başarılı olursa iyileşme her zamanki gibi devam eder. Yalnızca iLO/IPMI aygıtı arızalanırsa PDU'ya erişilir; erişim başarılı olursa kurtarma devam edebilir.
PDU'yu küme trafiğinden farklı bir ağa yerleştirdiğinizden emin olun; aksi takdirde tek bir ağ hatası, hem bağlantıyı kesme aygıtlarına erişimi engelleyecek hem de hizmetlerin geri yüklenmesini engelleyecektir.
Burada şu soruyu sorabilirsiniz: PDU tek bir arıza noktası mıdır? Bunun cevabı elbette öyle.
Bu risk sizin için önemliyse yalnız değilsiniz: her iki düğümü de iki PDU'ya bağlayın ve kümeleme yazılımına, düğümleri açıp kapatırken her ikisini de kullanmasını söyleyin. Bir PDU ölürse küme artık etkin kalır ve kurtarmayı engellemek için diğer PDU'da veya IPMI aygıtında ikinci bir arıza olması gerekir.
Seçenek 2 - Hakem Ekleme
Bazı senaryolarda, yinelenen ayrıştırma yöntemi teknik olarak mümkün olsa da politik olarak zordur. Pek çok şirket, yöneticiler ile uygulama sahipleri arasında bir miktar ayrım olmasını ister ve güvenlik bilincine sahip ağ yöneticileri, PDU erişim ayarlarını herhangi biriyle paylaşma konusunda her zaman istekli değildir.
Bu durumda önerilen alternatif, yetersayı hesaplamasına destek olabilecek tarafsız bir üçüncü taraf oluşturmaktır.
Bir arıza durumunda, bir düğümün, hizmetleri geri yükleyebilmesi için eşinin veya hakeminin yayın dalgalarını görebilmesi gerekir. Hakem ayrıca, her iki düğümün de hakemi görebilmesi ancak birbirini görememesi durumunda bir bağlantı kesme işlevi içerir.
Bu seçenek, bir makinenin eşdüzey ve hakem düğümüyle bağlantısını kaybetmesi durumunda makineyi sonlandıracak şekilde yapılandırılmış donanım izleme zamanlayıcısı gibi dolaylı bir ayırma yöntemiyle birlikte kullanılmalıdır. Böylece hayatta kalan kişi, donanım izleme zamanlayıcısının süresi dolduktan sonra eş düğümünün güvenli bir durumda olacağını makul bir şekilde varsayabilir.
Bir hakem ile üçüncü düğüm arasındaki pratik fark, bir hakemin çalışmak için çok daha az kaynağa ihtiyaç duyması ve potansiyel olarak birden fazla kümeye hizmet verebilmesidir.
Seçenek 3 - İnsan faktörü
Son yaklaşım, hayatta kalanların halihazırda çalıştırdıkları hizmetleri çalıştırmaya devam etmeleri, ancak sorun kendi kendine çözülene kadar (ağ geri yükleme, düğüm yeniden başlatma) veya bir kişi diğer tarafın öldüğünü manuel olarak doğrulama sorumluluğunu üstlenene kadar yenilerini başlatmamaktır.
Bonus seçeneği
Üçüncü bir düğüm ekleyebileceğinizi söylemiş miydim?
İki raf
Tartışmayı sürdürmek adına, sizi üçüncü düğümün yararları konusunda ikna ettiğimi varsayalım, şimdi düğümlerin fiziksel düzenini dikkate almalıyız. Aynı rafta barındırılıyorlarsa (ve çalıştırılıyorlarsa), bu da SPoF'u oluşturur ve ikinci bir raf eklenerek çözülemez.
Bu şaşırtıcıysa, iki düğümlü bir rafın arızalanması durumunda ne olacağını ve hayatta kalan düğümün bunu bir ağ arızasından nasıl ayırt edeceğini düşünün.
Kısa cevap, bunun mümkün olmadığı ve yine iki düğüm durumunda tüm sorunlarla uğraştığımızdır. Veya hayatta kalan:
- yetersayıyı göz ardı eder ve ağ kesintileri sırasında hatalı bir şekilde restorasyonu başlatma girişiminde bulunur (ayrışmayı tamamlama yeteneği farklı bir hikayedir ve PDU'nun dahil olup olmadığına ve gücü herhangi bir rafla paylaşıp paylaşmadığına bağlıdır) veya
- yeter sayıya saygı duyar ve eş düğümü başarısız olduğunda kendi bağlantısını zamanından önce keser
Her durumda, iki raf bir taneden daha iyi değildir ve düğümlerin ya bağımsız güç kaynakları alması ya da üç (veya sahip olduğunuz düğüm sayısına bağlı olarak daha fazla) rafa dağıtılması gerekir.
İki veri merkezi
Bu noktada artık riskten kaçınmayan okuyucular felaket kurtarmayı düşünmek isteyebilir. Bir asteroit, üç farklı rafa yayılmış üç düğümümüzle aynı veri merkezine çarptığında ne olur? Açıkçası Kötü Şeyler, ancak ihtiyaçlarınıza bağlı olarak ikinci bir veri merkezi eklemek yeterli olmayabilir.
Doğru şekilde yapılırsa, ikinci veri merkezi size (ve makul ölçüde) hizmetlerinizin ve verilerinizin güncel ve tutarlı bir kopyasını sağlar. Ancak iki düğümlü, iki raflı senaryolarda olduğu gibi, sistemde maksimum kullanılabilirliği sağlamak ve bozulmayı (veya veri kümesi tutarsızlıklarını) önlemek için yeterli bilgi yoktur. Üç düğüm (veya raf) olsa bile, bunları yalnızca iki veri merkezine dağıtmak, her iki tarafın da iletişim kuramadığı (artık çok daha muhtemel) bir olay durumunda sistemin güvenilir bir şekilde doğru kararı verememesine neden olur.
Bu, ikili veri merkezi çözümünün hiçbir zaman uygun olmadığı anlamına gelmez. Şirketler genellikle bir kişinin yedek veri merkezine taşınmak gibi olağanüstü bir adım atmadan önce bunun farkında olmasını ister. Kesintiyi otomatikleştirmek istiyorsanız, yeterli çoğunluğun anlamlı olması için üçüncü bir veri merkezine ihtiyacınız olacağını (doğrudan veya bir hakem aracılığıyla) veya tüm verileri güvenilir bir şekilde kapatmanın bir yolunu bulacağınızı unutmayın. merkez.
Kaynak: habr.com