Récupération après crash : Restauration automatique des flux

Pourquoi la récupération après crash est importante

Les serveurs redémarrent. Les kernel panics arrivent. Les alimentations tombent en panne. L’OOM killer termine les processus. Dans un environnement de streaming 24h/24, la question n’est pas si votre logiciel va redémarrer, mais quand — et ce qui arrive à vos flux quand cela se produit.

Sans récupération automatique après crash, chaque redémarrage nécessite une intervention manuelle : quelqu’un doit remarquer le problème, se connecter et recréer les routes. À 3h du matin un dimanche, cela peut signifier des minutes ou des heures d’interruption.

Vajra Cast a été conçu pour un fonctionnement sans surveillance. Quand il démarre — que ce soit depuis un démarrage à froid, un redémarrage de processus ou une replanification de conteneur — il restaure automatiquement toutes les routes à leur état précédent et reconnecte chaque flux.

Comment fonctionne la récupération après crash

La récupération après crash de Vajra Cast repose sur un principe simple : la base de données est la source de vérité, pas le processus en cours d’exécution.

Chaque route, entrée, sortie et paramètre de configuration est persisté dans une base de données PostgreSQL au moment de sa création ou de sa modification. Le moteur de routage en mémoire est une projection de l’état de la base de données — il peut être reconstruit à tout moment à partir de la configuration stockée.

La séquence de récupération

Quand Vajra Cast démarre, la séquence suivante s’exécute :

1. Connexion à la base de données. L’application se connecte à PostgreSQL et vérifie l’intégrité du schéma.
2. Chargement de l’état. Toutes les configurations de routes sont lues depuis la base de données : entrées, sorties, chaînes de basculement, profils de transcodage, mappages audio.
3. Reconstruction des routes. Le moteur de routage crée chaque route en mémoire à partir de la configuration stockée.
4. Liaison des listeners. Les listeners SRT et RTMP se lient à leurs ports configurés et commencent à accepter les connexions.
5. Initiation des callers. Les callers SRT et les sorties RTMP push commencent à se connecter à leurs points de terminaison distants.
6. Démarrage de la surveillance de santé. Le moteur de basculement commence à surveiller toutes les entrées.

Cette séquence entière se termine en quelques secondes. Du moment où le processus démarre au moment où les flux circulent à nouveau, le temps de récupération est généralement inférieur à 5 secondes — souvent inférieur à 2 secondes pour les déploiements de petite et moyenne taille.

Ce qui est persisté

Tout ce qui définit le comportement d’une route est stocké dans la base de données :

Ce qui n’est pas persisté : l’état transitoire à l’exécution comme les mesures de débit actuelles, les compteurs de paquets et les descripteurs de connexion actifs. Ceux-ci sont reconstruits à partir des données en direct lorsque les flux se reconnectent.

PostgreSQL : la couche de persistance

Vajra Cast utilise PostgreSQL comme magasin d’état. C’est un choix délibéré par rapport à des alternatives plus légères comme SQLite ou des magasins clé-valeur embarqués :

Durabilité. PostgreSQL utilise la journalisation anticipée (WAL) pour garantir que les transactions validées survivent aux crashs. Si Vajra Cast écrit une configuration de route et que PostgreSQL l’acquitte, ces données sont en sécurité — même si le serveur perd l’alimentation dans la milliseconde suivante.

Concurrence. Plusieurs composants de Vajra Cast (le moteur de routage, l’API REST, l’interface web) peuvent lire et écrire simultanément dans la base de données sans corruption. Le MVCC (Multi-Version Concurrency Control) gère cela de manière transparente.

Maturité opérationnelle. PostgreSQL a des décennies d’utilisation en production. Votre équipe d’exploitation sait déjà comment le sauvegarder, le répliquer et le surveiller. Il n’y a pas de format de base de données propriétaire à craindre.

Accès externe. Comme l’état est dans une base de données PostgreSQL standard, vous pouvez l’interroger directement pour le reporting, l’audit ou l’intégration avec des systèmes externes. Le schéma est documenté et stable.

Schémas de déploiement de la base de données

Pour un déploiement sur serveur unique, PostgreSQL s’exécute aux côtés de Vajra Cast sur le même hôte. La configuration Docker Compose inclut les deux services :

services:
  vajracast:
    image: vajracast/vajracast:latest
    depends_on:
      - postgres
    environment:
      DATABASE_URL: postgres://vajracast:secret@postgres:5432/vajracast

  postgres:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: vajracast
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: vajracast

volumes:
  pgdata:

Pour les déploiements haute disponibilité, utilisez un cluster PostgreSQL externe (services managés comme AWS RDS, Google Cloud SQL, ou un cluster Patroni auto-géré). Ainsi, la base de données survit même si l’hôte Vajra Cast entier tombe en panne.

Temps de récupération

À quelle vitesse Vajra Cast récupère-t-il ? Cela dépend de la taille de votre déploiement et de la nature du redémarrage.

Le démarrage de l’application en lui-même est rapide — moins de 2 secondes pour la plupart des configurations. Le facteur dominant dans le temps de récupération est le temps nécessaire pour que l’environnement (OS, runtime de conteneur, réseau) devienne disponible.

Reconnexion des flux

Après la récupération de Vajra Cast, les flux doivent se reconnecter :

• SRT Listeners : disponibles immédiatement. Les callers distants se reconnectent automatiquement car la gestion de connexion SRT gère la reconnexion.
• SRT Callers : Vajra Cast initie la connexion sortante immédiatement au démarrage. Le listener distant voit une nouvelle connexion en quelques secondes.
• RTMP Listeners : disponibles immédiatement. Les encodeurs qui poussent en RTMP réessayaient généralement à la déconnexion, donc ils se reconnectent dans leur intervalle de réessai (généralement 2-5 secondes).
• Sorties RTMP Push : Vajra Cast se reconnecte au serveur RTMP distant immédiatement au démarrage.

La récupération de bout en bout — du crash aux flux qui circulent à nouveau — est la somme du temps de récupération de l’application plus le temps de reconnexion des flux. Pour un système bien configuré, cela se situe généralement sous les 10 secondes.

Détection de crash et gestion de processus

Vajra Cast ne gère pas ses propres redémarrages. Il s’appuie plutôt sur le gestionnaire de processus ou l’orchestrateur de conteneurs pour détecter les crashs et redémarrer l’application :

• systemd : configurez Restart=always et RestartSec=1 dans le fichier d’unité. systemd détecte l’arrêt du processus et le redémarrage en moins d’une seconde.
• Docker : définissez restart: unless-stopped ou restart: always dans votre fichier Docker Compose. Le daemon Docker redémarre le conteneur à l’arrêt.
• Kubernetes : la restartPolicy: Always du pod (la valeur par défaut) garantit que le kubelet redémarre le conteneur. Les sondes de vivacité (liveness probes) peuvent détecter les processus bloqués qui ne se sont pas arrêtés mais ne sont plus fonctionnels.

Cette séparation des responsabilités — Vajra Cast gère la récupération d’état, l’orchestrateur gère le cycle de vie du processus — suit la philosophie Unix et évite la complexité des daemons auto-réparateurs.

Vérifications de santé

Vajra Cast expose des points de terminaison de vérification de santé que les gestionnaires de processus et les répartiteurs de charge peuvent utiliser pour vérifier que l’application fonctionne correctement :

GET /api/health

Ce point de terminaison retourne HTTP 200 quand l’application fonctionne et que la connexion à la base de données est saine. Utilisez-le comme sonde de vivacité dans Kubernetes ou comme vérification de santé dans Docker.

Pour une vérification plus approfondie, le point de terminaison de disponibilité confirme que le moteur de routage a terminé le chargement :

GET /api/ready

Celui-ci retourne HTTP 200 uniquement après que toutes les routes ont été reconstruites et que les listeners sont liés. Utilisez-le comme sonde de disponibilité (readiness probe) dans Kubernetes pour empêcher le trafic d’être dirigé vers une instance encore en cours d’initialisation.

Concevoir pour la récupération

Pour minimiser l’impact des crashs sur vos spectateurs :

1. Utilisez SRT pour les chemins critiques. Le tampon de reconnexion et de latence intégré de SRT absorbe gracieusement les brèves pannes.
2. Configurez les tampons de sortie. Un tampon de sortie de 2 à 5 secondes sur votre CDN ou processeur en aval peut masquer les brèves interruptions pendant la récupération.
3. Utilisez un PostgreSQL externe. Si la base de données est sur le même hôte et que l’hôte tombe, vous perdez l’état. Une base de données externe élimine ce risque.
4. Surveillez et alertez. Les métriques Prometheus et les points de terminaison de santé vous permettent de détecter les crashs instantanément et de vérifier la récupération.
5. Testez la récupération régulièrement. Tuez le processus pendant un flux de test. Mesurez le temps jusqu’à la récupération complète. Intégrez cela dans votre cahier opérationnel.

Prochaines étapes

• Retournez au Guide de basculement des flux vidéo pour l’architecture complète de fiabilité
• Découvrez le basculement multi-entrées pour la commutation automatique d’entrées
• Explorez le déploiement Docker et Kubernetes pour l’orchestration de conteneurs en production