Ito ay isang alamat na medyo karaniwan sa larangan ng hardware ng server. Sa pagsasagawa, ang mga hyperconverged na solusyon (kapag ang lahat ay nasa isa) ay kailangan para sa maraming bagay. Sa kasaysayan, ang mga unang arkitektura ay binuo ng Amazon at Google para sa kanilang mga serbisyo. Pagkatapos ang ideya ay gumawa ng isang computing farm mula sa magkatulad na mga node, na ang bawat isa ay may sariling mga disk. Ang lahat ng ito ay pinagsama ng ilang software na bumubuo ng system (hypervisor) at nahahati sa mga virtual machine. Ang pangunahing layunin ay isang minimum na pagsisikap para sa pagseserbisyo sa isang node at isang minimum na mga problema kapag nag-scale: bumili lamang ng isa pang libo o dalawa ng parehong mga server at ikonekta ang mga ito sa malapit. Sa pagsasagawa, ito ay mga nakahiwalay na kaso, at mas madalas na pinag-uusapan natin ang tungkol sa isang mas maliit na bilang ng mga node at isang bahagyang naiibang arkitektura.
Ngunit ang plus ay nananatiling pareho - hindi kapani-paniwalang kadalian ng pag-scale at pamamahala. Ang downside ay ang iba't ibang mga gawain ay gumagamit ng mga mapagkukunan nang iba, at sa ilang mga lugar ay magkakaroon ng maraming mga lokal na disk, sa iba ay magkakaroon ng maliit na RAM, at iba pa, iyon ay, para sa iba't ibang uri ng mga gawain, ang paggamit ng mapagkukunan ay bababa.
Lumalabas na nagbabayad ka ng 10–15% na higit pa para sa kadalian ng pag-setup. Ito ang nagpasiklab ng mito sa pamagat. Gumugol kami ng mahabang panahon sa paghahanap kung saan mailalapat ang teknolohiya, at nakita namin ito. Ang katotohanan ay ang Cisco ay walang sariling mga sistema ng imbakan, ngunit nais nila ang isang kumpletong merkado ng server. At ginawa nila ang Cisco Hyperflex - isang solusyon na may lokal na imbakan sa mga node.
At ito ay biglang naging isang napakahusay na solusyon para sa mga backup na sentro ng data (Disaster Recovery). Sasabihin ko sa iyo kung bakit at paano ngayon. At ipapakita ko sa iyo ang mga pagsubok sa kumpol.
Kung saan kailangan
Ang hyperconvergence ay:
- Paglilipat ng mga disk upang makalkula ang mga node.
- Buong pagsasama ng storage subsystem sa virtualization subsystem.
- Paglipat/pagsasama sa subsystem ng network.
Binibigyang-daan ka ng kumbinasyong ito na magpatupad ng maraming feature ng storage system sa antas ng virtualization at lahat mula sa isang control window.
Sa aming kumpanya, ang mga proyektong magdidisenyo ng mga redundant na data center ay may malaking pangangailangan, at madalas na pinipili ang isang hyperconverged na solusyon dahil sa isang grupo ng mga opsyon sa pagtitiklop (hanggang sa isang metrocluster) sa labas ng kahon.
Sa kaso ng mga backup na data center, karaniwang pinag-uusapan natin ang tungkol sa isang malayong pasilidad sa isang site sa kabilang panig ng lungsod o sa isa pang lungsod sa kabuuan. Pinapayagan ka nitong ibalik ang mga kritikal na sistema sa kaganapan ng isang bahagyang o kumpletong pagkabigo ng pangunahing sentro ng data. Ang data ng benta ay patuloy na kinokopya doon, at ang pagtitiklop na ito ay maaaring nasa antas ng aplikasyon o sa antas ng block device (imbakan).
Samakatuwid, ngayon ay magsasalita ako tungkol sa disenyo ng system at mga pagsubok, at pagkatapos ay tungkol sa isang pares ng mga totoong buhay na sitwasyon ng aplikasyon na may data sa pagtitipid.
Mga Pagsubok
Ang aming instance ay binubuo ng apat na server, bawat isa ay may 10 SSD drive na 960 GB. Mayroong nakalaang disk para sa pag-cache ng mga operasyon sa pagsulat at pag-iimbak ng serbisyo ng virtual machine. Ang solusyon mismo ay ang ika-apat na bersyon. Ang una ay tapat na krudo (paghusga sa pamamagitan ng mga review), ang pangalawa ay mamasa-masa, ang pangatlo ay medyo stable na, at ang isang ito ay matatawag na release pagkatapos ng pagtatapos ng beta testing para sa pangkalahatang publiko. Sa panahon ng pagsubok, wala akong nakitang mga problema, lahat ay gumagana tulad ng isang orasan.
Mga pagbabago sa v4Ang isang grupo ng mga bug ay naayos na.
Sa una, ang platform ay maaari lamang gumana sa VMware ESXi hypervisor at sinusuportahan ang isang maliit na bilang ng mga node. Gayundin, ang proseso ng pag-deploy ay hindi palaging matagumpay na natapos, ang ilang mga hakbang ay kailangang i-restart, may mga problema sa pag-update mula sa mga mas lumang bersyon, ang data sa GUI ay hindi palaging ipinapakita nang tama (bagaman hindi pa rin ako masaya sa pagpapakita ng mga graph ng pagganap ), kung minsan ay lumitaw ang mga problema sa interface na may virtualization.
Ngayon ang lahat ng mga problema sa pagkabata ay naayos na, kayang hawakan ng HyperFlex ang parehong ESXi at Hyper-V, at posible na:
- Paglikha ng isang nakaunat na kumpol.
- Paglikha ng isang cluster para sa mga opisina nang hindi gumagamit ng Fabric Interconnect, mula dalawa hanggang apat na node (bumili lang kami ng mga server).
- Kakayahang magtrabaho sa mga panlabas na sistema ng imbakan.
- Suporta para sa mga container at Kubernetes.
- Paglikha ng mga availability zone.
- Pagsasama sa VMware SRM kung hindi kasiya-siya ang built-in na functionality.
Ang arkitektura ay hindi gaanong naiiba sa mga solusyon ng mga pangunahing kakumpitensya nito; hindi sila lumikha ng isang bisikleta. Ang lahat ng ito ay tumatakbo sa VMware o Hyper-V virtualization platform. Ang hardware ay naka-host sa proprietary Cisco UCS server. Mayroong mga napopoot sa platform para sa kamag-anak na pagiging kumplikado ng paunang pag-setup, maraming mga pindutan, isang hindi maliit na sistema ng mga template at dependency, ngunit mayroon ding mga natutunan ang Zen, ay inspirasyon ng ideya at hindi na gusto upang gumana sa iba pang mga server.
Isasaalang-alang namin ang solusyon para sa VMware, dahil ang solusyon ay orihinal na nilikha para dito at may higit na pag-andar; Ang Hyper-V ay idinagdag sa daan upang makasabay sa mga kakumpitensya at matugunan ang mga inaasahan sa merkado.
Mayroong isang kumpol ng mga server na puno ng mga disk. Mayroong mga disk para sa pag-iimbak ng data (SSD o HDD - ayon sa iyong panlasa at pangangailangan), mayroong isang SSD disk para sa pag-cache. Kapag nagsusulat ng data sa datastore, ang data ay nai-save sa caching layer (nakalaang SSD disk at RAM ng serbisyong VM). Kaayon, ang isang bloke ng data ay ipinapadala sa mga node sa cluster (ang bilang ng mga node ay depende sa cluster replication factor). Pagkatapos ng kumpirmasyon mula sa lahat ng node tungkol sa matagumpay na pag-record, ang kumpirmasyon ng pag-record ay ipapadala sa hypervisor at pagkatapos ay sa VM. Ang naitala na data ay na-deduplicate, na-compress at nakasulat sa mga storage disk sa background. Kasabay nito, ang isang malaking bloke ay palaging nakasulat sa mga disk ng imbakan at sunud-sunod, na binabawasan ang pagkarga sa mga disk ng imbakan.
Palaging pinapagana ang deduplication at compression at hindi maaaring i-disable. Ang data ay direktang binabasa mula sa mga storage disk o mula sa RAM cache. Kung ginamit ang isang hybrid na configuration, ang mga nabasa ay naka-cache din sa SSD.
Ang data ay hindi nakatali sa kasalukuyang lokasyon ng virtual machine at ipinamamahagi nang pantay-pantay sa pagitan ng mga node. Ang diskarte na ito ay nagpapahintulot sa iyo na i-load ang lahat ng mga disk at mga interface ng network nang pantay. Mayroong isang malinaw na kawalan: hindi namin maaaring bawasan ang latency ng pagbasa hangga't maaari, dahil walang garantiya ng pagkakaroon ng data sa lokal. Ngunit naniniwala ako na ito ay isang maliit na sakripisyo kumpara sa mga benepisyong natanggap. Bukod dito, ang mga pagkaantala sa network ay umabot sa mga halaga na halos hindi nila naaapektuhan ang pangkalahatang resulta.
Ang isang espesyal na serbisyo VM Cisco HyperFlex Data Platform controller, na nilikha sa bawat storage node, ay responsable para sa buong lohika ng operasyon ng disk subsystem. Sa aming configuration ng VM ng serbisyo, walong vCPU at 72 GB ng RAM ang inilaan, na hindi gaanong kaunti. Ipaalala ko sa iyo na ang host mismo ay may 28 pisikal na core at 512 GB ng RAM.
Ang serbisyong VM ay may access sa mga pisikal na disk nang direkta sa pamamagitan ng pagpapasa ng SAS controller sa VM. Ang komunikasyon sa hypervisor ay nangyayari sa pamamagitan ng isang espesyal na module ng IOVisor, na humahadlang sa mga operasyon ng I/O, at gamit ang isang ahente na nagbibigay-daan sa iyong magpadala ng mga command sa hypervisor API. Ang ahente ay may pananagutan sa pagtatrabaho sa mga snapshot at clone ng HyperFlex.
Ang mga mapagkukunan ng disk ay naka-mount sa hypervisor bilang NFS o SMB shares (depende sa uri ng hypervisor, hulaan kung saan ang isa). At sa ilalim ng hood, ito ay isang distributed na file system na nagbibigay-daan sa iyong magdagdag ng mga feature ng mga pang-adultong full-fledged storage system: manipis na volume allocation, compression at deduplication, mga snapshot gamit ang Redirect-on-Write na teknolohiya, synchronous/asynchronous replication.
Ang serbisyong VM ay nagbibigay ng access sa WEB management interface ng HyperFlex subsystem. Mayroong pagsasama sa vCenter, at karamihan sa mga pang-araw-araw na gawain ay maaaring gawin mula dito, ngunit ang mga datastore, halimbawa, ay mas maginhawang i-cut mula sa isang hiwalay na webcam kung lumipat ka na sa isang mabilis na interface ng HTML5, o gumamit ng isang ganap na Flash client. na may ganap na pagsasama. Sa webcam ng serbisyo maaari mong tingnan ang pagganap at detalyadong katayuan ng system.
May isa pang uri ng node sa isang cluster - computing nodes. Ang mga ito ay maaaring mga rack o blade server na walang mga built-in na disk. Ang mga server na ito ay maaaring magpatakbo ng mga VM na ang data ay nakaimbak sa mga server na may mga disk. Mula sa punto ng view ng pag-access ng data, walang pagkakaiba sa pagitan ng mga uri ng mga node, dahil ang arkitektura ay nagsasangkot ng abstraction mula sa pisikal na lokasyon ng data. Ang maximum na ratio ng mga node sa pag-compute sa mga storage node ay 2:1.
Ang paggamit ng mga compute node ay nagpapataas ng flexibility kapag nag-scale ng mga mapagkukunan ng cluster: hindi namin kailangang bumili ng mga karagdagang node na may mga disk kung kailangan lang namin ng CPU/RAM. Bilang karagdagan, maaari kaming magdagdag ng isang blade cage at makatipid sa rack placement ng mga server.
Bilang resulta, mayroon kaming hyperconverged na platform na may mga sumusunod na feature:
- Hanggang 64 node sa isang cluster (hanggang 32 storage node).
- Ang pinakamababang bilang ng mga node sa isang cluster ay tatlo (dalawa para sa isang Edge cluster).
- Mekanismo ng redundancy ng data: pag-mirror gamit ang replication factor 2 at 3.
- Metro cluster.
- Asynchronous VM replication sa isa pang HyperFlex cluster.
- Orkestrasyon ng paglipat ng mga VM sa isang malayuang data center.
- Mga native na snapshot gamit ang teknolohiyang Redirect-on-Write.
- Hanggang 1 PB ng magagamit na espasyo sa replication factor 3 at walang deduplication. Hindi namin isinasaalang-alang ang replication factor 2, dahil hindi ito isang opsyon para sa mga seryosong benta.
Ang isa pang malaking plus ay kadalian ng pamamahala at pag-deploy. Ang lahat ng mga kumplikado ng pag-set up ng mga server ng UCS ay pinangangasiwaan ng isang dalubhasang VM na inihanda ng mga inhinyero ng Cisco.
Configuration ng test bench:
- 2 x Cisco UCS Fabric Interconnect 6248UP bilang isang management cluster at mga bahagi ng network (48 port na tumatakbo sa Ethernet 10G/FC 16G mode).
- Apat na Cisco UCS HXAF240 M4 server.
Mga katangian ng server:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
network
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet port
Imbakan ng HBA
Cisco 12G Modular SAS Pass through Controller
Mga Storage Disk
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Higit pang mga pagpipilian sa pagsasaayosBilang karagdagan sa napiling hardware, ang mga sumusunod na opsyon ay kasalukuyang magagamit:
- HXAF240c M5.
- Isa o dalawang CPU mula sa Intel Silver 4110 hanggang Intel Platinum I8260Y. Available ang pangalawang henerasyon.
- 24 na memory slot, mga strip mula 16 GB RDIMM 2600 hanggang 128 GB LRDIMM 2933.
- Mula 6 hanggang 23 data disk, isang caching disk, isang system disk at isang boot disk.
Mga Drive ng Kapasidad
- 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.
- Pag-cache ng mga Drive
- HX-NVMEXPB-I375 375GB 2.5 inch Intel Optane Drive, Extreme Perf & Endurance.
- HX-NVMEHW-H1600* 1.6TB 2.5 pulgadang Ent. Perf. NVMe SSD (3X endurance) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 pulgadang Ent. Perf. 12G SAS SSD (10X tibay) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 inch Ent. Perf. 12G SAS SED SSD (10X tibay) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 inch Enterprise performance 12G SAS SSD (3X endurance).
Mga System/Log Drive
- HX-SD240GM1X-EV 240GB 2.5 inch Enterprise Value 6G SATA SSD (Nangangailangan ng upgrade).
Mga Boot Drive
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Kumonekta sa network sa pamamagitan ng 40G, 25G o 10G Ethernet port.
Ang FI ay maaaring HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Ang pagsubok mismo
Upang subukan ang disk subsystem, ginamit ko ang HCIBench 2.2.1. Ito ay isang libreng utility na nagbibigay-daan sa iyong i-automate ang paglikha ng isang load mula sa maraming virtual machine. Ang load mismo ay nabuo ng karaniwang fio.
Ang aming cluster ay binubuo ng apat na node, replication factor 3, lahat ng mga disk ay Flash.
Para sa pagsubok, gumawa ako ng apat na datastore at walong virtual machine. Para sa mga write test, ipinapalagay na ang caching disk ay hindi puno.
Ang mga resulta ng pagsusulit ay ang mga sumusunod:
100% Basahin 100% Random
0% Basahin 100% Random
Lalim ng block/queue
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 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
Ang bold ay nagpapahiwatig ng mga halaga pagkatapos kung saan walang pagtaas sa pagiging produktibo, kung minsan kahit na ang pagkasira ay nakikita. Ito ay dahil sa katotohanang nalilimitahan tayo ng pagganap ng network/controllers/disks.
- Sequential read 4432 MB/s.
- Sequential write 804 MB/s.
- Kung nabigo ang isang controller (pagkabigo ng isang virtual machine o host), ang pagbaba ng pagganap ay dalawang beses.
- Kung nabigo ang storage disk, ang drawdown ay 1/3. Ang muling pagbuo ng disk ay tumatagal ng 5% ng mga mapagkukunan ng bawat controller.
Sa isang maliit na bloke, nalilimitahan tayo ng pagganap ng controller (virtual machine), ang CPU nito ay na-load sa 100%, at kapag tumaas ang block, nalilimitahan tayo ng port bandwidth. Hindi sapat ang 10 Gbps para i-unlock ang potensyal ng AllFlash system. Sa kasamaang palad, ang mga parameter ng ibinigay na demo stand ay hindi nagpapahintulot sa amin na subukan ang operasyon sa 40 Gbit/s.
Sa aking impresyon mula sa mga pagsubok at pag-aaral ng arkitektura, dahil sa algorithm na naglalagay ng data sa pagitan ng lahat ng mga host, nakakakuha kami ng scalable, predictable na pagganap, ngunit ito rin ay isang limitasyon kapag nagbabasa, dahil ito ay magiging posible upang pisilin ang higit pa mula sa mga lokal na disk, dito maaari itong mag-save ng mas produktibong network, halimbawa, available ang FI sa 40 Gbit/s.
Gayundin, ang isang disk para sa caching at deduplication ay maaaring isang limitasyon; sa katunayan, sa testbed na ito maaari tayong sumulat sa apat na SSD disk. Magiging mahusay na madagdagan ang bilang ng mga caching drive at makita ang pagkakaiba.
Tunay na gamit
Upang ayusin ang isang backup na data center, maaari kang gumamit ng dalawang diskarte (hindi namin isinasaalang-alang ang paglalagay ng backup sa isang malayong site):
- Aktibo-Pasibo. Ang lahat ng mga application ay naka-host sa pangunahing data center. Ang pagtitiklop ay kasabay o asynchronous. Kung nabigo ang pangunahing data center, kailangan nating i-activate ang backup. Maaari itong gawin nang manu-mano/mga script/mga aplikasyon ng orkestrasyon. Dito makakakuha tayo ng isang RPO na naaayon sa dalas ng pagtitiklop, at ang RTO ay nakadepende sa reaksyon at kakayahan ng administrator at sa kalidad ng pag-develop/pag-debug ng switching plan.
- Aktibo-Aktibo. Sa kasong ito, mayroon lamang kasabay na pagtitiklop; ang pagkakaroon ng mga data center ay tinutukoy ng isang quorum/arbiter na mahigpit na matatagpuan sa ikatlong site. RPO = 0, at ang RTO ay maaaring umabot sa 0 (kung pinapayagan ng application) o katumbas ng failover time ng isang node sa isang virtualization cluster. Sa antas ng virtualization, isang naka-stretch (Metro) cluster ang nilikha na nangangailangan ng Active-Active na storage.
Karaniwang nakikita namin na ang mga kliyente ay nagpatupad na ng isang arkitektura na may klasikong sistema ng imbakan sa pangunahing sentro ng data, kaya nagdidisenyo kami ng isa pa para sa pagtitiklop. Tulad ng nabanggit ko, nag-aalok ang Cisco HyperFlex ng asynchronous na pagtitiklop at nakaunat na paglikha ng kumpol ng virtualization. Kasabay nito, hindi namin kailangan ang isang nakalaang sistema ng imbakan ng antas ng Midrange at mas mataas na may mamahaling pag-andar ng pagtitiklop at Aktibo-Aktibong pag-access ng data sa dalawang sistema ng imbakan.
Sitwasyon 1: Mayroon kaming pangunahin at backup na mga data center, isang virtualization platform sa VMware vSphere. Ang lahat ng mga produktibong sistema ay matatagpuan sa pangunahing data center, at ang pagtitiklop ng mga virtual machine ay ginagawa sa antas ng hypervisor, maiiwasan nito ang pagpapanatiling naka-on ang mga VM sa backup na data center. Ginagaya namin ang mga database at mga espesyal na application gamit ang mga built-in na tool at pinananatiling naka-on ang mga VM. Kung nabigo ang pangunahing data center, naglulunsad kami ng mga system sa backup na data center. Naniniwala kami na mayroon kaming humigit-kumulang 100 virtual machine. Habang gumagana ang pangunahing data center, ang standby data center ay maaaring magpatakbo ng mga pagsubok na kapaligiran at iba pang mga system na maaaring isara kung ang pangunahing data center ay lumipat. Posible rin na gumamit tayo ng two-way replication. Mula sa punto ng hardware, walang magbabago.
Sa kaso ng klasikal na arkitektura, mag-i-install kami sa bawat data center ng hybrid storage system na may access sa pamamagitan ng FibreChannel, tiering, deduplication at compression (ngunit hindi online), 8 server para sa bawat site, 2 FibreChannel switch at 10G Ethernet. Para sa replikasyon at paglipat ng pamamahala sa isang klasikong arkitektura, maaari naming gamitin ang mga tool ng VMware (Replication + SRM) o mga tool ng third-party, na magiging mas mura ng kaunti at kung minsan ay mas maginhawa.
Ipinapakita ng figure ang diagram.
Kapag gumagamit ng Cisco HyperFlex, ang sumusunod na arkitektura ay nakuha:
Para sa HyperFlex, gumamit ako ng mga server na may malalaking mapagkukunan ng CPU/RAM, dahil... Ang ilan sa mga mapagkukunan ay mapupunta sa HyperFlex controller VM; sa mga tuntunin ng CPU at memorya, muling na-configure ko ang HyperFlex configuration nang kaunti upang hindi maglaro kasama ng Cisco at ginagarantiyahan ang mga mapagkukunan para sa natitirang mga VM. Ngunit maaari naming iwanan ang mga switch ng FibreChannel, at hindi namin kakailanganin ang mga Ethernet port para sa bawat server; ang lokal na trapiko ay inililipat sa loob ng FI.
Ang resulta ay ang sumusunod na configuration para sa bawat data center:
Mga server
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
Hybrid storage system na may FC Front-End (20TB 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
Mga lisensya
VMware Ent Plus
Replikasyon at/o orkestrasyon ng VM switching
VMware Ent Plus
Hindi ako nagbigay ng mga lisensya ng replication software para sa Hyperflex, dahil available ito sa labas ng kahon para sa amin.
Para sa klasikal na arkitektura, pumili ako ng isang vendor na itinatag ang sarili bilang isang de-kalidad at murang tagagawa. Para sa parehong mga pagpipilian, inilapat ko ang karaniwang diskwento para sa isang tiyak na solusyon, at bilang isang resulta nakatanggap ako ng mga tunay na presyo.
Ang solusyon ng Cisco HyperFlex ay naging 13% na mas mura.
Sitwasyon 2: paglikha ng dalawang aktibong data center. Sa sitwasyong ito, nagdidisenyo kami ng nakaunat na cluster sa VMware.
Ang klasikong arkitektura ay binubuo ng mga virtualization server, isang SAN (FC protocol) at dalawang sistema ng imbakan na maaaring magbasa at sumulat sa lakas ng tunog sa pagitan ng mga ito. Sa bawat sistema ng imbakan naglalagay kami ng kapaki-pakinabang na kapasidad para sa imbakan.
Sa HyperFlex, gumagawa lang kami ng Stretch Cluster na may parehong bilang ng mga node sa parehong mga site. Sa kasong ito, ginagamit ang isang replication factor na 2+2.
Ang resulta ay ang sumusunod na pagsasaayos:
klasikal na arkitektura
HyperFlex
Mga server
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 storage system (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
Mga lisensya
VMware Ent Plus
VMware Ent Plus
Sa lahat ng mga kalkulasyon, hindi ko isinasaalang-alang ang imprastraktura ng network, mga gastos sa sentro ng data, atbp.: magiging pareho sila para sa klasikal na arkitektura at para sa solusyon ng HyperFlex.
Sa mga tuntunin ng gastos, ang HyperFlex ay naging 5% na mas mahal. Ito ay nagkakahalaga na tandaan dito na sa mga tuntunin ng mga mapagkukunan ng CPU / RAM ay nagkaroon ako ng skew para sa Cisco, dahil sa pagsasaayos ay pinunan ko ang mga channel ng memory controller nang pantay-pantay. Ang gastos ay bahagyang mas mataas, ngunit hindi sa pamamagitan ng isang order ng magnitude, na malinaw na nagpapahiwatig na ang hyperconvergence ay hindi kinakailangang isang "laruan para sa mayayaman", ngunit maaaring makipagkumpitensya sa karaniwang diskarte sa pagbuo ng isang data center. Maaari rin itong maging interesado sa mga mayroon nang Cisco UCS server at ang kaukulang imprastraktura para sa kanila.
Kabilang sa mga pakinabang, nakukuha namin ang kawalan ng mga gastos para sa pangangasiwa ng SAN at mga sistema ng imbakan, online na compression at deduplication, isang solong entry point para sa suporta (virtualization, mga server, sila rin ay mga sistema ng imbakan), pag-save ng espasyo (ngunit hindi sa lahat ng mga sitwasyon), pagpapasimple ng operasyon.
Tulad ng para sa suporta, dito mo makuha ito mula sa isang vendor - Cisco. Sa paghusga sa aking karanasan sa mga server ng Cisco UCS, gusto ko ito; Hindi ko kailangang buksan ito sa HyperFlex, lahat ay gumana nang pareho. Mabilis na tumugon ang mga inhinyero at kayang lutasin hindi lamang ang mga karaniwang problema, kundi pati na rin ang mga kumplikadong kaso sa gilid. Minsan lumingon ako sa kanila nang may mga tanong: "Posible bang gawin ito, i-screw ito?" o “Nag-configure ako ng isang bagay dito, at ayaw nitong gumana. Tulong!" - matiyaga nilang hahanapin ang kinakailangang gabay doon at ituro ang mga tamang aksyon; hindi nila sasagutin ang: "Nalutas lang namin ang mga problema sa hardware."
sanggunian
- Ang aking mail - [protektado ng email]
Pinagmulan: www.habr.com