{"id":96767,"date":"2020-10-14T14:43:02","date_gmt":"2020-10-14T12:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam"},"modified":"2020-10-14T14:43:02","modified_gmt":"2020-10-14T12:43:02","slug":"hystax-cloud-migration-skachem-po-oblakam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam","title":{"rendered":"Hystax Cloud Migration: saltiamo tra le nuvole","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Uno dei giovani attori nel mercato delle soluzioni di Disaster Recovery \u00e8 Hystax, una startup russa fondata nel 2016. Poich\u00e9 il tema del recupero da disastri \u00e8 molto popolare e la concorrenza nel mercato \u00e8 estremamente alta, la startup ha deciso di concentrarsi sulla migrazione tra diverse infrastrutture cloud. Un prodotto che consenta una migrazione semplice e veloce nel cloud sarebbe molto utile anche per i clienti di \"Onlanta\" \u2013 gli utenti. Oncloud.ru<\/a><\/noindex>. Cos\u00ec ho conosciuto Hystax e ho iniziato a testarne le funzionalit\u00e0. Cosa ne \u00e8 venuto fuori, lo racconter\u00f2 in questo articolo.<\/p>\n

\"Hystax<\/a><\/noindex>
\nLa principale caratteristica di Hystax \u00e8 la sua ampia funzionalit\u00e0 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.<\/p>\n

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, \u041a\u0420\u041e\u041a \u00ab\u041e\u0431\u043b\u0430\u0447\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b\u00bb, Mail.ru e molti altri. Vale anche la pena notare che nel 2020 l'azienda ha aperto un centro R&D situato a Skolkovo.\u00a0<\/p>\n

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\u00e0 del prodotto, cosa che abbiamo deciso di verificare nella pratica.<\/p>\n

Quindi, il nostro compito di test consister\u00e0 nella migrazione dalla mia piattaforma di test VMware e macchine fisiche verso la piattaforma del provider, sempre gestita da VMware. S\u00ec, 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 \u00e8 semplicemente una tarea irrealizzabile. Inoltre, il cloud Oncloud.ru \u00e8 costruito precisamente su VMware, quindi questa piattaforma ci interessa maggiormente come obiettivo. Di seguito descriver\u00f2 il principio di funzionamento fondamentale, che in generale non dipende dalla piattaforma, e VMware pu\u00f2 essere sostituita con quella di un altro fornitore da qualsiasi lato.\u00a0<\/p>\n

Nella prima fase \u00e8 necessario implementare Hystax Acura, che funge da pannello di controllo del sistema.<\/p>\n

\"Hystax<\/a><\/noindex>
\nSi 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 \u00e8 implementato con risorse dimezzate. Quindi non bisogna dimenticare di modificarli, altrimenti i contenitori all'interno della VM, su cui \u00e8 costruita tutta l'infrastruttura, semplicemente non si avvianteranno e il portale sar\u00e0 inaccessibile. In Requisiti di distribuzione<\/a><\/noindex> sono descritti in dettaglio le risorse richieste e le porte per tutti i componenti del sistema.\u00a0<\/p>\n

Ci sono stati anche problemi con l'assegnazione dell'indirizzo IP tramite il modello, quindi \u00e8 stato modificato dalla console. Dopo questo, puoi accedere all'interfaccia web dell'amministratore e completare la configurazione iniziale.\u00a0<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nEndpoint \u2013 IP o FQDN del nostro vCenter.\u00a0
\nLogin e Password \u2013 qui \u00e8 chiaro.\u00a0
\nTarget ESXi hostname \u2013 uno degli host del nostro cluster, su cui verr\u00e0 effettuata la replica.\u00a0
\nTarget datastore \u2013 uno dei datastore del nostro cluster, su cui verr\u00e0 effettuata la replica.
\nHystax Acura Control Panel Public IP \u2013 l'indirizzo tramite il quale sar\u00e0 accessibile il pannello di controllo.<\/p>\n

\u00c8 necessaria una piccola precisazione riguardo all'host e al datastore. Infatti, la replica Hystax funziona a livello di host e datastore. Pi\u00f9 avanti spiegher\u00f2 come \u00e8 possibile cambiare l'host e il datastore per il tenant, ma il problema \u00e8 un altro. Hystax non supporta l'uso dei pool di risorse, quindi la replica avverr\u00e0 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\u00e0 riguardante il supporto dei pool di risorse). Inoltre, non \u00e8 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\u00f2 replicare e avviare autonomamente queste VM, ma non potr\u00e0 vederle nell'infrastruttura VMware a cui ha accesso e, di conseguenza, gestire ulteriormente le macchine virtuali. \u00c8 necessario che l'amministratore del cluster sposti la VM nel pool di risorse necessario o la importi in vCloud Director.<\/p>\n

Perch\u00e9 pongo tanta enfasi su questi aspetti? Perch\u00e9, per come comprendo il concetto del prodotto, il cliente dovrebbe avere la possibilit\u00e0 di gestire autonomamente qualsiasi migrazione o DR tramite il pannello Acura. Ma attualmente il supporto per VMware \u00e8 un po' indietro rispetto a quello di OpenStack, dove meccanismi simili sono gi\u00e0 stati implementati.\u00a0<\/p>\n

Tornando al dispiegamento. Prima di tutto, dopo aver configurato inizialmente il pannello, dobbiamo creare il primo tenant nel nostro sistema.<\/p>\n

\"Hystax<\/a><\/noindex>
\nTutti i campi qui sono chiari, parler\u00f2 solo del campo Cloud. Abbiamo gi\u00e0 il cloud \u00abdi default\u00bb che abbiamo creato durante la configurazione iniziale. Ma se vogliamo avere la possibilit\u00e0 di posizionare ciascun tenant su un proprio datastore e nel proprio pool di risorse, possiamo farlo creando cloud separati per ciascuno dei nostri clienti.<\/p>\n

\"Hystax<\/a><\/noindex>
\nNel 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\u00e0 indicare individualmente il pool di risorse necessario {\u00abresource_pool\u00bb: \u00abYOUR_POOL_NAME\u00bb}\u00a0<\/p>\n

Come avrete notato, nel modulo di creazione del tenant non ci sono indicazioni relativi all'assegnazione delle risorse o a qualche quota \u2013 non esiste nulla di tutto questo nel sistema. Non \u00e8 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'\u00e8 una cosa che non \u00e8 totalmente logica, ma \u00e8 obbligatoria \u2013 l'installazione dell'agente Cloud. Non \u00e8 logica perch\u00e9 l'agente viene scaricato nella pagina del cliente specifico.<\/p>\n

\"Hystax<\/a><\/noindex>
\nIn questo modo, non \u00e8 vincolato al tenant creato, e attraverso di esso opereranno tutti i nostri clienti (o pi\u00f9 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'\u00e8 anche un'altra questione spiacevole: non possiamo vedere dalla dashboard di Acura l'\u00abutilizzo\u00bb di questo agente, per capire se \u00e8 necessario distribuire un altro o se l'attuale installazione \u00e8 sufficiente. Di conseguenza, l'architettura appare come segue:<\/p>\n

\"Hystax<\/a><\/noindex>
\nIl passaggio successivo per accedere al portale del nostro cliente consiste nella creazione di un account (e in precedenza anche di un ruolo che verr\u00e0 assegnato a questo utente).<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nOra il nostro cliente pu\u00f2 utilizzare autonomamente il portale. Tutto ci\u00f2 che deve fare \u00e8 scaricare gli agenti dal portale e installarli dalla propria parte. Esistono tre tipi di agenti: Linux, Windows e VMware.<\/p>\n

\"Hystax<\/a><\/noindex>
\nI primi due vengono installati su fisiche o macchine virtuali su qualsiasi hypervisor diverso da VMware. Qui non \u00e8 necessaria alcuna configurazione aggiuntiva, l'agente viene scaricato e sa gi\u00e0 dove dev'essere connesso, e letteralmente dopo un minuto la macchina sar\u00e0 visibile nel pannello Acura. La situazione con l'agente VMware \u00e8 un po' pi\u00f9 complessa. Il problema \u00e8 che l'agente per VMware viene scaricato dal portale gi\u00e0 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\u00e0 implementato.<\/p>\n

\"Hystax<\/a><\/noindex>
\nIn effetti, questi dati il sistema ci chieder\u00e0 di specificare al primo download dell'agente VMware. Il problema \u00e8 che, nel nostro secolo di amore per la sicurezza, non tutti vorranno fornire la propria password di amministratore su un portale esterno, il che \u00e8 comprensibile. Dall'interno, dopo l'implementazione, l'agente non pu\u00f2 essere riconfigurato (si possono solo cambiare le impostazioni di rete). Qui prevedo difficolt\u00e0 con i clienti particolarmente cauti.\u00a0<\/p>\n

Dopo aver installato gli agenti, possiamo tornare al pannello Acura e vedere tutte le nostre macchine.<\/p>\n

\"Hystax<\/a><\/noindex>
\nPoich\u00e9 lavoro con il sistema da un po', ho macchine in vari stati. Tutte si trovano nel gruppo Default, ma \u00e8 possibile creare gruppi separati e spostare le macchine in base alle vostre esigenze. Questo non influisce su nulla \u2014 \u00e8 solo una rappresentazione logica dei dati e la loro organizzazione per un lavoro pi\u00f9 comodo. La prima e pi\u00f9 importante cosa che dobbiamo fare dopo \u00e8 avviare il processo di migrazione. Possiamo farlo in modo forzato e manualmente, oppure impostare un programma, anche per tutte le macchine contemporaneamente.<\/p>\n

\"Hystax<\/a><\/noindex>
\nRicordo che Hystax si era posizionato come prodotto per la migrazione. Quindi non c'\u00e8 niente di sorprendente nel fatto che per avviare le nostre macchine replicate sia necessario creare un piano DR. Il piano pu\u00f2 essere redatto per le macchine che si trovano gi\u00e0 nello stato di Sincronizzazione. \u00c8 possibile generarlo sia per una singola VM specifica che per tutte le macchine contemporaneamente.<\/p>\n

\"Hystax<\/a><\/noindex>
\nIl set di parametri per la generazione del piano DR varier\u00e0 a seconda dell'infrastruttura verso cui si intende migrare. Per un ambiente VMware \u00e8 disponibile un insieme minimo di parametri. Inoltre, il Re-IP non \u00e8 supportato per le macchine. In questo piano, ci interessano i seguenti aspetti: nella descrizione della VM, il parametro \u00absubnet\u00bb: \u00abVMNetwork\u00bb, dove associamo la VM a una rete specifica nel cluster. Il Rank \u00e8 rilevante quando si migrano pi\u00f9 VM, determinando l'ordine di avvio. Il Flavor descrive la configurazione della VM, in questo caso \u2013 1CPU, 2GB RAM. Nella sezione subnets definiamo che \u00absubnet\u00bb: \u00abVMNetwork\u00bb \u00e8 associata alla rete \u00abVM Network\u00bb VMware.\u00a0<\/p>\n

Quando si crea un piano DR, non \u00e8 possibile \"spargere\" i dischi su diversi datastore. Posizioneranno nello stesso datastore che \u00e8 stato definito per questa cloud cliente e, se si hanno dischi di classe diversa, ci\u00f2 potrebbe comportare alcune difficolt\u00e0 all'avvio della macchina, e dopo l'avvio e il \"distacco\" della VM da Hystax, richieder\u00e0 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\u00f9 grande macchina di test da 100 GB con tre dischi, ha richiesto massimo 10 minuti.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDopo, \u00e8 necessario verificare la VM avviata, i servizi attivi, la coerenza dei dati e effettuare ulteriori controlli.\u00a0<\/p>\n

A questo punto abbiamo due opzioni:\u00a0<\/p>\n

    \n
  1. Elimina \u2013 rimuovere il piano DR avviato. Questa azione semplicemente fermer\u00e0 la VM attiva. I dati della replica non scompariranno.\u00a0<\/li>\n
  2. Distacca \u2013 separare la macchina replicata da Acura, cio\u00e8 di fatto completare il processo di migrazione.\u00a0<\/li>\n<\/ol>\n

    \nVantaggi della soluzione:<\/strong>\u00a0<\/p>\n