Implémentation de la haute disponibilité

Les risques d’une architecture centralisée

1. Considérations générales

Les services basés sur une architecture centralisée permettent de faciliter le déploiement, l’administration et la maintenance des services. Ils posent toutefois le problème de la disponibilité car centraliser une architecture revient à mettre tous ses œufs dans le même panier et ainsi à tout perdre si le moindre incident survient.

Afin de réduire les risques d’indisponibilité des services, il est important d’identifier le ou les points uniques de défaillance (SPOF - Single Point Of Failure) qui reviennent à identifier les composants qui, s’ils sont défaillants, peuvent nuire à la disponibilité ou à la qualité d’accès au service.

Lorsque l’on souhaite sécuriser une architecture, on doit donc penser à vérifier l’ensemble des composants pouvant entraîner une panne complète du système. Il est nécessaire de considérer aussi bien l’accès réseau, la robustesse du matériel, la fiabilité des logiciels et les risques de corruption de données. L’objectif est d’envisager une panne de n’importe lequel de ces composants d’infrastructure sans que cela empêche l’accès au service.

Une fois les risques évalués, il est nécessaire de déterminer les stratégies à mettre en place pour pouvoir éviter la panne ou en minimiser l’impact.

Dans le cas d’une infrastructure complexe qui tombe en panne, il est d’autant plus difficile de déterminer l’origine de cette panne que les composants qui interviennent dans le processus sont nombreux. Ces interventions, qui sont souvent faites dans l’urgence (n’oublions pas que le service est en panne), deviennent longues, stressantes et coûteuses...

La mise en place d’une infrastructure à tolérance de panne consiste à prévoir à l’aide de composants dédiés le basculement des services sur des systèmes redondants, et ceci...

Haute disponibilité des services proxy d’accès client

1. Principes de protection des services proxy d’accès client

a. Rappels sur le fonctionnement des services d’accès client

La mise en place d’un système hautement disponible pour les serveurs hébergeant le rôle d’accès au client a été largement facilité avec les dernières versions d’Exchange. Dorénavant, les services d’accès client deviennent le point de connexion pour tous les protocoles clients : MAPI/HTTP, Outlook Anywhere, OWA, ActiveSync, IMAP, POP, EWS, PAI REST,...

Seul le rôle de messagerie unifié sera redirigé en direct sur le composant du serveur de boîtes aux lettres pour garantir la latence de connexion la plus réduite possible.

b. Solutions de haute disponibilité des services d’accès client

La haute disponibilité des services d’accès client ne nécessite donc pas de garantir l’intégrité d’une donnée quelconque et s’implémente à l’aide d’une solution de répartition de charges réseau.

Solution logicielle de répartition de charge

L’implémentation d’une solution de répartition logicielle est économiquement avantageuse. Des produits open source comme HAProxy (http://www.haproxy.org/) ont fait leurs preuves dans ce rôle depuis plusieurs années. Par contre le composant logiciel de répartition de charge réseau fournit avec Windows Server ne peut pas être utilisé car non supporté dans les scénarios de déploiement.

Selon la connectivité réseau...

Haute disponibilité des bases de données de boîtes aux lettres

1. Principes de protection des bases de données de boîtes aux lettres

a. Rappels sur le fonctionnement des services de boîtes aux lettres

La mise en place d’un système hautement disponible pour les serveurs hébergeant le rôle boîtes aux lettres doit prendre en compte les nouvelles spécifications de l’architecture des serveurs Exchange Server 2016. Dorénavant, le rôle boîtes aux lettres contient les services de rôles de boîtes aux lettres, de transport hub et d’accès au client…

Heureusement, seul le service de rôle boîtes aux lettres va nécessiter une attention particulière pour la mise en place d’une architecture hautement disponible. Les services de rôles de transport hub et d’accès client utilisent les mécanismes internes nativement à haute disponibilité que nous allons décrire ci-après.

b. Solutions de haute disponibilité des services de rôles de boîtes aux lettres

L’une des nouveautés les plus marquantes d’Exchange Server 2010 a été la remise à plat des différentes technologies de haute disponibilité et de réplication des bases de données par le groupe de disponibilité de bases de données (DAG - Data Availability Group). Celui-ci a remplacé l’ensemble des mécanismes de haute disponibilité que l’on pouvait trouver sur les versions précédentes.

Exchange Server 2016 profite de cette solution unique qui facilite la mise en place d’une infrastructure hautement disponible tout en garantissant la sécurité des données qui vont être répliquées sur plusieurs serveurs ou plusieurs datacenters.

Un groupe de disponibilité de bases de données symbolise la réunion d’un maximum de 16 serveurs qui vont pouvoir répliquer les bases de données Exchange Server 2016 pour en assurer la haute disponibilité.

Microsoft recommande d’implémenter trois copies minimum de chaque base de données afin de garantir la disponibilité des données et la réparation d’une copie défectueuse...