none
Live migration / failover PDC in replica RRS feed

  • Domanda

  • Ciao a tutti,

    ho due host Hyper-V 2016 e 2019, G9 e G10, ciascuno con il proprio storage indipendente.

    G10 ospita 2 Windows Server 2019, SRV13 e SRV17, entrambi PDC, DNS ed entrambi in replica su G9 (quindi ovviamente entrambi versione 8.0).

    Sia G9 che G10 fanno parte del dominio che risiede su SRV13 e SRV17.

    Per fare manutenzione all'host G10 senza interruzioni troppo lunghe per gli utenti ho provato a fare un failover pianificato di SRV13 ma al momento di invertire il senso di replica la procedura va in errore con event id 32082, 29230, 32068 ed infine 21118 dicendo che non riesce a connettersi a G10.

    Premetto che poco tempo fa ho dovuto forzatamente spostare SRV17 su G9 per un problema successo con gli snapshot e ha funzionato senza problemi.

    I due host hanno come DNS SRV17 come primario e SRV13 come secondario e ovviamente raggiungono e risolvono perfettamente i nomi.

    Avendo avuto un ambiente di test avrei fatto altre prove come la live migration ma purtroppo essendo in ambiente di produzione avevo già perso troppo tempo con queste operazioni e ho dovuto abbandonare.

    Chiedo quindi se qualcuno ha una configurazione simile e/o ha mai provato la live migration del PDC o può darmi qualche consiglio.Grazie

    venerdì 25 giugno 2021 13:42

Risposte

  • la configurazione è errata, in un dominio windows nei dns non deve esserci un indirizzo ip esterno al dominio (8.8.8.8) ed è preferibile non avere neppure l'indirizzo di loopback ::1 (127.0.0.1):

    per SRV17 devi avere

    Indirizzo IPv4. . . . . . . . . . . . : 10.100.34.14(Preferenziale)

    Server DNS . . . . . . . . . . . . .  : 10.100.34.13
                                               10.100.34.14

    per SRV13 devi avere

    Indirizzo IPv4. . . . . . . . . . . . : 10.100.34.13(Preferenziale)

    Server DNS . . . . . . . . . . . . .  : 10.100.34.14
                                               10.100.34.13

    per G10 devi avere

    Indirizzo IPv4. . . . . . . . . . . . : 10.100.51.14(Preferenziale)

    Server DNS . . . . . . . . . . . . .  : 10.100.34.13
                                               10.100.34.14

    per G9 devi avere

    Indirizzo IPv4. . . . . . . . . . . . : 10.100.34.13(Preferenziale)

    Server DNS . . . . . . . . . . . . .  : 10.100.34.13
                                               10.100.34.14

    quando SRV13 è down per i pochi istanti della live migration, tutte le macchine dovrebbero indirizzare le richieste di risoluzione al dns secondario ossia SRV17



    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com

    giovedì 1 luglio 2021 10:22
    Moderatore
  • Grazie Edoardo per il tuo suggerimento, il problema però non l'ho avuto con la live migration ma con il failover pianificato della replica ... tra l'altro chiedevo appunto se le due cose possono convivere (replica e live migration)

    Però, scusami, il terzo DNS non dovrebbe venire interrogato SOLO se non rispondono gli altri due?

    per la prima domanda: non ha senso far convivere le due soluzioni, la live migration è preferibile visto che la vm migra "a caldo" da un hyper-v all'altro.

    leggi questa discussione

    https://community.spiceworks.com/topic/2170634-hyper-v-live-migration-or-replica-failover

    per la seconda domanda la risposta è: tutte le macchine di dominio, per far funzionare correttamente l'infrastruttura di active directory, devono avere come dns solo i domain controller altrimenti ci sono malfunzionamenti.


    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com

    giovedì 1 luglio 2021 15:49
    Moderatore

Tutte le risposte

  • Ciao,

    Grazie per aver postato sul nostro forum!

    In base alla tua descrizione, ho ancora un po' di confusione riguardo al tuo ambiente, quindi vorrei prima controllare qualcosa:

    1) "Per fare manutenzione all'host G10 senza interruzioni lunghe utenti ho provato a fare un failover pianificato di SRV13 ma il senso di replica la procedura va in con event id 32082, 29230, 32068 ed infine 21118 dicendo che non ammettere a G10."

    ——Qual era la destinazione su cui desideri eseguire il failover? Da quanto ho capito, G10 è l'host su cui replichi G9 e ora provi a condurre una replica inversa da G10 a G9 e avvii anche un piano di failover pianificato su G9?

    2) Premetto che poco tempo fa ho dovuto forzatamente spostare SRV17 su G9 per un problema successo con gli snapshot e ha funzionato senza problemi.

    ——Puoi dirmi qualcosa di più su queste informazioni?

    3) Cosa intendi per migrazione live PDC? Se ho capito bene, puoi spostare manualmente il tuo SRV17 su G9, ma non puoi vivere la migrazione PDC?

    In base agli ID evento che hai offerto, penso che tu possa prima condurre una risoluzione dei problemi per la rete Hyper-V:

    https://social.technet.microsoft.com/wiki/contents/articles/22181.hyper-v-troubleshooting-event-ids-14050-and-32068-reverse-replication-failed.aspx

    Infine, suppongo che potresti voler ottenere la tua soluzione alternativa in breve tempo. In questo senso, ti suggerirei di contattare il supporto e i servizi clienti Microsoft dove è possibile eseguire rapidamente un'indagine più approfondita in modo da ottenere presto una spiegazione e una soluzione più soddisfacenti a questo problema. Inoltre, se il problema è stato dimostrato come un difetto del sistema, il costo della consulenza verrà rimborsato. Puoi trovare il numero di telefono della tua regione di conseguenza dal link sottostante.
    Numeri di telefono del servizio clienti globale:

    https://support.microsoft.com/en-us/help/13948/global-customer-service-phone-numbers

    Grazie per il vostro supporto e comprensione!

    BR,
    Joan

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    lunedì 28 giugno 2021 06:31
  • sei sicuro degli event id che hai scritto?

    puoi riportarli nuovamente ?

    inoltre il dc che detiene i ruoli fsmo è SRV17, giusto ?

    puoi postare anche il risultato di un ipconfig /all dei due DC SAV17 e SRV13 ed anche dei due host hyper-v G9 e G10 ?


    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com


    lunedì 28 giugno 2021 08:23
    Moderatore
  • Ciao,

    Vorrei verificare se le risposte in questo blog potrebbero essere di aiuto? Se sì, aiuta **accetta la risposta**, in modo che altri incontrino un problema simile possano trovare rapidamente informazioni utili. Se hai altri dubbi o domande, non esitare a inviare un feedback. Il tuo supporto è davvero importante per il nostro lavoro.

    I migliori saluti,
    Joan

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    giovedì 1 luglio 2021 03:16
  • Ciao e grazie mille per le celerissime risposte! Anche se io purtroppo ho avuto dei problemi e non sono riuscito a vederle prima di stamattina, dalle vostre considerazioni tra l'altro temo di avere la conferma che il problema sia proprio il fatto che SRV13 è fsmo.

    1. G10 primario, G9 failover. I test del failover pianificato funzionano (ma in quel frangente SRV13 è acceso!)

    2. ho dovuto spostare SRV17 con un failover NON pianificato, anche se in questo caso avevo rimosso la replica visto che il problema era che non faceva più il merge degli hrl e continuava a mangiarmi spazio su disco, ma SRV13 era acceso!

    3. intendo dire che, oltre alla replica, Hyper-V consente di usare la "live migration" ma non l'ho mai provata in pratica, anche se leggendo in internet temo di aver compreso che le due cose non possano convivere e cioè che non si possa fare una live migration di una vm in replica, e volevo conferma di questo.

    Dopo questa esperienza e queste considerazioni però capisco che il mio sistema in questo modo non può funzionare : se quando SRV13 che è fsmo non è raggiungibile l'host di replica non può farlo ripartire a che serve che sia in replica? Provo a rispiegare, se G10 morisse per un errore hardware io non riuscirei a far ripartire il mio dominio (dalle vm in replica su G9) perchè non c'è un fsmo disponibile ... giusto?

    Grazie

    giovedì 1 luglio 2021 09:06

  • Dopo questa esperienza e queste considerazioni però capisco che il mio sistema in questo modo non può funzionare : se quando SRV13 che è fsmo non è raggiungibile l'host di replica non può farlo ripartire a che serve che sia in replica? Provo a rispiegare, se G10 morisse per un errore hardware io non riuscirei a far ripartire il mio dominio (dalle vm in replica su G9) perchè non c'è un fsmo disponibile ... giusto?

    Grazie

    ti ripeto la richiesta:

    puoi postare anche il risultato di un ipconfig /all dei due DC SAV17 e SRV13 ed anche dei due host hyper-v G9 e G10 ?


    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com

    giovedì 1 luglio 2021 09:17
    Moderatore
  • Ciao,

    capisco e condivido il tuo scetticismo a proposito degli errori, che forse ho dimenticato di specificare che si generano su G9, perchè effettivamente cercandoli in internet si riferiscono ad altro (tra cui la protezione degli host sorvegliati), tra l'altro ho dimenticato di citare l'id 29262 che è quello di errore di risoluzione del nome dell'host primario G10.

    Come dicevo nell'altra risposta fsmo è SRV13 ... e temo che il problema sia proprio questo, ma a questo punto mi chiedo come fare per proteggerlo da eventuali disastri ... non vorrei andare fuori tema ma sto pensando a soluzioni alternative come la replica di veeam (che possiedo), anche se preferirei far funzionare la parte integrata in Windows (e cioè Hyper-V)

    Grazie

    giovedì 1 luglio 2021 09:28
  • come ho scritto poco fa vorrei vedere la configurazione ip di queste macchine perchè se gli ip dei dns sono messi in maniera corretta tutto dovrebbe funzionare anche se la live migration la fa il dc che detiene i ruoli fsmo.

    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com

    giovedì 1 luglio 2021 09:53
    Moderatore
  • Configurazione IP di Windows

       Nome host . . . . . . . . . . . . . . : SRVEURO17
       Suffisso DNS primario . . . . . . . . : euronord.local
       Tipo nodo . . . . . . . . . . . . . . : Ibrido
       Routing IP abilitato. . . . . . . . . : No
       Proxy WINS abilitato . . . . . . . .  : No
       Elenco di ricerca suffissi DNS. . . . : euronord.local

    Scheda Ethernet Ethernet:

       Suffisso DNS specifico per connessione:
       Descrizione . . . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
       Indirizzo fisico. . . . . . . . . . . : 00-15-5D-21-19-06
       DHCP abilitato. . . . . . . . . . . . : No
       Configurazione automatica abilitata   : Sì
       Indirizzo IPv6 locale rispetto al collegamento . : fe80::742f:98d8:bd89:ef5d%14(Preferenziale)
       Indirizzo IPv4. . . . . . . . . . . . : 10.100.34.14(Preferenziale)
       Subnet mask . . . . . . . . . . . . . : 255.255.0.0
       Gateway predefinito . . . . . . . . . : 10.100.0.254
       IAID DHCPv6 . . . . . . . . . . . : 83891549
       DUID Client DHCPv6. . . . . . . . : 00-01-00-01-25-21-51-E0-00-15-5D-21-19-06
       Server DNS . . . . . . . . . . . . .  : ::1
                                               10.100.34.13
                                               10.100.34.14
                                               8.8.8.8
       NetBIOS su TCP/IP . . . . . . . . . . : Attivato


    Configurazione IP di Windows

       Nome host . . . . . . . . . . . . . . : SRVEURO13
       Suffisso DNS primario . . . . . . . . : euronord.local
       Tipo nodo . . . . . . . . . . . . . . : Misto
       Routing IP abilitato. . . . . . . . . : No
       Proxy WINS abilitato . . . . . . . .  : No
       Elenco di ricerca suffissi DNS. . . . : euronord.local

    Scheda Ethernet Ethernet:

       Suffisso DNS specifico per connessione:
       Descrizione . . . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
       Indirizzo fisico. . . . . . . . . . . : 00-15-5D-21-19-03
       DHCP abilitato. . . . . . . . . . . . : No
       Configurazione automatica abilitata   : Sì
       Indirizzo IPv6 locale rispetto al collegamento . : fe80::1876:5e41:8f4d:e4eb%8(Preferenziale)
       Indirizzo IPv4. . . . . . . . . . . . : 10.100.34.13(Preferenziale)
       Subnet mask . . . . . . . . . . . . . : 255.255.0.0
       Gateway predefinito . . . . . . . . . : 10.100.0.254
       IAID DHCPv6 . . . . . . . . . . . : 83891549
       DUID Client DHCPv6. . . . . . . . : 00-01-00-01-25-0B-C1-75-00-15-5D-21-19-03
       Server DNS . . . . . . . . . . . . .  : ::1
                                               10.100.34.14
                                               10.100.34.13
                                               8.8.8.8
       NetBIOS su TCP/IP . . . . . . . . . . : Attivato

    Configurazione IP di Windows

       Nome host . . . . . . . . . . . . . . : ML350G10
       Suffisso DNS primario . . . . . . . . : euronord.local
       Tipo nodo . . . . . . . . . . . . . . : Misto
       Routing IP abilitato. . . . . . . . . : No
       Proxy WINS abilitato . . . . . . . .  : No
       Elenco di ricerca suffissi DNS. . . . : euronord.local

    Scheda Ethernet vEthernet (RETE ESTERNA):

       Suffisso DNS specifico per connessione: euronord.local
       Descrizione . . . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
       Indirizzo fisico. . . . . . . . . . . : 08-F1-EA-69-F1-8D
       DHCP abilitato. . . . . . . . . . . . : No
       Configurazione automatica abilitata   : Sì
       Indirizzo IPv6 locale rispetto al collegamento . : fe80::a806:130b:2cb1:8603%7(Preferenziale)
       Indirizzo IPv4. . . . . . . . . . . . : 10.100.51.4(Preferenziale)
       Subnet mask . . . . . . . . . . . . . : 255.255.0.0
       Gateway predefinito . . . . . . . . . : 10.100.0.254
       IAID DHCPv6 . . . . . . . . . . . : 302576106
       DUID Client DHCPv6. . . . . . . . : 00-01-00-01-25-00-F5-34-08-F1-EA-69-F1-8D
       Server DNS . . . . . . . . . . . . .  : 10.100.34.14
                                               10.100.34.13
                                               8.8.8.8
       NetBIOS su TCP/IP . . . . . . . . . . : Attivato


    Configurazione IP di Windows

       Nome host . . . . . . . . . . . . . . : ML350G9
       Suffisso DNS primario . . . . . . . . : euronord.local
       Tipo nodo . . . . . . . . . . . . . . : Ibrido
       Routing IP abilitato. . . . . . . . . : No
       Proxy WINS abilitato . . . . . . . .  : No
       Elenco di ricerca suffissi DNS. . . . : euronord.local

    Scheda Ethernet vEthernet (RETE ESTERNA):

       Suffisso DNS specifico per connessione:
       Descrizione . . . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
       Indirizzo fisico. . . . . . . . . . . : 98-F2-B3-ED-B9-BD
       DHCP abilitato. . . . . . . . . . . . : No
       Configurazione automatica abilitata   : Sì
       Indirizzo IPv6 locale rispetto al collegamento . : fe80::3ce7:df62:5c58:319d%10(Preferenziale)
       Indirizzo IPv4. . . . . . . . . . . . : 10.100.51.3(Preferenziale)
       Subnet mask . . . . . . . . . . . . . : 255.255.0.0
       Gateway predefinito . . . . . . . . . : 10.100.0.254
       IAID DHCPv6 . . . . . . . . . . . : 328790707
       DUID Client DHCPv6. . . . . . . . : 00-01-00-01-25-83-EE-C4-98-F2-B3-ED-B9-BA
       Server DNS . . . . . . . . . . . . .  : 10.100.34.14
                                               10.100.34.13
                                               8.8.8.8
       NetBIOS su TCP/IP . . . . . . . . . . : Attivato

    Scheda Tunnel isatap.{E0DB774D-577B-4787-B775-A3EE827A45F5}:

       Stato supporto. . . . . . . . . . . . : Supporto disconnesso
       Suffisso DNS specifico per connessione:
       Descrizione . . . . . . . . . . . . . : Microsoft ISATAP Adapter #3
       Indirizzo fisico. . . . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP abilitato. . . . . . . . . . . . : No
       Configurazione automatica abilitata   : Sì

    giovedì 1 luglio 2021 10:00
  • la configurazione è errata, in un dominio windows nei dns non deve esserci un indirizzo ip esterno al dominio (8.8.8.8) ed è preferibile non avere neppure l'indirizzo di loopback ::1 (127.0.0.1):

    per SRV17 devi avere

    Indirizzo IPv4. . . . . . . . . . . . : 10.100.34.14(Preferenziale)

    Server DNS . . . . . . . . . . . . .  : 10.100.34.13
                                               10.100.34.14

    per SRV13 devi avere

    Indirizzo IPv4. . . . . . . . . . . . : 10.100.34.13(Preferenziale)

    Server DNS . . . . . . . . . . . . .  : 10.100.34.14
                                               10.100.34.13

    per G10 devi avere

    Indirizzo IPv4. . . . . . . . . . . . : 10.100.51.14(Preferenziale)

    Server DNS . . . . . . . . . . . . .  : 10.100.34.13
                                               10.100.34.14

    per G9 devi avere

    Indirizzo IPv4. . . . . . . . . . . . : 10.100.34.13(Preferenziale)

    Server DNS . . . . . . . . . . . . .  : 10.100.34.13
                                               10.100.34.14

    quando SRV13 è down per i pochi istanti della live migration, tutte le macchine dovrebbero indirizzare le richieste di risoluzione al dns secondario ossia SRV17



    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com

    giovedì 1 luglio 2021 10:22
    Moderatore
  • Grazie Edoardo per il tuo suggerimento, il problema però non l'ho avuto con la live migration ma con il failover pianificato della replica ... tra l'altro chiedevo appunto se le due cose possono convivere (replica e live migration)

    Però, scusami, il terzo DNS non dovrebbe venire interrogato SOLO se non rispondono gli altri due?

    giovedì 1 luglio 2021 14:10
  • Ti allego screenshot di srv13 e di g10 in questo ordine e ti chiedo :

    per eliminare il loopback devo rimuovere la spunta da "registra nel DNS gli indirizzi di questa connessione", giusto?

    Inoltre è normale che nel DC e quindi SRV13 e quindi il primo screen, non sia esplicito il "Suffisso DNS per la connessione" mentre nell'host lo sia?

    SRVEURO13ml350g10

    giovedì 1 luglio 2021 14:30
  • Grazie Edoardo per il tuo suggerimento, il problema però non l'ho avuto con la live migration ma con il failover pianificato della replica ... tra l'altro chiedevo appunto se le due cose possono convivere (replica e live migration)

    Però, scusami, il terzo DNS non dovrebbe venire interrogato SOLO se non rispondono gli altri due?

    per la prima domanda: non ha senso far convivere le due soluzioni, la live migration è preferibile visto che la vm migra "a caldo" da un hyper-v all'altro.

    leggi questa discussione

    https://community.spiceworks.com/topic/2170634-hyper-v-live-migration-or-replica-failover

    per la seconda domanda la risposta è: tutte le macchine di dominio, per far funzionare correttamente l'infrastruttura di active directory, devono avere come dns solo i domain controller altrimenti ci sono malfunzionamenti.


    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com

    giovedì 1 luglio 2021 15:49
    Moderatore
  • l'indirizzo di loopbak non si elimina da qui ma dalla gestione del DNS andando a dire che il DNS deve stare in ascolto solo sull'ip configurato in scheda di rete e non su tutti gli ip.

    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com

    giovedì 1 luglio 2021 15:51
    Moderatore
  • Capisco ma la replica mi garantisce (ovviamente sulla carta, visto che in pratica non ha funzionato anche se probabilmente per colpa della configurazione errata) di avere un clone della vm ogni 15 minuti, quindi facendo un esempio se alle 17 di oggi il mio host G10 dovesse smettere di funzionare io (anzi l'azienda) avrei perso al massimo 15 minuti di lavoro, nell'altro caso dovrei ripristinare il backup della notte precedente e quindi almeno 18 ore di lavoro!

    ...dimentico qualcosa?

    Ciao e grazie

    venerdì 2 luglio 2021 13:09
  • l'indirizzo di loopbak non si elimina da qui ma dalla gestione del DNS andando a dire che il DNS deve stare in ascolto solo sull'ip configurato in scheda di rete e non su tutti gli ip.

    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com

    ok grazie, quindi dovrebbe essere configurato così?

    ne approfitto per chiederti se a tuo avviso sarebbe meglio eliminare anche questi

    ciao e grazie

    venerdì 2 luglio 2021 13:44
  • perfetto.

    si, i server di inoltro li puoi eliminare perchè il dns usa già nativamente i root hints


    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com

    venerdì 2 luglio 2021 14:50
    Moderatore
  • l'indirizzo di loopbak non si elimina da qui ma dalla gestione del DNS andando a dire che il DNS deve stare in ascolto solo sull'ip configurato in scheda di rete e non su tutti gli ip.


    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com

    ok grazie, quindi dovrebbe essere configurato così?

    ne approfitto per chiederti se a tuo avviso sarebbe meglio eliminare anche questi

    ciao e grazie

    ciao Edoardo, nonostante la modifica fatta come nello screenshot del post precedente, ipconfig mostra ancora il loopback come primo server DNS, sia su srv13 che su srv17 ... puoi aiutarmi?

       Server DNS . . . . . . . . . . . . .  : ::1
                                               10.100.34.14
                                               10.100.34.13
    lunedì 5 luglio 2021 12:43
  • posta la foto della configurazione della scheda di rete sia di ipv4 sia di ipv6

    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com

    lunedì 5 luglio 2021 12:54
    Moderatore
  • posta la foto della configurazione della scheda di rete sia di ipv4 sia di ipv6

    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com

    ottimo, grazie, credo di aver capito che il problema sta proprio nella configurazione dell'ipv6 ... che a proposito non uso (se non involontariamente) e non cononsco ... quindi non ho nemmeno configurato (la mia rete è composta da una ventina di client...) e mi sono sempre chiesto se valesse la pena tenerlo attivo / se ci sono problemi noti nel disattivarlo ma non l'ho mai considerato un problema.

    Visto ora sono sull'argomento credo sia giusto approfondire, intanto chiedo una tua opinione, grazie.

    lunedì 5 luglio 2021 14:41
  • io lo tengo disattivato soprattutto per individuare eventuali problemi nella rete.

    non ci sono controindicazioni


    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com

    martedì 6 luglio 2021 06:52
    Moderatore
  • Ciao,

    oggi ho avuto occasione di ripetere un tentativo di spostare una delle due vm guest (srv17 che non è fsmo) ma ancora una volta non ci sono riuscito, quindi il problema non era relativo ai dns.

    Ancora eventi 29230 (impossibile connettersi al server di replica) e 32068 (impossibile abilitare la replica inversa) sull'host secondario e in seguito (provando comunque ad avviare la vm) 21118 (non è possibile rimuovere il wrapping della protezione con chiave) che però ho notato rimanda al registro eventi HostGuardianService-Client ... che però non ho installato come ruolo e quindi ovviamente nemmeno configurato!! Possibile che sia un prerequisito?

    Ciao e grazie


    Giacomo Venza

    giovedì 4 novembre 2021 14:36
  • ti sfugge il concetto di live migration. 

    leggiti questo documento

    https://docs.microsoft.com/it-it/windows-server/virtualization/hyper-v/manage/live-migration-overview

    con la replica perdi 15 minuti di lavoro, con la live migration e il cluster di failover non hai nessun downtime


    Edoardo Benussi
    e[dot]benussi[at]gmx[dot]com

    giovedì 4 novembre 2021 15:10
    Moderatore
  • Può darsi, ma con la live migration in caso di guasto hardware dell'host principale perdo tutti i dati fino all'ultimo backup eseguito, mentre con la replica perdo al massimo 15 minuti di lavoro, non avendo storage condiviso.


    Giacomo Venza

    giovedì 4 novembre 2021 15:14