20 Düğümlü Adanmış GPU Render Farm Sınır Ötesi Kurulum (2026)

Giriş

Bir yaratıcı ekip birden fazla ülkeye yayılan adanmış bir render farm talep ettiğinde, neredeyse her zaman bir SaaS render farm'ın çözemeyeceği bir kısıtlama etrafında çalışı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önettiği dağıtılmış bir ekip veya çok aylık taahhüdü kare başı faturalandırmayı ekonomik açıdan hatalı kılan 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, titreme (jitter) koşullarında dayanıklı şifreli sınır ötesi taşıma ve ağır bir 3D viewport açıldığında çöken uzak masaüstü katmanı. Bir parça yanlış olduğunda küme çalışmaya devam eder; 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 uygun düşmeyen ekipler için adanmış GPU kümeleri de kuruyoruz. Bu makale söz konusu dağıtımlardan elde ettiğimiz bir saha rehberidir — tek bir adanmış tesisten, sınırlar ötesinde dağıtılmış bir yaratıcı sanatçı ekibine hizmet veren 20 düğümlü adanmış bir GPU render farm'ı nasıl tasarladığımız, geri adım attığımız tercihler ve artık varsayılan olarak uyguladığımız dersler hakkında dürüst notlarla birlikte. Adanmış altyapıyı yönetilen render farm kiralamamıza karşı tartıyorsanız bu rehber, adanmış yolun ek mimari yüzeye değip değmediğine karar vermenize yardımcı olacaktır.

Adanmış ve SaaS karar kriterleri

Ç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. Sahip olunacak altyapı, bakımı yapılacak güvenlik duvarı ve müşteri tarafında atanacak operasyon ekibi yoktur. Proje tabanlı çalışmalar için — tek bir kısa film, 30 saniyelik bir reklam, bir grup fotoğraf — bu model her önemli eksende kazanır.

Adanmış bir küme yalnızca aşağıdakilerden bir veya daha fazlası doğru olduğunda karmaşıklığını haklı kılar:

• Fikri mülkiyet kontrolü tercih değil, sözleşmeseldir. Müşterinin ana hizmet sözleşmesi veya son müşteri sözleşmesi, üçüncü bir tarafın sahne dosyalarını veya render kimlik bilgilerini tutmasını yasaklar. Sahne yüklemesine aracılık eden SaaS pipeline'lar, altta yatan hesaplama özdeş olsa bile bu kısıtlamayı ihlal eder.
• Taahhüt günler değil, aylar sürer. Sabit biçimli çalışmalar — uzun soluklu bir animasyon dizisi, çok çeyrekli bir archviz pipeline'ı, süregelen bir sanal prodüksiyon sahnesi — peşin mimari maliyetini amorti eder. Kare başı faturalandırma ise süreyle doğrusal olarak artar ve belirli bir noktadan sonra rekabetçi olmaktan çıkar.
• İş 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 önceden derleme (pre-bake) yapan simülasyon ağırlıklı pipeline'lar veya tescilli araç zincirleri, müşterinin doğrudan yapılandırabileceği adanmış düğümlere yönlendirir.
• Kendi bulutunuzu getirmek (BYOC) katı bir gereksinimdir. Müşterinin proje varlıkları müşteri hesabı altındaki bir cloud file-streaming platformunda yaşadığında, kümenin altyapı sağlayıcısı olarak değil müşteri kimliğiyle oturum açması gerekir. Aşağıda ayrıntılı ele alınan "Model B" düzeni budur.
• Ağ segmentasyonu ihtiyaçları tenant başına VLAN'ın ötesine geçer. Bazı iş akışları, kümenin yalnızca mantıksal olarak değil rota açısından da sağlayıcının daha geniş ağına görünmez olmasını gerektirir.

Bu kriterlerden hiçbiri uygulanmıyorsa yönetilen bir render farm neredeyse her zaman doğru seçimdir. İki veya daha fazlası uygulanıyorsa konuşma adanmış çözüme doğru kayar. Kalan soru coğrafidir: çalışmayı yürüten sanatçılar tesise yakın mı, yoksa kümenin ulusal sınırları aşan bir genel ISP omurgası üzerinden onlara hizmet vermesi mi gerekiyor?

Mimari genel bakış

Sınır ötesi adanmış kümeler için dağıttığımız mimari üç düzleme sahiptir: taşıma düzlemi, hesaplama düzlemi ve depolama hızlandırma düzlemi. Her düzlemin, deneyimimize göre çalışmadığında operasyonel sorunların büyük bölümünden sorumlu olan tek bir hata modu vardır.

        [ Uzak sanatçılar — ülkeler genelinde dağıtılmış ]
                          │
                          │  WireGuard hub-and-spoke
                          │  (UDP 51820, uçtan uca şifreli,
                          │   BBR + MSS-clamped taşıma)
                          ▼
   ┌─────────────────────────────────────────────────────┐
   │   Super Renders Farm — adanmış küme tesisi           │
   │                                                       │
   │   ┌─────────────────────────────────────────────┐   │
   │   │  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 clamp                │   │
   │   └────────────────────┬────────────────────────┘   │
   │                        │ LAN                          │
   │   ┌────────────────────▼────────────────────────┐   │
   │   │   20 × RTX 5090 render node                  │   │
   │   │   (Windows 11 Pro, Sunshine, cloud file-     │   │
   │   │    stream istemcisi, cache mount — filo      │   │
   │   │    genelinde tekdüze image)                  │   │
   │   └─────────────────────────────────────────────┘   │
   └─────────────────────────────────────────────────────┘
                              │
                              ▼
    [ Müşterinin cloud file-streaming platformu —
      müşteri her düğümde oturum açar; Super Renders
      Farm kimlik bilgilerini tutmaz (Model B) ]

Taşıma düzlemi, hub-and-spoke düzeninde WireGuard'dır. Her sanatçının iş istasyonu, küme tesisindeki hub'a şifreli bir UDP tüneli üzerinden bağlanır; hangi ülkede bulunursa bulunsun sanatçıdan kümeye giden tüm trafik aynı tünel topolojisini kullanır. Hesaplama düzlemi, her biri tek bir tesiste tek düzgün havuz olarak dağıtılmış, 32 GB VRAM'li bir NVIDIA RTX 5090 çalıştıran yirmi Windows 11 Pro düğümüdür. Depolama hızlandırma düzlemi, tesisteki tek bir edge-and-cache kutusudur; bu kutu ext4 üzerinde tek bir SSD ile desteklenen bir Samba SMB3 paylaşımının yanı sıra kümenin bağımlı olduğu ağ hizmetlerini (DNS, NTP, güvenlik duvarı) barındırır.

Kilit bir tasarım kararı: edge kutusu ile cache kutusu aynı makinedir. Bu mimarinin önceki bir versiyonu edge ağ geçidini ayrı bir cihaza, cache'i ise bir NAS'a yerleştiriyordu; bu durum soğuk çekmelerde yarış koşullarına (race condition) ve yamanacak iki yüzeye yol açtı. Tek bir Ubuntu 22.04 LTS host üzerinde birleştirmek her iki sorunu da ortadan kaldırdı. Kutu kritik bir kaynak haline gelir; ancak müşteri proje verisi cloud file-streaming platformunda yaşamaya devam ettiğinden, cache yerel bir arızadan sonra upstream'den yeniden ısınabilir.

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

Açıklanan dağıtımlar için varsayılan boyut, tek bir tesis içinde tek tekdüze havuz olarak dağıtılmış yirmi RTX 5090 düğümüdür. Bu boyut, fikri mülkiyete duyarlı iş akışları için adanmış kümelerin maliyetini geri kazandığı aralık olan on-yirmi sanatçılık yaratıcı ekiplerle sürekli olarak iyi örtüşür.

Her düğüm aynı donanım yapısına sahiptir: 32 GB VRAM'li tek bir RTX 5090, modern çok çekirdekli bir CPU, 64 GB veya 128 GB sistem RAM'i ve yalnızca işletim sistemi ile scratch için boyutlandırılmış yerel NVMe disk. Kalıcı proje verisi 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 image'dan dağıtılmış Windows 11 Pro'dur. DCC eklenti yığınlarını düğüm image'ına kasıtlı olarak önceden yüklemiyoruz. Müşteri kendi DCC araçlarının kurulumunu yönetir — Cinema 4D, Redshift, Houdini, After Effects, Blender ve diğerleri — böylece düğüm image'ı minimal ve yeniden üretilebilir kalır. Taahhüt sona erdiğinde aynı temiz baseline'dan silip yeniden image'larız.

Düğüm başına 32 GB VRAM'i kasıtlı olarak seçtik. Modern GPU renderer'lar — Redshift, Octane, Arnold GPU, Cycles — giderek artan şekilde yalnızca 24 GB kartlara sığmayacak büyük dokulu sahneler yüklüyor. RTX 5090'ın 32 GB kapasitesi, üretim renderer'ları için mevcut tatlı nokta; archviz, motion design ve animasyon işlerinin büyük çoğunluğunu sistem RAM'ine sayfalama yapmadan karşılıyor; bu da karma GPU havuzlarının sessizce yavaşladığı noktadır.

Yirmi düğüm özdeş biçimde yapılandırılmıştır — aynı image, aynı DCC kurulum seti, aynı cache mount, aynı WireGuard rotası — ve müşterinin render manager'ına tek bir havuz olarak sunulur. Deadline, Royal Render veya müşterinin kendi planlayıcısı, grubu başına herhangi bir yönlendirme ya da manuel yeniden dengeleme mantığı olmaksızın filoyu tek bir kaynak olarak ele alır. Kareler hangi düğüm boşsa ona devredilir; müşterinin render manager'ı yük dağılımını iş kuyruğu katmanında yönetir.

Filo katman-3 yönlendirilebilirdir — müşteri kendi render manager'ını kurar ve her düğümü uzak masaüstü ile sürmek yerine uzak bir iş istasyonundan gönderir. Bu, insanların beklediğinden daha fazla önem taşır: sanatçıların kavga ettiği bir küme ile sanatçıların unuttuğu bir küme arasındaki farktır.

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 yanıt 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. Müşteri sahne dosyalarını yükler; sağlayıcının pipeline'ı render işlemine aracılık eder. Bu, iş yüklerinin büyük çoğunluğu için işe yarar ve hemen hemen her ticari bulut render farm'ın arkasındaki modeldir.

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 veya projenin kaynak verisi için kimlik doğrulama materyalini hiçbir zaman tutmaz. Müşteri, kendi iş istasyonunda oturur gibi her düğümde bulut platformuna oturum açar. Proje dosyaları müşterinin bulutundan akar. Render çıktıları müşterinin bulutuna geri yazılır. Sağlayıcının rolü donanım ve pipeline katmanıyla sınırlıdır.

Bu üç nedenden dolayı önemlidir:

• Sözleşmesel: Müşterinin downstream müşterisinin, kimlik bilgilerinin ve kaynak dosyaların nerede tutulabileceğini kısıtlayan bir NDA veya ana hizmet sözleşmesi olduğunda, Model B sağlayıcıyı bu kısıtlamaların kapsamı dışında tutar.
• Denetim: Müşterinin, rendering pipeline'ının kimlik bilgilerini üçüncü bir tarafa ifşa etmediğini bir güvenlik denetçisine kanıtlaması gerektiğinde, Model B temiz bir yanıt sağlar.
• Taahhüt kapanışı: Sağlayıcı hiçbir zaman kimlik bilgisi tutmadığından taahhüt sonu kapatma işlemi daha basittir. Müşteri kendi bulut oturumlarını iptal eder; sağlayıcı cache'i siler, her düğümü temiz baseline'dan yeniden image'lar ve cache ile düğüm image'larının imha edildiğine dair yazılı bir kanıt belgesi sağlar.

Model B herkese uygun değildir. Müşterinin operasyon ekibini her düğümde kimlik bilgisi yaşam döngüsü yönetiminden sorumlu tutar — gizli anahtarlar aylık rotasyon yapıyorsa koordine edilecek yirmi rotasyon demektir. Bu operasyon pratiği zaten yerinde olan ekipler ödünleşimi kabul edilebilir buluyor. Olmayanlar ise genellikle Model A yönetilen rendering'de kalmayı tercih ediyor.

Cloud file-streaming entegrasyonu

Ele aldığımız 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 ortaya koyan bir hizmet. Sanatçı projeyi mount eder; düğüm talep üzerine dosyaları okur; platform yedek depolama, sürüm kontrolü ve bölgeler arası çoğaltmayı yönetir.

Müşterinin seçtiği genel bir cloud file-streaming platformuyla entegre oluyoruz. Platform her düğümden müşteri hesabıyla bir oturum açma olayı görür; düğüm üzerinde çalışan platform istemcisi proje ağacını bilinen bir yola mount eder; müşterinin DCC uygulaması o yoldan dosyaları yerel bir iş istasyonundaymış gibi açar. Bulut platformunun, düğümün bir render kümesinin parçası olduğunun farkında olmasına gerek yoktur.

Bu durum 20 düğümlü bir kümede kurulduğunda değişen şey erişim modelidir. Tek bir iş istasyonundaki tek bir sanatçı çalışırken talep üzerine tek seferde tek 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, her önbelleğe alınmış simülasyonu, her bağımlılık dosyasını paralel olarak çeker — bu hem uluslararası bant genişliğini israf eder hem de her aralığın ilk karesinde yavaşlığa neden olur.

Paylaşımlı cache işte bu yüzden vardır. Detaylara bir sonraki bölümde değineceğiz; ancak cloud file-streaming ile entegrasyon, cache'in var olmasının nedenidir. Buluttan varlık çekimleri cache kutusundan bir kez gerçekleştirilir, ardından LAN üzerinden tüm yirmi düğüme dağıtılır. Bulut platformu aynı dokunun yirmi eş zamanlı çekimini görmez — bir çekim görür, ardından ağımız içinde sıcak SMB okumaları.

Diğer pratik ayrıntı ise geri yazma (write-back) işlemidir. Bir render karesi tamamlandığında düğüm, çıktıyı müşterinin hesabı aracılığıyla cloud file-streaming platformuna geri yazar. Uzaktaki ofisteki müşteri ekibi karelerin gerçek zamanlı olarak proje ağacında belirdiğini görür. Manuel yükleme adımı yoktur, sağlayıcı aracılı aktarım yoktur; bulut platformu gidiş-dönüşü yönetir.

Paylaşımlı cache mimarisi

Paylaşımlı cache, yanlış yapıldığında bir kümenin değerini sessizce aşındıran iki ya da üç mimari seçimden biridir. Bunu önceki dağıtımlarda yanlış yaptık. Birden fazla yapı boyunca dayanmış olan 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). Bir düğüm cloud file-streaming istemcisi üzerinden bir proje dosyası açtığında dosya yerel cache üzerinden akar; ardından aynı dosyanın herhangi bir düğümde sonraki okumaları SSD'ye doğrudan LAN üzerinden erişir.

O paragrafın içinde kasıtlı olarak gizlenmiş üç seçim vardır.

Birincisi, düğüm başına cache değil, tek bir cache. Bu mimarinin önceki bir versiyonu cache materyalini düğüm başına depoluyordu. Yirmi 5090 düğümüyle bu, yönetilecek 200 TB gereksiz depolama ve bir şey sapıncaya kadar ayıklanacak yirmi ayrı cache durumu anlamına geliyordu. Tek bir paylaşımlı cache'de birleştirmek, depolama alanını yirmi kat küçülttü ve cache durumunu operasyon ekibinin inceleyebileceği tek bir artifact haline getirdi.

İkincisi, ext4'te tek SSD, XFS üzerinde LUKS'lu RAID 10 değil. Önceki plan, cache'i XFS üzerinde LUKS bekleyen-şifreleme içeren bir RAID 10 dizisine yerleştirmeyi öngörüyordu. Bu plan, dağıtım yaptığımız gerçek donanım için — tek SSD, tek dosya sistemi, tek mount — aşırı mühendislikti. RAID katmanını kaldırdık, LUKS'u kaldırdık ve ext4 kullandık; çünkü cache projenin gerçeğinin kaynağı değildir. Müşterinin bulutu gerçeğin kaynağıdır. Cache sürücüsü arızalanırsa değiştirip upstream'den yeniden ısıtırız; bulut katmanında yedekliliğimiz olduğu için cache katmanında yedekliliğe ihtiyaç duymayız.

Üçüncüsü, ilk render gününden önce cache'i ön-ısıtmak. Bu dersi zor yoldan öğrendik. D-Day'de her cache miss, kümede en pahalı okumadur — uluslararası bağlantıyı kat eder, müşterinin bulutundan çeker ve renderer tüketmeden önce yerel SSD'ye yazar. Üretim başlamadan bir önceki gün proje varlık ağacında yapılandırılmış bir geçiş olan ön-ısıtma, D-Day okumalarını soğuk bulut çekimlerinden sıcak SMB okumalarına dönüştürür. Artık her adanmış küme taahhüdüne bir ön-ısıtma penceresi planlıyoruz.

Tesis içinde her düğüm cache'i yerel LAN üzerinde SMB3 ile aynı sabit yoldan (\\cache.lan\proj) mount eder. Tesis içi trafik WireGuard tünelini geçmediğinden MSS clamping burada uygulanmaz ve bağlantı uçtan uca gigabit Ethernet hızında çalışır. Cache mount yolu tüm düğümlerde özdeştir; bu da müşterinin render manager'ı yapılandırmasını basitleştirir — aynı sahne dosyası yolu havuzun her üyesinde aynı şekilde çözümlenir.

Sınır ötesi ağ optimizasyonu

Taşıma katmanı, sınır ötesi bir kümenin kesintisiz mi yoksa bozuk mu hissettirdiğini belirleyen yerdir. 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 fark edilmeden yanlıştır. Kernel ve ağ yapılandırmasını ayarlamak isteğe bağlı değildir; çalışan bir küme ile büyük paketleri gizemli bir şekilde düşüren bir küme arasındaki fark budur.

WireGuard, hub-and-spoke. Her sanatçı, iş istasyonundan küme tesisindeki hub'a WireGuard istemcisi üzerinden bağlanır. Sanatçı ile küme arasındaki tüm trafik uçtan uca şifrelenir. Bir rol için IPSec, başka bir rol için farklı bir VPN karıştırmaktan kasıtlı olarak kaçınıyoruz; protokollerin birleştirilmesi güvenliği iyileştirmeksizin operasyonel yüzey alanını artırır.

TCP BBR. Linux'un varsayılan tıkanıklık kontrolü (CUBIC), hafif paket kaybı olan düşük gecikmeli bağlantılar için tasarlandı. Şifreli trafik taşıyan uzun mesafeli genel ISP bağlantıları çok farklı görünür — orta düzey gecikme, zaman zaman titreme ve asimetrik kayıp biçimleri. BBR, özellikle bağlantı müşterinin diğer internet trafiğiyle paylaşıldığında bu bağlantılarda CUBIC'e kıyasla sürekli olarak daha kullanılabilir verim üretir. Kernel'in stok BBR'ını (BBR v1) kullanıyoruz; daha yeni BBRv3 bu yapıda dağıtılmadı ve stok sürüm bizim için istikrarlı oldu.

TCP MSS clamping. Bu, "küme büyük dosyalar dışında çoğunlukla çalışıyor" şikayetlerinin en yaygın tek kaynağıdır. 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ü). Küçük paketler ve ping sorunsuz çalışır, bu da sorunu teşhis etmeyi zorlaştırır. Düzeltme, WireGuard yönlendiricisinde TCP MSS'i clamp etmektir; böylece TCP, tünelin içine sığacak paket boyutunu müzakere eder. Bunu uyguladıktan sonra TLS el sıkışmaları, RDP oturumları ve SMB büyük dosya okumaları takılmaktan çıkar.

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. Bunu yapmazsa tünel üzerinden DNS aramaları zaman aşımına uğrar, ancak ping yine de çalışır çünkü ping DNS'ten geçmez. Bu durum yürüttüğümüz en kafa karıştırıcı teşhis oturumlarından bazılarını üretir; çünkü her diğer test sağlıklı görünür.

chrony NTP için. Zaman senkronizasyonu önemsiz görünür ama render manager'lar için (Deadline işleri zaman damgalar), küme genelinde log korelasyonu ve zaman bileşeni olan kimlik doğrulama token'ları için önemlidir. chrony, uzun gecikmeli bir bağlantıda saat kaymasını eski ntpd'den daha iyi yönetir; edge kutusunda çalıştırıyoruz ve her düğümün buna senkronize olmasını sağlıyoruz.

Bu seçimlerin birleşik etkisi, çoğu iş yükü için LAN gibi hissettiren ve genel yol olağandışı biçimde yoğunlaştığında zarif şekilde bozulan bir tüneldir. Sonraki bölüm, bu tünel üzerinden 3D çalışması yapmanın pratikte nasıl göründüğünü ele alıyor.

Moonlight ve Sunshine ile uzak masaüstü

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

Uzak masaüstü için Moonlight (istemci) ve Sunshine (her düğümde host) kullanıyoruz. Bu kombinasyon, frame buffer'ı gerçek zamanlı kodlamak için RTX 5090 üzerindeki NVIDIA NVENC donanım kodlayıcısını kullanır, ardından bunu sanatçının iş istasyonuna akıtır. Kodlama düğümde zaten bulunan GPU'da gerçekleştiğinden renderer ile çekişme olmaz ve uzak masaüstünün eklediği gecikme ağ gidiş-dönüş süresiyle belirlenir — kodlama aşamasıyla değil.

3D viewport çalışması için bu, geleneksel uzak masaüstü için geçerli olmayan bir şekilde önem taşır. Eski protokoller — RDP, VNC, standart Microsoft uzak masaüstü — ofis iş yükleri için tasarlandı. Metin, iletişim kutuları ve yavaş değişen pencereleri iyi yönetirler, ancak dönerek önizleme sırasında tam ekran 3D viewport'ta başarısız olurlar. Moonlight + Sunshine frame buffer'ı video olarak ele alır — bu 3D çalışması için tam olarak doğru modeldir.

Bir düğümü sanatçıya teslim etmeden önce çalıştırdığımız bir kalite kapısı testimiz var — gayri resmi adıyla "Test 8" — belirli bir yük altında tanımlanmış viewport işlemleri dizisini uygulayan ve uzak masaüstü deneyiminin bir baseline'ı karşıladığını doğrulayan. Bir düğüm testi geçemezse ya kodlama pipeline'ını ayıklarız ya da sorunu çözene kadar düğümü rotasyondan çıkarırız. Bu testi her taahhüdün başında ve herhangi bir düğüm yeniden image'lamadan sonra çalıştırırız.

Sunshine'ın host'a özgü bir sorun yaşadığı durumlarda Parsec geçerli bir alternatiftir. Sunshine güvenilir şekilde yapılandırılamadığında küçük sayıda düğümü Parsec üzerinde gönderdik; sanatçı deneyimi benzer. Hesap tabanlı, bulut koordineli modelin Model B kimlik bilgisi yönetimiyle self-hosted Sunshine kadar temiz uymadığı için bunu standartlaştırmıyoruz.

Erken planlama aşamasında başka uzak masaüstü seçeneklerini değerlendirip onlardan uzaklaştık — GPU kodlama içermeyen genel uzak masaüstü araçları ve tam ekran 3D viewport'ta kalite kapımızı karşılamayan açık kaynaklı bir alternatif. Önemli olan ilke şudur: GPU kümesi düğümleri için donanım kodlamalı akış, ölçekte dayanıklı olan tek modeldir.

Kapasite planlama ve rezerve edilen dilim

Bu rehberdeki 20 düğümlü yapılandırma, Super Renders Farm'ın daha geniş filosundan taahhüt süresi boyunca ayrılmış rezerve edilmiş adanmış bir dilimdir. Rezerve, düğümlerin yönetilen hizmet havuzuyla paylaşılmadığı, diğer tenantlarla birlikte planlanmadığı ve kare başı faturalandırmaya tabi tutulmadığı anlamına gelir — müşteri dilimi sabit bir operasyonel gider olarak öder ve başlangıçtan sona kadar bu düğümler üzerinde münhasır kontrole sahiptir.

Dilimi yirmi düğüme boyutlandırmak kasıtlı bir tercihtir. On düğümün altında, bir küme yönetilen bir render farm'a karşı mimari yüzey alanını haklı kılmaz — SaaS yolu daha basit ve daha ekonomiktir. Otuzun üzerinde cache katmanının yeniden tasarlanması gerekir (birden fazla cache kutusu, bölgesel cache'ler) ve operasyonel model biçim değiştirir. Yirmi, tek bir edge-and-cache kutusunun, tek bir WireGuard hub'ının ve tekdüze bir Windows image'ının temiz tutunduğu aralıktır — ayrıca on-yirmi sanatçılık bir yaratıcı ekibin yoğun çalışma dönemlerinde kare akışını sürdürecek ve sakin dönemlerde boşta kalmayacak kadar düğüme sahip olduğu aralıktır.

Super Renders Farm bu adanmış dilimin ötesinde önemli bir filo işlettiğinden, taahhüt bunu gerektirdiğinde ölçek büyütme için alan mevcuttur. Aynı tesis içinde ek rezerve düğümler eklemek, tedarik döngüsü değil bir yapılandırma değişikliğidir. Çok aylık taahhütler yürüten müşteriler genellikle başlangıçta dilim boyutunu sabitler ve gerçek talep ile orijinal plan arasındaki farka göre çeyrek sınırlarında yeniden kapsamlandırır.

Ağ segmentasyonu

Böyle bir kümede ağ segmentasyonu isteğe bağlı değildir. Müşteri sağlayıcının altyapısı üzerinde çalışır; ancak müşteri sağlayıcının daha geniş ağını hiçbir zaman görememelidir — ne sağlayıcının NAS'ını, ne yönlendirici yönetim arayüzlerini, ne de diğer tenantları. Eşit ölçüde, sağlayıcının iç sistemleri müşterinin iş yüklerine hiçbir zaman maruz kalmamalıdır.

Segmentasyonu iki katmanda uyguluyoruz.

Katman 1 — edge güvenlik duvarı. Edge-and-cache kutusu, varsayılan-reddet gelen (inbound) duruşunda ufw (uncomplicated firewall) çalıştırır. Yalnızca WireGuard UDP portu (51820) genel internete açıktır. SSH, SMB, DNS, NTP ve edge üzerinde çalışan diğer tüm hizmetler dahili arayüzlere bağlıdır ve küme dışından erişilemez. Yönlendirme kuralları, WireGuard arayüzü ile küme LAN'ı arasında paket geçişine izin verir; ancak bunların ikisi ile sağlayıcının diğer dahili ağları arasında geçişe izin vermez. Varsayılan yönlendirme tutumu, açıkça izin verilmedikçe düşürmektir.

Katman 2 — her düğümde host güvenlik duvarı. Her render düğümünün, edge duruşunu yansıtan kendi Windows güvenlik duvarı yapılandırması vardır — kümenin ihtiyaç duyduğu hizmetler için (SMB, uzak masaüstü, render manager) küme IP'lerinden gelen bağlantıları kabul eder, diğer her şeyi düşürür. Bu gereksiz bir yedeklilik değil; derinlemesine savunmadır. Bir düğüm yanlış yapılandırılmış veya ele geçirilmişse host güvenlik duvarı bir engel olmaya devam eder.

Her iki katmanın ardındaki ilke en az ayrıcalıktır: müşteri ve düğümler yalnızca düğüm grubunu görebilmelidir. Müşteriye sağlayıcının iç ağına genel rotalar vermiyoruz. Müşterinin tüneli edge kutusunda sonlanır; edge kutusu yalnızca küme LAN'ına yönlendirir; küme LAN'ı yalnızca küme üyeleri arasında yönlendirir.

Pratikte müşteri, isteseler bile sağlayıcının diğer sistemlerini ping atamaz veya tarayamaz. Diğer tenantları ifşa eden paylaşımlı yönetim düzlemi yoktur, paylaşımlı izleme yolu yoktur.

Öğrenilen dersler

Bunlar, 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 derstir.

1. Dual-home gateway yönlendirme tuzağı. Edge kutusu iki ağ arayüzüne (biri genel, biri LAN) sahip olduğunda işlemlerin sırası önemlidir. LAN rotası, varsayılan rota değiştirilmeden önce yapılandırılmalıdır. Önce varsayılan rotayı değiştirip ardından LAN rotası eklemeye çalışırsanız, oturum açmak için kullandığınız SSH oturumu varsayılan rota değiştiği anda düşebilir ve kutunun dışında kalabilirsiniz. Düzeltme teknik değil prosedüreldir: önce dahili rotaları yapılandırın, doğrulayın ve yalnızca ardından varsayılan rotaya dokunun.

2. WireGuard ve DNS. dnsmasq, WireGuard arayüzü dahil olmak üzere dinlemesi gereken her arayüzü açıkça listelemelidir. Yalnızca LAN arayüzünü listelerseniz VPN istemcilerinden gelen DNS aramaları zaman aşımına uğrar — ancak ping yanıtları yine de çalışır çünkü ping DNS'ten geçmez. Bu, karşılaştığımız en yanıltıcı hata modlarından biridir. Düzeltme dnsmasq yapılandırmasındaki tek bir satırdır, ancak nereye bakacağınızı bilmeniz gerekir.

3. Tünel üzerinden TCP MSS clamping isteğe bağlı değildir. TLS el sıkışmaları, RDP oturumları, SMB büyük dosya okumaları — büyük paketler göndermek isteyen her şey — MSS clamp olmadan sessizce düşer. İlk belirti genellikle "Moonlight on saniye çalışıyor, sonra donuyor" veya "SMB dizinleri listeliyor ama 1 MB'dan büyük dosyaları okuyamıyor" şeklindedir. Düzeltme WireGuard host'unda tek bir iptables kuralıdır. Küme teslim edilmeden önce uygulayın.

4. Depolamayı doğru boyutlandırın, aşırı mühendislikten kaçının. Bu mimarinin önceki versiyonu XFS üzerinde LUKS şifrelemeli RAID 10 öngörüyordu. Dağıttığımız cache donanımı tek bir SSD'ydi. RAID katmanını kaldırdık, LUKS katmanını kaldırdık ve ext4 kullandık — çünkü cache gerçeğin kaynağı değildir, bulut platformu öyledir. Cache katmanındaki kağıt üzerindeki yedekliliği bulut katmanındaki gerçek yedeklilikle takas etmek doğru tercihtir. Ders şudur: veriyi gerçekte neye ihtiyaç duyduğuna göre tasarlayın, plan belgesinde güvenli hissettiren şeye göre değil.

5. Cache'i ön-ısıtın. D-Day'de her cache miss, uluslararası bağlantıya ve bulut platformuna gidiş-dönüş maliyetine neden olur. Soğuk cache'de üretimdeki ilk saat, diğer her şey doğru yapılandırılmış olsa bile yavaş hissedilir. Artık her taahhüde — genellikle üretim başlamadan bir ya da iki gün önce — bir ön-ısıtma penceresi planlıyoruz. Sanatçı ön-ısıtmayı görmez; ilk karede zaten hızlı çalışan bir küme görür.

Bunlar mimari değil, operasyonel derslerdir. Mimari belgede değil, dağıtım kontrol listesinde yer alırlar. Ancak teoride çalışan bir kümeyi gerçek üretim yüküne dayanıklı bir kümeyle ayırt ederler. Daha küçük kalıplar taahhüt bazında uygulanır — yukarıdaki beşi her dağıtımda ortaya çıkanlardır.

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 kendi bulutunuzu getirme (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 yanıttır — buradaki mimari karmaşıklık, proje tabanlı çalışmalar veya adanmış bir operasyon fonksiyonu olmayan ekipler için kendini haklı kılmaz.

Koşullar geçerli olduğunda, burada ele alınan kalıplar — Model B kimlik bilgileri, ext4'te paylaşımlı cache, WireGuard hub-and-spoke taşıma, MSS clamping ile BBR, Moonlight + Sunshine uzak masaüstü, iki katmanlı güvenlik duvarı — varsayılan olarak dağıttığımız şeylerdir. Bunlar tek geçerli kalıplar değildir, ancak dağıtımlar boyunca dayanmış olanlardır.

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ümesi 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: Kapsama, tesisteki donanım hazırlığına ve müşterinin cloud file-streaming kurulumuna bağlı olarak, tipik bir taahhüt donanım ve ağ temini için birkaç haftalık hazırlık süresinden üretim başlamadan bir-iki gün önceki ön-ısıtma penceresine kadar uzanır. Zaman çizelgesini sabit bir şablona göre değil müşterinin üretim takvimine göre belirliyoruz.

Q: Ekibim üç kıtaya yayılmışsa ne olur? A: WireGuard hub-and-spoke topolojisi, küme mimarisini değiştirmeksizin ek istemci konumlarına ölçeklenir. Her uzak sanatçı bir WireGuard istemcisi çalıştırır ve küme tesisindeki aynı hub'a bağlanır. Her bölgeden gecikme, söz konusu bölge ile hub arasındaki genel internet yolu tarafından belirlenir; deneyimimize göre BBR ve MSS clamping bu yollarda kullanılabilir ile kullanılamaz arasındaki farkı yaratır.

Q: Çok aylık bir taahhütten önce kümeyi kendi tarafımdan görebilir miyim? A: Kapsam görüşmesi sırasında genellikle bir kavram kanıtlama (proof-of-concept) penceresi düzenliyoruz. Tam form müşterinin projesine bağlıdır — bazen sanatçı deneyimini test etmek için tek düğümlü bir uzak masaüstü oturumu, bazen cache ve cloud file-streaming entegrasyonunu doğrulamak için küçük ölçekli bir render testi. Spesifik koşullar iş görüşmesidir; zaman çizelgeniz için nelerin işe yarayacağını konuşmak üzere satış ekibimize ulaşın.

Q: Taahhüt sonunda veri güvenliği nasıl ele alınır? A: Model B müşteri kimlik bilgilerini elimizden uzak tuttuğundan, taahhüt sonu kapatma işlemi donanım ve cache temizliğine odaklanır. SMB cache'ini sileriz, her düğümü temiz baseline'dan yeniden image'larız ve cache ile düğüm image'larının imha edildiğine dair yazılı bir kanıt belgesi sağlarız. Müşteri kendi cloud file-streaming oturumlarını iptal eder; bu sistemimizin dışındadır. Belirli sözleşme dili (NDA, SLA, kanıt belgesi ifadesi) satış ekibimiz tarafından yönetilir.

Q: 20 düğümden fazlasına ihtiyacım varsa ne olur? A: 20 düğümlü yapılandırma en yaygın dağıttığımız biçimdir; ancak mimari bunun ötesine ölçeklenir. Daha büyük filolar aynı tesis içinde eklenir — ek rezerve düğümler aynı WireGuard hub'ına, aynı SMB3 cache'e ve aynı tekdüze Windows image'ına dahil edilir. Pratik sınır genellikle cache bant genişliğidir: tek bir edge-and-cache kutusunun sonlu bir SMB okuma tavanı vardır ve çok büyük filo boyutlarında cache mimarisinin kendisinin yeniden düşünülmesi gerekir (birden fazla cache kutusu, bölgesel cache'ler). Bu tasarım tercihlerini taahhüt bazında ele alıyoruz.

Q: Cinema 4D, Redshift veya diğer DCC araçları için kendi lisansımı getirebilir miyim? A: Lisans modeli — kendi lisansınızı getirme (BYOL) veya sağlayıcı tarafından sağlanan — belirli DCC'ye ve müşterinin mevcut lisans envanterine bağlı bir iş kararıdır. Bazı yapılandırmalar müşteri lisanslarıyla sorunsuz çalışır; diğerleri sağlayıcı tarafından sağlananlarla daha basittir. Bunu kapsam görüşmesi sırasında çözeriz. Ayrıntılar için satış ekibimize ulaşın.

Q: AB ve ABD sağlayıcılarından gelen bulut depolamayı nasıl ele alıyorsunuz? A: Cloud file-streaming platformu müşterinin tercihidir. Kümemiz, Windows üzerinde oturum açma istemcisi çalıştırabilen ve müşterinin proje ağacını mount edilmiş bir dosya sistemi olarak ortaya koyabilen herhangi bir platformla entegre olur. Upstream bulutun coğrafi konumu, müşteri-küme yolunun uluslararası gecikmesini etkiler — bu nedenle sınır ötesi kurulumlar için WireGuard hub-and-spoke taşıma ve BBR ayarlı yapılandırmayı öneriyoruz. Bulut platformunu biz barındırmıyoruz; müşterinin hesabı kapsamında kalır.

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 duraksamış olabilir. Tünel, devam eden bir render sırasında düşerse render işleminin kendisi düğüm üzerinde çalışmaya devam eder (devam eden çalışma için tünele bağımlı değildir), ancak buluta geri yazma işlemi tünel yeniden kurulana kadar bekler. Tünel sağlığını edge kutusundan izliyoruz ve uzun süreli kesintilerde uyarı gönderiyoruz.