Tolérance aux pannes de la surveillance dans le cloud : déploiement hybride, accès local et clustering de serveurs multimédias

Tolérance aux pannes d'un service de vidéosurveillance cloud Cela implique bien plus que la simple protection contre la défaillance d'un serveur individuel. La perte de connexion à la plateforme de l'opérateur, la perte d'un serveur multimédia et la perte d'accès à des vidéos enregistrées constituent différents scénarios de défaillance. Chacun requiert une réponse architecturale adaptée.

Aipix prend en charge plusieurs éléments constitutifs complémentaires : déploiement sur site et hybride, accès local direct via Desktop Local, et le clustering de serveurs multimédias avec réservation de flux vidéo. Ces fonctionnalités doivent être prises en compte conjointement lors de la conception du service, tout en veillant à bien distinguer leurs responsabilités et leurs limites.

Le déploiement hybride détermine l'emplacement de traitement et de stockage de la vidéo. L'exploitation locale assure un accès en cas d'indisponibilité de la connectivité externe. Le clustering des serveurs multimédias pallie la défaillance d'un serveur gérant les flux vidéo. Aucun de ces mécanismes, à lui seul, ne garantit une disponibilité de bout en bout complète ni une protection automatique de chaque fichier d'archive.

Déploiement hybride et stockage local : réduire la dépendance à la connectivité externe

Aipix peut être déployé sur site, au sein de l'infrastructure de l'opérateur télécom. Ce dernier conserve ainsi le contrôle de l'environnement hébergeant la plateforme et ses données de service. Il convient toutefois de ne pas confondre un déploiement hébergé par l'opérateur avec le placement des ressources de traitement et de stockage vidéo chez le client : il s'agit de choix architecturaux distincts.

Dans un déploiement d'entreprise hybride, un Serveur multimédia Ce système peut être installé au sein du périmètre de sécurité du client, l'enregistrement vidéo et l'archivage étant assurés côté client. La plateforme de l'opérateur continue de fournir une gestion centralisée et des capacités d'accès à distance dès que les connexions nécessaires sont disponibles. Aipix décrit ce modèle pour les organisations qui ont besoin de services centralisés tout en conservant leurs données vidéo sensibles au sein de leur propre infrastructure.

Pour la planification de la résilience, la question de conception essentielle est de savoir si le flux vidéo local peut fonctionner indépendamment de la connexion externe. Dans une configuration appropriée, les caméras, le serveur multimédia local, le stockage et le poste de travail de visualisation local peuvent communiquer au sein du réseau du client. Aipix documente le fonctionnement du serveur multimédia à la fois au sein de la plateforme VSaaS et en tant que produit distinct, ainsi qu'avec un client dédié pour un accès local direct. Ces fonctionnalités constituent la base d'une telle conception, mais le comportement d'une installation particulière en cas de déconnexion doit être validé.

Cette distinction est importante : Le placement local d'une archive modifie son emplacement et ses dépendances réseau ; il ne crée pas automatiquement de copie redondante.

De même, un déploiement hybride comprenant un serveur Mediaserver local ne doit pas être considéré comme redondant du seul fait que l'opérateur dispose également de serveurs dans un centre de données. La conception doit déterminer quel serveur peut prendre le relais, s'il peut accéder aux caméras et quelles dépendances restent disponibles en cas de panne.

Fonctionnement local pendant une interruption de la connexion au cloud

Documents Aipix Desktop Local, Il s'agit d'un client Windows spécialisé qui communique directement avec un serveur multimédia sans interagir avec la plateforme VMS. Il permet la surveillance vidéo locale et l'accès aux archives d'enregistrement en cas d'absence ou d'instabilité de la connexion Internet. Il convient de ne pas confondre ce client avec l'idée que toute installation standard de bureau bascule automatiquement en mode hors ligne.

L'application Desktop Local propose des vues dédiées en direct et en enregistrement (DVR). Les fonctions d'archivage incluent la consultation des enregistrements et le téléchargement de segments enregistrés ; la conservation des archives et les calendriers d'enregistrement sont configurés sur le serveur multimédia.

L'accès local doit être préparé avant d'être nécessaire. La procédure d'autorisation documentée requiert au moins une connexion configurée à un serveur de vidéosurveillance, utilisant l'adresse, le port et le jeton appropriés. Plusieurs connexions peuvent être configurées, l'une d'entre elles étant définie par défaut ; cette configuration ne doit pas être interprétée comme une documentation relative au basculement automatique des clients entre serveurs.

Pour valider le déploiement, l'opérateur doit tester l'accès local en déconnectant volontairement la connexion externe. Ce test doit confirmer que le poste de travail peut toujours accéder au serveur multimédia, que les caméras restent accessibles localement et que les flux de travail prévus pour la visualisation en direct, l'enregistrement et l'accès aux archives fonctionnent comme prévu.

Il est essentiel de préciser la portée de cette fonctionnalité. Desktop Local est un client simplifié et non un substitut à l'ensemble des fonctions de la plateforme complète. Son indépendance avérée vis-à-vis du VMS ne garantit pas la disponibilité de l'ensemble des flux de travail de gestion centralisée, d'accès à distance ou autres flux de travail dépendants du cloud en cas de panne.

Le fonctionnement local permet de pallier la perte de connectivité externe. Il ne protège cependant pas, à lui seul, contre les pannes du serveur multimédia local, du stockage, du réseau ou de l'alimentation électrique.

Les composants principaux tolérance aux pannes pour la surveillance du cloud

Serveur multimédia. Ce système capture les flux vidéo des caméras, les traite et les distribue, et assure l'archivage et la gestion des flux vidéo. Un serveur principal gère les flux qui lui sont attribués ; un autre serveur peut être configuré pour réserver un flux afin d'assurer la continuité de service.

Contrôleur. Il coordonne les serveurs multimédias et assure la stabilité du système ainsi que sa tolérance aux pannes. Il reçoit les informations d'état et les événements des serveurs multimédias, ce qui lui permet de réagir aux changements d'état des serveurs, des flux et des caméras.

clusters de serveurs multimédias. Regroupez logiquement plusieurs serveurs multimédias. Leurs objectifs documentés incluent la réservation de flux vidéo sur des serveurs de cluster pour améliorer la tolérance aux pannes et permettre la modification en masse des paramètres du serveur.

Comment fonctionne la réservation de flux

Le mécanisme central est une configuration serveur multimédia primaire/secondaire.

Le mécanisme documenté fonctionne comme suit :

1. Un flux est attribué à un serveur multimédia principal. Ce serveur est responsable du traitement de ce flux en fonctionnement normal.
2. Un serveur supplémentaire est réservé. Aipix identifie ce serveur supplémentaire dans l'interface de gestion des flux comme étant le serveur de secours en cas de défaillance du serveur principal.
3. Les serveurs sont organisés en cluster. Un cluster est une combinaison logique de plusieurs serveurs multimédias, permettant de réserver des flux sur les serveurs du cluster.
4. En cas de défaillance du serveur principal, le serveur secondaire prend le relais. Le glossaire décrit explicitement la prise de contrôle automatique des fonctions principales dans une configuration à deux serveurs.

La documentation prévoit une prise de contrôle automatique, mais ne précise ni un délai de basculement universel, ni une garantie d'absence d'interruption, ni que chaque enregistrement en cours et chaque session client se poursuivent sans interruption.

Comment le contrôleur coordonne la tolérance aux pannes pour la surveillance du cloud

Le contrôleur est responsable de la coordination de la réponse du système aux changements d'état du serveur multimédia.

Le mécanisme comprend les étapes suivantes :

1. Le VMS envoie des commandes. Le VMS initie les opérations en envoyant des commandes d'appel de procédure distante (RPC) au contrôleur.
2. Le contrôleur exécute les commandes. Il effectue les opérations demandées sur les caméras, les caméras dotées d'un micrologiciel Agent préinstallé, les serveurs multimédias et les périphériques Bridge.
3. Le serveur multimédia communique son état. Un mécanisme de rappel fournit au contrôleur des informations actualisées sur le serveur multimédia, les flux et les caméras.
4. Le contrôleur reçoit des événements. Les notifications peuvent signaler l'état du serveur et du flux, l'état de la caméra, la reconnexion à une caméra et si un enregistrement d'archive est en cours.
5. Le contrôleur réagit aux changements. Il peut consigner les événements, attribuer des états aux caméras et relayer les informations au VMS, contribuant ainsi au mécanisme global de tolérance aux pannes.

Une distinction technique importante : la documentation décrit la gestion des rapports d’état et des événements, ainsi que le rôle du contrôleur dans la tolérance aux pannes. Elle ne précise pas que chaque basculement est déclenché par un rappel particulier et ne fournit pas d’algorithme détaillé de détection des pannes, d’intervalle de pulsation, de politique de nouvelle tentative ni de délai d’expiration.

Comment configurer la redondance du serveur en termes de tolérance aux pannes de la surveillance du cloud

La configuration pertinente via l'interface d'administration VMS.

Étape 1 : Créer un cluster de serveurs multimédias

Dans l'interface d'administration, ouvrez la section Serveurs multimédias et créez un cluster. Ajoutez les serveurs multimédias qui participeront à cette configuration.

La documentation Aipix détaille la création de clusters, l'ajout de serveurs, la modification des paramètres de cluster et la suppression de clusters.

Étape 2 : Attribuer les flux de la caméra

Configurez l'attribution du serveur multimédia à la caméra. Les options documentées incluent la distribution automatique, la sélection d'un serveur multimédia autonome et la sélection d'un groupe de serveurs multimédias.

Pour la réservation, le flux de travail correspondant recherche un cluster contenant deux serveurs : un serveur principal et un serveur secondaire.

Étape 3 : Sélectionner les serveurs principaux et secondaires éligibles

Lors de la sélection automatique du serveur, Aipix vérifie :

• Indique si la distribution du flux est activée sur le serveur.
• Si la limite configurée pour le nombre de flux sera dépassée.
• Si le débit binaire entrant dépasserait la limite de trafic configurée.
• Vérifier si le groupe du serveur correspond au groupe de la caméra.
• Vérifier si le taux d'utilisation du stockage se situe dans les limites autorisées.

La documentation relative au transfert de flux précise que l'utilisation du stockage ne doit pas dépasser 80% de capacité totale pendant cette recherche. La documentation générale relative à la sélection des serveurs indique également qu'un serveur est indisponible pour la distribution si chaque charge disque dépasse 80% dans la configuration de base.

Étape 4 : Confirmer la réservation

Une fois la recherche automatique terminée, un administrateur peut sélectionner manuellement un cluster. Le système recherche alors deux serveurs, un serveur principal et un serveur secondaire, au sein du cluster sélectionné. Lorsque les conditions sont remplies, leurs noms s'affichent et l'administrateur confirme le transfert ou l'affectation.

Important : Aipix distingue l’attribution d’une caméra à un serveur multimédia autonome de son attribution à un cluster avec un serveur supplémentaire réservé. L’option « serveur autonome » utilise uniquement le serveur principal et n’attribue pas de serveur secondaire.

Comment le choix du serveur contribue-t-il à la tolérance aux pannes de la surveillance dans le cloud ?

La tolérance aux pannes dépend de l'attribution des flux à des serveurs éligibles, plutôt que de leur simple distribution à n'importe quelle machine disponible.

Décrit ces contrôles :

Le système sélectionne le serveur disponible le moins chargé, en tenant compte du trafic entrant et des autres contraintes configurées. Ces vérifications contribuent à une allocation optimale des serveurs, mais l'équilibrage de charge à lui seul ne constitue pas un mécanisme de tolérance aux pannes. La réservation de flux sur un serveur supplémentaire représente le mécanisme de redondance spécifique.

Que deviennent les archives lorsque les flux changent ?

Il s'agit d'une distinction importante lors de l'évaluation de la résilience globale d'un déploiement VSaaS.

Lors du transfert de flux vidéo vers un autre serveur multimédia :

• Les archives restent sur le serveur multimédia d'origine.
• Les index d'archives sont transférés vers le nouveau serveur multimédia.
• Si l'archivage n'a pas été activé, les index ne sont pas transférés.
• Si des problèmes de lecture d'archives surviennent après le déplacement, un administrateur peut utiliser la fonction Recharger l'index pour actualiser les index.

Cela signifie que la réservation de flux et la redondance des archives sont deux choses distinctes. Le mécanisme de basculement de flux documenté ne doit pas être interprété comme une preuve que les fichiers d'archive sont automatiquement répliqués sur le serveur secondaire.

Le glossaire Mediaserver définit la duplication d'archives comme la création d'une copie de sauvegarde des données archivées par déplacement ou écriture parallèle sur un stockage à long terme. Il décrit également Ceph comme une technologie de stockage distribué prenant en charge la réplication et les clusters de stockage tolérants aux pannes. Toutefois, ces définitions ne garantissent pas que chaque déploiement Aipix utilise Ceph ni que la duplication d'archives est automatiquement configurée lors de la réservation de flux.

Que signifie et ne signifie pas la tolérance aux pannes de la surveillance dans le cloud dans Aipix ?

Documenté capacités :

• Plusieurs serveurs multimédias organisés en clusters.
• Réservation du flux vidéo sur un serveur supplémentaire.
• Prise de contrôle automatique des fonctions principales par le serveur secondaire dans la configuration à deux serveurs décrite dans la documentation.
• Coordination des contrôleurs et rapports d'état/d'événements.
• Sélection du serveur en fonction de la capacité configurée, du trafic, du groupe et des critères de stockage.

Non précisé dans la documentation consultée

• Temps exacts de détection et de récupération en cas de basculement.
• Vérifier que chaque session client en direct se reconnecte sans interruption.
• Indique si les données d'archivage sont répliquées de manière synchrone entre les serveurs principal et secondaire.
• La conservation des enregistrements effectués juste avant une panne est-elle garantie ?.
• Si le contrôleur lui-même dispose d'un système de redondance actif/passif.
• Le basculement vers le serveur principal récupéré est-il automatique ?.

Il s'agit de limitations de la documentation, et non d'une preuve que la plateforme est dépourvue de certaines fonctionnalités. Leur comportement devra être confirmé dans la documentation de déploiement correspondante ou auprès de l'équipe d'ingénierie d'Aipix.

Conclusion technique

La résilience du service Aipix s'évalue au mieux comme une combinaison d'architecture de déploiement, d'accès opérationnel local et de redondance du traitement des médias.

Au niveau du serveur multimédia, le mécanisme documenté repose sur une architecture multiserveur coordonnée par un contrôleur, permettant de réserver des flux vidéo sur un serveur supplémentaire. Dans la configuration à deux serveurs décrite, le serveur secondaire prend automatiquement le relais du serveur principal en cas de défaillance de ce dernier, tandis que des règles de sélection de serveur permettent d'allouer les flux aux ressources disponibles.

Le déploiement hybride offre une plus grande flexibilité dans le placement des charges de travail vidéo et des archives, tandis que l'accès local depuis le bureau permet un accès direct indépendant de toute interaction avec un système de gestion vidéo (VMS). Ces solutions répondent à un aspect différent du problème de résilience par rapport au clustering Mediaserver.

Pour l'opérateur, l'objectif de conception doit donc être explicite : préserver les flux de travail locaux nécessaires en cas de perte de connectivité, rétablir le traitement des flux après une panne de serveur et protéger la vidéo enregistrée grâce à des mécanismes de stockage et d'archivage dédiés. La disponibilité de bout en bout doit également prendre en compte les composants de gestion, le réseau, le stockage et l'infrastructure d'alimentation électrique.

L'argument le plus convaincant en matière de résilience n'est pas qu'un seul mécanisme empêche toute panne, mais plutôt que des mécanismes complémentaires permettent de gérer différents scénarios de défaillance, leur comportement étant vérifié dans le système déployé.

Créez un service VSaaS plus résilient en combinant déploiement hybride, accès vidéo local et clustering Mediaserver. Concevez votre architecture en tenant compte des scénarios de panne auxquels votre service doit résister et de la continuité attendue par vos clients.

Contactez Aipix pour discuter de vos options de déploiement, de vos exigences en matière de redondance et de vos objectifs de reprise.