Ez egy mítosz, amely meglehetősen gyakori a szerverhardverek területén. A gyakorlatban sok mindenre szükség van hiperkonvergens megoldásokra (amikor minden egyben van). Történelmileg az első architektúrákat az Amazon és a Google fejlesztette ki szolgáltatásaihoz. Aztán az volt az ötlet, hogy azonos csomópontokból készítsünk egy számítástechnikai farmot, amelyek mindegyikének megvan a maga lemeze. Mindezt valamilyen rendszerformáló szoftver (hipervizor) egyesítette, és virtuális gépekre osztotta. A fő cél egy csomópont kiszolgálásának minimális erőfeszítése és minimális probléma a méretezéssel: csak vásároljon még ezer-két ugyanolyan szervert, és csatlakoztassa őket a közelben. A gyakorlatban ezek elszigetelt esetek, és sokkal gyakrabban beszélünk kisebb számú csomópontról és kissé eltérő architektúráról.
De a plusz ugyanaz marad – hihetetlenül egyszerű a méretezhetőség és a kezelés. Hátránya, hogy a különböző feladatok eltérően fogyasztják az erőforrásokat, és néhol sok lesz a helyi lemez, máshol kevés a RAM, és így tovább, vagyis a különböző típusú feladatoknál csökken az erőforrás-kihasználás.
Kiderült, hogy 10–15%-kal többet kell fizetnie a beállítás megkönnyítése érdekében. Ez váltotta ki a mítoszt a címben. Sokáig kerestük, hol lehetne optimálisan alkalmazni a technológiát, és megtaláltuk. Az tény, hogy a Ciscónak nem voltak saját tárolórendszerei, de komplett szerverpiacot akartak. És megalkották a Cisco Hyperflexet – egy megoldást helyi tárhelyekkel a csomópontokon.
És ez hirtelen nagyon jó megoldásnak bizonyult a biztonsági mentési adatközpontokhoz (Disaster Recovery). Most elmondom, miért és hogyan. És megmutatom a klaszterteszteket.
Ahol szükséges
A hiperkonvergencia:
- Lemezek átvitele számítási csomópontokhoz.
- A tároló alrendszer teljes integrációja a virtualizációs alrendszerrel.
- Átadás/integráció a hálózati alrendszerrel.
Ez a kombináció lehetővé teszi számos tárolórendszer-funkció megvalósítását virtualizációs szinten, és mindezt egyetlen vezérlőablakból.
Cégünknél nagy az igény a redundáns adatközpontok tervezésére irányuló projektekre, és gyakran a hiperkonvergens megoldást választják a már kész replikációs lehetőségek (akár egy metrocluster) miatt.
A tartalék adatközpontok esetében általában egy távoli létesítményről beszélünk, amely a város másik felén található, vagy egy másik városban található. Lehetővé teszi a kritikus rendszerek visszaállítását a fő adatközpont részleges vagy teljes meghibásodása esetén. Az értékesítési adatok ott folyamatosan replikálódnak, és ez a replikáció lehet alkalmazásszintű vagy blokkeszköz (tárhely) szinten.
Ezért most a rendszertervezésről és a tesztekről fogok beszélni, majd néhány valós alkalmazási forgatókönyvről megtakarítási adatokkal.
Tesztek
Példányunk négy szerverből áll, amelyek mindegyike 10 darab 960 GB-os SSD-meghajtóval rendelkezik. Van egy dedikált lemez az írási műveletek gyorsítótárazására és a szolgáltatási virtuális gép tárolására. Maga a megoldás a negyedik verzió. Az első őszintén nyers (az értékelésekből ítélve), a második nedves, a harmadik már meglehetősen stabil, és ez már a béta tesztelése utáni kiadásnak nevezhető a nagyközönség számára. A tesztelés során nem láttam semmilyen problémát, minden úgy működik, mint egy óra.
V4-es változásokEgy csomó hibát javítottak.
Kezdetben a platform csak a VMware ESXi hypervisorral tudott működni, és néhány csomópontot támogatott. Ezenkívül a telepítési folyamat nem mindig fejeződött be sikeresen, néhány lépést újra kellett indítani, problémák voltak a régebbi verziókról való frissítéssel, a grafikus felhasználói felületen lévő adatok nem mindig jelennek meg megfelelően (bár továbbra sem vagyok elégedett a teljesítménygrafikonok megjelenítésével ), néha problémák merültek fel a virtualizációs felületen.
Mostanra minden gyermekkori problémát kijavítottak, a HyperFlex képes kezelni az ESXi-t és a Hyper-V-t is, valamint lehetséges:
- Nyújtott fürt létrehozása.
- Klaszter létrehozása irodák számára Fabric Interconnect használata nélkül, kettőtől négy csomópontig (csak szervereket vásárolunk).
- Képes dolgozni külső tárolórendszerekkel.
- Konténerek és Kubernetes támogatása.
- Elérhetőségi zónák létrehozása.
- Integráció a VMware SRM-mel, ha a beépített funkcionalitás nem kielégítő.
Az architektúra nem sokban különbözik a fő versenytársak megoldásaitól, nem ők alkottak kerékpárt. Mindez a VMware vagy a Hyper-V virtualizációs platformon fut. A hardver szabadalmazott Cisco UCS szervereken található. Vannak, akik utálják a platformot a kezdeti beállítás viszonylagos bonyolultsága, a sok gomb, a sablonok és függőségek nem triviális rendszere miatt, de vannak olyanok is, akik megtanulták a zent, inspirálják az ötlet, és már nem akarják más szerverekkel dolgozni.
Megfontoljuk a VMware megoldását, mivel a megoldást eredetileg erre hozták létre, és több funkcióval rendelkezik, a Hyper-V pedig menet közben került beépítésre, hogy lépést tartsunk a versenytársakkal és megfeleljünk a piaci elvárásoknak.
Van egy szervercsoport tele lemezekkel. Vannak lemezek az adatok tárolására (SSD vagy HDD - ízlés és igény szerint), van egy SSD lemez a gyorsítótárazáshoz. Amikor adatokat ír az adattárba, az adatok a gyorsítótárazási rétegre (a szolgáltatási virtuális gép dedikált SSD-lemezére és RAM-jára) kerülnek mentésre. Ezzel párhuzamosan egy adatblokk kerül elküldésre a fürt csomópontjainak (a csomópontok száma a fürt replikációs tényezőjétől függ). Miután az összes csomópont megerősítette a sikeres rögzítést, a rögzítés megerősítése elküldésre kerül a hypervisornak, majd a virtuális gépnek. A rögzített adatok deduplikálása, tömörítése és tárolólemezekre íródik a háttérben. Ugyanakkor a tárolólemezekre mindig és szekvenciálisan egy nagy blokk íródik, ami csökkenti a tárolólemezek terhelését.
A deduplikáció és a tömörítés mindig engedélyezve van, és nem tiltható le. Az adatok beolvasása közvetlenül a tárolólemezekről vagy a RAM gyorsítótárából történik. Ha hibrid konfigurációt használunk, az olvasások az SSD-n is gyorsítótárazásra kerülnek.
Az adatok nincsenek a virtuális gép aktuális helyéhez kötve, és egyenletesen oszlanak el a csomópontok között. Ez a megközelítés lehetővé teszi az összes lemez és hálózati interfész egyformán betöltését. Van egy nyilvánvaló hátránya: az olvasási késleltetést nem tudjuk a lehető legnagyobb mértékben csökkenteni, mivel nincs garancia az adatok helyi elérhetőségére. De úgy gondolom, hogy ez csekély áldozat a kapott juttatásokhoz képest. Ezenkívül a hálózati késések olyan értékeket értek el, amelyek gyakorlatilag nem befolyásolják az általános eredményt.
A lemezalrendszer teljes működési logikájáért egy speciális szolgáltatású VM Cisco HyperFlex Data Platform vezérlő, amely minden tárolócsomóponton jön létre. Szolgáltatási VM konfigurációnkban nyolc vCPU és 72 GB RAM került kiosztásra, ami nem is olyan kevés. Hadd emlékeztesselek arra, hogy maga a gazdagép 28 fizikai maggal és 512 GB RAM-mal rendelkezik.
A szolgáltatási virtuális gép közvetlenül a SAS-vezérlőnek a virtuális géphez való továbbításával fér hozzá a fizikai lemezekhez. A hipervizorral való kommunikáció egy speciális IOVisor modulon keresztül történik, amely elfogja az I/O műveleteket, és olyan ügynök használatával, amely lehetővé teszi parancsok küldését a hypervisor API-nak. Az ügynök felelős a HyperFlex pillanatképekkel és klónokkal való munkáért.
A lemezerőforrások a hypervisorba NFS- vagy SMB-megosztásként vannak felszerelve (a hypervisor típusától függően, találja ki, melyik hol található). És a motorháztető alatt ez egy elosztott fájlrendszer, amely lehetővé teszi a felnőttek teljes értékű tárolórendszereinek funkcióinak hozzáadását: vékony kötetelosztás, tömörítés és deduplikáció, pillanatképek Redirect-on-Write technológiával, szinkron/aszinkron replikáció.
A szolgáltatási virtuális gép hozzáférést biztosít a HyperFlex alrendszer WEB felügyeleti felületéhez. Van integráció a vCenterrel, és a legtöbb hétköznapi feladat elvégezhető belőle, de például az adattárakat kényelmesebb külön webkameráról vágni, ha már átváltottunk egy gyors HTML5 felületre, vagy teljes értékű Flash klienst használunk. teljes integrációval. A szerviz webkamerában megtekintheti a rendszer teljesítményét és részletes állapotát.
Van egy másik típusú csomópont a fürtben - a számítási csomópontok. Ezek lehetnek rack vagy blade szerverek beépített lemezek nélkül. Ezek a kiszolgálók olyan virtuális gépeket futtathatnak, amelyek adatait lemezes kiszolgálókon tárolják. Az adatelérés szempontjából nincs különbség a csomópontok típusai között, mert az architektúra az adatok fizikai helyétől való elvonatkoztatással jár. A számítási csomópontok és a tárolási csomópontok maximális aránya 2:1.
A számítási csomópontok használata növeli a rugalmasságot a fürterőforrások méretezésekor: nem kell további lemezes csomópontokat vásárolnunk, ha csak CPU/RAM-ra van szükségünk. Ezenkívül blade ketrecet is hozzáadhatunk, és spórolhatunk a szerverek rack elhelyezésén.
Ennek eredményeként van egy hiperkonvergens platformunk, amely a következő jellemzőkkel rendelkezik:
- Akár 64 csomópont egy fürtben (legfeljebb 32 tárolócsomópont).
- A csomópontok minimális száma egy fürtben három (egy Edge-fürtnél kettő).
- Adatredundancia mechanizmus: tükrözés 2-es és 3-as replikációs faktorral.
- Metró klaszter.
- Aszinkron virtuálisgép-replikáció egy másik HyperFlex-fürtre.
- A virtuális gépek távoli adatközpontra váltásának összehangolása.
- Natív pillanatképek Redirect-on-Write technológiával.
- Akár 1 PB felhasználható terület 3-as replikációs tényezővel és duplikálás nélkül. A 2-es replikációs faktort nem vesszük figyelembe, mert komoly eladásoknál ez nem opció.
Egy másik hatalmas előny a könnyű kezelés és telepítés. Az UCS-kiszolgálók beállításának minden bonyolultságáról a Cisco mérnökei által készített speciális virtuális gép gondoskodik.
Tesztpad konfiguráció:
- 2 x Cisco UCS Fabric Interconnect 6248UP felügyeleti fürtként és hálózati összetevőként (48 port Ethernet 10G/FC 16G módban működik).
- Négy Cisco UCS HXAF240 M4 szerver.
Szerver jellemzői:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
Hálózat
UCSC-MLOM-CSC-02 (VIC 1227). 2 db 10G Ethernet port
Tárolás HBA
Cisco 12G Modular SAS Pass through Controller
Tárolólemezek
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
További konfigurációs lehetőségekA kiválasztott hardveren kívül jelenleg a következő opciók állnak rendelkezésre:
- HXAF240c M5.
- Egy vagy két CPU az Intel Silver 4110-től az Intel Platinum I8260Y-ig. Második generáció elérhető.
- 24 memóriahely, csíkok 16 GB RDIMM 2600-tól 128 GB LRDIMM 2933-ig.
- 6-23 adatlemez, egy gyorsítótár, egy rendszerlemez és egy rendszerindító lemez.
Kapacitásmeghajtók
- HX-SD960G61X-EV 960 GB 2.5 hüvelykes Enterprise Value 6G SATA SSD (1X tartósság) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 hüvelykes Enterprise Value 6G SATA SSD (1X tartós) SAS 3.8 TB.
- Meghajtók gyorsítótárazása
- HX-NVMEXPB-I375 375 GB 2.5 hüvelykes Intel Optane meghajtó, Extreme Perf & Endurance.
- HX-NVMEHW-H1600* 1.6 TB 2.5 hüvelykes Ent. Perf. NVMe SSD (3X tartós) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400 GB 2.5 hüvelykes Ent. Perf. 12G SAS SSD (10X tartósság) SAS 400 GB.
- HX-SD800GBENK9** 800 GB 2.5 hüvelykes Ent. Perf. 12G SAS SED SSD (10X tartósság) SAS 800 GB.
- HX-SD16T123X-EP 1.6 TB 2.5 hüvelykes Vállalati teljesítmény 12G SAS SSD (3X tartósság).
Rendszer/naplómeghajtók
- HX-SD240GM1X-EV 240 GB 2.5 hüvelykes Enterprise Value 6G SATA SSD (Frissítést igényel).
Indító meghajtók
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB.
Csatlakozzon a hálózathoz 40G, 25G vagy 10G Ethernet porton keresztül.
Az FI lehet HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Maga a teszt
A lemez alrendszer teszteléséhez a HCIBench 2.2.1-et használtam. Ez egy ingyenes segédprogram, amely lehetővé teszi, hogy automatizálja a terhelés létrehozását több virtuális gépről. Magát a terhelést a szokásos fio generálja.
Klaszterünk négy csomópontból áll, 3-as replikációs faktor, minden lemez Flash.
A teszteléshez négy adattárat és nyolc virtuális gépet hoztam létre. Az írási teszteknél azt feltételezzük, hogy a gyorsítótárazó lemez nincs tele.
A teszt eredményei a következők:
100% olvasás 100% véletlenszerű
0% Olvasás 100% Véletlen
Blokk/sormélység
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
A félkövér olyan értékeket jelöl, amelyek után nem nő a termelékenység, néha még romlás is látható. Ez annak köszönhető, hogy a hálózat/vezérlők/lemezek teljesítménye korlátoz bennünket.
- Szekvenciális olvasás 4432 MB/s.
- Szekvenciális írás 804 MB/s.
- Ha az egyik vezérlő meghibásodik (egy virtuális gép vagy gazdagép meghibásodása), a teljesítmény kétszeres csökkenést jelent.
- Ha a tárolólemez meghibásodik, a lehívás 1/3. A lemez újraépítése az egyes vezérlők erőforrásainak 5%-át veszi igénybe.
Egy kis blokkon a vezérlő (virtuális gép) teljesítménye korlátoz minket, a CPU-ja 100%-ra van terhelve, a blokk növekedésével pedig a port sávszélessége korlátoz minket. A 10 Gbps nem elég az AllFlash rendszerben rejlő lehetőségek kiaknázásához. Sajnos a mellékelt bemutató állvány paraméterei nem teszik lehetővé, hogy 40 Gbit/s-on teszteljük a működést.
A tesztek és az architektúra tanulmányozása során szerzett benyomásom szerint az adatokat minden gép között elhelyező algoritmusnak köszönhetően skálázható, kiszámítható teljesítményt kapunk, de ez olvasáskor is korlátot jelent, mert a helyi lemezekről többet lehetne kipréselni, itt megspórolhat egy produktívabb hálózatot, például elérhető a 40 Gbit/s sebességű FI.
A gyorsítótárazáshoz és a deduplikációhoz egy lemez is korlátozás lehet, valójában ebben a tesztágyban négy SSD-lemezre írhatunk. Jó lenne növelni a gyorsítótárazott meghajtók számát, és látni a különbséget.
Valódi használat
A biztonsági mentési adatközpont megszervezéséhez kétféle megközelítést alkalmazhat (nem fontolgatjuk a biztonsági mentés távoli webhelyen való elhelyezését):
- Aktív Passzív. Minden alkalmazás a fő adatközpontban található. A replikáció szinkron vagy aszinkron. Ha a fő adatközpont meghibásodik, aktiválnunk kell a tartalékot. Ez megtehető manuálisan/szkriptek/hangszerelési alkalmazások. Itt a replikációs gyakorisággal arányos RPO-t kapunk, az RTO pedig az adminisztrátor reakciójától és képességeitől, valamint a váltási terv fejlesztésének/hibakeresésének minőségétől függ.
- Aktív-Aktív. Ebben az esetben csak szinkron replikációról van szó, az adatközpontok elérhetőségét a szigorúan a harmadik helyen elhelyezkedő határozatképesség/döntőbíró határozza meg. RPO = 0, és az RTO elérheti a 0-t (ha az alkalmazás lehetővé teszi), vagy egyenlő a virtualizációs fürt csomópontjának feladatátvételi idejével. A virtualizáció szintjén egy kiterjesztett (Metro) fürt jön létre, amely Active-Active tárolást igényel.
Általában azt látjuk, hogy a kliensek már megvalósítottak egy klasszikus tárolórendszerrel rendelkező architektúrát a fő adatközpontban, ezért tervezünk egy másikat a replikációhoz. Mint említettem, a Cisco HyperFlex aszinkron replikációt és kiterjesztett virtualizációs fürtlétrehozást kínál. Ugyanakkor nincs szükségünk középkategóriás és magasabb szintű dedikált tárolórendszerre, drága replikációs funkciókkal és Active-Active adathozzáféréssel két tárolórendszeren.
1. forgatókönyv: Van egy elsődleges és tartalék adatközpontunk, egy virtualizációs platformunk a VMware vSphere-en. Minden produktív rendszer a fő adatközpontban található, és a virtuális gépek replikációja hypervisor szinten történik, így elkerülhető, hogy a virtuális gépek bekapcsolva maradjanak a biztonsági mentési adatközpontban. Adatbázisokat és speciális alkalmazásokat replikálunk beépített eszközökkel, és bekapcsolva tartjuk a virtuális gépeket. Ha a fő adatközpont meghibásodik, rendszereket indítunk el a tartalék adatközpontban. Úgy gondoljuk, hogy körülbelül 100 virtuális gépünk van. Amíg az elsődleges adatközpont működik, a készenléti adatközpont tesztkörnyezeteket és más rendszereket futtathat, amelyek leállíthatók, ha az elsődleges adatközpont átvált. Az is lehetséges, hogy kétirányú replikációt használunk. Hardveres szempontból semmi sem fog változni.
Klasszikus architektúra esetén minden adatközpontba egy hibrid tárolórendszert telepítünk FibreChannel hozzáféréssel, rétegzéssel, deduplikációval és tömörítéssel (de nem online), oldalanként 8 szervert, 2 FibreChannel switchet és 10G Ethernetet. A klasszikus architektúra replikáció- és váltáskezeléséhez használhatunk VMware eszközöket (Replication + SRM) vagy harmadik féltől származó eszközöket, amelyek kicsit olcsóbbak és néha kényelmesebbek.
Az ábra a diagramot mutatja.
A Cisco HyperFlex használatakor a következő architektúra érhető el:
A HyperFlexhez nagy CPU/RAM erőforrásokkal rendelkező szervereket használtam, mert... Az erőforrások egy része a HyperFlex vezérlő virtuális gépét kapja, a CPU és a memória tekintetében még a HyperFlex konfigurációt is átkonfiguráltam egy kicsit, hogy ne játsszam együtt a Ciscóval, és erőforrásokat garantáljak a fennmaradó virtuális gépek számára. De elhagyhatjuk a FibreChannel switcheket, és nem lesz szükségünk Ethernet portokra minden szerverhez, a helyi forgalom az FI-n belül történik.
Az eredmény a következő konfiguráció volt minden adatközponthoz:
Kiszolgálók
8 x 1U szerver (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
Hibrid tárolórendszer FC Front-Enddel (20 TB SSD, 130 TB NL-SAS)
-
LAN
2 x Ethernet switch 10G 12 port
-
SAN
2 x FC switch 32/16Gb 24 port
2 x Cisco UCS FI 6332
Engedélyek
VMware Ent Plus
Virtuálisgép-váltás replikációja és/vagy hangszerelése
VMware Ent Plus
Nem adtam replikációs szoftverlicencet a Hyperflexhez, mivel ez már a dobozból is elérhető számunkra.
A klasszikus építészethez olyan eladót választottam, aki kiváló minőségű és olcsó gyártóvá vált. Mindkét lehetőségnél egy adott megoldásnál érvényesítettem a standard kedvezményt, és ennek eredményeként valós árakat kaptam.
A Cisco HyperFlex megoldás 13%-kal olcsóbbnak bizonyult.
2. forgatókönyv: két aktív adatközpont létrehozása. Ebben a forgatókönyvben egy kiterjesztett fürtöt tervezünk a VMware-en.
A klasszikus architektúra virtualizációs szerverekből, SAN-ból (FC protokoll) és két tárolórendszerből áll, amelyek képesek olvasni és írni a közöttük lévő kötetre. Minden tárolórendszeren hasznos tárolási kapacitást helyezünk el.
A HyperFlexnél egyszerűen létrehozunk egy Stretch Cluster-t, mindkét oldalon azonos számú csomóponttal. Ebben az esetben 2+2 replikációs tényezőt használunk.
Az eredmény a következő konfiguráció:
klasszikus építészet
HyperFlex
Kiszolgálók
16 x 1U szerver (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 tárolórendszer (150 TB SSD)
-
LAN
4 x Ethernet switch 10G 24 port
-
SAN
4 x FC switch 32/16Gb 24 port
4 x Cisco UCS FI 6332
Engedélyek
VMware Ent Plus
VMware Ent Plus
Minden számításnál nem vettem figyelembe a hálózati infrastruktúrát, adatközponti költségeket stb.: a klasszikus architektúránál és a HyperFlex megoldásnál is ugyanazok lesznek.
Költség szempontjából a HyperFlex 5%-kal drágábbnak bizonyult. Itt érdemes megjegyezni, hogy a CPU/RAM erőforrások tekintetében ferdítésem volt a Cisco-nál, mert a konfigurációban egyenletesen töltöttem ki a memóriavezérlő csatornáit. A költség valamivel magasabb, de nem egy nagyságrenddel, ami egyértelműen jelzi, hogy a hiperkonvergencia nem feltétlenül „játékszer a gazdagok számára”, hanem felveheti a versenyt az adatközpont-építés szokásos megközelítésével. Ez azok számára is érdekes lehet, akik már rendelkeznek Cisco UCS-szerverekkel és a hozzájuk tartozó infrastruktúrával.
Az előnyök között szerepel a SAN és a tárolórendszerek adminisztrációs költségeinek hiánya, az online tömörítés és duplikáció, a támogatás egyetlen belépési pontja (virtualizáció, szerverek, ezek is tárolórendszerek), a helytakarékosság (de nem minden esetben), a működés egyszerűsítése.
Ami a támogatást illeti, itt egy szállítótól kapja – a Cisco-tól. A Cisco UCS szerverekkel kapcsolatos tapasztalataim alapján tetszik, nem kellett HyperFlexen megnyitnom, minden ugyanúgy működött. A mérnökök gyorsan reagálnak, és nem csak a tipikus problémákat, hanem az összetett szélsőséges eseteket is meg tudják oldani. Néha kérdésekkel fordulok hozzájuk: „Meg lehet ezt csinálni, csavarja fel?” vagy „Itt konfiguráltam valamit, és nem akar működni. Segítség!" - ott türelmesen megtalálják a szükséges útmutatót és rámutatnak a helyes cselekvésekre, nem válaszolnak: „Csak hardverproblémákat oldunk meg.”
referenciák
- Levelem - [e-mail védett]
Forrás: will.com