Ovo je mit koji je prilično čest na polju serverskog hardvera. U praksi su hiperkonvergirana rješenja (kada je sve u jednom) potrebna za mnoge stvari. Istorijski gledano, prve arhitekture su razvili Amazon i Google za svoje usluge. Tada je ideja bila da se napravi računarska farma od identičnih čvorova, od kojih je svaki imao svoje diskove. Sve je to objedinio neki sistemski softver (hipervizor) i podijeljen na virtuelne mašine. Glavni cilj je minimum napora za servisiranje jednog čvora i minimum problema pri skaliranju: samo kupite još hiljadu ili dvije istih servera i povežite ih u blizini. U praksi su to izolovani slučajevi, a mnogo češće govorimo o manjem broju čvorova i nešto drugačijoj arhitekturi.
Ali plus ostaje isti - nevjerovatna lakoća skaliranja i upravljanja. Nedostatak je što različiti zadaci troše resurse različito, a na nekim mjestima će biti puno lokalnih diskova, na drugim će biti malo RAM-a i tako dalje, odnosno za različite vrste zadataka, iskorištenost resursa će se smanjiti.
Ispostavilo se da plaćate 10–15% više za jednostavno podešavanje. To je ono što je izazvalo mit u naslovu. Dugo smo tražili gdje bi tehnologija bila optimalno primijenjena i našli smo je. Činjenica je da Cisco nije imao sopstvene sisteme za skladištenje podataka, ali su želeli kompletno tržište servera. Napravili su i Cisco Hyperflex - rješenje sa lokalnim skladištem na čvorovima.
I ovo se odjednom pokazalo kao vrlo dobro rješenje za rezervne podatkovne centre (Disaster Recovery). Sada ću vam reći zašto i kako. I pokazaću vam klaster testove.
Gdje je potrebno
Hiperkonvergencija je:
- Prijenos diskova na računske čvorove.
- Potpuna integracija podsistema za skladištenje podataka sa podsistemom virtuelizacije.
- Transfer/integracija sa mrežnim podsistemom.
Ova kombinacija vam omogućava da implementirate mnoge funkcije sistema za skladištenje na nivou virtuelizacije i sve to iz jednog kontrolnog prozora.
U našoj kompaniji su projekti za projektovanje redundantnih data centara veoma traženi, a često se bira hiperkonvergentno rešenje zbog gomile opcija replikacije (do metroklastera) iz kutije.
U slučaju rezervnih data centara, obično govorimo o udaljenom objektu na lokaciji na drugoj strani grada ili u drugom gradu. Omogućava vam da obnovite kritične sisteme u slučaju djelomičnog ili potpunog kvara glavnog podatkovnog centra. Podaci o prodaji se tamo stalno repliciraju, a ta replikacija može biti na razini aplikacije ili na razini blok uređaja (skladišta).
Stoga ću sada govoriti o dizajnu sistema i testovima, a zatim o nekoliko scenarija iz stvarnog života sa podacima o uštedi.
Testovi
Naša instanca se sastoji od četiri servera, od kojih svaki ima 10 SSD diskova od 960 GB. Postoji namjenski disk za keširanje operacija pisanja i pohranjivanje servisne virtuelne mašine. Samo rješenje je četvrta verzija. Prvi je iskreno grub (sudeći po recenzijama), drugi je vlažan, treći je već prilično stabilan, a ovo se može nazvati izdanjem nakon završetka beta testiranja za širu javnost. Tokom testiranja nisam vidio nikakve probleme, sve radi kao sat.
Promjene u v4Gomila grešaka je ispravljena.
U početku je platforma mogla raditi samo sa VMware ESXi hipervizorom i podržavala je mali broj čvorova. Također, proces implementacije se nije uvijek završavao uspješno, neki koraci su morali biti ponovo pokrenuti, bilo je problema sa ažuriranjem sa starijih verzija, podaci u GUI-u nisu uvijek bili ispravno prikazani (iako još uvijek nisam zadovoljan prikazom grafikona performansi ), ponekad su se javljali problemi na interfejsu sa virtuelizacijom.
Sada su svi problemi iz djetinjstva riješeni, HyperFlex može podnijeti i ESXi i Hyper-V, plus moguće je:
- Kreiranje rastegnutog klastera.
- Kreiranje klastera za kancelarije bez korišćenja Fabric Interconnect, od dva do četiri čvora (kupujemo samo servere).
- Mogućnost rada sa eksternim sistemima za skladištenje podataka.
- Podrška za kontejnere i Kubernetes.
- Kreiranje zona dostupnosti.
- Integracija sa VMware SRM ako ugrađena funkcionalnost nije zadovoljavajuća.
Arhitektura se ne razlikuje mnogo od rješenja svojih glavnih konkurenata; oni nisu stvorili bicikl. Sve radi na VMware ili Hyper-V virtualizacijskoj platformi. Hardver se nalazi na vlasničkim Cisco UCS serverima. Ima onih koji mrze platformu zbog relativne složenosti početnog podešavanja, puno dugmadi, netrivijalnog sistema šablona i zavisnosti, ali ima i onih koji su naučili zen, inspirisani su idejom i više ne žele za rad sa drugim serverima.
Razmotrit ćemo rješenje za VMware, jer je rješenje izvorno kreirano za njega i ima više funkcionalnosti; Hyper-V je dodat usput kako bi se držao korak s konkurencijom i ispunio očekivanja tržišta.
Postoji grupa servera puna diskova. Postoje diskovi za skladištenje podataka (SSD ili HDD - po vašem ukusu i potrebama), postoji jedan SSD disk za keširanje. Prilikom pisanja podataka u skladište podataka, podaci se pohranjuju na sloju keširanja (namjenski SSD disk i RAM servisne VM). Paralelno, blok podataka se šalje čvorovima u klasteru (broj čvorova ovisi o faktoru replikacije klastera). Nakon potvrde sa svih čvorova o uspješnom snimanju, potvrda snimanja se šalje hipervizoru, a zatim VM. Snimljeni podaci se dedupliciraju, komprimiraju i zapisuju na diskove za pohranu u pozadini. U isto vrijeme, veliki blok se uvijek upisuje na diskove za pohranu i uzastopno, što smanjuje opterećenje diskova za pohranu.
Deduplikacija i kompresija su uvijek omogućeni i ne mogu se onemogućiti. Podaci se čitaju direktno sa diskova za skladištenje ili iz RAM keša. Ako se koristi hibridna konfiguracija, čitanja se također keširaju na SSD-u.
Podaci nisu vezani za trenutnu lokaciju virtuelne mašine i ravnomerno su raspoređeni između čvorova. Ovaj pristup vam omogućava da podjednako učitate sve diskove i mrežna sučelja. Postoji očigledan nedostatak: ne možemo smanjiti kašnjenje čitanja koliko god je to moguće, jer ne postoji garancija dostupnosti podataka lokalno. Ali vjerujem da je ovo mala žrtva u odnosu na dobijene koristi. Štoviše, kašnjenja u mreži dostigla su takve vrijednosti da praktički ne utječu na ukupni rezultat.
Posebni servisni VM Cisco HyperFlex Data Platform kontroler, koji se kreira na svakom čvoru za skladištenje, odgovoran je za celokupnu logiku rada diskovnog podsistema. U našoj servisnoj VM konfiguraciji izdvojeno je osam vCPU-a i 72 GB RAM-a, što i nije tako malo. Da vas podsjetim da sam host ima 28 fizičkih jezgara i 512 GB RAM-a.
Servisni VM ima pristup fizičkim diskovima direktno prosljeđivanjem SAS kontrolera na VM. Komunikacija sa hipervizorom se odvija preko posebnog modula IOVIsor, koji presreće I/O operacije, i pomoću agenta koji vam omogućava da pošaljete komande API-ju hipervizora. Agent je odgovoran za rad sa HyperFlex snimcima i klonovima.
Resursi diska se montiraju u hipervizor kao NFS ili SMB dijeljenja (u zavisnosti od tipa hipervizora, pogodite koji je gdje). A ispod haube, ovo je distribuirani sistem datoteka koji vam omogućava da dodate karakteristike punopravnih sistema skladištenja za odrasle: tanku alokaciju volumena, kompresiju i deduplikaciju, snimke pomoću tehnologije Redirect-on-Write, sinhrona/asinhrona replikacija.
Servis VM omogućava pristup WEB interfejsu za upravljanje podsistemom HyperFlex. Postoji integracija sa vCenter-om, i većina svakodnevnih zadataka se može obavljati iz njega, ali skladišta podataka, na primjer, pogodnije je izrezati iz zasebne web kamere ako ste već prešli na brzo HTML5 sučelje ili koristite punopravni Flash klijent sa potpunom integracijom. U servisnoj web kameri možete vidjeti performanse i detaljan status sistema.
Postoji još jedan tip čvora u klasteru - računarski čvorovi. To mogu biti rack ili blade serveri bez ugrađenih diskova. Ovi serveri mogu pokretati VM-ove čiji su podaci pohranjeni na serverima s diskovima. Sa stanovišta pristupa podacima, ne postoji razlika između tipova čvorova, jer arhitektura podrazumeva apstrakciju od fizičke lokacije podataka. Maksimalni omjer računarskih čvorova i čvorova za skladištenje je 2:1.
Korištenje računarskih čvorova povećava fleksibilnost pri skaliranju resursa klastera: ne moramo kupovati dodatne čvorove s diskovima ako nam je potreban samo CPU/RAM. Osim toga, možemo dodati blade kavez i uštedjeti na postavljanju servera u rack.
Kao rezultat, imamo hiperkonvergiranu platformu sa sljedećim karakteristikama:
- Do 64 čvora u klasteru (do 32 čvora za skladištenje).
- Minimalni broj čvorova u klasteru je tri (dva za Edge klaster).
- Mehanizam redundancije podataka: zrcaljenje sa faktorom replikacije 2 i 3.
- Metro klaster.
- Asinhrona VM replikacija na drugi HyperFlex klaster.
- Orkestracija prebacivanja VM-a na udaljeni data centar.
- Izvorni snimci koji koriste tehnologiju Redirect-on-Write.
- Do 1 PB korisnog prostora uz faktor replikacije 3 i bez deduplikacije. Ne uzimamo u obzir faktor replikacije 2, jer to nije opcija za ozbiljnu prodaju.
Još jedan veliki plus je jednostavnost upravljanja i implementacije. O svim složenostima postavljanja UCS servera brine specijalizovani VM koji pripremaju Cisco inženjeri.
Konfiguracija testnog stola:
- 2 x Cisco UCS Fabric Interconnect 6248UP kao upravljački klaster i mrežne komponente (48 portova koji rade u Ethernet 10G/FC 16G modu).
- Četiri Cisco UCS HXAF240 M4 servera.
Karakteristike servera:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
mreža
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet porta
Skladištenje HBA
Cisco 12G modularni SAS prolazni kontroler
Diskovi za pohranu
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Više opcija konfiguracijePored odabranog hardvera, trenutno su dostupne sljedeće opcije:
- HXAF240c M5.
- Jedan ili dva CPU-a u rasponu od Intel Silver 4110 do Intel Platinum I8260Y. Dostupna druga generacija.
- 24 memorijska slota, trake od 16 GB RDIMM 2600 do 128 GB LRDIMM 2933.
- Od 6 do 23 diska sa podacima, jedan disk za keširanje, jedan sistemski disk i jedan disk za pokretanje.
Capacity Drives
- HX-SD960G61X-EV 960GB 2.5 inča Enterprise Value 6G SATA SSD (1X izdržljivost) SAS 960 GB.
- HX-SD38T61X-EV 3.8TB 2.5 inča Enterprise Value 6G SATA SSD (1X izdržljivost) SAS 3.8 TB.
- Keširanje diskova
- HX-NVMEXPB-I375 375GB 2.5 inča Intel Optane Drive, Extreme Perf & Endurance.
- HX-NVMEHW-H1600* 1.6TB 2.5 inča Ent. Perf. NVMe SSD (3X izdržljivost) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 inča Ent. Perf. 12G SAS SSD (10X izdržljivost) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 inča Ent. Perf. 12G SAS SED SSD (10X izdržljivost) SAS 800 GB.
- HX-SD16T123X-EP 1.6 TB 2.5 inča 12G SAS SSD za poslovne performanse (3X izdržljivost).
Sistem/log diskovi
- HX-SD240GM1X-EV 240GB 2.5 inča Enterprise Value 6G SATA SSD (zahteva nadogradnju).
Boot Drives
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Povežite se na mrežu preko 40G, 25G ili 10G Ethernet portova.
FI može biti HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Sam test
Za testiranje diskovnog podsistema, koristio sam HCIBench 2.2.1. Ovo je besplatni uslužni program koji vam omogućava da automatizirate kreiranje opterećenja s više virtualnih mašina. Samo opterećenje generiše uobičajeni fio.
Naš klaster se sastoji od četiri čvora, faktor replikacije 3, svi diskovi su Flash.
Za testiranje sam napravio četiri skladišta podataka i osam virtuelnih mašina. Za testove pisanja, pretpostavlja se da disk za keširanje nije pun.
Rezultati testa su sljedeći:
100% Read 100% Random
0% Read 100%Random
Dubina bloka/reda
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
Podebljano označava vrijednosti nakon kojih nema povećanja produktivnosti, ponekad je čak vidljiva i degradacija. To je zbog činjenice da smo ograničeni performansama mreže/kontrolera/diskova.
- Sekvencijalno čitanje 4432 MB/s.
- Sekvencijalno upisivanje 804 MB/s.
- Ako jedan kontroler otkaže (kvar virtuelne mašine ili hosta), pad performansi je dvostruk.
- Ako disk za skladištenje ne uspije, povlačenje je 1/3. Obnova diska uzima 5% resursa svakog kontrolera.
Na malom bloku ograničeni smo performansama kontrolera (virtuelne mašine), njegov CPU je opterećen na 100%, a kada se blok povećava, ograničeni smo propusnim opsegom porta. 10 Gbps nije dovoljno da se otključa potencijal AllFlash sistema. Nažalost, parametri obezbeđenog demo stalka ne dozvoljavaju nam da testiramo rad na 40 Gbit/s.
Po mom utisku iz testova i proučavanja arhitekture, zbog algoritma koji postavlja podatke između svih hostova, dobijamo skalabilne, predvidljive performanse, ali to je i ograničenje pri čitanju, jer bi se iz lokalnih diskova moglo istisnuti više, ovdje može spasiti produktivniju mrežu, na primjer, dostupan je FI na 40 Gbit/s.
Također, jedan disk za keširanje i deduplikaciju može biti ograničenje; zapravo, u ovom testnom stolu možemo pisati na četiri SSD diska. Bilo bi sjajno da možete povećati broj diskova za keširanje i vidjeti razliku.
Prava upotreba
Da biste organizirali sigurnosnu kopiju podatkovnog centra, možete koristiti dva pristupa (ne razmatramo postavljanje sigurnosne kopije na udaljenu lokaciju):
- Aktivno-pasivni. Sve aplikacije su smještene u glavnom podatkovnom centru. Replikacija je sinhrona ili asinhrona. Ako glavni data centar pokvari, moramo aktivirati rezervni. Ovo se može uraditi ručno/skriptama/aplikacijama za orkestraciju. Ovdje ćemo dobiti RPO srazmjeran učestalosti replikacije, a RTO ovisi o reakciji i vještinama administratora i kvaliteti razvoja/debagovanja plana prebacivanja.
- Aktivan-Aktivan. U ovom slučaju postoji samo sinhrona replikacija; dostupnost podatkovnih centara određuje kvorum/arbitar koji se nalazi striktno na trećem mjestu. RPO = 0, a RTO može dostići 0 (ako aplikacija dozvoljava) ili jednak vremenu prelaska na grešku čvora u virtuelizacijskom klasteru. Na nivou virtuelizacije kreira se rastegnut (Metro) klaster koji zahteva Active-Active skladište.
Obično vidimo da su klijenti već implementirali arhitekturu sa klasičnim sistemom skladištenja u glavnom data centru, pa dizajniramo još jednu za replikaciju. Kao što sam spomenuo, Cisco HyperFlex nudi asinhronu replikaciju i kreiranje klastera rastegnute virtuelizacije. U isto vrijeme, nije nam potreban namjenski sistem za skladištenje srednjeg i višeg nivoa sa skupim funkcijama replikacije i aktivno-aktivnim pristupom podacima na dva sistema za skladištenje podataka.
Scenario 1: Imamo primarne i rezervne podatkovne centre, platformu za virtualizaciju na VMware vSphere. Svi produktivni sistemi se nalaze u glavnom data centru, a replikacija virtuelnih mašina se vrši na nivou hipervizora, što će izbeći zadržavanje VM-ova uključenih u backup data centru. Mi repliciramo baze podataka i posebne aplikacije koristeći ugrađene alate i držimo VM uključene. Ako glavni data centar pokvari, pokrećemo sisteme u backup data centru. Vjerujemo da imamo oko 100 virtuelnih mašina. Dok je primarni podatkovni centar operativan, podatkovni centar u stanju pripravnosti može pokrenuti testna okruženja i druge sisteme koji se mogu ugasiti ako se primarni podatkovni centar prebaci. Također je moguće da koristimo dvosmjernu replikaciju. Sa hardverske tačke gledišta, ništa se neće promijeniti.
U slučaju klasične arhitekture, u svaki data centar ćemo instalirati hibridni sistem za skladištenje podataka sa pristupom preko FibreChannela, slojevima, deduplikacijom i kompresijom (ali ne online), 8 servera za svaku lokaciju, 2 FibreChannel switch-a i 10G Ethernet. Za upravljanje replikacijom i prebacivanjem u klasičnoj arhitekturi možemo koristiti VMware alate (Replication + SRM) ili alate treće strane, koji će biti malo jeftiniji, a ponekad i praktičniji.
Na slici je prikazan dijagram.
Kada se koristi Cisco HyperFlex, dobija se sljedeća arhitektura:
Za HyperFlex koristio sam servere sa velikim CPU/RAM resursima, jer... Neki od resursa će ići na VM HyperFlex kontrolera; što se tiče CPU-a i memorije, čak sam malo rekonfigurisao HyperFlex konfiguraciju kako ne bih igrao zajedno sa Cisco i garantovao resurse za preostale VM. Ali možemo napustiti FibreChannel prekidače i neće nam trebati Ethernet portovi za svaki server; lokalni promet se prebacuje unutar FI-ja.
Rezultat je bila sljedeća konfiguracija za svaki podatkovni centar:
Serveri
8 x 1U server (384 GB RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB RAM-a, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
SHD
Hibridni sistem za skladištenje sa FC Front-End-om (20TB SSD, 130 TB NL-SAS)
-
LAN
2 x Ethernet prekidač 10G 12 portova
-
SAN
2 x FC switch 32/16Gb 24 porta
2 x Cisco UCS FI 6332
Licence
VMware Ent Plus
Replikacija i/ili orkestracija prebacivanja VM-a
VMware Ent Plus
Nisam dao licence softvera za replikaciju za Hyperflex, pošto je ovo za nas dostupno bez upotrebe.
Za klasičnu arhitekturu izabrao sam dobavljača koji se etablirao kao kvalitetan i jeftin proizvođač. Za obje opcije primijenio sam standardni popust za određeno rješenje i kao rezultat dobio sam realne cijene.
Cisco HyperFlex rješenje se pokazalo jeftinijim za 13%.
Scenario 2: stvaranje dva aktivna data centra. U ovom scenariju dizajniramo rastegnuti klaster na VMware-u.
Klasična arhitektura se sastoji od virtuelizacijskih servera, SAN-a (FC protokol) i dva sistema za skladištenje podataka koji mogu čitati i pisati na volumen koji se proteže između njih. Na svaki sistem skladištenja stavljamo koristan kapacitet za skladištenje.
U HyperFlexu jednostavno kreiramo Stretch Cluster sa istim brojem čvorova na obje lokacije. U ovom slučaju se koristi faktor replikacije 2+2.
Rezultat je sljedeća konfiguracija:
klasična arhitektura
HyperFlex
Serveri
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-a, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
SHD
2 x AllFlash sistema za pohranu (150 TB SSD)
-
LAN
4 x Ethernet prekidač 10G 24 portova
-
SAN
4 x FC switch 32/16Gb 24 porta
4 x Cisco UCS FI 6332
Licence
VMware Ent Plus
VMware Ent Plus
U svim proračunima nisam uzeo u obzir mrežnu infrastrukturu, troškove data centra itd.: oni će biti isti za klasičnu arhitekturu i za HyperFlex rješenje.
Što se tiče troškova, HyperFlex je bio 5% skuplji. Ovdje je vrijedno napomenuti da sam u pogledu CPU/RAM resursa imao iskrivljenje za Cisco, jer sam u konfiguraciji ravnomjerno popunjavao kanale memorijskog kontrolera. Trošak je nešto veći, ali ne za red veličine, što jasno ukazuje da hiperkonvergencija nije nužno „igračka za bogate“, ali može konkurirati standardnom pristupu izgradnji data centra. Ovo takođe može biti od interesa za one koji već imaju Cisco UCS servere i odgovarajuću infrastrukturu za njih.
Među prednostima dobijamo odsustvo troškova za administriranje SAN-a i sistema za skladištenje, onlajn kompresiju i deduplikaciju, jednu ulaznu tačku za podršku (virtualizacija, serveri, oni su i sistemi za skladištenje), uštedu prostora (ali ne u svim scenarijima), pojednostavljivanje operacije.
Što se tiče podrške, ovde je dobijate od jednog dobavljača - Cisco. Sudeći po mom iskustvu sa Cisco UCS serverima, sviđa mi se; nisam morao da ga otvaram na HyperFlex-u, sve je funkcionisalo isto. Inženjeri reaguju brzo i mogu riješiti ne samo tipične probleme, već i složene rubne slučajeve. Ponekad im se obratim sa pitanjima: „Da li je to moguće, zajebite to?” ili „Konfigurisao sam nešto ovde i ne želi da radi. U pomoć!" - strpljivo će tamo pronaći potreban vodič i ukazati na ispravne radnje; neće odgovoriti: "Mi rješavamo samo hardverske probleme."
reference
- moja pošta - [email zaštićen]
izvor: www.habr.com