hyper_orchestra

OpenSVC

Membre du consortium
OpenSVC, fondée en 2009, développe et supporte une solution opensource d'orchestration applicative orientée sur les besoins de haute disponibilité, de continuité de service et plan de reprise d'activité. Cette solution supporte les stratégies d'hébergements sur-site, multi-cloud et hybrides. Légère, facile à déployer et administrer, 100% pilotable par API elle offre un composant sécurisé du modèle No-Ops.
OpenSVC a été dès sa création, moteur dans l'innovation pour une approche orientée service dans l'intégration des applications sur les systèmes informatiques.

Présentation

OpenSVC est une solution alternative à des produits tels que Kubernetes, Mesos, Rancher, Red Hat Cluster, Suse Cluster, Veritas Cluster Server, HP ServiceGuard, IBM HACMP.

OpenSVC est un logiciel libre open source (GPLv2), développé depuis 2009 en France par la société OpenSVC SAS. Il répond aux besoins d’orchestration et d’intégration des applications, de gestion de la disponibilité, des plans de reprise sur incident et sur désastre. La solution repose sur plusieurs serveurs (physique, vm, cloud, …) sur lesquels un agent est installé. Chaque agent est configuré pour échanger des informations chiffrées avec les autres membres d’une grappe de serveurs, formant ainsi un « cluster opensvc ».

Le cluster est le socle permettant de recevoir les déploiements applicatifs, modélisés sous forme de 1 à n « services opensvc » par cluster.

Un « service opensvc » est un objet qui regroupe toutes les ressources nécessaires au déploiement d’une application (systèmes de fichiers, adresses ip, conteneurs, lanceurs applicatifs, réplication des données, …). Cet objet est manipulable par un jeu de commande simple (start, stop, switch, …) dont l’objectif est de fournir à l’administrateur une aisance dans le démarrage/arrêt applicatif, mais encore dans la relocalisation d’un service sur un autre serveur du cluster.

Les fonctionnalités « haute disponibilité » intégrées au cluster permettent de prendre des décisions de bascule automatique de services lorsque des évènements se produisent dans le cluster (perte d’une ressource, perte d’un serveur, …), assurant un taux de disponibilité maximal pour les clients de l’infrastructure.

La simplicité de gestion d’une application complexe, composée de multiples produits, permet de déléguer facilement les actions simples à des équipes de pilotage, et permet aux équipes d’administrateurs de se focaliser sur des sujets de fond. Un portail web optionnel permet de centraliser les informations émises par les multiples clusters opensvc du système d’information, mais aussi de piloter les services opensvc déployés dans les clusters.

L’agent OpenSVC, et le portail web centralisé sont dotés d’une API Rest, permettant une interconnexion aisée avec d’autres composants du système d’information.

A quoi sert-elle et que peut-on faire avec ? 

En partant d’un besoin simple, par exemple, mise à disposition d’une base de données postgresql en mode haute disponibilité. Une solution possible est de prendre 2 serveurs chez un hébergeur (OVH, Scaleway, Amazon, Google, …), d’y installer OpenSVC, et d’intégrer postgresql sous la forme d’un service OpenSVC. En fonction des prérequis techniques disponibles (ou non) chez l’hébergeur retenu, divers niveaux de service peuvent être obtenus, par exemple :

  • Basique : bascule manuelle de la base de données, avec réplication asynchrone des données
  • Avancé : bascule automatique en quelques secondes sur un serveur situé à des centaines/milliers de kilomètres, avec une réplication synchrone des données, et un export automatisé du contenu de la base chaque jour, le tout pilotable à distance, via l’api Rest.

Dans le contexte HyperOpenX, le composant développé correspond à un cas très particulier qui permet la mise en haute disponibilité d’un nœud « slave » SlapOS (Nexedi) :

  • Sans le composant, un sinistre sur un nœud slave SlapOS se traduit par une indisponibilité perçue par l’utilisateur final, qui va nécessiter le redéploiement et paramétrage des applications servies par le nœud slave.
  • Avec le composant, les services du nœud slave connaitront une courte indisponibilité, mais seront redémarrés en quelques secondes, sans perte de données, limitant grandement l’impact perçu au niveau de l’utilisateur final.

Bénéfices

  • Simplicité de gestion des services
  • Homogénéité dans le pilotage d’applications hétérogènes
  • Prérequis techniques limités

Cas d’usage et valeur ajoutée

Mise en haute disponibilité des instances MQseries (gestion des files de messages inter-applications de la banque)

orchestration d’une pile de conteneurs docker pour une application de voix sur ip, en réplication synchrone

Mise en haute disponibilité des bases de données Postgresql (Fichier des personnes recherchées/Fichés S ; Fichier des véhicules volés ; Données Balistiques ; Emploi du temps Police Nationale ; Statistiques des accidents de la route ; …)

hébergement haute dispo web, wordpress, nextcloud, restic, keycloak, freeipa, rundeck, mariadb …

Informations complémentaires

Spécificités organisationnelles

Spécificités techniques

  • Prérequis techniques :
    • 1 à N serveurs (physique ou vm ou cloud) / – Système Linux avec interpréteur python3
    • Interconnexions réseau (étendu ou non)
    • Adresses IP de service + noms DNS associés
    • Dispositif de stockage (local ou distant)
  • L’API Rest Agent est accessible lorsqu’un agent est installé et configuré : https://a.b.c.d:1215