En av de unga aktörerna på marknaden för Disaster Recovery-lösningar är Hystax, en rysk startup 2016. Eftersom ämnet katastrofåterställning är mycket populärt och marknaden är extremt konkurrensutsatt, beslutade startupen att fokusera på migrering mellan olika molninfrastrukturer. En produkt som låter dig organisera en enkel och snabb migrering till molnet skulle vara mycket användbar för Onlantas kunder - användare . Det var så jag lärde känna Hystax och började testa dess funktioner. Och vad som kom av det kommer jag att berätta i den här artikeln.
Huvudfunktionen hos Hystax är dess breda funktionalitet för att stödja olika virtualiseringsplattformar, gäst-OS och molntjänster, vilket gör det möjligt att flytta dina arbetsbelastningar från var som helst och var som helst.
Detta gör att du kan skapa inte bara DR-lösningar för att förbättra feltoleransen för tjänster, utan också snabbt och flexibelt migrera resurser mellan olika platser och hyperscalers för att öka kostnadsbesparingarna och välja den bästa lösningen för en viss tjänst för tillfället. Förutom de plattformar som anges i titelbilden, samarbetar företaget också aktivt med ryska molnleverantörer: Yandex.Cloud, CROC Cloud Services, Mail.ru och många andra. Det är också värt att notera att företaget 2020 öppnade ett FoU-center i Skolkovo.
Valet av en lösning av ett stort antal aktörer på marknaden indikerar en bra prispolicy och hög användbarhet för produkten, vilket vi bestämde oss för att testa i praktiken.
Så vår testuppgift kommer att bestå av att migrera från min VMware-testplats och fysiska maskiner till leverantörens webbplats som också kör VMware. Ja, det finns många lösningar som kan implementera en sådan migrering, men vi betraktar Hystax som ett universellt verktyg, och att testa migreringen i alla möjliga kombinationer är helt enkelt en orealistisk uppgift. Ja, och Oncloud.ru-molnet är byggt specifikt på VMware, så den här plattformen, som ett mål, intresserar oss i större utsträckning. Därefter kommer jag att beskriva den grundläggande principen för drift, som som helhet inte beror på plattformen, och VMware kan ersättas från vilken sida som helst med en plattform från en annan leverantör.
Det första steget är att distribuera Hystax Acura, som är systemets kontrollpanel.
Den expanderar från mallen. Av någon anledning, i vårt fall, var det inte helt korrekt och istället för den rekommenderade 8CPU:n sattes 16Gb ut med hälften av resurserna. Därför måste du komma ihåg att ändra dem, annars kommer infrastrukturen inuti den virtuella datorn, som allt är byggt på, helt enkelt inte att börja med behållare och portalen kommer att vara otillgänglig. I de nödvändiga resurserna beskrivs i detalj, såväl som portar för alla systemkomponenter.
Och det fanns också svårigheter med att ställa in IP-adressen genom mallen, så vi ändrade den från konsolen. Efter det kan du gå till administratörens webbgränssnitt och slutföra den initiala konfigurationsguiden.
Endpoint - IP eller FQDN för vårt vCenter.
Logga in och lösenord – det är tydligt här.
Target ESXi hostname är en av värdarna i vårt kluster som kommer att replikeras till.
Target datastore är en av databutikerna i vårt kluster som kommer att replikeras till.
Hystax Acura Control Panel Public IP - adressen där kontrollpanelen kommer att vara tillgänglig.
Ett litet förtydligande om värden och datalagring krävs. Faktum är att Hystax-replikering fungerar på värd- och datalagringsnivå. Därefter kommer jag att berätta hur du kan ändra värden och datalagringen för hyresgästen, men problemet är annorlunda. Hystax stöder inte resurspooling, d.v.s. repliken kommer alltid att hända med roten av klustret (när detta material skrevs släppte killarna från Hystax en uppdaterad version, där de snabbt implementerade min funktionsbegäran angående stöd för resurspooler). Inte heller vCloud Director stöds, dvs. om, som i mitt fall, hyresgästen inte har administratörsrättigheter till hela klustret, utan bara till en specifik resurspool, och vi gav åtkomst till Hystax, då kommer han att kunna replikera och köra dessa virtuella datorer självständigt, men han kommer att inte kunna se dem i VMware-infrastrukturen , som han har tillgång till och följaktligen ytterligare hantera virtuella maskiner. Klusteradministratören måste flytta den virtuella datorn till rätt resurspool eller importera den till vCloud Director.
Varför fokuserar jag så mycket på dessa ögonblick? Eftersom, så vitt jag förstår konceptet med produkten, bör kunden självständigt kunna implementera vilken migrering eller DR som helst med hjälp av Acura-panelen. Men än så länge ligger VMware-stödet något efter stödnivån för samma OpenStack, där sådana mekanismer redan har implementerats.
Men tillbaka till utbyggnaden. Först och främst, efter den första installationen av panelen, måste vi skapa den första hyresgästen i vårt system.
Alla fält här är tydliga, jag kommer bara att berätta om molnfältet. Vi har redan ett "default"-moln som vi skapade under den initiala konfigurationen. Men om vi vill kunna lägga varje hyresgäst på sin egen datastore och i sin egen resurspool kan vi implementera detta genom att skapa separata moln för var och en av våra kunder.
I form av att lägga till ett nytt moln anger vi samma parametrar som under den initiala konfigurationen (vi kan till och med använda samma värd), anger datalagringen som krävs för en viss kund, och nu i de ytterligare parametrarna kan vi redan individuellt specificera nödvändig poolresurs {"resource_pool" :"DIN_POOL_NAME"}
Som du kanske har märkt, i form av att skapa en hyresgäst står det ingenting om tilldelning av resurser eller någon form av kvotering – det finns inget av detta i systemet. Du kan inte begränsa hyresgästen i antalet samtidiga repliker, antalet maskiner för replikering eller några andra parametrar. Så vi har skapat den första hyresgästen. Nu finns det en inte helt logisk, men obligatorisk sak – att installera en Cloud-agent. Det är ologiskt, eftersom agenten laddas ner på en specifik kunds sida.
Samtidigt är det inte knutet till den skapade hyresgästen, och alla våra kunder kommer att arbeta igenom det (eller efter flera, om vi distribuerar dem). En agent stöder 10 samtidiga sessioner. Ett pass räknas som en bil. Det spelar ingen roll hur många diskar den har. Hittills finns det ingen mekanism för skalningsmedel i själva Acura för VMware. Det finns ytterligare ett obehagligt ögonblick - vi kan inte titta på "användningen" av denna agent från Acura-panelen för att avgöra om vi behöver distribuera mer eller om den nuvarande installationen räcker. Som ett resultat ser stativet ut så här:
Nästa steg för att komma åt vår kunds portal är att skapa ett konto (och först även en roll som kommer att tillämpas på denna användare).
Nu kan vår kund använda portalen självständigt. Allt han behöver göra är att ladda ner agenter från portalen och installera dem på sin sida. Det finns tre typer av agenter: Linux, Windows och VMware.
De två första läggs på fysik eller på virtuella maskiner på valfri hypervisor som inte är VMware. Det krävs ingen ytterligare konfiguration här, agenten laddar ner och vet redan var den ska knacka, och bokstavligen om en minut kommer bilen att synas i Acura-panelen. Med VMware-agenten är situationen lite mer komplicerad. Problemet är att Agent for VMware också laddas ner från portalen som redan är förberedd och har den nödvändiga konfigurationen. Men VMware-agenten behöver, förutom att känna till vår Acura-portal, också veta om det virtualiseringssystem som det kommer att distribueras på.
I själva verket kommer systemet att be oss att ange dessa data när du först laddar ner VMware-agenten. Problemet är att i vår tidsålder av universell kärlek till säkerhet, kommer inte alla att vilja ange sitt administratörslösenord på någon annans portal, vilket är ganska förståeligt. Från insidan, efter distributionen, kan agenten inte konfigureras på något sätt (du kan bara ändra dess nätverksinställningar). Här förutser jag svårigheter med särskilt försiktiga kunder.
Så efter att ha installerat agenterna kan vi gå tillbaka till Acura-panelen och se alla våra bilar.
Eftersom jag har arbetat med systemet i mer än en dag har jag maskiner i olika tillstånd. Alla är i standardgruppen, men det är möjligt att skapa separata grupper och överföra maskiner till dem efter behov. Detta påverkar ingenting - bara den logiska representationen av data och deras gruppering för mer bekvämt arbete. Det första och viktigaste vi behöver göra efter det är att starta migreringsprocessen. Vi kan göra detta både med tvång manuellt och sätta upp ett schema, inklusive i bulk för alla maskiner samtidigt.
Låt mig påminna dig om att Hystax var positionerat som en produkt för migration. Därför är det inte förvånande att vi måste skapa en DR-plan för att kunna köra våra replikerade maskiner. Du kan skapa en plan för maskiner som redan är i synkroniserat tillstånd. Du kan generera både för en specifik virtuell dator och för alla maskiner samtidigt.
Parametrarna när du genererar en DR-plan kommer att skilja sig beroende på vilken infrastruktur du ska migrera till. En minimal uppsättning alternativ är tillgängliga för en VMware-miljö. Re-IP för maskiner stöds inte heller. I detta avseende är vi intresserade av följande punkter: i beskrivningen av den virtuella datorn, parametern "subnet": "VMNetwork", där vi binder den virtuella datorn till ett specifikt nätverk i klustret. Rank - relevant vid migrering av flera virtuella datorer, bestämmer i vilken ordning de lanseras. Flavour beskriver VM-konfigurationen, i det här fallet 1CPU, 2GB RAM. I avsnittet undernät definierar vi att "undernät": "VMNetwork" är associerat med "VM-nätverket" för VMware.
När du skapar en DR-plan finns det inget sätt att "dela" diskar mellan olika datalager. De kommer att finnas i samma datalager som definierades för detta klientmoln, och om du har diskar av olika klasser kan detta orsaka vissa svårigheter när du startar maskinen, och efter att ha startat och "separerat" VM:n från Hystax, kommer den också att kräver en separat migreringsdisk till de nödvändiga datalagren. Sedan är det bara att köra vår DR-plan och vänta på att våra bilar ska stiga. P2V/V2V-konverteringsprocessen tar också tid. På min största 100GB testmaskin med tre diskar tog detta max 10 minuter.
Efter det bör du kontrollera den körda virtuella datorn, tjänster på den, datakonsistens och andra kontroller.
Vi har då två alternativ:
- Ta bort - ta bort en pågående DR-plan. Denna åtgärd kommer helt enkelt att stänga av den körda virtuella datorn. Dessa repliker kommer ingenstans.
- Lossa - riv av den replikerade bilen från Acura, d.v.s. faktiskt slutföra migreringsprocessen.
Fördelar med lösningen:
- enkel installation och konfiguration både på klientsidan och på leverantörssidan;
- lätt att ställa in migrering, skapa en DR-plan och lansera repliker;
- support och utvecklare svarar ganska snabbt på de problem som hittas och fixar dem med plattforms- eller agentuppdateringar.
Nackdelar
- Otillräckligt Vmware-stöd.
- Frånvaron av någon kvot för hyresgäster från plattformen.
Jag gjorde också en funktionsbegäran, som vi lämnade över till leverantören:
- användningsövervakning och distribution från Acura Management Console for Cloud Agents;
- tillgänglighet av kvoter för hyresgäster;
- möjligheten att begränsa antalet samtidiga replikeringar och hastighet för varje hyresgäst;
- stöd för VMware vCloud Director;
- stöd för resurspooler (implementerades under testning);
- möjligheten att konfigurera VMware-agenten från sidan av agenten själv, utan att ange referenser från klientinfrastrukturen i Acura-panelen;
- "Visualisering" av processen att starta en virtuell dator när du startar en DR-plan.
Det enda som orsakade mig stora klagomål var dokumentationen. Jag gillar inte riktigt "svarta lådor" och föredrar när det finns detaljerad dokumentation om hur produkten fungerar inuti. Och om för AWS och OpenStack produkten beskrivs ännu mer eller mindre, så finns det väldigt lite dokumentation för VMware.
Det finns en installationsguide som endast beskriver installationen av Acura-panelen, och där det inte finns ett ord om behovet av en molnagent. Det finns en komplett uppsättning specifikationer för produkten, vilket är bra. Det finns dokumentation som beskriver installationen "från och till" med AWS och OpenStack som exempel (även om det påminner mig mer om ett blogginlägg), och det finns en mycket liten kunskapsbas.
I allmänhet är detta inte riktigt det dokumentationsformat som jag är van vid, säg från större leverantörer, så jag var inte helt bekväm. Samtidigt hittade jag inga svar om några av nyanserna i systemets funktion "inuti" i den här dokumentationen - jag var tvungen att klargöra många frågor med teknisk support, och detta drog ut på processen med att distribuera stativet och testning.
Sammanfattningsvis kan jag säga att jag generellt gillade produkten och företagets inställning till genomförandet av uppgiften. Ja, det finns brister, det finns en riktigt kritisk brist på funktionalitet (i kombination med VMware). Det kan ses att företaget för det första fortfarande fokuserar på publika moln, i synnerhet AWS, och för vissa kommer detta att räcka. Att ha en så enkel och bekväm produkt idag, när många företag väljer en multimolnstrategi, är oerhört viktigt. Med tanke på det mycket lägre priset jämfört med konkurrenterna gör detta produkten extremt attraktiv.
Vi söker ett team . Kanske är det du?
Källa: will.com