Salam, Habr oxucuları. Bu yazı ilə biz inkişaf etdirdiyimiz AERODISK vAIR hiperkonverged sistemi haqqında danışacaq bir sıra açırıq. Əvvəlcə ilk məqalədə hər şey haqqında hər şeyi danışmaq istədik, lakin sistem kifayət qədər mürəkkəbdir, ona görə də fili hissə-hissə yeyəcəyik.
Hekayəyə sistemin yaranma tarixi ilə başlayaq, vAIR-in əsasını təşkil edən ARDFS fayl sistemini araşdıraq, həmçinin bu həllin Rusiya bazarında yerləşdirilməsi haqqında bir az danışaq.
Gələcək məqalələrdə biz müxtəlif memarlıq komponentləri (klaster, hipervizor, yük balanslaşdırıcısı, monitorinq sistemi və s.), konfiqurasiya prosesi, lisenziyalaşdırma məsələlərini qaldıracaq, qəza testlərini ayrıca göstərəcək və əlbəttə ki, yük testi haqqında yazacağıq və ölçü. Biz həmçinin vAIR-in icma versiyasına ayrıca məqalə həsr edəcəyik.
Aerodisk saxlama sistemləri haqqında hekayədirmi? Yaxud biz niyə ilk növbədə hiperkonvergensiya etməyə başladıq?
Əvvəlcə öz hiperkonvergensiyamızı yaratmaq ideyası 2010-cu ildə haradasa gəldi. O dövrdə bazarda nə Aerodisk, nə də oxşar həllər (kommersiya qutusu hiperkonverge sistemləri) yox idi. Tapşırıqımız aşağıdakılardan ibarət idi: Ethernet protokolu vasitəsilə interconnect ilə birləşdirilən yerli diskləri olan serverlər toplusundan genişləndirilmiş yaddaş yaratmaq və orada virtual maşınlar və proqram şəbəkəsini işə salmaq lazım idi. Bütün bunlar saxlama sistemləri olmadan həyata keçirilməli idi (çünki saxlama sistemləri və onun aparatları üçün sadəcə olaraq pul yox idi və biz hələ öz saxlama sistemlərimizi icad etməmişdik).
Biz bir çox açıq mənbə həllərini sınadıq və nəhayət bu problemi həll etdik, lakin həll yolu çox mürəkkəb və təkrarlanması çətin idi. Bundan əlavə, bu həll “Bu işləyirmi? Toxunma! Buna görə də, bu problemi həll edərək, işimizin nəticəsini tam hüquqlu məhsula çevirmək fikrini daha da inkişaf etdirmədik.
Həmin hadisədən sonra biz bu fikirdən uzaqlaşdıq, lakin bizdə hələ də hiss olunurdu ki, bu problem tamamilə həll oluna bilər və belə bir həllin faydaları göz qabağında idi. Sonradan xarici şirkətlərin buraxılmış HCI məhsulları yalnız bu hissi təsdiqlədi.
Buna görə də, 2016-cı ilin ortalarında tam hüquqlu məhsul yaratmaq çərçivəsində bu vəzifəyə qayıtdıq. O vaxt bizim investorlarla hələ heç bir əlaqəmiz yox idi, ona görə də biz özümüz üçün çox da böyük olmayan pula inkişaf stendi almalı olduq. Avito-da istifadə edilmiş serverləri və açarları toplayıb işə başladıq.
Əsas ilkin vəzifə Ethernet vasitəsilə interconnect vasitəsilə birləşdirilən klaster qovşaqlarının n-ci nömrəsində virtual bloklar şəklində məlumatları avtomatik və bərabər şəkildə paylaya bilən, sadə olsa da, öz fayl sistemimizi yaratmaq idi. Eyni zamanda, FS yaxşı və asanlıqla miqyas almalı və bitişik sistemlərdən müstəqil olmalıdır, yəni. vAIR-dən “sadəcə saxlama yeri” şəklində özgəninkiləşdirilə bilər.
İlk vAIR konsepsiyası
Uzatılmış saxlama (ceph, parıltı, parıltı və s.) təşkil etmək üçün hazır açıq mənbə həllərinin istifadəsindən qəsdən öz inkişafımızın xeyrinə imtina etdik, çünki onlarla artıq çoxlu layihə təcrübəmiz var idi. Əlbəttə ki, bu həllərin özləri əladır və Aerodisk üzərində işləməzdən əvvəl biz onlarla birdən çox inteqrasiya layihəsi həyata keçirdik. Ancaq bir müştəri üçün konkret tapşırığı yerinə yetirmək, işçi heyətini öyrətmək və bəlkə də böyük bir satıcının dəstəyini almaq bir şeydir və müxtəlif tapşırıqlar üçün istifadə ediləcək asanlıqla təkrarlanan məhsul yaratmaq başqa bir şeydir. Satıcı, özümüz haqqında belə bilməyəcəyik. İkinci məqsəd üçün mövcud açıq mənbə məhsulları bizim üçün uyğun deyildi, ona görə də özümüz paylanmış fayl sistemi yaratmağa qərar verdik.
İki il sonra bir neçə tərtibatçı (vAIR üzərində işi klassik Mühərrik saxlama sistemindəki işi birləşdirən) müəyyən bir nəticə əldə etdi.
2018-ci ilə qədər biz sadə bir fayl sistemi yazdıq və onu lazımi avadanlıqla tamamladıq. Sistem daxili interconnect vasitəsilə müxtəlif serverlərdən fiziki (lokal) diskləri bir düz hovuzda birləşdirdi və onları virtual bloklara “kəsdi”, sonra virtual bloklardan müxtəlif nasazlıqlara dözümlü blok cihazları yaradıldı, onların üzərində virtual bloklar yaradıldı. və KVM hipervizor avtomobillərindən istifadə etməklə həyata keçirilir.
Biz fayl sisteminin adı ilə çox narahat olmadıq və qısaca onu ARDFS adlandırdıq (təxmin edin nə deməkdir))
Bu prototip yaxşı görünürdü (vizual olaraq yox, təbii ki, hələ vizual dizayn yox idi) və performans və miqyas baxımından yaxşı nəticələr göstərdi. İlk real nəticədən sonra biz tam hüquqlu inkişaf mühiti və yalnız vAIR ilə məşğul olan ayrıca komanda təşkil edərək bu layihəni hərəkətə keçirdik.
Məhz o vaxta qədər həllin ümumi arxitekturası yetkinləşdi, bu hələ böyük dəyişikliklərə məruz qalmadı.
ARDFS fayl sisteminə dalış
ARDFS bütün klaster üzrə paylanmış, xətaya dözümlü məlumatların saxlanmasını təmin edən vAIR-in əsasını təşkil edir. ARDFS-nin fərqli xüsusiyyətlərindən biri (lakin yeganə deyil) metadata və idarəetmə üçün heç bir əlavə xüsusi serverdən istifadə etməməsidir. Bu, əvvəlcə həllin konfiqurasiyasını sadələşdirmək və etibarlılığı üçün nəzərdə tutulmuşdur.
Saxlama quruluşu
Klasterin bütün qovşaqlarında ARDFS bütün mövcud disk sahəsindən məntiqi hovuz təşkil edir. Hovuzun hələ məlumat və ya formatlaşdırılmış məkan olmadığını, sadəcə işarələmə olduğunu başa düşmək vacibdir, yəni. Quraşdırılmış vAIR olan istənilən qovşaqlar klasterə əlavə olunduqda avtomatik olaraq paylaşılan ARDFS hovuzuna əlavə edilir və disk resursları avtomatik olaraq bütün klasterdə paylaşılır (və gələcək məlumatların saxlanması üçün əlçatan olur). Bu yanaşma artıq işləyən sistemə heç bir ciddi təsir etmədən qovşaqları tez əlavə etməyə və silməyə imkan verir. Bunlar. sistemi "kərpiclə" ölçmək çox asandır, lazım olduqda çoxluqdakı qovşaqları əlavə etmək və ya silmək.
ARDFS hovuzunun üstünə 4 meqabayt ölçülü virtual bloklardan qurulan virtual disklər (virtual maşınlar üçün saxlama obyektləri) əlavə olunur. Virtual disklər birbaşa məlumatları saxlayır. Arızaya dözümlülük sxemi də virtual disk səviyyəsində qurulur.
Artıq təxmin etdiyiniz kimi, disk alt sisteminin nasazlıqlara qarşı dözümlülüyü üçün biz RAID (müstəqil disklərin lazımsız massivi) anlayışından istifadə etmirik, lakin RAIN (müstəqil qovşaqların lazımsız massivi) istifadə edirik. Bunlar. Arızaya dözümlülük disklər deyil, qovşaqlar əsasında ölçülür, avtomatlaşdırılır və idarə olunur. Disklər, əlbəttə ki, həm də saxlama obyektidir, onlar, hər şey kimi, nəzarət olunur, yerli RAID aparatının yığılması da daxil olmaqla, onlarla bütün standart əməliyyatları yerinə yetirə bilərsiniz, lakin klaster xüsusi olaraq qovşaqlarda işləyir.
Həqiqətən RAID istədiyiniz bir vəziyyətdə (məsələn, kiçik klasterlərdə çoxsaylı uğursuzluqları dəstəkləyən bir ssenari), heç bir şey sizə yerli RAID kontrollerlərindən istifadə etməyə və uzadılmış yaddaş və RAIN arxitekturasını qurmağa mane olmur. Bu ssenari olduqca canlıdır və tərəfimizdən dəstəklənir, buna görə də bu barədə vAIR-dən istifadə üçün tipik ssenarilər haqqında məqalədə danışacağıq.
Saxlama xətalarına dözümlülük sxemləri
vAIR-də virtual disklər üçün iki nasazlığa dözümlülük sxemi ola bilər:
1) Replikasiya faktoru və ya sadəcə replikasiya - nasazlığa dözümlülüyün bu üsulu çubuq və ip kimi sadədir. Sinxron replikasiya 2 (hər klasterə 2 nüsxə) və ya 3 (müvafiq olaraq 3 nüsxə) faktoru olan qovşaqlar arasında həyata keçirilir. RF-2 virtual diskə çoxluqdakı bir qovşağın uğursuzluğuna tab gətirməyə imkan verir, lakin faydalı həcmin yarısını "yeyir", RF-3 isə çoxluqdakı 2 qovşağın uğursuzluğuna tab gətirəcək, lakin diskin 2/3 hissəsini saxlayır. ehtiyacları üçün faydalı həcm. Bu sxem RAID-1-ə çox bənzəyir, yəni RF-2-də konfiqurasiya edilmiş virtual disk klasterdəki hər hansı bir nodeun uğursuzluğuna davamlıdır. Bu halda, məlumatlarla hər şey yaxşı olacaq və hətta I/O dayanmayacaq. Düşmüş node xidmətə qayıtdıqda, məlumatların avtomatik bərpası/sinxronizasiyası başlayacaq.
Aşağıda RF-2 və RF-3 məlumatlarının normal rejimdə və uğursuz vəziyyətdə paylanması nümunələri verilmişdir.
Bizdə 8 vAIR qovşağında işləyən 4MB unikal (faydalı) məlumat tutumu olan virtual maşınımız var. Aydındır ki, reallıqda belə kiçik həcmin olacağı ehtimalı azdır, lakin ARDFS əməliyyatının məntiqini əks etdirən sxem üçün bu nümunə ən başa düşüləndir. AB unikal virtual maşın məlumatlarını ehtiva edən 4MB virtual bloklardır. RF-2 müvafiq olaraq A1+A2 və B1+B2 bloklarının iki nüsxəsini yaradır. Bu bloklar eyni qovşaqda eyni məlumatların kəsişməsindən qaçaraq qovşaqlar arasında "yerləşir", yəni A1 nüsxəsi A2 nüsxəsi ilə eyni qovşaqda yerləşməyəcəkdir. B1 və B2 ilə eynidir.
Düyünlərdən biri uğursuz olarsa (məsələn, B3 nüsxəsini ehtiva edən 1 nömrəli qovşaq), bu nüsxə onun surətinin (yəni B2-nin surəti) olmadığı qovşaqda avtomatik olaraq aktivləşdirilir.
Beləliklə, virtual disk (və müvafiq olaraq VM) RF-2 sxemindəki bir nodeun uğursuzluğundan asanlıqla xilas ola bilər.
Replikasiya sxemi sadə və etibarlı olsa da, RAID1 ilə eyni problemdən əziyyət çəkir - kifayət qədər istifadə sahəsi yoxdur.
2) Yuxarıdakı problemi həll etmək üçün silmə kodlaşdırması və ya silmə kodlaşdırması (həmçinin “ehtiyatsız kodlaşdırma”, “silmək kodlaşdırması” və ya “ehtiyatsızlıq kodu” kimi də tanınır) mövcuddur. EC replikasiya ilə müqayisədə daha az disk sahəsi ilə yüksək məlumat əlçatanlığını təmin edən ehtiyat sxemidir. Bu mexanizmin iş prinsipi RAID 5, 6, 6P-yə bənzəyir.
Kodlaşdırma zamanı AK prosesi virtual bloku (standart olaraq 4MB) AK sxemindən asılı olaraq bir neçə kiçik "məlumat parçasına" bölür (məsələn, 2+1 sxemi hər 4MB bloku 2 2MB hissəyə bölür). Sonra, bu proses əvvəllər bölünmüş hissələrdən birindən böyük olmayan “məlumat parçaları” üçün “paritet parçaları” yaradır. Şifrəni açarkən, EC bütün klaster üzrə “sağ qalan” məlumatları oxuyaraq çatışmayan hissələri yaradır.
Məsələn, 2 klaster qovşağında həyata keçirilən 1 + 4 EC sxeminə malik virtual disk, RF-2 ilə eyni şəkildə çoxluqdakı bir qovşağın uğursuzluğuna asanlıqla tab gətirəcəkdir. Bu halda qaimə məsrəfləri daha az olacaq, xüsusən də RF-2 üçün faydalı tutum əmsalı 2, EC 2+1 üçün isə 1,5 olacaq.
Bunu daha sadə təsvir etmək üçün mahiyyət ondan ibarətdir ki, virtual blok 2-8-ə bölünür (niyə 2-dən 8-ə qədər, aşağıya baxın) "parçalar" və bu parçalar üçün oxşar həcmdə paritetin "paritetləri" hesablanır.
Nəticədə, məlumat və paritet klasterin bütün qovşaqları arasında bərabər paylanır. Eyni zamanda, replikasiyada olduğu kimi, ARDFS avtomatik olaraq məlumatları qovşaqlar arasında elə paylayır ki, eyni məlumatların (məlumatların nüsxələri və onların pariteti) eyni qovşaqda saxlanmasının qarşısını alsın, beləliklə, məlumatların itirilməsi ehtimalını aradan qaldırır. məlumatların və onların paritetinin birdən uğursuz olan bir saxlama qovşağında bitəcəyinə.
Aşağıda eyni 8 MB virtual maşın və 4 qovşaq ilə, lakin EC 2+1 sxemi ilə bir nümunə verilmişdir.
A və B blokları hər biri 2 MB olan iki hissəyə bölünür (ikisi 2+1 olduğundan), yəni A1+A2 və B1+B2. Replikadan fərqli olaraq, A1 A2-nin surəti deyil, bu, B bloku ilə eyni olan iki hissəyə bölünmüş virtual A blokudur. Ümumilikdə, hər birində iki iki MB-lıq parça olan 4MB-lıq iki dəst alırıq. Sonra, bu dəstlərin hər biri üçün paritet bir hissədən çox olmayan həcmlə hesablanır (yəni 2 MB), biz əlavə + 2 paritet (AP və BP) əldə edirik. Ümumilikdə 4×2 data + 2×2 paritetimiz var.
Sonra, məlumatlar onların pariteti ilə kəsişməməsi üçün parçalar qovşaqlar arasında "yerləşir". Bunlar. A1 və A2 AP ilə eyni qovşaqda olmayacaq.
Bir qovşağın (məsələn, üçüncünün) uğursuzluğu halında, düşmüş B1 bloku 2 nömrəli qovşaqda saxlanılan BP paritetindən avtomatik olaraq bərpa ediləcək və olduğu qovşaqda aktivləşdiriləcəkdir. B-pariteti yoxdur, yəni. BP-nin bir hissəsi. Bu nümunədə bu 1 nömrəli qovşaqdır
Əminəm ki, oxucunun sualı var:
"Təsvir etdiyiniz hər şey çoxdan həm rəqiblər, həm də açıq mənbə həlləri tərəfindən həyata keçirilir, ARDFS-də EC tətbiqiniz arasında fərq nədir?"
Və sonra ARDFS-nin maraqlı xüsusiyyətləri olacaq.
Çevikliyə diqqət yetirərək kodlaşdırmanı silin
Əvvəlcə biz kifayət qədər çevik EC X+Y sxemini təqdim etdik, burada X 2-dən 8-ə qədər rəqəmə, Y isə 1-dən 8-ə qədər rəqəmə bərabərdir, lakin həmişə X-dən az və ya ona bərabərdir. Bu sxem təqdim olunur. elastiklik üçün. Virtual blokun bölündüyü məlumat hissələrinin (X) sayının artırılması əlavə məsrəflərin azaldılmasına, yəni istifadə olunan yerin artırılmasına imkan verir.
Paritet hissələrinin (Y) sayının artırılması virtual diskin etibarlılığını artırır. Y dəyəri nə qədər böyükdürsə, klasterdəki daha çox qovşaq uğursuz ola bilər. Əlbəttə ki, paritet həcminin artırılması istifadə edilə bilən gücün miqdarını azaldır, lakin bu, etibarlılıq üçün ödənilməli bir qiymətdir.
Performansın EC dövrələrindən asılılığı demək olar ki, birbaşadır: nə qədər çox "parça", performans aşağıdır; burada, əlbəttə ki, balanslaşdırılmış bir görünüş lazımdır.
Bu yanaşma administratorlara maksimum çevikliklə uzadılmış yaddaşı konfiqurasiya etməyə imkan verir. ARDFS hovuzu daxilində hər hansı nasazlığa dözümlülük sxemlərindən və onların birləşmələrindən istifadə edə bilərsiniz ki, bu da fikrimizcə çox faydalıdır.
Aşağıda bir neçə (hamısı mümkün deyil) RF və EC sxemlərini müqayisə edən bir cədvəl var.
Cədvəl göstərir ki, hətta eyni vaxtda klasterdə 8-ə qədər qovşağın itirilməsinə imkan verən ən “terri” EC 7+7 kombinasiyası standart replikasiyadan daha az istifadə sahəsi “yeyir” (1,875-yə qarşı 2) və 7 dəfə daha yaxşı qoruyur. , bu qoruma mexanizmini daha mürəkkəb olsa da, məhdud disk sahəsi şəraitində maksimum etibarlılığı təmin etmək lazım olan hallarda daha cəlbedici edir. Eyni zamanda, X və ya Y-yə hər bir "artı" əlavə performans yükü olacağını başa düşməlisiniz, buna görə etibarlılıq, qənaət və performans arasındakı üçbucaqda çox diqqətlə seçməlisiniz. Bu səbəbdən kodlaşdırma ölçüsünü silmək üçün ayrıca məqalə ayıracağıq.
Fayl sisteminin etibarlılığı və muxtariyyəti
ARDFS klasterin bütün qovşaqlarında lokal olaraq işləyir və xüsusi Ethernet interfeysləri vasitəsilə öz vasitələrindən istifadə edərək onları sinxronlaşdırır. Əhəmiyyətli məqam ondan ibarətdir ki, ARDFS müstəqil olaraq təkcə məlumatları deyil, həm də saxlama ilə bağlı metaməlumatları sinxronlaşdırır. ARDFS üzərində işləyərkən biz eyni vaxtda bir sıra mövcud həlləri tədqiq etdik və aşkar etdik ki, bir çoxları xarici paylanmış DBMS-dən istifadə edərək fayl sistemi metasını sinxronlaşdırır, biz ondan sinxronizasiya üçün də istifadə edirik, lakin FS metadatasını deyil, yalnız konfiqurasiyaları (bu və digər əlaqəli alt sistemlər haqqında) növbəti məqalədə).
Xarici DBMS-dən istifadə edərək FS metadatasının sinxronlaşdırılması, əlbəttə ki, işləyən bir həlldir, lakin sonra ARDFS-də saxlanılan məlumatların ardıcıllığı xarici DBMS-dən və onun davranışından (və açığını desək, bu, şıltaq bir xanımdır) asılı olacaq. fikrimiz pisdir. Niyə? FS metadatası zədələnərsə, FS məlumatının özü də “əlvida” demək olar, ona görə də biz daha mürəkkəb, lakin etibarlı bir yol tutmağa qərar verdik.
Biz ARDFS üçün metadata sinxronizasiya alt sistemini özümüz yaratdıq və o, bitişik alt sistemlərdən tamamilə asılı olmayaraq yaşayır. Bunlar. başqa heç bir alt sistem ARDFS məlumatlarını korlaya bilməz. Fikrimizcə, bu, ən etibarlı və düzgün yoldur, lakin bunun əslində belə olub-olmadığını zaman göstərəcək. Bundan əlavə, bu yanaşmanın əlavə bir üstünlüyü var. ARDFS vAIR-dən asılı olmayaraq, uzanmış saxlama kimi istifadə oluna bilər ki, biz mütləq gələcək məhsullarda istifadə edəcəyik.
Nəticədə, ARDFS-i inkişaf etdirməklə, biz tutuma qənaət edə və ya performansa görə hər şeydən imtina edə və ya münasib qiymətə, lakin performans tələblərini azaldan ultra etibarlı saxlama imkanı verən seçim imkanı verən çevik və etibarlı fayl sistemi əldə etdik.
Sadə lisenziyalaşdırma siyasəti və çevik çatdırılma modeli ilə birlikdə (irəliyə baxanda vAIR qovşaq tərəfindən lisenziyalaşdırılıb və ya proqram təminatı, ya da proqram paketi kimi çatdırılır) bu, sizə həlli müxtəlif müştəri tələblərinə uyğunlaşdırmağa imkan verir. sonra bu tarazlığı asanlıqla qoruyur.
Bu möcüzə kimə lazımdır?
Bir tərəfdən deyə bilərik ki, artıq bazarda hiperkonvergensiya sahəsində ciddi həlləri olan oyunçular var və biz əslində bura doğru gedirik. Deyəsən bu söz doğrudur, AMMA...
Digər tərəfdən, biz tarlalara çıxıb müştərilərlə ünsiyyətdə olanda biz və tərəfdaşlarımız görürük ki, heç də belə deyil. Hiperkonvergensiya üçün bir çox tapşırıq var, bəzi yerlərdə insanlar bu cür həllərin mövcud olduğunu bilmirdilər, digərlərində bu, bahalı görünürdü, digərlərində alternativ həllərin uğursuz sınaqları var idi, digərlərində isə sanksiyalara görə satın almağı ümumiyyətlə qadağan edirlər. Ümumiyyətlə, sahə şumlanmadı, ona görə də bakirə torpaq qaldırmağa getdik))).
Saxlama sistemi nə vaxt GCS-dən daha yaxşıdır?
Bazarla işləyərkən bizdən tez-tez soruşurlar ki, yaddaş sistemləri ilə klassik sxemdən nə vaxt istifadə etmək daha yaxşıdır və hiperkonvergentdən nə vaxt istifadə etmək lazımdır? GCS istehsal edən bir çox şirkətlər (xüsusilə portfelində saxlama sistemləri olmayanlar) deyirlər: "Saxlama sistemləri köhnəlir, yalnız hiper birləşir!" Bu cəsarətli bəyanatdır, lakin reallığı tam əks etdirmir.
Əslində, saxlama bazarı həqiqətən hiperkonvergensiyaya və oxşar həllərə doğru irəliləyir, lakin həmişə bir "amma" var.
Birincisi, saxlama sistemləri ilə klassik sxem üzrə qurulan məlumat mərkəzləri və İT infrastrukturlarını asanlıqla yenidən qurmaq mümkün olmadığından, belə infrastrukturların modernləşdirilməsi və tamamlanması hələ 5-7 ildir ki, miras olaraq qalır.
İkincisi, hazırda tikilən infrastrukturun böyük hissəsi (Rusiya Federasiyası nəzərdə tutulur) saxlama sistemlərindən istifadə etməklə klassik sxemə əsasən qurulur və insanların hiperkonvergensiya haqqında məlumatı olmadığı üçün deyil, hiperkonvergensiya bazarı yeni, həllər və standartlar hələ müəyyən edilməyib , İT adamları hələ təlim keçməyiblər, onların təcrübəsi azdır, lakin onlar burada və indi məlumat mərkəzləri qurmalıdırlar. Və bu tendensiya daha 3-5 il davam edəcək (və sonra başqa bir miras, 1-ci bəndə baxın).
Üçüncüsü, paylanmış saxlama xərcləri olan hər yazı üçün 2 millisaniyəlik əlavə kiçik gecikmələrdə (əlbəttə ki, yerli keş istisna olmaqla) sırf texniki məhdudiyyət var.
Yaxşı, disk alt sisteminin şaquli miqyasını sevən böyük fiziki serverlərin istifadəsini unutmayaq.
Saxlama sistemlərinin GCS-dən daha yaxşı davrandığı bir çox zəruri və populyar vəzifələr var. Burada, əlbəttə ki, məhsul portfelində saxlama sistemləri olmayan istehsalçılar bizimlə razılaşmayacaqlar, lakin biz əsaslı şəkildə mübahisə etməyə hazırıq. Əlbəttə ki, biz, hər iki məhsulun tərtibatçıları olaraq, gələcək nəşrlərimizdən birində mütləq saxlama sistemlərini və GCS-ni müqayisə edəcəyik, burada hansı şərtlərdə daha yaxşı olduğunu aydın şəkildə nümayiş etdirəcəyik.
Hiperkonverge həllər harada saxlama sistemlərindən daha yaxşı işləyəcək?
Yuxarıdakı məqamlara əsaslanaraq üç açıq nəticə çıxarmaq olar:
- Hər hansı bir məhsulda ardıcıl olaraq baş verən qeyd üçün əlavə 2 millisaniyəlik gecikmə (indi sintetikdən danışmırıq, nanosaniyələr sintetikada göstərilə bilər) qeyri-kritik olduqda, hiperkonvergent uyğun gəlir.
- Böyük fiziki serverlərdən gələn yük bir çox kiçik virtual serverlərə çevrilə və qovşaqlar arasında paylana bildiyi yerlərdə hiperkonvergensiya da yaxşı işləyəcək.
- Üfüqi miqyaslama şaquli miqyasdan daha yüksək prioritet olduqda, GCS orada da yaxşı olacaq.
Bu həllər hansılardır?
- Bütün standart infrastruktur xidmətləri (kataloq xidməti, poçt, EDMS, fayl serverləri, kiçik və ya orta səviyyəli ERP və BI sistemləri və s.). Biz buna “ümumi hesablama” deyirik.
- Müştərilər üçün çoxlu sayda virtual maşını tez və standartlaşdırmaq üçün üfüqi şəkildə genişləndirmək və asanlıqla "kəsmək" lazım olan bulud provayderlərinin infrastrukturu.
- Bir çox kiçik istifadəçi virtual maşınlarının işlədiyi və vahid klaster daxilində səssizcə “üzən” virtual masa üstü infrastrukturu (VDI).
- Filial şəbəkələri, burada hər bir filialın standart, nasazlığa dözümlü, lakin 15-20 virtual maşından ibarət ucuz infrastruktura ehtiyacı var.
- Hər hansı paylanmış hesablama (məsələn, böyük məlumat xidmətləri). Yükün "dərinlikdə" deyil, "enində" getdiyi yerə.
- Əlavə kiçik gecikmələrin məqbul olduğu sınaq mühitləri, lakin büdcə məhdudiyyətləri var, çünki bunlar testlərdir.
Hal-hazırda, biz AERODISK vAIR-i məhz bu vəzifələr üçün etdik və diqqətimizi onlara yönəldirik (indiyə qədər uğurla). Bəlkə də bu tezliklə dəyişəcək, çünki... dünya bir yerdə dayanmır.
Beləliklə ...
Bu, böyük bir məqalə seriyasının birinci hissəsini tamamlayır, növbəti məqalədə həllin arxitekturası və istifadə olunan komponentlər haqqında danışacağıq.
Sualları, təklifləri və konstruktiv mübahisələri alqışlayırıq.
Mənbə: www.habr.com