Tai gana paplitęs mitas serverių techninės įrangos srityje. Praktiškai hiperkonverguoti sprendimai (kai viskas viename) reikalingi daugeliui dalykų. Istoriškai pirmąsias architektūras savo paslaugoms sukūrė „Amazon“ ir „Google“. Tada kilo mintis sukurti skaičiavimo ūkį iš identiškų mazgų, kurių kiekvienas turėtų savo diskus. Visa tai sujungė kažkokia sistemą formuojanti programinė įranga (hipervizorius) ir buvo padalinta į virtualias mašinas. Pagrindinis tikslas – minimalios pastangos aptarnauti vieną mazgą ir kuo mažiau problemų keičiant mastelį: tiesiog nusipirkite dar tūkstantį ar du tokius pačius serverius ir prijunkite juos netoliese. Praktiškai tai pavieniai atvejai ir daug dažniau kalbama apie mažesnį mazgų skaičių ir kiek kitokią architektūrą.
Tačiau pliusas išlieka tas pats – neįtikėtinas mastelio keitimo ir valdymo paprastumas. Minusas tas, kad skirtingos užduotys nevienodai sunaudoja resursus, o kai kur bus daug vietinių diskų, kitur – mažai RAM ir pan., tai yra skirtingų tipų užduotims resursų panaudojimas sumažės.
Pasirodo, kad jūs mokate 10–15% daugiau, kad būtų lengviau nustatyti. Būtent tai sukėlė mitą pavadinime. Ilgai ieškojome, kur būtų optimaliai pritaikyta technologija, ir radome. Faktas yra tas, kad „Cisco“ neturėjo savo saugojimo sistemų, tačiau norėjo visiškos serverių rinkos. Ir jie sukūrė „Cisco Hyperflex“ – sprendimą su vietine saugykla mazguose.
Ir tai staiga pasirodė esąs labai geras sprendimas atsarginiams duomenų centrams (Disaster Recovery). Dabar pasakysiu kodėl ir kaip. Ir aš jums parodysiu klasterių testus.
Kur reikia
Hiperkonvergencija yra:
- Diskų perkėlimas į skaičiavimo mazgus.
- Pilnas saugojimo posistemio integravimas su virtualizacijos posistemiu.
- Perdavimas/integravimas su tinklo posistemiu.
Šis derinys leidžia įdiegti daugybę saugojimo sistemos funkcijų virtualizacijos lygiu ir visa tai iš vieno valdymo lango.
Mūsų įmonėje perteklinių duomenų centrų projektavimo projektai yra labai paklausūs, o hiperkonverguotas sprendimas dažnai pasirenkamas dėl daugybės replikacijos parinkčių (iki metroklasterio).
Atsarginių duomenų centrų atveju paprastai kalbame apie nuotolinį objektą kitoje miesto pusėje arba visai kitame mieste. Tai leidžia atkurti svarbias sistemas iš dalies arba visiškai sugedus pagrindiniam duomenų centrui. Ten nuolat kartojami pardavimo duomenys, o replikacija gali būti taikomosios programos arba blokinio įrenginio (saugyklos) lygiu.
Todėl dabar kalbėsiu apie sistemos dizainą ir testus, o tada apie porą realių programų scenarijų su taupymo duomenimis.
Testai
Mūsų egzempliorius susideda iš keturių serverių, kurių kiekvienas turi 10 SSD diskų po 960 GB. Yra skirtas diskas įrašymo operacijoms talpykloje saugoti ir paslaugos virtualiajai mašinai saugoti. Pats sprendimas yra ketvirtoji versija. Pirmasis yra atvirai neapdorotas (sprendžiant iš apžvalgų), antrasis yra drėgnas, trečiasis jau gana stabilus, o šį galima pavadinti išleidimu pasibaigus beta versijos testavimui plačiajai visuomenei. Testavimo metu nemačiau jokių problemų, viskas veikia kaip laikrodis.
4 versijos pakeitimaiIštaisyta daugybė klaidų.
Iš pradžių platforma galėjo veikti tik su VMware ESXi hipervizoriumi ir palaikė nedidelį skaičių mazgų. Be to, diegimo procesas ne visada baigdavosi sėkmingai, kai kuriuos veiksmus reikėjo pradėti iš naujo, kilo problemų atnaujinant iš senesnių versijų, duomenys GUI ne visada buvo rodomi teisingai (nors vis dar nesu patenkintas našumo grafikų rodymu ), kartais iškildavo problemų sąsajoje su virtualizacija .
Dabar visos vaikystės problemos išspręstos, „HyperFlex“ gali valdyti ir ESXi, ir Hyper-V, be to, galima:
- Ištempto klasterio kūrimas.
- Biurų klasterio kūrimas nenaudojant Fabric Interconnect, nuo dviejų iki keturių mazgų (perkame tik serverius).
- Gebėjimas dirbti su išorinėmis saugojimo sistemomis.
- Konteinerių ir Kubernetes palaikymas.
- Pasiekiamumo zonų kūrimas.
- Integracija su VMware SRM, jei įmontuotas funkcionalumas nėra patenkinamas.
Architektūra nedaug skiriasi nuo pagrindinių konkurentų sprendimų, jie nesukūrė dviračio. Visa tai veikia VMware arba Hyper-V virtualizacijos platformoje. Techninė įranga yra priglobta patentuotuose Cisco UCS serveriuose. Yra tokių, kurie nekenčia platformos dėl santykinio pradinės sąrankos sudėtingumo, daugybės mygtukų, nebanalios šablonų ir priklausomybių sistemos, tačiau yra ir tokių, kurie išmoko zen, yra įkvėpti idėjos ir nebenori. dirbti su kitais serveriais.
Apsvarstysime VMware sprendimą, nes sprendimas iš pradžių buvo sukurtas jai ir turi daugiau funkcionalumo; kartu buvo pridėtas Hyper-V, siekiant neatsilikti nuo konkurentų ir patenkinti rinkos lūkesčius.
Yra serverių grupė, pilna diskų. Yra diskai duomenims saugoti (SSD arba HDD – pagal jūsų skonį ir poreikius), yra vienas SSD diskas talpyklai. Įrašant duomenis į duomenų saugyklą, duomenys išsaugomi talpyklos sluoksnyje (skirtas SSD diskas ir paslaugos VM RAM). Lygiagrečiai į klasterio mazgus siunčiamas duomenų blokas (mazgų skaičius priklauso nuo klasterio replikacijos koeficiento). Iš visų mazgų patvirtinus apie sėkmingą įrašymą, įrašymo patvirtinimas siunčiamas į hipervizorių, o tada į VM. Įrašyti duomenys panaikinami, suglaudinami ir įrašomi į saugojimo diskus fone. Tuo pačiu metu didelis blokas visada įrašomas į saugojimo diskus ir nuosekliai, o tai sumažina saugojimo diskų apkrovą.
Dubliavimo panaikinimas ir glaudinimas visada įjungti ir jų negalima išjungti. Duomenys nuskaitomi tiesiai iš saugojimo diskų arba iš RAM talpyklos. Jei naudojama hibridinė konfigūracija, skaitymai taip pat saugomi SSD talpykloje.
Duomenys nėra susieti su dabartine virtualiosios mašinos vieta ir yra tolygiai paskirstomi tarp mazgų. Šis metodas leidžia vienodai įkelti visus diskus ir tinklo sąsajas. Yra akivaizdus trūkumas: negalime kiek įmanoma sumažinti skaitymo delsos, nes nėra garantijos, kad duomenys bus pasiekiami vietoje. Bet manau, kad tai menka auka, palyginti su gaunama nauda. Be to, tinklo vėlavimai pasiekė tokias reikšmes, kad jie praktiškai neturi įtakos bendram rezultatui.
Už visą disko posistemio veikimo logiką atsakingas specialios paslaugos VM Cisco HyperFlex Data Platform valdiklis, kuris sukuriamas kiekviename saugojimo mazge. Mūsų tarnybinėje VM konfigūracijoje buvo skirti aštuoni vCPU ir 72 GB RAM, o tai nėra taip jau mažai. Priminsiu, kad pats pagrindinis kompiuteris turi 28 fizinius branduolius ir 512 GB RAM.
Paslaugos VM turi prieigą prie fizinių diskų tiesiogiai persiųsdama SAS valdiklį į VM. Ryšys su hipervizoriumi vyksta per specialų modulį IOVisor, kuris perima I/O operacijas, ir naudojant agentą, leidžiantį siųsti komandas į hipervizoriaus API. Agentas yra atsakingas už darbą su HyperFlex momentinėmis nuotraukomis ir klonais.
Disko ištekliai hipervizoriuje montuojami kaip NFS arba SMB akcijos (priklausomai nuo hipervizoriaus tipo, atspėkite, kuris iš jų yra kur). O po gaubtu tai yra paskirstyta failų sistema, leidžianti pridėti suaugusiems skirtų visaverčių saugojimo sistemų funkcijų: plonas apimties paskirstymas, glaudinimas ir dubliavimo panaikinimas, momentinės nuotraukos naudojant Redirect-on-Write technologiją, sinchroninis / asinchroninis replikavimas.
Paslauga VM suteikia prieigą prie HyperFlex posistemio WEB valdymo sąsajos. Yra integracija su vCenter, iš jo galima atlikti daugumą kasdienių užduočių, tačiau, pavyzdžiui, duomenų saugyklas patogiau iškirpti iš atskiros internetinės kameros, jei jau perėjote prie greitos HTML5 sąsajos arba naudojate visavertį „Flash“ klientą. su pilna integracija. Paslaugos internetinėje kameroje galite peržiūrėti sistemos veikimą ir išsamią būseną.
Klasteryje yra ir kito tipo mazgai – skaičiavimo mazgai. Tai gali būti stovo arba blade serveriai be įmontuotų diskų. Šie serveriai gali paleisti VM, kurių duomenys saugomi serveriuose su diskais. Duomenų prieigos požiūriu nėra skirtumo tarp mazgų tipų, nes architektūra apima abstrakciją nuo fizinės duomenų vietos. Maksimalus skaičiavimo mazgų ir saugojimo mazgų santykis yra 2:1.
Skaičiavimo mazgų naudojimas padidina lankstumą keičiant klasterio išteklius: mums nereikia pirkti papildomų mazgų su diskais, jei mums reikia tik procesoriaus / RAM. Be to, galime pridėti blade narvelį ir sutaupyti serverių stove.
Dėl to turime hiperkonverguotą platformą su šiomis funkcijomis:
- Iki 64 mazgų grupėje (iki 32 saugojimo mazgų).
- Mažiausias mazgų skaičius klasteryje yra trys (du „Edge“ klasteriui).
- Duomenų pertekliaus mechanizmas: atspindėjimas su 2 ir 3 replikacijos koeficientais.
- Metro klasteris.
- Asinchroninis VM replikavimas į kitą HyperFlex klasterį.
- VM perjungimo į nuotolinį duomenų centrą organizavimas.
- Natūralios momentinės nuotraukos naudojant Redirect-on-Write technologiją.
- Iki 1 PB naudingos vietos esant 3 replikacijos koeficientui ir be dubliavimo panaikinimo. Mes neatsižvelgiame į replikacijos koeficientą 2, nes tai nėra pasirinkimas rimtam pardavimui.
Kitas didžiulis pliusas yra valdymo ir diegimo paprastumas. Visais sudėtingais UCS serverių nustatymo klausimais pasirūpina specializuota VM, kurią parengė Cisco inžinieriai.
Bandymo stendo konfigūracija:
- 2 x Cisco UCS Fabric Interconnect 6248UP kaip valdymo klasteris ir tinklo komponentai (48 prievadai veikia Ethernet 10G/FC 16G režimu).
- Keturi Cisco UCS HXAF240 M4 serveriai.
Serverio charakteristikos:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM / PC4-19200 / dvigubo rango / x 4 / 1.2 V
tinklas
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet prievadai
HBA saugykla
„Cisco 12G Modular SAS“ praėjimas per valdiklį
Saugojimo diskai
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Daugiau konfigūravimo parinkčiųBe pasirinktos aparatinės įrangos, šiuo metu galimos šios parinktys:
- HXAF240c M5.
- Vienas ar du procesoriai nuo Intel Silver 4110 iki Intel Platinum I8260Y. Galima antros kartos.
- 24 atminties lizdai, juostos nuo 16 GB RDIMM 2600 iki 128 GB LRDIMM 2933.
- Nuo 6 iki 23 duomenų diskų, vienas talpyklos diskas, vienas sistemos diskas ir vienas įkrovos diskas.
Talpos diskai
- HX-SD960G61X-EV 960GB 2.5 colio Enterprise Value 6G SATA SSD (1X patvarumas) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 colio Enterprise Value 6G SATA SSD (1X patvarumo) SAS 3.8 TB.
- Diskų kaupimas talpykloje
- HX-NVMEXPB-I375 375 GB 2.5 colio „Intel Optane“ diskas, ypatingas tobulumas ir ištvermė.
- HX-NVMEHW-H1600* 1.6 TB 2.5 colio Ent. Perf. NVMe SSD (3X patvarumas) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 colio Ent. Perf. 12G SAS SSD (10X patvarumo) SAS 400 GB.
- HX-SD800GBENK9** 800 GB 2.5 colio Ent. Perf. 12G SAS SED SSD (10X patvarumas) SAS 800 GB.
- HX-SD16T123X-EP 1.6 TB 2.5 colio įmonės našumo 12G SAS SSD (3X patvarumas).
Sistemos / žurnalo diskai
- HX-SD240GM1X-EV 240 GB 2.5 colio Enterprise Value 6G SATA SSD (reikalingas atnaujinimas).
Įkrovos diskai
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB.
Prisijunkite prie tinklo per 40G, 25G arba 10G Ethernet prievadus.
FI gali būti HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Pats testas
Norėdami išbandyti disko posistemį, naudojau HCIBench 2.2.1. Tai nemokama programa, leidžianti automatizuoti apkrovos kūrimą iš kelių virtualių mašinų. Pati apkrovą generuoja įprastas fio.
Mūsų klasteris susideda iš keturių mazgų, replikacijos koeficientas 3, visi diskai yra Flash.
Bandymui sukūriau keturias duomenų saugyklas ir aštuonias virtualias mašinas. Atliekant rašymo testus, daroma prielaida, kad talpyklos diskas nėra pilnas.
Bandymo rezultatai yra tokie:
100% skaityta 100% atsitiktinai
0% Skaityti 100% Atsitiktinai
Bloko / eilės gylis
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36 ms 374348 IOPS
2.47 ms 414116 IOPS
4,86 ms 420180 IOPS
2,22 ms 57408 IOPS
3,09 ms 82744 IOPS
5,02 ms 101824 IPOS
8,75 ms 116912 IOPS
17,2 ms 118592 IOPS
8K
0,67 ms 188416 IOPS
0,93 ms 273280 IOPS
1,7 ms 299932 IOPS
2,72 ms 376,484 IOPS
5,47 ms 373,176 IOPS
3,1 ms 41148 IOPS
4,7 ms 54396 IOPS
7,09 ms 72192 IOPS
12,77 ms 80132 IOPS
16K
0,77 ms 164116 IOPS
1,12 ms 228328 IOPS
1,9 ms 268140 IOPS
3,96 ms 258480 IOPS
3,8 ms 33640 IOPS
6,97 ms 36696 IOPS
11,35 ms 45060 IOPS
32K
1,07 ms 119292 IOPS
1,79 ms 142888 IOPS
3,56 ms 143760 IOPS
7,17 ms 17810 IOPS
11,96 ms 21396 IOPS
64K
1,84 ms 69440 IOPS
3,6 ms 71008 IOPS
7,26 ms 70404 IOPS
11,37 ms 11248 IOPS
Pusjuodis žymi vertes, po kurių produktyvumas nepadidėja, kartais net matomas degradavimas. Taip yra dėl to, kad mus riboja tinklo / valdiklių / diskų veikimas.
- Nuoseklus skaitymas 4432 MB/s.
- Nuoseklus rašymas 804 MB/s.
- Jei vienas valdiklis sugenda (virtualios mašinos ar pagrindinio kompiuterio gedimas), našumas sumažėja dvigubai.
- Jei saugojimo diskas sugenda, išimama 1/3. Disko atkūrimas užima 5% kiekvieno valdiklio išteklių.
Mažame bloke mus riboja valdiklio (virtualios mašinos) našumas, jo CPU apkraunamas 100%, o kai blokas padidėja, mus riboja prievado pralaidumas. 10 Gbps nepakanka, kad išlaisvintumėte „AllFlash“ sistemos potencialą. Deja, pateikto demonstracinio stendo parametrai neleidžia išbandyti veikimo 40 Gbit/s greičiu.
Mano įspūdis iš testų ir tyrinėjant architektūrą, dėl algoritmo, kuris talpina duomenis tarp visų kompiuterių, gauname keičiamo dydžio, nuspėjamą našumą, tačiau tai taip pat yra apribojimas skaitant, nes būtų galima išspausti daugiau iš vietinių diskų, čia gali sutaupyti našesnis tinklas, pavyzdžiui, galimas FI 40 Gbit/s greičiu.
Be to, vienas diskas talpyklai saugoti ir dubliavimui pašalinti gali būti apribojimas; iš tikrųjų šioje bandymo vietoje galime rašyti į keturis SSD diskus. Būtų puiku, jei pavyktų padidinti talpyklos diskų skaičių ir pamatyti skirtumą.
Realus naudojimas
Norėdami organizuoti atsarginį duomenų centrą, galite naudoti du būdus (nesvarstome, kad atsarginės kopijos dėti nuotolinėje svetainėje):
- Aktyvus-pasyvus. Visos programos talpinamos pagrindiniame duomenų centre. Replikacija yra sinchroninė arba asinchroninė. Jei pagrindinis duomenų centras sugenda, turime suaktyvinti atsarginį duomenų centrą. Tai galima padaryti rankiniu būdu / scenarijus / orkestravimo programas. Čia gausime replikacijos dažnį atitinkantį RPO, o RTO priklauso nuo administratoriaus reakcijos ir įgūdžių bei perjungimo plano kūrimo/derinimo kokybės.
- Aktyvus-Aktyvus. Šiuo atveju yra tik sinchroninis replikavimas; duomenų centrų prieinamumą nustato kvorumas / arbitras, esantis griežtai trečioje svetainėje. RPO = 0, o RTO gali pasiekti 0 (jei programa leidžia) arba lygus virtualizacijos klasterio mazgo pertrūkio laikui. Virtualizavimo lygiu sukuriamas ištemptas (Metro) klasteris, kuriam reikalinga aktyvi-aktyvi saugykla.
Paprastai matome, kad klientai pagrindiniame duomenų centre jau yra įdiegę architektūrą su klasikine saugojimo sistema, todėl sukuriame kitą replikacijai. Kaip jau minėjau, „Cisco HyperFlex“ siūlo asinchroninį replikavimą ir išplėstą virtualizacijos klasterio kūrimą. Tuo pačiu metu mums nereikia specialios vidutinio ir aukštesnio lygio saugojimo sistemos su brangiomis replikavimo funkcijomis ir aktyvia-aktyvia duomenų prieiga dviejose saugojimo sistemose.
1 scenarijus: Turime pirminį ir atsarginį duomenų centrus, virtualizacijos platformą VMware vSphere. Visos produktyvios sistemos yra pagrindiniame duomenų centre, o virtualių mašinų replikacija vykdoma hipervizoriaus lygmeniu, todėl VM nebus įjungtos atsarginiame duomenų centre. Mes dauginame duomenų bazes ir specialias programas naudodami integruotus įrankius ir palaikome įjungtas VM. Jei sugenda pagrindinis duomenų centras, sistemas paleidžiame atsarginiame duomenų centre. Manome, kad turime apie 100 virtualių mašinų. Kol veikia pirminis duomenų centras, budėjimo režimo duomenų centras gali paleisti bandomąsias aplinkas ir kitas sistemas, kurios gali būti išjungtos, jei pirminis duomenų centras persijungia. Taip pat įmanoma, kad naudojame dvipusį replikaciją. Aparatūros požiūriu niekas nepasikeis.
Klasikinės architektūros atveju kiekviename duomenų centre įdiegsime hibridinę saugojimo sistemą su prieiga per FibreChannel, pakopomis, deduplikacija ir glaudinimu (bet ne internetu), 8 serverius kiekvienai svetainei, 2 FibreChannel jungiklius ir 10G Ethernet. Replikacijos ir perjungimo valdymui klasikinėje architektūroje galime naudoti VMware įrankius (Replication + SRM) arba trečiųjų šalių įrankius, kurie bus šiek tiek pigesni, o kartais ir patogesni.
Paveikslėlyje parodyta diagrama.
Naudojant Cisco HyperFlex, gaunama tokia architektūra:
„HyperFlex“ naudoju serverius su dideliais CPU/RAM ištekliais, nes... Dalis išteklių atiteks „HyperFlex“ valdiklio VM; kalbant apie procesorių ir atmintį, net šiek tiek perkonfigūravau „HyperFlex“ konfigūraciją, kad nežaisčiau kartu su „Cisco“ ir garantuočiau išteklius likusioms VM. Tačiau galime atsisakyti „FibreChannel“ jungiklių ir kiekvienam serveriui nereikės Ethernet prievadų; vietinis srautas perjungiamas FI.
Rezultatas buvo tokia kiekvieno duomenų centro konfigūracija:
Serveriai
8 x 1U serveris (384 GB RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
SHD
Hibridinė saugojimo sistema su FC Front-End (20 TB SSD, 130 TB NL-SAS)
-
LAN
2 x Ethernet jungiklis 10G 12 prievadų
-
SAN
2 x FC jungiklis 32/16Gb 24 prievadai
2 x Cisco UCS FI 6332
Licencijos
VMware Ent Plus
VM perjungimo replikavimas ir (arba) orkestravimas
VMware Ent Plus
Aš nepateikiau „Hyperflex“ replikacijos programinės įrangos licencijų, nes ją galime įsigyti jau iš karto.
Klasikinei architektūrai pasirinkau pardavėją, kuris įsitvirtino kaip kokybiškas ir nebrangus gamintojas. Abiem variantams pritaikiau standartinę nuolaidą konkrečiam sprendimui ir dėl to gavau realias kainas.
„Cisco HyperFlex“ sprendimas pasirodė 13% pigesnis.
2 scenarijus: dviejų aktyvių duomenų centrų sukūrimas. Pagal šį scenarijų VMware kuriame ištemptą klasterį.
Klasikinę architektūrą sudaro virtualizacijos serveriai, SAN (FC protokolas) ir dvi saugojimo sistemos, galinčios nuskaityti ir rašyti tarp jų ištemptą tomą. Kiekvienoje saugojimo sistemoje įdedame naudingos talpos saugojimui.
„HyperFlex“ mes tiesiog sukuriame „Stret Cluster“ su tuo pačiu mazgų skaičiumi abiejose svetainėse. Šiuo atveju naudojamas replikacijos koeficientas 2+2.
Rezultatas yra tokia konfigūracija:
klasikinė architektūra
HyperFlex
Serveriai
16 x 1U serveris (384 GB RAM, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)
16 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
SHD
2 x „AllFlash“ saugojimo sistemos (150 TB SSD)
-
LAN
4 x Ethernet jungiklis 10G 24 prievadų
-
SAN
4 x FC jungiklis 32/16Gb 24 prievadai
4 x Cisco UCS FI 6332
Licencijos
VMware Ent Plus
VMware Ent Plus
Visuose skaičiavimuose neatsižvelgiau į tinklo infrastruktūrą, duomenų centro kaštus ir t.t.: klasikinei architektūrai ir HyperFlex sprendimui jie bus vienodi.
Kalbant apie kainą, HyperFlex pasirodė 5% brangesnis. Čia verta pastebėti, kad kalbant apie CPU/RAM resursus, aš turėjau iškrypimą Cisco, nes konfigūracijoje atminties valdiklio kanalus užpildžiau tolygiai. Kaina yra šiek tiek didesnė, bet ne pagal dydį, o tai aiškiai rodo, kad hiperkonvergencija nebūtinai yra „turtuolių žaislas“, bet gali konkuruoti su standartiniu duomenų centro kūrimo metodu. Tai taip pat gali dominti tuos, kurie jau turi Cisco UCS serverius ir atitinkamą infrastruktūrą.
Tarp privalumų yra tai, kad nėra išlaidų administruojant SAN ir saugojimo sistemas, internetinį glaudinimą ir dubliavimo panaikinimą, vieną įėjimo tašką palaikymui (virtualizacija, serveriai, jie taip pat yra saugojimo sistemos), vietos taupymą (bet ne visais atvejais), operaciją supaprastinant.
Kalbant apie palaikymą, čia jį gausite iš vieno pardavėjo - „Cisco“. Sprendžiant iš mano patirties su Cisco UCS serveriais, man tai patinka; man nereikėjo atidaryti HyperFlex, viskas veikė taip pat. Inžinieriai operatyviai reaguoja ir gali išspręsti ne tik tipines problemas, bet ir sudėtingus kraštutinius atvejus. Kartais kreipiuosi į juos su klausimais: „Ar įmanoma tai padaryti, prisukti? arba „Aš čia kažką sukonfigūravau ir jis nenori veikti. Pagalba!" - jie ten kantriai suras reikiamą vadovą ir nurodys teisingus veiksmus; neatsakys: „Spręstume tik techninės įrangos problemas“.
Nuorodos
- Mano paštas - [apsaugotas el. paštu]
Šaltinis: www.habr.com