Windows Server 2008 R2: Di rete nei cluster di Failover
Quando l'errore non è un'opzione, la configurazione dei cluster di failover in Windows Server è in grado di garantire un'elevata disponibilità.
John Marlin
Il modello di rete in Windows Server 2008 e Windows Server 2008 R2 Failover Clustering fornisce più solida e affidabile comunicazione tra tutti i nodi del cluster, che migliora notevolmente l'efficienza e l'affidabilità del clustering di failover. Esistono anche diverse nuove funzionalità, tra cui:
- Comunicazioni più affidabili utilizzando TCP e UDP unicast
- Supporto per IPv6
- Supporto per l'individuazione dei nodi del cluster su subnet separate, routing
- Più di controllare accuratamente il rilevamento degli errori di rete
È necessario utilizzare hardware di rete contrassegnati come "Certified for Windows Server 2008." Tutti gli altri componenti della soluzione di cluster di failover devono inoltre essere certificata allo stesso modo. Se si utilizzano dispositivi iSCSI, le schede di rete devono essere dedicato per una comunicazione di rete o iSCSI, non entrambi.
Durante la progettazione dell'infrastruttura di rete per connettere i nodi del cluster, è essenziale evitare singoli punti di errore. Esistono molti modi per eseguire questa operazione. È possibile connettere i nodi di cluster con più reti distinte. È inoltre Impossibile connettere i nodi del cluster con una rete con schede di rete in team, commutatori ridondanti, router ridondanti o componenti hardware simili che consentono di rimuovere singoli punti di errore. Questi requisiti dell'architettura differiscono dai cluster di server in Windows Server 2003 necessari due reti distinte.
Comunicazioni del cluster
Clustering di Failover di Windows Server 2008 ora utilizza una scheda di rete virtuale denominata scheda virtuale del Cluster di Failover Microsoft per la comunicazione tra i nodi del cluster. Sarà disponibile anche in questo in Gestione periferiche in schede di rete (selezionare Mostra periferiche nascoste). È inoltre visualizzato quando il comando IPCONFIG /ALL. Questa scheda di rete gestisce il routing dei pacchetti tutte le reti appropriate per la comunicazione, join e così via.
Questa scheda avranno un indirizzo APIPA definito nel blocco di indirizzi 169.254.0.0/16. In IPv6, in cui sono stati assegnati con la fe80::/ 10 prefisso. In alcuni ambienti, quando un indirizzo APIPA, dispongono di schede di tali schede sono disattivate. Se si disattiva la scheda virtuale del Cluster, si verrà disattivato la comunicazione tra i nodi.
L'obiettivo è sostenere la connettività TCP/IP tra due o più sistemi, nonostante il fallimento di qualsiasi componente del percorso di rete. Pertanto, deve esistere un percorso fisico alternativo. In altre parole, errore di un componente di rete (se è una scheda di rete, router, switch o hub) non dovrebbe provocare una ripartizione di comunicazione.
Comunicazione deve continuare in modo tempestivo. Potrebbe esserci una risposta più lenta ma comunicazione persisterà fino a quando non vi è un route fisiche alternativo o il collegamento. Questo veramente entra in gioco quando parla con i nodi in siti distinti o subnet.
Un'altra modifica nel Clustering di Failover di Windows Server 2008 è il meccanismo di heartbeat del cluster. Mentre utilizza ancora la porta 3343, esso ha eseguito la transizione da un meccanismo di controllo dello stato broadcast UDP una comunicazione di UDP unicast. È simile a un ping in quanto utilizza un processo di richiesta-risposta, ma include le funzionalità più sofisticate, ad esempio la protezione e la sequenza di numerazione.
Il comportamento predefinito è modificato in termini di risposte quanti sono necessari prima che il nodo è considerato non raggiungibile, l'avvio di un raggruppamento per ottenere una nuova visualizzazione di appartenenza del cluster. L'heartbeat cluster informare tutti i nodi che su e giù. Per impostazione predefinita, le impostazioni sono controllate da:
- SameSubnetDelay: frequenza di heartbeat per i nodi nella stessa subnet
- SameSubnetThreshold: soglia di ritardi per i nodi nella stessa subnet
- CrossSubnetDelay: frequenza di heartbeat per i nodi in subnet diverse
- CrossSubnetThreshold: soglia di ritardi per i nodi in subnet diverse
Queste impostazioni e il metodo per la loro modifica, vengono definite nel "Configurare Heartbeat e DNS impostazioni in un multisito Cluster di Failover" pagina TechNet Library. Non c'è un "heartbeat" inviate con un numero di sequenza, ad esempio da Nodo1, Nodo2. Nodo 2 risponde con lo stesso numero di sequenza. Node1 invia nuovamente lo stesso numero di sequenza Nodo2 e nodo 2 restituisce un'ultima volta.
Nodo 1 sarebbe quindi determinare questa sequenza di heartbeat completa e avviare nuovamente il processo con un altro numero di sequenza. Se una delle sequenze di heartbeat vengono eliminata o non ricevuta, si è ritenuto un heartbeat "persa". Per impostazione predefinita, se le cinque di queste sequenze non vengono eseguite, il nodo è considerato attivo o inattivo.
È possibile modificare queste impostazioni per aumentare il ritardo o la soglia, ma solo è possibile risolvere eventuali problemi di rete. Se esistono eventuali problemi di latenza di rete, si potrebbe ovviare, ma non risolve il problema. Pertanto, tenere presente che apportano modifiche alle impostazioni di ritardo o soglia non è considerata una tecnica di risoluzione dei problemi.
L'heartbeat, per impostazione predefinita, prevede di utilizzare IPv6, come se fosse un protocollo più veloce rispetto a IPv4. Se IPv6 è stata disattivata, verrà invece utilizzato IPv4. Un cluster di failover non mescolare e corrispondono a IPv6 e IPv4. Utilizzerà uno o l'altro, ma non entrambi contemporaneamente.
Creazione di cluster
Quando si crea un cluster in Windows Server 2008 e Windows Server 2008 R2, il driver di rete di cluster rileva e crea le reti in base al fatto che sia un gateway predefinito sulla scheda. Se viene rilevato un gateway predefinito, tale rete è impostata per consentire ai client di connettersi e utilizzarlo per le comunicazioni del cluster.
In questo modo, gli indirizzi IP del cluster e i punti di accesso client, i nomi di rete, utilizzano la rete. Fornisce inoltre è un valore metrico iniziando a 10.000. Se una rete non dispone di un gateway predefinito, si avrà un valore metrico iniziando a 1.000. Quindi verrà essere selezionata solo per le comunicazioni del Cluster. Ogni rete che rileva aumenta l'incremento di metrica per 100.
Una cosa sulle modalità di che funzionamento a questo punto è che non esiste il concetto più di una rete "pubblica" e "privata". Di conseguenza, la vecchia "configurazione"Heartbeat"privata su un Server di Cluster consigliata" articolo per Windows Server 2003 il servizio cluster non valido. Comunicazioni del cluster verranno comunque passare attraverso tutte le reti.
Nelle versioni precedenti, è definito rete a cui si desidera utilizzare per le comunicazioni del cluster. Fino a quando tale rete era disponibile, il cluster utilizzerà solo a tale rete. Windows Server 2008 e Windows Server 2008 R2 consente di utilizzare tutte le reti. Se si è verificato un problema con una rete, verrà automaticamente attivato tra le reti.
Non vi è una metrica interna che utilizza il driver di rete di Cluster. Non utilizza il valore di metrica TCPIP generale. È possibile visualizzare i valori di metrici con il seguente comando di Windows PowerShell:
Get-ClusterNetwork | Nome FT, metrica
I valori di metrici realmente entrano in gioco quando si parla di disporre di un cluster con macchine virtuali con disponibilità elevata (VM) e l'utilizzo dei volumi condivisi del Cluster.
Si supponga, ad esempio, che si desidera eseguire questo comando con queste reti configurate:
Name -------------------------------------------------- Rete di iSCSI |
Metrica -------------------------- 1000 |
Quando si utilizzano i volumi condivisi del Cluster, verrà utilizzata la rete di metriche di valore più bassa per tutto il traffico CSV o accesso in modalità di reindirizzamento. Quando si utilizza la funzione di migrazione diretta del clustering di failover, utilizzerà la metrica più bassa di secondo.
Nell'esempio, il traffico CSV passa attraverso la rete iSCSI e migrazioni live passerà attraverso la rete utilizzata per i backup. Durante lo scatto di una copia di backup delle macchine virtuali, i volumi condivisi del Cluster verranno registrati in un accesso in modalità di reindirizzamento. Questo prevede interferire con le connessioni ISCSI e può causare errori del disco. Un backup dei dati sul disco locale del nodo 1 e una migrazione a Live interferiscono tra loro.
È necessario riconfigurare le reti per ottenere tutto ciò che è necessario. Per la rete di migrazione Live, è possibile modificare questa impostazione far apparire le proprietà di una delle macchine virtuali. Nella scheda Live migrazione è possibile modificarlo in rete di Cluster LM. A tale scopo, è necessario eseguire questa operazione su una singola macchina virtuale poiché si tratta di un'impostazione globale per tutte le macchine virtuali.
Per la rete CSV, è possibile modificare solo questa modifica tramite Windows PowerShell. Per ordinare le reti da basso ad alto, è possibile utilizzare i seguenti comandi:
Get-ClusterNetwork "CSV Cluster" | %{$_.Metric=800} Get-ClusterNetwork "LM Cluster" | %{$_.Metric=900} Get-ClusterNetwork "Backup Network" | %{$_.Metric=1000} Get-ClusterNetwork "ISCSI Storage Network" | %{$_.Metric=1100}
Esecuzione del comando per visualizzare i criteri di misurazione dimostrare:
Name -------------------------------------------------- Rete di iSCSI |
Metrica ------------------------ 1100 |
La rete di cluster CSV è impostata per metrica 800. Aggiunta di qualsiasi nuova rete che non dispone di un gateway predefinito sarebbe superiore. Ora con metriche configurate correttamente, è possibile eseguire backup o eseguire operazioni live Migration macchine virtuali senza eventuali conflitti sulle reti.
L'ultima cosa da ricordare è la convalida dei cluster. È possibile eseguire alcuni test di convalida di rete per determinare i problemi di connettività, le configurazioni di rete e così via. È possibile eseguire questi test in qualsiasi momento senza influire sulla produzione.
Di seguito sono riportati i test di convalida del cluster:
- Configurazione del cluster
- Elenco informazioni reti Cluster
- Rete
- Elenco ordine di Binding rete
- Convalidare la configurazione di rete di Cluster
- Convalidare la configurazione IP
- Convalidare le proprietà di più Subnet
- Convalidare la comunicazione di rete
È possibile trovare i dettagli del test di convalida del Cluster sul "informazioni sui test di convalida del Cluster" pagina TechNet Library. Questo visualizzerà esattamente cosa cercare i test e non di quali ciascun test.
.jpg)
**John Marlin**è un senior support escalation engineer nel gruppo di supporto tecnico commerciale. Lavora con Microsoft da più di diciannove anni, con negli ultimi 14 anni nei Cluster di server di messa a fuoco.