En flux tendu, Cognacq-Jay Image privilégie un stockage qu’elle peut sonder

L’historique régie de télévision doit aujourd’hui transcoder à toute vitesse les émissions dans une multitude de formats numériques. Pour elle, la bande passante importe autant que la traque des erreurs.

La régie de télévision Cognacq-Jay Image a choisi de s’équiper d’une solution de stockage super élastique Qumulo, car celle-ci permet un monitoring et un paramétrage plus fins que ses concurrentes. Ce détail était primordial, dans un contexte où l’application a ceci de critique qu’elle doit faire entrer et sortir en continu de grandes quantités de fichiers. Et, ce, en respectant un timing serré, imposé par les clients de la régie.

« Chaque jour, ce sont plusieurs To de vidéos qui arrivent, que nous transformons et que nous renvoyons dans un délai contraint à leurs chaînes pour qu’elles les diffusent. Nous devons maintenir un débit, mais celui-ci dépend tout autant de la performance de la plateforme que de la justesse des processus que nous exécutons », explique Michel Desconnets, le responsable des systèmes à la DSI de Cognacq-Jay Image.

« Nous devons maintenir un débit, mais celui-ci dépend tout autant de la performance de la plateforme que de la justesse des processus que nous exécutons. »
Michel DesconnetsResponsable des systèmes, à la DSI de Cognacq-Jay Image

Le métier de Cognacq-Jay Image consiste historiquement à effectuer un montage de postproduction sur les émissions de télévision : insérer un générique, intercaler des spots de publicité, ajouter des sous-titres… Mais depuis que la télé est diffusée sur les canaux numériques, le gros du travail est informatique : il s’agit de transcoder chaque vidéo en une multitude de formats, qui pour la TNT, qui pour le web, qui pour telles et telles boxes, qui pour telle application sur tel et tel autre terminal.

« Pour un journal télévisé, par exemple, nous recevons des reportages qui viennent d’être tournés et que nous renvoyons correctement formatés au bout de dix minutes. Mais pour un film en très haute résolution, il faut compter plusieurs heures de conversion. Certains clients nous envoient leurs vidéos à la dernière minute, d’autres nous les envoient des semaines à l’avance. »

« La quantité de formats dépend de chaque client. Certaines vidéos nécessitent l’ajout de DRM… Nous devons prendre tous ces paramètres en compte, gérer les priorités pour chacun des travaux qui se trouvent à un instant T sur nos systèmes. C’est un processus excessivement complexe. »

Les clients de Cognac-Jay vont des petites chaînes indépendantes aux groupes média qui chapeautent plusieurs chaînes. Certains clients se chargent en interne d’une partie du processus, souvent le montage des bancs-titres et l’archivage des émissions sur la durée. D’autres non.

Nombre d’entre eux exigent que Cognacq-Jay Image leur dédie une infrastructure informatique. C’est ainsi que le prestataire a multiplié les plateformes de stockage dans son datacenter. On y trouve des NAS super élastiques Isilon de Dell EMC, des baies de stockage objet Scality

Le défi d’éviter le moindre retard

En 2020, l’un de ces clients – Michel Desconnets ne souhaite pas indiquer lequel – allait augmenter sa production et la baie Scality qui lui était dédiée n’offrait plus les caractéristiques adéquates. « Il s’agissait d’une baie de 300 To qui permettait de soutenir un débit de 2,5 Go/s. La capacité n’était pas un problème, car seuls 60 To étaient dédiés à la production et le reste servait à l’archivage des vidéos, ce dernier devant être réinternalisé par notre client. Non, notre véritable souci concernait le débit : nous avions besoin de 3 Go/s pour les écritures, plus 1 Go/s en lecture pour exporter les fichiers finaux », raconte le responsable.

« Les serveurs chargés du transcodage supportent de grandes bandes passantes, mais ils écrivent une importante quantité de fichiers en parallèle. »
Michel DesconnetsResponsable des systèmes, à la DSI de Cognacq-Jay Image

Et d’expliquer la complexité de la mécanique : « les serveurs chargés du transcodage supportent de grandes bandes passantes, mais ils écrivent une importante quantité de fichiers en parallèle. Si votre temps d’écriture est 20 % moins performant que leur vitesse de calcul, cela va retarder d’autres processus. Le problème est que l’on ne sait plus ce qui retarde l’ensemble. »

« C’est-à-dire qu’au-delà du simple goulet d’étranglement technique, nous ne savons plus réagir rapidement sur les vraies erreurs. Or, les vraies erreurs – un problème de transcodage, la mauvaise version d’un fichier, etc. – sont très fréquentes et demandent une extrême vigilance de notre part. »

Vers le milieu de l’année 2020, Michel Desconnets et son équipe se mettent donc en quête d’une nouvelle solution de stockage. « Dans toutes leurs offres, Scality était plus compétent sur la capacité de stockage que sur la vitesse d’accès, c’est-à-dire que leurs solutions nous imposaient d’acheter beaucoup de serveurs en amont pour compenser leur latence. »

« Chez Isilon, le problème de la bande passante se pose moins. En revanche, il est très difficile de monitorer l’activité avec une baie Isilon, en particulier lorsque l’on cherche à diagnostiquer les problèmes que posent les petits fichiers, ceux que posent les gros fichiers, etc. »

Qumulo, du stockage logiciel sur du matériel HPE

C’est alors que la DSI de Cognacq-Jay Image rencontre Qumulo. « Ils nous ont proposé des machines en test pendant deux mois. Nous avons pu valider que cette solution disposait d’une API très riche, qui nous permettait d’écrire des scripts très poussés, en plus d’être fournie avec des chaînes de test prêtes à l’emploi. »

La commande d’une solution Qumulo est passée lors du dernier trimestre 2020. Qumulo étant une solution logicielle, elle s’achète au travers de HPE, lequel fournit les matériels préconfigurés. En l’occurrence, Cognacq-Jay Image décide d’acheter six serveurs Apollo, au format Rack 2U, qui offrent chacun 36 To de capacité de stockage.

Ils sont complétés par deux switches qui tiennent dans 1U. Outre interconnecter les nœuds, ces switches assurent quatre connexions en 10 Gbit/s vers les serveurs de transcodage, soit une trentaine de machines Windows. Selon les tests effectués, cette configuration supporte sans sourciller une charge de 6 Go/s.

« Les serveurs de transcodage étant également liés au même client, nous pourrions nous poser la question d’opter pour des infrastructures hyperconvergées qui réunissent stockage et serveurs dans la même baie. Mais ces systèmes ne sont pas adaptés à nos besoins, où la capacité de calcul est indépendante de la capacité de stockage. Nous voulons pouvoir augmenter l’un sans nécessairement augmenter l’autre », commente Michel Desconnets.

« De plus, notre processus passe aussi par des serveurs d’export qui, eux, ne sont pas dédiés à des clients et supposent donc une infrastructure de toute façon séparée. »

La solution est en place fin 2020. « Nous devions la mettre en production à partir de 2021, mais notre client a augmenté sa charge de travail juste avant Noël. Nous avons donc accéléré la migration. Finalement, nous sommes passés du test à la production en deux jours. »

Tout à coup, la solution a déraillé

Au début, tout se passe comme Cognacq-Jay Image l’avait envisagé. Mais deux mois plus tard, la solution se met à dérailler.

« En février 2021, nous avons subitement vu des files d’attente se former. Un fichier qui aurait dû sortir en une heure, prenait deux, voire trois heures pour être transcodé dans tous les formats. Les outils de monitoring de Qumulo révélaient des latences cent fois trop élevées ! Pour autant, ils ne nous permettaient pas de savoir si le problème venait des disques ou du code de nos outils. »

« J’ai donc profité des possibilités de l’API pour écrire des scripts qui récupèrent les informations de monitoring en temps réel et les comparent dans le temps. Grâce à cela, je me suis rendu compte que si j’éteignais certains transcodeurs en amont, tout allait plus vite, ce qui signifie que le parallélisme était paradoxalement devenu contre-productif », s’étonne Michel Desconnets.

Il ne tardera pas à comprendre que la faute venait de l’agencement des processus. « Nous avions décidé de transcoder tous les fichiers dans un premier format. Puis de tous les transcoder dans un second format, etc. Sauf qu’en procédant ainsi, nous chargions et déchargions les fichiers dans le cache à chaque transcodage. » Il précise que le cache est constitué de 1 To sur chaque nœud, soit 6 To, c’est-à-dire trop peu pour conserver tous les fichiers en cours de traitement.

« La bonne pratique était de plutôt transcoder un fichier dans tous les formats possibles, puis de passer au second fichier. Nous devions faire en sorte qu’un fichier qui entre sorte le plus vite possible, plutôt que chercher à en transcoder le plus possible en même temps ! »

L’opportunité de bâtir un monitoring complet

Michel Desconnets n’est pas peu fier du système de monitoring qu’il a réussi à bâtir au-dessus de l’API de Qumulo. L’outil Zabbix récupère les métriques, Kibana analyse les logs et, in fine, Grafana représente l’ensemble sous forme graphique.

« En moyenne, nous utilisons 100 To par jour. [...] Ce n’est pas un stockage qui gonfle au fur et à mesure, mais qui se remplit et se vide en permanence. »
Michel DesconnetsResponsable des systèmes, à la DSI de Cognacq-Jay Image

« J’ai mis au point une console qui permet de descendre jusqu’à la provenance de chaque opération. Ce système de monitoring nous a permis de résoudre tous nos problèmes en une moins d’une semaine. Au bout de deux semaines, nous avons optimisé très finement tous les réglages. Nous avons même découvert des bugs qui existaient depuis longtemps dans nos processus et que nous avons enfin réparés. »

Lorsque les problèmes ont été résolus, la charge a augmenté pendant une douzaine d’heures, les travaux retardés s’achevant subitement en même temps que ceux en cours. Pour autant, Michel Desconnets se félicite de constater que la baie Qumulo a supporté le choc sans broncher.

Depuis, l’équipe a ajouté deux nœuds Apollo. La capacité brute totale s’élève ainsi à 288 To, soit 210 To utiles, le reste servant de redondance. « En moyenne, nous utilisons 100 To par jour. Parfois, nous grimpons à 180 To, puis nous redescendons dès le lendemain à 85 To. Ce n’est pas un stockage qui gonfle au fur et à mesure, mais qui se remplit et se vide en permanence. »

« Désormais, notre cluster de stockage Qumulo fonctionne comme une horloge. Les métriques remontent toujours et elles nous permettent même de mieux suivre l’activité de ce client. Nous détectons par exemple qu’ils n’ont pas acquitté assez rapidement les opérations que nous avons effectuées, ce qui permet de résoudre plus vite certains blocages », conclut Michel Desconnets.

Pour approfondir sur Administration du stockage

Close