See on müüt, mis on serveritehnika valdkonnas suhteliselt levinud. Praktiliselt on hüperkonvergeeritud lahendused (kui kõik on ühes) vajalikud paljuski. Ajalooliselt on esimesed arhitektuurid välja töötanud Amazon ja Google oma teenuste jaoks. Siis oli mõte luua arvutifarmer ühetaolistest sõlmedest, millest igaühel on oma kettad. Kõik see ühendati mingi süsteemitekitava tarkvaraga (hüperviisor) ja jagati seejärel virtuaalsete masinate vahel. Peamine ülesanne — minimaalne vaeva ühe sõlme hooldamiseks ja minimaalne probleemide arv skaleerimisel: lihtsalt osteti veel tuhat-kaks sellist serverit ja ühendati ritta. Praktiliselt on need üksikud juhud, ja palju sagedamini räägitakse väiksemast sõlmede arvust ja pisut teisest arhitektuurist.
Kuid pluss jääb samaks — uskumatult lihtne skaleerimine ja haldamine. Miinus — erinevad ülesanded tarbivad ressursse erinevalt, ja kuskile on palju kohalikke kettaid, kuskile vähe RAM-i ja nii edasi, st erinevat tüüpi ülesannete korral langeb ressursi kasutus.
Selgus, et maksate 10–15% rohkem mugavuse seadistamise eest. Just see tõi kaasa siin nimetatud müüdi. Otsisime pikka aega, kus saaks tehnoloogiat optimaalselt rakendada, ja leidsime. Asi on selles, et Ciscol ei olnud oma andmesalvestussüsteeme, kuid nad soovisid täielikku serveriturgu. Ja nad tegid Cisco Hyperflex — lahendus kohalike salvestustega sõlmedel.
Ja sellest tulenevalt sai väga hea lahenduse резервных дата-центров (Disaster Recovery). Miks ja kuidas — räägin nüüd. Ja näitan klastrite teste.
Kus on vajalik
Hüperkonvergeeritus — see on:
- Kettade viimine arvutisõlmedesse.
- Täpne integratsioon andmesalvestuse alamprogrammi ja virtualiseerimise alamprogrammi vahel.
- Viimine/integratsioon võrgu alamprogrammi.
Selline paar võimaldab rakendada paljusid andmesalvestuse funktsioone virtualiseerimise tasandil ja kõik ühest haldusaknast.
Meie ettevõttes on väga nõutud projektid reservdata keskustest ja sageli valitakse just hüperkonvergeeritud lahendus tänu kohutavalt paljudele replikatsiooni võimalustele (kuni metroklaster) kastist välja.
Varuväravakeskuste puhul räägitakse tavaliselt kaugobjektist, mis asub linnas või isegi teises linnas. See võimaldab taastada kriitilised süsteemid põhiväravakeskuse osalise või täieliku rikke korral. Andmed replikeeritakse pidevalt müügiserverist, ja see replikatsioon võib toimuda rakenduse tasemel või plokkseadmestiku tasemel (SAN).
Seetõttu räägin nüüd süsteemi struktuurist ja testidest, ja seejärel — paarist tegeliku rakenduse stsenaariumist koos kokkuhoidu puudutavate andmetega.
Testid
Meie mudel koosneb neljast serverist, milles on igaühes 10 SSD-diski, mille suurus on 960 GB. On eraldatud ketas kirjutamise ja teenindava virtuaalmasina operatsioonide vahemäluks. Lahendus ise on neljas versioon. Esimene oli avatud toode (kohtuotsuste alusel), teine oli samuti ebastabiilne, kolmas oli juba piisavalt stabiilne, ja seda saab nimetada väljalaskeversiooniks pärast avaliku beetatesti lõppu. Testimise ajal ei märganud ma probleeme, kõik töötab nagu kell.
Muutused v4-sPalju vigu on parandatud.
Alguses suutis platvorm töötada ainult hüpervisoriga VMware ESXi ja toetas väikest arvu node. Samuti ei lõppenud juurutamisprotsess kaugeltki alati edukalt, mõningaid etappe tuli taas käivitada, esines probleeme vanematelt versioonidelt uuendamisel, andmeid GUI-s ei kuvatud alati õigesti (kuigi ma ei ole praegugi graafikute kuvamise osas küll rahul), mõnikord esines probleeme virtualiseerimisega.
Praegu on kõik lastehaigused parandatud, HyperFlex toetab nii ESXi-d kui ka Hyper-V-d, lisaks on võimalik:
- Laiendatud klastri loomine.
- Klastri loomine kontorite jaoks ilma Fabric Interconnecti kasutamiseta, kahe kuni nelja nodega (ostame ainult serverid).
- Võime töötada väliste SAN-idega.
- Konteinerite ja Kubernetes'e tugi.
- Saadavuspiirkondade loomine.
- Integreerimine VMware SRM-iga, kui sisseehitatud funktsioon ei rahulda.
Arhitektuur ei erine oluliselt peamistest konkurentidest, uut ratast pole loodud. See töötab virtuelleerimise platvormil VMware või Hyper-V. Füüsiliselt on see paigutatud Cisco UCSi enda väljatöötatud serveritesse. On inimesi, kes vihkavad platvormi selle suhtelise keerukuse, rohkete nuppude, keerulise mallide ja sõltuvuste süsteemi tõttu, kuid leidub ka neid, kes on saavutanud zen'i, on ideest haaranud ja ei soovi enam teiste serveritega töötada.
Käsitleme just VMware lahendust, kuna see lahendus loodi algselt selle jaoks ja omab suuremat funktsionaalsust; Hyper-V-d on hiljem täiustatud, et mitte konkurentidest maha jääda ja turu ootustele vastata.
On olemas klaster serveritest, mis on täidetud ketastega. Andmete salvestamiseks on ketas (SSD või HDD — teie valik ja vajadused), seal on üks SSD-ketas vahemällu salvestamiseks. Andmete kirjutamisel andmestoori salvestatakse andmed vahemälu kihile (pühendatud SSD-ketas ja RAM teenindus-VM). Samal ajal saadetakse andmepakk sõlmedesse klastri sees (sõlmede arv sõltub klastri replikatsiooni tegurist). Pärast kõigilt sõlmedelt edu tõendamist saadetakse kirjutamise kinnitus hüperviisorile ja seejärel — VM-le. Salvestatud andmeid deduplitseeritakse, tihendatakse ja salvestatakse salvestusketastele taustal. Sel juhul kirjutatakse alati suur plokk salvestusketastele järjestikku, mis vähendab nende koormust.
Deduplikatsioon ja tihendamine on pidevalt lubatud ja neid ei saa välja lülitada. Andmete lugemine toimub otse salvestusketastelt või RAM-i vahemälu kaudu. Kui kasutatakse hübriidkonfiguratsiooni, siis ka lugemine vahemälust SSD-ketast.
Andmed ei ole seotud virtuaalmasina praeguse asukohaga ja jaotatakse sõlmede vahel ühtlaselt. Selline lähenemine võimaldab koormata kõiki kettaid ja võrgu liidesi ühtlaselt. Tõukab selgelt esile miinus: me ei saa lugemise viivitust maksimaalselt vähendada, kuna puudub garantii, et andmed asuvad kohalikult. Kuid ma arvan, et see on tühine ohver saadud plusside võrreldes. Eriti kuna võrgu viivitused on saavutanud selliseid suurusi, et praktiliselt ei mõjuta üldist tulemust.
Kogu diskialtistiku töölogika eest vastutab spetsiaalne teenus-WM Cisco HyperFlex Data Platform controller, mis luuakse igas salvestusnode'is. Meie konfiguratsioonis on teenus-WM-le eraldatud kaheksa vCPU-d ja 72 GB RAM-i, mis ei ole sugugi vähe. Tuletan meelde, et hostil on 28 füüsilist südamikku ja 512 GB RAM-i.
Teenuse-WM-ile on otse füüsilistele kettale juurdepääs SAS-kontrolleri edastamise kaudu WM-is. Suhtlemine hüperviisoriga toimub spetsiaalse IOVisor mooduli kaudu, mis püüab kinni sisendi-väljundi toimingud, ja agendi abil, mis võimaldab anda käske hüperviisori API-le. Agent on vastutav HyperFlex-i snapshotide ja kloonide haldamise eest.
Hüperviisorisse on diskiresursid monteeritud kui NFS- või SMB-jagamised (sõltub hüperviisori tüübist, proovige ära arvata, mis kus). Aga selle all on jaotatud failisüsteem, mis võimaldab lisada täiendavaid funktsioone täiskasvanute tõsistele salvestussüsteemidele: peene mahu eraldumise, pigistamise ja deduplikatsiooni, Redirect-on-Write tehnoloogia põhiseid snapshots, sünkroonset/ asünkroonset replikatsiooni.
Teenuse-WM pakub juurdepääsu HyperFlex süsteemi haldamise veebiliidesele. On olemas integreerimine vCenter'iga, ja enamus igapäevaseid ülesandeid saab sealt täita, kuid datastooride jagamist on mugavam teha eraldi veebiliidesest, kui olete juba kiirele HTML5- liidesele üle läinud, või kasutada täieõiguslikku Flash-klienti täie integreerimisega. Teenuse veebiliideses on võimalik vaadata süsteemi jõudlust ja täpset staatust.
Klastris on olemas ka teine tüüp node'id - arvutusnode'id. Need võivad olla 19. või blade-serverid ilma sisseehitatud kettaideta. Nendel serveritel saab käitada WM-e, mille andmed on salvestatud ketastega serverites. Andmetele juurdepääsu osas pole tüüpide vahel mingit erinevust, kuna arhitektuur eeldab andmete füüsilisest asukohast abstraktsiooni. Arvutusnode'ide ja salvestusnode'ide maksimaalne suhe on 2:1.
Arvutusnode'ide kasutamine suurendab klassiressursside skaleerimise paindlikkust: me ei pea tingimata ostma ketastega node'e, kui meie vajadus on ainult CPU/RAM. Lisaks saame lisada blade-korvi ja saavutada kokkuhoidu serverite paigutamisel riiulis.
Kokkuvõttes on meil hüperkonvergeeritud platvorm järgmiste funktsioonidega:
- Klasstris, kus on kuni 64 sõlme (kuni 32 salvestussõlme).
- Klasstri minimaalne sõlmede arv on kolm (kaks – Edge-klasstri jaoks).
- Andmete ülejääkide mehhanism: peegeldamine replikatsiooni faktoriga 2 ja 3.
- Metro-klasstri.
- Asünkroonne VM replikatsioon teisele HyperFlex-klasstrile.
- VM-i ülekande orkestreerimine kauguses asuvasse andmekeskusesse.
- Kohalikud jäädvustused Redirect-on-Write tehnoloogia alusel.
- Kuni 1 PB kasulikku ruumi replikatsiooni faktoriga 3 ja ilma dedupikatsioonita. Replikatsiooni faktor 2 ei ole arvestatud, kuna see ei ole tõsiste müükide jaoks sobiv variant.
Veel üks suur pluss on haldamise ja seadistamise lihtsus. Kõik UCS-serverite seadistamise keerukused lahendab spetsialiseeritud VM, mille on ette valmistanud Cisco insenerid.
Testseina konfiguratsioon:
- 2 x Cisco UCS Fabric Interconnect 6248UP juht- ja võrgukomponentide jaoks (48 porti, töötades 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
UCSC-MLOM-CSC-02 (VIC 1227). 2 porti 10G Ethernet
Salvestuse HBA
Cisco 12G Modular SAS Pass through Controller
Salvestusketta
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Rohkem konfiguratsiooni valikuidValitud riistvara kõrval on praegu 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.
- 6–23 andmeketast, üks vahemälu ketas, üks süsteemi ja üks käivituskettas.
Kapasiteedi ketaste
- HX-SD960G61X-EV 960GB 2,5 tolli ettevõtte väärtus 6G SATA SSD (1X vastupidavus) SAS 960 GB.
- HX-SD38T61X-EV 3.8TB 2,5 tolli ettevõtte väärtus 6G SATA SSD (1X vastupidavus) SAS 3.8 TB.
- Vahemälu kettad
- HX-NVMEXPB-I375 375GB 2,5 tolli Intel Optane Drive, äärmine jõudlus ja vastupidavus.
- HX-NVMEHW-H1600* 1,6TB 2,5 tolli ettevõtte jõudluse NVMe SSD (3X vastupidavus) NVMe 1,6 TB.
- HX-SD400G12TX-EP 400GB 2,5 tolli ettevõtte jõudlus 12G SAS SSD (10X vastupidavus) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2,5 tolli ettevõtte jõudlus 12G SAS SED SSD (10X vastupidavus) SAS 800 GB.
- HX-SD16T123X-EP 1,6TB 2,5 tolli ettevõtte jõudluse 12G SAS SSD (3X vastupidavus).
Süsteemi/Logi kettad
- HX-SD240GM1X-EV 240GB 2,5 tolli ettevõtte väärtus 6G SATA SSD (nõuab värskendamist).
Käivituskettad
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Ühendamine võrguga 40G, 25G või 10G Etherneti portide kaudu.
FI-na võivad olla HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Test
Diskialumise testimiseks kasutasin HCIBench 2.2.1. See on tasuta utiliit, mis võimaldab automatiseerida koormate loomist mitmest virtuaalsest masina. Koormus genereeritakse tavalise fio kaudu.
Meie klasster koosneb neljast sõlmest, replikatsiooni faktor 3, kõik kettad on Flash.
Testimiseks lõin ma neli andmestikku ja kaheksa virtuaalset masinat. Kirjutamiseks testimise korral on planeeritud variant, kus vahemälu ketas ei täitu.
Testitulemused on järgmised:
100 % Lugemine 100 % Juhuslik
0 % Lugemine 100% Juhuslik
Blokk / 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
Raske kirjete paksus, pärast mida jõudlus ei parane, isegi võib näha halvenemist. See on seotud sellega, et me jõuame võrgu / kontrollide / ketaste jõudlusse.
- Jõudlus lugemise järjekorras 4432 MB/s.
- Jõudlus kirjutamise järjekorras 804 MB/s.
- Ühe kontrolli (virtuaalmasina või hosti) ebaõnnestumise korral on jõudluse langus kaks korda.
- Andmete ketta ebaõnnestumise korral on langus kolmandik. Ketaste uuendamine kasutab iga kontrolli 5% ressursse.
Väikese ploki puhul jõuame kontrolli jõudlusse (virtuaalmasin), selle CPU on 100% koormatud, ploki suurendamisel jõuame portide läbilaskevõime piiril. 10 Gb/s ei ole piisav AllFlash-süsteemi potentsiaali avamiseks. Kahjuks ei luba antud demostendi parameetrid 40 Gb/s testimist.
Minu muljete põhjal testide ja arhitektuuri uurimise põhjal, andmete algoritmi tõttu, mis jaotab andmeid kõigi hostide vahel, saavutame skaleeritava ja ettearvatava jõudluse, kuid see on piirang lugemisel, kuna kohalikelt ketastelt võiksime pigistada rohkem, siin võib aidata võimekam võrk, näiteks on saadaval FI 40 Gb/s.
Samuti võib üks ketas vahemällu ja de-deduplikatsiooni olla piirang, tegelikult saame antud stendil kirjutada neljale SSD-kettale. Oleks suurepärane, kui saaksime suurendada vahemälu ketaste arvu ja näha vahet.
Tõeline kasutus
Kaugandmete keskust võib korraldada kahe lähenemisviisi abil (ei arvestata varukoopiat eemal asuval alal):
- Aktiv-Passiivne. Kõik rakendused on paigutatud peamisse andmekeskusesse. Replikatsioon on sünkroonne või asünkroonne. Peamise andmekeskuse (AC) rikke korral tuleb aktiveerida varuplaan. Selle saab teha käsitsi / skriptide / orkestreerimise rakendustega. Siin saavutame RPO, mis vastab replikatsiooni sagedusele, ja RTO sõltub administraatori reaktsioonist ja oskustest ning plaani väljatöötamise / testimise kvaliteedist.
- Aktiv-Aktivne. Sellisel juhul on olemas ainult sünkroonne replikatsioon, andmekeskuste kättesaadavus määratakse kvoorumi / arbiteri kaudu, mis on rangelt paigutatud kolmandasse kohta. RPO = 0, samas kui RTO võib ulatuda 0 (kui rakendus seda võimaldab) või olla võrreldav virtuaalserveri rikke säästmise ajaga. Virtuaalserveri tasemel luuakse laiendatud (Metro) klaster, mis nõuab Aktiiv-Aktivne salvestusi.
Tavaliselt näeme klientidel juba teostatud arhitektuuri klassikalise salvestuse (SDS) puhul peamises andmekeskuses, seega projekteerime veel ühe replikatsiooni jaoks. Nagu ma mainisin, pakub Cisco HyperFlex asünkroonset replikatsiooni ja laiendatud virtuaalklastri loomist. Sel juhul ei ole meil vaja spetsiaalset Midrange taseme salvestust ja kõrgemat varianti, mis sisaldaks kalliseid replikatsiooni funktsioone ja Aktiiv-Aktivse andmete juurdepääsu kahel salvestusel.
Stsenaarium 1: Meil on peamine ja varu andmekeskus, virtuaalserveri platvorm VMware vSphere'il. Kõik tootmissüsteemid on paigutatud peamisse andmekeskusesse, samas kui virtuaalmasinate replikatsioon toimub hüperviisori tasemel, mis võimaldab mitte hoida VM-e sisse lülitatuna varu andmekeskuses. Andmebaasid ja spetsiaalsed rakendused replitseerime sisseehitatud tööriistade kaudu ja hoiame VM-e sisse lülitatuna. Peamise andmekeskuse tõrgete korral запускаем süsteemid varu andmekeskuses. Arvutame, et meil on umbes 100 virtuaalmasinat. Kuni peamine andmekeskus on aktiivne, saab varu andmekeskuses käivitada testkeskkondi ja muid süsteeme, mida saab välja lülitada peamise andmekeskuse vahetuse korral. Samuti on võimalik variant, kus kasutame kahepoolset replikatsiooni. Riistvara poolest ei muutu miski.
Klassikalise arhitektuuri korral paigaldame igasse andmekeskusse hübriidse salvestussüsteemi, millel on juurdepääs FibreChanneli kaudu, tieringu, dedupeerimise ja kompressiooniga (kuid mitte reaalajas), 8 serverit igas asukohas, 2 FibreChanneli ja Ethernet 10G lülitit. Repikeerimise ja klassikalise arhitektuuri haldamiseks saame kasutada VMware vahendeid (Replication + SRM) või alternatiivseid abinõusid, mis võivad olla veidi odavamad ja mõnikord mugavamad.
Joonisel on esitatud skeem.
Cisco HyperFlexi kasutamise korral on arhitektuur järgmine:
HyperFlexi jaoks kasutasin kõrgete ressurssidega servereid CPU/RAM, kuna osa ressursse läheb HyperFlexi juhtimis-VM-ile. CPU ja mälu osas isegi ületasin veidi HyperFlexi konfiguratsiooni, et mitte Ciscoga leppida ja tagada ressursid teistele VM-ile. Seega saame FibreChanneli lülititest loobuda ja meil ei ole vaja Etherneti porte iga serveri jaoks, kohalik liiklus suunatakse FI sees.
Saime sellise konfiguratsiooni iga andmekeskuse 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)
Salvestusseadmed
Hübriidne salvestussüsteem FC Front-Endiga (20TB SSD, 130 TB NL-SAS)
—
LAN
2 x Etherneti lülitit 10G 12 ports
—
SAN
2 x FC lülitit 32/16Gb 24 ports
2 x Cisco UCS FI 6332
Litsentsid
VMware Ent Plus
Repikeerimine ja/või VM-ide vahetuse orkestreerimine
VMware Ent Plus
HyperFlexi puhul ei arvestanud tarkvaralitsentse repikeerimise jaoks, kuna see on meil saadaval välja pakutuna.
Klassikalise arhitektuuri jaoks valisin tarnija, kellel on tõestatud kvaliteet ja madalad hinnad. Mõlema variandi puhul kasutasin konkreetse lahenduse tavapärast allahindlust, mille tulemuseks olid reaalsed hinnad.
Cisco HyperFlexi lahendus osutus 13% odavamaks.
Stsenaarium 2: kaks aktiivset andmekeskust. Selles stsenaariumis projekteerime ulatunud klastrit VMware'i peal.
Klassikaline arhitektuur koosneb virtualiseerimise serveritest, SAN-ist (FC-protokoll) ja kahest salvestussüsteemist, mis oskavad lugeda ja kirjutada andmeid, mis on nende vahel laiali toodud. Iga salvestussüsteemi jaoks paigutame kasuliku mahtunud salvestusruumi.
HyperFlexis saame lihtsalt luua Stretch Clusteri, millel on mõlemas asukohas sama palju sõlmi. 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)
Salvestusseadmed
2 x AllFlash salvestussüsteemi (150 TB SSD)
—
LAN
4 x Etherneti lülitit 10G 24 ports
—
SAN
4 x FC lülitit 32/16Gb 24 ports
4 x Cisco UCS FI 6332
Litsentsid
VMware Ent Plus
VMware Ent Plus
Kõikides arvutustes ei arvestanud ma võrgu infrastruktuuri, andmekeskuste kulusid jne: need on klassikalise arhitektuuri ja HyperFlex lahenduse puhul samad.
Hinnalt osutus HyperFlex 5% kallimaks. Siin on oluline märkida, et CPU/RAM ressursside osas oli mul Cisco puhul ebasoodne olukord, kuna täitsin mälu kontrollerite kanalid ühtlaselt. Hind on veidi kõrgem, kuid mitte tõeliselt palju, mis selgelt näitab, et hüperkonvergents ei ole tingimata "rikaste mänguasi", vaid võib konkureerida standardse lähenemisega andmekeskuse ehitusele. Samuti võib see huvi pakkuda neile, kellel juba on Cisco UCS serverid ja vastav infrastruktuur.
Eeliste hulka kuulub SAN ja andmemassiivide haldamise kulude puudumine, reaalajas kompressioon ja dedupeerimine, üksik sisenemispunkt toetuseks (virtualiseerimine, serverid, samuti – andmemassiivid), ruumi kokkuhoid (kuid mitte kõigis stsenaariumites), hoolduse lihtsustamine.
Mis puutub toetusesse, siis siin saate seda ühelt pakkujalt – Cisco. Kui tugineda oma kogemusele Cisco UCS serveritega, siis mulle see meeldib, HyperFlexi avamine ei olnud vajalik, kõik töötas niigi. Insenerid vastavad kiiresti ja suudavad lahendada mitte ainult tüüpilisi probleeme, vaid ka keerulisi piire. Mõnikord küsin neilt: „Kas on võimalik teha nii, kinnitada see?” või „Ma siin konfigureerisin midagi ja see ei taha töötada. Aita!” – nad leiavad kannatlikult õige juhendi ja osutavad õigetele toimingutele, nad ei ütle: „Lahendame vaid riistvaraprobleeme”.
Viidatud lingid
- Minu e-post on StGeneralov@croc.ru
Allikas: habr.com
