Réserve OTT/DVR

Important

Version bêta 2.1. Ce qui est décrit ici n’existe que dans la version bêta 2.1 : elle s’installe depuis le dépôt bêta et uniquement avec une licence ; la version stable 2.0.2 et la version de démonstration ne l’ont pas. La version bêta est fournie sans garantie, et l’assistance est assurée dans la mesure du possible (Programme de test bêta).

La réserve OTT/DVR protège les spectateurs de la diffusion OTT contre la panne d’un nœud ou d’un flux sur celui-ci. Les nœuds qui diffusent une même chaîne sont réunis en un groupe OTT, d’après un nom de groupe identique. La protection fonctionne de deux façons :

  • bascule en cours de visionnage — la playlist maître HLS désigne au lecteur les nœuds de secours et, en cas de panne de son nœud, le lecteur continue depuis un autre ;

  • redirection à l’ouverture — un nœud qui ne peut pas servir un nouveau spectateur ou une requête d’archive les redirige vers un nœud qui le peut.

Champs, écran et détails : Groupes OTT ; ici, ce qu’il faut planifier.

Deux nœuds d'un groupe OTT reçoivent une même source ; la playlist maître du nœud A désigne le nœud B comme secours ; lorsque le flux ou le nœud A tombe en panne, un lecteur qui prend en charge le secours passe sur le nœud B via son adresse HTTPS publique ; un nouveau spectateur ou une requête d'archive adressée au nœud A reçoit une redirection 302 vers le nœud B.

Panne du nœud A : le lecteur passe sur le nœud B, et les nouveaux spectateurs et les requêtes d’archive sont redirigés vers lui.

Quand l’utiliser

  • La chaîne est diffusée en HLS, LL-HLS ou DASH à des spectateurs sur Internet ou dans un grand réseau, et la panne d’un serveur ne doit pas interrompre le visionnage.

  • Vous avez besoin de l’archive (catch-up) même lorsque l’enregistrement s’est interrompu sur l’un des nœuds.

Les récepteurs multicast sont protégés par un autre mécanisme : Réserve à chaud des sorties multicast. Contre la panne de la source, ce sont les entrées de secours qui protègent (1. Source : entrées de secours), et il vaut la peine de les avoir sur chaque nœud du groupe.

Ce qui est protégé dans cette version bêta

Cas

Ce qui se passe

Limites

Le spectateur regarde, le nœud ou le flux tombe en panne

Le lecteur passe sur le nœud de secours indiqué dans la playlist maître

Flux HLS simples avec une seule source sur les nœuds ; lecteurs prenant en charge les variantes de secours (Lecteurs et réserve OTT/DVR)

Un nouveau spectateur ouvre un flux qui ne fonctionne pas sur le nœud

Redirection 302 vers le nœud où le flux est en direct

N’importe quel lecteur ; HLS, LL-HLS et DASH

Requête d’archive pour une période absente du nœud

Redirection 302 vers le nœud où la période est enregistrée ; 404 si elle n’existe nulle part

Le nœud est choisi d’après la plage d’archive ; les trous à l’intérieur de la plage sont servis par le nœud lui-même

Les ensembles adaptatifs, le LL-HLS et le DASH ne sont protégés que par la redirection à l’ouverture : un spectateur qui regarde déjà rouvre le flux en cas de panne du nœud. Après la bascule, les sous-titres restent sur le nœud d’origine.

Nœuds et groupe

  • Combien. Deux nœuds ou plus. La playlist maître indique à chaque spectateur jusqu’à deux nœuds de secours choisis de façon équilibrée, si bien que les spectateurs d’un nœud en panne se répartissent sur tous les nœuds éligibles du groupe (Puissance).

  • Domaine et réserve. Tous les nœuds sont dans un même domaine Meshwork avec la réserve Meshwork activée. Le spectateur arrive sur le nœud de secours avec un laissez-passer, une autorisation signée de regarder depuis un autre nœud. Il est signé par la clé de visionnage, convenue automatiquement entre les nœuds. Les horloges des nœuds ne doivent pas s’écarter de plus de 240 secondes.

  • Groupe. Pour le flux ou l”ensemble adaptatif, « Réserve OTT » est activé, et le « Nom du groupe de réserve » est le même sur tous les nœuds qui diffusent la chaîne.

  • Une seule source. La bascule en cours de visionnage fonctionne entre membres dont la source commune est prouvée : les nœuds prennent le même flux, et non chacun le sien.

  • Version. Un membre est un flux ou un ensemble d’un nœud dans un groupe OTT. Un membre sur un nœud de version antérieure à 2.1.0.456 n’accepte pas de spectateurs : mettez à jour tous les nœuds du groupe.

  • Limite de connexions. Le champ « Connexions max, HTTP/HLS » de l’identifiant s’applique sur chaque nœud séparément : un abonné redirigé peut ouvrir autant de sessions sur l’autre nœud aussi.

Adresses des nœuds

Le lecteur ouvre le nœud de secours directement, à l’adresse que ce nœud annonce, sans passer par le nœud d’où vient le spectateur ni par un répartiteur de charge commun.

  • Une adresse publique pour chaque nœud. Renseignez le « Nom d’hôte » du serveur HTTP de chaque nœud (Serveur HTTP de diffusion) : un nom DNS accessible aux spectateurs, par exemple node-b.example.net. Sans lui, le nœud annonce son adresse, et uniquement en HTTP.

  • Spectateurs publics, adresses publiques. À un spectateur venant d’une adresse publique, le nœud ne propose pas de secours ayant une adresse privée (problème « Un nœud n’a que des adresses privées pour le secours »).

  • HTTPS. À un spectateur en HTTPS — y compris derrière un proxy qui transmet X-Forwarded-Proto: https — seuls des secours ayant une adresse HTTPS sont proposés. Le certificat de chaque nœud doit être émis pour son « Nom d’hôte » (problème « Un nœud n’a pas d’adresse https pour le secours »).

  • Proxy. Le nœud juge l’adresse du spectateur d’après la connexion et ne lit pas X-Forwarded-For. Derrière un proxy à adresse privée, tous les spectateurs semblent privés, et la règle des adresses publiques ne fonctionne pas : donnez aux nœuds des adresses publiques.

  • Cache et CDN. Un CDN convient devant les adresses principales de chaque nœud ; un nom CDN commun à plusieurs nœuds ne convient pas pour les adresses de secours (8.1. Réserve OTT/DVR et CDN).

Puissance

Quand un nœud tombe en panne, ses spectateurs se répartissent sur les autres nœuds éligibles du groupe : chaque spectateur passe sur l’un de ses deux secours, et les secours sont choisis de façon équilibrée entre les spectateurs. Sur N nœuds éligibles, chacun des restants reçoit environ 1/(N−1) des spectateurs du nœud en panne. Prévoyez sur chaque nœud une marge de CPU et d’interface réseau pour 1 + 1/(N−1) fois la charge normale : le double avec deux nœuds, une fois et demie avec trois.

Un nœud n’est éligible que tant qu’à la fois il :

  • est proposé comme secours (colonne « Secours » — « Peut secourir ») et a servi la fenêtre live — les derniers segments de l’antenne dans la playlist — au cours des 10 dernières minutes ;

  • prend la même source (transition « Même chronologie ») ;

  • sert du HLS sur MPEG-TS avec des niveaux du même codec (pour un bundle adaptatif, avec un débit au plus 1,25 fois plus élevé) ;

  • a une horloge qui diffère de celle de ce nœud de 240 secondes au plus et détient la clé de visionnage ;

  • n’est pas surchargé.

La protection contre la surcharge ménage un nœud de secours mais n’ajoute pas de capacité. Un nœud n’accepte pas un nouveau spectateur d’un autre nœud lorsque :

  • la charge du CPU ou du réseau dépasse les seuils d’erreur des paramètres des alertes (Alerteur) ;

  • le « Plafond de sessions de secours » est atteint.

Un nœud ne refuse jamais ses propres spectateurs (Protection contre la surcharge). Après un refus, le lecteur passe à son second secours.

Si les deux secours refusent, le spectateur perd le flux. Des refus pendant plus de 30 secondes déclenchent l’alerte de code 79 (reserve-ott-overload) : la marge ne suffit pas.

Archive

Pour la redirection vers l’archive, c’est l’archive du protocole de la requête qui compte : MPEG-TS pour HLS, fMP4 pour LL-HLS et DASH. La profondeur d’archive peut différer d’un nœud à l’autre : la requête part vers le nœud qui conserve la plus grande partie de la période. Le nœud est choisi d’après la plage d’archive, de l’enregistrement le plus ancien au plus récent ; les trous à l’intérieur de sa plage sont servis par le nœud lui-même. Stockage de l’archive : DVR : archive du flux.

Lecteurs

La bascule en cours de visionnage est disponible pour les lecteurs qui savent basculer sur des variantes de secours : AVPlayer (Safari, iOS, tvOS), hls.js et les lecteurs similaires dans le navigateur, ExoPlayer et Media3. VLC, les lecteurs basés sur ffmpeg, mpv, Kodi et les boîtiers sans User-Agent ne reçoivent pas de variantes de secours et rouvrent le flux en cas de panne du nœud ; c’est alors la redirection qui intervient. Ce qui a été vérifié pour chaque lecteur, le son et la vidéo dans les navigateurs : Lecteurs et réserve OTT/DVR.

Pour votre propre lecteur basé sur hls.js : définissez des délais d’attente courts pour le chargement de la playlist et du segment, environ une durée cible de segment — la bascule prend alors quelques secondes.

Avant la mise en service

  • Sur l’écran « Réserves », le groupe OTT est à l’état « Secouru », sans problème ; le bloc « Clé de visionnage OTT » indique « En service ».

  • Chaque nœud a un « Nom d’hôte » public défini, et le certificat HTTPS est émis pour ce nom.

  • Une panne d’essai — une pause de l’entrée du flux sur un nœud — fait passer le lecteur sur l’autre nœud ; un nouveau spectateur de ce flux reçoit une redirection.

  • Les alertes de codes 70, 78 et 79 sont livrées à la personne d’astreinte (Redondance des flux).