Haute disponibilité et reprise d’activité après sinistre
System Center : les serveurs et 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. Il dépend du rôle de la fonctionnalité défaillante et du temps nécessaire pour récupérer la fonctionnalité défaillante.
Haute disponibilité
Les besoins de haute disponibilité sont résolus en créant une redondance dans le groupe d’administration pour les bases de données opérationnelles et d’entrepôt de données Operations Manager, les serveurs de passerelle et d’administration et les charges de travail spécifiques. Ces charges de travail incluent la surveillance des appareils réseau, la surveillance multiplateforme et les charges de travail spécifiques au groupe d’administration qui ont été précédemment gérées par le serveur d’administration racine.
Les plusieurs serveurs, la configuration d’un groupe d’administration unique peut utiliser SQL Server Always On pour fournir une haute disponibilité et une continuité de service des bases de données Operations Manager. La tolérance de panne du serveur d’administration est fournie en ayant au moins deux serveurs d’administration et en utilisant les pools de ressources pour surveiller les serveurs UNIX, les serveurs Linux et les périphériques réseau. Les serveurs Windows basés sur un agent peuvent être configurés avec un serveur d’administration principal et secondaire pour rediriger les communications de l’agent si un serveur d’administration échoue.
L’émulateur RMS peut également être déplacé vers un autre serveur d’administration si le serveur d’administration hébergeant l’émulateur RMS devient indisponible.
Les connexions de la console Opérateur peuvent être rendues hautement disponibles en configurant la haute disponibilité pour les services d’accès aux données. Pour ce faire, installez Microsoft Network Load Balancing (NLB) ou utilisez 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 charge réseau et lors de l’ouverture de la console, vous référencez le nom virtuel inscrit dans DNS, des serveurs d’administration à charge équilibrée.
Remarque
Un équilibreur de charge réseau n’est pas pris 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 base de données de serveur de rapports unique, elle n’est pas prise en charge avec Operations Manager. Operations Manager Reporting installe une extension de sécurité personnalisée dans le cadre de la configuration des composants frontaux, qui ne peuvent pas être répliqués sur la batterie de serveurs web.
Récupération d’urgence
La récupération d’urgence concerne les mesures prises pour s’assurer que les opérations peuvent être reprise en cas de défaillance catastrophique (par exemple, perte de l’ensemble 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 dans la planification de la récupération d’urgence affectent la façon dont Operations Manager pourra 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 se concentre sur la stratégie recommandée de récupération d’urgence et de résilience, ainsi que sur les étapes à suivre pour garantir une récupération fluide.
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 du système, elles ne doivent pas être utilisées pour la protection contre les pertes de données accidentelles, involontaires ou malveillantes ou la corruption. Dans ces cas, la sauvegarde de copies de réplication copiées ou décalées peut être utilisée pour les opérations de restauration. Dans de nombreux cas, une opération de restauration est la forme la plus appropriée de récupération d’urgence. Un exemple de ceci peut être une base de données de création de rapports de faible priorité ou des données d’analyse. Dans de nombreux cas, le coût d’activation de la récupération d’urgence multisite au niveau du système ou de l’application dépasse largement la valeur des données. Dans les cas où la valeur à court terme des données est faible et que la nécessité d’accéder aux données peut être retardée sans impact commercial grave si une défaillance ou une récupération d’urgence de site est excessive, envisagez d’utiliser des processus de sauvegarde et de restauration simples pour la récupération d’urgence si les économies de coûts le justifient.
Comprendre l’impact et la tolérance aux temps d’arrêt vous aideront à prendre les décisions qui doivent être comprises afin de concevoir correctement l’architecture d’Operations Manager et le niveau de complexité et de coût requis pour prendre en charge la récupération d’urgence. En outre, tenez compte de l’étendue de la surveillance de la perte de données que l’organisation informatique peut tolérer sans provoquer de conséquences métier. Cela est le mieux décrit en deux termes : objectif de délai de récupération (RTO) et objectif de point de récupération (RPO).
Les deux configurations de conception de récupération d’urgence les plus courantes pour Operations Manager sont :
- Création d’un groupe d’administration dupliqué, déployé sur le 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 de l’entrepôt de données, avec des serveurs d’administration déployés dans une configuration à reprise progressive, qui ne participent pas au groupe d’administration tant que les actions de récupération ne doivent pas être effectuées.
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 ; Toutefois, il s’agit de l’option la plus complexe. La configuration entre les deux doit être cohérente afin que lorsque vous effectuez un basculement, il n’existe aucune différence entre ce qui est surveillé, alerté ou signalé, présenté et enfin réaffecté. L’intégration à d’autres plateformes de surveillance ou 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 d’incidents, d’éléments de configuration, etc. Les agents seront multihomed entre les deux groupes d’administration, de sorte qu’il y aura des duplications de 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. Au minimum, envisagez d’implémenter un groupe de disponibilité Always On SQL Server 2014 ou 2016 pour assurer la récupération des bases de données opérationnelles et de l’entrepôt de données entre deux centres de données, où une instance de cluster de basculement à deux nœuds (FCI) est déployée dans le centre de données principal et un serveur SQL server autonome dans le centre de données secondaire dans le cadre d’un cluster de basculement Windows Server unique (WSFC). Le réplica secondaire du groupe de disponibilité Always On se trouverait sur l’instance autonome non FCI, comme illustré dans le diagramme suivant.
Dans cet exemple, vous devez déployer un ou plusieurs serveurs Windows avec la même configuration matérielle et le même nom d’ordinateur, puis réinstaller le rôle 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 l’installation d’Operations Manager à partir de l’invite de commandes.
Pendant ce temps, les agents devront mettre en file d’attente les données collectées (alertes, événements, performances, et ainsi de suite) jusqu’à ce qu’ils puissent reprendre la communication avec un serveur d’administration dans le groupe d’administration. Cette approche évite d’installer de nouvelles instances de SQL Server et de restaurer des bases de données à partir de votre dernière sauvegarde correcte connue. Toutefois, dans ce scénario de récupération, il y aura probablement un délai plus long pour revenir à un état opérable, étant donné que vous devrez déployer les autres rôles nécessaires pour reprendre la fonctionnalité minimale de surveillance. Si cette approche n’est pas acceptable, vous pouvez déployer des serveurs d’administration dans votre centre de données secondaire pour la récupération en veille. Supprimez-les en tant que membres des trois pools de ressources principaux : tous les serveurs d’administration, pool de ressources, notifications et affectation AD. Cela inclut également tout pool de ressources personnalisé, qui peut inclure des serveurs d’administration hébergés dans le centre de données principal et qui doivent continuer à fonctionner dans le cadre du plan de récupération. Les services System Center Data Access, System Center Configuration Management et Microsoft Monitoring Agent doivent être arrêtés et définis sur manuel ou désactivé et démarrés uniquement 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 d’étapes de récupération. Cela garantit que toute autre dépendance du serveur d’administration est capturée et planifiée lorsque le plan de récupération d’urgence doit être implémenté.
Si 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 l’autorise. Reconfigurez les agents Windows pour mettre en cache uniquement les serveurs d’administration de votre centre de données principal qui doivent les gérer pour les empêcher de tenter de basculer vers un serveur d’administration dans le centre de données secondaire, ce qui retarderait uniquement 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 après le déploiement si vous envoyez (push) l’agent à partir de la console, à nouveau à l’aide d’une méthode scriptée gérée avec votre solution de gestion de la configuration d’entreprise.
Operations Manager peut être déployé sur des machines virtuelles Azure comme autre option de récupération d’urgence pour maintenir 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 serveur SQL Server hébergeant les bases de données Operations Manager affecte négativement les performances du groupe d’administration.
Tenez compte de l’étendue de surveillance, de la topologie réseau et de la connectivité réseau à Microsoft Azure (c’est-à-dire, VPN 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, et ainsi de suite), de l’accès à la console, des lois ou stratégies réglementaires ou pertinentes, et ainsi de suite pour concevoir correctement ce scénario dans Azure IaaS ou d’autres fournisseurs de cloud public.