Yksi nuorista toimijoista Disaster Recovery -ratkaisujen markkinoilla on Hystax, venäläinen startup vuonna 2016. Koska katastrofipalautusaihe on erittäin suosittu ja markkinoilla erittäin kilpailtu, startup päätti keskittyä migraatioon eri pilviinfrastruktuurien välillä. Tuote, jonka avulla voit järjestää yksinkertaisen ja nopean siirtymisen pilveen, olisi erittäin hyödyllinen Onlantan asiakkaille - käyttäjille . Näin tutustuin Hystaxiin ja aloin testata sen ominaisuuksia. Ja mitä siitä tuli, kerron tässä artikkelissa.
Hystaxin pääominaisuus on sen laaja toiminnallisuus tukea erilaisia virtualisointialustoja, vieraskäyttöjärjestelmää ja pilvipalveluita, mikä mahdollistaa työkuormien siirtämisen mistä tahansa ja mistä tahansa.
Näin voit luoda paitsi DR-ratkaisuja palvelujen vikasietoisuuden parantamiseksi, myös siirtää resursseja nopeasti, joustavasti eri kohteiden ja hyperskaalaajien välillä kustannussäästöjen lisäämiseksi ja valita kulloinkin paras ratkaisu tiettyyn palveluun. Otsikkokuvassa lueteltujen alustojen lisäksi yritys tekee aktiivisesti yhteistyötä myös venäläisten pilvipalveluntarjoajien kanssa: Yandex.Cloud, CROC Cloud Services, Mail.ru ja monet muut. On myös huomionarvoista, että vuonna 2020 yritys avasi T&K-keskuksen, joka sijaitsee Skolkovossa.
Useiden markkinoiden toimijoiden yhden ratkaisun valinta osoittaa hyvää hinnoittelupolitiikkaa ja tuotteen korkeaa sovellettavuutta, jota päätimme testata käytännössä.
Testitehtävämme koostuu siis siirtymisestä VMware-testisivustoltani ja fyysisistä koneistani palveluntarjoajan sivustolle, joka myös käyttää VMwarea. Kyllä, on monia ratkaisuja, joilla tällainen migraatio voidaan toteuttaa, mutta pidämme Hystaxia universaalina työkaluna, ja migraation testaus kaikissa mahdollisissa yhdistelmissä on yksinkertaisesti epärealistinen tehtävä. Kyllä, ja Oncloud.ru-pilvi on rakennettu nimenomaan VMwarelle, joten tämä foorumi kohteena kiinnostaa meitä enemmän. Seuraavaksi kuvailen toiminnan perusperiaatetta, joka ei kokonaisuutena riipu alustasta ja VMware voidaan korvata miltä puolelta tahansa toisen valmistajan alustalla.
Ensimmäinen askel on ottaa käyttöön Hystax Acura, joka on järjestelmän ohjauspaneeli.
Se laajenee mallista. Jostain syystä meidän tapauksessamme se ei ollut täysin oikein ja suositellun 8CPU:n sijaan otettiin käyttöön 16 Gb puolet resursseista. Siksi älä unohda muuttaa niitä, muuten virtuaalikoneen sisällä oleva infrastruktuuri, jolle kaikki on rakennettu, ei yksinkertaisesti käynnisty konteilla ja portaali ei ole käytettävissä. SISÄÄN tarvittavat resurssit kuvataan yksityiskohtaisesti, samoin kuin portit kaikille järjestelmäkomponenteille.
Ja IP-osoitteen asettamisessa mallin kautta oli myös vaikeuksia, joten muutimme sen konsolista. Tämän jälkeen voit siirtyä järjestelmänvalvojan verkkokäyttöliittymään ja suorittaa ohjatun alkumääritystoiminnon.
Päätepiste - vCenterimme IP tai FQDN.
Kirjautumistunnus ja salasana - se on selkeä täällä.
Kohteen ESXi-isäntänimi on yksi klusterimme isännistä, joihin replikoidaan.
Kohdetietovarasto on yksi klusterin tietovarastoista, johon kopioidaan.
Hystax Acura Control Panel Public IP -osoite, jossa ohjauspaneeli on käytettävissä.
Vähän selvennystä isännästä ja tietovarastosta tarvitaan. Tosiasia on, että Hystax-replikointi toimii isäntä- ja tietovarastotasolla. Seuraavaksi kerron sinulle, kuinka voit vaihtaa vuokralaisen isännän ja tietovaraston, mutta ongelma on erilainen. Hystax ei tue resurssien yhdistämistä, ts. replika tapahtuu aina klusterin juurille (tätä materiaalia kirjoitettaessa Hystaxin kaverit julkaisivat päivitetyn version, jossa he toteuttivat nopeasti ominaisuuspyyntöni resurssipoolien tuesta). Myöskään vCloud Directoria ei tueta, esim. Jos vuokraajalla ei ole järjestelmänvalvojan oikeuksia koko klusteriin, vaan vain tiettyyn resurssipooliin, ja olemme antaneet pääsyn Hystaxiin, niin hän voi itsenäisesti replikoida ja käyttää näitä virtuaalikoneita, mutta ei voi nähdä niitä VMware-infrastruktuurissa, johon hänellä on pääsy, ja vastaavasti hallita virtuaalikoneita edelleen. Klusterin järjestelmänvalvojan on siirrettävä VM oikeaan resurssipooliin tai tuotava se vCloud Directoriin.
Miksi keskityn niin paljon näihin hetkiin? Koska sikäli kuin ymmärrän tuotteen konseptin, asiakkaan pitäisi pystyä itsenäisesti toteuttamaan mikä tahansa migraatio tai DR Acura-paneelin avulla. Mutta toistaiseksi VMware-tuki on hieman jäljessä saman OpenStackin tukitasosta, jossa tällaisia mekanismeja on jo otettu käyttöön.
Mutta takaisin käyttöönottoon. Ensinnäkin paneelin alkuasennuksen jälkeen meidän on luotava ensimmäinen vuokralainen järjestelmäämme.
Kaikki kentät täällä ovat tyhjiä, kerron vain Pilvi-kentästä. Meillä on jo "oletus" pilvi, jonka loimme alkukokoonpanon aikana. Mutta jos haluamme pystyä sijoittamaan jokaisen vuokralaisen omaan tietovarastoonsa ja omaan resurssivalikoimaansa, voimme toteuttaa tämän luomalla erilliset pilvet jokaiselle asiakkaallemme.
Uuden pilven lisäämisen muodossa määritämme samat parametrit kuin alkukonfiguroinnissa (voimme jopa käyttää samaa isäntää), määritämme tietylle asiakkaalle vaaditun tietovaraston ja nyt lisäparametreissa voimme jo määrittää yksilöllisesti vaadittu pooliresurssi {"resource_pool" :"YOUR_POOL_NAME"}
Kuten olet ehkä huomannut, vuokralaisen luomisessa ei ole mitään resurssien jakamisesta tai jonkinlaisesta kiintiöstä - järjestelmässä ei ole mitään sellaista. Et voi rajoittaa vuokraajaa samanaikaisten replikoiden, replikoitavien koneiden lukumäärän tai muiden parametrien suhteen. Olemme siis luoneet ensimmäisen vuokralaisen. Nyt ei ole täysin looginen, mutta pakollinen asia - Cloud-agentin asentaminen. Se on epäloogista, koska agentti ladataan tietyn asiakkaan sivulta.
Samalla se ei ole sidottu luotuun vuokraajaan, ja kaikki asiakkaamme käyvät läpi sen (tai usean jälkeen, jos otamme heidät käyttöön). Yksi agentti tukee 10 samanaikaista istuntoa. Yksi istunto lasketaan yhdeksi autoksi. Ei ole väliä kuinka monta levyä siinä on. Toistaiseksi itse Acurassa ei ole mekanismia skaalausagenttien VMwarelle. On vielä yksi epämiellyttävä hetki - emme pysty tarkastelemaan tämän agentin "käyttöä" Acura-paneelista tehdäksemme johtopäätöksen, tarvitseeko meidän ottaa käyttöön lisää vai riittääkö nykyinen asennus. Tämän seurauksena teline näyttää tältä:
Seuraava askel asiakasportaaliin pääsemiseksi on tilin luominen (ja ensin myös tälle käyttäjälle sovellettava rooli).
Nyt asiakkaamme voi käyttää portaalia itsenäisesti. Hänen tarvitsee vain ladata agentit portaalista ja asentaa ne puolelleen. Agentteja on kolmenlaisia: Linux, Windows ja VMware.
Kaksi ensimmäistä asetetaan fysiikkaan tai virtuaalikoneisiin missä tahansa muussa kuin VMware-hypervisorissa. Tässä ei tarvita lisäasetuksia, agentti lataa ja tietää jo minne koputtaa, ja kirjaimellisesti minuutin kuluttua auto on näkyvissä Acura-paneelissa. VMware-agentin kanssa tilanne on hieman monimutkaisempi. Ongelmana on, että Agent for VMware ladataan myös portaalista, joka on jo valmis ja jolla on tarvittavat asetukset. Mutta VMware-agentin on sen lisäksi, että hän tietää Acura-portaalistamme, myös se virtualisointijärjestelmä, jossa se otetaan käyttöön.
Itse asiassa järjestelmä pyytää meitä määrittämään nämä tiedot, kun lataamme VMware-agentin ensimmäistä kertaa. Ongelmana on, että yleisen turvallisuuden aikakaudellamme kaikki eivät halua ilmoittaa järjestelmänvalvojan salasanaansa jonkun muun portaalissa, mikä on täysin ymmärrettävää. Sisältä, käyttöönoton jälkeen, agenttia ei voi määrittää millään tavalla (voit muuttaa vain sen verkkoasetuksia). Tässä ennakoin vaikeuksia erityisen varovaisten asiakkaiden kanssa.
Joten agenttien asentamisen jälkeen voimme palata Acura-paneeliin ja nähdä kaikki automme.
Koska olen työskennellyt järjestelmän parissa yli päivän, minulla on koneita eri tilassa. Ne kaikki ovat Oletus-ryhmässä, mutta on mahdollista luoda erillisiä ryhmiä ja siirtää niihin koneita tarpeen mukaan. Tämä ei vaikuta mihinkään - vain tietojen loogiseen esitykseen ja niiden ryhmittelyyn mukavampaa työtä varten. Ensimmäinen ja tärkein asia, joka meidän on tehtävä sen jälkeen, on aloittaa siirtoprosessi. Voimme tehdä tämän sekä väkisin manuaalisesti että määrittää aikataulun, mukaan lukien irtotavarana kaikille koneille kerralla.
Haluan muistuttaa, että Hystax asetettiin siirtotuotteeksi. Siksi ei ole yllättävää, että meidän on luotava DR-suunnitelma voidaksemme käyttää kopioituja koneitamme. Voit luoda suunnitelman koneille, jotka ovat jo synkronoitu-tilassa. Voit luoda sekä yhdelle tietylle VM:lle että kaikille koneille kerralla.
DR-suunnitelmaa luotaessa käytettävät parametrit vaihtelevat sen infrastruktuurin mukaan, johon siirryt. VMware-ympäristössä on käytettävissä pieni joukko vaihtoehtoja. Myöskään koneiden IP:n uudelleenvaihtoa ei tueta. Tässä suhteessa olemme kiinnostuneita seuraavista kohdista: VM:n kuvauksessa "aliverkko"-parametri: "VMNetwork", jossa sitomme VM:n tiettyyn verkkoon klusterissa. Sijoitus - merkityksellinen siirrettäessä useita virtuaalikoneita, määrittää järjestyksen, jossa ne käynnistetään. Flavor kuvaa VM-kokoonpanoa, tässä tapauksessa 1CPU, 2GB RAM. Aliverkot-osiossa määritämme, että "aliverkko": "VMNetwork" liittyy VMwaren "VM-verkkoon".
Kun luot DR-suunnitelmaa, levyjä ei voi "jakaa" eri tietovarastoihin. Ne sijaitsevat samassa tietovarastossa, joka on määritetty tälle asiakaspilvelle, ja jos sinulla on eri luokkien levyjä, tämä voi aiheuttaa vaikeuksia koneen käynnistyksessä ja kun VM on käynnistetty ja "erotettu" Hystaxista, se myös vaativat erilliset siirtolevyt vaadittuihin tietovarastoihin. Sitten meidän on vain suoritettava DR-suunnitelmamme ja odotettava, että automme nousevat. Myös P2V/V2V-muunnosprosessi vie aikaa. Suurimmalla 100 Gt:n testikoneellani kolmella levyllä tämä kesti enintään 10 minuuttia.
Tämän jälkeen kannattaa tarkistaa käynnissä oleva VM, sen palvelut, tietojen yhdenmukaisuus ja muut tarkistukset.
Sitten meillä on kaksi vaihtoehtoa:
- Poista - poista käynnissä oleva DR-suunnitelma. Tämä toiminto yksinkertaisesti sammuttaa käynnissä olevan virtuaalikoneen. Nämä kopiot eivät katoa mihinkään.
- Irrota - repäise replikoitu auto Acurasta, ts. todella suorittaa siirtoprosessin.
Ratkaisun edut:
- asennuksen ja konfiguroinnin helppous sekä asiakas- että toimittajapuolella;
- siirtymisen, DR-suunnitelman luomisen ja kopioiden käynnistämisen helppous;
- tuki ja kehittäjät reagoivat melko nopeasti löydettyihin ongelmiin ja korjaavat ne alusta- tai agenttipäivityksillä.
Miinukset
- Riittämätön Vmware-tuki.
- Vuokralaisten kiintiön puuttuminen alustalta.
Tein myös ominaisuuspyynnön, jonka luovutimme myyjälle:
- käytön seuranta ja käyttöönotto Acura Management Consolesta Cloud Agentsille;
- vuokralaisten kiintiöiden saatavuus;
- kyky rajoittaa kunkin vuokralaisen samanaikaisten kopioiden määrää ja nopeutta;
- tuki VMware vCloud Directorille;
- resurssipoolien tuki (otettiin käyttöön testauksen aikana);
- kyky määrittää VMware-agentti itse agentin puolelta syöttämättä valtuustietoja asiakasinfrastruktuurista Acura-paneelissa;
- Virtuaalikoneen käynnistysprosessin "visualisointi" DR-suunnitelmaa käynnistettäessä.
Ainoa asia, joka aiheutti minulle suuria valituksia, oli dokumentaatio. En todellakaan pidä "mustista laatikoista" ja pidän siitä, että tuotteen sisällä on yksityiskohtainen dokumentaatio siitä, miten tuote toimii. Ja jos AWS:lle ja OpenStackille tuote on kuvattu enemmän tai vähemmän, niin VMwarelle on hyvin vähän dokumentaatiota.
Siellä on asennusopas, joka kuvaa vain Acura-paneelin käyttöönottoa ja jossa ei ole sanaakaan pilviagentin tarpeesta. Tuotteelle on olemassa täydellinen joukko teknisiä tietoja, mikä on hyvä. On dokumentaatiota, joka kuvaa asennuksen "alkaen ja asti" käyttämällä esimerkkinä AWS:ää ja OpenStackia (vaikka se muistuttaa minua enemmän blogikirjoituksesta), ja siellä on hyvin pieni Knowledge Base.
Yleensä tämä ei ole aivan se dokumentaatiomuoto, johon olen tottunut, vaikkapa isommilta myyjiltä, joten en ollut täysin mukava. Samaan aikaan en löytänyt tästä dokumentaatiosta vastauksia joihinkin järjestelmän toiminnan vivahteisiin "sisältä" - jouduin selvittämään monia kysymyksiä teknisen tuen kanssa, mikä pikemminkin hidasti telineen käyttöönottoprosessia ja testaus.
Yhteenvetona voin sanoa, että yleisesti ottaen pidin tuotteesta ja yrityksen lähestymistavasta tehtävän toteuttamiseen. Kyllä, on puutteita, on todella kriittinen toiminnallisuuden puute (yhdessä VMwaren kanssa). Voidaan nähdä, että ensinnäkin yritys keskittyy edelleen julkisiin pilviin, erityisesti AWS:ään, ja joillekin tämä riittää. Näin yksinkertaisen ja kätevän tuotteen saaminen nykyään, kun monet yritykset valitsevat monipilvistrategian, on erittäin tärkeää. Koska hinta on paljon alhaisempi verrattuna kilpailijoihin, tämä tekee tuotteesta erittäin houkuttelevan.
Etsimme tiimiä . Ehkä se olet sinä?
Lähde: will.com