Lo specchio "live" del cluster HA VM?

Sto leggendo delle tecniche HA nella virtualizzazione, ma tutte le soluzioni che vedo funzionano più o less come VRRP più specializzate – quando l'host scende, VM viene avviato su un altro host di virtualizzazione. Se lo spazio di archiviazione è condiviso (ad es. ISCSI), è ansible avviare lo stesso "VM" in modo da ospite ospite sembra un tipo di guasto di corrente. Ma se ci sono alcuni dati importnti che risiedono nella RAM (ad esempio in database di memory), allora è persa.

Sarebbe comunque ansible creare un'istantanea di esecuzione di VM con un certo intervallo (purtroppo richiede molto tempo per creare tale snapshot in modo da non essere realmente eseguito each lascia dire 10 secondi). Poi un altro host di virtualizzazione potrebbe caricare tale snapshot e continuare a eseguire VM "senza interruzione" (più less tempo intervallo).

  • Cluster di failover a due nodes con archiviazione interna
  • Windows 2008 ignora le richieste ARP gratuite
  • Balancers di carico ridondanti per i server Web basati su Windows?
  • Configurazione del DNS secondario per funzionare se Primario è in discesa (Bind)
  • Disponibilità elevata del server per una piccola impresa
  • Centri dati multipli e traffico HTTP: DNS Round Robin è l'unico modo per assicurare il fallimento immediato?
  • Quindi la mia domanda è – ci sono delle soluzioni automaticamente "mirroring" VMs in modo tale che dopo l'errore di virtualizzazione host VM può essere "ripreso" su un altro host senza interruzione notevole? Letteralmente come RAID1 di VM. Specchio completamente sincronizzato sul livello RAM.

    5 Solutions collect form web for “Lo specchio "live" del cluster HA VM?”

    I server non dovrebbero "solo fallire" nel modo che stai descrivendo. La maggior parte delle persone non si preoccupa di questo.

    Tuttavia, questo è un caso di utilizzo per VMware Fault Tolerance (FT) .

    Questo farà quello che stai chiedendo.

    Se si desidera una replica asynchronous con un piccolo ritardo ( come 10 secondi ), allora una soluzione come Zerto sarebbe apt.

    1) Distribuire un cluster VServer VMware e utilizzare le funzionalità https://www.vmware.com/files/pdf/techpaper/VMware-vSphere6-FT-arch-perf.pdf per la tolleranza agli errori nelle macchine virtuali (come già indicato in precedenza).

    2) Distribuire un cluster XenServer e utilizzare Remus https://wiki.xenproject.org/wiki/Remus .

    Ci sono alcune soluzioni che possono eseguire failover VM senza alcun tempo di inattività. Alless so di HPE VSA e Starwinds . Hanno anche versioni libere, in modo da poter guardare quelle.

    Tuttavia, non so esattamente il primo, non lo è ancora testato da me. Circa il secondo – c'è un'opzione in cui è ansible assegnare una quantità di RAM sul dispositivo HA e questa RAM viene replicata anche in un altro nodo. E il failover dei VM senza riavviare. Testato con cluster Hyper-V.

    Purtroppo no, non c'è modo di farlo e in realtà non ne ha bisogno affatto. Anche i database in memory possono fare il mirroring e l'HA sul livello di applicazione, non c'è bisogno di mirroring di memory in questo modo. Basta avviare più istanze del database in memory e lasciare che il mirroring inizia! È tollerante ai guasti e puoi anche effettuare aggiornamenti e manutenzione senza interruzioni.

    Purtroppo la risposta è no , alless per ipervisori commerciali / aziendali.

    Ok, sono corretto: non ho mai usato / letto di Xen + Remus , e mi sembra abbastanza interessante.

    So di VMWare FT, ma ha grandi limitazioni che ho scartato automaticamente. Fortunatamente, alcune di queste restrizioni sono state rimosse con l'ultima versione VMWare. Tuttavia, nello scenario di collegamento in networking o in I / O, l'impatto della prestazione cruda sarebbe semplicemente troppo grande per tollerare.

    Comunque, da quello che posso leggere, entrambi sono basati sul concetto di checkpoint : in pratica, la VM sottostante è continuamente migrata in diretta. Il vero block di block / mirroring è molto più costoso: alcuni anni fa un progetto basato su Qemu / KVM ha provato questa stessa cosa – ed è stato abbandonato a causa dell'enorme degradazione delle performance che ha comandato.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.