Exporter (0) Imprimer
Développer tout

Créer une architecture et une stratégie haute disponibilité pour SharePoint 2013

 

S’applique à : SharePoint Server 2013, SharePoint Foundation 2013

Dernière rubrique modifiée : 2014-10-22

Résumé : Découvrez comment combiner l’architecture et la technologie de batterie pour créer un environnement hautement disponible dans une batterie de serveurs SharePoint 2013 unique.

Une stratégie de haute disponibilité est importante pour un environnement SharePoint 2013 de production. Une stratégie de bout en bout inclut les processus opérationnels, la gouvernance de plateforme, l’architecture et les solutions techniques. Cet article se concentre sur les aspects techniques et architecturaux de la haute disponibilité. Les instructions décrivent les éléments de conception SharePoint spécifiques et les options techniques qui détermineront votre stratégie de haute disponibilité.

RemarqueRemarque :
La haute disponibilité et la récupération d’urgence ne sont pas identiques. Il existe bien un chevauchement en matière de planification et de solutions, mais celles-ci sont des sous-ensembles de la fonction de continuité des opérations. L’objectif de la haute disponibilité est d’apporter de la résilience dans le centre de données principal et des temps morts planifiés. Le but d’une récupération d’urgence est de permettre à une organisation de reprendre les opérations d’un ordinateur dans un centre de données secondaire lorsqu’une urgence au niveau du centre de données principal rend l’infrastructure inutilisable. Pour plus d’informations sur la récupération d’urgence pour SharePoint 2013, voir Choisir une stratégie de récupération d’urgence pour SharePoint 2013.

Dans cet article :

La haute disponibilité est généralement utilisée pour décrire la capacité d’un système à continuer à fonctionner et à fournir des ressources aux utilisateurs lorsqu’une défaillance se produit dans une ou plusieurs des catégories suivantes dans un domaine d’erreur : matériel, logiciel ou application. Le niveau de disponibilité est exprimé en tant que mesure du pourcentage de temps pendant lequel un système est opérationnel en continu pour prendre en charge les fonctions business. Le niveau de disponibilité requis varie selon les organisations. Si cette exigence peut également varier selon les divisions, un contrat de niveau de service s’applique à l’organisation dans son ensemble. Du point de vue des utilisateurs, une batterie de serveurs UNRESOLVED_TOKEN_VAL(SharePointAll_1st_NoVer) est disponible lorsque les utilisateurs peuvent y accéder et utiliser les fonctionnalités et services dont ils ont besoin pour faire leur travail.

Une batterie de serveurs SharePoint hautement disponible présente les objectifs et caractéristiques suivants :

  • La conception de la batterie de serveurs réduit les éventuels points de défaillance. Comme il est généralement impossible de supprimer tous les points de défaillance, la stratégie globale doit indiquer comment répondre à un événement de défaillance.

  • Les événements de basculement sont transparents et ont un impact minimal sur les activités de l’utilisateur.

  • La batterie de serveurs continue à fonctionner en capacité réduite au lieu d’échouer totalement.

  • La batterie de serveurs est robuste. Les incidents qui affectent le service se produisent rarement et une mesure efficace et pertinente est mise en place le cas échéant.

Pour pouvoir créer une architecture et une stratégie de haute disponibilité réalistes et économiques pour votre environnement SharePoint, vous devez définir et quantifier vos objectifs de disponibilité. Ceux-ci reflètent l’étendue de la dépendance de votre organisation à SharePoint 2013 et à quel point une perte de service peut se répercuter sur les opérations de l’organisation. L’impact de la perte de service dépend de la nature de la perte (complète ou partielle) et de sa durée.

La perte de revenu est généralement identifiée comme le premier résultat d’un service réduit ou d’une perte de service complète, notamment pour les sociétés qui font des affaires en ligne. Toutefois, d’autres conséquences moins visibles sont tout aussi préjudiciables pour une organisation. Par exemple, une organisation peut faire face à une perte de confiance des partenaires, fournisseurs ou clients, ou à une baisse du respect de la marque, ainsi qu’à des problèmes juridiques.

Une stratégie de haute disponibilité efficace doit refléter les besoins spécifiques de votre organisation. Elle doit en outre fournir un équilibre parfait entre les exigences de l’entreprise, les contrats de niveau de service informatique, la disponibilité des solutions techniques, les capacités de prise en charge informatique et les coûts d’infrastructure.

Après avoir identifié les exigences de disponibilité de votre organisation, vous pouvez commencer à créer une conception de haute disponibilité et une stratégie de réduction du risque de temps morts et de limitation des opérations. Les professionnels de l’informatique qui conçoivent et déploient des systèmes hautement disponibles utilisent les principes directeurs suivants pour atteindre leurs objectifs :

  • Éliminer les points de défaillance uniques pour chaque domaine d’erreur et l’intégralité du système à chaque couche possible (système d’exploitation, logiciel et application SharePoint)

    RemarqueRemarque :
    Un domaine d’erreur fournit l’étendue et la limite d’un point de défaillance physique. L’édition de mars 2011 du magazine IEEE Computer propose la définition suivante : « Un domaine d’erreur est un ensemble de composants matériels (ordinateurs, commutateurs, etc.) qui partagent un point de défaillance unique. »
    Pour plus d’informations sur les domaines d’erreur et les domaines de mise à niveau, voir Explication des domaines d’erreur Windows Azure et des domaines de mise à niveau pour les professionnels de l’informatique.
  • Implémenter une détection, une isolation et une résolution des erreurs extrêmement rapides

RemarqueRemarque :
Un contrat de niveau de service est un contrat négocié entre des fournisseurs de services informatiques (groupe informatique interne ou fournisseur externe) et les représentants des utilisateurs. Il permet d’identifier et de quantifier les services requis et la prise en charge que le fournisseur de services va offrir. Ces contrats sont clairs, spécifiques et précis afin d’éviter tout malentendu en ce qui concerne les attentes des fournisseurs et des utilisateurs. La clarté et la précision sont essentielles, car les contrats de niveau de service spécifient des pénalités financières importantes en cas de participation de fournisseurs de services tiers.

La haute disponibilité et la tolérance de panne ne sont pas identiques. La définition de la haute disponibilité est importante car la tolérance de panne est souvent utilisée comme synonyme pour décrire l’implémentation de la haute disponibilité.

Les solutions de haute disponibilité ont une grande étendue et fournissent un ensemble de ressources partagées à l’échelle du système qui sont intégrées afin de fournir les services requis prédéfinis. La solution utilise différentes associations de matériel et de logiciel standard du secteur afin de réduire les temps morts et de restaurer les services en cas de défaillance du système ou d’une partie du système.

Une solution à tolérance de panne est centrée sur le matériel et utilise un matériel spécialisé pour détecter les pannes et basculer instantanément sur un composant matériel redondant. Il peut s’agir d’un processeur, d’une carte mémoire, d’une source d’alimentation, d’un sous-système d’E/S ou d’un sous-système de stockage. Le basculement vers un composant redondant fournit un niveau de service élevé.

Une analyse coûts-avantages des solutions à tolérance de panne et des solutions de haute disponibilité permet aux organisations de mettre au point une stratégie efficace pour atteindre les objectifs de disponibilité de leur batterie de serveurs SharePoint. En règle générale, des contreparties de coûts s’appliquent entre les deux solutions. Pour plus d’informations, voir Évaluation des solutions de haute disponibilité par rapport aux solutions à tolérance de panne.

La disponibilité est mesurée par rapport à une exploitation à 100 % du temps, soit sans temps mort. Dans le domaine informatique, la mesure courante de la disponibilité est exprimée sous la forme d’une suite de neuf, allant d’un neuf (90 %) à cinq (99,999 %), qui correspond à la disponibilité idéale. La mesure par nombre de neuf représente le pourcentage de temps pendant lequel un système donné est en cours d’exécution, en cours de fonctionnement et disponible pour les utilisateurs.

RemarqueRemarque :
Le temps de fonctionnement est souvent utilisé comme synonyme de la disponibilité. Toutefois, cette assimilation est trompeuse, car un système informatique peut être en cours d’exécution mais incapable de fournir les services et fonctionnalités dont les utilisateurs ont besoin.

Le pourcentage de disponibilité est calculé à l’aide de la formule x = (n - y) * 100/n.

  • x est le pourcentage

  • n est le nombre total de minutes dans un mois donné (30 jours)

  • y est le nombre total de minutes pendant lesquelles un système ou un service est indisponible

Comme vous pouvez le voir dans le tableau suivant, qui met en corrélation le pourcentage de disponibilité et les équivalents de temps de calendrier, le score de cinq neuf de disponibilité est difficile à atteindre. Ce niveau de disponibilité est également onéreux, complexe et, dans certains cas, il présente un risque. Pour plus d’informations sur les cinq neuf, consultez la publication de Vijay Gill, Combien de neuf ? et celle de Sean Hull, Le mythe des cinq neuf : pourquoi la haute disponibilité est surévaluée.

RemarqueRemarque :
Un score de disponibilité de trois neuf représente la norme pour la plupart des entreprises qui exploitent des batteries de serveurs SharePoint dans leur centre de données. Ce niveau de disponibilité est également classique pour une batterie de serveurs SharePoint déployée dans un environnement hébergé ou dans le nuage.

Corrélation entre le pourcentage de disponibilité et les temps morts du calendrier

Pourcentage de disponibilité acceptable Durée des temps morts par jour Durée des temps morts par mois Durée des temps morts par an

90 (un neuf)

144,00 minutes

72 heures

36,5 jours

99 (deux neuf)

14,40 minutes

7 heures

3,65 jours

99,9 (trois neuf)

86,40 secondes

43 minutes

8,77 heures

99,99 (quatre neuf)

8,64 secondes

4 minutes

52,60 minutes

99,999 (cinq neuf)

0,86 seconde

26 secondes

5,26 minutes

Bien qu’ils soient hors de la portée de cet article, plusieurs des aspects suivants d’un contrat de niveau de service doivent être présents dans une conception de haute disponibilité.

Définition et étendue de la disponibilité

Vous ne pouvez pas créer un environnement de disponibilité ou négocier un contrat de niveau de service si vous ne définissez pas d’abord la disponibilité. Celle-ci doit correspondre à la mesure de la capacité des utilisateurs à effectuer les tâches normales liées à leur travail et à utiliser les fonctions et services fournis par UNRESOLVED_TOKEN_VAL(SharePointAll_1st_NoVer). Les charges de travail SharePoint utilisées par une organisation déterminent cette définition et l’étendue de la disponibilité. Les exigences de charge de travail varient selon les clients et sont fondées sur les besoins spécifiques de chaque organisation, les fonctions fournies par la batterie de serveurs et le profil des utilisateurs de cette batterie.

Exclusions des calculs de disponibilité

Les exclusions de disponibilité sont aussi importantes pour la conception de la disponibilité qu’elles le sont pour un contrat de niveau de service. Chaque système nécessite une maintenance de routine. Les temps morts planifiés ou les niveaux de service réduits ne font pas partie des calculs de disponibilité. Les exclusions classiques sont les heures de maintenance prévues et les temps morts planifiés pour des activités telles que la mise en quarantaine d’un virus ou la réponse à une menace de sécurité.

Mesure des temps morts

Le tableau « Corrélation entre le pourcentage de disponibilité et les temps morts du calendrier » identifie les temps morts pour chaque neuf de disponibilité. Les mesures suivantes sont utilisées pour calculer la disponibilité :

  • Temps moyen entre les défaillances (MTBF) : intervalle prévu entre deux défaillances consécutives pour un système réparable.

  • Temps moyen jusqu’à défaillance (MTTF) : intervalle prévu jusqu’à défaillance pour un système irréparable.

  • Temps moyen jusqu’à réparation ou remplacement (MTTR) : intervalle prévu jusqu’à réparation ou remplacement d’un composant défaillant.

La formule suivante permet de calculer la disponibilité : Disponibilité = MTBF/(MTTF+MTTR). Vous pouvez utiliser cette formule pour calculer la disponibilité totale et l’améliorer en utilisant des composants matériels et logiciels plus fiables afin d’augmenter le MTTF et de diminuer le MTTR.

Relation entre performances et disponibilité

Les performances ne sont pas indépendantes de la disponibilité. Les fournisseurs de services et les clients définissent des points de référence de performances quantifiables pour les niveaux de services en cas de fonctionnement dans des conditions normales. Toutefois, une réduction de la disponibilité se produit lorsqu’un événement extraordinaire a un impact significatif sur les performances, rendant le système pratiquement inutilisable. Par définition, la batterie de serveurs n’est pas disponible. Voici des exemples typiques d’événements extraordinaires :

  • Attaques par déni de service sur les serveurs Web publics

  • Requêtes au format incorrect qui utilisent des ressources de serveur de base de données en fonctionnement ou des transactions de base de données qui verrouillent les tables

  • Défaillances sur un réseau étendu (WAN) ou latence réseau élevée causées par des événements à d’autres emplacements

Comme de plus en plus d’organisations passent à des environnements hébergés ou des batteries de serveurs SharePoint répartis géographiquement, la latence réseau est essentielle pour la planification de la disponibilité.

Un processus implémentant la haute disponibilité est l’un des investissements les plus onéreux pour une batterie de serveurs SharePoint. À mesure que le niveau de disponibilité et le nombre de systèmes que vous voulez rendre hautement disponibles augmentent, la complexité et le coût de la solution de disponibilité augmentent également. Les coûts suivants s’inscrivent généralement dans un investissement dans la haute disponibilité :

  • Composants d’infrastructure supplémentaires, tels que les cartes réseau, les commutateurs et l’alimentation pour la redondance.

  • Matériel, logiciel ou licences logicielles supplémentaires permettant de prendre en charge divers rôles de batterie fournissant une redondance de charge de travail dans l’architecture de batterie de serveurs.

  • Matériel de rechange pour remplacer un équipement défaillant.

    Bien qu’il soit courant de préparer des ordinateurs de rechange dans différents états de disponibilité à utiliser pour des opérations de maintenance de routine ou pour remplacer un serveur défaillant, votre investissement se concrétise par du matériel inutilisé.

    RemarqueRemarque :
    Les progrès réalisés en matière de technologie de virtualisation permettent aux organisations d’utiliser des ordinateurs virtuels comme disques d’échange à chaud ou à froid. Les ordinateurs virtuels peuvent fournir la même fonctionnalité. La virtualisation peut fournir souplesse et rentabilité. Toutefois, vous devez vous assurer qu’un ordinateur virtuel est capable de gérer la charge de l’ordinateur physique qu’il remplace.
  • Augmentation des coûts de maintenance et de prise en charge proportionnelle au niveau de disponibilité et aux solutions utilisées pour satisfaire les exigences de disponibilité.

  • Modifications anticipées de la batterie de serveurs, telles que la montée en puissance. Lors de la montée en puissance d’une batterie de serveurs, la solution de disponibilité doit pouvoir refléter toutes les modifications de la topologie de batterie. Les coûts augmenteront probablement.

  • Système d’alerte et de détection robuste pour une détection rapide des pannes. Ce système peut utiliser les outils de détection des pannes existants et inclure des outils d’alerte et d’analyse de l’intégrité tels que System Center Operations Manager.

  • Coûts d’intégration ou de personnalisation requis pour implémenter la haute disponibilité pour la batterie ou pour satisfaire les exigences plus générales du centre de données.

Évaluez le coût d’une meilleure disponibilité dans le contexte de vos principaux besoins professionnels. Dans de nombreux cas, toutes les unités d’organisation ne nécessitent pas le même niveau de disponibilité. Pensez à faire varier les niveaux de disponibilité des différents sites, services ou batteries.

Pour revenir au tableau « Corrélation entre le pourcentage de disponibilité et les temps morts du calendrier », un score de cinq neuf de disponibilité signifie que sur une année, le système est indisponible pendant uniquement 5,26 minutes ! Si vous pouvez atteindre ce niveau de disponibilité, le coût reste cependant prohibitif pour de nombreuses organisations. La décision clé consiste à déterminer à quel stade un investissement dans un neuf de disponibilité supplémentaire ne représente plus un avantage par rapport à l’impact d’une défaillance.

L’illustration suivante indique comment distribuer et configurer différentes parties d’un environnement SharePoint pour augmenter la disponibilité dans une batterie. Cet exemple montre également comment la redondance peut résoudre les domaines d’erreur.

RemarqueRemarque :
Notre exemple n’est pas exhaustif. Il ne présente pas tous les domaines d’erreur ni l’ensemble du matériel à tolérance de panne.

Exemples de redondance dans une topologie de batterie de serveurs pour résoudre les points de défaillance

Exemple de batterie de serveur montrant comment les rôles et services redondants sont utilisés pour adresser les points de défaillance unique.

En ce qui concerne la topologie figurant dans l’illustration précédente, notez les points suivants :

  • La batterie de serveurs figurant dans cet exemple peut correspondre à des ordinateurs physiques ou virtuels déployés sur des serveurs hôtes Hyper-V. Le principe d’identification et de réponse aux points de défaillance s’applique aux deux types d’environnement.

  • Quatre serveurs (W1-W4) sont dédiés à la fourniture de contenu et cette redondance augmente la disponibilité en cas de défaillance dans un ou plusieurs serveurs. Ce niveau de redondance permet également à la batterie de continuer à fonctionner lors de l’application des mises à jour logicielles.

  • Quatre serveurs d’applications (A1-A4) augmentent la disponibilité des services de batterie et des composants d’application spécifiques tels que la recherche. Les rôles et composants de recherche sont redondants. Pour plus d’informations sur la disponibilité de la recherche, voir Mettre à l’échelle la recherche pour les sites Internet dans SharePoint Server 2013

  • Les serveurs de base de données de batterie sont redondants et la haute disponibilité de base de données peut être atteinte à l’aide de la mise en miroir ou du clustering de base de données.

  • Dans un environnement virtuel, les ordinateurs virtuels sont placés sur des serveurs hôtes Hyper-V distincts pour éliminer un point de défaillance unique. Cette approche en matière de sélection élective des ordinateurs virtuels suit les instructions relatives aux meilleures pratiques en matière de disponibilité et de performances.

  • Le premier serveur de base de données (numéroté 1) et le rack 2 (numéroté 2), qui contient deux des ordinateurs hôtes de virtualisation, sont identifiés comme les domaines d’erreur pour afficher la façon dont votre batterie et votre infrastructure peuvent être visualisées en tant que collection de domaines d’erreur. Cette illustration indique comment effectuer une analyse approfondie de votre environnement pour développer une stratégie globale et une analyse coûts-avantages.

Autres rôles et services de batterie

Notre exemple n’inclut pas tous les rôles, services et applications de service susceptibles d’être exécutés dans une batterie SharePoint spécifique. Vous ne pouvez pas utiliser une approche générique de haute disponibilité pour tous les éléments d’une batterie SharePoint. Il existe des exclusions importantes en ce qui concerne l’adoption d’une approche standard de haute disponibilité. Ces exclusions sont les suivantes :

Une fois que vous avez conçu une architecture prenant en charge les rôles et les charges de travail hautement disponibles, vous pouvez utiliser des composants à tolérance de panne pour optimiser la disponibilité. Les solutions à tolérance de panne sont disponibles dans toute l’infrastructure, bases de données incluses.

La tolérance de panne est disponible pour la quasi-totalité des composants matériels dans l’infrastructure d’une batterie SharePoint. Dans le cadre de votre conception de haute disponibilité, déterminez les parties de l’infrastructure devant être à tolérance de panne d’un point de vue opérationnel et financier. La possibilité de rendre chaque partie de l’infrastructure à tolérance de panne ne vous y oblige pas pour autant.

Étant donné que la plateforme SharePoint et ses charges de travail d’application dépendent de la disponibilité et de la fiabilité de toutes les bases de données SharePoint, les bases de données hautement disponibles constituent un aspect essentiel de votre stratégie de haute disponibilité. Vous pouvez utiliser les fonctionnalités suivantes en tant que solutions à tolérance de panne pour les serveurs de base de données et bases de données UNRESOLVED_TOKEN_VAL(SharePointAll_2nd_NoVer) :

  • Clustering de basculement SQL Server (instances de cluster de basculement AlwaysOn dans SQL Server 2012)

  • Mise en miroir de bases de données SQL Server de haute disponibilité

  • Groupes de disponibilité AlwaysOn

ImportantImportant :
SQL Server 2012 AlwaysOn est disponible uniquement dans SQL Server Enterprise.

À propos des instances de cluster de basculement AlwaysOn et des groupes de disponibilité AlwaysOn

Un cluster de basculement nécessite un stockage sur disque partagé entre deux ordinateurs. Dans une configuration à deux nœuds, les ordinateurs sont configurés comme actif/passif, fournissant ainsi une instance entièrement redondante du nœud principal. Le nœud passif est uniquement mis en ligne lorsque le nœud principal échoue. Le disque partagé n’est présenté qu’à un ordinateur à la fois. Cette configuration est celle qui nécessite généralement le plus de matériel supplémentaire. Dans SQL Server 2012, ce type de configuration de cluster est une instance de cluster de basculement AlwaysOn et il représente une méthode spécifique d’installation de SQL Server. En raison de la configuration requise, vous ne pouvez pas procéder à une installation standard de SQL Server puis passer facilement à une instance de cluster de basculement.

Un groupe de disponibilité AlwaysOn représente une autre technologie dans SQL Server 2012 (voyez-le comme le descendant de la mise en miroir de bases de données), qui utilise certaines fonctionnalités exposées par le clustering Windows. Toutefois, un groupe de disponibilité ne nécessite pas de stockage sur disque partagé, et les ordinateurs d’un groupe de disponibilité ne nécessitent pas l’installation d’une configuration spécialisée de SQL Server. Une fois qu’un serveur de base de données est ajouté à un cluster Windows, il est assez simple d’activer les groupes de disponibilité AlwaysOn, puis de configurer le groupe de disponibilité souhaité.

En résumé, tout serveur exécutant SQL Server 2012 Enterprise Edition peut utiliser les groupes de disponibilité AlwaysOn en rejoignant un cluster et en configurant le groupe de disponibilité. Les clusters de basculement AlwaysOn nécessitent des étapes de configuration et du matériel spéciaux pour configurer les instances de cluster de basculement. Chacune de ces technologies a son utilisation pour des environnements spécifiques et elles constituent des solutions complémentaires. Pour plus d’informations sur ces fonctionnalités, voir le Guide des solutions AlwaysOn Microsoft SQL Server pour la haute disponibilité et la récupération d’urgence.

ImportantImportant :
Étant donné que chaque option de haute disponibilité SQL Server a ses propres fonctionnalités, forces et faiblesses, une option n’est pas nécessairement meilleure qu’une autre. Par exemple, dans un scénario donné utilisant les groupes de disponibilité AlwaysOn, la minimisation de la perte de données peut être plus appropriée que tout gain de performances atteint grâce aux instances de cluster de basculement AlwaysOn. Vous devez choisir une solution de haute disponibilité basée sur vos besoins professionnels et exigences d’infrastructure informatique.

Les bases de données SharePoint constituent un facteur déterminant dans la sélection d’une option SQL Server. Vous devez comprendre les caractéristiques des bases de données SharePoint 2013. Chaque base de données peut impliquer des exigences ou des contraintes spécifiques qui déterminent la solution à tolérance de panne SQL Server appropriée et entièrement prise en charge dans votre environnement de production. Nous vous recommandons de consulter les articles suivants :

Le clustering de basculement permet une prise en charge de la disponibilité pour une instance de SQL Server sur SQL Server 2008 R2 avec Service Pack 1 (SP1) ou SQL Server 2012.

RemarqueRemarque :
Le clustering de basculement SQL Server est renommé Instances de cluster de basculement AlwaysOn dans SQL Server 2012. Pour plus de simplicité, le terme clustering de basculement s’applique au clustering de basculement SQL Server dans SQL Server 2008 R2 avec Service Pack 1 (SP1) ou aux instances de cluster de basculement AlwaysOn dans SQL Server 2012.

Un cluster de basculement est une combinaison d’un ou plusieurs nœuds ou serveurs et d’au moins deux disques partagés. Bien qu’une instance de cluster de basculement apparaisse comme un seul ordinateur, elle permet un basculement d’un nœud vers un autre si le nœud actuel devient indisponible. SharePoint 2013 peut être exécuté sur toute combinaison de nœuds actifs et passifs dans un cluster pris en charge par SQL Server.

SharePoint 2013 fait référence au cluster dans son ensemble. Par conséquent, le basculement est automatique et transparent du point de vue de SharePoint 2013.

RemarqueRemarque :
Lorsqu’un basculement planifié ou non planifié se produit, les connexions sont abandonnées et doivent être établies à nouveau lors de la transition d’un nœud de cluster à un autre.

Pour plus d’informations sur le clustering de basculement SQL Server, voir les articles suivants :

Le principal avantage des groupes de disponibilité AlwaysOn SQL Server et de la mise en miroir de bases de données SQL Server est qu’ils fournissent tous les deux une redondance des données complète ou quasi complète en fonction de leur configuration pour le traitement des transactions. Outre la minimisation de la perte de données, le basculement automatique permet de diminuer les temps morts pour les bases de données de production.

ImportantImportant :
Si SQL Server 2012 prend en charge la mise en miroir de bases de données, cette fonctionnalité est déconseillée. Nous vous recommandons d’éviter de l’utiliser dans tout nouveau développement. Pensez à modifier les applications qui utilisent actuellement cette fonctionnalité. Utilisez plutôt les groupes de disponibilité AlwaysOn.

Groupes de disponibilité AlwaysOn

La fonctionnalité des groupes de disponibilité AlwaysOn SQL Server est une solution de haute disponibilité et de récupération d’urgence qui fournit une alternative à la mise en miroir de bases de données au niveau de l’entreprise. Les groupes de disponibilité AlwaysOn prennent en charge un environnement de basculement pour les bases de données utilisateur contenues dans une collection définie par l’utilisateur. Un groupe de disponibilité est constitué des éléments suivants :

  • des réplicas, qui sont un ensemble distinct de bases de données utilisateur appelées bases de données de disponibilité et traitées comme une seule unité. Chaque groupe de disponibilité prend en charge un réplica principal et jusqu’à quatre réplicas secondaires ;

  • une instance spécifique de SQL Server pour héberger chaque réplica et tenir à jour une copie locale de chaque base de données qui appartient au groupe de disponibilité.

Lorsqu’un groupe de disponibilité bascule vers une instance cible ou un serveur cible, toutes les bases de données du groupe basculent également. SQL Server 2012 pouvant héberger plusieurs groupes de disponibilité sur un même serveur, vous pouvez configurer AlwaysOn pour un basculement vers des instances SQL Server sur différents serveurs. Cela évite que des serveurs de secours à hautes performances inactifs soient contraints de gérer la charge complète du serveur principal, ce qui constitue l’un des principaux avantages offerts par les groupes de disponibilité.

RemarqueRemarque :
Les problèmes liés aux bases de données (tels que la perte d’un fichier de données, la suppression d’une base de données ou l’endommagement d’un journal des transactions) ne provoquent pas de basculement.

Pour plus de détails sur les avantages offerts par les groupes de disponibilité AlwaysOn et pour obtenir une vue d’ensemble de la terminologie associée, voir Groupes de disponibilité AlwaysOn (SQL Server).

Mise en miroir de bases de données

La mise en miroir de bases de données fournit une redondance de base de données en conservant une copie en miroir des bases de données sur le serveur de base de données principal. La mise en miroir est implémentée pour chaque base de données et fonctionne uniquement avec les bases de données qui utilisent le mode de récupération complète.

RemarqueRemarque :
Il existe deux modes de fonctionnement de la mise en miroir. L’un des deux, le mode haute sécurité, prend en charge les opérations synchrones. En mode haute sécurité, lorsqu’une session démarre, le serveur miroir synchronise la base de données miroir et la base de données principale aussi rapidement que possible. Une fois les bases de données synchronisées, une transaction est écrite dans le journal sur le serveur secondaire, puis relue. (Le serveur principal reprend le contrôle dès que la transaction est renforcée.) L’autre mode de mise en miroir est le mode haute performance, c’est-à-dire qu’il utilise des opérations asynchrones pour réduire la latence des transactions, au prix d’une augmentation de la perte de données.

Pour la mise en miroir haute disponibilité dans une batterie de serveurs SharePoint, vous devez utiliser le mode haute sécurité avec basculement automatique. La mise en miroir haute sécurité de bases de données nécessite trois instances de serveur : un serveur principal, un serveur miroir et un serveur témoin. Le serveur témoin permet à SQL Server de basculer automatiquement du serveur principal sur le serveur miroir. Le basculement de la base de données principale sur la base de données miroir prend généralement plusieurs secondes.

Pour obtenir des informations générales sur la mise en miroir de bases de données, voir Mise en miroir de bases de données.

ImportantImportant :
Les bases de données configurées pour utiliser le fournisseur du magasin d’objets BLOB distant FILESTREAM SQL Server ne peuvent pas être mises en miroir.

Le choix d’une technologie SQL Server pour la haute disponibilité et la récupération d’urgence doit être basé sur les buts professionnels de votre entreprise en ce qui concerne l’objectif de point de récupération (RPO) et l’objectif de temps de récupération (RTO). Si le RPO et le RTO sont généralement associés à la récupération d’urgence, certains événements de défaillance sont hors de l’étendue d’urgence, mais nécessitent une récupération à partir du support de sauvegarde local dans le centre de données principal.

ImportantImportant :
En fonction de la base de données particulière, les différentes bases de données SharePoint 2013 ne prennent en charge que des options de haute disponibilité SQL Server spécifiques. Pour plus d’informations, voir Options de haute disponibilité et de récupération d’urgence prises en charge pour les bases de données SharePoint (SharePoint 2013).

Le tableau suivant propose une comparaison générale des résultats de RPO et de RTO auxquels les solutions SQL Server disponibles parviennent.

RemarqueRemarque :
Les durées du tableau suivant permettent de comparer les options de base de données. En pratique, les durées dépendent de la charge de travail, du volume de données et des procédures de basculement.

Comparaison du RPO et du RTO en fonction de la technologie de base de données

Solution SQL Server Perte de données potentielle (RPO) Temps de récupération potentiel (RTO) Basculement automatique Secondaires accessibles en lecture
ImportantImportant :
SharePoint 2013 ne prend pas en charge cette configuration.

Groupe de disponibilité AlwaysOn (validation synchrone)

Zéro

Secondes

Oui

0-2

Groupe de disponibilité AlwaysOn (validation asynchrone)

Secondes

Minutes

Non

0-4

Instance de cluster de basculement AlwaysOn

Non applicable

Une instance de cluster de basculement ne fournit pas de protection des données. Le volume de perte de données dépend de l’implémentation du système de stockage.

Secondes voire minutes

Oui

Non applicable

Mise en miroir de bases de données - Haute sécurité (mode synchrone + serveur témoin)

Zéro

Secondes

Oui

Non applicable

Mise en miroir de bases de données - Haute performance (mode asynchrone)

Secondes

Minutes

Non

Non applicable

Sauvegarde, copie, restauration

Heures ou zéro si le processus du journal est accessible après la défaillance

Heures voire jours

Non

Pas lors d’une restauration

Comparaison du cluster SQL Server, du groupe de disponibilité AlwaysOn et du miroir de bases de données

Cluster de basculement SQL Server Groupe de disponibilité AlwaysOn SQL Server 2012 Miroir haute disponibilité SQL Server

Temps nécessaire au basculement

Le membre de cluster prend le relais quasi immédiatement après la défaillance. Un décalage se produit lorsque le nœud du cluster subit une rotation vers le haut.

Le réplica prend le relais quasi immédiatement après la défaillance. Un décalage se produit lorsque le réplica secondaire subit une rotation vers le haut.

Le miroir prend le relais dès que la file d’attente de restauration par progression est traitée.

Cohérence transactionnelle

Oui

Oui

Oui

Simultanéité transactionnelle

Oui

Oui

Oui

Temps jusqu’à la récupération

Temps de récupération inférieur à celui d’un groupe de disponibilité

Temps de récupération inférieur à celui d’un cluster de basculement, mais récupération plus rapide qu’avec une solution mise en miroir

Temps de récupération légèrement supérieur à celui d’un cluster ou groupe de disponibilité

Étapes nécessaires pour le basculement

Les nœuds de base de données détectent automatiquement une défaillance.

SharePoint 2013 fait référence au cluster de sorte que le basculement soit transparent et automatique.

L’écouteur de groupe de disponibilité détecte automatiquement une défaillance et le basculement est transparent et automatique.

La base de données détecte automatiquement une défaillance.

SharePoint 2013 connaît l’emplacement du miroir, si celui-ci a été configuré correctement de sorte que le basculement soit automatique.

Protection contre les défaillances de stockage

Le cluster de basculement ne fournit pas de protection des données. Le volume de perte de données dépend de l’implémentation du système de stockage. Par exemple, un environnement SAN a des composants redondants comme plusieurs chemins de fichiers, RAID et disques d’échange à chaud.

Protège contre les défaillances de stockage car le réplica principal écrit sur les disques locaux des réplicas secondaires.

Protège contre les défaillances de stockage car les serveurs de base de données principal et miroir écrivent sur des disques locaux.

Types de stockage pris en charge

Nécessite un stockage partagé, qui est plus onéreux que le stockage dédié.

Peut utiliser des solutions de stockage directement attachées et moins onéreuses.

Peut utiliser un stockage directement attaché et moins onéreux.

Exigences en matière d’emplacement

Les membres du cluster doivent se trouver sur le même sous-réseau.

RemarqueRemarque :
Ce n’est pas le cas avec SQL Server 2012.

Les réplicas peuvent se trouver sur différents sous-réseaux tant que la latence n’entraîne pas de problèmes de performances.

Le serveur principal, le serveur miroir et le serveur témoin doivent se trouver sur le même réseau local (boucle de latence allant jusqu’à 1 milliseconde).

Mode de récupération

Mode de récupération complète SQL Server recommandé. Vous pouvez utiliser le mode de récupération simple SQL Server. Toutefois, en cas de perte du cluster, le seul point de récupération disponible sera la dernière sauvegarde complète.

Nécessite le mode de récupération complète SQL Server 2012.

Nécessite le mode de récupération complète SQL Server.

Dégradation des performances

Une diminution des performances peut se produire lors d’un basculement. Le serveur peut être indisponible lors du basculement et les connexions sont abandonnées, puis rétablies sur le nouveau nœud actif.

Les groupes de disponibilité AlwaysOn introduisent une latence transactionnelle en raison de la validation synchrone sur les réplicas secondaires. Le volume de latence dépend du nombre de réplicas secondaires devant être synchronisés.

La surcharge de mémoire et de processeur est supérieure à celle du clustering, mais inférieure à celle de la mise en miroir.

La mise en miroir de haute disponibilité introduit une latence transactionnelle car elle est synchrone. Elle implique également une surcharge de mémoire et de processeur supplémentaire.

Surcharge opérationnelle

Configurée et maintenue au niveau du serveur.

La surcharge opérationnelle est supérieure à celle du clustering et de la mise en miroir. AlwaysOn nécessite une surcharge au niveau du serveur de base de données SQL Server en plus du niveau Windows Server.

RemarqueRemarque :
Les objets de niveau serveur tels que les ouvertures de session et les travaux d’agent doivent être maintenus manuellement.

Si vous ajoutez des bases de données de contenu, vous devez les ajouter à un groupe de disponibilité, puis synchroniser le réplica principal avec les réplicas secondaires.

Un environnement de batterie de serveurs SharePoint nécessite plusieurs étapes de configuration pour que la chaîne de connexion SharePoint 2013 soit correctement associée au nom d’écouteur de groupe de disponibilité.

La surcharge opérationnelle est supérieure à celle du clustering. Elle doit être configurée et maintenue pour toutes les bases de données. La reconfiguration après basculement est manuelle.

RemarqueRemarque :
Les objets de niveau serveur tels que les ouvertures de session et les travaux d’agent doivent être maintenus manuellement.

Si vous ajoutez des bases de données de contenu, vous devez les ajouter au serveur principal, puis synchroniser le serveur principal avec le serveur miroir.

Certaines entreprises possèdent des centres de données qui sont proches les uns des autres et connectés par des liens de fibre optique à large bande passante. Lorsque cet environnement est disponible, il est possible de configurer les deux centres de données en tant que batterie de serveurs unique. Cette topologie de batterie de serveurs distribuée est appelée batterie de serveurs « étendue ».

Pour qu’une architecture de batterie de serveurs étendue fonctionne en tant que solution de haute disponibilité prise en charge, les conditions préalables suivantes doivent être remplies :

  • Il existe dans la batterie de serveurs une latence hautement cohérente de moins de 1 ms (à sens unique) 99,9 % du temps sur une période de dix minutes. (La latence dans la batterie de serveurs est généralement définie comme la latence entre les serveurs Web frontaux et les serveurs de base de données.)

  • La vitesse de bande passante doit être d’au moins 1 gigabit par seconde.

Pour autoriser la tolérance de panne dans une batterie étendue, consultez les instructions des meilleures pratiques standard pour configurer les applications de service et les bases de données redondantes.

L’illustration suivante présente une batterie étendue.

Batterie de serveurs étendue

Topologie de batterie de serveurs étendue utilisant deux centres de données pour fournir une haute disponibilité.

Votre stratégie de haute disponibilité doit inclure les opérations de sauvegarde et de restauration appropriées pour vous assurer que la batterie de serveurs est résiliente. En cas d’incident, comme une défaillance de support ou une erreur utilisateur, vous devez être capable de restaurer la partie de l’environnement de la batterie de serveurs ou des données de batterie de serveurs touchée au moment opportun. Une solution de sauvegarde et de restauration efficace doit vous permettre d’atteindre les objectifs de temps de récupération (RTO) et de point de récupération (RPO) que vous avez définis.

Pour plus d’informations, voir Sauvegarde et restauration de SharePoint 2013.

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft