Hei Habr-lukijat. Tällä artikkelilla avaamme sarjan, joka kertoo kehittämästämme hyperkonvergoidusta AERODISK VAIR -järjestelmästä. Aluksi halusimme kertoa kaiken kaikesta ensimmäisessä artikkelissa, mutta järjestelmä on melko monimutkainen, joten syömme norsun osissa.
Aloitetaan tarina järjestelmän luomisen historiasta, syvennetään vAIR:n perustana olevaan ARDFS-tiedostojärjestelmään ja puhutaan myös hieman tämän ratkaisun sijoittumisesta Venäjän markkinoille.
Tulevissa artikkeleissa puhumme tarkemmin erilaisista arkkitehtonisista komponenteista (klusteri, hypervisor, kuormituksen tasapainottaja, valvontajärjestelmä, jne.), konfigurointiprosessista, nostamme esille lisenssiongelmia, näytämme erikseen törmäystestejä ja tietysti kirjoitamme kuormitustestauksesta ja mitoitus. Omistamme myös erillisen artikkelin vAIR:n yhteisöversiolle.
Onko Aerodisk tarina tallennusjärjestelmistä? Tai miksi aloimme tehdä hyperkonvergenssia?
Aluksi ajatus oman hyperkonvergenssimme luomisesta syntyi jossain vuoden 2010 tienoilla. Tuolloin markkinoilla ei ollut Aerodiskiä eikä vastaavia ratkaisuja (kaupallisia boxed hyperconverged -järjestelmiä). Tehtävämme oli seuraava: joukosta palvelimia, joissa oli paikallisia levyjä, joita yhdistää Ethernet-protokollan kautta tapahtuva yhteys, oli tarpeen luoda laajennettu tallennustila ja käynnistää siellä virtuaalikoneita ja ohjelmistoverkko. Kaikki tämä piti toteuttaa ilman tallennusjärjestelmiä (koska tallennusjärjestelmiin ja niiden laitteistoihin ei yksinkertaisesti ollut rahaa, emmekä olleet vielä keksineet omia tallennusjärjestelmiä).
Kokeilimme monia avoimen lähdekoodin ratkaisuja ja lopulta ratkaisimme tämän ongelman, mutta ratkaisu oli erittäin monimutkainen ja vaikea toistaa. Lisäksi tämä ratkaisu kuului kategoriaan "Toimiiko se? Älä koske! Tämän ongelman ratkaistuamme emme siis kehittäneet ajatusta työmme tuloksen muuntamisesta täysimittaiseksi tuotteeksi.
Tuon tapauksen jälkeen siirryimme pois tästä ajatuksesta, mutta silti meillä oli tunne, että tämä ongelma oli täysin ratkaistavissa, ja tällaisen ratkaisun edut olivat enemmän kuin ilmeisiä. Myöhemmin ulkomaisten yritysten HCI-tuotteet vain vahvistivat tätä tunnetta.
Siksi vuoden 2016 puolivälissä palasimme tähän tehtävään osana täysimittaisen tuotteen luomista. Tuolloin meillä ei vielä ollut suhteita sijoittajiin, joten jouduimme ostamaan kehitysosaston omalla ei kovin isolla rahalla. Kerättyämme käytetyt palvelimet ja kytkimet Avitoon, päästiin töihin.
Päätehtävänä oli luoda oma, vaikkakin yksinkertainen, mutta oma tiedostojärjestelmämme, joka pystyisi automaattisesti ja tasaisesti jakamaan dataa virtuaalilohkojen muodossa n:nnelle klusterisolmulle, jotka on liitetty toisiinsa Ethernetin kautta. Samalla FS:n tulee skaalata hyvin ja helposti ja olla riippumaton viereisistä järjestelmistä, ts. vieraannuttaa vAIR:sta "vain varaston" muodossa.
Ensimmäinen vAIR-konsepti
Luovuimme tietoisesti valmiiden avoimen lähdekoodin ratkaisujen käytöstä venytetyn varastoinnin järjestämiseen (ceph, gluster, luster ym.) oman kehityksemme hyväksi, koska meillä oli niistä jo paljon projektikokemusta. Tietysti nämä ratkaisut itsessään ovat erinomaisia, ja ennen kuin työskentelimme Aerodiskin parissa, toteutimme niiden kanssa useamman kuin yhden integraatioprojektin. Mutta yksi asia on toteuttaa tietty tehtävä yhdelle asiakkaalle, kouluttaa henkilökuntaa ja ehkä ostaa suuren myyjän tuki, ja aivan toinen asia on luoda helposti kopioitava tuote, jota käytetään erilaisiin tehtäviin, joita me myyjä, ehkä emme tiedä itsestämme. Toiseksi olemassa olevat avoimen lähdekoodin tuotteet eivät olleet meille sopivia, joten päätimme luoda itse hajautetun tiedostojärjestelmän.
Kaksi vuotta myöhemmin useat kehittäjät (jotka yhdistivät vAIR-työn klassiseen Engine-tallennusjärjestelmään) saavuttivat tietyn tuloksen.
Vuoteen 2018 mennessä olimme kirjoittaneet yksinkertaisen tiedostojärjestelmän ja täydentäneet sitä tarvittavalla laitteistolla. Järjestelmä yhdisti eri palvelimilta tulevat fyysiset (paikalliset) levyt yhdeksi tasaiseksi pooliksi sisäisen liitännän kautta ja "leikkasi" ne virtuaalisiksi lohkoiksi, minkä jälkeen virtuaalilohkoista luotiin eriasteisia vikasietoisia lohkolaitteita, joille luotiin virtuaalisia. ja suoritettiin KVM-hypervisor-autoilla.
Emme välittäneet liikaa tiedostojärjestelmän nimestä ja kutsuimme sitä ytimekkäästi ARDFS:ksi (arvatkaa mitä se tarkoittaa)
Tämä prototyyppi näytti hyvältä (ei tietenkään visuaalisesti, visuaalista suunnittelua ei vielä ollut) ja osoitti hyviä tuloksia suorituskyvyn ja skaalauksen suhteen. Ensimmäisen todellisen tuloksen jälkeen laitoimme tämän projektin liikkeelle, organisoimme täysimittaisen kehitysympäristön ja erillisen tiimin, joka käsitteli vain vAIR:ia.
Juuri siihen mennessä ratkaisun yleinen arkkitehtuuri oli kypsynyt, mikä ei ole vielä kokenut suuria muutoksia.
Sukellus ARDFS-tiedostojärjestelmään
ARDFS on vAIR:n perusta, joka tarjoaa hajautetun, vikasietoisen tiedontallennustilan koko klusterin alueella. Yksi (mutta ei ainoa) ARDFS:n erityispiirteistä on, että se ei käytä muita omistettuja palvelimia metatietoihin ja hallintaan. Tämä oli alun perin suunniteltu yksinkertaistamaan ratkaisun konfigurointia ja parantamaan sen luotettavuutta.
Varastointirakenne
Kaikissa klusterin solmuissa ARDFS järjestää loogisen poolin kaikesta käytettävissä olevasta levytilasta. On tärkeää ymmärtää, että pooli ei ole vielä dataa tai muotoiltua tilaa, vaan yksinkertaisesti merkintää, ts. Kaikki solmut, joihin on asennettu vAIR, lisätään automaattisesti jaettuun ARDFS-pooliin, ja levyresurssit jaetaan automaattisesti koko klusterin kesken (ja ovat käytettävissä tulevaa tietojen tallennusta varten). Tämän lähestymistavan avulla voit lisätä ja poistaa solmuja lennossa ilman vakavaa vaikutusta jo käynnissä olevaan järjestelmään. Nuo. järjestelmä on erittäin helppo skaalata "tiileissä", tarvittaessa lisäämällä tai poistamalla klusterin solmuja.
ARDFS-poolin päälle lisätään virtuaalilevyjä (virtuaalikoneiden tallennusobjekteja), jotka on rakennettu 4 megatavun kokoisista virtuaalilohkoista. Virtuaalilevyt tallentavat tiedot suoraan. Vikasietokaavio asetetaan myös virtuaalilevytasolle.
Kuten olet ehkä jo arvannut, emme käytä levyalijärjestelmän vikasietoisuutta varten RAID-käsitettä (Redundant array of independent Disks), vaan käytämme RAINia (Redundant array of itsenäisiä solmuja). Nuo. Vikasietokyky mitataan, automatisoidaan ja hallitaan solmujen, ei levyjen, perusteella. Levyt ovat tietysti myös tallennusobjekteja, niitä, kuten kaikkea muutakin, valvotaan, niillä voi suorittaa kaikki vakiotoiminnot, mukaan lukien paikallisen laitteisto-RAIDin kokoaminen, mutta klusteri toimii nimenomaan solmuissa.
Tilanteessa, jossa todella haluat RAIDin (esimerkiksi skenaario, joka tukee useita vikoja pienissä klusteissa), mikään ei estä sinua käyttämästä paikallisia RAID-ohjaimia ja rakentamasta venytettyä tallennustilaa ja RAIN-arkkitehtuuria päälle. Tämä skenaario on melko elävä ja tuemme sitä, joten puhumme siitä artikkelissa, joka käsittelee tyypillisiä vAIRin käyttöskenaarioita.
Varastoinnin vikasietojärjestelmät
VAIRissa voi olla kaksi vikasietojärjestelmää virtuaalisille levyille:
1) Replikointitekijä tai yksinkertaisesti replikointi - tämä vikasietomenetelmä on yhtä yksinkertainen kuin keppi ja köysi. Synkroninen replikointi suoritetaan solmujen välillä kertoimella 2 (2 kopiota per klusteri) tai 3 (3 kopiota, vastaavasti). RF-2 sallii virtuaalisen levyn kestää klusterin yhden solmun vian, mutta "syö" puolet hyödyllisestä tilavuudesta, ja RF-3 kestää klusterin kahden solmun vian, mutta varaa 2/2 hyödyllinen tilavuus sen tarpeisiin. Tämä malli on hyvin samanlainen kuin RAID-3, eli RF-1:ssa määritetty virtuaalilevy kestää minkä tahansa klusterin solmun vikoja. Tässä tapauksessa kaikki on kunnossa tietojen kanssa, eikä edes I/O pysähdy. Kun kaatunut solmu palaa palveluun, automaattinen tietojen palautus/synkronointi alkaa.
Alla on esimerkkejä RF-2- ja RF-3-tietojen jakautumisesta normaalitilassa ja vikatilanteessa.
Meillä on virtuaalikone, jonka kapasiteetti on 8 Mt ainutlaatuista (hyödyllistä) dataa ja joka toimii 4 vAIR-solmussa. On selvää, että todellisuudessa on epätodennäköistä, että niin pieni määrä tulee olemaan, mutta ARDFS:n toiminnan logiikkaa heijastavalle järjestelmälle tämä esimerkki on ymmärrettävin. AB ovat 4 Mt:n virtuaalilohkoja, jotka sisältävät ainutlaatuista virtuaalikoneen dataa. RF-2 luo kaksi kopiota näistä lohkoista A1+A2 ja B1+B2, vastaavasti. Nämä lohkot on "aseteltu" solmujen poikki, jolloin vältetään saman datan leikkaus samassa solmussa, eli kopio A1 ei sijaitse samassa solmussa kuin kopio A2. Sama B1:n ja B2:n kanssa.
Jos jokin solmuista epäonnistuu (esimerkiksi solmu nro 3, joka sisältää kopion B1:stä), tämä kopio aktivoituu automaattisesti solmussa, jossa ei ole kopiota sen kopiosta (eli kopiosta B2).
Siten virtuaalilevy (ja vastaavasti VM) selviytyy helposti yhden solmun epäonnistumisesta RF-2-järjestelmässä.
Replikointijärjestelmä, vaikka se on yksinkertainen ja luotettava, kärsii samasta ongelmasta kuin RAID1 - ei tarpeeksi tilaa.
2) Pyyhkimiskoodaus tai poistokoodaus (tunnetaan myös nimellä "redundantti koodaus", "poistokoodaus" tai "redundanssikoodi") on olemassa yllä olevan ongelman ratkaisemiseksi. EC on redundanssijärjestelmä, joka tarjoaa korkean tiedon saatavuuden pienemmällä levytilalla replikointiin verrattuna. Tämän mekanismin toimintaperiaate on samanlainen kuin RAID 5, 6, 6P.
Koodattaessa EC-prosessi jakaa virtuaalisen lohkon (oletusarvoisesti 4 Mt) useampaan pienempään "datalohkoon" EC-mallin mukaan (esimerkiksi 2+1-malli jakaa jokaisen 4 Mt:n lohkon 2 2 Mt:n paloiksi). Seuraavaksi tämä prosessi luo "tietopaloihin" "pariteettipaloja", jotka eivät ole suurempia kuin yksi aiemmin jaetuista osista. Dekoodattaessa EC luo puuttuvat palaset lukemalla "eloonjääneet" tiedot koko klusterista.
Esimerkiksi virtuaalilevy 2 + 1 EC -mallilla, joka on toteutettu 4 klusterin solmussa, kestää helposti klusterin yhden solmun vian samalla tavalla kuin RF-2. Tällöin yleiskustannukset ovat pienemmät, erityisesti hyötykapasiteettikerroin RF-2:lle on 2 ja EC 2+1:lle 1,5.
Yksinkertaisemmin kuvattuna olemus on, että virtuaalilohko on jaettu 2-8 (miksi 2 - 8, katso alla) "kappaleeseen", ja näille kappaleille lasketaan vastaavan tilavuuden pariteetin "kappaleet".
Tämän seurauksena data ja pariteetti jakautuvat tasaisesti klusterin kaikkiin solmuihin. Samaan aikaan, kuten replikoinnin yhteydessä, ARDFS jakaa tiedot automaattisesti solmujen kesken siten, että estetään identtisten tietojen (tietojen kopioiden ja niiden pariteetin) tallentaminen samaan solmuun, jotta vältetään tietojen menettämisen mahdollisuus. siihen, että tiedot ja niiden pariteetti päätyvät yhtäkkiä yhteen tallennussolmuun, joka epäonnistuu.
Alla on esimerkki, jossa on sama 8 Mt:n virtuaalikone ja 4 solmua, mutta EC 2+1 -mallilla.
Lohkot A ja B on jaettu kahteen 2 Mt:n osaan (kaksi koska 2+1), eli A1+A2 ja B1+B2. Toisin kuin replika, A1 ei ole kopio A2:sta, se on virtuaalinen lohko A, jaettu kahteen osaan, sama lohkon B kanssa. Saamme yhteensä kaksi 4 Mt:n sarjaa, joista kumpikin sisältää kaksi kahden megatavun kappaletta. Seuraavaksi kullekin näistä joukoista lasketaan pariteetti enintään yhden kappaleen (eli 2 MB) tilavuudella, saadaan lisä + 2 pariteettiyksikköä (AP ja BP). Yhteensä meillä on 4×2 dataa + 2×2 pariteetti.
Seuraavaksi palat "asetetaan" solmujen joukkoon, jotta tiedot eivät leikkaa niiden pariteettia. Nuo. A1 ja A2 eivät ole samassa solmussa kuin AP.
Yhden solmun (esimerkiksi myös kolmannen) vikaantuessa kaatunut lohko B1 palautetaan automaattisesti BP-pariteetista, joka on tallennettu solmuun nro 2, ja aktivoituu siinä solmussa, jossa on ei B-pariteettia, ts. pala BP:tä. Tässä esimerkissä tämä on solmu nro 1
Olen varma, että lukijalla on kysymys:
"Kaikki kuvailemasi on jo pitkään otettu käyttöön sekä kilpailijoiden toimesta että avoimen lähdekoodin ratkaisuissa. Mitä eroa on EC:n toteutuksella ARDFS:ssä?"
Ja sitten on mielenkiintoisia ominaisuuksia ARDFS: stä.
Poista koodaus keskittyen joustavuuteen
Aluksi tarjosimme melko joustavan EC X+Y -kaavion, jossa X on yhtä suuri kuin luku 2 - 8 ja Y on yhtä suuri kuin luku 1 - 8, mutta aina pienempi tai yhtä suuri kuin X. Tämä malli tarjotaan joustavuuden vuoksi. Tietojen määrän (X) lisääminen, joihin virtuaalilohko on jaettu, mahdollistaa yleiskustannusten vähentämisen eli käyttötilan lisäämisen.
Pariteettipalojen (Y) määrän lisääminen lisää virtuaalilevyn luotettavuutta. Mitä suurempi Y-arvo, sitä useampi klusterin solmu voi epäonnistua. Tietysti pariteettivolyymin lisääminen vähentää käytettävissä olevan kapasiteetin määrää, mutta tämä on hinta, joka maksetaan luotettavuudesta.
Suorituskyvyn riippuvuus EC-piireistä on lähes suora: mitä enemmän "kappaleita", sitä pienempi suorituskyky; tässä tietysti tarvitaan tasapainoista näkemystä.
Tämän lähestymistavan avulla järjestelmänvalvojat voivat määrittää venytettyä tallennustilaa mahdollisimman joustavasti. ARDFS-poolissa voit käyttää mitä tahansa vikasietojärjestelmiä ja niiden yhdistelmiä, mikä on mielestämme myös erittäin hyödyllistä.
Alla on taulukko, jossa verrataan useita (ei kaikkia mahdollisia) RF- ja EC-järjestelmiä.
Taulukko osoittaa, että jopa kaikkein "froteisin" yhdistelmä EC 8+7, joka mahdollistaa jopa 7 solmun katoamisen klusterissa samanaikaisesti, "syö" vähemmän hyödyllistä tilaa (1,875 vs. 2) kuin tavallinen replikointi ja suojaa 7 kertaa paremmin , mikä tekee tästä suojausmekanismista, vaikkakin monimutkaisemman, paljon houkuttelevamman tilanteissa, joissa on tarpeen varmistaa maksimaalinen luotettavuus rajoitetun levytilan olosuhteissa. Samanaikaisesti sinun on ymmärrettävä, että jokainen "plus" X:lle tai Y:lle on lisäsuorituskyky, joten luotettavuuden, säästöjen ja suorituskyvyn välisessä kolmiossa sinun on valittava erittäin huolellisesti. Tästä syystä omistamme erillisen artikkelin poistokoodauksen mitoituksesta.
Tiedostojärjestelmän luotettavuus ja autonomia
ARDFS toimii paikallisesti kaikissa klusterin solmuissa ja synkronoi ne omin keinoin omistettujen Ethernet-liitäntöjen kautta. Tärkeää on, että ARDFS synkronoi itsenäisesti paitsi datan myös tallennukseen liittyvät metatiedot. Työskennellessämme ARDFS:n parissa tutkimme samanaikaisesti useita olemassa olevia ratkaisuja ja huomasimme, että monet synkronoivat tiedostojärjestelmän metan käyttämällä ulkoista hajautettua DBMS:ää, jota käytämme myös synkronointiin, mutta vain määrityksiä, ei FS-metatietoja (tästä ja muista asiaan liittyvistä alijärjestelmistä seuraavassa artikkelissa).
FS-metatietojen synkronointi ulkoisen DBMS:n avulla on tietysti toimiva ratkaisu, mutta silloin ARDFS:ään tallennettujen tietojen johdonmukaisuus riippuisi ulkoisesta DBMS:stä ja sen käyttäytymisestä (ja suoraan sanottuna se on oikukas nainen), joka mielipiteemme on huono. Miksi? Jos FS-metadata vaurioituu, itse FS-datalle voidaan myös sanoa "näkemiin", joten päätimme valita monimutkaisemman mutta luotettavan polun.
Teimme itse ARDFS:lle metatietojen synkronointialijärjestelmän, joka toimii täysin riippumattomasti viereisistä alijärjestelmistä. Nuo. mikään muu alajärjestelmä ei voi turmella ARDFS-tietoja. Mielestämme tämä on luotettavin ja oikea tapa, mutta aika näyttää, onko näin todella. Lisäksi tällä lähestymistavalla on lisäetu. ARDFS:ää voidaan käyttää vAIRista riippumatta, aivan kuten venytettyä säilytystä, jota tulemme varmasti käyttämään tulevissa tuotteissa.
Tämän seurauksena ARDFS:ää kehittämällä saimme joustavan ja luotettavan tiedostojärjestelmän, joka antaa mahdollisuuden valita, missä voit säästää kapasiteettia tai luopua kaikesta suorituskyvystä tai tehdä erittäin luotettavaa tallennustilaa kohtuullisin kustannuksin, mutta suorituskykyvaatimuksia alentaen.
Yhdessä yksinkertaisen lisensointipolitiikan ja joustavan toimitusmallin kanssa (tulevaisuudessa vAIR lisensoidaan solmukohtaisesti ja toimitetaan joko ohjelmistona tai ohjelmistopakettina) tämä mahdollistaa ratkaisun erittäin tarkasti räätälöimisen monenlaisiin asiakkaiden tarpeisiin ja tarpeisiin. sitten säilyttää tämä tasapaino helposti.
Kuka tarvitsee tätä ihmettä?
Toisaalta voidaan sanoa, että markkinoilla on jo toimijoita, joilla on vakavia ratkaisuja hyperkonvergenssin alalla, ja tähän olemme itse asiassa menossa. Tämä väite näyttää olevan totta, MUTTA...
Toisaalta, kun menemme pellolle ja kommunikoimme asiakkaiden kanssa, näemme kumppanimme kanssa, että näin ei ole ollenkaan. Hyperkonvergenssin tehtäviä on monia, paikoin ihmiset eivät yksinkertaisesti tienneet tällaisten ratkaisujen olemassaolosta, toisaalla ne tuntuivat kalliilta, toisaalla vaihtoehtoisia ratkaisuja testattiin epäonnistuneesti, ja toisaalla ne kieltävät ostamisen kokonaan sanktioiden takia. Yleensä pelto osoittautui kyntämättömäksi, joten menimme nostamaan neitseellistä maaperää))).
Milloin tallennusjärjestelmä on parempi kuin GCS?
Kun työskentelemme markkinoiden kanssa, meiltä kysytään usein, milloin on parempi käyttää klassista mallia tallennusjärjestelmien kanssa ja milloin käyttää hyperkonvergenttia? Monet GCS:ää valmistavat yritykset (erityisesti ne, joilla ei ole tallennusjärjestelmiä) sanovat: "Tallennusjärjestelmät ovat vanhentumassa, vain hyperkonvergoituneet!" Tämä on rohkea lausunto, mutta se ei täysin vastaa todellisuutta.
Itse asiassa tallennusmarkkinat ovat todellakin siirtymässä kohti hyperkonvergenssia ja vastaavia ratkaisuja, mutta aina löytyy "mutta".
Ensinnäkin perinteisen kaavan mukaan rakennettuja datakeskuksia ja IT-infrastruktuureja tallennusjärjestelmillä ei voida helposti rakentaa uudelleen, joten tällaisten infrastruktuurien modernisointi ja valmistuminen on vielä 5-7 vuoden perintö.
Toiseksi tällä hetkellä rakennettava infrastruktuuri (eli Venäjän federaatio) on rakennettu suurimmaksi osaksi perinteisen kaavan mukaan käyttämällä tallennusjärjestelmiä, eikä siksi, että ihmiset eivät tietäisi hyperkonvergenssista, vaan koska hyperkonvergenssimarkkinat ovat uudet, ratkaisut ja standardeja ei ole vielä laadittu, IT-henkilöitä ei ole vielä koulutettu, heillä on vähän kokemusta, mutta heidän on rakennettava datakeskuksia tässä ja nyt. Ja tämä suuntaus kestää vielä 3-5 vuotta (ja sitten toinen perintö, katso kohta 1).
Kolmanneksi, pienet 2 millisekunnin lisäviiveet kirjoitusta kohti (lukuun ottamatta tietysti paikallista välimuistia) ovat puhtaasti tekniset rajoitukset, jotka ovat hajautetun tallennustilan kustannuksia.
No, älkäämme unohtako suurten fyysisten palvelimien käyttöä, jotka rakastavat levyalijärjestelmän vertikaalista skaalausta.
On monia tarpeellisia ja suosittuja tehtäviä, joissa tallennusjärjestelmät toimivat paremmin kuin GCS. Tässä tietenkään ne valmistajat, joilla ei ole varastojärjestelmiä tuotevalikoimassaan, eivät ole kanssamme samaa mieltä, mutta olemme valmiita väittelemään järkevästi. Tietenkin me molempien tuotteiden kehittäjinä vertaamme ehdottomasti tallennusjärjestelmiä ja GCS:ää jossain tulevassa julkaisussamme, jossa näytämme selkeästi kumpi on parempi missä olosuhteissa.
Ja missä hyperkonvergoidut ratkaisut toimivat paremmin kuin tallennusjärjestelmät?
Edellä olevien kohtien perusteella voidaan tehdä kolme selvää johtopäätöstä:
- Siellä missä 2 millisekuntia ylimääräistä tallennuksen latenssia, jota esiintyy johdonmukaisesti missä tahansa tuotteessa (nyt emme puhu synteettistä, nanosekuntia voidaan näyttää synteettisellä), on kriittinen, hyperkonvergentti sopii.
- Kun suurten fyysisten palvelimien kuorma voidaan muuttaa moniksi pieniksi virtuaalisiksi ja jakaa solmujen kesken, myös hyperkonvergenssi toimii siellä hyvin.
- Jos vaakasuuntainen skaalaus on korkeampi prioriteetti kuin pystyskaalaus, GCS pärjää hyvin myös siellä.
Mitä nämä ratkaisut ovat?
- Kaikki perusinfrastruktuuripalvelut (hakemistopalvelu, sähköposti, EDMS, tiedostopalvelimet, pienet tai keskisuuret ERP- ja BI-järjestelmät jne.). Kutsumme tätä "yleiseksi tietojenkäsittelyksi".
- Pilvipalveluntarjoajien infrastruktuuri, jossa on tarpeen nopeasti ja standardoidusti horisontaalisesti laajentaa ja helposti "leikata" suuri määrä virtuaalikoneita asiakkaille.
- Virtual Desktop Infrastruktuuri (VDI), jossa monet pienten käyttäjien virtuaalikoneet toimivat ja "kelluvat" hiljaa yhtenäisessä klusterissa.
- Haaraverkot, joissa jokainen haara tarvitsee standardin, vikasietoisen, mutta edullisen 15-20 virtuaalikoneen infrastruktuurin.
- Mikä tahansa hajautettu laskenta (esimerkiksi suurdatapalvelut). Missä kuorma ei kulje "syvyyteen", vaan "leveyteen".
- Testausympäristöt, joissa ylimääräiset pienet viiveet ovat hyväksyttäviä, mutta budjettirajoituksia on, koska nämä ovat testejä.
Tällä hetkellä juuri näihin tehtäviin olemme tehneet AERODISK VAIRin ja niihin keskitymme (toistaiseksi onnistuneesti). Ehkä tämä muuttuu pian, koska... maailma ei pysy paikallaan.
Niin…
Tämä täydentää suuren artikkelisarjan ensimmäisen osan, seuraavassa artikkelissa puhumme ratkaisun arkkitehtuurista ja käytetyistä komponenteista.
Otamme mielellämme vastaan kysymyksiä, ehdotuksia ja rakentavia kiistoja.
Lähde: will.com