Een van de jonge spelers op de markt voor oplossingen voor Disaster Recovery is het bedrijf Hystax - een Russische startup uit 2016. Aangezien het onderwerp van noodherstel zeer populair is en er extreem hoge concurrentie op de markt is, besloot de startup zich te concentreren op migratie tussen verschillende cloudinfrastructuren. Een product dat eenvoudige en snelle migratie naar de cloud mogelijk maakt, zou ook zeer nuttig zijn voor de klanten van het bedrijf "Onlanta" - gebruikers. . Zo kwam ik in contact met Hystax en begon ik zijn mogelijkheden te testen. Wat daaruit voortkwam, vertel ik in dit artikel.
De belangrijkste functie van Hystax is de brede functionaliteit in het ondersteunen van verschillende virtualisatieplatformen, gastbesturingssystemen en cloudservices, wat de mogelijkheid biedt om uw werklasten van waar dan ook naartoe over te brengen.
Dit maakt niet alleen het creëren van DR-oplossingen mogelijk om de betrouwbaarheid van services te verhogen, maar ook om middelen snel en flexibel tussen verschillende locaties en hyperscalers te migreren voor kostenbesparing en het kiezen van de beste oplossing voor een specifieke service op dat moment. Naast de platformen die op de voorpagina zijn vermeld, werkt het bedrijf ook actief samen met Russische cloudproviders: Yandex.Cloud, KROK "Cloud Services", Mail.ru en vele anderen. Het is ook vermeldenswaard dat het bedrijf in 2020 een R&D-centrum heeft opgericht, gevestigd in Skolkovo.
De keuze van één oplossing door een groot aantal spelers op de markt duidt op een goed prijsbeleid en hoge toepasbaarheid van het product, wat wij in de praktijk hebben besloten te verifiëren.
Dus, onze testopdracht zal bestaan uit het migreren vanaf mijn testomgeving VMware en fysieke machines naar de locatie van de provider die ook wordt beheerd door VMware. Ja, er zijn talloze oplossingen die dergelijke migratie kunnen uitvoeren, maar we beschouwen Hystax als een universele oplossing, en het testen van migratie in alle mogelijke combinaties is gewoon een onmogelijke taak. Bovendien is de cloud Oncloud.ru precies gebaseerd op VMware, dus dit platform is voor ons van groter belang als doel. Verder zal ik het belangrijkste principe van de werking beschrijven, dat over het algemeen niet afhankelijk is van het platform, en VMware kan aan elke kant worden vervangen door het platform van een andere leverancier.
In de eerste fase moet Hystax Acura worden uitgerold, wat de beheerpaneel van het systeem is.
Het wordt uitgerold vanuit een sjabloon. Om de een of andere reden was deze in ons geval niet helemaal correct en in plaats van de aanbevolen 8CPU, 16Gb werd het uitgerold met de helft van de middelen. Dus vergeet niet deze aan te passen, anders kunnen de containers in de infrastructuur binnen de VM, waarop alles is gebouwd, gewoon niet starten en zal het portaal niet toegankelijk zijn. In staan de benodigde middelen en poorten voor alle systeemcomponenten gedetailleerd beschreven.
En met het toewijzen van het IP-adres via het sjabloon waren er ook problemen, dus we hebben dit vanuit de console aangepast. Daarna kan men naar de webinterface van het beheerpaneel gaan en de initiële configuratiewizard invullen.
Endpoint – het IP of FQDN van onze vCenter.
Login en Wachtwoord – dit is duidelijk.
Target ESXi-hostnaam – een van de hosts van ons cluster waar de replicatie zal plaatsvinden.
Target datastore – een van de datastores van ons cluster waar de replicatie zal plaatsvinden.
Hystax Acura Control Panel Publiek IP – het adres waar de beheerpaneel toegankelijk zal zijn.
Er is een kleine verduidelijking nodig over de host en datastore. Het punt is dat de replicatie van Hystax op het niveau van de host en datastore werkt. Verder zal ik uitleggen hoe men de host en datastore voor de tenant kan wijzigen, maar het probleem ligt anders. Hystax ondersteunt geen werken met resource pools, dat wil zeggen dat de replicatie altijd naar de root van het cluster zal plaatsvinden (terwijl ik dit materiaal schreef, hadden de jongens van Hystax een bijgewerkte versie uitgebracht waarin ze mijn feature request voor ondersteuning van resource pools snel hadden geïmplementeerd). VCloud Director wordt ook niet ondersteund, dat betekent dat als de tenant, zoals in mijn geval, geen beheerdersrechten over het hele cluster heeft, maar alleen over een specifieke resource pool, en we hebben toegang tot Hystax verleend, hij in staat is om zelfstandig deze VMs te repliceren en op te starten, maar hij zal ze niet kunnen zien in de VMware-infrastructuur waarvoor hij toegang heeft en kan dus verder geen virtuele machines beheren. Het is noodzakelijk dat de clusterbeheerder de VM naar de juiste resource pool verplaatst of deze importeert in vCloud Director.
Waarom benadruk ik deze punten zo? Omdat, voor zover ik de productconcept begreep, de klant in staat moet zijn om elke migratie of DR zelfstandig uit te voeren via het Acura-paneel. Maar op dit moment blijft de ondersteuning voor VMware iets achter in vergelijking met de ondersteuning voor OpenStack, waar dergelijke mechanismen al zijn gerealiseerd.
Laten we terugkeren naar de uitrol. Allereerst, na de initiële configuratie van het paneel, moeten we de eerste tenant in ons systeem creëren.
Alle velden zijn hier begrijpelijk. Ik zal alleen het veld Cloud toelichten. We hebben al een "standaard" cloud die we hebben gemaakt tijdens de eerste configuratie. Maar als we de mogelijkheid willen hebben om elke tenant op een eigen datastore en in een eigen resource pool te plaatsen, kunnen we dit realiseren door afzonderlijke clouds voor elk van onze klanten te creëren.
In het formulier voor het toevoegen van een nieuwe cloud geven we dezelfde parameters op als bij de initiële configuratie (we kunnen zelfs dezelfde host gebruiken), en geven de benodigde datastore voor de specifieke klant aan. Nu kunnen we in de aanvullende parameters individueel de benodigde resource pool opgeven {"resource_pool": "YOUR_POOL_NAME"}.
Zoals je misschien hebt opgemerkt, staat er in het formulier voor het creëren van een tenant niets over het toewijzen van bronnen of enige quota – dit is niet aanwezig in het systeem. We kunnen de tenant niet beperken in het aantal gelijktijdige replica's, het aantal machines voor replicatie of op andere parameters. Dus, we hebben de eerste tenant gecreëerd. Nu is er iets wat niet helemaal logisch is, maar wel verplicht – de installatie van de Cloud-agent. Het is niet logisch, omdat de agent wordt gedownload op de pagina van de specifieke klant.
Hij is namelijk niet gekoppeld aan de gemaakte tenant en al onze klanten zullen via hem werken (of via meerdere, als we ze uitrollen). Eén agent ondersteunt 10 gelijktijdige sessies. Bij één sessie wordt één machine gerekend. Het maakt niet uit hoeveel schijven deze heeft. Tot op heden is er binnen Acura zelf geen mechanisme voor het schalen van agents onder VMware. Er is nog een vervelend punt: we hebben niet de mogelijkheid om vanuit het Acura-paneel de 'utilisatie' van deze agent te bekijken om te concluderen of we meer moeten uitrollen of dat de huidige installatie voldoende is. Uiteindelijk ziet de stand er als volgt uit:
De volgende stap om toegang te krijgen tot het portaal van onze klant is het aanmaken van een account (en vooraf moet er ook een rol worden aangemaakt die aan deze gebruiker zal worden toegewezen).
Nu kan onze klant het portaal zelfstandig gebruiken. Alles wat hij hoeft te doen, is de agents van het portaal te downloaden en aan zijn kant te installeren. Er zijn drie soorten agents: Linux, Windows en VMware.
De eerste twee worden geïnstalleerd op fysieke servers of op virtuele machines op elke hypervisor die niet VMware is. Hier hoeft verder niets te worden geconfigureerd; de agent wordt gedownload en weet al waar hij moet aankloppen, en letterlijk binnen een minuut is de machine zichtbaar in het Acura-paneel. De situatie met de VMware-agent is iets ingewikkelder. Het probleem is dat de agent voor VMware ook al voorbereid en met de noodzakelijke configuratie van het portaal wordt gedownload. Maar de VMware-agent moet, naast de kennis over ons Acura-portaal, ook weten over het virtualisatiesysteem waarop hij zal worden uitgerold.
Eigenlijk vraagt het systeem ons deze gegevens op te geven bij de eerste download van de VMware-agent. Het probleem is dat in ons tijdperk van algemene liefde voor beveiliging niet iedereen bereid zal zijn om hun admin-wachtwoord op een vreemde portal in te voeren, wat volkomen begrijpelijk is. Van binnenuit, na de uitrol, kan de agent ook niet verder geconfigureerd worden (je kunt alleen zijn netwerkinstellingen wijzigen). Hier voorzie ik problemen bij bijzonder voorzichtige klanten.
Dus, na de installatie van de agents kunnen we terugkeren naar het Acura-paneel en al onze machines zien.
Aangezien ik al een tijdje met het systeem werk, heb ik machines in verschillende staten. Ze bevinden zich allemaal in de Default-groep, maar er is de mogelijkheid om aparte groepen te maken en de machines daar naartoe te verplaatsen, zoals u dat wilt. Dit heeft geen invloed op iets - het is slechts een logische voorstelling van gegevens en hun groepering voor een gemakkelijker werkproces. Het eerste en belangrijkste dat we hierna moeten doen, is het migratieproces starten. We kunnen dit zowel handmatig afdwingen als een schema instellen, inclusief massaal voor alle machines tegelijk.
Ik herinner u eraan dat Hystax zich positioneerde als een product voor migratie. Daarom is het niet verwonderlijk dat we een DR-plan moeten maken om onze gesynchroniseerde machines te starten. Een plan kan worden opgesteld voor machines die al in de staat Synced zijn. Het kan zowel voor een specifieke VM als voor alle machines tegelijk worden gegenereerd.
De set parameters bij het genereren van een DR-plan zal verschillen afhankelijk van de infrastructuur waarnaar u migreert. Voor de VMware-omgeving is er een minimale set parameters beschikbaar. Re-IP wordt ook niet ondersteund voor machines. In dit plan zijn de volgende punten van belang: in de VM-beschrijving is de parameter "subnet": "VMNetwork", waarbij we de VM toewijzen aan een specifiek netwerk in het cluster. Rank is relevant bij de migratie van meerdere VM's en bepaalt de volgorde van hun opstarten. Flavor beschrijft de configuratie van de VM, in dit geval - 1CPU, 2GB RAM. In de sectie subnets definiëren we dat "subnet": "VMNetwork" is geassocieerd met het netwerk "VM Network" van VMware.
Bij het maken van een DR-plan is het niet mogelijk om de schijven over verschillende datastores te spreiden. Ze zullen zich bevinden op dezelfde datastore die is bepaald voor deze klantcloud, en als u schijven van verschillende klasse heeft, kan dit enige problemen veroorzaken bij de opstart van de machine. Na de opstartperiode en het "ontkoppelen" van de VM van Hystax, is er ook een aparte migratie van de schijven naar de juiste datastores nodig. Daarna hoeven we alleen ons DR-plan te starten en te wachten tot onze machines opgestart zijn. Het conversieproces P2V/V2V kost ook tijd. Op mijn grootste testmachine van 100 GB met drie schijven duurde het maximaal 10 minuten.
Daarna dient u de opgestarte VM, de services daarop, de consistentie van de gegevens en andere controles te controleren.
Daarna hebben we twee wegen:
- Verwijderen – stop de actieve DR-plannen. Deze actie stopt simpelweg de actieve VM. De gegevens van de replica verdwijnen nergens.
- Detach – ontkoppel de gerepliceerde machine van Acura, d.w.z. beëindig feitelijk het migratieproces.
Voordelen van de oplossing:
- gemak van installatie en configuratie zowel aan de klanten- als aan de providerzijde;
- gemak van configuratie van migratie, het maken van DR-plannen en het opstarten van replicaties;
- ondersteuning en ontwikkelaars reageren vrij snel op gevonden problemen en lossen deze op met platformupdates of agents.
Nadelen
- Onvoldoende ondersteuning voor Vmware.
- Geen schaling voor tenants vanaf het platform.
Ik heb ook een Feature Request ingediend, die we aan de leverancier hebben doorgegeven:
- bewaking van gebruik en deployment vanuit het Acura beheerscherm voor Cloud agents;
- beschikbaarheid van quotering voor tenants;
- mogelijkheid om het aantal gelijktijdige replicaties en de snelheid voor elke tenant te beperken;
- ondersteuning voor VMware vCloud Director;
- ondersteuning voor resource pools (dit werd geïmplementeerd tijdens de testfase);
- mogelijkheid om de VMware-agent vanuit de agent zelf in te stellen, zonder inloggegevens van de klantinfrastructuur in het Acura-paneel in te voeren;
- "visualisatie" van het VM-opstartproces bij het opstarten van het DR-plan.
Het enige wat me echt in het oog sprong – is de documentatie. Ik hou niet van "zwarte dozen" en geef de voorkeur aan gedetailleerde documentatie over hoe het product intern werkt. En als het product voor AWS en OpenStack nog enigszins wordt beschreven, is er voor VMware extreem weinig documentatie.
Er is een Installatiehandleiding die alleen de implementatie van het Acura-paneel beschrijft, en waar niet wordt vermeld dat ook een Cloud-agent nodig is. Er is een volledige set product specificaties, wat goed is. Er is documentatie die de configuratie van "begin tot eind" beschrijft aan de hand van AWS en OpenStack (hoewel het meer op een blogpost lijkt), en er is een zeer kleine Knowledge Base.
Over het algemeen is dit niet helemaal het documentatieformaat waar ik aan gewend ben, laten we zeggen, bij grotere leveranciers, dus ik voelde me er niet echt comfortabel bij. Tegelijkertijd vond ik geen antwoorden op enkele nuances van het systeem "intern" in deze documentatie – veel vragen moest ik verifiëren bij de technische ondersteuning, en dat vertraagde het implementatieproces en de uitvoering van tests behoorlijk.
Samenvattend kan ik zeggen dat ik over het algemeen tevreden ben met het product en de aanpak van het bedrijf bij de uitvoering van de taak. Ja, er zijn tekortkomingen, er is echt een kritische tekortkoming in de functionaliteit (in combinatie met VMware). Het is duidelijk dat het bedrijf zich in de eerste plaats richt op publieke cloudoplossingen, met name AWS, en voor sommigen zal dit voldoende zijn. De beschikbaarheid van zo'n eenvoudig en gebruiksvriendelijk product is vandaag de dag, wanneer veel bedrijven kiezen voor een multicloudstrategie, van groot belang. Gezien de veel lagere prijs in vergelijking met concurrenten, maakt dit het product uiterst aantrekkelijk.
We zijn op zoek naar . Misschien bent u het wel?
Bron: habr.com
