Serveur d'impression

Présentation des options de quorum de cluster Windows Server – Bien choisir son serveur d impression

Le 11 décembre 2019 - 12 minutes de lecture

David Bermingham examine les moyens de garantir que les informations critiques de l'entreprise détenues dans les déploiements de SQL Server peuvent être protégées via des quorums de cluster, notamment en examinant le rôle des différentes options «témoins».

Si vous déployez SQL Server, vous exécutez probablement des applications critiques sur celui-ci. Vous devez vous assurer qu'il est protégé contre les temps d'arrêt et la perte de données. Vous disposez généralement de l'une des deux options de protection haute disponibilité: les groupes de disponibilité Always On (AOAG), introduits avec SQL Server 2012 Enterprise Edition, ou les instances de cluster de basculement Always On (FCI), qui ont longtemps été une solution éprouvée de haute disponibilité. fourni avec SQL Server Standard et Enterprise Editions. Dans ces deux solutions, l'infrastructure sous-jacente de disponibilité repose sur le clustering de basculement Windows Server (WSFC). Ils impliquent tous deux d'exécuter SQL Server sur un nœud principal et de configurer un ou plusieurs nœuds secondaires exécutant également SQL Server. AOAG a intégré la réplication pour garder les données synchronisées entre les nœuds. FCI nécessite un périphérique de stockage partagé ou une solution de réplication logicielle.

En cas de panne sur le nœud principal, le logiciel de mise en cluster déplace les opérations vers l'un des nœuds secondaires, où il peut continuer à fonctionner avec un minimum d'indisponibilité ou de perte de données. Les options de clustering Microsoft AOAG et FCI reposent sur un quorum pour décider quel nœud va être mis en ligne en cas de basculement. Le quorum empêche le «cerveau divisé» où deux nœuds pensent qu'ils devraient être actifs, ce qui pourrait entraîner une perte de données s'il n'était pas empêché.

Un examen plus approfondi des quorums de grappes

Dans un cluster, chaque nœud obtient un vote indiquant qu'il est en ligne. Dans le cluster SQL Server illustré à la figure 1, chacun des trois nœuds obtient un vote. Si vous avez un échec – supposons que le nœud principal se déconnecte – alors les nœuds deux et trois ont deux votes sur trois, formant un ensemble de nœuds majoritaires. Le quorum déplacera ensuite SQL Server vers le nœud deux ou trois.

Figure un: cluster à trois nœuds.

Mais que se passe-t-il si vous avez un cluster à deux nœuds comme celui de la figure deux avec seulement deux votes? Si le nœud principal (un) échoue, le nœud deux reste en ligne avec un vote. Un sur deux est une égalité, donc le nœud deux ne basculera pas, le cluster sera hors ligne et votre SQL Server n'est plus en service. Vous avez besoin d'un nœud témoin pour briser le lien. Il existe trois types de nœuds témoins dans un cluster: témoin de disque, témoin de partage de fichiers et témoin de cloud.

Figure deux: cluster à deux nœuds.

Le témoin du disque

Dans un cluster de stockage partagé, vous pouvez utiliser une petite partition sur le disque SAN comme témoin de disque pour agir comme un vote comme dans la figure trois. Si le nœud un échoue, le nœud deux et le témoin de disque SAN forment une majorité de deux sur trois, SQL Server basculera et l'opération continuera. Fait intéressant, un témoin de disque n'est pas un point de défaillance unique. Si le témoin échoue, vous disposez toujours de deux voix (nœuds un et deux) qui représentent une majorité de deux sur trois. Peu importe que vous perdiez le témoin, qu'il s'agisse d'un disque, d'un partage de fichiers ou d'un témoin cloud, car vous disposez toujours de deux votes sur trois. Étant donné que les nœuds un et deux sont toujours sains, SQL continuera de travailler sur le nœud un sans échec ni basculement.

Figure trois: ensemble de nœuds majoritaires avec témoin de disque.

Le témoin de partage de fichiers

Microsoft a introduit le concept de témoin de partage de fichiers pour les systèmes qui n'utilisent pas de stockage partagé. Le cas d'utilisation d'origine était pour les serveurs Exchange, mais depuis lors, il a également été utilisé pour AOAG et SQL Server FCI qui utilisent SIOS DataKeeper pour créer des clusters sans SAN. Vous pouvez désigner n'importe quel autre serveur Windows de votre domaine pour agir en tant que vote. Vous créez simplement un partage de fichiers et donnez au cluster un accès en lecture-écriture, créant un partage de fichiers simple qui agit comme un vote dans votre cluster. Voici comment implémenter la haute disponibilité pour tous les groupes de disponibilité ou pour les clusters sans SAN. Et comme un témoin de disque, vous pouvez perdre un témoin de partage de fichiers et le cluster continuera de fonctionner.

Témoin de nuage

Cloud Witness a été introduit avec Windows Server 2016. Vous pouvez tirer parti du stockage d'objets blob Microsoft Azure pour agir en tant que témoin. Vous provisionnez simplement un compte de stockage et à l'aide du gestionnaire de cluster de basculement, configurez un témoin cloud qui pointe vers ce compte de stockage. Notez que ces deux nœuds doivent accéder au cloud public pour tirer parti d'un témoin cloud. Cette option vous offre une haute disponibilité sans avoir besoin d'un troisième serveur pour agir en tant que témoin.

Reprise après sinistre simple et économique

Les témoins cloud (figure quatre) vous permettent de configurer des clusters multi-sites sans nécessiter qu'un troisième site contienne un témoin disque comme précédemment requis. Par exemple, supposons que le nœud un se trouve à Chicago et le nœud deux à Dallas, auparavant, vous devez configurer un troisième site pour votre témoin de partage de fichiers afin de vous assurer que la défaillance d'un site unique n'affectera qu'un seul de vos votes de quorum. Pour garantir le basculement automatique sans témoin cloud, le témoin de partage de fichiers devait se trouver dans un emplacement distinct (potentiellement très coûteux) pour la reprise après sinistre à l'échelle du site.

Figure quatre: témoin de nuage.

Les témoins cloud sont également importants dans les petits bureaux ou les sites distants où vous ne disposez que de deux serveurs physiques. Par exemple, si vous avez deux serveurs exécutant Hyper V et deux machines virtuelles exécutées sur chaque serveur, et que vous souhaitez une redondance, mais que vous ne pouvez pas vous permettre un troisième serveur ou un SAN. Au lieu de cela, vous pouvez créer un cluster à deux nœuds et utiliser un témoin cloud Azure pour votre cluster. Cela vous permet de créer un cluster à deux nœuds très rentable pour votre bureau distant ou votre succursale.

Quorum dynamique

Et si vous avez un cluster à quatre nœuds et des serveurs supplémentaires pour plus de redondance? Si le nœud un échoue, SQL passe au nœud deux. Mais que se passe-t-il si le nœud deux échoue également? Maintenant, même si vous avez encore deux nœuds opérationnels, deux sur quatre ne sont pas majoritaires, et donc SQL se déconnecte. Conscient de ce problème, Microsoft a introduit le quorum dynamique dans Windows Server 2012. Les quorums dynamiques ajustent le nombre de votes dans votre cluster à mesure que les nœuds commencent à tomber.

Si vous avez deux nœuds dans votre cluster, Microsoft ajuste le quorum. Cela crée toujours un nombre pair de votes. Avec seulement deux nœuds restants, il changera le nombre de quorum à un et supprimera le vote de l'un de ces nœuds. Vous pourriez potentiellement perdre les trois nœuds, et tant qu'un témoin est disponible, le dernier nœud restera en ligne.

Témoin dynamique

Le témoin dynamique ajoute ou supprime des votes au témoin de partage de fichiers pour garantir le nombre approprié de votes pour la protection de basculement. Dans une configuration à quatre nœuds, si vous perdez le nœud un, le nœud deux sera mis en ligne avec SQL Server, mais sans le témoin dynamique, le témoin de partage de fichiers vous donne quatre votes dans le cluster. Supposons maintenant qu'ils soient tous assis dans le même rack et que ce rack a échoué, ce qui vous a fait perdre deux d'entre eux en même temps. Vous perdriez deux voix sur quatre. Même si le nœud deux est entièrement opérationnel et peut parler au témoin de partage de fichiers, il se déconnecte et le fonctionnement de SQL Server s'arrête.

Si cela se produit avec un témoin dynamique, SQL continuerait de fonctionner. Lorsque vous perdez le nœud un, Microsoft reconnaît que les nœuds deux, trois, quatre et le témoin représentent quatre votes, ce qui est un nombre pair. Il supprimera le vote des témoins de partage de fichiers, de sorte que le cluster dispose de trois votes. Vous pouvez maintenant perdre ce serveur et il basculera toujours. Une fois que vous avez perdu le nœud un, Microsoft constate qu'il ne reste que deux nœuds, ce qui donne un vote au témoin de partage de fichiers. Maintenant, vous pourriez perdre le nœud trois, et le nœud quatre sera mis en ligne car les nœuds quatre et le témoin de partage de fichiers représentent deux votes, pour une majorité de deux sur trois. Le témoin dynamique contrôlera en fait si un témoin – cloud, partage de fichiers ou témoin de disque – a un vote dans le cluster, ce qui vous offre un niveau de disponibilité beaucoup plus élevé qu'un simple quorum dynamique.

Avant 2012, vous ne configuriez un témoin que si cela vous donnait un nombre impair de votes. Dans un cluster à deux nœuds, vous configurez un témoin; dans un cluster à trois nœuds, vous ne le faites pas, car cela ferait quatre votes. À partir de 2012 R2 ou version ultérieure, vous configurez toujours le témoin et le quorum dynamique garantit que vous disposez du nombre approprié de votes.

Quorums dans le cloud

La figure cinq est une configuration cloud typique à 100%. Chaque fournisseur de cloud a des concepts très similaires de régions géographiques avec des zones de disponibilité (AZ) (parfois appelées domaines de pannes) dans chaque région. Au sein d'une région géographique, les AZ ou les domaines de pannes sont totalement indépendants les uns des autres. Une défaillance matérielle dans AZ one ne devrait pas du tout affecter AZ deux. Dans de nombreux cas, ces AZ se trouvent dans différents bâtiments attachés à différents réseaux électriques et systèmes de refroidissement. Ils sont fournis avec autant de redondance et aussi peu de points de défaillance uniques que possible.

Figure cinq: configuration du cloud.

Lorsque vous créez un cluster pour protéger votre implémentation SQL Server, que vous utilisiez des AOAG ou FCI dans un cluster sans SAN avec SIOS DataKeeper, commencez par placer chaque nœud de votre cluster dans un AZ différent. Dans le cloud, vous êtes limité à l'utilisation d'un témoin de partage de fichiers ou du témoin de cloud Azure. Si vous utilisez un témoin de partage de fichiers, assurez-vous qu'il réside dans son propre AZ. Cela vous offre une disponibilité maximale en garantissant que la défaillance d'une zone entière n'affectera qu'un vote du cluster à la fois.

Témoin de cloud Azure

Si vous utilisez le témoin cloud, vous n'avez pas à vous en préoccuper, car le témoin cloud est sa propre entité et l'échec d'un seul AZ ne l'affectera pas. Notez que le témoin de cloud Azure n'est pas limité aux déploiements Azure. Même si AWS est votre plate-forme, vous pouvez toujours nous servir de témoin cloud Azure dans le cadre de votre quorum cloud et cela ne vous coûtera presque rien.

L'auteur

David Bermingham est reconnu dans la communauté technologique comme un expert en haute disponibilité et a été élu par ses pairs pour être un MVP Microsoft Cloud and Datacenter Management. Le travail de David en tant que directeur, évangéliste technique chez SIOS Technology Corp., l'a concentré sur l'évangélisation des solutions de haute disponibilité et de reprise après sinistre de Microsoft, ainsi que sur l'assistance pratique, la formation et les services professionnels pour les implémentations de cluster. David détient de nombreuses certifications techniques et s'appuie sur plus de vingt ans d'expérience en informatique, notamment dans les domaines de la finance, des soins de santé et de l'éducation, pour aider les organisations à concevoir des solutions répondant à leurs besoins de haute disponibilité et de reprise après sinistre. David a récemment commencé à parler du déploiement de serveurs SQL hautement disponibles dans le cloud Azure et du déploiement du cloud hybride Azure pour la reprise après sinistre. En savoir plus sur www.us.sios.com ou ClusteringforMereMortals.com. Courriel [email protected]

SIOS est le fournisseur de la solution de réplication basée sur le logiciel SIOS DataKeeper.

Commentaires

Laisser un commentaire

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