Haute disponibilité et récupération d’urgence

Important

Cette version d’Operations Manager a atteint la fin du support. Nous vous recommandons de mettre à niveau vers Operations Manager 2022.

System Center : les serveurs et les fonctionnalités Operations Manager peuvent potentiellement échouer, ce qui affecte les fonctionnalités d’Operations Manager. La quantité de données et de fonctionnalités perdues lors d'une défaillance est différente dans chaque scénario de panne. Cela dépend du rôle de la fonctionnalité défaillante et de la durée nécessaire à la récupération de la fonctionnalité défaillante.

Haute disponibilité

Pour répondre aux besoins en matière de haute disponibilité, vous pouvez créer une redondance dans le groupe d’administration pour les bases de données d’entrepôt de données et les bases de données opérationnelles Operations Manager, pour la passerelle et les serveurs d’administration, ainsi que pour certaines charges de travail. Ces charges de travail incluent les charges de travail relatives à l’analyse des périphériques réseau, à l’analyse multiplateforme, ainsi qu’aux groupes d’administration, qui étaient gérées auparavant par le serveur d’administration racine.

La configuration avec plusieurs serveurs et un seul groupe d’administration peut utiliser SQL Server Always On pour assurer la haute disponibilité et la continuité du service des bases de données Operations Manager. La tolérance de panne du serveur d’administration est possible avec au moins deux serveurs d’administration et l’utilisation de pools de ressources pour la supervision des serveurs UNIX, des serveurs Linux et des appareils réseau. Les serveurs Windows basés sur les agents peuvent être configurés à l’aide d’un serveur d’administration principal et secondaire pour rediriger les communications des agents, en cas de panne du serveur d’administration.

L’émulateur RMS peut également être déplacé vers un autre serveur d’administration, en cas d’indisponibilité du serveur d’administration qui héberge l’émulateur RMS.

Vous pouvez rendre les connexions à la console Opérateur hautement disponibles en configurant la haute disponibilité pour les services d’accès aux données. Pour ce faire, vous pouvez installer l’équilibrage de charge réseau Microsoft (NLB) ou utiliser des équilibreurs de charge matériels ou un alias DNS. Un ou plusieurs serveurs d’administration sont ajoutés en tant que membres du pool d’équilibrage de la charge réseau. Lorsque vous ouvrez la console, vous référencez le nom virtuel des serveurs d’administration à charge équilibrée, qui est inscrit dans DNS.

Notes

Une Load Balancer réseau n’est pas prise en charge pour le serveur de console web Operations Manager.

Plusieurs serveurs de passerelle peuvent être déployées dans une limite d'approbation pour fournir des chemins redondants pour les agents qui s'étendent au-delà de cette limite d'approbation. Comme les agents peuvent basculer entre un serveur d'administration principal et un ou plusieurs serveurs d'administration secondaires, ils peuvent également basculer entre des serveurs de passerelle. En outre, plusieurs serveurs de passerelle peuvent être utilisés pour distribuer la charge de travail de gestion des ordinateurs gérés sans agent et des périphériques réseau gérés.

En plus de fournir la redondance via le basculement agent-passerelle, les serveurs de passerelle peuvent être configurés pour basculer entre des serveurs d'administration d'un groupe d'administration si plusieurs serveurs d'administration sont disponibles.

Bien que SQL Server Reporting Services prenne en charge un modèle de déploiement avec montée en puissance parallèle qui vous permet d’exécuter plusieurs instances de serveur de rapports qui partagent une seule base de données de serveur de rapports, il n’est pas pris en charge avec Operations Manager. Operations Manager Reporting installe une extension de sécurité personnalisée dans le cadre de la configuration des composants front-end, qui ne peuvent pas être répliqués sur la batterie de serveurs web.

Récupération d'urgence

La reprise d’activité désigne les mesures prises pour assurer la reprise des opérations en cas de défaillance grave (par exemple, la perte du centre de données qui héberge l’infrastructure principale). Il s’agit d’un élément important qui doit être pris en compte dans tout déploiement et les décisions prises lors de la planification de la récupération d’urgence affectent la façon dont Operations Manager sera en mesure de continuer à prendre en charge la surveillance proactive et la création de rapports sur les performances et la disponibilité de vos services informatiques critiques. Cette section traite de la stratégie recommandée pour la récupération d’urgence et la résilience, et donne les étapes à suivre pour garantir une récupération sans heurts.

Bien que les solutions de haute disponibilité et de récupération d’urgence fournissent une protection contre les défaillances système ou la perte de système, elles ne doivent pas être utilisées pour la protection contre la perte ou l’altération accidentelle, involontaire ou malveillante de données. Dans ce cas, les copies de réplication copiées de sauvegarde ou en retard peuvent être utilisées pour les opérations de restauration. Dans de nombreux cas, la restauration est la forme de récupération d’urgence qui convient le mieux. C’est la cas, par exemple, pour une base de données de création de rapports ou des données d’analyse dont la priorité est peu élevée. Souvent, le coût que représente l’activation de la récupération d’urgence multisite au niveau du système ou des applications dépasse largement la valeur des données. Dans les cas où la valeur à court terme des données est faible et la nécessité d’accéder aux données peut être retardée sans impact important sur l’activité en cas de défaillance ou de la récupération d’urgence d’un site, vous pouvez utiliser des processus simples de sauvegarde et de restauration pour la récupération d’urgence, si votre budget le permet.

Le fait de connaître l’impact et la tolérance de panne en cas de temps mort vous permettra de prendre les décisions nécessaires pour concevoir correctement l’architecture d’Operations Manager, et de comprendre le niveau de complexité et le coût requis pour prendre en charge la récupération d’urgence. Par ailleurs, tenez compte du degré de perte de données de supervision que votre service informatique peut tolérer sans conséquence sur l’activité de l’entreprise. On parle alors d’objectif de délai de récupération et d’objectif de point de récupération.

Pour Operations Manager, les deux configurations les plus courantes pour la conception de la récupération d’urgence sont les suivantes :

• Création d’un groupe d’administration en double déployé sur votre centre de données secondaire qui duplique à l’échelle et à la configuration du groupe d’administration principal.
• Déploiement de serveurs supplémentaires dans un centre de données secondaire pour prendre en charge la base de données opérationnelle et la base de données de l’entrepôt de données, avec des serveurs d’administration déployés dans une configuration de secours à froid, ne participant pas au groupe d’administration tant qu’aucune action de récupération n’est nécessaire.

Le déploiement d’un groupe d’administration en double est une option lorsqu’il n’existe aucune tolérance pour les temps d’arrêt ; cependant, c’est l’option la plus complexe. La configuration entre les deux doit être cohérente afin que, lorsque vous effectuez un basculement, il n’y ait aucune différence dans ce qui est surveillé, alerté ou signalé, présenté et finalement regénéré. L’intégration à d’autres plateformes de supervision ou à des plateformes ITSM telles que System Center - Service Manager, Remedy ou ServiceNow doit également exister, et éventuellement configurée dans un état actif/passif pour éviter la duplication des incidents, des éléments de configuration, etc. Les agents doivent résider sur les deux groupes d’administration pour permettre la duplication des données.

Le diagramme suivant est un exemple de ce scénario de conception.

Si la récupération immédiate n’est pas nécessaire pour votre déploiement Operations Manager et que vous souhaitez éviter la complexité d’un groupe d’administration en double, vous pouvez également déployer des composants de groupe d’administration supplémentaires dans votre centre de données secondaire afin de conserver les fonctionnalités de votre groupe d’administration. Vous devez, au minimum, implémenter un groupe de disponibilité AlwaysOn SQL Server 2014 ou 2016 pour permettre la récupération des bases de données opérationnelles et de l’entrepôt de données entre plusieurs centres de données. La configuration nécessaire est la suivante : une instance de cluster de basculement à deux nœuds déployée dans le centre de données principal et un serveur SQL Server autonome déployé dans le centre de données secondaire, au sein d’un même cluster de basculement Windows Server (WSFC). Le réplica secondaire du groupe de disponibilité AlwaysOn doit se trouver sur une instance autonome autre que l’instance de cluster de basculement, comme indiqué dans le diagramme suivant.

Dans cet exemple, vous serez obligé de déployer un ou plusieurs serveurs Windows avec le même nom d’ordinateur et la même configuration matérielle, puis de réinstaller le rôle du serveur d’administration à l’aide du paramètre /Recover. Voici un exemple :

Setup.exe /silent /AcceptEndUserLicenseAgreement:1 /recover /InstallPath:<Install Directory> /ManagementGroupName:MGNAME /SqlServerInstance:SQLServerName.domain.com /DatabaseName:OperationsManager /DWSqlServerInstance:SQLServerName.domain.com /DWDatabaseName:OperationsManagerDW /ActionAccountUser:DOMAIN\omaa /ActionAccountPassword:password /DASAccountUser:DOMAIN\omdas /DASAccountPassword:password /DatareaderUser:DOMAIN\omdr /DatareaderPassword:password /DataWriterUser:DOMAIN\omdw /DataWriterPassword:password /EnableErrorReporting:Always /SendCEIPReports:1 /UseMicrosoftUpdate:0

Pour plus d’informations, consultez Installation d’Operations Manager depuis l’invite de commandes.

Pendant ce temps, les agents mettent en file d’attente les données collectées (alertes, événements, performances, etc.) jusqu’à ce qu’ils puissent reprendre la communication avec un serveur d’administration du groupe d’administration. Cette approche évite l’installation de nouvelles instances de SQL Server, ainsi que la restauration des bases de données à partir de votre dernière sauvegarde saine. Toutefois, dans ce scénario de récupération, le retour à un état opérable sera probablement plus long, étant donné que vous devrez déployer les autres rôles nécessaires pour reprendre la fonctionnalité de supervision minimale. Si cette approche ne convient pas, vous pouvez déployer des serveurs d’administration dans votre centre de données secondaire pour une récupération sur les serveurs de secours. Supprimez-les des trois pools de ressources principaux : pool de ressources Tous les serveurs d’administration, Notifications et Affectation AD. Cela inclut également tout pool de ressources personnalisé comprenant un serveur d’administration hébergé dans le centre de données principal et devant continuer à fonctionner dans le cadre du plan de récupération. Les services Microsoft Monitoring Agent, et les services d’accès aux données et de gestion de la configuration System Center, doivent être arrêtés, puis définis sur Manuel ou Désactivé, pour n’être démarrés que dans un scénario de récupération d’urgence.

Si un serveur d’administration prend en charge l’intégration (via un connecteur hébergé directement sur le serveur d’administration ou à partir d’un autre produit System Center tel que VMM, Orchestrator ou Service Manager), cela doit être planifié avec des étapes de récupération manuelles ou automatiques en fonction de la configuration d’intégration et de la séquence des étapes de récupération. Cela garantit la capture et la planification de toutes les autres dépendances sur le serveur d’administration pour l’implémentation du plan de reprise d’activité, si nécessaire.

Quand un site est hors connexion, l’agent bascule vers le serveur d’administration d’un autre site, en supposant que la configuration de basculement de l’agent le permette. Reconfigurez les agents Windows pour mettre en cache uniquement les serveurs d’administration de votre centre de données principal, qui doit les gérer pour empêcher toute tentative de basculement vers un serveur d’administration du centre de données secondaire, ce qui aurait pour effet de retarder la récupération et la création de rapports. Cela peut être effectué si vous déployez manuellement l’agent de manière automatisée avec un script (par exemple, VBScript ou, mieux encore, PowerShell) pour préconfigurer pendant l’installation, ou si vous post-déploiement si vous envoyez l’agent à partir de la console, à l’aide d’une méthode de script gérée avec votre solution de gestion de la configuration d’entreprise.

Operations Manager peut être déployé sur les machines virtuelles Azure comme une alternative à la récupération d’urgence, afin d’assurer la continuité du groupe d’administration. Il sera également nécessaire de déployer SQL Server sur une machine virtuelle dans Azure et non dans une configuration hybride, car la latence entre un serveur d’administration et le SQL Server hébergeant les bases de données Operations Manager aura un impact négatif sur les performances du groupe d’administration.

Tenez compte de l’étendue de la surveillance, de la topologie réseau et de la connectivité réseau à Microsoft Azure (c’est-à-dire, VPN de site à site ou ExpressRoute), des points d’intégration (c’est-à-dire des solutions ITSM, d’autres produits System Center, des modules complémentaires tiers, etc.), de l’accès à la console, des lois ou stratégies réglementaires ou pertinentes, et ainsi de suite afin de créer correctement ce scénario au sein d’Azure IaaS ou d’autres fournisseurs de cloud public.