Comportement de récupération de réplication continue en cluster
S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Dernière rubrique modifiée : 2007-10-29
La réplication continue en cluster (CCR) offre une redondance totale des données et des services donnant accès aux données. La redondance totale permet une récupération rapide dans les cas où une copie partagée de données de boîte aux lettres ne permettrait pas une récupération rapide.
Les comportements de récupération de CCR se distinguent selon deux types d'interruption :
Interruptions programmées Ces interruptions sont déclenchées par l'administrateur. Une interruption programmée permet de récupérer d'un échec détecté par le système d'analyse ou d'effectuer certaines tâches administratives, telles que la maintenance du matériel, l'installation de logiciels ou des mises à jour logicielles.
Interruptions non programmées Ces interruptions sont déclenchées par le système en guise d'action de récupération suite à la détection d'une défaillance. Ces interruptions sont détectées et leur récupération est déclenchée par le service de cluster de Windows.
Le tableau suivant décrit les actions de récupération prévues pour diverses défaillances. Certaines défaillances requièrent que l'administrateur déclenche la récupération, tandis que d'autres sont automatiquement gérées par la solution de clustering Exchange.
Actions de récupération pour les défaillances
| Description | Action | Commentaires |
|---|---|---|
Erreur d'arrêt de système d'exploitation, système d'exploitation détecté cessant de répondre, panne d'électricité totale d'un noeud, erreur irrécupérable du microprocesseur, défaillance de carte mère, de carte d'insertion ou de communication pour un noeud |
Basculement automatique vers un noeud passif, si disponible. L'administrateur a également la possibilité de forcer un montage automatique indépendant de la perte de données si aucune récupération ne s'est produite au cours d'une période configurée. Si aucune base de données n'est montée après le basculement et que le noeud actif d'origine revient en ligne avec tout son stockage opérationnel, les journaux manquants sont copiés et les bases de données montées automatiquement. |
Pour qu'un noeud passif soit disponible, il doit être possible d'établir un quorum après l'échec. Cela signifie que le noeud restant doit pouvoir accéder au quorum de partage de fichiers. Cela signifie également qu'une majorité des noeuds figurant dans le cluster doivent être opérationnels et capables de communiquer entre eux. |
Défaillance de stockage totale sur le serveur actif |
Défaillances de stockage rapportées au système d'analyse et via ce dernier. L'administrateur peut récupérer le stockage ou déclencher une interruption programmée sur le noeud passif. |
Cette défaillance est signalée comme une défaillance de toutes les bases de données. |
Défaillance du centre de données |
En cas de défaillance du noeud actif dans le centre de données principal, basculement automatique du serveur de boîtes aux lettres en cluster vers le noeud passif dans le deuxième centre de données. |
D'autres Exchange, services d'annuaire, services de mise en réseau et serveurs doivent être récupérés pour continuer à assurer l'accès à la messagerie. Les données de messagerie sont disponibles et à jour en quelques minutes. |
Défaillance du lecteur du système d'exploitation |
Aucune action de récupération automatique. Non détectée par Exchange, sauf en cas de défaillance du système d'exploitation. Détectée sur la base d'échecs apparents plutôt que d'une cause principale. |
Une défaillance du lecteur du système d'exploitation est signalée par l'analyse du système d'exploitation et peut entraîner une défaillance du système d'exploitation. |
Espace du lecteur du système d'exploitation insuffisant |
Basculement automatique vers un noeud passif, si disponible. |
Cette défaillance est signalée aux services de surveillance et via ces derniers. Si aucune récupération n'a lieu ou ne peut avoir lieu, l'action de récupération relative à ce scénario est déterminée par l'administrateur. |
Échec complet du réseau public du cluster |
Aucune action de récupération automatique. |
En cas de perte du réseau public, les ressources d'adresses IP entrent en état d'échec. Une fois le problème de réseau public résolu, les ressources peuvent être remises en ligne. |
Perte de quorum de cluster |
Serveurs de boîtes aux lettres en cluster et quorum de cluster en mode hors connexion. |
Ce scénario entraîne l'absence de service en cas d'impossibilité de former un quorum. |
Échec de la banque d'informations |
Redémarrage automatique de la ressource de banque d'informations. Si la défaillance de la ressource de banque d'informations se produit durant un redémarrage, un basculement est déclenché. |
Après plusieurs défaillances, l'administrateur peut tenter de déplacer manuellement le serveur de boîtes aux lettres vers le nœud passif pour le mettre en ligne. |
Échec de lecteur d'application (fichiers binaires) |
Aucune action de récupération automatique. |
Généralement, ce scénario entraîne d'autres défaillances qui sont signalées aux services de surveillance et via ces derniers, et auxquelles l'administrateur peut appliquer des actions. L'action de récupération relative à ce scénario est déterminée par l'administrateur. |
Espace disque du lecteur d'application (fichiers binaires) insuffisant |
Aucune action de récupération automatique. |
Cet incident est rapporté aux services de surveillance et via ces derniers. L'action de récupération relative à ce scénario est déterminée par l'administrateur. |
Perte totale de base de données ou de groupe de stockage, ou défaillance totale de la base de données |
Tentative automatique de remontage des bases de données affectées. En cas d'échec de cette tentative, la boîte de dialogue reste en état d'échec mais aucun basculement du serveur de boîtes aux lettres en cluster n'a lieu. |
Le groupe de stockage ou la base de données est soit démonté suite à une défaillance ou un endommagement logiciel, soit en échec en raison de défaillances matérielles. Par exemple, un groupe de stockage force le démontage de toutes les bases de données lorsque son répertoire du journal est indisponible. L'administrateur détermine l'action corrective. |
Défaillance partielle du groupe de stockage ou de la base de données, indisponibilité de certaines données ou échec de montage de base de données initial |
Aucune action de récupération automatique. |
Échec partiel signifie que des endommagements ont été signalés mais que ces derniers n'ont pas forcé le démontage du groupe de stockage ou de la base de données. Si une base de données n'est pas montée au démarrage, aucune action n'est exécutée et la surveillance signale l'échec. Le serveur de boîtes aux lettres génère des événements suite à la détection de ce problème. Cela peut être signalé par les services de surveillance. La surveillance détecte et signale également les bases de données démontées. |
Journal endommagé détecté pour le groupe de stockage |
Aucune action de récupération automatique. La copie se trouve dans une condition interrompue et doit être réamorcée. |
La surveillance signale cette condition. |
Espace insuffisant du lecteur des journaux de la base de données ou des transactions |
Aucune action de récupération automatique. Les bases de données composant le groupe de stockage sont démontées. |
La condition d'espace disque insuffisant est signalée via le système de surveillance. L'administrateur détermine l'action corrective. |
L'administrateur dispose d'un contrôle de configuration sur la récupération après interruption non programmée. Pour plus d'informations sur les interruptions programmées et non programmées, consultez la rubrique Interruptions programmées et non programmées.