4 conseils pour bien choisir un serveur de Streaming Video
Choisir son serveur de streaming vidéo peut être un processus difficile. Lorsqu’on demande aux gens quelle est la puissance du serveur qu’ils veulent, les réponses comprennent habituellement « le moins possible » et « assez pour faire le travail. »
Cette incertitude est compréhensible; on ne veut pas acheter trop, mais on ne veut pas non plus être à court. Toutefois, ces types de réponses laissent beaucoup de marge de manoeuvre, ce qui est aggravé par le caractère imprévisible et exigeant en ressources de la diffusion de vidéos en continu. Si vous utilisez Wowza Streaming Engine, il n’y a pas de limite au nombre de flux que vous pouvez transcoder et livrer, mais vous serez limité par le matériel de votre serveur et la bande passante offerte par votre fournisseur d’hébergement ou votre centre de données.
Alors, comment déterminez-vous la puissance dont vous avez réellement besoin lors de la sélection d’un serveur multimédia? Bien que de nombreux facteurs jouent un rôle, la considération la plus importante est l’équilibre entre deux contraintes : la bande passante du réseau et la capacité de traitement.
Pour les scénarios où vous avez un grand nombre de sources — et, par conséquent, un grand nombre de flux —, ces contraintes peuvent rapidement devenir des goulots d’étranglement dans la diffusion vidéo en continu. Atteindre les limites de bande passante et manquer de mémoire sont deux façons communes serveurs frapper la capacité maximale lors de la diffusion en continu.
Heureusement, il existe quelques pratiques exemplaires que vous pouvez suivre pour éviter d’atteindre la surcharge de serveur. Ces quatre conseils vous aideront à choisir le matériel de serveur multimédia qui répond à vos demandes de diffusion en continu.
Table of Contents
Conseil #1 : Déterminez votre nombre de flux entrants et comment ils seront emballés
La capacité de traitement d’un serveur est affectée par l’unité centrale de traitement (UC) et la mémoire disponible (mémoire vive d’accès aléatoire). Pour éviter les surcharges causées par les limitations de la capacité de traitement, vous devez savoir combien de flux votre serveur aura à traiter simultanément, et combien de mémoire cela nécessitera.
Combien de flux avez-vous besoin pour transcoder?
Toutes les tâches de traitement ne requièrent pas la même puissance de traitement. Après avoir compris le nombre de flux entrants que votre serveur devra gérer, vous devez indiquer comment vous prévoyez d’emballer vos flux pour la livraison.
Les tâches de codage et de transcodage des supports sont intrinsèquement des processus à forte intensité de processeur. Par exemple, l’exécution de quelque chose comme Flash Media Live Encoder (FMLE) dans un environnement de bureau consomme jusqu’à 80 pour cent d’un seul processeur de base.
La quantité de CPU nécessaire pour les tâches traditionnelles de transcodage varie cependant. « Transcodage » peut se référer à la modification des codecs (p. ex., conversion de VP8 en H.264), ou à la conversion d’un flux pour un débit adaptatif, ou à la livraison « ABR », (p. ex., conversion d’un seul flux de débit binaire en quatre rendus). Bien que les deux travaux consommeront CPU, flux de transrating pour la livraison ABR utilisera beaucoup plus.
Alternativement, parfois un flux de travail ne nécessitera qu’un flux à transmettre (par exemple, convertir un seul flux RTMP en HLS). C’est ce qu’on appelle le « traitement de passage », une tâche qui exige beaucoup moins de CPU pour l’emballage.
Si vous avez besoin de transcode plusieurs flux pour la livraison ABR, vous aurez besoin d’un serveur avec une plus grande capacité de traitement. Le nombre de flux qu’un serveur donné peut transcoder varie considérablement. Cependant, nous comparons régulièrement les serveurs et les charges de travail pour aider les utilisateurs à comprendre à quoi s’attendre. Lisez notre dernier rapport de référence sur le transcodage pour en savoir plus.
Voici un exemple de configuration pour un flux de travail OTT (over-the-top) :
De combien de mémoire avez-vous besoin?
La mémoire consommée pendant les processus d’ingestion et d’empaquetage correspond généralement au nombre total de connexions de flux entrantes, qui sont visibles sous forme de processus Java. Plus vous avez de sources et de flux entrants, plus votre serveur aura besoin de capacité de traitement.
Conseil #2 : Estimer les flux simultanés de pointe à partir de votre serveur
Alors que la relation entre le débit binaire et la bande passante est à peu près la même pour l’ingestion et l’évacuation, le côté sortant devient un peu plus difficile. Pourquoi? Il n’est pas toujours facile de deviner le nombre de téléspectateurs que vous aurez, ou les rendus dont ces téléspectateurs auront besoin.
Pour éviter les surcharges liées à la bande passante, estimez la bande passante de pointe que votre serveur devra gérer. Voici un exemple de cas d’utilisation pour vous guider dans le processus :
Exemple : Estimation des flux simultanés de pointe
Supposons que vous utilisez un Data Center qui offre une capacité de débit maximale de 2 Go/s. Compte tenu de notre règle de 80 pour cent ci-dessus, cela signifie que vous devez planifier pour un tuyau de bande passante maximale de 1,6 Go/s.
Pour comprendre combien de flux vous pouvez placer dans un tuyau de 1,6 Go/s, vous devez d’abord estimer la taille moyenne des flux livrés aux téléspectateurs finaux. Notez que la résolution de flux de votre spectateur moyen peut être différente de celle de votre flux source. Si vous transcodez votre flux source vers le bas à des rendus plus petits, les téléspectateurs peuvent regarder un flux 40 pour cent plus petit que la source du flux (quand il s’agit de flux sortants, nous sommes le plus concernés par la taille du flux du téléspectateur moyen).
En supposant 30 images par seconde, voici quelques bonnes lignes directrices pour la taille du Stream :
Stream Resolution | Streaming Bitrate |
8K | 21 – 50 Mbps |
4K | 13 – 34 Mbps |
1080p | 3 – 6 Mbps |
720p | 1.5 – 4 Mbps |
420p | 0.5 – 2 Mbps |
360p | 0.4 – 1 Mbps |
En utilisant la taille moyenne de flux de visionnement que vous avez déterminée, vous pouvez maintenant estimer vos besoins en bande passante. Pour ce faire, il suffit de multiplier le débit du flux par le nombre maximal de flux :
débit de flux * nombre de flux simultanés de pointe 80 % de la bande passante totale disponible
Pour continuer avec notre exemple, voici quelques scénarios pour les connexions de pics, compte tenu des différentes tailles de flux de visionneuse moyenne :
Average Viewer
Stream Size |
Total Viewers | Outbound
Bandwidth |
Useable
Bandwidth |
Total Pipe |
1080p @ 6 Mbps | 258 | 1.55 Gbps | 1.6 Gbps | 2 Gbps |
720p @ 2 Mbps | 775 | 1.55 Gbps | 1.6 Gbps | 2 Gbps |
360p @ 0.5 Mbps | 3,100 | 1.55 Gbps | 1.6 Gbps | 2 Gbps |
Gardez à l’esprit que vous devez également tenir compte de votre bande passante du flux entrant. Bien qu’il s’agisse généralement d’un faible pourcentage de vos flux simultanés totaux, dans des scénarios comportant un grand nombre de un-à-un ou un-à-plusieurs diffusions, la bande passante pour les flux entrants peut vraiment s’additionner.
Enfin, si ce calcul révèle que la bande passante de votre serveur est insuffisante, vous pouvez utiliser un réseau de diffusion de contenu (CDN), comme ISC CDN, pour offrir des flux à n’importe quel public. La fonctionnalité Stream Targets vous permet d’envoyer un seul flux ou un groupe de rendus de flux transcodés de ISC Streaming Engine à ISC CDN à n’importe quel nombre de téléspectateurs.
Conseil #3 : Choisissez le bon modèle de déploiement
Une autre considération est de savoir s’il faut se déployer sur une infrastructure en nuage ou sur place à l’aide d’un serveur matériel « entièrement métallique ». Le déploiement de l’informatique en nuage présente de nombreux avantages, notamment une utilisation plus efficace des ressources et une réduction des frais généraux.
Cependant, l’infrastructure en nuage utilise également des piles de logiciels de virtualisation et de gestion de l’orchestration, ce qui ajoute une charge de travail supplémentaire aux ressources physiques, y compris le processeur, le réseau et la mémoire vive. Combinés à des pratiques courantes de surréservation, ces frais généraux réduiront la charge utilisable sur une machine virtuelle donnée.
Par contre, une configuration en métal nu permet généralement une plus grande capacité de traitement. Sur un serveur entièrement métallique, vous pouvez vous attendre à utiliser jusqu’à 80 pour cent de la bande passante totale du réseau, et même des pourcentages plus élevés de CPU. Dans des déploiements virtualisés et en nuage comparables, les processeurs utilisables dépassent généralement les 65 pour cent, et les réseaux accessibles autour de 50 pour cent.
Bien que les configurations en métal nu aient l’avantage d’une plus grande disponibilité des ressources, les environnements en nuage virtualisés sont flexibles, faciles à utiliser et offrent des capacités libre-service. Pour bien des gens, ces aspects positifs l’emportent sur les aspects négatifs.
Conseil no 4 : Utiliser les réseaux de déchargement et de livraison de contenu du GPU
Pour tirer le meilleur parti de la capacité de traitement de votre serveur, il ya quelques autres capacités d’infrastructure que vous pouvez faire usage de : GPU déchargement et CDN.
Déchargement et accélération du GPU
Wowza Streaming Engine prend en charge l’utilisation de graphiques-processeur déchargement des charges de travail transcoder, de sorte que vous pouvez maximiser votre puissance de traitement. En utilisant la mise à l’échelle du GPU, les utilisateurs des configurations cloud et bare-metal ont réussi à décharger jusqu’à 75 pour cent de leur charge de travail de transcodage CPU.
Réseaux de diffusion de contenu
Employer et pousser des flux vers un CDN est l’un des moyens les plus courants de supprimer un goulot d’étranglement avec un seul serveur. À l’aide d’un CDN, il est possible de réduire les flux sortants à un seul flux pour chaque rendu.
Comme mentionné, vous pouvez utiliser la fonctionnalité Stream Targets dans Wowza Streaming Engine pour pousser un flux simple ou multi-débit à Wowza CDN pour augmenter efficacement la distribution de flux à un public mondial. Cela prend le fardeau de la livraison hors de votre serveur, de sorte que vous pouvez diffuser à un plus grand nombre de téléspectateurs concurrents sans se soucier d’atteindre votre capacité de bande passante.
Il est important de noter que les options de configuration dans votre CDN – y compris le rapport de perte de mémoire cache et le temps de mise en ligne (TTL) pour le contenu mis en cache – peuvent augmenter considérablement le nombre de requêtes à votre serveur Wowza Streaming Engine.
Bien qu’ils ne soient pas définitifs ou absolus, nous espérons que ces conseils vous aideront à affiner vos options et à dimensionner vos ressources de serveur de manière appropriée. Même après le dimensionnement, nous vous recommandons fortement de tester la performance sous charge, et/ou d’utiliser une pile de virtualisation/orchestration qui vous permet d’ajuster et d’ajouter des ressources.