Con un po' di ritardo (la preparazione del lancio assorbe molto tempo e risorse) rispondo alle domande che mi sono state poste durante il webcast della scorsa settimana dedicato al Failover Cluster di Windows Server 2008.

Come sono configurate le schede di rete dei due nodi del cluster?

Il cluster deve essere accessibile dai client della rete e i diversi nodi devono passarsi informazioni come per esempio il segnale di hearthbeat. E' quindi consigliabile avere almeno due schede di rete in ogni nodo del cluster che possono essere entrambe usate per tutti e due gli scopi (accesso dai client e segnale di hearthbeat). In molti casi è conveninete avere una scheda dedicata al segnala infracluster, una ad uso misto e una dedicata al solo accesso in amministrazione ai nodi del cluster.

In presenza di due schde di rete automaticamente una viene dedicata al segnale di herthbeat e l'altra per uso misto (hearthbeat e accesso dalla rete al cluster).

NetworkConfig-4  NetworkConfig-5

E' ancora obbligatorio che siano configurate su reti differenti per poterle usare in cluster?

Ho fatto un semplice test. Ho preso due macchine virtuali che uso per i test delle configurazioni cluster entrambe dotate di due schede di rete. Ho configurato le schede su CLS001 con i due IP 192.168.0.101/24 e 192.168.0.201/24 e le schede su CLS002 con gli IP 192.168.0.102/24 e 192.168.0.202/24 tutte e quattro connesse allo stesso switch virtuale.
Ho fatto quindi girare il tool di validazione della configurazione e il risultato lo vedete sotto:

NetworkConfig-0 
La configurazione ha superato i test ma con degli Warning.
Ci sono infatti degli warning:

NetworkConfig-1

NetworkConfig-2

NetworkConfig-3

Quindi sebbene, secondo il tool di validazione, possa funzionare, io sconsiglierei questa configurazione.

Ciò che posso fare via riga di comando posso farla via interfaccia grafica?

Direi proprio di si.

Qual'è il modello di majority utilizzato per default?

Dipende dalla configurazione di server e dischi (presenza di nodi multipli, di dischi condivisi, ecc...)

Creando un cluster di macchine virtuali risolvo il problema di dover per forza utilizzare HW identici, beneficiando di macchine virtuali identiche, che girano su HW diversi?

Se per cluster di macchine virtuali si intende la messa in cluster tra loro di VM in esecuzione su due server fisici diversi (perché separati e perché con configurazione diversa), senza necessità spostare le VM tra nodi diversi del è sicuramente una soluzione (devono però essere essere configurate in modo identico le due VM).
Questo scenario è però possibile solo se si clusterizzano applicazioni cluster aware e OS che supportano il cluster. La clustrizzazione di intere macchine virtuali mi svincola dal tipo di applicazioni installate al loro interno e dal sistema operativo.

Quando si parlà di riparabilità per i dischi si intede anche la perdita di signature?
Con windows 2003 poteva infatti capitare (esite anche una apposita patch fornita da microsoft) ed era necessario eseguire una procedura da linea di comando per ridare la signature. Con 2008 non è più necessario? Si autoripara anche in questi casi?

In Windows Server 2003 i dischi erano identificati unicamente attraverso la Disk signature.
In Windows Server 2008 i dischi sono identificati usando diversi attributi tra cui la Disk Signature e dati ricavati da SCSI Inquiry. In questo modo se un disco non può essere trovato usando un attributo, il servizio di clustering proverà a trovarlo usando un altro metodo. Se il servizio trova il disco procederà all'autoriparazione e aggiornerà i propri dati relativi ai dischi. In questo modo in Windows Server 2008 i dischi si autoriparano anche in caso di modifica della signature (che provoca in Windows Server 2003 la messa in off-line dei dischi) eliminando molte chiamate al supporto tecnico.

Si può creare un cluster di soli 2 nodi senza disco di quorum e senza storage condiviso?

E' possibile creare una configurazione di questo tipo usando come terzo "votante" uno share di rete (Node nad File Share Majority) che può risiedere su un server non appartenente al cluster e residente anche in una sede remota.

Quando si usa il modello di quorum Node and File Share Majority, come e' possibile che il Cluster Service possa accedere ad una share remota, se gira come Local System?

La share utilizzata come witness deve essere configurata in modo che sia consentito l'accesso in lettura e scrittura a tutti i computer account (computer$) del cluster:

NetworkConfig-6 NetworkConfig-7

Maggiori informazioni sulla crezione del file share qui.

Adesso non vi resta che sperimentare.

Giorgio