Uno dei nuovi attori nel mercato delle soluzioni per il Disaster Recovery è Hystax, una startup russa del 2016. Poiché il tema del ripristino da disastri è molto popolare e c'è un'alta concorrenza sul mercato, la startup ha deciso di concentrarsi sulla migrazione tra diverse infrastrutture cloud. Un prodotto che consenta una migrazione semplice e veloce verso il cloud sarebbe molto utile anche per i clienti della società «Онланта» — utenti . Così ho conosciuto Hystax e ho iniziato a testarne le funzionalità. Cosa ne è venuto fuori, lo racconterò in questo articolo.
La principale caratteristica di Hystax è la sua ampia funzionalità nel supportare diverse piattaforme di virtualizzazione, sistemi operativi guest e servizi cloud, il che consente di trasferire i tuoi carichi di lavoro da qualsiasi luogo a qualsiasi altro.
Questo consente non solo di creare soluzioni DR per migliorare la resilienza dei servizi, ma anche di migrare rapidamente e in modo flessibile le risorse tra diverse piattaforme e hyperscaler per massimizzare i risparmi e scegliere la soluzione migliore per un servizio specifico in un dato momento. Oltre alle piattaforme elencate nell'immagine principale, l'azienda collabora attivamente anche con fornitori di cloud russi: Yandex.Cloud, КРОК «Облачные сервисы», Mail.ru e molti altri. Vale anche la pena notare che nel 2020 l'azienda ha aperto un centro R&D situato a Skolkovo.
La scelta di una sola soluzione da parte di un gran numero di attori sul mercato indica una buona politica di prezzo e un'alta applicabilità del prodotto, cosa che abbiamo deciso di verificare nella pratica.
Quindi, il nostro compito di test consisterà nella migrazione dalla mia piattaforma di test VMware e macchine fisiche verso la piattaforma del provider, sempre gestita da VMware. Sì, ci sono molte soluzioni che possono effettuare tale migrazione, ma stiamo considerando Hystax come strumento universale, e testare la migrazione in tutte le possibili combinazioni è semplicemente una tarea irrealizzabile. Inoltre, il cloud Oncloud.ru è costruito precisamente su VMware, quindi questa piattaforma ci interessa maggiormente come obiettivo. Di seguito descriverò il principio di funzionamento fondamentale, che in generale non dipende dalla piattaforma, e VMware può essere sostituita con quella di un altro fornitore da qualsiasi lato.
Nella prima fase è necessario implementare Hystax Acura, che funge da pannello di controllo del sistema.
Si implementa da un modello. Per qualche motivo, nel nostro caso non era del tutto corretto e, invece dei 8 CPU e 16 GB raccomandati, si è implementato con risorse dimezzate. Quindi non bisogna dimenticare di modificarli, altrimenti i contenitori all'interno della VM, su cui è costruita tutta l'infrastruttura, semplicemente non si avvianteranno e il portale sarà inaccessibile. In sono descritti in dettaglio le risorse richieste e le porte per tutti i componenti del sistema.
Ci sono stati anche problemi con l'assegnazione dell'indirizzo IP tramite il modello, quindi è stato modificato dalla console. Dopo questo, puoi accedere all'interfaccia web dell'amministratore e completare la configurazione iniziale.
Endpoint – IP o FQDN del nostro vCenter.
Login e Password – qui è chiaro.
Target ESXi hostname – uno degli host del nostro cluster, su cui verrà effettuata la replica.
Target datastore – uno dei datastore del nostro cluster, su cui verrà effettuata la replica.
Hystax Acura Control Panel Public IP – l'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 è possibile cambiare l'host e il datastore per il tenant, ma il problema è un altro. Hystax non supporta l'uso dei pool di risorse, quindi 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à riguardante il supporto dei pool di risorse). Inoltre, non è supportato vCloud Director, quindi, se 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, allora può replicare e avviare autonomamente queste VM, ma non potrà vederle nell'infrastruttura VMware a cui ha accesso e, di conseguenza, gestire ulteriormente le macchine virtuali. È necessario che l'amministratore del cluster sposti la VM nel pool di risorse necessario o la importi in vCloud Director.
Perché pongo tanta enfasi su questi aspetti? Perché, per come comprendo il concetto del prodotto, il cliente dovrebbe avere la possibilità di gestire autonomamente qualsiasi migrazione o DR tramite il pannello Acura. Ma attualmente il supporto per VMware è un po' indietro rispetto a quello di OpenStack, dove meccanismi simili sono già stati implementati.
Tornando al dispiegamento. Prima di tutto, dopo aver configurato inizialmente il pannello, dobbiamo creare il primo tenant nel nostro sistema.
Tutti i campi qui sono chiari, parlerò solo del campo Cloud. Abbiamo già il cloud «di default» che abbiamo creato durante la configurazione iniziale. Ma se vogliamo avere la possibilità di posizionare ciascun tenant su un proprio datastore e nel proprio pool di risorse, possiamo farlo creando cloud separati per ciascuno dei nostri clienti.
Nel modulo per l'aggiunta di una nuova cloud, indichiamo gli stessi parametri di quando configuravamo inizialmente (possiamo anche usare lo stesso host), specifichiamo il datastore necessario per il cliente specifico, e ora nei parametri aggiuntivi possiamo già indicare individualmente il pool di risorse necessario {«resource_pool»: «YOUR_POOL_NAME»}
Come avrete notato, nel modulo di creazione del tenant non ci sono indicazioni relativi all'assegnazione delle risorse o a qualche quota – non esiste nulla di tutto questo nel sistema. Non è possibile limitare un tenant nel numero di repliche simultanee, nel numero di macchine per la replicazione o secondo altri parametri. Quindi, abbiamo creato il primo tenant. Ora c'è una cosa che non è totalmente logica, ma è obbligatoria – l'installazione dell'agente Cloud. Non è logica perché l'agente viene scaricato nella pagina del cliente specifico.
In questo modo, non è vincolato al tenant creato, e attraverso di esso opereranno tutti i nostri clienti (o più di uno, se li deployiamo). Un agente supporta 10 sessioni simultanee. Una sessione corrisponde a una macchina. Non importa il numero di dischi che ha. Attualmente, non esiste un meccanismo per scalare gli agenti all'interno di Acura su VMware. C'è anche un'altra questione spiacevole: non possiamo vedere dalla dashboard di Acura l'«utilizzo» di questo agente, per capire se è necessario distribuire un altro o se l'attuale installazione è sufficiente. Di conseguenza, l'architettura appare come segue:
Il passaggio successivo per accedere al portale del nostro cliente consiste nella creazione di un account (e in precedenza anche di un ruolo che verrà assegnato a questo utente).
Ora il nostro cliente può utilizzare autonomamente il portale. Tutto ciò che deve fare è scaricare gli agenti dal portale e installarli dalla propria parte. Esistono tre tipi di agenti: Linux, Windows e VMware.
I primi due vengono installati su fisiche o macchine virtuali su qualsiasi hypervisor diverso da VMware. Qui non è necessaria alcuna configurazione aggiuntiva, l'agente viene scaricato e sa già dove dev'essere connesso, e letteralmente dopo un minuto la macchina sarà visibile nel pannello Acura. La situazione con l'agente VMware è un po' più complessa. Il problema è che l'agente per VMware viene scaricato dal portale già configurato e contiene le informazioni necessarie. Ma l'agente VMware, oltre a conoscere il nostro portale Acura, deve sapere anche riguardo al sistema di virtualizzazione su cui verrà implementato.
In effetti, questi dati il sistema ci chiederà di specificare al primo download dell'agente VMware. Il problema è che, nel nostro secolo di amore per la sicurezza, non tutti vorranno fornire la propria password di amministratore su un portale esterno, il che è comprensibile. Dall'interno, dopo l'implementazione, l'agente non può essere riconfigurato (si possono solo cambiare le impostazioni di rete). Qui prevedo difficoltà con i clienti particolarmente cauti.
Dopo aver installato gli agenti, possiamo tornare al pannello Acura e vedere tutte le nostre macchine.
Poiché lavoro con il sistema da un po', ho macchine in vari stati. Tutte si trovano nel gruppo Default, ma è possibile creare gruppi separati e spostare le macchine in base alle vostre esigenze. Questo non influisce su nulla — è solo una rappresentazione logica dei dati e la loro organizzazione per un lavoro più comodo. La prima e più importante cosa che dobbiamo fare dopo è avviare il processo di migrazione. Possiamo farlo in modo forzato e manualmente, oppure impostare un programma, anche per tutte le macchine contemporaneamente.
Ricordo che Hystax si era posizionato come prodotto per la migrazione. Quindi non c'è niente di sorprendente nel fatto che per avviare le nostre macchine replicate sia necessario creare un piano DR. Il piano può essere redatto per le macchine che si trovano già nello stato di Sincronizzazione. È possibile generarlo sia per una singola VM specifica che per tutte le macchine contemporaneamente.
Il set di parametri per la generazione del piano DR varierà a seconda dell'infrastruttura verso cui si intende migrare. Per un ambiente VMware è disponibile un insieme minimo di parametri. Inoltre, il Re-IP non è supportato per le macchine. In questo piano, ci interessano i seguenti aspetti: nella descrizione della VM, il parametro «subnet»: «VMNetwork», dove associamo la VM a una rete specifica nel cluster. Il Rank è rilevante quando si migrano più VM, determinando l'ordine di avvio. Il Flavor descrive la configurazione della VM, in questo caso – 1CPU, 2GB RAM. Nella sezione subnets definiamo che «subnet»: «VMNetwork» è associata alla rete «VM Network» VMware.
Quando si crea un piano DR, non è possibile "spargere" i dischi su diversi datastore. Posizioneranno nello stesso datastore che è stato definito per questa cloud cliente e, se si hanno dischi di classe diversa, ciò potrebbe comportare alcune difficoltà all'avvio della macchina, e dopo l'avvio e il "distacco" della VM da Hystax, richiederà anche una migrazione separata dei dischi nei giusti datastore. A questo punto, non ci resta che avviare il nostro piano DR e attendere il momento in cui le nostre macchine si avvieranno. Il processo di conversione P2V/V2V richiede tempo. Sulla mia più grande macchina di test da 100 GB con tre dischi, ha richiesto massimo 10 minuti.
Dopo, è necessario verificare la VM avviata, i servizi attivi, la coerenza dei dati e effettuare ulteriori controlli.
A questo punto abbiamo due opzioni:
- Elimina – rimuovere il piano DR avviato. Questa azione semplicemente fermerà la VM attiva. I dati della replica non scompariranno.
- Distacca – separare la macchina replicata da Acura, cioè di fatto completare il processo di migrazione.
Vantaggi della soluzione:
- facilità di installazione e configurazione sia dal lato cliente che dal lato fornitore;
- semplicità nella configurazione della migrazione, creazione del piano DR e avvio delle repliche;
- Il supporto e gli sviluppatori reagiscono piuttosto rapidamente ai problemi segnalati e li risolvono tramite aggiornamenti della piattaforma o agenti.
Svantaggi
- Supporto insufficiente per Vmware.
- Assenza di qualsivoglia quota per i tenant da parte della piattaforma.
Ho anche redatto una Feature Request che abbiamo inviato al fornitore:
- monitoraggio dell'utilizzo e distribuzione dalla console di gestione Acura per gli agenti Cloud;
- presenza di quote per i tenant;
- possibilità di limitare il numero di repliche simultanee e la velocità per ogni tenant;
- supporto per VMware vCloud Director;
- supporto per i pool di risorse (realizzato durante i test);
- possibilità di configurare l'agente VMware da parte dello stesso agente, senza inserire le credenziali dell'infrastruttura cliente nel pannello di Acura;
- "visualizzazione" del processo di avvio della VM durante l'avvio del piano DR.
L'unica cosa che mi ha creato maggiori lamentele è stata la documentazione. Non amo molto le "black box" e preferisco avere documentazione dettagliata su come funziona il prodotto internamente. E 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, senza menzionare la necessità di avere anche un agente Cloud. Esiste un insieme completo di specifiche sul prodotto, il che è positivo. C'è anche documentazione che descrive la configurazione «dall'inizio alla fine» usando AWS e OpenStack (anche se mi sembra più un post di blog), e c'è una Knowledge Base molto ridotta.
In generale, non è esattamente il formato di documentazione a cui sono abituato, diciamo, da venditori più grandi, quindi non mi sono sentito del tutto a mio agio. Inoltre, non ho trovato risposte su alcune sfumature del funzionamento del sistema «internamente» in questa documentazione - ho dovuto chiarire molte domande con il supporto tecnico, e questo ha prolungato notevolmente il processo di dispiegamento dell'ambiente e di esecuzione dei test.
In conclusione, posso dire che nel complesso il prodotto e l'approccio dell'azienda all'implementazione del compito mi sono piaciuti. Sì, ci sono delle carenze, c'è davvero una mancanza critica di funzionalità (in particolare con VMware). È evidente che l'azienda si orienta principalmente verso i cloud pubblici, in particolare AWS, e per alcuni questo sarà sufficiente. La disponibilità di un prodotto così semplice e conveniente oggi, quando molte aziende scelgono una strategia multi-cloud, è estremamente importante. Considerando il prezzo notevolmente inferiore rispetto ai concorrenti, questo rende il prodotto molto attraente.
Stiamo cercando per il nostro team . Potresti essere proprio tu?
Fonte: habr.com
