Uno dei giovani attori nel mercato delle soluzioni di Disaster Recovery è Hystax, una startup russa del 2016. Poiché il tema del ripristino di emergenza è molto popolare e la competizione sul mercato è estremamente alta, la startup ha deciso di concentrarsi sulla migrazione tra diverse infrastrutture cloud. Un prodotto che consenta una migrazione semplice e rapida nel cloud sarebbe molto utile anche per i clienti di "Onlanta" — utenti. . Così ho conosciuto Hystax e ho iniziato a testarne le funzionalità. Quello che è uscito da questo, lo racconterò in questo articolo.
Il principale punto di forza di Hystax è la sua ampia funzionalità nel supporto di diverse piattaforme di virtualizzazione, sistemi operativi guest e servizi cloud, che consente di spostare i propri carichi di lavoro da qualsiasi luogo a qualsiasi luogo.
Questo permette di creare non solo soluzioni DR per aumentare la resilienza dei servizi, ma anche di migrare risorse in modo rapido e flessibile tra diversi data center e hyperscalers per massimizzare il risparmio e scegliere la soluzione migliore per un determinato servizio in quel momento. Oltre alle piattaforme elencate nell'immagine principale, l'azienda collabora attivamente anche con provider cloud russi: Yandex.Cloud, KROK "Servizi Cloud", Mail.ru e molti altri. Va inoltre notato che nel 2020 l'azienda ha aperto un centro R&D situato a Skolkovo.
La scelta di una soluzione da parte di molti attori sul mercato indica una buona politica dei prezzi e un'elevata applicabilità del prodotto, e questo abbiamo deciso di verificarlo nella pratica.
Pertanto, il nostro compito di test consisterà nella migrazione dalla mia piattaforma di test VMware e da macchine fisiche alla piattaforma del provider, anch'essa gestita da VMware. Sì, ci sono molte soluzioni che possono effettuare una simile migrazione, ma consideriamo Hystax come uno strumento universale, mentre testare la migrazione in tutte le possibili combinazioni è semplicemente un compito irrealistico. Inoltre, il cloud Oncloud.ru è costruito proprio su VMware, quindi questa piattaforma ci interessa maggiormente come obiettivo. Di seguito descriverò il principio di funzionamento principale, che in generale non dipende dalla piattaforma, e VMware può essere sostituito con una piattaforma di un altro fornitore.
Nella prima fase è necessario distribuire Hystax Acura, che è il pannello di controllo del sistema.
Viene distribuito da un modello. Per qualche motivo, nel nostro caso, non era completamente corretto e anziché i 8CPU raccomandati, 16Gb si distribuiva con una capacità due volte inferiore. Pertanto, non dimenticare di modificarli, altrimenti l'infrastruttura all'interno della VM, su cui tutto è costruito, non si avvierà semplicemente e il portale sarà inaccessibile. In sono descritti in dettaglio le risorse richieste e le porte per tutti i componenti del sistema.
E ci sono stati anche problemi con l'assegnazione dell'indirizzo IP tramite il modello, quindi l'abbiamo cambiato dalla console. Dopo di ciò, è possibile passare all'interfaccia web di amministrazione e completare il maestro di configurazione iniziale.
Endpoint – IP o FQDN del nostro vCenter.
Login e Password – qui è chiaro.
Nome host ESXi target – uno degli host del nostro cluster su cui verrà eseguita la replica.
Datastore target – uno dei datastore del nostro cluster su cui verrà eseguita la replica.
IP pubblico del pannello di controllo Hystax Acura – indirizzo tramite il quale sarà accessibile il pannello di controllo.
È necessaria una piccola precisazione riguardo all'host e al datastore. Infatti, la replica Hystax funziona a livello di host e datastore. Più avanti spiegherò come cambiare l'host e il datastore per il tenant, ma il problema è un altro. Hystax non supporta il lavoro con pool di risorse, cioè la replica avverrà sempre nella radice del cluster (mentre scrivevo questo materiale, i ragazzi di Hystax hanno rilasciato una versione aggiornata in cui hanno rapidamente implementato la mia richiesta di funzionalità riguardo al supporto dei pool di risorse). Non è supportato nemmeno vCloud Director, cioè se, come nel mio caso, il tenant non ha diritti di amministratore su tutto il cluster, ma solo su un particolare pool di risorse, e abbiamo dato accesso a Hystax, quindi potrà replicare ed avviare queste VM autonomamente, ma non sarà in grado di vederle nell'infrastruttura VMware a cui ha accesso e, di conseguenza, non potrà gestire ulteriormente le macchine virtuali. Sarà necessario che l'amministratore del cluster sposti la VM nel pool di risorse corretto o la importi in vCloud Director.
Perché sottolineo così tanto questi aspetti? Perché, per quanto riesca a capire il concetto del prodotto, il cliente deve avere la possibilità di eseguire autonomamente qualsiasi migrazione o DR tramite il pannello Acura. Ma attualmente il supporto VMware è un po' indietro rispetto al supporto di OpenStack, dove meccanismi simili sono già implementati.
Ma torniamo al deployment. Prima di tutto, dopo la configurazione iniziale del pannello, dobbiamo creare il primo tenant nel nostro sistema.
Tutti i campi qui sono chiari; parlerò solo del campo Cloud. Abbiamo già una 'cloud di default', che abbiamo creato durante la configurazione iniziale. Ma se vogliamo avere la possibilità di allocare ogni tenant su un proprio datastor e in un proprio pool di risorse, possiamo realizzarlo creando cloud separati per ciascuno dei nostri clienti.
Nel modulo per aggiungere una nuova cloud, indichiamo gli stessi parametri che abbiamo utilizzato nella configurazione iniziale (possiamo persino utilizzare lo stesso host), indichiamo il datastor necessario per il cliente specifico, e ora, nelle impostazioni aggiuntive, possiamo già indicare individualmente il pool di risorse necessario {«resource_pool»: «YOUR_POOL_NAME»}.
Come avrete notato, nel modulo di creazione del tenant non c'è nulla riguardo all'assegnazione delle risorse o a eventuali quote: non c'è nulla di tutto ciò nel sistema. Non è possibile limitare un tenant nel numero di repliche simultanee, nel numero di macchine per la replicazione o in altri parametri. Quindi, abbiamo creato il primo tenant. Ora c'è una cosa non del tutto logica, ma obbligatoria: l'installazione dell'agente Cloud. Non è logica poiché l'agente viene scaricato nella pagina del cliente specifico.
In questo modo, non è legato al tenant creato, e attraverso di esso lavoreranno tutti i nostri clienti (o attraverso alcuni, se li deployeremo). Un agente supporta 10 sessioni simultanee. Una sessione è considerata una macchina. Non importa quante dischi ha. Ad oggi, non esiste un meccanismo per scalare gli agenti direttamente in Acura sotto VMware. C'è anche un altro aspetto spiacevole: non abbiamo la possibilità di vedere dalla console Acura l'"utilizzo" di questo agente, per decidere se è necessario deployarne ancora uno o se l'installazione attuale è sufficiente. In definitiva, lo stand appare come segue:
Il passo successivo per accedere al portale del nostro cliente è creare un account (e preliminarmente anche un ruolo, che verrà applicato a questo utente).
Ora il nostro cliente può utilizzare il portale autonomamente. Tutto ciò che deve fare è scaricare gli agenti dal portale e installarli dalla sua parte. Ci sono tre tipi di agenti: Linux, Windows e VMware.
I primi due possono essere installati su hardware fisico o su macchine virtuali su qualsiasi hypervisor diverso da VMware. Qui non è necessario configurare nulla di aggiuntivo; l'agente viene scaricato e già sa dove deve collegarsi, e praticamente in un minuto la macchina sarà visibile nella console Acura. La situazione con l'agente VMware è un po' più complessa. Il problema è che l'agente per VMware viene anch'esso scaricato dal portale già preparato e con la configurazione necessaria. Tuttavia, l'agente VMware, oltre a conoscere il nostro portale Acura, deve anche sapere del sistema di virtualizzazione su cui verrà deployato.
In effetti, questi dati il sistema ci chiederà di fornire al primo download dell'agente VMware. Il problema è che, nell'era dell'amore universale per la sicurezza, non tutti saranno disposti a inserire la propria password di amministrazione su un portale esterno, il che è comprensibile. Una volta deployato, l'agente non può più essere configurato (è possibile solo modificare le sue impostazioni di rete). Qui prevedo difficoltà con clienti particolarmente cauti.
Quindi, dopo aver installato gli agenti, possiamo tornare alla console Acura e vedere tutte le nostre macchine.
Poiché non è il mio primo giorno di lavoro con il sistema, ho macchine in diversi stati. Tutte si trovano nel gruppo Default, ma è possibile creare gruppi separati e spostare le macchine in essi, come necessario. Questo non influisce su niente: è solo una rappresentazione logica dei dati e una loro organizzazione per un lavoro più comodo. La prima e più importante cosa che dobbiamo fare dopo è avviare il processo di migrazione. Possiamo farlo sia manualmente che forzatamente, sia impostare un programma, incluso per tutte le macchine contemporaneamente.
Ricordo che Hystax è stato posizionato come prodotto per la migrazione. Pertanto, non c'è nulla di sorprendente nel fatto che per avviare le nostre macchine replicate dobbiamo creare un piano DR. Il piano può essere redatto per le macchine che sono già nello stato Synced. Può essere generato sia per una specifica VM che per tutte le macchine contemporaneamente.
Il set di parametri durante la generazione del piano DR varierà a seconda dell'infrastruttura verso cui migrerai. Per l'ambiente VMware è disponibile un set minimo di parametri. Inoltre, non è supportato il Re-IP per le macchine. In questo piano ci interessano i seguenti aspetti: nella descrizione della VM il parametro "subnet": "VMNetwork", dove colleghiamo la VM a una rete specifica nel cluster. Rank – è rilevante quando si migrano più VM, determina l'ordine di avvio. Flavor – descrive la configurazione della VM, in questo caso: 1CPU, 2GB RAM. Nella sezione subnets definiremo che "subnet": "VMNetwork" è associato alla rete "VM Network" VMware.
Quando si crea un piano DR non è possibile "sdoppiare" i dischi su diversi datastore. Questi si troveranno nello stesso datastore che è stato definito per questa cloud client, e se hai dischi di classi diverse, ciò può causare alcuni problemi all'avvio della macchina, e dopo l'avvio e il "distacco" della VM da Hystax, richiederà anche una migrazione separata dei dischi nei datastore appropriati. Dopo, non ci rimane che avviare il nostro piano DR e attendere che le nostre macchine si avviino. Il processo di conversione P2V/V2V richiede anche tempo. Sulla mia macchina di test più grande da 100 GB con tre dischi, ci sono voluti al massimo 10 minuti.
Dopo ciò, è necessario controllare la VM avviata, i servizi su di essa, la coerenza dei dati e effettuare ulteriori verifiche.
Da qui abbiamo due percorsi:
- Elimina – rimuovi il piano DR avviato. Questa azione spegnerà semplicemente la VM avviata. I dati della replica non andranno da nessuna parte.
- Distacca – stacca la macchina replicata da Acura, cioè termina effettivamente il processo di migrazione.
Vantaggi della soluzione:
- facilità di installazione e configurazione sia dal lato del cliente che da quello del fornitore;
- facilità di configurazione della migrazione, creazione del piano DR e avvio delle repliche;
- il supporto e gli sviluppatori rispondono piuttosto rapidamente ai problemi riscontrati e li risolvono tramite aggiornamenti della piattaforma o degli agenti.
Contro
- Supporto insufficiente per Vmware.
- Mancanza di qualsiasi tipo di quota per i tenant da parte della piattaforma.
Ho anche preparato una richiesta di funzionalità che abbiamo inviato al fornitore:
- monitoraggio dell'uso e distribuzione dalla console di gestione Acura per gli agenti Cloud;
- presenza di quote per i tenant;
- possibilità di limitare il numero di replicazioni simultanee e la velocità per ogni tenant;
- supporto per VMware vCloud Director;
- supporto per i resource pool (realizzato durante i test);
- possibilità di configurare l'agente VMware direttamente dall'agente stesso, senza dover inserire le credenziali dell'infrastruttura del cliente nel pannello Acura;
- «visualizzazione» del processo di avvio della VM durante l'attivazione del piano DR.
L'unica cosa che mi ha sollevato grandi obiezioni è stata la documentazione. Non mi piacciono molto le «scatole nere» e preferisco avere dettagliate indicazioni su come funziona il prodotto internamente. Se per AWS e OpenStack il prodotto è descritto più o meno, per VMware la documentazione è estremamente scarsa.
C'è una Guida all'Installazione che descrive solo il dispiegamento del pannello Acura, e non dice nulla sul fatto che ci sia bisogno anche di un Cloud agent. C'è un set completo di specifiche sul prodotto, il che è positivo. C'è una documentazione che descrive la configurazione «dall'inizio alla fine» con esempi di AWS e OpenStack (anche se mi ricorda più un post di un blog), e c'è una Knowledge Base molto limitata.
In generale, questo non è propriamente il formato di documentazione a cui sono abituato, diciamo, da fornitori più grandi, quindi non mi sono sentito completamente a mio agio. D'altra parte, non sono riuscito a trovare risposte a alcune sfumature del funzionamento del sistema «internamente» in questa documentazione – ho dovuto chiarire molte domande con il supporto tecnico, e questo ha allungato notevolmente il processo di dispiegamento dell'ambiente e di conduzione dei test.
In sintesi, posso dire che, nel complesso, mi è piaciuto il prodotto e l'approccio dell'azienda nell'affrontare il compito. Sì, ci sono delle carenze, c'è effettivamente una mancanza critica di funzionalità (in combinazione con VMware). È evidente che, prima di tutto, l'azienda si orienta comunque verso i cloud pubblici, in particolare AWS, e per qualcuno questo potrebbe essere sufficiente. La presenza di un prodotto così semplice e comodo oggi, quando molte aziende scelgono una strategia multi-cloud, è estremamente importante. Considerando il prezzo molto più basso rispetto ai concorrenti, questo rende il prodotto estremamente attraente.
Stiamo cercando un . Potresti essere tu?
Fonte: habr.com
