Tämä on myytti, joka on melko yleinen palvelinlaitteistojen alalla. Käytännössä hyperkonvergoituja ratkaisuja (kun kaikki on yhdessä) tarvitaan moneen asiaan. Ensimmäiset arkkitehtuurit ovat historiallisesti kehittäneet Amazon ja Google palveluilleen. Sitten ideana oli tehdä laskentatila identtisistä solmuista, joista jokaisella oli omat levynsä. Kaikki tämä yhdisti jokin järjestelmän muodostava ohjelmisto (hypervisor) ja jaettiin virtuaalikoneen. Päätavoite on minimaalinen vaiva yhden solmun huoltoon ja minimaaliset ongelmat skaalattaessa: osta vain tuhat tai kaksi samaa palvelinta ja yhdistä ne läheltä. Käytännössä nämä ovat yksittäistapauksia, ja paljon useammin puhutaan pienemmästä solmumäärästä ja hieman erilaisesta arkkitehtuurista.
Mutta plus pysyy samana - uskomaton skaalauksen ja hallinnan helppous. Huonona puolena on, että eri tehtävät kuluttavat resursseja eri tavalla, ja paikoin tulee paljon paikallisia levyjä, toisissa vähän RAM-muistia ja niin edelleen, eli erityyppisissä tehtävissä resurssien käyttö vähenee.
Osoittautuu, että maksat 10–15 % enemmän asennuksen helposta. Tämä sai aikaan myytin otsikossa. Etsimme pitkään, missä tekniikkaa sovellettaisiin optimaalisesti, ja löysimme sen. Tosiasia on, että Ciscolla ei ollut omia tallennusjärjestelmiä, mutta he halusivat täydelliset palvelinmarkkinat. Ja he tekivät Cisco Hyperflexin - ratkaisun, jossa on paikallinen tallennus solmuissa.
Ja tämä yhtäkkiä osoittautui erittäin hyväksi ratkaisuksi varmuuskopiointitietokeskuksiin (Disaster Recovery). Kerron nyt miksi ja miten. Ja näytän sinulle klusteritestit.
Siellä missä tarvitaan
Hyperkonvergenssi on:
- Levyjen siirto laskentasolmuihin.
- Tallennusalijärjestelmän täydellinen integrointi virtualisointialijärjestelmään.
- Siirto/integrointi verkkoalijärjestelmään.
Tämän yhdistelmän avulla voit toteuttaa monia tallennusjärjestelmän ominaisuuksia virtualisointitasolla ja kaikki yhdestä ohjausikkunasta.
Yrityksessämme redundanttien palvelinkeskusten suunnitteluprojektit ovat erittäin kysyttyjä, ja hyperkonvergoitu ratkaisu valitaan usein jo valmiiksi otettujen replikointivaihtoehtojen (jopa metroklusteriin) vuoksi.
Varapalvelinkeskusten tapauksessa puhumme yleensä etäkeskuksesta kaupungin toisella puolella tai kokonaan toisessa kaupungissa. Sen avulla voit palauttaa kriittiset järjestelmät, jos pääpalvelinkeskus epäonnistuu osittain tai kokonaan. Myyntitietoja replikoidaan siellä jatkuvasti, ja tämä replikointi voi olla sovellustasolla tai lohkolaitteen (tallennus) tasolla.
Siksi puhun nyt järjestelmän suunnittelusta ja testeistä, ja sitten parista tosielämän sovellusskenaariosta säästötietojen kera.
testit
Instanssimme koostuu neljästä palvelimesta, joista jokaisessa on 10 960 Gt:n SSD-asemaa. Kirjoitustoimintojen välimuistiin ja palvelun virtuaalikoneen tallentamiseen on oma levy. Itse ratkaisu on neljäs versio. Ensimmäinen on suoraan sanottuna raaka (arvostelujen perusteella), toinen on kostea, kolmas on jo melko vakaa, ja tätä voidaan kutsua julkaisuksi suurelle yleisölle betatestauksen päätyttyä. Testauksen aikana en nähnyt mitään ongelmia, kaikki toimii kuin kello.
Muutoksia v4:ssäJoukko bugeja on korjattu.
Aluksi alusta toimi vain VMware ESXi -hypervisorin kanssa ja tuki pientä määrää solmuja. Käyttöönottoprosessi ei myöskään aina päättynyt onnistuneesti, jotkut vaiheet oli käynnistettävä uudelleen, päivityksessä vanhemmista versioista oli ongelmia, GUI:n tiedot eivät aina näkyneet oikein (vaikka en ole vieläkään tyytyväinen suorituskykykaavioiden näyttöön ), joskus ilmeni ongelmia virtualisoinnin käyttöliittymässä.
Nyt kaikki lapsuuden ongelmat on korjattu, HyperFlex pystyy käsittelemään sekä ESXin että Hyper-V:n, ja lisäksi on mahdollista:
- Luodaan venytetty klusteri.
- Luodaan klusterin toimistoille ilman Fabric Interconnectia, kahdesta neljään solmua (ostamme vain palvelimia).
- Kyky työskennellä ulkoisten tallennusjärjestelmien kanssa.
- Tuki konteille ja Kubernetesille.
- Käytettävyysvyöhykkeiden luominen.
- Integrointi VMware SRM:ään, jos sisäänrakennettu toiminnallisuus ei ole tyydyttävä.
Arkkitehtuuri ei juuri eroa pääkilpailijoidensa ratkaisuista, he eivät luoneet polkupyörää. Se kaikki toimii VMware- tai Hyper-V-virtualisointialustalla. Laitteistoa isännöidään patentoiduilla Cisco UCS -palvelimilla. Jotkut vihaavat alustaa alkuperäisen asennuksen suhteellisen monimutkaisuuden vuoksi, paljon painikkeita, ei-triviaalia mallien ja riippuvuuksien järjestelmää, mutta on myös niitä, jotka ovat oppineet Zenin, inspiroituvat ideasta eivätkä enää halua. työskentelemään muiden palvelimien kanssa.
Harkitsemme ratkaisua VMwarelle, koska ratkaisu luotiin alun perin sille ja siinä on enemmän toimintoja; Hyper-V lisättiin matkan varrella kilpailijoiden tahdissa ja markkinoiden odotusten täyttämiseksi.
Palvelimia on täynnä levyjä. Tietojen tallentamiseen on levyjä (SSD tai HDD - makusi ja tarpeidesi mukaan), välimuistiin on yksi SSD-levy. Kun dataa kirjoitetaan tietovarastoon, tiedot tallennetaan välimuistikerrokseen (omistettu SSD-levy ja palvelun VM:n RAM). Samanaikaisesti datalohko lähetetään klusterin solmuille (solmujen lukumäärä riippuu klusterin replikointitekijästä). Kun kaikki solmut ovat vahvistaneet onnistuneen tallennuksen, tallennuksen vahvistus lähetetään hypervisorille ja sitten VM:lle. Tallennetusta tiedosta kopioidaan, pakataan ja kirjoitetaan tallennuslevyille taustalla. Samalla tallennuslevyille kirjoitetaan aina suuri lohko ja peräkkäin, mikä vähentää tallennuslevyjen kuormitusta.
Päällekkäisyyden poistaminen ja pakkaus ovat aina käytössä, eikä niitä voi poistaa käytöstä. Tiedot luetaan suoraan tallennuslevyiltä tai RAM-välimuistista. Jos käytetään hybridikokoonpanoa, lukemat tallennetaan myös SSD-levyn välimuistiin.
Tietoja ei ole sidottu virtuaalikoneen nykyiseen sijaintiin, vaan ne jakautuvat tasaisesti solmujen kesken. Tämän lähestymistavan avulla voit ladata kaikki levyt ja verkkoliitännät tasaisesti. Siinä on ilmeinen haittapuoli: emme voi vähentää lukuviivettä niin paljon kuin mahdollista, koska tietojen saatavuudesta paikallisesti ei ole takeita. Mutta uskon, että tämä on pieni uhraus saatuihin etuihin verrattuna. Lisäksi verkkoviiveet ovat saavuttaneet sellaiset arvot, että ne eivät käytännössä vaikuta kokonaistulokseen.
Jokaiseen tallennussolmuun luotava erikoispalvelu VM Cisco HyperFlex Data Platform -ohjain vastaa levyalijärjestelmän koko toimintalogiikasta. Palvelu-VM-kokoonpanossamme oli varattu kahdeksan vCPU:ta ja 72 Gt RAM-muistia, mikä ei ole niin vähän. Haluan muistuttaa, että isännässä itsessään on 28 fyysistä ydintä ja 512 Gt RAM-muistia.
Palvelu-VM:llä on pääsy fyysisille levyille suoraan välittämällä SAS-ohjain VM:lle. Viestintä hypervisorin kanssa tapahtuu erityisen IOVisor-moduulin kautta, joka sieppaa I/O-toiminnot, ja käyttämällä agenttia, jonka avulla voit lähettää komentoja hypervisor API:lle. Agentti vastaa työskentelystä HyperFlex-snapshot-kuvien ja -kloonien kanssa.
Levyresurssit liitetään hypervisoriin NFS- tai SMB-osuuksina (hypervisorin tyypistä riippuen, arvaa kumpi on missä). Ja konepellin alla tämä on hajautettu tiedostojärjestelmä, jonka avulla voit lisätä aikuisten täysimittaisten tallennusjärjestelmien ominaisuuksia: ohut volyymien allokointi, pakkaus ja kopioinnin poistaminen, tilannevedokset Redirect-on-Write -tekniikalla, synkroninen/asynkroninen replikointi.
Palvelu VM tarjoaa pääsyn HyperFlex-alijärjestelmän WEB-hallintaliittymään. Integraatio on vCenterin kanssa, ja useimmat arkitehtävät voidaan suorittaa siitä, mutta esimerkiksi tietovarastot on helpompi leikata erillisestä verkkokamerasta, jos olet jo siirtynyt nopeaan HTML5-käyttöliittymään tai käyttää täysimittaista Flash-asiakasta. täydellä integraatiolla. Palvelun web-kamerassa voit tarkastella järjestelmän suorituskykyä ja yksityiskohtaista tilaa.
Klusterissa on toinenkin solmutyyppi - laskentasolmut. Nämä voivat olla teline- tai korttipalvelimia ilman sisäänrakennettuja levyjä. Nämä palvelimet voivat ajaa virtuaalikoneita, joiden tiedot on tallennettu palvelimille, joissa on levyt. Tietojen käytön kannalta solmutyyppien välillä ei ole eroa, koska arkkitehtuuriin liittyy abstraktiota tiedon fyysisestä sijainnista. Laskentasolmujen maksimisuhde tallennussolmuihin on 2:1.
Laskentasolmujen käyttö lisää joustavuutta klusteriresurssien skaalauksessa: meidän ei tarvitse ostaa lisää solmuja levyillä, jos tarvitsemme vain CPU/RAM-muistia. Lisäksi voimme lisätä blade-häkin ja säästää palvelimien telinesijoittelussa.
Tämän seurauksena meillä on hyperkonvergoitu alusta, jossa on seuraavat ominaisuudet:
- Jopa 64 solmua klusterissa (jopa 32 tallennussolmua).
- Solmujen vähimmäismäärä klusterissa on kolme (kaksi Edge-klusterille).
- Tietojen redundanssimekanismi: peilaus replikointikertoimella 2 ja 3.
- Metroklusteri.
- Asynkroninen VM-replikointi toiseen HyperFlex-klusteriin.
- Virtuaalisten koneiden vaihtaminen etäpalvelinkeskukseen.
- Alkuperäiset tilannevedokset Redirect-on-Write-tekniikalla.
- Jopa 1 PB käytettävissä olevaa tilaa toisinnuskertoimella 3 ja ilman kopioiden poistoa. Emme ota huomioon replikointikerrointa 2, koska se ei ole vaihtoehto vakavaan myyntiin.
Toinen suuri plus on hallinnan ja käyttöönoton helppous. Kaikista UCS-palvelimien asennuksen monimutkaisuudesta huolehtii Ciscon insinöörien valmistama erikoistunut VM.
Testipenkin kokoonpano:
- 2 x Cisco UCS Fabric Interconnect 6248UP hallintaklusterina ja verkkokomponenttina (48 porttia Ethernet 10G/FC 16G -tilassa).
- Neljä Cisco UCS HXAF240 M4 -palvelinta.
Palvelimen ominaisuudet:
prosessori
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 Gt DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
verkko
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet-porttia
Varastointi HBA
Cisco 12G Modular SAS Pass through Controller
Tallennuslevyt
1 x SSD Intel S3520 120 Gt, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 Gt
Lisää konfigurointivaihtoehtojaValittujen laitteistojen lisäksi seuraavat vaihtoehdot ovat tällä hetkellä käytettävissä:
- HXAF240c M5.
- Yksi tai kaksi prosessoria Intel Silver 4110:stä Intel Platinum I8260Y:hen. Toinen sukupolvi saatavilla.
- 24 muistipaikkaa, nauhat 16 Gt RDIMM 2600 - 128 Gt LRDIMM 2933.
- 6 - 23 datalevyä, yksi välimuistilevy, yksi järjestelmälevy ja yksi käynnistyslevy.
Kapasiteetti asemat
- HX-SD960G61X-EV 960 Gt 2.5 tuuman Enterprise Value 6G SATA SSD (1X kestävyys) SAS 960 Gt.
- HX-SD38T61X-EV 3.8 Tt 2.5 tuuman Enterprise Value 6G SATA SSD (1X kestävyys) SAS 3.8 Tt.
- Asemien välimuisti
- HX-NVMEXPB-I375 375 Gt 2.5 tuuman Intel Optane -asema, Extreme Perf & Endurance.
- HX-NVMEHW-H1600* 1.6 Tt 2.5 tuumaa Ent. Perf. NVMe SSD (3X kestävyys) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 tuumaa Ent. Perf. 12G SAS SSD (10X kestävyys) SAS 400 Gt.
- HX-SD800GBENK9** 800GB 2.5 tuumaa Ent. Perf. 12G SAS SED SSD (10X kestävyys) SAS 800 Gt.
- HX-SD16T123X-EP 1.6 Tt 2.5 tuuman Enterprise-suorituskykyinen 12G SAS SSD (3X kestävyys).
Järjestelmä/lokiasemat
- HX-SD240GM1X-EV 240 Gt 2.5 tuuman Enterprise Value 6G SATA SSD (vaatii päivityksen).
Käynnistysasemat
- HX-M2-240 Gt 240 Gt SATA M.2 SSD SATA 240 Gt.
Yhdistä verkkoon 40G, 25G tai 10G Ethernet-porttien kautta.
FI voi olla HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Itse testi
Levyalijärjestelmän testaamiseen käytin HCIBench 2.2.1:tä. Tämä on ilmainen apuohjelma, jonka avulla voit automatisoida kuorman luomisen useista virtuaalikoneista. Itse kuorman tuottaa tavallinen fio.
Klusterimme koostuu neljästä solmusta, replikointikerroin 3, kaikki levyt ovat Flashia.
Testausta varten loin neljä tietovarastoa ja kahdeksan virtuaalikonetta. Kirjoitustesteissä oletetaan, että välimuistilevy ei ole täynnä.
Testitulokset ovat seuraavat:
100 % Lue 100 % Satunnainen
0 % Lue 100 % Satunnainen
Lohkon/jonon syvyys
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
Lihavoitu tarkoittaa arvoja, joiden jälkeen tuottavuus ei nouse, joskus jopa heikkenemistä näkyy. Tämä johtuu siitä, että verkon/ohjaimien/levyjen suorituskyky rajoittaa meitä.
- Jaksollinen lukunopeus 4432 MB/s.
- Sarjakirjoitus 804 MB/s.
- Jos yksi ohjain epäonnistuu (virtuaalikoneen tai isännän vika), suorituskyvyn lasku on kaksinkertainen.
- Jos tallennuslevy epäonnistuu, nosto on 1/3. Levyn uudelleenrakentaminen vie 5 % kunkin ohjaimen resursseista.
Pienellä lohkolla meitä rajoittaa ohjaimen (virtuaalikoneen) suorituskyky, sen prosessori on ladattu 100%, ja kun lohko kasvaa, meitä rajoittaa portin kaistanleveys. 10 Gbps ei riitä vapauttamaan AllFlash-järjestelmän potentiaalia. Valitettavasti toimitetun esittelytelineen parametrit eivät salli meidän testata toimintaa 40 Gbit/s.
Testeistä ja arkkitehtuurin tutkimisesta saamani vaikutelman mukaan dataa kaikkien isäntien väliin sijoittavan algoritmin ansiosta saamme skaalautuvan, ennustettavan suorituskyvyn, mutta tämä on myös rajoitus luettaessa, koska paikallisilta levyiltä olisi mahdollista puristaa enemmän irti, täällä voi säästää tuottavamman verkon, esimerkiksi 40 Gbit/s FI on saatavilla.
Myös yksi levy välimuistiin ja duplikoinnin poistamiseen voi olla rajoitus; itse asiassa tällä testialustalla voimme kirjoittaa neljälle SSD-levylle. Olisi hienoa pystyä lisäämään välimuistiasemien määrää ja nähdä ero.
Todellista käyttöä
Varmuuskopiointikeskuksen järjestämiseen voit käyttää kahta tapaa (emme harkitse varmuuskopion sijoittamista etäsivustoon):
- Aktiivi passiivi. Kaikki sovellukset sijaitsevat pääpalvelinkeskuksessa. Replikointi on synkronista tai asynkronista. Jos pääpalvelinkeskus epäonnistuu, meidän on aktivoitava varakeskus. Tämä voidaan tehdä manuaalisesti / komentosarjat / orkestrointisovellukset. Täällä saamme RPO:n, joka on verrannollinen replikointitiheyteen, ja RTO riippuu järjestelmänvalvojan reaktiosta ja taidoista sekä kytkentäsuunnitelman kehittämisen/virheenkorjauksen laadusta.
- Aktiivinen-aktiivinen. Tässä tapauksessa on vain synkroninen replikointi; palvelinkeskusten saatavuuden määrittää tiukasti kolmannessa paikassa sijaitseva koorumi/välimies. RPO = 0, ja RTO voi olla 0 (jos sovellus sallii) tai yhtä suuri kuin virtualisointiklusterin solmun vikasietoaika. Virtualisointitasolla luodaan venytetty (Metro) -klusteri, joka vaatii Active-Active-tallennustilan.
Yleensä näemme, että asiakkaat ovat jo ottaneet käyttöön arkkitehtuurin, jossa on klassinen tallennusjärjestelmä pääpalvelinkeskuksessa, joten suunnittelemme toisen replikointia varten. Kuten mainitsin, Cisco HyperFlex tarjoaa asynkronisen replikoinnin ja venytetyn virtualisointiklusterin luomisen. Samaan aikaan emme tarvitse keskitason tai korkeamman tason tallennusjärjestelmää, jossa on kalliit replikointitoiminnot ja Active-Active-tietojen käyttö kahdessa tallennusjärjestelmässä.
Skenaario 1: Meillä on ensisijainen ja varatietokeskus, virtualisointialusta VMware vSpheressä. Kaikki tuottavat järjestelmät sijaitsevat pääpalvelinkeskuksessa, ja virtuaalikoneiden replikointi suoritetaan hypervisor-tasolla, jolloin vältetään virtuaalikoneiden pitäminen päällä varmuuskopiointikeskuksessa. Replikoimme tietokantoja ja erikoissovelluksia sisäänrakennetuilla työkaluilla ja pidämme virtuaalikoneet päällä. Jos pääpalvelinkeskus epäonnistuu, käynnistämme järjestelmät varatietokeskuksessa. Uskomme, että meillä on noin 100 virtuaalikonetta. Kun ensisijainen palvelinkeskus on toiminnassa, valmiustilassa oleva palvelinkeskus voi käyttää testiympäristöjä ja muita järjestelmiä, jotka voidaan sulkea, jos ensisijainen palvelinkeskus vaihtuu. On myös mahdollista, että käytämme kaksisuuntaista replikointia. Laitteiston näkökulmasta mikään ei muutu.
Klassisen arkkitehtuurin tapauksessa asennamme jokaiseen palvelinkeskukseen hybriditallennusjärjestelmän, jossa on pääsy FibreChannelin kautta, porrastetus, duplikointi ja pakkaus (mutta ei verkossa), 8 palvelinta jokaiselle sivustolle, 2 FibreChannel-kytkintä ja 10G Ethernet. Klassisen arkkitehtuurin replikoinnin ja vaihdon hallintaan voimme käyttää VMware-työkaluja (Replication + SRM) tai kolmannen osapuolen työkaluja, jotka ovat hieman halvempia ja joskus kätevämpiä.
Kuvassa on kaavio.
Cisco HyperFlexiä käytettäessä saadaan seuraava arkkitehtuuri:
HyperFlexissä käytin palvelimia, joissa oli suuret CPU/RAM-resurssit, koska... Osa resursseista menee HyperFlex-ohjain VM:lle; prosessorin ja muistin osalta jopa konfiguroin HyperFlex-kokoonpanoa hieman uudelleen, jotta en leikkisi Ciscon kanssa ja takaa resurssit jäljellä oleville virtuaalikoille. Mutta voimme luopua FibreChannel-kytkimistä, emmekä tarvitse Ethernet-portteja jokaiselle palvelimelle, vaan paikallinen liikenne kytketään FI:n sisällä.
Tuloksena oli seuraava konfiguraatio jokaiselle datakeskukselle:
Palvelimet
8 x 1U palvelin (384 Gt RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 Gt RAM-muistia, 2 x Intel Gold 6150, 3,2 Gt SSD, 10 x 6 Tt NL-SAS)
SHD
Hybriditallennusjärjestelmä FC Front-Endillä (20 Tt SSD, 130 Tt NL-SAS)
-
LAN
2 x Ethernet-kytkin 10G 12 porttia
-
SAN
2 x FC-kytkin 32/16Gb 24 porttia
2 x Cisco UCS FI 6332
lisenssin
VMware Ent Plus
VM-vaihdon replikointi ja/tai organisointi
VMware Ent Plus
En toimittanut replikointiohjelmiston lisenssejä Hyperflexille, koska se on meille heti saatavilla.
Klassiseen arkkitehtuuriin valitsin myyjän, joka on vakiinnuttanut asemansa laadukkaana ja edullisena valmistajana. Molemmissa vaihtoehdoissa käytin tietyn ratkaisun vakioalennusta, ja sen seurauksena sain todellisia hintoja.
Cisco HyperFlex -ratkaisu osoittautui 13 % halvemmaksi.
Skenaario 2: kahden aktiivisen datakeskuksen luominen. Tässä skenaariossa suunnittelemme venytettyä klusteria VMwarelle.
Klassinen arkkitehtuuri koostuu virtualisointipalvelimista, SAN-protokollasta (FC-protokolla) ja kahdesta tallennusjärjestelmästä, jotka voivat lukea ja kirjoittaa niiden väliin venytetylle taltiolle. Jokaiseen tallennusjärjestelmään laitamme hyödyllisen varastointikapasiteetin.
HyperFlexissä luomme yksinkertaisesti Stretch Clusterin, jossa on sama määrä solmuja molemmissa sivustoissa. Tässä tapauksessa käytetään replikaatiokerrointa 2+2.
Tuloksena on seuraava kokoonpano:
klassista arkkitehtuuria
HyperFlex
Palvelimet
16 x 1U palvelin (384 Gt RAM-muistia, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)
16 x HX240C-M5L (512 Gt RAM-muistia, 2 x Intel Gold 6132, 1,6 Tt NVMe, 12 x 3,8 Tt SSD, VIC 1387)
SHD
2 x AllFlash tallennusjärjestelmää (150 TB SSD)
-
LAN
4 x Ethernet-kytkin 10G 24 porttia
-
SAN
4 x FC-kytkin 32/16Gb 24 porttia
4 x Cisco UCS FI 6332
lisenssin
VMware Ent Plus
VMware Ent Plus
Kaikissa laskelmissa en ottanut huomioon verkkoinfrastruktuuria, konesalin kustannuksia jne.: ne ovat samat klassiselle arkkitehtuurille ja HyperFlex-ratkaisulle.
Kustannusten suhteen HyperFlex osoittautui 5 % kalliimmaksi. Tässä kannattaa huomioida, että CPU/RAM-resurssien suhteen minulla oli vinossa Cisco, koska kokoonpanossa täytin muistiohjaimen kanavat tasaisesti. Kustannukset ovat hieman korkeammat, mutta ei suuruusluokkaa, mikä osoittaa selvästi, että hyperkonvergenssi ei välttämättä ole "rikkaiden lelu", vaan se voi kilpailla tavallisen palvelinkeskuksen rakentamistavan kanssa. Tämä saattaa kiinnostaa myös niitä, joilla on jo Cisco UCS -palvelimia ja niitä varten tarvittava infrastruktuuri.
Etujen joukossa saamme SAN- ja tallennusjärjestelmien hallintakustannusten puuttumisen, online-pakkauksen ja päällekkäisyyden poistamisen, yhden tukipisteen (virtualisointi, palvelimet, ne ovat myös tallennusjärjestelmiä), tilan säästämisen (mutta ei kaikissa skenaarioissa), yksinkertaistaa toimintaa.
Mitä tulee tukeen, täältä saat sen yhdeltä toimittajalta - Cisco. Kokemukseni Cisco UCS -palvelimista päätellen pidän siitä; minun ei tarvinnut avata sitä HyperFlexissä, kaikki toimi aivan samoin. Insinöörit reagoivat nopeasti ja voivat ratkaista tyypillisten ongelmien lisäksi myös monimutkaisia reunatapauksia. Joskus käännyn heidän puoleen kysymyksillä: "Onko mahdollista tehdä tämä, kiinnitä se?" tai "Määritin jotain tähän, mutta se ei halua toimia. Auta!" - he etsivät sieltä kärsivällisesti tarvittavan oppaan ja osoittavat oikeat toimenpiteet; he eivät vastaa: "Ratkaisemme vain laitteistoongelmia."
viittaukset
- Minun postini - [sähköposti suojattu]
Lähde: will.com