Ey Habr!
Yeni Yıl tatilinin ardından, iki siteyi temel alan, felakete dayanıklı bir bulutu yeniden hizmete sunduk. Bugün size bunun nasıl çalıştığını anlatacağız ve kümenin ayrı ayrı öğeleri arızalandığında ve tüm site çöktüğünde istemci sanal makinelerine ne olacağını göstereceğiz (spoiler - onlarla her şey yolunda).
OST sitesinde felakete dayanıklı bulut depolama sistemi.
İçinde neler var
Kaputun altında, kümede VMware ESXi hipervizörlü Cisco UCS sunucuları, iki INFINIDAT InfiniBox F2240 depolama sistemi, Cisco Nexus ağ ekipmanı ve Brocade SAN anahtarları bulunuyor. Küme iki bölgeye ayrılmıştır - OST ve NORD, yani. her veri merkezi aynı ekipman setine sahiptir. Aslında onu felaketlere karşı dayanıklı kılan da bu.
Bir site içinde ana öğeler de kopyalanır (ana bilgisayarlar, SAN anahtarları, ağ iletişimi).
İki saha, yine ayrılmış olan özel fiber optik yollarla birbirine bağlanmıştır.
Depolama sistemleri hakkında birkaç söz. NetApp üzerinde felaketlere dayanıklı bulutun ilk versiyonunu oluşturduk. Burada INFINIDAT'ı seçtik ve işte nedeni:
- Aktif-Aktif çoğaltma seçeneği. Depolama sistemlerinden biri tamamen arızalansa bile sanal makinenin çalışır durumda kalmasını sağlar. Çoğaltma hakkında daha sonra size daha fazla bilgi vereceğim.
- Sistem hata toleransını artırmak için üç disk denetleyicisi. Genellikle iki tane vardır.
- Hazır çözüm. Sadece ağa bağlanması ve yapılandırılması gereken, önceden monte edilmiş bir raf aldık.
- Özenli teknik destek. INFINIDAT mühendisleri, depolama sistemi günlüklerini ve olaylarını sürekli olarak analiz eder, yeni ürün yazılımı sürümlerini yükler ve yapılandırmaya yardımcı olur.
İşte ambalajın açılmasından bazı fotoğraflar:
Nasıl çalışıyor
Bulut zaten kendi içinde hataya dayanıklı. İstemciyi tek donanım ve yazılım arızalarından korur. Felaketlere dayanıklılık, bir sitedeki büyük arızalara karşı korunmaya yardımcı olacaktır: örneğin, bir depolama sisteminin (veya oldukça sık meydana gelen bir SDS kümesinin) arızası, bir depolama ağındaki büyük hatalar vb. Ve en önemlisi: böyle bir bulut, bir yangın, elektrik kesintisi, akıncıların ele geçirmesi veya uzaylıların inişi nedeniyle tüm siteye erişilemez hale geldiğinde tasarruf sağlar.
Tüm bu durumlarda istemci sanal makineleri çalışmaya devam eder ve nedeni budur.
Küme tasarımı, istemci sanal makinelerine sahip herhangi bir ESXi ana bilgisayarının iki depolama sisteminden herhangi birine erişebileceği şekilde tasarlanmıştır. OST sitesindeki depolama sistemi arızalanırsa sanal makineler çalışmaya devam edecek: üzerinde çalıştıkları ana bilgisayarlar, veriler için NORD'daki depolama sistemine erişecek.
Bir kümedeki bağlantı şeması böyle görünür.
Bu, iki sitenin SAN yapıları arasında bir Anahtarlar Arası Bağlantının yapılandırılması nedeniyle mümkündür: Yapı A OST SAN anahtarı, Yapı A NORD SAN anahtarına bağlanır ve Yapı B SAN anahtarları için de benzer şekilde bağlanır.
SAN fabrikalarının tüm bu karmaşıklıklarının anlamlı olması için, iki depolama sistemi arasında Aktif-Aktif çoğaltma yapılandırılır: bilgiler yerel ve uzak depolama sistemlerine neredeyse aynı anda yazılır, RPO = 0. Orijinal verilerin bir depolama sisteminde, kopyasının ise diğerinde depolandığı ortaya çıktı. Veriler, depolama birimleri düzeyinde çoğaltılır ve VM verileri (diskleri, yapılandırma dosyası, takas dosyası vb.) bunların üzerinde depolanır.
ESXi ana bilgisayarı, birincil birimi ve onun kopyasını tek bir disk aygıtı (Depolama Aygıtı) olarak görür. ESXi ana bilgisayarından her disk aygıtına 24 yol vardır:
12 yol onu yerel depolama sistemine (optimal yollar) ve geri kalan 12 yolu da uzak depolama sistemine (optimal olmayan yollar) bağlar. Normal bir durumda ESXi, yerel depolama sistemindeki verilere "en uygun" yolları kullanarak erişir. Bu depolama sistemi arızalandığında ESXi en uygun yolları kaybeder ve "optimal olmayan" yollara geçer. Diyagramda böyle görünüyor.
Afete dayanıklı bir kümenin şeması.
Tüm istemci ağları, ortak bir ağ yapısı aracılığıyla her iki siteye de bağlanır. Her site, istemcinin ağlarının sonlandırıldığı bir Sağlayıcı Kenarı (PE) çalıştırır. PE'ler ortak bir kümede birleştirilir. PE bir sitede arızalanırsa tüm trafik ikinci siteye yönlendirilir. Bu sayede PE'siz kalan sitedeki sanal makineler ağ üzerinden istemciye erişilebilir durumda kalır.
Şimdi çeşitli arızalar sırasında istemci sanal makinelerine ne olacağını görelim. En hafif seçeneklerle başlayalım ve tüm sitenin en ciddi başarısızlığıyla bitirelim. Örneklerde ana platform OST olacak ve veri kopyalarıyla birlikte yedekleme platformu da NORD olacaktır.
İstemci sanal makinesine ne olur?
Çoğaltma Bağlantısı başarısız oluyor. İki sitenin depolama sistemleri arasındaki çoğaltma durur.
ESXi yalnızca yerel disk aygıtlarıyla (optimum yollar aracılığıyla) çalışır.
Sanal makineler çalışmaya devam ediyor.
ISL (Anahtarlar Arası Bağlantı) kopuyor. Durum pek olası değil. Tabii çılgın bir ekskavatör, bağımsız rotalar üzerinde çalışan ve farklı girdilerle sahalara getirilen birkaç optik rotayı aynı anda kazmazsa. Ama yine de. Bu durumda ESXi ana bilgisayarları yolların yarısını kaybeder ve yalnızca yerel depolama sistemlerine erişebilir. Kopyalar toplanır ancak toplantı sahipleri bunlara erişemez.
Sanal makineler normal çalışıyor.
SAN anahtarı sitelerden birinde arızalanıyor. ESXi ana bilgisayarları depolama sistemine giden yolların bir kısmını kaybeder. Bu durumda, anahtarın başarısız olduğu sitedeki ana bilgisayarlar yalnızca HBA'larından biri aracılığıyla çalışacaktır.
Sanal makineler normal şekilde çalışmaya devam eder.
Sitelerden birindeki tüm SAN anahtarları arızalı. Diyelim ki OST sitesinde böyle bir felaket yaşandı. Bu durumda, bu sitedeki ESXi ana bilgisayarları disk aygıtlarına giden tüm yolları kaybedecektir. Standart VMware vSphere HA mekanizması devreye giriyor: NORD'daki OST sitesindeki tüm sanal makineleri maksimum 140 saniye içinde yeniden başlatacak.
NORD site ana bilgisayarlarında çalışan sanal makineler normal şekilde çalışıyor.
ESXi ana bilgisayarı bir sitede hata veriyor. Burada vSphere HA mekanizması yeniden çalışır: Arızalı ana bilgisayardaki sanal makineler, aynı veya uzak sitedeki diğer ana bilgisayarlarda yeniden başlatılır. Sanal makinenin yeniden başlatma süresi 1 dakikaya kadardır.
OST sitesindeki tüm ESXi ana bilgisayarları arızalanırsa başka seçenek yoktur: VM'ler başka bir yerde yeniden başlatılır. Yeniden başlatma süresi aynıdır.
Depolama sistemi bir sitede arızalanıyor. Diyelim ki depolama sistemi OST sitesinde arızalandı. Daha sonra OST sitesinin ESXi ana bilgisayarları NORD'daki depolama kopyalarıyla çalışmaya geçer. Arızalı depolama sistemi hizmete döndükten sonra zorunlu çoğaltma gerçekleşecek ve ESXi OST ana bilgisayarları yeniden yerel depolama sistemine erişmeye başlayacaktır.
Sanal makineler bunca zamandır normal şekilde çalışıyor.
Sitelerden biri başarısız oldu. Bu durumda yedekleme sitesindeki tüm sanal makineler vSphere HA mekanizması aracılığıyla yeniden başlatılacaktır. VM yeniden başlatma süresi 140 saniyedir. Bu durumda, sanal makinenin tüm ağ ayarları kaydedilecek ve ağ üzerinden istemci tarafından erişilebilir olmaya devam edecektir.
Yedekleme sahasındaki makinelerin yeniden başlatılmasının sorunsuz bir şekilde gerçekleşmesini sağlamak için her sahanın yalnızca yarısı doludur. İkinci yarı, tüm sanal makinelerin ikinci, hasarlı siteden taşınması durumunda bir yedektir.
Felaketlere dayanıklı, iki veri merkezini temel alan bir bulut, bu tür arızalara karşı koruma sağlar.
Bu zevk ucuz değil çünkü ana kaynaklara ek olarak ikinci sitede de bir rezerv gerekiyor. Bu nedenle, iş açısından kritik hizmetler, uzun vadeli kesintiler büyük finansal ve itibar kayıplarına neden olan veya bilgi sisteminin düzenleyici kurumların veya şirket içi düzenlemelerin felakete dayanıklılık gereksinimlerine tabi olduğu böyle bir buluta yerleştirilir.
Kaynaklar:
Kaynak: habr.com