Dokumen ini memberikan panduan tentang cara memperluas renderfarm lokal yang sudah ada untuk menggunakan resource komputasi di Google Cloud. Dokumen ini mengasumsikan bahwa Anda telah menerapkan render farm di infrastruktur lokal dan telah memahami konsep dasar efek visual (VFX) dan pipeline animasi, software pengelolaan antrean, dan metode lisensi software yang umum.
Ringkasan
Merender elemen 2D atau 3D untuk animasi, film, iklan, atau video game memerlukan komputasi dan memakan waktu. Merender elemen ini memerlukan investasi besar dalam hardware dan infrastruktur bersama dengan tim profesional IT khusus untuk men-deploy dan memelihara hardware dan software.
Saat farm render lokal mencapai pemakaian 100 persen, pengelolaan tugas bisa menjadi tantangan. Prioritas dan dependensi tugas, memulai ulang frame yang dilepaskan, serta beban jaringan, disk, dan CPU semuanya menjadi bagian dari persamaan kompleks yang harus Anda pantau dan kontrol dengan cermat, sering kali dalam tenggat waktu yang sulit.
Untuk mengelola tugas ini, fasilitas VFX telah memasukkan software pengelolaan antrean ke dalam pipeline mereka. Software pengelolaan antrean dapat:
- Men-deploy pekerjaan ke resource lokal dan berbasis cloud.
- Mengelola ketergantungan antarpekerjaan.
- Berkomunikasi dengan sistem pengelolaan aset.
- Sediakan antarmuka pengguna dan API untuk bahasa umum seperti Python.
Meskipun beberapa software pengelolaan antrean dapat men-deploy tugas ke worker berbasis cloud, Anda tetap bertanggung jawab untuk terhubung ke cloud, menyinkronkan aset, memilih framework penyimpanan, mengelola template image, dan menyediakan pemberian lisensi software Anda sendiri.
Opsi berikut tersedia untuk membangun serta mengelola pipeline dan alur kerja render di lingkungan cloud atau hybrid cloud:
- Jika belum memiliki resource lokal atau cloud, Anda dapat menggunakan layanan render berbasis cloud software as a service (SaaS) seperti Conductor.
- Jika ingin mengelola infrastruktur sendiri, Anda dapat membangun dan men-deploy resource cloud yang dijelaskan dalam dokumen ini.
- Jika ingin membangun alur kerja kustom berdasarkan persyaratan spesifik Anda, Anda dapat bekerja sama dengan partner integrator layanan Google Cloud seperti Gunpowder atau AppsBroker. Opsi ini memiliki keuntungan karena dapat menjalankan semua layanan cloud di lingkungan Google Cloud Anda sendiri yang aman.
Untuk membantu menentukan solusi ideal bagi fasilitas Anda, hubungi perwakilan Google Cloud Anda.
Catatan: Catatan produksi muncul secara berkala di seluruh dokumen ini. Catatan ini menawarkan praktik terbaik yang harus diikuti saat Anda mem-build render farm.
Menghubungkan ke cloud
Bergantung pada workload Anda, tentukan cara fasilitas Anda terhubung ke Google Cloud, baik melalui ISP partner, koneksi langsung, atau melalui internet publik.
Menghubungkan melalui internet
Tanpa konektivitas khusus, Anda dapat terhubung ke jaringan Google dan menggunakan model keamanan end-to-end kami dengan mengakses layanan Google Cloud melalui internet. Utilitas seperti gcloud dan alat dan resource command line gsutil seperti Compute Engine API semua menggunakan autentikasi, otorisasi, dan enkripsi yang aman untuk membantu mengamankan data Anda.
Cloud VPN
Apa pun cara Anda terhubung, sebaiknya gunakan virtual private network (VPN) untuk mengamankan koneksi Anda.
Cloud VPN membantu Anda menghubungkan jaringan lokal dengan aman ke jaringan Virtual Private Cloud (VPC) Google melalui koneksi VPN IPsec. Data yang sedang dalam pengiriman akan dienkripsi sebelum lewat satu atau beberapa tunnel VPN.
Pelajari cara membuat VPN untuk project Anda.
VPN yang disediakan pelanggan
Meskipun Anda dapat menyiapkan gateway VPN Anda sendiri untuk terhubung langsung dengan Google, sebaiknya gunakan Cloud VPN, yang menawarkan lebih banyak fleksibilitas dan integrasi yang lebih baik dengan Google Cloud.
Cloud Interconnect
Google mendukung berbagai cara untuk menghubungkan infrastruktur Anda ke Google Cloud. Koneksi tingkat perusahaan ini, yang secara kolektif dikenal sebagai Cloud Interconnect, menawarkan ketersediaan yang lebih tinggi dan latensi yang lebih rendah daripada koneksi internet standar, serta harga traffic keluar yang lebih rendah.
Cross-Cloud Interconnect memungkinkan Anda membangun konektivitas khusus bandwidth tinggi ke Google Cloud untuk data Anda di cloud lain. Cara ini akan mengurangi kompleksitas jaringan, mengurangi biaya transfer data, dan memungkinkan render farm multicloud dengan throughput tinggi.
Dedicated Interconnect
Dedicated Interconnect menyediakan koneksi fisik langsung dan komunikasi RFC 1918 antara jaringan lokal Anda dan jaringan Google. Koneksi ini memberikan kapasitas koneksi melalui jenis koneksi berikut:
- Satu atau beberapa koneksi Ethernet 10 Gbps, dengan maksimum delapan koneksi atau total 80 Gbps per interkoneksi.
- Satu atau beberapa koneksi Ethernet 100 Gbps, dengan maksimum dua koneksi atau total 200 Gbps per interkoneksi.
Traffic Dedicated Interconnect tidak dienkripsi. Jika perlu mengirim data melalui Dedicated Interconnect dengan cara yang aman, Anda harus membuat koneksi VPN Anda sendiri. Cloud VPN tidak kompatibel dengan Dedicated Interconnect, sehingga Anda harus menyediakan VPN Anda sendiri dalam kasus ini.
Partner Interconnect
Partner Interconnect memberikan konektivitas antara jaringan lokal dan jaringan VPC Anda melalui penyedia layanan yang didukung. Koneksi Partner Interconnect berguna jika infrastruktur Anda berada di lokasi fisik yang tidak dapat menjangkau fasilitas kolokasi Dedicated Interconnect atau jika kebutuhan data Anda tidak menjamin seluruh koneksi 10-Gbps.
Jenis koneksi lainnya
Cara lain untuk terhubung ke Google mungkin tersedia di lokasi spesifik Anda. Untuk mendapatkan bantuan dalam menentukan cara terbaik dan paling hemat biaya untuk terhubung ke Google Cloud, hubungi perwakilan Google Cloud Anda.
Mengamankan konten Anda
Untuk menjalankan konten mereka di platform cloud publik apa pun, pemilik konten seperti studio Hollywood besar mewajibkan vendor mematuhi praktik terbaik keamanan yang ditentukan secara internal dan oleh organisasi seperti MPAA. Google Cloud menawarkan model keamanan zero-trust yang terintegrasi dalam produk seperti Google Workspace, BeyondCorp Enterprise, dan BeyondProd.
Setiap studio memiliki persyaratan berbeda untuk mengamankan workload rendering. Anda dapat menemukan laporan resmi keamanan dan dokumentasi kepatuhan di cloud.google.com/security.
Jika ada pertanyaan tentang proses audit kepatuhan keamanan, hubungi perwakilan Google Cloud Anda.
Mengatur proyek Anda
Project adalah komponen organisasi inti Google Cloud. Di fasilitas, Anda dapat mengatur tugas berdasarkan project masing-masing atau membaginya menjadi beberapa project. Misalnya, Anda mungkin ingin membuat project terpisah untuk fase pravisualisasi, riset dan pengembangan, serta produksi sebuah film.
Project menetapkan batas isolasi untuk data jaringan dan administrasi project. Namun, Anda dapat berbagi jaringan antar-project dengan VPC Bersama, yang memberi project terpisah dengan akses ke resource umum.
Catatan produksi: Buat project host VPC Bersama yang berisi resource dengan semua alat produksi Anda. Anda dapat menetapkan semua project yang dibuat di organisasi Anda sebagai project layanan VPC Bersama. Penetapan ini berarti bahwa setiap project di organisasi Anda dapat mengakses library, skrip, dan software yang sama dengan yang disediakan oleh project host.
Resource Organisasi
Anda dapat mengelola project di bagian resource Organisasi, yang mungkin sudah Anda tetapkan. Memigrasi semua project ke dalam organisasi akan memberikan sejumlah manfaat.
Catatan produksi: Tetapkan pengelola produksi sebagai pemilik project individual dan pengelolaan studio sebagai pemilik resource Organisasi.
Menentukan akses ke resource
Project memerlukan akses yang aman ke resource yang disertai pembatasan tempat pengguna atau layanan diizinkan untuk beroperasi. Untuk membantu Anda menentukan akses, Google Cloud menawarkan Identity and Access Management (IAM), yang dapat Anda gunakan untuk mengelola kontrol akses dengan menentukan peran dengan level akses tertentu ke resource tertentu.
Catatan produksi: Untuk membatasi akses pengguna hanya ke resource yang diperlukan untuk melakukan tugas tertentu berdasarkan peran mereka, terapkan prinsip hak istimewa terendah baik di infrastruktur lokal maupun di cloud.
Misalnya, pertimbangkan render worker, yang merupakan virtual machine (VM) yang dapat di-deploy dari template instance bawaan yang menggunakan image kustom Anda. Render worker yang berjalan di akun layanan dapat membaca dari Cloud Storage dan menulis ke penyimpanan yang terpasang, seperti filer cloud atau persistent disk. Namun, Anda tidak perlu menambahkan artis satu per satu ke project Google Cloud sama sekali, karena artis tersebut tidak memerlukan akses langsung ke resource cloud.
Anda dapat menetapkan peran untuk merender wrangler atau administrator project yang memiliki akses ke semua resource Compute Engine, yang memungkinkan mereka menjalankan fungsi pada resource yang tidak dapat diakses oleh pengguna lain.
Tentukan kebijakan untuk menentukan peran mana yang dapat mengakses jenis resource tertentu di organisasi Anda. Tabel berikut menunjukkan cara tugas produksi yang umum dipetakan ke peran IAM di Google Cloud.
| Tugas produksi | Nama peran | Jenis aset |
|---|---|---|
| Studio manager | resourcemanager.organizationAdmin |
Project Organisasi |
| Production manager | owner, editor |
Project |
| Render wrangler | compute.admin, iam.serviceAccountActor |
Project |
| Akun pengelolaan antrean | compute.admin, iam.serviceAccountActor |
Project Organisasi |
| Artis perorangan | [tidak ada akses] | Tidak berlaku |
Access scopes
Cakupan akses menawarkan cara untuk mengontrol izin instance yang berjalan, terlepas dari siapa yang login. Anda dapat menentukan cakupan ketika membuat instance sendiri, atau ketika software pengelolaan antrean men-deploy resource dari template instance.
Cakupan lebih diutamakan daripada izin IAM setiap pengguna atau akun layanan. Prioritas ini berarti bahwa cakupan akses dapat mencegah administrator project login ke instance untuk menghapus bucket penyimpanan atau mengubah setelan firewall.
Catatan produksi: Secara default, instance dapat
membaca, tetapi tidak dapat menulis ke Cloud Storage. Jika pipeline render Anda menulis
render yang sudah selesai kembali ke Cloud Storage, tambahkan
devstorage.read_write cakupan ke instance Anda pada saat pembuatan.
Memilih cara men-deploy resource
Dengan rendering cloud, Anda dapat menggunakan resource hanya saat diperlukan, tetapi Anda dapat memilih dari beberapa cara untuk menyediakan resource untuk render farm Anda.
Men-deploy sesuai permintaan
Untuk penggunaan resource yang optimal, Anda dapat memilih untuk men-deploy render worker hanya saat mengirim tugas ke render farm. Anda dapat men-deploy banyak VM untuk dibagikan di seluruh frame dalam tugas, atau bahkan membuat satu VM per frame.
Sistem pengelolaan antrean Anda dapat memantau instance yang sedang berjalan, yang dapat diantrekan kembali jika VM di-preempt, dan dihentikan saat setiap tugas selesai.
Men-deploy kumpulan resource
Anda juga dapat memilih untuk men-deploy grup instance, yang tidak terkait dengan tugas tertentu, yang dapat diakses oleh sistem pengelolaan antrean lokal Anda sebagai resource tambahan. Jika Anda menggunakan Spot VM Google Cloud, grup instance yang berjalan dapat menerima beberapa tugas per VM, menggunakan semua core dan memaksimalkan penggunaan resource. Pendekatan ini mungkin merupakan strategi yang paling mudah untuk diterapkan karena meniru cara render farm lokal diisi dengan tugas.
Melisensikan software
Pemberian lisensi software pihak ketiga dapat sangat bervariasi dari satu paket ke paket lainnya. Berikut adalah beberapa skema dan model pemberian lisensi yang mungkin Anda temui di pipeline VFX. Untuk setiap skema, kolom ketiga menampilkan pendekatan pemberian lisensi yang direkomendasikan.
| Skema | Deskripsi | Rekomendasi |
|---|---|---|
| Dikunci dengan node | Diberi lisensi pada alamat MAC, alamat IP, atau ID CPU tertentu. Hanya dapat dijalankan oleh satu proses. | Berbasis instance |
| Berbasis node | Dilisensikan ke node tertentu (instance). Jumlah pengguna atau proses arbitrer dapat berjalan pada node berlisensi. | Berbasis instance |
| Mengambang | Diperiksa dari server lisensi yang melacak penggunaan. | Server lisensi |
| Pemberian lisensi software | ||
| Interaktif | Memungkinkan pengguna menjalankan software secara interaktif di lingkungan berbasis grafis. | Server lisensi atau berbasis instance |
| Batch | Mengizinkan pengguna menjalankan software hanya di lingkungan command line. | Server lisensi |
| Pemberian lisensi berbasis cloud | ||
| Berbasis penggunaan | Diperiksa hanya ketika proses berjalan pada instance cloud. Setelah proses selesai atau berakhir, lisensi akan dirilis. | Server lisensi berbasis cloud |
| Berbasis waktu beroperasi | Diperiksa saat instance aktif dan berjalan. Saat instance dihentikan atau dihapus, lisensi akan dirilis. | Server lisensi berbasis cloud |
Menggunakan pemberian lisensi berbasis instance
Beberapa program software atau plugin dilisensikan langsung ke hardware tempat program tersebut dijalankan. Pendekatan pemberian lisensi ini dapat menimbulkan masalah di cloud, karena ID hardware seperti alamat IP atau MAC ditetapkan secara dinamis.
Alamat MAC
Saat dibuat, instance diberi alamat MAC yang dipertahankan selama instance tidak dihapus. Anda dapat menghentikan atau memulai ulang instance, dan alamat MAC akan dipertahankan. Anda dapat menggunakan alamat MAC ini untuk pembuatan dan validasi lisensi hingga instance tersebut dihapus.
Menetapkan alamat IP statis
Saat Anda membuat instance, instance tersebut akan diberi alamat IP internal dan, secara opsional, alamat IP eksternal. Untuk mempertahankan alamat IP eksternal instance, Anda dapat mencadangkan alamat IP statis dan menetapkannya ke instance Anda. Alamat IP ini akan dicadangkan hanya untuk instance ini. Alamat IP statis merupakan resource berbasis project, maka alamat IP tersebut tunduk pada kuota regional.
Anda juga dapat menetapkan alamat IP internal saat membuat instance. Hal ini berguna jika Anda ingin alamat IP internal grup instance berada dalam rentang yang sama.
Dongle hardware
Software lama mungkin masih dilisensikan melalui dongle, kunci hardware yang diprogram dengan lisensi produk. Sebagian besar perusahaan software telah berhenti menggunakan dongle hardware, tetapi beberapa pengguna mungkin memiliki software lama yang terkait dengan salah satu perangkat ini. Jika mengalami masalah ini, hubungi produsen software untuk mengetahui apakah mereka dapat memberi Anda lisensi terbaru untuk software tertentu.
Jika produsen software tidak dapat menyediakan lisensi tersebut, Anda dapat menerapkan hub USB yang terpasang di jaringan atau solusi USB melalui IP.
Menggunakan server lisensi
Sebagian besar software modern menawarkan opsi lisensi mengambang. Opsi ini paling masuk akal di lingkungan cloud, tetapi memerlukan pengelolaan lisensi dan kontrol akses yang lebih kuat untuk mencegah penggunaan lisensi yang berlebihan dalam jumlah terbatas.
Agar tidak melebihi kapasitas lisensi, Anda dapat, sebagai bagian dari proses antrean tugas, memilih lisensi yang akan digunakan dan mengontrol jumlah tugas yang menggunakan lisensi.
Server lisensi lokal
Anda dapat menggunakan server lisensi lokal yang sudah ada untuk memberikan lisensi ke instance yang berjalan di cloud. Jika memilih metode ini, Anda harus menyediakan cara bagi render worker untuk berkomunikasi dengan jaringan lokal, baik melalui VPN maupun beberapa koneksi aman lainnya.
Server lisensi berbasis cloud
Di cloud, Anda dapat menjalankan server lisensi yang menyajikan instance dalam project atau bahkan lintas project menggunakan VPC Bersama. Lisensi mengambang terkadang ditautkan ke alamat MAC hardware, sehingga instance kecil yang berjalan lama dengan alamat IP statis dapat dengan mudah menyajikan lisensi ke banyak instance render.
Server lisensi hybrid
Beberapa software dapat menggunakan beberapa server lisensi dalam urutan yang diprioritaskan. Misalnya, perender mungkin mengkueri jumlah lisensi yang tersedia dari server lokal, dan jika tidak ada yang tersedia, gunakan server lisensi berbasis cloud. Strategi ini dapat membantu memaksimalkan penggunaan lisensi permanen sebelum Anda mencoba jenis lisensi lainnya.
Catatan produksi: Menentukan satu atau beberapa server lisensi di variabel lingkungan dan menentukan urutan prioritas; Autodesk Arnold, perender populer, membantu Anda melakukan hal ini. Jika tugas tidak dapat memperoleh lisensi dengan menggunakan server pertama, tugas tersebut akan mencoba menggunakan server lain yang tercantum, seperti dalam contoh berikut:
export solidangle_LICENSE=5053@x.x.0.1;5053@x.x.0.2
Pada contoh sebelumnya, perender Arnold mencoba mendapatkan lisensi dari
server di x.x.0.1, 5053 port. Jika gagal, upaya tersebut akan mencoba mendapatkan
lisensi dari port yang sama di alamat IP x.x.0.2.
Pemberian lisensi berbasis cloud
Beberapa vendor menawarkan lisensi berbasis cloud yang menyediakan lisensi software sesuai permintaan untuk instance Anda. Pemberian lisensi berbasis cloud umumnya ditagih dalam dua cara: berbasis penggunaan dan berbasis waktu beroperasi.
Pemberian lisensi berbasis penggunaan
Pemberian lisensi berbasis penggunaan ditagih berdasarkan durasi penggunaan software. Biasanya dengan jenis pemberian lisensi ini, lisensi diperiksa dari server berbasis cloud saat proses dimulai dan dirilis ketika proses selesai. Selama lisensi diperiksa, Anda akan ditagih atas penggunaan lisensi tersebut. Jenis pemberian lisensi ini biasanya digunakan untuk software rendering.
Pemberian lisensi berbasis waktu beroperasi
Lisensi berbasis waktu beroperasi atau berkuota ditagih berdasarkan waktu beroperasi instance Compute Engine Anda. Instance dikonfigurasi untuk terdaftar dengan server lisensi berbasis cloud selama proses startup. Selama instance berjalan, lisensi akan diperiksa. Saat instance dihentikan atau dihapus, lisensi akan dirilis. Jenis pemberian lisensi ini biasanya digunakan untuk render worker yang di-deploy oleh queue manager.
Memilih cara menyimpan data Anda
Jenis penyimpanan yang Anda pilih di Google Cloud bergantung pada strategi penyimpanan yang Anda pilih serta faktor-faktor seperti persyaratan ketahanan dan biaya.
Persistent disk
Anda mungkin dapat menghindari penerapan server file sepenuhnya dengan menyertakan persistent disk (PD) ke dalam workload Anda. PD adalah jenis block storage yang sesuai dengan POSIX, berukuran hingga 64 TB, yang tidak asing bagi sebagian besar fasilitas VFX. Persistent disk tersedia sebagai drive standar dan solid state drive (SSD). Anda dapat melampirkan PD dalam mode baca-tulis ke satu instance, atau dalam mode hanya baca ke sejumlah besar instance, seperti sekelompok render worker.
| Kelebihan | Kekurangan | Kasus penggunaan ideal |
|---|---|---|
| Dipasang sebagai volume NFS atau SMB standar. Dapat mengubah ukuran secara dinamis. Hingga 128 PD dapat ditambahkan ke satu instance. PD yang sama dapat dipasang sebagai hanya baca di ratusan atau ribuan instance. |
Ukuran maksimum 64 TB. Hanya dapat menulis ke PD jika terpasang ke satu instance. Hanya dapat diakses oleh resource yang berada di region yang sama. |
Pipeline lanjutan yang dapat membuat disk baru per tugas. Pipeline yang menyajikan data yang jarang diupdate, seperti software atau library umum, untuk merender worker. |
Penyimpanan objek
Cloud Storage adalah penyimpanan yang sangat redundan dan sangat tahan lama, yang tidak seperti sistem file tradisional, tidak terstruktur dan kapasitasnya hampir tidak terbatas. File di Cloud Storage disimpan di bucket, yang mirip dengan folder, dan dapat diakses di seluruh dunia.
Tidak seperti penyimpanan tradisional, penyimpanan objek tidak dapat dipasang sebagai volume logis oleh sistem operasi (OS). Jika memutuskan untuk menggabungkan penyimpanan objek ke dalam pipeline render, Anda harus mengubah cara membaca dan menulis data, baik melalui utilitas command line seperti gsutil atau melalui Cloud Storage API.
| Kelebihan | Kekurangan | Kasus penggunaan ideal |
|---|---|---|
| Penyimpanan tahan lama dan sangat tersedia untuk semua ukuran file. Satu API untuk seluruh kelas penyimpanan. Murah. Data tersedia di seluruh dunia. Kapasitas yang hampir tidak terbatas. |
Tidak sesuai dengan POSIX. Harus diakses melalui API atau utilitas command line. Dalam pipeline render, data harus ditransfer secara lokal sebelum digunakan. |
Pipeline render dengan sistem pengelolaan aset yang dapat memublikasikan data ke
Cloud Storage. Pipeline render dengan sistem pengelolaan antrean yang dapat mengambil data dari Cloud Storage sebelum rendering. |
Produk penyimpanan lainnya
Produk penyimpanan lainnya tersedia sebagai layanan terkelola, melalui saluran pihak ketiga seperti Cloud Marketplace, atau sebagai project open source melalui repositori software atau GitHub.
| Produk | Kelebihan | Kekurangan | Kasus penggunaan ideal |
|---|---|---|---|
| Filestore | Sistem file yang dikelompokkan dan dapat mendukung ribuan koneksi NFS
secara bersamaan. Dapat disinkronkan dengan cluster NAS lokal. |
Tidak ada cara untuk menyinkronkan file secara selektif. Tidak ada sinkronisasi dua arah. | Fasilitas VFX sedang hingga besar dengan ratusan TB data untuk disajikan di cloud. |
| Pixit Media, PixStor | Sistem file penyebaran skala yang dapat mendukung ribuan klien NFS atau POSIX secara bersamaan. Data dapat di-cache sesuai permintaan dari NAS lokal, dan update otomatis dikirim kembali ke penyimpanan lokal. | Biaya, dukungan pihak ketiga dari Pixit. | Fasilitas VFX sedang hingga besar dengan ratusan TB data untuk disajikan di cloud. |
| Volume NetApp Google Cloud | Solusi penyimpanan yang terkelola sepenuhnya di Google Cloud. Mendukung lingkungan NFS, SMB, dan multiprotokol. Ringkasan waktu dengan pemulihan instance |
Hanya tersedia di region Google Cloud tertentu. | VFX dengan pipeline yang mampu menyinkronkan
aset. Disk bersama di berbagai workstation virtual. |
| Cloud Storage FUSE | Memasang bucket Cloud Storage sebagai sistem file. Hemat biaya. | Bukan sistem file yang sesuai dengan POSIX. Mungkin sulit dikonfigurasi dan dioptimalkan. | Fasilitas VFX yang dapat men-deploy, mengonfigurasi, dan memelihara sistem file open source, dengan pipeline yang dapat menyinkronkan aset. |
Jenis penyimpanan lainnya tersedia di Google Cloud. Untuk mengetahui informasi selengkapnya, hubungi perwakilan Google Cloud Anda.
Bacaan lebih lanjut tentang opsi penyimpanan data
- Opsi penyimpanan yang tersedia di Google Cloud
- Penyimpanan file di Compute Engine
- Mendesain strategi penyimpanan yang optimal untuk workload cloud Anda
Menerapkan strategi penyimpanan
Anda dapat mengimplementasikan sejumlah strategi penyimpanan di VFX atau pipeline produksi animasi dengan menetapkan konvensi yang menentukan cara menangani data Anda, baik dengan mengakses data langsung dari penyimpanan lokal maupun melakukan sinkronisasi penyimpanan lokal dan cloud.
Strategi 1: Memasang penyimpanan lokal secara langsung
Jika fasilitas Anda memiliki konektivitas ke Google Cloud minimal 10 Gbps dan dekat dengan region Google Cloud, Anda dapat memilih untuk memasang NAS lokal langsung pada cloud render worker. Meskipun sederhana, strategi ini juga dapat menghabiskan biaya dan bandwidth, karena apa pun yang Anda buat di cloud dan ditulis kembali ke penyimpanan dihitung sebagai data traffic keluar.
| Kelebihan | Kekurangan | Kasus penggunaan ideal |
|---|---|---|
| Penerapan yang mudah. Membaca/menulis ke penyimpanan umum. Ketersediaan data langsung, tanpa perlu caching atau sinkronisasi. |
Bisa lebih mahal daripada opsi lainnya. Memerlukan kedekatan dengan pusat data Google untuk mencapai latensi rendah. Jumlah maksimum instance yang dapat dihubungkan ke NAS lokal bergantung pada bandwidth dan jenis koneksi Anda. |
Fasilitas di dekat pusat data Google yang perlu melakukan burst render workload ke
cloud, yang tidak perlu mengkhawatirkan biaya. Fasilitas dengan konektivitas ke Google Cloud minimal 10 Gbps. |
Strategi 2: Menyinkronkan sesuai permintaan
Anda dapat memilih untuk push data ke cloud atau push data dari penyimpanan lokal, atau sebaliknya, hanya saat data diperlukan, seperti saat frame dirender atau aset dipublikasikan. Jika Anda menggunakan strategi ini, sinkronisasi dapat dipicu oleh mekanisme dalam pipeline, seperti skrip watch, oleh pengendali peristiwa seperti Pub/Sub, atau dengan serangkaian perintah sebagai bagian dari skrip tugas.
Anda dapat melakukan sinkronisasi dengan menggunakan berbagai perintah, seperti perintah scp gcloud, perintah rsync gsutil , atau protokol transfer data berbasis UDP (UDT). Jika Anda memilih untuk menggunakan UDT pihak ketiga seperti Aspera, Cloud FastPath, BitSpeed, atau FDT untuk berkomunikasi dengan bucket Cloud Storage, lihat dokumentasi pihak ketiga untuk mempelajari model keamanan dan praktik terbaiknya. Google tidak mengelola layanan pihak ketiga ini.
Metode push
Biasanya, Anda menggunakan metode push saat memublikasikan aset, menempatkan file dalam folder watch, atau menyelesaikan tugas render, setelah itu Anda mengirimkannya ke lokasi yang telah ditentukan.
Contoh:
- Cloud render worker menyelesaikan tugas render, dan frame yang dihasilkan didorong kembali ke penyimpanan lokal.
- Seorang artis memublikasikan aset. Bagian dari proses publikasi aset meliputi pengiriman data terkait ke jalur yang telah ditetapkan di Cloud Storage.
Metode pull
Gunakan metode pull saat file diminta, biasanya oleh instance render berbasis cloud.
Contoh: Sebagai bagian dari skrip tugas render, semua aset yang diperlukan untuk merender scene akan ditarik ke dalam sistem file sebelum rendering, tempat semua render worker dapat mengaksesnya.
| Kelebihan | Kekurangan | Kasus penggunaan ideal |
|---|---|---|
| Kontrol penuh atas data mana yang disinkronkan dan kapan. Kemampuan untuk memilih metode dan protokol transfer. |
Pipeline produksi Anda harus dapat menangani peristiwa yang memicu
sinkronisasi push/pull. Resource tambahan mungkin diperlukan untuk menangani antrean sinkronisasi. |
Fasilitas kecil hingga besar yang memiliki pipeline kustom dan menginginkan kontrol penuh atas sinkronisasi aset. |
Catatan produksi: Mengelola sinkronisasi data dengan sistem pengelolaan antrean yang sama dengan yang Anda gunakan untuk menangani tugas render. Tugas sinkronisasi dapat menggunakan resource cloud terpisah untuk memaksimalkan bandwidth yang tersedia dan meminimalkan traffic jaringan.
Strategi 3: Penyimpanan lokal, cache baca-tayang berbasis cloud
Google Cloud telah memperluas dan mengembangkan solusi caching KNFSD sebagai opsi open source. Solusi ini dapat menangani permintaan performa render farm yang melebihi kemampuan infrastruktur penyimpanan. Cache KNFSD menawarkan cache baca-tayang berperforma tinggi, yang memungkinkan beban kerja menskalakan hingga ratusan—atau bahkan ribuan—node render di beberapa region dan kumpulan penyimpanan hybrid.
Cache KNFSD adalah solusi penyebaran skala yang mengurangi beban pada layanan berbagi file utama. Cache KNFSD juga mengurangi efek kelebihan beban saat banyak node render mencoba mengambil file dari server file secara bersamaan. Dengan menggunakan lapisan caching di jaringan VPC yang sama dengan node render, latensi baca berkurang, sehingga tugas render dimulai dan diselesaikan lebih cepat. Bergantung pada cara Anda mengonfigurasi server file cache, data tetap berada dalam cache hingga:
- Data sudah usang, atau tetap tidak tersentuh selama jangka waktu tertentu.
- Ruang diperlukan di server file, dan saat ini data dihapus dari cache berdasarkan usia.
Strategi ini mengurangi jumlah bandwidth dan kompleksitas yang diperlukan untuk men-deploy banyak instance render serentak.
Dalam beberapa kasus, Anda mungkin ingin melakukan prapenyiapan pada cache untuk memastikan bahwa semua
data terkait tugas ada sebelum rendering. Untuk melakukan prapenyiapan cache, baca
konten direktori yang ada di server file cloud Anda dengan menjalankan read
atau stat dari satu atau beberapa file. Mengakses file dengan cara ini akan memicu
mekanisme sinkronisasi.
Anda juga dapat menambahkan peralatan lokal fisik untuk berkomunikasi dengan alat virtual. Misalnya, NetApp menawarkan solusi penyimpanan yang dapat lebih mengurangi latensi antara penyimpanan lokal dan cloud.
| Kelebihan | Kekurangan | Kasus penggunaan ideal |
|---|---|---|
| Data yang tersimpan di cache dikelola secara otomatis. Mengurangi persyaratan bandwidth. Sistem file cloud yang dikelompokkan dapat ditingkatkan atau diturunkan skalanya bergantung pada persyaratan tugas. |
Dapat dikenai biaya tambahan. Tugas prapekerjaan harus diterapkan jika Anda memilih untuk melakukan prapenyiapan cache. |
Fasilitas besar yang men-deploy banyak instance serentak dan membaca aset umum di banyak tugas. |
Memfilter data
Anda dapat membuat database jenis aset dan kondisi terkait untuk menentukan apakah akan menyinkronkan jenis data tertentu atau tidak. Anda mungkin tidak ingin menyinkronkan beberapa jenis data, seperti data sementara yang dihasilkan sebagai bagian dari proses konversi, file cache, atau data simulasi. Pertimbangkan juga apakah Anda perlu menyinkronkan aset yang tidak disetujui, karena tidak semua iterasi akan digunakan dalam render akhir.
Melakukan transfer massal awal
Saat menerapkan hybrid render farm, Anda mungkin ingin melakukan transfer awal semua atau sebagian set data ke Cloud Storage, persistent disk, atau penyimpanan berbasis cloud lainnya. Bergantung pada faktor seperti jumlah dan jenis data yang akan ditransfer, serta kecepatan koneksi, Anda mungkin dapat melakukan sinkronisasi penuh dalam beberapa hari atau minggu. Gambar berikut membandingkan waktu yang biasa untuk transfer online dan fisik.
Jika workload transfer Anda melebihi batasan waktu atau bandwidth, Google menawarkan sejumlah opsi transfer untuk memindahkan data Anda ke cloud, termasuk Transfer Appliance.
Pengarsipan dan pemulihan dari bencana
Perbedaan antara pengarsipan data dan pemulihan dari bencana perlu diperhatikan. Yang pertama adalah salinan selektif tugas yang sudah selesai, sedangkan yang kedua adalah status data yang dapat dipulihkan. Sebaiknya rancang disaster recovery plan yang sesuai dengan kebutuhan fasilitas Anda dan sediakan rencana darurat di luar lokasi. Konsultasikan dengan vendor penyimpanan lokal untuk mendapatkan bantuan terkait disaster recovery plan yang sesuai dengan platform penyimpanan spesifik Anda.
Mengarsipkan data di cloud
Setelah project selesai, biasanya tugas yang sudah selesai disimpan ke dalam beberapa bentuk penyimpanan jangka panjang, biasanya media pita magnetik seperti LTO. Kartrid ini tunduk pada persyaratan lingkungan dan, dari waktu ke waktu, pengelolaannya bisa menjadi sulit. Fasilitas produksi yang besar terkadang menyimpan seluruh arsipnya di ruang yang dibuat khusus dengan pengarsipan purnawaktu untuk melacak data dan mengambilnya saat diminta.
Menelusuri aset, foto, atau rekaman video tertentu yang diarsipkan dapat menghabiskan waktu, karena data mungkin disimpan di beberapa kartrid, pengindeksan arsip mungkin tidak ada atau tidak lengkap, atau mungkin ada batasan kecepatan untuk membaca data dari pita magnetik.
Dengan memigrasikan arsip data ke cloud, Anda tidak hanya dapat menghilangkan kebutuhan akan pengelolaan lokal dan penyimpanan media arsip, tetapi juga membuat data Anda jauh lebih mudah diakses dan ditelusuri daripada metode arsip tradisional.
Pipeline pengarsipan dasar mungkin terlihat seperti diagram berikut, yang menggunakan berbagai layanan cloud untuk memeriksa, mengategorikan, memberi tag, dan mengatur arsip. Dari cloud, Anda dapat membuat alat pengelolaan dan pengambilan arsip untuk menelusuri data menggunakan berbagai kriteria metadata seperti tanggal, project, format, atau resolusi. Anda juga dapat menggunakan Machine Learning API untuk memberi tag dan mengategorikan image serta video, dan menyimpan hasilnya dalam database berbasis cloud seperti BigQuery.
Topik selanjutnya yang perlu dipertimbangkan:
- Otomatiskan pembuatan thumbnail atau proxy untuk konten yang berada dalam kelas penyimpanan Cloud Storage yang memiliki biaya pengambilan. Gunakan proxy ini dalam sistem pengelolaan aset media Anda sehingga pengguna dapat menjelajahi data sambil hanya membaca proxy, bukan aset yang diarsipkan.
- Pertimbangkan untuk menggunakan machine learning guna mengategorikan konten live action. Gunakan Cloud Vision untuk memberi label tekstur dan pelat latar belakang, atau Video Intelligence API untuk membantu penelusuran dan pengambilan rekaman video referensi.
- Anda juga dapat menggunakan image Vertex AI AutoML untuk membuat model image kustom guna mengenali aset apa pun, baik live action atau yang dirender.
- Untuk konten yang dirender, sebaiknya simpan salinan disk image render worker bersama dengan aset yang dirender. Jika perlu membuat ulang penyiapan, Anda akan memiliki versi software, plugin, library OS, dan dependensi yang benar jika perlu merender ulang foto yang diarsipkan.
Mengelola aset dan produksi
Mengerjakan project yang sama di beberapa fasilitas dapat menghadirkan tantangan unik, terutama ketika konten dan aset harus tersedia di seluruh dunia. Menyinkronkan data secara manual di seluruh jaringan pribadi dapat memerlukan biaya yang mahal dan memerlukan resource, serta tunduk pada batasan bandwidth lokal.
Jika workload Anda memerlukan data yang tersedia secara global, Anda mungkin dapat menggunakan Cloud Storage, yang dapat diakses dari mana saja untuk mengakses layanan Google. Untuk menggabungkan Cloud Storage ke dalam pipeline, Anda harus mengubah pipeline untuk memahami jalur objek, lalu menarik atau mengirim data Anda ke render worker sebelum rendering. Penggunaan metode ini akan memberikan akses global ke data yang dipublikasikan, tetapi memerlukan pipeline Anda untuk mengirimkan aset ke tempat yang dibutuhkan dalam jumlah waktu yang wajar.
Misalnya, seniman tekstur di Los Angeles dapat memublikasikan file image untuk digunakan oleh seniman pencahayaan di London. Prosesnya terlihat seperti ini:
- Pipeline publikasi mengirim file ke Cloud Storage dan menambahkan entri ke database aset berbasis cloud.
- Seorang artis di London menjalankan skrip untuk mengumpulkan aset untuk adegan. Lokasi file dikueri dari database dan dibaca dari Cloud Storage ke disk lokal.
- Software pengelolaan antrean mengumpulkan daftar aset yang diperlukan untuk rendering, mengkuerinya dari database aset, dan mendownloadnya dari Cloud Storage ke penyimpanan lokal setiap render worker.
Menggunakan Cloud Storage seperti ini juga memberi Anda arsip semua data yang dipublikasikan di cloud jika Anda memilih untuk menggunakan Cloud Storage sebagai bagian dari pipeline arsip Anda.
Mengelola database
Software pengelolaan aset dan produksi bergantung pada database yang sangat tersedia dan tahan lama, yang disalurkan di host yang mampu menangani ratusan atau ribuan kueri per detik. Database biasanya dihosting di server lokal yang berjalan di rak yang sama dengan render workers, dan memiliki batasan daya, jaringan, serta HVAC yang sama.
Sebaiknya Anda menjalankan database produksi MySQL, NoSQL, dan PostgreSQL sebagai layanan berbasis cloud terkelola. Layanan ini sangat tersedia dan dapat diakses secara global, mengenkripsi data dalam penyimpanan maupun dalam pengiriman, serta menawarkan fungsi replikasi bawaan.
Mengelola antrean
Program software pengelolaan antrean yang tersedia secara komersial, seperti Qube!, Batas waktu, dan Tractor banyak digunakan di industri VFX/animasi. Ada juga opsi software open source yang tersedia, seperti OpenCue. Anda dapat menggunakan software ini untuk men-deploy dan mengelola workload komputasi apa pun di berbagai worker, bukan hanya render. Anda dapat men-deploy dan mengelola publikasi aset, simulasi partikel dan cairan, baking tekstur, dan komposisi dengan framework penjadwalan yang sama yang Anda gunakan untuk mengelola render.
Beberapa fasilitas telah menerapkan software penjadwalan tujuan umum seperti HTCondor dari University of Wisconsin, Slurm dari SchedMD, atau Univa Grid Engine ke dalam pipeline VFX mereka. Namun, software yang dirancang khusus untuk industri VFX memberikan perhatian khusus pada fitur seperti berikut:
- Dependens berbasis tugas, frame, dan lapisan. Beberapa tugas perlu diselesaikan sebelum Anda dapat memulai tugas lain. Misalnya, jalankan simulasi cairan secara keseluruhan sebelum rendering.
- Prioritas tugas, yang dapat digunakan oleh render wrangler untuk mengubah urutan tugas berdasarkan batas waktu dan jadwal masing-masing.
- Jenis resource, label, atau target, yang dapat Anda gunakan untuk mencocokkan resource tertentu dengan tugas yang memerlukannya. Misalnya, deploy render yang dipercepat GPU hanya pada VM yang terpasang GPU.
- Merekam data historis terkait penggunaan resource dan menyediakannya melalui API atau dasbor untuk analisis lebih lanjut. Misalnya, lihat penggunaan CPU dan memori rata-rata untuk beberapa iterasi terakhir render guna memprediksi penggunaan resource untuk iterasi berikutnya.
- Tugas sebelum dan sesudah periode tayang. Misalnya, tugas praperiode tayang menarik semua aset yang diperlukan ke render worker lokal sebelum rendering. Tugas pascaperiode tayang akan menyalin frame hasil render ke lokasi yang ditentukan pada sistem file, lalu menandai frame sebagai selesai dalam sistem pengelolaan aset.
- Integrasi dengan aplikasi software 2D dan 3D yang populer seperti Maya, 3ds Max, Houdini, Cinema 4D, atau Nuke.
Catatan produksi: Gunakan software pengelolaan antrean untuk mengenali kumpulan resource berbasis cloud seolah-olah resource tersebut adalah render worker lokal. Metode ini memerlukan beberapa pengawasan untuk memaksimalkan penggunaan resource dengan menjalankan sebanyak mungkin render yang dapat ditangani setiap instance, sebuah teknik yang dikenal sebagai bin packing. Operasi ini biasanya ditangani secara algoritmis dan oleh wrangler render.
Anda juga dapat mengotomatiskan pembuatan, pengelolaan, dan penghentian resource berbasis cloud secara on-demand. Metode ini mengandalkan queue manager Anda untuk menjalankan skrip pra-render dan pasca-render yang membuat resource sesuai kebutuhan, memantaunya selama rendering, dan menghentikannya setelah tugas selesai.
Mempertimbangkan deployment pekerjaan
Saat Anda mengimplementasikan render farm yang menggunakan penyimpanan lokal dan berbasis cloud, berikut adalah beberapa pertimbangan yang mungkin perlu diperhatikan oleh queue manager Anda:
- Pemberian lisensi dapat berbeda antara deployment cloud dan lokal. Beberapa lisensi berbasis node, beberapa berbasis proses. Pastikan software pengelolaan antrean Anda men-deploy tugas untuk memaksimalkan nilai lisensi Anda.
- Pertimbangkan untuk menambahkan tag atau label unik ke resource berbasis cloud untuk memastikan bahwa tag atau label tersebut hanya digunakan saat ditetapkan ke jenis tugas tertentu.
- Gunakan Cloud Logging untuk mendeteksi instance yang tidak digunakan atau tidak ada aktivitas.
- Saat meluncurkan pekerjaan dependen, pertimbangkan lokasi tempat data yang dihasilkan akan berada dan lokasi yang diperlukan untuk langkah berikutnya.
- Jika namespace jalur Anda berbeda antara penyimpanan lokal dan berbasis cloud, pertimbangkan untuk menggunakan jalur relatif agar rendering dapat menjadi agnostik lokasi. Atau, bergantung pada platform, Anda dapat membuat mekanisme untuk menukar jalur pada waktu render.
- Beberapa render, simulasi, atau pascaproses mengandalkan pembuatan angka acak, yang dapat berbeda-beda di setiap produsen CPU. Bahkan CPU dari produsen yang sama, tetapi generasi chip yang berbeda dapat memberikan hasil yang berbeda. Jika ragu, gunakan jenis CPU yang identik atau serupa untuk semua frame tugas.
- Jika Anda menggunakan alat cache baca-tayang, pertimbangkan untuk men-deploy tugas praperiode tayang untuk melakukan prapenyiapan cache dan memastikan bahwa semua aset tersedia di cloud sebelum Anda men-deploy resource cloud. Pendekatan ini meminimalkan jumlah waktu yang membuat render worker terpaksa menunggu saat aset dipindahkan ke cloud.
Logging dan pemantauan
Perekaman dan pemantauan penggunaan serta performa resource adalah aspek penting setiap render farm. Google Cloud menawarkan sejumlah API, alat, dan solusi untuk membantu memberikan insight tentang penggunaan resource dan layanan.
Cara tercepat untuk memantau aktivitas VM adalah dengan melihat output port serial-nya. Output ini dapat berguna saat instance tidak responsif melalui bidang kontrol layanan standar, seperti supervisor pengelolaan antrean render.
Cara lain untuk mengumpulkan dan memantau penggunaan resource di Google Cloud meliputi:
- Gunakan Cloud Logging untuk merekam log penggunaan dan audit, serta untuk mengekspor log yang dihasilkan ke Cloud Storage, BigQuery, dan layanan lainnya.
- Gunakan Cloud Monitoring untuk menginstal agen di VM Anda untuk memantau sistem metrics.
- Gabungkan Cloud Logging API ke dalam skrip pipeline untuk login langsung ke Cloud Logging menggunakan library klien untuk bahasa skrip yang populer.
- Gunakan Cloud Monitoring untuk membuat diagram guna memahami penggunaan resource.
Mengonfigurasi worker instance render
Agar workload Anda benar-benar hybrid, node render lokal harus identik dengan node render berbasis cloud, dengan versi OS, build kernel, library yang diinstal, dan software yang cocok. Anda mungkin juga perlu memperbanyak titik pemasangan, namespace jalur, dan bahkan lingkungan pengguna di cloud, karena keduanya bersifat lokal.
Memilih disk image
Anda dapat memilih dari salah satu image publik atau membuat image kustom Anda sendiri yang didasarkan pada image node render lokal. Image publik mencakup kumpulan paket yang menyiapkan dan mengelola akun pengguna serta mengaktifkan autentikasi berbasis kunci Secure Shell (SSH).
Membuat image kustom
Jika memilih untuk membuat image kustom, Anda harus menambahkan lebih banyak library ke Linux dan Windows agar dapat berfungsi dengan baik di lingkungan Compute Engine.
Image kustom Anda harus mematuhi praktik terbaik keamanan. Jika Anda menggunakan Linux, instal lingkungan tamu Linux untuk Compute Engine agar dapat mengakses fungsionalitas yang disediakan oleh image publik secara default. Dengan menginstal lingkungan tamu, Anda dapat melakukan tugas-tugas, seperti akses metadata, konfigurasi sistem, dan mengoptimalkan OS untuk digunakan di Google Cloud, dengan menggunakan kontrol keamanan yang sama pada image kustom Anda dengan yang Anda gunakan pada image publik.
Catatan produksi: Mengelola image kustom Anda dalam project terpisah di level organisasi. Pendekatan ini memberi Anda kontrol yang lebih akurat atas cara gambar dibuat atau diubah, dan memungkinkan Anda menerapkan versions, yang akan berguna saat menggunakan berbagai software atau versi OS di beberapa produksi.
Mengotomatiskan pembuatan image dan deployment instance
Anda dapat menggunakan alat seperti Packer untuk menjadikan image lebih mudah diperbanyak, dapat diaudit, dapat dikonfigurasi, dan diandalkan. Anda juga dapat menggunakan alat seperti Ansible untuk mengonfigurasi node render yang sedang berjalan dan menerapkan kontrol terperinci atas konfigurasi dan siklus prosesnya.
Memilih jenis mesin
Di Google Cloud, Anda dapat memilih salah satu jenis mesin yang telah ditetapkan atau menentukan jenis mesin kustom. Dengan menggunakan Jenis Mesin Kustom, Anda dapat mengontrol resource sehingga instance dapat disesuaikan berdasarkan jenis tugas yang dijalankan di Google Cloud. Saat membuat instance, Anda dapat menambahkan GPU dan menentukan jumlah CPU, platform CPU, jumlah RAM, serta jenis dan ukuran disk.
Catatan produksi: Untuk pipeline yang men-deploy satu instance per frame, pertimbangkan untuk menyesuaikan instance berdasarkan statistik tugas historis seperti beban CPU atau penggunaan memori untuk mengoptimalkan penggunaan resource di seluruh frame foto. Misalnya, Anda dapat memilih untuk men-deploy mesin dengan jumlah CPU lebih tinggi untuk frame yang berisi motion blur yang berat guna membantu menormalisasi waktu render di semua frame.
Memilih antara preemptible VM dan standar
Preemptible VM (PVM) mengacu pada kapasitas Compute Engine berlebih yang dijual dengan harga lebih rendah daripada VM standar. Compute Engine dapat menghentikan atau melakukan preempt instance ini jika tugas lain memerlukan akses ke kapasitas tersebut. PVM ideal untuk merender workload yang fault tolerant dan dikelola oleh sistem antrean yang melacak tugas yang hilang hingga preemption.
VM standar dapat dijalankan tanpa batas waktu dan ideal untuk server lisensi atau host administrator antrean yang perlu berjalan secara persisten.
Preemptible VM akan dihentikan secara otomatis setelah 24 jam, jadi jangan menggunakannya untuk menjalankan render atau simulasi yang berjalan lebih lama.
Tingkat preemption berjalan dari 5% hingga 15%, yang untuk workload rendering standar mungkin dapat ditoleransi mengingat biaya yang dikurangi. Beberapa praktik terbaik preemptible dapat membantu Anda menentukan cara terbaik untuk mengintegrasikan PVM ke dalam pipeline render. Jika instance Anda di-preempt, Compute Engine akan mengirim sinyal preemption ke instance, yang dapat Anda gunakan untuk memicu scheduler guna menghentikan tugas saat ini dan menambahkan antrean.
| VM Standar | Preemptible VM |
|---|---|
| Dapat digunakan untuk tugas yang berjalan lama. Ideal untuk pekerjaan dengan prioritas tinggi dan tenggat waktu yang sulit. Dapat dijalankan tanpa batas waktu, sehingga ideal untuk server lisensi atau hosting administrator antrean. |
Dihentikan secara otomatis setelah 24 jam. Memerlukan sistem pengelolaan antrean untuk menangani instance yang di-preempt. |
Catatan produksi: Beberapa perender dapat melakukan snapshot dari render yang sedang berlangsung pada interval tertentu, jadi jika VM di-preempt, Anda dapat menjeda dan melanjutkan rendering tanpa harus memulai ulang frame dari awal. Jika perender Anda mendukung pembuatan snapshot, dan Anda memilih untuk menggunakan PVM, aktifkan pembuatan snapshot render di pipeline untuk menghindari kehilangan pekerjaan. Saat snapshot sedang ditulis dan diupdate, data dapat ditulis ke Cloud Storage, dan diambil saat PVM baru di-deploy jika render worker di-preempt. Untuk menghindari biaya penyimpanan, hapus data snapshot untuk render yang sudah selesai.
Memberikan akses ke worker render
IAM membantu Anda menetapkan akses ke resource cloud kepada individu yang memerlukan akses. Untuk pekerja render Linux, Anda dapat menggunakan Login OS untuk membatasi akses lebih lanjut dalam sesi SSH, sehingga Anda dapat mengontrol siapa yang menjadi administrator.
Mengontrol biaya hybrid render farm
Saat memperkirakan biaya, Anda harus mempertimbangkan banyak faktor, tetapi sebaiknya terapkan praktik terbaik umum berikut sebagai kebijakan untuk hybrid render farm Anda:
- Gunakan preemptible instance secara default. Gunakan preemptible VM, kecuali jika tugas render Anda berjalan sangat lama, empat jam atau lebih per frame, atau Anda memiliki tenggat waktu yang ketat untuk menghasilkan foto.
- Minimalkan traffic keluar. Hanya salin data yang Anda butuhkan kembali ke penyimpanan lokal. Umumnya, data ini akan menjadi frame akhir yang dirender, tetapi juga bisa berupa penerusan atau data simulasi terpisah. Jika Anda memasang NAS lokal secara langsung, atau menggunakan produk penyimpanan yang disinkronkan secara otomatis, tulis semua data yang dirender ke sistem file lokal render worker, lalu salin hal yang Anda butuhkan kembali ke sistem penyimpanan lokal untuk menghindari traffic keluar untuk data sementara dan yang tidak perlu.
- Ukuran VM yang tepat. Pastikan Anda membuat render worker dengan penggunaan resource yang optimal, dengan hanya menetapkan jumlah vCPU yang diperlukan, jumlah RAM optimal, dan jumlah GPU yang tepat, jika ada. Pertimbangkan juga cara meminimalkan ukuran disk yang terpasang.
- Pertimbangkan durasi minimum satu menit. Di Google Cloud, instance ditagih per detik dengan waktu minimum satu menit. Jika workload Anda mencakup rendering frame yang memerlukan waktu kurang dari satu menit, pertimbangkan untuk membagi tugas secara bersamaan agar tidak men-deploy instance selama kurang dari satu menit waktu komputasi.
- Menyimpan set data besar di cloud. Jika Anda menggunakan render farm untuk menghasilkan data dalam jumlah besar, seperti EXR yang dalam atau data simulasi, pertimbangkan untuk menggunakan workstation berbasis cloud yang berada jauh dari pipeline. Misalnya, seniman FX mungkin menjalankan simulasi yang lancar di cloud, dengan menulis file cache ke penyimpanan berbasis cloud. Kemudian, seniman pencahayaan dapat mengakses data simulasi ini dari workstation virtual yang ada di Google Cloud. Untuk mengetahui informasi selengkapnya tentang workstation virtual, hubungi perwakilan Google Cloud Anda.
- Manfaatkan diskon abonemen dan berkelanjutan. Jika Anda menjalankan sekumpulan resource, diskon untuk penggunaan berkelanjutan dapat menghemat biaya instance yang berjalan selama sebulan penuh hingga 30%. Diskon abonemen juga dapat diterima dalam beberapa kasus.
Memperluas render farm yang sudah ada ke cloud adalah cara hemat biaya untuk menggunakan resource yang canggih dan hemat biaya tanpa biaya modal. Tidak ada dua pipeline produksi yang sama, sehingga tidak ada dokumen yang dapat mencakup setiap topik dan persyaratan yang unik. Untuk mendapatkan bantuan terkait migrasi beban kerja render ke cloud, hubungi perwakilan Google Cloud Anda.
Langkah selanjutnya
- Jalankan bukti konsep render farm hybrid.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.