Configurazione di adattatore di networking Hyper V sulla partizione padre

Ho letto su Hyper V e come gestisce il networking virtuale e penso di aver individuato un problema con un piccolo cluster che è stato messo insieme da me dalla nostra networking per ospitare una farm di SharePoint.

I server sono domande hanno due NICs – 1 da utilizzare per il traffico LAN standard e l'altro per la comunicazione con la memory SAN.

Su un'installazione predefinita quando il ruolo del Hyper V è abilitato e una networking virtuale viene creata per ciascuna NIC, quindi come lo capisco, è necessario accadere quanto segue:

  1. Creare un interruttore virtuale.
  2. Creare un vNIC con lo stesso nome del vSwitch.
  3. L'host si sbatte dalla NIC fisica e si lega al nuovo vNIC.

Il risultato è che il sistema operativo OS utilizza lo stesso path di networking virtuale che i VM dei bambini utilizzano e qualsiasi nuovo guest VM può creare propri vNIC contro il vSwitch appropriato.

Nel caso dei server che sto guardando vedo che in ognuna delle macchine host i vNIC sono stati non legati e la macchina è stata ricollegata alle NIC fisiche.

Tutto funziona bene per quanto posso dirlo. Il set-up è stato replicato in tutte le lame del cluster in modo che Live Migration ecc funziona bene.

Sono corretto nella mia comprensione del networking di Hyper V come ho brevemente riassunto sopra? (Se sbaglio puoi ignorare il resto del post …!)

In caso affermativo, date le modifiche apportte in questa configuration, esistono problemi potenziali che potrebbero verificarsi con le macchine host collegate alle NIC fisiche?

Abbiamo un problema intermittente con il congelamento dell'attività di networking su VM casuali a volte random – la soluzione è di riavviare la VM o di spostarla in un altro host. Un altro problema intermittente è per gli host di BSOD e riavviare occasionalmente – le discariche di crash sembrano indicare un problema all'interno di un driver di networking. Finora mi è stato detto che il problema è probabilmente solo driver o impostazioni del BIOS e diverse cose sono state tentate senza successo per fermare i problemi. Mi chiedo se i nostri problemi potrebbero essere collegati agli host che legano le NIC fisiche quando dovrebbero essere legati ai vNIC invece.

  • Trova account bloccati in Active Directory (un modo che effettivamente funziona!)
  • Come posso monitorare un pool di applicazioni IIS 7.5 con WMI?
  • Imansible connettersi a un dominio di Windows da una substring diversa
  • Contatori di performance in Perfmon / Server 2008 R2
  • Totale RAM% da perfmon Windows Server 2008 R2
  • Gli account utente locali sono scomparsi dopo l'installazione di Active Directory e l'esecuzione di dcpromo
  • Ripristina il disco di ripristino di Windows Server 2008 R2 SP1
  • Esport / printing tutti i ruoli e le funzioni
  • 2 Solutions collect form web for “Configurazione di adattatore di networking Hyper V sulla partizione padre”

    Per quanto riguarda i bsod, è necessario applicare i seguenti aggiornamenti rapidi (rilevanti per la tua situazione).

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

    Sei davvero in esecuzione con solo due NIC, sono 10 GB? se no, i tuoi cluster non vengono eseguiti in una configuration consigliata. È vero che passerà con gli avvertimenti il ​​test di validation cluster ma sarà less ottimale.

    Se hai davvero un nic per lm, csv, hb, vms, mgmt, allora hai configurato l'unico modo ansible e l'host deve condividere i nic con i vm.

    Un altro problema è stato questo cluster costruito con hyper-v installato allora sysprepped? Se è così allora si hanno collisioni mac.

    http://blogs.technet.com/b/jhoward/archive/2008/07/15/hyper-v-mac-address-allocation-and-apparent-network-issues-mac-collisions-can-cause.aspx

    Non. Lo stai facendo bene. In un team Hyper-V è ansible creare una vera networking di scheda con lo stesso nome a una networking virtuale in tutti i nodes. Dovresti farlo e questo è il suggerimento di Microsoft.

    Sebbene utilizzi le NIC per fare molte cose e che potrebbero genera i tuoi problemi. Tieni presente che utilizzare solo due tabs di networking per questo scenario non è l'opzione migliore e potrebbe avere un comportmento imprevisto.

    Sulla base delle raccomandazioni di Microsoft, in tutti i nodes Hyper-V occorrerebbe:

    1. Una NIC dedicata a macchine virtuali.
    2. Una NIC dedicata alla gestione, che significa essere utilizzata per l'host.
    3. Una NIC dedicata a iSCSI.
    4. Una NIC dedicata al battito cardiaco. Questo è il traffico interno del cluster.
    5. Se stai pianificando di utilizzare Live Migraton devi dedicare una NIC per questo.

    Prova ad avere tutti loro. Ricordi di rinominarli esattamente su tutti i nodes.

    Ricorda che Microsoft non support Teaming a NIC in cluster Hyper-V, che potrebbero generare errori. Ulteriori informazioni sono disponibili presso Microsoft KB 968703 .

    Leggi questo articolo sulle best practice di networking per sapere quali protocolli dovresti abilitare in quale NIC e sulla metrica. È altamente consigliato modificare la metrica in each interface.

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