See on müüt, mis on serveri riistvara vallas üsna levinud. Praktikas on hüperkonvergeeritud lahendusi (kui kõik on ühes) vaja paljude asjade jaoks. Ajalooliselt töötasid esimesed arhitektuurid välja Amazon ja Google oma teenuste jaoks. Siis tekkis idee teha arvutusfarm identsetest sõlmedest, millest igaühel on oma kettad. Seda kõike ühendas mingi süsteemi moodustav tarkvara (hüperviisor) ja jagati virtuaalmasinateks. Peamine eesmärk on minimaalne pingutus ühe sõlme teenindamiseks ja minimaalne probleeme skaleerimisel: ostke lihtsalt tuhat või kaks samasugust serverit ja ühendage need läheduses. Praktikas on need üksikjuhtumid ja palju sagedamini räägime väiksemast arvust sõlmedest ja veidi erinevast arhitektuurist.
Kuid pluss jääb samaks – uskumatu skaleerimise ja haldamise lihtsus. Negatiivne külg on see, et erinevad ülesanded tarbivad ressursse erinevalt ja mõnes kohas on palju lokaalseid kettaid, teises on vähe RAM-i jne, ehk siis erinevat tüüpi ülesannete puhul ressursikasutus väheneb.
Selgub, et seadistamise hõlbustamise eest maksate 10–15% rohkem. Just see tekitas pealkirjas oleva müüdi. Otsisime kaua aega, kus tehnoloogiat optimaalselt rakendada saaks, ja leidsime selle. Fakt on see, et Ciscol polnud oma salvestussüsteeme, kuid nad tahtsid täielikku serveriturgu. Ja nad tegid Cisco Hyperflexi – lahenduse, mille sõlmedes on kohalik salvestusruum.
Ja see osutus ühtäkki väga heaks lahenduseks varuandmekeskuste jaoks (katastroofi taastamine). Ma ütlen teile nüüd, miks ja kuidas. Ja ma näitan teile klastriteste.
Kus vaja
Hüperkonvergents on:
- Ketaste ülekandmine arvutussõlmedesse.
- Salvestusalamsüsteemi täielik integreerimine virtualiseerimise alamsüsteemiga.
- Ülekanne/integreerimine võrgu alamsüsteemiga.
See kombinatsioon võimaldab teil rakendada paljusid salvestussüsteemi funktsioone virtualiseerimise tasemel ja seda kõike ühest juhtimisaknast.
Meie ettevõttes on üleliigsete andmekeskuste projekteerimise projektid väga nõutud ja sageli valitakse hüperkonvergeeritud lahendus tänu hulgale replikatsioonivõimalustele (kuni metroklastrini).
Varuandmekeskuste puhul räägime tavaliselt kaugemast rajatisest, mis asub linna teises otsas või üldse teises linnas. See võimaldab teil taastada kriitilised süsteemid peamise andmekeskuse osalise või täieliku rikke korral. Seal kopeeritakse pidevalt müügiandmeid ja see replikatsioon võib olla rakenduse tasemel või plokkseadme (salvestusruumi) tasemel.
Seetõttu räägin nüüd süsteemi disainist ja testidest ning siis paarist reaalsest rakendusestsenaariumist koos säästuandmetega.
Testid
Meie eksemplar koosneb neljast serverist, millest igaühel on 10 960 GB SSD-draivi. Kirjutamistoimingute vahemällu salvestamiseks ja teenuse virtuaalmasina salvestamiseks on spetsiaalne ketas. Lahendus ise on neljas versioon. Esimene on ausalt öeldes toores (arvustuste põhjal otsustades), teine on niiske, kolmas on juba üsna stabiilne ja seda võib nimetada väljalaseks pärast laiemale avalikkusele mõeldud beetatestimise lõppu. Testimise ajal ma probleeme ei näinud, kõik töötab nagu kell.
Muudatused versioonis 4Hunnik vigu on parandatud.
Algselt sai platvorm töötada ainult VMware ESXi hüperviisoriga ja toetas väikest arvu sõlme. Samuti ei lõppenud juurutusprotsess alati edukalt, mõned sammud tuli taaskäivitada, vanematest versioonidest värskendamisel esines probleeme, GUI-s olevaid andmeid ei kuvatud alati õigesti (kuigi ma pole ikka veel rahul jõudlusgraafikute kuvamisega ), tekkis mõnikord probleeme virtualiseerimise liidesega.
Nüüd on kõik lapsepõlveprobleemid lahendatud, HyperFlex saab hakkama nii ESXi kui Hyper-V-ga, lisaks on võimalik:
- Venitatud klastri loomine.
- Kontorite jaoks klastri loomine ilma Fabric Interconnecti kasutamata, kahest kuni neljast sõlmest (ostame ainult servereid).
- Võimalus töötada väliste salvestussüsteemidega.
- Konteinerite ja Kubernetesi tugi.
- Kättesaadavustsoonide loomine.
- Integreerimine VMware SRM-iga, kui sisseehitatud funktsionaalsus ei ole rahuldav.
Arhitektuur ei erine palju peamiste konkurentide lahendustest, jalgratast nad ei loonud. See kõik töötab VMware või Hyper-V virtualiseerimisplatvormil. Riistvara majutatakse patenteeritud Cisco UCS-serverites. On neid, kes vihkavad platvormi algseadistuse suhtelise keerukuse, paljude nuppude, mittetriviaalse mallide ja sõltuvuste süsteemi pärast, kuid on ka neid, kes on zeni õppinud, on ideest inspireeritud ega taha enam. teiste serveritega töötamiseks.
Kaalume VMware lahendust, kuna lahendus loodi algselt selle jaoks ja sellel on rohkem funktsionaalsust, Hyper-V lisandus tee peale, et konkurentidega sammu pidada ja turu ootustele vastata.
Seal on servereid täis kettaid. Andmete salvestamiseks on kettad (SSD või HDD - vastavalt maitsele ja vajadustele), vahemällu on üks SSD ketas. Andmete andmesalve kirjutamisel salvestatakse andmed vahemälukihile (teenuse VM-i spetsiaalne SSD ketas ja RAM). Paralleelselt saadetakse klastri sõlmedesse andmeplokk (sõlmede arv sõltub klastri replikatsioonitegurist). Pärast kõigi sõlmede kinnitust eduka salvestamise kohta saadetakse salvestuse kinnitus hüperviisorile ja seejärel VM-ile. Salvestatud andmed deduplikeeritakse, tihendatakse ja kirjutatakse taustal salvestusketastele. Samal ajal kirjutatakse salvestusketastele alati ja järjestikku suur plokk, mis vähendab salvestusketaste koormust.
Deduplikatsioon ja tihendamine on alati lubatud ja neid ei saa keelata. Andmeid loetakse otse salvestusketastelt või RAM-i vahemälust. Kui kasutatakse hübriidkonfiguratsiooni, salvestatakse lugemised ka SSD-le vahemällu.
Andmed ei ole seotud virtuaalmasina praeguse asukohaga ja jaotuvad sõlmede vahel ühtlaselt. See lähenemine võimaldab laadida kõiki kettaid ja võrguliideseid võrdselt. Sellel on ilmne puudus: me ei saa lugemislatentsust nii palju kui võimalik vähendada, kuna andmete lokaalne kättesaadavus pole garanteeritud. Kuid ma usun, et see on väike ohver võrreldes saadud kasudega. Lisaks on võrgu viivitused saavutanud sellised väärtused, mis praktiliselt ei mõjuta üldist tulemust.
Spetsiaalne VM Cisco HyperFlex Data Platform kontroller, mis luuakse igas salvestussõlmes, vastutab kogu ketta alamsüsteemi tööloogika eest. Meie teenuse VM-i konfiguratsioonis eraldati kaheksa vCPU-d ja 72 GB muutmälu, mida polegi nii vähe. Tuletan meelde, et hostil endal on 28 füüsilist tuuma ja 512 GB muutmälu.
Teenuse VM-l on juurdepääs füüsilistele ketastele otse, edastades SAS-i kontrolleri VM-ile. Suhtlemine hüperviisoriga toimub spetsiaalse mooduli IOVisor kaudu, mis peatab I/O operatsioonid, ja kasutades agenti, mis võimaldab saata käske hüperviisori API-le. Agent vastutab HyperFlexi hetktõmmiste ja kloonidega töötamise eest.
Kettaressursid monteeritakse hüperviisorisse NFS- või SMB-jagamistena (olenevalt hüperviisori tüübist, arvake ära, kumb on kus). Ja kapoti all on see hajutatud failisüsteem, mis võimaldab teil lisada täiskasvanutele mõeldud täisväärtuslike salvestussüsteemide funktsioone: õhuke mahu eraldamine, tihendamine ja dubleerimine, hetktõmmised ümbersuunamise-kirjutamisel tehnoloogia abil, sünkroonne/asünkroonne replikatsioon.
Teenus VM võimaldab juurdepääsu HyperFlexi alamsüsteemi veebihaldusliidesele. Integratsioon vCenteriga on olemas ja sealt saab teha enamikku igapäevatoiminguid, kuid näiteks andmesalve on mugavam lõigata eraldi veebikaamerast, kui oled juba kiirele HTML5 liidesele üle läinud või kasutad täisväärtuslikku Flash-klienti täieliku integratsiooniga. Teenuse veebikaameras saate vaadata süsteemi jõudlust ja üksikasjalikku olekut.
Klastris on teist tüüpi sõlm - arvutussõlmed. Need võivad olla rack- või teraserverid, millel pole sisseehitatud kettaid. Need serverid saavad käivitada VM-e, mille andmed on salvestatud ketastega serveritesse. Andmejuurdepääsu seisukohalt ei ole sõlmetüüpide vahel vahet, sest arhitektuur hõlmab andmete füüsilisest asukohast abstraheerimist. Arvutussõlmede ja salvestussõlmede maksimaalne suhe on 2:1.
Arvutussõlmede kasutamine suurendab paindlikkust klastri ressursside skaleerimisel: me ei pea ostma täiendavaid kettaid, kui vajame ainult CPU/RAM-i. Lisaks saame lisada blade puuri ja säästa serverite püstiku paigutamisel.
Selle tulemusena on meil hüperkonvergeeritud platvorm, millel on järgmised funktsioonid:
- Kuni 64 sõlme klastris (kuni 32 salvestussõlme).
- Klastris on minimaalne sõlmede arv kolm (edge klastri jaoks kaks).
- Andmete liiasusmehhanism: peegeldamine replikatsiooniteguriga 2 ja 3.
- Metroo klaster.
- Asünkroonne VM-i replikatsioon teise HyperFlexi klastrisse.
- VM-ide kaugandmekeskusesse ümberlülitamise korraldamine.
- Natiivsed hetktõmmised, kasutades ümbersuunamise kirjutamisel tehnoloogiat.
- Kuni 1 PB kasutatavat ruumi replikatsiooniteguriga 3 ja ilma dubleerimiseta. Me ei võta arvesse replikatsioonitegurit 2, kuna see ei ole tõsiste müügivõimaluste jaoks.
Teine suur pluss on haldamise ja juurutamise lihtsus. Kõigi UCS-serverite seadistamise keerukuse eest hoolitseb spetsiaalne VM, mille on koostanud Cisco insenerid.
Katsestendi konfiguratsioon:
- 2 x Cisco UCS Fabric Interconnect 6248UP haldusklastri ja võrgukomponentidena (48 porti, mis töötavad Ethernet 10G/FC 16G režiimis).
- Neli Cisco UCS HXAF240 M4 serverit.
Serveri omadused:
Protsessor
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/kahe asetusega/x4/1.2v
võrk
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Etherneti porti
Salvestus HBA
Cisco 12G modulaarne SAS-i kontrolleri läbimine
Salvestuskettad
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Rohkem konfiguratsioonivalikuidLisaks valitud riistvarale on praegu saadaval järgmised valikud:
- HXAF240c M5.
- Üks või kaks protsessorit alates Intel Silver 4110 kuni Intel Platinum I8260Y. Saadaval teine põlvkond.
- 24 mälupesa, ribad alates 16 GB RDIMM 2600 kuni 128 GB LRDIMM 2933.
- 6 kuni 23 andmeketast, üks vahemäluketas, üks süsteemiketas ja üks alglaadimisketas.
Võimsusajamid
- HX-SD960G61X-EV 960GB 2.5-tolline Enterprise Value 6G SATA SSD (1X vastupidavus) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 tolli Enterprise Value 6G SATA SSD (1X vastupidavus) SAS 3.8 TB.
- Draivide vahemällu salvestamine
- HX-NVMEXPB-I375 375 GB 2.5-tolline Intel Optane draiv, äärmuslik jõudlus ja vastupidavus.
- HX-NVMEHW-H1600* 1.6 TB 2.5 tolli Ent. Perf. NVMe SSD (3X vastupidavus) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400 GB 2.5 tolli Ent. Perf. 12G SAS SSD (10X vastupidavus) SAS 400 GB.
- HX-SD800GBENK9** 800 GB 2.5-tolline Ent. Perf. 12G SAS SED SSD (10X vastupidavus) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5-tolline Enterprise jõudlus 12G SAS SSD (3X vastupidavus).
Süsteemi/logi draivid
- HX-SD240GM1X-EV 240 GB 2.5-tolline Enterprise Value 6G SATA SSD (vajab uuendamist).
Käivitusdraivid
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB.
Ühendage võrguga 40G, 25G või 10G Etherneti portide kaudu.
FI võib olla HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Test ise
Ketta alamsüsteemi testimiseks kasutasin HCIBenchi 2.2.1. See on tasuta utiliit, mis võimaldab automatiseerida koormuse loomist mitmest virtuaalmasinast. Koormuse ise genereerib tavaline fio.
Meie klaster koosneb neljast sõlmest, replikatsioonitegur 3, kõik kettad on Flash.
Testimiseks lõin neli andmesalvet ja kaheksa virtuaalmasinat. Kirjutamistestide puhul eeldatakse, et vahemällu salvestav ketas pole täis.
Testi tulemused on järgmised:
100% lugemine 100% juhuslik
0% Lugemine 100% juhuslikult
Ploki/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 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
Paks tähistab väärtusi, mille järel tootlikkus ei tõuse, mõnikord on näha isegi halvenemist. See on tingitud asjaolust, et meid piirab võrgu/kontrollerite/ketaste jõudlus.
- Järjestikune lugemine 4432 MB/s.
- Järjestikune kirjutamine 804 MB/s.
- Kui üks kontroller ebaõnnestub (virtuaalse masina või hosti rike), on jõudluse langus kahekordne.
- Kui salvestusketas ebaõnnestub, on väljavõte 1/3. Ketta taastamine võtab 5% iga kontrolleri ressurssidest.
Väikesel plokil piirab meid kontrolleri (virtuaalmasina) jõudlus, selle protsessor on 100% koormatud ja kui plokk suureneb, piirab meid pordi ribalaius. 10 Gbps ei ole AllFlash süsteemi potentsiaali avamiseks piisav. Kahjuks ei võimalda kaasasoleva demostendi parameetrid 40 Gbit/s toimimist testida.
Minu mulje järgi testidest ja arhitektuuri uurimisest, et tänu algoritmile, mis paigutab andmed kõigi hostide vahele, saame skaleeritava, prognoositava jõudluse, kuid see on lugemisel ka piirang, sest kohalikelt ketastelt oleks võimalik rohkem välja pigistada, siin võib see säästa produktiivsemat võrku, näiteks on saadaval FI 40 Gbit/s.
Piiranguks võib osutuda ka üks ketas vahemällu salvestamiseks ja dubleerimiseks; tegelikult saame selles testbändis kirjutada neljale SSD-kettale. Oleks tore, kui saaks vahemällu salvestavate draivide arvu suurendada ja erinevust näha.
Reaalne kasutus
Varundusandmekeskuse korraldamiseks võite kasutada kahte lähenemisviisi (me ei kaalu varukoopia paigutamist kaugsaidile):
- Aktiivne passiivne. Kõik rakendused on hostitud peamises andmekeskuses. Replikatsioon on sünkroonne või asünkroonne. Kui peamine andmekeskus ebaõnnestub, peame aktiveerima varukeskuse. Seda saab teha käsitsi/skriptide/orkestreerimisrakendustega. Siin saame replikatsioonisagedusele vastava RPO ja RTO sõltub administraatori reaktsioonist ja oskustest ning lülitusplaani arendamise/silumise kvaliteedist.
- Aktiivne-Aktiivne. Sel juhul toimub ainult sünkroonne replikatsioon; andmekeskuste saadavuse määrab kvoorum/vahekohtunik, mis asub rangelt kolmandal saidil. RPO = 0 ja RTO võib ulatuda 0-ni (kui rakendus lubab) või võrdne virtualiseerimisklastri sõlme tõrkesiirdeajaga. Virtualiseerimise tasemel luuakse venitatud (Metro) klaster, mis nõuab Active-Active salvestusruumi.
Tavaliselt näeme, et kliendid on peamises andmekeskuses juba juurutanud klassikalise salvestussüsteemiga arhitektuuri, seega kavandame replikatsiooni jaoks teise. Nagu mainisin, pakub Cisco HyperFlex asünkroonset replikatsiooni ja venitatud virtualiseerimisklastri loomist. Samal ajal ei vaja me spetsiaalset keskmise ja kõrgema taseme salvestussüsteemi, millel on kallid replikatsioonifunktsioonid ja Active-Active andmete juurdepääs kahel salvestussüsteemil.
1. stsenaarium: Meil on esmane ja varuandmekeskus, virtualiseerimisplatvorm VMware vSphere'is. Kõik tootlikud süsteemid asuvad peamises andmekeskuses ja virtuaalmasinate replikatsioon toimub hüperviisori tasemel, see väldib VM-ide sisselülitamist varuandmekeskuses. Kopeerime andmebaase ja erirakendusi sisseehitatud tööriistade abil ning hoiame VM-id sisse lülitatuna. Kui peamine andmekeskus ebaõnnestub, käivitame süsteemid varuandmekeskuses. Usume, et meil on umbes 100 virtuaalset masinat. Kui esmane andmekeskus töötab, saab ooterežiimis olev andmekeskus käivitada testkeskkondi ja muid süsteeme, mille saab peamise andmekeskuse ümberlülitumisel välja lülitada. Samuti on võimalik, et kasutame kahesuunalist replikatsiooni. Riistvara seisukohalt ei muutu midagi.
Klassikalise arhitektuuri puhul paigaldame igasse andmekeskusesse hübriidsalvestussüsteemi, millel on juurdepääs FibreChanneli, astmestamise, dubleerimise ja tihendamise kaudu (kuid mitte võrgus), iga saidi jaoks 8 serverit, 2 FibreChannel lülitit ja 10G Ethernet. Klassikalise arhitektuuri replikatsiooni- ja kommutatsioonihalduseks saame kasutada VMware'i tööriistu (Replication + SRM) või kolmanda osapoole tööriistu, mis on veidi odavamad ja mõnikord mugavamad.
Joonis näitab diagrammi.
Cisco HyperFlexi kasutamisel saadakse järgmine arhitektuur:
HyperFlexi jaoks kasutasin suurte CPU/RAM-ressurssidega servereid, kuna... Osa ressursse läheb HyperFlexi kontrolleri VM-ile; protsessori ja mälu osas konfigureerisin isegi HyperFlexi konfiguratsiooni veidi ümber, et mitte Ciscoga kaasa mängida ja ülejäänud VM-idele ressursse garanteerida. Kuid me võime FibreChanneli lülititest loobuda ja me ei vaja iga serveri jaoks Etherneti porte, kohalik liiklus lülitatakse FI sees.
Tulemuseks oli iga andmekeskuse jaoks järgmine konfiguratsioon:
Serverid
8 x 1U server (384 GB RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB muutmälu, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
SHD
Hübriidsalvestussüsteem FC esiosaga (20 TB SSD, 130 TB NL-SAS)
-
LAN
2 x Etherneti lüliti 10G 12 porti
-
SAN
2 x FC switch 32/16Gb 24 porti
2 x Cisco UCS FI 6332
Litsentsid
VMware Ent Plus
VM-i ümberlülituse replikatsioon ja/või orkestreerimine
VMware Ent Plus
Ma ei andnud Hyperflexi jaoks replikatsioonitarkvara litsentse, kuna see on meile karbist väljas saadaval.
Klassikalise arhitektuuri jaoks valisin müüja, kes on end tõestanud kvaliteetse ja odava tootjana. Mõlema variandi puhul rakendasin konkreetse lahenduse tavaallahindlust ja selle tulemusena sain reaalsed hinnad.
Cisco HyperFlexi lahendus osutus 13% odavamaks.
2. stsenaarium: kahe aktiivse andmekeskuse loomine. Selle stsenaariumi korral kujundame VMware'is venitatud klastri.
Klassikaline arhitektuur koosneb virtualiseerimisserveritest, SAN-ist (FC-protokoll) ja kahest salvestussüsteemist, mis suudavad lugeda ja kirjutada nende vahele venitatud helitugevusele. Igale salvestussüsteemile paneme ladustamiseks kasuliku mahu.
HyperFlexis loome lihtsalt venitusklastri, millel on mõlemal saidil sama arv sõlme. Sel juhul kasutatakse replikatsioonitegurit 2+2.
Tulemuseks on järgmine konfiguratsioon:
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 muutmälu, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
SHD
2 x AllFlash salvestussüsteemi (150 TB SSD)
-
LAN
4 x Etherneti lüliti 10G 24 porti
-
SAN
4 x FC switch 32/16Gb 24 porti
4 x Cisco UCS FI 6332
Litsentsid
VMware Ent Plus
VMware Ent Plus
Kõigis arvutustes ei võtnud ma arvesse võrgu infrastruktuuri, andmekeskuse kulusid jms: need on klassikalise arhitektuuri ja HyperFlexi lahenduse puhul samad.
Kulude poolest osutus HyperFlex 5% kallimaks. Siinkohal tasub märkida, et CPU/RAM-i ressursside osas oli mul Cisco jaoks viltu, kuna konfiguratsioonis täitsin mälukontrolleri kanalid ühtlaselt. Maksumus on pisut kõrgem, kuid mitte suurusjärgus, mis näitab selgelt, et hüperkonvergents pole tingimata "rikaste mänguasi", vaid võib konkureerida andmekeskuse ehitamise standardse lähenemisviisiga. See võib huvi pakkuda ka neile, kellel juba on Cisco UCS-i serverid ja nende jaoks vastav infrastruktuur.
Eeliste hulgas on SAN-i ja salvestussüsteemide haldamise kulude puudumine, võrgus tihendamine ja dubleerimine, üks tugipunkt (virtualiseerimine, serverid, need on ka salvestussüsteemid), ruumi säästmine (kuid mitte kõigis stsenaariumides), toimimise lihtsustamine.
Mis puutub tuge, siis siin saate selle ühelt müüjalt - Cisco. Cisco UCS-i serveritega seotud kogemuste põhjal mulle see meeldib; ma ei pidanud seda HyperFlexis avama, kõik töötas samamoodi. Insenerid reageerivad kiiresti ja suudavad lahendada mitte ainult tüüpilisi probleeme, vaid ka keerukaid äärejuhtumeid. Mõnikord pöördun nende poole küsimustega: "Kas seda on võimalik teha, keerake kinni?" või „Seadistasin siin midagi ja see ei taha töötada. Aidake!" - nad leiavad sealt kannatlikult üles vajaliku juhendi ja osutavad õigetele tegevustele; nad ei vasta: "Me lahendame ainult riistvaraprobleeme."
Viited
- Minu post - [meiliga kaitstud]
Allikas: www.habr.com