Ky Ă«shtĂ« njĂ« mit, mjaft i pĂ«rhapur nĂ« fushĂ«n e harduerit tĂ« serverit. NĂ« praktikĂ«, megjithatĂ«, zgjidhjet hiperkonvergjente (kur gjithçka Ă«shtĂ« nĂ« njĂ«) janĂ« tĂ« nevojshme pĂ«r shumĂ« arsye. Historikisht, arkitekturat e para u zhvilluan nga Amazon dhe Google pĂ«r shĂ«rbimet e tyre. AtĂ«herĂ«, ideja ishte tĂ« krijohej njĂ« fermĂ« llogaritĂ«se nga nyje tĂ« ngjashme, tĂ« çdo njĂ«ra prej tĂ« cilave kishte hard diskĂ«t e saj. TĂ« gjitha kĂ«to bashkoheshin me njĂ« softuer sistemor (hipervizor) dhe ndaheshin mĂ« tej nĂ« makina virtuale. QĂ«llimi kryesor â minimumi i pĂ«rpjekjeve pĂ«r mirĂ«mbajtjen e njĂ« nyje dhe minimumi i problemeve gjatĂ« shkallĂ«zimit: thjesht blenĂ« njĂ« mijĂ« ose dy tĂ« tjera tĂ« tilla dhe i lidhnin ngjitur. NĂ« praktikĂ«, kjo Ă«shtĂ« njĂ«ndjike, dhe mĂ« shpesh flitet pĂ«r njĂ« numĂ«r mĂ« tĂ« vogĂ«l nyjesh dhe njĂ« arkitekturĂ« pak mĂ« ndryshe.
Por pĂ«rfitimi mbetet i njĂ«jtĂ« â thjeshtĂ«sia e jashtĂ«zakonshme e shkallĂ«zimit dhe menaxhimit. MangĂ«sia â detyra tĂ« ndryshme konsumojnĂ« burime nĂ« mĂ«nyrĂ« tĂ« ndryshme, dhe ndonjĂ«herĂ« disa disqe lokale do tĂ« jenĂ« tĂ« shumtĂ«, ndĂ«rsa nĂ« vende tĂ« tjera do tĂ« ketĂ« pak RAM dhe kĂ«shtu me radhĂ«, pra, nĂ« varĂ«si tĂ« llojit tĂ« detyrave, do tĂ« ketĂ« rĂ«nie tĂ« shfrytĂ«zimit tĂ« burimeve.
KĂ«shtu doli qĂ« po paguanit 10-15% mĂ« shumĂ« pĂ«r lehtĂ«sinĂ« e konfigurimit. Ky Ă«shtĂ« edhe miti nga titulli. Kemi kĂ«rkuar pĂ«r njĂ« kohĂ« tĂ« gjatĂ« se ku do tĂ« aplikohej shkĂ«lqyeshĂ«m teknologjia dhe e gjetĂ«m. Problemi Ă«shtĂ« se Cisco nuk kishte sistemet e tij tĂ« ruajtjes, por ata donin tĂ« ishin tĂ« pranishĂ«m nĂ« tĂ«rĂ« tregun e serverĂ«ve. Prandaj krijuan Cisco Hyperflex â njĂ« zgjidhje me depozita lokale nĂ« nyje.
Dhe nga kjo papritur doli njĂ« zgjidhje shumĂ« e mirĂ« pĂ«r qendrat e tĂ« dhĂ«nave rezervĂ« (Disaster Recovery). Pse dhe si â tani do t'ju tregoj. Dhe do tĂ« tregoj testet e klasterit.
Ku është e nevojshme
Hiperkonvergenca është:
- Transferimi i disqeve në nyjet kompjuterike.
- Integrimi i plotë i sistemit të ruajtjes së të dhënave me sistemin e virtualizimit.
- Transferimi/integrimi me sistemin rrjetor.
Kjo lidhje lejon realizimin e shumë funksioneve të sistemit të ruajtjes në nivelin e virtualizimit dhe gjithçka nga një dritare menaxhimi.
Në kompaninë tonë, projektet për projektimin e qendrave të të dhënave rezervë janë shumë të kërkuara, dhe shpesh zgjidhet pikërisht zgjidhja hiperkonvergente për shkak të shumë mundësive për replikim (deri në metroklauster) nga kutia.
Në rastin e qendrave të të dhënave rezervë, zakonisht flitet për një objekt të largët në një vend tjetër në qytet ose madje në një qytet tjetër. Ai lejon rikthimin e sistemeve kritike në rast të dështimit të pjesshëm ose të plotë të qendrës kryesore të të dhënave. Të dhënat nga prodhimi replikohen vazhdimisht aty, dhe kjo replikim mund të jetë në nivelin e aplikacionit ose në nivelin e një pajisjeje bllokuese (SHTD).
Prandaj, tani do të flas për strukturën e sistemit dhe testet, dhe pastaj për disa skenarë të aplikimit të vërtetë me të dhëna mbi kursimet.
Testet
Eksemplari ynë përbëhet nga katër serverë, të cilët kanë nga 10 disqe SSD me kapacitet 960 GB secili. Ka një disk të dedikuar për keshimin e operacioneve të shkruara dhe ruajtjen e makinës virtuale shërbyese. Zgjidhja është versioni i katërt. Versioni i parë ishte hapur (sipas komenteve), i dyti ishte i papjekur, i treti ishte mjaft stabil, dhe këtë mund ta quajmë lëshim pas përfundimit të testit beta me një audiencë të gjerë. Gjatë testimit nuk kam parë probleme, gjithçka funksionon siç duhet.
Ndryshimet në v4Përmirësuar një grumbull gabimesh.
Në fillim, plataforma mund të funksiononte vetëm me hipervizorin VMware ESXi dhe mbështeste një numër të vogël nodash. Gjithashtu, procesi i vendosjes nuk përfundonte gjithmonë me sukses, duke detyruar ri-fillimin e disa hapave, kishim probleme me azhurnimet nga versionet e vjetra, dhe të dhënat në GUI shpesh nuk shfaqeshin saktë (ndonëse edhe tani nuk jam i kënaqur me vizatimet e performancës), ndonjëherë ishin probleme në prehjen me virtualizimin.
Tani të gjitha dobësitë e fëmijërisë janë korrigjuar, HyperFlex mbështet dhe ESXi, dhe Hyper-V, plus është e mundur:
- Krijimi i një klasteri të shtrirë.
- Krijimi i një klasteri për zyra pa përdorur Fabric Interconnect, nga dy në katër nodë (blejmë vetëm serverë).
- Mundësia për të punuar me ruajtëse të jashtme të të dhënave.
- Mbështetje për kontejnerët dhe Kubernetes.
- Krijimi i zonave të aksesit.
- Integrimi me VMware SRM, nëse funksionaliteti i integruar nuk është i mjaftueshëm.
Arkitektura nuk ndryshon ndjeshëm nga zgjidhjet e konkurrentëve kryesorë; nuk kemi rikrijuar ruletën. Të gjitha funksionon në platformën e virtualizimit VMware ose Hyper-V. Hardware vendoset në serverët e zhvilluar vetë nga Cisco UCS. Ka ata që e urrejnë këtë platformë për kompleksitetin e saj fillestar, numrin e madh të butonave, sistemin e ndërlikuar të shablloneve dhe varësive, por ka edhe ata që kanë arritur zenin, janë përthithur nga ideja dhe nuk duan të punojnë më me servera të tjerë.
Ne do të shqyrtojmë zgjidhjen për VMware, sepse zgjidhja është krijuar fillimisht për të dhe ka funksionalitet më të madh; Hyper-V është përmirësuar gjatë rrugës në mënyrë që të mos mbetet pas konkurrentëve dhe për t'u përputhur me pritjet e tregut.
Ka një klaster serverash të mbushura me disqe. Ka disqe për ruajtjen e të dhënave (SSD ose HDD - sipas dëshirës dhe nevojave tuaja), dhe ka një disq të vetëm SSD për keqstrimin. Kur shkruhen të dhënat në datastore, ndodh ruajtja e të dhënave në slojin e keqstrimit (disku SSD i dedikuar dhe RAM e VM-së shërbimit). Paralelisht, blloku i të dhënave dërgohet në node-t në klaster (numri i node-ve varet nga faktorët e replikimit të klasterit). Pasi të konfirmohet nga të gjitha node-t për shkruan e suksesshme, konfirmimi i shkruan dërgohet në hipervizor dhe më pas - në VM. Të dhënat e shkruara në sfond dedupplikohen, kompresohen dhe shkruhen në disqet e ruajtjes. Në këtë proces, gjithmonë shkruhet një bllok i madh në mënyrë sekondare, duke reduktuar ngarkesën mbi disqet e ruajtjes.
Deduplication dhe kompresimi janë gjithmonë aktiv, dhe nuk mund të çaktivizohen. Leximi i të dhënave bëhet drejtpërdrejt nga disqet e ruajtjes ose nga cache RAM. Nëse përdoret një konfigurim hibrid, leximi gjithashtu ruhet në diskun SSD.
Të dhënat nuk janë të lidhura me lokacionin aktual të makinës virtuelle dhe shpërndahen njëlloj midis nodave. Ky qasje lejon ngarkimin e njëjtë të të gjitha disqeve dhe ndërfaqeve rrjet. Një disavantazh i dukshëm është se nuk mund të minimizojmë vonesat në lexim, për shkak se nuk ka garanci për praninë e të dhënave lokal. Megjithatë, unë mendoj se kjo është një sakrifice e vogël krahasuar me avantazhet që marrim. Më shumë, vonesat në rrjet kanë arritur nivele të tilla sa që praktikisht nuk ndikojnë në rezultatet e përgjithshme.
E gjithĂ« logjika e funksionimit tĂ« nĂ«nstrukturĂ«s sĂ« diskĂ«ve Ă«shtĂ« menaxhuar nga njĂ« VM shĂ«rbimi speciale Cisco HyperFlex Data Platform controller, e cila krijohet nĂ« çdo nod tĂ« ruajtjes. NĂ« konfigurimin tonĂ«, VM shĂ«rbimi mori tetĂ« vCPU dhe 72 GB RAM, qĂ« sâĂ«shtĂ« aspak pak. TĂ« rikujtoj se vetĂ« host-i ka 28 bĂ«rthama fizike dhe 512 GB RAM.
Makinë Virtuale Shërbimi ka qasje në disqet fizike direkt përmes kalimit të kontroluesit SAS në VM. Komunikimi me hipervizorin ndodh përmes një moduli të veçantë IOVisor, i cili kap operacionet e hyrjes dhe daljes, si dhe përmes një agjenti që lejon dërgimin e komandave në API-në e hipervizorit. Agjenti është përgjegjës për punën me snapshotet dhe klonët HyperFlex.
Në hipervizor, burimet diskore montohen si ndarëse NFS ose SMB (varet nga tipi i hipervizorit, tregoni se cila është cila). Por nën kapak është një sistem i shpërndarë skedarësh, i cili lejon shtimin e karakteristikave të plota të depove të dhënash: alokim të hollë të volumeve, kompresim dhe deduplikim, snapshotet me teknologjinë Redirect-on-Write, replikim sinkron/asinchron.
MakinĂ« Virtuale ShĂ«rbimi ofron qasje nĂ« ndĂ«rfaqen WEB pĂ«r menaxhimin e sistemit HyperFlex. Ka integrim me vCenter, dhe shumica e detyrave tĂ« pĂ«rditshme mund tĂ« kryhen prej tij, por datastoret, pĂ«r shembull, Ă«shtĂ« mĂ« e lehtĂ« tâi ndajmĂ« nga njĂ« ndĂ«rfaqe e veçantĂ« web nĂ«se keni kaluar nĂ« ndĂ«rfaqen e shpejtĂ« HTML5, ose tĂ« pĂ«rdorni njĂ« klient tĂ« plotĂ« Flash me integrim tĂ« plotĂ«. NĂ« ndĂ«rfaqen e shĂ«rbimit mund tĂ« shihni performancĂ«n dhe statusin e detajuar tĂ« sistemit.
Ekziston edhe njĂ« lloj tjetĂ«r nod nĂ« klaster â nodet pĂ«rpunuese. KĂ«to mund tĂ« jenĂ« serverĂ« regjistrues ose serverĂ« blade pa disqe tĂ« integruar. NĂ« kĂ«to serverĂ« mund tĂ« startojmĂ« VM, tĂ« dhĂ«nat e tĂ« cilave ruhen nĂ« serverĂ«t me disqe. Nga pikĂ«pamja e aksesit nĂ« tĂ« dhĂ«na, nuk ka asnjĂ« ndryshim ndĂ«rmjet llojeve tĂ« nodit, pasi arkitektura parashikon abstragimin nga vendndodhja fizike e tĂ« dhĂ«nave. Raporti maksimal midis nodit pĂ«rpunues dhe nodit tĂ« ruajtjes Ă«shtĂ« 2:1.
Përdorimi i nodëve përpunuese rrit fleksibilitetin gjatë zgjerimit të burimeve të klasterit: nuk është e nevojshme të blejmë nodë me disqe nëse kemi nevojë vetëm për CPU/RAM. Madje, ne mund të shtojmë një sistem rack dhe të fitojmë kursim në vendosjen e serverëve në raft.
Si rezultati, kemi një platformë hiper-konvergjente me funksionalitetet e mëposhtme:
- Derik në 64 nodë në klaster (derik në 32 nodë ruajtjeje).
- Numri minimal i nodëve në klaster është tre (dy për klasterin Edge).
- Mekanizmi i tepricës së të dhënave: pasqyrimi me faktor replikimi 2 dhe 3.
- Metro-klaster.
- Replikimi asinkron i VM në një klaster tjetër HyperFlex.
- Orkestrimi i kalimit të VM në një Qendër të të Dhënave të largët.
- Snapshot natyrore me teknologjinë Redirect-on-Write.
- Deri në 1 PB hapësirë të dobishme me faktor replikimi 3 dhe pa marrë parasysh deduplication. Faktor replikimi 2 nuk është marrë parasysh, pasi nuk është një mundësi për shitje serioze.
Një avantazh tjetër i madh është thjeshtësia e menaxhimit dhe shpërndarjes. Të gjitha Ndërlikimet e konfigurimit të serverëve UCS i merr përsipër një VM e specializuar, e përgatitur nga inxhinierët e Cisco.
Konfigurimi i skenës testuese:
- 2 x Cisco UCS Fabric Interconnect 6248UP si grupi menaxhues dhe komponentët rrjetë (48 porta, që punojnë në mënyrë Ethernet 10G/FC 16G).
- Katër servera Cisco UCS HXAF240 M4.
Karakteristikat e serverëve:
CPU
2 x Intel Âź Xeon Âź E5-2690 v4
RAM
16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/rang dyfish/x4/1.2v
Rrjeti regjistro log /dev/log local0 regjistro log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s përdorues haproxy grup haproxy daemondefaults log global mode http opsion httplog opsion dontlognull timeout connect 5000 timeout client 50000 timeout server 50000frontend http_front bind *:80 stats uri /haproxy?stats default_backend http_backbackend http_back balance roundrobin server server_name1 private_ip1:80 check server server_name2 private_ip2:80 check
UCSC-MLOM-CSC-02 (VIC 1227). 2 porta 10G Ethernet
Storage HBA
Cisco 12G Modular SAS Pass through Controller
Disk të ruajtjes
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Më shumë mundësi konfigurimeshPërveç harduerit të zgjedhur, aktualisht janë të disponueshme opsione të tjera:
- HXAF240c M5.
- Një ose dy CPU duke filluar nga Intel Silver 4110 deri te Intel Platinum I8260Y. E dyta gjeneratë është në dispozicion.
- 24 fole memorje, module nga 16 GB RDIMM 2600 deri te 128 GB LRDIMM 2933.
- Nga 6 deri në 23 disqe për të dhëna, një disk për memorie me shpejtësi, një disk sistemik dhe një disk për nisje.
Diskat e Kapacitetit
- HX-SD960G61X-EV 960GB 2.5 Inch Enterprise Value 6G SATA SSD (1X endurance) SAS 960 GB.
- HX-SD38T61X-EV 3.8TB 2.5 inch Enterprise Value 6G SATA SSD (1X endurance) SAS 3.8 TB.
- Disqetë D caching
- 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 Enterprise performance 12G SAS SSD (3X endurance).
Disqetë / Log
- HX-SD240GM1X-EV 240GB 2.5 inch Enterprise Value 6G SATA SSD (Requires upgrade).
Disqetë Boot
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Connection to the network via 40G, 25G or 10G Ethernet ports.
As FI can be HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Testi vete
Për testimin e nënshkallave disk, kam përdorur HCIBench 2.2.1. Ky është një mjet falas, që lejon automatizimin e krijimit të ngarkesave nga disa makina virtuale. Ngarkesa e vet është gjeneruar nga fio e zakonshme.
Klastri ynë përbëhet nga katër nodet, faktor replikimi 3, të gjithë disqet Flash.
Për testimin kam krijuar katër datastore dhe tetë makina virtuale. Për testet e shkrimit supozohet varianti kur disku caching nuk mbushet.
Rezultatet e testeve janë si në vijim:
100 % Leximi 100 % Rastësor
0 % Leximi 100% Rastësor
Bllok/thellësia e radhës
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36ms 374348 IOPS
2.47 ms 414116 IOPS
4,86ms 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
Vlerat e shënuara me shkronja të trasha tregojnë pas të cilave nuk ka rritje të performancës, ndonjëherë është e dukshme edhe degradimi. Kjo është e lidhur me faktin se përballohemi me performancën e rrjetit/kontrolluesve/disqeve.
- Leximi sekondar 4432 MB/s.
- Shkrimi sekondar 804 MB/s.
- Kur një kontrollues dështon (dështimi i makinës virtuale ose hostit) reduktoni performancën me 50%.
- Kur dështoni diskun e ruajtjes - reduktim prej 1/3. Rindërtimi i një disku zë 5% të burimeve të çdo kontrolluesi.
Në bllokun e vogël, ne hasim një kufizim në performancën e kontrollorit (virtual machine), CPU e tij është e ngarkuar 100%, dhe kur rritet blloku, hasim në kapacitetin e porteve. 10 Gbit/s nuk është e mjaftueshme për të shfrytëzuar potencialin e sistemit AllFlash. Fatkeqësisht, parametrat e demonit të ofruar nuk lejojnë të kontrollojmë funksionimin në 40 Gbit/s.
Sipas përshtypjeve të mia nga testet dhe studimi i arkitekturës, përmes algoritmit që shpërndan të dhënat mes të gjitha hosteve, ne fitojmë një performancë të parashikueshme dhe të shkallëzuar, por kjo është gjithashtu një kufizim gjatë leximit, pasi nga disqet lokale mund të nxjerrim më shumë, këtu mund të na shpëtojë një rrjet më të fuqishëm, për shembull, janë të disponueshme FI në 40 Gbit/s.
Gjithashtu, një disk për caching dhe deduplication mund të jetë një kufizim, faktikisht në këtë stendë ne mund të shkruajmë në katër SSD disqe. Do të ishte e shkëlqyer të kishe mundësinë të rritesh numrin e disqeve që cache-ojnë dhe të shohësh ndryshimin.
PĂ«rdorimi real
Për organizimin e backup-it të Qendrës së të Dhënave, mund të përdoren dy qasje (nuk shqyrtojmë vendosjen e backup-it në një lokacion të largët):
- Aktiv-Pasiv. Të gjitha aplikacionet janë të vendosura në qendrën kryesore të të dhënave. Riprodhimi është sinkron ose asinkron. Në rastin e rënies së qendrës kryesore të të dhënave, duhet të aktivizojmë rezervën. Kjo mund të bëhet manualisht/de bëhet me skripta/aplikacione orkestrimi. Këtu do të arrijmë RPO që është në përputhje me frekuencën e riprodhimit dhe RTO varet nga reagimi dhe aftësitë e administratorit dhe cilësia e përpunimit/disa e planit të kalimit.
- Aktiv-Aktiv. Në këtë rast, ekziston vetëm riprodhim sinkron, disponueshmëria e qendrave të të dhënave përcaktohet nga kuorumi/arbitri, i vendosur në një vend të tretë. RPO = 0, ndërsa RTO mund të arrijë 0 (nëse aplikacioni lejon) ose është e barabartë me kohën për të trajtuar dështimin e nodit në klasterin e virtualizimit. Në nivelin e virtualizimit krijohet një klaster i shtrirë (Metro), që kërkon Active-Active SAN.
Zakonisht shohim te klientët një arkitekturë të realizuar tashmë me një SAN klasike në qendrën kryesore të të dhënave, prandaj projektojmë një tjetër për replikim. Siç e përmenda, Cisco HyperFlex ofron replikim asinkron dhe krijimin e një klasteri të shtrirë të virtualizimit. Në këtë rast, nuk na duhen SAN të nivelit Midrange dhe më lartë me funksione replikimi dhe qasje Active-Active në të dhëna në dy SAN.
Skema 1: Ne kemi një qendër të të dhënave primare dhe një rezervë, si dhe një platformë virtualizimi me VMware vSphere. Të gjitha sistemet produktive ndodhen në qendrën e të dhënave primare, ndërsa replikimi i makinave virtuale bëhet në nivelin e hipervizorit, çka do të thotë se nuk është e nevojshme të mbahen VM-të të aktivizuar në qendrën e të dhënave rezervë. Baza të dhënash dhe aplikacione speciale replikohen me mjete të ndërtuara brenda sistemit dhe mban VM-të të aktivizuar. Në rast të dështimit të qendrës së të dhënave primare, ne aktivizojmë sistemet në qendrën e të dhënave rezervë. Ne llogarisim se kemi rreth 100 makina virtuale. Ndërkohë që qendra e të dhënave primare është aktivizuar, në qendrën e të dhënave rezervë mund të aktivizohen mjedise testuese dhe sisteme të tjera, të cilat mund të çaktivizohen në rast të kalimit në qendrën e të dhënave primare. Gjithashtu, ekziston gjithashtu mundësia e replikimit dypalësh. Nga pikëpamja e aparaturës, asgjë nuk do të ndryshojë.
Në rastin e arkitekturës klasike do të vendosim një ruajtje hibride në çdo Qendër të të Dhënave me qasje përmes FibreChannel, me tiering, deduplication dhe kompresim (por jo në linjë), 8 serverë në çdo lokacion, 2 switch-e FibreChannel dhe Ethernet 10G. Për replikimin dhe menaxhimin e kalimeve në arkitekturën klasike mund të përdorim mjete VMware (Replikimi + SRM) ose mjete të tjera të jashtme, që do të jenë pak më të lira dhe ndonjëherë më të lehta për përdorim.
Në vizatim është paraqitur skema.
Në rastin e Cisco HyperFlex, rezulton kjo arkitekturë:
Për HyperFlex kam përdorur serverë me burime të mëdha CPU/RAM, pasi një pjesë e burimeve do të shkojnë për VM-në e kontrolluesit HyperFlex, madje kam bërë një mbivlerësim të vogël në konfigurimin HyperFlex për CPU dhe memorie, për të mos favorizuar Cisco-n dhe për të garantuar burime për VM-të e tjera. Megjithatë, mund të heqim dorë nga switch-at FibreChannel, dhe nuk do na nevojiten porte Ethernet për çdo server, trafiku lokal komutohet brenda FI.
Si rezultat, arritëm këtë konfigurim për çdo Qendër të të Dhënave:
Serverët
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)
Sistemi i Ruajtjes
Ruajtje hibride me FC Front-End (20TB SSD, 130 TB NL-SAS)
â
LAN
2 x switch Ethernet 10G me 12 porte
â
SAN
2 x FC switch 32/16Gb 24 porte
2 x Cisco UCS FI 6332
Licencat
VMware Ent Plus
Replikimi dhe/orkestrimi i kalimeve VM
VMware Ent Plus
Për Hyperflex nuk kam parashikuar licencat e softuerit të replikimit, pasi kjo është në dispozicion nga kutia.
Për arkitekturën klasike, kam zgjedhur një ofrues që e ka provuar veten si një prodhues cilësor dhe ekonomik. Për të dy variantet kam aplikuar zbritjen standarde për zgjidhjen specifike, duke rezultuar në çmime reale.
Zgjidhja në Cisco HyperFlex doli 13% më e lirë.
Skema 2: krijimi i dy qendrave aktive të të dhënave. Në këtë skemë, ne projektosh një klaster të shtrirë mbi VMware.
Arkitektura klasike përbëhet nga servera virtualizimi, SAN (protokoll FC) dhe dy SHTD që dinë të lexojnë dhe shkruajnë në ate shtrirë mes tyre. Në çdo SHTD parashikojmë kapacitet të dobishëm për lokacione.
Me HyperFlex thjesht krijojmë Cluster të Shtrirë me numër të barabartë nodash në të dy lokacione. Në këtë rast përdoret faktori i replikimit 2+2.
Kemi marrë konfigurimin e mëposhtëm:
Arkitektura klasike
HyperFlex
Serverët
16 x Server 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)
Sistemi i Ruajtjes
2 x SHTD AllFlash (150 TB SSD)
â
LAN
4 x switch 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ë çdo llogaritje 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 në HyperFlex.
Ămimi i HyperFlex ishte 5% mĂ« i lartĂ«. KĂ«tu merret parasysh se pĂ«r burimet CPU/RAM kam pasur njĂ« disbalancĂ« pĂ«r Cisco, pasi nĂ« konfigurim plotĂ«sova kanalet e kontrollorĂ«ve tĂ« memories nĂ« mĂ«nyrĂ« tĂ« barabartĂ«. Ămimi Ă«shtĂ« pak mĂ« i lartĂ«, por jo nĂ« njĂ« masĂ« tĂ« madhe, gjĂ« qĂ« tregon qartĂ« se hiper-konvergjenca nuk Ă«shtĂ« domosdoshmĂ«risht "lojĂ« pĂ«r tĂ« pasurit", por mund tĂ« konkurrojĂ« me qasjen standarde nĂ« ndĂ«rtimin e Qendrave tĂ« tĂ« DhĂ«nave. KĂ«shtu qĂ« kjo mund tĂ« jetĂ« interesante pĂ«r ata qĂ« tashmĂ« kanĂ« servera Cisco UCS dhe infrastrukturĂ«n pĂ«rkatĂ«se pĂ«r ta.
Nga avantazhet do të kemi mungesën e kostove për administrimin e SAN dhe SCSI, kompresionin dhe deduplikimin në kohë reale, një pikë të vetme kontakti për mbështetje (virtualizimi, serverat, ata gjithashtu janë - SCSI), kursimin e hapësirës (por jo në të gjitha skenarët), thjeshtimin e operacioneve.
Sa i pĂ«rket mbĂ«shtetjes, ju merrni atĂ« nga njĂ« ofrues i vetĂ«m â Cisco. NĂ«se gjykoj pĂ«rvojĂ«n time me serverĂ«t Cisco UCS, mĂ« pĂ«lqen; nuk mĂ« duhej tĂ« hapja HyperFlex, gjithçka funksiononte. InxhinierĂ«t pĂ«rgjigjen shpejt dhe mund tĂ« zgjidhin jo vetĂ«m probleme standard, por edhe raste tĂ« ndĂ«rlikuara. NdonjĂ«herĂ« i kontaktoj me pyetje si: "A Ă«shtĂ« e mundur ta bĂ«j kĂ«tĂ«, ta lidhem me kĂ«tĂ«?" ose "Kam bĂ«rĂ« ndonjĂ« konfigurim dhe nuk funksionon. MĂ« ndihmoni!" â ata me durim gjejnĂ« udhĂ«zimin e nevojshĂ«m dhe tregojnĂ« pĂ«r veprimet e duhra, nuk do tĂ« pĂ«rgjigjen: "Ne zgjidhim vetĂ«m problemet harduerike."
Linke
- Emaili im â StGeneralov@croc.ru
Burimi: habr.com
