See on müüt, mis on serveritehnika valdkonnas üsna levinud. Praktikas on aga hübriidlahendused (kui kõik on ühes) vajalikud mitmesugustel eesmärkidel. Ajalooliselt arendati esimesed arhitektuurid Amazonis ja Googles nende teenuste jaoks. Idee oli luua arvutusfarm, kus kõik sõlmed on ühesugused ja igal neist on oma kettad. Kõike seda ühendati mingi süsteemi loomise tarkvara (hüperviisoriga) ja jagati seejärel virtuaalseteks masinateks. Peamine eesmärk — minimaalne hoolduskoormus ühe sõlme jaoks ja probleemide minimaalne arv mahu suurendamisel: lihtsalt osteti veel tuhat-kaks selliseid servereid ja ühendati kõrval. Praktikas on see üksikjuhtum, ja palju sagedamini räägitakse väiksemate sõlmede arvust ja veidi teisest arhitektuurist.
Kuid pluss jääb endiseks — uskumatult lihtne skaleerimine ja haldamine. Miinus — erinevad ülesanded tarbivad ressursse erinevalt, ja mõnes kohas on kohalikke kettaid palju, teises kohas vähem RAM-i jne, see tähendab, et erinevat tüüpi ülesannete puhul on ressursside kasutamine madal.
Selgus, et maksate 10–15% enam mugavuse eest seadistamisel. Just see tekitas pealkirjas oleva müüdi. Otsisime kaua, kus see tehnoloogia optimaalselt rakenduks, ja leidsime. Asi on selles, et Cisco’l ei olnud oma SÜD-sid, kuid nad soovisid täielikku serveriturge. Ja nad lõid Cisco Hyperflexi — lahenduse kohalike salvestustega node'ides.
Sellest sai äkki väga hea lahendus varukoopia andeskeskustele (Disaster Recovery). Miks ja kuidas — räägin nüüd. Ja näitan klastritest teste.
Kus on vajalik
Hüpere konvergents — see on:
- Kettade transport arvutusmoodulitesse.
- Täielik salvestussüsteemi integreerimine virtualiseerimise alamsüsteemiga.
- Transport/integreerimine võrgu alamsüsteemiga.
Selline kombinatsioon võimaldab rakendada paljusid SÜD funktsioone virtualiseerimise tasandil ja kõike ühest juhtpaneelist.
Meie ettevõttes on väga nõutud projektid varukoopia andeskeskuste projekteerimiseks, ja sageli valitakse just hübriidlahendus, kuna sellel on palju replikeerimise võimalusi (kuni metroklaasini) juba standardsena.
Tavaliselt räägitakse varukoopiate andmekeskustest, mis asub teises linnas või linna teises otsas. See võimaldab taastada kriitilised süsteemid põhikeskuse osalise või täieliku rikke korral. Andmeid replikatakse pidevalt, ning see võib toimuda rakendustasandil või plokkseadmestiku tasandil (SAN).
Seetõttu räägin nüüd süsteemi seadmest ja testidest ning seejärel — paarist reaalse rakenduse stsenaariumist koos säästmisandmetega.
Testid
Meie eksemplar koosneb neljast serverist, milles igas on 10 SSD-diski mahuga 960 GB. Seal on eraldi ketas kirjutamisoperatsioonide vahemällu salvestamiseks ja teenuse virtuaalmasina hoidmiseks. Lahendus on juba neljas versioon. Esimene oli tõeliselt toor, teine jäi ikka veel tooreks, kolmas oli juba piisavalt stabiilne, ja seda võib pidada avaliku beetatestimise lõpetamise järel välja antud versiooniks. Testimise ajal ei kohanud ma ühtegi probleemi, kõik töötab nagu kellavärk.
Muudatused v4Parandatud on palju vigu.
Alguses töötas platvorm ainult VMware ESXi hüperajuri ja toetas väikest arvu node. Samuti ei lõppenud juurutamisprotsess alati edukalt, pidi mõningaid etappe taaskäivitama, esines probleeme vanematelt versioonidelt uuendamisega ja andmete kuvamine GUI-s ei olnud alati korrektne (kuigi ma ei ole siiani eriti rahul jõudluse graafikute kuvamisega); mõnikord tekkisid probleemid virtualiseerimise piiril.
Nüüd on kõik algsed probleemid lahendatud, HyperFlex toetab nii ESXi kui Hyper-V, lisaks on võimalik:
- Laiendatud klastri loomine.
- Klastri loomine kontorites ilma Fabric Interconnecti kasutamiseta, kahest kuni neljani node'ini (ostame ainult serverid).
- Võime töötada väliste andmesalvestussüsteemidega.
- Konteinerite ja Kubernetes'e tugi.
- Saadavuspiirkondade loomine.
- Integreerimine VMware SRM-iga, kui sisseehitatud funktsionaalsus ei rahulda.
Arhitektuur ei erine oluliselt peamistest konkurentidest, ratast ei hakata uuesti välja mõtlema. Kõik töötab VMware või Hyper-V virtualiseerimisplatvormi peal. Riistvara on paigutatud Cisco UCS enda arendatud serveritesse. On neid, kes vihkavad platvormi suhtelise keerukuse tõttu algse seadistamise, paljude nuppude, mittetriviaalsete mallide ja sõltuvuste süsteemi poolest, kuid on ka neid, kes on tunnetanud zen'i, mõistnud ideed ja ei soovi enam teiste serveritega töötada.
Käsitleme just VMware lahendust, kuna see lahendus loodi algselt selle jaoks ja omab rohkem funktsioone; Hyper-V-d viimistleti jooksvalt, et mitte konkurentidest maha jääda ja vastata turu ootustele.
Klastri koosneb serveritest, millel on arvukalt kõvakettaid. Andmete säilitamiseks on saadaval muudatusdeta kõvakettad (SSD või HDD — vastavalt teie soovidele ja vajadustele), samuti üks SSD-ketas vahemäluks. Andmete kirjutamisel andmesalvestusse salvestatakse andmed vahemälu kihile (eraldatud SSD-disk ja teenuse VM RAM). Samal ajal saadetakse andmeplokk klastrisse node'idesse (node'ide arv sõltub klastrite replikatsiooni tegurist). Pärast kõigilt node’idelt edukast kirjutamisest saavad kinnitused, mis saadetakse hyperviisorile ja sealt edasi VM-ile. Salvestatud andmed dedupeeritakse, tihendatakse ja kirjutatakse salvestusketastele taustal. Samuti kirjutatakse salvestusketastele alati suur plokk ja järjestikku, mis vähendab salvestusketaste koormust.
Dedupeerimine ja tihendamine on pidevalt sisse lülitatud ning neid ei saa välja lülitada. Andmete lugemine toimub otse salvestuskettalt või RAM vahemälust. Kui kasutatakse hübriidkonfiguratsiooni, siis ka lugemine jaotatakse SSD-kettale.
Andmed ei seondu virtuaalmasina praeguse asukohaga ning jaotatakse sõlmede vahel võrdselt. Selline lähenemine võimaldab koormata kõik ketas- ja võrguinterfaced ühtlaselt. Ilmselge miinus on see, et me ei saa maksimaalselt vähendada lugemise viivitust, kuna puudub garantii, et andmed on lokaalsetes seadmetes olemas. Kuid ma arvan, et see on väike ohver võrreldes saadud eelistega. Eriti kuna võrgu viivitused on saavutanud selliseid väärtusi, et need ei mõjuta praktiliselt üldist tulemust.
Kogu ketas- ja süsteemi töö loogika eest vastutab spetsiaalne Teenuse VM Cisco HyperFlex Data Platform controller, mis luuakse igas salvestamise sõlmes. Meie konfiguratsioonis eraldati teenuse VM-le kaheksa vCPU ja 72 GB RAM, mis ei ole sugugi vähe. Tuletan meelde, et hostil on 28 füüsilist tuuma ja 512 GB RAM.
Teenuslik VM pääseb füüsilistele kettale otse, kasutades SAS-kontrolleri edastamist VM-i. Suhtlemine hüperviisoriga toimub spetsiaalse IOVisor mooduli kaudu, mis tabab sisend-väljundoperatsioonid, ja agendi kaudu, mis võimaldab käske edastada hüperviisori API-le. Agent vastutab HyperFlex'i jäädvustuste ja kloonide töötamise eest.
Hüperviisorile mountitakse kettaruumi ressursid kui NFS- või SMB-jagamine (sõltub hüperviisori tüübist, arvake, kummas on kummagi). Ja selle all on jaotatud failisüsteem, mis võimaldab lisada täiskasvanute funktsioone tipptasemel SDH-dest: pehme mahtude eraldamine, tihendamine ja dedupeerimine, Redirect-on-Write tehnoloogia jäädvustused, sünkroonne/asünkroonne replikatsioon.
Teenuse VM pakub juurdepääsu HyperFlex alamsüsteemi haldus WEB-liidesesse. On olemas integratsioon vCenter'iga, ja enamik igapäevasest tööst saab seal tehtud, kuid datastores't on näiteks mugavam kärpida eraldi veebiliidesest, kui olete juba liikunud kiiresti HTML5 liidesele, või kasutada täieõiguslikku Flash-kliendi täieintegratsiooniga. Teenuste veebiliideses saab vaadata süsteemi jõudlust ja detailset olekut.
Klastris on olemas ka teine tüüp sõlmedest - arvutuslikud sõlmed. Need võivad olla rack- või blade-serverid ilma sisemiste ketasteta. Nendel serveritel saab käitada VM-e, mille andmed on salvestatud ketastega serveritesse. Andmete juurdepääsu osas pole sõlmetüüpide vahel erinevust, kuna arhitektuur eeldab andmete füüsilise asukoha pealt abstraheerimist. Maksimaalne arv arvutussõlmi ja salvestussõlmi on 2:1.
Arvutussõlmede kasutamine suurendab klastrite ressursside skaleerimispaindlikkust: me ei pea tingimata ostma ketastega sõlmi, kui meie vajadus on ainult CPU/RAM. Lisaks võime lisada blade-korvi ja saavutada kokkuhoiust serverite paigutamisel rack'is.
Kokkuvõttes on meil hüperkonvergentine platvorm järgmiste omadustega:
- Klasstris kuni 64 sõlme (kuni 32 salvestussõlme).
- Klasstri minimaalne sõlmede arv on kolm (kaks - Edge-klastrite jaoks).
- Andmete ülemäärasuse mehhanism: peegeldamine replikatsiooni faktoriga 2 ja 3.
- Metro-klaster.
- VM-ide asünkroonne replikatsioon teise HyperFlex-klastri.
- VM-ide orkestreerimine kaugseadmisesse lülitumiseks.
- Natiivsed kiiruspunktid Redirect-on-Write tehnoloogia abil.
- Kuni 1 PB kasulikku ruumi replikatsiooni faktoriga 3 ja ilma deduplication'ita. Replikatsiooni faktor 2 ei arvestata, kuna see ei ole tõsiste müügivõimaluste jaoks sobiv.
Veel üks suur plusspunkt — haldamise ja juurutamise lihtsus. Kõik UCS serverite seadistamise keerukused võtab enda peale spetsialiseeritud virtuaalmasin, mille on ette valmistanud Cisco insenerid.
Teststandardi konfiguratsioon:
- 2 x Cisco UCS Fabric Interconnect 6248UP haldusklastri ja võrgukomponentidena (48 porti, töötavad Ethernet 10G/FC 16G režiimis).
- Neli Cisco UCS HXAF240 M4 serverit.
Serverite omadused:
CPU
2 x Intel ® Xeon ® E5-2690 v4
RAM
16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
Võrk log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s user haproxy group haproxy daemondefaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000frontend http_front bind *:80 stats uri /haproxy?stats default_backend http_backbackend http_back balance roundrobin server server_name1 private_ip1:80 check server server_name2 private_ip2:80 check
UCSC-MLOM-CSC-02 (VIC 1227). 2 porti 10G Ethernet
Salvestuse HBA
Cisco 12G Modular SAS Pass through Controller
Salvestusdiskid
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Rohkem konfiguratsioonivõimalusiValitud riistvarast lisaks, on hetkel saadaval järgmised valikud:
- HXAF240c M5.
- Üks või kaks CPU-d alates Intel Silver 4110 kuni Intel Platinum I8260Y. Saadaval on teine põlvkond.
- 24 mälu pesa, mälupulgad alates 16 GB RDIMM 2600 kuni 128 GB LRDIMM 2933.
- Alates 6 kuni 23 andmeketast, üks vahemälu ketas, üks süsteemiketaste ja üks käivituskettas.
Mahutavus ketas
- HX-SD960G61X-EV 960GB 2.5-tolline Enterprise Value 6G SATA SSD (1X kestvusega) SAS 960 GB.
- HX-SD38T61X-EV 3.8TB 2.5-tolline Enterprise Value 6G SATA SSD (1X kestvusega) SAS 3.8 TB.
- Vahemälu kettad
- HX-NVMEXPB-I375 375GB 2.5-tolline Intel Optane Drive, äärmiselt kõrge jõudlus ja kestvus.
- HX-NVMEHW-H1600* 1.6TB 2.5-tolline Ent. Perf. NVMe SSD (3X kestvusega) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5-tolline Ent. Perf. 12G SAS SSD (10X kestvusega) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5-tolline Ent. Perf. 12G SAS SED SSD (10X kestvusega) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5-tolline Enterprise jõudlusega 12G SAS SSD (3X kestvusega).
Süsteemi / logi kettad
- HX-SD240GM1X-EV 240GB 2.5-tolline Enterprise Value 6G SATA SSD (vajab uuendust).
Alglaadimise kettad
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Ühendamine võrku 40G, 25G või 10G Etherneti portide kaudu.
FI-de jaoks võivad olla HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Test ise
Kettasüsteemi testimiseks kasutasin HCIBench 2.2.1. See on tasuta utiliit, mis võimaldab automatiseerida koormuse loomist mitmest virtuaalsest masinast. Koormus genereeritakse tavalise fio-ga.
Meie kluster koosneb neljast nõost, replikatsiooni faktor on 3, kõik kettad on Flash.
Testimiseks lõin neli andmesalvestust ja kaheksa virtuaalset masinat. Kirjutamise testide puhul eeldatakse, et vahemälu kett ei ületa oma mahutavust.
Testide tulemused on järgmised:
100 % Lugemine 100 % Juhuslik
0 % Lugemine 100% Juhuslik
Plokki/järjekorra sügavus
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 IOPS
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 376484 IOPS
5,47 ms 373176 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
Rasvatud väärtused, mille järel ei ole jõudluse tõusu, mõnikord on isegi näha halvenemist. See on seotud sellega, et jõudlus piirab võrku/kontrollereid/kette.
- Järjestikune lugemine 4432 MB/s.
- Järjestikune kirjutamine 804 MB/s.
- Ühe kontrolleri rike (virtuaalmasina või hosti rike) põhjendab jõudluse langust - kaks korda.
- Salvestusplaatide rikke korral - langus 1/3. Ketaste taastamine kasutab 5% iga kontrolleri ressursse.
Küünalblokkide puhul piirame kontrolleri, virtuaalmasina, jõudlust, mille CPU on 100% koormatud, ning kui suurendame bloki, kokku puutume portide läbilaskevõimega. 10 Gbit/s on AllFlash-süsteemi potentsiaali avamiseks ebapiisav. Kahjuks ei võimalda esitatud demostendi parameetrid testida tööd 40 Gbit/s kiirusel.
Minu mulje testidest ja arhitektuuri uurimisest on, et andmete jaotamise algoritm võimaldab meil saavutada skaleeritavat ja prognoositavat jõudlust, kuid see on samas piirang lugemisel, kuna kohalikelt ketastelt oleks võimalik saavutada rohkem. Kollektsioonivõime võiks päästa kiirem võrk, näiteks FI on saadaval kiirusel 40 Gbit/s.
Samuti võib üks ketas puhverdamiseks ja dedupliceerimiseks olla piirang, sest antud seades saame kirjutada neljale SSD-kettale. Oleks suurepärane, kui oleks võimalik suurendada puhverduskettade arvu ja näha erinevust.
Tegelik kasutus
Reserveeritud andmekeskuse organiseerimiseks on võimalik kasutada kahte lähenemist (kaugplaanile salvestamine ei tule arvesse):
- Active-Passive. Kõik rakendused asuvad peamises andmekeskuses. Replikatsioon on sünkroonne või asünkroonne. Peamise andmekeskuse ebaõnnestumise korral tuleb aktiveerida varuandmekeskus. Seda saab teha käsitsi / skriptide / orkestreerimise rakenduste kaudu. Siin saame RPO, mis on võrreldav replikatsiooni sagedusega, ja RTO sõltub administraatori reageerimisest ja oskustest ning plaani ülemineku kvaliteedist.
- Active-Active. Selles olukorras on ainult sünkroonne replikatsioon, andmekeskuste kättesaadavus määratakse kvoorumi / vahemehega, mis on kindlalt kolmandas asukohas. RPO = 0, ja RTO võib ulatuda 0 (kui rakendus lubab) või olla võrreldav viga saanud sõlme taastamise ajaga virtualiseerimisklastris. Virtualiseerimistasandil luuakse venitatud (Metro) klaster, mis vajab Active-Active salvestussüsteemi.
Tavaliselt näeme klientide juures juba rakendatud arhitektuuri klassikalise andmesalvestuse süsteemiga peamiselt andmekeskuses, seega projekteerime veel ühe replikatsiooniks. Nagu ma mainisin, pakub Cisco HyperFlex asünkroonset replikatsiooni ja ulatusliku virtualiseerimise klastrite loomist. Selleks ei ole meil vaja pühendatud keskmise ulatusega ja kõrgema taseme andmesalvestust, mis sisaldab kallimaid replikatsiooni ja aktiivse-aktiivse andmete ligipääsu funktsioone kahel andmesalvestusel.
Skenaario 1: Meil on peamine ja varu andmekeskus, virtuaalplatvorm VMware vSphere. Kõik tootmissüsteemid asuvad peamas andmekeskuses, samas kui virtuaalmasinate replikatsioon toimub hüperviisori tasemel, mis võimaldab mitte hoida VM-e sisselülitatuna varu andmekeskuses. Andmebaasid ja spetsiaalsed rakendused replikeerime sisseehitatud vahenditega ja hoiame VM-e sisselülitatuna. Peamise andmekeskuse rikke korral käivitame süsteemid varu andmekeskuses. Arvame, et meil on umbes 100 virtuaalmasinat. Seni, kuni peamine andmekeskus on toimiv, saab varu andmekeskuses käivitada testkeskkondi ja muid süsteeme, mille saab välja lülitada, kui peamine andmekeskus tuleb vahetada. Samuti on võimalik kasutada kahepoolset replikatsiooni. Seadmestiku seisukohalt ei muutu midagi.
Klassikalise arhitektuuri puhul paigaldame igasse andakeskusesse hübriidse salvestussüsteemi, millel on juurdepääs FibreChanneli kaudu, tigermooduli, dedupeerimise ja kompressiooniga (kuid mitte reaalajas), 8 serverit iga asukoha kohta, 2 FibreChanneli ja 10G Etherneti lülitit. Replikatsiooniks ja vahetuse haldamiseks klassikalises arhitektuuris saame kasutada VMware'i vahendeid (Replication + SRM) või kolmandate osapoolte vahendeid, mis on veidi odavamad ja mõnikord mugavamad.
Joonisel on esitatud skeem.
Cisco HyperFlexi kasutamisel saadakse järgmine arhitektuur:
HyperFlexi jaoks kasutasin suuri CPU/RAM ressursse, kuna osa ressursse läheb HyperFlexi kontrolleri VM-ile. CPU ja mälu osas olen isegi pisut üle kavandanud HyperFlexi konfiguratsioonis, et mitte mängida Cisco suunas ja tagada ressursid teistele VM-idele. Sellega saame loobuda FibreChanneli lülititest ning meil ei ole vaja iga serveri jaoks Etherneti porte, kohalik liiklus kommutitakse FI sees.
Tulemusena saime järgmise konfiguratsiooni iga andakeskuse jaoks:
Serverid
8 x 1U Server (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)
Salvestussüsteem
Hübriidne salvestussüsteem FC Front-Endiga (20TB SSD, 130 TB NL-SAS)
—
LAN
2 x 10G Etherneti lülitit 12 porti
—
SAN
2 x FC lüliti 32/16Gb 24 porti
2 x Cisco UCS FI 6332
Load
VMware Ent Plus
Replikatsioon ja/või VM-i orkestreerimine
VMware Ent Plus
Hyperflexi jaoks ei ole tarkvara replikatsiooni litsentse kaasatud, kuna see on meil saadaval kui standardlahendus.
Klassikalise arhitektuuri jaoks valisin müüja, kelle kvaliteet ja taskukohasus on tõestatud. Kasutasin mõlema variandi puhul konkreetse lahenduse standardset soodustust, tulemusena sain reaalsed hinnad.
Cisco HyperFlex lahendus osutus 13% odavamaks.
Stsenaarium 2: kaks aktiivset andmekeskkonda. Selles stsenaariumis projekteerime venitatud klastri VMware'i põhjal.
Klassikaline arhitektuur koosneb virtualiseerimisserveritest, SAN (FC protokoll) ja kahest salvestusseadmest, mis suudavad lugeda ja kirjutada, venitatud nende vahel. Iga salvestusseadmest kavandame kasuliku mahtu kohale.
HyperFlex'is loome lihtsalt Stretch Clusteri, kus igas asukohas on sama arv noderit. Sellisel juhul kasutatakse replikatsiooni tegurit 2+2.
Saime järgmise konfiguratsiooni:
Klassikaline arhitektuur
HyperFlex
Serverid
16 x 1U server (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)
Salvestussüsteem
2 x AllFlash salvestusseade (150 TB SSD)
—
LAN
4 x Ethernet lüliti 10G 24 porti
—
SAN
4 x FC lüliti 32/16Gb 24 porti
4 x Cisco UCS FI 6332
Load
VMware Ent Plus
VMware Ent Plus
Kõikides arvutustes ei arvestanud ma võrgu infrastruktuuri, andmekeskuse kulusid jne: need on klassikalise arhitektuuri ja HyperFlex lahenduse jaoks samad.
HyperFlex osutus 5% kallimaks. Siinkohal on oluline märkida, et Cisco puhul on CPU/RAM ressursside jaotuses minu konfiguratsioonis mälu kontrollide kanalite tasakaalustamine. Hind on veidi kõrgem, kuid mitte enneolematult, mis näitab selgelt, et hüperkonvergents ei ole tingimata "rikaste mänguasi", vaid võib konkureerida tavalise andmekeskuse ülesehitamise lähenemisega. See võiks huvi pakkuda ka neile, kellel juba on Cisco UCS serverid ja vastav infrastruktuur.
Eelisteks on SAN-i ja salvestusseadmestiku haldustasude puudumine, reaalajas kompresseerimine ja dedupeerimine, ühtne tugipunkt (virtualiseerimine, serverid, samuti — salvestusseadmestik), ruumi kokkuhoid (aga mitte kõikides stsenaariumides) ja tööprotsesside lihtsustamine.
Toetuse osas saate seda ainult ühelt tarnijalt — Cisco. Minu kogemus Cisco UCS serveritega on positiivne, HyperFlexi avama ei pidanud, kõik töötas nagu peab. Insenerid vastavad kiiresti ja suudavad lahendada mitte ainult tavalisi probleeme, vaid ka keerulisi erandeid. Aeg-ajalt pöördun nende poole küsimustega: "Kas sedasi saab teha, lisada seda?" või "Olen siin midagi seadistanud, ja see ei tööta. Aidake!" — nad on kannatlikud ja leiavad õige juhendi ning näitavad õigeid toiminguid, nad ei ütle: "Me lahendame ainult riistvaraga seotud probleeme."
Lingid
- Minu e-post on StGeneralov@croc.ru
Allikas: habr.com
