Merhaba Habr okuyucuları. Bu yazımızla geliştirdiğimiz hiper bütünleşik sistem AERODISK vAIR'den bahsedecek bir seri açıyoruz. Başlangıçta ilk yazıda her şeyi anlatmak istedik ama sistem oldukça karmaşık, bu yüzden fili parça parça yiyeceğiz.
Hikayeye sistemin yaratılış tarihiyle başlayalım, vAIR'in temeli olan ARDFS dosya sistemini inceleyelim ve ayrıca bu çözümün Rusya pazarındaki konumu hakkında da biraz konuşalım.
Gelecek makalelerde farklı mimari bileşenler (küme, hipervizör, yük dengeleyici, izleme sistemi vb.), konfigürasyon süreci, lisanslama sorunlarını gündeme getirmek, çarpışma testlerini ayrı ayrı göstermek ve elbette yük testi ve hakkında yazmak hakkında daha ayrıntılı olarak konuşacağız. boyutlandırma. Ayrıca vAIR'in topluluk sürümüne de ayrı bir makale ayıracağız.
Aerodisk depolama sistemleriyle ilgili bir hikaye mi? Veya neden ilk etapta hiper yakınsama yapmaya başladık?
Başlangıçta kendi hiper yakınsamamızı yaratma fikri 2010 yılı civarında aklımıza geldi. O dönemde piyasada ne Aerodisk ne de benzeri çözümler (ticari kutulu hiper bütünleşik sistemler) mevcuttu. Görevimiz şuydu: Ethernet protokolü aracılığıyla bir ara bağlantıyla birleştirilen yerel disklere sahip bir dizi sunucudan, genişletilmiş bir depolama alanı oluşturmak ve orada sanal makineleri ve bir yazılım ağını başlatmak gerekiyordu. Tüm bunların depolama sistemleri olmadan uygulanması gerekiyordu (çünkü depolama sistemleri ve donanımı için para yoktu ve henüz kendi depolama sistemlerimizi icat etmemiştik).
Birçok açık kaynak çözümü denedik ve sonunda bu sorunu çözdük ancak çözüm çok karmaşıktı ve tekrarlanması zordu. Üstelik bu çözüm “İşe yarıyor mu?” kategorisindeydi. Dokunma! Bu nedenle, bu sorunu çözdükten sonra çalışmalarımızın sonucunu tam teşekküllü bir ürüne dönüştürme fikrini daha fazla geliştirmedik.
O olaydan sonra bu fikirden uzaklaştık ama yine de bu sorunun tamamen çözülebilir olduğu ve böyle bir çözümün faydalarının fazlasıyla açık olduğu hissine kapıldık. Daha sonra yabancı şirketlerin piyasaya sürülen HCI ürünleri de bu duyguyu doğruladı.
Bu nedenle 2016 yılının ortalarında tam teşekküllü bir ürün yaratmanın bir parçası olarak bu göreve geri döndük. O zamanlar henüz yatırımcılarla herhangi bir ilişkimiz yoktu, bu yüzden çok büyük olmayan paramızla bir geliştirme standı satın almak zorunda kaldık. Avito'da kullanılmış sunucuları ve anahtarları topladıktan sonra işe koyulduk.
Başlangıçtaki asıl görev, basit de olsa kendi dosya sistemimizi oluşturmaktı; bu sistem, verileri Ethernet aracılığıyla bir ara bağlantıyla bağlanan n'inci sayıda küme düğümüne sanal bloklar biçiminde otomatik ve eşit bir şekilde dağıtabilir. Aynı zamanda FS'nin iyi ve kolay bir şekilde ölçeklendirilmesi ve komşu sistemlerden bağımsız olması gerekir; “sadece bir depolama tesisi” şeklinde vAIR'den yabancılaştırılabilir.
İlk vAIR konsepti
Uzatılmış depolamayı (ceph, gluster, luster ve benzeri) organize etmek için hazır açık kaynaklı çözümlerin kullanımını kendi gelişimimiz lehine kasıtlı olarak terk ettik, çünkü onlarla zaten çok fazla proje deneyimimiz vardı. Elbette bu çözümlerin kendisi mükemmel ve Aerodisk üzerinde çalışmaya başlamadan önce onlarla birden fazla entegrasyon projesi uyguladık. Ancak bir müşteri için belirli bir görevi uygulamak, personeli eğitmek ve belki de büyük bir satıcının desteğini satın almak başka bir şey, çeşitli görevler için kullanılacak, kolayca kopyalanabilen bir ürün yaratmak başka bir şey. Satıcı, kendimiz hakkında bile bilgi sahibi olamayacağız. İkinci amaç olarak mevcut açık kaynak ürünler bize uygun olmadığından kendimiz dağıtık bir dosya sistemi oluşturmaya karar verdik.
İki yıl sonra, birkaç geliştirici (vAIR üzerindeki çalışmaları klasik Engine depolama sistemindeki çalışmalarla birleştiren) belirli bir sonuca ulaştı.
2018 yılına gelindiğinde basit bir dosya sistemi yazdık ve onu gerekli donanımlarla destekledik. Sistem, farklı sunuculardan gelen fiziksel (yerel) diskleri dahili bir ara bağlantı aracılığıyla tek bir düz havuzda birleştirdi ve bunları sanal bloklar halinde "kesti", ardından üzerinde sanal blokların oluşturulduğu sanal bloklardan, farklı derecelerde hata toleransına sahip blok cihazları oluşturuldu. ve KVM hiper yönetici arabaları kullanılarak yürütülür.
Dosya sisteminin ismiyle çok fazla uğraşmadık ve kısaca ARDFS adını verdik (tahmin edin ne anlama geldiğini)
Bu prototip iyi görünüyordu (görsel olarak değil elbette, henüz görsel bir tasarım yoktu) ve performans ve ölçeklendirme açısından iyi sonuçlar verdi. İlk gerçek sonuçtan sonra, tam teşekküllü bir geliştirme ortamı ve yalnızca vAIR ile ilgilenen ayrı bir ekip düzenleyerek bu projeyi harekete geçirdik.
Tam o zamana kadar çözümün genel mimarisi olgunlaşmıştı ve henüz büyük değişikliklere uğramamıştı.
ARDFS dosya sistemine dalmak
ARDFS, tüm küme genelinde dağıtılmış, hataya dayanıklı veri depolama sağlayan vAIR'in temelidir. ARDFS'nin (ancak tek değil) ayırt edici özelliklerinden biri, meta veriler ve yönetim için herhangi bir ek özel sunucu kullanmamasıdır. Bu başlangıçta çözümün konfigürasyonunu basitleştirmek ve güvenilirliğini sağlamak için tasarlandı.
Depolama yapısı
Kümenin tüm düğümlerinde ARDFS, kullanılabilir tüm disk alanından mantıksal bir havuz düzenler. Havuzun henüz veri veya biçimlendirilmiş alan değil, yalnızca işaretleme olduğunu anlamak önemlidir. vAIR yüklü tüm düğümler, kümeye eklendiğinde otomatik olarak paylaşılan ARDFS havuzuna eklenir ve disk kaynakları otomatik olarak kümenin tamamında paylaşılır (ve gelecekteki veri depolama için kullanılabilir). Bu yaklaşım, halihazırda çalışmakta olan sistem üzerinde ciddi bir etki yaratmadan, anında düğüm eklemenize ve kaldırmanıza olanak tanır. Onlar. Gerekirse kümedeki düğümleri ekleyerek veya çıkararak sistemin "tuğlalarla" ölçeklendirilmesi çok kolaydır.
4 megabayt boyutunda sanal bloklardan oluşturulan ARDFS havuzunun üzerine sanal diskler (sanal makineler için depolama nesneleri) eklenir. Sanal diskler verileri doğrudan depolar. Hata toleransı şeması da sanal disk düzeyinde ayarlanır.
Tahmin edebileceğiniz gibi, disk alt sisteminin hata toleransı için RAID (Bağımsız Disklerin Yedek Dizisi) kavramını kullanmıyoruz, ancak RAIN (Bağımsız Düğümlerin Yedekli Dizisi) kullanıyoruz. Onlar. Hata toleransı disklere göre değil düğümlere göre ölçülür, otomatikleştirilir ve yönetilir. Diskler elbette bir depolama nesnesidir, diğer her şey gibi izlenirler, yerel bir donanım RAID'i oluşturmak da dahil olmak üzere tüm standart işlemleri onlarla gerçekleştirebilirsiniz, ancak küme özellikle düğümler üzerinde çalışır.
RAID'i gerçekten istediğiniz bir durumda (örneğin, küçük kümelerde birden fazla arızayı destekleyen bir senaryo), hiçbir şey sizi yerel RAID denetleyicilerini kullanmaktan ve bunun üzerine genişletilmiş depolama ve RAIN mimarisi oluşturmaktan alıkoyamaz. Bu senaryo oldukça canlıdır ve tarafımızdan desteklenmektedir, bu nedenle vAIR kullanımına ilişkin tipik senaryolar hakkındaki bir makalede bundan bahsedeceğiz.
Depolama Hata Tolerans Şemaları
vAIR'de sanal diskler için iki hata tolerans şeması olabilir:
1) Çoğaltma faktörü veya basitçe çoğaltma - bu hata toleransı yöntemi bir çubuk ve bir ip kadar basittir. Eşzamanlı çoğaltma, 2 (küme başına 2 kopya) veya 3 (sırasıyla 3 kopya) faktörüne sahip düğümler arasında gerçekleştirilir. RF-2, sanal diskin kümedeki bir düğümün arızasına dayanmasına izin verir, ancak yararlı hacmin yarısını "yer" ve RF-3, kümedeki 2 düğümün arızasına dayanabilir, ancak 2/3'ünü ayırır ihtiyaçları için faydalı hacim. Bu şema RAID-1'e çok benzer, yani RF-2'de yapılandırılmış bir sanal disk, kümedeki herhangi bir düğümün arızasına karşı dayanıklıdır. Bu durumda verilerle ilgili her şey yolunda olacak ve G/Ç bile durmayacaktır. Düşen düğüm hizmete döndüğünde otomatik veri kurtarma/senkronizasyon başlayacaktır.
Aşağıda RF-2 ve RF-3 verilerinin normal modda ve arıza durumunda dağılımına ilişkin örnekler verilmiştir.
8 vAIR düğümünde çalışan, 4 MB benzersiz (faydalı) veri kapasitesine sahip bir sanal makinemiz var. Gerçekte bu kadar küçük bir hacmin olma ihtimalinin düşük olduğu açıktır ancak ARDFS çalışma mantığını yansıtan bir şema için bu örnek en anlaşılır olanıdır. AB, benzersiz sanal makine verilerini içeren 4 MB'lık sanal bloklardır. RF-2 bu A1+A2 ve B1+B2 bloklarının sırasıyla iki kopyasını oluşturur. Bu bloklar, aynı verilerin aynı düğümde kesişmesinden kaçınarak düğümler arasında "yerleştirilmiştir"; yani A1 kopyası, A2 kopyasıyla aynı düğümde yer almayacaktır. B1 ve B2 ile aynı.
Düğümlerden biri arızalanırsa (örneğin, B3'in bir kopyasını içeren 1 numaralı düğüm), bu kopya, kopyasının (yani B2'nin bir kopyasının) bulunmadığı düğümde otomatik olarak etkinleştirilir.
Böylece, sanal disk (ve buna göre VM), RF-2 şemasındaki bir düğümün arızasından kolayca kurtulabilir.
Çoğaltma şeması basit ve güvenilir olmasına rağmen RAID1 ile aynı sorunu yaşıyor: yeterli kullanılabilir alan yok.
2) Silme kodlaması veya silme kodlaması ("yedek kodlama", "silme kodlaması" veya "artıklık kodu" olarak da bilinir) yukarıdaki sorunu çözmek için mevcuttur. EC, çoğaltmaya kıyasla daha düşük disk alanı yüküyle yüksek veri kullanılabilirliği sağlayan bir artıklık şemasıdır. Bu mekanizmanın çalışma prensibi RAID 5, 6, 6P'ye benzer.
Kodlama sırasında, EC işlemi sanal bir bloğu (varsayılan olarak 4 MB) EC şemasına bağlı olarak birkaç daha küçük "veri parçasına" böler (örneğin, 2+1 şeması her 4 MB'lık bloğu 2 adet 2 MB parçaya böler). Daha sonra bu süreç, daha önce bölünmüş parçalardan birinden daha büyük olmayan "veri parçaları" için "eşlik parçaları" üretir. Kod çözme sırasında EC, kümenin tamamındaki "hayatta kalan" verileri okuyarak eksik parçaları oluşturur.
Örneğin, 2 küme düğümünde uygulanan 1 + 4 EC şemasına sahip bir sanal disk, RF-2 ile aynı şekilde kümedeki bir düğümün arızasına kolayca dayanacaktır. Bu durumda genel giderler daha düşük olacaktır, özellikle RF-2 için faydalı kapasite katsayısı 2, EC 2+1 için ise 1,5 olacaktır.
Daha basit bir şekilde açıklamak gerekirse, esas olan, sanal bloğun 2-8 (neden 2'den 8'e kadar, aşağıya bakın) "parçalara" bölünmesi ve bu parçalar için benzer hacimdeki parite "parçalarının" hesaplanmasıdır.
Sonuç olarak veriler ve eşlik, kümenin tüm düğümlerine eşit şekilde dağıtılır. Aynı zamanda, çoğaltmada olduğu gibi, ARDFS, veri kaybı olasılığını ortadan kaldırmak amacıyla, aynı verilerin (veri kopyaları ve eşliklerinin) aynı düğümde depolanmasını önleyecek şekilde verileri düğümler arasında otomatik olarak dağıtır. Verilerin ve eşliklerinin birdenbire başarısız olan bir depolama düğümünde bulunacağı gerçeğine.
Aşağıda aynı 8 MB sanal makineye ve 4 düğüme sahip ancak EC 2+1 şemasına sahip bir örnek bulunmaktadır.
A ve B blokları her biri 2 MB'lık iki parçaya (2+1 olduğu için iki) yani A1+A2 ve B1+B2'ye bölünmüştür. Bir kopyanın aksine, A1, A2'nin bir kopyası değildir, B bloğuyla aynı şekilde iki parçaya bölünmüş sanal bir A bloğudur. Toplamda, her biri iki adet iki MB'lık parça içeren 4 MB'lık iki set elde ederiz. Daha sonra, bu setlerin her biri için, bir parçadan (yani 2 MB) fazla olmayan bir hacimle eşlik hesaplanır, ek + 2 parça parite (AP ve BP) elde edilir. Toplamda 4×2 veri + 2×2 pariteye sahibiz.
Daha sonra parçalar, verilerin eşlikleriyle kesişmemesi için düğümler arasında "yerleştirilir". Onlar. A1 ve A2, AP ile aynı düğümde olmayacaktır.
Bir düğümün (örneğin üçüncünün de) arızalanması durumunda, düşen B1 bloğu, 2 numaralı düğümde depolanan BP paritesinden otomatik olarak geri yüklenecek ve bulunduğu düğümde etkinleştirilecektir. B-paritesi yok, yani BP'nin bir parçası. Bu örnekte bu, 1 numaralı düğümdür.
Eminim okuyucunun bir sorusu vardır:
"Açıkladığınız her şey uzun süredir hem rakipler tarafından hem de açık kaynaklı çözümlerde uygulanıyor, sizin ARDFS'de EC uygulamanız arasındaki fark nedir?"
Ve sonra ARDFS'nin ilginç özellikleri olacak.
Esnekliğe odaklanarak kodlamayı silme
Başlangıçta, X'in 2'den 8'e kadar bir sayıya ve Y'nin 1'den 8'e kadar bir sayıya eşit olduğu ancak her zaman X'ten küçük veya X'e eşit olduğu oldukça esnek bir EC X+Y şeması sağladık. Bu şema sağlanmıştır. esneklik için. Sanal bloğun bölündüğü veri parçalarının (X) sayısının arttırılması, genel maliyetlerin azaltılmasına, yani kullanılabilir alanın arttırılmasına olanak sağlar.
Eşlik parçalarının (Y) sayısını artırmak, sanal diskin güvenilirliğini artırır. Y değeri ne kadar büyük olursa kümedeki düğümlerin sayısı da o kadar fazla olur. Eşlik hacminin arttırılması elbette kullanılabilir kapasite miktarını azaltır ancak bu, güvenilirlik için ödenmesi gereken bir bedeldir.
Performansın EC devrelerine bağımlılığı neredeyse doğrudandır: ne kadar çok "parça" olursa performans o kadar düşük olur; burada elbette dengeli bir bakış açısına ihtiyaç vardır.
Bu yaklaşım, yöneticilerin uzatılmış depolamayı maksimum esneklikle yapılandırmasına olanak tanır. ARDFS havuzunda herhangi bir hata tolerans şemasını ve bunların kombinasyonlarını kullanabilirsiniz; bizce bu da çok faydalıdır.
Aşağıda birkaç (tümü mümkün olmayan) RF ve EC şemalarını karşılaştıran bir tablo bulunmaktadır.
Tablo, aynı anda bir kümede 8 düğümün kaybına izin veren en "havlu" EC 7+7 kombinasyonunun bile, standart çoğaltmaya göre daha az kullanılabilir alan "tükettiğini" (1,875'e karşı 2) ve 7 kat daha iyi koruduğunu göstermektedir. Bu, bu koruma mekanizmasını daha karmaşık olmasına rağmen, sınırlı disk alanı koşullarında maksimum güvenilirliği sağlamanın gerekli olduğu durumlarda çok daha çekici hale getirir. Aynı zamanda, X veya Y'ye eklenen her "artı"nın ek bir performans yükü oluşturacağını anlamalısınız; dolayısıyla güvenilirlik, tasarruf ve performans arasındaki üçgende çok dikkatli seçim yapmanız gerekir. Bu nedenle silme kodlama boyutlandırmasına ayrı bir makale ayıracağız.
Dosya sisteminin güvenilirliği ve özerkliği
ARDFS, kümenin tüm düğümlerinde yerel olarak çalışır ve bunları, özel Ethernet arayüzleri aracılığıyla kendi araçlarını kullanarak senkronize eder. Önemli olan nokta, ARDFS'nin yalnızca verileri değil aynı zamanda depolama ile ilgili meta verileri de bağımsız olarak senkronize etmesidir. ARDFS üzerinde çalışırken, aynı anda bir dizi mevcut çözümü inceledik ve çoğunun dosya sistemi metasını, senkronizasyon için de kullandığımız harici dağıtılmış bir DBMS kullanarak senkronize ettiğini keşfettik, ancak FS meta verilerini değil yalnızca yapılandırmaları (bu ve diğer ilgili alt sistemler hakkında) bir sonraki makalede).
FS meta verilerini harici bir DBMS kullanarak senkronize etmek elbette çalışan bir çözümdür, ancak daha sonra ARDFS'de depolanan verilerin tutarlılığı harici DBMS'ye ve onun davranışına (ve açıkçası kaprisli bir bayandır) bağlı olacaktır. düşüncemiz kötü. Neden? FS meta verileri hasar görürse, FS verilerinin kendisine de "hoşçakal" diyebiliriz, bu nedenle daha karmaşık ama güvenilir bir yol izlemeye karar verdik.
ARDFS'nin meta veri senkronizasyon alt sistemini kendimiz yaptık ve komşu alt sistemlerden tamamen bağımsız olarak yaşıyor. Onlar. başka hiçbir alt sistem ARDFS verilerini bozamaz. Bizce en güvenilir ve doğru yol bu olsa da gerçekte böyle olup olmadığını zaman gösterecek. Ayrıca bu yaklaşımın ek bir avantajı da vardır. ARDFS, gelecekteki ürünlerimizde mutlaka kullanacağımız uzatılmış depolama gibi, vAIR'den bağımsız olarak da kullanılabilir.
Sonuç olarak, ARDFS'yi geliştirerek, kapasiteden tasarruf edebileceğiniz veya performanstan her şeyden vazgeçebileceğiniz veya makul bir maliyetle ultra güvenilir depolama yapabileceğiniz ancak performans gereksinimlerini azaltabileceğiniz bir seçenek sunan esnek ve güvenilir bir dosya sistemi elde ettik.
Basit bir lisanslama politikası ve esnek bir dağıtım modeliyle (ileriye bakıldığında, vAIR düğüm tarafından lisanslanır ve yazılım veya yazılım paketi olarak teslim edilir) birlikte, bu, çözümün çok çeşitli müşteri gereksinimlerine çok doğru bir şekilde uyarlanmasını mümkün kılar ve o zaman bu dengeyi kolayca koruyun.
Bu mucizeye kimin ihtiyacı var?
Bir yandan piyasada hiper yakınsama alanında ciddi çözümleri olan oyuncuların zaten bulunduğunu ve aslında bizim de bu noktaya doğru gittiğimizi söyleyebiliriz. Görünüşe göre bu ifade doğru, AMA...
Öte yandan tarlalara çıkıp müşterilerle iletişime geçtiğimizde biz ve ortaklarımız durumun hiç de öyle olmadığını görüyoruz. Hiper yakınsama için pek çok görev var; bazı yerlerde insanlar bu tür çözümlerin varlığından habersizdi, diğerlerinde pahalı görünüyordu, diğerlerinde alternatif çözümlere ilişkin başarısız testler vardı ve diğerlerinde ise yaptırımlar nedeniyle satın almayı tamamen yasakladılar. Genel olarak tarlanın sürülmediği ortaya çıktı, bu yüzden bakir toprağı yetiştirmeye gittik))).
Depolama sistemi ne zaman GCS'den daha iyidir?
Piyasada çalışırken, bize sıklıkla depolama sistemleriyle klasik şemayı kullanmanın ne zaman daha iyi olduğu ve ne zaman hiper yakınsak kullanmanın daha iyi olduğu sorulur. GCS üreten pek çok şirket (özellikle portföyünde depolama sistemleri olmayanlar) şunu söylüyor: “Depolama sistemleri demode oluyor, yalnızca hiper yakınsanmış hale geliyor!” Bu cesur bir ifadedir ancak gerçeği tam olarak yansıtmamaktadır.
Gerçekte, depolama pazarı gerçekten de hiper yakınsamaya ve benzer çözümlere doğru ilerliyor, ancak her zaman bir "ama" vardır.
Öncelikle depolama sistemleri ile klasik şemaya göre inşa edilen veri merkezleri ve bilişim altyapıları kolaylıkla yeniden inşa edilemediği için bu tür altyapıların modernizasyonu ve tamamlanması hala 5-7 yıllık bir miras.
İkincisi, şu anda inşa edilmekte olan altyapının (Rusya Federasyonu anlamına gelir) büyük bir kısmı, depolama sistemleri kullanılarak klasik şemaya göre inşa edilmektedir ve insanların hiper yakınsama hakkında bilgi sahibi olmadığı için değil, hiper yakınsama pazarının yeni olması, çözümler ve çözümler sunması nedeniyle inşa edilmektedir. standartlar henüz belirlenmedi, BT çalışanları henüz eğitilmedi, çok az deneyimleri var, ancak burada ve şimdi veri merkezleri kurmaları gerekiyor. Ve bu eğilim 3-5 yıl daha sürecek (ve ardından başka bir miras, bkz. 1. madde).
Üçüncüsü, dağıtılmış depolamanın maliyeti olan yazma başına 2 milisaniyelik ek küçük gecikmelerde (tabii ki yerel önbellek hariç) tamamen teknik bir sınırlama vardır.
Disk alt sisteminin dikey ölçeklendirilmesini seven büyük fiziksel sunucuların kullanımını unutmayalım.
Depolama sistemlerinin GCS'den daha iyi davrandığı birçok gerekli ve popüler görev vardır. Burada elbette ürün portföyünde depolama sistemi olmayan üreticiler bizimle aynı fikirde olmayacaklar ama biz makul bir şekilde tartışmaya hazırız. Elbette biz, her iki ürünün geliştiricileri olarak, depolama sistemlerini ve GCS'yi gelecekteki yayınlarımızdan birinde mutlaka karşılaştıracağız ve hangisinin hangi koşullar altında daha iyi olduğunu açıkça göstereceğiz.
Peki hiper bütünleşik çözümler nerede depolama sistemlerinden daha iyi çalışacak?
Yukarıdaki noktalara dayanarak üç açık sonuç çıkarılabilir:
- Herhangi bir üründe sürekli olarak meydana gelen kayıt için ilave 2 milisaniyelik gecikme süresinin kritik olmadığı durumlarda (şimdi sentetiklerden bahsetmiyoruz, nanosaniyeler sentetiklerde gösterilebilir) hiper yakınsak uygundur.
- Büyük fiziksel sunuculardan gelen yükün çok sayıda küçük sanal sunucuya dönüştürülebildiği ve düğümler arasında dağıtılabildiği durumlarda hiper yakınsama da burada iyi çalışacaktır.
- Yatay ölçeklendirmenin dikey ölçeklendirmeden daha yüksek öncelikli olduğu durumlarda, GCS burada da gayet iyi iş görecektir.
Bu çözümler nelerdir?
- Tüm standart altyapı hizmetleri (dizin hizmeti, posta, EDMS, dosya sunucuları, küçük veya orta ölçekli ERP ve BI sistemleri vb.). Biz buna “genel hesaplama” diyoruz.
- Müşteriler için çok sayıda sanal makineyi yatay olarak genişletmenin ve kolayca "kesmenin" hızlı ve standart hale getirilmesinin gerekli olduğu bulut sağlayıcılarının altyapısı.
- Birçok küçük kullanıcı sanal makinesinin tek tip bir küme içinde çalıştığı ve sessizce "yüzdüğü" sanal masaüstü altyapısı (VDI).
- Her şubenin 15-20 sanal makineden oluşan standart, hataya dayanıklı ancak ucuz bir altyapıya ihtiyaç duyduğu şube ağları.
- Herhangi bir dağıtılmış bilgi işlem (örneğin büyük veri hizmetleri). Yükün "derinlemesine" değil, "genişliğine" gittiği yer.
- Ek küçük gecikmelerin kabul edilebilir olduğu ancak bütçe kısıtlamalarının olduğu test ortamları çünkü bunlar testlerdir.
Şu anda AERODISK vAIR'i bu görevler için yaptık ve onlara odaklanıyoruz (şu ana kadar başarılı bir şekilde). Belki bu durum yakında değişecek çünkü... dünya yerinde durmuyor.
Yani ...
Bu, geniş bir makale serisinin ilk bölümünü tamamlıyor; bir sonraki makalede çözümün mimarisinden ve kullanılan bileşenlerden bahsedeceğiz.
Soruları, önerileri ve yapıcı anlaşmazlıkları memnuniyetle karşılıyoruz.
Kaynak: habr.com