Les choix d’architecture

1. Les différentes architectures 

Derrière les termes de haute disponibilité se cachent deux types de solutions distinctes : 

● La solution de type actif/passif. 

● La solution de type actif/actif. 

La  première  augmente  la  disponibilité  en  basculant  les  ressources  d’un  serveur  à  un  autre  en  cas  de  problème  (solution  hautement  disponible).  La  deuxième  solution  permet  d’avoir  plusieurs  serveurs  qui  répondent  aux  demandes en même temps (répartition de charge) et qui peuvent tolérer la perte d’un membre (solution hautement  disponible). 

Les  solutions  de  type  actif/actif  peuvent  sembler  de  prime  abord  plus  intéressantes,  mais  elles  sont  également  encore plus complexes et doivent être envisagées pour répondre d’abord à un problème de répartition de charge. 

Dans un environnement Microsoft, les solutions sont les suivantes : 

● Solution actif/passif : cluster à basculement (MSCS). 

● Solution actif/actif : cluster NLB (Network Load Balancing). 

Une application destinée aux utilisateurs doit être compatible avec une solution de haute disponibilité. En dehors des 

« grands »  éditeurs  de  logiciels,  il  est  courant  qu’un  éditeur  n’ait  jamais  testé  son  application  en  environnement  hautement disponible et ne puisse donc s’engager sur son bon fonctionnement. Au minimum, les points suivants sont  à analyser : 

● Est­ce que l’ensemble des données peut résider sur des volumes partagés et donc autres que C:\ ? 

● Est­ce que certaines clés de registre doivent être répliquées entre les serveurs ? 

● L’application utilise­t­elle un dongle ou une connexion physique qui ne peut pas être doublée ou connectée  sur deux machines ? 

● Est­ce  que  les  clients  peuvent  utiliser  un  nom  NetBIOS/DNS  et  une  adresse  IP  différents  de  ceux  de  la  machine physique (nom/IP virtuels) ? 

● Quels sont les mécanismes pour détecter une panne de l’application et décider de basculer ? 

Un seul serveur héberge une même ressource à un moment donné. Il n’a pas besoin de synchroniser les données  métiers  avec  les  autres  serveurs  (16  au  maximum,  8  en  édition  itanium).  S’il  tombe  en  panne,  un  autre  serveur  démarrera  l’application,  qui  aura  accès  aux  mêmes  volumes  disque  que  le  serveur  précédent,  devant  juste  gérer  l’interruption brutale du service (journaux de transactions pour une base de données par exemple). Le stockage peut  être un point de faille unique dans certains cas. Le stockage d’entreprise (SAN, ...) coûte cher et il est donc mutualisé  entre les plates­formes. En échange, tous les éléments sont doublés, notamment les contrôleurs. Bien que tout soit  mis en œuvre pour qu’une panne n’arrive jamais, cela reste possible. Un autre problème est la corruption du volume  (LUN)  hébergeant  les  données.  Si  une  vérification  de  la  partition  s’impose  (chkdsk),  il  faut  prendre  en  compte  l’indisponibilité pendant la durée de celle­ci (qui dépend du nombre de fichiers et non du volume). 

N  serveurs  (32  au  maximum)  répondent  aux  requêtes  simultanément.  Les  serveurs  doivent  pouvoir  répondre  à  toutes  les  requêtes  et  donc  avoir  accès  à  l’ensemble  des  données  permettant  d’y  répondre.  L’utilisation  la  plus  répandue concerne les fermes de serveurs Web. Tous les serveurs ont une copie des sites Web et les données sont  stockées dans une base de données qui est hébergée en dehors de la ferme. La complexité concerne la session de  l’utilisateur. Il peut avoir un panier (site commercial) et/ou être authentifié sur le site. Si le serveur qui a répondu à  ses  requêtes  tombe  en  panne,  un  autre  serveur  doit  pouvoir  prendre  la  relève,  de  préférence  sans  renvoyer  l’utilisateur  sur  la  page  d’accueil.  La  session  de  l’utilisateur  doit  donc  être  conservée  à  l’extérieur  du  serveur,  par  exemple dans une base de données. Cela implique que le site Web ait prévu ce type d’architecture et stocke bien la  Dans la solution actif/passif

Dans la solution actif/actif

enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA8Mjg5MzAyIC0gYWRhbW8gZGlhcnJhIC0gMjU4ZThlZWQtN2NjNS00YTU2LThlODQtZjYwZWVhYWMyOThluAFUBvunzogLAA==-enidentnumber

session en dehors du serveur. Sur un site marchand très fréquenté, cette gestion de sessions a un impact important  sur la consommation de ressources. Il est possible de faire fonctionner un cluster NLB en mode actif/passif, mais ce  mode de fonctionnement est un usage atypique par rapport à la philosophie du produit. 

Voici un tableau synthétisant les différences importantes entre les deux solutions : 

Notez  que  ces  deux  technologies  ne  sont  pas  supportées  sur  le  même  serveur,  cf.  l’article  235305  (Interoperability between MSCS and NLB) de la base de connaissances Microsoft. 

2. La haute disponibilité, nirvana de votre infrastructure ? 

Les promesses de la haute disponibilité ne seront tenues que si les équipes et les processus sont en cohérence avec  le  besoin  auquel  répond  cette  promesse.  Alors  que  le  coût  de  la  solution  est  certain,  il  ne  sera  amorti  que  si  elle  permet effectivement de parer à des coupures de services. Le coût de la solution porte au moins sur les éléments  suivants : 

● Les investissements matériels (par exemple deux serveurs au lieu d’un). 

● Encombrement, consommations électrique et climatique complémentaires. 

● Le socle logiciel « infrastructure » (2 licences édition Entreprise pour le cluster à basculement, les agents de  sauvegardes...). 

Ces  coûts  s’entendent  par  environnement  et  doivent  donc  être  reportés  sur  chaque  environnement  impacté  (préproduction, qualification...). Le coût d’indisponibilité doit donc être supérieur à ces exemples de coûts. 

Le danger consiste à considérer un cluster comme un serveur classique « amélioré ». Cette approche était souvent  fatale  dans  les  versions  antérieures  de  Windows.  Il  suffisait  qu’un  administrateur  supprime  un  partage  de  fichiers  depuis l’explorateur au lieu de le faire par la console d’administration du cluster pour faire échouer cette ressource  cluster  et  générer  par  défaut  une  bascule  du  cluster.  Microsoft  a  fortement  revu  l’intégration  de  la  couche  cluster  dans le système d’exploitation. Cette même erreur sur Windows Server 2008 R2 est gérée, le système supprimant en  fait  la  ressource  cluster  directement  sans  générer  d’incident.  Il  en  résulte  une  forte  diminution  des  incidents  provoqués par des erreurs humaines dues à la méconnaissance des spécificités et une réduction de celles­ci. 

La  politique  des  éditeurs  concernant  les  licences  évolue,  même  si  un  décalage  persiste.  Par  exemple,  il  n’est  plus  nécessaire  d’acheter  la  version  Entreprise  de  Microsoft  SQL  Server  pour  l’implémenter  en  cluster  depuis  la  version  2005. En revanche, le même produit est toujours nécessaire en version Entreprise pour constituer une ferme cluster 

donc  pas  conscience  de  l’état  des  applications  pour  lesquelles  il  répartit  la  charge.  S’il  s’agit  de  sites  Web  par  exemple,  l’arrêt  de  IIS  ne  fera  pas  sortir  la  machine  du  cluster.  Vous  aurez  ainsi  une  partie  des  utilisateurs  qui  n’accèderont  plus  au  site,  notamment  si  l’affinité  est  active.  Il  vous  incombe  de  mettre  en  place  un  mécanisme  de  vérification  de  l’applicatif,  afin  de  sortir  de  la  ferme  un  nœud  défaillant.  Le  seul  cas  géré  par  cluster  NLB  est  un  problème de niveau 3 et inférieur. Par exemple, si le serveur perd l’accès au réseau, il sera automatiquement sorti de  la ferme et les utilisateurs répartis sur les nœuds restants (convergence). Une exception est constituée par exemple  par Microsoft ISA, qui pilote le cluster NLB et sort du cluster en cas de problème. 

La  technologie  NLB  propose  plusieurs  solutions  pour  créer  l’adresse  IP  virtuelle,  toutes  ont  des  avantages  et  inconvénients. Certains commutateurs réseaux (Cisco, Enterasys...) nécessitent un paramétrage spécifique avant que  cela fonctionne. 

Un  cluster  NLB  est  constitué  le  plus  souvent  avec  deux  serveurs.  Contrairement  au  mode  actif/passif,  on  peut  se  retrouver  dans  une  situation  où  l’absence  d’un  nœud  n’est  plus  possible  pour  tenir  la  charge.  L’aspect  haute  disponibilité n’est donc plus couvert, car la perte d’un nœud engendre une interruption de service ou du moins une  trop  grande  dégradation.  Il  faut  donc  être  très  vigilant  sur  la  charge  que  doit  absorber  la  ferme  afin  de  tolérer  la  perte d’un nœud. Ce phénomène est aussi possible avec un cluster à basculement, si les deux nœuds sont actifs en  même temps sur des ressources différentes (actif/actif en mode croisé). Cette configuration n’est pas recommandée  par Microsoft, qui propose plutôt un cluster à trois nœuds dans ce cas (actif/actif/passif). Le nœud passif est alors  mutualisé pour les deux actifs. 

enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA8Mjg5MzAyIC0gYWRhbW8gZGlhcnJhIC0gMjU4ZThlZWQtN2NjNS00YTU2LThlODQtZjYwZWVhYWMyOThluAFUBvunzogLAA==-enidentnumber