Vai al contenuto
EuroVPSEuroVPS

Cosa facciamo · Dati e web: Live migration e uscita dall'hypervisor

Lasciate un hypervisor proprietario o KVM standalone per il nostro private cloud OLVM. Le VM si spostano a caldo e ogni VM è verificata prima di muovere dati.
Pallet di server marcati FRAGILE tra gli armadi, 2005

Le macchine virtuali in esecuzione si spostano tra host senza fermarsi, e interi ambienti lasciano VMware o server KVM standalone per il nostro private cloud Oracle Linux Virtualization Manager (OLVM). A caldo quando è sicuro farlo a caldo, come copia a freddo verificata quando non lo è, e sempre con l'originale tenuto intatto finché il lato nuovo non è dimostrato.

Cos'è

Tre tipi di spostamento sotto un'unica disciplina:

  • Live migration: una macchina virtuale KVM in esecuzione, memoria e disco, spostata tra host con una pausa misurata in millisecondi. È così che facciamo la manutenzione degli host e la sostituzione dell'hardware senza programmare il vostro downtime.
  • Uscite dall'hypervisor: ambienti VMware e host KVM standalone spostati su OLVM, dove le VM si avviano da storage enterprise all-flash su fabric Fibre Channel ridondanti, con backup e monitoraggio dal primo giorno.
  • Trasferimenti di sito: interi ambienti ricollocati tra i nostri datacenter, conservando indirizzi e identità.

Come lo costruiamo

Una regola decisionale prima che si muova un solo byte. Se generazione della CPU, rete sottostante e release dell'hypervisor restano compatibili, la VM si sposta a caldo. Quando cambiano tutte insieme, non scommettiamo: la VM viene spenta, copiata, ridefinita e avviata a freddo sulla destinazione, e la sorgente resta intatta come rollback.

Live migration fatta come si deve. Usiamo il percorso di migrazione diretta di libvirt con copia dello storage e auto-converge, così anche le VM molto attive convergono. La destinazione viene preparata prima: storage pool, bridge e interfacce VLAN, e per layout di disco inusuali un'immagine pre-creata esattamente alla dimensione della sorgente.

Ricostruire lo stateless, replicare lo stateful. Per un'uscita preferiamo spesso una ricostruzione pulita da specifiche misurate dal vivo. I livelli web e applicativi vengono ricostruiti dalla configurazione; il database si sposta per replica, così il cutover è una promozione con pochi secondi di delta.

Un'appliance di migrazione costruita allo scopo. Le conversioni girano su un server di migrazione dedicato con storage all-flash NVMe e SSD, collegato direttamente al nostro fabric. Converte guest da altri hypervisor e trasmette le immagini disco KVM direttamente nei dischi creati dalla piattaforma di destinazione, conservando indirizzi MAC, modalità firmware e tipo di macchina, così la VM si avvia all'arrivo.

Verificata contro l'API, non contro gli appunti di build. Ogni VM viene controllata rispetto al virtualization manager stesso (topologia CPU, garanzie di memoria, interfacce di rete, route, dischi, hostname) prima che si muova qualsiasi dato. Le VM vengono dimensionate correttamente e non ricevono mai più vCPU di quanti core abbia un singolo socket CPU.

Windows gestito. Driver e guest tool vengono sistemati, gli strumenti del vecchio hypervisor rimossi solo quando il disco di avvio gira su VirtIO, e Active Directory e licenze controllati dopo lo spostamento.

Dry run, tempi concordati. Ogni conversione viene prima provata su una copia. Se uno spostamento potrebbe toccare il vostro traffico, concordiamo prima i tempi con voi.

Da cosa vi protegge

  • Downtime per manutenzione degli host, interventi sul firmware o sostituzione dell'hardware.
  • Cambiamenti di licenza da cui non avete via d'uscita.
  • Una migrazione che perde la sorgente prima che la destinazione funzioni.
  • Uno spostamento tra generazioni di CPU che rompe silenziosamente un guest.
  • VM che arrivano con la topologia sbagliata, un'interfaccia mancante o un indirizzo perso.
  • Rinumerare l'intero ambiente solo per cambiare piattaforma.

In pratica

Un load balancer spostato a caldo. La VM load balancer molto trafficata di un editore di news è stata migrata a caldo tra host, disco compreso, in 3 minuti e 5 secondi, con una pausa di circa 300 millisecondi.

Un'emittente nazionale lascia VMware. Abbiamo ricostruito la piattaforma web di un'emittente nazionale da VMware su OLVM come VM dimensionate correttamente, verificato ciascuna contro l'API e spostato il database per replica. Un server di sviluppo è passato dalla nostra appliance di migrazione ed era pronto all'avvio in circa sette minuti e mezzo. Il cutover si è concluso mesi fa.

Un host KVM standalone, importato. Il server KVM standalone di un cliente è stato importato in OLVM a circa nove GiB al minuto, con ogni indirizzo intatto, perché il dry run aveva già gestito la denominazione delle interfacce del nuovo chipset virtuale.

Un ambiente VDI spostato tra paesi. Un ambiente di desktop virtuali si è spostato da Amsterdam ad Atene. Abbiamo portato intera la sua subnet di gestione sulla nostra estensione Layer 2, così ogni pool di desktop e ogni entitlement sono passati invariati, e ogni domain controller è stato verificato in salute dopo.

Perché EuroVPS

  • Una regola scritta per a caldo contro a freddo, applicata ogni volta.
  • La sorgente tenuta come rollback finché la destinazione non è dimostrata.
  • Un'appliance di migrazione dedicata, non un portatile e un fine settimana.
  • Estensione Layer 2 tra i nostri siti, così vi spostate senza rinumerare.
  • Ogni VM verificata contro l'API prima che si muovano dati.

Domande frequenti

  1. Potete spostare le nostre VM senza ricostruirle? Sì, per conversione, con driver e tool sostituiti in un ordine testato. Conserviamo gli originali finché non date il via libera.
  2. Le nostre VM conserveranno gli indirizzi IP? Possono. Con l'estensione Layer 2, i server conservano i loro indirizzi e si spostano uno alla volta.
  3. Per quanto tempo una live migration mette in pausa la VM? Tipicamente una frazione di secondo al momento dello switchover. Gli spostamenti a freddo vanno in una finestra concordata con voi.
  4. E se qualcosa va storto a metà spostamento? La sorgente è invariata. Torniamo indietro, scopriamo il perché e riproviamo.
  5. Che cos'è OLVM? Oracle Linux Virtualization Manager, gestione enterprise per KVM standard. Nessun lock-in proprietario.

State lasciando VMware? Parla con un ingegnere.

Il vostro prossimo partner per l'infrastruttura

Guardiamo la vostra infrastruttura.

Raccontateci cosa fate girare oggi e cosa deve migliorare. Un ingegnere esaminerà la vostra richiesta e vi aiuterà a pianificare il passo successivo.

+357 222 32280
Un ingegnere EuroVPS trasporta un nodo server nella sala del datacenter
Una conversazione con le persone che si prenderanno cura della vostra infrastruttura.

Partiamo dalla vostra infrastruttura.

Un po' di contesto ci aiuta a iniziare la conversazione giusta.

Useremo i vostri dati per rispondere alla vostra richiesta. Informativa sulla privacy