Articles avec le tag ‘failover clustering’
Failover Clustering et CSV
Intro:
1) Node Majority Quorum Configuration : Cluster avec quorum à jeu de majorité ou quorum MNS (pour Majority Node Set). Ce type de cluster reste en ligne tant qu’une majorité des noeuds le composant est opérationnelle. Ainsi, un cluster à 4 noeuds fonctionne tant que 3 noeuds sur 4 sont opérationnels (si un deuxième noeud tombe en panne, la majorité n’est plus atteinte et le service tombe).
2) Node and Disk Majority Quorum Configuration: Cette configuration est proche de la précédente. La seule différence est l’ajout d’un témoin (un disque partagé de type NAS ou SAN) qui agira comme un noeud dans le calcul de la majorité. Cette configuration augmente le niveau de tolérance aux pannes. En effet, un cluster à 4 noeuds restera en ligne tant que 2 des noeuds (plus le disque partagé) seront fonctionnels.
3) Node and File Share Majority Quorum Configuration: Cette configuration utilise un partage de fichiers en tant que témoin. Hormis cela, elle est identique à la précédente.
4) No Majority (Disk Only) Quorum Configuration : Cette configuration utilise un quorum partagé (c’est-à-dire stocké sur un support de stockage de type NAS ou SAN). Cette implémentation est la seule où le quorum n’est pas répliqué localement sur l’ensemble des noeuds ! Ce type de configuration n’implémente pas le principe de la majorité (un cluster à 4 noeuds reste fonctionnel tant qu’au moins un noeud est actif). Malheureusement ce système induit une unicité des données (si le support partagé est corrompu, le cluster est perdu !) et il devrait être de moins en moins utilisé dans les années à venir.
La figure 1 représente un cluster à deux noeuds avec quorum partagé (à gauche) ainsi qu’un cluster à deux noeuds avec quorum à jeu de majorité.
Retenez que les clusters les plus intéressants en termes de fonctionnalités sont ceux implémentant un quorum à majorité avec témoin. L’utilisation de cluster à quorum partagé peut encore se justifier dans certains scénarios mais nécessite une plus grande rigueur au niveau des données (sauvegardes fréquentes, réplication du SAN…).
http://www.windowsnetworking.com/articles_tutorials/Cluster-Quorums.html
Sinon, pour répondre à la question de ton client, CSV supporte toutes les configurations de quorum supportée d’une manière générale avec les cluster windows 2008 :
- Node majority quorum
- Node and disk majority quorum
- Node and file share majority quorum
- No majority quorum
A part la stratégie de quorum, ça reste du Failover cluster Actif/Actif Share nothing à la microsoft
Comment fonctionnait Hyper-V V1 ?
Si une application tournant sur une LUN a besoin de basculer sur un autre nœud, alors toutes les applications sur cette même LUN vont également basculer. Ceci à une conséquence importante au niveau du stockage puisque les clients décident alors de créer une LUN par application (qui le plus souvent, se retrouve être une machine virtuelle). Ceci pose de nombreux problèmes de complexité de stockage avec un découpage difficile de la baie SAN qui s’accompagne généralement d’une perte de place…
Hyper-V V2
CSV autorise les nœuds d’un même cluster à partager l’accès à une LUN ce qui signifie que l’application sur ce disque partagé peut être exécuté par n’importe quel nœud, n’importe quand. CSV casse la dépense actuelle entre la ressource applicative (dans notre cas la VM) et la ressource disque (le disk CSV) ce qui signifie que dans un environnement CSV peu importe où le disque est monté car il apparaît comme local pour tous les nœuds du cluster. Une nouvelle notion apparaît c’est le nœud coordinateur qui correspondant anciennement au propriétaire et c’est lui qui gère l’accès concurrentiel à la ressource disque en fonction de la demande.
Le point important que le CSV n’utilise pas de technologies propriétaires mais se base tout simplement sur le standard NTFS ce qui veut dire qu’il n’y a besoin de rien de spécial pour le déployer et l’implémenter dans votre architecture.
Il est toujours recommandé d’avoir au minimum deux réseaux pour votre cluster, un premier dit « Publique » pour la connexion des clients et un second dit « privé » pour les pulsations (heartbeat). En plus de cela, il est recommandé d’avoir un troisième réseau dédié pour le CSV et la fonction Live Migration d’au moins 1 GB pour s’assurer que le réseau de pulsations ne soit pas saturé et loupe ainsi une vérification et ne provoque un basculement involontaire.
CSV autorise les nœuds d’un même cluster à partager l’accès à une LUN ce qui signifie que l’application sur ce disque partagé peut être exécuté par n’importe quel nœud, n’importe quand. CSV casse la dépense actuelle entre la ressource applicative (dans notre cas la VM) et la ressource disque (le disk CSV) ce qui signifie que dans un environnement CSV peu importe où le disque est monté car il apparaît comme local pour tous les nœuds du cluster. Une nouvelle notion apparaît c’est le nœud coordinateur qui correspondant anciennement au propriétaire et c’est lui qui gère l’accès concurrentiel à la ressource disque en fonction de la demande.
Le nœud coordinateur peut être n’importe quel nœud dans un cluster, et la VM sur le disque CSV peut être également sur n’importe que hôte hyper-V du cluster.
Le point important que le CSV n’utilise pas de technologies propriétaires mais se base tout simplement sur le standard NTFS ce qui veut dire qu’il n’y a besoin de rien de spécial pour le déployer et l’implémenter dans votre architecture.
La technologie CSV est tolérante à la perte d’un coordinateur, d’un nœud hébergeant une VM, d’un chemin réseau ou encore d’un chemin d’accès au stockage c’est ce que l’on appel « CSV I/O Redirection ».
Source et en savoir plus : http://www.mslive.fr/dossiers-15-3-presentation-technologie-csv-%28cluster-shared-volume%29-introduite-dans-clustering-windows-2008.aspx
Steps for using Hyper-V and Failover Clustering
- Step 1: Connect both physical computers to the networks and storage
- Step 2: Install Hyper-V and Failover Clustering on both physical computers
In this step, you install the Hyper-V role and the Failover Clustering feature. - Step 3: Create a virtual network
- Step 4: Validate the cluster configuration
- Step 5: Create the cluster
- Step 6: Create a virtual machine and reconfigure the automatic start action
- Step 7: Make the virtual machine highly available
- Step 8: Configure the virtual machine
- Step 9: Test a planned failover
- Step 10: Test an unplanned failover
- Step 11: Modify the settings of a virtual machine
- Step 12: Remove a virtual machine from a cluster
The Windows Storage Server Team just released a new 30-page white paper on "Configuring Failover Clusters with Windows Storage Server 2008".
This paper will guide you through the process of configuring the networks, domains and clustering features, including performance recommendations for a pair of Windows Storage Server 2008 appliances hosting a File Server or a Microsoft iSCSI Software Target in a high availability failover cluster.
The table of contents for this new white paper shows:
- Failover Cluster Prerequisites
- Establish a Network Naming Convention
- TCP/IP Network Configuration
- Public Network
- Storage Network
- Heartbeat Network
- Procedures
- Prepare the Failover Cluster
- Create a Domain User Account
- Add Nodes to an Active Directory Domain
- Expose Storage to Cluster Nodes
- Install the Failover Cluster Feature
- Run Cluster Validation
- Create and Configure the Failover Cluster
- Create a Cluster
- Set Cluster Network Properties and Apply Naming Convention
- Create a Highly Available File Server
- Mapping User Folders to the Highly Available File Server Share
- Create a Highly Available iSCSI Target
- Configuring Windows Firewall for Microsoft iSCSI Software Target
- Installing the Microsoft iSCSI Software Target
- Create the Failover iSCSI Target Resource Group
- Create an iSCSI Target in the Microsoft iSCSI Target MMC
- Create and Configure Virtual Disks
- Connect Initiators
- Microsoft iSCSI Software Target Performance Recommendations
- Testing Your Failover Cluster Configuration
Download it from
http://download.microsoft.com/download/3/B/5/3B5632C8-7A04-44A6-8ED2-A122C2D6DDB1/ConfigureFailover.docx
