Questu hè un mitu chì hè abbastanza cumuni in u campu di u hardware di u servitore. In pratica, i suluzioni hyperconverged (quandu tuttu hè in unu) sò necessarii per parechje cose. Stòricamente, i primi architetture sò stati sviluppati da Amazon è Google per i so servizii. Allora l'idea era di fà una splutazioni di computing da i nodi idèntici, chì ognunu avia u so propiu discu. Tuttu chistu era unitu da qualchì software di furmazione di sistema (hypervisor) è era divisu in macchine virtuali. L'obiettivu principale hè un minimu sforzu per u serviziu di un node è un minimu di prublemi quandu scaling: solu cumprà un altru milla o dui di i stessi servitori è cunnette vi vicinu. In pratica, questi sò casi isolati, è assai più spessu parlemu di un numeru più chjucu di nodi è una architettura ligeramente diversa.
Ma u plus resta u listessu - facilità incredibile di scala è gestione. U svantaghju hè chì e diverse attività consumanu risorse in modu diversu, è in certi lochi ci saranu assai dischi lucali, in altri ci sarà pocu RAM, è cusì, vale à dì, per diversi tipi di compiti, l'utilizazione di risorse diminuite.
Risulta chì paghe 10-15% più per facilità di setup. Hè ciò chì hà suscitatu u mitu in u titulu. Avemu passatu assai tempu à circà induve a tecnulugia seria applicata in modu ottimale, è l'avemu trovu. U fattu hè chì Cisco ùn hà micca u so propiu sistema di almacenamiento, ma vulianu un mercatu di servitore cumpletu. E anu fattu Cisco Hyperflex - una suluzione cù almacenamiento locale nantu à i nodi.
È questu di colpu hè diventatu una soluzione assai bona per i centri di dati di salvezza (Recuperazione di Disaster). Vi dicu perchè è cumu avà. È vi mustraraghju i testi di cluster.
Induve bisognu
L'iperconvergenza hè:
- Trasferimentu di discu à i nodi di calculu.
- Integrazione cumpleta di u sottosistema di almacenamiento cù u sottosistema di virtualizazione.
- Trasferimentu / integrazione cù u sottosistema di a reta.
Questa cumminazione permette di implementà parechje funziunalità di u sistema di almacenamentu à u livellu di virtualizazione è tuttu da una finestra di cuntrollu.
In a nostra cumpagnia, i prughjetti di cuncepimentu di centri di dati redundante sò in grande dumanda, è una suluzione iperconvergente hè spessu scelta per una mansa di opzioni di replicazione (finu à un metrocluster) fora di a scatula.
In u casu di centri di dati di salvezza, di solitu parlemu di una facilità remota in un situ à l'altra parte di a cità o in una altra cità in tuttu. Permette di restaurà i sistemi critichi in casu di fallimentu parziale o cumpletu di u centru di dati principale. I dati di vendita sò constantemente replicati quì, è sta replicazione pò esse à u livellu di l'applicazione o à u livellu di u dispositivu di bloccu (almacenamiento).
Dunque, avà parraraghju di u disignu di u sistema è di e teste, è dopu un coppiu di scenarii d'applicazione in a vita reale cù dati di risparmiu.
Testi
A nostra istanza hè custituita da quattru servitori, ognunu di i quali hà 10 unità SSD di 960 GB. Ci hè un discu dedicatu per caching operazioni di scrittura è almacenà a macchina virtuale di serviziu. A suluzione stessu hè a quarta versione. U primu hè francamente crudu (a ghjudicà da e recensioni), u sicondu hè umitu, u terzu hè digià abbastanza stabile, è questu pò esse chjamatu liberazione dopu a fine di a prova beta per u publicu generale. Durante a prova ùn aghju micca vistu prublemi, tuttu funziona cum'è un clock.
Cambiamenti in v4Una mansa di bug sò stati risolti.
Inizialmente, a piattaforma puderia travaglià solu cù l'ipervisore VMware ESXi è supportava un picculu numeru di nodi. Inoltre, u prucessu di implementazione ùn hè micca sempre finitu bè, alcuni passi anu da esse riavviatu, ci sò stati prublemi cù l'aghjurnamentu di e versioni più vechje, i dati in a GUI ùn sò micca sempre visualizati currettamente (ancu se ùn sò micca sempre cuntentu di a visualizazione di i grafici di rendiment. ), qualchì volta i prublemi sò ghjunti à l'interfaccia cù a virtualizazione.
Avà tutti i prublemi di a zitiddina sò stati risolti, HyperFlex pò trattà sia ESXi sia Hyper-V, in più hè pussibule:
- Crià un cluster allungatu.
- Crià un cluster per l'uffizii senza aduprà Fabric Interconnect, da dui à quattru nodi (compramu solu servitori).
- Capacità di travaglià cù sistemi di almacenamiento esterni.
- Supportu per i containers è Kubernetes.
- Creazione di zoni di dispunibilità.
- Integrazione cù VMware SRM se a funziunalità integrata ùn hè micca satisfacente.
L'architettura ùn hè micca assai sfarente di e soluzioni di i so principali cuncurrenti, ùn anu micca creatu una bicicletta. Tuttu funziona nantu à a piattaforma di virtualizazione VMware o Hyper-V. L'hardware hè allughjatu nantu à i servitori proprietari Cisco UCS. Ci sò quelli chì odianu a piattaforma per a cumplessità relativa di a cunfigurazione iniziale, assai buttoni, un sistema micca triviale di mudelli è dipendenze, ma ci sò ancu quelli chì anu amparatu Zen, sò inspirati da l'idea è ùn volenu più. per travaglià cù altri servitori.
Cunsidereremu a suluzione per VMware, postu chì a suluzione hè stata creata originariamente per questu è hà più funziunalità; Hyper-V hè statu aghjuntu à a strada per mantene a cuncurrenza cù i cuncurrenti è risponde à l'aspettattivi di u mercatu.
Ci hè un cluster di servitori pienu di dischi. Ci sò dischi per l'almacenamiento di dati (SSD o HDD - secondu u vostru gustu è bisogni), ci hè un discu SSD per caching. Quandu scrivite dati à u datastore, i dati sò salvati nantu à a capa di caching (discu SSD dedicatu è RAM di u serviziu VM). In parallelu, un bloccu di dati hè mandatu à i nodi in u cluster (u numaru di nodi dipende da u fattore di replicazione di cluster). Dopu a cunferma di tutti i nodi nantu à a registrazione successu, a cunferma di a registrazione hè mandata à l'ipervisore è dopu à a VM. I dati arregistrati sò deduplicati, cumpressi è scritti à i dischi di almacenamiento in fondo. À u listessu tempu, un grande blocu hè sempre scrittu à i dischi di almacenamiento è sequentially, chì reduce a carica nantu à i dischi di almacenamiento.
A deduplicazione è a cumpressione sò sempre attivate è ùn ponu micca esse disattivate. I dati sò letti direttamente da i dischi di almacenamiento o da a cache RAM. Se una cunfigurazione hibrida hè aduprata, e letture sò ancu in cache in u SSD.
I dati ùn sò micca ligati à u locu attuale di a macchina virtuale è sò distribuiti uniformemente trà i nodi. Stu approcciu permette di carricà tutti i dischi è l'interfaccia di a rete ugualmente. Ci hè un svantaghju evidenti: ùn pudemu micca riduce a latenza di lettura quant'è pussibule, postu chì ùn ci hè micca garanzia di dispunibilità di dati in u locu. Ma crede chì questu hè un sacrifiziu minore cumparatu cù i benefici ricevuti. Inoltre, i ritardi di a rete anu righjuntu tali valori chì praticamente ùn affettanu micca u risultatu generale.
Un serviziu speciale VM Cisco HyperFlex Data Platform controller, chì hè creatu nantu à ogni node di almacenamiento, hè rispunsevule per tutta a logica di operazione di u sottosistema di discu. In u nostru serviziu di cunfigurazione VM, ottu vCPU è 72 GB di RAM sò stati attribuiti, chì ùn hè micca cusì pocu. Lasciami ricurdà chì l'ospitu stessu hà 28 core fisichi è 512 GB di RAM.
U serviziu VM hà accessu à i dischi fisichi direttamente trasmettendu u controller SAS à a VM. A cumunicazione cù l'ipervisore si faci per un modulu speciale IOVisor, chì intercepte l'operazioni I/O, è utilizendu un agentu chì permette di mandà cumandamenti à l'API di l'ipervisore. L'agente hè rispunsevule per travaglià cù snapshots è cloni HyperFlex.
I risorsi di discu sò muntati in l'ipervisore cum'è azzioni NFS o SMB (secondu u tipu d'ipervisore, indovinà quale hè induve). È sottu u cappucciu, questu hè un sistema di fugliale distribuitu chì permette di aghjunghje funzioni di sistemi di almacenamentu cumpletu per adulti: allocazione di volumi sottili, compressione è deduplicazione, snapshots cù a tecnulugia Redirect-on-Write, replicazione sincrona / asincrona.
U serviziu VM furnisce l'accessu à l'interfaccia di gestione WEB di u subsistema HyperFlex. Ci hè integrazione cù vCenter, è a maiò parte di i travaglii di ogni ghjornu ponu esse realizati da ellu, ma i datastores, per esempiu, sò più convenienti per cutà da una webcam separata se avete digià cambiatu à una interfaccia HTML5 veloce, o utilizate un cliente Flash cumpletu. cun piena integrazione. In a webcam di serviziu pudete vede u rendiment è u statutu detallatu di u sistema.
Ci hè un altru tipu di node in un cluster - nodi di computing. Questi ponu esse servitori rack o blade senza dischi integrati. Questi servitori ponu eseguisce VMs chì i dati sò almacenati in servitori cù discu. Da u puntu di vista di l'accessu di dati, ùn ci hè micca una diferenza trà i tipi di nodi, perchè l'architettura implica l'astrazione da u locu fisicu di e dati. U rapportu massimu di i nodi di computing à i nodi di almacenamiento hè 2: 1.
L'usu di i nodi di compute aumenta a flessibilità quandu si scala e risorse di cluster: ùn avemu micca bisognu di cumprà nodi supplementari cù dischi si avemu solu bisognu di CPU / RAM. Inoltre, pudemu aghjunghje una gabbia di lama è salvà nantu à a piazza di rack di i servitori.
In u risultatu, avemu una piattaforma iperconvergente cù e seguenti caratteristiche:
- Finu à 64 nodi in un cluster (finu à 32 nodi di almacenamiento).
- U numeru minimu di nodi in un cluster hè trè (dui per un cluster Edge).
- Meccanismo di ridondanza di dati: mirroring cù fattore di replicazione 2 è 3.
- cluster Metro.
- Replicazione VM asincrona à un altru cluster HyperFlex.
- Orchestrazione di cambià VM à un centru di dati remoto.
- Snapshots nativi chì utilizanu a tecnulugia Redirect-on-Write.
- Finu à 1 PB di spaziu utilizable à u fattore di replicazione 3 è senza deduplicazione. Ùn avemu micca cunsideratu u fattore di replicazione 2, perchè questu ùn hè micca una opzione per a vendita seria.
Un altru grande plus hè a facilità di gestione è implementazione. Tutte e cumplessità di stallà i servitori UCS sò curati da una VM specializata preparata da ingegneri Cisco.
Cunfigurazione di u bancu di prova:
- 2 x Cisco UCS Fabric Interconnect 6248UP cum'è cluster di gestione è cumpunenti di rete (48 porti chì operanu in modalità Ethernet 10G/FC 16G).
- Quattru servitori Cisco UCS HXAF240 M4.
Caratteristiche di u servitore:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
Network
UCSC-MLOM-CSC-02 (VIC 1227). 2 porti Ethernet 10G
Storage HBA
Cisco 12G Modular SAS Pass through Controller
Dischi di almacenamiento
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Più opzioni di cunfigurazioneIn più di u hardware sceltu, e seguenti opzioni sò attualmente dispunibili:
- HXAF240c M5.
- Una o duie CPU chì varienu da Intel Silver 4110 à Intel Platinum I8260Y. A seconda generazione dispunibule.
- 24 slot di memoria, strisce da 16 GB RDIMM 2600 à 128 GB LRDIMM 2933.
- Da 6 à 23 dischi di dati, un discu di cache, un discu di sistema è un discu di boot.
Unità di capacità
- HX-SD960G61X-EV 960 GB 2.5 pollici Enterprise Value 6G SATA SSD (1X endurance) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 inch Enterprise Value 6G SATA SSD (1X endurance) SAS 3.8 TB.
- Caching Drives
- HX-NVMEXPB-I375 375GB 2.5 inch Intel Optane Drive, Extreme Perf & Endurance.
- HX-NVMEHW-H1600* 1.6TB 2.5 inch Ent. Perf. NVMe SSD (3X endurance) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 inch Ent. Perf. 12G SAS SSD (10X endurance) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 inch Ent. Perf. 12G SAS SED SSD (10X endurance) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 inch Performance Enterprise 12G SAS SSD (3X endurance).
Unità di sistema / log
- HX-SD240GM1X-EV 240GB 2.5 inch Enterprise Value 6G SATA SSD (necessita l'aghjurnamentu).
Boot Drives
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB.
Cunnette à a reta via i porti Ethernet 40G, 25G o 10G.
U FI pò esse HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
A prova stessu
Per pruvà u sottosistema di discu, aghju utilizatu HCIBench 2.2.1. Questa hè una utilità gratuita chì permette di automatizà a creazione di una carica da parechje macchine virtuali. A carica stessa hè generata da u fio di solitu.
U nostru cluster hè custituitu di quattru nodi, fattore di replicazione 3, tutti i dischi sò Flash.
Per pruvà, aghju creatu quattru datastores è ottu macchine virtuali. Per i testi di scrittura, si assume chì u discu di cache ùn hè micca pienu.
I risultati di a prova sò i seguenti:
100% Lettu 100% Casuale
0% Lettu 100% Aleatoriu
Prufundità di bloccu / fila
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
Bold indica i valori dopu chì ùn ci hè micca un aumentu di a produtividade, qualchì volta ancu a degradazione hè visibile. Questu hè duvuta à u fattu chì simu limitati da u rendiment di a rete / cuntrolli / dischi.
- Lettura sequenziale 4432 MB/s.
- Scrittura sequenziale 804 MB/s.
- Se un controller falla (fallimentu di una macchina virtuale o host), a calata di rendiment hè doppia.
- Se u discu di almacenamiento falla, u drawdown hè 1/3. A ricustruzione di u discu pigghia 5% di e risorse di ogni controller.
Nant'à un picculu bloccu, simu limitati da u rendiment di u controller (macchina virtuale), u so CPU hè carricu à 100%, è quandu u bloccu aumenta, simu limitati da a larghezza di banda di u portu. 10 Gbps ùn hè micca abbastanza per sbloccà u putenziale di u sistema AllFlash. Sfortunatamente, i paràmetri di u stand demo furnitu ùn ci permettenu micca di pruvà l'operazione à 40 Gbit/s.
In a mo impressione da e teste è studià l'architettura, per via di l'algoritmu chì mette e dati trà tutti l'ospiti, avemu un rendimentu scalabile, prevedibile, ma questu hè ancu una limitazione quandu leghje, perchè saria pussibule di strincà più da i dischi lucali, quì pò salvà una reta più pruduttiva, per esempiu, FI à 40 Gbit / s hè dispunibule.
Inoltre, un discu per caching è deduplicazione pò esse una limitazione; in fattu, in questu testbed pudemu scrive à quattru dischi SSD. Saria bellu di pudè aumentà u nùmeru di caching drives è vede a diferenza.
U veru usu
Per urganizà un centru di dati di salvezza, pudete aduprà dui approcci (ùn cunsideremu micca di mette una copia di salvezza in un situ remoto):
- Active-Passive. Tutte l'applicazioni sò ospitate in u centru di dati principale. A replicazione hè sincrona o asincrona. Sè u centru di dati principali fiasca, avemu bisognu di attivà a copia di salvezza. Questu pò esse fattu manualmente / scripts / applicazioni d'orchestrazione. Quì avemu da ottene un RPO proporzionale à a frequenza di replicazione, è a RTO dipende da a reazione è e cumpetenze di l'amministratore è a qualità di sviluppu / debugging di u pianu di cambiamentu.
- Active-Active. In questu casu, ci hè solu replicazione sincrona; a dispunibilità di i centri di dati hè determinata da un quorum / arbitro situatu strettamente in u terzu situ. RPO = 0, è RTO pò ghjunghje à 0 (se l'applicazione permette) o uguali à u tempu di failover di un node in un cluster di virtualizazione. À u nivellu di virtualizazione, un cluster allungatu (Metro) hè creatu chì necessita un almacenamiento Active-Active.
Di solitu vedemu chì i clienti anu digià implementatu una architettura cù un sistema di almacenamiento classicu in u centru di dati principale, cusì cuncepemu un altru per a replicazione. Cumu l'aghju dettu, Cisco HyperFlex offre replicazione asincrona è creazione di cluster di virtualizazione allungata. À u listessu tempu, ùn avemu micca bisognu di un sistema di almacenamiento dedicatu di u livellu Midrange è più altu cù funzioni di replicazione caru è accessu di dati Active-Active nantu à dui sistemi di almacenamiento.
Scenariu 1: Avemu un centru di dati primariu è di salvezza, una piattaforma di virtualizazione in VMware vSphere. Tutti i sistemi pruduttivi sò situati in u centru di dati principale, è a replicazione di e macchine virtuali hè realizatu à u livellu di l'ipervisore, questu evitarà di mantene e VM attivate in u centru di dati di salvezza. Replichemu e basa di dati è l'applicazioni speciali utilizendu strumenti integrati è mantenemu i VM attivati. Se u centru di dati principale falla, lanciamu sistemi in u centru di dati di salvezza. Cridemu chì avemu circa 100 macchine virtuali. Mentre u centru di dati primariu hè operativu, u centru di dati in standby pò eseguisce ambienti di prova è altri sistemi chì ponu esse chjusi se u centru di dati primariu cambia. Hè ancu pussibule chì usemu a replicazione bidirezionale. Da un puntu di vista hardware, nunda ùn cambierà.
In u casu di l'architettura classica, installemu in ogni centru di dati un sistema di almacenamentu hibridu cù accessu via FibreChannel, tiering, deduplicazione è cumpressione (ma micca in linea), 8 servitori per ogni situ, 2 switches FibreChannel è 10G Ethernet. Per a gestione di a replicazione è di u cambiamentu in una architettura classica, pudemu usà strumenti VMware (Replication + SRM) o strumenti di terzu, chì saranu un pocu più prezzu è à volte più convenientu.
A figura mostra u schema.
Quandu si usa Cisco HyperFlex, l'architettura seguente hè ottenuta:
Per HyperFlex, aghju utilizatu servitori cù grandi risorse CPU / RAM, perchè ... Alcune di e risorse andaranu à a VM di u controller HyperFlex; in quantu à CPU è memoria, aghju ancu cunfiguratu un pocu a cunfigurazione HyperFlex per ùn ghjucà cù Cisco è guarantisci risorse per i VM restantes. Ma pudemu abbandunà i switches FibreChannel, è ùn avemu micca bisognu di porti Ethernet per ogni servitore; u trafficu lucale hè cambiatu in FI.
U risultatu hè a seguente cunfigurazione per ogni centru di dati:
I servitori
8 x 1U Server (384 GB di RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB di RAM, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
SHD
Sistema di almacenamiento ibridu cù FC Front-End (20TB SSD, 130TB NL-SAS)
-
AVIANCA
2 x Switch Ethernet 10G 12 porti
-
SAN
2 x FC switch 32/16Gb 24 porti
2 x Cisco UCS FI 6332
Licenze
VMware Ent Plus
Replicazione è/o orchestrazione di u cambiamentu di VM
VMware Ent Plus
Ùn aghju micca furnitu licenze di software di replicazione per Hyperflex, postu chì questu hè dispunibule fora di a scatula per noi.
Per l'architettura classica, aghju sceltu un venditore chì s'hè stabilitu cum'è un fabricatore d'alta qualità è prezzu. Per e duie opzioni, aghju applicatu u scontu standard per una suluzione specifica, è in u risultatu aghju ricevutu prezzi veri.
A suluzione Cisco HyperFlex hè stata 13% più prezzu.
Scenariu 2: creazione di dui centri dati attivi. In questu scenariu, cuncepemu un cluster allungatu nantu à VMware.
L'architettura classica hè custituita da servitori di virtualizazione, un SAN (protokollu FC) è dui sistemi di almacenamento chì ponu leghje è scrive à u voluminu stesu trà elli. In ogni sistema di almacenamentu mettemu una capacità utile per u almacenamentu.
In HyperFlex creemu simpricimenti un Stretch Cluster cù u listessu numeru di nodi in i dui siti. In questu casu, un fattore di replicazione di 2 + 2 hè utilizatu.
U risultatu hè a seguente cunfigurazione:
architettura classica
HyperFlex
I servitori
16 x 1U Server (384 GB di RAM, 2 x Intel Gold 6132, FC HBA, 2 x NIC 10G)
16 x HX240C-M5L (512 GB di RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
SHD
2 x Sistemi di almacenamiento AllFlash (150 TB SSD)
-
AVIANCA
4 x Switch Ethernet 10G 24 porti
-
SAN
4 x FC switch 32/16Gb 24 porti
4 x Cisco UCS FI 6332
Licenze
VMware Ent Plus
VMware Ent Plus
In tutti i calculi, ùn aghju micca cunsideratu l'infrastruttura di rete, i costi di u centru di dati, etc.: seranu listessi per l'architettura classica è per a suluzione HyperFlex.
In quantu à u costu, HyperFlex hè diventatu 5% più caru. Hè da nutà quì chì in termini di risorse CPU / RAM aghju avutu un skew per Cisco, perchè in a cunfigurazione aghju pienu i canali di u controller di memoria in modu uniforme. U costu hè ligeramente più altu, ma micca per un ordine di grandezza, chì indica chjaramente chì l'iperconvergenza ùn hè micca necessariamente un "ghjocu per i ricchi", ma pò cumpete cù l'approcciu standard per custruisce un centru di dati. Questu pò ancu esse d'interessu per quelli chì anu digià servitori Cisco UCS è l'infrastruttura currispondente per elli.
Trà i vantaghji, avemu l'absenza di costi per l'amministrazione di SAN è sistemi di almacenamento, compressione è deduplicazione in linea, un puntu d'entrata unicu per u supportu (virtualizazione, servitori, sò ancu sistemi di almacenamento), risparmià spaziu (ma micca in tutti i scenarii), simplificà u funziunamentu.
In quantu à u supportu, quì l'avete da un venditore - Cisco. A ghjudicà da a mo sperienza cù i servitori Cisco UCS, mi piace; Ùn aghju micca bisognu di apre in HyperFlex, tuttu hà travagliatu u listessu. L'ingegneri rispundenu prestu è ponu risolve micca solu i prublemi tipici, ma ancu i casi cumplessi. Calchì volta mi turnu à elli cù e dumande: "Hè pussibule di fà questu, vittite?" o "Aghju cunfiguratu qualcosa quì, è ùn vole micca travaglià. Aiutu!" - Pacienza trovanu a guida necessaria è indicà l'azzioni curretta; ùn risponderanu micca: "Risolvemu solu i prublemi di hardware".
referenze
- U mo mail - [email prutettu]
Source: www.habr.com