{"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 del 2016. Poich\u00e9 il tema del ripristino dei dati \u00e8 molto popolare e c'\u00e8 una concorrenza estremamente alta, la startup ha deciso di concentrarsi sulla migrazione tra diverse infrastrutture cloud. Un prodotto che consenta di organizzare una migrazione semplice e veloce nel cloud sarebbe molto utile anche ai clienti dell'azienda \"Onlanta\" \u2014 gli utenti Oncloud.ru<\/a><\/noindex>. Cos\u00ec ho conosciuto Hystax e ho iniziato a testarne le funzionalit\u00e0. Quello che \u00e8 uscito da questo, lo racconter\u00f2 in questo articolo.<\/p>\n

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

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.\u00a0<\/p>\n

La scelta di una soluzione da parte di molti attori sul mercato indica una buona politica dei prezzi e un'elevata applicabilit\u00e0 del prodotto, e questo abbiamo deciso di verificarlo nella pratica.<\/p>\n

Pertanto, il nostro compito di test consister\u00e0 nella migrazione dalla mia piattaforma di test VMware e da macchine fisiche alla piattaforma del provider, anch'essa gestita da VMware. S\u00ec, 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 \u00e8 semplicemente un compito irrealistico. Inoltre, il cloud Oncloud.ru \u00e8 costruito proprio su VMware, quindi questa piattaforma ci interessa maggiormente come obiettivo. Di seguito descriver\u00f2 il principio di funzionamento principale, che in generale non dipende dalla piattaforma, e VMware pu\u00f2 essere sostituito con una piattaforma di un altro fornitore.\u00a0<\/p>\n

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

\"Hystax<\/a><\/noindex>
\nViene distribuito da un modello. Per qualche motivo, nel nostro caso, non era completamente corretto e anzich\u00e9 i 8CPU raccomandati, 16Gb si distribuiva con una capacit\u00e0 due volte inferiore. Pertanto, non dimenticare di modificarli, altrimenti l'infrastruttura all'interno della VM, su cui tutto \u00e8 costruito, non si avvier\u00e0 semplicemente 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

E ci sono stati anche problemi con l'assegnazione dell'indirizzo IP tramite il modello, quindi l'abbiamo cambiato dalla console. Dopo di ci\u00f2, \u00e8 possibile passare all'interfaccia web di amministrazione e completare il maestro di 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
\nNome host ESXi target \u2013 uno degli host del nostro cluster su cui verr\u00e0 eseguita la replica.\u00a0
\nDatastore target \u2013 uno dei datastore del nostro cluster su cui verr\u00e0 eseguita la replica.
\nIP pubblico del pannello di controllo Hystax Acura \u2013 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 cambiare l'host e il datastore per il tenant, ma il problema \u00e8 un altro. Hystax non supporta il lavoro con pool di risorse, cio\u00e8 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 riguardo al supporto dei pool di risorse). Non \u00e8 supportato nemmeno vCloud Director, cio\u00e8 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\u00e0 replicare ed avviare queste VM autonomamente, ma non sar\u00e0 in grado di vederle nell'infrastruttura VMware a cui ha accesso e, di conseguenza, non potr\u00e0 gestire ulteriormente le macchine virtuali. Sar\u00e0 necessario che l'amministratore del cluster sposti la VM nel pool di risorse corretto o la importi in vCloud Director.<\/p>\n

Perch\u00e9 sottolineo cos\u00ec tanto questi aspetti? Perch\u00e9, per quanto riesca a capire il concetto del prodotto, il cliente deve avere la possibilit\u00e0 di eseguire autonomamente qualsiasi migrazione o DR tramite il pannello Acura. Ma attualmente il supporto VMware \u00e8 un po' indietro rispetto al supporto di OpenStack, dove meccanismi simili sono gi\u00e0 implementati.\u00a0<\/p>\n

Ma torniamo al deployment. Prima di tutto, dopo la configurazione iniziale del 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 una 'cloud di default', che abbiamo creato durante la configurazione iniziale. Ma se vogliamo avere la possibilit\u00e0 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.<\/p>\n

\"Hystax<\/a><\/noindex>
\nNel 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\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 c'\u00e8 nulla riguardo all'assegnazione delle risorse o a eventuali quote: non c'\u00e8 nulla di tutto ci\u00f2 nel sistema. Non \u00e8 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'\u00e8 una cosa non del tutto logica, ma obbligatoria: l'installazione dell'agente Cloud. Non \u00e8 logica poich\u00e9 l'agente viene scaricato nella pagina del cliente specifico.<\/p>\n

\"Hystax<\/a><\/noindex>
\nIn questo modo, non \u00e8 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 \u00e8 considerata una macchina. Non importa quante dischi ha. Ad oggi, non esiste un meccanismo per scalare gli agenti direttamente in Acura sotto VMware. C'\u00e8 anche un altro aspetto spiacevole: non abbiamo la possibilit\u00e0 di vedere dalla console Acura l'\"utilizzo\" di questo agente, per decidere se \u00e8 necessario deployarne ancora uno o se l'installazione attuale \u00e8 sufficiente. In definitiva, lo stand appare come segue:<\/p>\n

\"Hystax<\/a><\/noindex>
\nIl passo successivo per accedere al portale del nostro cliente \u00e8 creare un account (e preliminarmente anche un ruolo, che verr\u00e0 applicato a questo utente).<\/p>\n

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

\"Hystax<\/a><\/noindex>
\nI primi due possono essere installati su hardware fisico o su macchine virtuali su qualsiasi hypervisor diverso da VMware. Qui non \u00e8 necessario configurare nulla di aggiuntivo; l'agente viene scaricato e gi\u00e0 sa dove deve collegarsi, e praticamente in un minuto la macchina sar\u00e0 visibile nella console Acura. La situazione con l'agente VMware \u00e8 un po' pi\u00f9 complessa. Il problema \u00e8 che l'agente per VMware viene anch'esso scaricato dal portale gi\u00e0 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\u00e0 deployato.<\/p>\n

\"Hystax<\/a><\/noindex>
\nIn effetti, questi dati il sistema ci chieder\u00e0 di fornire al primo download dell'agente VMware. Il problema \u00e8 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 \u00e8 comprensibile. Una volta deployato, l'agente non pu\u00f2 pi\u00f9 essere configurato (\u00e8 possibile solo modificare le sue impostazioni di rete). Qui prevedo difficolt\u00e0 con clienti particolarmente cauti.\u00a0<\/p>\n

Quindi, dopo aver installato gli agenti, possiamo tornare alla console Acura e vedere tutte le nostre macchine.<\/p>\n

\"Hystax<\/a><\/noindex>
\nPoich\u00e9 non \u00e8 il mio primo giorno di lavoro con il sistema, ho macchine in diversi stati. Tutte si trovano nel gruppo Default, ma \u00e8 possibile creare gruppi separati e spostare le macchine in essi, come necessario. Questo non influisce su niente: \u00e8 solo una rappresentazione logica dei dati e una 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 sia manualmente che forzatamente, sia impostare un programma, incluso per tutte le macchine contemporaneamente.<\/p>\n

\"Hystax<\/a><\/noindex>
\nRicordo che Hystax \u00e8 stato posizionato come prodotto per la migrazione. Pertanto, non c'\u00e8 nulla di sorprendente nel fatto che per avviare le nostre macchine replicate dobbiamo creare un piano DR. Il piano pu\u00f2 essere redatto per le macchine che sono gi\u00e0 nello stato Synced. Pu\u00f2 essere generato sia per una specifica VM che per tutte le macchine contemporaneamente.<\/p>\n

\"Hystax<\/a><\/noindex>
\nIl set di parametri durante la generazione del piano DR varier\u00e0 a seconda dell'infrastruttura verso cui migrerai. Per l'ambiente VMware \u00e8 disponibile un set minimo di parametri. Inoltre, non \u00e8 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 \u2013 \u00e8 rilevante quando si migrano pi\u00f9 VM, determina l'ordine di avvio. Flavor \u2013 descrive la configurazione della VM, in questo caso: 1CPU, 2GB RAM. Nella sezione subnets definiremo che \"subnet\": \"VMNetwork\" \u00e8 associato alla rete \"VM Network\" VMware.\u00a0<\/p>\n

Quando si crea un piano DR non \u00e8 possibile \"sdoppiare\" i dischi su diversi datastore. Questi si troveranno nello stesso datastore che \u00e8 stato definito per questa cloud client, e se hai dischi di classi diverse, ci\u00f2 pu\u00f2 causare alcuni problemi all'avvio della macchina, e dopo l'avvio e il \"distacco\" della VM da Hystax, richieder\u00e0 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\u00f9 grande da 100 GB con tre dischi, ci sono voluti al massimo 10 minuti.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDopo ci\u00f2, \u00e8 necessario controllare la VM avviata, i servizi su di essa, la coerenza dei dati e effettuare ulteriori verifiche.\u00a0<\/p>\n

Da qui abbiamo due percorsi:\u00a0<\/p>\n

    \n
  1. Elimina \u2013 rimuovi il piano DR avviato. Questa azione spegner\u00e0 semplicemente la VM avviata. I dati della replica non andranno da nessuna parte.\u00a0<\/li>\n
  2. Distacca \u2013 stacca la macchina replicata da Acura, cio\u00e8 termina effettivamente il processo di migrazione.\u00a0<\/li>\n<\/ol>\n

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