Serveur d'impression

Comprendre le quorum de cluster de basculement Windows Server dans Windows Server 2016 – Mise en cluster pour de simples mortels – Serveur d’impression

Le 27 août 2019 - 2 minutes de lecture

Avant d'examiner les nouvelles fonctionnalités de quorum dans Windows Server 2016, il est important de savoir d'où nous venons. Dans mon précédent article intitulé Comprendre le quorum de cluster de basculement Windows Server dans Windows Server 2012 R2, je suis entré dans des détails très détaillés concernant l'historique et l'évolution du quorum de cluster. Je vous suggère de lire cet article pour comprendre le fonctionnement du quorum dans Windows Server 2012 R2 et comment les nouvelles fonctionnalités de Windows Server 2016 amélioreront encore la résilience de vos déploiements de clusters.

Témoin de nuage

Commençons par ma nouvelle fonctionnalité préférée, Cloud Witness. Un témoin de nuage vous permet d'utiliser Azure Blob Storage pour agir en tant que témoin pour votre cluster. Ce témoin serait à la place d'un témoin Disk ou d'un témoin de partage de fichier. La configuration d'un Cloud Witness est extrêmement facile et, selon mon expérience, il ne coûte pratiquement rien d'héberger dans Azure. Le seul inconvénient est que les nœuds de cluster devront pouvoir communiquer via Internet avec Azure Blob Storage. Très souvent, il est interdit aux nœuds de cluster de communiquer avec l’Internet public. Vous devrez donc vous coordonner avec votre équipe de sécurité si vous souhaitez activer un témoin Cloud.

Il existe de nombreuses raisons impérieuses pour utiliser Cloud Witness, mais pour moi, cela est plus logique dans trois environnements très spécifiques: le cluster de basculement dans Azure, les clusters de succursales et les clusters multisites. Examinons chacun de ces scénarios pour voir comment Cloud Witness peut aider.

azure-cloud-witness "srcset =" https://clusteringformeremortals.files.wordpress.com/2016/12/azure-cloud-witness.png?w=660 660w, https://clusteringformeremortals.files.wordpress.com/ 2016/12 / azure-cloud-witness.png? W = 150 150w, https://clusteringformeremortals.files.wordpress.com/2016/12/azure-cloud-witness.png?w=300 300w, https: // clusteringformeremortals.files.wordpress.com/2016/12/azure-cloud-witness.png?w=768 768w, https://clusteringformeremortals.files.wordpress.com/2016/azure-cloud-witness.png?w = 1024 1024w, https://clusteringformeremortals.files.wordpress.com/2016/azure-cloud-witness.png 1255w "tailles =" (largeur maximale: 660px) 100vw, 660px "/></p>
<p><em>Figure 1 – Le compte de stockage témoin sur le nuage doit toujours être configuré sur le stockage localement redondant (LRS)         </em></p>
<p>Si vous passez à Azure (ou à n’importe quel fournisseur de cloud), vous devez vous assurer que vos déploiements sont hautement disponibles. Si vous utilisez SQL Server, les serveurs de fichiers, SAP ou d'autres charges de travail traditionnellement mises en cluster avec le clustering de basculement Windows Server, vous devrez utiliser un témoin de partage de fichier ou un témoin Cloud, puisqu'un témoin de disque n'est pas possible dans Azure. Avec Windows Server 2012 R2 ou Windows Server 2008 R2, vous devez utiliser un témoin de partage de fichier. Avec Windows Server 2016, il est maintenant possible d'utiliser un Cloud Witness. L’avantage d’un témoin Cloud est qu’il n’est pas nécessaire de conserver une autre instance Windows dans Azure pour héberger le partage de fichiers. Au lieu de cela, Microsoft vous permet de tirer parti du stockage blob. Cela vous donne une solution moins coûteuse, beaucoup plus facile à gérer et plus résiliente.</p>
<p>Lorsque vous examinez les déploiements de grappes dans les succursales, le coût et la maintenance sont toujours une considération. Si vous pensez à une chaîne de vente au détail comptant des centaines ou des milliers d'emplacements, le coût d'un SAN dans chaque emplacement peut être prohibitif. Si vous considérez que chaque emplacement peut exécuter un cluster Hyper-V à deux nœuds sur une configuration S2D Hyper-converged ou une configuration 3<sup>rd</sup> Cloud Witness aide l'entreprise à éviter l'ajout d'un serveur physique supplémentaire à chaque emplacement pour qu'il serve de témoin de partage de fichier ou l'ajout d'un réseau de stockage à chaque emplacement.</p>
<p>Et enfin, lors du déploiement d’un cluster multisite, le Cloud Witness élimine la nécessité d’un 3<sup>rd</sup> centre de données pour héberger le témoin de partage de fichiers. Avant l’introduction du témoin Cloud, les meilleures pratiques dicteraient que le témoin de partage de fichiers réside dans un fichier 3.<sup>rd</sup> emplacement. Accès à un 3<sup>rd</sup> centre de données juste pour héberger un partage de fichiers témoin n'était pas toujours faisable et certainement introduit une autre couche de complexité. En plaçant à l'aide d'un témoin Cloud, vous éliminez le besoin de maintenir une<sup>rd</sup> la localisation et l'accès au témoin se font par le biais de l'internet public, ce qui minimise également les besoins du réseau.</p>
<h2><span class=Connaissance du site

Lors de la construction d'un cluster multisite, il y a toujours eu un autre problème commun. Contrôler le basculement pour toujours préférer le site local n'était pas possible. Bien que vous puissiez spécifier des propriétaires privilégiés, le paramètre Propriétaires favoris est généralement mal compris et les administrateurs n’ont peut-être pas compris que même s’ils n’avaient pas indiqué un serveur comme propriétaire privilégié, ce serveur était automatiquement ajouté à la fin de la liste des propriétaires privilégiés gérée par le propriétaire. grappe. Le résultat de ce malentendu est que bien que vous ayez uniquement répertorié les serveurs locaux en tant que propriétaires privilégiés, vous pouvez potentiellement avoir un basculement de ressource de cluster sur le site de récupération d'urgence, même si un nœud parfaitement correct est disponible sur le site local. Évidemment, ce n'est pas ce à quoi vous vous attendiez et utiliser Site Awareness éliminerait ce problème à l'avenir.

Site Awareness résout ce problème en préférant toujours le site local lors du choix du nœud à mettre en ligne. Ainsi, dans des circonstances normales, une charge de travail en cluster basculera toujours vers un nœud local, sauf en cas de panne complète du site. Dans ce cas, l'un des nœuds de récupération d'urgence sera mis en ligne. Il en va de même une fois que vous exécutez sur le site DR, le cluster récupérera la charge de travail sur un serveur du site DR s'il était précédemment exécuté sur un nœud du site DR. La connaissance du site préférera toujours un nœud local.

Domaines d'erreur

Construire sur la connaissance du site est Fault Domains. Fault Domains va encore plus loin et vous permet de définir des emplacements de nœud, de chasse et de rack en plus du site. Les domaines de défaillance présentent trois avantages: L'affinité de stockage dans un cluster extensible, augmente la résilience des espaces de stockage et améliore les alertes des services de santé en incluant des métadonnées sur l'emplacement des ressources associées qui déclenchent l'alarme. Storage Affinity vous aidera à vous assurer que vos charges de travail et votre stockage de cluster s'exécutent au même emplacement. Vous ne voudriez certainement pas que votre VM lise et écrit des données qui se trouvent sur un CSV dans une ville différente si vous pouvez l’aider.

Cependant, je pense que le plus grand gagnant ici est le scénario Storage Spaces Direct (S2D). SD2 utilisera les informations que vous fournissez sur l'emplacement de vos nœuds de cluster (Site, Rack, Chassis) pour vous assurer que les multiples copies de données écrites pour la redondance résident toutes dans des domaines de défaillance différents. Cela permet de garantir que le placement des données est optimisé afin que la défaillance d'un seul nœud, châssis, rack ou site ne réduise pas l'intégralité de votre déploiement S2D. Cosmos Darwin a une excellente vidéo sur Channel 9 qui explique ce concept en détail.

Résumé

Windows Server 2016 ajoute plusieurs nouvelles améliorations au quorum de cluster qui procurera des avantages immédiats pour vos déploiements de cluster. Outre les améliorations qui ont une incidence sur le quorum de cluster, vous souhaiterez également découvrir quelques-unes des autres nouvelles améliorations de cluster telles que la mise à niveau progressive du système, la résilience de la machine virtuelle, les clusters de groupe de travail et multi-domaines, etc.

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.