Een 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 richten op de migratie tussen verschillende cloudinfrastructuren. Een product dat een eenvoudige en snelle migratie naar de cloud mogelijk maakt, zou ook erg nuttig zijn voor de klanten van Onlanta – gebruikers . Zo maakte ik kennis met Hystax en begon ik de mogelijkheden ervan te testen. En wat het resultaat was, vertel ik u in dit artikel.
De belangrijkste eigenschap van Hystax is de uitgebreide functionaliteit in de ondersteuning van diverse virtualisatieplatformen, gastbesturingssystemen en cloudservices, waardoor u uw workloads van en naar elke locatie kunt overbrengen.
Hierdoor kunnen we niet alleen DR-oplossingen creëren om de fouttolerantie van services te vergroten, maar ook om snel en flexibel resources te migreren tussen verschillende sites en hyperscalers. Zo besparen we kosten en kunnen we op elk gewenst moment de beste oplossing voor een specifieke service selecteren. Naast de platforms die in de titelafbeelding zijn genoemd, werkt het bedrijf ook actief samen met Russische cloudproviders: Yandex.Cloud, KROK Cloud Services, Mail.ru en vele anderen. Het is ook de moeite waard om te vermelden dat het bedrijf in 2020 een R&D-centrum in Skolkovo heeft geopend.
Het feit dat een groot aantal spelers op de markt voor één oplossing kozen, wijst op een goed prijsbeleid en een hoge toepasbaarheid van het product. Wij besloten dit in de praktijk te testen.
Onze testtaak zal dus bestaan uit de migratie van mijn VMware-testsite en fysieke machines naar de site van de provider, waar ook VMware draait. Ja, er zijn veel oplossingen die een dergelijke migratie kunnen uitvoeren, maar wij beschouwen Hystax als een universeel hulpmiddel en het testen van de migratie in alle mogelijke combinaties is eenvoudigweg een onrealistische taak. En de Oncloud.ru-cloud is gebouwd op VMware, dus dit platform is voor ons als doelgroep van groter belang. Hierna zal ik het basisprincipe van de werking beschrijven. Dit principe is over het algemeen onafhankelijk van het platform en VMware kan aan beide kanten 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 het sjabloon. Om een of andere reden was dit in ons geval niet helemaal correct en in plaats van de aanbevolen 8 CPU's werd er 16 GB ingezet met de helft van het aantal bronnen. Vergeet daarom niet om deze te wijzigen. Anders start de containerinfrastructuur in de virtuele machine (waarop alles is gebouwd) niet en is de portal niet beschikbaar. IN De benodigde bronnen worden gedetailleerd beschreven, evenals de poorten voor alle systeemcomponenten.
Omdat er ook problemen waren met het instellen van het IP-adres via een sjabloon, hebben we dit via de console gewijzigd. Hierna kunt u naar de beheerderswebinterface gaan en de wizard voor de eerste configuratie invullen.
Eindpunt – IP of FQDN van onze vCenter.
Login en wachtwoord – dat is duidelijk.
Doel ESXi-hostnaam – een van de hosts van ons cluster waarnaar de replicatie wordt uitgevoerd.
Doelgegevensopslag – een van de gegevensopslagplaatsen van ons cluster waarnaar replicatie wordt uitgevoerd.
Openbaar IP-adres van het Hystax Acura-bedieningspaneel: het adres waarop het bedieningspaneel beschikbaar zal zijn.
Er is een kleine verduidelijking nodig met betrekking tot de host en de datastore. Het punt is dat Hystax-replicatie op het host- en datastoreniveau werkt. Hierna leg ik uit hoe je de host en datastore voor een tenant kunt wijzigen, maar het probleem is anders. Hystax ondersteunt het werken met resource pools niet; de replica wordt dus altijd naar de root van het cluster gestuurd (toen dit materiaal werd geschreven, hadden de mensen van Hystax een bijgewerkte versie uitgebracht, waarin ze snel mijn verzoek voor ondersteuning van resource pools hebben geïmplementeerd). Ook vCloud Director wordt niet ondersteund. Als de tenant, zoals in mijn geval, dus geen beheerdersrechten heeft voor het hele cluster, maar alleen voor een specifieke resourcepool, en wij toegang hebben gegeven aan Hystax, dan kan hij deze VM's onafhankelijk repliceren en starten. Hij kan ze echter niet zien in de VMware-infrastructuur waartoe hij toegang heeft en kan de virtuele machines dus niet verder beheren. De clusterbeheerder moet de virtuele machine naar de juiste resourcepool verplaatsen of deze importeren in vCloud Director.
Waarom benadruk ik deze punten zo? Omdat, voor zover ik het concept van het product begrijp, de klant zelfstandig elke migratie of DR moet kunnen uitvoeren met behulp van het Acura-paneel. Maar vooralsnog ligt de ondersteuning voor VMware iets onder het niveau van de ondersteuning voor OpenStack, waar vergelijkbare mechanismen al zijn geïmplementeerd.
Maar laten we teruggaan naar de implementatie. Het eerste dat we moeten doen nadat we het paneel hebben ingesteld, is de eerste tenant in ons systeem aanmaken.
Alle velden hier zijn leeg, ik vertel u alleen over het veld Cloud. We hebben al een standaardcloud die we tijdens de eerste configuratie hebben aangemaakt. Als we echter elke tenant in een eigen datastore en in een eigen resourcepool willen plaatsen, kunnen we dit doen door voor elke klant een aparte cloud te maken.
In het formulier voor het toevoegen van een nieuwe cloud specificeren we dezelfde parameters als tijdens de eerste configuratie (we kunnen zelfs dezelfde host gebruiken), specificeren we de datastore die nodig is voor een specifieke klant, en nu kunnen we in de extra parameters individueel de benodigde resourcepool specificeren {«resource_pool»: «YOUR_POOL_NAME»}
Zoals u wellicht hebt opgemerkt, staat er in het formulier voor het aanmaken van een tenant niets over toewijzing van resources of quota. Dit staat allemaal niet in het systeem. Het is niet mogelijk om een tenant te beperken wat betreft het aantal gelijktijdige replica's, het aantal machines voor replicatie of andere parameters. Dus, we hebben de eerste huurder gecreëerd. Nu is er nog iets wat niet helemaal logisch is, maar wel verplicht: het installeren van de Cloud-agent. Dat is onlogisch, aangezien de agent wordt gedownload vanaf de pagina van een specifieke klant.
Tegelijkertijd is het niet gebonden aan de aangemaakte tenant en zullen al onze klanten erdoorheen werken (of via meerdere, als we die implementeren). Één agent ondersteunt 10 gelijktijdige sessies. Per sessie wordt één auto geteld. Het maakt niet uit hoeveel schijven er zijn. Tot op heden bestaat er geen mechanisme voor het schalen van agenten in Acura zelf onder VMware. Er is nog een vervelend moment: we hebben niet de mogelijkheid om naar het 'gebruik' van deze agent op 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 zo uitziet:
De volgende stap om toegang te krijgen tot ons klantenportaal is het aanmaken van een account (en eerst een rol die aan deze gebruiker wordt toegewezen).
Nu kan onze klant het portaal zelfstandig gebruiken. Het enige wat hij hoeft te doen is de app downloaden via het agentenportaal en installeren. Er zijn drie soorten agents: Linux, Windows en VMware.
De eerste twee worden geïnstalleerd op fysieke of virtuele machines op een andere hypervisor dan VMware. U hoeft verder niets te configureren: de agent wordt gedownload en weet al waar hij moet aankloppen. Binnen een minuut is de auto zichtbaar op het Acura-paneel. Bij de VMware-agent is de situatie iets ingewikkelder. Het probleem is dat de agent voor VMware ook al is gedownload van de portal en al is voorbereid en de benodigde configuratie bevat. Naast kennis over ons Acura-portaal moet de VMware-agent ook kennis hebben van het virtualisatiesysteem waarop deze wordt geïmplementeerd.
Het systeem vraagt ons om deze gegevens op te geven wanneer we de VMware-agent voor het eerst downloaden. Het probleem is dat in ons tijdperk van universele liefde voor veiligheid niet iedereen zijn beheerderswachtwoord op het portaal van iemand anders wil opgeven, wat begrijpelijk is. Na implementatie kan de agent intern op geen enkele manier meer worden geconfigureerd (u kunt alleen de netwerkinstellingen wijzigen). Ik voorzie hierbij moeilijkheden bij bijzonder voorzichtige klanten.
Nadat we de agenten hebben geïnstalleerd, kunnen we teruggaan naar het Acura-dashboard en al onze auto's bekijken.
Omdat ik al een aantal dagen met het systeem werk, heb ik auto's in verschillende staten. Ik heb ze allemaal in de Standaardgroep staan, maar je kunt eventueel aparte groepen aanmaken en daar auto's naartoe verplaatsen. Dit heeft geen invloed op iets, alleen op de logische presentatie van de gegevens en de groepering ervan, wat het werken gemakkelijker maakt. Het eerste en belangrijkste dat we hierna moeten doen, is het migratieproces starten. We kunnen dit handmatig doen of door een schema op te stellen. Ook kunnen we de productie in massa voor alle machines tegelijk uitvoeren.
Ik wil u eraan herinneren dat Hystax werd gepositioneerd als een migratieproduct. Het is daarom niet verrassend dat we een DR-plan moeten maken om onze gerepliceerde machines te kunnen laten draaien. Er kan een plan worden gemaakt voor machines die al in de status Gesynchroniseerd staan. Het kan voor één specifieke VM of voor alle machines tegelijk worden gegenereerd.
De parameters die u gebruikt bij het genereren van een DR-plan verschillen, afhankelijk van de infrastructuur waarnaar u wilt migreren. Voor de VMware-omgeving is een minimale set parameters beschikbaar. Ook het opnieuw toekennen van een IP aan machines wordt niet ondersteund. In dit verband zijn we geïnteresseerd in de volgende punten: in de VM-beschrijving, de parameter "subnet": "VMNetwork", waarbij we de VM aan een specifiek netwerk in het cluster binden. Rang – relevant bij het migreren van meerdere VM's, bepaalt de volgorde waarin ze worden gestart. Smaak – beschrijft de VM-configuratie, in dit geval – 1 CPU, 2 GB RAM. In het gedeelte Subnetten definiëren we het "subnet": "VMNetwork" is gekoppeld aan het VMware-netwerk "VM Network".
Bij het maken van een DR-plan is het niet mogelijk om schijven over verschillende datastores te 'spreiden'. Ze bevinden zich in dezelfde datastore die is gedefinieerd voor deze clientcloud. Als u schijven van verschillende klassen hebt, kan dit problemen opleveren bij het opstarten van de machine. Na het opstarten en 'afscheuren' van de virtuele machine van Hystax, is er bovendien een aparte migratie van schijven naar de vereiste datastores nodig. Het enige wat ons nu nog rest is het uitvoeren van ons DR-plan en wachten tot onze voertuigen vertrekken. Het P2V/V2V-conversieproces kost ook tijd. Op mijn grootste testmachine, 100GB met drie schijven, duurde het maximaal 10 minuten.
Hierna controleert u de actieve VM, de services erop, de consistentie van de gegevens en voert u andere controles uit.
Vanaf hier hebben we twee opties:
- Verwijderen – verwijder het actieve DR-plan. Met deze actie wordt de actieve VM eenvoudigweg afgesloten. Deze replica's gaan nergens heen.
- Losmaken – de gerepliceerde auto loskoppelen van de Acura, d.w.z. het migratieproces daadwerkelijk voltooien.
Voordelen van de oplossing:
- eenvoudige installatie en configuratie, zowel voor de klant als voor de provider;
- eenvoudige migratie-instelling, DR-plancreatie en replica-lancering;
- Ondersteuning en ontwikkelaars reageren snel op gevonden problemen en lossen deze op met platform- of agentupdates.
Tegens
- Onvoldoende ondersteuning voor VMware.
- Het ontbreken van quota voor huurders op het platform.
Ik heb ook een functieverzoek opgesteld en dit bij de leverancier ingediend:
- Controleer het gebruik en implementeer vanuit Acura Management Console voor Cloud Agents;
- beschikbaarheid van quota voor huurders;
- de mogelijkheid om het aantal gelijktijdige replicaties en de snelheid voor elke tenant te beperken;
- VMware vCloud Director-ondersteuning;
- ondersteuning voor resource pools (geïmplementeerd tijdens het testen);
- de mogelijkheid om de VMware-agent te configureren vanaf de agent zelf, zonder dat de inloggegevens van de clientinfrastructuur in het Acura-paneel hoeven te worden ingevoerd;
- "visualisatie" van het opstartproces van de VM bij het uitvoeren van een DR-plan.
Het enige waar ik echt over klaagde was de documentatie. Ik ben geen grote fan van 'zwarte dozen' en geef de voorkeur aan gedetailleerde documentatie over hoe het product binnenin werkt. En terwijl voor AWS en OpenStack het product min of meer beschreven is, is er voor VMware heel weinig documentatie.
Er is een installatiehandleiding die alleen de implementatie van het Acura-paneel beschrijft, en er wordt met geen woord gerept over het feit dat de Cloud Agent ook nodig is. Er is een volledige set specificaties voor het product, en dat is goed. Er is documentatie waarin de installatie van begin tot eind wordt beschreven, waarbij AWS en OpenStack als voorbeeld worden gebruikt (hoewel het voor mij meer op een blogpost lijkt). Er is ook een kleine kennisbank.
Over het geheel genomen was het niet helemaal het documentatieformat dat ik gewend ben van bijvoorbeeld grotere leveranciers, dus ik was er niet helemaal tevreden mee. Tegelijkertijd heb ik in deze documentatie nooit antwoorden gevonden op enkele nuances van de werking van het systeem "binnenin" – ik moest veel vragen beantwoorden met de technische ondersteuning, en dit vertraagde het proces van het implementeren van de standaard en het uitvoeren van tests aanzienlijk.
Samenvattend kan ik zeggen dat ik het product en de aanpak van het bedrijf bij het uitvoeren van de taak over het algemeen goed vond. Ja, er zijn enkele tekortkomingen, er is een echt ernstig gebrek aan functionaliteit (in combinatie 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 dat voldoende zijn. Tegenwoordig is het ontzettend belangrijk dat zo'n eenvoudig en handig product beschikbaar is, zeker nu veel bedrijven kiezen voor een multi-cloudstrategie. Gezien de veel lagere prijs vergeleken met concurrenten, is dit product zeer aantrekkelijk.
Wij zijn op zoek naar een teamlid . Misschien ligt het aan jou?
Bron: www.habr.com
