Daire Byrne est le chef mondial des systèmes chez DNEG. Il est titulaire à la fois du baccalauréat en sciences et physique expérimentale de l’University College Dublin et d’une maîtrise en sciences optoélectroniques du Trinity College Dublin.
Fort de plus de 18 ans d’expérience dans l’industrie, Daire a commencé sa carrière chez Framestore en 2002 en tant qu’administrateur principal des systèmes avant de rejoindre DNEG en 2009 en tant qu’architecte principal des systèmes. Dans son rôle de chef mondial des systèmes qu’il occupe depuis 2018, Daire dirige une petite équipe d’ingénieurs et d’architectes principaux des systèmes qui s’occupent des infrastructures informatiques de base, du stockage évolutif, des systèmes de rendu des fermes, ainsi que de la recherche et du développement sur les nouvelles technologies d’infrastructure informatique.
La version 5.11 du (puissant) Linux kernel a récemment été publiée avec de nouvelles fonctionnalités et des correctifs auxquels DNEG a contribué, la « réexportation NFS » étant désormais un mode de fonctionnement officiellement pris en charge. Découvrez comment Daire et l’équipe Systèmes de DNEG ont travaillé avec la communauté de développement NFS de Linux pour optimiser ses exigences en matière de rendu en nuage.
*** Avertissement : Passons aux éléments techniques ***
Cloud Rendering chez DNEG
Comme tous les principaux studios d’effets visuels, DNEG utilise de grandes « fermes de rendu » composées de nombreux ordinateurs, d’unités centrales et de dispositifs stockage pour produire nos étonnants rendus d’images finales.
Bien que DNEG dispose de fermes de rendu locales assez importantes dans tous nos emplacements à l’échelle mondiale, il arrive qu’à l’approche d’une échéance, nous ayons besoin d’un surcroît de rendu en utilisant des instances de calcul dans le nuage pour mener à bien un projet. Comme l’ensemble de notre stockage est hébergé en local, l’utilisation de l’informatique en nuage pose des problèmes particuliers, car il faut s’assurer que toutes les données nécessaires au rendu sont également disponibles pour les instances informatiques en nuage, qu’elles soient hébergées en local ou à distance.
Nos applications de création de contenu numérique reposent encore largement sur des systèmes de fichiers POSIX sur le stockage en bloc. Traditionnellement, cela n’est pas idéal pour interagir avec les services en nuage. La latence des opérations sur les métadonnées POSIX peut ralentir considérablement le transfert de données sur Internet et nos connexions RPV vers le nuage sont limitées en bande passante. Il existe généralement deux stratégies principales pour traiter ce problème de stockage en nuage.
Explorer nos options
Nous pourrions transférer et répliquer à l’avance tous les fichiers dont les rendus auront besoin vers des serveurs de stockage en nuage (p. ex., des serveurs NFS) qui serviront ensuite toutes les instances de calcul des clients. Étant donné que les images de rendu lisent la plupart des mêmes données par processus de rendu (géométrie, textures, etc.), nous pouvons téléverser en une seule fois un grand ensemble de données qui seront ensuite utilisées par plusieurs clients. Ce processus de prétraitement des rendus pour déterminer tous les fichiers nécessaires peut cependant être difficile et prendre du temps dans un pipeline qui évolue rapidement. Le transfert de l’intégralité d’un fichier ne constitue pas forcément l’option la plus efficace, si seulement une petite partie de ce fichier est réellement nécessaire pour un rendu (les parties peuvent varier en fonction de l’endroit où pointe la caméra de la scène). Nous devons également transférer tous les fichiers obtenus une fois le rendu terminé, ce qui constitue une étape supplémentaire.
La méthode alternative permettant de transmettre les données aux infrastructures en nuage consiste à lire directement et « sur demande » les données à partir du stockage local. Cependant, si toutes les instances de calcul faisaient de même, elles liraient la plupart du temps toujours les mêmes fichiers, ce qui saturerait rapidement la liaison montante de notre réseau vers le nuage. Ce dont nous avons besoin, c’est d’un système de stockage en nuage qui se trouve au milieu et qui met en cache les données lues à partir du stockage local, puis qui sert ces données en cache à toutes les instances en nuage. Ainsi, la première lecture provient directement du stockage local, mais toutes les demandes de lecture ultérieures pour les mêmes données à partir des instances en nuage sont ensuite transmises par un serveur de stockage en nuage local. Toutes les écritures passent par le serveur de cache du stockage en nuage et sont renvoyées directement vers le stockage local.
Ce type de système est souvent appelé « accélération du réseau étendu » ou « mise en cache du filtre ». Tant que votre charge de travail consiste principalement en des lectures de données d’actifs communs, il peut s’agir d’un moyen très efficace de combiner les instances en nuage et le rendu local sans avoir à faire trop de travail supplémentaire.
NFS de Linux
Notre stockage local principal est entièrement basé sur Linux et nos fermes de rendu Linux utilisent donc les implémentations du serveur et du client NFS de Linux pour déplacer nos données. Ainsi, lorsque nous avons appris que la version 4.13 du noyau Linux principal avait introduit la possibilité de « réexporter » un soutien client NFS (open-by-handle), nous avons commencé à étudier si cela pouvait être utilisé pour réexporter notre stockage local vers le nuage. Le noyau Linux a déjà la capacité de mettre en cache les lectures des clients NFS sur le disque en utilisant fscache/cachefiles depuis de nombreuses années, alors pourrions-nous combiner cela avec cette nouvelle capacité de réexportation?
Adapter Linek kenel à nos besoins
Avec l’aide de la communauté des développeurs du NFS de Linux, nous avons d’abord dû passer un peu de temps sur le fscache/cachefiles pour le rendre stable sur les noyaux principaux. Une fois cela fait, nous avons pu configurer un serveur NFS Linux basé sur le nuage et lui faire monter notre stockage local en utilisant l’option « fsc » pour mettre en cache les lectures NFS sur le stockage local. Nous avons ensuite pu configurer les exportations NFS de ces montages et demander à nos instances de calcul en nuage de les monter. Cette méthode a bien fonctionné pour nous et nous a aidés à réaliser plusieurs de nos projets au cours des dernières années.
Cependant, elle présentait encore divers problèmes de performance et de stabilité qui la rendaient impropre à un usage général. L’idée de réexporter un montage client du noyau Linux en utilisant le serveur du noyau Linux n’était toujours pas une configuration supportée ou recommandée après tout. Nous avions tout de même réussi à cataloguer la plupart des problèmes et nous avons donc approché la communauté des développeurs NFS de Linux une fois de plus avec nos résultats dans l’espoir qu’ils pourraient être affinés et devenir un mode d’opération pris en charge que d’autres pourraient aussi utiliser.
Lancement de Linux version 5.11
L’industrie des effets visuels doit beaucoup au travail des développeurs du noyau Linux et des développeurs et des spécialistes en maintenance de NFS en particulier. La plupart de nos systèmes distribués reposent sur les performances et la stabilité du client NFS de Linux. Lorsque les développeurs ont manifesté de l’intérêt pour notre cas d’utilisation de réexportation et ont commencé à fournir des correctifs à tester, nous avons fourni des commentaires en retour et les performances et la stabilité de notre installation se sont rapidement améliorées au fur et à mesure que les correctifs étaient affinés.
Depuis Linux version 5.11, la réexportation NFS d’un client NFS est maintenant un mode d’opération pris en charge et les performances devraient être assez bonnes sans travail supplémentaire. Combiné avec fscache/cachefiles, cela fait un très bon « accélérateur du réseau étendu » pour les systèmes de fichiers NFS. Si vous souhaitez l’essayer et découvrir des bogues ou des problèmes de performance, engagez-vous auprès de la communauté des développeurs NFS de Linux, qui sera sans doute ravie de vous aider!