Eén van de jonge spelers op de markt voor Disaster Recovery-oplossingen is Hystax, een Russische startup uit 2016. Omdat het onderwerp disaster recovery erg populair is en de markt extreem competitief is, besloot de startup zich te concentreren op migratie tussen verschillende cloudinfrastructuren. Een product waarmee je een eenvoudige en snelle migratie naar de cloud kunt organiseren, zou ook voor de klanten van Onlanta - gebruikers - zeer nuttig zijn . Zo maakte ik kennis met Hystax en begon ik de mogelijkheden ervan te testen. Wat er van terecht kwam, vertel ik je in dit artikel.
Het belangrijkste kenmerk van Hystax is de brede functionaliteit ter ondersteuning van verschillende virtualisatieplatforms, gastbesturingssystemen en clouddiensten, waardoor het mogelijk wordt om uw werklasten overal en altijd over te dragen.
Hierdoor kunt u niet alleen DR-oplossingen creëren om de fouttolerantie van services te vergroten, maar ook snel en flexibel resources migreren tussen verschillende sites en hyperscalers om de kostenbesparingen te vergroten en de beste oplossing voor een specifieke service op een bepaald moment te selecteren. Naast de platforms die op de titelfoto worden vermeld, werkt het bedrijf ook actief samen met Russische cloudproviders: Yandex.Cloud, CROC Cloud Services, Mail.ru en vele anderen. Het is ook vermeldenswaard dat het bedrijf in 2020 een R&D-centrum in Skolkovo opende.
De keuze voor één oplossing door een groot aantal spelers op de markt duidt op een goed prijsbeleid en een hoge toepasbaarheid van het product, wat we besloten in de praktijk te testen.
Onze testtaak zal dus bestaan uit het migreren van mijn VMware-testsite en fysieke machines naar de site van de provider, ook beheerd door VMware. Ja, er zijn veel oplossingen die een dergelijke migratie kunnen uitvoeren, maar wij beschouwen Hystax als een universeel hulpmiddel, en het testen van migratie in alle mogelijke combinaties is eenvoudigweg een onrealistische taak. En de Oncloud.ru-cloud is specifiek op VMware gebouwd, dus dit platform als doelwit interesseert ons meer. Vervolgens zal ik het basisprincipe van de werking beschrijven, dat over het algemeen onafhankelijk is van het platform, en VMware van elke kant kan worden vervangen door een platform van een andere leverancier.
De eerste stap is het implementeren van Hystax Acura, het bedieningspaneel van het systeem.
Het ontvouwt zich vanuit de sjabloon. Om de een of andere reden was het in ons geval niet helemaal correct en in plaats van de aanbevolen 8CPU werd 16 Gb ingezet met de helft van de bronnen. Daarom moet u onthouden dat u ze moet wijzigen, anders zal de containerinfrastructuur binnen de VM, waarop alles is gebouwd, eenvoudigweg niet starten en is de portal ontoegankelijk. IN De benodigde bronnen worden gedetailleerd beschreven, evenals poorten voor alle systeemcomponenten.
Er waren ook problemen bij het instellen van het IP-adres via een sjabloon, dus hebben we dit vanaf de console gewijzigd. Hierna kunt u naar de beheerderswebinterface gaan en de initiële configuratiewizard voltooien.
Eindpunt – IP of FQDN van ons vCenter.
Login en wachtwoord – dit is duidelijk.
Doel-ESXi-hostnaam is een van de hosts in ons cluster waarnaar replicatie zal worden uitgevoerd.
Doeldatastore is een van de datastores in ons cluster waarnaar replicatie zal worden uitgevoerd.
Hystax Acura-bedieningspaneel Openbaar IP – het adres waar het alarmsysteem beschikbaar zal zijn.
Er is enige verduidelijking nodig met betrekking tot de host en de datastore. Feit is dat Hystax-replicatie werkt op host- en datastore-niveau. Vervolgens zal ik je vertellen hoe je de host en datastore voor een tenant kunt wijzigen, maar het probleem is anders. Hystax ondersteunt het werken met resourcepools niet, d.w.z. de replica gaat altijd naar de root van het cluster (op het moment dat dit materiaal werd geschreven, brachten de jongens van Hystax een bijgewerkte versie uit, waarin ze snel mijn functieverzoek met betrekking tot ondersteuning voor resourcepools implementeerden). vCloud Director wordt ook niet ondersteund, d.w.z. als, zoals in mijn geval, de huurder geen beheerdersrechten heeft voor het hele cluster, maar alleen voor een specifieke resourcepool, en we toegang hebben gegeven tot Hystax, dan zal hij deze VM’s onafhankelijk kunnen repliceren en starten, maar hij zal dat wel doen kan ze niet zien in de VMware-infrastructuur waartoe hij toegang heeft en dienovereenkomstig virtuele machines verder beheert. Het is noodzakelijk dat de clusterbeheerder de VM naar de gewenste resourcepool verplaatst of importeert in vCloud Director.
Waarom concentreer ik me zo veel op deze punten? Omdat, voor zover ik het concept van het product begrijp, de klant elke migratie of DR zelfstandig moet kunnen implementeren met behulp van het Acura-paneel. Maar tot nu toe ligt de ondersteuning van VMware iets achter op het ondersteuningsniveau voor OpenStack, waar vergelijkbare mechanismen al zijn geïmplementeerd.
Maar laten we teruggaan naar de implementatie. Allereerst moeten we na de eerste installatie van het paneel de eerste huurder in ons systeem aanmaken.
Alle velden hier zijn duidelijk, ik vertel je alleen over het Cloud-veld. We hebben al een “standaard” cloud die we tijdens de initiële configuratie hebben gemaakt. Maar als we elke tenant op zijn eigen datastore en in zijn eigen resourcepool willen kunnen plaatsen, kunnen we dit implementeren door voor elk van onze klanten aparte clouds te creëren.
In het formulier voor het toevoegen van een nieuwe cloud specificeren we dezelfde parameters als tijdens de initiële configuratie (we kunnen zelfs dezelfde host gebruiken), geven we de datastore aan die nodig is voor een specifieke klant, en nu kunnen we in aanvullende parameters de vereiste bron individueel specificeren pool {"resource_pool" : "YOUR_POOL_NAME"}
Zoals je misschien hebt gemerkt, staat er in het formulier voor het maken van tenants niets over de toewijzing van middelen of eventuele quota; dit alles is niet aanwezig in het systeem. Het is onmogelijk om een tenant te beperken wat betreft het aantal gelijktijdige replica's, het aantal machines voor replicatie of andere parameters. We hebben dus de eerste tenant gemaakt. Nu is er iets dat niet geheel logisch, maar verplicht is: het installeren van een Cloud-agent. Het is onlogisch, aangezien de agent wordt gedownload op de pagina van een specifieke klant.
Tegelijkertijd is het niet gebonden aan de aangemaakte tenant en zullen al onze klanten er doorheen werken (of via meerdere, als we ze inzetten). Eén agent ondersteunt 10 gelijktijdige sessies. Eén machine wordt als één sessie geteld. Het maakt niet uit hoeveel schijven er zijn. Tot op heden is er geen mechanisme voor het schalen van agenten in Acura zelf onder VMware. Er is nog een onaangenaam moment: we hebben niet de mogelijkheid om naar de "verwijdering" van deze agent uit het Acura-paneel te kijken om te concluderen of we meer moeten inzetten of dat de huidige installatie voldoende is. Het resultaat is dat de stand er als volgt uitziet:
De volgende stap om toegang te krijgen tot ons klantportaal is het aanmaken van een account (en eerst een rol die op deze gebruiker van toepassing is).
Nu kan onze klant het portaal zelfstandig gebruiken. Het enige wat hij hoeft te doen is de agenten van de portal downloaden en aan zijn kant installeren. Er zijn drie soorten agenten: Linux, Windows en VMware.
De eerste twee worden geïnstalleerd op de natuurkunde of op virtuele machines op een andere hypervisor dan VMware. Het is niet nodig om iets extra's te configureren, de agent wordt gedownload en weet al waar hij moet kloppen, en letterlijk binnen een minuut zal de auto zichtbaar zijn in het Acura-paneel. Met de VMware-agent is de situatie iets ingewikkelder. Het probleem is dat de agent voor VMware ook wordt gedownload vanuit de portal die al is voorbereid en de benodigde configuratie bevat. Maar naast kennis over ons Acura-portaal moet een VMware-agent ook kennis hebben van het virtualisatiesysteem waarop deze zal worden ingezet.
Eigenlijk zal het systeem ons om deze gegevens vragen wanneer we de VMware-agent voor het eerst downloaden. Het probleem is dat in onze tijd van universele liefde voor veiligheid niet iedereen zijn beheerderswachtwoord wil opgeven op de portal van iemand anders, wat heel begrijpelijk is. Van binnenuit kan de agent na implementatie op geen enkele manier worden geconfigureerd (u kunt alleen de netwerkinstellingen wijzigen). Hier voorzie ik moeilijkheden bij bijzonder voorzichtige klanten.
Dus na het installeren van de agenten kunnen we teruggaan naar het Acura-paneel en al onze auto's bekijken.
Omdat ik nu een aantal dagen met het systeem werk, heb ik auto's in verschillende staten. Ik heb ze allemaal in de standaardgroep, maar het is mogelijk om afzonderlijke groepen te maken en er auto's naar over te zetten als je dat wilt. Dit heeft nergens invloed op - alleen een logische presentatie van gegevens en hun groepering voor gemakkelijker werken. Het eerste en belangrijkste dat we hierna moeten doen, is het migratieproces starten. Dit kunnen wij handmatig doen of door een planning op te stellen, ook in bulk voor alle machines tegelijk.
Laat me u eraan herinneren dat Hystax werd gepositioneerd als een product voor migratie. Daarom is het niet verrassend dat we, om onze gerepliceerde machines te kunnen laten draaien, een DR-plan moeten maken. Het plan kan worden gemaakt voor machines die zich al in de gesynchroniseerde status bevinden. U kunt zowel voor één specifieke VM als voor alle machines tegelijk genereren.
De set parameters bij het genereren van een DR-plan zal verschillen, afhankelijk van de infrastructuur waarnaar u migreert. Er is een minimale set parameters beschikbaar voor de VMware-omgeving. Re-IP voor machines wordt ook niet ondersteund. In dit verband zijn we geïnteresseerd in de volgende punten: in de VM-beschrijving de parameter “subnet”: “VMNetwork”, waar we de VM aan een specifiek netwerk in het cluster binden. Rang – relevant bij het migreren van meerdere VM’s; het bepaalt de volgorde waarin ze worden gelanceerd. Smaak – beschrijft de VM-configuratie, in dit geval – 1CPU, 2GB RAM. In de sectie subnetten definiëren we dat "subnet": "VMNetwork" is gekoppeld aan het VMware "VM Network".
Bij het maken van een DR-plan is er geen manier om schijven over verschillende datastores te “verspreiden”. Ze zullen zich in dezelfde datastore bevinden die voor deze clientcloud is gedefinieerd, en als u schijven van verschillende klassen hebt, kan dit problemen veroorzaken bij het opstarten van de machine, en na het starten en “scheiden” van de VM van Hystax, zal dit ook gebeuren vereisen afzonderlijke migratieschijven naar de vereiste datastores. Dan hoeven we alleen maar ons DR-plan te lanceren en te wachten tot onze auto's opstaan. Het P2V/V2V-conversieproces kost ook tijd. Op mijn grootste testmachine, 100 GB met drie schijven, duurde het maximaal 10 minuten.
Hierna moet u de actieve VM, de services erop, de consistentie van de gegevens controleren en andere controles uitvoeren.
Dan hebben we twee manieren:
- Verwijderen – verwijder het actieve DR-plan. Met deze actie wordt eenvoudigweg de actieve VM afgesloten. Deze replica's gaan nergens heen.
- Loskoppelen – scheur een gerepliceerde auto los van een Acura, d.w.z. daadwerkelijk het migratieproces voltooien.
Voordelen van de oplossing:
- installatie- en configuratiegemak, zowel door de klant als door de provider;
- het gemak van het opzetten van de migratie, het maken van een DR-plan en het lanceren van replica's;
- ondersteuning en ontwikkelaars reageren vrij snel op gevonden problemen en lossen deze op met behulp van platform- of agentupdates.
Tegens
- Onvoldoende VMware-ondersteuning.
- Afwezigheid van quota voor tenants van het platform.
Ik heb ook een Feature Request samengesteld, die we bij de leverancier hebben ingediend:
- gebruiksmonitoring en implementatie vanaf de Acura-beheerconsole voor cloudagenten;
- beschikbaarheid van quota voor huurders;
- de mogelijkheid om het aantal gelijktijdige replicaties en snelheid voor elke tenant te beperken;
- VMware vCloud Director-ondersteuning;
- ondersteuning voor resourcepools (geïmplementeerd tijdens het testen);
- de mogelijkheid om de VMware-agent vanuit de agent zelf te configureren, zonder inloggegevens van de clientinfrastructuur in het Acura-paneel in te voeren;
- “visualisatie” van het opstartproces van de VM bij het uitvoeren van het DR-plan.
Het enige dat mij grote kritiek bezorgde, was de documentatie. Ik hou niet echt van "zwarte dozen" en geef er de voorkeur aan als er gedetailleerde documentatie is over hoe het product van binnen werkt. En als het product voor AWS en OpenStack nog min of meer beschreven wordt, dan is er voor VMware heel weinig documentatie.
Er is een Installatiehandleiding die alleen de inzet van het Acura-paneel beschrijft, en er wordt met geen woord gerept over het feit dat er ook een Cloud-agent nodig is. Er is een volledige set productspecificaties, wat goed is. Er is documentatie die de installatie “van begin tot eind” beschrijft met AWS en OpenStack als voorbeeld (hoewel het voor mij meer op een blogpost lijkt), en er is een zeer kleine kennisbank.
Over het algemeen is dit niet helemaal het documentatieformaat dat ik gewend ben van bijvoorbeeld grotere leveranciers, dus ik voelde me niet helemaal op mijn gemak. Tegelijkertijd heb ik in deze documentatie nooit antwoorden gevonden over enkele nuances van hoe het systeem 'binnenin' werkt - veel vragen moesten worden opgehelderd met technische ondersteuning, en dit vertraagde het proces van het inzetten van de stand en het uitvoeren van testen.
Samenvattend kan ik zeggen dat ik over het algemeen het product en de benadering van de taak door het bedrijf leuk vond. Ja, er zijn tekortkomingen, er is een echt kritiek gebrek aan functionaliteit (in verband met VMware). Het is duidelijk dat het bedrijf zich in de eerste plaats nog steeds richt op publieke clouds, met name AWS, en voor sommigen zal dit voldoende zijn. Het is tegenwoordig uiterst belangrijk om zo’n eenvoudig en handig product te hebben, nu veel bedrijven kiezen voor een multi-cloudstrategie. Gezien de veel lagere prijs in vergelijking met concurrenten, maakt dit het product uiterst aantrekkelijk.
Wij zijn op zoek naar een teamlid . Misschien ben jij het?
Bron: www.habr.com