Architecture Opalis 6.2 : haute disponibilité et pertes de composants
Dans un post précédent (ici) je faisais un article sur les notions d’architecture Opalis (version 6.2) et il me semblait important de parler du fonctionnement d’Opalis 6.2 en cas de perte d’un composant mais aussi des mécanismes de hautes disponibilités supportés.
1. Cas de perte d’un composant :
Perte d’un composant |
Description |
Action server |
En cas de perte d’un « Action Server » la ou les « policies » déployées sur l’ « Action Server » ne peuvent pas s’exécuter si elles ne sont pas déployées sur un autre « Action Server ». |
DataStore |
Plus d’accès aux consoles (plus de création de nouvelles policies, etc.) Plus d'accès au report. Les « Actions Servers » ne peuvent pas exécuter les « policies » |
Management Server |
Plus d’accès aux consoles OIS et Deployment Manager. |
Dashboard /report servers |
Plus d’accès aux rapports/dashboard WEB. |
Operator console |
Plus de possibilité de surveiller les « policies » et de les gérer via la console WEB. |
2. Haute disponibilité des composants principaux :
Comme vous avez pu le constater ci-dessus le composant central de l’infrastructure Opalis est le DataStore c’est-à-dire le serveur de base données ! Les scénarios supportés sont les suivants :
- Mise en place d’un cluster SQL. Le log shipping et mirroring ne sont pas des scénarios supportés pour le moment.
- Il est aussi possible d’exporter l’ensemble des éléments (objets d’Opalis : policies, variables, schedules, counters, configuration globale) grâce à la tâche d’export se trouvant dans la console OIS. Attention, l’export pouvant se faire à plusieurs niveaux (folder, policy) il est recommandé de faire un export au niveau du nœud central pour exporter tous les éléments.
Il n’est pas possible de « clusteriser » le management serveur. D’un autre côté la perte de ce composant empêchera juste la gestion de « policies » au travers de la console OIS et le déploiement de nouveaux IP (via la console Deployment Manager). La supervision et la gestion des « policies » (démarrage / arrêts) pourra toujours s’effectuée au travers de l’ « Operator console ».
La redondance et répartition de charge au niveau du composant « Action server » est gérée nativement par Opalis. Chaque Action Server peut gérer environ 50 « policies » exécutés simultanées (REX et valeur par défaut). Ce paramètre peut être modifié en exécutant la commande :
aspt <ActionServerName> <MaximumRunningPolicies>
La valeur 50 est aussi à prendre avec précaution car cela dépend des performances matériels du serveur.
Même si cette limitation est largement suffisante dans la majorité des cas, elle devrait largement être dépassée avec la version 6.3 et la possibilité d’installer l’ « Action Server » sur un OS Windows Server 2008 (R2) (*) . Ensuite, les « Actions Servers » ont une notion de primaire et secondaire. Dans le cas où le serveur primaire exécutant une ou plusieurs « policies » devient indisponible, l’ « Action Server » secondaire prend le relais. L’ « Action Server » est marqué comme indisponible (offline) s’il y a une absence de connectivité à la base de données supérieure à 45 secondes. Il est donc recommandé d’avoir au moins 2 « Actions servers ». De plus, le mécanisme de failover/load balancing intégré dans Opalis pour les « Action Servers » est un mécanisme de « Waterfall ».
(*) Les informations concernant la version 6.3 d’Opalis sont décrites sous réserve des informations connues à ce jour. Pour plus d’informations sur la version 6.3 d’Opalis se diriger vers : https://blogs.technet.com/b/opalis/archive/2010/08/12/what-s-coming-in-the-next-opalis-release.aspx.