Cluster Hyper-V con failover – NETWORKING

Stiamo cercando di creare un cluster Hyper-V di 3 nodes con migrazione in diretta e failover utilizzando:

  • 3 x Dell R710 con dual quad core Xeon e 128 GB RAM e 6 NIC in ciascuno
  • 1 x Dell MD 3220i SAN

Verrà eseguito questa configuration da un centro dati e co-localizzeremo il nostro kit.

Può chiunque spiegare come dovremmo impostare le connessioni di networking per rendere il sistema ridondante?

Abbiamo esaminato questo grande articolo, ma non siamo sicuri di come get un setup di 3 server correttamente e in modo affidabile: http://faultbucket.ca/2011/01/hyper-v-failover-cluster-setup/ .

Credo che abbiamo bisogno di connessioni di networking per: migrazione dal vivo, battito cardiaco, gestione, hyper-v ecc.

Suppongo che stiamo eseguendo da un DC tutti i IP dovranno essere IP pubblici?

I server AD saranno VM. Uno su ciascun server Hyper-V e la configuration per non essere HA.

  • Fornire connessione Internet a macchine virtuali su Hyper-V
  • Generazioni Hyper-V 2012 R2
  • Come gestire Microsoft Hyper-V Server 2008 R2 da Windows XP / Server 2003?
  • Hardware RAID0 / 1 controller
  • Come utilizzare più server virtuali con un solo indirizzo IP pubblico?
  • È ansible aggiornare un disco di differenziazione genitore Hyper-V per spingere gli aggiornamenti a tutti i bambini?
  • Installazione del sistema ospite da DVD fisico Hyper-v 2012 R2 di CD / DVD
  • Gli ospiti Hyper-V: latenza intermittente
  • 5 Solutions collect form web for “Cluster Hyper-V con failover – NETWORKING”

    Ci sono stato! L'anno scorso ho installato un cluster simile (eccetto le mie scatole sono state Fujitsu) utilizzando una iSCSI SAN per Hyper V.

    In realtà non è così difficile, ma ci saranno trappole lungo la strada. Se stai colocando, vorrei certamente provare la tua installazione in un rack server nei tuoi locali prima di spostarlo nel datacentre (ho usato un armadio server insonorizzato per questo).

    Oh, un'altra cosa in preparazione, non lo dici, ma una cosa che non mi preoccuperei è l'avvio iSCSI che viene offerto in alcuni sisthemes iSCSI. È un dolore da impostare e non sempre funziona con la ridondanza. È sempre meglio disporre di uno o due dischi di avvio fisico nei nodes in modo che se si dispone di un problema di configuration di networking o di iSCSI, è comunque ansible eseguire l'avvio. Utilizzo di unità a stato solido (40 GB) in ciascuno dei miei server per i dischi di avvio.

    Avete sicuramente bisogno di una AD DC separata. Infatti ho iniziato con un cluster di 3 nodes e poi ho limitato questo a due nodes, più un nodo "cluster" incluso che esegue backup su DPM 2010 e su una DC virtualizzata.

    Parliamo di sei porti, questo può essere sufficiente. Ma permettimi di illustrare il mio configuration del nodo con 10 porte:

    • Avnetworking sempre bisogno di 2 porte per nodo per la networking iSCSI (ognuna di esse appartiene a una subnet diversa per la ridondanza MPIO e dovrebbe essere su NIC separate)
    • 1 port per il battito cardiaco che non ha nessun altro traffico su di esso
    • 1 port per la migrazione in diretta e trasferimenti (questo è l'unico che si potrebbe desiderare di aggiornare a 10g o infiniband, ma a less che non si fornisca 10s di VM al giorno non ne vale la pena)
    • 1 port per l'accesso remoto del desktop
    • 1 port per la scheda di gestione del server
    • 1 set di porte collegate che costituiscono la principale networking di accesso *
    • 1 set di porte di squadra che costituiscono una networking DMZ (opzionale) *

    * È spesso sottolineato dai detrattori che Microsoft non support ufficialmente il team di porto (mentre VMWare fa), ma la parola ufficiale è che non lo scoraggiano, ma semplicemente sento che il supporto è nelle mani dei fornitori di NIC. Utilizzo delle Intel NIC della generazione ET, che dispongono di funzionalità specifiche di networking virtuale e mi sembra di lavorare molto bene con Hyper V. In realtà ti consente di dividere una squadra tra gli switch in modo che se uno degli switch non riesce, hai un accesso coerente alle squadre , un po 'come MPIO ma per macchine virtuali.

    Hyper V è in realtà molto resistente e utile da usare. Vorrei avvicinarmi al tuo lavoro in questa sequenza: 1) Impostare individualmente i nodes, installare l'iniziatore iSCSI, installare MPIO, fornire le porte iSCSI, le porte di trasporto e di heatbeat, porti di gestione diversi indirizzi di substring.
    2) Impostare Hyper V e assegnare le porte selezionate alla networking virtuale 3) Eseguire quindi la procedura guidata di validation dei cluster e formare il cluster.

    Devi sempre assegnare porte alla networking virtuale innanzitutto, perché questo impedisce loro di essere utilizzati dal cluster. Questo suona intuitivo, ma fondamentalmente stai mantenendo la tua networking virtuale agnostica alla tua networking di cluster. Questo ti dà ancora ridondanza, quindi non ti preoccupare. Ma per raggiungere questo objective (e non c'è altro modo) dovrai disporre di un set separato di switch per il tuo cluster e l'iper V (due ciascuno per la riduzione) o dovrai impostare VLAN sugli switch. Io faccio quest'ultimo (usando VLANS intriggersto) e funziona ottimamente.

    Alcuni altri posti qui hanno suggerito di utilizzare un consulente per eseguire questo lavoro. Se hanno familiarità con Hyper V, questo può essere una buona idea. Non ti dà la conoscenza indepth che altrimenti avrebbe acquistato da fai da te, ma ti farà risparmiare tempo. Ho avuto un sacco di tempo l'anno scorso, e non mi dispiace ammettere che ci sono voluti diversi mesi di lavoro e figurare le cose per farlo funzionare.

    In bocca al lupo!

    Benvenuti in un mondo di dolore. Fai una mistkake che rovina la tua esperienza in un momento in cui sei in un mondo di dolore per non pensare alle cose.

    I server AD saranno VM. Uno su ciascun server Hyper-V e la configuration per non essere HA

    Pensate a quello che fai qui. Il clustering di Windows necessita di avviare l'AD, in quanto la configuration è in AD. Se per qualsiasi motivo il potere non riesce nel centro dati, quando viene eseguito il backup l'operatore non verrà avviato in quanto non sono disponibili server AD. Devi essere cauto al 100% con questo.

    Vi suggerisco fortemente di tenere una piccola macchina aggiuntiva (Atom basata se ha t obe) come agire come il controllo AD (cioè ruoli importnti) con un USV separato. Il clustering funziona bene, ma avere tutti i controller AD in VM richiede problemi.

    http://technet.microsoft.com/en-us/library/ff428137(WS.10).aspx

    ha la guida necessaria. Oltre a questo, consideri l'utilizzo di una networking di networking veloce. No, non 10g … troppo lento, troppo costoso. Ottenga un bel set di tabs Infiniband, un interruttore Infiniband e fai habppy con i trasferimenti FAST.

    La SAN può anche essere troppo piccola in IOPS. Se si parla di un carico del 100% su due macchine (una in riserva), questo è un LOTTO di VM. Devi assicurarsi che i tuoi budget IOPS siano in linea per questo. Ho problemi con un 6 10k Raptor Raid 10 su un singolo host da 64GB a volte – si esegue 4 volte il budget di memory, quindi mi aspetterei 4-6 volte le esigenze di IOPS (e non ho database, sono separati). Assicuratevi di sapere che il lato SAN è abbastanza buono.

    Sto leggendo della stessa configuration di networking e qui è brevemente quello che penso sia corretto. Correggi se mi sbaglio.

    • 2 (etherchannel / hp trunked) per la migrazione in diretta
    • 2 (etherchannel / hp trunked) per la normale connettività di networking
    • 2 per SAN, nessun etherchannel come server di Windows può fare MPIO

    Utilizzare due interruttori. Se non è ansible impilare, crea un tracciato etherchannel / hp tra di essi e utilizza (alless) tante porte per questo come è attivo per la tua SAN. porti per questo.

    • Sulle porte per la SAN, e sui SAN nICS sui server, triggersre i frame Jumbo e il controllo del stream. Questo dovrebbe anche essere impostato sui collegamenti inter-switch.
    • Le interruttori inter switch dovrebbero essere etherchannels / porte tronco hp, penso che entrambi i frame Jumbo e controllo di stream abilitato
    • Collegamenti di migrazione in diretta con etherchanneled (tronchi hp), frame jumbo e controllo del stream.

    Spegni il controllo di tempesta unicast sugli interruttori. Se ansible, utilizzare altri interruttori per la connettività di networking. Disabilita Spanning Tree-protocol.

    Per quanto riguarda la SAN 3220i, penso che abbia porte a 4 Gbit, due su ciascun controller. Penso che sia un passivo attivo, e se colbind ciascuno di each controller NIC ad un interruttore ciascuno.

    Hai dimenticato di specificare che dovresti separare la migrazione dal vivo e la SAN in VLAN differenti. Evitare la VLAN di default (1). Utilizzare buoni interruttori, i buffer (o qualcosa del genere) hanno un impatto piuttosto importnte sulle performance (quindi ho letto).

    hai guardato quanto segue

    http://technet.microsoft.com/en-us/library/ff428137(WS.10).aspx

    Trovo abbastanza difficile avvitare il cluster iper-v per andare per esso.

    Mentre il clustering di Windows richiede l'avvio di AD, è ansible farlo funzionare molto bene in ambienti totalmente virtualizzati a 2 nodes.

    Vorrei fare queste raccomandazioni che mi hanno servito bene sia per la nostra networking interna che per le nostre reti di clienti: – riserva spazio su disco sufficiente e I / O su ciascun nodo del cluster per eseguire una DC locale. In questo modo, il servizio cluster non ha mai cercato di trovare qualcosa da interrogare. – Impostare il servizio cluster su "Automatico (avvio in ritardo)". In questo modo, Hyper-V ha un po 'di tempo supplementare per iniziare prima del servizio del cluster.

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