WireGuard şifreleme · BBR tıkanıklık kontrolü · Paylaşımlı önbellek · Küresel ölçekte dağıtık yaratıcı ekipler için yapılandırma.
Modern yaratıcı iş giderek daha dağıtık hale geliyor. Bir 3B boru hattında New York'ta bir sanat yönetmeni, Berlin'de bir aydınlatma ekibi, Seul'de serbest çalışan look-dev sanatçıları ve başka bir kıtada bir render farm bulunabilir. Bu dördü aynı gigabit LAN üzerinde olduğunda render farm erişimi sorun değildir. Olmadıklarında iş akışı kamuya açık internetten geçer ve uzun mesafeli yönlendirmenin her tuhaflığı takvimde görünmeye başlar.
Bu tip yapılandırmalarda üç sorun tekrarlanır. Birincisi gecikmedir — kıtalar arası 150 ila 250 ms gidiş-dönüş süresi uzaktan masaüstünün hissini değiştirir ve render yöneticisindeki veya varlık akış protokolündeki her gevezeliği büyütür. İkincisi titremedir (jitter) — uluslararası hatlar genellikle sınırda çalışır ve paket zamanlaması değişir. Üçüncüsü bant genişliği maliyeti ve rekabettir — bir 40 GB sahne dosyasını kıtalar arası bir hattan bir kez çekmek kabul edilebilirdir; her render düğümünün kendi önbelleği olduğu için yirmi kez çekmek değildir.
Yerel bir render farm bunların çoğunu atlatır. Sanatçılarıyla aynı veri merkezi bölgesinde zaten bir kümeye sahip olan ekipler, bu sayfada açıklanan şeylerin çoğuna ihtiyaç duymaz. Aşağıdakilerden biri geçerli olduğunda cross-country render doğru mimari seçim haline gelir:
Bunlardan biri doğru olduğunda soru operasyonel hale gelir: dünyanın diğer ucundaki bir render farm'ı, sanatçının yerel ağının bir parçası gibi davranacak şekilde nasıl çalıştırırız? Bu sayfanın geri kalanı Super Renders Farm'da buna nasıl yaklaştığımızı anlatır.
Cross-country bağlantıları, teker teker değil dört parçayı birlikte uygulayarak optimize ederiz.
Müşteri uç noktasından render farm'a giden her bağlantı WireGuard üzerinden çalışır. Müşterinin makinesi bir WireGuard eşi olur; ana veri merkezi bir hub işletir. Şifreleme otomatik ve uçtan uçadır; müşteri kamuya açık internette düz metin trafik görmez, biz de görmeyiz. WireGuard ayrıca uzun mesafeli bir hatta darboğaz olacak kadar ağır değildir — ek yükü geleneksel bir IPsec yığınınınkinden belirgin biçimde küçüktür.
Linux çekirdeğinin varsayılan tıkanıklık kontrolü (CUBIC), titreme ve paket kaybı karşısında muhafazakâr davranır — kaybı yavaşlama sinyali olarak yorumlar, bu kayıp aralıklı uluslararası yönlendirmeden geliyor olsa ve gerçek bir tıkanıklık olmasa bile. BBR (Bottleneck Bandwidth and RTT), hattın gerçek bant genişliği-gecikme çarpımını ölçer ve kapasite var oldukça boruyu dolu tutar. Kararlı bir kıtalar arası rotada BBR, aynı donanımla CUBIC'in genellikle iki ila üç katı verim sağlar. Titremeli bir rotada fark daha büyüktür.
Bir paket WireGuard gibi bir tünelden geçtiğinde, etkin MTU değeri alttaki arayüzünkinden küçüktür. Bir TCP bağlantısı tünelin taşıyabileceğinden daha büyük bir MSS müzakere ederse iki şey olur: küçük paketler geçer, büyük paketler sessizce düşürülür. Belirti uzaktan çalışmadaki en sinir bozucu durumlardan biridir — SSH çalışır, ping çalışır, ama TLS el sıkışmaları, RDP oturumları ve anlamlı boyuttaki SMB dosya kopyaları takılır. WireGuard ağ geçidinde MSS'i sıkıştırırız, böylece tüm TCP bağlantıları tünelin gerçekten teslim edebileceği bir segment boyutu müzakere eder.
Farm içinde, dahili DNS çözümleme için `dnsmasq` ve zaman senkronizasyonu için `chrony` çalıştırırız. İkisi de göründüklerinden daha önemli olan sessiz altyapı parçalarıdır. Dahili DNS, render düğümlerinin paylaşımlı önbelleğe IP adresi yerine `cache.lan` olarak başvurmasını sağlar, bu da topolojiyi yeniden düzenlemeyi güvenli kılar. Zaman senkronizasyonu önemlidir çünkü render yöneticilerinin ve günlük boru hatlarının çoğu saat sapmasına iyi dayanmaz — filodaki diğerlerinden 30 saniye sapmış bir düğüm kafa karıştırıcı iş atama davranışı üretebilir. İki hizmet de yalnızca dahili ağı dinler; kamuya açık internetten hiçbir şey onlarla doğrudan konuşmaz.
Birlikte ele alındığında bu dört parça, uzun mesafeli bir render farm'ı uzaktaki bir makineden çok sanatçının iş istasyonunun yavaş bir LAN uzantısı gibi hissettirir. Hiçbiri egzotik değildir; değer bunları bir yığın olarak uygulamakta ve parametreleri müşteri trafiğinin gerçekten aldığı rotalara göre ayarlamakta yatar.
Cross-country yapılandırmalar için kullandığımız dağıtım biçimi hub-and-spoke topolojisidir; tek bir birincil veri merkezi hub görevi görür ve bir veya daha fazla ikincil site site-to-site WireGuard ile bağlanır.
Bu topolojide her kurulumda tekrarlanan birkaç karar değinmeye değer.
Edge ve önbellek üç değil tek bir kutuda çalışır. WireGuard'ı dışarıdan sonlandıran aynı Ubuntu makinesi Samba önbelleği, dahili DNS ve zaman hizmetini de barındırır. Belirli bir sebep yoksa bu rolleri birden çok makineye bölmeyiz. Doğru boyutlandırma kasıtlıdır. Adanmış tek bir önbellek kutusunun bir giriş ve bir çıkış ağ yolu vardır, bu da yönlendirme matematiğini basit tutar. Hata modlarını düşünmeyi de kolaylaştırır — önbellek ayaktaysa dahili hizmetler ayaktadır; değilse dahili olarak hiçbir şey çalışmaz, ve bu tek sinyali uyarmak üç ayrı sinyalden daha kolaydır.
Site-to-site WireGuard ikincil konumu yönetir. Dağıtım iki fiziksel konuma yayıldığında — örneğin, ana veri merkezi artı aynı metropoldeki daha küçük kiralık bir site — ikisi kamu ISP üzerinden bir site-to-site WireGuard tüneliyle bağlanır. Aralarındaki trafik host perspektifinden büyük bir alt ağ gibi görünür. İkincil sitedeki render grubu B, Main DC'deki önbelleği grup A ile aynı şekilde okur, sadece daha fazla atlama ile.
Ağ Layer-3 yönlendirilebilirdir. Her düğüm, diğer düğümlerin doğrudan adresleyebileceği gerçek bir IP host'tur. Belirli bir render yöneticisi dayatmayız. Deadline tercih eden ekipler kendi Deadline deposunu müşteri tarafı bir koordinatör düğümünde çalıştırabilir; başka bir şey tercih eden ekipler onu kullanabilir. Farm host'ları, ağı, önbelleği ve optimizasyon yığınını sağlar; üstündeki orkestrasyon katmanı müşterinin seçimidir.
Daha derin bir gezinti için, operasyonel dağıtım kılavuzu tüm prosedürü adım adım kapsar ve mimari derinlemesine analiz WireGuard ve önbellek tasarımına daha fazla ayrıntıyla girer.
Kıtalar arası bant genişliği iki anlamda pahalıdır: bulut egress faturasında para kazandırır ve sanatçılar bir varlığın borudan inmesini beklediğinde zaman kaybettirir. Bunu düşünmeyen bir render filosu, her işin duvar zamanının önemli bir bölümünü, binanın başka bir yerinde önbellekte zaten bulunan sahne dosyalarını soğuk çekmeye harcayabilir.
Paylaşımlı önbellek deseni en basit ve en büyük kaldıraçtır. Ana veri merkezindeki bir Samba (SMB3) önbellek sunucusu proje varlıklarını tutar. Her render düğümü önbelleği mount eder ve sahne dosyalarını LAN üzerinden okur. Bir iş yeni bir varlığa atıfta bulunduğunda, önbellek onu müşterinin bulut depolama alanından bir kez çeker. Aynı varlığa ihtiyaç duyan sonraki her düğüm onu LAN kopyasından okur. Aksi takdirde 40 GB'lik bir sahne dosyasını yirmi kez çekecek olan 20 düğümlü bir filo, onu bir kez çeker.
Prensip doğrudandır. Pratikte tasarımın iki parçası önemlidir.
Düğüm başına önbelleklemeden kaçının. Her render düğümüne kendi büyük yerel SSD'sini verip istediğini önbelleğe almasına izin vermek caziptir. 10 TB proje verisiyle 20 düğümlü bir filo için bu, paylaşımlı geçersiz kılma mantığı olmadan 200 TB'lık çoğaltılmış depolama haline gelir. Bunu yapmayız. Paylaşımlı önbellek tek önbelleğimizdir; düğümler yerel disklerini proje arşivi değil çalışma alanı olarak değerlendirir.
D-day'den önce önbelleği ısıtın. Bir müşteri projenin Pazartesi başlayacağını duyurduğunda hafta sonu boyunca önbelleği önceden ısıtırız. Pazartesi günkü ilk iş, yirmi saatlik soğuk çekiş tetiklemek yerine sıcak bir önbellekten okur. Bu, bir projenin ilk render'ının hızlı hissettirmesinin en güvenilir yöntemidir.
Doğru boyutlandırma hakkında bir not: önbellek kutusu ext4 dosya sistemi üzerinde tek bir SATA SSD kullanır. Bir önbellek için (birincil depolamanın aksine) tek diskli bir düzen doğru ödünleşimdir. Önbellek gerçeğin kaynağı değildir — bu, müşterinin bulut depolama alanıdır — ve önbellek bulutu yeniden çekerek veya bir proje yedeğinden rsync ile yeniden inşa edilebilir. Şifrelenmiş bir hacim üzerinde yedekli bir dizi oluşturmak maliyet ve karmaşıklık ekler ama operasyonel hikâyeyi değiştirmez; önbelleği kaybeden bir düğüm bir akşamlık bir yeniden kurulum işidir, veri kaybı olayı değildir. Önbellek donanımını rolüne göre boyutlandırmak, işletme maliyetini öngörülebilir tutmanın en kolay yollarından biridir.
Tek bir cross-country dağıtım yerine kalıcı bir küme düşünen ekipler için dedicated cluster options sayfası o düzenlemeyi ayrıntılı olarak ele alır.
Cross-country render farm'lar evrensel olarak daha iyi bir seçenek değildir. Belirli bir iş akışı türü için anlam taşır ve yerel bir farm'a kıyasla öngörülebilir ödünleşimlere sahiptir.
GPU düğümünü etkileşimli olarak yönetmesi gereken sanatçılar için — örneğin Redshift ile bir Cinema 4D sahnesi açmak, IPR önizlemeleri yapmak veya tam iş gönderiminden önce render çerçevelemek — Moonlight'ı istemci, Sunshine'ı host olarak kullanırız. Her ikisi de render düğümünün GPU'sundaki NVENC donanım kodlamasını kullanır, bu da yazılım kodlamalı uzaktan masaüstü protokollerinden gözle görülür biçimde daha akıcı bir akış üretir. İyi ayarlanmış uzun mesafeli bir hat üzerindeki kodlanmış video, yüksek detaylı viewport etkileşimi dahil gerçek iş için kullanılabilir bir deneyim sunar; aynı iş yükü düz RDP üzerinde sıklıkla sunmaz. Parsec, Sunshine'ın oturum müzakeresinde zorlandığı nadir durumlar için yedek olarak yapılandırılmıştır.
İyi ayarlanmış bir kıtalar arası hat tipik olarak 150 ila 250 ms gidiş-dönüşe yerleşir. Sayı coğrafi ayrışmaya ve müşterinin trafiğinin gerçekten aldığı rotaya bağlıdır. Bu sayfada belirli bir şehir-çifti gecikmesi yayınlamıyoruz çünkü genelleşmez — kendi ISP'niz, kendi peering'iniz ve kendi yerel atlamalarınız deneyimi alıntılayabileceğimiz herhangi bir sayı kadar etkiler. Planlama aşamasında aday bir uç noktadan bir prob çalıştırabilir ve ekibinizin kullanacağı rota için gerçek ölçümleri paylaşabiliriz.
Cross-country dağıtımlarımız, müşterinin kendi bulut platformunda proje depolamasıyla, mevcut nesil tüketici GPU'larıyla (RTX 5090 sınıfı donanım) 20 düğümlü küme ölçeğinde çalıştı. Bu yaklaşık olarak önceki bölümlerdeki mimari seçimlerin önem kazanmaya başladığı ölçektir — daha küçük filolarda daha az optimize edilmiş bir kurulum daha rahat işini görebilir.
Cross-country render, sanatçılar dağıtık olduğunda ve render filosunun bir yerde olması gerektiğinde, proje verileri zaten belirli bir bulut bölgesinde yaşadığında, müşterinin yerel seçeneklerin sağlayamayacağı IP-izoleli altyapıya ihtiyacı olduğunda veya GPU bulunabilirliği veya maliyeti belirli bir bölgeyi tercih ettiğinde doğru uyumdur.
Ekipteki herkes render filosuyla aynı ofiste veya ülkede çalışıyorsa, bu sayfadaki optimizasyonlar çoğunlukla gereksiz ek yüktür. Daha kısa borular ve daha basit yönlendirme ile yerel bir farm işletmesi daha kolay olur ve BBR veya MSS sıkıştırmasından aynı şekilde yararlanmaz. Dürüst karşıt konumlama önemlidir: her ekip bu mimariye ihtiyaç duymaz. Sanatçıların ve render donanımının aynı bölgede oturabileceği iş yükleri için standart render farm rental options sayfası durumu iyi kapsar.
Genel ifadelerle, iyi ayarlanmış uzun mesafeli hatlar 150 ila 250 milisaniye gidiş-dönüş aralığında yer alır; kesin sayı sanatçının ISP'sine, trafiğin aldığı rotaya ve uç noktanın coğrafi konumuna bağlıdır. Planlama sırasında aday bir iş istasyonundan bir prob çalıştırabilir ve rotanız için gerçekten ölçülen sayıları paylaşabiliriz.
BBR tıkanıklık kontrolü birincil önlemdir — hat titrediğinde varsayılan CUBIC'in yaptığı gibi paket kaybında çökmek yerine verimi sabit tutar. WireGuard'ın kendisi de IPsec tüneli gibi oturum durumu tutmadığından kısa ağ kesintilerine karşı toleranslıdır. ISP düzeyindeki kesintiler için, üst akış rota geri döner dönmez tünel yeniden bağlanır; devam eden render işleri sanatçının bağlantısının durumundan bağımsız olarak farm tarafında çalışmaya devam eder.
Evet. Her bağlantı WireGuard ile şifrelenmiştir: sanatçı uç noktasından ana veri merkezine ve Main DC ile herhangi bir ikincil site arasında site-to-site. Kamuya açık internette gözlemcinin ekibiniz ile render filosu arasındaki düz metin trafiği okuyabileceği bir nokta yoktur. Herhangi bir aracı taşıya güven istemiyoruz; şifreleme WireGuard katmanındadır, üstüne seçenek olarak eklenmiş değildir.
Evet. WireGuard hub birden çok eşi kabul eder, dolayısıyla herhangi bir konum sayısından herhangi bir sayıda sanatçı aynı anda aynı farm'a bağlanabilir. Her sanatçı iş istasyonunda WireGuard istemcisini çalıştırır, Moonlight'ı açar ve kendisine atanmış render düğümüne bağlanır. Önbellek ve DNS gibi dahili hizmetler filo genelinde paylaşılır, böylece farklı kıtalardan aynı sahne üzerinde çalışan iki sanatçı aynı varlık kümesini görür.
Paylaşımlı SMB önbelleği aracılığıyla. Bir render işi önbelleğin henüz görmediği bir varlığa atıfta bulunduğunda, önbellek onu müşterinin bulut depolama alanından bir kez çeker. Aynı varlığa ihtiyaç duyan sonraki düğümler onu kıtalar arası hat üzerinden değil, LAN üzerinden hat hızında önbellekten okurlar. Başlangıç tarihleri öngörülebilir projeler için önbelleği D-day'den önce ısıtırız, böylece projenin ilk render'ı soğuk çekiş şelalesi tetiklemek yerine sıcak bir önbellekten yararlanır.
Aynı şekilde çalışır; coğrafi ayrım yalnızca önbelleğe ilk çekmenin aynı bölge depolamasından daha uzun sürdüğü anlamına gelir. Bir varlık önbelleğe girdikten sonra coğrafi ayrım önemini yitirir — render düğümleri LAN üzerinden okur. Bu senaryoda genellikle önbelleği önceden ısıtırız, böylece bölgeler arası çekme proje başlamadan önce bizim tarafımızda gerçekleşir ve ilk render sırasında olmaz.
Veri yerleşimi, render filosunun kendisinin nerede sağlandığına bağlıdır ve bunu müşteri ile önceden planlarız. Belirli yerleşim gereksinimleri olan ekipler için, proje verilerinin nerede tutulduğunu, render'ların nerede üretildiğini, günlüklerin nerede saklandığını ve ilişkinin sonunda verilerin nasıl silindiğini görüşmemiz gerekir. Bu tek bir evet veya hayır cevabı değil bir planlama sohbetidir; durumunuzun ayrıntılarını görüşmek için lütfen bizimle iletişime geçin.
Render'ın kendisi devam eder. Render işleri farm tarafında sanatçının tünel durumundan bağımsız olarak çalışır — bir iş dağıtıldıktan sonra sanatçı tamamen bağlantıyı kesebilir ve kareler üretilmeye devam eder. Tünel geri döndüğünde sanatçı WireGuard eşini yeniden kurar ve Moonlight üzerinden aynı oturuma tekrar bağlanır. Render ortasındaki bir tünel kesintisinin en sık görülen pratik etkisi, sanatçının kesinti boyunca ilerlemeyi canlı izleyememesidir; render'ın kendisi yeniden başlamaz.
