20 Düğümlü Adanmış GPU render farm sınır ötesi kurulum (2026)

Giriş

Bir yaratıcı ekip birden fazla lokasyon ve okyanus boyunca uzanan adanmış bir render farm istediğinde, neredeyse her zaman bir SaaS render farm'ın çözemeyeceği bir kısıtlama etrafından dolanıyordur. Üçüncü tarafların kimlik bilgilerini tutmasına sözleşmesel olarak izin veremeyen bir stüdyo, bir ülkedeki sanatçıların başka bir ülkedeki düğümleri yöneten dağıtılmış bir ekip veya çok aylık taahhüdü kare başı faturalandırmayı ekonomik olarak yanlış yapan bir prodüksiyon şirketi olabilir.

Adanmış kümeler dağıtırken edindiğimiz deneyime göre, zor kısım nadiren "daha fazla GPU kiralamaktır". Doğru parçaları bağlamaktır: müşteriye ait bulut depolama, iş yüküne uygun boyutlandırılmış özel bir GPU filosu, jitter'a dayanan şifreli sınır ötesi taşıma ve ağır bir 3D viewport açıldığında çökmeyen bir uzak masaüstü katmanı. Bir parça yanlış olduğunda küme çalışır, ancak sanatçılar fark eder — ve taahhüt sessizce bozulur.

Önemli bir CPU + GPU filosuna sahip bir bulut render farm olan Super Renders Farm'ı işletiyoruz ve aynı zamanda iş akışları varsayılan yönetilen hizmetimize uymayan ekipler için adanmış GPU kümeleri de kuruyoruz. Bu makale, bu dağıtımlardan derlenmiş bir saha rehberidir — iki sahayı kapsayan ve uzak sanatçılara sınır ötesi hizmet veren 20 düğümlü adanmış bir GPU render farm'ı nasıl tasarladığımız. Adanmış altyapıyı yönetilen render farm kiralamamıza karşı değerlendiriyorsanız, bu rehber adanmış yolun ek mimari yüzeye değip değmediğine karar vermenize yardımcı olacaktır.

Karar kriterleri: adanmış mı SaaS mı

Çoğu rendering iş yükü adanmış bir kümeye ihtiyaç duymaz. Yönetilen bir bulut render farm bir sahneyi alır, kareleri planlar ve dakika başına faturalandırır. Proje tabanlı iş için — tek bir kısa film, 30 saniyelik bir reklam, bir grup still — bu model her ilgili eksende kazanır.

Adanmış bir küme yalnızca aşağıdakilerden biri veya daha fazlası doğru olduğunda kendini haklı çıkarır:

• Fikri mülkiyet kontrolü sözleşmeseldir, tercih değildir. Müşterinin sözleşmesi üçüncü tarafların sahne dosyalarını veya render kimlik bilgilerini tutmasını yasaklar. Sahne yüklemesine aracılık eden SaaS pipeline'lar, altta yatan hesaplama aynı olsa bile bu kısıtlamayı ihlal eder.
• Taahhüt günler değil, aylar sürer. Sabit şekilli iş — uzun süreli bir animasyon dizisi, çok çeyrekli bir archviz pipeline'ı, devam eden bir sanal prodüksiyon sahnesi — peşin mimari maliyetini amorti eder.
• İş akışı, yönetilen bir pipeline'ın barındıramayacağı kadar özelleştirilmiştir. Özel DCC eklenti yığınları, şirket içi render manager'lar, paylaşımlı önbelleğe pre-bake yapan simülasyon ağırlıklı pipeline'lar veya tescilli araç zincirleri adanmış düğümlere doğru iter.
• Bring-your-own-cloud katı bir gereksinimdir. Müşterinin proje varlıkları müşterinin hesabı altındaki bir cloud file-streaming platformunda yaşadığında, küme altyapı sağlayıcı olarak değil, müşteri olarak oturum açmalıdır.
• Ağ segmentasyonu ihtiyaçları tenant başına VLAN'ın ötesine geçer. Bazı iş akışları, kümenin sağlayıcının daha geniş ağına yalnızca mantıksal olarak değil, yönlendirme açısından da görünmez olmasını gerektirir.

Bu kriterlerden hiçbiri uygulanmazsa, yönetilen bir render farm neredeyse kesinlikle doğru seçimdir. İki veya daha fazlası uygulanırsa, konuşma adanmışa doğru kayar. Kalan soru coğrafidir: iş tek bir veri merkezine sığar mı, yoksa sanatçılara ulaşmak için bir kamu ISP omurgasını geçmesi gerekir mi?

Mimari genel bakış

Sınır ötesi adanmış kümeler için dağıttığımız mimari üç düzleme sahiptir: bir taşıma düzlemi, bir hesaplama düzlemi ve bir depolama hızlandırma düzlemi.

        [ Uzak sanatçı ekibi ]
              │  WireGuard (UDP 51820, uçtan uca şifreli)
              ▼
   ┌──────────────────────────────────────────────────┐
   │   Main DC (iyi uluslararası transit)               │
   │                                                    │
   │   ┌──────────────────────────────────────────┐    │
   │   │  EDGE + CACHE BOX (tek Ubuntu host)       │    │
   │   │   • WireGuard hub (NAT/MASQUERADE)        │    │
   │   │   • Samba SMB3 cache (tek SSD, ext4)      │    │
   │   │   • dnsmasq (.lan bölgesi)                │    │
   │   │   • chrony (NTP)                          │    │
   │   │   • ufw + BBR + TCP MSS clamping          │    │
   │   └────────────┬─────────────────────────────┘    │
   │                │ LAN                                │
   │     ┌──────────▼───────────┐                        │
   │     │ Group A — ~10 düğüm   │  RTX 5090              │
   │     │ (Sunshine + bulut     │  C4D / Redshift / vb.  │
   │     │  istemci + cache      │                        │
   │     │  mount)               │                        │
   │     └───────────────────────┘                        │
   │                                                    │
   │     WireGuard site-to-site (kamu ISP yolu)          │
   └────────────────────┬───────────────────────────────┘
                        ▼
   ┌──────────────────────────────────────────────────┐
   │   İkincil saha (aynı şehir)                         │
   │     ┌───────────────────────┐                      │
   │     │ Group B — ~10 düğüm   │  cache'i sahalar     │
   │     │ (Main DC'ye tünel)    │  arası tünel ile     │
   │     │                       │  okur                │
   │     └───────────────────────┘                       │
   └──────────────────────────────────────────────────┘

   Harici cloud file-streaming platformu — müşteri oturum açar;
   altyapı sağlayıcı kimlik bilgilerini tutmaz.

Taşıma düzlemi uzak sanatçılar için hub-and-spoke modelinde WireGuard'dır artı iki hesaplama sahası arasında bir site-to-site tünel. Hesaplama düzlemi iki grup on Windows 11 Pro düğümünden oluşur, her biri 32 GB VRAM'li bir NVIDIA RTX 5090 sürer. Depolama hızlandırma düzlemi ana sahada tek bir edge-and-cache kutusudur.

Tasarım kararı: edge kutusu ile cache kutusu aynı makinedir. Mimari ayrıntılarımıza bakın.

20 düğümlü GPU küme kurulumu

Tanımlanan dağıtımlar için varsayılan boyut yirmi RTX 5090 düğümüdür — iki saha arasında onar onar bölünmüştür. Bu boyut on-yirmi sanatçılık bir yaratıcı ekibe iyi eşleşir, fikri mülkiyete duyarlı iş akışları için adanmış kümelerin amorti olduğu bant.

Her düğüm aynı donanım şekline sahiptir: 32 GB VRAM'li bir RTX 5090, modern bir çok çekirdekli CPU, 64 veya 128 GB sistem RAM'i ve OS ve scratch için boyutlandırılmış yerel bir NVMe disk. Kalıcı proje verileri paylaşımlı cache'de veya upstream cloud file-streaming platformunda yaşar — asla düğümün kendisinde değil.

Her düğümdeki işletim sistemi temiz bir imajdan dağıtılmış Windows 11 Pro'dur. Düğüm imajına kasıtlı olarak DCC eklenti yığınları önyüklemiyoruz. Müşteri kendi DCC araçlarının kurulumunu yönetir — Cinema 4D, Redshift, Houdini, After Effects, Blender ve diğerleri.

Group A ve Group B özdeş şekilde yapılandırılır. Sahalar arası WireGuard tüneli açıldığında ve cache mount edildiğinde, ikincil saha ana sahanın LAN'ının ince bir uzantısı gibi davranır. Filo katman 3 yönlendirilebilirdir — müşteri kendi render manager'ını kurar ve her düğümü uzak masaüstü ile yönetmek yerine uzak bir iş istasyonundan gönderir.

Müşteriye ait kimlik bilgileri (Model B)

Fikri mülkiyete duyarlı iş akışları için adanmış bir kümeyi en sık doğru cevap haline getiren tek mimari karar, Model B dediğimiz şeydir: müşteriye ait kimlik bilgileri. Model A'da — kendi SaaS hizmetimiz dahil yönetilen render farm'lar için varsayılan — altyapı sağlayıcı rendering pipeline'ının kimlik bilgilerini tutar.

Model B'de altyapı sağlayıcı donanım, işletim sistemi, ağ ve cache katmanı sağlar, ancak müşterinin cloud file-streaming platformu için kimlik doğrulama materyalini asla tutmaz. Müşteri her düğümde bulut platformuna kendi iş istasyonundaymış gibi oturum açar.

Üç neden önemlidir: (1) Sözleşmesel — müşterinin downstream sözleşmesi kimlik bilgilerinin nerede tutulacağını sınırlandırdığında; (2) Denetim — bir güvenlik denetçisine temiz bir cevap verir; (3) Taahhüt kapanışı — sağlayıcı asla kimlik bilgileri tutmadığı için temizlik daha basittir.

Model B herkese uygun değildir. Müşterinin operasyon ekibini her düğümde kimlik bilgisi yaşam döngüsü için çengele takar. BYOC derinlikli analizimize bakın.

Cloud file-streaming entegrasyonu

Tartışılan yapılandırmalarda, müşterinin proje varlıkları bir cloud file-streaming platformunda yaşar — bulut destekli proje ağacını her düğümde sanal bir dosya sistemi olarak gösteren bir hizmet. Sanatçı projeyi mount eder; düğüm dosyaları talep üzerine okur; platform yedek depolama, sürüm kontrolü ve bölgeler arası replikasyonu yönetir.

Müşterinin seçtiği genel bir cloud file-streaming platformuyla entegre oluyoruz. Platform her düğümden müşterinin hesabını kullanarak bir oturum açma olayı görür; platform istemcisi düğümde proje ağacını bilinen bir yola mount eder; müşterinin DCC uygulaması o yoldan dosyaları yerel bir iş istasyonundaki gibi açar.

20 düğümlü bir kümede değişen şey erişim modelidir. Tek bir iş istasyonundaki tek bir sanatçı bir seferde bir proje dosyası çeker. Bir kare aralığı için aynı sahneyi aynı anda açan yirmi render düğümü, aynı varlıklar için senkronize bir bulut okuma patlaması yaratır. Cache olmadan, her düğüm her dokuyu paralel olarak çeker — uluslararası bant genişliğini boşa harcar.

Write-back için, bir render karesi bittiğinde, düğüm çıktıyı müşterinin hesabı aracılığıyla cloud file-streaming platformuna yazar.

Paylaşımlı cache mimarisi

Paylaşımlı cache, yanlış yapıldığında kümenin değerini sessizce aşındıran iki üç mimari seçimden biridir. Önceki dağıtımlarda yanlış yaptık. Birden fazla yapı boyunca dayanan model kasıtlı olarak muhafazakardır.

Tek bir edge-and-cache kutusu Ubuntu 22.04 LTS çalıştırır, ext4 olarak biçimlendirilmiş ve Samba SMB3 üzerinden kümeye sunulan tek bir 8 TB SATA SSD ile. Cache mount'u her render düğümünde sabit bir yolda görünür (örneğin \\cache.lan\proj).

Üç kasıtlı seçim: (1) Tek bir cache, düğüm başına değil — 200 TB gereksiz yer kaplamayı önler. (2) Ext4'te tek SSD, XFS üzerinde LUKS'lu RAID 10 değil — cache gerçeğin kaynağı değil, müşterinin bulutu öyledir. (3) İlk render gününden önce cache'i ön-ısıtmak — D-Day okumalarını cold cloud pull'lardan sıcak SMB okumalarına dönüştürür.

Sahalar arasında Group B, cache'i sahalar arası WireGuard tüneli üzerinden okur. MSS clamping doğru şekilde uygulandığında, bizim için güvenilir olmuştur.

Sınır ötesi ağ optimizasyonu

Taşıma katmanı, sınır ötesi bir kümenin kesintisiz mi yoksa bozuk mu hissettirdiğine karar verir. TCP/IP, IP parçalama ve DNS-üzerinden-VPN'in varsayılan davranışları, SMB ve uzak masaüstü taşıyan uzun mesafeli şifreli tüneller için ince bir şekilde yanlıştır.

WireGuard hub-and-spoke artı site-to-site. Her sanatçı iş istasyonundan WireGuard istemci üzerinden ana sahanın hub'ına bağlanır. İki hesaplama sahası da aralarında bir WireGuard tüneline sahiptir.

TCP BBR. Linux'un varsayılan tıkanıklık kontrolü (CUBIC) hafif paket kaybı olan düşük gecikme bağlantıları için tasarlandı. Şifreli trafik taşıyan uzun mesafeli kamu ISP bağlantıları çok farklı görünür. BBR sürekli olarak daha kullanılabilir verim üretir. Kernel'in stok BBR'ını (BBR v1) kullanıyoruz.

TCP MSS clamping. "Küme çoğunlukla çalışıyor, büyük dosyalar hariç" şikayetlerinin en yaygın kaynağı. Trafik etkili MTU'yu azaltan bir tüneli geçtiğinde, büyük paketler ya parçalanır (yavaş) ya da sessizce düşürülür (daha kötü). Düzeltme: WireGuard yönlendiricisinde TCP MSS'i clamp etmek.

dnsmasq ile VPN arayüzü listelenmiş. İnce bir tuzak: dnsmasq, istemci özel bir .lan adresi sorgulasa bile yapılandırmasında WireGuard arayüzünü (örneğin wg0) açıkça listelemelidir. Bu olmadan tünel üzerinden DNS aramaları zaman aşımına uğrar — ancak ping hala çalışır.

chrony NTP için. Zaman senkronizasyonu render manager'lar (Deadline işleri zaman damgalar), sahalar arası log korelasyonu ve zaman bileşeni olan herhangi bir kimlik doğrulama token'ı için önemlidir.

Moonlight ve Sunshine ile uzak masaüstü

Uzak masaüstü, sanatçıların en doğrudan deneyimlediği katmandır. Bu katman yavaş veya kekemelendirici hissettiriyorsa, renderer'ın ne kadar hızlı olduğu önemli değildir.

Uzak masaüstü için Moonlight (istemci) ve Sunshine (her düğümde host) kullanıyoruz. Kombinasyon, frame buffer'ı gerçek zamanlı kodlamak için RTX 5090'daki NVIDIA NVENC donanım kodlayıcısını kullanır. Kodlama düğümde zaten bulunan GPU'da gerçekleştiği için renderer ile çekişme yoktur.

3D viewport çalışması için bu, geleneksel uzak masaüstü için olmadığı şekilde önemlidir. Eski protokoller — RDP, VNC — ofis iş yükleri için tasarlandı. Moonlight + Sunshine frame buffer'ı video olarak ele alır — 3D çalışması için tam doğru model.

Bir düğümü bir sanatçıya devretmeden önce çalıştırdığımız bir kalite kapısı testimiz var — gayri resmi olarak "Test 8". Parsec geçerli bir geri dönüş. Moonlight, Parsec ve RDP karşılaştırmamıza bakın.

Hibrit altyapı (sahip + kiralanmış)

Adanmış kümelerin ekonomisini sürekli iyileştiren operasyonel kararlardan biri, sahip olunan ve kiralanan hesaplamayı karıştırmaktır. Tanımlanan 20 düğümlü yapılandırmalar için tipik olarak ana sahadaki mevcut kapasiteden yaklaşık on düğüm ve ikincil bir sahadaki kiralanan alandan yaklaşık on düğüm yapılandırıyoruz.

İlk neden: sermaye esnekliği. Sahip olunan ve kiralanan kapasiteyi karıştıran bir küme yirmi yeni düğümün peşinen satın alınmasını gerektirmez. İkinci neden: kapasite planlama. Çok aylık taahhütlerin nadiren düz bir talep eğrisi vardır.

Her iki grup da müşterinin perspektifinden özdeş davranır. Hibrit sahip + kira modelimize bakın.

Ağ segmentasyonu

Böyle bir kümede ağ segmentasyonu isteğe bağlı değildir. Müşteri sağlayıcının altyapısında çalışır, ancak sağlayıcının daha geniş ağını asla görememelidir — ne NAS'ı, ne yönlendirici yönetici arayüzleri, ne diğer kiracılar.

İki katmanda segmentasyon uyguluyoruz. Tier 1 — edge güvenlik duvarı — edge-and-cache kutusu varsayılan-reddet inbound modunda ufw çalıştırır. Yalnızca WireGuard UDP portu (51820) kamu internetine açıktır. Tier 2 — her düğümde host güvenlik duvarı — her düğümün edge duruşunu yansıtan kendi Windows güvenlik duvarı yapılandırması vardır.

Pratikte, müşteri isteseler bile sağlayıcının diğer sistemlerini ping atamaz veya tarayamaz. Ağ güvenlik mimarimize bakın.

Öğrenilen dersler

Kurduğumuz her adanmış kümede ya saatlerce hata ayıklamadan tasarruf etmemizi sağlayan ya da — uygulamayı unuttuğumuzda — saatlerce hata ayıklamaya mal olan beş operasyonel ders.

1. Dual-home gateway yönlendirme tuzağı. Edge kutusu iki ağ arayüzüne sahip olduğunda, işlemlerin sırası önemlidir. LAN rotası varsayılan rota değiştirilmeden önce yapılandırılmalıdır.

2. WireGuard ve DNS. dnsmasq, WireGuard arayüzü dahil olmak üzere dinlemesi gereken her arayüzü açıkça listelemelidir.

3. Bir tünel üzerinden TCP MSS clamping isteğe bağlı değildir. TLS, RDP, SMB büyük dosya okumaları — büyük paketler göndermek isteyen her şey — MSS clamp olmadan sessizce düşer.

4. Depolamayı doğru boyutlandırmak. Cache gerçeğin kaynağı değildir, müşterinin bulutu öyledir. Bulut katmanında yedeklilik varken RAID/LUKS gerekmez.

5. Cache'i ön-ısıtmak. D-Day'de her cache miss bir uluslararası gidiş-geliş'e mal olur. Bir ön-ısıtma penceresi ilk üretim saatini kurtarır.

Öğrenilen dersler koleksiyonumuza bakın.

Sonuç

Adanmış 20 düğümlü sınır ötesi bir GPU render farm, fikri mülkiyet kontrolü sözleşmesel olduğunda, taahhüt çok aylık olduğunda, iş akışı özel yapılandırma gerektirdiğinde ve BYOC kimlik doğrulaması pazarlık konusu olmadığında doğru mimaridir. Bu koşulların dışında, yönetilen bir render farm neredeyse her zaman daha iyi cevaptır.

Koşullar uygulandığında, burada kapsanan modeller — Model B kimlik bilgileri, ext4'te paylaşımlı cache, WireGuard hub-and-spoke artı site-to-site, MSS clamping ile BBR, uzak masaüstü için Moonlight + Sunshine, iki katmanlı güvenlik duvarı — varsayılan olarak dağıttığımız şeydir.

Super Renders Farm'ın arkasındaki ekip hem yönetilen render farm kiralama hem de adanmış küme dağıtımları işletmektedir — bu rehber boyunca açıklanan adanmış GPU küme yapılandırmaları ve sınır ötesi topolojiler dahil.

FAQ

Q: Tipik bir 20 düğümlü adanmış küme dağıtımı ne kadar sürer? A: Kapsam, kiralanan sahadaki donanım uygunluğu ve müşterinin cloud file-streaming kurulumuna bağlı olarak, tipik bir taahhüt donanım ve ağ hazırlığı için birkaç haftalık lead time'dan üretim başlangıcından bir-iki gün önceki bir ön-ısıtma penceresine kadar uzanır.

Q: Ekibim üç kıtaya yayılmışsa ne olur? A: Müşteri-hub WireGuard tüneli küme mimarisini değiştirmeden ek müşteri konumlarına ölçeklenir. Her uzak sanatçı bir WireGuard istemci çalıştırır ve ana sahadaki aynı hub'a bağlanır.

Q: Çok aylık bir taahhütten önce kümeyi kendi tarafımdan görebilir miyim? A: Tipik olarak kapsam konuşması sırasında bir kavram kanıtlama penceresi düzenleriz. Tam form müşterinin projesine bağlıdır.

Q: Taahhüt sonunda veri güvenliği nasıl ele alınır? A: Model B müşteri kimlik bilgilerini ellerimizden uzak tuttuğu için, kapanış donanım ve cache temizliğine odaklanır. SMB cache'ini sileriz, her düğümü temiz baseline'dan yeniden image'larız ve imha edildiğine dair yazılı bir kanıt sağlarız.

Q: 20 düğümden fazlasına ihtiyacım varsa ne olur? A: 20 düğümlü yapılandırma en yaygın şekildir, ancak mimari bunun ötesine ölçeklenir. Ek sahalarda ek gruplar ekleyerek daha büyük filolar kurduk.

Q: Cinema 4D, Redshift veya diğer DCC araçları için kendi lisansımı getirebilir miyim? A: Lisans modeli — bring-your-own-license veya sağlayıcı tarafından sağlanan — belirli DCC'ye ve müşterinin mevcut lisans envanterine bağlı bir iş kararıdır.

Q: AB veya ABD sağlayıcılarından bulut depolamayı nasıl ele alıyorsunuz? A: Cloud file-streaming platformu müşterinin seçimidir. Kümemiz Windows üzerinde bir oturum açma istemcisi çalıştırabilen ve müşterinin proje ağacını monte edilmiş bir dosya sistemi olarak ifşa edebilen herhangi bir platformla entegre olur.

Q: WireGuard tüneli düşerse ne olur? A: WireGuard, altta yatan ağ kurtarıldığında oturumu otomatik olarak yeniden kurar; müşterinin uzak masaüstü oturumu yeniden el sıkışma sırasında kısa süre duraklayabilir.