Merhaba Habr okuyucuları! Son yazımızda AERODISK ENGINE depolama sistemlerinde felaketten kurtarmanın basit bir yolu olan replikasyondan bahsetmiştik. Bu makalede, daha karmaşık ve ilginç bir konuya - metrocluster'a, yani iki veri merkezi için veri merkezlerinin aktif-aktif modda çalışmasına olanak tanıyan otomatik felaketten koruma aracına dalacağız. Size anlatacağız, göstereceğiz, kıracağız ve tamir edeceğiz.
Her zamanki gibi önce teori
Metroküme, bir şehir veya bölge içindeki çeşitli bölgelere yayılmış bir kümedir. "Küme" kelimesi bize kompleksin otomatik olduğunu, yani arıza durumunda küme düğümlerinin otomatik olarak değiştirildiğini açıkça ima ediyor.
Metrocluster ile düzenli çoğaltma arasındaki temel fark burada yatmaktadır. Operasyonların otomasyonu. Yani, belirli olaylar durumunda (veri merkezi arızası, kanalların bozulması vb.), depolama sistemi, veri kullanılabilirliğini korumak için gerekli eylemleri bağımsız olarak gerçekleştirecektir. Normal kopyalar kullanıldığında, bu eylemler tamamen veya kısmen yönetici tarafından manuel olarak gerçekleştirilir.
Ne işe yarar?
Müşterilerin belirli metrocluster uygulamalarını kullanırken takip ettiği temel amaç, RTO'yu (Kurtarma Süresi Hedefi) en aza indirmektir. Yani, bir arıza sonrasında BT hizmetlerinin iyileşme süresini en aza indirmek. Düzenli çoğaltma kullanıyorsanız kurtarma süresi her zaman metroclusterdaki kurtarma süresinden daha uzun olacaktır. Neden? Çok basit. Yöneticinin masasında olması ve çoğaltmayı manuel olarak değiştirmesi gerekir; metrocluster bunu otomatik olarak yapar.
Uyumayan, yemek yemeyen, sigara içmeyen veya hastalanmayan ve günün 24 saati depolama sisteminin durumunu izleyen özel bir yöneticiniz yoksa, yöneticinin bunu yapacağını garanti etmenin hiçbir yolu yoktur. Arıza durumunda manuel anahtarlama için kullanılabilir.
Buna göre, bir metrocluster veya ölümsüz bir yöneticinin yokluğunda, 99. seviye yönetici görev hizmetinin RTO'su, tüm sistemlerin anahtarlama süresi ve yöneticinin çalışmaya başlamasının garanti edildiği maksimum sürenin toplamına eşit olacaktır. depolama sistemleri ve ilgili sistemler ile.
Böylece, RTO gereksiniminin saatler veya günler değil dakikalar olması durumunda metroclusterın kullanılması gerektiği sonucuna varıyoruz. Yani, en kötü veri merkezi arızası durumunda BT departmanının işletmeye zaman sağlaması gerekir. BT hizmetlerine erişimi dakikalar, hatta saniyeler içinde yeniden sağlamak için.
Nasıl çalışır?
Alt düzeyde metrocluster, önceki makalede açıkladığımız senkronize veri çoğaltma mekanizmasını kullanır (bkz. ). Çoğaltma eşzamanlı olduğundan, gereksinimler karşılık gelir veya daha doğrusu:
- fizik olarak fiber optik, 10 gigabit Ethernet (veya üstü);
- veri merkezleri arasındaki mesafe 40 kilometreden fazla değil;
- veri merkezleri arasındaki (depolama sistemleri arasındaki) optik kanal gecikmesi 5 milisaniyeye kadardır (optimal olarak 2).
Tüm bu gereksinimler doğası gereği tavsiye niteliğindedir, yani metroküme bu gereksinimler karşılanmasa bile çalışacaktır, ancak bu gereksinimlere uyulmamasının sonuçlarının her iki depolama sisteminin de işletimindeki bir yavaşlamaya eşit olduğunu anlamalıyız. Metrokümesi.
Peki, depolama sistemleri arasında veri aktarımı için senkronize bir kopya kullanılır ve kopyalar otomatik olarak nasıl geçiş yapar ve en önemlisi bölünmüş beyinden nasıl kaçınılır? Bunu yapmak için daha yüksek düzeyde ek bir varlık kullanılır - bir hakem.
Hakem nasıl çalışır ve görevi nedir?
Hakem, üçüncü bir sitede (örneğin bir ofiste) başlatılması gereken ve ICMP ve SSH aracılığıyla depolama sistemine erişim sağlaması gereken küçük bir sanal makine veya donanım kümesidir. Başlatma sonrasında, hakem IP'yi ayarlamalı ve ardından depolama tarafından adresini ve ayrıca metroküme katılan uzaktan kumandaların adreslerini belirtmelidir. Bundan sonra hakem çalışmaya hazırdır.
Hakem, metrokümedeki tüm depolama sistemlerini sürekli olarak izler ve belirli bir depolama sisteminin kullanılamaması durumunda, kümenin başka bir üyesinin ("canlı" depolama sistemlerinden biri) kullanılamadığını doğruladıktan sonra, çoğaltma kurallarını değiştirme prosedürünü başlatmaya karar verir. ve haritalama.
Çok önemli bir nokta. Hakem her zaman depolama sistemlerinin bulunduğu yerden farklı bir yerde bulunmalıdır; yani ne depolama sistemi 1'in kurulu olduğu veri merkezi 1'de ne de depolama sistemi 2'nin kurulu olduğu veri merkezi 2'de bulunmalıdır.
Neden? Çünkü bu, bir hakemin, hayatta kalan depolama sistemlerinden birinin yardımıyla, depolama sistemlerinin kurulu olduğu iki alandan herhangi birinin düşüşünü açık ve doğru bir şekilde belirleyebilmesinin tek yoludur. Hakem yerleştirmenin diğer yöntemleri beyin bölünmesiyle sonuçlanabilir.
Şimdi hakemin çalışmasının detaylarına dalalım.
Hakem, tüm depolama denetleyicilerini sürekli olarak yoklayan çeşitli hizmetleri çalıştırır. Anket sonucu öncekinden farklıysa (var/kullanılamaz), o zaman hakem üzerinde de çalışan küçük bir veri tabanına kaydedilir.
Hakemin çalışma mantığına daha detaylı bakalım.
Adım 1: Kullanılamazlığı belirleyin. Depolama sistemi arızası olayı, 5 saniye içinde aynı depolama sisteminin her iki denetleyicisinden de ping gelmemesidir.
Adım 2. Anahtarlama prosedürünü başlatın. Hakem, depolama sistemlerinden birinin kullanılamadığını fark ettikten sonra, “ölü” depolama sisteminin gerçekten öldüğünden emin olmak için “canlı” depolama sistemine bir istek gönderir.
Hakemden böyle bir komut aldıktan sonra, ikinci (canlı) depolama sistemi ek olarak düşen birinci depolama sisteminin kullanılabilirliğini kontrol eder ve eğer orada değilse hakeme tahmininin onayını gönderir. Depolama sistemi gerçekten kullanılamıyor.
Böyle bir onayı aldıktan sonra, hakem, düşen depolama sisteminde aktif (birincil) olan kopyalar üzerinde çoğaltmayı değiştirmek ve eşlemeyi yükseltmek için uzaktan bir prosedür başlatır ve bu kopyaları ikincilden birincil ve ikincil olarak değiştirmek için ikinci depolama sistemine bir komut gönderir. haritalamayı yükseltin. Peki, ikinci depolama sistemi buna göre bu prosedürleri gerçekleştirir ve ardından kayıp LUN'lara kendisinden erişim sağlar.
Neden ek doğrulamaya ihtiyaç var? Nisap için. Yani, toplam tek (3) sayıdaki küme üyesinin çoğunluğunun küme düğümlerinden birinin düşüşünü onaylaması gerekir. Ancak o zaman bu karar kesinlikle doğru olacaktır. Bu, hatalı geçişten ve buna bağlı olarak bölünmüş beyinden kaçınmak için gereklidir.
Zaman adımı 2 yaklaşık 5 - 10 saniye sürer; bu nedenle, kullanılamama durumunu belirlemek için gereken süre (5 saniye) dikkate alınarak, kazadan sonraki 10 - 15 saniye içinde, düşen depolama sistemindeki LUN'lar canlı sistemle çalışmaya otomatik olarak hazır olacaktır. depolama sistemi.
Ana bilgisayarlar ile bağlantıların kaybolmasını önlemek için, ana bilgisayarlardaki zaman aşımlarını doğru şekilde yapılandırmaya da dikkat etmeniz gerektiği açıktır. Önerilen zaman aşımı en az 30 saniyedir. Bu, bir felaket durumunda yük değiştirme sırasında ana bilgisayarın depolama sistemiyle bağlantısını kesmesini önleyecek ve G/Ç kesintisi olmamasını sağlayacaktır.
Durun bir saniye, eğer metroclusterda her şey bu kadar iyiyse neden düzenli kopyalamaya ihtiyacımız var?
Gerçekte her şey o kadar basit değil.
Metrocluster'ın artılarını ve eksilerini ele alalım
Böylece, metroclusterın geleneksel çoğaltmaya kıyasla bariz avantajlarının şunlar olduğunu fark ettik:
- Bir felaket durumunda minimum kurtarma süresini garantileyen tam otomasyon;
- Bu kadar :-).
Ve şimdi dikkat, eksileri:
- Çözüm maliyeti. Aerodisk sistemlerindeki metrocluster ek lisans gerektirmese de (kopyalamayla aynı lisans kullanılır), çözümün maliyeti yine de senkronize çoğaltmanın kullanılmasından daha yüksek olacaktır. Eşzamanlı bir kopyaya yönelik tüm gereksinimlerin yanı sıra ek anahtarlama ve ek siteyle ilişkili metroküme gereksinimlerini de uygulamanız gerekecektir (bkz. metroküme planlaması);
- Çözümün karmaşıklığı. Metrocluster normal bir kopyadan çok daha karmaşıktır ve planlama, yapılandırma ve belgeleme açısından çok daha fazla dikkat ve çaba gerektirir.
Sonunda. Gerçekten RTO'yu saniyeler veya dakikalar içinde sağlamanız gerektiğinde Metrocluster kesinlikle teknolojik olarak çok gelişmiş ve iyi bir çözümdür. Ancak böyle bir görev yoksa ve saatlerce RTO iş için uygunsa, o zaman serçeleri topla vurmanın bir anlamı yoktur. Bir metro kümesi ek maliyetlere ve BT altyapısının karmaşıklığına neden olacağından olağan işçi-köylü kopyalaması yeterlidir.
Metroküme planlaması
Bu bölüm metroküme tasarımına yönelik kapsamlı bir rehber olma iddiasında değildir, yalnızca böyle bir sistem kurmaya karar verirseniz üzerinde çalışılması gereken ana yönleri gösterir. Bu nedenle, bir metrocluster'ı fiilen uygularken, istişare için depolama sistemi üreticisini (yani bizi) ve diğer ilgili sistemleri dahil ettiğinizden emin olun.
oyun alanı
Yukarıda belirtildiği gibi, bir metrocluster en az üç saha gerektirir. Depolama sistemleri ve ilgili sistemlerin çalışacağı iki veri merkezinin yanı sıra hakemin çalışacağı üçüncü bir saha.
Veri merkezleri arasında önerilen mesafe 40 kilometreden fazla değildir. Daha büyük bir mesafenin ek gecikmelere neden olma olasılığı yüksektir ve metroküme durumunda bu son derece istenmeyen bir durumdur. Gecikmelerin 5 milisaniyeye kadar olması gerektiğini hatırlatalım, ancak 2 milisaniye içerisinde tutulması tavsiye edilir.
Planlama sürecinde gecikmelerin de kontrol edilmesi tavsiye edilir. Veri merkezleri arasında fiber optik sağlayan az çok olgun bir sağlayıcı, kalite kontrolünü oldukça hızlı bir şekilde organize edebilir.
Hakem önündeki gecikmelere gelince (yani üçüncü site ile ilk ikisi arasında), önerilen gecikme eşiği 200 milisaniyeye kadardır, yani İnternet üzerinden normal bir kurumsal VPN bağlantısı uygundur.
Anahtarlama ve Ağ İletişimi
Farklı sitelerdeki depolama sistemlerini bağlamanın yeterli olduğu çoğaltma şemasından farklı olarak metrocluster şeması, ana bilgisayarların farklı sitelerdeki her iki depolama sistemine bağlanmasını gerektirir. Farkın ne olduğunu daha açık hale getirmek için her iki şema da aşağıda gösterilmiştir.
Diyagramdan da görülebileceği gibi site 1 hostlarımız hem depolama sistemi 1'e hem de depolama sistemi 2'ye bakar. Ayrıca site 2 hostları ise tam tersine hem depolama sistemi 2'ye hem de depolama sistemi 1'e bakar. Yani her ana bilgisayar her iki depolama sistemini de görür. Bu metroclusterın çalışması için bir ön koşuldur.
Elbette her ana bilgisayarı bir optik kabloyla başka bir veri merkezine bağlamaya gerek yok; hiçbir bağlantı noktası veya kablo yeterli olmayacaktır. Tüm bu bağlantıların Ethernet 10G+ veya FibreChannel 8G+ anahtarları aracılığıyla yapılması gerekir (FC yalnızca IO için ana bilgisayarları ve depolama sistemlerini bağlamak içindir, çoğaltma kanalı şu anda yalnızca IP (Ethernet 10G+) aracılığıyla kullanılabilir.
Şimdi ağ topolojisi hakkında birkaç kelime. Önemli bir nokta, alt ağların doğru yapılandırılmasıdır. Aşağıdaki trafik türleri için hemen birkaç alt ağ tanımlamak gerekir:
- Verilerin depolama sistemleri arasında senkronize edileceği çoğaltma alt ağı. Bunlardan birkaçı olabilir, bu durumda önemli değil, hepsi mevcut (halihazırda uygulanmış) ağ topolojisine bağlıdır. Bunlardan iki tane varsa, o zaman açıkça yönlendirmenin bunlar arasında yapılandırılması gerekir;
- Ana bilgisayarların depolama kaynaklarına erişeceği depolama alt ağları (iSCSI ise). Her veri merkezinde böyle bir alt ağ bulunmalıdır;
- Kontrol alt ağları, yani depolama sistemlerinin yönetildiği üç sitedeki üç yönlendirilebilir alt ağ ve hakem de burada bulunur.
Görevlere büyük ölçüde bağımlı olduklarından, burada ana bilgisayar kaynaklarına erişim için alt ağları dikkate almıyoruz.
Farklı trafiği farklı alt ağlara ayırmak son derece önemlidir (kopyayı G/Ç'den ayırmak özellikle önemlidir), çünkü tüm trafiği tek bir "kalın" alt ağa karıştırırsanız, bu trafiği yönetmek imkansız olacaktır ve iki veri merkezinin koşulları nedeniyle bu durum yine de farklı ağ çarpışma seçeneklerine neden olabilir. Veri merkezleri arasında uzanan bir ağın planlanması konusunu ağ ekipmanı üreticilerinin kaynakları üzerinde detaylı bir şekilde anlatıldığı için bu yazı çerçevesinde bu konuya derinlemesine girmeyeceğiz.
Hakem yapılandırması
Hakem, ICMP ve SSH protokolleri aracılığıyla depolama sisteminin tüm yönetim arayüzlerine erişim sağlamalıdır. Ayrıca hakemin emniyetini de düşünmelisiniz. Burada bir nüans var.
Arbiter yük devretmesi son derece arzu edilen bir durumdur ancak gerekli değildir. Hakem yanlış zamanda kaza yaparsa ne olur?
- Metrocluster'ın normal modda çalışması değişmeyecek çünkü arbtir'in metrocluster'ın normal modda çalışması üzerinde kesinlikle hiçbir etkisi yoktur (görevi, veri merkezleri arasındaki yükü zamanında değiştirmektir)
- Üstelik, eğer hakem herhangi bir nedenle düşerse ve veri merkezinde bir kazayı "uyuyakalırsa", o zaman herhangi bir değişiklik olmayacaktır çünkü gerekli anahtarlama komutlarını verecek ve yetersayıyı organize edecek kimse olmayacaktır. Bu durumda metrocluster, RTO'yu etkileyecek bir felaket sırasında manuel olarak değiştirilmesi gereken çoğaltma ile düzenli bir şemaya dönüşecektir.
Bundan ne sonuç çıkıyor? Gerçekten minimum bir RTO sağlamanız gerekiyorsa, hakemin hataya dayanıklı olduğundan emin olmanız gerekir. Bunun için iki seçenek var:
- Hataya dayanıklı bir hipervizör üzerinde hakemli bir sanal makine başlatın; neyse ki tüm yetişkin hipervizörler hata toleransını destekler;
- Üçüncü tesiste (geleneksel bir ofiste) normal bir küme kuramayacak kadar tembelseniz ve mevcut bir hipervozor kümesi yoksa, o zaman hakemin, içinde iki sıradan olan 2U'luk bir kutuda yapılmış bir donanım sürümünü sağladık. x-86 sunucuları çalışır ve yerel bir arızadan kurtulabilir.
Metrocluster'ın normal modda buna ihtiyacı olmamasına rağmen, hakemin hata toleransının sağlanmasını şiddetle tavsiye ediyoruz. Ancak hem teorinin hem de uygulamanın gösterdiği gibi, gerçekten güvenilir, afetlere dayanıklı bir altyapı oluşturursanız, bunu güvenli bir şekilde yapmak daha iyidir. Kendinizi ve işinizi "anlamsızlık yasasından", yani hem hakemin hem de depolama sisteminin bulunduğu sitelerden birinin başarısızlığından korumak daha iyidir.
Çözüm mimarisi
Yukarıdaki gereksinimler göz önüne alındığında aşağıdaki genel çözüm mimarisini elde ederiz.
Ciddi aşırı yüklenmeyi önlemek için LUN'lar iki bölgeye eşit şekilde dağıtılmalıdır. Aynı zamanda, her iki veri merkezinde boyutlandırma yaparken, uygulamanın bozulmasını önlemek için yalnızca çift hacmi (verileri aynı anda iki depolama sisteminde depolamak için gereklidir) değil, aynı zamanda IOPS ve MB/s'de çift performansı da dahil etmelisiniz. veri merkezlerinden birinde arıza olması durumunda ov.
Ayrı olarak, boyutlandırmaya doğru yaklaşımla (yani, IOPS ve MB/s'nin yanı sıra gerekli CPU ve RAM kaynaklarının uygun üst sınırlarını sağlamamız koşuluyla), depolama sistemlerinden birinin depolama sistemlerinden biri olması durumunda bunu not ediyoruz. Metro kümesi başarısız olursa, tek bir depolama sistemi üzerinde geçici çalışma koşulları altında performansta ciddi bir düşüş olmayacaktır.
Bu, iki site aynı anda çalışırken, her işlemin iki depolama sistemine (RAID-1/10'a benzer) yazılması gerektiğinden eşzamanlı çoğaltmanın yazma performansının yarısını "yemesi" ile açıklanmaktadır. Dolayısıyla, depolama sistemlerinden biri arızalanırsa, kopyalamanın etkisi geçici olarak (arızalı depolama sistemi düzelene kadar) ortadan kalkar ve yazma performansında iki kat artış elde ederiz. Arızalı depolama sisteminin LUN'ları çalışan depolama sisteminde yeniden başlatıldığında, diğer depolama sisteminin LUN'larından yük gelmesi nedeniyle bu iki kat artış ortadan kalkıyor ve önceki performans seviyesine geri dönüyoruz. “düşmek”, ancak yalnızca tek bir site çerçevesinde.
Yetkili boyutlandırmanın yardımıyla, kullanıcıların tüm depolama sisteminin arızasını hiç hissetmeyecekleri koşulları sağlayabilirsiniz. Ancak bir kez daha tekrarlıyoruz, bu çok dikkatli bir boyutlandırma gerektirir, bu arada, bizimle ücretsiz olarak iletişime geçebilirsiniz :-).
Bir metrocluster kurma
Bir metrocluster oluşturmak, daha önce açıkladığımız düzenli çoğaltma kurulumuna çok benzer. . Bu nedenle sadece farklılıklara odaklanalım. Laboratuvarda yukarıdaki mimariyi temel alan, yalnızca minimal bir versiyonda bir tezgah kurduk: 10G Ethernet aracılığıyla bağlanan iki depolama sistemi, iki 10G anahtar ve 10G bağlantı noktalarına sahip her iki depolama sistemindeki anahtarlar üzerinden bakan bir ana bilgisayar. Hakem sanal bir makinede çalışır.
Bir kopya için sanal IP'leri (VIP'ler) yapılandırırken metrocluster için VIP türünü seçmelisiniz.
İki LUN için iki çoğaltma bağlantısı oluşturduk ve bunları iki depolama sistemine dağıttık: Depolama sistemi 1'de LUN TEST Birincil (METRO bağlantısı), depolama sistemi 2 için LUN TEST2 Birincil (METRO2 bağlantısı).
Onlar için iki özdeş hedef yapılandırdık (bizim durumumuzda iSCSI, ancak FC de destekleniyor, kurulum mantığı aynı).
Depolama sistemi1:
Depolama sistemi2:
Çoğaltma bağlantıları için her depolama sistemi üzerinde eşlemeler yapıldı.
Depolama sistemi1:
Depolama sistemi2:
Multipath kurulumu yapıp hosta sunduk.
Bir hakemin kurulması
Hakemin kendisi ile özel bir şey yapmanıza gerek yoktur; sadece onu üçüncü sitede etkinleştirmeniz, ona bir IP vermeniz ve ICMP ve SSH aracılığıyla ona erişimi yapılandırmanız yeterlidir. Kurulumun kendisi depolama sistemlerinin kendisinden gerçekleştirilir. Bu durumda hakemi metroclusterdaki depolama denetleyicilerinden herhangi birinde bir kez yapılandırmak yeterlidir; bu ayarlar tüm denetleyicilere otomatik olarak dağıtılacaktır.
Uzaktan çoğaltma>> Metrocluster (herhangi bir denetleyicide)>> bölümünde “Yapılandır” düğmesi.
Hakemin IP'sinin yanı sıra iki uzak depolama denetleyicisinin kontrol arayüzlerini giriyoruz.
Bundan sonra tüm hizmetleri etkinleştirmeniz gerekir (“Her Şeyi Yeniden Başlat” düğmesi). Gelecekte yeniden yapılandırılırsa ayarların etkili olması için hizmetlerin yeniden başlatılması gerekir.
Tüm hizmetlerin çalışıp çalışmadığını kontrol ediyoruz.
Bu, metrocluster kurulumunu tamamlar.
çarpışma testi
Çoğaltma işlevi (anahtarlama, tutarlılık vb.) daha önce tartışıldığı için bizim durumumuzdaki çarpışma testi oldukça basit ve hızlı olacaktır. . Bu nedenle, metroclusterın güvenilirliğini test etmek için arıza tespiti, anahtarlama otomasyonunu ve kayıt kayıplarının (G/Ç duraklamaları) olmadığını kontrol etmek bizim için yeterlidir.
Bunu yapmak için, ilk önce diğer depolama sisteminde etkinleştirilmesi gereken büyük bir dosyayı LUN'a kopyalamaya başlayarak, her iki denetleyiciyi de fiziksel olarak kapatarak depolama sistemlerinden birinin tamamen arızalanmasını taklit ederiz.
Bir depolama sistemini devre dışı bırakın. İkinci depolama sisteminde, günlüklerde komşu sistemle bağlantının kesildiğine dair uyarılar ve mesajlar görüyoruz. SMTP veya SNMP izleme yoluyla bildirimler yapılandırılmışsa yönetici ilgili bildirimleri alacaktır.
Tam olarak 10 saniye sonra (her iki ekran görüntüsünde de görülüyor), METRO çoğaltma bağlantısı (arızalı depolama sisteminde Birincil olan bağlantı), çalışan depolama sisteminde otomatik olarak Birincil hale geldi. Mevcut eşlemeyi kullanarak LUN TEST, ana bilgisayarın kullanımına açık kaldı, kayıt biraz düştü (söz verilen yüzde 10 dahilinde) ancak kesintiye uğramadı.
Test başarıyla tamamlandı.
Özetlemek
Metrocluster'ın AERODISK Engine N serisi depolama sistemlerindeki mevcut uygulaması, BT hizmetlerinin aksama süresini ortadan kaldırmanın veya en aza indirmenin gerekli olduğu durumlarda sorunların tamamen çözülmesine ve minimum işçilik maliyetleriyle 24/7/365 çalışmasının sağlanmasına olanak tanır.
Elbette tüm bunların teori, ideal laboratuvar koşulları vb. olduğunu söyleyebiliriz... ANCAK afete dayanıklılık işlevselliğini uyguladığımız ve sistemlerin mükemmel çalıştığı çok sayıda projemiz var. Felakete dayanıklı bir konfigürasyonda yalnızca iki depolama sistemi kullanan oldukça tanınmış müşterilerimizden biri, proje hakkında bilgi yayınlamayı zaten kabul etti, bu nedenle bir sonraki bölümde savaş uygulaması hakkında konuşacağız.
Teşekkür ederiz, verimli bir tartışma için sabırsızlanıyoruz.
Kaynak: habr.com