Ky është një mit mjaft i zakonshëm në fushën e harduerit të serverit. Në praktikë, zgjidhjet hiperkonvergjente (kur gjithçka është në një) nevojiten për shumë gjëra. Historikisht, arkitekturat e para u zhvilluan nga Amazon dhe Google për shërbimet e tyre. Më pas ideja ishte të krijonim një fermë kompjuterike nga nyje identike, secila prej të cilave kishte disqet e veta. E gjithë kjo u bashkua nga disa softuer formues të sistemit (hipervizor) dhe u nda në makina virtuale. Qëllimi kryesor është një minimum përpjekjeje për shërbimin e një nyje dhe një minimum problemesh gjatë shkallëzimit: thjesht blini një mijë ose dy serverë të tjerë të njëjtë dhe lidhini ata afër. Në praktikë, këto janë raste të izoluara, dhe shumë më shpesh flasim për një numër më të vogël nyjesh dhe një arkitekturë paksa të ndryshme.
Por plusi mbetet i njëjtë - lehtësia e jashtëzakonshme e shkallëzimit dhe menaxhimit. E keqja është se detyra të ndryshme konsumojnë burime ndryshe, dhe në disa vende do të ketë shumë disqe lokale, në të tjera do të ketë pak RAM, e kështu me radhë, domethënë për lloje të ndryshme detyrash, përdorimi i burimeve do të ulet.
Rezulton se ju paguani 10–15% më shumë për lehtësinë e konfigurimit. Kjo është ajo që ndezi mitin në titull. Kemi kaluar një kohë të gjatë duke kërkuar se ku do të aplikohej në mënyrë optimale teknologjia dhe e gjetëm atë. Fakti është se Cisco nuk kishte sistemet e veta të ruajtjes, por ata donin një treg të plotë të serverëve. Dhe ata bënë Cisco Hyperflex - një zgjidhje me ruajtje lokale në nyje.
Dhe kjo papritmas doli të ishte një zgjidhje shumë e mirë për qendrat e të dhënave rezervë (Rimëkëmbja e fatkeqësive). Unë do t'ju tregoj pse dhe si tani. Dhe unë do t'ju tregoj testet e grupit.
Aty ku duhet
Hiperkonvergjenca është:
- Transferimi i disqeve në nyjet llogaritëse.
- Integrimi i plotë i nënsistemit të ruajtjes me nënsistemin e virtualizimit.
- Transferimi/integrimi me nënsistemin e rrjetit.
Ky kombinim ju lejon të implementoni shumë veçori të sistemit të ruajtjes në nivelin e virtualizimit dhe të gjitha nga një dritare kontrolli.
Në kompaninë tonë, projektet për të hartuar qendra të tepërta të të dhënave janë në kërkesë të madhe dhe shpesh zgjidhet një zgjidhje hiperkonverguese për shkak të një sërë opsionesh replikimi (deri në një metrocluster) jashtë kutisë.
Në rastin e qendrave të të dhënave rezervë, zakonisht flasim për një strukturë të largët në një vend në anën tjetër të qytetit ose në një qytet tjetër krejtësisht. Kjo ju lejon të rivendosni sistemet kritike në rast të një dështimi të pjesshëm ose të plotë të qendrës kryesore të të dhënave. Të dhënat e shitjeve përsëriten vazhdimisht atje, dhe ky përsëritje mund të jetë në nivelin e aplikacionit ose në nivelin e pajisjes së bllokut (ruajtjes).
Prandaj, tani do të flas për dizajnin dhe testet e sistemit, dhe më pas për disa skenarë të aplikacioneve në jetën reale me të dhëna kursimi.
testet
Shembulli ynë përbëhet nga katër serverë, secili prej të cilëve ka 10 disqe SSD me 960 GB. Ekziston një disk i dedikuar për ruajtjen e operacioneve të shkrimit në memorie dhe ruajtjen e makinës virtuale të shërbimit. Vetë zgjidhja është versioni i katërt. E para është sinqerisht e papërpunuar (duke gjykuar nga rishikimet), e dyta është e lagësht, e treta tashmë është mjaft e qëndrueshme dhe kjo mund të quhet një lëshim pas përfundimit të testimit beta për publikun e gjerë. Gjatë testimit nuk pashë asnjë problem, gjithçka funksionon si një orë.
Ndryshimet në v4Një mori gabimesh janë rregulluar.
Fillimisht, platforma mund të punonte vetëm me hipervizorin VMware ESXi dhe mbështeti një numër të vogël nyjesh. Gjithashtu, procesi i vendosjes nuk përfundoi gjithmonë me sukses, disa hapa duhej të rifilloheshin, kishte probleme me përditësimin nga versionet më të vjetra, të dhënat në GUI nuk shfaqeshin gjithmonë si duhet (megjithëse ende nuk jam i kënaqur me shfaqjen e grafikëve të performancës ), ndonjëherë lindnin probleme në ndërfaqen me virtualizimin.
Tani të gjitha problemet e fëmijërisë janë rregulluar, HyperFlex mund të trajtojë si ESXi ashtu edhe Hyper-V, plus është e mundur që:
- Krijimi i një grupi të shtrirë.
- Krijimi i një grupi për zyra pa përdorur Fabric Interconnect, nga dy deri në katër nyje (ne blejmë vetëm serverë).
- Aftësia për të punuar me sistemet e ruajtjes së jashtme.
- Mbështetje për kontejnerët dhe Kubernetes.
- Krijimi i zonave të disponueshmërisë.
- Integrimi me VMware SRM nëse funksionaliteti i integruar nuk është i kënaqshëm.
Arkitektura nuk është shumë e ndryshme nga zgjidhjet e konkurrentëve të saj kryesorë; ata nuk krijuan një biçikletë. E gjitha funksionon në platformën e virtualizimit VMware ose Hyper-V. Pajisja është e pritur në serverë të pronarit Cisco UCS. Ka nga ata që e urrejnë platformën për kompleksitetin relativ të konfigurimit fillestar, shumë butona, një sistem jo të parëndësishëm shabllonesh dhe varësish, por ka edhe nga ata që kanë mësuar Zen, janë frymëzuar nga ideja dhe nuk duan më. për të punuar me serverë të tjerë.
Ne do të shqyrtojmë zgjidhjen për VMware, pasi zgjidhja u krijua fillimisht për të dhe ka më shumë funksionalitet; Hyper-V u shtua gjatë rrugës për të vazhduar me konkurrentët dhe për të përmbushur pritjet e tregut.
Ekziston një grup serverësh plot me disqe. Ka disqe për ruajtjen e të dhënave (SSD ose HDD - sipas shijes dhe nevojave tuaja), ekziston një disk SSD për memorie. Kur shkruani të dhëna në dyqanin e të dhënave, të dhënat ruhen në shtresën e memories (disku i dedikuar SSD dhe RAM-i i shërbimit VM). Paralelisht, një bllok i të dhënave u dërgohet nyjeve në grup (numri i nyjeve varet nga faktori i replikimit të grupit). Pas konfirmimit nga të gjitha nyjet për regjistrimin e suksesshëm, konfirmimi i regjistrimit dërgohet te hipervizori dhe më pas te VM. Të dhënat e regjistruara çkopjohen, kompresohen dhe shkruhen në disqet e ruajtjes në sfond. Në të njëjtën kohë, një bllok i madh shkruhet gjithmonë në disqet e ruajtjes dhe në mënyrë sekuenciale, gjë që zvogëlon ngarkesën në disqet e ruajtjes.
Deduplikimi dhe kompresimi janë gjithmonë të aktivizuara dhe nuk mund të çaktivizohen. Të dhënat lexohen drejtpërdrejt nga disqet e ruajtjes ose nga memoria e RAM-it. Nëse përdoret një konfigurim hibrid, leximet ruhen gjithashtu në SSD.
Të dhënat nuk janë të lidhura me vendndodhjen aktuale të makinës virtuale dhe shpërndahen në mënyrë të barabartë midis nyjeve. Kjo qasje ju lejon të ngarkoni të gjithë disqet dhe ndërfaqet e rrjetit në mënyrë të barabartë. Ekziston një disavantazh i dukshëm: ne nuk mund ta zvogëlojmë vonesën e leximit sa më shumë që të jetë e mundur, pasi nuk ka asnjë garanci për disponueshmërinë e të dhënave në nivel lokal. Por besoj se kjo është një sakrificë e vogël në krahasim me përfitimet e marra. Për më tepër, vonesat në rrjet kanë arritur vlera të tilla që praktikisht nuk ndikojnë në rezultatin e përgjithshëm.
Një kontrollues i posaçëm i shërbimit VM Cisco HyperFlex të Platformës së të Dhënave, i cili krijohet në çdo nyje ruajtëse, është përgjegjës për të gjithë logjikën e funksionimit të nënsistemit të diskut. Në konfigurimin tonë të VM të shërbimit, u ndanë tetë vCPU dhe 72 GB RAM, që nuk është aq pak. Më lejoni t'ju kujtoj se vetë hosti ka 28 bërthama fizike dhe 512 GB RAM.
Shërbimi VM ka akses në disqe fizike direkt duke përcjellë kontrolluesin SAS te VM. Komunikimi me hipervizorin ndodh përmes një moduli të veçantë IOVisor, i cili përgjon operacionet I/O, dhe duke përdorur një agjent që ju lejon të dërgoni komanda në API të hipervizorit. Agjenti është përgjegjës për punën me fotografitë dhe klonet e HyperFlex.
Burimet e diskut montohen në hipervizor si NFS ose SMB aksione (në varësi të llojit të hipervizorit, mendoni se cili është vendi). Dhe nën kapuç, ky është një sistem skedari i shpërndarë që ju lejon të shtoni veçori të sistemeve të ruajtjes me të drejta të plota për të rritur: shpërndarjen e volumit të hollë, ngjeshjen dhe heqjen e dyfishimit, fotografi duke përdorur teknologjinë Redirect-on-Write, përsëritje sinkron/asinkron.
Shërbimi VM ofron akses në ndërfaqen e menaxhimit WEB të nënsistemit HyperFlex. Ekziston një integrim me vCenter dhe shumica e detyrave të përditshme mund të kryhen prej tij, por dyqanet e të dhënave, për shembull, janë më të përshtatshme për t'u prerë nga një kamerë e veçantë në internet nëse tashmë keni kaluar në një ndërfaqe të shpejtë HTML5 ose përdorni një klient të plotë Flash me integrim të plotë. Në kamerën e internetit të shërbimit mund të shikoni performancën dhe statusin e detajuar të sistemit.
Ekziston një lloj tjetër nyjesh në një grup - nyjet kompjuterike. Këta mund të jenë serverë rack ose blade pa disqe të integruar. Këta serverë mund të ekzekutojnë VM të dhënat e të cilave ruhen në serverë me disqe. Nga pikëpamja e aksesit të të dhënave, nuk ka dallim midis llojeve të nyjeve, sepse arkitektura përfshin abstraksion nga vendndodhja fizike e të dhënave. Raporti maksimal i nyjeve llogaritëse ndaj nyjeve të ruajtjes është 2:1.
Përdorimi i nyjeve llogaritëse rrit fleksibilitetin gjatë shkallëzimit të burimeve të grupimit: nuk kemi nevojë të blejmë nyje shtesë me disqe nëse kemi nevojë vetëm për CPU/RAM. Përveç kësaj, ne mund të shtojmë një kafaz teh dhe të kursejmë në vendosjen e rafteve të serverëve.
Si rezultat, ne kemi një platformë hiperkonvergjente me karakteristikat e mëposhtme:
- Deri në 64 nyje në një grup (deri në 32 nyje ruajtëse).
- Numri minimal i nyjeve në një grup është tre (dy për një grupim Edge).
- Mekanizmi i tepricës së të dhënave: pasqyrimi me faktorin e përsëritjes 2 dhe 3.
- Grupi i metrosë.
- Replikimi asinkron i VM-së në një grup tjetër HyperFlex.
- Orkestrimi i kalimit të VM-ve në një qendër të largët të të dhënave.
- Fotot origjinale duke përdorur teknologjinë Redirect-on-Write.
- Deri në 1 PB hapësirë të përdorshme në faktorin e riprodhimit 3 dhe pa dedublikim. Ne nuk marrim parasysh faktorin e përsëritjes 2, sepse ky nuk është një opsion për shitje serioze.
Një tjetër plus i madh është lehtësia e menaxhimit dhe vendosjes. Të gjitha kompleksitetet e konfigurimit të serverëve UCS kujdesen nga një VM e specializuar e përgatitur nga inxhinierët Cisco.
Konfigurimi i stolit të provës:
- 2 x Cisco UCS Fabric Interconnect 6248UP si një grup menaxhimi dhe komponentë rrjeti (48 porte që funksionojnë në modalitetin Ethernet 10G/FC 16G).
- Katër serverë Cisco UCS HXAF240 M4.
Karakteristikat e serverit:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/rang i dyfishtë/x4/1.2v
Rrjet
UCSC-MLOM-CSC-02 (VIC 1227). 2 porte Ethernet 10G
Magazinimi HBA
Cisco 12G Modular SAS Kaloni përmes kontrolluesit
Disqet e ruajtjes
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Më shumë opsione konfigurimiPërveç harduerit të zgjedhur, aktualisht janë të disponueshme opsionet e mëposhtme:
- HXAF240c M5.
- Një ose dy CPU që variojnë nga Intel Silver 4110 në Intel Platinum I8260Y. Gjenerata e dytë në dispozicion.
- 24 fole memorie, shirita nga 16 GB RDIMM 2600 deri në 128 GB LRDIMM 2933.
- Nga 6 deri në 23 disqe të dhënash, një disk memorie, një disk sistemi dhe një disk boot.
Disqet e kapacitetit
- HX-SD960G61X-EV 960 GB 2.5 inç Vlera e ndërmarrjes 6G SATA SSD (1X qëndrueshmëri) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 inç Vlera e ndërmarrjes 6G SATA SSD (1X qëndrueshmëri) SAS 3.8 TB.
- Memoria e disqeve
- HX-NVMEXPB-I375 375 GB 2.5 inç Intel Optane Drive, Perf dhe qëndrueshmëri ekstreme.
- HX-NVMEHW-H1600* 1.6 TB 2.5 inç Ent. Perf. NVMe SSD (qëndrueshmëri 3X) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 inç Ent. Perf. 12G SAS SSD (10X qëndrueshmëri) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 inç Ent. Perf. 12G SAS SED SSD (10X qëndrueshmëri) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 inç Performanca e ndërmarrjes 12G SAS SSD (qëndrueshmëri 3X).
Disqet e sistemit/log
- HX-SD240GM1X-EV 240 GB 2.5 inç Vlera e ndërmarrjes 6G SATA SSD (Kërkon përmirësim).
Disqet e nisjes
- HX-M2-240 GB 240 GB SATA M.2 SSD SATA 240 GB.
Lidhu me rrjetin nëpërmjet portave Ethernet 40G, 25G ose 10G.
FI mund të jetë HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Vetë testi
Për të testuar nënsistemin e diskut, përdora HCIBench 2.2.1. Ky është një mjet falas që ju lejon të automatizoni krijimin e një ngarkese nga shumë makina virtuale. Ngarkesa në vetvete gjenerohet nga fio e zakonshme.
Grupi ynë përbëhet nga katër nyje, faktori i replikimit 3, të gjithë disqet janë Flash.
Për testim, unë krijova katër dyqane të dhënash dhe tetë makina virtuale. Për testet e shkrimit, supozohet se disku i memorizimit nuk është i plotë.
Rezultatet e testit janë si më poshtë:
100% e lexuar 100% e rastësishme
0% Lexuar 100% Rastësisht
Thellësia e bllokut/radhës
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 tregon vlerat pas të cilave nuk ka rritje të produktivitetit, ndonjëherë edhe degradimi është i dukshëm. Kjo për faktin se jemi të kufizuar nga performanca e rrjetit/kontrolluesve/disqeve.
- Leximi sekuencial 4432 MB/s.
- Shkrimi sekuencial 804 MB/s.
- Nëse një kontrollues dështon (dështimi i një makinerie virtuale ose hosti), rënia e performancës është e dyfishtë.
- Nëse disku i ruajtjes dështon, tërheqja është 1/3. Rindërtimi i diskut merr 5% të burimeve të secilit kontrollues.
Në një bllok të vogël, ne jemi të kufizuar nga performanca e kontrolluesit (makina virtuale), CPU-ja e saj ngarkohet në 100%, dhe kur blloku rritet, ne jemi të kufizuar nga gjerësia e brezit të portit. 10 Gbps nuk mjaftojnë për të zhbllokuar potencialin e sistemit AllFlash. Fatkeqësisht, parametrat e stendës demo të ofruar nuk na lejojnë të testojmë funksionimin me 40 Gbit/s.
Në përshtypjen time nga testet dhe studimi i arkitekturës, për shkak të algoritmit që vendos të dhëna midis të gjithë hosteve, marrim performancë të shkallëzueshme, të parashikueshme, por ky është gjithashtu një kufizim gjatë leximit, sepse do të ishte e mundur të shtrydhte më shumë nga disqet lokale, këtu mund të kursejë një rrjet më produktiv, për shembull, disponohet FI me 40 Gbit/s.
Gjithashtu, një disk për caching dhe deduplication mund të jetë një kufizim; në fakt, në këtë shtrat testimi mund të shkruajmë në katër disqe SSD. Do të ishte mirë të rrisni numrin e disqeve të memorizimit dhe të shihni ndryshimin.
Përdorimi i vërtetë
Për të organizuar një qendër të dhënash rezervë, mund të përdorni dy mënyra (ne nuk e konsiderojmë vendosjen e një kopje rezervë në një sajt të largët):
- Aktiv-Pasiv. Të gjitha aplikacionet janë të pritura në qendrën kryesore të të dhënave. Replikimi është sinkron ose asinkron. Nëse qendra kryesore e të dhënave dështon, duhet të aktivizojmë atë rezervë. Kjo mund të bëhet manualisht/skriptet/aplikacionet orkestruese. Këtu do të marrim një RPO në përpjesëtim me frekuencën e riprodhimit, dhe RTO varet nga reagimi dhe aftësitë e administratorit dhe cilësia e zhvillimit/debugimit të planit të ndërrimit.
- Aktiv-Aktiv. Në këtë rast, ka vetëm përsëritje sinkron; disponueshmëria e qendrave të të dhënave përcaktohet nga një kuorum/arbitër i vendosur rreptësisht në faqen e tretë. RPO = 0, dhe RTO mund të arrijë 0 (nëse aplikacioni lejon) ose e barabartë me kohën e dështimit të një nyje në një grup virtualizimi. Në nivelin e virtualizimit, krijohet një grup i shtrirë (Metro) që kërkon ruajtje Active-Active.
Zakonisht shohim që klientët tashmë kanë implementuar një arkitekturë me një sistem ruajtjeje klasike në qendrën kryesore të të dhënave, kështu që ne projektojmë një tjetër për replikim. Siç e përmenda, Cisco HyperFlex ofron replikim asinkron dhe krijimin e një grupi të shtrirë të virtualizimit. Në të njëjtën kohë, ne nuk kemi nevojë për një sistem ruajtjeje të dedikuar të nivelit të mesëm dhe më të lartë me funksione të shtrenjta të riprodhimit dhe akses të të dhënave Active-Active në dy sisteme ruajtjeje.
Skenari 1: Ne kemi një qendër të dhënash primare dhe rezervë, një platformë virtualizimi në VMware vSphere. Të gjitha sistemet prodhuese janë të vendosura në qendrën kryesore të të dhënave dhe riprodhimi i makinave virtuale kryhet në nivelin e hipervizorit, kjo do të shmangë mbajtjen e VM-ve të ndezura në qendrën e të dhënave rezervë. Ne përsërisim bazat e të dhënave dhe aplikacionet speciale duke përdorur mjete të integruara dhe i mbajmë të ndezur VM-të. Nëse qendra kryesore e të dhënave dështon, ne lëshojmë sisteme në qendrën e të dhënave rezervë. Besojmë se kemi rreth 100 makina virtuale. Ndërsa qendra kryesore e të dhënave është funksionale, qendra e të dhënave në pritje mund të ekzekutojë mjedise testimi dhe sisteme të tjera që mund të mbyllen nëse qendra kryesore e të dhënave ndërrohet. Është gjithashtu e mundur që të përdorim përsëritjen e dyanshme. Nga pikëpamja harduerike, asgjë nuk do të ndryshojë.
Në rastin e arkitekturës klasike, ne do të instalojmë në çdo qendër të dhënash një sistem ruajtjeje hibride me akses nëpërmjet FibreChannel, nivele, dedublikim dhe kompresim (por jo online), 8 serverë për çdo faqe, 2 ndërprerës FibreChannel dhe 10G Ethernet. Për menaxhimin e riprodhimit dhe ndërrimit në një arkitekturë klasike, ne mund të përdorim mjete VMware (Replication + SRM) ose mjete të palëve të treta, të cilat do të jenë pak më të lira dhe ndonjëherë më të përshtatshme.
Figura tregon diagramin.
Kur përdorni Cisco HyperFlex, merret arkitektura e mëposhtme:
Për HyperFlex, kam përdorur serverë me burime të mëdha CPU/RAM, sepse... Disa nga burimet do të shkojnë në kontrolluesin HyperFlex VM; për sa i përket CPU-së dhe kujtesës, unë madje e rikonfigurova pak konfigurimin HyperFlex në mënyrë që të mos luaj së bashku me Cisco dhe të garantoj burime për VM-të e mbetura. Por ne mund të braktisim ndërprerësit FibreChannel dhe nuk do të kemi nevojë për porte Ethernet për secilin server; trafiku lokal ndërrohet brenda FI.
Rezultati ishte konfigurimi i mëposhtëm për secilën qendër të të dhënave:
Serverat
Server 8 x 1U (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
Sistemi hibrid i ruajtjes me FC Front-End (20 TB SSD, 130 TB NL-SAS)
-
LAN
2 x ndërprerës Ethernet 10G 12 porte
-
SAN
2 x FC switch 32/16Gb 24 porte
2 x Cisco UCS FI 6332
Licencat
VMware Ent Plus
Replikimi dhe/ose orkestrimi i ndërrimit të VM
VMware Ent Plus
Unë nuk ofrova licenca të softuerit të riprodhimit për Hyperflex, pasi kjo është e disponueshme jashtë kutisë për ne.
Për arkitekturën klasike, zgjodha një shitës që është vendosur si një prodhues me cilësi të lartë dhe të lirë. Për të dy opsionet, aplikova zbritjen standarde për një zgjidhje specifike dhe si rezultat mora çmime reale.
Zgjidhja Cisco HyperFlex doli të ishte 13% më e lirë.
Skenari 2: krijimi i dy qendrave aktive të të dhënave. Në këtë skenar, ne po dizajnojmë një grup të shtrirë në VMware.
Arkitektura klasike përbëhet nga serverë virtualizimi, një SAN (FC protokoll) dhe dy sisteme ruajtjeje që mund të lexojnë dhe shkruajnë në vëllimin e shtrirë midis tyre. Në çdo sistem magazinimi vendosim një kapacitet të dobishëm për ruajtje.
Në HyperFlex ne thjesht krijojmë një Stretch Cluster me të njëjtin numër nyjesh në të dy faqet. Në këtë rast, përdoret një faktor replikimi prej 2+2.
Rezultati është konfigurimi i mëposhtëm:
arkitekturës klasike
HyperFlex
Serverat
Server 16 x 1U (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 sisteme ruajtëse AllFlash (150 TB SSD)
-
LAN
4 x ndërprerës Ethernet 10G 24 porte
-
SAN
4 x FC switch 32/16Gb 24 porte
4 x Cisco UCS FI 6332
Licencat
VMware Ent Plus
VMware Ent Plus
Në të gjitha llogaritjet, nuk kam marrë parasysh infrastrukturën e rrjetit, kostot e qendrës së të dhënave, etj.: ato do të jenë të njëjta për arkitekturën klasike dhe për zgjidhjen HyperFlex.
Për sa i përket kostos, HyperFlex doli të ishte 5% më i shtrenjtë. Vlen të përmendet këtu se për sa i përket burimeve të CPU/RAM-it, unë kisha një anim për Cisco-n, sepse në konfigurim i mbusha në mënyrë të barabartë kanalet e kontrolluesit të kujtesës. Kostoja është pak më e lartë, por jo me një renditje të madhësisë, gjë që tregon qartë se hiperkonvergjenca nuk është domosdoshmërisht një "lodër për të pasurit", por mund të konkurrojë me qasjen standarde për ndërtimin e një qendre të dhënash. Kjo mund të jetë gjithashtu me interes për ata që tashmë kanë serverë Cisco UCS dhe infrastrukturën përkatëse për ta.
Ndër avantazhet, marrim mungesën e kostove për administrimin e SAN dhe sistemeve të ruajtjes, kompresimin dhe heqjen e dyfishimit në internet, një pikë të vetme hyrëse për mbështetje (virtualizim, serverë, ato janë gjithashtu sisteme ruajtjeje), kursim i hapësirës (por jo në të gjithë skenarët), duke thjeshtuar funksionimin.
Sa i përket mbështetjes, këtu e merrni nga një shitës - Cisco. Duke gjykuar nga përvoja ime me serverët Cisco UCS, më pëlqen; nuk më duhej ta hapja në HyperFlex, gjithçka funksionoi njësoj. Inxhinierët përgjigjen menjëherë dhe mund të zgjidhin jo vetëm probleme tipike, por edhe raste komplekse. Ndonjëherë u drejtohem atyre me pyetje: "A është e mundur ta bëni këtë, vidhosni?" ose "Kam konfiguruar diçka këtu dhe nuk dëshiron të funksionojë. Ndihmë!" - ata do të gjejnë me durim udhëzuesin e nevojshëm atje dhe do të tregojnë veprimet e sakta; ata nuk do të përgjigjen: "Ne zgjidhim vetëm probleme harduerike".
Referencat
- Posta ime - [email mbrojtur]
Burimi: www.habr.com