OpenStack · Canonical · Red Hat OSP · depuis 2008

OpenStack en production, sans insomnie.

Nous maintenons votre cloud OpenStack — Canonical, Red Hat OSP ou votre propre distribution. Nos propres ingénieurs en FR/ES/EN, avec ligne téléphonique directe et réponse dans votre fuseau horaire.

[ 01 ]Qui nous aidons

Trois clouds OpenStack, trois douleurs

Nous supportons des clouds installés par d'autres, ceux qui changent de distribution et ceux qui tournent depuis des années en pilote automatique. Vendor-neutral : nous ne cherchons pas à vous vendre un autre OpenStack, nous maintenons le vôtre.

Profil A

Charmed OpenStack de Canonical

Vous avez un contrat vendor et ça fonctionne, mais vous voulez un interlocuteur local qui parle votre langue, se trouve dans votre fuseau horaire et comprend MicroCloud, Juju et OVN sans longues chaînes d'escalade.

Ce que nous faisonsNous complétons votre contrat Canonical avec du support local en FR/ES/EN ou nous le remplaçons si vous préférez consolider vos fournisseurs.

Urgent 2029 Profil B

Red Hat OpenStack Platform (OSP 17.1)

Red Hat ferme le cycle traditionnel d'OSP en juin 2029. La suite, Red Hat OpenStack Services on OpenShift, change tout le modèle opérationnel. Quelqu'un doit trancher : rester, sauter vers RHOSO, ou changer de distribution.

Ce que nous faisonsNous auditons votre OSP, chiffrons les trois voies et vous accompagnons dans celle que vous choisirez.

Profil C

Cloud DIY, Kolla-Ansible ou distribution maison

Votre équipe ou un intégrateur précédent l'ont monté. Cela fonctionne, mais la documentation a pris du retard et les upgrades font peur. Vous ne voulez pas jeter le cloud ; vous voulez le stabiliser et le rendre à nouveau maintenable.

Ce que nous faisonsNous montons le runbook, colmatons les trous de sécurité, rendons les upgrades reproductibles et prenons l'astreinte en option.

[ 02 ]Forfaits de support

Du sauvetage ponctuel au 24×7 avec astreinte

Trois modèles qui couvrent 95 % des cas. Si votre cloud a des exigences de secteur régulé (banque, santé, défense), on en parle à part — ça ne tient pas dans trois cartes.

Modalité 01

Sauvetage

Quand ça brûle et qu'il n'y a pas de contrat en place. Intervention ponctuelle, sans engagement, pour stabiliser et laisser l'environnement documenté.

  • Diagnostic et stabilisation de l'incident
  • Rapport technique avec cause racine
  • Recommandations pour éviter la récidive
  • Sans engagement · facturé à l'intervention
Voir support d'urgence
Le plus souscrit

Modalité 02

Contrat continu

Ingénieur de référence, ticketing dédié et cycle régulier de patches et de revue. Le quotidien opérationnel, couvert en heures ouvrées.

  • Ingénieur de référence avec accès à votre environnement
  • Ticketing dédié avec SLA défini au contrat
  • Cycle régulier de patches et minor upgrades
  • Revue de capacité et de dette technique
  • Support L3 sur Nova, Neutron, Cinder, Keystone, Ceph
  • Runbook et documentation vivante de l'environnement
Demander une proposition

Modalité 03

Opérations 24×7

Tout ce du contrat continu, plus surveillance et astreinte réelle hors horaires, avec notre propre ingénieur au bout du fil.

  • Tout ce de la Modalité 02
  • Surveillance avec Prometheus, Grafana et alertmanager
  • Astreinte avec un ingénieur propre de SIXE
  • Couverture des incidents hors horaires
  • Post-mortem après incidents critiques
  • Formation périodique pour votre équipe
Discutons de votre cas

Chaque cloud a sa taille, sa distribution et ses fenêtres de maintenance. Avant de donner une fourchette nous voulons voir l'inventaire et en parler — nous ne vendons pas de packages fermés à l'aveugle.

[ 03 ]Ce que nous faisons, concrètement

Un lundi ordinaire avec votre OpenStack

Nous préférons montrer une journée de travail plutôt que trois promesses abstraites. Voilà ce qui se passe généralement lors de la première astreinte de la semaine chez un client en production.

08:45

Revue des alertes du week-end

Nous regardons Prometheus et RabbitMQ. Deux avis de latence sur neutron-server le samedi ; aucun critique. Nous notons la cause (un agent OVN déconnecté qui s'est auto-réparé) dans le runbook.

10:15

Patch de sécurité sur Keystone

Un CVE avec un score 7,5 sort sur keystoneauth. Backport disponible upstream, nous l'appliquons en préproduction, validons la fédération SAML du client et programmons une fenêtre en production pour le mardi soir.

12:00

Réunion trimestrielle avec le client

Revue de capacité : le pool de compute-05 est à 78 %. Nous proposons d'ajouter deux hyperviseurs avant la prochaine clôture. Revue des tenants : deux projets ont consommé le double de leur quota ce trimestre — il faut rééquilibrer.

15:30

Debug de placement

Un développeur se plaint que ses VMs avec GPU ne démarrent pas. Nous regardons placement, il manque des traits sur le nouveau nœud compute. Corrigé en 25 minutes, documenté dans le runbook pour la prochaine mise en service de matériel.

17:00

Passation à l'astreinte

Handoff avec l'ingénieur de l'après-midi. État de l'environnement, alertes mises en sourdine, fenêtre de mardi préparée. L'astreinte prend le relais avec le contexte complet — elle ne découvre pas votre cloud dans un ticket à 3 h du matin.

[ 04 ]Fin de cycle · Red Hat OSP

Si vous êtes sur Red Hat OSP, vous avez une décision à prendre

EOL · OSP 17.1

JUIN 2029

Extended Life-cycle Support

~46 mois

Trois voies sensées, chacune avec sa place

Red Hat a clôturé la ligne traditionnelle d'OpenStack Platform avec la 17.1. Le successeur officiel est Red Hat OpenStack Services on OpenShift (RHOSO), qui change le modèle opérationnel en posant le control plane sur Kubernetes. C'est une décision d'architecture, pas seulement un renouvellement de contrat.

  • Rester sur OSP 17.1 sous ELS le temps de planifier la voie sereinement.
  • Migrer vers RHOSO si vous utilisez déjà OpenShift ou souhaitez unifier la plateforme.
  • Changer de distribution vers Canonical Charmed ou Kolla-Ansible si cela correspond mieux à votre équipe.

Nous pouvons auditer votre OSP et vous rendre les trois voies avec des chiffres : coût des licences, temps de migration estimé et risque opérationnel. Nous sommes vendor-neutral : chaque option a sa place, et cela dépend de votre contexte — pas de notre tarif.

[ 05 ]Portée réelle

Distributions que nous exploitons en production

Nous ne listons pas chaque service un par un : nous préférons en parler au cas par cas. Nous couvrons les services core d'OpenStack et les services adjacents selon l'environnement de chaque client, avec un focus sur ce qui s'opère réellement, pas sur ce qui sonne bien dans un catalogue.

Nous travaillons habituellement sur Canonical Charmed / Sunbeam, Red Hat OSP 16.2 et 17.1, Kolla-Ansible et des déploiements DIY sur Ubuntu, RHEL ou SUSE. Pour la sauvegarde nous nous appuyons sur Trilio quand c'est pertinent, et pour former votre équipe nous proposons des cours officiels OpenStack à tarif partenaire.

[ 06 ]Questions fréquentes

Doutes sur le support d'OpenStack

Qu'est-ce que le support managé d'OpenStack ?

C'est un contrat par lequel une équipe externe prend en charge l'exploitation de votre cloud OpenStack : surveillance, patches, upgrades, gestion des incidents et conseil technique en continu. Il peut compléter le support du vendor (Canonical, Red Hat) ou le remplacer entièrement. Chez SIXE nous le faisons vendor-neutral : nous supportons votre distribution, quel que soit le fournisseur de vos licences.

Pouvez-vous maintenir un cloud que vous n'avez pas installé ?

Oui — c'est le Profil C plus haut. Nous commençons par un audit de deux semaines : inventaire, version de chaque service, dette de patches, couverture de surveillance, sauvegardes et runbook. À la fin, nous livrons un rapport avec les constats, les risques hiérarchisés et un plan pour amener l'environnement à un état supportable. À partir de là, l'un des trois forfaits.

Quel SLA proposez-vous pour OpenStack ?

Le SLA — délais de réponse et de résolution par sévérité, fenêtres et pénalités — se définit au contrat et dépend de la modalité choisie, de la taille de l'environnement et des fenêtres hors horaires. Nous l'accordons avec votre équipe, le mettons par écrit et le tenons.

Supportez-vous Red Hat OpenStack Platform après l'EOL de 2029 ?

Oui, tant que Red Hat maintient l'ELS d'OSP 17.1 (prévu jusqu'en juin 2029) nous fournissons du support L3 aux côtés de votre contrat. Et avant cette date nous vous accompagnons pour choisir la voie : rester en ELS le temps de planifier, migrer vers Red Hat OpenStack Services on OpenShift, ou passer à Canonical ou Kolla-Ansible. La décision revient à votre comité — nous apportons les chiffres.

Comment est facturé le support d'OpenStack ?

Cela dépend de la modalité. Sauvetage : facturé à l'intervention, sans engagement. Contrat continu et Opérations 24×7 : forfait mensuel dimensionné à l'inventaire (nombre d'hyperviseurs, tenants, backend de storage et fenêtres couvertes). Avant de donner une fourchette nous voulons regarder l'environnement — parlez-nous ici.

Coexistez-vous avec le support de Canonical ou le remplacez-vous ?

Les deux options sont valables et nous avons fait les deux. La coexistence convient quand vous voulez une réponse locale dans votre fuseau horaire en français, espagnol ou anglais, en conservant le contrat Canonical pour l'accès aux fixes upstream. L'option fournisseur unique a du sens quand vous voulez consolider facturation et point de contact. Nous auditons les deux scénarios avant de recommander.

Travaillez-vous sur Ceph avec OpenStack ?

Oui — c'est la combinaison par défaut dans 90 % de nos clouds. Ceph comme backend de Cinder, Glance et Manila, et dans certains cas comme object storage (RGW) pour Swift. Nous avons une page dédiée au support Ceph pour l'IA et le HPC si le focus est le storage.

Et si je suis encore sur VMware ou Hyper-V et que je veux passer à OpenStack ?

Alors ce n'est pas encore du support qu'il vous faut, c'est une migration. Nous avons un service dédié avec PoC de 6 semaines : Migration vers OpenStack depuis VMware ou Hyper-V. Une fois la migration terminée, la même équipe peut rester en exploitation avec l'un des trois forfaits de cette page.
[ 07 ]On commence par un appel

Parlez-nous de votre cloud, pas via un formulaire

Distribution, nombre d'hyperviseurs, version et ce qui vous fait mal. Nous vous renvoyons une fourchette et une proposition en moins de 24 h ouvrées.