Scroll Top

Réduire les coûts d’hébergement (on premise & cloud) grâce au monitoring et aux actions automatisées

Introduction

Au fil des années, j’ai architecturé, conçu, dimensionné et implémenté de nombreux environnements SAP BusinessObjects. Outre les exigences habituelles, il était parfois nécessaire d’implémenter la “Haute Disponibilité”.

Par exemple ça consiste à avoir deux serveurs ou plus regroupés ensemble de sorte que si un serveur tombe en panne, les autres serveurs continueront à servir les utilisateurs et leurs requêtes.

utilisateurs-requetes-serveur

Parfois, il fallait s’assurer que le déploiement pouvait supporter un pic d’utilisation très élevé pendant des périodes d’activité très chargées.

Par exemple, deux serveurs pourraient être suffisants pour l’entreprise la majeure partie de l’année, mais à certaines périodes, comme à la fin des trimestres, quatre serveurs seraient nécessaires.

deploiement-business-objects

La question des coûts

Quand on implémente un environnement avec plusieurs serveurs, il est sûr que certains serveurs ne seront pas utilisés à un moment ou à un autre – ce qui vous coûtera de l’argent pour rien – ni par votre équipe informatique interne pour l’architecture on premise ni par votre hébergeur Cloud (AWS, MS Azure ou GCP).

Le scénario le plus évident c’est celui qui consiste à faire tourner des serveurs pour une poignée d’utilisateurs ou pire, pour aucun utilisateur, et en dehors des heures de travail.

cout-business-objects

Pour éviter ce scénario, vous pouvez programmer vos serveurs pour qu’ils démarrent à 7h par exemple, et s’arrêtent automatiquement à 23h mais c’est un choix tout ou rien. De plus, cela peut ne pas être très pratique pour les horaires de nuit.

La solution idéale serait d’implémenter un modèle similaire à celui des solutions SaaS modernes actuelles, c’est-à-dire “pay as you go”.

La question du monitoring

SAP BusinessObjects fournit une solution de monitoring des serveurs. Il vous donne la possibilité d’utiliser des observateurs (watchers) pour surveiller les différents services (CMS, FRS, APS, Webi Processing Server, etc.) pour les événements (par exemple, manque d’espace disque) et si nécessaire, vous pouvez être averti par e-mail lorsque la règle est déclenchée.

monitoring-sap-bi-4-2

Monitoring in SAP BI 4.2

Cependant, la limite c’est que vous ne pouvez déclencher que des notifications par e-mail.  Vous ne pouvez pas mettre en place des actions automatisées et proactives pour résoudre les problèmes. Par exemple : Redémarrer un service, démarrer un nœud dans un cluster, exécuter un script pour effacer les fichiers temporaires, etc.

Dans cette optique, 360Suite a développé une solution qui comble cette lacune et peut déclencher des actions automatisées et proactives telles qu’exécuter un programme, appeler une URL, lancer un exécutable ou redémarrer un service, ainsi que l’envoi des notifications par courriel.

automatiser-actions-360live

360Live

Scénarios & Solutions

Scénario 1 : Défaillance des services et/ou du nœud dans le cluster

Vous avez un cluster de 2 serveurs (nœuds). Le nœud 1 est en marche et l’autre est arrêté en veille à froid et prêt à être démarré en cas de sinistre. Ceci est également connu sous le nom de mode Actif / Passif.

C’est une proposition utile si la Haute Disponibilité n’est pas critique et que vous voulez économiser les coûts d’exploitation de serveurs inutiles.

Solution: Monitorez l’état des services SAP BusinessObjects pour déterminer s’ils fonctionnent ou non. Dans le cas où un service est arrêté, utilisez 360Live pour :

  1. Notifier les administrateurs
  2. Essayer automatiquement de redémarrer le service
  3. Exécuter un script pour démarrer le Nœud 2 du cluster

Scénario 2: Démarrage / Arrêter des nœuds en fonction de l’utilisation et des ressources disponibles

J’ai un client avec deux serveurs Web et cinq serveurs SAP BusinessObjects.  Il s’agit, bien sûr, d’un déploiement important, mais la vérité est que bien qu’ils veulent une haute disponibilité (donc deux services / serveurs de chaque type), les trois autres serveurs SAP BusinessObjects ne sont principalement là que pour les périodes de pointe de l’année (Pâques, Black Friday, etc). Comme vous pouvez probablement le deviner, c’est pour acteur de la Grand Distribution.

C’est un gros investissement pour quelque chose qui n’est vraiment utilisé que 30 jours par an.

En quoi un monitoring adéquat peut-il vous aider à n’utiliser ces serveurs “supplémentaires” que lorsqu’il y a suffisamment de sessions et de requêtes d’utilisateurs, et ainsi justifier leur coût ?

Planifier des instances est également un autre problème. Vous pouvez prédire les planifications qui sont gérées par l’informatique mais pas facilement celles qui sont générées par les utilisateurs. Il serait stupide de faire tourner des serveurs supplémentaires toute la nuit, juste au cas où ce serait une nuit chargée !

Solution: Monitorez soit l’un, soit l’autre, soit les deux options suivantes:

  • Nombre de sessions utilisateur sur la plateforme SAP BusinessObjects (CMS)
  • Nombre de requêtes sur des services spécifiques comme par exemple Web Intelligence Processing Server, Lumira Server, Adaptive Job Server, etc.

En utilisant 360Live, vous avez la possibilité de surveiller ces mesures et d’exécuter facilement des scripts pour démarrer/arrêter les services SAP BusinessObjects et/ou les nœuds de serveur.

Démonstration

Dans la vidéo au début de l’article, je vous montre comment j’utilise 360Live pour gérer les scénarios présentés. L’architecture est la suivante :

monitoring-sap-businessobjects

360Live monitoring SAP BusinessObjects

Conclusion

L’utilisation du monitoring permet d’augmenter la stabilité et éventuellement améliorer les performances d’une application / système d’exploitation, c’est bien connue. Déclencher des actions automatiques pour nous aider dans ce processus n’est pas nouveau non plus, mais comme nous l’avons déjà mentionné, il est malheureusement impossible de le faire out of the box avec SAP BusinessObjects

Les scénarios couverts dans cet article de blog visaient directement à économiser les coûts d’hébergement (on premise ou dans le Cloud), et nous pourrions aller beaucoup plus loin en étant plus efficaces avec l’espace disque (File Store), la RAM (surtout en pensant à Lumira), et autres dépendances, processus et services coûteux.

J’espère que cela vous a été utile et je vous invite à nous faire part de vos commentaires et des autres scénarios que vous avez mis en place ou que vous aimeriez mettre en œuvre.

Publications similaires

Laissez un commentaire