Uno dei giovani attori nel mercato delle soluzioni di Disaster Recovery è Hystax, una startup russa nel 2016. Poiché il tema del disaster recovery è molto diffuso e il mercato è estremamente competitivo, la startup ha deciso di concentrarsi sulla migrazione tra diverse infrastrutture cloud. Un prodotto che permetta di organizzare una migrazione al cloud semplice e veloce sarebbe molto utile per i clienti - utenti di Onlanta . È così che ho conosciuto Hystax e ho iniziato a testarne le caratteristiche. E cosa ne è venuto fuori, lo dirò in questo articolo.
La caratteristica principale di Hystax è la sua ampia funzionalità per supportare varie piattaforme di virtualizzazione, sistemi operativi guest e servizi cloud, che consente di spostare i carichi di lavoro da qualsiasi luogo e ovunque.
Ciò consente non solo di creare soluzioni DR per migliorare la tolleranza ai guasti dei servizi, ma anche di migrare in modo rapido e flessibile le risorse tra diversi siti e hyperscaler per aumentare i risparmi sui costi e selezionare la soluzione migliore per un particolare servizio al momento. Oltre alle piattaforme elencate nell'immagine del titolo, la società collabora attivamente anche con i fornitori di servizi cloud russi: Yandex.Cloud, CROC Cloud Services, Mail.ru e molti altri. Vale anche la pena notare che nel 2020 l'azienda ha aperto un centro di ricerca e sviluppo situato a Skolkovo.
La scelta di una soluzione da parte di un gran numero di attori sul mercato indica una buona politica dei prezzi e un'elevata applicabilità del prodotto, che abbiamo deciso di testare in pratica.
Pertanto, la nostra attività di test consisterà nella migrazione dal mio sito di test VMware e dalle macchine fisiche al sito del provider che esegue anche VMware. Sì, esistono molte soluzioni in grado di implementare tale migrazione, ma consideriamo Hystax uno strumento universale e testare la migrazione in tutte le possibili combinazioni è semplicemente un compito irrealistico. Sì, e il cloud Oncloud.ru è costruito appositamente su VMware, quindi questa piattaforma, come obiettivo, ci interessa maggiormente. Successivamente, descriverò il principio di funzionamento di base, che nel complesso non dipende dalla piattaforma e VMware può essere sostituito da qualsiasi lato con una piattaforma di un altro fornitore.
Il primo passo è implementare Hystax Acura, che è il pannello di controllo del sistema.
Si espande dal modello. Per qualche motivo, nel nostro caso, non era del tutto corretto e invece delle 8 CPU consigliate, sono stati distribuiti 16 GB con metà delle risorse. Pertanto, non bisogna dimenticare di cambiarli, altrimenti l'infrastruttura all'interno della VM, su cui tutto è costruito, semplicemente non si avvierà con i container e il portale non sarà disponibile. IN le risorse necessarie sono descritte in dettaglio, così come le porte per tutti i componenti del sistema.
E c'erano anche difficoltà con l'impostazione dell'indirizzo IP tramite il modello, quindi l'abbiamo cambiato dalla console. Successivamente, puoi andare all'interfaccia web di amministrazione e completare la procedura guidata di configurazione iniziale.
Endpoint: IP o FQDN del nostro vCenter.
Login e password: qui è chiaro.
Il nome host ESXi di destinazione è uno degli host nel nostro cluster su cui verrà replicato.
Il datastore di destinazione è uno dei datastore del nostro cluster in cui verrà eseguita la replica.
IP pubblico del pannello di controllo Hystax Acura - l'indirizzo in cui sarà disponibile il pannello di controllo.
È necessario un piccolo chiarimento sull'host e sul datastore. Il fatto è che la replica Hystax funziona a livello di host e datastore. Successivamente, ti dirò come puoi modificare l'host e il datastore per il tenant, ma il problema è diverso. Hystax non supporta il raggruppamento di risorse, ad es. la replica avverrà sempre alla radice del cluster (al momento della stesura di questo materiale, i ragazzi di Hystax hanno rilasciato una versione aggiornata, in cui hanno rapidamente implementato la mia richiesta di funzionalità relativa al supporto per i pool di risorse). Inoltre vCloud Director non è supportato, ad es. se, come nel mio caso, il tenant non ha diritti di amministratore sull'intero cluster, ma solo su uno specifico pool di risorse, e abbiamo dato accesso a Hystax, allora sarà in grado di replicare ed eseguire autonomamente queste VM, ma non sarà in grado di vederli nell'infrastruttura VMware , a cui ha accesso e, di conseguenza, gestire ulteriormente le macchine virtuali. L'amministratore del cluster deve spostare la macchina virtuale nel pool di risorse corretto o importarla in vCloud Director.
Perché mi concentro così tanto su questi momenti? Perché, per quanto ho capito il concetto del prodotto, il cliente dovrebbe essere in grado di implementare autonomamente qualsiasi migrazione o ripristino di emergenza utilizzando il pannello Acura. Ma finora, il supporto di VMware è leggermente inferiore al livello di supporto per lo stesso OpenStack, dove tali meccanismi sono già stati implementati.
Ma torniamo alla distribuzione. Prima di tutto, dopo il setup iniziale del pannello, dobbiamo creare il primo tenant nel nostro sistema.
Tutti i campi qui sono chiari, ti parlerò solo del campo Cloud. Abbiamo già un cloud "predefinito" che abbiamo creato durante la configurazione iniziale. Ma se vogliamo essere in grado di inserire ogni tenant nel proprio datastore e nel proprio pool di risorse, possiamo implementarlo creando cloud separati per ciascuno dei nostri clienti.
Sotto forma di aggiunta di un nuovo cloud, specifichiamo gli stessi parametri della configurazione iniziale (possiamo persino utilizzare lo stesso host), specifichiamo il datastore richiesto per un determinato cliente e ora nei parametri aggiuntivi possiamo già specificare individualmente il risorsa pool obbligatoria {"resource_pool" :"YOUR_POOL_NAME"}
Come avrai notato, sotto forma di creazione di un inquilino non c'è nulla sull'allocazione delle risorse o su qualche tipo di quota - non c'è nulla di tutto ciò nel sistema. Non è possibile limitare il tenant nel numero di repliche simultanee, nel numero di macchine per la replica o in base a qualsiasi altro parametro. Quindi, abbiamo creato il primo inquilino. Ora c'è una cosa non del tutto logica, ma obbligatoria: l'installazione di un agente cloud. È illogico, perché l'agente viene scaricato sulla pagina di un cliente specifico.
Allo stesso tempo, non è legato al tenant creato e tutti i nostri clienti lavoreranno attraverso di esso (o dopo diversi, se li distribuiamo). Un agente supporta 10 sessioni simultanee. Una sessione conta come una macchina. Non importa quanti dischi ha. Ad oggi, non esiste alcun meccanismo per il ridimensionamento degli agenti in Acura stessa per VMware. C'è un altro momento spiacevole: non siamo in grado di esaminare l '"utilizzo" di questo agente dal pannello Acura per concludere se è necessario distribuire di più o l'installazione corrente è sufficiente. Di conseguenza, lo stand si presenta così:
Il passaggio successivo per accedere al nostro portale clienti è creare un account (e prima anche un ruolo che verrà applicato a questo utente).
Ora il nostro cliente può utilizzare il portale in autonomia. Tutto quello che deve fare è scaricare gli agenti dal portale e installarli dalla sua parte. Esistono tre tipi di agenti: Linux, Windows e VMware.
I primi due vengono applicati alla fisica o alle macchine virtuali su qualsiasi hypervisor non VMware. Non è richiesta alcuna configurazione aggiuntiva qui, l'agente scarica e sa già dove bussare, e letteralmente in un minuto l'auto sarà visibile nel pannello Acura. Con l'agente VMware, la situazione è un po' più complicata. Il problema è che l'Agente per VMware viene scaricato anche dal portale già predisposto e con la configurazione necessaria. Ma l'agente VMware, oltre a conoscere il nostro portale Acura, deve anche conoscere il sistema di virtualizzazione su cui verrà distribuito.
In realtà, il sistema ci chiederà di specificare questi dati quando scarichi per la prima volta l'agente VMware. Il problema è che nella nostra epoca di amore universale per la sicurezza, non tutti vorranno indicare la propria password di amministratore sul portale di qualcun altro, il che è abbastanza comprensibile. Dall'interno, dopo la distribuzione, l'agente non può essere configurato in alcun modo (è possibile solo modificarne le impostazioni di rete). Qui prevedo difficoltà con clienti particolarmente prudenti.
Quindi, dopo aver installato gli agenti, possiamo tornare al pannello Acura e vedere tutte le nostre auto.
Dato che lavoro con il sistema da più di un giorno, ho macchine in vari stati. Sono tutti nel gruppo Predefinito, ma è possibile creare gruppi separati e trasferirvi le macchine, a seconda delle necessità. Ciò non influisce su nulla, solo sulla rappresentazione logica dei dati e sul loro raggruppamento per un lavoro più conveniente. La prima e più importante cosa che dobbiamo fare dopo è avviare il processo di migrazione. Possiamo farlo sia forzatamente manualmente, sia impostare una pianificazione, anche in blocco per tutte le macchine contemporaneamente.
Lascia che ti ricordi che Hystax è stato posizionato come un prodotto per la migrazione. Pertanto, non sorprende che per eseguire le nostre macchine replicate, sia necessario creare un piano DR. Puoi creare un piano per le macchine che si trovano già nello stato Sincronizzato. Puoi generare sia per una macchina virtuale specifica, sia per tutte le macchine contemporaneamente.
L'insieme di parametri durante la generazione di un piano DR differirà a seconda dell'infrastruttura a cui verrà eseguita la migrazione. Per un ambiente VMware è disponibile un set minimo di opzioni. Anche il re-IP per le macchine non è supportato. A questo proposito, ci interessano i seguenti punti: nella descrizione della VM, il parametro "subnet": "VMNetwork", dove leghiamo la VM a una rete specifica nel cluster. Classifica: rilevante durante la migrazione di più macchine virtuali, determina l'ordine in cui vengono avviate. Flavour descrive la configurazione della VM, in questo caso 1 CPU, 2 GB di RAM. Nella sezione subnets, definiamo quella "subnet": "VMNetwork" è associata alla "VM Network" di VMware.
Quando si crea un piano DR, non è possibile "suddividere" i dischi tra diversi datastore. Si troveranno nello stesso datastore definito per questo client cloud e, se si dispone di dischi di classi diverse, ciò potrebbe causare alcune difficoltà all'avvio della macchina e, dopo aver avviato e "separato" la VM da Hystax, sarà anche richiedono una migrazione separata dei dischi nei datastore richiesti. Quindi dobbiamo solo eseguire il nostro piano DR e aspettare che le nostre auto si alzino. Anche il processo di conversione P2V/V2V richiede tempo. Sulla mia più grande macchina di prova da 100 GB con tre dischi, ci sono voluti un massimo di 10 minuti.
Successivamente, dovresti controllare la VM in esecuzione, i servizi su di essa, la coerenza dei dati e altri controlli.
Abbiamo quindi due opzioni:
- Elimina: elimina un piano DR in esecuzione. Questa azione spegnerà semplicemente la macchina virtuale in esecuzione. Queste repliche non andranno da nessuna parte.
- Stacca: strappa l'auto replicata da Acura, ad es. completare effettivamente il processo di migrazione.
Vantaggi della soluzione:
- facilità di installazione e configurazione sia lato client che lato provider;
- facilità di configurazione della migrazione, creazione di un piano DR e lancio di repliche;
- il supporto e gli sviluppatori rispondono abbastanza rapidamente ai problemi riscontrati e li risolvono con gli aggiornamenti della piattaforma o dell'agente.
Contro
- Supporto Vmware insufficiente.
- L'assenza di qualsiasi quota per gli inquilini dalla piattaforma.
Ho anche fatto una richiesta di funzionalità, che abbiamo consegnato al venditore:
- monitoraggio e implementazione dell'utilizzo da Acura Management Console per gli agenti cloud;
- disponibilità di quote per inquilini;
- la possibilità di limitare il numero di repliche simultanee e la velocità per ogni tenant;
- supporto per VMware vCloud Director;
- supporto per pool di risorse (è stato implementato durante i test);
- la possibilità di configurare l'agente VMware dal lato dell'agente stesso, senza inserire le credenziali dall'infrastruttura client nel pannello Acura;
- "Visualizzazione" del processo di avvio di una VM all'avvio di un piano DR.
L'unica cosa che mi ha causato grandi lamentele è stata la documentazione. Non mi piacciono molto le "scatole nere" e preferisco quando c'è una documentazione dettagliata su come funziona il prodotto all'interno. E se per AWS e OpenStack il prodotto è descritto ancora più o meno, allora per VMware c'è pochissima documentazione.
Esiste una Guida all'installazione che descrive solo la distribuzione del pannello Acura e dove non c'è una parola sulla necessità di un agente cloud. C'è una serie completa di specifiche per il prodotto, il che è positivo. Esiste una documentazione che descrive la configurazione "da e verso" utilizzando AWS e OpenStack come esempio (anche se mi ricorda più un post sul blog) e c'è una Knowledge Base molto piccola.
In generale, questo non è esattamente il formato di documentazione a cui sono abituato, diciamo, da fornitori più grandi, quindi non mi sentivo del tutto a mio agio. Allo stesso tempo, in questa documentazione non ho trovato risposte su alcune delle sfumature del funzionamento del sistema "all'interno" - ho dovuto chiarire molte domande con il supporto tecnico, e questo ha piuttosto trascinato il processo di installazione dello stand e test.
Riassumendo, posso dire che in generale mi è piaciuto il prodotto e l'approccio dell'azienda all'implementazione dell'incarico. Sì, ci sono difetti, c'è una mancanza di funzionalità davvero critica (in combinazione con VMware). Si vede che, prima di tutto, l'azienda punta ancora sui cloud pubblici, in particolare su AWS, e per alcuni questo sarà sufficiente. Avere un prodotto così semplice e conveniente oggi, quando molte aziende scelgono una strategia multi-cloud, è estremamente importante. Dato il prezzo molto più basso rispetto ai concorrenti, questo rende il prodotto estremamente appetibile.
Cerchiamo una squadra . Forse sei tu?
Fonte: habr.com