Créer une ferme de rendu hybride

Cet article explique comment étendre votre ferme de rendu sur site existante pour utiliser des ressources de calcul sur Google Cloud. Dans cet article, nous partons du principe que vous avez déjà mis en œuvre une ferme de rendu sur site, et que vous maîtrisez les concepts de base des effets visuels (VFX) et des pipelines d'animation, des logiciels de gestion des files d'attente et des méthodes courantes de gestion des licences logicielles.

Présentation

Le rendu d'éléments 2D ou 3D destinés à l'animation, aux films, aux publicités ou aux jeux vidéo est un processus qui demande beaucoup de temps et de ressources de calcul. Le rendu de ces éléments nécessite un investissement important en matériel et en infrastructure, ainsi qu'une équipe de professionnels de l'informatique dédiée au déploiement et à la gestion du matériel et des logiciels.

Lorsqu'une ferme de rendu sur site est à 100 % de son utilisation, la gestion des tâches peut s'avérer fastidieuse. Les priorités et les dépendances des tâches, le redémarrage des cadres supprimés ainsi que la charge du réseau, du disque et du processeur font tous partie de l'équation complexe que vous devez surveiller et contrôler de près, souvent dans des délais serrés.

Dans le but de gérer ces tâches, les installations VFX ont intégré un logiciel de gestion des files d'attente dans leurs pipelines. Ce logiciel peut :

  • déployer des tâches sur des ressources sur site et basées dans le cloud ;
  • gérer les dépendances entre les tâches ;
  • communiquer avec les systèmes de gestion des éléments ;
  • fournir aux utilisateurs une interface et des API pour les langages courants tels que Python.

Certains logiciels de gestion des files d'attente peuvent déployer des tâches sur des nœuds de calcul basés dans le cloud, mais vous êtes toujours responsable de la connexion au cloud, de la synchronisation des éléments, du choix de l'infrastructure de stockage, de la gestion des modèles d'images et de la spécification de vos propres licences logicielles.

Certaines installations de petite ou moyenne taille ne possédant pas les ressources techniques nécessaires à la mise en œuvre d'une ferme de rendu hybride peuvent utiliser le service de ferme de rendu de Google, Zync. Pour vous aider à choisir la solution idéale pour votre installation, adressez-vous à votre représentant GCP.

Remarque : Des notes de production s'affichent régulièrement tout au long de cet article. Elles mettent en avant les bonnes pratiques à suivre lors de la création de votre ferme de rendu.

Se connecter au cloud

En fonction de votre charge de travail, déterminez le mode de connexion de votre installation à Google Cloud, que ce soit par l'intermédiaire d'un fournisseur d'accès Internet partenaire, d'une connexion directe ou de l'Internet public.

Se connecter via Internet

Sans connectivité spéciale, vous pouvez vous connecter au réseau de Google et utiliser notre modèle de sécurité de bout en bout en accédant aux services Google Cloud via Internet. Les utilitaires tels que les outils de ligne de commande gcloud et gsutil ainsi que les ressources comme l'API Compute Engine exploitent tous l'authentification, l'autorisation et le chiffrement pour vous aider à protéger vos données.

Cloud VPN

Quelle que soit la méthode retenue, nous vous recommandons d'utiliser un réseau privé virtuel (VPN) pour sécuriser votre connexion.

Cloud VPN vous aide à connecter de façon sécurisée votre réseau sur site au réseau cloud privé virtuel (VPC) de Google via une connexion VPN IPsec. Les données en transit sont chiffrées avant de passer par un ou plusieurs tunnels VPN.

Découvrez comment créer un VPN pour votre projet.

VPN fourni par le client

Bien que vous puissiez configurer votre propre passerelle VPN pour vous connecter directement à Google, nous vous recommandons d'utiliser Cloud VPN, qui offre davantage de flexibilité et une meilleure intégration à Google Cloud.

Cloud Interconnect

Nous vous proposons plusieurs options pour connecter votre infrastructure à Google Cloud. Ces connexions conçues pour les entreprises, connues collectivement sous le nom de Cloud Interconnect, offrent une plus grande disponibilité et une plus faible latence que les connexions Internet standards, ainsi que des tarifs de sortie réduits.

Interconnexion dédiée

L'interconnexion dédiée fournit des connexions physiques directes ainsi qu'une communication RFC 1918 entre votre réseau sur site et le réseau de Google. Elle offre une capacité de connexion sur les types de connexion suivants :

  • Une ou plusieurs connexions Ethernet 10 Gbit/s, avec un maximum de huit connexions (soit 80 Gbit/s au total) par interconnexion
  • Une ou plusieurs connexions Ethernet 100 Gbit/s, avec un maximum de deux connexions (soit 200 Gbit/s au total) par interconnexion

Le trafic de l'interconnexion dédiée n'est pas chiffré. Par conséquent, si vous devez transmettre des données de manière sécurisée, vous devez établir votre propre connexion VPN. Cloud VPN n'est pas compatible avec l'interconnexion dédiée. Dans ce cas, vous devez donc fournir votre propre VPN.

Interconnexion partenaire

L'interconnexion partenaire fournit une connectivité entre votre réseau sur site et votre réseau VPC via un fournisseur de services agréé. Une interconnexion partenaire est utile si votre infrastructure se situe à un emplacement physique qui ne peut pas bénéficier d'une interconnexion dédiée depuis une installation hébergée en colocation ou lorsqu'une connexion intégrale de 10 Gbit/s n'est pas justifiée par rapport à vos besoins.

Autres types de connexions

Il est possible que d'autres méthodes de connexion à Google soient disponibles dans votre pays. Pour obtenir de l'aide afin de déterminer la méthode la plus économique et la plus efficace pour vous connecter à Google Cloud, adressez-vous à votre représentant GCP.

Sécuriser votre contenu

Pour exploiter leur contenu sur n'importe quelle plate-forme cloud publique, les propriétaires de contenu comme les grands studios hollywoodiens exigent des fournisseurs qu'ils se conforment aux bonnes pratiques de sécurité, définies à la fois en interne et par des organisations telles que la MPAA.

Bien que les exigences de chaque studio diffèrent légèrement, vous trouverez à la section Sécuriser les charges de travail de rendu les bonnes pratiques courantes concernant la création d'une ferme de rendu hybride. Vous pouvez également consulter des livres blancs sur la sécurité et des documents relatifs à la conformité sur cloud.google.com/security.

Pour toute question sur le processus d'audit conformité/sécurité, adressez-vous à votre représentant GCP.

Organiser vos projets

Les projets constituent le composant organisationnel principal de Google Cloud. Dans votre installation, vous pouvez organiser les tâches au sein de leur propre projet ou les diviser en plusieurs projets. Par exemple, vous pouvez créer des projets distincts pour les phases de prévisualisation, de recherche-développement et de production d'un film.

Les projets établissent une limite d'isolation pour les données du réseau et l'administration de projets. Toutefois, vous pouvez partager des réseaux sur plusieurs projets à l'aide d'un VPC partagé, ce qui permet à des projets distincts d'accéder à des ressources communes.

Notes de production : Créez un projet hôte de VPC partagé contenant les ressources avec tous vos outils de production. Vous pouvez désigner tous les projets créés dans votre organisation en tant que projets de service VPC partagé. Cette désignation signifie que tout projet de votre organisation peut accéder aux mêmes bibliothèques, scripts et logiciels fournis par le projet hôte.

Ressource "Organisation"

Vous pouvez gérer des projets sous une ressource "Organisation" que vous avez peut-être déjà définie. La migration de tous vos projets au sein d'une organisation offre de nombreux avantages.

Notes de production : Désignez les responsables de production en tant que propriétaires de leurs projets individuels et les directeurs du studio en tant que propriétaires de la ressource "Organisation".

Définir l'accès aux ressources

Les projets nécessitent un accès sécurisé aux ressources, qui s'accompagne de restrictions concernant l'emplacement auquel les utilisateurs ou les services sont autorisés à effectuer des opérations. Pour vous aider à configurer l'accès, Google Cloud propose la gestion de l'authentification et des accès (IAM), qui vous permet de gérer le contrôle des accès en définissant quels rôles disposent de quels niveaux d'accès à des ressources spécifiques.

Notes de production : Pour limiter l'accès des utilisateurs aux seules ressources nécessaires à l'exécution de tâches spécifiques suivant leur rôle, appliquez le principe du moindre privilège à la fois sur site et dans le cloud.

Prenons l'exemple d'un nœud de calcul de rendu, à savoir une machine virtuelle (VM) que vous pouvez déployer à partir d'un modèle d'instance prédéfini reprenant votre image personnalisée. Le nœud de calcul de rendu qui s'exécute sous un compte de service peut effectuer des opérations de lecture à partir de Cloud Storage et des opérations d'écriture sur un élément de stockage attaché, tel qu'un serveur cloud ou un disque persistant. Toutefois, il n'est pas nécessaire d'ajouter des artistes individuels aux projets Google Cloud, car ils n'ont pas besoin d'un accès direct aux ressources cloud.

Vous pouvez attribuer des rôles aux responsables du rendu ou aux administrateurs de projet ayant accès à toutes les ressources Compute Engine, ce qui leur permet d'exécuter des fonctions sur des ressources inaccessibles aux autres utilisateurs.

Définissez une stratégie pour déterminer quels rôles peuvent accéder à quels types de ressources dans votre organisation. Le tableau suivant montre comment les tâches de production classiques sont mappées avec les rôles IAM dans Google Cloud.

Tâche de production Nom du rôle Type de ressource
Responsable studio resourcemanager.organizationAdmin Organisation
Projet
Responsable de la production owner editor Projet
Responsable du rendu compute.admin iam.serviceAccountActor Projet
Compte de gestion des files d'attente compute.admin iam.serviceAccountActor Organisation
Projet
Artiste individuel [aucun accès] Non applicable

Champs d'application de l'accès

Les champs d'application de l'accès vous permettent de contrôler les autorisations d'une instance en cours d'exécution, indépendamment des utilisateurs connectés. Vous pouvez spécifier des champs d'application lorsque vous créez vous-même une instance ou lorsque votre logiciel de gestion des files d'attente déploie des ressources à partir d'un modèle d'instance.

Les champs d'application sont prioritaires par rapport aux autorisations IAM d'un utilisateur individuel ou d'un compte de service. Cette priorité signifie qu'un champ d'application de l'accès peut empêcher un administrateur de projet de se connecter à une instance pour supprimer un bucket de stockage ou modifier un paramètre de pare-feu.

Notes de production : Par défaut, les instances peuvent lire, mais pas écrire sur Cloud Storage. Si votre pipeline de rendu écrit les rendus finis dans Cloud Storage, ajoutez le niveau d'accès devstorage.read_write à votre instance au moment de la création.

Choisir comment déployer des ressources

Le rendu cloud vous permet de n'utiliser les ressources qu'en cas de besoin, mais vous pouvez choisir parmi plusieurs méthodes pour rendre les ressources disponibles pour votre ferme de rendu.

Déployer à la demande

Pour une utilisation optimale des ressources, vous pouvez choisir de ne déployer des nœuds de calcul de rendu que lorsque vous envoyez une tâche à la ferme de rendu. Vous pouvez déployer de nombreuses VM à partager sur tous les cadres d'une tâche ou même créer une VM par cadre.

Votre système de gestion des files d'attente peut surveiller les instances en cours d'exécution, qui peuvent être remises en file d'attente si une VM est préemptée ou arrêtées lorsque des tâches individuelles sont terminées.

Déployer un pool de ressources

Vous pouvez également choisir de déployer un groupe d'instances, non liées à une tâche spécifique, auxquelles votre système de gestion des files d'attente sur site peut accéder en tant que ressources supplémentaires. Bien que moins rentable qu'une stratégie à la demande, un groupe d'instances en cours d'exécution peut accepter plusieurs tâches par VM, en utilisant tous les cœurs et en maximisant l'utilisation des ressources. Cette approche constitue peut-être la stratégie la plus simple à mettre en œuvre, car elle imite la manière dont une ferme de rendu sur site est remplie de tâches.

Gérer les licences logicielles

La gestion des licences tierces peut varier considérablement d'un package à l'autre. Voici quelques schémas de gestion des licences et modèles que vous pouvez rencontrer dans un pipeline VFX. Pour chaque schéma, la troisième colonne indique l'approche recommandée.

Schéma Description Recommandation
Nœud verrouillé Licence accordée à une adresse MAC, une adresse IP ou un ID de processeur spécifique. Ne peut être exécutée que par un seul processus. Licence basée sur l'instance
En fonction des nœuds Licence accordée à un nœud spécifique (instance). Un nombre arbitraire d'utilisateurs ou de processus peuvent s'exécuter sur un nœud sous licence. Licence basée sur l'instance
Licence flottante Licence extraite d'un serveur de licences qui garde une trace de son utilisation. Serveur de licences
Licences logicielles
Licence interactive Permet à l'utilisateur d'exécuter le logiciel de manière interactive dans un environnement graphique. Serveur de licences ou licence basée sur l'instance
Par lot Permet à l'utilisateur de n'exécuter le logiciel que dans un environnement de ligne de commande. Serveur de licences
Licences basées sur le cloud
En fonction de l'utilisation Licence extraite uniquement lorsqu'un processus s'exécute sur une instance cloud. Lorsque le processus se termine ou est arrêté, la licence est diffusée. Serveur de licences basées sur le cloud
En fonction de la disponibilité Licence extraite lorsqu'une instance est active et en cours d'exécution. Lorsque l'instance est arrêtée ou supprimée, la licence est renvoyée. Serveur de licences basées sur le cloud

Utiliser des licences basées sur l'instance

Certains logiciels ou plug-ins sont concédés sous licence directement au matériel sur lequel ils s'exécutent. Cette approche peut poser problème dans le cloud, où des identifiants matériels tels que des adresses MAC ou IP sont attribués de manière dynamique.

Adresses MAC

Lors de leur création, les instances se voient attribuer une adresse MAC qui est conservée tant que l'instance n'est pas supprimée. Même si vous arrêtez ou redémarrez l'instance, l'adresse MAC est conservée. Vous pouvez utiliser cette adresse MAC pour créer et valider une licence jusqu'à la suppression de l'instance.

Attribuer une adresse IP statique

Lorsque vous créez une instance, une adresse IP interne et, éventuellement, une adresse IP externe lui sont attribuées. Pour conserver l'adresse IP externe d'une instance, vous pouvez réserver une adresse IP statique et l'attribuer à votre instance. Cette adresse IP sera réservée pour cette instance uniquement. Comme les adresses IP statiques sont des ressources basées sur un projet, elles sont soumises à des quotas régionaux.

Vous pouvez également attribuer une adresse IP interne lors de la création d'une instance, ce qui peut s'avérer utile si vous souhaitez que les adresses IP internes d'un groupe d'instances appartiennent à la même plage.

Dongles matériels

Les logiciels plus anciens peuvent toujours être concédés sous licence via un dongle, c'est-à-dire une clé matérielle programmée avec une licence de produit. La plupart des éditeurs de logiciels ont cessé d'utiliser des dongles matériels, mais certains utilisateurs peuvent disposer de logiciels anciens associés à un périphérique de ce type. Si vous rencontrez ce problème, adressez-vous au fabricant du logiciel pour savoir s'il peut vous fournir une licence mise à jour.

Si le fabricant du logiciel ne peut pas fournir une telle licence, vous pouvez opter pour un hub USB rattaché au réseau ou une solution USB via IP.

Utiliser un serveur de licences

La plupart des logiciels modernes proposent une option de licence flottante. Cette option est la plus adaptée à un environnement cloud, mais elle nécessite une gestion des licences et un contrôle des accès renforcés pour éviter la surconsommation d'un nombre limité de licences.

Pour éviter de dépasser votre capacité, vous pouvez choisir les licences à utiliser et contrôler le nombre de tâches utilisant des licences dans le cadre de votre processus de file d'attente.

Serveur de licences sur site

Vous pouvez utiliser votre serveur de licences sur site existant pour fournir des licences aux instances qui s'exécutent dans le cloud. Si vous choisissez cette méthode, vous devez fournir à vos nœuds de calcul de rendu un moyen de communiquer avec votre réseau sur site, via un VPN ou une autre connexion sécurisée.

Serveur de licences basées sur le cloud

Dans le cloud, vous pouvez exécuter un serveur de licences desservant des instances sur votre projet ou même sur plusieurs projets à l'aide d'un VPC partagé. Les licences flottantes étant parfois associées à une adresse MAC matérielle, une petite instance à exécution longue avec une adresse IP statique peut facilement distribuer des licences à de nombreuses instances de rendu.

Serveur de licences hybride

Certains logiciels peuvent utiliser plusieurs serveurs de licences par ordre de priorité. Par exemple, un moteur de rendu peut interroger le nombre de licences disponibles sur un serveur sur site et, si aucune licence n'est disponible, utiliser un serveur de licences basées sur le cloud. Cette stratégie peut vous aider à optimiser l'utilisation de licences permanentes avant d'extraire d'autres types de licences.

Notes de production : Définissez un ou plusieurs serveurs de licences dans une variable d'environnement, ainsi que l'ordre de priorité. Le moteur de rendu populaire Autodesk Arnold peut vous y aider. Si la tâche ne peut pas acquérir de licence depuis le premier serveur, elle essaie d'utiliser les autres serveurs répertoriés, comme dans l'exemple suivant :

export solidangle_LICENSE=5053@x.x.0.1;5053@x.x.0.2

Dans l'exemple précédent, le moteur de rendu Arnold tente d'obtenir une licence depuis le serveur à l'adresse x.x.0.1, port 5053. Si cette tentative échoue, il tente ensuite d'obtenir une licence depuis le même port à l'adresse IP x.x.0.2.

Licences basées sur le cloud

Certains fournisseurs proposent des licences logicielles basées sur le cloud, accordées à la demande pour vos instances. Ces licences sont généralement facturées de deux manières : en fonction de l'utilisation et en fonction de la disponibilité.

Licences basées sur l'utilisation

Les licences basées sur l'utilisation sont facturées en fonction du temps d'utilisation du logiciel. En règle générale, une licence de ce type est extraite d'un serveur basé sur le cloud au démarrage du processus et est renvoyée à la fin du processus. Tant que la licence n'est pas renvoyée, son utilisation vous est facturée. Ce type de licence est couramment utilisé pour les logiciels de rendu.

Licences basées sur la disponibilité

Les licences mesurées ou basées sur la disponibilité sont facturées en fonction de la disponibilité de votre instance Compute Engine. L'instance est configurée de manière à s'inscrire auprès du serveur de licences basées sur le cloud lors du processus de démarrage. Tant que l'instance est en cours d'exécution, la licence est utilisée. Lorsque l'instance est arrêtée ou supprimée, la licence est renvoyée. Ce type de licence est couramment utilisé pour les tâches de rendu déployées par un gestionnaire de files d'attente.

Choisir comment stocker vos données

Le type de stockage que vous choisissez sur Google Cloud dépend de votre stratégie de stockage ainsi que de facteurs tels que les exigences de durabilité et le coût. Pour en savoir plus sur Cloud Storage, consultez la page Serveurs de fichiers sur Compute Engine.

Disque persistant

Vous pouvez peut-être éviter complètement de mettre en œuvre un serveur de fichiers en intégrant des disques persistants à votre charge de travail. Les disques persistants constituent un type de stockage de blocs compatible avec POSIX, pouvant atteindre 64 To et compatible avec la plupart des installations VFX. Les disques persistants sont disponibles à la fois sous forme de disques standards et de disques durs SSD. Vous pouvez associer un disque persistant en mode lecture-écriture à une seule instance, ou en mode lecture seule à un grand nombre d'instances (par exemple, un groupe de nœuds de calcul de rendu).

Avantages Inconvénients Cas d'utilisation idéal
S'installe en tant que volume NFS ou SMB standard.

Peut être redimensionné de manière dynamique.

Il est possible d'associer jusqu'à 128 disques persistants à une seule instance.

Le même disque persistant peut être installé en lecture seule sur des centaines, voire des milliers d'instances.
Taille maximale de 64 To.

Opérations d'écriture possibles sur un disque persistant uniquement lorsqu'il est installé sur une seule instance.

N'est accessible que depuis des ressources situées dans la même région.
Pipelines avancés capables de créer un disque tâche par tâche.

Pipelines qui diffusent des données rarement mises à jour, comme des bibliothèques logicielles ou communes, sur les nœuds de calcul de rendu.

Stockage d'objets

Cloud Storage est une solution de stockage à redondance et à durabilité élevées qui, contrairement aux systèmes de fichiers traditionnels, est non structurée et offre une capacité pratiquement illimitée. Sur Cloud Storage, les fichiers sont stockés dans des buckets, semblables à des dossiers et accessibles dans le monde entier.

Contrairement aux solutions de stockage traditionnelles, le stockage d'objets ne peut pas être installé en tant que volume logique par un système d'exploitation. Si vous décidez d'intégrer le stockage d'objets à votre pipeline de rendu, vous devez modifier le mode de lecture et d'écriture des données, soit par le biais d'utilitaires de ligne de commande comme gsutil, soit via l'API Cloud Storage.

Avantages Inconvénients Cas d'utilisation idéal
Solution de stockage à disponibilité et durabilité élevées pour les fichiers de toutes tailles.

Une seule API pour plusieurs classes de stockage.

Bon marché.

Les données sont disponibles dans le monde entier.

Capacité presque illimitée.
Non compatible avec POSIX.

Accès via l'API ou l'utilitaire de ligne de commande.

Dans un pipeline de rendu, les données doivent être transférées au niveau local avant utilisation.
Pipelines de rendu avec un système de gestion des éléments pouvant publier des données sur Cloud Storage.

Pipelines de rendu avec un système de gestion des files d'attente pouvant récupérer des données depuis Cloud Storage avant le rendu.

Autres produits de stockage

D'autres produits de stockage sont disponibles sous forme de services gérés, via des canaux tiers tels que Cloud Marketplace ou sous forme de projets Open Source via des dépôts logiciels ou GitHub.

Produit Avantages Inconvénients Cas d'utilisation idéal
Elastifile, Cloud File System (ECFS) [Acquis par Google Cloud] Système de fichiers en cluster pouvant accepter des milliers de connexions NFS simultanées.

Capable de se synchroniser avec le cluster NAS sur site.
Bien que le stockage sur site ou la synchronisation dans le cloud soient disponibles, les données ne peuvent être synchronisées que dans une seule direction. Par exemple, ECFS sur site peut effectuer des opérations de lecture et d'écriture, mais ECFS basé sur le cloud est en lecture seule.

Impossible de sélectionner les fichiers à synchroniser. Pas de synchronisation bidirectionnelle.
Installations VFX moyennes à grandes avec plusieurs centaines de To de données à stocker dans le cloud.
Pixit Media, PixStor Système de fichiers évolutif pouvant accepter des milliers de clients NFS ou POSIX simultanés. Les données peuvent être mises en cache à la demande à partir d'un NAS sur site, les mises à jour étant automatiquement renvoyées vers le stockage sur site. Coût, assistance tierce fournie par Pixit. Installations VFX moyennes à grandes avec plusieurs centaines de To de données à stocker dans le cloud.
Filestore Solution de stockage entièrement gérée sur Google Cloud.

Simple à déployer et à gérer.
Maximum de 64 To par instance. Les performances NFS sont fixes et ne s'adaptent pas au nombre de clients actifs. Installations VFX petites à moyennes avec un pipeline capable de synchroniser les éléments.

Disque partagé entre des postes de travail virtuels.
Cloud Storage FUSE Installe les buckets Cloud Storage en tant que systèmes de fichiers. Économique. Système de fichiers non compatible avec POSIX. Peut être difficile à configurer et à optimiser. Installations VFX capables de déployer, de configurer et de gérer un système de fichiers Open Source, avec un pipeline pouvant synchroniser les éléments.

D'autres types de stockage sont disponibles sur Google Cloud. Pour plus d'informations, adressez-vous à votre représentant GCP.

Documentation complémentaire sur les options de stockage de données

Mettre en œuvre des stratégies de stockage

Vous pouvez mettre en œuvre un certain nombre de stratégies de stockage dans les pipelines de production VFX ou d'animation en établissant des conventions déterminant le traitement de vos données, que vous y accédiez directement depuis votre stockage sur site ou que vous réalisiez une synchronisation entre le stockage sur site et le cloud.

Stratégie 1 : Installer directement le stockage sur site

Installation du stockage sur site directement à partir de nœuds de calcul de rendu basés dans le cloud
Installer le stockage sur site directement à partir de nœuds de calcul de rendu basés dans le cloud

Si votre installation dispose d'une connectivité à Google Cloud d'au moins 10 Gbit/s et se trouve à proximité d'une région Google Cloud, vous pouvez choisir d'installer votre NAS sur site directement sur des nœuds de calcul de rendu dans le cloud. Bien que cette stratégie soit simple, elle peut également s'avérer coûteuse et gourmande en bande passante, car tout ce que vous créez sur le cloud et écrivez dans le stockage est comptabilisé en tant que sortie de données.

Avantages Inconvénients Cas d'utilisation idéal
Mise en œuvre simple.

Opérations de lecture/écriture dans l'espace de stockage commun.

Disponibilité immédiate des données, pas de mise en cache ni de synchronisation nécessaire.
Peut s'avérer plus coûteux que d'autres options.

La proximité d'un centre de données Google est nécessaire pour obtenir une faible latence.

Le nombre maximal d'instances que vous pouvez connecter à votre NAS sur site dépend de votre bande passante et de votre type de connexion.
Installations situées à proximité d'un centre de données Google ayant besoin d'utiliser les charges de travail de rendu en rafale dans le cloud, indépendamment du coût.

Installations avec une connectivité à Google Cloud d'au moins 10 Gbit/s.

Stratégie 2 : Synchroniser à la demande

Synchronisation des données à la demande entre le stockage sur site et le stockage basé dans le cloud
Synchronisation des données à la demande entre le stockage sur site et le stockage basé dans le cloud

Vous pouvez choisir de transférer (push) des données vers le cloud ou de les extraire (pull) d'un stockage sur site ou inversement, uniquement lorsque des données sont requises, par exemple lorsqu'un cadre est rendu ou qu'un élément est publié. Si vous utilisez cette stratégie, la synchronisation peut être déclenchée par un mécanisme de votre pipeline (tel qu'un script de surveillance), par un gestionnaire d'événements (comme Cloud Pub/Sub) ou par un ensemble de commandes dans le cadre d'un script de tâche.

Vous pouvez effectuer une synchronisation à l'aide de diverses commandes, telles que la commande gcloud scp, la commande gsutil rsync ou des protocoles de transfert de données basés sur UDP (UDT). Si vous choisissez d'utiliser un protocole UDT tiers comme Aspera, Cloud FastPath, BitSpeed ou FDT pour communiquer avec un bucket Cloud Storage, reportez-vous à la documentation du tiers concerné pour en apprendre davantage sur son modèle de sécurité et sur les bonnes pratiques à adopter. Google ne gère aucun de ces services tiers.

Méthode push

En règle générale, vous utilisez la méthode push lorsque vous publiez un élément, placez un fichier dans un dossier de surveillance ou effectuez une tâche de rendu, après quoi vous envoyez le résultat à un emplacement prédéfini.

Exemples :

  • Un nœud de calcul termine une tâche de rendu, et les cadres obtenus sont envoyés à l'espace de stockage sur site.
  • Un artiste publie un élément. Une partie du processus de publication des éléments implique l'envoi des données associées à un chemin d'accès prédéfini sur Cloud Storage.

Méthode pull

Vous utilisez la méthode pull lorsqu'un fichier est demandé, généralement par une instance de rendu basée dans le cloud.

Exemple : Dans le cadre d'un script de tâche de rendu, tous les éléments nécessaires au rendu d'une scène sont extraits dans un système de fichiers avant le rendu, et ainsi accessibles à tous les nœuds de calcul de rendu.

Avantages Inconvénients Cas d'utilisation idéal
Contrôle total concernant les données qui sont synchronisées et le moment de la synchronisation.

Possibilité de choisir la méthode et le protocole de transfert.
Votre pipeline de production doit être capable de gérer des événements pour déclencher des synchronisations push/pull.

Des ressources supplémentaires peuvent être nécessaires pour gérer la file d'attente de synchronisation.
Installations petites à grandes dotées de pipelines personnalisés et souhaitant un contrôle complet sur la synchronisation des éléments.

Notes de production : Gérez la synchronisation des données avec le même système de gestion des files d'attente que celui utilisé pour la gestion des tâches de rendu. Les tâches de synchronisation peuvent utiliser des ressources cloud distinctes pour optimiser la bande passante disponible et minimiser le trafic réseau.

Stratégie 3 : Stockage sur site et cache de lecture continue basé dans le cloud

Utilisation du stockage sur site avec un cache de lecture continue basé dans le cloud
Utilisation du stockage sur site avec un cache de lecture continue basé dans le cloud

Dans cette stratégie, vous mettez en œuvre un système de mise en cache virtuel dans le cloud qui joue un rôle à la fois de cache de lecture et de serveur de fichiers. Chaque nœud de calcul de rendu dans le cloud installe le dispositif de mise en cache sous le protocole NFS ou SMB comme il le ferait avec un serveur de fichiers conventionnel. Si un nœud de calcul de rendu lit un fichier qui n'est pas présent dans le cache, le fichier est transféré du stockage sur site vers le serveur de fichiers dans le cloud. En fonction de la configuration de votre serveur de fichiers en cache, les données restent dans le cache jusqu'à ce que :

  • les données vieillissent ou restent intactes pendant une période déterminée ;
  • l'espace sur le serveur de fichiers vienne à manquer, auquel cas les données sont supprimées du cache en fonction de leur âge.

Cette stratégie diminue la bande passante et la complexité inhérentes au déploiement de plusieurs instances de rendu simultanées.

Dans certains cas, vous pouvez préchauffer votre cache pour vous assurer que toutes les données relatives aux tâches sont présentes avant le rendu. Pour ce faire, lisez le contenu d'un répertoire situé sur votre serveur de fichiers cloud à l'aide d'une commande read ou stat exécutée sur un ou plusieurs fichiers. Cette opération déclenche le mécanisme de synchronisation.

Vous pouvez également ajouter un dispositif sur site physique pour communiquer avec le dispositif virtuel. Par exemple, NetApp propose une solution de stockage pouvant réduire davantage la latence entre votre stockage sur site et le cloud.

Avantages Inconvénients Cas d'utilisation idéal
Les données mises en cache sont gérées automatiquement.

Diminue la bande passante requise.

Les systèmes de fichiers cloud en cluster peuvent faire l'objet d'un scaling à la hausse ou à la baisse en fonction des exigences de la tâche.
Peut entraîner des coûts supplémentaires.

Des tâches préalables doivent être effectuées si vous décidez de préchauffer le cache.
Grandes installations qui déploient de nombreuses instances simultanées et lisent des éléments communs à de nombreuses tâches.

Filtrer les données

Vous pouvez créer une base de données de types d'éléments et de conditions associées pour déterminer si un type de données particulier doit être synchronisé. Il est possible que vous ne souhaitiez jamais synchroniser certains types de données, telles que les données éphémères générées dans le cadre d'un processus de conversion, les fichiers de cache ou les données de simulation. Déterminez également si les éléments non approuvés doivent être synchronisés, car toutes les itérations ne seront pas utilisées dans les rendus finaux.

Effectuer un transfert initial de manière groupée

Lors de la mise en œuvre de votre ferme de rendu hybride, vous souhaiterez peut-être effectuer un transfert initial de tout ou partie de votre ensemble de données vers Cloud Storage, un disque persistant ou une autre solution stockage basée dans le cloud. En fonction de facteurs tels que la quantité et le type de données à transférer et votre vitesse de connexion, vous pourrez peut-être effectuer une synchronisation complète au bout de quelques jours ou de quelques semaines. La figure suivante compare les temps d'exécution classiques pour les transferts en ligne et physiques.

Comparaison des temps d'exécution classiques pour les transferts en ligne et physiques
Comparaison des temps d'exécution classiques pour les transferts en ligne et physiques

Si la charge de travail de transfert dépasse vos contraintes de temps ou de bande passante, Google propose un certain nombre d'options de transfert de vos données vers le cloud, y compris Transfer Appliance.

Archivage et reprise après sinistre

Il est important de noter la différence entre l'archivage des données et la reprise après sinistre. Le premier est une copie sélective du travail fini, tandis que le second est un état des données pouvant être récupéré. Vous devez concevoir un plan de reprise après sinistre répondant aux besoins de votre installation et fournissant un plan d'urgence hors site. Consultez votre fournisseur de stockage sur site pour qu'il vous aide à déterminer le plan de reprise après sinistre adapté à votre plate-forme de stockage spécifique.

Archiver des données dans le cloud

Une fois le projet terminé, il est courant de conserver le travail terminé dans un espace de stockage à long terme, généralement un support sur bande magnétique tel que LTO. Ces cartouches sont soumises à des exigences environnementales et, avec le temps, peuvent s'avérer difficiles à gérer sur le plan logistique. Les grandes installations de production hébergent parfois l'intégralité de leurs archives dans une salle spécialement conçue à cet effet, avec un archiviste à temps plein, pour pouvoir effectuer le suivi des données et les récupérer à la demande.

La recherche d'archives spécifiques d'éléments, de plans ou de séquences peut prendre beaucoup de temps pour les raisons suivantes : les données peuvent être stockées sur plusieurs cartouches, l'indexation des archives peut être manquante ou incomplète, ou la vitesse de lecture des données sur bande magnétique peut être limitée.

La migration de vos archives de données vers le cloud peut non seulement éliminer la gestion et le stockage sur site des supports d'archives, mais elle peut également rendre vos données beaucoup plus accessibles et facilement consultables qu'avec les méthodes d'archivage traditionnelles.

Un pipeline d'archivage de base pourrait ressembler au schéma ci-dessous, exploitant différents services cloud pour examiner, classer, étiqueter et organiser des archives. Depuis le cloud, vous pouvez créer un outil de gestion et de récupération d'archives pour rechercher des données selon divers critères de métadonnées, tels que la date, le projet, le format ou la résolution. Vous pouvez également utiliser les API Machine Learning pour classer les images et les vidéos et leur attribuer des tags, en stockant les résultats dans une base de données basée dans le cloud comme BigQuery.

Pipeline d'archivage d'éléments faisant appel au machine learning pour classer le contenu
Pipeline d'archivage d'éléments faisant appel au machine learning pour classer le contenu

Vous pouvez envisager les autres options suivantes :

  • Automatisez la génération de vignettes ou de proxys pour le contenu résidant aux niveaux Cloud Storage Nearline, Cloud Storage Coldline ou Cloud Storage Archive. Utilisez ces proxys dans votre système de gestion d'éléments multimédias afin que les utilisateurs parcourent les données en ne lisant que les proxys, et non les éléments archivés.
  • Pensez à utiliser le machine learning pour classer le contenu des prises de vue réelles. Exploitez Cloud Vision pour ajouter des libellés aux textures et aux fonds d'arrière-plan, ou l'API Video Intelligence pour faciliter la recherche et la récupération de vidéos de référence.
  • Vous pouvez également utiliser AutoML Vision pour créer un modèle de vision personnalisé afin de reconnaître n'importe quel élément, qu'il s'agisse d'une prise de vue réelle ou d'un rendu.
  • Pour le contenu rendu, envisagez de sauvegarder une copie de l'image disque du nœud de calcul rendu parallèlement à l'élément rendu. Si vous devez recréer la configuration, vous disposez ainsi des versions logicielles, plug-ins, bibliothèques de système d'exploitation et dépendances disponibles corrects pour restituer un plan archivé.

Gérer les éléments et la production

Travailler sur le même projet dans plusieurs installations peut présenter des défis uniques, en particulier lorsque le contenu et les éléments doivent être disponibles dans le monde entier. La synchronisation manuelle des données sur des réseaux privés peut s'avérer coûteuse et gourmande en ressources. Elle est également soumise à des limites de bande passante locale.

Si votre charge de travail nécessite des données disponibles à l'échelle mondiale, vous pourrez peut-être utiliser Cloud Storage, qui est accessible depuis n'importe quel emplacement permettant d'accéder aux services Google. Pour intégrer Cloud Storage à votre pipeline, vous devez le modifier afin qu'il décode les chemins d'accès aux objets, puis extraire ou transmettre les données à vos nœuds de calcul de rendu avant d'initier le rendu. L'utilisation de cette méthode offre un accès mondial aux données publiées, mais nécessite que votre pipeline fournisse les éléments là où ils sont nécessaires dans un délai raisonnable.

Par exemple, un artiste en texture basé à Los Angeles peut publier des fichiers image destinés à être utilisés par un artiste en éclairage situé à Londres. Le processus est semblable à ce qui suit :

Publier des éléments sur Cloud Storage
Publier des éléments sur Cloud Storage
  1. Le pipeline de publication transfère les fichiers vers Cloud Storage et ajoute une entrée à une base de données d'éléments dans le cloud.
  2. Un artiste londonien exécute un script pour rassembler les éléments d'une scène. Les emplacements des fichiers sont interrogés depuis la base de données et lus depuis Cloud Storage sur le disque local.
  3. Le logiciel de gestion des files d'attente rassemble la liste des éléments nécessaires au rendu, les interroge depuis la base de données d'éléments, et les télécharge depuis Cloud Storage vers l'espace de stockage local de chaque nœud de calcul de rendu.

Utiliser Cloud Storage de cette manière vous donne également accès à une archive de toutes vos données publiées dans le cloud si vous décidez d'utiliser Cloud Storage dans le cadre de votre pipeline d'archives.

Gérer les bases de données

Les logiciels de gestion des éléments et de la production reposent sur des bases de données à durabilité et disponibilité élevées, diffusées sur des hôtes capables de traiter des centaines, voire des milliers de requêtes par seconde. Les bases de données sont généralement hébergées sur un serveur sur site qui s'exécute sur le même rack que les nœuds de calcul de rendu, et sont soumises aux mêmes limitations en matière d'alimentation, de réseau et de CVC.

Vous pouvez envisager d'exécuter vos bases de données de production MySQL, NoSQL et PostgreSQL en tant que services basés dans le cloud. Ces services sont hautement disponibles et accessibles dans le monde entier. Ils chiffrent les données au repos et en transit, et offrent une fonctionnalité de réplication intégrée.

Gérer les files d'attente

Les programmes logiciels de gestion des files d'attente disponibles sur le marché, comme Qube!, Deadline et Tractor sont largement utilisés dans l'industrie de l'animation/des effets visuels. Des options logicielles Open Source sont également disponibles, comme OpenCue. Vous pouvez choisir ces logiciels pour déployer et gérer n'importe quelle charge de travail de calcul sur plusieurs nœuds de calcul, et pas seulement pour les rendus. Vous pouvez déployer et gérer la publication d'éléments, les simulations de particules et de fluides, la préparation des textures et la composition avec le même framework de planification que vous utilisez pour gérer les rendus.

Certaines installations ont intégré des logiciels de planification polyvalents comme HTCondor de l'Université du Wisconsin, Slurm de SchedMD ou Univa Grid Engine dans leurs pipelines d'effets visuels. Les logiciels spécialement conçus pour l'industrie des effets visuels accordent une attention particulière aux fonctionnalités suivantes :

  • Les dépendances basées sur les tâches, les cadres et les couches : certaines tâches doivent être terminées avant de pouvoir en démarrer d'autres. Par exemple, vous devez exécuter une simulation de fluide dans son intégralité avant de procéder à son rendu.
  • La priorité des tâches, que les gestionnaires de rendu peuvent utiliser pour modifier l'ordre des tâches en fonction d'échéances et de plannings individuels.
  • Les types de ressources, les étiquettes ou les cibles, que vous pouvez utiliser pour faire correspondre des ressources spécifiques aux tâches qui en ont besoin. Par exemple, vous pouvez déployer les rendus accélérés seulement sur des VM auxquelles sont associées des GPU.
  • La collecte de données historiques sur l'utilisation des ressources et leur affichage via une API ou un tableau de bord pour une analyse approfondie. Par exemple, consultez l'utilisation moyenne des processeurs et de la mémoire pour les dernières itérations d'un rendu afin de prédire l'utilisation des ressources pour la prochaine itération.
  • Les tâches avant et après le transfert. Par exemple, une tâche préalable au transfert extrait tous les éléments nécessaires du nœud de calcul avant de générer le rendu. Une tâche post-transfert copie le cadre obtenu vers un emplacement spécifique dans un système de fichiers et indique que le cadre est complet dans un système de gestion des éléments.
  • L'intégration à des applications logicielles 2D et 3D populaires comme Maya, 3ds Max, Houdini, Cinema 4D ou Nuke.

Notes de production : Utilisez un logiciel de gestion des files d'attente pour identifier un pool de ressources basées dans le cloud comme s'il s'agissait de nœuds de calcul de rendu sur site. Cette méthode nécessite une certaine surveillance afin d'optimiser l'utilisation des ressources, en exécutant autant de rendus que peut gérer chaque instance (technique connue sous le nom de "bin packing"). En règle générale, ces opérations sont traitées à la fois par des algorithmes et par des gestionnaires de données sur la ferme de rendu.

Vous pouvez également automatiser la création, la gestion et l'arrêt des ressources basées dans le cloud à la demande. Cette méthode nécessite que votre gestionnaire de files d'attente exécute des scripts avant et après rendu qui créent les ressources nécessaires, les surveillent pendant le rendu et les arrêtent une fois les tâches sont effectuées.

Remarques relatives au déploiement des tâches

Lorsque vous mettez en œuvre une ferme de rendu utilisant à la fois un stockage sur site et un stockage basé dans le cloud, tenez éventuellement compte des points suivants concernant votre gestionnaire de files d'attente :

  • Les licences peuvent différer entre les déploiements sur le cloud et sur site. Certaines licences sont basées sur des nœuds, d'autres sur des processus. Assurez-vous que votre logiciel de gestion de file d'attente déploie des tâches pour maximiser la valeur de vos licences.
  • Envisagez d'ajouter des tags ou des étiquettes uniques aux ressources basées dans le cloud pour vous assurer qu'elles ne sont utilisées que lorsqu'elles sont affectées à des types de tâches spécifiques.
  • Utilisez Cloud Logging pour détecter les instances inutilisées ou inactives.
  • Lors du lancement des tâches dépendantes, réfléchissez à l'emplacement des résultats et déterminez où ils devront se trouver pour l'étape suivante.
  • Si vos espaces de noms de chemin d'accès diffèrent pour les espaces de stockage sur site ou dans le cloud, envisagez d'utiliser des chemins d'accès relatifs afin que les rendus soient indépendants des emplacements. En fonction de la plate-forme, vous pouvez également créer un mécanisme pour échanger les chemins d'accès au moment du rendu.
  • Certains rendus, simulations ou processus préalables reposent sur la génération de nombres aléatoires, qui peuvent varier d'un fabricant de processeurs à l'autre. Même les processeurs d'un même fabricant, équipés de puces de générations différentes, peuvent produire des résultats différents. En cas de doute, utilisez des processeurs identiques ou similaires pour tous les cadres d'une tâche.
  • Si vous utilisez un dispositif de cache de lecture continue, envisagez de déployer une tâche préalable au transfert pour préchauffer le cache. Assurez-vous ensuite que tous les éléments sont disponibles sur le cloud avant de déployer des ressources cloud. Cette approche réduit le délai d'attente des nœuds de calcul de rendu pendant le transfert des éléments vers le cloud.

Journalisation et surveillance

L'enregistrement et la surveillance de l'utilisation des ressources et de leurs performances constituent un aspect essentiel de toute ferme de rendu. Google Cloud offre un certain nombre d'API, d'outils et de solutions pour vous aider à mieux comprendre l'utilisation des ressources et des services.

La méthode la plus rapide pour surveiller l'activité d'une VM consiste à afficher la sortie de son port série. Ce résultat peut s'avérer utile lorsqu'une instance ne répond pas via des plans de contrôle de service classiques tels que le superviseur de gestion des files d'attente de rendu.

Voici d'autres méthodes permettant de capturer et de surveiller l'utilisation des ressources sur Google Cloud :

Configurer les instances de nœuds de calcul de rendu

Pour que votre charge de travail soit réellement hybride, les nœuds de rendu sur site doivent être identiques aux nœuds de rendu basés dans le cloud, avec des versions de système d'exploitation, des compilations du noyau, des bibliothèques installées et des logiciels correspondants. Vous devrez peut-être également reproduire les points d'installation, les espaces de noms de chemins d'accès et même les environnements utilisateur sur le cloud, étant donné qu'ils sont sur site.

Choisir une image disque

Vous pouvez choisir parmi l'une des images publiques ou créer votre propre image personnalisée basée sur l'image de votre nœud de rendu sur site. Les images publiques incluent un ensemble de packages qui configurent et gèrent les comptes utilisateur, et activent l'authentification à base de clés SSH (Secure Shell).

Créer une image personnalisée

Si vous décidez de créer une image personnalisée, vous devrez ajouter des bibliothèques supplémentaires sous Linux et Windows pour qu'elles fonctionnent correctement dans l'environnement Compute Engine.

Votre image personnalisée doit respecter ces bonnes pratiques de sécurité. Si vous utilisez Linux, installez l'environnement invité Linux pour Compute Engine afin d'accéder aux fonctionnalités fournies par défaut par les images publiques. En installant l'environnement invité, vous pouvez effectuer des tâches comme accéder aux métadonnées, configurer le système et optimiser l'OS pour une utilisation sur Google Cloud, en utilisant les mêmes contrôles de sécurité sur votre image personnalisée que ceux des images publiques.

Notes de production : Gérez vos images personnalisées dans un projet séparé pour des raisons d'organisation. Cette approche vous permet de contrôler plus précisément la création et la modification des images ainsi que d'appliquer des versions, ce qui peut s'avérer utile lorsque vous utilisez des versions différentes de logiciels ou de systèmes d'exploitation sur plusieurs productions.

Automatiser la création d'images et le déploiement d'instances

Vous pouvez utiliser des outils comme Packer pour rendre la création d'images plus reproductible, contrôlable, configurable et fiable. Vous pouvez également utiliser un outil comme Ansible pour configurer vos nœuds de rendu en cours d'exécution, et exercer un contrôle précis sur leur configuration et leur cycle de vie.

Pour en savoir plus sur l'automatisation de la création d'images et de la configuration d'instances, consultez la section Générer une image automatisée avec Jenkins, Packer et Kubernetes.

Choisir un type de machine

Sur Google Cloud, vous pouvez choisir l'un des types de machines prédéfinis ou spécifier un type de machine personnalisé. L'utilisation de types de machines personnalisés vous permet de contrôler les ressources afin de personnaliser les instances en fonction des types de tâches que vous exécutez sur Google Cloud. Lors de la création d'une instance, vous pouvez ajouter des GPU et spécifier le nombre de processeurs, leur plate-forme, la quantité de RAM, ainsi que le type et la taille des disques.

Notes de production : Pour les pipelines qui déploient une instance par cadre, envisagez de personnaliser l'instance en fonction des statistiques de tâches historiques, telles que la charge du processeur ou l'utilisation de la mémoire. Vous optimiserez ainsi l'utilisation des ressources sur tous les cadres d'un plan. Par exemple, vous pouvez décider de déployer des machines avec un nombre de processeurs supérieur pour les cadres contenant un flou cinétique intense, afin de normaliser les temps de rendu sur tous les cadres.

Choisir entre les VM standards et les VM préemptives

Les VM préemptives font référence à la capacité excédentaire de Compute Engine, commercialisée à un prix nettement inférieur à celui des VM standards. Compute Engine peut arrêter ou préempter ces instances si d'autres tâches requièrent un accès à cette capacité. Les VM préemptives sont idéales pour le rendu de charges de travail tolérantes aux pannes et gérées par un système de mise en file d'attente qui garde la trace des tâches perdues au stade de la préemption.

Les VM standards peuvent être exécutées à l'infini et sont parfaitement adaptées aux serveurs de licences ou aux hébergeurs d'administrateurs de files d'attente devant être exécutés de manière constante.

Les VM préemptives sont arrêtées automatiquement après 24 heures. Par conséquent, elles ne doivent pas servir à l'exécution de rendus ou de simulations plus longs.

Les taux de préemption varient de 5 % à 15 %, ce qui est assez tolérable pour des charges de travail de rendu classiques, étant donné le coût réduit. Certaines bonnes pratiques en matière de préemption peuvent vous aider à choisir la meilleure méthode pour intégrer des VM préemptives à votre pipeline de rendu. Si votre instance est préemptée, Compute Engine lui envoie un signal de préemption, que vous pouvez utiliser pour demander à votre planificateur de terminer la tâche en cours et de la replacer en file d'attente.

VM standard VM préemptive
Peut être utilisée pour des tâches à exécution longue.

Idéale pour les tâches hautement prioritaires avec des échéances fermes.

Peut être exécutée à l'infini, donc idéale pour les serveurs de licences ou l'hébergement d'administrateurs de files d'attente.
Se termine automatiquement après 24 heures.

Nécessite un système de gestion des files d'attente afin de gérer les instances préemptées.

Notes de production : Certains moteurs de rendu peuvent effectuer un instantané en cours de rendu à intervalles spécifiés. Ainsi, si la VM est préemptée, vous pouvez suspendre et reprendre le rendu sans avoir à redémarrer un cadre depuis le début. Si votre moteur de rendu accepte la création d'instantanés et que vous choisissez d'utiliser des VM préemptives, activez la création d'instantanés de rendu dans votre pipeline pour éviter de perdre votre travail. Pendant l'écriture et la mise à jour d'instantanés, les données peuvent être écrites sur Cloud Storage et, si le nœud de rendu est préempté, il est récupéré lors du déploiement d'une nouvelle VM préemptive. Pour éviter des coûts de stockage, supprimez les données des instantanés pour les rendus terminés.

Autoriser l'accès aux nœuds de calcul de rendu

IAM vous permet d'accorder l'accès aux ressources cloud aux utilisateurs qui en ont besoin. Pour les nœuds de calcul de rendu Linux, vous pouvez utiliser OS Login pour restreindre davantage l'accès au sein d'une session SSH, ce qui vous permet de contrôler les rôles d'administrateur.

Contrôler les coûts d'une ferme de rendu hybride

Pour estimer les coûts, vous devez prendre en compte de nombreux facteurs. Nous vous recommandons de mettre en place ces bonnes pratiques courantes dans votre stratégie de ferme de rendu hybride :

  • Utilisez des instances préemptives par défaut. À moins que votre tâche de rendu ne soit extrêmement longue (au moins quatre heures par cadre), ou que vous ayez une échéance ferme à respecter pour diffuser un plan, utilisez des VM préemptives.
  • Minimisez la sortie. Copiez seulement les données dont vous avez besoin pour le stockage sur site. Dans la plupart des cas, ces données représenteront les cadres rendus finaux, mais il peut également s'agir de passes distinctes ou de données de simulation. Si vous installez directement votre NAS sur site ou utilisez un produit de stockage qui se synchronise automatiquement, écrivez toutes les données de rendu dans le système de fichiers local du nœud de rendu, puis copiez ce dont vous avez besoin dans l'espace de stockage sur site pour éviter toute sortie temporaire et inutile des données.
  • Utilisez des VM de taille adaptée. Veillez à créer vos nœuds de calcul de rendu avec une utilisation optimale des ressources, en affectant uniquement le nombre nécessaire de processeurs virtuels, la quantité optimale de RAM et le nombre correct de GPU, le cas échéant. Envisagez également de minimiser la taille des disques associés.
  • Pensez à la facturation minimale d'une minute. Sur Google Cloud, les instances sont facturées à la seconde avec un minimum d'une minute. Si votre charge de travail inclut un rendu de cadres qui prend moins d'une minute, envisagez de regrouper les tâches pour éviter de devoir déployer une instance pour moins d'une minute de temps de calcul.
  • Conservez de grands ensembles de données sur le cloud. Si vous utilisez votre ferme de rendu pour générer d'énormes quantités de données, comme des fichiers EXR à grande profondeur ou des données de simulation, envisagez d'utiliser un poste de travail basé dans le cloud et situé plus en aval du pipeline. Prenons l'exemple d'un artiste FX qui souhaite exécuter une simulation de fluide dans le cloud, et écrit des fichiers cache sur un espace de stockage basé dans le cloud. Un artiste d'éclairage pourra alors accéder à ces données de simulation à partir d'un poste de travail virtuel sur Google Cloud. Pour en savoir plus sur les postes de travail virtuels, adressez-vous à votre représentant GCP.
  • Profitez des remises sur engagement d'utilisation ou proportionnelles à une utilisation soutenue. Si vous exécutez un pool de ressources, les remises proportionnelles à une utilisation soutenue peuvent vous faire économiser jusqu'à 30 % du coût des instances exécutées pendant un mois entier. Les remises sur engagement d'utilisation peuvent également être avantageuses dans certains cas.

Comparer les coûts entre fermes de rendu sur site et fermes basées dans le cloud

Comparez les coûts de création et de gestion d'une ferme de rendu sur site par rapport à la création d'une ferme de rendu basée dans le cloud. L'exemple de répartition des coûts suivant compare les deux scénarios (tous les coûts sont exprimés en USD).

Coûts d'une ferme de rendu sur site Coûts d'une ferme de rendu basée dans le cloud
Coûts initiaux de création
Prix par nœud : 3 800 $
Nombre de nœuds : 100
Matériel réseau, création de salle blanche : 100 000 $
Matériel de stockage : 127 000 $
Connexion initiale au fournisseur : 20 000 $
Connectivité de provisionnement : 2 000 $
Total des coûts de création : 629 000 $
Coûts initiaux de connectivité
Matériel réseau : 10 000 $
Matériel de stockage : 127 000 $
Connectivité de provisionnement : 2 000 $
Total des coûts de création : 139 000 $
Coûts annuels
Contrat d'assistance réseau : 15 000 $
Contrat d'assistance serveur : 34 050 $
Coûts annuels
Contrat d'assistance réseau : 1 500 $
Contrat d'assistance serveur : 19 050 $
Coûts mensuels
Bande passante : 2 500 $
Utilitaires : 8 000 $
Coût au pied carré : 40 $
Pieds carrés requis : 400
Personnel/Assistance informatique : 15 000 $
Total des coûts mensuels : 41 500 $
Coûts mensuels
Bande passante : 2 500 $
2 interconnexions dédiées : 3 600 $
100 Go de sortie : 12 $
Total des coûts mensuels : 6 112 $
Utilisation de la ferme de rendu
Pourcentage d'utilisation mensuelle : 50 %
Nombre d'heures de rendu par mois : 36 500
Utilisation de la ferme de rendu
Nombre d'instances : 100
Type de machine : n1-standard-32, préemptive
Pourcentage d'utilisation mensuelle : 50 %
Nombre d'heures de rendu par mois : 36 500
Coût par heure de rendu : 5,62 $ Coût par heure de rendu : 1,46 $

Résumé

L'extension de votre ferme de rendu existante dans le cloud représente un moyen économique d'exploiter des ressources puissantes et peu coûteuses sans dépenses en capital. Tous les pipelines de production sont différents. Ainsi, aucun document ne peut couvrir tous les sujets et toutes les exigences. Pour obtenir de l'aide concernant la migration de vos charges de travail de rendu vers le cloud, adressez-vous à votre représentant GCP.

Autres ressources

D'autres solutions applicables, dont certaines ont été mentionnées dans cet article, sont disponibles sur cloud.google.com.

Testez d'autres fonctionnalités de Google Cloud. Découvrez nos tutoriels.