Alain, notre administrateur système, revient aujourd’hui sur le blog à la suite de son premier article. Nous espérons que l’infrastructure de nos serveurs n’aura plus de secrets pour vous !
Bonjour tout le monde ! Cela fait un moment que je ne vous ai pas écrit, il est temps de remédier à cela ! J’aimerais vous présenter les nouvelles concernant l’infrastructure de RadioKing. Mais avant cela, un petit glossaire :
- Cluster : désigne un groupe (ou une « grappe ») (par exemple, nous parlerons de cluster de radio ou de cluster d’API)
- Kubernetes : technologie qui orchestre des conteneurs (par exemple, les conteneurs peuvent contenir une radio).
- Dépôt Git : endroit où le code est stocké pour pouvoir effectuer des modifications à celui-ci, sans en perdre l’ancienne version.
Le nouveau système d’hébergement des radios
Comme évoqué précédemment dans la première partie de cette série d’articles, nous avons mis en place un nouveau système pour gérer et héberger vos radios. Ce système permet à chaque radio de disposer de son propre environnement d’exécution. Nous avons donc isolé vos radios les unes des autres, pour nous permettre de les gérer avec une granularité plus fine.
Les redémarrages, mises à jour ou même les tests de nouvelles versions peuvent donc se faire indépendamment, sans impacter les autres radios. Ce nouveau système, entièrement automatisé, repose sur Kubernetes. Un dépôt Git s’occupe de maintenir l’ensemble du code permettant la gestion et le déploiement des radios. Cela nous permet de garantir la validité de la configuration appliquée aux différents clusters.
Ce système, appelé le « GitOps » (je ne suis pas un grand fan des buzzwords), assure une résilience dans le sens où, si le cluster venait à être entièrement détruit (ce que je n’espère pas) il serait possible d’en reconstruire un à l’identique rapidement.
Le nouveau Manager Radio
Vous avez, sans doute, bien pris en main le nouveau Manager Radio et nous en sommes très fiers ! Ce nouveau manager est mieux pensé et surtout mieux armé.
En effet, nous avons réétudié l’ensemble des API qui desservent les fonctionnalités offertes par ce Nouveau Manager. En suivant la logique des micro-services (ici les API) sans état (=destructibles), c’est également un cluster Kubernetes qui héberge toutes ces API. Elles sont séparées du cluster des radios pour assurer une meilleure résilience.
À nouveau, la gestion, les mises à jour et le dépannage en sont grandement facilités et plus fiables. En suivant le précepte « Cattle vs Pets » (bétail vs animal de compagnie, remplaçable = bétail, indispensable = animal de compagnie), chaque composant de cette infrastructure est remplaçable sans dommage.
Le nouveau système de stockages des fichiers
Vous avez sans doute pu constater une panne impactant notre service de diffusion durant le mois de juin 2020. Nous avons travaillé d’arrache-pied pour vous offrir un stockage de fichiers plus fiable et plus réparti. La nouvelle technologie employée est à l’état de l’art, et est en phase de mise en production. Nous avons mis en oeuvre un cluster Ceph, hébergé sur des machines puissantes et disposant d’un volume de stockage important.
L’ensemble des serveurs ont profité des dernières mises à jour, ce qui les rend donc sécurisés et fiables. Chaque composant de cette infrastructure a été testé dans le cadre du PRA (Plan de Reprise d’Activité). Cela veut dire que nous avons simulé une panne de tout ou partie du système et analysé le comportement de celui-ci en réaction à ce dysfonctionnement provoqué. Nous sommes ainsi en mesure de maintenir plus efficacement le système de fichiers distribués, permettant le stockage de toutes les pistes audio que vous ajoutez dans votre Médiathèque.
Enfin, sachant que deux précautions valent mieux qu’une, ce système est lui aussi sauvegardé chez un autre hébergeur, sur un autre serveur. Comme le système d’aujourd’hui d’ailleurs.
Des métriques, toujours plus de métriques
Nous continuons de travailler sur l’aperçu de l’entièreté de l’infrastructure. Un grand nombre de métriques, concernant les serveurs, les machines virtuelles et les conteneurs de RadioKing, sont collectées (CPU, RAM, réseau, etc…) cela afin d’être alertés très tôt et de pouvoir intervenir rapidement et précisément en cas de dysfonctionnement.
Ces nombreuses métriques offrent une visibilité accrue de l’infrastructure, mais également un indice de performance global. Nous sommes donc en mesure de mettre à l’échelle les différents serveurs qui composent notre infrastructure.
Par ailleurs, la collecte des logs (historique) des serveurs est désormais généralisée et centralisée. Nous construisons actuellement des tableaux de bord permettant de visualiser les flux de logs. Ils nous donnent aussi la possibilité de détecter les comportements anormaux de l’infrastructure.
