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 |
Je travaille actuellement en tant qu’Enterprise Architect pour le groupe CAPGEMINI. Acteur et expert communautaire reconnu depuis de nombreuses années, j’anime ce site autour des technologies Microsoft, des thématiques du Cloud, des infrastructures, … Je suis également à l’origine de nombreuses publications dans la presse IT.
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 »…