web-dev-qa-db-fra.com

AlwaysOn AG contre FCI

Tout au long de la documentation MS pour Groupes de disponibilité AlwaysOn (AG) et Instances de cluster de basculement AlwaysOn (FCI) Je vois le schéma suivant:

  1. FCI est pour les scénarios HA.
  2. Une réplique secondaire synchrone AG, colocalisée avec la principale, est destinée aux scénarios HA.
  3. Une réplique secondaire asynchrone AG, dans un autre centre de données, est destinée aux scénarios de reprise après sinistre.

Voici un exemple de lien MS en discutant .

Étant donné que les options # 1 et # 2 sont toutes deux destinées aux scénarios HA, comment puis-je choisir entre elles? Si MS publiait les coûts et les mesures RPO/RTO à la fois pour # 1 et # 2, il serait assez facile de décider lequel je veux.

Ou peut-être existe-t-il une autre façon de comprendre les différences de ROI entre ces options. Par exemple, l'option # 2 est la mieux adaptée aux VLDB et l'option # 1 est la mieux adaptée aux volumes de transactions très élevés. Je ne sais pas.

Encore une fois, quels sont les critères de sélection qu'un DBA utilise pour choisir entre les options # 1 et # 2?

Pour compliquer encore les choses, je sais que les options # 1 et # 2 peuvent être combinées! Quand est-il sage de combiner les deux options? Quand est-il inutile de combiner les deux options? Je sais que lorsque ces options sont combinées, l'AG ne prend plus en charge le basculement automatique. C'est une anecdote intéressante, mais ne répond pas à ma question.

Par ailleurs, j'ai l'intention de provisionner ma solution finale dans Azure IaaS. Si j'utilise un Always On FCI, je vais probablement créer le quasi-SAN à l'aide de Storage Spaces Direct (S2D).

Mise à jour

J'ai trouvé deux articles qui donnent une comparaison. Le premier est MS docs , et l'autre est Choosing the Right Availability Tech . Les deux ont un tableau comme celui-ci:

╔═════════════════════════════╦══════════════════════════╗
║ FCI                         ║ AG                       ║
╠═════════════════════════════╬══════════════════════════╣
║  * Server Level             ║  * Database Level        ║
╠═════════════════════════════╬══════════════════════════╣
║  * Requires shared storage  ║  * Uses direct           ║
║     (SAN or Storage Spaces  ║     attached storage     ║
║     Direct)                 ║                          ║
╠═════════════════════════════╬══════════════════════════╣
║  * RTO from 30              ║  * RTO typically less    ║
║     seconds to 20 minutes.  ║     than 30 seconds      ║
╠═════════════════════════════╬══════════════════════════╣
║  * RPO: no data loss.       ║  * RPO: ???              ║
╠═════════════════════════════╬══════════════════════════╣
║  * Only Passive Secondaries ║  * Active or Passive     ║
║                             ║     Secondaries          ║
╠═════════════════════════════╬══════════════════════════╣
║  * One SQL Server           ║  * Multiple SQL Server   ║
║     instance/license        ║     instances / licenses ║
╚═════════════════════════════╩══════════════════════════╝

L'article n'a pas commenté AG RPO, mais j'ai lu ailleurs qu'il n'y a aucune perte de données lors de la récupération d'une réplique secondaire synchrone. Je ne sais pas si cela est vrai et je ne sais pas quel pourrait être le RPO de la réplique secondaire asynchrone. Dans Azure, il y a ne ressource AG qui nécessite deux contrôleurs de domaine sont créés avec l'AG (peu importe si vous avez vos propres contrôleurs de domaine). Je ne sais pas si un Azure FCI a la même exigence lourde.

Plus important encore - je ne sais toujours pas pourquoi il est utile de combiner les deux techniques. J'ai seulement lu qu'il "améliore" ou "maximise" la disponibilité. C'est une vague affirmation de l'OMI.

Plus de trivia: J'ai également repéré une discussion suggérant que n FCI de deux nœuds devrait être évité .

sql-serveravailability-groupsclusteringhigh-availabilityazure
5
Brent Arias

En général, FCI est plus avantageux par rapport à AG pour diverses raisons déjà mentionnées ci-dessus. Bien sûr, le FCI à 2 nœuds est complètement génial mais ne doit pas être construit directement sur les espaces de stockage car S2D est connu pour être problématique dans les déploiements à moins de 4 nœuds ( source ).

Pour Azure, je préfère m'en tenir à un VSAN conçu pour fonctionner dans des scénarios à 2 ou 3 nœuds comme ( exemple ).

ici est un peu plus d'informations sur FCI vs AG que vous pourriez trouver utiles aussi

5
Net Runner

Cela dépend de l'exigence et du besoin de chaque client quant à la meilleure option parmi les deux (options 1 et 2) à des fins de haute disponibilité. Divers critères généralement vérifiés sont fournis ci-dessous:

S'il s'agit d'une édition standard, vous devrez opter pour FCI (Option 1).

Allez avec AG (Synchrone - Option 2), si toutes les conditions ci-dessous satisfont:

  • Avoir l'édition Enterprise de SQL Server (Basic AG est également disponible dans l'édition Standard depuis SQL Server 2016)
  • Vous avez besoin et avez la capacité de stockage pour stocker plusieurs copies de vos fichiers de base de données pour un niveau de sécurité supplémentaire. Le stockage est un point de défaillance unique dans FCI car il n'a qu'un seul ensemble de fichiers de données contre plusieurs dans les AG.
  • Vérifiez la latence du réseau et du disque pour voir si la latence totale entre le disque du serveur A et le disque du serveur B est conforme aux normes acceptables pour vos applications, car les transactions ne reviendront pas à l'application tant qu'elles ne seront pas validées sur le serveur secondaire (B).
  • N'oubliez pas que les objets de niveau serveur ne sont pas automatiquement synchronisés du serveur A vers le serveur B car les bases de données système ne sont pas synchronisées. Donc, soit vous gardez manuellement synchronisé tous les objets de niveau serveur entre les serveurs participants, soit vous déployez une solution automatisée qui continuera à synchroniser ces objets de niveau serveur entre les 2 serveurs.
  • Vous avez suffisamment d'expertise pour traiter les problèmes opérationnels d'AG. Les AG sont beaucoup plus compliqués que les FCI et vous devez donc être prêt à résoudre tous les problèmes liés aux AG, en particulier ceux liés aux performances.

Ou

Si vous devez décharger des requêtes de rapport (ou des sauvegardes) sur le serveur secondaire pour réduire la charge sur l'instance principale, utilisez AG.

Je combinerais (1 et 3) ou (2 et 3) à la fois pour HA et DR, où 1 ou 2 fournirait une solution HA et 3 serait une solution DR. Il est donc toujours préférable de combiner 1 & 3 ou 2 & 3 pour une stratégie HA et DR complète.

Mais je ne sais pas s'il est avantageux de combiner 1 et 2.

4
Masood Hashim