La haute disponibilité Microsoft: quoi, comment, pourquoi…

L’augmentation de la disponibilité est une préoccupation majeure des DSI. Avec l’avènement de la virtualisation et de la consolidation, il est plus facile d’y arriver, quand bien même, il existe tellement d’options et de mécanismes différents pour y arriver… Petit tour d’horizon rapide sur les solutions Microsoft concernant la mise en oeuvre de la haute disponibilité…

Voici un tableau, avec les liens de mise en oeuvre correspondant, des services les plus couramment déployés:

Service Redondance Architecture Type de disponibilité Moyen
DHCP (utilisation de scopes partagés) Plusieurs serveurs DHCP standalone Chaque serveur utilise ses propres scopes, aucune réplication Actif/Actif, les clients utilisent le broadcast pour chercher un serveur DHCP En cas de panne, seuls les serveurs restants répondent via broadcast
DHCP en Failover Cluster Plusieurs serveurs DHCP dans un cluster Stockage partagé (FC, iSCSI,SAS) Actif/Passif, les clients utilisent le broadcast pour chercher un serveur DHCP En cas de panne, le Failover fait en sorte qu’un nouveau serveur réponde au broadcast
DNS (usage de transfert de zones) Plusieurs serveurs DNS standalone Les zones DNS sont transférées à intervalle régulier Actif/Actif, les clients disposent de plusieurs serveurs DNS dans leur configuration IP En cas de panne, les serveurs alternatifs sont utilisés
DNS (intégration AD) Plusieurs serveurs dans un domaine Réplication AD DS Actif/Actif, les clients disposent de plusieurs serveurs DNS dans leur configuration IP En cas de panne, les serveurs alternatifs sont utilisés
AD DS Plusieurs DC dans un domaine Réplication AD DS Actif/Actif, le DC Locator trouve le DC Le DC Locator trouve le DC disponible
Serveur de fichiers (avec usage DFS) Plusieurs serveurs de fichiers avec DFS Réplication DFS (DFS Namespaces stocké dans AD, consistence garantie) Actif/Actif, utilisation du serveur le plus proche En cas de panne, une alternative du DFS Namespace est utilisée
Serveur de fichiers (Failover Cluster) Plusieurs serveurs dans un cluster Stockage partagé (FC, iSCSI,SAS) Actif/Passif, nom et IP publiées dans le DNS Failover, SMB Continuous Availability
Serveur de fichiers (Scale-Out) Plusieurs serveurs dans un cluster Stockage partagé, Stockage CSV (FC, iSCSI,SAS) Actif/Actif, via Distributed Network Name SMB Continuous Availability
Serveur WEB (contenu statique) Plusieurs serveurs WEB dans un cluster Uniquement la copie initiale Actif/Actif, DNS Round Robin, load balancer Nouvelle tentative client
Serveur WEB (avec un back-end) Plusieurs serveurs WEB dans un cluster Partage de fichier en back-end Actif/Actif, DNS Round Robin, load balancer Nouvelle tentative client
Serveur WEB (avec un SQL back-end) Plusieurs serveurs WEB dans un cluster Base de données SQL Actif/Actif, DNS Round Robin, load balancer Nouvelle tentative client
Hyper-V (failover clustering) Plusieurs serveurs dans un cluster Stockage partagé (FC, iSCSI,SAS, SMB) Actif/Passif, les clients se connectent via l’IP publiée VM rebootée en cas de panne
Hyper-V (utilisation de Replica) Plusieurs serveurs Réplication par VM Actif/Passif, les clients se connectent via l’IP publiée Failover manuel
Exchange Server (DAG) Plusieurs serveurs dans un cluster Réplication synchrone (Database Access Groups) Actif/Actif, utilisation d’AD DS pour les informations MBX/DAG Outlook bascule en offline puis se reconnecte
Sharepoint (Front End WEB) Plusieurs serveurs Stockage SQL Server Actif/Actif, DNS Round Robin, load balancer Nouvelle tentative client
Sharepoint (Request Manager) Plusieurs serveurs Stockage SQL Server Actif/Actif, Request Manager avec load balancer Nouvelle tentative client
SQL Server (réplication) Plusieurs serveurs Réplication par base Actif/Actif, les clients se connectent sur le serveur L’application peut détecter la panne et basculer vers un au autre serveur
SQL Server (miroir) Plusieurs serveurs Miroir par base Actif/Passif, partenaire définit au niveau de la connexion Failover automatique, si témoin et l’application nécessite une reconnexion
SQL Server (AlwaysOn Failover Cluster – instance) Plusieurs serveurs SQL ans un cluster Stockage partagé, Stockage (FC, iSCSI,SAS) Actif/Passif, ressources nom et IP publiées dans le DNS Failover Automatic, l’application nécessite une reconnexion
SQL Server (AlwaysOn Availability Groups) Plusieurs serveurs SQL dans un cluster Miroir, par groupe de disponibilité Actif/Passif, le listener est publié dans le DNS Failover automatique, si témoin et l’application nécessite une reconnexion
  • Salut Cédric,

    Normalement je suis fan de tes articles bien argumentés mais le je reste sur ma faim voire je suis en désaccord :
    – De manière générale, le tableau devrait être enrichi des pour/contre et d’information sur les couts/bénéfices
    – Le DNS Round Robin n’est pas une méthode de HA, juste de répartition de charge « aveugle »
    – Dans le cas des serveurs web, si on utilise un load balancer H/W, il n’y a pas de nouvelle tentative du client, le LB détecte la ou les cible(s) encore active(s) au préalable
    – La fonctionnalité Request Manager de SharePoint 2013 n’est pas un moyen de haute dispo : il sert à équilibrer la charge de manière intelligente et à protéger l’infrastructure contre des charges abusives. UN LB reste nécessaire
    – Au niveau SQL, il faut signaler que dès qu’il y a une reconnexion, la transaction en cours est perdue et dois être relancée. Certaines applications le font automatiquement, d’autres pas. Cela peut varier également en fonction du timeout côté client

    Bonne journée,
    Marc

  • Merci Marc pour tes précisions ! Pour être franc, je me suis basé sur les recommandations Microsoft à ce sujet, et leur point de vue et souvent « discutable »…