Dit is een mythe die vrij vaak voorkomt op het gebied van serverhardware. In de praktijk zijn voor veel zaken hypergeconvergeerde oplossingen (als alles in één zit) nodig. Historisch gezien werden de eerste architecturen ontwikkeld door Amazon en Google voor hun diensten. Toen was het idee om een computerpark te maken van identieke knooppunten, die elk hun eigen schijven hadden. Dit alles werd verenigd door een aantal systeemvormende software (hypervisor) en verdeeld in virtuele machines. Het hoofddoel is een minimale inspanning voor het onderhoud van één knooppunt en een minimum aan problemen bij het opschalen: koop gewoon nog eens duizend of twee van dezelfde servers en sluit ze in de buurt aan. In de praktijk zijn dit geïsoleerde gevallen, en veel vaker hebben we het over een kleiner aantal knooppunten en een iets andere architectuur.
Maar het pluspunt blijft hetzelfde: ongelooflijk gemak van schaalbaarheid en beheer. Het nadeel is dat verschillende taken bronnen op een andere manier verbruiken, en op sommige plaatsen zullen er veel lokale schijven zijn, op andere plaatsen zal er weinig RAM zijn, enzovoort, dat wil zeggen dat voor verschillende soorten taken het gebruik van bronnen zal afnemen.
Het blijkt dat u 10-15% meer betaalt voor het installatiegemak. Dit is wat de mythe in de titel veroorzaakte. We hebben lang gezocht naar waar de technologie optimaal toegepast kon worden, en die hebben we gevonden. Feit is dat Cisco geen eigen opslagsystemen had, maar een complete servermarkt wilde. En ze maakten Cisco Hyperflex - een oplossing met lokale opslag op knooppunten.
En dit bleek ineens een hele goede oplossing voor backup datacenters (Disaster Recovery). Ik zal je nu vertellen waarom en hoe. En ik zal je de clustertests laten zien.
Waar nodig
Hyperconvergentie is:
- Schijven overbrengen naar rekenknooppunten.
- Volledige integratie van het opslagsubsysteem met het virtualisatiesubsysteem.
- Overdracht/integratie met het netwerksubsysteem.
Met deze combinatie kunt u veel opslagsysteemfuncties op virtualisatieniveau implementeren, en dat allemaal vanuit één bedieningsvenster.
Bij ons bedrijf is er veel vraag naar projecten voor het ontwerpen van redundante datacenters, en er wordt vaak gekozen voor een hypergeconvergeerde oplossing vanwege de vele kant-en-klare replicatie-opties (tot een metrocluster).
In het geval van back-updatacenters hebben we het meestal over een externe faciliteit op een locatie aan de andere kant van de stad of in een andere stad. Hiermee kunt u kritieke systemen herstellen in het geval van een gedeeltelijke of volledige storing van het hoofddatacenter. Verkoopgegevens worden daar voortdurend gerepliceerd, en deze replicatie kan plaatsvinden op applicatieniveau of op blokapparaatniveau (opslag).
Daarom zal ik het nu hebben over het systeemontwerp en de tests, en daarna over een paar praktijkscenario's met besparingsgegevens.
Testen
Onze instance bestaat uit vier servers met elk 10 SSD-schijven van 960 GB. Er is een speciale schijf voor het cachen van schrijfbewerkingen en het opslaan van de virtuele servicemachine. De oplossing zelf is de vierde versie. De eerste is eerlijk gezegd grof (te oordelen naar de recensies), de tweede is vochtig, de derde is al behoorlijk stabiel, en deze kan een release worden genoemd na het einde van de bètatests voor het grote publiek. Tijdens het testen heb ik geen problemen gezien, alles werkt als een klok.
Veranderingen in v4Er zijn een aantal bugs opgelost.
Aanvankelijk kon het platform alleen werken met de VMware ESXi-hypervisor en ondersteunde het een klein aantal knooppunten. Ook eindigde het implementatieproces niet altijd succesvol, moesten sommige stappen opnieuw worden gestart, waren er problemen met het updaten van oudere versies, werden gegevens in de GUI niet altijd correct weergegeven (hoewel ik nog steeds niet blij ben met de weergave van prestatiegrafieken ), ontstonden er soms problemen op het raakvlak met virtualisatie.
Nu alle kinderproblemen zijn opgelost, kan HyperFlex zowel ESXi als Hyper-V aan, en is het mogelijk om:
- Een uitgerekt cluster maken.
- Een cluster voor kantoren creëren zonder Fabric Interconnect te gebruiken, van twee naar vier knooppunten (we kopen alleen servers).
- Mogelijkheid om met externe opslagsystemen te werken.
- Ondersteuning voor containers en Kubernetes.
- Aanmaken van beschikbaarheidszones.
- Integratie met VMware SRM als de ingebouwde functionaliteit niet naar wens is.
De architectuur verschilt niet veel van de oplossingen van de belangrijkste concurrenten; ze hebben geen fiets gecreëerd. Het draait allemaal op het VMware- of Hyper-V-virtualisatieplatform. De hardware wordt gehost op eigen Cisco UCS-servers. Er zijn mensen die het platform haten vanwege de relatieve complexiteit van de initiële installatie, de vele knoppen, een niet-triviaal systeem van sjablonen en afhankelijkheden, maar er zijn ook mensen die Zen hebben geleerd, geïnspireerd zijn door het idee en niet langer willen om met andere servers te werken.
We zullen de oplossing voor VMware overwegen, aangezien de oplossing er oorspronkelijk voor is gemaakt en meer functionaliteit heeft; Hyper-V is gaandeweg toegevoegd om gelijke tred te houden met de concurrentie en aan de verwachtingen van de markt te voldoen.
Er is een cluster van servers vol met schijven. Er zijn schijven voor gegevensopslag (SSD of HDD - afhankelijk van uw smaak en behoeften), er is één SSD-schijf voor caching. Wanneer gegevens naar de datastore worden geschreven, worden de gegevens opgeslagen op de cachinglaag (speciale SSD-schijf en RAM van de service-VM). Parallel wordt een gegevensblok naar knooppunten in het cluster verzonden (het aantal knooppunten is afhankelijk van de clusterreplicatiefactor). Na bevestiging van alle knooppunten over succesvolle opname, wordt de bevestiging van de opname naar de hypervisor en vervolgens naar de VM gestuurd. De opgenomen gegevens worden op de achtergrond gededupliceerd, gecomprimeerd en naar opslagschijven geschreven. Tegelijkertijd wordt er altijd en opeenvolgend een groot blok naar de opslagschijven geschreven, waardoor de belasting van de opslagschijven wordt verminderd.
Deduplicatie en compressie zijn altijd ingeschakeld en kunnen niet worden uitgeschakeld. Gegevens worden rechtstreeks van opslagschijven of uit de RAM-cache gelezen. Als er een hybride configuratie wordt gebruikt, worden de leesbewerkingen ook in de cache op de SSD opgeslagen.
De gegevens zijn niet gebonden aan de huidige locatie van de virtuele machine en worden gelijkmatig verdeeld over de knooppunten. Met deze aanpak kunt u alle schijven en netwerkinterfaces gelijkelijk laden. Er is een duidelijk nadeel: we kunnen de leeslatentie niet zoveel mogelijk beperken, omdat er geen garantie is dat de gegevens lokaal beschikbaar zijn. Maar ik geloof dat dit een klein offer is vergeleken met de ontvangen voordelen. Bovendien hebben netwerkvertragingen zulke waarden bereikt dat ze praktisch geen invloed hebben op het algehele resultaat.
Een speciale service VM Cisco HyperFlex Data Platform-controller, die op elk opslagknooppunt wordt gemaakt, is verantwoordelijk voor de volledige bedieningslogica van het schijfsubsysteem. In onze service-VM-configuratie werden acht vCPU's en 72 GB RAM toegewezen, wat niet zo weinig is. Laat me je eraan herinneren dat de host zelf 28 fysieke kernen en 512 GB RAM heeft.
De service-VM heeft rechtstreeks toegang tot fysieke schijven door de SAS-controller door te sturen naar de VM. Communicatie met de hypervisor vindt plaats via een speciale module IOVisor, die I/O-bewerkingen onderschept, en via een agent waarmee u opdrachten naar de hypervisor-API kunt verzenden. De agent is verantwoordelijk voor het werken met HyperFlex-snapshots en klonen.
Schijfbronnen worden in de hypervisor aangekoppeld als NFS- of SMB-shares (afhankelijk van het type hypervisor, raad eens welke zich waar bevindt). En onder de motorkap bevindt zich een gedistribueerd bestandssysteem waarmee u functies van volwaardige opslagsystemen voor volwassenen kunt toevoegen: toewijzing van dunne volumes, compressie en deduplicatie, snapshots met behulp van Redirect-on-Write-technologie, synchrone/asynchrone replicatie.
De service-VM biedt toegang tot de WEB-beheerinterface van het HyperFlex-subsysteem. Er is integratie met vCenter en de meeste dagelijkse taken kunnen er vanuit worden uitgevoerd, maar datastores zijn bijvoorbeeld handiger om uit een aparte webcam te knippen als je al bent overgestapt op een snelle HTML5-interface, of een volwaardige Flash-client gebruikt met volledige integratie. In de servicewebcam kunt u de prestaties en gedetailleerde status van het systeem bekijken.
Er is een ander type knooppunt in een cluster: computerknooppunten. Dit kunnen rack- of bladeservers zijn zonder ingebouwde schijven. Deze servers kunnen VM’s draaien waarvan de gegevens zijn opgeslagen op servers met schijven. Vanuit het oogpunt van datatoegang is er geen verschil tussen de typen knooppunten, omdat de architectuur abstractie van de fysieke locatie van de gegevens inhoudt. De maximale verhouding tussen rekenknooppunten en opslagknooppunten is 2:1.
Het gebruik van rekenknooppunten vergroot de flexibiliteit bij het schalen van clusterbronnen: we hoeven geen extra knooppunten met schijven te kopen als we alleen CPU/RAM nodig hebben. Daarnaast kunnen we een bladecage toevoegen en besparen op rackplaatsing van servers.
Als gevolg hiervan hebben we een hypergeconvergeerd platform met de volgende kenmerken:
- Maximaal 64 knooppunten in een cluster (maximaal 32 opslagknooppunten).
- Het minimumaantal knooppunten in een cluster is drie (twee voor een Edge-cluster).
- Mechanisme voor gegevensredundantie: spiegeling met replicatiefactor 2 en 3.
- Metrocluster.
- Asynchrone VM-replicatie naar een ander HyperFlex-cluster.
- Orkestratie van het overschakelen van VM's naar een extern datacenter.
- Native snapshots met behulp van Redirect-on-Write-technologie.
- Tot 1 PB bruikbare ruimte bij replicatiefactor 3 en zonder deduplicatie. Wij houden geen rekening met replicatiefactor 2, omdat dit bij serieuze verkopen geen optie is.
Een ander groot pluspunt is het gemak van beheer en implementatie. Alle complexiteiten van het opzetten van UCS-servers worden afgehandeld door een gespecialiseerde VM die is voorbereid door Cisco-technici.
Testbankconfiguratie:
- 2 x Cisco UCS Fabric Interconnect 6248UP als beheercluster en netwerkcomponenten (48 poorten werkend in Ethernet 10G/FC 16G-modus).
- Vier Cisco UCS HXAF240 M4-servers.
Serverkenmerken:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
Netwerk
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet-poorten
Opslag HBA
Cisco 12G modulaire SAS-pass-through-controller
Opslagschijven
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Meer configuratiemogelijkhedenNaast de geselecteerde hardware zijn momenteel de volgende opties beschikbaar:
- HXAF240c M5.
- Eén of twee CPU's, variërend van Intel Silver 4110 tot Intel Platinum I8260Y. Tweede generatie beschikbaar.
- 24 geheugenslots, strips van 16 GB RDIMM 2600 tot 128 GB LRDIMM 2933.
- Van 6 tot 23 dataschijven, één cachingschijf, één systeemschijf en één opstartschijf.
Capaciteit schijven
- HX-SD960G61X-EV 960 GB 2.5 inch Enterprise Value 6G SATA SSD (1x uithoudingsvermogen) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 inch Enterprise Value 6G SATA SSD (1x uithoudingsvermogen) SAS 3.8 TB.
- Caching van schijven
- HX-NVMEXPB-I375 375 GB 2.5-inch Intel Optane-schijf, extreme prestaties en uithoudingsvermogen.
- HX-NVMEHW-H1600* 1.6 TB 2.5 inch Ent. Perf. NVMe SSD (3x uithoudingsvermogen) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 inch Ent. Perf. 12G SAS SSD (10x uithoudingsvermogen) SAS 400 GB.
- HX-SD800GBENK9** 800 GB 2.5 inch Ent. Perf. 12G SAS SED SSD (10x uithoudingsvermogen) SAS 800 GB.
- HX-SD16T123X-EP 1.6 TB 2.5 inch Enterprise-prestaties 12G SAS SSD (3x uithoudingsvermogen).
Systeem-/logboekschijven
- HX-SD240GM1X-EV 240 GB 2.5 inch Enterprise Value 6G SATA SSD (vereist upgrade).
Opstartschijven
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Maak verbinding met het netwerk via 40G-, 25G- of 10G Ethernet-poorten.
De FI kan HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G) zijn.
De proef zelf
Om het schijfsubsysteem te testen, heb ik HCIBench 2.2.1 gebruikt. Dit is een gratis hulpprogramma waarmee u het maken van een belasting vanaf meerdere virtuele machines kunt automatiseren. De belasting zelf wordt gegenereerd door de gebruikelijke fio.
Ons cluster bestaat uit vier knooppunten, replicatiefactor 3, alle schijven zijn Flash.
Om te testen heb ik vier datastores en acht virtuele machines gemaakt. Bij schrijftests wordt ervan uitgegaan dat de cachingschijf niet vol is.
De testresultaten zijn als volgt:
100% Lezen 100% Willekeurig
0% Lezen 100% Willekeurig
Blok-/wachtrijdiepte
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
Vetgedrukt geeft waarden aan waarna er geen sprake meer is van productiviteitsstijging, soms is zelfs degradatie zichtbaar. Dit komt door het feit dat we beperkt worden door de prestaties van het netwerk/controllers/schijven.
- Sequentieel lezen 4432 MB/s.
- Sequentieel schrijven 804 MB/s.
- Als één controller uitvalt (falen van een virtuele machine of host), is de prestatiedaling tweeledig.
- Als de opslagschijf defect raakt, is de opname 1/3. Het opnieuw opbouwen van de schijf vergt 5% van de bronnen van elke controller.
Op een klein blok worden we beperkt door de prestaties van de controller (virtuele machine), de CPU wordt voor 100% geladen en wanneer het blok groter wordt, worden we beperkt door de poortbandbreedte. 10 Gbps is niet genoeg om het potentieel van het AllFlash-systeem te ontsluiten. Helaas laten de parameters van de meegeleverde demostand ons niet toe om de werking op 40 Gbit/s te testen.
In mijn indruk van tests en het bestuderen van de architectuur krijgen we, dankzij het algoritme dat gegevens tussen alle hosts plaatst, schaalbare, voorspelbare prestaties, maar dit is ook een beperking bij het lezen, omdat het mogelijk zou zijn om meer uit lokale schijven te halen. hier kan het een productiever netwerk besparen; er is bijvoorbeeld FI met 40 Gbit/s beschikbaar.
Ook kan één schijf voor caching en deduplicatie een beperking zijn; in dit testbed kunnen we zelfs naar vier SSD-schijven schrijven. Het zou geweldig zijn om het aantal caching-schijven te kunnen vergroten en het verschil te zien.
Echt gebruik
Om een back-updatacenter te organiseren, kunt u twee benaderingen gebruiken (we overwegen niet om een back-up op een externe locatie te plaatsen):
- Actief passief. Alle applicaties worden gehost in het hoofddatacenter. Replicatie is synchroon of asynchroon. Als het hoofddatacenter uitvalt, moeten we het back-upcentrum activeren. Dit kan handmatig/scripts/orkestratietoepassingen worden gedaan. Hier krijgen we een RPO die evenredig is met de replicatiefrequentie, en de RTO hangt af van de reactie en vaardigheden van de beheerder en de kwaliteit van de ontwikkeling/debuggen van het overstapplan.
- Actief-actief. In dit geval is er alleen sprake van synchrone replicatie; de beschikbaarheid van datacenters wordt bepaald door een quorum/arbiter die zich strikt op de derde locatie bevindt. RPO = 0, en RTO kan 0 bereiken (als de applicatie dit toestaat) of gelijk zijn aan de failover-tijd van een knooppunt in een virtualisatiecluster. Op virtualisatieniveau wordt een uitgerekt (Metro)cluster gecreëerd dat Active-Active opslag vereist.
Meestal zien we dat klanten al een architectuur met een klassiek opslagsysteem in het hoofddatacenter hebben geïmplementeerd, dus ontwerpen we een andere voor replicatie. Zoals ik al zei, biedt Cisco HyperFlex asynchrone replicatie en het creëren van uitgebreide virtualisatieclusters. Tegelijkertijd hebben we geen speciaal opslagsysteem van het Midrange-niveau en hoger nodig met dure replicatiefuncties en Active-Active-gegevenstoegang op twee opslagsystemen.
Scenario 1: We hebben een primair en back-updatacenter, een virtualisatieplatform op VMware vSphere. Alle productieve systemen bevinden zich in het hoofddatacenter en de replicatie van virtuele machines wordt uitgevoerd op hypervisorniveau. Hierdoor wordt voorkomen dat VM's ingeschakeld blijven in het back-updatacenter. We repliceren databases en speciale applicaties met behulp van ingebouwde tools en houden de VM’s ingeschakeld. Als het hoofddatacenter uitvalt, lanceren we systemen in het back-updatacenter. We denken dat we ongeveer 100 virtuele machines hebben. Terwijl het primaire datacenter operationeel is, kan het standby-datacenter testomgevingen en andere systemen draaien die kunnen worden uitgeschakeld als het primaire datacenter overschakelt. Het is ook mogelijk dat we tweerichtingsreplicatie gebruiken. Vanuit hardware-oogpunt verandert er niets.
In het geval van klassieke architectuur installeren we in elk datacenter een hybride opslagsysteem met toegang via FibreChannel, tiering, deduplicatie en compressie (maar niet online), 8 servers voor elke site, 2 FibreChannel-switches en 10G Ethernet. Voor replicatie- en schakelbeheer in een klassieke architectuur kunnen we VMware-tools (Replicatie + SRM) of tools van derden gebruiken, die iets goedkoper en soms handiger zullen zijn.
De figuur toont het diagram.
Bij gebruik van Cisco HyperFlex wordt de volgende architectuur verkregen:
Voor HyperFlex gebruikte ik servers met grote CPU/RAM-bronnen, omdat... Een deel van de bronnen gaat naar de HyperFlex-controller-VM; qua CPU en geheugen heb ik de HyperFlex-configuratie zelfs een beetje opnieuw geconfigureerd om niet mee te spelen met Cisco en bronnen voor de resterende VM's te garanderen. Maar we kunnen FibreChannel-switches achterwege laten en we hebben geen Ethernet-poorten nodig voor elke server; lokaal verkeer wordt binnen FI geschakeld.
Het resultaat was de volgende configuratie voor elk datacenter:
Servers
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)
SHD
Hybride opslagsysteem met FC Front-End (20TB SSD, 130 TB NL-SAS)
-
LAN
2 x Ethernet-switch 10G 12 poorten
-
SAN
2 x FC-switch 32/16Gb 24 poorten
2 x Cisco UCS FI 6332
van de licentie
VMware Ent Plus
Replicatie en/of orkestratie van VM-switching
VMware Ent Plus
Ik heb geen replicatiesoftwarelicenties voor Hyperflex verstrekt, aangezien dit voor ons kant-en-klaar beschikbaar is.
Voor klassieke architectuur heb ik gekozen voor een leverancier die zich heeft bewezen als een hoogwaardige en goedkope fabrikant. Voor beide opties heb ik de standaardkorting voor een specifieke oplossing toegepast, waardoor ik echte prijzen kreeg.
De Cisco HyperFlex-oplossing bleek 13% goedkoper.
Scenario 2: oprichting van twee actieve datacenters. In dit scenario ontwerpen we een uitgerekt cluster op VMware.
De klassieke architectuur bestaat uit virtualisatieservers, een SAN (FC-protocol) en twee opslagsystemen die kunnen lezen en schrijven naar het volume dat zich ertussen bevindt. Op elk opslagsysteem plaatsen we een nuttige capaciteit voor opslag.
Bij HyperFlex creëren we eenvoudigweg een Stretch Cluster met hetzelfde aantal knooppunten op beide sites. In dit geval wordt een replicatiefactor van 2+2 gebruikt.
Het resultaat is de volgende configuratie:
klassieke architectuur
Hyperflex
Servers
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)
SHD
2 x AllFlash-opslagsystemen (150 TB SSD)
-
LAN
4 x Ethernet-switch 10G 24 poorten
-
SAN
4 x FC-switch 32/16Gb 24 poorten
4 x Cisco UCS FI 6332
van de licentie
VMware Ent Plus
VMware Ent Plus
Bij alle berekeningen heb ik geen rekening gehouden met de netwerkinfrastructuur, datacenterkosten, etc.: die zullen hetzelfde zijn voor de klassieke architectuur en voor de HyperFlex-oplossing.
Qua kosten bleek HyperFlex 5% duurder. Het is de moeite waard hier op te merken dat ik qua CPU/RAM-bronnen een voorkeur had voor Cisco, omdat ik in de configuratie de geheugencontrollerkanalen gelijkmatig vulde. De kosten zijn iets hoger, maar niet in een orde van grootte, wat duidelijk aangeeft dat hyperconvergentie niet noodzakelijkerwijs ‘speelgoed voor de rijken’ is, maar kan concurreren met de standaardaanpak voor het bouwen van een datacenter. Dit kan ook interessant zijn voor degenen die al over Cisco UCS-servers en de bijbehorende infrastructuur daarvoor beschikken.
Tot de voordelen behoren de afwezigheid van kosten voor het beheer van SAN- en opslagsystemen, online compressie en deduplicatie, één enkel toegangspunt voor ondersteuning (virtualisatie, servers, het zijn ook opslagsystemen), ruimtebesparing (maar niet in alle scenario's), vereenvoudiging van de bediening.
Wat ondersteuning betreft, hier krijgt u deze van één leverancier: Cisco. Afgaande op mijn ervaring met Cisco UCS-servers bevalt het mij; ik hoefde het niet op HyperFlex te openen, alles werkte precies hetzelfde. Ingenieurs reageren snel en kunnen niet alleen typische problemen, maar ook complexe randgevallen oplossen. Soms wend ik me tot hen met vragen: "Is het mogelijk om dit te doen, schroef het vast?" of “Ik heb hier iets geconfigureerd en het wil niet werken. Hulp!" - ze zullen daar geduldig de nodige gids vinden en de juiste acties aanwijzen; ze zullen niet antwoorden: "We lossen alleen hardwareproblemen op."
referenties
- Mijn mail - [e-mail beveiligd]
Bron: www.habr.com