Merhaba Habr okuyucuları! Bu makalenin konusu felaket kurtarma araçlarının AERODISK Engine depolama sistemlerinde uygulanması olacaktır. Başlangıçta her iki araç hakkında tek bir makale yazmak istedik: replikasyon ve metrocluster, ancak ne yazık ki makale çok uzun olduğu için makaleyi iki bölüme ayırdık. Basitten karmaşığa doğru gidelim. Bu yazıda senkronize çoğaltmayı kurup test edeceğiz - bir veri merkezini bırakacağız ve ayrıca veri merkezleri arasındaki iletişim kanalını kesip ne olacağını göreceğiz.
Müşterilerimiz sıklıkla bize çoğaltmayla ilgili çeşitli sorular soruyor; bu nedenle, kopyaların kurulumuna ve uygulanmasını test etmeye geçmeden önce, depolamada çoğaltmanın ne olduğu hakkında size biraz bilgi vereceğiz.
Biraz teori
Depolama sistemlerinde çoğaltma, aynı anda birden fazla depolama sisteminde veri kimliğinin sağlanmasına yönelik sürekli bir süreçtir. Teknik olarak çoğaltma iki şekilde gerçekleştirilir.
Eşzamanlı çoğaltma – bu, verilerin ana depolama sisteminden yedek sisteme kopyalanması ve ardından her iki depolama sisteminden de verilerin kaydedilip onaylandığının zorunlu olarak onaylanmasıdır. Her iki tarafta (her iki depolama sistemi) onay alındıktan sonra veriler kayıtlı kabul edilir ve üzerinde çalışılabilir. Bu, kopyaya katılan tüm depolama sistemlerinde garantili veri kimliği sağlar.
Bu yöntemin avantajları:
- Veriler tüm depolama sistemlerinde her zaman aynıdır
Eksileri:
- Çözümün yüksek maliyeti (hızlı iletişim kanalları, pahalı optik fiber, uzun dalga alıcı-vericiler vb.)
- Mesafe kısıtlamaları (onlarca kilometre dahilinde)
- Mantıksal veri bozulmasına karşı koruma yoktur (ana depolama sistemindeki veriler bozulursa (kasıtlı veya kazara), veriler her zaman aynı olduğundan yedek sistemde otomatik olarak ve anında bozulur (paradoks budur)
Eşzamansız çoğaltma – bu aynı zamanda verilerin ana depolama sisteminden yedek sisteme kopyalanmasıdır, ancak belirli bir gecikmeyle ve diğer taraftaki yazmayı onaylamaya gerek yoktur. Verileri ana depolama sistemine kaydettikten hemen sonra verilerle çalışabilirsiniz ve veriler bir süre sonra yedek depolama sisteminde kullanılabilir olacaktır. Bu durumda verilerin kimliği elbette hiçbir şekilde garanti edilmez. Yedekleme depolama sistemindeki veriler her zaman biraz "geçmiştedir".
Eşzamansız çoğaltmanın artıları:
- Düşük maliyetli çözüm (herhangi bir iletişim kanalı, isteğe bağlı optik)
- Mesafe sınırlaması yok
- Yedek depolama sisteminde, ana sistemdeki veriler hasar görürse (en azından bir süreliğine) bozulmaz; veriler bozulursa, yedek depolama sistemindeki verilerin bozulmasını önlemek için çoğaltmayı her zaman durdurabilirsiniz.
Eksileri:
- Farklı veri merkezlerindeki veriler her zaman aynı değildir
Bu nedenle çoğaltma modunun seçimi iş hedeflerine bağlıdır. Yedek veri merkezinin ana veri merkeziyle tam olarak aynı verileri içermesi sizin için kritikse (örn. RPO için iş gereksinimi = 0), o zaman parayı dağıtmanız ve senkronize bir veri merkezinin sınırlamalarına katlanmanız gerekecektir. kopya. Veri durumundaki gecikme kabul edilebilirse veya para yoksa, o zaman kesinlikle eşzamansız yöntemi kullanmanız gerekir.
Ayrıca böyle bir modu (daha doğrusu bir topolojiyi) bir metrocluster olarak ayrı ayrı vurgulayalım. Metrocluster modunda eşzamanlı çoğaltma kullanılır, ancak normal kopyadan farklı olarak metrocluster her iki depolama sisteminin de etkin modda çalışmasına izin verir. Onlar. aktif ve yedek veri merkezleri arasında bir ayrımınız yoktur. Uygulamalar, fiziksel olarak farklı veri merkezlerinde bulunan iki depolama sistemiyle eş zamanlı çalışır. Böyle bir topolojide kazalar sırasındaki kesinti süreleri çok küçüktür (RTO, genellikle dakikalar). Bu yazıda metrocluster uygulamamızı ele almayacağız, çünkü bu çok geniş ve kapsamlı bir konu, bu yüzden bunun devamında buna ayrı bir sonraki makaleyi ayıracağız.
Ayrıca, depolama sistemlerini kullanarak çoğaltma hakkında konuştuğumuzda çoğu kişinin aklına şu makul soru gelir: > "Birçok uygulamanın kendi çoğaltma araçları vardır, neden depolama sistemlerinde çoğaltma kullanalım ki? Daha mı iyi yoksa daha mı kötü?
Burada net bir cevap yok, işte FOR ve CONS argümanları:
Depolama çoğaltması İÇİN bağımsız değişkenler:
- Çözümün basitliği. Tek bir araçla, yük türü ve uygulamadan bağımsız olarak tüm veri kümenizi çoğaltabilirsiniz. Uygulamalardan bir kopya kullanıyorsanız her uygulamayı ayrı ayrı yapılandırmanız gerekecektir. Bunlardan 2'den fazlası varsa, bu son derece emek yoğun ve pahalıdır (uygulama çoğaltma genellikle her uygulama için ayrı ve ücretsiz olmayan bir lisans gerektirir. Ancak bu konuda daha fazlası aşağıdadır).
- Her şeyi (her uygulamayı, her veriyi) çoğaltabilirsiniz ve bu her zaman tutarlı olacaktır. Çoğu (çoğu) uygulamanın çoğaltma özelliği yoktur ve depolama sistemindeki kopyalar felaketlere karşı koruma sağlamanın tek yoludur.
- Uygulama çoğaltma işlevi için fazla ödeme yapmanıza gerek yoktur. Kural olarak, tıpkı bir depolama sistemi kopyası için lisanslar gibi ucuz değildir. Ancak depolama çoğaltma lisansı için bir kez ödeme yapmanız gerekir ve her uygulama için ayrı olarak uygulama çoğaltma lisansının satın alınması gerekir. Bu tür çok sayıda uygulama varsa, bu oldukça pahalıya mal olur ve depolama çoğaltma lisanslarının maliyeti kovada bir düşüş olur.
Depolama çoğaltmasına karşı argümanlar:
- Uygulamalar aracılığıyla kopyalama, uygulamaların bakış açısından daha fazla işlevselliğe sahiptir, uygulama verilerini daha iyi bilir (açıkçası), dolayısıyla onlarla çalışmak için daha fazla seçenek vardır.
- Bazı uygulamaların üreticileri, çoğaltmanın üçüncü taraf araçlar kullanılarak yapılması durumunda verilerinin tutarlılığını garanti etmez. *
* - tartışmalı tez. Örneğin, tanınmış bir DBMS üreticisi, çok uzun bir süredir resmi olarak DBMS'lerinin yalnızca kendi araçları kullanılarak normal şekilde kopyalanabileceğini ve çoğaltmanın geri kalanının (depolama sistemleri dahil) "doğru olmadığını" beyan ediyor. Ama hayat bunun böyle olmadığını gösterdi. Büyük olasılıkla (ancak bu kesin değil) bu, müşterilere daha fazla lisans satmaya yönelik en dürüst girişim değildir.
Sonuç olarak çoğu durumda depolama sisteminden çoğaltma daha iyidir çünkü Bu daha basit ve daha ucuz bir seçenektir ancak belirli uygulama işlevselliğinin gerekli olduğu ve uygulama düzeyinde çoğaltmayla çalışmanın gerekli olduğu karmaşık durumlar vardır.
Teori bitti, şimdi pratik
Replikayı laboratuvarımızda yapılandıracağız. Laboratuvar koşullarında iki veri merkezini (aslında farklı binalardaymış gibi görünen iki bitişik raf) taklit ettik. Stand, birbirine optik kablolarla bağlanan iki Engine N2 depolama sisteminden oluşur. Windows Server 2016 çalıştıran fiziksel bir sunucu, her iki depolama sistemine de 10 Gb Ethernet kullanılarak bağlanır. Stand oldukça basit ama bu özü değiştirmiyor.
Şematik olarak şöyle görünür:
Mantıksal olarak çoğaltma şu şekilde düzenlenir:
Şimdi sahip olduğumuz çoğaltma işlevine bakalım.
İki mod desteklenir: eşzamansız ve eşzamanlı. Senkron modun mesafe ve iletişim kanalıyla sınırlı olması mantıklıdır. Özellikle senkron mod, fizik olarak fiber ve 10 Gigabit Ethernet (veya üzeri) kullanımını gerektirir.
Senkron kopyalama için desteklenen mesafe 40 kilometre olup, optik kanalın veri merkezleri arasındaki gecikme değeri 2 milisaniyeye kadar çıkmaktadır. Genel olarak büyük gecikmelerle çalışacaktır, ancak kayıt sırasında güçlü yavaşlamalar olacaktır (ki bu da mantıklıdır), bu nedenle veri merkezleri arasında senkronize çoğaltma planlıyorsanız optiklerin kalitesini ve gecikmeleri kontrol etmelisiniz.
Eşzamansız çoğaltma gereksinimleri o kadar ciddi değildir. Daha doğrusu hiç orada değiller. Çalışan herhangi bir Ethernet bağlantısı işe yarayacaktır.
Şu anda AERODISK ENGINE depolama sistemi, Ethernet protokolü (bakır veya optik üzerinden) aracılığıyla blok aygıtların (LUN'lar) çoğaltılmasını desteklemektedir. Fiber Kanal üzerinden SAN yapısı üzerinden replikasyonun gerekli olduğu projeler için şu anda uygun bir çözüm ekliyoruz ancak henüz hazır değil, dolayısıyla bizim durumumuzda yalnızca Ethernet.
Çoğaltma, küçük sistemlerden eski sistemlere ve bunun tersi gibi tüm ENGINE serisi depolama sistemleri (N1, N2, N4) arasında çalışabilir.
Her iki çoğaltma modunun işlevselliği tamamen aynıdır. Aşağıda mevcut olanlarla ilgili daha fazla ayrıntı verilmiştir:
- Çoğaltma “bire bir” veya “bire bir”, yani ana ve yedek olmak üzere iki veri merkezine sahip klasik versiyon
- Çoğaltma "birden çoğa" veya "birden çoğa"dır, yani. bir LUN aynı anda birden fazla depolama sistemine kopyalanabilir
- Çoğaltma yönünü etkinleştirmek, devre dışı bırakmak veya değiştirmek için sırasıyla çoğaltmayı etkinleştirin, devre dışı bırakın ve "tersine çevirin"
- Çoğaltma, hem RDG (Raid Distributed Group) hem de DDP (Dinamik Disk Havuzu) havuzları için kullanılabilir. Ancak bir RDG havuzunun LUN'ları yalnızca başka bir RDG'ye kopyalanabilir. DDP'de de aynısı var.
Daha birçok küçük özellik var ama bunları listelemenin özel bir anlamı yok, kurulum sırasında bunlara değineceğiz.
Çoğaltmayı ayarlama
Kurulum işlemi oldukça basittir ve üç aşamadan oluşur.
- Ağ yapılandırması
- Depolama kurulumu
- Kuralları (bağlantıları) ayarlama ve eşleme
Çoğaltma kurulumunda önemli bir nokta, ilk iki aşamanın uzak depolama sisteminde, üçüncü aşamanın ise yalnızca ana sistemde tekrarlanması gerektiğidir.
Ağ kaynaklarını ayarlama
İlk adım, çoğaltma trafiğinin iletileceği ağ bağlantı noktalarını yapılandırmaktır. Bunu yapmak için Ön uç bağdaştırıcılar bölümünde bağlantı noktalarını etkinleştirmeniz ve IP adreslerini ayarlamanız gerekir.
Bundan sonra bir havuz (bizim durumumuzda RDG) ve çoğaltma için bir sanal IP (VIP) oluşturmamız gerekiyor. VIP, depolama denetleyicilerinin (az önce yapılandırdığımız bağlantı noktaları) iki "fiziksel" adresine bağlı değişken bir IP adresidir. Bu ana çoğaltma arayüzü olacaktır. Etiketli trafikle çalışmanız gerekiyorsa VIP ile değil VLAN ile de çalışabilirsiniz.
Replika için VIP oluşturma süreci, G/Ç için VIP (NFS, SMB, iSCSI) oluşturmaktan pek farklı değildir. Bu durumda normal bir VIP oluşturuyoruz (VLAN olmadan), ancak bunun çoğaltma için olduğunu belirttiğinizden emin olun (bu işaretçi olmadan bir sonraki adımda kurala VIP ekleyemeyiz).
VIP, aralarında dolaştığı IP bağlantı noktalarıyla aynı alt ağda olmalıdır.
Bu ayarları elbette farklı bir IP ile uzak bir depolama sisteminde tekrarlıyoruz.
Farklı depolama sistemlerinden gelen VIP'ler farklı alt ağlarda olabilir, asıl önemli olan aralarında yönlendirme olmasıdır. Bizim durumumuzda bu örnek tam olarak gösterilmektedir (192.168.3.XX ve 192.168.2.XX)
Bu, ağ kısmının hazırlanmasını tamamlar.
Depolamayı ayarlama
Bir kopya için depolamayı ayarlamak, yalnızca eşlemeyi özel bir "Çoğaltma Eşleme" menüsü aracılığıyla yapmamız açısından normalden farklıdır. Aksi takdirde her şey normal kurulumdakiyle aynıdır. Şimdi sırayla.
Daha önce oluşturulan R02 havuzunda bir LUN oluşturmanız gerekir. Bunu oluşturalım ve LUN1 olarak adlandıralım.
Aynı LUN'u aynı boyuttaki bir uzak depolama sisteminde de oluşturmamız gerekiyor. Biz yaratırız. Karışıklığı önlemek için uzak LUN LUN1R'yi arayalım
Zaten var olan bir LUN'u almamız gerekiyorsa, kopyayı ayarlarken bu üretken LUN'un ana bilgisayarla bağlantısını kesmemiz ve uzak depolama sisteminde aynı boyutta boş bir LUN oluşturmamız gerekir.
Depolama kurulumu tamamlandı, çoğaltma kuralı oluşturmaya geçelim.
Çoğaltma kurallarını veya çoğaltma bağlantılarını ayarlama
Şu anda birincil olacak depolama sistemi üzerinde LUN'lar oluşturduktan sonra, depolama sistemi 1'deki LUN1'i depolama sistemi 1'deki LUN2R'ye kopyalama kuralını yapılandırıyoruz.
Ayar “Uzaktan çoğaltma” menüsünde yapılır
Bir kural oluşturalım. Bunu yapmak için kopyanın alıcısını belirtmeniz gerekir. Burada ayrıca bağlantının adını ve çoğaltma türünü (senkron veya asenkron) da ayarladık.
“Uzak sistemler” alanına depolama sistemimizi2 ekliyoruz. Eklemek için yönetim IP depolama sistemlerini (MGR) ve çoğaltma gerçekleştireceğimiz uzak LUN'un adını (bizim durumumuzda LUN1R) kullanmanız gerekir. Kontrol IP'lerine yalnızca bağlantı ekleme aşamasında ihtiyaç duyulur; çoğaltma trafiği bunlar üzerinden iletilmez; bunun için önceden yapılandırılmış VIP kullanılacaktır.
Zaten bu aşamada “birden çoğa” topolojisi için birden fazla uzak sistem ekleyebiliriz: aşağıdaki şekilde olduğu gibi “düğüm ekle” butonuna tıklayın.
Bizim durumumuzda yalnızca bir uzak sistem var, bu yüzden kendimizi bununla sınırlıyoruz.
Kural hazır. Lütfen tüm çoğaltma katılımcılarına otomatik olarak eklendiğini unutmayın (bizim durumumuzda bunlardan iki tane var). İstediğiniz sayıda LUN için ve istediğiniz yönde istediğiniz kadar kural oluşturabilirsiniz. Örneğin yükü dengelemek için LUN'ların bir kısmını depolama sistemi 1'den depolama sistemi 2'ye, diğer kısmını ise tam tersine depolama sistemi 2'den depolama sistemi 1'e kopyalayabiliriz.
Depolama sistemi1. Oluşturulduktan hemen sonra senkronizasyon başladı.
Depolama sistemi2. Aynı kuralı görüyoruz ancak senkronizasyon zaten sona erdi.
Depolama sistemi 1'deki LUN1 Birincil roldedir, yani etkindir. Depolama sistemi 1'deki LUN2R, İkincil rolündedir, yani depolama sistemi 1'in arızalanması durumunda beklemededir.
Artık LUN'umuzu ana bilgisayara bağlayabiliriz.
FC aracılığıyla da yapılabilse de iSCSI aracılığıyla bağlanacağız. Bir kopyada iSCSI LUN aracılığıyla eşlemenin ayarlanması pratik olarak olağan senaryodan farklı değildir, bu nedenle bunu burada ayrıntılı olarak ele almayacağız. Varsa bu süreç şu makalede anlatılıyor:'.
Tek farkımız “Replication Mapping” menüsünde haritalama oluşturmamızdır.
Haritalamayı kurduk ve LUN'u ana bilgisayara verdik. Toplantı sahibi LUN'u gördü.
Yerel bir dosya sistemine biçimlendiriyoruz.
İşte bu, kurulum tamamlandı. Daha sonra testler gelecek.
Test
Üç ana senaryoyu test edeceğiz.
- Düzenli rol değiştirme İkincil > Birincil. Örneğin ana veri merkezinde bazı önleyici işlemler yapmamız gerektiğinde düzenli rol değişimine ihtiyaç duyulur ve bu süre zarfında verinin kullanılabilir olması için yükü yedek veri merkezine aktarırız.
- Acil durum rolü değiştirme İkincil > Birincil (veri merkezi arızası). Bu, çoğaltmanın mevcut olduğu ana senaryodur ve şirketi uzun bir süre durdurmadan tam bir veri merkezi arızasından kurtulmaya yardımcı olabilir.
- Veri merkezleri arasındaki iletişim kanallarının dökümü. Bazı nedenlerden dolayı veri merkezleri arasındaki iletişim kanalının kullanılamadığı durumlarda (örneğin, bir ekskavatörün yanlış yeri kazması ve karanlık optikleri kırması) iki depolama sisteminin doğru davranışının kontrol edilmesi.
Öncelikle LUN'umuza veri yazmaya başlayacağız (rastgele veriler içeren dosyalar yazmaya). Depolama sistemleri arasındaki iletişim kanalının kullanıldığını hemen görüyoruz. Çoğaltmadan sorumlu bağlantı noktalarının yük izlemesini açarsanız bunu anlamak kolaydır.
Artık her iki depolama sisteminde de “faydalı” veriler var, teste başlayabiliriz.
Her ihtimale karşı, dosyalardan birinin hash toplamlarına bakalım ve bunları yazalım.
Düzenli rol değiştirme
Rolleri değiştirme işlemi (çoğaltma yönünü değiştirme) herhangi bir depolama sistemiyle yapılabilir, ancak yine de her ikisine de gitmeniz gerekecektir, çünkü Birincil'de eşlemeyi devre dışı bırakmanız ve İkincil'de (Birincil olacak) etkinleştirmeniz gerekecektir. ).
Belki şimdi makul bir soru ortaya çıkıyor: Neden bunu otomatikleştirmiyorsunuz? Cevap şudur: Çok basit; çoğaltma, yalnızca manuel işlemlere dayalı, felakete dayanıklılık için basit bir araçtır. Bu işlemleri otomatikleştirmek için bir metrocluster modu vardır; tamamen otomatiktir, ancak yapılandırması çok daha karmaşıktır. Bir sonraki yazımızda metrocluster kurulumu hakkında yazacağız.
Ana depolama sisteminde kaydın durmasını sağlamak için eşlemeyi devre dışı bırakıyoruz.
Daha sonra depolama sistemlerinden birinde (ana veya yedekte olması fark etmez) “Uzaktan çoğaltma” menüsünde REPL1 bağlantımızı seçin ve “Rolü değiştir”e tıklayın.
Birkaç saniye sonra LUN1R (yedek depolama sistemi) Birincil olur.
LUN1R'yi depolama sistemi2 ile eşliyoruz.
Bundan sonra E: sürücümüz ana bilgisayara otomatik olarak bağlanır, ancak bu sefer LUN1R'den "gelir".
Her ihtimale karşı karma toplamlarını karşılaştırırız.
Aynı şekilde. Test geçildi.
Yük devretme. Veri merkezi arızası
Şu anda, düzenli geçişten sonra ana depolama sistemi sırasıyla depolama sistemi 2 ve LUN1R'dir. Bir kazayı taklit etmek için her iki depolama denetleyicisinin2 gücünü kapatacağız.
Artık ona erişim yok.
Depolama sistemi 1'de (şu anda yedek olan) neler olduğunu görelim.
Birincil LUN'un (LUN1R) kullanılamadığını görüyoruz. Günlüklerde, bilgi panelinde ve ayrıca çoğaltma kuralının kendisinde bir hata mesajı belirdi. Buna göre, ana bilgisayardan gelen veriler şu anda kullanılamıyor.
LUN1'in rolünü Birincil olarak değiştirin.
Ana makineye haritalama yapıyorum.
Ana bilgisayarda E sürücüsünün göründüğünden emin olun.
Hash'ı kontrol ediyoruz.
Herşey yolunda. Depolama sistemi, aktif olan veri merkezinin çöküşünü başarıyla atlattı. Çoğaltma "geri alınmasını" bağlamak ve LUN'u yedek veri merkezinden bağlamak için harcadığımız yaklaşık süre yaklaşık 3 dakikaydı. Gerçek üretimde her şeyin çok daha karmaşık olduğu ve depolama sistemleriyle yapılan işlemlere ek olarak ağda, ana bilgisayarlarda, uygulamalarda çok daha fazla işlem gerçekleştirmeniz gerektiği açıktır. Ve hayatta bu süre çok daha uzun olacak.
Buraya her şeyin, testin başarıyla tamamlandığını yazmak isterim ama acele etmeyelim. Ana depolama sistemi “yalan söylüyor”, “düştüğünde” Birincil rolde olduğunu biliyoruz. Aniden açılırsa ne olur? Veri bozulmasına eşit olan iki Birincil rol olacak mı? Şimdi kontrol edelim.
Aniden temel depolama sistemini açalım.
Birkaç dakika boyunca yüklenir ve kısa bir senkronizasyonun ardından İkincil rolünde hizmete geri döner.
Her şey yolunda. Bölünmüş beyin gerçekleşmedi. Bunu düşündük ve depolama sistemi her zaman bir düşüşten sonra, "yaşam boyunca" hangi rolde olduğuna bakılmaksızın İkincil rolüne yükselir. Artık veri merkezi arıza testinin başarılı olduğunu kesin olarak söyleyebiliriz.
Veri merkezleri arasındaki iletişim kanallarının arızalanması
Bu testin ana görevi, depolama sisteminin iki depolama sistemi arasındaki iletişim kanallarını geçici olarak kaybedip tekrar ortaya çıkması durumunda tuhaf davranmaya başlamamasını sağlamaktır.
Bu yüzden. Depolama sistemleri arasındaki kabloların bağlantısını kesiyoruz (bir ekskavatör tarafından kazıldığını hayal edelim).
Primary'de Secondary ile hiçbir bağlantının olmadığını görüyoruz.
İkincil'de Birincil ile hiçbir bağlantının olmadığını görüyoruz.
Her şey yolunda gidiyor ve ana depolama sistemine veri yazmaya devam ediyoruz, yani yedek sistemden farklı olmaları garanti ediliyor, yani "ayrılmışlar".
Birkaç dakika içinde iletişim kanalını “onarıyoruz”. Depolama sistemleri birbirini gördüğü anda veri senkronizasyonu otomatik olarak etkinleştirilir. Burada yöneticiden hiçbir şey istenmiyor.
Bir süre sonra senkronizasyon tamamlanır.
Bağlantı yeniden sağlandı, iletişim kanallarının kaybı herhangi bir acil duruma neden olmadı ve açıldıktan sonra senkronizasyon otomatik olarak gerçekleşti.
Bulgular
Teoriyi analiz ettik - neye ihtiyaç var ve neden, artıları nerede ve eksileri nerede. Daha sonra iki depolama sistemi arasında senkron replikasyon ayarlıyoruz.
Daha sonra normal anahtarlama, veri merkezi arızası ve iletişim kanalı arızası için temel testler gerçekleştirildi. Her durumda depolama sistemi iyi çalıştı. Manuel senaryoda veri kaybı olmaz ve idari işlemler minimumda tutulur.
Bir dahaki sefere durumu daha da karmaşık hale getireceğiz ve tüm bu mantığın otomatikleştirilmiş bir metrocluster'da aktif-aktif modda, yani her iki depolama sisteminin de birincil olduğu ve depolama sistemi arızası durumunda davranışın tamamen otomatik olduğu durumlarda nasıl çalıştığını göstereceğiz.
Lütfen yorumlarınızı yazın, sağlam eleştiri ve pratik tavsiyeler almaktan memnuniyet duyarız.
Bir dahaki sefere kadar.
Kaynak: habr.com