Questo documento fornisce indicazioni su come estendere la tua farm di rendering on-premise esistente per utilizzare le risorse di calcolo su Google Cloud. Il documento presuppone che tu abbia già implementato una farm di rendering on-premise e che tu abbia familiarità con i concetti di base delle pipeline di animazione ed effetti visivi (VFX), con il software di gestione delle code e con i metodi di licenza software comuni.
Panoramica
Il rendering di elementi 2D o 3D per animazioni, film, spot pubblicitari o videogiochi richiede molto tempo e risorse di calcolo. Il rendering di questi elementi richiede un investimento sostanziale in hardware e infrastruttura, nonché un team dedicato di professionisti IT per il deployment e la manutenzione di hardware e software.
Quando una farm di rendering on-premise è inutilizzata al 100%, la gestione dei job può diventare un problema. Le priorità e le dipendenze delle attività, il riavvio dei frame persi e il carico della rete, del disco e della CPU fanno tutti parte dell'equazione complessa che devi monitorare e controllare attentamente, spesso in tempi stretti.
Per gestire questi job, le strutture di VFX hanno incorporato software di gestione delle code nelle proprie pipeline. Il software di gestione delle code può:
- Esegui il deployment dei job in risorse on-premise e basate su cloud.
- Gestisci le dipendenze tra job.
- Comunicare con i sistemi di gestione degli asset.
- Fornisci agli utenti un'interfaccia utente e API per linguaggi comuni come Python.
Sebbene alcuni software di gestione delle code possano eseguire il deployment dei job su worker basati su cloud, rimane comunque tua responsabilità connetterti al cloud, sincronizzare gli asset, scegliere un framework di archiviazione, gestire i modelli di immagine e fornire le licenze del software.
Per creare e gestire le pipeline di rendering e i 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 su cloud come Conductor.
- Se vuoi gestire la tua infrastruttura, puoi creare e implementare le risorse cloud descritte in questo documento.
- Se vuoi creare un flusso di lavoro personalizzato in base ai tuoi requisiti specifici, puoi collaborare con partner di integrazione di servizi Google Cloud come Gunpowder o Qodea. Questa opzione ha 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 Google Cloud.
Nota:le note di produzione vengono visualizzate periodicamente in questo documento. Queste note forniscono le best practice da seguire durante la creazione della tua farm di rendering.
Connessione al cloud
A seconda del carico di lavoro, decidi come la tua struttura si connette a Google Cloud, tramite un ISP partner, una connessione diretta o tramite la rete internet pubblica.
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 tramite 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 connessione.
Cloud VPN ti aiuta a connettere in sicurezza la tua rete on-premise alla �� I dati in transito vengono criptati prima di essere trasmessi tramite 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 un'integrazione migliore con Google Cloud.
Cloud Interconnect
Google supporta diversi modi per connettere la tua infrastruttura a Google Cloud. Queste connessioni di livello enterprise, note collettivamente come Cloud Interconnect, offrono una maggiore disponibilità e una latenza inferiore rispetto alle connessioni internet standard, nonché prezzi ridotti per il traffico in uscita.
Cross-Cloud Interconnect ti consente di stabilire una connettività dedicata a elevata larghezza di banda a Google Cloud per i tuoi dati in un altro cloud. In questo modo, riduci la complessità della rete, i costi di trasferimento dei dati e ottieni farm di rendering multicloud ad alta produttività.
Dedicated Interconnect
Dedicated Interconnect fornisce connessioni fisiche dirette e comunicazioni RFC 1918 tra la rete on-premise e la rete di 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 di Dedicated Interconnect non è criptato. Se devi trasmettere dati tramite Dedicated Interconnect in modo sicuro, devi stabilire la 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 fornitore 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 località potrebbero essere disponibili altri modi per contattare Google. Per assistenza per determinare il modo migliore e più conveniente per connetterti a Google Cloud, contatta il tuo rappresentante di Google Cloud.
Proteggere i contenuti
Per pubblicare i propri contenuti su qualsiasi piattaforma cloud pubblico, i proprietari di contenuti come i principali studi cinematografici di Hollywood richiedono ai fornitori di rispettare le best practice di sicurezza definite sia internamente che 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 la protezione dei carichi di lavoro di rendering. Puoi trovare white paper sulla sicurezza e documentazione sulla conformità all'indirizzo cloud.google.com/security.
In caso di domande sulla procedura di controllo della conformità alla sicurezza, contatta il tuo rappresentante Google Cloud.
Organizzare i progetti
I progetti sono un componente organizzativo fondamentale di Google Cloud. Nel tuo impianto, puoi organizzare i job in un progetto dedicato o suddividerli in più progetti. Ad esempio, potresti voler creare progetti distinti per le fasi di previsualizzazione, ricerca e sviluppo e produzione di un film.
I progetti stabiliscono un confine di isolamento sia per i dati di rete sia per la gestione del progetto. Tuttavia, puoi condividere le reti tra i progetti con la VPC condivisa, che fornisce ai progetti separati l'accesso alle risorse comuni.
Note sulla produzione: crea un progetto host VPC condiviso contenente risorse con tutti gli strumenti di produzione. Puoi designare tutti i progetti creati nella tua organizzazione come progetti di servizio VPC condiviso. Questa designazione indica che qualsiasi progetto della tua organizzazione può accedere alle stesse librerie, agli stessi script e allo stesso software forniti dal progetto host.
La risorsa Organizzazione
Puoi gestire i progetti in una risorsa dell'organizzazione, che potresti aver già configurato. La migrazione di tutti i tuoi progetti in un'organizzazione offre una serie di vantaggi.
Note di produzione: designa i gestori della produzione come proprietari dei singoli progetti e la gestione dello studio come proprietari della risorsa Organizzazione.
Definire l'accesso alle risorse
I progetti richiedono l'accesso sicuro alle risorse insieme a limitazioni su dove gli utenti o i servizi possono operare. Per aiutarti a definire l'accesso, Google Cloud offre Identity and Access Management (IAM), che puoi utilizzare per gestire il controllo dell'accesso'accesso definendo quali ruoli hanno quali livelli di accesso a quali risorse.
Note sulla produzione: per limitare l'accesso degli utenti solo alle risorse necessarie per eseguire attività specifiche in base al loro ruolo, implementa il principio del privilegio minimo sia on-premise che nel cloud.
Ad esempio, prendi in considerazione un worker di rendering, ovvero una macchina virtuale (VM) che puoi eseguire da un modello di istanza predefinito che utilizza la tua immagine personalizzata. Il worker di rendering in esecuzione in un account di servizio può leggere da Cloud Storage e scrivere nello spazio di archiviazione collegato, ad esempio un filer cloud o un disco permanente. Tuttavia, non è necessario aggiungere singoli artisti ai progetti Google Cloud, in quanto non hanno bisogno di accedere direttamente alle risorse cloud.
Puoi assegnare ruoli a responsabili della gestione dei rendering o amministratori di progetti che hanno accesso a tutte le risorse di Compute Engine, il che consente loro di eseguire funzioni su risorse inaccessibili ad altri utenti.
Definisci un criterio per determinare quali ruoli possono accedere a quali tipi di risorse nella tua organizzazione. La tabella seguente mostra come le attività di produzione tipiche vengono mappate ai ruoli IAM in Google Cloud.
| Attività di produzione | Nome ruolo | Tipo di risorsa |
|---|---|---|
| Gestore dello studio | resourcemanager.organizationAdmin |
Progetto Organizzazione |
| Production manager | owner, editor |
Progetto |
| Wrangler di rendering | compute.admin, iam.serviceAccountActor |
Progetto |
| Account di gestione della coda | compute.admin, iam.serviceAccountActor |
Progetto Organizzazione |
| Artista singolo | [no access] | Non applicabile |
Ambiti di accesso
Gli ambiti di accesso ti consentono di controllare le autorizzazioni di un'istanza in esecuzione, indipendentemente da chi ha eseguito l'accesso. Puoi specificare gli ambiti quando crei un'istanza personalmente o quando il software di gestione delle code esegue il deployment delle risorse da un modello di istanza.
Gli ambiti hanno la precedenza sulle autorizzazioni IAM di un singolo utente o account di servizio. Questa precedenza significa che un ambito di accesso può impedire a un amministratore del progetto di accedere a un'istanza per eliminare un bucket di archiviazione o modificare un'impostazione del firewall.
Note sulla produzione: per impostazione predefinita, le istanze possono leggere, ma non scrivere in Cloud Storage. Se la pipeline di rendering scrive nuovamente i rendering finali in Cloud Storage, aggiungi l'ambitodevstorage.read_write all'istanza al momento della creazione.
Scelta del modo di eseguire il deployment delle risorse
Con il rendering sul cloud, puoi utilizzare le risorse solo quando necessario, ma puoi scegliere tra diversi modi per renderle disponibili per la tua farm di rendering.
Esegui il deployment on demand
Per un utilizzo ottimale delle risorse, puoi scegliere di implementare i worker di rendering solo quando invii un job alla farm di rendering. Puoi eseguire il deployment di più VM da condividere tra tutti i frame di un job o anche creare una VM per frame.
Il sistema di gestione delle code può monitorare le istanze in esecuzione, che possono essere riassegnate alla coda se una VM viene prelevata e terminate al completamento delle singole attività.
Esegui il deployment di un pool di risorse
Puoi anche scegliere di eseguire il deployment di un gruppo di istanze, non correlate a un job specifico, a cui il 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 farm di rendering on-premise viene compilata con i job.
Licenziare il software
Le licenze di software di terze parti possono variare notevolmente da un pacchetto all'altro. Di seguito sono riportati alcuni schemi e modelli di licenza che potresti trovare in una pipeline VFX. Per ogni schema, la terza colonna mostra l'approccio di licenza consigliato.
| Scheme | Descrizione | Consiglio |
|---|---|---|
| Nodo bloccato | Licenza concessa per un indirizzo MAC, un indirizzo IP o un ID CPU specifico. Può essere eseguito solo da un singolo processo. | In base all'istanza |
| In base al nodo | Licenza concessa a un nodo (istanza) specifico. Un numero arbitrario di utenti o processi può essere eseguito su un nodo con licenza. | In base all'istanza |
| Floating | Effettuato il check-out 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 su grafica. | Server di licenze o basato su istanze |
| Batch | Consente all'utente di eseguire il software solo in un ambiente a riga di comando. | Server delle licenze |
| Licenze basate su cloud | ||
| Basato su utilizzo | Effettuato il check-out solo quando un processo viene eseguito su un'istanza cloud. Al termine o all'interruzione della procedura, la licenza viene rilasciata. | Server delle licenze basato su cloud |
| In base al tempo di attività | Effettuato 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 su cloud |
Utilizzo delle licenze basate sulle istanze
Alcuni programmi software o plug-in sono concessi in licenza direttamente all'hardware su cui vengono eseguiti. Questo approccio alla concessione delle 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 della licenza fino all'eliminazione dell'istanza.
Assegna un indirizzo IP statico
Quando crei un'istanza, viene assegnato un indirizzo IP interno e, facoltativamente, uno 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 per questa istanza. Poiché gli indirizzi IP statici sono una risorsa basata su progetto, sono soggetti alle 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
Il software precedente potrebbe essere ancora concesso in licenza tramite un dongle, una chiave hardware programmata con una licenza di prodotto. La maggior parte delle aziende di software ha smesso di utilizzare dongle hardware, ma alcuni utenti potrebbero avere software legacy associato a uno di questi dispositivi. Se riscontri questo problema, contatta il produttore del software per verificare se può fornirti una licenza aggiornata per il software in questione.
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 del software moderno offre un'opzione di licenza flottante. Questa opzione è più adatta in un ambiente cloud, ma richiede una gestione delle licenze e controllo dell'accesso più rigorosi per evitare il 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 procedura di 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 ai tuoi worker di rendering un modo per 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 serve istanze nel tuo progetto o anche in più progetti utilizzando il VPC condiviso. A volte le licenze a rotazione sono collegate a un indirizzo MAC hardware, pertanto un'istanza piccola e di lunga durata 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 visualizzatore potrebbe eseguire una query sul numero di licenze disponibili da un server on-premise e, se non sono disponibili, utilizzare un server delle licenze basato su cloud. Questa strategia può aiutarti a massimizzare l'utilizzo delle licenze permanenti prima di esaminare altri tipi di licenze.
Note di produzione: definisci uno o più server di licenza in una variabile di ambiente e definisci l'ordine di priorità. Autodesk Arnold, un popolare programma di rendering, 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 nell'esempio seguente:
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, il client tenta di ottenere una licenza dalla stessa porta all'indirizzo IP x.x.0.2.
Licenze basate su cloud
Alcuni fornitori offrono licenze basate su cloud che forniscono licenze software su richiesta per le tue istanze. In genere, le licenze basate su cloud vengono fatturate in due modi: in base all'utilizzo e in base al tempo di attività.
Licenze basate sull'utilizzo
Le licenze basate sull'utilizzo vengono fatturate in base al tempo di utilizzo del software. In genere, con questo tipo di licenze, una licenza viene controllata da un server basato su cloud all'avvio del processo e viene rilasciata al suo completamento. Finché una licenza è in uso, ti viene addebitato l'utilizzo di quella licenza. Questo tipo di licenza viene in genere utilizzato per il software di rendering.
Licenze basate sul tempo di attività
Le licenze basate sul tempo di attività o misurate vengono fatturate in base al tempo di attività della tua 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 controllata. Quando l'istanza viene interrotta o eliminata, la licenza viene rilasciata. Questo tipo di licenza viene solitamente utilizzato per i worker di rendering di cui viene eseguito il deployment da parte di un gestore code.
Scelta della modalità di archiviazione dei dati
Il tipo di archiviazione che scegli su Google Cloud dipende dalla strategia di archiviazione che hai scelto, nonché da fattori quali requisiti di durabilità e costo.
Disco permanente
Potresti evitare del tutto di implementare un file server incorporando dischi permanenti (PD) nel tuo carico di lavoro. I PD sono un tipo di archiviazione a blocchi conforme a POSIX, con dimensioni massime di 64 TB, che sono familiari alla maggior parte delle strutture di VFX. I dischi permanenti sono disponibili sia come unità standard che come unità a stato solido (SSD). Puoi collegare un DP in modalità di lettura e 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.
| Vantaggi | Svantaggi | Caso d'uso ideale |
|---|---|---|
| Viene montato come volume NFS o SMB standard. Può ridimensionarsi dinamicamente. A una singola istanza è possibile collegare fino a 128 PD. Lo stesso DP può essere montato in modalità di sola lettura su centinaia o migliaia di istanze. |
Dimensioni massime di 64 TB. Può scrivere nel DP solo se è collegato a una singola istanza. Possono essere accessibili solo le risorse che si trovano nella stessa regione. |
Pipeline avanzate che possono creare un nuovo disco in base al job. Pipeline che pubblicano dati aggiornati di rado, come software o librerie comuni, per il rendering dei worker. |
Archiviazione di oggetti
Cloud Storage è uno spazio di archiviazione altamente ridondante e durevole che, a differenza dei file system tradizionali, è non strutturato e ha una capacità praticamente illimitata. I file su Cloud Storage vengono archiviati in bucket, che sono simili alle 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 lo spazio di archiviazione oggetti nella pipeline di rendering, devi modificare il modo in cui leggi e scrivi i dati tramite utilità a riga di comando come gcloud CLI o tramite l'API Cloud Storage.
| Vantaggi | Svantaggi | 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à a 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 delle risorse in grado di pubblicare i dati su Cloud Storage. Esegui il rendering delle pipeline con un sistema di gestione delle code che può 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 il Cloud Marketplace o come progetti open source tramite repository software o GitHub.
| Prodotto | Vantaggi | Svantaggi | Caso d'uso ideale |
|---|---|---|---|
| Filestore | File system cluster che può supportare migliaia di connessioni NFS simultanee. In grado di sincronizzarsi con il cluster NAS on-premise. |
Impossibile sincronizzare i file in modo selettivo. Nessuna sincronizzazione bidirezionale. | Strutture di post-produzione VFX di medie e grandi dimensioni con centinaia di TB di dati da presentare sul cloud. |
| Pixit Media, PixStor | File system scalabile 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 aggiornamenti inviati automaticamente allo spazio di archiviazione on-premise. | Costo, assistenza di terze parti da Pixit. | Strutture di post-produzione VFX 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 regioni Google Cloud. | Strutture di post-produzione VFX con una pipeline in grado di sincronizzare gli asset. Disco condiviso tra 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 VFX 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. |
Su Google Cloud sono disponibili altri tipi di archiviazione. Per ulteriori informazioni, contatta il tuo rappresentante Google Cloud.
Ulteriori informazioni sulle opzioni di archiviazione dei dati
- Opzioni di archiviazione disponibili su Google Cloud
- Archiviazione di file su Compute Engine
- Progettare una strategia di archiviazione ottimale per il carico di lavoro cloud
Implementazione di strategie di archiviazione
Puoi implementare una serie di strategie di archiviazione nelle pipeline di produzione di animazione o VFX stabilendo convenzioni che determinano come gestire i dati, indipendentemente dal fatto che tu acceda ai dati direttamente dallo spazio di archiviazione on-premise o se li sincronizzi tra lo spazio di archiviazione on-premise e il cloud.
Strategia 1: monta direttamente lo spazio di archiviazione on-premise
Se la tua struttura dispone di una connettività a Google Cloud di almeno 10 Gbps e si trova nelle immediate vicinanze di una regione Google Cloud, puoi scegliere di montare il NAS on-premise direttamente sui worker di rendering cloud. Sebbene questa strategia sia semplice, può anche essere dispendiosa in termini di costi e larghezza di banda, perché tutto ciò che crei sul cloud e scrivi nuovamente nello spazio di archiviazione viene conteggiato come dati in uscita.
| Vantaggi | Svantaggi | 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 rispetto ad altre opzioni. La vicinanza a un data center Google è necessaria per ottenere una bassa latenza. Il numero massimo di istanze che puoi collegare al tuo NAS on-premise dipende dalla larghezza di banda e dal tipo di connessione. |
Strutture vicine 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: sincronizza su richiesta
Puoi scegliere di caricare i dati sul cloud o estrarre i dati dallo spazio di archiviazione on-premise o viceversa, solo quando i dati sono necessari, ad esempio quando viene visualizzato 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 eventi come Pub/Sub o da un insieme di comandi all'interno di uno script di job.
Puoi eseguire una sincronizzazione utilizzando una serie di comandi, ad esempio il comando scp dell'interfaccia a riga di comando gcloud CLI, il comando rsync gcloud CLI o i protocolli di trasferimento 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 conoscere il suo 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 collezionista o completi un job di rendering, dopodiché lo invii a una posizione predefinita.
Esempi:
- Un worker di rendering sul cloud completa un job di rendering e i frame risultanti vengono nuovamente inviati allo spazio di archiviazione on-premise.
- Un artista pubblica una risorsa. Parte del processo di pubblicazione delle risorse prevede l'invio dei dati associati a un percorso predefinito su Cloud Storage.
Metodo pull
Utilizza il metodo pull quando viene richiesto un file, in genere da un'istanza di rendering basata su cloud.
Esempio: nell'ambito di uno script di job di rendering, tutti gli asset necessari per eseguire il rendering di una scena vengono inseriti in un file system prima del rendering, dove tutti i worker di rendering possono accedervi.
| Vantaggi | Svantaggi | Caso d'uso ideale |
|---|---|---|
| Controllo completo su quali dati vengono sincronizzati e quando. Possibilità di scegliere il metodo e il protocollo di trasferimento. |
La pipeline di produzione deve essere in grado di gestire gli eventi per attivare le sincronizzazioni push/pull. Per gestire la coda di sincronizzazione potrebbero essere necessarie risorse aggiuntive. |
Strutture di piccole e grandi dimensioni con pipeline personalizzate e che vogliono un controllo completo sulla sincronizzazione delle risorse. |
Note sulla produzione: gestisci la sincronizzazione dei dati con lo stesso sistema di gestione delle code che utilizzi per gestire i job 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: archiviazione on-premise, cache di lettura completa basata su cloud
Google Cloud ha esteso e sviluppato una soluzione di memorizzazione nella cache KNFSD come opzione open source. La soluzione può gestire richieste di prestazioni della farm di rendering 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 di scalare i carichi di lavoro su 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à che riduce il carico sul servizio di condivisione di file principale. La memorizzazione nella cache KNFSD riduce anche l'effetto di sovraccarico quando molti nodi di rendering tentano contemporaneamente di recuperare file dal file server. L'utilizzo di un livello di memorizzazione nella stessa rete VPC dei nodi di rendering riduce la latenza di lettura, il che consente di avviare e completare più rapidamente i job di rendering. A seconda di come hai configurato il server file con cache, i dati rimangono nella cache fino a quando:
- I dati vengono eliminati o rimangono invariati per un determinato periodo di tempo.
- È necessario spazio sul file server, a quel punto i dati vengono rimossi dalla cache in base alla data di creazione.
Questa strategia riduce la larghezza di banda e la complessità necessarie per eseguire il deployment di molte istanze di rendering simultanee.
In alcuni casi, ti consigliamo di preriscaldare la cache per assicurarti che tutti i dati relativi al job siano presenti prima del rendering. Per preriscaldare la cache, leggi i contenuti di una directory 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 on-premise fisica per comunicare con l'appliance virtuale. Ad esempio, NetApp offre una soluzione di archiviazione che può ridurre ulteriormente la latenza tra lo spazio di archiviazione on-premise e il cloud.
| Vantaggi | Svantaggi | Caso d'uso ideale |
|---|---|---|
| I dati memorizzati nella cache vengono gestiti automaticamente. Riduce i requisiti di larghezza di banda. È possibile eseguire lo scale up o lo scale down dei file system cloud clusterizzati in base ai requisiti del job. |
Potrebbero essere applicati costi aggiuntivi. Le attività pre-job devono essere implementate se scegli di preriscaldare la cache. |
Strutture di grandi dimensioni 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 determinato tipo di dati. Potresti non voler mai sincronizzare alcuni tipi di dati, ad esempio i dati effimeri generati nell'ambito di un processo di conversione, i file della cache o i dati di simulazione. Valuta anche la possibilità di sincronizzare gli asset non approvati, perché non tutte le iterazioni verranno utilizzate nei rendering finali.
Eseguire un trasferimento collettivo iniziale
Quando implementi la tua farm di rendering ibrida, ti consigliamo di eseguire un trasferimento iniziale di tutto o parte del tuo set di dati in Cloud Storage, su disco permanente o su un altro spazio di archiviazione basato su 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 nel corso 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 vincoli di tempo o di larghezza di banda, Google offre una serie di opzioni di trasferimento per caricare i dati sul cloud, inclusa Transfer Appliance di Google.
Archiviazione e ripristino di emergenza
Vale la pena notare la differenza tra l'archiviazione dei dati e il recupero di emergenza. La prima è una copia selettiva del lavoro finito, mentre la seconda è un stato dei dati che può essere recuperato. Vuoi creare un piano di ripristino di emergenza adatto alle esigenze della tua struttura e che preveda un piano di emergenza off-site. Rivolgiti al tuo fornitore di soluzioni di archiviazione on-premise per ricevere assistenza in merito a un piano di ripristino di emergenza adatto alla tua piattaforma di archiviazione specifica.
Archiviazione dei dati nel cloud
Al termine di un progetto, è prassi comune salvare il lavoro finito in qualche forma di archiviazione a lungo termine, in genere su supporti magnetici come le LTO. Queste cartucce sono soggette a requisiti ambientali e, nel tempo, possono essere difficili da gestire dal punto di vista logistico. A volte, le grandi strutture di produzione ospitano l'intero archivio in una stanza appositamente costruita con un archivista a tempo pieno che tiene traccia dei dati e li recupera quando richiesto.
La ricerca di asset, scatti o filmati archiviati specifici può richiedere molto tempo, poiché i dati potrebbero essere archiviati su più cartucce, l'indicizzazione dell'archivio potrebbe essere mancante o incompleta oppure potrebbero esserci limitazioni di velocità per la lettura dei dati dalla magnella magnetica.
La migrazione dell'archivio di dati al cloud non solo elimina la necessità di gestire e archiviare i contenuti multimediali dell'archivio on-premise, ma rende anche i dati molto più accessibili e disponibili per la ricerca rispetto ai metodi di archiviazione tradizionali.
Una pipeline di archiviazione di base potrebbe avere il seguente aspetto, utilizzando diversi servizi cloud per esaminare, classificare, taggare e organizzare gli archivi. Dal cloud, puoi create uno strumento di gestione e recupero dell'archivio per cercare i dati utilizzando vari criteri dei metadati, come data, progetto, formato o risoluzione. Puoi anche utilizzare le API di machine learning per taggare e classificare immagini e video, archiviando i risultati in un database basato su cloud come BigQuery.
Altri argomenti da considerare:
- Automatizza la generazione di miniature o proxy per i contenuti che si trovano nelle classi di archiviazione di Cloud Storage con tariffe di recupero. Utilizza questi proxy all'interno del tuo sistema di gestione delle risorse multimediali in modo che gli utenti possano sfogliare i dati leggendo solo i proxy e non le risorse archiviate.
- Valuta la possibilità di utilizzare il machine learning per categorizzare i contenuti live-action. Utilizza Cloud Vision per etichettare texture e sfondo oppure l'API Video Intelligence per facilitare la ricerca e il recupero di filmati di riferimento.
- Puoi anche utilizzare l'immagine Vertex AI AutoML per creare un modello di immagini personalizzato per riconoscere qualsiasi risorsa, sia dal vivo che in animazione.
- Per i contenuti visualizzati, ti consigliamo di salvare una copia dell'immagine del disco del worker di rendering insieme alla risorsa visualizzata. Se devi ricreare la configurazione, avrai a disposizione le versioni software, i plug-in, le librerie OS e le dipendenze corrette se devi eseguire nuovamente il rendering di uno scatto archiviato.
Gestione di asset e produzione
Lavorare allo stesso progetto in più strutture può presentare delle sfide uniche, soprattutto quando i contenuti e le risorse devono essere disponibili in tutto il mondo. La sincronizzazione manuale dei dati su reti private può essere costosa e richiede molte risorse ed è soggetta a limitazioni della larghezza di banda locale.
Se il tuo carico di lavoro richiede dati disponibili a livello globale, potresti utilizzare Cloud Storage, che è accessibile da qualsiasi luogo in cui puoi accedere ai servizi Google. Per incorporare Cloud Storage nella pipeline, devi modificarla in modo da comprendere i percorsi degli oggetti, quindi estrarre o inviare i dati ai worker di rendering prima del rendering. L'utilizzo di questo metodo fornisce accesso globale ai dati pubblicati, ma richiede che la pipeline carichi gli asset dove sono necessari in un lasso di tempo ragionevole.
Ad esempio, un texture artist di Los Angeles può pubblicare file immagine da utilizzare da un lighting artist di Londra. Il processo è il seguente:
- La pipeline di pubblicazione invia i file a Cloud Storage e aggiunge una voce a un database di asset basato su cloud.
- Un artista di Londra esegue uno script per raccogliere asset per una scena. Le posizioni dei file vengono sottoposte a query dal database e lette da Cloud Storage sul disco locale.
- Il software di gestione della coda raccoglie un elenco di asset necessari per il rendering, esegue query sul database degli asset e li scarica da Cloud Storage nello spazio di archiviazione locale di ogni istanza di lavoro di rendering.
L'utilizzo di Cloud Storage in questo modo ti fornisce anche un'archivio di tutti i dati pubblicati sul cloud, se scegli di utilizzare Cloud Storage all'interno della pipeline di archiviazione.
Gestione dei database
Il software di gestione delle risorse e della produzione si basa su 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 impianti di climatizzazione.
Potresti prendere in considerazione l'esecuzione dei database di produzione MySQL, NoSQL e PostgreSQL come servizi basati su cloud gestiti. Questi servizi sono ad alta disponibilità e accessibili a livello globale, criptano i dati sia at-rest sia in transito e offrono funzionalità di replica integrate.
Gestione delle code
Software di gestione delle code disponibili in commercio, come Qube!, Deadline e Tractor sono ampiamente utilizzati nel settore VFX/animazione. Sono disponibili anche opzioni di 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 per i rendering. Puoi eseguire il deployment e gestire la pubblicazione degli asset, le simulazioni di particelle e fluidi, la baking delle texture e il compositing con lo stesso framework di pianificazione utilizzato 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. Il software progettato specificamente per il settore VFX, tuttavia, presta particolare attenzione a funzionalità come le seguenti:
- Dipendenza basata su job, frame e livello. Alcune attività devono essere completate prima di poter iniziare altri lavori. Ad esempio, esegui una simulazione di fluido nella sua interezza prima del rendering.
- La priorità del job, che i 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 associare risorse specifiche ai job che le richiedono. Ad esempio, esegui il deployment dei rendering con accelerazione GPU solo sulle VM con GPU collegate.
- Acquisisci i dati storici sull'utilizzo delle risorse e rendili disponibili 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 e post-volo. Ad esempio, un job di preflight recupera tutti gli asset necessari nel worker di rendering locale prima del rendering. Un compito post-flight copia il frame visualizzato risultante in una posizione designata su un file system e poi contrassegna il frame come completo in un sistema di gestione delle risorse.
- Integrazione con applicazioni software 2D e 3D di uso comune 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 di rendering possibile per ogni istanza, una tecnica nota come bin packing. Queste operazioni vengono in genere gestite sia in modo algoritmico sia tramite wrangler di rendering.
Puoi anche automatizzare la creazione, la gestione e il termine delle risorse basate su cloud su base on demand. Questo metodo si basa sul gestore code per eseguire script pre- e post-rendering che creano le risorse in base alle esigenze, le monitorano durante il rendering e le terminano al termine delle attività.
Considerazioni sul deployment dei job
Quando implementi una farm di rendering che utilizza sia lo spazio di archiviazione on-premise sia quello basato su cloud, ecco alcuni aspetti che il gestore della coda potrebbe dover tenere presente:
- Le licenze potrebbero variare in base al deployment cloud o on-premise. Alcune licenza si basano sui nodi, altre sono basate sui processi. Assicurati che il software di gestione delle code implementi i job per massimizzare il valore delle licenze.
- Valuta la possibilità di aggiungere tag o etichette univoci alle risorse basate su 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 risiede i dati risultanti e dove devono trovarsi per il passaggio successivo.
- Se gli spazi dei nomi dei percorsi sono diversi tra lo spazio di archiviazione on-premise e quello basato su cloud, ti consigliamo di utilizzare percorsi relativi per consentire ai rendering di essere agnostici rispetto alla posizione. In alternativa, a seconda della piattaforma, puoi creare un meccanismo per scambiare i percorsi al momento del rendering.
- Alcuni rendering, simulazioni o post-elaborazione si basano sulla generazione di numeri random, che può variare in base ai produttori di CPU. Anche le CPU dello stesso produttore, ma di generazioni di chip diverse, possono produrre risultati diversi. In caso di dubbio, utilizza tipi di CPU identici o simili per tutti i frame di un job.
- Se utilizzi un'appliance cache read-through, valuta la possibilità di eseguire il deployment di un job di preflight per preriscaldare 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 dei worker di rendering durante il trasferimento delle risorse nel cloud.
Logging e monitoraggio
La registrazione e il monitoraggio dell'utilizzo delle risorse e delle prestazioni 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 è visualizzarne l'output della porta seriale. Questa uscita può essere utile quando un'istanza non risponde tramite i piani di controllo dei servizi tipici, come 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 al fine di monitorare le metriche di sistema.
- Incorpora l'API Cloud Logging negli script della pipeline per generare log 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 carico di lavoro sia veramente ibrido, i nodi di rendering on-premise devono essere identici ai nodi di rendering basati su cloud, con versioni del sistema operativo, build del kernel, librerie e software installati corrispondenti. Potrebbe anche essere necessario riprodurre i punti di montaggio, i nomi di spazio dei percorsi e persino gli ambienti utente sul cloud, perché si trovano on-premise.
Scegliere un'immagine disco
Puoi scegliere una delle immagini pubbliche o creare la tua immagine personalizzata in base all'immagine del tuo nodo di rendering on-premise. Le immagini pubbliche includono una raccolta di pacchetti che configurano e gestiscono gli account utente e attivano l'autenticazione basata su chiavi Secure Shell (SSH).
Creazione di un'immagine personalizzata
Se scegli di creare un'immagine personalizzata, dovrai aggiungere altre librerie sia a Linux che a Windows affinché funzionino correttamente nell'ambiente Compute Engine.
L'immagine personalizzata deve essere conforme alle 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 immagini personalizzate in un progetto separato a livello di organizzazione. Questo approccio ti offre un controllo più preciso sulla modalità di creazione o modifica delle immagini e ti consente di applicare versioni, che possono essere utili quando utilizzi software o versioni del sistema operativo diversi in più produzioni.
Automatizzazione della creazione delle immagini e del deployment delle 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 personalizzata. 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, il tipo e le dimensioni dei dischi.
Note di produzione: per le pipeline che implementano un'istanza per frame, valuta la possibilità di personalizzarla 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 un'inquadratura. Ad esempio, puoi scegliere di implementare macchine con un numero di CPU superiore per i frame che contengono sfocature dinamiche elevate per contribuire a normalizzare i tempi di rendering in tutti i frame.
Scelta tra VM standard e prerilasciabili
Le VM prerilasciabili (PVM) fanno riferimento alla capacità in eccesso di Compute Engine venduta a un prezzo molto più basso rispetto alle VM standard. Compute Engine potrebbe terminare o prerilasciare queste istanze se altre attività richiedono l'accesso a questa capacità. Le VM prerilasciabili sono ideali per il rendering di carichi di lavoro a tolleranza di errore e gestiti da un sistema di coda 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 di amministrazione delle code che devono essere eseguiti in modo persistente.
Le VM prerilasciabili vengono interrotte automaticamente dopo 24 ore, quindi non utilizzarle per eseguire rendering o simulazioni che richiedono più tempo.
Le frequenze di preemption vanno dal 5% al 15%, il che per i tipici carichi di lavoro di rendering è probabilmente tollerabile dato il costo ridotto. Alcune best practice per le VM preemptibili possono aiutarti a decidere il modo migliore per integrare le VM preemptibili 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 rimetta in coda.
| VM standard | VM preemptible |
|---|---|
| Può essere utilizzato per job a lunga esecuzione. Ideale per job ad alta priorità con scadenze rigide. Può essere eseguito a tempo indeterminato, quindi è ideale per l'hosting di server delle licenze o di amministratori di code. |
Viene terminato automaticamente dopo 24 ore. Richiede un sistema di gestione delle code per gestire le istanze prelevate. |
Note di produzione: alcuni renderer possono eseguire un'istantanea di un rendering in corso a intervalli specificati, quindi se la VM viene precettata, puoi mettere in pausa e riprendere il rendering senza dover riavviare un frame da zero. Se il tuo renderer supporta gli snapshot e scegli di utilizzare le VM private, attiva gli 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 prelevato, possono essere recuperati quando viene implementato un nuovo PVM. Per evitare costi di archiviazione, elimina i dati degli istantanei per i rendering completati.
Concedere l'accesso ai lavoratori 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 avere il controllo su chi è un amministratore.
Controllo dei costi di una farm di rendering ibrida
Quando stimerai i costi, dovrai prendere in considerazione molti fattori, ma ti consigliamo di implementare queste best practice comuni come norme per la tua farm di rendering ibrida:
- Utilizza le istanze prerilasciabili per impostazione predefinita. A meno che il tuo job di rendering non sia estremamente lungo, con quattro o più ore per frame, o se hai una scadenza obbligatoria per la consegna di uno scatto, utilizza le VM prerilasciabili.
- Riduci al minimo il traffico in uscita. Ripristina solo i dati di cui hai bisogno nello spazio di archiviazione on-premise. Nella maggior parte dei casi, questi dati saranno i frame finali visualizzati, ma possono anche essere passaggi o dati di simulazione separati. Se monti direttamente il NAS on-premise o utilizzi un prodotto di archiviazione che si sincronizza automaticamente, scrivi tutti i dati visualizzati nel file system locale dell'attività di rendering, quindi copia ciò che ti serve nello spazio di archiviazione on-premise per evitare di esportare dati temporanei e non necessari.
- Esegui il dimensionamento ottimale delle 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. Valuta anche come ridurre al minimo le dimensioni degli eventuali dischi collegati.
- Valuta la possibilità di realizzare un video di almeno un minuto. Su Google Cloud, le istanze vengono fatturate al secondo con un minimo di un minuto. Se il tuo carico di lavoro 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.
- Mantieni set di dati di grandi dimensioni sul cloud. Se utilizzi la tua farm di rendering per generare enormi quantità di dati, come file EXR di alta qualità o dati di simulazione, valuta la possibilità di utilizzare una workstation basata su cloud più avanti nella pipeline. Ad esempio, un artista degli effetti speciali potrebbe eseguire una simulazione di fluidi sul cloud, scrivendo i file della cache in uno spazio di archiviazione basato su cloud. Un lighting artist potrebbe quindi accedere a questi dati di simulazione da una workstation virtuale su Google Cloud. Per ulteriori informazioni sulle workstation virtuali, contatta il tuo rappresentante Google Cloud.
- Sfrutta gli sconti per utilizzo sostenuto e per impegno di utilizzo. Se gestisci un pool di risorse, gli sconti per utilizzo sostenuto possono farti risparmiare fino al 30% sul costo delle istanze in esecuzione 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 economico per utilizzare risorse potenti e a basso costo senza spese di capitale. Non esistono due pipeline di produzione uguali, pertanto nessun documento può coprire tutti gli argomenti e i requisiti unici. 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.