Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Un Datacenter utilise trois grandes catégories d'équipement :
Les équipements de type Compute (serveurs ESX à base de processeur X86, serveurs IBM à base de processeur Power, etc.), ce sont ces équipements qui hébergent les différentes instances.
Les équipements de type Storage (baies de stockage de données, baies de stockage objets, baies de sauvegarde et archivage des données).
Les équipements de type Network (switch réseaux, Firewall, BigIP, etc.), qui permettent les échanges de flux internes et externes entre services et instances.
NB : Ces trois catégories sont elles-mêmes constituées de sous-catégories permettant de calculer plus finement les répartitions des émissions de CO2 par instance utilisateur. Pour des raisons de simplification, ces sous-catégories ne seront pas prises en compte dans la méthode de calcul explicitée ci-dessous.
La consommation énergétique de chaque équipement est collectée chaque minute (puissance instantanée exprimée en Watt) et stockée dans une base de données (base Clef-valeur MIMIR).
En complément, nous collectons les éléments suivants qui permettront de calculer l'émission de CO2 associée :
Le PUE (efficacité), calculé quotidiennement sur les Datacenters que nous exploitons, et mensuellement pour les Datacenters en colocation.
Les facteurs d'émission de CO2 (en kgCO2e/kWh), dont les valeurs sont actualisées chaque année, sur la base des données ADEME et fournisseurs.
L'émission de CO2 d'un équipement est calculée à la journée :
Transformation de la consommation instantanée en kWh/jour depuis les données collectées dans la base de données Clef-valeur.
Application du PUE du Datacenter :
Si un équipement consomme 1000 kWh/jour et que le PUE du datacenter est de 1.3, la consommation réelle de l'équipement sera de 1300 kWh.
Conversion des kWh/jour en CO2 (kg) avec le facteur d'émission de CO2 du fournisseur :
Si 80% de l'énergie du Datacenter provient d'un fournisseur qui émet 0.008 kg de CO2 par kWh et les 20% restant d'un groupe second fournisseur qui émet 0.01 kg de CO2 par kWh, alors l'émission de l'équipement sera de : 1300 * 0.008 * (80 / 100) + 1300 * 0.01 * (20 / 100) , soit 10,92 kg de CO2 par jour.
Un Service Global est le regroupement logique de ressources (principalement des Instances) qui utilisent les ressources des différentes catégories d'équipement physique (Compute, Storage et Network). L'empreinte carbone d'un Service Global sera donc la somme de l'émission de CO2 de ses ressources.
Bienvenue dans la documentation publique de cegedim.cloud, un partenaire de confiance pour l'hébergement de clouds privés !
ITCare est la plateforme de gestion Cloud de cegedim.cloud.
Elle intègre une interface d'administration web et une API qui offrent une vue à 360° de vos ressources Cloud hébergées et gérées par cegedim.cloud.
Conçue comme un service web unifié, elle régit les points clés suivants :
Gestion des ressources Cloud : déployer et administrer vos ressources
Supervision : surveiller la santé et la performance de vos applications, être notifié en cas d'incident
Support : contactez nos équipes de support pour toute question ou incident
Gouvernance : consultez les rapports de sécurité et d'obsolescence, gérez les créneaux de maintenance
Intégration : intégrez vos processus d'entreprise à votre cloud via l'API ITCare
Vous pouvez accéder à ITCare à partir de n'importe quelle page de ce site web en utilisant le lien ITCare dans l'en-tête.
La page Débuter avec ITCare explique en détail comment accéder à ITCare, avec des informations sur l'authentification et les autorisations.
Toutes les informations nécessaires à la découverte et à la bonne utilisation de l'API ITCare sont disponibles dans la section ITCare API du menu principal.
Si vous êtes client, vous pouvez joindre notre Service Desk via cette ligne téléphonique directe pour toute demande de support : +33 (0)1 49 09 22 22
Pour toute demande d'information ou de contact, vous pouvez utiliser ce formulaire :
Afin de vous aider à appréhender et maitriser chaque aspect de la plateforme ITCare, nous proposons un ensemble de démos interactives spécifiques à des fonctionnalités disponible dans notre Cloud Management Platform.
Différentes actions sont possibles pour gérer les ressources sur notre plateforme ITCare. Nous vous les présentons ci-dessous !
En fonction des ressources sélectionnées dans la fenêtre de filtrage, des filtres dynamiques seront désormais disponibles pour afficher plus efficacement ce qui vous intéresse.
Vos notifications sont configurables et personnalisables via des abonnements. Nous vous montrons cela ci-dessous !
La première étape incontournable : créer un abonnement selon vos critères personnalisés.
Maintenant que vous savez comment créer un abonnement, voyons comment le gérer.
Les abonnements tirent partie de groupes de diffusions. Nous vous montrons comment les gérer.
Lorsque vos notifications sont paramétrées, il est essentiel de savoir comment les superviser.
cegedim.cloud fournit dans ITCare une rubrique dédiée à son empreinte carbone.
Cette rubrique permet d'identifier l'impact environnemental des applications de façon détaillée, en affichant à la fois l'émission de CO2 des Services Globaux ainsi que celle des instances associées.
Le calcul de l'empreinte carbone fait partie intégrante du projet Enercare, en se basant sur la répartition de la consommation énergétique des services. Elle prend en compte les équipements IT (serveurs, baies de stockage, réseaux ...) mais également tous les éléments nécessaires à leur bon fonctionnement (climatisation, groupes électrogènes, onduleurs ...). Ces derniers sont associés à l'indicateur de performance énergétique par datacenters calculé par le Power Usage Effectiveness (PUE).
Le périmètre inclut les Datacenters propres à Cegedim ainsi que ceux en colocation.
cegedim.cloud a travaillé sur des outils internes et une méthodologie pour répartir les consommations des services utilisant des instances mutualisées. Etant en démarche d’amélioration continue, elle sera amenée à évoluer avec la fiabilisation et la précision des données remontées.
Les émissions directes du scope 1 des datacenters : combustions fossiles des groupes électrogènes, émissions fugitives liées aux fluides frigorigènes des systèmes de refroidissement.
Les émissions indirectes du scope 2 : consommation d’électricité des équipements, incluant le PUE.
Les émissions indirectes du scope 3 : émissions amont liées aux combustibles et à la production d’électricité, produits et services achetés pour le fonctionnement de nos services, tenant compte de leur fabrication à leur fin de vie, déplacements des collaborateurs.
Les données retranscrites dans Enercare correspondent aux activités de cegedim.cloud, indépendamment de celles des autres filiales et du groupe Cegedim. Le bilan carbone étant réalisé et audité annuellement, nous ne pouvons pas corréler en temps réel les coefficients de calcul à l’utilisation des services.
La section Règles de Calcul ci-dessous explicite la collecte de la consommation énergétique des équipements physiques et la méthode de calcul de l'empreinte carbone pour les services et instances.
Le calcul de l’empreinte carbone de nos services cloud suit les règles du . Nous incluons les éléments suivants dans la fonctionnalité Enercare :
Pour en savoir plus sur les actions de diminution de l’impact environnemental entreprises par cegedim.cloud, vous pouvez consulter la de notre site internet.
Exemple:
Chaque ressource appartient à une hiérarchie qui contient : Catégorie, Type, Famille. Une vue d'ensemble de la catégorisation est décrite comme suit :
Application server
Tomcat
Wildfly
Container
Kubernetes
Instance
Linux
CentOS
Debian
Oracle
RHEL
Ubuntu
Windows
Unix
Load balancer
Load Balancer
Managed database
MariaDB
OpenSearch
PostgreSQL
Redis
SQL Server
Message broker
Apache Kafka
RabbitMQ
Storage
GlusterFS
Lors de l'obtention d'une ressource, un attribut nommé path
est disponible dans la sortie pour informer sur la catégorie-famille-type à parcourir afin d'obtenir des détails sur la ressource.
Le point d'entrée de l'API pourrait être le endpoint : /compute/resources
. Il peut être utilisé pour explorer les informations de base et naviguer vers la catégorie appropriée pour obtenir les détails.
JSON ne supporte pas nativement le format Date/Time. Tous les paramètres tagués en tant que Date par l'API sont donc des string au format ISO8601.
Z correspond à la timezone : +0200 par exemple.
Pour les requêtes GET, ne pas oublier d'URL-Encoder ces paramètres.
Certaines méthodes autorisent le test des appels API sans que cela ne déclenche réellement l'action dans ITCare. La validation s'effectue cependant. Pour activer le mode Dry Run, il suffit d'ajouter un header personnalisé dans vos requêtes HTTP :
Une fois que le serveur traitera votre requête, le même header personnalisé sera inclus dans la réponse.
Certaines méthodes sont asynchrones et nécessitent un délai après leur invocation. Cela s'applique à des longues transactions telles que l'administration des ressources ou l'envoi de rapports. Les méthodes qui fonctionnent de manière asynchrone répondront :
un code retour HTTP 202
un corps contenant un ID de suivi de l'opération asynchrone en cours
Voici un exemple de code en Python qui explique le fonctionnement asynchrone :
Les statuts des actions peuvent être :
IN_PROGRESS
SUCCESS
ERROR
Découvrez les dernières mises à jour de cegedim.cloud ! Améliorations continues, nouveaux produits, nouvelles fonctionnalités et évolutions sont référencés ici.
La gestion du niveau de support a été grandement améliorée sur nos produits. Vous pouvez désormais choisir d'activer et de déployer la surveillance sans activer immédiatement les alertes. Cela permet à nos utilisateurs de tester les checks de surveillance sans déclencher de tickets ou le support d'astreinte téléphonique.
Une nouvelle action de self-service est disponible sur tous les PaaS PostgreSQL : la mise à niveau sur place. Cela vous permet de mettre à niveau votre déploiement d'une version quelconque à la dernière version de manière autonome et sans avoir à redeployer un autre PaaS. Cette opération est décrite dans la page de mise à niveau de cette Académie pour PostgreSQL. Toutes les mesures de sécurité ont été mises en œuvre et en cas d'erreur, une fonction de retour arrière est incluse dans le processus de mise à niveau.
De multiples améliorations ont été apportées pour améliorer l'expérience utilisateur, les performances et l'interface de ITCare.
Un nouveau dashboard de sécurité offre une visibilité en temps réel sur les vulnérabilités, la protection Bot Defense, les instances Vault et l’obsolescence des ressources. Il permet un suivi précis des vulnérabilités corrigées et des attaques bloquées. Les pages "Vulnérabilités" et "Bot Defense" ont été enrichies pour une gestion optimisée.
Nous avons amélioré la précision des calculs en prenant en compte uniquement les périodes définies dans l’indicateur. La visibilité est renforcée avec l’affichage des périodes de disponibilité et d’indisponibilité par mois ou par jour. Les raisons des interruptions sont désormais accessibles, et les maintenances ne sont plus comptabilisées comme des indisponibilités, garantissant des indicateurs plus fiables.
L'activation du chiffrement TLS est désormais possible sur demande après le provisioning d'un PostgreSQL PaaS. Merci de soumettre un ticket de demande dans ITCare pour cette fonctionnalité.
Nous avons amélioré la sélection des politiques de sauvegarde et permettons désormais la sélection d'une politique "répliquée" même pour les services de type "non-production". Cela signifie que si vous avez des ressources sensibles de type "non-production", vous pouvez sélectionner une politique qui gère la réplication des sauvegardes hors site.
Le panneau de sauvegarde a été amélioré dans ITCare pour tous nos produits PaaS. Il devrait être affiché sur tous les produits et plus d'informations sont désormais disponibles, telles que les politiques de sauvegarde, l'horodatage de la dernière sauvegarde et l'empreinte de stockage du système (et de la base de données, le cas échéant) en Go.
Les Object Stores sont désormais indexés dans la barre de recherche principale et peuvent être trouvés pour une navigation plus facile vers la page d'informations détaillées.
Always On est désormais disponible dans ITCare en self-service pour SQL Server 2022 Enterprise edition. Pour plus d'informations, veuillez consulter les informations sur le produit SQL Server - Architecture.
En septembre, nous avons lancé la sélection de la politique de sauvegarde pour Linux et Windows lors du provisionnement. Vous pouvez désormais sélectionner la politique de sauvegarde pour plusieurs PaaS lors du provisionnement : OpenSearch, Redis, Apache Kafka, RabbitMQ, GlusterFS, Tomcat, Wildfly.
Nous avons également amélioré l'aperçu de l'interface utilisateur pour ces produits afin de vous permettre de voir l'empreinte de la sauvegarde et les politiques associées configurées.
La prochaine et dernière livraison concernera les produits restants suivants : PostgreSQL, MariaDB, SQL Server.
L'ajout de nodes supplémentaires pour le produit Apache Kafka est désormais possible sur requête via un ticket depuis ITCare. Pour rappel, un cluster Apache Kafka est composé à minima de 3 nodes pour de la production.
Kubernetes 1.28 est désormais disponible dans ITCare !
Un nouveau système de filtrage est maintenant disponible dans la section Ressources ! Les filtres s'ajustent automatiquement en fonction du type de ressource choisi, permettant ainsi une expérience plus personnalisée et une présentation optimisée des informations attendues.
Une démonstration interactive est disponible dans la section démo : Filtres dynamiques
Nous sommes heureux d'annoncer que Redis 7.2.5 est désormais disponible sur notre plateforme ITCare. Vous pouvez également demander la mise à jour en version 7.2.5 d'un PaaS Redis déjà existant via un ticket requête.
La sélection de votre politique de sauvegarde pour les instances virtuelles Linux et Windows est maintenant disponible en autonomie lors de la création de vos ressources dans ITCare !
Cette fonctionnalité est présentement en phase Bêta accessible à tous.
La distribution Oracle Linux est désormais disponible en libre service via ITCare, notre plateforme de gestion du Cloud. Cette distribution est disponible dans le cadre de notre produit d'instances virtuelles avec les mêmes options et propriétés.
Bot Defense a été mis à jour pour introduire le mode transparent, vous permettant de voir les requêtes jugées illégitimes sans impacter le trafic. Ce mode facilite l'analyse des logs et l'identification des faux positifs, ce qui permet d'affiner les réglages en ajoutant des IP légitimes à la liste blanche avant de passer au mode blocage.
Pour plus d'informations, merci de lire la documentation Bot Defense.
OverDrive, basé sur la technologie Nextcloud, offre une plateforme de stockage et de synchronisation de fichiers avec de puissantes capacités de collaboration avec des interfaces de bureau, mobiles et web. Ce nouveau produit est disponible en libre-service par l'intermédiaire d'ITCare dans la taille XS et est hébergé sur site avec des normes de sécurité élevées.
Pour plus d'informations, veuillez lire la documentation OverDrive.
Pour simplifier la création d'un load balancer, il est désormais possible de créer un load balancer sur votre cluster Kubernetes directement depuis le menu déroulant Gérer.
Un nouvel indicateur de santé a été ajouté à tous les clusters Kubernetes dont la surveillance est activée pour surveiller l'API Kubernetes.
Le système d'exploitation utilisé par les PaaS a été mis à niveau en dernière version lorsque cela était possible. Cela garantit que tous les nouveaux déploiements seront à jour et bénéficieront des correctifs de sécurité.
Une nouvelle fonctionnalité est disponible pour les clusters OpenSearch afin de migrer d'une topologie basique vers une topologie avec master dédiés. Cette migration ajoutera 3 nœuds dédiés au rôle de maître (n'hébergeant pas de données).
Des nœuds spécialisés dédiés au rôle d'ingestion peuvent maintenant être ajoutés à votre cluster OpenSearch. Cette nouvelle fonctionnalité est disponible dans le menu déroulant Gérer et ajoutera 2 nouveaux nœuds dédiés au rôle d'ingestion.
L'installation d'extensions PostgreSQL sur vos PaaS est désormais possible en libre service via ITCare. La liste des extensions supportées est disponible dans la documentation PostgreSQL - Architecture.
Cette fonctionnalité n'est disponible que pour les déploiements PostgreSQL 15 et supérieur.
Le PaaS OpenSearch a été mis à jour pour supporté et permettre le déploiement de la version 2.11.1.
Le menu principal d'ITCare a été amélioré afin d'offrir une meilleure navigation en réduisant le nombre de pages en cascade.
L'ancien moteur de notification a été supprimé et remplacé par un meilleur système de notification capable de gérer des règles de notification très précises. Cela vous permet de personnaliser exactement les notifications que vous souhaitez recevoir à l'aide d'abonnements ainsi que les destinataires à l'aide de groupes de diffusion d'e-mails.
Vos anciennes souscriptions de notification ont été conservées.
Il est désormais possible de sélectionner l'Ingress provider que vous souhaitez pour Kubernetes dans l'assistant de création. Les Ingress provider disponibles sont : NGINX, Istio et Traefik.
SQL Server 2022 est disponible au provisioning dans ITCare. Comme précédemment, il est possible de choisir l'édition Standard ou Entreprise au provisioning.
Dans ITCare, l'affichage de Kubernetes a été amélioré pour afficher le rôle Ingress sur vos nœuds ainsi que la version du système d'exploitation déployé sur chaque nœud.
Après avoir amélioré la gestion des URL dans ITCare, il est maintenant possible de créer vos propres alertes HTTP sur des URL directement depuis ITCare sur votre load balancer en utilisant l'onglet URL.
La version 12 de la distribution Linux Debian est disponible pour le déploiement dans ITCare. L'automatisation a été améliorée et l'approvisionnement est désormais plus rapide.
L'amélioration de la sécurité, précédemment disponible dans Debian 11, est toujours en vigueur, mais elle est désormais facultative et peut être désactivée dans l'assistant.
La nouvelle version LTS de MariaDB est disponible pour le déploiement dans ITCare. Consultez les notes de version officielles de MariaDB pour plus d'informations.
Les ressources peuvent désormais être incluses ou exclues en mode batch à partir de votre page Service. Nous avons également amélioré les informations sur l'état des correctifs grâce à un panneau dédié dans la vue d'ensemble de votre ressource, qui vous permet de voir rapidement si votre ressource a été patchée et quand aura lieu la prochaine Patch Party.
Des descriptions personnalisées peuvent être ajoutées à vos ressources et Services dans ITCare pour identifier rapidement vos applications.
Pour vous aider à naviguer vers vos ressources préférées, vous pouvez désormais ajouter des ressources à votre liste personnelle de favoris que vous pouvez appeler à partir de l'en-tête ITCare.
Un nouvel onglet est disponible dans la section Calcul pour parcourir les réseaux disponibles pour votre cloud avec leurs propriétés.
Le calendrier de maintenance a été amélioré pour afficher les événements personnalisés propres à chaque client. Les RFC et les événements privés apparaîtront désormais dans le calendrier ITCare de votre cloud.
La section Sécurité a été améliorée avec un nouveau point d'entrée pour Bot Defense & DoS Protection avec ses détails concernant les requêtes bloquées et les attaques.
La version 3.6.0 de Apache Kafka, plateforme open-source de streaming d'événements distribués, est disponible au déploiement via ITCare.
Cette nouvelle version utilise l'algorithme de consensus Raft et permet de s'affranchir de Zookeeper.
La version 15 de PostgreSQL est disponible au déploiement via ITCare. Elle est compatible avec toutes les fonctionnalités précédemment proposées.
La fonctionnalité PostgreSQL de restauration en libre-service, qui vous permet de restaurer une sauvegarde d'une source vers une autre destination, est disponible en libre-service dans ITCare.
Un nouveau mode "Strict" a été rajouté à la fonctionnalité Bot Defense.
Ce profil plus restrictif est déployable rapidement en cas d'attaque en cours sur vos Load balancers. Son paramétrage plus fin est destiné à bloquer un nombre de requêtes plus conséquent.
Vous pouvez créer jusqu'à 5 ressources supplémentaires avec la même configuration. Les ressources supplémentaires seront situées dans la même région, mais les zones de disponibilité peuvent être différentes.
Lorsque vous affichez une instance virtuelle, vous pouvez maintenant utiliser cette ressource existante comme modèle pour créer une nouvelle ressource avec les mêmes propriétés : CPU, RAM, réseau, stockage, options de gestion.
Vérifiez la taille du disque dans le nouveau modèle. En fonction du modèle source, vous pourriez avoir une quantité de stockage incorrecte configurée. C'est un bug connu !
La fonctionnalité a pour objectif de faire économiser du temps pour créer une nouvelle instance virtuelle, mais elle ne CLONERA rien.
Lors de la création d'une ressource, la sélection du réseau est maintenant consciente de l'environnement du Service.
Si le Service a :
un environnement de Production, les réseaux de production sont affichés par défaut.
un environnement de Non-production, les réseaux de non-production sont affichés par défaut.
Dans les deux cas, les réseaux de production et de non-production restent disponibles pour la sélection.
Les maintenances peuvent maintenant être planifiées sur plusieurs ou toutes les ressources au niveau du service.
Une instance PostgreSQL unique peut maintenant être convertie en un cluster PostgreSQL hautement disponible avec deux nœuds. Cette opération n'est pas réversible.
De nouvelles actions de gestion sont maintenant disponibles sur les clusters :
Redimensionnement : il peut également être effectué au niveau du nœud en fonction de la configuration du produit.
Patch party : les statuts de chaque ressource sont maintenant visibles dans la vue étendue du service.
Il est désormais possible de mettre à jour votre cluster Conteneurs (K8s) vers la dernière version supportée à partir du menu de gestion du cluster :
La mise à niveau vers la version supérieure suivante est possible - le saut de version n'est pas autorisé
Le retour à une version antérieure n'est pas possible
Les URL liées à un équilibreur de charge peuvent désormais être gérées individuellement :
Un onglet URL dédié est disponible dans la page de l'équilibreur de charge
Les actions suivantes peuvent être effectuées par URL ou sur un groupe d'URL : planifier la maintenance, activer / désactiver la surveillance
La création d'URL est disponible dans les actions de gestion de l'équilibreur de charge
Certaines méthodes renvoient des résultats paginés. Le formatage d'un résultat paginé presente la structure suivante :
Les valeurs page
et size
peuvent être ajoutées aux paramètres de la requête afin d'obtenir la page suivante ou précédente.
Pour obtenir les 50 premiers éléments d'une requête GET pour un endpoint paginé : https://api.cegedim.cloud/foo/bar?page=1&size=50
L'API ITCare utilise le protocole OAuth 2.0 pour l'authentification et les autorisations. Elle supporte les scénarios OAuth 2.0 habituels tels que ceux utilisés pour les serveurs web et les applications clientes. Cela signifie que chaque requête API doit contenir un header "Authorization" embarquant un token d'accès précédemment obtenu grâce à des identifiants.
Pour interroger l'API ITCare, un compte API est requis afin de pouvoir obtenir le token d'accès obligatoire. Pour obtenir ce compte API, une requête doit être soumise aux équipes support cegedim.cloud en fournissant les informations suivantes :
L'organisation cible
Une description simple de l'usage cible de l'API
En général, on peut utiliser la commande base64 pour encoder une chaîne de caractères. L'utilisation d'outils en ligne de commande sous Linux, par exemple :
Si la demande d'access_token est autorisée et valide, voici un exemple de réponse :
Lorsque le token expire, il est possible de :
Demander un nouvel access_token
Rafraîchir le token en interrogeant le endpoint /token
L'API ITCare utilise les codes de réponse HTTP conventionnels pour indiquer le succès ou l'échec d'une demande API.
En règle générale :
Les codes 2xx
indiquent un succès.
Les codes 4xx
indiquent des paramètres incorrects ou incomplets (par exemple, un paramètre requis a été omis, ou une opération a échoué avec une tierce partie, etc.)
Les codes de l'ordre de 5xx
indiquent une erreur avec les serveurs d'ITCare.
Ce tableau présente d'autres exemples de codes de réponse HTTP.
ITCare produit également un message d'erreur et un code d'erreur formaté en JSON :
Il n'est pas possible de créer son propre compte ITCare pour accéder à la plateforme.
Pour obtenir un compte ITCare, le représentant de la sécurité de votre organisation doit soumettre une demande de création de compte.
Veuillez contacter votre Service Delivery Management ou l'équipe commerciale de cegedim.cloud.
L'authentification ITCare est basée sur une adresse e-mail et un mot de passe conformes aux normes de la politique de sécurité de cegedim.cloud.
Les comptes API utilisent le protocole OpenID. Plus d'informations sur l'API ITCare sont disponibles dans la page API ITCare.
L'authentification multi-facteurs est disponible et obligatoire pour certaines actions à haut privilège.
Au cours du processus d'intégration, vous recevrez toutes les informations nécessaires pour configurer correctement l'authentification multifactorielle.
Les privilèges dans ITCare sont divisés en rôles assignés à des profils. Les profils sont attribués aux utilisateurs.
Le MFA doit être configuré et sera obligatoire pour les rôles suivants :
Gérer les maintenances
Modifier les ressources
Gérer les ressources
Ce tableau non exhaustif décrit les actions basiques autorisées par profil :
La topologie de la plateforme d'hébergement cegedim.cloud est divisée en :
Régions : un groupe de centre de données à faible latence ( < 1 ms)
Zones de disponibilité : ensemble de composants d'infrastructure dédiés dans un centre de données
Voici la liste des régions disponibles pour nos clients :
Une ressource est un composant d'infrastructure ou middleware déployé dans le cloud de cegedim.cloud.
Une ressource est systématiquement définie par les propriétés suivantes :
un id : identifiant unique de la ressource.
un type : le type de la ressource e.g. instance virtuelle, cluster Kubernetes, etc..
un nom : plus pratique à manipuler qu'un id.
un statut : défini l'état de la ressource (active, inactive).
un environnement : défini le type d'environnement de la ressource (production, qa, dev, test, etc..).
des tags : permet de taguer vos ressources avec des clés/valeurs personnalisables qui sont requêtables.
Voici les statuts possibles d'une ressource qui sont visibles par la web UI ou renvoyés par l'API :
Tout client cegedim.cloud possède une Organisation qui matérialise son existence au sein de notre SI.
Plusieurs Clouds peuvent être créés au sein d'une Organisation. Ceux-ci permettent de cloisonner les ressources et les droits utilisateurs.
Vous pouvez donc définir, au niveau d'un Cloud, qui a accès à quoi et quelles actions peuvent être réalisées. Il est donc possible, par exemple, d'avoir un Cloud offrant pleins pouvoirs à vos équipes de développement pour ne pas perturber la production.
Au sein d'un Cloud, les ressources sont ensuite regroupées dans des Services.
Les Services permettent de regrouper vos ressources de manière logiques selon plusieurs critères libres :
Le périmètre d'une application
Par environnement
Tout autre critère libre : par client par exemple
Les Services ne permettent pas d'appliquer des restrictions des droits utilisateurs.
Dans ITCare, les Services ont des pages dédiées qui permettent de consulter aisément l'ensemble des ressources qui leur est attaché.
L'API REST ITCare respecte les spécifications standard OpenAPI. La documentation en ligne est disponible à cette adresse :
Aussi, vous pouvez désormais mettre à jour en version 1.28 un cluster déjà existant en autonomie. Pensez à avant de déclencher une mise à jour !
Une démonstration interactive est disponible dans la section démo :
Une démonstration interactive est disponible dans la section démo :
Les versions 3.12 et 3.13 sont désormais supportées par le PaaS RabbitMQ ! Pour plus d'informations, merci de lire la documentation RabbitMQainsi que les notes de mises à jour officielles.
La version 16 est maintenant supportée par le PaaS PostgreSQL ! Pour plus d'informations, merci de lire la documentation ainsi que les notes de mises à jour officielles.
Pour obtenir un token d'accès, le client doit soumettre une requête au endpoint . Le serveur d'autorisation exige l'authentification (base64-encodé) du client pour délivrer un access_token. Voici un exemple de demande d'access_token :
Elle ne peut appartenir qu'à un seul Service. Voir pour la définition d'un Service.
200
Demande traitée avec succès
Varie en fonction de la demande
201
Objet créé avec succès
Objet créé
202
Ordre de création de l'objet traité avec succès, la demande sera traitée de manière asynchrone
Objet vide ou objet de suivi décrivant le traitement de la demande asynchrone
400
Mauvaise requête - Erreur de syntaxe ou de cohérence dans la requête. Doit être corrigée par l'émetteur
Blanc ou indication de l'erreur à corriger du côté du client
401
Accès non autorisé à la ressource
Vide
403
Accès non autorisé
Vide
404
Ressource non existante
Vide
409
Conflit
Vide
422
Donnée incohérente
Vide
500
Erreur fatale de l'API
Vide
503
Service temporairement indisponible
Vide
Voir les ressources
Voir toutes les ressources et leurs informations. Lecture seule.
Gérer les maintenances
Capacité de gérer les maintenances.
Modifier les ressources
Capacité de modifier les ressources sauf création et suppression.
Gérer les ressources
Gestion complète des ressources.
Standard (STD)
Maintenance (DTM)
Operator (OPE)
Power (POW)
Bodies
create-instance
POW
start-instance
OPE
stop-instance
OPE
reset-instance
OPE
resize-compute-instance
OPE
delete-instance
POW
Instance monitoring
enable-monitoring-instance
OPE
disable-monitoring-instance
OPE
Snapshot of instances
create-snapshot
MNT
recover-snapshot
MNT
delete-snapshot
MNT
DNS aliases of instances
create-dns
OPE
delete-dns
OPE
LoadBalancers
create-lb
POW
start-lb
OPE
stop-lb
OPE
delete-lb
POW
Monitoring of LoadBalancers
enable-monitoring-lb
OPE
disable-monitoring-lb
OPE
Manage LoadBalancers
add-member-lb
OPE
delete-member-lb
OPE
update-member-state
OPE
DNS alias of LoadBalancers
create-dns-lb
OPE
delete-dns-lb
OPE
Manage maintenance
create-maintenance
MNT
delete-maintenance
MNT
Indicators
create-indicator
POW
update-indicator
POW
delete-indicator
POW
SMS
subscribe-vortext
POW
Storage Object
create-object-stores
POW
update-object-stores
OPE
delete-object-stores
POW
Storage Object - Users
create-user-objectstores
POW
update-user-objectstores
POW
delete-user-objectstores
POW
K8S Clusters
create-cluster
POW
create-cluster-namespace
OPE
delete-cluster-namespace
OPE
create-cluster-nodes
POW
delete-cluster-nodes
POW
EB
Zone Parisienne
EB4 : Boulogne-Billancourt
EB5 : Magny-les-Hameaux
ET
Zone Toulousaine
ET1 : Labège
ET2 : Balma
EB-HDS-A
Zone cliente
EB4
EB-HDS-B
Zone cliente
EB4
EB-HDS-C
Zone cliente
EB5
EB-A
Zone réservée au groupe Cegedim
EB4
EB-B
Zone réservée au groupe Cegedim
EB4
EB-C
Zone réservée au groupe Cegedim
EB5
ET-HDS-A
Zone cliente
ET1
ET-HDS-B
Zone cliente
ET1
ET-A
Zone réservée au groupe Cegedim
ET1
ET-B
Zone réservée au groupe Cegedim
ET1
Actif
La ressource est active et le service est disponible.
ACTIVE
Préparation
La ressource est en cours d'installation ou configuration. Le service n'est pas encore disponible.
PREPARATION
Inactif
La ressource est inactive et le service est indisponible.
INACTIVE
Vous pouvez explorer les spécifications de l'API et utiliser la fonctionnalité Test it afin d'exécuter et de tester les points de terminaison.
Deux types d'authentifications sont disponibles : Bearer ou Oauth.
Lorsque vous utilisez l'option Test it en Oauth, veuillez :
Sélectionner les scopes : openid
et email
Saisir le clientId : cgdm-itcare-api-academy
.
Pour utiliser l'option Bearer, veuiller consulter la section Authentication.
Notes :
Les paramètres Cookies, Headers sont optionels.
L'affichage de la fenêtre suite au clique sur Test it peut prendre quelques secondes.
Plusieurs produits sont disponibles au catalogue cegedim.cloud.
Ils sont classés par catégories dans les sections ci-dessous afin d'en avoir un aperçu rapide et la possibilité de naviguer directement vers la documentation publique associée.
La grande majorité de ces produits sont disponibles en self-service via ITCare, notre outil de gestion de plateforme cloud.
Pour plus d'informations sur nos offres commerciales, merci de consulter notre site officiel.
Les Instances virtuelles managées cegedim.cloud sont toutes, sauf AIX, disponibles à la consommation en libre-service via notre plateforme de gestion de cloud appelée ITCare.
Elles sont hautement personnalisables (stockage, surveillance, sauvegarde, réplication) et redimensionnables (processeurs et mémoire). Elles offrent la meilleure flexibilité lorsqu'un produit n'est pas disponible en mode plateforme en tant que service (PaaS).
Voici les systèmes d'exploitation et distributions supportés par cegedim.cloud :
Linux
Debian
Ubuntu
Centos
Red Hat Linux Enterprise (RHEL)
Windows Server
AIX
Les Conteneurs (K8s)sont des clusters Kubernetes dédiés disponibles à la consommation en libre-service dans notre plateforme de gestion de cloud nommé ITCare.
Kubernetes est une plateforme d'orchestration de conteneurs open-source qui automatise le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Elle est fournie en tant que service géré par cegedim.cloud et bénéficie de l'infrastructure, des opérations et du support que nous fournissons.
Cela inclut des fonctionnalités telles que la mise à l'échelle, la surveillance, les correctifs de sécurité et le déploiement simplifié, ce qui permet aux développeurs et aux équipes de se concentrer sur le développement d'applications et d'éviter les complexités liées à la gestion de l'infrastructure sous-jacente.
Matomo est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Selon le dimensionnement choisi pour faire face au nombre de pages suivies par mois, plusieurs composants seront déployés et managés par cegedim.cloud afin de vous permettre de vous focaliser sur l'utilisation et la configuration de Matomo.
MariaDB est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Instances
1
3
CPU (par instance)
2 - 16 vCPU
2 - 16 vCPU
RAM (par instance)
4 - 384 Go
4 - 384 Go
Stockage (par instance)
10 - 2048 Go
10 - 2048 Go
Version(s) supportée(s)
10.11
10.6
10.11
10.6
Surveillance
Surveillance 24/7
Sauvegarde
Réplication (PRA)
Disponibilité
99,8%
99,9%
Déploiement Multi-AZ
OpenSearch est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Instances
3 - 5+
CPU (par instance)
2 - 16 vCPU
RAM (par instance)
4 - 384 Go
Stockage (par instance)
100 - 8000 Go
Version(s) supportée(s)
2.x
Surveillance
Surveillance 24/7
Sauvegarde
Réplication (PRA)
Disponibilité
99,9%
Déploiement Multi-AZ
PostgreSQL est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Instance
1
2
CPU (par instance)
2 - 16 vCPU
2 - 16 vCPU
RAM (par instance)
4 - 384 Go
4 - 384 Go
Stockage (par instance)
10 - 2048 Go
10 - 2048 Go
Versions supportées
10 à 16
12 à 16
Surveillance
Surveillance 24/7
Sauvegarde
Réplication (PRA)
Disponibilité
99,8%
99,9%
Déploiement Multi-AZ
Redis est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Instance(s)
1
3
CPU (par instance)
2 - 16 vCPU
2 - 16 vCPU
RAM (par instance)
4 - 384 Go
4 - 384 Go
Stockage (par instance)
10 - 2048 Go
10 - 2048 Go
Version(s) supportée(s)
7.2
6.2
7.2
6.2
Surveillance
Surveillance 24/7
Sauvegarde
Réplication (PRA)
TLS/SSL
Disponibilité
99,8%
99.9%
Déploiement Multi-AZ
SQL Server est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Instance(s)
1
3
CPU (par instance)
2 - 16 vCPU
2 - 16 vCPU
RAM (par instance)
4 - 384 Go
4 - 384 Go
Stockage (par instance)
10 - 4096 Go
10 - 4096 Go
Version(s) supportée(s)
2022
2019
2017
2016
2022
2019
2017
2016
Surveillance
Surveillance 24/7
Sauvegarde
Réplication (PRA)
Disponibilité
99,8%
99.9%
Déploiement Multi-AZ
Apache Kafka est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Brokers
3+
Contrôleurs
3
CPU (par broker)
2 - 16 vCPU
RAM (par broker)
4 - 384 Go
Stockage
40 - 1024 Go
Version(s) supportée(s)
3.6.0
Surveillance
Surveillance 24/7
Sauvegarde
Réplication (PRA)
Disponibilité
99.9%
Déploiement Multi-AZ
RabbitMQest un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Instances
1
3
CPU (par instance)
2 - 16 vCPU
2 - 16 vCPU
RAM (par instance)
4 - 384 Go
4 - 384 Go
Stockage (par instance)
10 - 2048 Go
10 - 2048 Go
Version(s) supportée(s)
3.13
3.13
Surveillance
Surveillance 24/7
Sauvegarde
Réplication (PRA)
Disponibilité
99,8%
99,9%
Déploiement multi-AZ
La solution Advanced Vulnerability Assessment est un service d'analyse et de détection de vulnérabilités sur vos ressources exposées sur Internet.
Ce service n'est pas disponible en libre-service et nécessite une prise de contact avec l'équipe commerciale de cegedim.cloud.
Bot Defense est une fonctionnalité de protection contre les bots malicieux ainsi que les dénis de service distribués.
Elle est activable individuellement sur vos répartiteurs de charge directement depuis notre plateforme de gestion de cloud nommé ITCare.
Le service Campagne de Phishing est un service sur mesure qui permet d'évaluer l'efficacité de la sensibilisation à la sécurité du courrier électronique.
Ce service n'est pas disponible en libre-service et nécessite une prise de contact avec l'équipe commerciale de cegedim.cloud.
La solution Data Masking transforme les données sensibles contenues dans les bases de données en données moins sensibles, selon vos propres spécifications et besoins.
Ce service n'est pas disponible en libre-service et nécessite une prise de contact avec l'équipe commerciale de cegedim.cloud.
La solution de supervision avancée basée sur ExtraHop permet d'accéder à des tableaux de bords détaillés sur vos ressources.
Ce service est activable en libre-service via notre plateforme de gestion de cloud nommé ITCare.
GlusterFS est un système de fichiers distribué open-source qui permet un stockage évolutif et performant sur plusieurs serveurs. Il regroupe les ressources de stockage de plusieurs machines en un seul pool de stockage, offrant un espace de noms unique pour faciliter la gestion et l'accès.
Grâce à sa capacité à évoluer et à gérer de grandes quantités de données, GlusterFS offre des avantages tels que l'amélioration de la capacité de stockage, la tolérance aux pannes et la haute disponibilité pour diverses applications et charges de travail.
GlusterFS est un PaaS disponible à la consommation en libre-service via notre plateforme de gestion de cloud nommé ITCare.
Instance(s)
2
CPU (par instance)
2 vCPU
RAM (par instance)
4 Go
Version(s) supportée(s)
10.2
Surveillance
Surveillance 24/7
Sauvegarde
Réplication (PRA)
Disponibilité
99.9%
Déploiement Multi-AZ
La solution de Stockage Objet compatible S3 (Simple Storage Service) de cegedim.cloud est un service de stockage basé dans le cloud. Elle offre un stockage évolutif, sécurisé et durable pour différents types de données, notamment des fichiers, des images, des vidéos et des sauvegardes.
Les avantages d'une solution de stockage d'objets S3 comprennent une haute disponibilité, un stockage à faible coût, des contrôles d'accès flexibles, une redondance automatique des données et la possibilité de choisir différents fournisseurs et d'éviter la dépendance à l'égard d'un fournisseur.
Compatibilité S3
Géo-réplication
Quota
Object Lock
Cycle de vie des fichiers
URLs pré-signées
Comment cegedim.cloud supporte-t-il ses produits managés ?
Les offres managées de cegedim.cloud incluent du support. Ce support se découpe en 4 phases :
Phase standard : cegedim.cloud offre un support complet du produit.
Phase fin de vente : phase secondaire indiquant qu'une nouvelle version a été élue en phase de support Standard. Il est fortement conseillé d'effectuer une migration vers une version plus récente.
Phase support étendu : troisième phase qui débute à la date de fin de vie (EOL) annoncée par l'éditeur pour le produit. Cela signifie que plusieurs services ne sont plus garantis et passent en meilleurs efforts.
Phase fin de Support : phase terminale activée quand cegedim.cloud n'est plus en mesure de fournir du support. Des frais peuvent s'appliquer si le système est considéré comme un risque pour la sécurité (violation, compromission des données, nécessité d'isolation).
Voici un listing détaillé des fonctionnalités selon les phases de support :
Depuis de notre gestionnaire de plateforme cloud ITCare, vous pouvez créer un ticket de demande d'assistance.
Depuis la page d'accueil ou bien depuis la section Support dans le menu latéral gauche, cliquez sur le bouton Formuler une demande.
Recherchez d'abord le formulaire correspondant au produit pour lequel vous avez besoin d'aide en tapant le nom du produit dans la barre de recherche. Sélectionnez le formulaire et fournissez les informations requises.
Un ticket d'assistance sera créé lors de la soumission.
Les ressources gérées sont surveillées par cegedim.cloud si la surveillance a été activée.
Cependant, un formulaire d'incident est disponible dans notre gestionnaire de plateforme cloud ITCare si vous avez besoin de nous faire part d'un problème que nous aurions manqué.
Depuis la page d'accueil ou la section Support du menu latéral gauche, cliquez sur le bouton Déclarer un incident.
Pour mieux traiter votre incident, un niveau de gravité est requis :
Pas d'impact
Dégradation
Interruption de service
Recherchez le formulaire approprié en recherchant le nom du produit avec lequel vous avez un problème, puis fournissez les informations requises.
Un ticket d'incident sera créé et notre équipe de support vous contactera dès que possible.
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Supervision & Support d'incident technique
Requêtes standards
Temps de restauration garantie
Support 24x7 (option)
Sauvegarde, restauration et géo-réplication de données
Reprise d'activité en cas de désastre
Cybersécurité managée
Patches de sécurité et mise à jour mineures trimestrielles
Patches de sécurité critiques et mise à jour
Déploiement via ITCare
Comment cegedim.cloud gère le patching des serveurs ?
cegedim.cloud s'assure que tous les serveurs sont patchés lors d'événements appelés Patch Party. Ces événements ont lieu tous les trimestres un dimanche, soit 4 fois par an.
Lors d'une Patch Party, les patchs sont installés sur tous les serveurs non exclus de l'événement puis suivis d'un redémarrage.
Les services seront interrompus pendant une Patch Party !
Les Patch Parties ont lieu tous les trimestres, soit 4 fois par an. Deux Patch Parties sont programmées chaque trimestre :
Patch Party de QA : elle a lieu en premier pendant les heures ouvrées, le jeudi, et ne concerne que les environnements de non-production.
Patch Party de Production : elle a lieu 3 semaines après la Patch Party de QA, le dimanche, et ne s'applique qu'aux environnements de production.
Sur chaque page de détails d'une ressource, un panneau intitulé Patch status vous permet de consulter les informations suivantes :
La dernière fois que la ressource a été mise à jour avec succès
Le timestamp de la mise à jour
Le tag du correctif de la mise à jour avec ce format : YYYY-QQ (par exemple 2022-Q4)
La prochaine Patch Party programmée si la ressource n'est pas exclue
La personne qui a exclu la ressource et la date si la ressource est exclue
Sur chaque page de détails d'une ressource, un bouton Patch Party vous permet d'inclure ou d'exclure définitivement la ressource des Patch Party.
L'exclusion d'une ressource doit être motivée par une raison. Inclure vous permet de sélectionner le Patch Group qui affectera le moment où votre ressource sera effectivement mise à jour au cours de la journée de correctifs.
Dans le même bouton Patch Party que celui décrit ci-dessus, vous pouvez changer le Patch Group souhaité à tout moment.
3 groupes de patches sont disponibles pour diviser vos ressources. Chaque groupe sera traité à des moments différents.
Ceci est utile si vous ne voulez pas que plusieurs ressources soient patchées (et interrompues) en même temps, améliorant ainsi la résilience de votre application.
Matomo est disponible en libre-service dans ITCare pour tous les utilisateurs autorisés.
En fonction du dimensionnement choisi (voir les dimensionnements ci-dessous), plusieurs composants seront déployés avec un strict minimum de :
1 serveur web frontal
1 serveur de base de données
1 équilibreur de charge avec une adresse IP publique (certificat inclus)
Les tailles supérieures (pour suivre plus de pages vues par mois) peuvent inclure plus de serveurs web pour l'équilibrage de charge. Pour les tailles supérieures à XL, un ticket de demande sera nécessaire.
Une fois provisionnée, votre instance Matomo est accessible au public via l'URL fournie dans ITCare.
L'installation de plugins et les mises à jour de Matomo peuvent être effectuées par le client en toute autonomie.
Matomo est disponible dans les régions suivantes :
EMEA - France - Boulogne-Billancourt
EMEA - France - Toulouse
Les tailles suivantes sont disponibles :
XS
Suivi de 100 000 pages vues par mois ou moins
S
Suivi de 1 million de pages vues par mois ou moins
M
Suivi de 10 millions de pages vues par mois ou moins
L
Suivi de 100 millions de pages vues par mois ou moins
XL
Suivi de plus de 100 millions de pages vues par mois
Le redimensionnement est disponible dans le self-service ITCare mais ne permet que le redimensionnement vers le haut.
Le redimensionnement vers le bas n'est pas possible !
La version de Matomo déployée dépend de la dernière mise à jour de nos repository lors de la dernière patch party.
La dernière version sera souvent disponible mais il peut arriver que la version déployée ne soit pas la dernière.
Dans ce cas, la mise à jour peut être déclenchée par le client en autonomie directement depuis l'interface web UI ou sur demande en créant un ticket de demande dans ITCare.
Cette section énumère les fonctionnalités / capacités disponibles pour le client, ainsi que la manière de les demander / de les exécuter :
Libre-service
Le client peut effectuer des actions de manière autonome à l'aide d'ITCare.
Sur requête
Le client peut demander à l'équipe de support de cegedim.cloud de prendre les mesures nécessaires.
Mise à jour de Matomo
La mise à jour peut être effectuée par le super utilisateur.
Installer et activer des plugins
Les plugins peuvent être installés par le super utilisateur à partir de l'interface web.
Gérer les privilèges
Le super utilisateur peut accorder des privilèges à n'importe quel utilisateur.
Accès SSH
L'accès SSH est désactivé et réservé aux administrateurs de cegedim.cloud.
Modifier des fichiers de configuration
Sur demande avec un ticket.
Le client dispose d'un compte local super utilisateur.
OpenOIDC est configuré pour ajouter et autoriser facilement d'autres utilisateurs à accéder à Matomo.
L'accès à votre instance Matomo se fait de manière sécurisée via HTTPS.
Toutes les données sont stockées dans les centres de données de cegedim.cloud sur des baies de stockage cryptées.
Le mot de passe du compte super utilisateur fourni au client n'est pas stocké ni sauvegardé par cegedim.cloud.
Matomo et les composants associés sont surveillés par notre équipe de support. Un état de santé global est affiché dans ITCare pour votre confort.
Matomo (anciennement appelé Piwik) est un logiciel de mesure open source qui fournit des statistiques de données sur l'utilisation d'une page web, telles que les visites, les pages vues, l'origine des visites et bien plus encore.
Matomo offre la possibilité d'avoir une analyse complète sur certains aspects de vos sites web avec des informations concernant : vos visiteurs, leur comportement, leurs habitudes et plus encore.
Matomo est un excellent substitut à Google Analytics pour les raisons suivantes :
Pleine propriété des données
Protection de la vie privée
Pas d'échantillonnage de données
Conformité RGPD (recommandé par la CNIL)
Flexibilité (portabilité des données, accès brut, open source, etc...)
Matomo est déployé sur site dans les centres de données de cegedim.cloud et est fourni en tant que service.
cegedim.cloud garantit le niveau de service managé suivant : le déploiement des instances, le maintien en condition opérationnelle, la flexibilité, la sécurité et le monitoring sont ainsi assurés par nos experts.
Dimensions
XS
S
M
L
XL
Surveillance
Surveillance 24x7
Sauvegarde
Réplication de données (PRA)
Disponibilité
99,8%
Choix de la région
Libre-service
Pour plus d'information, veuillez consulter la page Matomo - Architecture.
La facturation est mensuelle et varie en fonction de la taille choisie. Veuillez contacter votre Service Delivery Manager pour plus d'informations concernant la tarification.
L'instance virtuelle est un produit entièrement géré proposé par cegedim.cloud, conçu pour simplifier et améliorer votre expérience d'hébergement. Avec les instances virtuelles, vous n'avez plus à vous soucier de la complexité de la gestion de votre infrastructure d'hébergement - notre équipe d'experts s'occupe de tout.
Notre produit prend en charge une variété de systèmes d'exploitation tels que Linux, Windows et AIX, ce qui vous donne la liberté de choisir l'environnement qui répond le mieux à vos besoins. Il peut être déployé sans effort grâce à notre outil de gestion de plateforme cloud convivial appelé ITCare.
Cet outil vous donne la possibilité de démarrer l'instance souhaitée, de sélectionner le système d'exploitation de votre choix et de personnaliser les ressources pour répondre à vos besoins spécifiques en quelques clics, garantissant ainsi que vos instances sont adaptées aux exigences de votre entreprise.
Nous comprenons l'importance des performances et de la fiabilité, c'est pourquoi les instances virtuelles sont équipées de systèmes de surveillance, de services de sauvegarde et de réplication des données. Cela garantit une visibilité en temps réel de la santé de vos instances et une sécurité accrue.
En résumé, que vous ayez besoin d'un système d'exploitation Linux, Windows ou AIX, et quelles que soient vos exigences en matière de ressources, les instances virtuelles vous offrent la flexibilité et l'évolutivité dont vous avez besoin.
La configuration des ressources peut varier en fonction du système d'exploitation cible.
Systèmes d'exploitation supportés
Linux
Windows
AIX
CPU (par instance)
2 - 16
RAM (par instance)
4 - 384 Go
Stockage (par instance)
35 - 4096 Go
Surveillance
Surveillance 24x7
Sauvegarde
Réplication de données (PRA)
Disponibilité
99,8%
Choix de la région et de la zone de disponibilité
Libre-service
Pour plus d'information sur les instances virtuelles, vous pouvez consulter https://code.cegedim.cloud/product-management/gitbook/french-documentation/-/blob/main/calcul/instances-virtuelles/instances-virtuelles-architectures.md.
La facturation est mensuelle et basée sur le nombre d'instances et les coûts supplémentaires pour le stockage, la sauvegarde, la surveillance 24x7.
L'estimation du coût d'une instance virtuelle est disponible auprès de votre Service Delivery Manager.
Connectez-vous à la plateforme ITCare, cliquez sur le bouton Statistiques dans le menu principal à gauche. Cliquez sur "Créer une instance Matomo" et suivez les instructions.
Indiquez le service global dans lequel vous souhaitez créer une instance Matomo.
Donnez le nom de l'instance que vous voulez créer. Un nom de site web et une URL par défaut peuvent être configurés pendant le provisionnement. Ils sont facultatifs. S'ils sont laissés vides, des valeurs fictives seront utilisées. Cliquez sur Suivant.
Choisissez la taille de l'instance de Matomo Analytics correspondant à vos besoins et cliquez sur Suivant.
Fournissez le mot de passe du super utilisateur nommé "administrator" qui vous sera donné.
Le mot de passe du super utilisateur n'est pas sauvegardé par cegedim.cloud.
Veillez à sauvegarder votre mot de passe!
A l'étape suivante, vous pouvez configurer les options de gestion :
Surveillance (fortement recommandé)
Surveillance 24/7
Sauvegarde (fortement recommandé)
Réplication du stockage
Cliquez sur Suivant.
Sélectionnez la région dans laquelle vous souhaitez créer votre instance Matomo.
Cliquez sur Suivant.
Vérifiez vos entrées dans la page de synthèse. Vous pouvez :
Vérifier l'instance qui sera créée
Voir le service global cible
Enregistrer votre mot de passe administrateur
Vérifier les options de gestion
Cliquer sur Soumettre une fois prêt.
Une fois que l'instance est prête, vous recevrez un e-mail contenant les informations nécessaires pour vous y connecter.
Allez dans le menu Statistiques du menu principal de gauche et cliquez sur le lien Gérer.
Une fois que toutes les instances Matomo sont présentées, cliquez sur le bouton de démarrage de l'instance de votre choix. Le démarrage d'une instance Matomo démarre tous les composants.
Une notification par e-mail sera envoyée lorsque le service sera activé.
Allez dans le menu Statistiques du menu principal de gauche et cliquez sur le lien Gérer.
Une fois que toutes les instances de Matomo sont présentées, cliquez sur le bouton d'arrêt de l'instance de votre choix. Saisissez un numéro RFC pour le suivi (facultatif) puis validez en cliquant sur Stop. L'arrêt d'une instance Matomo arrêtera tous les composants et la surveillance sera désactivée.
Une notification par e-mail sera envoyée lorsque l'instance sera arrêtée.
Allez dans le menu Statistiques à partir du menu principal de gauche et cliquez sur le lien Gérer.
Une fois que toutes les instances Matomo sont affichées, cliquez sur le bouton de suppression de l'instance de votre choix.
Cette action supprimera tous les composants utilisés par cette instance Matomo.
Veuillez noter que cette action n'est pas récupérable.
Saisissez un numéro RFC pour le suivi (facultatif) et le nom de l'instance (captcha obligatoire) pour confirmer votre choix, puis cliquez sur Supprimer.
Une notification par e-mail sera envoyée lorsque l'instance sera supprimée.
Allez dans le menu Statistiques du menu principal de gauche et cliquez sur le lien Gérer.
Une fois que toutes les instances de Matomo sont présentées, cliquez sur le bouton de redimensionnement de l'instance de votre choix.
Sélectionnez la nouvelle taille qui ne peut être que supérieure à la taille actuelle et cliquez sur Redimensionner.
Le service sera interrompu pendant la durée de l'opération (quelques minutes).
Une notification par e-mail sera envoyée lorsque l'instance sera redimensionnée.
Connectez-vous à votre instance Matomo Analytics avec l'utilisateur "administrator" que vous avez fourni lors du provisionnement.
Cliquez sur l'icône Administration représenté par une roue crantée :\
Sélectionnez le menu "Extensions" dans la catégorie "Système"
Allez à la fin de la page et cliquez sur le bouton "Installer de nouveaux composants" :
Recherchez, installez et activez les modules à votre guise :\
Connectez-vous à votre instance Matomo Analytics avec l'utilisateur "administrator".
Cliquez sur l'icône d'administration
Cliquez en haut de la page sur le message indiquant une nouvelle version
Confirmer la mise à jour automatique\
Attendre la fin de la mise à jour avec un message de réussite\
Le partage des responsabilités
Pour avoir une compréhension commune des responsabilités et des devoirs entre cegedim.cloud et le client, nous utilisons une matrice RACI applicable à nos produits managés.
R
Responsable (acteur)
Assigné à la réalisation de la tâche ou du produit à livrer
A
Responsable (décisionnaire)
A le pouvoir de décision final et la responsabilité de l'achèvement (1 seul par tâche)
C
Consulté
Un conseiller, une partie prenante ou un expert en la matière qui est consulté avant une décision ou une action.
I
Informé
Doit être informé après une décision ou une action
Vous trouverez ci-dessous les matrices RACI décrivant les actions liées à la gestion des produits managés du catalogue cegedim.cloud.
Il existe de légères différences en fonction du plan souscrit par le client :
Libre-service
Le client peut créer des ressources directement à travers ITCare, en utilisant le libre-service et le paiement à l'utilisation.
Sur requête
Les ressources sont provisionnées et livrées par cegedim.cloud à la demande du client.
Créer, Arrêter, Démarrer, Supprimer une instance ou un cluster
Libre-service
I
A / R
La décision de provisionner / arrêter / démarrer / supprimer est prise par le client.
Les actions sont effectuées :
par les clients par le biais d'ITCare s'ils ont souscrit au service "On Demand".
pour d'autres clients, par l'équipe des services professionnels de cegedim.cloud
Utiliser une instance ou un cluster
*
I
A / R
Le client est responsable de l'utilisation saine du produit.
Modifier les configurations
Sur requête
A / R
I
À la demande du client, certains paramètres de configuration peuvent être modifiés.
Surveillance standard
*
A / R
I
La surveillance est obligatoire et le client peut y accéder par le biais d'ITCare.
Métriques de performance
*
R
I
Les mesures de performance sont fournies par défaut et sont accessibles via ITCare.
Sauvegarde et restauration
*
R
A / I
La politique de sauvegarde est définie par le client et appliquée par cegedim.cloud, qui est chargé de s'assurer que les sauvegardes sont effectuées, et de restaurer les données sur demande.
Le client dispose d'informations sur la sauvegarde dans ITCare.
Protection contre la reprise après sinistre
*
R
A / I
Le Disaster Recovery est activé par le client et appliqué par cegedim.cloud, qui est chargé de s'assurer que les RTO et RPO associés sont atteints.
Le client dispose d'informations sur la protection contre les sinistres dans ITCare.
Correctifs de sécurité
*
R
A / I
cegedim.cloud applique les patchs de sécurité dans l'environnement d'exécution, trimestriellement, lors des "Patch parties", par défaut.
Le client peut choisir d'exclure une instance de l'application des correctifs via ITCare.
Mises à jour des versions
Sur requête ou Libre-service
R
A / I
La mise à jour peut parfois être effectuée par le client depuis ITCare en autonomie OU une demande peut être émise par le client, et si la transition est possible, cegedim.cloud effectuera la mise à jour ou l'upgrade de la version du produit.
Certains de nos produits disposent d'actions spécifiques qui peuvent être réalisées au autonomie et en libre-service depuis notre outils de gestion de cloud ITCare. Les matrices ci-dessous sont donc complémentaires à la matrice RACI générique.
Ajouter un nœud Kubernetes
Libre-service
I
A / R
Le Client peut ajouter des nœuds Kubernetes en libre-service via ITCare.
Redimensionner un nœud Kubernetes
Libre-service
I
A / R
Le Client peut redimensionner des nœuds Kubernetes en libre-service via ITCare.
Supprimer un nœud Kubernetes
Libre-service
I
A / R
Le Client peut supprimer des nœuds Kubernetes en libre-service via ITCare.
Activer le mode HA sur un cluster Kubernetes
Libre-service
I
A / R
Le Client peut activer la Haute disponibilité sur un cluster Kubernetes en libre-service via ITCare.
Ajouter une réplique MariaDB en lecture seule
Sur requête
A / R
I
Sur demande, une réplique MariaDB en lecture seule peut être configurée pour un nœud MariaDB autonome.
Gestion des Index
*
I
A / R
Le client est responsable de la création et de la gestion de ses index. cegedim.cloud n'y a pas accès à l'exception de l'index security_audit.
Restaurer PostgreSQL source vers destination
Libre-service
I
A / R
La décision de restaurer un PostgreSQL sur un autre déploiement PostgreSQL est prise par le client. Les actions sont effectuées:
par le biais d'ITCare s'ils ont souscrit au service "On Demand".
par l'équipe Professionnals Services de cegedim.cloud
Conversion en Haute disponibilité
Libre-service
I
A / R
La décision de restaurer un PostgreSQL sur un autre déploiement PostgreSQL est prise par le client. Les actions sont effectuées:
par le biais d'ITCare s'ils ont souscrit au service "On Demand".
par l'équipe Professionnals Services de cegedim.cloud
Gérer les objets Apache Kafka
*
I
A / R
Le client est responsable de la gestion des objets Apache Kafka (topics, partitions, etc.) et de leur bonne utilisation.
Gérer les objets RabbitMQ
*
I
A / R
Le client est responsable de la gestion des objets RabbitMQ (échanges, files d'attente, etc.) et de leur bonne utilisation.
Activer / Désactiver l'option Bot Defense sur un Load Balancer
Libre-service
I
A / R
La décision d'activer/désactiver l'option Bot Defense est prise par le client.
Ajouter ou supprimer une IP sur la whitelist
Libre-service
I
A / R
Le client peut ajouter ou supprimer une IP sur la whitelist.
Accès aux DDOS et aux requêtes bloquées de Bot Defense et Dos Protection
Libre-service
I
A / R
Signalez en temps réel les demandes bloquées (y compris l'adresse IP bloquée, la raison du blocage et l'ID du support).
Demande de détails sur la demande bloquée
Sur requête
A / R
I
À la demande du client, des informations supplémentaires peuvent être fournies pour une demande bloquée en fournissant l'identifiant du support.
Désigner un champion et définir les objectifs de masquage des données
*
I
A / R
Définir le contexte du masquage
*
I
A / R
Identifier les données sensibles à masquer (spécifications)
*
I
A / R
Identifier les contraintes d'intégrité des données dans la base de données
*
I
A / R
PDM : découverte et marquage des données sensibles
*
A / R
I / C
PDM : Définition des règles de masquage et de la politique de masquage
*
A / R
I / C
PDM : Facultatif : mise en œuvre de règles et de dictionnaires personnalisés
*
A / R
I / C
PDM : Création et exécution du plan de masquage*
10 traitements d'anonymisation inclus
Abonnement de 12 mois
Options : Paquet de 10 traitements d'anonymisation supplémentaires à utiliser pendant la période d'abonnement.
*
A / R
I / C
Vérification des résultats et validation de l'efficacité du masquage
*
I
A / R
*Chaque exécution comprend : la vérification des prérequis, l'exécution du script, le suivi de l'exécution par un expert en sécurité informatique en contact direct avec le client.
Gérer les volumes de stockage
Libre-service
I
A / R
Le client est responsable de la gestion (création, suppression, redimensionnement) des volumes de stockage pour son cluster.
Créer un Object Store
Libre-service
I
A / R
La décision de provisionner / supprimer / modifier un Object Store et les paramètres associés est prise par le client.
Les actions sont effectuées :
par les clients par le biais d'ITCare s'ils ont souscrit au plan "Libre service".
pour les autres clients, par les équipes Professional Services de cegedim.cloud
Gérer le quota des Object Store
Libre-service
I
A / R
Supprimer un Object Store
Libre-service
I
A / R
Créer un Object User
Libre-service
I
A / R
La décision de créer un utilisateur d'objet et les paramètres associés est prise par le client.
Les actions sont effectuées :
par les clients par le biais d'ITCare s'ils ont souscrit au plan "Libre service".
pour d'autres clients, par les équipes Professional Services de cegedim.cloud
Gérer les Object Users
Libre-service
I
A / R
La décision de modifier un utilisateur d'objet et les paramètres associés est prise par le client.
Ces actions comprennent le renouvellement de la clé secrète ou le verrouillage de l'utilisateur de l'objet.
Les actions sont effectuées :
par les clients par le biais d'ITCare s'ils ont souscrit au plan "Libre service".
pour les autres clients, par les équipes Professional Services de cegedim.cloud
Supprimer un Object User
Libre-service
I
A / R
La décision de supprimer un utilisateur d'objet et les paramètres associés est prise par le client.
Les actions sont effectuées :
par les clients par le biais d'ITCare s'ils ont souscrit au plan "Libre service".
pour les autres clients, par les équipes Professional Services de cegedim.cloud
Créer un Bucket
Libre-service
I
A / R
La création des buckets et des paramètres associés est faite par le client.
Les actions sont effectuées en utilisant l'API S3
Supprimer un Bucket
Libre-service
I
A / R
La suppression des buckets et des paramètres associés est effectuée par le client.
Les actions sont effectuées en utilisant l'API S3
Appliquer une politique de gestion des buckets
Libre-service
I
A / R
La gestion de la politique du panier est effectuée par le client.
Les actions sont effectuées en utilisant l'API S3
Appliquer une politique de gestion du cycle de vie
Libre-service
I
A / R
La gestion du cycle de vie de la configuration est assurée par le client.
Les actions sont effectuées en utilisant l'API S3
Gérer la configuration Object Lock
Libre-service
I
A / R
les configurations Object Lock, appliquées sur les buckets ou les objets, sont réalisés par le client
Les actions sont effectuées en utilisant l'API S3
Disponibilité et Supervision
*
R / A
I
cegedim.cloud s'assure que le service de stockage d'objets est disponible et fonctionnel à tout moment.
Réplication multi-régions
*
R / A
I
La réplication des données entre les régions est gérée par cegedim.cloud qui assure que les RTO et RPO associés sont atteints.
Le client dispose d'informations sur la protection contre les sinistres dans ITCare.
Correctifs de sécurité
*
R / A
I
cegedim.cloud est en charge d'appliquer les correctifs de sécurité.
Cette action est transparente pour les utilisateurs et n'entraîne pas d'interruption de service.
Mises à jour
*
R / A
I
cegedim.cloud est en charge d'appliquer les mises à jour.
Cette action est transparente pour les utilisateurs et n'entraîne pas d'interruption de service.
l'API S3 est susceptible d'être modifiée.
Les distributions Linux suivantes sont disponibles lorsque vous sélectionnez Linux comme système d'exploitation pour votre Instance Virtuelle :
Centos
Debian
Ubuntu
Red Hat Linux Enterprise (RHEL)
Oracle Linux
Windows Server est disponible comme système d'exploitation pour votre Instance Virtuelle. cegedim.cloud supporte plusieurs versions de Windows Server 2022 à Windows Server 2012R2.
cegedim.cloud supporte le système d'exploitation IBM AIX sur les systèmes IBM Power. La version actuellement supportée est la version majeure 7 et les versions de niveau technologique associées.
Les instances virtuelles sont disponibles dans les centres de données cegedim.cloud suivants :
EB4 - Boulogne-Billancourt, France
EB5 - Magny-les-Hameaux, France
ET1 - Labège, France
ET2 - Balma, France
Une Instance Virtuelle peut être configurée et personnalisée selon vos besoins :
Calcul : nombre de vCPU
RAM : quantité de mémoire allouée (varie en fonction du nombre de vCPU)
Stockage : disques et stockage supplémentaires en Go à allouer à l'instance virtuelle
Cette section énumère les fonctions / capacités disponibles pour le client, et la manière de les demander / de les exécuter :
L'authentification dans l'instance virtuelle est basée sur Active Directory pour Linux et Windows (pas pour AIX qui reste en utilisateurs locaux). L'utilisateur demandeur sera automatiquement ajouté en tant qu'administrateur de l'instance virtuelle. Cet utilisateur est ensuite libre de configurer et d'ajouter d'autres utilisateurs avec les privilèges souhaités.
La sauvegarde est une option qui peut être activée pour votre instance virtuelle. Dans un environnement de production, l'option de sauvegarde sera toujours activée par défaut dans ITCare.
Vous pouvez désactiver l'option de sauvegarde à vos risques et périls.
Les sauvegardes sont effectuées tous les jours et sauvegardées dans le centre de données local, puis répliquées dans un second centre de données sur le campus. La durée de conservation des sauvegardes pour les instances virtuelles est de 28 jours par défaut, mais elle peut être adaptée à vos besoins avec votre Service Delivery Manager.
La date de la dernière sauvegarde et l'empreinte de stockage de la sauvegarde peuvent être consultées directement dans ITCare sur la page des détails de la ressource de votre instance virtuelle.
Comme indiqué, les instances virtuelles sont gérées et la surveillance est donc assurée si l'option a été cochée. Dans un environnement de production, l'option de surveillance est toujours activée par défaut.
Vous pouvez désactiver l'option de surveillance à vos risques et périls.
En activant la surveillance, plusieurs contrôles de santé seront déployés pour s'assurer que votre instance virtuelle fonctionne et reste saine. Si l'un de ces contrôles est déclenché, notre équipe de support est avertie par un ticket afin de résoudre le problème dans le cadre du niveau d'accord de service autorisé.
Ces alertes de surveillance peuvent être consultées directement dans ITCare et des métriques de performance sont également fournies pour les indicateurs clés tels que le CPU, la mémoire, le disque et la consommation du réseau.
Lorsque la surveillance est activée, elle n'est effective que pendant les heures ouvrées. Pour étendre la surveillance en dehors des heures ouvrées, l'option 24x7 peut être activée et des frais supplémentaires seront appliqués.
Cette option garantit que votre instance virtuelle est surveillée à tout moment par notre équipe de support et que des mesures seront prises pour escalader et résoudre tout problème.
La réplication des données est une fonction qui permet la protection de la reprise après sinistre. Lorsque cette fonction est activée, les données de votre instance virtuelle sont répliquées depuis la baie de stockage locale vers une baie de stockage hors site.
Cela signifie qu'en cas de perte du centre de données local, vos données sont toujours en sécurité dans un autre centre de données et la procédure de restauration et de relance de votre Instance Virtuelle peut être activée.
Vous pouvez désactiver l'option de réplication à vos risques et périls.
Option
Option
Option
Option
Option
Option
Option
Option
Libre service
Le client peut effectuer une action de manière autonome.
Sur demande
Le client peut demander à l'équipe de support de cegedim.cloud de prendre les mesures nécessaires via un ticket.
Accès SSH ou RDP
L'accès SSH ou RDP est autorisé et automatiquement fourni au demandeur de l'instance virtuelle.
Démarrer, arrêter, redémarrer, supprimer et redimensionner une instance virtuelle
Actions disponibles en libre-service dans notre outil de gestion de la plateforme en nuage ITCare.
Créer, supprimer, restaurer un instantané
Actions disponibles en libre-service dans notre outil de gestion de la plateforme en nuage ITCare.
Activer ou désactiver la surveillance, le 24x7, la sauvegarde et la réplication des données
Actions disponibles en libre-service dans notre outil de gestion de la plateforme en nuage ITCare.
Ajouter ou supprimer une plage de maintenance
Actions disponibles en libre-service dans notre outil de gestion de la plateforme en nuage ITCare.
Modifier l'allocation de l'espace de stockage
Un ticket de requête est nécessaire pour modifier l'allocation de stockage d'une Instance Virtuelle.
Modifier un fichier de configuration
Certains fichiers de configuration (tels que les repository) seront gérés par cegedim.cloud. Un ticket requête est nécessaire pour modifier certains de ces composants.
Pour créer une nouvelle instance virtuelle, rendez-vous sur ITCare et recherchez votre service global cible où vous créerez votre nouvelle instance.
Recherchez votre service global dans la barre de recherche supérieure et cliquez dessus pour afficher sa page d'information. Une fois dans votre service global, cliquez sur le bouton Créer une ressource, sélectionnez Linux, Windows ou AIX et la version et/ou la distribution souhaitée.
Remplir les champs :
Nom de la machine virtuelle
Dimensionnement du CPU/RAM
Disques et capacité de stockage pour chaque disque
Emplacement de la cible
Réseau cible
Options de gestion (sauvegarde, surveillance, surveillance 24x7, réplication des données)
Cliquez sur Suivant une fois que tous les champs ont été remplis.
Lors de l'étape de personnalisation, vous pouvez :
Formuler une requête spécifique (il est à noter que cela retardera la tâche automatisée car cela déclenchera une intervention humaine)
Créer plusieurs instances avec la même configuration (noms et emplacement à fournir)
Cliquez ensuite sur Suivant.
Lisez le résumé avant de soumettre le formulaire.
Une fois que le déploiement est prêt, vous en serez informé par e-mail.
Quelle que soit l'instance ou le système d'exploitation auquel vous devez vous connecter, l'utilisation d'un Bastion est obligatoire. Vous devez d'abord vous connecter au Bastion assigné à votre locataire, à partir duquel vous pouvez ensuite initier une connexion SSH ou RDP à vos instances.
Connexion SSH en utilisant Putty ou mRemoteNG installé sur votre Bastion. Les identifiants à utiliser sont vos propres identifiants d'utilisateur adm.corp.
La connexion directe en tant qu'utilisateur root est désactivée sur toutes les instances virtuelles Linux. Vous devez vous connecter avec un utilisateur non root, puis utiliser les permissions sudoers pour effectuer des actions à haut privilège.
Deux méthodes d'authentification sont autorisées :
LDAP
Clé publique et privée
Pour se connecter via SSH en utilisant la méthode d'authentification LDAP, vous devez avoir un compte valide dans le même domaine LDAP que celui dans lequel votre instance virtuelle est inscrite.
Il n'est pas nécessaire de spécifier le nom du domaine LDAP dans votre login.
Lors de la première connexion, votre répertoire personnel sera automatiquement créé : /home/<yourlogin>/
Pour obtenir la liste des commandes autorisées, entrez la commande suivante : sudo -l
Pour se connecter à une instance virtuelle linux avec votre clé publique SSH, votre clé doit être ajoutée au fichier /home/<user>/.ssh/authorized_keys.
Où <user> est le nom du compte local sur le serveur cible et login spécifie le nom de l'utilisateur local : ssh user@host
Connexion RDP en utilisant Remote Desktop de mRemoteNG ou Windows mstsc intégré sur votre Bastion. Les identifiants à utiliser sont ceux de l'utilisateur adm.corp.
Connexion SSH en utilisant Putty ou mRemoteNG installé sur votre Bastion. Un compte utilisateur local avec un accès sudo ou root sera fourni lors de la livraison de l'instance.
our lister les utilisateurs et groupes LDAP autorisés à se connecter, utilisez la commande suivante :
simple_allow_groups : groupes LDAP
simple_allow_users : utilisateurs LDAP
Pour autoriser la connexion d'un utilisateur LDAP, utilisez la commande suivante :
Pour autoriser la connexion à un groupe LDAP, utilisez la commande suivante :
Pour supprimer l'accès à un utilisateur ou groupe LDAP, utilisez la commande suivante :
Pour accorder des droits sudo à des utilisateurs ou groupes LDAP (ainsi qu'à des utilisateurs ou groupes locaux), créez un nouveau fichier dans /etc/sudoers.d
Il n'est pas recommandé d'ajouter des instructions sudoers dans le fichier /etc/sudoers. Réservé au système.
Utilisez la commande visudo pour éditer votre fichier sudoers :
Pour demander l'ajout d'une réplique en lecture seule de MariaDB, il est nécessaire de créer un ticket requête via ITCare.
Dans la section Support du menu latéral gauche, cliquer sur le bouton Formuler une demande.
Dans la catégorie Base de données puis MariaDB, sélectionner et remplir le formulaire : Mise en place d'une réplication passive MariaDB
Un ticket d'assistance sera créé à la soumission.
Les distributions Linux suivantes peuvent être renforcées pendant l'approvisionnement :
Debian à partir de la version 11
Ubuntu à partir de la version 22.04
Oracle Linux à partir de la version 9
Certains systèmes de fichiers faibles sont désactivés dans le noyau
Points de montage séparés pour les systèmes de fichiers très actifs : /var/log, /var/log/audit, /var/tmp
Protection des points de montage /var/log, /tmp et /var/tmp
Désactivation du stockage amovible
S'assurer que le mot de passe root est requis pour démarrer en mode de secours
Traçage de chaque utilisation de la commande sudo
Plusieurs paramètres sont activés dans le noyau pour protéger les processus en cours d'exécution
Les services réseau inutiles ou faibles sont désactivés (appliqué par le gestionnaire de configuration)
Le service de gestion du temps est configuré et actif
IPV6 est désactivé
Plusieurs paramètres du noyau sont définis pour protéger le réseau
Désactiver les protocoles réseau peu courants
Centralisation des journaux du système
S'assurer que chaque événement est enregistré
S'assurer que le service cron est actif et configuré
S'assurer que les répertoires cron sont protégés
S'assurer que ssh est actif et configuré
Forcer les protocoles et paramètres sécurisés de ssh
S'assurer de la désactivation des sessions inactives
S'assurer que les règles de mot de passe fort sont appliquées
S'assurer que les fichiers d'authentification sensibles sont protégés
cegedim.cloud fournit des clusters Kubernetes gérés, avec le plus haut niveau de sécurité et de résilience intégré.
En utilisant ces clusters, vous pouvez déployer vos workloads Kubernetes standards dans les centres de données cegedim.cloud afin de maximiser la disponibilité de vos applications.
cegedim.cloud fournit également une console Rancher, où vous pouvez gérer vos workloads, et configurer les capacités d'observabilité intégrées (Logging et Métrologie) pour la connecter à vos propres plateformes (Grafana, ElasticSearch...).
Les principaux objectifs du projet Container en tant que Service sont :
Capacité à fournir des clusters Kubernetes de dernière génération à la demande.
Application Stateful supportée
Prise en charge des volumes persistants avec Auto-Provisioning et Haute Disponibilité
Respecter les normes réseau, les règles de stockage et de sécurité.
Une sécurité renforcée
Système de surveillance et de métriques intégré à la demande pour chaque application
Prise en charge des règles de réseau dynamiques
Nœuds
2 - 256
CPU (par nœud)
2 - 16
RAM (par nœud)
6 - 256 Go
Surveillance
Surveillance 24x7
Sauvegarde des nœuds
Sauvegarde ETCD
Toutes les 2 heures avec 7 jours de rétention
Sauvegarde des volumes persistants
Réplication de données (PRA)
Haute disponibilité
Disponibilité
99,9%
Choix de la région
Libre-service
Pour plus d'information, veuillez consulter la page K8s - Architecture.
La facturation est mensuelle et basée sur le nombre de nœuds et sur les coûts supplémentaires tel que le stockage et la sauvegarde.
L'estimation des coûts pour un cluster Kubernetes est disponible via votre Service Delivery Manager.
Il existe 3 topologies possibles pour le cluster K8s fourni par cegedim.cloud :
Standalone : les charges de travail sont déployées dans un seul centre de données sans plan de reprise après sinistre.
Standard : les charges de travail sont toujours déployées dans un seul centre de données, mais elles sont protégées contre un désastre du centre de données en utilisant un centre de données secondaire comme basculement.
Haute disponibilité : les charges de travail sont déployées dans deux centres de données et aucune interruption des services en cas de sinistre du centre de données ne peut être obtenue avec un déploiement multi-réplica correctement distribué.
cegedim.cloud fournit une topologie de calcul basée sur :
Région : une paire de centres de données
Area : isolation du réseau d'infrastructure entre les locataires
Zones de disponibilité : à l'intérieur d'une zone, infrastructure isolée pour le calcul et le stockage.
Les clusters Kubernetes peuvent être déployés à l'aide de 2 topologies :
Standard
1
1
2
2
4h
Haute Disponibilité
3
2
3
4
0 - 5 min
En fonction de vos exigences en termes de RTO et de coûts, vous pouvez choisir la topologie la mieux adaptée à vos besoins.
Standard
High Availability
Pour plus de détails sur la topologie de haute disponibilité, veuillez suivre cette page : Haute Disponibilité
cegedim.cloud utilise des clés topologiques standard :
topology.kubernetes.io/region
Région
topology.kubernetes.io/zone
Zone de disponibilité
kubernetes.io/hostname
FQDN du noeud
Depuis Kubernetes > 1.20, failure-domain.beta.kubernetes.io/zone est obsolète mais reste disponible en cas de préexistence. Seul topology.kubernetes.io/zone sera officiellement maintenu.
Voici la liste des composants et des outils qui sont déployés dans un cluster standard livré :
Rancher
2.9.2
Kubernetes
1.30
Ingress controllers
ingress-nginx 1.10.0, traefik 2.11.2, istio 1.20.3
Prometheus
2.42.0
Grafana
9.1.5
Helm
3.13.3
CSI Ceph
3.11.0
Node OS
Ubuntu 22.04
CNI - canal (Calico+Flannel)
3.28.1
Docker
27.1.2
Voici un schéma avec tous les composants du réseau expliqués :
Deux pods de 2 namespaces appartenant au même projet Rancher peuvent communiquer entre eux.
Deux pods de 2 namespaces appartenant à deux projets Rancher différents ne peuvent pas communiquer entre eux à moins que l'utilisateur ne définisse une Network Policy dédiée à ce besoin.
Les pods d'un projet Rancher nommé System peuvent communiquer avec les pods d'autres projets Rancher.
Les pods ne peuvent envoyer des requêtes qu'aux serveurs du même VLAN, à moins qu'une règle d'ouverture de réseau spécifique ne soit configurée entre les deux VLANs.
Les pods ne peuvent pas envoyer de requêtes à Internet à moins qu'un proxy ne soit configuré à l'intérieur du pod ou qu'une règle d'ouverture de réseau spécifique ne soit configurée pour le VLAN concerné.
Les requêtes vers le serveur api kube peuvent faire l'objet d'une proxy inverse par l'URL Rancher.
La charge de travail hébergée par les pods ne peut pas être directement accessible depuis l'extérieur du cluster K8S, mais via une couche d'entrée pour le protocole HTTP ou via un service NodePort pour le protocole TCP avec un équilibreur de charge respectif.
nginx est l'ingress controller déployé pour exposer vos workloads. Vous pouvez trouver la documentation pertinente sur le Github officiel à l'adresse :
Deux ingress controllers sont déployés :
Un exposé au réseau interne de Cegedim
ingress controller nginx
écoute sur chaque nœud de travail sur le port :80
il s'agit de la classe d'entrée par défaut (aucune classe d'entrée ne doit être spécifiée).
Un exposé à internet
nginx ingress controller - vous pouvez demander à avoir un ingress controller externe pour nginx.
écoute de chaque nœud de travail sur le port : 8081
cette ingress classe est : nginx-ext
en utilisant l'annotation : kubernetes.io/ingress.class:"nginx-ext"
Un cluster K8s est livré avec :
Un Elastic Secured Endpoint, géré par des appliances F5, exposant la charge de travail K8s au réseau interne de Cegedim (une fois que vous êtes connecté au LAN de Cegedim, soit physiquement, soit par VPN).
Une résolution DNS *.<votreclustername>.ccs.cegedim.cloud
vers ce point d'accès.
Un certificat SSL *.<votreclustername>.ccs.cegedim.cloud
configuré
Vous pouvez utiliser ITCare en cas de besoin d'une configuration spécifique :
Exposition de vos charges de travail à l'Internet ou à un lien privé
Utilisation d'un FQDN spécifique pour déployer votre charge de travail
Utilisation d'un certificat spécifique pour déployer votre charge de travail
Utilisation de Traefik comme fournisseur d'intrusion au lieu de nginx
Ajout d'autres fournisseurs d'entrée
Accès aux ressources en dehors du cluster
Pour plus d'informations concernant le hardening de Kubernetes, nous vous invitons à consulter cette page : Hardening
Pour plus d'informations sur la solution de stockage persistant disponible pour cegedim.cloud de cegedim.cloud, veuillez suivre cette page : Stockage Persistant
Kubernetes dispose de fonctionnalités et de mécanismes intégrés pour maintenir en bonne santé les nœuds et les workoads kubernetes :
kube-scheduler décide sur quels nœuds placer les pods en fonction des ressources demandées par les pods et des ressources non réservées des nœuds.
kubelet Out-Of-Memory tue les pods qui consomment plus de ressources que les valeurs limitées définies dans la spécification (OOM killed).
Pour quelque raison que ce soit, si le nœud est à court de ressources, kubelet expulse les pods afin d'alléger la pression sur les nœuds (éviction des pods). La décision d'éviction des pods est basée sur la qualité de service des pods.
Gardez à l'esprit que cegedim.cloud fournit des clusters Kubernetes standard avec ces fonctionnalités et a qualifié les documentations officielles de Kubernetes ci-dessous :
Le problème se situe au niveau de l'application dans la vie réelle :
toutes les technologies ne sont pas nativement compatibles avec les conteneurs
les mesures d'utilisation des ressources collectées par le kubelet (ou l'exportateur de nœuds, etc.) ne sont pas en temps réel
les mesures d'utilisation des ressources ne sont pas prises en compte par le planificateur kube
kubelet, en tant que processus Linux, n'est pas toujours le processus le plus prioritaire, en particulier lorsque les nœuds n'ont plus de CPU.
L'incapacité à gérer les contraintes de ressources sur les nœuds par kubelet conduit à des défaillances de nœuds et au redéploiement de toutes les charges de travail correspondantes. Dans le pire des cas, un effet domino sur la défaillance des nœuds peut se produire.
cegedim.cloud fournit une solution de hardening appelée cgdm-hardening :
Un esclave de hardening de pods par nœuds de travail : écrit la consommation de CPU et de RAM dans une base de données centralisée.
Un pod de hardening-maître déployé sur les nœuds maîtres : il lit les métriques dans la base de données et prend des mesures en cas de crise.
L'empreinte de la pile de hardening sur les ressources est très faible
Le pod Hardening-master
peut agir selon deux modes :
Mode préventif (en tant qu'assistant du planificateur kube, mode par défaut) :
Place le taint cegedim.io/overload=true:NoSchedule pour éviter de placer plus de pods sur des nœuds sous pression (85% RAM ou 90% CPU). Lorsque le CPU est inférieur à 85% et que la RAM est inférieure à 80%, l'altération est supprimée.
Mode de protection (en tant qu'assistant du contrôleur de kube) :
Lorsque la consommation de RAM atteint 95 %, il tue les pods les plus récents, l'un après l'autre, pour soulager la pression. Il n'est pas activé par défaut.
Vous ne devez jamais utiliser la wildcard tolérance dans les applications, sinon l'effet préventif de cette solution ne sera pas valable.
Limitation : cette solution ne permet pas de protéger les nœuds qui tombent en panne en raison d'un pic d'utilisation extrêmement élevé du CPU pendant une période de temps très courte.
Le nouveau cluster Kubernetes sera provisionné avec le hardeing préventif activé.
Si les charges de travail déployées par les clients entraînent un grand nombre de défaillances de nœuds (TLS_K8_NODES), le mode de protection sera activé.
Le client peut désactiver ce hardening en créant un ticket requête dans ITCare.
Par conséquent, la vérification TLS_K8_NODES de centreon au niveau du cluster et la vérification de l'état de santé de centreon sur les nœuds de travail seront désactivées.
Cela signifie que les clients doivent redémarrer eux-mêmes les nœuds en cas de crise.
Le client peut réactiver ce hardening en faisant un ticket requête ITCare à tout moment.
cegedim.cloud propose désormais une plateforme de stockage Ceph multi-locataires en tant que fournisseur de CSI avec les spécifications suivantes :
Les données sont répliquées 4 fois et réparties uniformément (à l'aide de Ceph Crush Map) sur 2 centres de données afin de garantir que, dans les scénarios de catastrophe, 2 répliques de données sont toujours disponibles.
Chaque cluster Kubernetes, en tant que client Ceph, dispose de son propre pool de données sur le serveur Ceph et consomme des services avec ses propres identifiants.
Seul le RBD Ceph CSI est fourni pour le moment.
Ceph Cluster
17.2.5
CSI Ceph
3.9.0
cgdm-rwo
Utiliser CSI Ceph rbd pour provisioner des volumes persistants ReadWriteOnce
Réplication
x4
x4
Tolérance de panne : Une AZ indisponible
Tolérance de panne : Un DC indisponible
Approvisionnement de nouveaux PV
Remonter le PV existant
Compatible avec toutes les applications K8S
Montage multiple (RWX)
Redimensionnable
Aperçu
Tolérance de panne : perte de 1 AZ
Tolérance de panne : perte de 1 DC
Compatible avec K8S 1.22+
Compatible avec K8S 1.22-
cegedim.cloud utilise External Snapshotter pour prendre des clichés et restaurer le PVC de vos clusters Kubernetes.
Toutes les informations relatives à cette application sont disponibles à l'adresse suivante :
Il est recommandé de nommer la classe d'instantanés d'après la classe de stockage. Il suffit d'exécuter la commande ci-dessous pour vérifier :
Pour répertorier tous les CSI disponibles dans un cluster Kubernetes, procédez comme suit :
Voici une correspondance entre la classe de stockage et le CSI :
cgdm-rwo
Ceph RBD
Managed MariaDB
MariaDB est un système de gestion de base de données open-source créé par les développeurs de MySQL. MariaDB utilise des tables pour stocker les données de manière organisée et il est possible d'interagir avec la base de données à l'aide de requêtes SQL.
Il prend en charge des concepts tels que les clés primaires, les index et les relations entre les tables. MariaDB est largement utilisé pour le stockage et la gestion des données dans diverses applications, des sites web aux systèmes d'entreprise. C'est un choix populaire en raison de sa fiabilité, de ses performances et de sa nature open-source.
MariaDB est déployé on-premise dans les centres de données de cegedim.cloud.
La version support à long terme (LTS) peut être déployée en self-service à l'aide d'ITCare.
Le même niveau de service que l'offre Compute est garanti : déploiement d'instances, maintien en condition opérationnelle, flexibilité, sécurité et monitoring sont ainsi assurés par nos experts.
Deux topologies sont disponibles en libre-service :
Instance autonome
Cluster Galera (3 nœuds)
Le cluster Galera est prêt pour la production avec au moins 3 nœuds répartis sur toutes les zones de disponibilité d'une Région cible.
Le dimensionnement peut être configuré selon vos besoins.
La facturation est mensuelle et basée sur le nombre d'instance plus des coûts supplémentaires pour le stockage, la sauvegarde, la surveillance 24/7.
L'estimation du coût d'une instance MariaDB est disponible via votre Service Delivery Manager.
OpenSearch managé
OpenSearch est une suite de recherche et d'analyse open source pilotée par la communauté et dérivée d'Elasticsearch 7.10.2 & Kibana 7.10.2 sous licence Apache 2.0.
Il se compose d'un démon de moteur de recherche, OpenSearch, et d'une interface de visualisation et d'utilisation, OpenSearch Dashboards. Il permet d'ingérer, de sécuriser, de rechercher, d'agréger, de visualiser et d'analyser facilement les données.
Ces capacités sont populaires pour des cas d'utilisation tels que la recherche d'applications, l'analyse des journaux, etc.
Les serveurs OpenSearch Cluster et la configuration des services sont gérés par cegedim.cloud. Le produit est disponible en libre-service dans ITCare.
Les utilisateurs ont un accès complet à la base de données et aux tableaux de bord d'OpenSearch. Il est de la responsabilité des utilisateurs de gérer la sécurité des index et de leur cycle de vie.
OpenSearch est déployé en tant que cluster sur site dans nos centres de données.
Le même niveau de service que l'offre Compute est garanti : déploiement d'instances, maintien en condition opérationnelle, flexibilité, sécurité et monitoring sont ainsi assurés par nos experts.
Le dimensionnement peut être configuré en fonction de vos besoins.
Le nombre minimum de nœuds pour un cluster est de 3 serveurs mais n'est pas recommandé pour la production. Il est conseillé de déployer au moins 5 nœuds ou plus pour une utilisation en production.
La facturation est mensuelle et basée sur le nombre de nœuds, plus des coûts supplémentaires pour le stockage, la sauvegarde et la surveillance 24/7.
L'estimation du coût d'un cluster OpenSearch est disponible auprès de votre Responsable de compte Technique.
L'édition communautaire de MariaDB est disponible en libre-service en deux topologies :
Un cluster Galera s'appuyant sur 3 instances actives/actives
Pour plus d'informations sur l'architecture de MariaDB :
Les instances MariaDB sont accessibles sur le port 3306 par défaut.
MariaDB est disponible dans les centres de données cegedim.cloud suivants :
EB4 (Boulogne-Billancourt, France)
ET1 (Labège, France)
Dans certains cas, lorsqu'un troisième nœud est déployé (cluster Galera), des centres de données secondaires proches peuvent également être utilisés pour assurer une résilience maximale :
EB5 (Magny-les-Hameaux, France)
ET2 (Balma, France)
La plateforme en tant que service de MariaDB est hébergée sur la distribution Linux Debian 10.
La taille minimale requise est de 2 CPU et 4GB de RAM.
Le stockage peut être configuré pendant le provisionnement et augmenté par la suite sur demande.
Il s'agit d'une instance simple déployée dans un seul centre de données.
Deux instances MariaDB sont déployées dans le même centre de données : le nœud principal avec une réplique en lecture seule.
Déployé uniquement sur requête !
Un cluster MariaDB Galera est un cluster multi-primaire virtuellement synchrone pour MariaDB.
Un cluster basé sur 3 instances actives/actives est déployable dans n'importe quel centre de données de cegedim.cloud.
La version prise en charge est la dernière LTS (long term support) actuellement disponible.
Pour plus d'informations, veuillez consulter les versions de MariaDB.
Cette section énumère les fonctionnalités disponibles pour le client, ainsi que la manière de les demander ou de les exécuter :
Quelques paramètres MariaDB par défaut configurés par cegedim.cloud :
La politique de sauvegarde pour MariaDB est configurée comme suit :
Sauvegarde complète chaque week-end (en ligne)
Sauvegarde différentielle tous les jours (en ligne)
Sauvegarde de Binlog toutes les deux heures
La rétention de sauvegarde par défaut pour les sauvegardes complètes et les sauvegardes dépendantes est de deux semaines.
L'authentification de MariaDB est basée sur l'utilisateur interne.
Un utilisateur d'administration est fourni au client lorsque le provisionnement est terminé.
Le mot de passe de cet utilisateur n'est pas stocké ni sauvegardé par cegedim.cloud. Veillez à l'enregistrer dans votre propre coffre-fort.
Dans le cadre de notre offre de bases de données gérées, MariaDB fait l'objet d'une surveillance spécifique en plus du système sous-jacent afin de garantir la disponibilité et les performances du service.
Les indicateurs clés suivants de MariaDB sont surveillés et suivis :
Nombre de connexions client interrompues
Nombre de tentatives de connexion au serveur ayant échoué
Nombre de connexions refusées en raison d'erreurs internes du serveur
Nombre maximal de connexions simultanées ouvertes
Ce guide présente l'ensemble des éléments de configuration nécessaires pour améliorer la disponibilité et la continuité de service de vos applications déployées dans un cluster Kubernetes managés par cegedim.cloud.
Il s'agit d'un guide indispensable pour que votre stratégie de reprise après sinistre réponde aux exigences de cegedim.cloud.
Une fois votre cluster Kubernetes configuré pour fonctionner selon la topologie de haute disponibilité (HA), certaines bonnes pratiques de configuration sont nécessaires pour permettre à vos applications :
pour fonctionner de façon simultanée sur tous les centres de données de la région.
de disposer d'une capacité suffisante dans tous les centres de données en cas de catastrophe sur l'un d'entre eux
Pour rappel, les nœuds des clusters Kubernetes sont répartis dans 3 zones de disponibilité (AZ) et 2 centres de données :
AZ "A" et "B" fonctionnent sur le centre de données primaire.
AZ "C" fonctionne sur le centre de données secondaire.
Pour les services sans état qui prennent en charge la mise à l'échelle, la meilleure pratique consiste à faire fonctionner au moins trois pods :
Ces 3 pods doivent être correctement configurés pour qu'au moins un pod fonctionne sur chaque zone de disponibilité :
Nous utilisons preferedDuringSchedulingIgnoredDuringExecution
et non requiredDuringSchedulingIgnoredDuringExecution
car nous voulons que cette exigence soit "souple" : Kubernetes permettra alors de programmer plusieurs pods sur la même AZ si vous exécutez plus de répliques que d'AZ, ou en cas de défaillance d'une zone.
Si vous utilisez la topologie de cluster haute disponibilité, votre objectif est de déployer des applications résilientes en cas de panne du centre de données.
Cette page décrit quelques bonnes pratiques pour déterminer le dimensionnement des nœuds de travail pour chaque zone de disponibilité où vos charges de travail sont exécutées.
Pour rappel, Kubernetes Cluster est déployé dans 3 zones de disponibilité, et 2 centres de données. Dans le pire des cas, une seul zone de disponibilité fonctionnera si le centre de données primaire subit un sinistre majeur.
C'est l'hypothèse à prendre en compte pour déterminer le dimensionnement "nominal", que l'on peut appeler "Si le centre de données primaire tombe en panne, de quelle capacité de CPU / RAM ai-je besoin pour continuer à faire fonctionner mon application ?".
Pour déterminer cette capacité, puis les nœuds de travail déployés dans la zone de disponibilité "C" (combien, et avec quelles ressources), vous aurez besoin de 3 paramètres :
Vous avez alors deux possibilités pour calculer la taille :
Au niveau de la granularité "Cluster Level": si vous débutez le processus et que vos charges de travail ne sont pas aussi complexes ou variables, utilisez cette option :
Déterminer un MBCO global pour les déploiements croisés
Additionner toutes les demandes de ressources des pods pour obtenir un numéro unique.
Additionner toutes les ressources utilisées par les pods pour obtenir un nombre unique.
Au niveau de la granularité "Pod Level" : Si vous voulez que le dimensionnement soit parfaitement adapté et que vous en avez le temps, prenez le temps de déterminer ces paramètres pour chaque déploiement de votre cluster Kubernetes, car le MBCO peut varier ! Par exemple :
Une application web nécessitera un MBCO avec 100 %.
Un cache nécessitera un MBCO de 50%.
Une fonctionnalité "agréable à avoir" ou un outil interne peut être à 0 %.
Le calcul au "niveau de cluster" n'est pas assez précis pour être absolument certain que le cluster sera d'une taille appropriée. Il suffit de le savoir et d'évaluer si cela vaut la peine de prendre le risque.
Dans tous les cas, ce dimensionnement doit être réévalué régulièrement, en fonction des nouveaux déploiements ou des redimensionnements que vous effectuez dans vos opérations quotidiennes.
Si vous avez additionné toutes les demandes et l'utilisation, et que vous avez déterminé le MBCO au niveau du "cluster", vous pouvez utiliser cette formule simple pour calculer le dimensionnement requis pour l'AZ "C" dans le centre de données secondaire :
Si vous avez déterminé un MBCO par déploiement, vous devrez calculer votre dimensionnement avec une formule plus complexe :
Une fois que vous avez calculé votre MBCO, il est important de tirer parti des capacités de Kubernetes (QoS, notamment PodDisruptionBudget
) pour que votre déploiement suive votre décision.
Utilisez ITCare ou demandez l'aide de notre support pour dimensionner votre cluster.
Au cours de cette phase, vous devrez hiérarchiser vos actifs et définir les composants qui sont essentiels à la disponibilité de vos services.
connaître l'utilisation de vos ressources, une fois le déploiement effectué, il est bon d'observer la consommation de ressources de votre charge de travail.
Dans Kubernetes il y a 3 classes de QoS :
Garantie
Burstable
BestEffort
Pour les charges de travail critiques, vous pouvez utiliser la QOS "garantie", qui définit simplement les limites de ressources égales aux demandes de ressources :
Pour les charges de travail moins critiques, vous pouvez utiliser le QOS "Burstable", qui définira les limites de ressources et les demandes.
Le budget de perturbation des pods vous permettra de configurer votre tolérance aux pannes et le nombre de pannes que votre application peut supporter avant d'être indisponible.
Avec une charge de travail sans état, l'objectif est d'avoir un nombre minimum de pods disponibles à tout moment, pour ce faire vous pouvez définir un simple budget de perturbation des pods :
Avec une charge de travail à état, le but est d'avoir un nombre maximum de pods indisponibles à tout moment, afin de maintenir le quorum par exemple :
Scénarios de trafic élevé :
Rancher supporte la même authentification SSO que ITCare.
Selon la localisation de votre cluster, Rancher est accessible avec les URL suivantes :
Dans ITCare, vous pouvez trouver l'URL de votre cluster dans la page de détail de celui-ci :
Rancher demandera une authentification lors de la première connexion : cliquez simplement sur "Login with Keycloak".
Vous serez ensuite redirigé vers la mire de connexion :
Une fois connecté, vous devriez avoir un écran listant tous les clusters auxquels vous avez accès :
Si l'interface se coince après l'authentification, merci d'essayer ces liens :
Si lors de la première connexion vous ne voyez pas votre cluster dans la liste des clusters, vous pouvez vous déconnecter et vous reconnecter.
Vous pouvez gérer vos préférences d'interface utilisateur (thème sombre, nombre de lignes par tableau...) en configurant vos préférences utilisateur. Veuillez vous référer ici à la documentation complète ci-dessous.
Afin de se connecter au cluster en utilisant la CLI, vous avez deux options :
par kubectl
normal à distance
en utilisant rancher online kubectl
.
Les deux sont disponibles en accédant à la page "cluster" dans Rancher.
Il y a deux façons de le faire :
Cliquez sur le nom du cluster dans la liste des clusters.
Cliquez sur le nom du cluster dans le menu supérieur gauche.
Une fois sur la page d'accueil du cluster, vous pouvez télécharger le "KubeConfig File" :
Ou bien juste copier le contenu du "Kubeconfig File" :
Cette configuration peut être mélangée avec d'autres configurations kubectl.
L'authentification peut être partagée avec tout cluster géré par la même instance de rancher.
Une fois sur la page d'accueil du cluster, vous pouvez utiliser le web CLI en cliquant sur l'icône ci-dessous:
Cela devrait lancer un shell web comme celui-ci :
La gestion des jetons est disponible juste en dessous de l'avatar de l'utilisateur :
Il existe deux champs d'application :
no-scope : global scope : utilisé pour interagir avec l'API globale de Rancher
cluster-scoped : jeton dédié à l'accès à un cluster spécifique
Les jetons peuvent avoir des cycles de vie différents :
Une durée de vie illimitée, il suivra le cycle de vie du compte qui lui est rattaché
Une durée limitée
Vous pouvez utiliser ITCare pour ajouter ou supprimer des nœuds à votre cluster.
Rancher gère les espaces de noms via project, qui est un concept n'existant spécifiquement que dans les clusters Kubernetes gérés par Rancher.
Le projet n'est pas une ressource native de Kubernetes. Par défaut, un cluster Kubernetes est provisionné avec 2 projets :
System : contenant les espaces de noms des composants principaux comme : kube-system, etc.
Default : contenant l'espace de noms "par défaut".
Les utilisateurs sont libres de créer d'autres projets si nécessaire. En se basant sur le niveau du projet, Rancher offre une automatisation intégrée comme : l'octroi de droits d'accès, l'isolation du réseau, etc.
Les utilisateurs sont fortement encouragés à classer les espaces de noms dans un projet.
Passer à la vue projet
Créer un nouvel espace de noms à partir de la vue du projet
Insérez un nom unique et remplissez les autres champs si nécessaire, puis cliquez sur "Créer"
cegedim.cloud recommande et supporte officiellement la gestion des droits d'accès via les groupes AD.
Seuls les groupes AD commençant par G_EMEA_* et G_K8_* sont connus par Rancher.
Par défaut, lors de la création d'un cluster :
Le rôle d'utilisateur standard est donné au groupe G_K8_<NOM_DU_CLUSTER>_USERS qui contient les power users du Cloud associé.
Le rôle d'administrateur est attribué au groupe G_K8_<NOM_DU_CLUSTER>_ADMINS qui est vide par défaut et peut être complété par des utilisateurs compétents et certifiés via un ticket ITCare vers l'équipe de support AD.
Par exemple, l’utilisateur user1@cegedim.com a besoin d’accès standard au cluster test-preprod, il doit faire une demande pour l'ajouter dans le groupe AD nommé G_K8_TEST_PREPROD_USERS.
Lorsque les utilisateurs créent un nouveau projet, en tant que propriétaire par défaut, ils sont libres de lier n'importe quel rôle à n'importe quel groupe AD dans le cadre de ce projet.
Si les rôles prédéfinis de Rancher ne peuvent pas répondre à vos besoins, veuillez contacter les administrateurs de votre cluster pour configurer un rolebinding personnalisé ou un clusterrolebinding.
Dans cette partie, nous supposerons que les droits sont donnés à un groupe et non à un utilisateur.
Pour gérer les droits sur un projet, il existe deux moyens : L'interface utilisateur ou l'API.
L'un des rôles les plus élevés que vous pouvez attribuer est "Project Admin".
Utilisation de l'interface utilisateur
Éditez le projet dont vous êtes propriétaire ou sur lequel vous avez suffisamment de droits accordé par le propriétaire.
Sélectionnez le groupe et le rôle dans la formulaire.
Utilisation de l'API
En utilisant l'API, c'est assez simple. Vous aurez d'abord besoin de quelques paramètres :
Obtenir l'ID du projet
Pour obtenir l'ID du projet, vous pouvez utiliser l'explorateur d'API en utilisant simplement le bouton "View in API".
Obtenir l'ID du rôle
Pour obtenir l'ID du rôle, il se peut que vous ne soyez pas autorisé à l'afficher via l'interface utilisateur, mais vous l'obtiendrez via cette requête API :
Donner des autorisations
En utilisant votre clé API, vous pouvez faire une demande POST pour créer le lien de rôle :
Les version api de ressources Kubernetes peuvent être obsolètes, voire supprimés lors de la mise à jour de version Kubernetes.
Il y a une risque de cassure si vous avez des ressources avec une version api supprimé dans la nouvelle version de Kubernetes.
Pour éviter cela, une des solutions est d'utiliser l'outil "kubent" pour vérifier la compatibilité .
Kubent détecte les objets obsolètes du cluster Kubernetes. Vous devez migrer/modifier les ressources identifiés avant la mise à jour de version Kubernetes.
Pour installer kubent :
Pour identifier les objets obsolètes qui vont être supprimés dans la prochain version Kubernetes :
Un exemple de l'output :
Dans ce tutoriel, si votre cluster est planifié pour une mise à jour vers version Kubernetes 1.22, vous devez migrer votre resource ingress nommé "toto" de version api networking.k8s.io/v1beta1
vers networking.k8s.io/v1
avant la mise à jour.
Cette migration peut impliquer une modification des champs supplémentaires de la ressource. Veillez consulter la documentation officielle :
Dans cet exemple, nous allons configurer le transfert de logs d'un cluster Kubernetes vers un cluster OpenSearch.
Le cluster OpenSearch est dans cet exemple my-cluster.es.cegedim.cloud
Le nom de la sortie du cluster est my-cluster-output
.
Dans Rancher, sous Logging > ClusterOutput et Logging > Output, modifiez la configuration YAML et changez ceci :
ClusterFlow/ClusterOutput présentent de nombreux problèmes lors de l'envoi de logs à OpenSearch / ELK cluster : Conflit de type de valeur attendue avec la même clé (par exemple, une valeur changée de "long" à "string" sera rejetée par OpenSearch / ELK Cluster).
Cela peut se produire isi vous avez activé Dynatrace.
Voici des exemples complets de la spécification ClusterOutput/Output pour ElasticSearch et OpenSearch :
Il y a deux options :
Migration vers Flow/ClusterOutput : poussera tous les logs des espaces de noms vers le même index OpenSearch.
Migration vers Flow/Output : poussera les logs des espaces de noms séparés vers des index OpenSearch dédiés.
La recommandation est de migrer vers "Flow/Output", et même d'avoir un index OpenSearch dédié pour les applications très importantes.
Créer un fichier avec tous les espaces de noms :
Créer des fichiers K8s YAML pour configurer les logs sur tous les espaces de noms :
Appliquer la configuration :
Créer un fichier avec tous les espaces de noms :
Créer des fichiers K8S YAML :
Appliquer la configuration :
Aucun tampon important ne devrait se produire si tout se passe bien. Vérifions le
Vérifions les 5 dernières lignes du journal de Fluentd :
Jetez un coup d'œil dans /fluentd/log/out
à l'intérieur du pod fluentd
, mais la plupart du temps, ce qui suit vous aidera :
Il est facile d'identifier le pod à l'origine du problème :
Il faut comprendre que l'erreur n'est pas dans Kubernetes, c'est le conteneur qui produit des logs incohérents au format json. Ensuite, OpenSearch rejette les journaux envoyés. Banzai réessayera et tôt ou tard, le débordement arrivera.
Sources :
Une solution à court terme peut être choisie ci-dessous :
Retirer le pod du flux (exclusion du pod) ou désactiver l'ensemble du flux de l'espace de noms concerné.
Nettoyer l'index lié dans le serveur ES
Solution à long terme :
Adapter l'application pour produire un journal plus cohérent
Voir s'il est possible de configurer ES pour qu'il ignore gentiment, mais ne rejette pas, le paquet entier envoyé par Banzai.
Les recommandations des ont été suivies afin de renforcer et sécuriser nos systèmes d'exploitation Linux.
Option
Option
Option
De plus amples informations sur le Ceph CSI sont disponibles via le lien ci-dessous
Pour plus d'information, veuillez consulter la page .
Pour plus d'information, veuillez consulter la page .
Une instance autonome (avec une réplique sur demande)
vous pouvez accéder à vos métriques via l'interface utilisateur de rancher ou via un client comme .
cegedim.cloud utilise comme plateforme de gestion de .
Kubent pourrait échouer de reporter certaine information, e.g. espace de nom de l'ingress, vous pouvez remonter l'issue à l'éditeur :
Libre service
Le client peut effectuer des actions de manière autonome sur ses propres bases de données.
Sur demande
Le client peut demander à l'équipe de support de cegedim.cloud de prendre les mesures nécessaires.
Accès SSH
L'accès SSH n'est pas autorisé.
Modifier le fichier de configuration de MariaDB
Sur demande via un ticket. Revue par l'équipe de cegedim.cloud.
Jeu de caractères
utf
Jeu de caractères par défaut de la base de données
transaction_isolation
READ-COMMITTED
Type de transaction
max_connexions
1000
Nombre maximum de connexions autorisées à l'instance
innodb_buffer_pool_size
50% de la RAM
Mémoire tampon Innodb allouée à l'instance
requêtes lentes
désactivé
Les requêtes lentes ne sont pas enregistrées par défaut
Le cluster OpenSearch est disponible en tant que :
Cluster de 3 nœuds - non recommandé pour une utilisation en production
Cluster de 5 nœuds ou plus - recommandé pour une utilisation en production
Dans la topologie à 3 serveurs, tous les serveurs jouent le rôle de maître, deux d'entre eux sont également utilisés comme nœuds de données. Chaque index est répliqué par défaut sur ces deux nœuds de données.
Avec 5 serveurs ou plus, trois nœuds sont utilisés comme nœuds maîtres et n'hébergent pas de données. En fonction de la zone, les nœuds maîtres sont répartis sur 2 ou 3 zones de disponibilité. Les nœuds restants n'hébergent que des données et sont répartis sur deux zones de disponibilité.
Dans une Area avec 3 zones de disponibilité, le cluster est résilient face à une défaillance d'une zone de disponibilité.
Dans une Area avec 2 zones de disponibilité, le cluster peut tomber en panne si la zone de disponibilité contenant deux maîtres n'est pas disponible.
Cette section énumère les fonctionnalités / capacités disponibles pour les utilisateurs, ainsi que la manière de les demander / de les exécuter :
Libre-service
Le client peut effectuer des actions de manière autonome à l'aide d'ITCare.
Sur requête
Le client peut demander à l'équipe de support de cegedim.cloud de prendre les mesures nécessaires.
Accès SSH
L'accès SSH est désactivé et réservé aux administrateurs de cegedim.cloud
Changement de configuration
Sur requête via ticket
L'authentification utilise le système de sécurité interne d'OpenSearch. Il peut être configuré sur demande pour accepter Active Directory comme backend d'authentification.
Les autorisations sont effectuées à l'aide de RBAC. Il peut être configuré sur demande pour accepter Active Directory comme fournisseur de rôles.
TLS/SSL est activé par défaut pour les flux réseau entrants et internes.
Cette section explique comment est gérée la gestion des mots de passe :
Compte admin
Autre compte
Compte kibana
Utilisé par le serveur de tableau de bord pour se connecter au cluster
Compte support
Utilisé par l'équipe de support de cegedim.cloud (il a un accès limité et ne peut pas lire les données d'index)
Compte centreon
Utilisé par le système de surveillance cegedim.cloud (il n'a accès qu'aux informations de surveillance)
Compte prometheus
Utilisé par le système de métrologie de cegedim.cloud (il n'a accès qu'aux informations de surveillance)
Instances
1
3
CPU (par instance)
2 - 16 vCPU
2 - 16 vCPU
RAM (par instance)
4 - 384 Go
4 - 384 Go
Version(s) supportée(s)
10.6
10.6
Surveillance
Surveillance 24x7
Sauvegarde
Réplication de données (PRA)
Disponibilité
99,8%
99,9%
Déploiement multi-AZ
Libre-service
Instances
3
5 (recommandé)
CPU (par instance)
2 - 16 vCPU
RAM (par instance)
4 - 384 Go
Version(s) supportée(s)
2.11.0
2.15.0
Surveillance
Surveillance 24x7
Sauvegarde
Réplication de données (PRA)
Disponibilité
99,9%
Déploiement multi-AZ
Libre-service
Minimum Business Continuity Objective (MBCO)
Comme le RTO / RPO, le MBCO est un paramètre majeur pour dimensionner votre DRP.
En résumé, il s'agit du pourcentage de capacité de votre application déployée qui est nécessaire pour que votre entreprise soit opérationnelle.
Selon la taille de vos charges de travail lorsque vous les exécutez dans 3 AZ, la performance que vous jugez suffisante peut être de 30%, 50% ou 100%.
Par exemple, si vous avez une application avec 3 répliques de 4GB RAM sur chaque AZ, vous pouvez déterminer le MBCO de manière très différente :
33%
il suffit qu'un seul fonctionne pendant la panne, car les performances seront correctes.
vous pouvez prendre le risque de ne pas avoir de redondance pendant la période de panne
66%
soit, 2 pods minimum sont nécessaires pour avoir une performance OK
et/ou vous ne voulez pas prendre le risque d'échouer si le seul pod restant échoue.
100%
vous avez absolument besoin de 3 pods minimum pour faire fonctionner le service avec des performances nominales
Le choix vous appartient !
Pods Ressources Demandes
Comme Kubernetes essaiera de replanifier vos pods en cas de panne, les requêtes sont un paramètre absolument majeur à gérer.
Si l'AZ-C n'a pas assez de ressources pour satisfaire toutes les exigences des déploiements de pods souhaités, Kubernetes ne les déploiera pas, et peut-être que vos applications ne seront pas disponibles !
Pour connaître vos demandes, vous pouvez exécuter cette commande :
kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{"-"}{range .spec.containers[*]}{"/"}{.name}{";"}{.resources.requests.cpu}{";"}{.resources.limits.cpu}{";"}{.resources.requests.memory}{";"}{.resources.limits.memory}{"\n"}{end}{"\n"}{end}'
| grep
-v
-e '^$'
Utilisation des ressources
Déterminer les demandes, c'est bien pour être sûr que Kubernetes déploiera autant de pods que vous le souhaitez, mais qu'en est-il de la capacité réelle utilisée par vos pods ? Il faut également en tenir compte pour avoir une idée des ressources "brutes" dont vos applications ont besoin.
Pour le déterminer, vous pouvez exécuter cette commande pour connaître l'utilisation actuelle de votre pod :
kubectl top pod
EB (Boulogne-Billancourt)
ET (Toulouse-Labège)
Pour commencer, rendez-vous sur ITCare et recherchez votre service global cible où vous créerez votre nouveau PostgreSQL.
Recherchez votre service Global dans la barre de recherche supérieure et cliquez dessus pour afficher sa page d'information.
Une fois dans votre Service Global, cliquez sur le bouton Créer une ressource et sélectionnez PostgreSQL.
Aller sur Bases de données managées, choisir PostgreSQL et sélectionner la version requise.
Remplir le formulaire et cliquer sur Suivant. Définir les personnalisations et cliquer sur Suivant.
Valider la synthèse et soumettre le formulaire.
Une fois le déploiement prêt, vous en serez informé par e-mail.
Sur la page de ressources de votre PostgreSQL, vous pouvez effectuer toutes les actions disponibles en utilisant le bouton Gérer dans le coin supérieur droit. Cela inclut le démarrage, l'arrêt, la suppression, le redémarrage, le redimensionnement et bien plus encore.
Lorsque votre cluster est créé avec ITCare, vous avez obtenu un rôle sql avec des informations d'identification.
Avec ces informations d'identification, vous pouvez vous connecter au cluster avec son nom sur le port tcp 5432. Vous pouvez utiliser la base de données postgres pour vous connecter.
Si votre cluster s'appelle "mycluster" vous pouvez utiliser le code python suivant :
Lorsque votre cluster est créé avec ITCare, vous avez obtenu un rôle sql avec des informations d'identification.
Si vous choisissez d'activer TLS, vous avez reçu le certificat racine auquel vous devez faire confiance et que vous devez donner à la bibliothèque que vous utilisée pour vous connecter, par exemple psycopg2.
Avec ces informations d'identification, vous pouvez vous connecter au cluster avec son nom sur le port tcp 5432. Vous pouvez utiliser la base de données postgres pour vous connecter.
Si votre cluster s'appelle "mycluster" vous pouvez utiliser le code python suivant :
Il est plus sûr de ne pas utiliser un rôle d'administrateur pour les applications.
Une fois connecté, vous pouvez créer un rôle standard comme suit (remplacez <a_role>
et <very_strong_password>
par vos propres informations d'identification) :
Si vous voulez créer une base de données dont le propriétaire sera le rôle que vous venez de créer, utilisez les requêtes SQL suivantes :
Vous pouvez utiliser les requêtes SQL suivantes avec la base de données template0 comme base de données template :
Le PaaS PostgreSQL dispose d'une fonctionnalité permettant de restaurer un PaaS PostgreSQL (source) vers un autre PaaS PostgreSQL (destination) à un moment donné (en utilisant le Point-In-Time Recovery) sous les contraintes suivantes :
l'utilisateur doit avoir accès au cloud de la ferme source et de la ferme de destination
la source doit être sauvegardée (option choisie lors de la création)
la source et la destination doivent être actives
la source et la destination doivent être différentes
la source et la destination doivent être dans la même version de PostgreSQL
la source et la destination doivent être en version 12 ou supérieure
l'heure cible ne doit pas être dans le futur (délimitée à droite par l'heure actuelle).
l'heure cible ne doit pas être inférieure à 7 jours (pour les services de non-production) ou à 14 jours (pour les services de production) avec pour référence l'heure actuelle (délimitée à gauche par la rétention des sauvegardes).
Vous pouvez choisir d'inclure ou d'exclure la cible temporelle dans le processus de restauration.
Le processus de restauration d'une base de données PostgreSQL est une étape importante. Voyons comment procéder ci-dessous :
OpenSearch amène plusieurs changements, vous devez donc vérifier la compatibilité de votre application avec ceux-ci.
Il s'agit du principal changement induisant une rupture et il n'est pas spécifique à OpenSearch car il était déjà prévu par ElasticSearch avant le fork.
Vous devez donc vous assurer que vos applications n'utilisent plus les paramètres "type".
Voici quelques solutions concernant les produits souvent utilisés avec les solutions élastiques et comment les configurer pour qu'ils fonctionnent avec OpenSearch 2.x
Si le client est Fluentbit, la solution la plus simple est de définir le paramètre Suppress_Type_Name sur On.
Il est également possible de changer le plugin de sortie pour le plugin natif d'OpenSearch qui fait partie de Fluentbit depuis la version 1.9.
L'article suivant peut s'avérer utile pour débuter avec Fluentbit et OpenSearch :
Si le client est Fluentd, c'est plus délicat. Il existe également unsuppress_type_name mais le plugin n'utilise ce paramètre que s'il détecte une version d'Elastic >= 7.
Nous devons donc ajouter d'autres paramètres :
verify_es_version_at_startup = false - pour ne pas laisser le plugin détecter la version
default_elasticsearch_version = '7'
Voici par exemple les changements à effectuer sur les spécifications du plugin de sortie que nous utilisons dans Kubernetes.
Il y a aussi un plugin de sortie pour OpenSearch.
Le plugin OpenSearch n'est pas encore disponible dans le système de journalisation de Rancher.
PostgreSQL est actuellement le principal SGBDR (système de gestion de base de données relationnelle) open source, avec une large gamme de fonctionnalités et une grande communauté qui le soutient.
cegedim.cloud fournit des instances de bases de données PostgreSQL entièrement gérées pour vous permettre de construire vos applications sans vous soucier de la disponibilité, la sécurité et la résilience des bases de données PostgreSQL.
PostgreSQL est déployé sur site dans les centres de données de cegedim.cloud.
cegedim.cloud garantit le même niveau de service que l'offre Compute & Database : déploiement des instances, maintien en condition opérationnelle, flexibilité, sécurité et monitoring sont ainsi assurés par nos experts.
Deux types de déploiements PostgreSQL sont disponibles :
Le mode Instance autonome fournit une instance PostgreSQL standard.
Le mode Haute disponibilité fournit un déploiement PostgreSQL multi-instances avec des capacités de résilience et d'évolutivité améliorées.
Le dimensionnement peut être configuré en fonction de vos besoins.
Instance
1
2
CPU (par instance)
2 - 16 vCPU
2 - 16 vCPU
RAM (par instance)
4 - 384 Go
4 - 384 Go
Versions supportées
10, 11, 12, 13, 14, 15, 16
12, 13, 14, 15, 16
Surveillance
Surveillance 24x7
Sauvegarde
Réplication de données (PRA)
Disponibilité
99,8%
99,9%
Déploiement multi-AZ
Libre-service
Pour plus d'information, veuillez consulter la page PostgreSQL - Architecture.
La facturation est mensuelle et basée sur le nombre de nœuds plus les coûts supplémentaires pour le stockage, la sauvegarde et le monitoring 24x7.
L'estimation du coût d'un nœud PostgreSQL est disponible via votre Service Delivery Manager.
Connectez-vous à la plateforme ITCare, recherchez le service global auquel attacher le cluster et cliquez dessus.
Cliquez sur le bouton Créer une ressource dans votre Service Global et sélectionnez OpenSearch. Donnez un nom unique au cluster et définissez un nom de préfixe qui sera utilisé pour nommer les machines virtuelles. Cliquez sur Suivant.
Sélectionnez le nombre de nœuds et la taille des nœuds. Cliquez sur Suivant.
Sélectionnez le volume de stockage. Cliquez sur Suivant.
Sélectionnez la région et la zone dans laquelle vous souhaitez installer votre cluster. Cliquez sur Suivant.
Sélectionnez le VLAN dans lequel vous souhaitez déployer votre cluster. Cliquez sur Suivant.
Activez ou désactivez les options supplémentaires :
Surveillance des machines virtuelles et des clusters
Surveillance 24/7
Sauvegarde
Réplication des machines virtuelles (récupération en cas de désastre)
Cliquez sur Suivant.
Sélectionnez la version et définissez un mot de passe administrateur qui sera utilisé pour gérer votre cluster.
Les mots de passe ne sont pas sauvegardés par cegedim.cloud.
Assurez-vous de sauvegarder votre mot de passe!
A l'étape finale, vous pouvez vérifier la synthèse de votre demande : vérifier les noms des machines virtuelles à créer, sauvegarder votre mot de passe administrateur, modifier les options de gestion.
Cliquez sur Soumettre.
Une fois que le cluster est prêt, vous serez notifié par email avec les informations requises pour se connecter au cluster.
Dans le panneau de contrôle gauche, cliquez sur le nom du cluster pour afficher la page de détails de celui-ci. En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Démarrer et confirmer.
Une notification par courriel sera envoyée lorsque le service sera activé.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Stop.
Saisissez un numéro RFC pour le suivi (facultatif). Cliquez sur Soumettre.
L'arrêt d'un cluster arrêtera toutes les machines virtuelles attachées au cluster et la surveillance sera désactivée.
Une notification par courrier électronique sera envoyée lorsque le cluster sera arrêté.
En haut de la page du cluster, cliquez sur le nom du cluster OpenSearch, puis sur Ajouter des nœuds.
Sélectionnez le nombre de nœuds que vous souhaitez ajouter (nombre pair) et sélectionnez la nouvelle taille (cpu/ram). Spécifiez la taille du disque de données.
Une notification par courrier électronique sera envoyée lorsque tous les nœuds auront été ajoutés.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Redimensionner les nœuds.
Sélectionnez les nœuds que vous souhaitez redimensionner et sélectionnez la nouvelle taille (cpu/ram).
Une notification par courriel sera envoyée lorsque tous les nœuds auront été redimensionnés.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Supprimer. Cette action arrêtera et supprimera toutes les machines virtuelles.
Veuillez noter que cette action n'est pas récupérable!
Saisissez un numéro RFC pour le suivi (facultatif), puis cliquez sur Soumettre.
Une notification par courriel sera envoyée lorsque le cluster sera supprimé.
La mise à niveau d'un cluster n'est pas encore implémentée dans ITCare.
Si vous souhaitez mettre à niveau votre cluster existant vers une version plus récente, vous devez envoyer une demande au support en indiquant la version souhaitée.
Pendant la mise à jour, le cluster OpenSearch continuera à fonctionner correctement car nous effectuons une mise à jour continue. Cependant, il se peut que vous constatiez une courte indisponibilité pendant la mise à jour des serveurs de tableaux de bord, qui est effectuée après la mise à jour du cluster OpenSearch.
La mise à jour de la topologie d'un cluster est proposée pour un cluster Opensearch initialement constitué de trois nœuds (topologie basique).
La mise à jour est implémentée dans ITCare via l'option "Gérer-Migrer vers un master dédié"
La migration permet d'ajouter deux nœuds Master, tout en spécialisant les (n-1) nœuds existants au rôle de Data. Le cluster sera ainsi composé de trois nœuds Master et du reste des nœuds dédiés au rôle de Data.
Pendant la mise à jour vers une topologie "Master dédié", le cluster continuera de fonctionner,bien qu'il puisse temporairement passer à un statut "Yellow".Cependant, certains objets du cluster, comme les tableaux de bord, peuvent être temporairement indisponibles. Tout reviendra à la normale une fois la migration terminée.
La fonctionnalité d'ajout de nœuds dédiés au rôle d'ingestion est disponible pour un cluster OpenSearch avec une topologie « master dédié » (cluster de cinq nœuds).
La mise en place de nœuds d'ingestion dédiés est implémentée dans ITCare via le menu déroulant "Gérer" puis l'action "Ajouter des noeuds d'ingestion"
Grâce à ces nœuds d'ingestion, il est possible d'isoler le processus d'ingestion des données, ce qui permet de limiter l'impact sur l'indexation ou la recherche, même en cas de volumes élevés de données entrantes. Cela améliore ainsi la stabilité et les performances globales du cluster.
L'architecture multi-niveau (Hot-Warm-Cold) dans OpenSearch permet d'optimiser les coûts, les performances et la scalabilité en fonction des besoins spécifiques de votre application. Cette architecture permet de stocker les données en fonction de leur fréquence d'accès, en répartissant les données fréquemment sollicitées au niveau des nœuds identifiés (Hot), les données moyennement sollicitées au niveau des nœuds identifiés (Warm) et les données non fréquemment recherchées au niveau des nœuds identifiés (Cold). En plus des différences d'attributs, le nombre de nœuds à chaque niveau peut également varier pour répondre aux besoins spécifiques des requêtes de recherche.
Pour répondre à ce besoin, nous proposons deux niveaux à l'architecture multi-niveaux (Hot-Cold). La configuration des attributs de nœud est disponible dans ITCare via l'action "Définir les attributs du nœud", accessible au niveau de chaque nœud.
Dans OpenSearch, chaque nœud est limité par défaut à 1000 shards pour maintenir les performances et la stabilité du cluster en gérant l’utilisation des ressources.
Dépasser cette limite, par exemple lors de la création de nouveaux index, entraînera une erreur.
Voici des solutions ci-dessous qui vous aideront à résoudre ce problème.
Ajouter des nœuds supplémentaires répartit les shards sur plus de ressources, réduisant la charge par nœud.
Chaque nœud supplémentaire apporte sa propre limite de 1000 shards, augmentant ainsi la capacité globale du cluster.
Ajustez le paramètre cluster.max_shards_per_node pour autoriser plus de shards par nœud si votre matériel le permet (CPU, mémoire et stockage suffisants).
Il est recommandé de ne pas dépasser 2000 shards par nœud pour éviter une surcharge.
Utilisez la commande suivante pour modifier le paramètre :
Lors de la création de nouveaux index, planifiez soigneusement le nombre de shards en fonction de la taille des données et de la croissance attendue.
Voici quelques bonnes pratiques:
Utilisez moins de shard, plus grands, pour les petites données.
Révisez régulièrement l'allocation des shards pour optimiser l’utilisation des ressources selon l'évolution du cluster.
Surveillez régulièrement l’utilisation des shards et des ressources pour des performances optimales.
Un dashboard Grafana pour OpenSearch est disponible sur ce sujet dans votre plateforme de monitoring avancée.
Assurez-vous que vos nœuds disposent de ressources suffisantes avant d’augmenter les limites de shards.
PostgreSQL est actuellement le principal SGBDR (système de gestion de base de données relationnelle) open source, avec une large gamme de fonctionnalités et une grande communauté qui le soutient.
cegedim.cloud fournit des instances de bases de données PostgreSQL entièrement gérées pour vous permettre de construire vos applications sans exploiter la disponibilité, la sécurité et la résilience des bases de données PostgreSQL.
Les versions de PostgreSQL actuellement supportées sont : 10, 11, 12, 13, 14, 15, 16.
Pour mettre à jour votre PaaS PostgreSQL, veuillez vous référer à cette page : PostgreSQL - Mise à jour
cegedim.cloud prend en charge deux types de déploiements PostgreSQL :
Le mode Single Instance fournit une instance PostgreSQL standard.
Le mode Haute disponibilité fournit une instance PostgreSQL multi-instances, avec des capacités de résilience et d'évolutivité améliorées
PostgreSQL est disponible à la fois sur le centre de données de cegedim.cloud :
EB4 (Boulogne-Billancourt, France)
ET1 (Labège, France)
Dans certains cas, lorsqu'un deuxième nœud est déployé (haute disponibilité), un centre de données secondaire proche peut également être utilisé pour assurer une résilience maximale :
EB5 (Magny-les-Hameaux, France)
ET2 (Balma, France)
Dans le cas d'une topologie à haute disponibilité, le PaaS est construit de manière à être résilient au DC si possible.
Ci-dessous, un exemple de répartition des nœuds :
Cette section énumère les fonctionnalités disponibles pour le client, ainsi que la manière de les demander ou de les exécuter :
Libre-service
Le client peut effectuer une action de manière autonome.
Sur requête
Le client peut demander que l'action soit effectuée auprès de l'équipe de support de cegedim.cloud.
Accès SSH
L'accès SSH est désactivé et réservé aux administrateurs de cegedim.cloud.
Modifier le fichier de configuration
Sur demande via un ticket. Seulement possible si cela n'affecte pas la surveillance et la résilience.
Installer une extension
Les extensions PostgreSQL autorisées sont installables en libre service par les utilisateurs depuis ITCare à partir de la version 15 et supérieure. Autrement, une demande via ticket requête est toujours requise.
Il est possible d'ajouter des fonctionnalités à PostgreSQL à travers ce qu'on appelle des extensions. Ces extensions peuvent ajouter de nouveaux types, des fonctions supplémentaires aussi bien pour les administrateurs que pour des utilisateurs "classiques", voire même des applications complètes.
Une fois que le PaaS PostgreSQL 15 et supérieur a été provisionné, vous pouvez installer certaines de ces extensions à travers ITCare.
Ci-dessous la liste des extensions supportées par le PaaS PostgreSQL à partir de la version 15:
Attention l'installation de certaines extensions peut nécessiter un redémarrage de PostgreSQL et donc entrainer une indisponibilité de votre PaaS PostgreSQL.
Le client se voit attribuer un rôle dont il choisit le mot de passe.
Le mot de passe de cet utilisateur n'est pas stocké ni sauvegardé par cegedim.cloud. Veillez à l'enregistrer dans votre propre coffre-fort.
Le rôle fourni au client dispose des autorisations suivantes :
LOGIN
CREATEROLE
CREATEDB
Ainsi, le client peut créer un rôle d'application et des bases de données dédiées.
Le transport sécurisé est une option lors du provisionnement et n'est disponible qu'à partir de la version 13.
Si le transport sécurisé est sélectionné, TLS/SSL sera activé pour le protocole PostgreSQL et seule une connexion TLS des clients sera acceptée.
Toutes les données sont stockées dans les centres de données cegedim.cloud sur des baies de stockage cryptées.
Cette section énumère la gestion des mots de passe :
compte client dédié
SCRAM-SHA-256
TOUT autre compte
SCRAM-SHA-256
compte cegedim.cloud
SCRAM-SHA-256
compte de surveillance
SCRAM-SHA-256
Si la sauvegarde est activée lors du provisionnement (activée par défaut pour un service de type Production), les politiques de sauvegarde suivantes s'appliquent :
Sauvegarde complète tous les jours conservée pendant 14 jours
Sauvegarde complète une fois par semaine.
Sauvegardes différentielles entre les deux.
Les journaux de type Write-ahead (WAL) sont archivés.
Point-in-Time recovery prise en charge pendant 14 jours.
Dans le cadre de notre offre de bases de données gérées, PostgreSQL fait l'objet d'une surveillance spécifique au-dessus du système sous-jacent afin de garantir la disponibilité et les performances du service.
Les indicateurs clés PostgreSQL suivants sont surveillés et suivis :
Connexions
Utilisation de la mémoire
Dépassement des IDs de transactions (TXID wraparround)
État de santé
Redis qui signifie Remote Dictionary Server, est un magasin de données clé-valeur rapide, open source, en mémoire.
Redis est déployé sur site dans les centres de données cegedim.cloud.
cegedim.cloud garantit le même niveau de service que l'offre Compute : déploiement des instances, maintien en condition opérationnelle, flexibilité, sécurité et monitoring sont ainsi assurés par nos experts.
Deux topologies sont disponibles :
Instance autonome
Cluster Sentinel de 3 instances
La topologie cluster Sentinel est prête pour la production avec 3 instances réparties sur toutes les Zones de Disponibilité d'une Area cible.
Chaque instance exécute les processus Redis et Sentinel. Une instance est primaire et les deux autres sont des répliques.
Le dimensionnement peut être configuré en fonction de vos besoins.
L'estimation des coûts pour un PaaS Redis est disponible via votre Service Delivery Manager.
La facturation est basée sur le nombre de nœuds auquel s'ajoutent les frais supplémentaires de stockage, de sauvegarde, surveillance 24/7.
Merci de préciser si celle-ci doit être réalisée en heures non ouvrées pour planification d'une RFC.
Il est recommandé de procéder à la mise à jour de vos environnements de non production d'abord afin de pouvoir estimer le temps d'interruption généré par l'opération ainsi que de recetter vos applications dans la nouvelle version du moteur.
La mise à jour d'un déploiement PostgreSQL (mono-instance ou haute disponibilité) se déroule en deux étapes complètement automatisées :
Mise à jour du système d'exploitation préalable
Plusieurs mises à jour selon le scénario : Debian 9 → Debian 10 → Debian 11 -> Debian 12
Mise à jour du moteur PostgreSQL dans la version cible
La durée d'une mise à jour est variable selon :
Les ressources cpu et ram configurées
La quantité de données dont les entêtes doivent être modifiés par le moteur PostgreSQL.
La quantité de données à réindexer suite au changement de librairie C, après une mise à jour de l'OS.
Le mode de sauvegarde :
Point-in-time Recovery (PITR) à partir de PostgreSQL 12 et supérieur.
Le mode de sauvegarde "dump" disparait donc au profit du "PITR" et ne reste utilisé que dans les versions de PostgreSQL inférieures à la version 12.
A titre indicatif, voici les durées pour chaque étape d'une mise à jour d'une base de données pgbench de 100 Go :
Mise à jour de Debian : 10 minutes en moyenne
Réindexation PostgreSQL : 5 minutes en moyenne
Mise à jour de PostgreSQL : 1 minute en moyenne
Checksum PostgreSQL : 3 minutes en moyenne
Vacuuming de PostgreSQL : 1 minute en moyenne
Sauvegarde complète de PostgreSQL (mode PITR) : 16 minutes en moyenne
En mode PostgreSQL HA, nous devons également mettre à jour le réplica et le synchroniser avec le leader :
Synchronisation PostgreSQL : 4 minutes en moyenne
Durée moyenne totale pour une base de données de 100GB : 40 minutes
Distribution Linux supportées par cegedim.cloud en fonction de la version de PostgreSQL :
La mise à jour du système d'exploitation, si elle a lieu, peut nécessiter une réindexation complète (aussi prise en charge par cegedim.cloud) du fait des évolutions de la librairie C lors de la mise à jour du système d'exploitation.
Selon la quantité de données, cette opération peut prendre un certains temps.
Ci-dessous les chemins de mises à jour supportés par cegedim.cloud :
* Une migration du système d'exploitation est requise.
** Une double migration du système d'exploitation est requise.
*** Une triple migration du système d'exploitation est requise.
La mise à jour d'un PaaS Redis est de la responsabilité de cegedim.cloud et peut être demandée via un ticket soumis depuis ITCare.
Merci de préciser un créneau de disponibilité pour l'opération et si l'opération doit être effectuée en heures non ouvrées.
Il est recommandé de procéder à la mise à jour de vos environnements de non production d'abord afin de pouvoir estimer le temps d'interruption généré par l'opération ainsi que de recetter vos applications dans la nouvelle version du moteur.
La mise à jour d'un déploiement Redis (mono-instance ou cluster en haute disponibilité) se déroule en deux étapes complètement automatisées :
Mise à jour du système d'exploitation préalable
Plusieurs mises à jour selon le scénario: Debian 10 → Debian 11 → Debian 12
Mise à jour du moteur Redis et Sentinel dans la version cible
La durée d'une mise à jour est variable selon:
La topologie
Topologie Standalone: Redis sera mise à jour.
Topologie Sentinel: Redis et Sentinel seront mis à jour sur chaque noeuds.
Le nombre de mise à jour du système d'exploitation nécessaire
Mise à jour du système d'exploitation Debian: 10 minutes en moyenne
Mise à jour des paquets Redis: 5 minutes en moyenne
Mise à jour des paquets Sentinel: 5 minutes en moyenne
Distribution Linux supportées par cegedim.cloud en fonction de la version de Redis:
Microsoft SQL Server est un système de gestion de base de données relationnelle développé par Microsoft.
Il est conçu pour stocker et récupérer des données telles que demandées par d’autres applications logicielles. Les fonctionnalités principales de SQL Server incluent :
Stockage et récupération de données : SQL Server offre une plateforme sécurisée et scalable pour stocker une grande quantité de données structurées et semi-structurées de manière efficace.
Interrogation et manipulation de données : Il propose des capacités avancées d’interrogation, telles que la possibilité d’écrire des requêtes complexes en utilisant le langage SQL, de joindre des tables, de créer des vues et de récupérer des données en fonction de critères spécifiques.
BI et analytique : SQL Server fournit des outils et des services pour l’analyse, le reporting et la visualisation des données, permettant aux utilisateurs de tirer des enseignements des données stockées afin de prendre des décisions basées sur les données.
Sécurité et intégrité des données : Il propose des fonctionnalités de sécurité solides, telles que l’authentification, le contrôle d’accès et le chiffrement, pour protéger les données sensibles contre tout accès ou modification non autorisé.
Haute disponibilité et évolutivité : SQL Server prend en charge des fonctionnalités comme le clustering, la bascule en cas de panne et la réplication pour assurer une disponibilité continue des données et pour répondre aux exigences croissantes en adaptant l’infrastructure de la base de données en termes de taille ou de performance.
SQL Server est déployé sur site dans les centres de données de cegedim.cloud .
Le même niveau de service que l'offre Compute est garanti : le déploiement des instances, la maintenance en condition opérationnelle, la flexibilité, la sécurité et la surveillance sont ainsi assurés par nos experts.
SQL Server 2016, 2017, 2019 et 2022 sont déployables en libre-service via notre plateforme de gestion de cloud ITCare.
Deux éditions sont supportées : Standard et Entreprise.
Deux topologies sont disponibles :
Instance autonome
Cluster Always On
La topologie de cluster Always On est prête pour la production mais n'est produite que sur demande. Seule la version SQL Server 2022 Enterprise est disponible en libre-service.
Le dimensionnement peut être configuré selon vos besoins.
La facturation est basée sur le nombre de nœuds, plus des coûts supplémentaires pour le stockage, la sauvegarde, surveillance 24/7.
Les coûts sont disponibles auprès de votre Service Delivery Manager.
Pour commencer, rendez-vous sur ITCare et recherchez votre service global cible où vous créerez votre nouveau déploiement Redis.
Recherchez votre service Global dans la barre de recherche supérieure et cliquez dessus pour afficher sa page d'information.
Une fois dans votre Service Global, cliquez sur le bouton Créer une ressource, sélectionnez Redis et la version requise.
Remplir le formulaire :
Sélectionner une topologie
Définir le nom du futur déploiement
Le dimensionnement
Le stockage requis sur chaque instance
La localisation cible
Le réseau cible
Les options de gestion (sauvegarde, surveillance, 24/7, réplication site distant)
Cliquer sur Suivant une fois les champs remplis.
A l'étape de personnalisation :
Saisir le mot de passe du compte administrateur qui sera fourni
Sélectionner les options de persistance requises
Activer ou non le chiffrement TLS
Puis cliquer sur Suivant.
Les mots de passe ne sont pas sauvegardés par cegedim.cloud.
Assurez-vous de sauvegarder votre mot de passe!
Réviser la synthèse avant de soumettre le formulaire.
Une fois le déploiement prêt, vous en serez informé par e-mail.
Ce code décrit comment se connecter sur Redis lorsque la topologie est une instance unique. Ce code est volontairement simplifié (les erreurs ne sont pas gérées), il est destiné à la démonstration uniquement.
Le langage Python est utilisé. Nous supposons que l'instance Redis est nommée pcluredis01.hosting.cegedim.cloud.
Ce code décrit comment se connecter sur Redis lorsque la topologie est Cluster (avec Sentinel). Il est volontairement simplifié (les erreurs ne sont pas gérées), il est destiné à la démonstration uniquement.
Le langage Python est utilisé.
Nous supposons que le cluster Redis est nommé redis-cluster avec un préfixe pclu. Il existe donc 3 machines :
pcluredis01.hosting.cegedim.cloud
pcluredis02.hosting.cegedim.cloud
pcluredis03.hosting.cegedim.cloud
Deux exemples sont proposés, avec et sans TLS.
Redis est déployable en self-service via notre outil de gestion de plateforme cloud : ITCare.
Deux topologies sont disponibles :
Instance autonome
Cluster Sentinel
L'instance autonome, une fois déployée, est accessible sur le port d'écoute 6379.
Le cluster Redis Sentinel est déployé sur 3 instances répartis sur toutes les Zones de disponibilité d'une Area.
Le cluster, une fois déployé, est accessible sur le port d'écoute 6379.
Chaque instance exécute les processus Redis et Sentinel
Port d'écoute Sentinel : 26379
Sur les 3 instances, l'une d'elle est primaire et les deux autres sont des répliques
Les répliques sont ouvertes en lecture seule
La persistance fait référence à l'écriture de données sur un support durable, tel qu'un disque SSD (solid-state disk). Redis propose une série d'options de persistance.
RDB (Redis Database) : La persistance RDB réalise des instantanés ponctuels de votre ensemble de données à des intervalles spécifiés.
AOF (Append Only File) : La persistance AOF enregistre chaque opération d'écriture reçue par le serveur. Ces opérations peuvent ensuite être rejouées au démarrage du serveur, reconstituant ainsi l'ensemble de données d'origine. Les commandes sont enregistrées dans le même format que le protocole Redis lui-même.
Pas de persistance : Vous pouvez désactiver complètement la persistance. Cette option est parfois utilisée pour la mise en cache.
RDB + AOF : Vous pouvez également combiner AOF et RDB dans la même instance.
Si l'instance primaire tombe en panne, une réplique sera automatiquement promue en tant que nouveau primaire. La réplique sera reconfigurée automatiquement pour suivre le nouveau primaire.
Sentinel fournit les informations concernant l'instance primaire et les instances répliques.
Cette section énumère les fonctionnalités disponibles pour le client, ainsi que la manière de les demander ou de les exécuter :
Si la persistance AOF est active, les paramètres suivants seront appliqués :
si RDB est actif, les paramètres suivants seront appliqués :
Les paramètres noyau suivants ont été modifiés afin d'optimiser les performances du système d'exploitation pour Redis :
vm.overcommit_memory = 1
vm.swappiness = 1
net.core.somaxconn = 65535
Le mode d'authentification utilisé est le mode interne : Redis 6 ACL.
Les mots de passe sont hashés avec SHA-256 et n’apparaissent pas en clair dans le fichier ACL.
Les ACL de Redis 6 sont utilisées pour gérer les autorisations.
Sur Sentinel, le compte client dédié a les droits sur :
Sur Redis, le compte client dédié a les droits sur :
Le client peut choisir d'activer le non le transport TLS lors de la demande de création en libre-service via ITCare.
Cette section énumère la gestion des mots de passe :
Les éléments suivants sont surveillés et sont accessibles dans ITCare.
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
Les pods sont déployés en utilisant les Kubernetes.
Option
Option
Option
Option
Option
Option
Option
Option
Pour plus d'information sur la configuration des attributs de nœud, veuillez consulter la .
Certaines de ces extensions sont développées au sein même du projet PostgreSQL et suivent donc les évolutions des différentes version de PostgreSQL. Vous pouvez en trouver la liste .
D'autres sont développées par des entreprises tierces et suivent leur propre rythme à l'instar de ou de pour ne citer que les plus connues.
Il fournit une réplication intégrée, différents niveaux de persistance sur le disque, et offre une haute disponibilité avec .
Il existe un .
Pour plus d'information, veuillez consulter la page .
La mise à jour d'un PaaS PostgreSQL est de la responsabilité de cegedim.cloud et peut être demandée via un soumis depuis ITCare en précisant un créneau de disponibilité pour l'opération.
Selon la version source et cible de PostgreSQL, il peut donc être nécessaire de migrer d'abord le système d'exploitation dans une version supportée par cegedim.cloud (voir ).
Pour plus d'information, veuillez consulter la page .
Dans les deux cas, vous pouvez choisir de faire persister ou non les données sur le disque lors de la demande de création, voir .
PostgreSQL 10
Debian 9
PostgreSQL 11
Debian 10
PostgreSQL 12
Debian 10
PostgreSQL 13
Debian 11
PostgreSQL 14
Debian 11
PostgreSQL 15
Debian 11
PostgreSQL 16
Debian 12
6.2.x
Debian 10
6.2.x
Debian 12 (déploiements créés après le 31 mai 2024)
7.2.x
Debian 12
Si Persistance RDB activée
save 3600 1
save 300 100
save 60 10000
Si Persistance AOF activée
append fsync every sec
Libre service
Le client peut effectuer une action de manière autonome.
Sur demande
Le client peut demander à l'équipe de support de cegedim.cloud de prendre les mesures nécessaires.
Accès SSH
L'accès SSH est désactivé et réservé aux administrateurs de cegedim.cloud.
Modifier le fichier de configuration
Sur demande via un billet.
Accès à Redis/Sentinel
Le client peut se connecter avec un compte à Redis et Sentinel (mot de passe défini par le client dans l'assistant de provisionnement).
bind
@IP 127.0.0.1
Adresse d'écoute
timeout
300
Fermer la connexion après qu'un client soit inactif pendant N secondes (0 pour désactiver)
logfile
/var/log/redis/redis-server.log
Chemin du fichier journal
supervised
systemd
Interaction de supervision
appendonly
oui
dir
/var/lib/redis/persistance
appendfsync
everysec
save
3600 1
save
300 100
save
60 10000
rdb_compression
oui
rdbchecksum
oui
dir
/var/lib/redis/persistance
compte du client
SHA-256
TOUT autre compte
SHA-256
compte cgdm_admin
SHA-256
compte cgdm_monitor
SHA-256
DBS_REDIS_CLI_CLIENTS
Vérifier le nombre de clients connectés
DBS_REDIS_CLI_AOF_STATUS
Vérifier l'état de l'aof
DBS_REDIS_CLI_COMMANDS
Nombre de commandes traitées
DBS_REDIS_CLI_CONNECTIONS
Nombre de connexions
DBS_REDIS_CLI_CPU
Utilisation du CPU
DBS_REDIS_CLI_MEMORY
Utilisation de la mémoire
DBS_REDIS_CLI_REPL_REPLICAS_COUNT
Vérifier le nombre de répliques
DBS_REDIS_CLI_RDB_STATUS
Statut de la RDB
DBS_REDIS_PING
Vérifie la disponibilité du nœud
DBS_REDIS_SENTINEL_MASTER_UP
Vérifie l'état du maître à partir de Sentinel
DBS_REDIS_SENTINEL_SLAVES_COUNT
Vérifier le nombre de répliques à partir de Sentinel
DBS_REDIS_SENTINEL_SENTINELS_COUNT
Vérifier Sentinelscount
DBS_REDIS_SENTINEL_QUORUM
Vérifier l'état du quorum
TLS_REDIS_CERT_EXPIRATION
Vérifier l'expiration du certificat Redis
TLS_SENTINEL_CERT_EXPIRATION
Vérifier l'expiration du certificat Sentinel
Deux topologies sont disponibles :
Instance autonome
Cluster AlwaysOn
La configuration du cluster Always On repose sur une topologie à 3 nœuds :
Deux nœuds situés sur le même site.
Ces nœuds sont configurés pour partager la charge ou être en basculement automatique en cas de défaillance.
Une règle d'anti-affinité garantit que les nœuds actifs ne cohabitent pas sur le même hôte hyperviseur, renforçant ainsi la résilience.
Localisé sur un site secondaire pour assurer la reprise après sinistre (DRP).
Ce nœud ne traite aucune requête active et est réservé uniquement au basculement en cas de défaillance des nœuds actifs.
Le nœud passif est soumis à des restrictions strictes pour respecter les règles de licence Microsoft License Mobility with Failover Rights :
Aucune charge active : Le nœud passif ne peut pas exécuter de requêtes SQL, de rapports ou de charges de travail utilisateur.
Opérations autorisées :
Vérifications de la cohérence des bases de données.
Sauvegardes complètes et des journaux de transactions.
Surveillance des performances et des ressources.
Licences optimisées : Grâce à la Software Assurance, l'utilisation du nœud passif est incluse sans coût supplémentaire, à condition que ces restrictions soient respectées.
Tolérance aux pannes : La réplication synchronisée garantit que les données sont disponibles en temps réel sur les nœuds actifs.
Reprise après sinistre (DRP) : Le déploiement d'un nœud passif sur un site secondaire renforce la sécurité et la continuité des activités.
Maintenance simplifiée : Les basculements planifiés permettent d'effectuer des mises à jour ou des interventions techniques sans interruption de service.
Une supervision spécifique adaptée au cluster Always On est en place pour :
Garantir que les restrictions liées au nœud passif sont respectées.
Surveiller les performances et les basculements automatiques.
Prévenir les risques de non-conformité avec les règles de licence.
SQL Server est disponible dans les centres de données de cegedim.cloud dans les régions suivantes :
EB4 - Boulogne-Billancourt, France
ET1 - Labège, France
Dans le cadre de la topologie AlwaysOn, un nœud inactif est automatiquement déployé dans un site secondaire proche pour renforcer la résilience du cluster :
EB5 (Magny-les-Hameaux, France)
ET2 (Balma, France)
Virtuel
SQL Server 2022
Windows Server 2022
Standard ou Entreprise
Virtuel
SQL Server 2019
Windows Server 2019
Standard ou Entreprise
Virtuel
SQL Server 2017
Windows Server 2019
Standard ou Entreprise
Virtuel
SQL Server 2016
Windows Server 2016
Standard ou Entreprise
Disposition du système de fichiers pour le PaaS SQL Server de cegedim.cloud :
D:\
MSSQL
30 Go
Racine de l'instance
E:\
MSSQL_USER_DATA
30 Go
Base de données utilisateurs
F:\
MSSQL_USER_LOG
10 Go
Log des bases de données utilisateurs
G:\
MSSQL_TEMPDB
10 Go
TempDB
En raison des préfixes appliqués aux objets Active Directory, le nom de la machine virtuelle provisionnée est limité à 13 caractères maximum pour un PaaS SQL Server.
Liste des ports :
1433
Écouteur de port statique du serveur
TCP
1434
SQL Server Browser
UDP
2382
Serveur d'écoute de SQL Server Analysis Services
UDP
2383
Serveur d'écoute de SQL Server Analysis Services
TCP
5022
SQL Server BDM/AG Endpoint
TCP
Seuls les ports de l'écouteur SQL Server et du navigateur SQL Server sont ouverts en entrée dans le pare-feu Windows par défaut et appliqués via une GPO sur l'unité organisationnelle.
Liste des modules installés par défaut lors de la provision :
Moteur de base de données
Réplication
Recherche en texte intégral
Connectivité des outils client
SDK
Cette section vise à répertorier les fonctionnalités/capacités disponibles pour le client, et comment les demander/exécuter :
Libre-service
Le client peut effectuer l'action de manière autonome.
A la demande
Le client peut demander que l'équipe de support de cegedim.cloud effectue l'action.
Database Collation
Integration Services
Analysis Services
Reporting Services
Recherche en texte intégral
Export, Import SQL Server backup
Création de cluster Always On
Disponible exclusivement pour l'édition SQL Server 2022 Enterprise, demander conseil à votre responsable de prestation de services
Le PaaS SQL Server fonctionne exclusivement dans un environnement Windows. La méthode standard de connexion à l'instance est le RDP (Remote Desktop Protocol).
Pour vous connecter à la machine virtuelle, vous devez disposer des privilèges requis au niveau du domaine ou au niveau de la machine locale.
L'authentification est configurée par défaut en mode mixte, ce qui offre deux types de connexion :
Connexion SQL Server: au niveau de l'instance
Utilisateur Active directory: au niveau du domaine - Authentification Windows intégrée
La connexion à l'instance est disponible localement ou à distance :
Localement : une fois connecté en RDP, lancez le SQL Server Management Studio local
A distance: lancez le SQL Server Management Studio et spécifiez l'instance cible Localement
SSMS peut utiliser les informations d'identification de l'utilisateur Windows avec lequel vous êtes déjà connecté via RDP pour vous connecter à l'instance SQL Server.
L'authentification avec un login SQL est également possible localement.
Spécifiez une instance cible dans le champ du nom du serveur en imposant le protocole : tcp:HOSTNAME\INSTANCENAME
Sélectionnez simplement "SQL Server Authentication" et fournissez le login SQL avec le mot de passe associé.
Les autorisations pour cegedim.cloud sont gérées par GPO.
Cette section répertorie la gestion des mots de passe pour le PaaS SQL Server :
compte admin
AUTRE compte
compte cgdm_admin
compte monitoring
Les autorisations pour les clients sont gérées par les clients eux-mêmes.
Le client qui demande une instance SQL Server via ITCare sera automatiquement autorisé à se connecter à l'instance. Il peut accorder l'accès à tout utilisateur ou groupe Active Directory.
Les patchs sont installés lors des "Patch parties" gérées par cegedim.cloud tous les trimestres. Une instance peut être patchée manuellement exceptionnellement si la sécurité ou la correction de bugs l'exige.
Les données pour le PaaS SQL Server de cegedim.cloud sont stockées sur les machines virtuelles dédiées créées lors de la demande d'un PaaS. Ces machines virtuelles et le stockage associé sont hébergés et gérés dans les propres centres de données de cegedim.cloud.
Instance(s)
1
3
CPU (par instance)
2 - 16 vCPU
2 - 16 vCPU
RAM (par instance)
4 - 384 Go
4 - 384 Go
Version(s) supportée(s)
6.2
7.2
6.2
7.2
TLS/SSL
Surveillance
Surveillance 24x7
Sauvegarde
Réplication de données (PRA)
Disponibilité
99,8%
99,9%
Déploiement multi-AZ
Libre-service
PostgreSQL 10
Debian 9 → Debian 10
Debian 9 → Debian 10
Debian 9 → Debian 11
Debian 9 → Debian 11
PostgreSQL 11
Debian 9 → Debian 10
Debian 9 → Debian 11
Debian 9 → Debian 11
PostgreSQL 12
Debian 10 → Debian 11
Debian 10 → Debian 11
PostgreSQL 13
PostgreSQL 14
PostgreSQL 15
Instances
1
3
CPU (par instance)
2 - 16 vCPU
2 - 16 vCPU
RAM (par instance)
8 - 384 Go
8 - 384 Go
Version(s) supportée(s)
2016
2017
2019
2022
2016
2017
2019
2022
Sauvegarde
Surveillance
Surveillance 24x7
Réplication de données (PRA)
Disponibilité
99,8%
99,9%
Déploiement Multi-AZ
Libre-service
Pour commencer, connectez-vous à ITCare et recherchez votre service global cible où vous créerez votre nouveau serveur SQL. Une fois dans votre service global, cliquez sur le bouton Créer une ressource dans le coin supérieur droit.
Dans la catégorie Bases de données managées, sélectionnez SQL Server :
Choisissez la version et l'édition souhaitées :
Nom : Indiquez le nouveau nom de la machine virtuelle SQL Server.
En mode Cluster AlwaysOn, spécifiez le nom du groupe de disponibilité.
Prefix : indiqué un prefix pour initialier les machines virtuelles du cluster.
Dimensionnement : Sélectionnez un dimensionnement pour votre instance. La valeur par défaut et le dimensionnement le plus bas est 2 CPUs / 4 Go RAM.
Stockage : Sélectionnez la capacité de stockage requise pour SQL Server. Cinq disques sont nécessaires.
La valeur par défaut et la capacité de stockage minimale sont de 30 Go pour les disques de l'instance racine et des bases de données utilisateur, de 10 Go pour les disques du journal utilisateur et de tempdb.
Localisation : Sélectionnez la région dans laquelle vous souhaitez effectuer le déploiement. Choisissez une zone dans cette région et enfin une zone de disponibilité.
Réseau : Sélectionnez le VLAN dans lequel vous voulez déployer. Idéalement, il s'agit du VLAN de votre backend.
Authentification : Sélectionnez le domaine d'authentification dans lequel vous souhaitez vous déployer.
Options de gestion : Activez les options de gestion.
Activer ou désactiver la surveillance
Activer ou désactiver la surveillance 24/7
Activer la sauvegarde de votre machine virtuelle
Activer la réplication de vos machines virtuelles (sur le site de Reprise d'activité après sinistre)
Indiquez le mot de passe de l'administrateur que vous utiliserez pour l'utilisateur de l'administrateur du serveur SQL.
cegedim.cloud n'enregistrera pas ce mot de passe. Veuillez donc le conserver en lieu sûr dans votre coffre-fort.
Confirmez votre mot de passe.
Choisissez votre collation SQL.
Ajouter des technologies supplémentaires disponibles dans SQL Server : SSIS, SSAS, SSRS
Vous pouvez ajouter une demande spécifique avant de la soumettre, mais cela retardera le provisionnement automatique.
Cliquez sur Suivant lorsque vous avez terminé.
Cette page reprendra vos données, veuillez vérifier que tout est correct avant de les soumettre. Vous pouvez afficher et enregistrer votre mot de passe administrateur. Une fois les données vérifiées, cliquez sur Soumettre.
Une fois que le déploiement est prêt, vous serez notifié par email. Le provisionnement peut prendre jusqu'à une heure en fonction de la charge actuelle de l'automatisation.
En haut de la page de la ressource, cliquez sur le bouton Gérer, puis sur Démarrer et confirmer.
Une notification par courrier électronique sera envoyée lorsque le service sera activé.
En haut de la page de la ressource, cliquez sur le bouton Gérer, puis sur Arrêter. Saisissez un numéro RFC pour le suivi (facultatif). Cliquez sur Soumettre.
L'arrêt d'un cluster entraîne l'arrêt de toutes les machines virtuelles attachées au cluster et la désactivation de la surveillance.
Une notification par courrier électronique sera envoyée lorsque le cluster sera arrêté.
En haut de la page des ressources, cliquez sur le bouton Gérer, puis sur Redimensionner. Sélectionnez la nouvelle taille (CPU / RAM).
Une notification par courrier électronique sera envoyée lorsque tous les nœuds auront été redimensionnés.
En haut de la page du cluster, cliquez sur le bouton Gérer, puis sur Supprimer. Cela arrêtera et supprimera toutes les machines virtuelles.
Veuillez noter que cette action n'est pas récupérable !
Saisissez un numéro RFC pour le suivi (facultatif), puis cliquez sur Soumettre. Une notification par courrier électronique sera envoyée lorsque le déploiement sera supprimé.
Option
Option
Option
Option
Option
Option
Option
Option
Option
Option
*
*
**
**
** Debian 9 → Debian 11
*** Debian 9 → Debian 12
*
**
**
** Debian 9 → Debian 11
*** Debian 9 → Debian 12
*
*
* Debian 10 → Debian 11
** Debian 10 → Debian 12
* Debian 11 → Debian 12
* Debian 11 → Debian 12
* Debian 11 → Debian 12
Option
Option
Option
Option
Option
Option
Option
Option
Resource Id, example: 1234
Service Id, example: 56789
Platform, example: Debian 8
Support Phases, example: STANDARD,EXTENDED
Start Date (ISO8601 format), example: 2022-07-22T00:00:00.000Z
Results page you want to retrieve (0..N)
Number of records per page.
Sorting criteria in the format: property(,asc|desc). Default sort order is ascending. Multiple sort criteria is not supported.
Platform, example: cent7, ubu22
Storage specification of platform (disks / max sizes...)
Resource profiles (CPU/RAM) that can be allocated to instances.
Properties specification of platform (package / script, backup type...)
This method allows to delete a matomo instance.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
DELETE /analytics/matomo/123
id, example: 123
Names, example: resource01,!resource02,resource42
Environments, example: PRODUCTION,DEVELOPMENT
Status, example: ACTIVE,INACTIVE
Tags, example: agkey:mytagvalue,application:itcare
Filter list by monitoring status
Filter list by monitoring on call status
Filter list by backup status
Filter list by DRP status
Filter list by patch party status
Topology, example: Standard, HA
Version, example: v1.26.15, v1.28.13, etc...
Region, example: EB,ET
Results page you want to retrieve (0..N)
Number of records per page.
Sorting criteria in the format: property(,asc|desc). Default sort order is ascending. Multiple sort criteria is not supported.
K8sCluster Id, example: 123
type, example: az-distribution | dc-distribution
This method allows to delete a Kubernetes cluster node.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
To delete a Kubernetes node, the id of the Kubernetes cluster and the id of the node to delete must be specified.
To list the nodes of the Kubernetes cluster, use the endpoint : GET /containers/kubernetes/{kuberneteId}/nodes/{nodeId}.
Use the following to delete a node of a Kubernetes cluster.
DELETE /containers/kubernetes/1234/nodes/4567
To keep consistency on the Kubernetes cluster, please note that :
All nodes cannot be deleted.
All ingress nodes cannot be deleted.
API users will have a BAD_REQUEST
when trying to break one of the rule above.
id, example: 123
id, example: 456
Service Id, example: 1234
availabilityZone
policyType, example: SERVER
backupReplicated
Names, example: resource01,!resource02,resource42
Types, example: TOMCAT or WILDFLY or WEB_ZONE
Families, example: DEBIAN,CENTOS,RHEL
Environments, example: PRODUCTION,DEVELOPMENT
Status, example: ACTIVE,INACTIVE
Tags, example: mytagkey:mytagvalue,application:itcare
Filter list by monitoring status
Filter list by monitoring on call status
Filter list by backup status
Filter list by DRP status
Filter list by patch party status
Availability Zone, example: EB-A, EB-B, EB-C, etc...
IPs, example: 10.59.13.29
VLAN, example: EB_1125_DMZ8
Results page you want to retrieve (0..N)
Number of records per page.
Sorting criteria in the format: property(,asc|desc). Default sort order is ascending. Multiple sort criteria is not supported.
Names, example: resource01,!resource02,resource42
Types, example: WINDOWS,AIX,LINUX
Families, example: DEBIAN,CENTOS,RHEL
Environments, example: PRODUCTION,DEVELOPMENT
Status, example: ACTIVE,INACTIVE
Tags, example: mytagkey:mytagvalue,application:itcare
Filter list by monitoring status
Filter list by monitoring on call status
Filter list by backup status
Filter list by DRP status
Filter list by patch party status
Availability Zone, example: EB-A, EB-B, EB-C, etc...
IPs, example: 10.59.13.29
VLAN, example: EB_1125_DMZ8
Results page you want to retrieve (0..N)
Number of records per page.
Sorting criteria in the format: property(,asc|desc). Default sort order is ascending. Multiple sort criteria is not supported.
Resource Id, example: 123
Snapshot Id, example: 123-snap-42
This method allows to update the partch party informations related to the given service.
Structure of payload is generic and describes :
an array
containing the patch party configuration to apply for each resource of the given serviceUpdate Patch Party Statuses
PATCH /services/1234/patch-policies
[
{
"resourceId": 500079802,
"excluded": false,
"exclusionReason": "I don't want to include this resource"
},
{
"resourceId": 500079545,
"excluded": true,
"patchGroup": "2"
},
{
"resourceId": 500057033,
"excluded": false,
"exclusionReason": "Wrong patch group is set",
"patchGroup": "1c"
},
{
"resourceId": 500057055,
"excluded": false,
"patchGroup": "1"
}
]
[
{
"status": "FAILED",
"message": "The patch group is only allowed when the farm has one member",
"id": -1,
"internalId": 500057055
},
{
"status": "IN_PROGRESS",
"message": "Include PatchParty SQLServer rhutsql20",
"process": "INCLUDE_PATCHPARTY",
"id": 500079545,
"lastUpdatedAt": "2023-11-16T11:53:42.888+00:00"
},
{
"status": "FAILED",
"message": "Wrong patch party group set",
"id": -1,
"internalId": 500057033
},
{
"id": 202
}
]
There are 3 groups available defining the sequence on which the instance should be updated: 1 (First Group), 2 (Second Group) or 3 (Third Group).
If no group is set, it means that you have no preference while defining the sequences.
Service Id, example: 44411
boolean flag to fetch history details for every ci
Names, example: resource01,!resource02,resource42
Environments, example: PRODUCTION,DEVELOPMENT
Statuses, example: ACTIVE,INACTIVE
Tags, example: mytagkey:mytagvalue,application:itcare
Sorting criteria in the format: property(,asc|desc). Default sort order is ascending. Multiple sort criteria is not supported.
Results page you want to retrieve (0..N)
Number of records per page.
Service Id, example: 500063721
Actions, example: enable_monitoring
Statuses, example: SUCCESS
Names, example: REBITTEST01
Service Id, example: 44411
Names, example: devvcaglfs02
Statuses, example: ACTIVE,INACTIVE,PREPARATION
Sizing of the resource, example: 2cpu4gb
Number of nodes, example: 2
IP Address, ex: 10.10.10.10
Service Id, example: 44411
Names, example: REBMYAPP01,REBMYSRV
Categories, example: INSTANCES,APPLICATION_SERVERS,LOAD_BALANCERS
Statuses, example: ACTIVE,INACTIVE,PREPARATION
Service Id, example: 44411
Names, example: PET1
Statuses, example: ACTIVE,INACTIVE,PREPARATION
Service Id, example: 44411
Names, example: www.cegedim.com,www.egypt.eg
Statuses, example: ACTIVE,INACTIVE,PREPARATION
Service Id, example: 44411
Names, example: www.cegedim.com,www.egypt.eg
Statuses, example: ACTIVE,INACTIVE,PREPARATION
Number of Members, example: 2
Service Id, example: 44411
Names, example: REBMYAPP01,REBMYSRV
Statuses, example: ACTIVE,INACTIVE,PREPARATION
Versions, example: EB,ET,NK
Service Id, example: 44411
Names, example: REBMYAPP01,REBMYSRV
Families, example: DEBIAN,RHEL
Backup
Drp
withManagedNodes
withApplicationServers
withOracleDbs
withMongoNodeJs
Statuses, example: ACTIVE,INACTIVE,PREPARATION
Service Id, example: 44411
Broker name, example: deblaprmq01
Broker status, example: ACTIVE
Broker version, example: 3.9
Broker size, example: 4cpu8gb
Service Id, example: 44411
Names, example: REBMYAPP01,REBMYSRV
Backup
Drp
Statuses, example: ACTIVE,INACTIVE,PREPARATION
Category, example: INSTANCES
""
Allows to list resources available in your cloud.
This endpoint could be used as a main entry to get informations about the other kind of resource types.
When the resource is retrieved, the *path*
attribut allows to navigate to the right category of the resource.
For example : *path=/compute/containers/kubernetes*
tells to check the sections *compute > containers > kubernetes*
for more details.
IDs, example: 123,456,789
Names, example: resource01,!resource02,resource42
Types, example: WINDOWS,AIX,LINUX
Families, example: DEBIAN,CENTOS,RHEL
Versions, example: DEBIAN_10,CENTOS_6,RHEL_5
Environments, example: PRODUCTION,DEVELOPMENT
Status, example: ACTIVE,INACTIVE
Tags, example: mytagkey:mytagvalue,application:itcare
Results page you want to retrieve (0..N)
Number of records per page.
Sorting criteria in the format: property(,asc|desc). Default sort order is ascending. Multiple sort criteria is not supported.
Gets a compute Resource by its Id.
A Resource
is the ITCare base object.
A resource is composed of :
*id*
: Unique identifier of the resource*name*
: Name of the resource*serviceId*
: Each resource must be linked to a service . The service is a logical entity that hosts resources per environment, application ...*environment*
: The environment of the resource. Can be for example 'PRODUCTION', 'QA', 'RECETTE_UAT', 'DEV' ...*creationUser*
: The creator of the resource*creationTime*
: When the resource has been created*comment*
: Description of the resource*category*
: High level categorization of the resource*family*
: Family of the resource belonging the category*status*
: status of the resource. It can be 'ACTIVE' (running), 'INACTIVE' (stopped)*resourceType*
: Type of the resource*cloudId*
: Each cloud*cloudName*
: name of the related cloud*path*
: Helper that gives a path or location about which category to find the resource for more details operationsWhen the resource is retrieved, the *path*
attribut allows to navigate to the right category of the resource.
Resource Id, example: 123
Retrieves all operations and events that occurs on a resource : start, stop, monitoring operations ...
Resource Id, example: 123
Actions, example: enable_monitoring
Statuses, example: SUCCESS
Resource Id, example: 123
Resource/Node Ids, example: 123
[]
Operation Type, example: available|available-nodes|in-progress|in-progress-nodes|list-actions-in-progress|list-available-actions
available
Service Ids, example: 1234
Environment, example: PRODUCTION,QA
Technologies of resource. For exemple LINUX,KUBERNETES
Count statistic with uncategorized types
global|count|obsolescence|service|network, example: global
Start Date (ISO8601 format), example: 2022-07-22T00:00:00.000Z
This method allows to delete a redis instance.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
DELETE /redis/123
id, example: 123
This method allows to delete a Maria DB instance.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
DELETE /mariadb/123
Id, example: 123
This method allows to delete an OpenSearch instance.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
DELETE /opensearch/123
id, example: 123
Names, example: resource01,!resource02,resource42
Types, example: WINDOWS,AIX,LINUX
Families, example: DEBIAN,CENTOS,RHEL
Environments, example: PRODUCTION,DEVELOPMENT
Status, example: ACTIVE,INACTIVE
Tags, example: mytagkey:mytagvalue,application:itcare
Filter List for Restore
Database Version, example: 11
Filter list by monitoring status
Filter list by monitoring on call status
Filter list by backup status
Filter list by DRP status
Filter list by patch party status
Topology, example: AlwaysOn, Galera, Replica Set, Cluster, Standalone, HA, etc..
Version, example: 2.11.0, 2022 EE, etc...
Results page you want to retrieve (0..N)
Number of records per page.
Sorting criteria in the format: property(,asc|desc). Default sort order is ascending. Multiple sort criteria is not supported.
This method allows to delete a postgre SQL instance.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
DELETE /postgresql/123
id, example: 123
Names, example: resource01,!resource02,resource42
Environments, example: PRODUCTION,DEVELOPMENT
Status, example: ACTIVE,INACTIVE
Tags, example: mytagkey:mytagvalue,application:itcare
Results page you want to retrieve (0..N)
Number of records per page.
Sorting criteria in the format: property(,asc|desc). Default sort order is ascending. Multiple sort criteria is not supported.
This method allows to delete an Apache Kafka platform.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
DELETE /message-brokers/apache-kafka/123
id, example: 123
This method allows to delete a RabbitMQ broker instance.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
DELETE /message-brokers/rabbitmq/123
id, example: 123
By default,The user's clouds are used to filter the final output
Names, example: resource01,!resource02,resource42
Types, example: WINDOWS,AIX,LINUX
Families, example: DEBIAN,CENTOS,RHEL
Environments, example: PRODUCTION,DEVELOPMENT
Status, example: ACTIVE,INACTIVE
Tags, example: mytagkey:mytagvalue,application:itcare
Filter list by monitoring status
Filter list by monitoring on call status
Filter list by backup status
Filter list by DRP status
Filter list by patch party status
Topology, example: Cluster, Standalone, etc..
Version, example: 2.7.0, 3.6.0, 3.9.29-1, etc...
Results page you want to retrieve (0..N)
Number of records per page.
Sorting criteria in the format: property(,asc|desc). Default sort order is ascending. Multiple sort criteria is not supported.
Names, example: resource01,!resource02,resource42
Environments, example: PRODUCTION,DEVELOPMENT
Status, example: ACTIVE,INACTIVE
Tags, example: mytagkey:mytagvalue,application:itcare
Filter list by monitoring status
Filter list by monitoring on call status
URLs, example: .cegedim.cloud
IRules, iRule-Redirect-gis-workflow
Default Persistence, example: cookie,hash, or source_addr etc...
Fallback Persistence, example: dest_addr, source_addr, etc...
Load Balancing Mode, example: least-connections-node, round-robin, etc...
Protocols, example: HTTP, HTTPS, MYSQL, etc...
VLAN, example: EB_1125_DMZ8
Results page you want to retrieve (0..N)
Number of records per page.
Sorting criteria in the format: property(,asc|desc). Default sort order is ascending. Multiple sort criteria is not supported.
This method allows to delete a URL of Load Balancer.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
DELETE /loadbalancers/123/urls/456
Load Balancer Id, example: 123
Load Balancer Url Id, example: 123
id, example: 500067154
From Date (ISO8601 format), example: 2023-03-15T00:00:00.000Z
To Date (ISO8601 format), example: 2023-03-16T00:00:00.000Z
type, example: security
security
criteria, example: bot
bot
size, example: 20
20
Filter, example: resource01,!resource02,resource42
publicIp
Environments, example: QA
Scopes, example: frontend , backend
Regions, example: EB,NK
Results page you want to retrieve (0..N)
Number of records per page.
Sorting criteria in the format: property(,asc|desc). Default sort order is ascending. Multiple sort criteria is not supported.
This method returns the list of accessible networks from a Load balancing Zone.
scope
query parameter to filter private
, interco
, internet
networks. for 'frontend' and 'backend' networks, use scope=private
environment
query parameter to filter production
, non_production
networks. for 'production' networks, use environment=production
onlyNonFull
if you want only networks with available IP addresses to be listed.clouds
parameter (comma-separated list of long) to restrict results to specified Clouds IDs (use the /me to obtain the list of your Clouds).Resource Id, example: 123
Resource/Node Ids, example: 123
[]
LB/URL Ids, example: 123
[]
Resource Ids : urls or members, example: 123
[]
Operation Type, example: available|available-nodes|in-progress|in-progress-nodes|list-actions-in-progress|list-available-actions
available
Names, example: overdrive1
Results page you want to retrieve (0..N)
Number of records per page.
Sorting criteria in the format: property(,asc|desc). Default sort order is ascending. Multiple sort criteria is not supported.
This method allows to delete an Overdrive instance.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
DELETE /storage/overdrive/123
id, example: 123
Names, example: resource01,!resource02,resource42
Environments, example: PRODUCTION,DEVELOPMENT
Status, example: ACTIVE,INACTIVE
Tags, example: mytagkey:mytagvalue,application:itcare
Filter list by monitoring status
Filter list by monitoring on call status
Filter list by backup status
Filter list by DRP status
Filter list by patch party status
Topology, example: Cluster
Version, example: v1.26.15, v1.28.13, etc...
VirtualIp, example: 127.0.0.1, 127.0, 127, 10.%.62
Results page you want to retrieve (0..N)
Number of records per page.
Sorting criteria in the format: property(,asc|desc). Default sort order is ascending. Multiple sort criteria is not supported.
A low-latency network area, in which we can create load balancers to address several availabilty-zones within this area.
Use param withAvailabilityZones=true
to retrieve Availability Zones of the region.
Region Name, example: EB
Include Areas
false
A low-latency network area, in which we can create load balancers to address several availabilty-zones within this area.
Use param withAvailabilityZones=true
to retrieve Availability Zones of the region.
Region Name, example: EB
Platform Id, example: deb10
Include Availability Zone
true
This method returns the list of accessible networks from an Area.
scope
filter by network scopeonlyNonFull
if you want only networks with available IP addresses to be listedRegion Name, example: EB
Area Name, example: EB-QA
This method returns the list of accessible networks from a Load balancing Zone.
scope
query parameter to filter private
, interco
, internet
networks. for 'frontend' and 'backend' networks, use scope=private
environment
query parameter to filter production
, non_production
networks. for 'production' networks, use environment=production
onlyNonFull
if you want only networks with available IP addresses to be listed.clouds
parameter (comma-separated list of long) to restrict results to specified Clouds IDs (use the /me to obtain the list of your Clouds).Region Name, example: EB
Area Name, example: EB-QA
A healthcheck is a test performed on a loadbalanced url to retrieve the status of the service Use the clouds
parameter (comma-separated list of long) to restrict results to specified Clouds IDs (use the /me to obtain the list of your Clouds).
Region Name, example: EB
Area Name, example: EB-QA
This method returns the list of accessible networks from an Availability Zone.
You can use scope
query parameter to filter frontend/backend networks,
and onlyNonFull
if you want only networks with available IP addresses to be listed
Region Name, example: EB
Area Name, example: EB-QA
AZ Name, example: EB-QA-A
This method returns the list of accessible authentication domains within a network.
Region Name, example: EB
Area Name, example: EB-QA
AZ Name, example: EB-QA-A
Network Id, example: 123
EB
EB-INT
""
This method allows to create a matomo instance.
You will have to know at the minimum :
region
attribute)name
attribute)sizing
attribute). The possible values are : XS (Up to 100K ppm), S(Up to 1M ppm), M(Up to 10M ppm), L(Up to 100M ppm), XL(More than 100M ppm)password
attribute). The password must be At least one lowercase, one uppercase, one digit, one special character, minimum length must be 12.serviceId
attribute).defaultWebSiteName
, defaultWebUri
).This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
POST /analytics/matomo
{
"name": "pmatomo01",
"region": "EB",
"sizing":"XS",
"serviceId":"123",
"password": "Password!!??",
"defaultWebSiteName": "ITCare",
"defaultWebUri": "https://itcare.cegedim.cloud"
}
Indicates if backup has to be setup on instance. If absent, backup will be setup automatically if instance is in a production service.
BackupPolicy id. Refers to desired backup policy to be applied for the database, must be set when backup is enabled.
Default website name to be configured in Matomo, if left empty, a dummy value will be configured
Default website url to be configured in Matomo, if left empty, a dummy value will be configured
Indicates if alerting should be activated. If absent, set to false.
Indicates if monitoring will be setup. If absent, it will be automatically be setup if this is an production environment, or if backup is enabled.
Name of Matomo Instance
[a-z0-9\-]{4,60}$
Indicates why a production resource is not under backup.
Indicates why a production resource is not under monitoring.
Indicates why a production resource is not replicated.
Indicates if on call teams will be called on non business hours if an incident occurs on instance. If absent, set to false.
Password to connect to the matomo instance.
Region. that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Regulation. Refer to the regulation of the Area (HDS|STANDARD). If absent, default 'STANDARD' will be used.
Indicates if replication will be setup. If absent, it will be automatically be setup if this is an production environment
BackupPolicy id. Refers to desired backup policy to be applied for the virtual machine, must be set when backup is enabled.
id of service to put instance in.
Sizing. L, XL , XS, S, M. Sizing for matomo instances
This method allows to update a matomo instance.
Structure of payload is generic and describes :
operation
you want to be performedoptions
data relative to the operation performed - see details - optional.Below are different operations currently implemented.
Start matomo instance
Use the start
operation to start a matomo instance.
Starts matomo instance.
This method is synchronous (status code 202
).
Example :
PATCH /analytics/matomo/1234
{
"operation": "start"
}
Stop matomo instance
Use the stop
operation to stop the nodes of the matomo instance and the instance itself.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /analytics/matomo/1234
{
"operation":"stop"
}
Extend matomo instance
Use the extend
operation to stop the nodes of the matomo instance and the instance itself.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /analytics/matomo/1234
{
"operation":"extend",
"options" : {
"sizing" : "M"
}
}
id, example: 123
This method allows to create a cluster.
You will have to know at the minimum :
area
attribute)networkId
attribute)name
attribute)nodeSizing
attribute)instanceCount
attribute)serviceId
attribute)This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
POST /clusters
{
"name": "PCLUSTER01",
"area": "EB",
"networkId": "ED145",
"serviceId": 123,
"nodeSizing":, "1cpu2gb"
"instanceCount": 2
}
Describes the k8s container to be created.
Area. Refer to an Area of a Region, that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Indicates if backup has to be setup on instance. If absent, backup will be setup automatically if instance is in a production service.
BackupPolicy id. Refers to desired backup policy to be applied for the database, must be set when backup is enabled.
Kubernetes Container Ingress Providers
Number of instances to create in k8s cluster
Indicates if alerting should be activated. If absent, set to false.
Indicates if monitoring will be setup. If absent, it will be automatically be setup if this is an production environment, or if backup is enabled.
Name of k8s cluster
[a-z0-9\-]+
The network Id of the ELS cluster
Indicates why a production resource is not under backup.
Indicates why a production resource is not under monitoring.
Indicates why a production resource is not replicated.
Node sizing for cluster
Indicates if on call teams will be called on non business hours if an incident occurs on instance. If absent, set to false.
Product platform of the cluster
Region. that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Regulation. Refer to the regulation of the Area (HDS|STANDARD). If absent, default 'STANDARD' will be used.
Indicates if replication will be setup. If absent, it will be automatically be setup if this is an production environment
BackupPolicy id. Refers to desired backup policy to be applied for the virtual machine, must be set when backup is enabled.
id of service to put instance in.
K8sCluster Id, example: 123
Describes a load balancer.
Area. Refer to an Area of a Region, that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Indicates if backup has to be setup on instance. If absent, backup will be setup automatically if instance is in a production service.
certificate of the load balancer., example: wildcard_cegedim.com
BackupPolicy id. Refers to desired backup policy to be applied for the database, must be set when backup is enabled.
healtcheck of load balancer., example: http
Indicates if alerting should be activated. If absent, set to false.
Indicates if monitoring will be setup. If absent, it will be automatically be setup if this is an production environment, or if backup is enabled.
Network id. Refer to networks available in List Networks method. If absent, a default network of AZ will be used.
Indicates why a production resource is not under backup.
Indicates why a production resource is not under monitoring.
Indicates why a production resource is not replicated.
Indicates if on call teams will be called on non business hours if an incident occurs on instance. If absent, set to false.
port member of load balancer., example: 80, 443, ...
profile name of load balancer.
Region. that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Regulation. Refer to the regulation of the Area (HDS|STANDARD). If absent, default 'STANDARD' will be used.
Indicates if replication will be setup. If absent, it will be automatically be setup if this is an production environment
BackupPolicy id. Refers to desired backup policy to be applied for the virtual machine, must be set when backup is enabled.
id of service to put instance in.
Indicates if a DNS record is to be set. If absent, set to false.
ssl profile of the load balancer., example: profile_wildcard.cegedim.com_secure
url of load balancer. Must be unique, and fit naming rules convention., example: url.cegedim.com
^(https?:\\/\\/)?(www\\.)?[a-zA-Z][a-zA-Z0-9.-]{2,63}+$
port of load balancer in case of TCP VS Profile
This method allows to delete a K8s Cluster Container.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
DELETE /k8s-clusters/123
DELETE /k8s-clusters/123
{
"changeReference": "rfc nunmber 456"
}
id, example: 123
Parameters when deleting a resource
Optional reference for change
This method allows to update a cluster.
Structure of payload is generic and describes :
operation
you want to be performedoptions
data relative to the operation performed - see details.Below are different operations currently implemented.
Create Nodes
Use the create_nodes
operation to create the nodes of a cluster.
Create nodes operation will add the new nodes in the cluster by availability zone. You can specify the availability zone you need in the request.
This method is synchronous (status code 202
).
Example :
PATCH /containers/kubernetes/1234
{
"operation": "create_nodes",
"options": {
"nodes": [
{
"nodesNb": 1,
"nodeSizing": "2cpu4gb",
"az": "EB-A"
},
{
"nodesNb": 2,
"nodeSizing": "4cpu8gb",
"az": "EB-B"
}
]
}
}
Delete Nodes
Use the delete_nodes
operation to delete the nodes of a cluster.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /containers/kubernetes/1234
{
"operation":"delete_nodes",
"options":{
"nodes": ["11112","11113","11114"]
}
}
Enable High Availability - HA
Use the enable_ha
operation to enable the HA of a cluster.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /containers/kubernetes/1234
{
"operation":"enable_ha"
}
Update Monitoring
Use the update_monitoring
operation to update the monitoring state of the cluster.
Use the state
option to turn on/off monitoring.
Use the on_call
option to turn on/off 24/7 monitoring.
This method is synchronous (status code 202
).
PATCH /containers/kubernetes/1234
{
"operation": "update_monitoring",
"options": {
"state": true,
"on_call": true
}
}
Update Patch Party
Use the update_patch_party
operation to update the patch party scheduled plan of the cluster.
excluded
option to turn on/off patch party.patchGroup
option to select the patching group, the patchGroup
is optional, and is only allowed when the farm has one member.exclusionReason
option to explain the reason of excluding the resource from patch part.This method is synchronous (status code 202
).
PATCH /containers/kubernetes/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": false,
"patchGroup": "3"
}
}
}
PATCH /containers/kubernetes/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": true,
"exclusionReason": "I want to handle this by myself"
}
}
}
Upgrade
Use the upgrade
operation to upgrade the cluster.
version
option to set the target version to be installed.The requirements are :
/compute/platform/products?type=KUBERNETES
to list all versions available for the cluster.This method is synchronous (status code 202
).
PATCH /containers/kubernetes/1234
{
"operation": "upgrade",
"options": {
"version": "1.24"
}
}
K8s Cluster Id, example: 123
This method allows to create an instance.
You will have to know at the minimum :
region
attribute)platform
attribute)name
attribute)resourceId
attribute)serviceId
attribute)This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
POST /instances
{
"name": "PINSTANCE01",
"region": "EB4",
"serviceId": 13,
"platform": "deb8",
"resourceId": "1cpu2gb"
}
This will create a Debian 8 machine (1cpu 2gb RAM) in EB4 region, named PINSTANCE01, and put it into service of ID 13.
By setting only these parameters, ITCare will use default profile of image (disk configuration) and choose most appropriate Availability Zone and network to host your instance. If you want to specify those parameters take a look at other examples in this documentation.
Response :
{
"id": "1333",
"status": "IN_PROGRESS"
}
With some python code, you can create instance and wait for completion like this:
instance = {
"name": "PINSTANCE01",
"region": "EB4",
"serviceId": 13,
"platform": "deb8",
"resourceId": "1cpu2gb"
}
action = itcare.post('/api/instances', payload=instance)
while action['status']=='IN_PROGRESS':
time.sleep(1)
action = itcare.get('/api/actions/{}'.format(action['id']))
print action['status']
Choose target Platform and properties
You'll have to know which platform you want to create, and so use Platforms methods to properly fill in relevant attributes (disks / custom properties / allocated resources...).
Choose Availability Zone and Network
You may want to choose your availability zone and network, you can do this by adding availabilityZone
and networkId
parameters to your request.
To discover both availability zones and networks, you can use methods Regions, AZ, and Networks.
Describes the instance to be created.
Area. Refer to an Area of a Region, that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
authentication domain id, if not set, will take default, example: CGDM-EMEA
Availability zone id. Refer to AZ available in List Availability Zones method. If absent, default AZ of region will be used.
Indicates if backup has to be setup on instance. If absent, backup will be setup automatically if instance is in a production service.
Indicates if backup off site (data replicated to another region) has to be setup on instance. If absent, backup off site will be setup automatically if instance is in a production service.
BackupPolicy id. Refers to desired backup policy to be applied for the database, must be set when backup is enabled.
Indicates if alerting should be activated. If absent, set to false.
Indicates if monitoring will be setup. If absent, it will be automatically be setup if this is an production environment, or if backup is enabled.
hostname of instance. Must be unique, and fit naming rules convention., example: PEB4MYAPP01
Network id. Refer to networks available in List Networks method. If absent, a default network of AZ will be used.
Indicates why a production resource is not under backup.
Indicates why a production resource is not under monitoring.
Indicates why a production resource is not replicated.
Indicates if on call teams will be called on non business hours if an incident occurs on instance. If absent, set to false.
id of platform (image) of instance. To discover available platforms, use ListPlatforms method, example: deb8 for Debian 8
code of product., example: rmq11 for RabbitMQ 11
Custom properties to set up on instance such as security enforcement ... . Depends on which platform you choose to create (for some of them, properties are mandatory). Refer to platform specification to find out.
Region. that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Regulation. Refer to the regulation of the Area (HDS|STANDARD). If absent, default 'STANDARD' will be used.
Indicates if replication will be setup. If absent, it will be automatically be setup if this is an production environment
identifier of resources (cpu/ram) that will be allocated to the instance. Use List Platforms method to see resources available for each of them., example: 1cpu2gb
BackupPolicy id. Refers to desired backup policy to be applied for the virtual machine, must be set when backup is enabled.
id of service to put instance in.
specific request to be done by an administrator. Can differ delivery of instance up to 24h., example: Could you please install .NET framework 4.5 on instance ? Thanks.
Volumes to setup on instance. If absent, will be set to defaults.
This method allows to delete an instance.
Instance has to be in INACTIVE
status, meaning that you have to stop it before deleting it. Use Update Instance
PATCH method with stop
operation prior to this deletion.
This operation cannot be undone afterwards.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
Example (no body required) :
DELETE /instances/1233
With additional change reference :
DELETE /instances/1233
{
"changeReference": "RFC_123"
}
id, example: 123
Parameters when deleting a resource
Optional reference for change
This method allows to update an instance.
Structure of payload is generic and describes :
operation
you want to be performedoptions
to pass to operation to have the operation performed.Below are different operations currently implemented.
Stop an Instance
Use the stop
operation to perform the stop of instance.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
Use this method only if instance is running and is in the ACTIVE
state. Otherwise a 400
status error code will be returned.
PATCH /instances/1234
{
"operation": "stop"
}
You can also put an optional changeReference
if you want ITCare keep a reference to external change management system :
PATCH /instances/1234
{
"operation": "stop",
"options": {
"changeReference": "RFC_123"
}
}
Start an Instance
Use the start
operation to perform the start of instance.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
Use this method only if instance is not running and is in the INACTIVE
state. Otherwise a 400
status error code will be returned.
PATCH /instances/1234
{
"operation": "start"
}
You can also put an optional changeReference
if you want ITCare keep a reference to external change management system :
PATCH /instances/1234
{
"operation": "start",
"options": {
"changeReference": "RFC_123"
}
}
Reset an Instance
Use the reset
operation to perform the reset of instance.
Reset operation will perform a hard reset of instance, like power off/power on.
This operation may result in data loss, your applications and services will not be stopped gracefully.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
Use this method only if instance is running and is in the ACTIVE
state. Otherwise a 400
status error code will be returned.
PATCH /instances/1234
{
"operation": "reset"
}
You can also put an optional comment
that will be display in monitoring system :
PATCH /instances/1234
{
"operation": "reset",
"options": {
"comment": "Reset instance because OS is freezed"
}
}
Resize an Instance
Use the resize
operation to perform the resize of instance.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
Use this method only if instance is not running and is in the INACTIVE
or ACTIVE
state. Otherwise a 400
status error code will be returned.
PATCH /instances/1234
{
"operation": "resize",
"options": {
"sizing": "2cpu4gb",
"changeReference": ""
}
}
Update Monitoring
Use the update_monitoring
operation to update the monitoring state of the instance.
Use the state
option to turn on/off monitoring.
Use the alerting
option to turn on/off alerting. When alerting is desactivated, no incident will be handled when the ressource is has alerts.
This method is asynchronous (status code 202
).
PATCH /instances/1234
{
"operation": "update_monitoring",
"options": {
"state": true,
"alerting": false
}
}
Update Patch Party Statuses
Use the operation update_patch_party
to manage the patch party settings of your instances.
2 options are available :
PATCH /instances/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": true,
"exclusionReason": "I want to handle this App. by myself"
}
}
}
There are 3 groups available defining the sequence on which the instance should be updated: 1 (First Group), 2 (Second Group) or 3 (Third Group).
If no group is set, it means that you have no preference while defining the sequences.
PATCH /instances/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": false,
"patchGroup": 3
}
}
}
Replication management
Use the operation update_storage_replication
to manage the replication settings of your instances.
2 options are available :
PATCH /instances/1234
{
"operation": "update_storage_replication",
"options": {
"state": false
}
}
PATCH /instances/1234
{
"operation": "update_storage_replication",
"options": {
"state": true
}
}
PATCH /instances/1234
{
"operation": "update_storage_replication",
"options": {
"state": true,
"deactivationReason": "I want it ..."
}
}
Instance Backup Management
Use the update_backup
operation to enable/disable instance backup.
Requirements to update manage backup are :
2 options are available:
PATCH /instances/1234
{
"operation": "update_backup",
"options": {
"state": true
}
}
PATCH /instances/1234
{
"operation": "update_backup",
"options": {
"state": false,
"deactivationReason": "Because.."
}
}
id, example: 123
Service Id, example: 44411
Update Patch party configuration for resources of a service
Tags allows you to qualify your resources with a custom set of key-value pairs. Tags will be accessible using ITCare search.
123
Simple key/value object to put on resources (services, instances, loadbalancers) to be able to search across resources easily, and to benefit dynamic resource groups.
Key of tag
Value of tag
Tags allows you to qualify your resources with a custom set of key-value pairs. Tags will be accessible using ITCare search.
123
Simple key/value object to put on resources (services, instances, loadbalancers) to be able to search across resources easily, and to benefit dynamic resource groups.
Key of tag
Value of tag
Tags allows you to qualify your resources with a custom set of key-value pairs. Tags will be accessible using ITCare search.
123
Simple key/value object to put on resources (services, instances, loadbalancers) to be able to search across resources easily, and to benefit dynamic resource groups.
Key of tag
Value of tag
No Content
This method allows to create a redis instance.
You will have to know at the minimum :
area
attribute). Areas can be available in List Regions method.name
attribute). The name can contain any lowercase characters or numbers (5-60). It must not be the keyword 'cluster'.nodeSizing
attribute). Ex: 2cpu2gbdiskSize
attribute). The possible values are at least 40 and maximum 1024 (representing GB).admPassword
attribute). The password must be At least one lowercase, one uppercase, one digit, one special character, minimum length must be 12.redisVersion
attribute). Example: 6.2.5serviceId
attribute).networkId
attribute).instanceCount
attribute). Minimum 1 and maximum 3persistenceMode
attribute).optional fields:
az
attribute).This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
POST /redis
{
"redisVersion": "6.2.5",
"region" : "EB",
"area": "EB-QA",
"az": "az",
"name": "Test123",
"nodeSizing": "2cpu2gb",
"diskSize": 40,
"networkId": 1234511,
"serviceId": 46922,
"admPassword": "Test123@2022",
"instanceCount": 1,
"persistenceMode" : "PERSISTENT"
}
The admin password
^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#&()–{}:;',?/*~$^+=<>]).{12,20}$
Area. Refer to an Area of a Region, that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Availability zone of the maria DB
Indicates if backup has to be setup on instance. If absent, backup will be setup automatically if instance is in a production service.
BackupPolicy id. Refers to desired backup policy to be applied for the database, must be set when backup is enabled.
The storage needed on each data node of the maria DB
Number of instances to create for mariadb
Indicates if alerting should be activated. If absent, set to false.
Indicates if monitoring will be setup. If absent, it will be automatically be setup if this is an production environment, or if backup is enabled.
Name of Redis DB
The network Id of the ELS cluster
Indicates why a production resource is not under backup.
Indicates why a production resource is not under monitoring.
Indicates why a production resource is not replicated.
Node sizing for cluster
Indicates if on call teams will be called on non business hours if an incident occurs on instance. If absent, set to false.
Product platform of the cluster
Region. that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Regulation. Refer to the regulation of the Area (HDS|STANDARD). If absent, default 'STANDARD' will be used.
Indicates if replication will be setup. If absent, it will be automatically be setup if this is an production environment
BackupPolicy id. Refers to desired backup policy to be applied for the virtual machine, must be set when backup is enabled.
id of service to put instance in.
Prefix of the virtual machine names for Redis DB
This method allows to update a Redis instance.
Structure of payload is generic and describes :
operation
you want to be performedoptions
data relative to the operation performed - see details - optional.Below are different operations currently implemented.
Start Redis instance
Use the start
operation to start a Redis instance.
Starts kafka instance.
This method is synchronous (status code 202
).
Example :
PATCH /redis/1234
{
"operation": "start"
}
Stop Redis instance
Use the stop
operation to stop the nodes of the Redis instance and the instance itself.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /redis/1234
{
"operation":"stop"
}
Resize Redis instance
Use the resize
operation to resize the nodes of the Redis instance and the instance itself.
This operation cannot be undone afterwards.
This method is asynchronous (status code 202
).
PATCH /redis/1234
{
"operation":"resize",
"options": {
"sizing": "2cpu4gb"
}
}
Update Monitoring
Use the update_monitoring
operation to update the monitoring state of the cluster.
Use the state
option to turn on/off monitoring.
Use the on_call
option to turn on/off 24/7 monitoring.
This method is synchronous (status code 202
).
PATCH /redis/1234
{
"operation": "update_monitoring",
"options": {
"state": true,
"on_call": true
}
}
Update Patch Party
Use the update_patch_party
operation to update the patch party scheduled plan of the cluster.
excluded
option to turn on/off patch party.patchGroup
option to select the patching group, the patchGroup
is optional, and is only allowed when the farm has one member.exclusionReason
option to explain the reason of excluding the resource from patch part.This method is synchronous (status code 202
).
PATCH /redis/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": false,
"patchGroup": "3"
}
}
}
PATCH /redis/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": true,
"exclusionReason": "I want to handle this by myself"
}
}
}
id, example: 123
This method allows to create a Maria DB instance.
You will have to know at the minimum :
area
attribute). Areas can be available in List Regions method.name
attribute). The name can contain any lowercase characters or numbers (5-60). It must not be the keyword 'cluster'.nodeSizing
attribute). Ex: 2cpu2gbdiskSize
attribute). The possible values are at least 40 and maximum 1024 (representing GB).admPassword
attribute). The password must be At least one lowercase, one uppercase, one digit, one special character, minimum length must be 12.Maria DBVersion
attribute). Example: 13serviceId
attribute).networkId
attribute).instanceCount
attribute). Minimum 1 and maximum 3topology
attribute). Either single or clusteroptional fields:
az
attribute).tlsEnabled
attribute).This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
POST /mariadb
{
"version": "10.6",
"region" : "EB",
"area": "EB-QA",
"az": "az",
"name": "Test123",
"nodeSizing": "2cpu2gb",
"diskSize": 40,
"networkId": 1234511,
"serviceId": 46922,
"admPassword": "Test123@2022",
"instanceCount": 1,
"topology" : "SINGLE"
}
The admin password
^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#&()–{}:;',?/*~$^+=<>]).{12,20}$
Area. Refer to an Area of a Region, that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Availability zone of the maria DB
Indicates if backup has to be setup on instance. If absent, backup will be setup automatically if instance is in a production service.
BackupPolicy id. Refers to desired backup policy to be applied for the database, must be set when backup is enabled.
The storage needed on each data node of the maria DB
Number of instances to create for mariadb
Indicates if alerting should be activated. If absent, set to false.
Indicates if monitoring will be setup. If absent, it will be automatically be setup if this is an production environment, or if backup is enabled.
Name of maria DB
[a-z0-9\-]{4,60}$
The network Id of the ELS cluster
Indicates why a production resource is not under backup.
Indicates why a production resource is not under monitoring.
Indicates why a production resource is not replicated.
Node sizing for cluster
Indicates if on call teams will be called on non business hours if an incident occurs on instance. If absent, set to false.
Product platform of the cluster
Region. that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Regulation. Refer to the regulation of the Area (HDS|STANDARD). If absent, default 'STANDARD' will be used.
Indicates if replication will be setup. If absent, it will be automatically be setup if this is an production environment
BackupPolicy id. Refers to desired backup policy to be applied for the virtual machine, must be set when backup is enabled.
id of service to put instance in.
Version of maria DB cluster
This method allows to update a MariaDB instance.
Structure of payload is generic and describes :
operation
you want to be performedoptions
data relative to the operation performed - see details - optional.Below are different operations currently implemented.
Start MariaDB instance
Use the start
operation to start a MariaDB instance.
Starts kafka instance.
This method is synchronous (status code 202
).
Example :
PATCH /mariadb/1234
{
"operation": "start"
}
Stop MariaDB instance
Use the stop
operation to stop the nodes of the MariaDB instance and the instance itself.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /compute/databases/mariadb/1234
{
"operation":"stop"
}
Resize MariaDB instance
Use the resize
operation to resize the sizing of the MariaDB instance.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /compute/databases/mariadb/1234
{
"operation":"resize",
"options" : {
"sizing" : "2cpu4gb"
}
}
Update Monitoring
Use the update_monitoring
operation to update the monitoring state of the MariaDB instance.
Use the state
option to turn on/off monitoring.
Use the on_call
option to turn on/off 24/7 monitoring.
This method is synchronous (status code 202
).
PATCH /mariadb/1234
{
"operation": "update_monitoring",
"options": {
"state": true,
"on_call": true
}
}
Update Patch Party
Use the update_patch_party
operation to update the patch party scheduled plan for the MariaDB instance.
excluded
option to turn on/off patch party.patchGroup
option to select the patching group, the patchGroup
is optional, and is only allowed when the farm has one member.exclusionReason
option to explain the reason of excluding the resource from patch part.This method is synchronous (status code 202
).
PATCH /mariadb/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": false,
"patchGroup": "3"
}
}
}
PATCH /mariadb/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": true,
"exclusionReason": "I want to handle this by myself"
}
}
}
Id, example: 123
This method allows to create an OpenSearch instance.
You will have to know at the minimum :
area
attribute). Areas can be available in List Regions method.name
attribute). The name can contain any lowercase characters or numbers (5-60). It must not be the keyword 'cluster'.nodeSizing
attribute). Ex: 2cpu4gbdiskSize
attribute). The possible values are at least 40 and maximum 1024 (representing GB).admPassword
attribute). The password must be At least one lowercase, one uppercase, one digit, one special character, minimum length must be 12.clusterVersion
attribute). Example: 1.2.3serviceId
attribute).networkId
attribute).instanceCount
attribute). Must be odd and at least be 3, recommended is 5, Maximum is 51nodePrefix
attribute). 4 to 60 uppercase charactersThis method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
POST /opensearch
{
"clusterVersion": "1.2.3",
"region" : "EB",
"area": "EB-QA",
"az": "az",
"name": "Test123",
"nodeSizing": "2cpu4gb",
"diskSize": 40,
"networkId": 1234511,
"serviceId": 46922,
"admPassword": "Test123@2022",
"instanceCount": "3",
"nodePrefix" : "OPESTC"
}
The admin password
^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#&()–{}:;',?/*~$^+=<>]).{12,20}$
Area. Refer to an Area of a Region, that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Indicates if backup has to be setup on instance. If absent, backup will be setup automatically if instance is in a production service.
BackupPolicy id. Refers to desired backup policy to be applied for the database, must be set when backup is enabled.
The storage needed on each data node of the ELS cluster
Number of instances to create in ELS cluster
[13579]$
Indicates if alerting should be activated. If absent, set to false.
Indicates if monitoring will be setup. If absent, it will be automatically be setup if this is an production environment, or if backup is enabled.
Name of els cluster
[a-z0-9_\-]{4,60}$
The network Id of the ELS cluster
Indicates why a production resource is not under backup.
Indicates why a production resource is not under monitoring.
Indicates why a production resource is not replicated.
Prefix of the node names for els cluster
[A-Z0-9-.]{4,60}$
Node sizing for cluster
Indicates if on call teams will be called on non business hours if an incident occurs on instance. If absent, set to false.
Product platform of the cluster
Region. that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Regulation. Refer to the regulation of the Area (HDS|STANDARD). If absent, default 'STANDARD' will be used.
Indicates if replication will be setup. If absent, it will be automatically be setup if this is an production environment
BackupPolicy id. Refers to desired backup policy to be applied for the virtual machine, must be set when backup is enabled.
id of service to put instance in.
This method allows to update an OpenSearch instance.
Structure of payload is generic and describes :
operation
you want to be performedoptions
data relative to the operation performed - see details - optional.Below are different operations currently implemented.
Start OpenSearch instance
Use the start
operation to start an OpenSearch instance.
Starts OpenSearch instance.
This method is synchronous (status code 202
).
Example :
PATCH /opensearch/1234
{
"operation": "start"
}
Stop OpenSearch instance
Use the stop
operation to stop the nodes of the OpenSearch instance and the instance itself.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /opensearch/1234
{
"operation":"stop"
}
Add nodes the OpenSearch instance
Use the add_nodes
operation to add nodes to the OpenSearch instance.
nodesCount
must be even
This method is synchronous (status code 202
).
PATCH /opensearch/1234
{
"operation":"add_nodes",
"options" : {
"diskSize" : 10,
"nodeSize" : "2cpu4gb",
"nodesCount": 2
}
}
Resize OpenSearch instance
Use the resize_nodes
operation to resize the sizing of the OpenSearch nodes.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /opensearch/1234
{
"operation":"resize_nodes",
"options" : {
"nodeSize" : "2cpu4gb",
"nodes" : ["node1"]
}
}
Update Monitoring
Use the update_monitoring
operation to update the monitoring state of the cluster.
Use the state
option to turn on/off monitoring.
Use the on_call
option to turn on/off 24/7 monitoring.
This method is synchronous (status code 202
).
PATCH /opensearch/1234
{
"operation": "update_monitoring",
"options": {
"state": true,
"on_call": true
}
}
Update Patch Party
Use the update_patch_party
operation to update the patch party scheduled plan of the OpenSearch instance.
excluded
option to turn on/off patch party.patchGroup
option to select the patching group, the patchGroup
is optional, and is only allowed when the farm has one member.exclusionReason
option to explain the reason of excluding the resource from patch part.This method is synchronous (status code 202
).
PATCH /opensearch/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": false,
"patchGroup": "3"
}
}
}
PATCH /opensearch/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": true,
"exclusionReason": "I want to handle this by myself"
}
}
}
id, example: 123
This method allows to create a postgre SQL instance.
You will have to know at the minimum :
area
attribute). Areas can be available in List Regions method.name
attribute). The name can contain any lowercase characters or numbers (5-60). It must not be the keyword 'cluster'.nodeSizing
attribute). Ex: 2cpu2gbdiskSize
attribute). The possible values are at least 40 and maximum 1024 (representing GB).admPassword
attribute). The password must be At least one lowercase, one uppercase, one digit, one special character, minimum length must be 12.postgreVersion
attribute). Example: 13serviceId
attribute).networkId
attribute).topology
attribute). Either standalone / HAtrigram
attribute).allowedReplicationLag
attribute). The minimum size is 1 MB and maximum is 10240 MBHA topology extra fields: These fields are required for HA clusters:
nodePrefix
attribute). The prefix should be from 5 to 12 characters and can contain any uppercase character.az
attribute).trigram
attribute).tls
attribute).This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
POST /postgresql
{
"serviceId" : 123,
"nodeSizing" : "2cpu4gb",
"networkId" : 132,
"area" : "EB-QA",
"diskSize" : 40,
"admPassword" : "Test123@2022",
"postgreVersion" : "13",
"allowedReplicationLag" : 10,
"az" : "az",
"topology" : "STANDALONE",
"trigram" : "tri",
"tls" : true,
"name" : "NEWPOSTGRE01"
}
This method allows to update a PostgreSQL instance.
Structure of payload is generic and describes :
operation
you want to be performedoptions
data relative to the operation performed - see details - optional.Below are different operations currently implemented.
Start PostgreSQL instance
Use the start
operation to start a PostgreSQL instance.
Starts PostgreSQL instance.
This method is asynchronous (status code 202
).
Example :
PATCH /postgresql/1234
{
"operation": "start"
}
Stop PostgreSQL instance
Use the stop
operation to stop the nodes of the PostgreSQL instance and the instance itself.
This operation cannot be undone afterwards.
This method is asynchronous (status code 202
).
PATCH /postgresql/1234
{
"operation":"stop"
}
Resize PostgreSQL instance
Use the resize
operation to resize the nodes of the PostgreSQL instance and the instance itself.
This operation cannot be undone afterwards.
This method is asynchronous (status code 202
).
PATCH /postgresql/1234
{
"operation":"resize",
"options": {
"sizing": "2cpu4gb"
}
}
Restore PostgreSQL instance
Use the restore
operation to restore a PostgreSQL instance to another PostgreSQL instance with the same farm version.
The available stop
options are BEFORE
and AFTER
.
This method is asynchronous (status code 202
).
PATCH /postgresql/5678
{
"operation": "restore",
"options": {
"sourceId": 1234,
"stop": "BEFORE",
"timestamp": "2022-11-02T09:32:02.000+00:00"
}
}
Convert from Standalone to HA PostgreSQL instance
Use the enable_ha
operation to convert a PostgreSQL instance from Standalone to HA mode.
This method is asynchronous (status code 202
).
PATCH /postgresql/5678
{
"operation": "enable_ha",
"options": {
"replicationLag": 50,
"changeReference": "000"
}
}
Update Monitoring
Use the update_monitoring
operation to update the monitoring state of the cluster.
Use the state
option to turn on/off monitoring.
Use the on_call
option to turn on/off 24/7 monitoring.
This method is asynchronous (status code 202
).
PATCH /postgresql/1234
{
"operation": "update_monitoring",
"options": {
"state": true,
"on_call": true
}
}
Update Patch Party
Use the update_patch_party
operation to update the patch party scheduled plan of the cluster.
excluded
option to turn on/off patch party.patchGroup
option to select the patching group, the patchGroup
is optional, and is only allowed when the farm has one member.exclusionReason
option to explain the reason of excluding the resource from patch part.This method is synchronous (status code 202
).
PATCH /postgresql/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": false,
"patchGroup": "3"
}
}
}
PATCH /postgresql/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": true,
"exclusionReason": "I want to handle this by myself"
}
}
}
Install PostgreSQL extension
Use the install_extension
operation to install an extension in the PostgreSQL.
This method is asynchronous (status code 202
).
PATCH /postgresql/1234
{
"operation":"install_extension",
"options": {
"dbname": "mydb",
"extensions_list": [
{"name": "ext1"},
{"name": "ext2"}
]
}
}
Upgrade PostgreSQL version
Use the upgrade
operation to upgrade the PostgreSQL version.
This method is asynchronous (status code 202
).
PATCH /postgresql/1234
{
"operation":"upgrade",
"options": {
"targetVersion": "12",
"changeReference": "RFC 1234"
}
}
id, example: 123
This method allows to create a SQL Server 2022 platform.
You will have to know at the minimum :
name
attribute). The name can contain any lowercase characters or numbers (5-60). It must not be the keyword 'cluster'.volumes
attribute). Initially, 5 disks are allocated and you can create one more. The first disk with id disk0
represents the "C: System", its maximum possible value is 70 and minimum is 1 (representing GB). disk1
represents "D: Root Instance", disk2
represents "E: User Databases", disk 3
represents "F: User Log" and disk4
represents "G: TempDB". The maximum possible value for these disks is 4096 and the minimum is 10 (representing GB).customerPassword
attribute). The password must be At least one lowercase, one uppercase, one digit, one special character, minimum length must be 8.serviceId
attribute).networkId
attribute).area
attribute).collation
attribute).edition
attribute) whether it's "STD" or "ENT"This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
optional fields:
az
attribute) default az of area will be used if not providedauthenticationDomainId
attribute)alwaysOn
attribute) default is falsessis
attribute) default is falsessrs
attribute) default is falsessas
attribute) default is falseasServerModeStd
attribute) which will be considered only if ssas
is true
asCollation
attribute) which will be considered only if ssas
is true
fullText
attribute) default is falseavailabilityMode
attribute)failoverMode
attribute)readableSecondary
attribute)witness
attribute)listenerName
attribute)POST /sqlserver
{
"name":"RSQL22",
"nodeSizing":"2cpu8gb",
"volumes":[
{
"id":"disk3",
"sizeGb":10
},
{
"id":"disk4",
"sizeGb":10
},
{
"id":"disk2",
"sizeGb":30
},
{
"id":"disk1",
"sizeGb":30
},
{
"id":"disk0",
"sizeGb":70
}
],
"area":"EB-QA",
"customerPassword":"P@ssw0rd",
"collation":"French_BIN",
"edition":"STD",
"serviceId":2423,
"networkId":5000802
}
Cluster/Basic Always On, example: true
Area. Refer to an Area of a Region, that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Collation for Analysis Services
Modelisation type
Modelisation type, example: TABULAR
authentication domain id, example: CGDM-EMEA
Cluster availability mode, example: Synchronous_commit
Availability zone of SQL Server
Indicates if backup has to be setup on instance. If absent, backup will be setup automatically if instance is in a production service.
Database Collation, example: French_BIN
Customer Password
BackupPolicy id. Refers to desired backup policy to be applied for the database, must be set when backup is enabled.
SQL Server edition, example: ENT
Cluster failover mode, example: Read-intent_only
Whether Full-Text search is enabled or not
Cluster listener name, example: rhusqllsnr01
Indicates if alerting should be activated. If absent, set to false.
Indicates if monitoring will be setup. If absent, it will be automatically be setup if this is an production environment, or if backup is enabled.
Name of SQL Server
The network Id of the ELS cluster
Indicates why a production resource is not under backup.
Indicates why a production resource is not under monitoring.
Indicates why a production resource is not replicated.
cluster nodes number, example: 3
Node sizing for cluster
Indicates if on call teams will be called on non business hours if an incident occurs on instance. If absent, set to false.
Product platform of the cluster
Prefix name of SQL Server
Cluster readable secondary, example: YES, NO, READ_ONLY
Region. that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Regulation. Refer to the regulation of the Area (HDS|STANDARD). If absent, default 'STANDARD' will be used.
Indicates if replication will be setup. If absent, it will be automatically be setup if this is an production environment
BackupPolicy id. Refers to desired backup policy to be applied for the virtual machine, must be set when backup is enabled.
id of service to put instance in.
specific request to be done by an administrator. Can differ delivery of instance up to 24h., example: Could you please install .NET framework 4.5 on instance ? Thanks.
SQL Server Analysis Services (SSAS)
SQL Server Integration Services (SSIS)
SQL Server Reporting Services (SSRS)
Volumes to setup on instance. If absent, will be set to defaults.
This method allows to delete a SQL Server instance.
This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
DELETE /compute/databases/sqlserver/1234
DELETE /compute/databases/sqlserver/1234
{
"changeReference": "56789"
}
id, example: 123
Parameters when deleting a resource
Optional reference for change
This method allows to update a SQL Server Farm.
Structure of payload is generic and describes :
operation
you want to be performedoptions
data relative to the operation performed - see details - optional.Below are different operations currently implemented.
Start SQL Server Farm
Use the start
operation to start the SQL Server Farm.
This method is synchronous (status code 202
).
Example :
PATCH /compute/databases/sqlserver/1234
{
"operation": "start"
}
Stop SQL Server Farm
Use the stop
operation to stop the SQL Server Farm.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /compute/databases/sqlserver/1234
{
"operation": "stop"
}
PATCH /compute/databases/sqlserver/1234
{
"operation": "stop",
"options": {
"changeReference": "56789"
}
}
Reset SQLServer Farm
Use the reset
operation to reset the SQL Server Farm.
This method is synchronous (status code 202
).
Example :
PATCH /compute/databases/sqlserver/1234
{
"operation": "reset"
}
Resize SQLServer instance
Use the resize
operation to resize the nodes of the SQLServer instance and the instance itself.
This operation cannot be undone afterwards.
This method is asynchronous (status code 202
).
PATCH /compute/databases/sqlserver/1234
{
"operation":"resize",
"options": {
"sizing": "2cpu4gb"
}
}
Update Monitoring
Use the update_monitoring
operation to update the monitoring state of the SQL Server.
Use the state
option to turn on/off monitoring.
Use the on_call
option to turn on/off 24/7 monitoring.
This method is synchronous (status code 202
).
PATCH /compute/databases/sqlserver/1234
{
"operation": "update_monitoring",
"options": {
"state": true,
"on_call": true
}
}
Update Patch Party
Use the update_patch_party
operation to update the patch party scheduled plan of the SQLServer.
excluded
option to turn on/off patch party.patchGroup
option to select the patching group, the patchGroup
is optional, and is only allowed when the farm has one member.exclusionReason
option to explain the reason of excluding the resource from patch part.This method is synchronous (status code 202
).
PATCH /compute/databases/sqlserver/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": false,
"patchGroup": "3"
}
}
}
PATCH /compute/databases/sqlserver/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": true,
"exclusionReason": "I want to handle this by myself"
}
}
}
id, example: 123
Object describing a partial modification of an object to perform. Please refer to documentation to get list of operations available and their specific payload.
Operation to perform on target object, example: operation_name
Specific payload to pass to have the operation performed. Refer to documentation for each operation.
This method allows to create an Apache Kafka platform.
You will have to know at the minimum :
area
attribute). Areas can be available in List Regions method.name
attribute). The name can contain any lowercase characters or numbers (5-60). It must not be the keyword 'cluster'.nodePrefix
attribute). The prefix should be from 5 to 12 characters and can contain any uppercase character.brokerCount
attribute). The possible values are at least 3 and maximum 5.diskSize
attribute). The possible values are at least 40 and maximum 1024 (representing GB).admPassword
attribute). The password must be At least one lowercase, one uppercase, one digit, one special character, minimum length must be 12.kafkaVersion
attribute). Example: 2.7.0serviceId
attribute).networkId
attribute).This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
POST /message-brokers/apache-kafka
{
"kafkaVersion": "2.7.0",
"area": "EB-QA",
"name": "testkafka",
"nodePrefix": "DM123",
"nodeSizing": "2cpu4gb",
"brokerCount": 3,
"diskSize": 40,
"networkId": 1234511,
"serviceId": 46922,
"admPassword": "Test123@2022"
}
The admin password
^(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#&()–{}:;',?/*~$^+=<>]).{12,20}$
Area. Refer to an Area of a Region, that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Indicates if backup has to be setup on instance. If absent, backup will be setup automatically if instance is in a production service.
Number of brokers to create in Kafka cluster
BackupPolicy id. Refers to desired backup policy to be applied for the database, must be set when backup is enabled.
The storage needed on each data node of the ELS cluster
Indicates if alerting should be activated. If absent, set to false.
Indicates if monitoring will be setup. If absent, it will be automatically be setup if this is an production environment, or if backup is enabled.
Name of Kafka cluster
(?!cluster$)([a-z0-9_]{5,60})$
The network Id of the ELS cluster
Indicates why a production resource is not under backup.
Indicates why a production resource is not under monitoring.
Indicates why a production resource is not replicated.
Prefix of the node names for Kafka cluster
[A-Z0-9]{5,12}$
Node sizing for cluster
Indicates if on call teams will be called on non business hours if an incident occurs on instance. If absent, set to false.
Product platform of the cluster
Region. that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Regulation. Refer to the regulation of the Area (HDS|STANDARD). If absent, default 'STANDARD' will be used.
Indicates if replication will be setup. If absent, it will be automatically be setup if this is an production environment
BackupPolicy id. Refers to desired backup policy to be applied for the virtual machine, must be set when backup is enabled.
id of service to put instance in.
This method allows to update an Apache Kafka platform.
Structure of payload is generic and describes :
operation
you want to be performedoptions
data relative to the operation performed - see details - optional.Below are different operations currently implemented.
Start Apache Kafka instance
Use the start
operation to start an Apache Kafka instance.
Starts Apache Kafka instance.
This method is synchronous (status code 202
).
Example :
PATCH /message-brokers/apache-kafka/1234
{
"operation": "start"
}
Stop Apache Kafka instance
Use the stop
operation to stop the nodes of the Apache Kafka instance and the instance itself.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /message-brokers/apache-kafka/1234
{
"operation":"stop"
}
Resize Apache Kafka instance
Use the resize
operation to resize the sizing of the Apache Kafka instance.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /message-brokers/apache-kafka/1234
{
"operation":"resize",
"options" : {
"sizing" : "2cpu4gb"
}
}
Reconfigure Apache Kafka instance
Use the reconfigure
operation to update the Apache Kafka instance params.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /message-brokers/apache-kafka/1234
{
"operation":"reconfigure",
"options" : {
"param" : "param"
}
}
Update Monitoring
Use the update_monitoring
operation to update the monitoring state of the Apache Kafka instance.
Use the state
option to turn on/off monitoring.
Use the on_call
option to turn on/off 24/7 monitoring.
This method is synchronous (status code 202
).
PATCH /message-brokers/apache-kafka/1234
{
"operation": "update_monitoring",
"options": {
"state": true,
"on_call": true
}
}
Update Patch Party
Use the update_patch_party
operation to update the patch party scheduled plan of the Apache Kafka instance.
excluded
option to turn on/off patch party.patchGroup
option to select the patching group, the patchGroup
is optional, and is only allowed when the farm has one member.exclusionReason
option to explain the reason of excluding the resource from patch part.This method is synchronous (status code 202
).
PATCH /message-brokers/apache-kafka/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": false,
"patchGroup": "3"
}
}
}
PATCH /message-brokers/apache-kafka/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": true,
"exclusionReason": "I want to handle this by myself"
}
}
}
id, example: 123
This method allows to create a RabbitMQ instance.
You will have to know at the minimum :
area
attribute). Areas can be available in List Regions method.name
attribute).vmPrefix
attribute).brokerCount
attribute). The possible values are at least 1 or 3 and maximum 5.diskSize
attribute). The possible values are at least 10 and maximum 2048 (representing GB).admPassword
attribute). The password must be At least one lowercase, one uppercase, one digit, one special character, minimum length must be 12.rabbitMqVersion
attribute). Example: 3.8.9serviceId
attribute).networkId
attribute).Optional parameters that might be helpful:
vmPrefix
attribute).az
attribute).This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
POST /message-brokers/rabbitmq
{
"rabbitMqVersion": "3.8.9",
"area": "EB-QA",
"name": "Test123",
"nodeSizing": "2cpu4gb",
"brokerCount": 3,
"diskSize": 40,
"networkId": 1234511,
"serviceId": 46922,
"admPassword": "Test123@2022",
"vmPrefix" : "AAAAAA"
}
The admin password
^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#&()–{}:;',?/*~$^+=<>]).{12,20}$
Area. Refer to an Area of a Region, that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Availability zone of the RabbitMQ Broker
Indicates if backup has to be setup on instance. If absent, backup will be setup automatically if instance is in a production service.
Number of brokers to create in RabbitMQ Broker
BackupPolicy id. Refers to desired backup policy to be applied for the database, must be set when backup is enabled.
The storage needed on each data node of the RabbitMQ Broker
Indicates if alerting should be activated. If absent, set to false.
Indicates if monitoring will be setup. If absent, it will be automatically be setup if this is an production environment, or if backup is enabled.
Name of RabbitMQ Broker
The network Id of the ELS cluster
Indicates why a production resource is not under backup.
Indicates why a production resource is not under monitoring.
Indicates why a production resource is not replicated.
Node sizing for cluster
Indicates if on call teams will be called on non business hours if an incident occurs on instance. If absent, set to false.
Product platform of the cluster
Region. that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Regulation. Refer to the regulation of the Area (HDS|STANDARD). If absent, default 'STANDARD' will be used.
Indicates if replication will be setup. If absent, it will be automatically be setup if this is an production environment
BackupPolicy id. Refers to desired backup policy to be applied for the virtual machine, must be set when backup is enabled.
id of service to put instance in.
Prefix of the virtual machine names for RabbitMQ Broker (Clusters)
This method allows to update a RabbitMQ instance.
Structure of payload is generic and describes :
operation
you want to be performedoptions
data relative to the operation performed - see details - optional.Below are different operations currently implemented.
Start RabbitMQ instance
Use the start
operation to start a RabbitMQ instance.
Starts RabbitMQ instance.
This method is synchronous (status code 202
).
Example :
PATCH /message-brokers/rabbitmq/1234
{
"operation": "start"
}
Stop RabbitMQ instance
Use the stop
operation to stop the nodes of the RabbitMQ instance and the instance itself.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /message-brokers/rabbitmq/1234
{
"operation":"stop"
}
Resize RabbitMQ instance
Use the resize
operation to resize the sizing of the RabbitMQ.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /message-brokers/rabbitmq/1234
{
"operation":"resize",
"options" : {
"sizing" : "2cpu4gb"
}
}
Update Monitoring
Use the update_monitoring
operation to update the monitoring state of the cluster.
Use the state
option to turn on/off monitoring.
Use the on_call
option to turn on/off 24/7 monitoring.
This method is synchronous (status code 202
).
PATCH /message-brokers/rabbitmq/1234
{
"operation": "update_monitoring",
"options": {
"state": true,
"on_call": true
}
}
Update Patch Party
Use the update_patch_party
operation to update the patch party scheduled plan of the broker.
excluded
option to turn on/off patch party.patchGroup
option to select the patching group, the patchGroup
is optional, and is only allowed when the farm has one member.exclusionReason
option to explain the reason of excluding the resource from patch part.This method is synchronous (status code 202
).
PATCH /message-brokers/rabbitmq/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": false,
"patchGroup": "3"
}
}
}
PATCH /message-brokers/rabbitmq/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": true,
"exclusionReason": "I want to handle this by myself"
}
}
}
id, example: 123
This method allows to create a LoadBalancer.
You will have to know at the minimum :
the area of the region where you want to host your cluster (area
attribute). Areas can be available in List Regions method.
url (url
attribute). The url you want to create and respect URLs naming convention.
network ID of the cluster (networkId
attribute).
On which service the LoadBalancer belongs to (serviceId
attribute).
On which domain the url should be belong to (domain
attribute).
Healthcheck to check that your url is responding (healthcheck
attribute).
Persistence configuration (persistence
attribute).
Port member : port on which the members of the loadbalancer should be listening to (portMembers
attribute). Example: 80
Profile Names (profileName
attribute). Ex : HTTP, HTTPS, TCP. For HTTP, profileName
= 80.
Redirection rules (redirectToHttps
attribute). Redirect to HTTPS or not.
Members (members
attribute). Members of the loadbalancer
optional fields:
region
attribute).setUpDNSEnabled
attribute). If True, the domain must support the DNS creation.
If the attribut is set to True and the domain do not support DNS setup, an error 400 will be raised.networkId
attribute). If not set, the system will choose the default network available on the Availability Zone.This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
POST /loadbalancers
{
"url": "url.cegedim.com",
"serviceId": 46922,
"area": "EB-QA",
"networkId": 4242,
"healthcheck":"CDGM",
"persistence": true,
"portMembers": 80,
"profileName": "HTTP",
"redirectToHttps":false,
"setUpDNSEnabled":false,
"members": [
{
"id": 42,
"network": {
"id": 42,
"ipAddress" : "1.2.3.4"
}
}
]
}
When the LoadBalancer supports SSL
POST /loadbalancers
{
"url": "url.cegedim.com",
"serviceId": 46922,
"area": "EB-QA",
"networkId": 4242,
"healthcheck":"CDGM",
"persistence": true,
"portMembers": 80,
"profileName": "HTTPS",
"redirectToHttps":true,
"setUpDNSEnabled":false,
"sslProfile":"my_ssl_profle",
"certificateName":"my_cert.crt",
"members": [
{
"id": 42,
"network": {
"id": 42,
"ip" : "1.2.3.4"
}
}
]
}
Describes a load balancer.
Area. Refer to an Area of a Region, that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Indicates if backup has to be setup on instance. If absent, backup will be setup automatically if instance is in a production service.
certificate of the load balancer., example: wildcard_cegedim.com
BackupPolicy id. Refers to desired backup policy to be applied for the database, must be set when backup is enabled.
healtcheck of load balancer., example: http
Members of pool to setup on load balancer.
Indicates if alerting should be activated. If absent, set to false.
Indicates if monitoring will be setup. If absent, it will be automatically be setup if this is an production environment, or if backup is enabled.
Network id. Refer to networks available in List Networks method. If absent, a default network of AZ will be used.
Indicates why a production resource is not under backup.
Indicates why a production resource is not under monitoring.
Indicates why a production resource is not replicated.
Indicates if on call teams will be called on non business hours if an incident occurs on instance. If absent, set to false.
port member of load balancer., example: 80, 443, ...
profile name of load balancer.
Region. that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Regulation. Refer to the regulation of the Area (HDS|STANDARD). If absent, default 'STANDARD' will be used.
Indicates if replication will be setup. If absent, it will be automatically be setup if this is an production environment
BackupPolicy id. Refers to desired backup policy to be applied for the virtual machine, must be set when backup is enabled.
id of service to put instance in.
Indicates if a DNS record is to be set. If absent, set to false.
ssl profile of the load balancer., example: profile_wildcard.cegedim.com_secure
url of load balancer. Must be unique, and fit naming rules convention., example: url.cegedim.com
^(https?:\\/\\/)?(www\\.)?[a-zA-Z][a-zA-Z0-9.-]{2,63}+$
port of load balancer in case of TCP VS Profile
This method allows to create a URL for a LoadBalancer.
name
is the name of the url.setUpDNSEnabled
setup dns or not.monitoringEnabled
enable monitoring for urlonCallSupervision
enable 24/7 monitoring for urlThis method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
POST /loadbalancers/124/urls
{
"name": "url.cegedim.com",
"setUpDNSEnabled": false,
"monitoringEnabled": true,
"onCallSupervision": true
}
Describes a load balancer.
Indicates if monitoring will be setup.
url of load balancer. Must be unique, and fit naming rules convention., example: url.cegedim.com
^(https?:\\/\\/)?(www\\.)?[a-zA-Z][a-zA-Z0-9.-]{2,63}+$
Indicates if on call teams will be called on non business hours if an incident occurs on instance. If absent, set to false.
Indicates if a DNS record is to be set. If absent, set to false.
ssl profile of the load balancer., example: profile_wildcard.cegedim.com_secure
Add a member to an existing loadbalancer.
The member must be a valid ITCare resource and must be in the same network as the other members of the loadbalancer.
Request example :
POST /compute/loadbalancers/my-service.cegedim.cloud/members
{
"resourceId": 5050706,
"port": 80,
"state": "enabled",
"name": "REBITCGDM1032",
"ip": "10.25.19.158"
}
Minimum payload must contain the following information :
Other field will be ignored. The following payload is valid:
POST /compute/loadbalancers/my-service.cegedim.cloud/members
{
"resourceId": 5050706,
"port": 80,
}
This method is synchronous (status code 200
) and will return loadbalancer's members list with the new member added :
[
{
"resourceId": 1050975,
"name": "PEB4APP01",
"port": 443,
"state": "enabled",
"status": "up",
"ip": "10.26.12.11"
},
{
"resourceId": 1050976,
"name": "PEB4APP02",
"port": 443,
"state": "enabled",
"status": "up",
"ip": "10.26.12.12"
},
{
"resourceId": 898734,
"name": "PEB4APP03",
"port": 443,
"state": "enabled",
"status": "up",
"ip": "10.26.12.13"
}
]
Note: New member will added with state enabled.
Note: Member statistic are not included in the response body
IP address of the member.
Category of the member
Family of the member
Internal type of the member of the member
Area on which the member is located
Name of the member on the loadbalancer
port of the member., example: 80, 443, ...
Name of the member of the member
Id of the resource. Required when an operation is performed.
serviceId on which this member belongs to
Member state. (enabled, disabled, offline)
Status of the member. (up, down, user_down)
Technical Network on which the member is located
Technology of the member
This method allows to update a load balancer.
Structure of payload is generic and describes :
operation
you want to be performedoptions
data relative to the operation performed - see details.Below are different operations currently implemented.
Start Load Balancer
Use the start
operation to start the load balancer.
This method is synchronous (status code 202
).
Example :
PATCH /loadbalancers/1234
{
"operation": "start",
"options": {
"changeReference": "5678"
}
}
Stop Load Balancer
Use the stop
operation to stop the load balancer.
This method is synchronous (status code 202
).
PATCH /loadbalancers/1234
{
"operation": "stop",
"options": {
"changeReference": "5678"
}
}
Create Bot Defense for Load Balancer
Use the activate_bot
operation to Update Security Profile for load balancer.
Use the template
with values strict
, standard
to set the template to be applied. Default template value is standard
.
Use the mode
with values transparent
, blocking
to set the mode to be applied. Mode is optional and default mode is blocking
.
This method is synchronous (status code 202
).
PATCH /loadbalancers/1234
{
"operation": "activate_bot",
"options": {
"changeReference": "5678",
"template": "strict",
"mode" : "blocking"
}
}
Update Bot Defense for Load Balancer
Use the update_bot
operation to Update Security Profile for load balancer.
Use the template
with values strict
, standard
to set the template to be applied. Default template value is standard
.
Use the mode
with values transparent
, blocking
to set the mode to be applied. Mode is optional and default mode is blocking
.
This method is synchronous (status code 202
).
PATCH /loadbalancers/1234
{
"operation": "update_bot",
"options": {
"changeReference": "5678",
"template": "strict",
"mode" : "blocking"
}
}
When the Security Profile is applied, Use the mode
with values transparent
, blocking
to set the mode to be applied. Mode is optional and default mode is blocking
.
In transparent
mode, requests considered to be malicious generate an alarm but are not blocked.
blocking
mode blocks the requests identified as malicious by Bot Defense
PATCH /loadbalancers/1234
{
"operation": "update_bot",
"options": {
"changeReference": "5678",
"mode" : "transparent"
}
}
Delete Bot Defense Security Profile from Load Balancer
When Security Profile is activated on a Load Balancer, the attribut botDefenseEnabled
on the PATCH /loadbalancers/1234
is true.
To remove the Bot Defense Security Profile from a Load Balancer, use :
Use the delete_bot
operation to remove Security Profile from the load balancer.
This method is synchronous (status code 202
).
PATCH /loadbalancers/1234
{
"operation": "delete_bot",
"options": {
"changeReference": "5678"
}
}
Update IP to whitelist for Load Balancer
Use the edit_bot_whitelist
operation to update/add IP to whitelist for load balancer.
This method is synchronous (status code 202
).
PATCH /loadbalancers/1234
{
"operation": "edit_bot_whitelist",
"options": {
"ip": "10.0.3.40",
"changeReference": "5678"
}
}
Remove IP Address from whitelist for Load Balancer
Use the delete_bot_whitelist
operation to remove IP from whitelist for load balancer.
This method is synchronous (status code 202
).
PATCH /loadbalancers/1234
{
"operation": "delete_bot_whitelist",
"options": {
"ip": "10.0.3.40",
"changeReference": "5678"
}
}
** changeReference
(optional) is the RFC Number if available.
Update Monitoring for Load Balancer and its URLs
Use the update_monitoring
operation to update monitoring status for load balancer.
This method is synchronous (status code 202
).
PATCH /loadbalancers/1234
{
"operation": "update_monitoring",
"options": {
"state": true,
"on_call": true
}
}
url1
and url4
form its list of URLs.PATCH /loadbalancers/1234
{
"operation": "update_monitoring",
"options": {
"state": true,
"on_call": true,
"updateUrls": [
"url1",
"url4"
]
}
}
Load Balancer Id, example: 123
Object describing a partial modification of an object to perform. Please refer to documentation to get list of operations available and their specific payload.
Operation to perform on target object, example: operation_name
Specific payload to pass to have the operation performed. Refer to documentation for each operation.
This method allows to update a url of load balancer.
Structure of payload is generic and describes :
operation
you want to be performedoptions
data relative to the operation performed - see details.Below are different operations currently implemented.
Update Monitoring for Load Balancer and its URLs
Use the update_monitoring
operation to update monitoring status for load balancer.
This method is synchronous (status code 202
).
PATCH /loadbalancers/1234/urls/5678
{
"operation": "update_monitoring",
"options": {
"state": true,
"onCall": true
}
}
Load Balancer Id, example: 123
Load Balancer Url Id, example: 123
Object describing a partial modification of an object to perform. Please refer to documentation to get list of operations available and their specific payload.
Operation to perform on target object, example: operation_name
Specific payload to pass to have the operation performed. Refer to documentation for each operation.
Set the state of a loadbalancer member.
The member must be a valid ITCare resource and must be a member of the specified loadbalancer.
Possible state value are :
Example :
PATCH /compute/loadbalancers/123/members/1050975
{
"operation": "disabled"
}
This method is synchronous (status code 200
) and will return loadbalancer's member object :
{
"resourceId": 1050975,
"name": PEB4APP01,
"port": 443,
"state": "disabled",
"status": "up",
"name": "PEB4APP01",
"address": "10.26.12.11"
}
This method allows to create an OverDrive instance.
You will have to know at the minimum :
region
attribute)name
attribute)sizing
attribute). The possible values are : XS (Up to 50 users total), S(Up to 1M ppm), M(Up to 10M ppm), L(Up to 100M ppm), XL(More than 100M ppm)password
attribute). The password must be At least one lowercase, one uppercase, one digit, one special character, minimum length must be 12.serviceId
attribute).driveSiteUri
).This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
POST /storage/overdrive
{
"name": "poverdrive01",
"region": "EB",
"sizing":"XS",
"serviceId":"123",
"password": "Password!!??",
"driveSiteUri": "demo.mydrive.cegedim.cloud"
}
Indicates if backup has to be setup on instance. If absent, backup will be setup automatically if instance is in a production service.
BackupPolicy id. Refers to desired backup policy to be applied for the database, must be set when backup is enabled.
Define the Drive URL to be configured in OverDrive
Indicates if alerting should be activated. If absent, set to false.
Indicates if monitoring will be setup. If absent, it will be automatically be setup if this is an production environment, or if backup is enabled.
Name of OverDrive Instance
[a-z0-9\-]{4,60}$
Indicates why a production resource is not under backup.
Indicates why a production resource is not under monitoring.
Indicates why a production resource is not replicated.
Indicates if on call teams will be called on non business hours if an incident occurs on instance. If absent, set to false.
Password to connect to the OverDrive instance.
Region. that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Regulation. Refer to the regulation of the Area (HDS|STANDARD). If absent, default 'STANDARD' will be used.
Indicates if replication will be setup. If absent, it will be automatically be setup if this is an production environment
BackupPolicy id. Refers to desired backup policy to be applied for the virtual machine, must be set when backup is enabled.
id of service to put instance in.
Sizing. L, XL , XS, S, M. Sizing for OverDrive instances
This method allows to update an Overdrive instance.
Structure of payload is generic and describes :
operation
you want to be performedoptions
data relative to the operation performed - see details - optional.Below are different operations currently implemented.
Start Overdrive instance
Use the start
operation to start an Overdrive instance.
Starts overdrive instance.
This method is synchronous (status code 202
).
Example :
PATCH /storage/overdrive/1234
{
"operation": "start"
}
Stop Overdrive instance
Use the stop
operation to stop the nodes of the Overdrive instance and the instance itself.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /storage/overdrive/1234
{
"operation":"stop"
}
id, example: 123
This method allows to create a GlusterFS cluster.
You will have to know at the minimum :
area
attribute). Areas can be available in List Regions method.name
attribute). The name can contain any lowercase characters, dashes and underscores.diskSize
attribute). The possible values are at least 10 and maximum 1024 (representing GB).admPassword
attribute). The password must be between 12 and 20 characters with at least one lowercase character, one uppercase character, one digit and one special characteruserName
attribute). Maximum size is 32 characters, lowercase characters, underscore and dashe are allowedserviceId
attribute).networkId
attribute).This method is asynchronous (status code 202
) and you'll have to wait for async action to be completed by checking its status.
POST /storage/glusterfs
{
"name": "mygluster01",
"diskSize": "15",
"admPassword": "mySuperPassword123!!",
"userName": "dda",
"networkId": 123,
"area":"EB-A",
"serviceId": 46922
}
The user password
^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#&()–{}:;',?/*~$^+=<>]).{12,20}$
Area. Refer to an Area of a Region, that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Indicates if backup has to be setup on instance. If absent, backup will be setup automatically if instance is in a production service.
BackupPolicy id. Refers to desired backup policy to be applied for the database, must be set when backup is enabled.
The volume configured within the configuration process of the GlusterFs cluster
Indicates if alerting should be activated. If absent, set to false.
Indicates if monitoring will be setup. If absent, it will be automatically be setup if this is an production environment, or if backup is enabled.
Name of GlusterFs cluster
[a-z0-9_\-]{5,60}$
The network Id of the ELS cluster
Indicates why a production resource is not under backup.
Indicates why a production resource is not under monitoring.
Indicates why a production resource is not replicated.
Node sizing for cluster
Indicates if on call teams will be called on non business hours if an incident occurs on instance. If absent, set to false.
Product platform of the cluster
Region. that is a low-latency network area, available in List Regions method. If absent, default Area of Region will be used.
Regulation. Refer to the regulation of the Area (HDS|STANDARD). If absent, default 'STANDARD' will be used.
Indicates if replication will be setup. If absent, it will be automatically be setup if this is an production environment
BackupPolicy id. Refers to desired backup policy to be applied for the virtual machine, must be set when backup is enabled.
id of service to put instance in.
[a-z0-9_\-]{1,32}$
This method allows to update a GlusterFS cluster.
Structure of payload is generic and describes :
operation
you want to be performedoptions
data relative to the operation performed - see details.Below are different operations currently implemented.
Start
Use the start
operation to start a GlusterFS cluster.
Create nodes operation will add the new nodes in the cluster by availability zone. You can specify the availability zone you need in the request.
This method is synchronous (status code 202
).
Example :
PATCH /storage/glusterfs/1234
{
"operation": "start",
"options": {
"changeReference": "RFC_123"
}
}
Stop
Use the stop
operation to stop a GlusterFS cluster.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /storage/glusterfs/1234
{
"operation": "start",
"options": {
"changeReference": "RFC_123"
}
}
Resize GlusterFS instance
Use the resize
operation to resize the nodes of the GlusterFS instance and the instance itself.
This operation cannot be undone afterwards.
This method is asynchronous (status code 202
).
PATCH /storage/glusterfs/1234
{
"operation":"resize",
"options": {
"sizing": "2cpu4gb"
}
}
Add Volume
Use the add_volume
operation to add a Volume to a GlusterFS cluster.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /storage/glusterfs/1234
{
"operation": "add_volume",
"options": {
"diskSize": "42",
"userName": "dda",
"userPass":"mySuperPassw0rd42"
}
}
Resize Volume
Use the resize_volume
operation to resize a Volume to a GlusterFS cluster.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /storage/glusterfs/1234
{
"operation": "resize_volume",
"options": {
"name":"dda",
"diskSize": "42",
"userName": "dda"
}
}
Resize Volume
Use the delete_volume
operation to delete a Volume from a GlusterFS cluster.
This operation cannot be undone afterwards.
This method is synchronous (status code 202
).
PATCH /storage/glusterfs/1234
{
"operation": "delete_volume",
"options": {
"name":"dda"
}
}
Update Monitoring
Use the update_monitoring
operation to update the monitoring state of the GlusterFS cluster.
Use the state
option to turn on/off monitoring.
Use the on_call
option to turn on/off 24/7 monitoring.
This method is synchronous (status code 202
).
PATCH /storage/glusterfs/1234
{
"operation": "update_monitoring",
"options": {
"state": true,
"on_call": true
}
}
Update Patch Party
Use the update_patch_party
operation to update the patch party scheduled plan of the GlusterFS cluster.
excluded
option to turn on/off patch party.patchGroup
option to select the patching group, the patchGroup
is optional, and is only allowed when the farm has one member.exclusionReason
option to explain the reason of excluding the resource from patch part.This method is synchronous (status code 202
).
PATCH /storage/glusterfs/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": false,
"patchGroup": "3"
}
}
}
PATCH /storage/glusterfs/1234
{
"operation": "update_patch_party",
"options": {
"patchParty": {
"excluded": true,
"exclusionReason": "I want to handle this by myself"
}
}
}
Event environments
ALL,NON_PROD,PROD
Event types
CUSTOMER,MAINTENANCE_SLOT
Maintenance types
SWITCH,NETWORK,PATCH_PARTY
Start Date (ISO8601 format)
2022-04-01T22:00:00.000Z
End Date (ISO8601 format)
2022-04-30T22:00:00.000Z