Questo documento fornisce indicazioni su come estendere la tua render farm on-premise esistente per utilizzare le risorse di calcolo su Google Cloud. Il documento presuppone che tu abbia già implementato una render farm on-premise e che tu abbia familiarità con i concetti di base delle pipeline di effetti visivi (VFX) e animazione, del software di gestione delle code e dei metodi comuni di licenza software.
Panoramica
Il rendering di elementi 2D o 3D per animazioni, film, spot pubblicitari o videogiochi richiede molta potenza di calcolo e tempo. Il rendering di questi elementi richiede un investimento sostanziale in hardware e infrastruttura, oltre a un team dedicato di professionisti IT per implementare e gestire hardware e software.
Quando una render farm on-premise viene utilizzata al 100%, la gestione dei job può diventare difficile. Le priorità e le dipendenze delle attività, il riavvio dei frame eliminati e il carico di rete, disco e CPU fanno parte dell'equazione complessa che devi monitorare e controllare attentamente, spesso entro scadenze ravvicinate.
Per gestire questi job, gli studi di effetti visivi hanno incorporato software di gestione delle code nelle loro pipeline. Il software di gestione delle code può:
- Esegui il deployment dei job su risorse on-premise e basate su cloud.
- Gestisci le dipendenze tra i job.
- Comunicare con i sistemi di gestione degli asset.
- Fornire agli utenti un'interfaccia utente e API per linguaggi comuni come Python.
Sebbene alcuni software di gestione delle code possano distribuire i job ai worker basati su cloud, tu sei comunque responsabile della connessione al cloud, della sincronizzazione degli asset, della scelta di un framework di archiviazione, della gestione dei modelli di immagini e della fornitura della tua licenza software.
Per creare e gestire pipeline di rendering e flussi di lavoro in un ambiente cloud o cloud ibrido sono disponibili le seguenti opzioni:
- Se non disponi già di risorse on-premise o cloud, puoi utilizzare un servizio di rendering basato sul cloud software as a service (SaaS) come Conductor.
- Se vuoi gestire la tua infrastruttura, puoi creare ed eseguire il deployment delle risorse cloud descritte in questo documento.
- Se vuoi creare un flusso di lavoro personalizzato in base ai tuoi requisiti specifici, puoi collaborare con partner integratori di servizi come Gunpowder o Qodea. Google Cloud Questa opzione offre il vantaggio di eseguire tutti i servizi cloud nel tuo ambiente Google Cloud sicuro.
Per determinare la soluzione ideale per la tua struttura, contatta il tuo rappresentante diGoogle Cloud .
Nota:le note di produzione vengono visualizzate periodicamente in questo documento. Queste note offrono best practice da seguire durante la creazione della render farm.
Connessione al cloud
A seconda del tuo workload, decidi come connettere la tua struttura a Google Cloud, tramite un ISP partner, una connessione diretta o tramite internet pubblico.
Connessione tramite internet
Senza alcuna connettività speciale, puoi connetterti alla rete di Google e utilizzare il nostro modello di sicurezza end-to-end accedendo ai servizi Google Cloud su internet. Utilità come Google Cloud CLI e risorse come l'API Compute Engine utilizzano tutte autenticazione, autorizzazione e crittografia sicure per proteggere i tuoi dati.
Cloud VPN
Indipendentemente dal tipo di connessione, ti consigliamo di utilizzare una rete privata virtuale (VPN) per proteggere la tua connessione.
Cloud VPN ti aiuta a connettere in modo sicuro la tua rete on-premise alla tua rete VPC (Virtual Private Cloud) di Google tramite una connessione VPN IPsec. I dati in transito vengono criptati prima di passare attraverso uno o più tunnel VPN.
Scopri come creare una VPN per il tuo progetto.
VPN fornita dal cliente
Sebbene tu possa configurare il tuo gateway VPN per connetterti direttamente a Google, ti consigliamo di utilizzare Cloud VPN, che offre maggiore flessibilità e una migliore integrazione con Google Cloud.
Cloud Interconnect
Google supporta diversi modi per connettere la tua infrastruttura a Google Cloud. Queste connessioni di livello aziendale, note collettivamente come Cloud Interconnect, offrono maggiore disponibilità e minore latenza rispetto alle connessioni internet standard, oltre a prezzi di uscita ridotti.
Cross-Cloud Interconnect ti consente di stabilire una connettività dedicata a larghezza di banda elevata a Google Cloud per i tuoi dati in un altro cloud. In questo modo si riduce la complessità della rete, i costi di trasferimento dei dati e si abilitano farm di rendering multicloud ad alto throughput.
Dedicated Interconnect
Dedicated Interconnect fornisce connessioni fisiche dirette e comunicazioni RFC 1918 tra la tua rete on-premise e la rete Google. Offre capacità di connessione tramite i seguenti tipi di connessioni:
- Una o più connessioni Ethernet da 10 Gbps, con un massimo di otto connessioni o 80 Gbps totali per interconnessione.
- Una o più connessioni Ethernet da 100 Gbps, con un massimo di due connessioni o 200 Gbps totali per interconnessione.
Il traffico Dedicated Interconnect non è criptato. Se devi trasmettere dati tramite Dedicated Interconnect in modo sicuro, devi stabilire una tua connessione VPN. Cloud VPN non è compatibile con Dedicated Interconnect, quindi in questo caso devi fornire la tua VPN.
Partner Interconnect
Partner Interconnect fornisce connettività tra la tua rete on-premise e la tua rete VPC tramite un provider di servizi supportato. Una connessione Partner Interconnect è utile se la tua infrastruttura si trova in una località fisica che non può raggiungere una struttura di colocation di Dedicated Interconnect o se le tue esigenze di dati non garantiscono un'intera connessione a 10 Gbps.
Altri tipi di connessione
Nella tua posizione specifica potrebbero essere disponibili altri modi per connettersi a Google. Per assistenza nella scelta del modo migliore e più conveniente per connettersi a Google Cloud, contatta il tuo Google Cloud rappresentante.
Proteggere i tuoi contenuti
Per eseguire i propri contenuti su qualsiasi piattaforma cloud pubblica, i proprietari dei contenuti, come i principali studi cinematografici di Hollywood, richiedono ai fornitori di rispettare le best practice per la sicurezza definite internamente e da organizzazioni come la MPAA. Google Cloud offre modelli di sicurezza Zero Trust integrati in prodotti come Google Workspace, Chrome Enterprise Premium e BeyondProd.
Ogni studio ha requisiti diversi per proteggere i carichi di lavoro di rendering. Puoi trovare i white paper sulla sicurezza e la documentazione sulla conformità all'indirizzo cloud.google.com/security.
Se hai domande sulla procedura di audit di conformità alla sicurezza, contatta il tuo rappresentante diGoogle Cloud .
Organizzare i progetti
I progetti sono un componente organizzativo fondamentale di Google Cloud. Nella tua struttura, puoi organizzare i lavori in un progetto separato o suddividerli in più progetti. Ad esempio, potresti voler creare progetti separati per le fasi di previsualizzazione, ricerca e sviluppo e produzione di un film.
I progetti stabiliscono un limite di isolamento sia per i dati di rete che per l'amministrazione del progetto. Tuttavia, puoi condividere le reti tra i progetti con il VPC condiviso, che fornisce a progetti separati l'accesso a risorse comuni.
Note di produzione:crea un progetto host VPC condiviso che contenga risorse con tutti i tuoi strumenti di produzione. Puoi designare tutti i progetti creati nella tua organizzazione come progetti di servizio del VPC condiviso. Questa designazione significa che qualsiasi progetto della tua organizzazione può accedere alle stesse librerie, agli stessi script e allo stesso software forniti dal progetto host.
Risorsa Organizzazione
Puoi gestire i progetti in una risorsa dell'organizzazione, che potresti aver già creato. La migrazione di tutti i tuoi progetti in un'organizzazione offre una serie di vantaggi.
Note di produzione: designa i responsabili della produzione come proprietari dei singoli progetti e la gestione dello studio come proprietari della risorsa Organizzazione.
Definizione dell'accesso alle risorse
I progetti richiedono un accesso sicuro alle risorse, insieme a limitazioni relative a dove gli utenti o i servizi sono autorizzati a operare. Per aiutarti a definire l'accesso, Google Cloud offre Identity and Access Management (IAM), che puoi utilizzare per gestire il controllo degli accessi definendo quali ruoli hanno quali livelli di accesso a quali risorse.
Note di produzione: per limitare l'accesso degli utenti solo alle risorse necessarie per svolgere attività specifiche in base al loro ruolo, implementa il principio del privilegio minimo sia on-premise che nel cloud.
Ad esempio, considera un worker di rendering, ovvero una macchina virtuale (VM) che puoi eseguire il deployment da un modello di istanza predefinito che utilizza la tua immagine personalizzata. Il worker di rendering in esecuzione con un service account può leggere da Cloud Storage e scrivere nell'archiviazione collegata, ad esempio un cloud filer o un disco permanente. Tuttavia, non è necessario aggiungere singoli artisti ai progettiGoogle Cloud , perché non hanno bisogno dell'accesso diretto alle risorse cloud.
Puoi assegnare ruoli a render wrangler o amministratori di progetto che hanno accesso a tutte le risorse Compute Engine, il che consente loro di eseguire funzioni su risorse inaccessibili ad altri utenti.
Definisci una policy per determinare quali ruoli possono accedere a quali tipi di risorse nella tua organizzazione. La seguente tabella mostra la mappatura delle attività di produzione tipiche ai ruoli IAM in Google Cloud.
| Attività di produzione | Nome ruolo | Tipo di risorsa |
|---|---|---|
| Studio Manager | resourcemanager.organizationAdmin |
Organizzazione Progetto |
| Production Manager | owner, editor |
Progetto |
| Render wrangler | compute.admin, iam.serviceAccountActor |
Progetto |
| Account di gestione della coda | compute.admin, iam.serviceAccountActor |
Organizzazione Progetto |
| Artista privato | [nessun accesso] | Non applicabile |
Ambiti di accesso
Gli ambiti di accesso ti offrono un modo per controllare le autorizzazioni di un'istanza in esecuzione indipendentemente da chi ha eseguito l'accesso. Puoi specificare gli ambiti quando crei un'istanza o quando il software di gestione delle code esegue il deployment delle risorse da un template di istanza.
Gli ambiti hanno la precedenza sulle autorizzazioni IAM di un singolo utente o service account. Questa precedenza significa che un ambito di accesso può impedire a un amministratore di progetto di accedere a un'istanza per eliminare un bucket di archiviazione o modificare un'impostazione del firewall.
Note di produzione:per impostazione predefinita, le istanze possono leggere, ma non scrivere, in Cloud Storage. Se la pipeline di rendering scrive
i rendering completati in Cloud Storage, aggiungi l'ambito
devstorage.read_write alla tua istanza al momento della creazione.
Scegliere come eseguire il deployment delle risorse
Con il rendering sul cloud, puoi utilizzare le risorse solo quando necessario, ma puoi scegliere tra diversi modi per rendere disponibili le risorse alla tua render farm.
Esegui il deployment on demand
Per un utilizzo ottimale delle risorse, puoi scegliere di eseguire il deployment dei worker di rendering solo quando invii un job alla render farm. Puoi eseguire il deployment di molte VM da condividere in tutti i frame di un job o persino creare una VM per frame.
Il sistema di gestione delle code può monitorare le istanze in esecuzione, che possono essere rimesse in coda se una VM viene prerilasciata e terminate quando le singole attività vengono completate.
Esegui il deployment di un pool di risorse
Puoi anche scegliere di eseguire il deployment di un gruppo di istanze, non correlate a un lavoro specifico, a cui il tuo sistema di gestione delle code on-premise può accedere come risorse aggiuntive. Se utilizzi le VM spot di Google Cloud, un gruppo di istanze in esecuzione può accettare più job per VM, utilizzando tutti i core e massimizzando l'utilizzo delle risorse. Questo approccio potrebbe essere la strategia più semplice da implementare perché imita il modo in cui una render farm on-premise viene popolata con i job.
Licenza del software
Le licenze software di terze parti possono variare notevolmente da pacchetto a pacchetto. Di seguito sono riportati alcuni degli schemi e dei modelli di licenza che potresti incontrare in una pipeline di effetti visivi. Per ogni schema, la terza colonna mostra l'approccio di licenza consigliato.
| Scheme | Descrizione | Suggerimento |
|---|---|---|
| Nodo bloccato | Con licenza per un indirizzo MAC, un indirizzo IP o un ID CPU specifico. Può essere eseguito solo da un singolo processo. | Basato sull'istanza |
| Basato su nodi | Licenza per un nodo (istanza) specifico. Su un nodo con licenza può essere eseguito un numero arbitrario di utenti o processi. | Basato sull'istanza |
| Mobile | Estratto da un server delle licenze che tiene traccia dell'utilizzo. | Server delle licenze |
| Licenze software | ||
| Interattiva | Consente all'utente di eseguire il software in modo interattivo in un ambiente basato sulla grafica. | Server di licenze o basato su istanze |
| Batch | Consente all'utente di eseguire il software solo in un ambiente della riga di comando. | Server delle licenze |
| Licenze basate su cloud | ||
| In base all'utilizzo | Estratto solo quando un processo viene eseguito su un'istanza cloud. Al termine o all'interruzione del processo, la licenza viene rilasciata. | Server delle licenze basato sul cloud |
| Basato sul tempo di attività | Hai eseguito il check-out mentre un'istanza è attiva e in esecuzione. Quando l'istanza viene arrestata o eliminata, la licenza viene rilasciata. | Server delle licenze basato sul cloud |
Utilizzare le licenze basate sulle istanze
Alcuni programmi software o plug-in sono concessi in licenza direttamente all'hardware su cui vengono eseguiti. Questo approccio alle licenze può presentare un problema nel cloud, dove gli identificatori hardware come gli indirizzi MAC o IP vengono assegnati in modo dinamico.
Indirizzi MAC
Quando vengono create, alle istanze viene assegnato un indirizzo MAC che viene mantenuto finché l'istanza non viene eliminata. Puoi arrestare o riavviare un'istanza e l'indirizzo MAC verrà mantenuto. Puoi utilizzare questo indirizzo MAC per la creazione e la convalida delle licenze finché l'istanza non viene eliminata.
Assegna un indirizzo IP statico
Quando crei un'istanza, le viene assegnato un indirizzo IP interno e, facoltativamente, un indirizzo IP esterno. Per conservare l'indirizzo IP esterno di un'istanza, puoi prenotare un indirizzo IP statico e assegnarlo all'istanza. Questo indirizzo IP verrà riservato solo a questa istanza. Poiché gli indirizzi IP statici sono una risorsa basata sul progetto, sono soggetti a quote regionali.
Puoi anche assegnare un indirizzo IP interno quando crei un'istanza, il che è utile se vuoi che gli indirizzi IP interni di un gruppo di istanze rientrino nello stesso intervallo.
Dongle hardware
I software meno recenti potrebbero ancora essere concessi in licenza tramite un dongle, una chiave hardware programmata con una licenza di prodotto. La maggior parte delle società di software ha smesso di utilizzare dongle hardware, ma alcuni utenti potrebbero avere software legacy associati a uno di questi dispositivi. Se riscontri questo problema, contatta il produttore del software per verificare se può fornirti una licenza aggiornata per il tuo software specifico.
Se il produttore del software non può fornire una licenza di questo tipo, puoi implementare un hub USB collegato alla rete o una soluzione USB over IP.
Utilizzo di un server delle licenze
La maggior parte dei software moderni offre un'opzione di licenza mobile. Questa opzione è più adatta a un ambiente cloud, ma richiede una gestione delle licenze e un controllo dell'accesso più rigorosi per evitare un consumo eccessivo di un numero limitato di licenze.
Per evitare di superare la capacità della licenza, puoi scegliere quali licenze utilizzare e controllare il numero di job che le utilizzano nell'ambito della coda dei job.
Server delle licenze on-premise
Puoi utilizzare il server delle licenze on-premise esistente per fornire licenze alle istanze in esecuzione nel cloud. Se scegli questo metodo, devi fornire un modo per consentire ai tuoi worker di rendering di comunicare con la tua rete on-premise, tramite una VPN o un'altra connessione sicura.
Server delle licenze basato su cloud
Nel cloud, puoi eseguire un server delle licenze che gestisce le istanze nel tuo progetto o anche in più progetti utilizzando il VPC condiviso. A volte le licenze mobili sono collegate a un indirizzo MAC hardware, quindi un'istanza piccola e a lunga esecuzione con un indirizzo IP statico può facilmente fornire licenze a molte istanze di rendering.
Server delle licenze ibrido
Alcuni software possono utilizzare più server delle licenze in un ordine prioritario. Ad esempio, un renderer potrebbe eseguire una query sul numero di licenze disponibili da un server on-premise e, se non sono disponibili, utilizzare un server di licenze basato sul cloud. Questa strategia può aiutarti a utilizzare al meglio le licenze permanenti prima di esaminare altri tipi di licenza.
Note di produzione: definisci uno o più server delle licenze in una variabile di ambiente e definisci l'ordine di priorità. Autodesk Arnold, un renderer molto diffuso, ti aiuta a farlo. Se il job non riesce ad acquisire una licenza utilizzando il primo server, tenta di utilizzare gli altri server elencati, come nel seguente esempio:
export solidangle_LICENSE=5053@x.x.0.1;5053@x.x.0.2
Nell'esempio precedente, il renderer Arnold tenta di ottenere una licenza dal server all'indirizzo x.x.0.1, porta 5053. Se il tentativo non va a buon fine, prova a ottenere
una licenza dalla stessa porta all'indirizzo IP x.x.0.2.
Licenze basate su cloud
Alcuni fornitori offrono licenze basate sul cloud che forniscono licenze software on demand per le tue istanze. La licenza basata su cloud viene generalmente fatturata in due modi: in base all'utilizzo e in base al tempo di attività.
Gestione licenze basata sull'utilizzo
Le licenze basate sull'utilizzo vengono fatturate in base al tempo di utilizzo del software. In genere, con questo tipo di licenza, una licenza viene estratta da un server basato sul cloud all'avvio del processo e viene rilasciata al termine del processo. Finché una licenza è estratta, ti viene addebitato l'utilizzo della licenza. Questo tipo di licenza viene in genere utilizzato per il software di rendering.
Gestione licenze basata sull'uptime
Le licenze basate sull'uptime o misurate vengono fatturate in base all'uptime dell'istanza Compute Engine. L'istanza è configurata per registrarsi al server delle licenze basato su cloud durante la procedura di avvio. Finché l'istanza è in esecuzione, la licenza viene estratta. Quando l'istanza viene arrestata o eliminata, la licenza viene rilasciata. Questo tipo di licenza viene in genere utilizzato per i worker di rendering che un gestore delle code distribuisce.
Scegliere come archiviare i dati
Il tipo di archiviazione che scegli su Google Cloud dipende dalla strategia di archiviazione che hai scelto, nonché da fattori quali i requisiti di durabilità e il costo.
Disco permanente
Potresti riuscire a evitare del tutto l'implementazione di un file server incorporando dischi permanenti (PD) nel tuo workload. I PD sono un tipo di archiviazione a blocchi conforme a POSIX, fino a 64 TB di dimensioni, che è familiare alla maggior parte degli studi di VFX. I dischi permanenti sono disponibili sia come unità standard sia come unità a stato solido (SSD). Puoi collegare un disco permanente in modalità di lettura/scrittura a una singola istanza o in modalità di sola lettura a un numero elevato di istanze, ad esempio un gruppo di worker di rendering.
| Pro | Contro | Caso d'uso ideale |
|---|---|---|
| Viene montato come volume NFS o SMB standard. Può essere ridimensionato dinamicamente. È possibile collegare fino a 128 dischi permanenti a una singola istanza. Lo stesso disco permanente può essere montato in modalità di sola lettura su centinaia o migliaia di istanze. |
Dimensioni massime di 64 TB. Può scrivere su PD solo se collegato a una singola istanza. Può essere accessibile solo dalle risorse che si trovano nella stessa regione. |
Pipeline avanzate in grado di creare un nuovo disco in base al job. Pipeline che forniscono dati aggiornati di rado, come software o librerie comuni, ai worker di rendering. |
Archiviazione di oggetti
Cloud Storage è uno spazio di archiviazione altamente ridondante e duraturo che, a differenza dei file system tradizionali, non è strutturato e ha una capacità praticamente illimitata. I file su Cloud Storage sono archiviati in bucket, che sono simili a cartelle e sono accessibili in tutto il mondo.
A differenza dell'archiviazione tradizionale, l'archiviazione di oggetti non può essere montata come volume logico da un sistema operativo (OS). Se decidi di incorporare l'object storage nella pipeline di rendering, devi modificare il modo in cui leggi e scrivi i dati, tramite utilità della riga di comando come gcloud CLI o tramite l'API Cloud Storage.
| Pro | Contro | Caso d'uso ideale |
|---|---|---|
| Archiviazione durevole e ad alta disponibilità per file di tutte le dimensioni. Un'unica API per tutte le classi di archiviazione. Economico. I dati sono disponibili in tutto il mondo. Capacità praticamente illimitata. |
Non conforme a POSIX. Deve essere accessibile tramite API o utilità da riga di comando. In una pipeline di rendering, i dati devono essere trasferiti localmente prima dell'uso. |
Esegui il rendering delle pipeline con un sistema di gestione degli asset in grado di pubblicare i dati in Cloud Storage. Pipeline di rendering con un sistema di gestione delle code in grado di recuperare i dati da Cloud Storage prima del rendering. |
Altri prodotti di archiviazione
Altri prodotti di archiviazione sono disponibili come servizi gestiti tramite canali di terze parti come Cloud Marketplace o come progetti open source tramite repository software o GitHub.
| Prodotto | Pro | Contro | Caso d'uso ideale |
|---|---|---|---|
| Filestore | File system in cluster in grado di supportare migliaia di connessioni NFS simultanee. Possibilità di sincronizzazione con il cluster NAS on-premise. |
Non è possibile sincronizzare i file in modo selettivo. Nessuna sincronizzazione bidirezionale. | Studi di effetti visivi di medie e grandi dimensioni con centinaia di TB di dati da presentare sul cloud. |
| Pixit Media, PixStor | File system scalabile in orizzontale in grado di supportare migliaia di client NFS o POSIX simultanei. I dati possono essere memorizzati nella cache su richiesta dal NAS on-premise, con gli aggiornamenti inviati automaticamente allo spazio di archiviazione on-premise. | Costo, assistenza di terze parti di Pixit. | Studi di effetti visivi di medie e grandi dimensioni con centinaia di TB di dati da presentare sul cloud. |
| Google Cloud NetApp Volumes | Soluzione di archiviazione completamente gestita su Google Cloud. Supporta gli ambienti NFS, SMB e multiprotocollo. Snapshot point-in-time con recupero dell'istanza |
Non disponibile in tutte le Google Cloud regioni. | Strutture VFX con una pipeline in grado di sincronizzare gli asset. Disco condiviso tra le workstation virtuali. |
| Cloud Storage FUSE | Monta i bucket Cloud Storage come file system. Costi ridotti. | Non è un file system conforme a POSIX. Può essere difficile da configurare e ottimizzare. | Strutture di effetti visivi in grado di eseguire il deployment, la configurazione e la manutenzione di un file system open source, con una pipeline in grado di sincronizzare gli asset. |
Altri tipi di archiviazione sono disponibili su Google Cloud. Per maggiori informazioni, contatta il tuo Google Cloud rappresentante.
Ulteriori informazioni sulle opzioni di archiviazione dei dati
- Opzioni di archiviazione disponibili su Google Cloud
- Archiviazione di file su Compute Engine
- Progetta una strategia di archiviazione ottimale per il tuo carico di lavoro cloud
Implementazione di strategie di archiviazione
Puoi implementare diverse strategie di archiviazione nelle pipeline di produzione di VFX o animazione stabilendo convenzioni che determinano come gestire i dati, se accedi ai dati direttamente dall'archiviazione on-premise o se esegui la sincronizzazione tra l'archiviazione on-premise e il cloud.
Strategia 1: monta direttamente lo spazio di archiviazione on-premise
Se la tua struttura ha una connettività a Google Cloud di almeno 10 Gbps e si trova nelle immediate vicinanze di una Google Cloud regione, puoi scegliere di montare il NAS on-premise direttamente sui worker di rendering cloud. Sebbene questa strategia sia semplice, può anche essere costosa e richiedere molta larghezza di banda, perché tutto ciò che crei sul cloud e scrivi di nuovo nello spazio di archiviazione viene conteggiato come dati di uscita.
| Pro | Contro | Caso d'uso ideale |
|---|---|---|
| Implementazione semplice. Lettura/scrittura nello spazio di archiviazione comune. Disponibilità immediata dei dati, senza necessità di memorizzazione nella cache o sincronizzazione. |
Può essere più costoso di altre opzioni. La vicinanza a un data center Google è necessaria per ottenere una bassa latenza. Il numero massimo di istanze a cui puoi connetterti al tuo NAS on-premise dipende dalla larghezza di banda e dal tipo di connessione. |
Strutture vicino a un data center Google che devono eseguire il rendering dei carichi di lavoro nel cloud, dove il costo non è un problema. Strutture con connettività a Google Cloud di almeno 10 Gbps. |
Strategia 2: sincronizzazione on demand
Puoi scegliere di trasferire i dati sul cloud o recuperare i dati dallo spazio di archiviazione on-premise o viceversa solo quando sono necessari, ad esempio quando viene eseguito il rendering di un frame o viene pubblicato un asset. Se utilizzi questa strategia, la sincronizzazione può essere attivata da un meccanismo nella pipeline, ad esempio uno script di monitoraggio, da un gestore di eventi come Pub/Sub o da un insieme di comandi nell'ambito di uno script di job.
Puoi eseguire una sincronizzazione utilizzando una serie di comandi, ad esempio il comando gcloud CLI scp, il comando gcloud CLI rsync o protocolli di trasferimento dei dati basati su UDP (UDT). Se scegli di utilizzare un UDT di terze parti come Aspera, Cloud FastPath, BitSpeed, o FDT per comunicare con un bucket Cloud Storage, consulta la documentazione della terza parte per scoprire il modello di sicurezza e le best practice. Google non gestisce questi servizi di terze parti.
Metodo push
In genere, utilizzi il metodo push quando pubblichi una risorsa, inserisci un file in una cartella monitorata o completi un job di rendering, dopodiché lo invii a una posizione predefinita.
Esempi:
- Un worker di rendering cloud completa un job di rendering e i frame risultanti vengono inviati di nuovo allo spazio di archiviazione on-premise.
- Un artista pubblica una risorsa. Parte del processo di pubblicazione degli asset prevede il push dei dati associati a un percorso predefinito su Cloud Storage.
Metodo pull
Utilizzi il metodo pull quando viene richiesto un file, in genere da un'istanza di rendering basata sul cloud.
Esempio: nell'ambito di uno script di un job di rendering, tutte le risorse necessarie per il rendering di una scena vengono inserite in un file system prima del rendering, dove tutti i worker di rendering possono accedervi.
| Pro | Contro | Caso d'uso ideale |
|---|---|---|
| Controllo completo su quali dati vengono sincronizzati e quando. Possibilità di scegliere il metodo di trasferimento e il protocollo. |
La pipeline di produzione deve essere in grado di gestire gli eventi per attivare
le sincronizzazioni push/pull. Potrebbero essere necessarie risorse aggiuntive per gestire la coda di sincronizzazione. |
Strutture di piccole e grandi dimensioni che dispongono di pipeline personalizzate e desiderano il controllo completo sulla sincronizzazione degli asset. |
Note di produzione: gestisci la sincronizzazione dei dati con lo stesso sistema di gestione delle code che utilizzi per gestire i lavori di rendering. Le attività di sincronizzazione possono utilizzare risorse cloud separate per massimizzare la larghezza di banda disponibile e ridurre al minimo il traffico di rete.
Strategia 3: spazio di archiviazione on-premise, cache di lettura basata su cloud
Google Cloud ha esteso e sviluppato una soluzione di memorizzazione nella cache KNFSD come opzione open source. La soluzione è in grado di gestire le richieste di prestazioni della render farm che superano le capacità dell'infrastruttura di archiviazione. La memorizzazione nella cache KNFSD offre una memorizzazione nella cache read-through ad alte prestazioni, che consente ai carichi di lavoro di scalare a centinaia o addirittura migliaia di nodi di rendering in più regioni e pool di archiviazione ibridi.
La memorizzazione nella cache KNFSD è una soluzione di scalabilità orizzontale che riduce il carico sul servizio di condivisione file principale. La memorizzazione nella cache di KNFSD riduce anche l'effetto di sovraccarico quando molti nodi di rendering tentano di recuperare i file dal server di file contemporaneamente. Utilizzando un livello di memorizzazione nella cache sulla stessa rete VPC dei nodi di rendering, la latenza di lettura viene ridotta, il che aiuta i job di rendering a iniziare e completarsi più rapidamente. A seconda di come hai configurato il server di file di memorizzazione nella cache, i dati rimangono nella cache fino a quando:
- I dati diventano obsoleti o rimangono invariati per un periodo di tempo specificato.
- È necessario spazio sul file server, dopodiché i dati vengono rimossi dalla cache in base all'età.
Questa strategia riduce la quantità di larghezza di banda e la complessità necessarie per il deployment di molte istanze di rendering simultanee.
In alcuni casi, potresti voler pre-riscaldare la cache per assicurarti che tutti
i dati relativi al lavoro siano presenti prima del rendering. Per precaricare la cache, leggi i
contenuti di una directory che si trova sul tuo file server cloud eseguendo un read
o un stat di uno o più file. L'accesso ai file in questo modo attiva il meccanismo di sincronizzazione.
Puoi anche aggiungere un'appliance fisica on-premise per comunicare con l'appliance virtuale. Ad esempio, NetApp offre una soluzione di archiviazione che può ridurre ulteriormente la latenza tra l'archiviazione on-premise e il cloud.
| Pro | Contro | Caso d'uso ideale |
|---|---|---|
| I dati memorizzati nella cache vengono gestiti automaticamente. Riduce i requisiti di larghezza di banda. I file system cloud in cluster possono essere scalati in base ai requisiti del job. |
Può comportare costi aggiuntivi. Se scegli di precaricare la cache, devi implementare le attività pre-job. |
Grandi strutture che eseguono il deployment di molte istanze simultanee e leggono asset comuni in molti job. |
Filtrare i dati
Puoi creare un database di tipi di asset e condizioni associate per definire se sincronizzare un particolare tipo di dati. Potresti non voler mai sincronizzare alcuni tipi di dati, come i dati effimeri generati nell'ambito di un processo di conversione, i file della cache o i dati di simulazione. Valuta anche se sincronizzare gli asset non approvati, perché non tutte le iterazioni verranno utilizzate nei rendering finali.
Eseguire un trasferimento collettivo iniziale
Quando implementi la tua render farm ibrida, potresti voler eseguire un trasferimento iniziale di tutto o parte del tuo set di dati a Cloud Storage, al disco permanente o a un altro spazio di archiviazione basato sul cloud. A seconda di fattori quali la quantità e il tipo di dati da trasferire e la velocità della connessione, potresti essere in grado di eseguire una sincronizzazione completa nell'arco di alcuni giorni o settimane. La figura seguente confronta i tempi tipici per i trasferimenti online e fisici.
Se il carico di lavoro di trasferimento supera i limiti di tempo o di larghezza di banda, Google offre una serie di opzioni di trasferimento per trasferire i dati nel cloud, inclusa Transfer Appliance di Google.
Archiviazione e ripristino di emergenza
È importante notare la differenza tra l'archiviazione dei dati e il ripristino di emergenza. Il primo è una copia selettiva del lavoro finito, mentre il secondo è uno stato dei dati che può essere recuperato. Vuoi progettare un piano di ripristino di emergenza che soddisfi le esigenze della tua struttura e fornisca un piano di emergenza esterno. Consulta il fornitore dello spazio di archiviazione on-premise per ricevere assistenza con un piano di ripristino di emergenza adatto alla tua piattaforma di archiviazione specifica.
Archiviazione dei dati nel cloud
Una volta completato un progetto, è prassi comune salvare il lavoro finito in una forma di archiviazione a lungo termine, in genere su supporti a nastro magnetico come LTO. Queste cartucce sono soggette a requisiti ambientali e, nel tempo, possono essere difficili da gestire dal punto di vista logistico. A volte, i grandi impianti di produzione ospitano l'intero archivio in una stanza appositamente costruita con un archivista a tempo pieno per tenere traccia dei dati e recuperarli quando richiesto.
La ricerca di asset, scatti o filmati archiviati specifici può richiedere molto tempo, perché i dati potrebbero essere memorizzati su più cartucce, l'indicizzazione dell'archivio potrebbe essere mancante o incompleta oppure potrebbero esserci limitazioni di velocità nella lettura dei dati dal nastro magnetico.
La migrazione dell'archivio di dati nel cloud non solo può eliminare la necessità di gestione e archiviazione in sede dei supporti di archiviazione, ma può anche rendere i tuoi dati molto più accessibili e ricercabili rispetto ai metodi di archiviazione tradizionali.
Una pipeline di archiviazione di base potrebbe avere l'aspetto del seguente diagramma, che utilizza diversi servizi cloud per esaminare, classificare, taggare e organizzare gli archivi. Dal cloud puoi creare uno strumento di gestione e recupero degli archivi per cercare i dati utilizzando vari criteri di metadati come data, progetto, formato o risoluzione. Puoi anche utilizzare le API Machine Learning per taggare e classificare immagini e video, memorizzando i risultati in un database basato sul cloud come BigQuery.
Altri argomenti da considerare:
- Automatizza la generazione di miniature o proxy per i contenuti che si trovano all'interno delle classi di archiviazione Cloud Storage che prevedono tariffe di recupero. Utilizza questi proxy all'interno del sistema di gestione degli asset multimediali in modo che gli utenti possano sfogliare i dati leggendo solo i proxy, non gli asset archiviati.
- Valuta la possibilità di utilizzare il machine learning per classificare i contenuti live action. Utilizza Cloud Vision per etichettare texture e sfondi o l'API Video Intelligence per facilitare la ricerca e il recupero di filmati di riferimento.
- Puoi anche utilizzare Vertex AI AutoML Image per creare un modello di immagine personalizzato per riconoscere qualsiasi risorsa, sia live action che renderizzata.
- Per i contenuti sottoposti a rendering, valuta la possibilità di salvare una copia dell'immagine del disco del worker di rendering insieme all'asset sottoposto a rendering. Se devi ricreare la configurazione, avrai a disposizione le versioni software, i plug-in, le librerie del sistema operativo e le dipendenze corrette se devi eseguire nuovamente il rendering di una ripresa archiviata.
Gestione di asset e produzione
Lavorare allo stesso progetto in più strutture può presentare sfide uniche, soprattutto quando i contenuti e gli asset devono essere disponibili in tutto il mondo. La sincronizzazione manuale dei dati nelle reti private può essere costosa e richiedere molte risorse ed è soggetta a limitazioni della larghezza di banda locale.
Se il tuo carico di lavoro richiede dati disponibili a livello globale, potresti essere in grado di utilizzare Cloud Storage, accessibile da qualsiasi luogo in cui puoi accedere ai servizi Google. Per incorporare Cloud Storage nella pipeline, devi modificare la pipeline in modo che comprenda i percorsi degli oggetti, quindi estrai o invia i dati ai worker di rendering prima del rendering. L'utilizzo di questo metodo fornisce l'accesso globale ai dati pubblicati, ma richiede che la pipeline fornisca gli asset dove sono necessari in un periodo di tempo ragionevole.
Ad esempio, un artista di texture a Los Angeles può pubblicare file di immagini da utilizzare da un artista dell'illuminazione a Londra. La procedura è la seguente:
- La pipeline di pubblicazione trasferisce i file in Cloud Storage e aggiunge una voce a un database di asset basato sul cloud.
- Un artista di Londra esegue uno script per raccogliere gli asset per una scena. Le posizioni dei file vengono interrogate dal database e lette da Cloud Storage sul disco locale.
- Il software di gestione delle code raccoglie un elenco di asset necessari per il rendering, li interroga dal database degli asset e li scarica da Cloud Storage nell'archivio locale di ogni worker di rendering.
L'utilizzo di Cloud Storage in questo modo ti fornisce anche un archivio di tutti i tuoi dati pubblicati sul cloud se scegli di utilizzare Cloud Storage come parte della pipeline di archiviazione.
Gestione dei database
Il software di gestione della produzione e degli asset dipende da database durevoli e ad alta disponibilità che vengono pubblicati su host in grado di gestire centinaia o migliaia di query al secondo. I database sono in genere ospitati su un server on-premise in esecuzione nello stesso rack dei worker di rendering e sono soggetti alle stesse limitazioni di alimentazione, rete e HVAC.
Potresti prendere in considerazione l'esecuzione dei database di produzione MySQL, NoSQL e PostgreSQL come servizi gestiti basati sul cloud. Questi servizi sono ad alta disponibilità e accessibili a livello globale, criptano i dati sia at-rest che in transito e offrono funzionalità di replica integrate.
Gestione delle code
Programmi software di gestione delle code disponibili in commercio, come Qube!, Deadline e Tractor sono ampiamente utilizzati nel settore degli effetti visivi e dell'animazione. Sono disponibili anche opzioni software open source, come OpenCue. Puoi utilizzare questo software per eseguire il deployment e gestire qualsiasi carico di lavoro di calcolo su una serie di worker, non solo render. Puoi eseguire il deployment e gestire la pubblicazione degli asset, le simulazioni di particelle e fluidi, la cottura delle texture e il compositing con lo stesso framework di pianificazione che utilizzi per gestire i rendering.
Alcune strutture hanno implementato software di pianificazione generici come HTCondor dell'Università del Wisconsin, Slurm di SchedMD o Univa Grid Engine nelle loro pipeline VFX. Software progettato specificamente per il settore degli effetti speciali, che presta particolare attenzione a funzionalità come:
- Dipendenza basata su job, frame e livello. Alcune attività devono essere completate prima di poter iniziare altri lavori. Ad esempio, esegui una simulazione di fluidi nella sua interezza prima del rendering.
- Priorità del job, che i render wrangler possono utilizzare per modificare l'ordine dei job in base a scadenze e pianificazioni individuali.
- Tipi di risorse, etichette o target, che puoi utilizzare per abbinare risorse specifiche a job che le richiedono. Ad esempio, esegui il deployment di rendering accelerati dalla GPU solo sulle VM con GPU collegate.
- Acquisizione dei dati storici sull'utilizzo delle risorse e loro disponibilità tramite un'API o una dashboard per ulteriori analisi. Ad esempio, esamina l'utilizzo medio di CPU e memoria per le ultime iterazioni di un rendering per prevedere l'utilizzo delle risorse per l'iterazione successiva.
- Job pre-volo e post-volo. Ad esempio, un job di pre-volo estrae tutti gli asset necessari sul worker di rendering locale prima del rendering. Un job post-flight copia il frame sottoposto a rendering risultante in una posizione designata su un file system e poi contrassegna il frame come completato in un sistema di gestione degli asset.
- Integrazione con le applicazioni software 2D e 3D più diffuse, come Maya, 3ds Max, Houdini, Cinema 4D o Nuke.
Note di produzione: utilizza un software di gestione delle code per riconoscere un pool di risorse basate su cloud come se fossero worker di rendering on-premise. Questo metodo richiede una certa supervisione per massimizzare l'utilizzo delle risorse eseguendo il maggior numero possibile di rendering che ogni istanza può gestire, una tecnica nota come bin packing. Queste operazioni vengono in genere gestite sia in modo algoritmico sia dai render wrangler.
Puoi anche automatizzare la creazione, la gestione e l'interruzione delle risorse basate sul cloud su base on demand. Questo metodo si basa sul gestore delle code per eseguire script pre- e post-rendering che creano le risorse necessarie, le monitorano durante il rendering e le terminano al termine delle attività.
Considerazioni sul deployment dei job
Quando implementi una render farm che utilizza sia l'archiviazione on-premise sia quella basata sul cloud, ecco alcuni aspetti che il gestore delle code potrebbe dover tenere a mente:
- Le licenze potrebbero variare tra le implementazioni cloud e on-premise. Alcune licenze sono basate sui nodi, altre sui processi. Assicurati che il software di gestione delle code distribuisca i job in modo da massimizzare il valore delle licenze.
- Valuta la possibilità di aggiungere tag o etichette unici alle risorse basate sul cloud per assicurarti che vengano utilizzati solo quando assegnati a tipi di job specifici.
- Utilizza Cloud Logging per rilevare istanze inutilizzate o inattive.
- Quando avvii job dipendenti, considera dove risiederanno i dati risultanti e dove devono trovarsi per il passaggio successivo.
- Se gli spazi dei nomi dei percorsi differiscono tra l'archiviazione on-premise e quella basata sul cloud, valuta la possibilità di utilizzare percorsi relativi per consentire ai rendering di essere indipendenti dalla posizione. In alternativa, a seconda della piattaforma, potresti creare un meccanismo per scambiare i percorsi al momento del rendering.
- Alcuni rendering, simulazioni o post-elaborazioni si basano sulla generazione di numeri casuali, che può variare a seconda dei produttori di CPU. Anche le CPU dello stesso produttore, ma di generazioni di chip diverse, possono produrre risultati diversi. In caso di dubbi, utilizza tipi di CPU identici o simili per tutti i frame di un job.
- Se utilizzi un'appliance di cache read-through, valuta la possibilità di eseguire il deployment di un job di pre-flight per precaricare la cache e assicurarti che tutti gli asset siano disponibili sul cloud prima di eseguire il deployment delle risorse cloud. Questo approccio riduce al minimo il tempo di attesa forzata dei worker di rendering durante lo spostamento degli asset nel cloud.
Logging e monitoraggio
La registrazione e il monitoraggio dell'utilizzo e delle prestazioni delle risorse sono un aspetto essenziale di qualsiasi render farm. Google Cloud offre una serie di API, strumenti e soluzioni per fornire informazioni sull'utilizzo di risorse e servizi.
Il modo più rapido per monitorare l'attività di una VM è visualizzare l'output della porta seriale. Questo output può essere utile quando un'istanza non risponde tramite i normali piani di controllo del servizio, ad esempio il supervisore di gestione della coda di rendering.
Altri modi per raccogliere e monitorare l'utilizzo delle risorse su Google Cloud includono:
- Utilizza Cloud Logging per acquisire i log di utilizzo e di controllo ed esportare i log risultanti in Cloud Storage, BigQuery e altri servizi.
- Utilizza Cloud Monitoring per installare un agente sulle tue VM per monitorare le metriche di sistema.
- Incorpora l'API Cloud Logging negli script della pipeline per eseguire il logging direttamente in Cloud Logging utilizzando le librerie client per i linguaggi di scripting più diffusi.
- Utilizza Cloud Monitoring per creare grafici per comprendere l'utilizzo delle risorse.
Configurazione delle istanze di worker di rendering
Affinché il tuo workload sia veramente ibrido, i nodi di rendering on-premise devono essere identici ai nodi di rendering basati sul cloud, con versioni del sistema operativo, build del kernel, librerie installate e software corrispondenti. Potresti anche dover riprodurre i punti di montaggio, gli spazi dei nomi dei percorsi e persino gli ambienti utente sul cloud, perché si trovano on-premise.
Scelta di un'immagine disco
Puoi scegliere una delle immagini pubbliche o creare una immagine personalizzata basata sull'immagine del nodo di rendering on-premise. Le immagini pubbliche includono una raccolta di pacchetti che configurano e gestiscono gli account utente e abilitano l'autenticazione basata su chiavi Secure Shell (SSH).
Creare un'immagine personalizzata
Se scegli di creare un'immagine personalizzata, devi aggiungere altre librerie sia a Linux che a Windows affinché funzionino correttamente nell'ambiente Compute Engine.
L'immagine personalizzata deve rispettare le best practice per la sicurezza. Se utilizzi Linux, installa l'ambiente guest Linux per Compute Engine per accedere alle funzionalità fornite per impostazione predefinita dalle immagini pubbliche. Installando l'ambiente guest, puoi eseguire attività come l'accesso ai metadati, la configurazione del sistema e l'ottimizzazione del sistema operativo per l'utilizzo su Google Cloud, utilizzando gli stessi controlli di sicurezza sull'immagine personalizzata che utilizzi sulle immagini pubbliche.
Note di produzione: gestisci le tue immagini personalizzate in un progetto separato a livello di organizzazione. Questo approccio ti offre un controllo più preciso su come vengono create o modificate le immagini e ti consente di applicare versioni, il che può essere utile quando utilizzi versioni diverse di software o sistemi operativi in più produzioni.
Automatizzazione della creazione di immagini e del deployment di istanze
Puoi utilizzare strumenti come Packer per rendere la creazione di immagini più riproducibile, verificabile, configurabile e affidabile. Puoi anche utilizzare uno strumento come Ansible per configurare i nodi di rendering in esecuzione ed esercitare un controllo granulare sulla loro configurazione e sul loro ciclo di vita.
Scelta di un tipo di macchina
Su Google Cloud, puoi scegliere uno dei tipi di macchine predefiniti o specificare un tipo di macchina personalizzato. L'utilizzo di tipi di macchine personalizzate ti consente di controllare le risorse in modo da poter personalizzare le istanze in base ai tipi di job che esegui su Google Cloud. Quando crei un'istanza, puoi aggiungere GPU e specificare il numero di CPU, la piattaforma CPU, la quantità di RAM e il tipo e le dimensioni dei dischi.
Note di produzione: per le pipeline che eseguono il deployment di un'istanza per frame, valuta la possibilità di personalizzare l'istanza in base alle statistiche storiche dei job, come il carico della CPU o l'utilizzo della memoria, per ottimizzare l'utilizzo delle risorse in tutti i frame di una ripresa. Ad esempio, potresti scegliere di eseguire il deployment di macchine con un numero maggiore di CPU per i frame che contengono un forte motion blur per contribuire a normalizzare i tempi di rendering in tutti i frame.
Scelta tra VM standard e prerilasciabili
Le VM prerilasciabili (PVM) si riferiscono alla capacità in eccesso di Compute Engine venduta a un prezzo inferiore rispetto alle VM standard. Compute Engine potrebbe terminare o prerilasciare queste istanze se altre attività richiedono l'accesso a questa capacità. Le PVM sono ideali per carichi di lavoro di rendering a tolleranza di errore e gestiti da un sistema di gestione delle code che tiene traccia dei job persi a causa del prerilascio.
Le VM standard possono essere eseguite a tempo indeterminato e sono ideali per i server delle licenze o gli host amministratori delle code che devono essere eseguiti in modo permanente.
Le VM preemptible vengono terminate automaticamente dopo 24 ore, quindi non utilizzarle per eseguire rendering o simulazioni di durata superiore.
I tassi di prerilascio variano dal 5% al 15%, il che per i tipici workload di rendering è probabilmente tollerabile dato il costo ridotto. Alcune best practice per le VM preemptible possono aiutarti a decidere il modo migliore per integrarle nella pipeline di rendering. Se la tua istanza viene prerilasciata, Compute Engine invia un segnale di prerilascio all'istanza, che puoi utilizzare per attivare lo scheduler in modo che termini il job corrente e lo rimetta in coda.
| VM standard | VM preemptible |
|---|---|
| Può essere utilizzato per job a lunga esecuzione. Ideale per i job ad alta priorità con scadenze rigide. Può essere eseguito a tempo indeterminato, quindi è ideale per l'hosting di server di licenze o amministratori di code. |
Terminato automaticamente dopo 24 ore. Richiede un sistema di gestione delle code per gestire le istanze preemption. |
Note di produzione: alcuni renderer possono eseguire uno snapshot di un rendering in corso a intervalli specificati, quindi se la VM viene preempted, puoi mettere in pausa e riprendere il rendering senza dover riavviare un frame da zero. Se il renderer supporta la creazione di snapshot e scegli di utilizzare le PVM, attiva la creazione di snapshot di rendering nella pipeline per evitare di perdere il lavoro. Mentre gli snapshot vengono scritti e aggiornati, i dati possono essere scritti in Cloud Storage e, se il worker di rendering viene interrotto, recuperati quando viene eseguito il deployment di una nuova PVM. Per evitare costi di archiviazione, elimina i dati degli snapshot per i rendering completati.
Concessione dell'accesso ai worker di rendering
IAM ti aiuta ad assegnare l'accesso alle risorse cloud alle persone che ne hanno bisogno. Per i worker di rendering Linux, puoi utilizzare OS Login per limitare ulteriormente l'accesso all'interno di una sessione SSH, in modo da controllare chi è un amministratore.
Controllare i costi di una farm di rendering ibrida
Quando stimi i costi, devi prendere in considerazione molti fattori, ma ti consigliamo di implementare queste best practice comuni come policy per la tua render farm ibrida:
- Utilizza le istanze prerilasciabili per impostazione predefinita. A meno che il tuo job di rendering non sia estremamente lungo, quattro o più ore per frame, o tu non abbia una scadenza rigida per la consegna di una ripresa, utilizza le VM preemptible.
- Ridurre al minimo il traffico in uscita. Copia solo i dati che ti servono di nuovo nello spazio di archiviazione on-premise. Nella maggior parte dei casi, questi dati saranno i frame di rendering finali, ma possono anche essere passaggi separati o dati di simulazione. Se monti il NAS on-premise direttamente o utilizzi un prodotto di archiviazione che si sincronizza automaticamente, scrivi tutti i dati sottoposti a rendering nel file system locale del worker di rendering, quindi copia ciò che ti serve nell'archiviazione on-premise per evitare l'uscita di dati temporanei e non necessari.
- Dimensiona correttamente le VM. Assicurati di creare i worker di rendering con un utilizzo ottimale delle risorse, assegnando solo il numero necessario di vCPU, la quantità ottimale di RAM e il numero corretto di GPU, se presenti. Considera anche come ridurre al minimo le dimensioni di eventuali dischi collegati.
- Considera il minimo di un minuto. Il giorno Google Cloud, le istanze vengono fatturate al secondo con un minimo di un minuto. Se il tuo workload include il rendering di frame che richiedono meno di un minuto, valuta la possibilità di raggruppare le attività per evitare di eseguire il deployment di un'istanza per meno di un minuto di tempo di calcolo.
- Conserva i set di dati di grandi dimensioni sul cloud. Se utilizzi la tua render farm per generare grandi quantità di dati, come EXR profondi o dati di simulazione, valuta la possibilità di utilizzare una workstation basata sul cloud più avanti nella pipeline. Ad esempio, un artista di effetti speciali potrebbe eseguire una simulazione di fluidi sul cloud, scrivendo i file della cache in uno spazio di archiviazione basato sul cloud. Un lighting artist potrebbe quindi accedere a questi dati di simulazione da una workstation virtuale suGoogle Cloud. Per saperne di più sulle workstation virtuali, contatta il tuo Google Cloud rappresentante.
- Usufruisci degli sconti per utilizzo sostenuto e per impegno di utilizzo. Se esegui un pool di risorse, gli sconti per utilizzo sostenuto possono farti risparmiare fino al 30% del costo delle istanze eseguite per un intero mese. In alcuni casi, possono essere utili anche gli sconti per impegno di utilizzo.
L'estensione della tua farm di rendering esistente al cloud è un modo conveniente per utilizzare risorse potenti ed economiche senza spese di capitale. Non esistono due pipeline di produzione uguali, quindi nessun documento può coprire ogni argomento e requisito unico. Per assistenza con la migrazione dei carichi di lavoro di rendering al cloud, contatta il tuo rappresentante di Google Cloud .
Passaggi successivi
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.