Ülkeler arası render farm deployment: 2026'da sahadan altı ders

Giriş: Mimari diyagramlar yalan söyler, production log'ları söylemez

Temiz mimari planına karşı dağınık production gerçekliği

Bir planlama belgesinde çizdiğiniz mimari diyagram ile bir Salı öğleden sonra gerçekten bir müşteri için render çalıştıran sistem arasında bir boşluk vardır. Deploy ettiğimiz her ülkeler arası render farm bu boşluğu zor yoldan kapattı — kendi gateway'imizden bizi kilitleyen komutlarla, ICMP'nin ağın iyi olduğunu söylediği sırada sessizce timeout'a düşen DNS sorgularıyla, temiz biten ve büyük bir paket tüneli geçmeye çalıştığı anda düşen TCP handshake'lerle.

Bu makale, bir render farm nasıl inşa edileceğine dair bir öğretici değildir. Sanatçıları bir ülkede çalışırken donanımları başka bir ülkede koşan müşteriler için adanmış GPU cluster'lar deploy ederken gerçekten neyi kırıp neyi düzelttiğimizin bir kaydıdır. Buradaki dersler bilinçli olarak operasyoneldir, mimari değil. Bir tedarikçinin ürün sayfasında görünmeyen ve nadiren halka açık bir konferans konuşmasına ulaşan türden şeylerdir, çünkü mühendislikten çok saha notları gibi okunurlar.

Super Renders Farm'da on yıldan uzun süredir bir fully managed cloud render farm işletiyoruz. Ekipler kıtalar arasında uzanan adanmış bir cluster'a ihtiyaç duyduğunda — sanatçılar bir tarafta, GPU'lar diğer tarafta — bunlar üçüncü deployment'tan sonra değil, ilk deployment'tan önce okumayı dilediğimiz altı derstir. Ayrıca dürüst bir karşı-dersler bölümü ekliyoruz: denediğimiz, vazgeçtiğimiz veya bilinçli olarak deploy etmediğimiz bileşenler. Tam resmi istiyorsanız bu makaleyi tam operasyonel rehberimiz ve mimari derinleştirmesi yazımız ile birlikte okuyun.

Ders 1: Dual-home gateway routing tuzağı

İki ağ arayüzü olan bir gateway makinesini ilk deploy ettiğimizde — biri public internete bakan, biri internal LAN'a — internal route'u set etmeden default route'u değiştirdik. Üç saniye içinde SSH oturumumuz düştü. Yeniden bağlanamadık. Makine, out-of-band konsolu olmayan bir datacenter rack'inde duruyordu ve geri dönüş yolu yalnızca bir remote-hands ticket'ıydı.

Bu, dual-home gateway routing tuzağıdır ve tanıdığımız her operatörü en az bir kez ısırmıştır. Mekanik basittir: bir makinenin iki NIC'i olduğunda, kernel'a hangi gateway'in hangi ağı yönettiğini söylemek gerekir. Default route'u public arayüze işaret etmeye değiştirirseniz (external trafik WireGuard endpoint'inden, NAT çıkışından veya tasarımınızın gerektirdiği yerden çıksın diye), ve internal LAN için route'u henüz sabitlemediyseniz, internal LAN üzerinden gelen SSH oturumunuzun aniden dönüş yolu kalmaz. Laptop'unuza geri gönderdiğiniz her paket public arayüzden çıkmaya çalışır, upstream router tarafından düşürülür çünkü kaynak IP o yönden anlamsızdır ve terminaliniz asılır.

Düzeltme mekaniktir: her zaman önce internal route'u set edin, sonra default'u değiştirin. Ubuntu 22.04 koşan bir Linux gateway'de bu sıra aşağı yukarı şöyle görünür. Önce LAN-tarafı gateway aracılığıyla LAN alt ağı için explicit bir route eklersiniz. Sonra, ve ancak o zaman, default route'u egress tasarımınızın gerektirdiği şeye değiştirirsiniz.

# Adım 1: LAN-tarafı gateway aracılığıyla internal LAN route'unu sabitle
sudo ip route add 10.0.0.0/24 via 10.0.0.1 dev eth1

# Adım 2: ANCAK ŞİMDİ default route'u değiştir
sudo ip route replace default via <public-gateway-ip> dev eth0

Pratikte iki operasyonel alışkanlık bunu daha güvenli kılar. İlki, herhangi bir routing değişikliği için tmux veya screen gibi bir araç kullanın. Oturumu kaybederseniz, iş disconnect'i atlatır ve yeniden bağlandığınız anda recover edebilirsiniz. İkincisi, default route'a dokunan her gateway değişikliğinde bir watchdog koyun: iptal etmediğiniz sürece routing tablolarını beş dakika içinde known-good bir duruma geri döndüren bir cron job. Bu cron job bizi birden fazla kez remote-hands ticket'ından kurtardı.

Genelleştirilebilir ders şu: herhangi bir dual-homed makinede, operasyonların sırası final state'in doğruluğundan daha önemlidir. Aynı konfigürasyon yanlış sırada uygulandığında doğru sırada uygulandığından farklı bir sonuç üretir — ve fark shell'inizi koruyup korumamanızdır.

Ders 2: WireGuard artı DNS konfigürasyon tuzağı

Bir render node, gateway'e bir WireGuard tüneli açar. Tünel kalkar. ICMP her iki yönde de çalışır — sanatçı tarafındaki operatör her internal IP'yi ping'leyebilir. Ağın sağlıklı olduğuna güvenerek, operatör bir render job'ı başlatır. Job takılır. Log'lar DNS resolution timeout'ları gösterir. Kafa karışıklığı yerleşir, çünkü operatör az önce her internal adresi ping ile test etti ve hepsi cevap verdi.

Bu, WireGuard artı DNS konfigürasyon tuzağıdır. Pattern, ülkeler arası bir render farm deployment'ında en mantığa aykırı debug deneyimlerinden biridir, çünkü standart «ağ ayakta mı?» kontrolü (ICMP) yeşil dönerken gerçek kullanıcıya görünür hata farklı bir protokol katmanında gerçekleşir.

Kök neden neredeyse her zaman dnsmasq'dır — veya gateway'de hangi internal DNS resolver'ı çalıştırıyorsanız — WireGuard arayüzünde dinlemek üzere konfigüre edilmemiştir. Varsayılan olarak dnsmasq başlangıçta bildiği arayüzlere bind olur. WireGuard arayüzü (wg0) dnsmasq'tan sonra kalkar ve ona orada dinlemesini explicit söylemediğiniz sürece, tünelden gelen sorgular resolver'a hiç ulaşmaz. Diğer her protokol — ICMP, internal IP'lere TCP, hatta IP literal ile direkt SMB mount'lar — çalışırken, sorgular client'ta timeout olur.

Düzeltme dnsmasq konfigürasyonunda bir satırdır:

# /etc/dnsmasq.conf
interface=wg0
interface=eth1
bind-interfaces

bind-interfaces direktifi de önemlidir. Onsuz dnsmasq wildcard 0.0.0.0 üzerinde dinler, bu birçok durumda işe yarar ama bazı firewall konfigürasyonlarıyla kötü etkileşir. Hangi arayüzlerin DNS sunduğu konusunda explicit olmak daha güvenlidir.

Tanı tuzağı tehlikeli olan kısımdır. ICMP çalıştığında, doğal insan içgüdüsü ağı dışlamak ve application katmanına bakmaktır. Bu debug yolunun saatleri yediğini gördük: bir operatör render node'da firewall kurallarını kovalar, sonra license sunucuları kontrol eder, sonra stale bir Deadline konfigürasyonundan şüphelenir, sonra sonunda — üç saat sonra — sanatçı tarafından dig @internal-dns-ip cache.lan çalıştırır ve timeout'u alır. Bu debug oturumunu bir kez yaptınız mı, asla unutmazsınız. Genel ders: DNS resolution'ı ağ sağlığı smoke test'inize ekleyin. Yalnızca ICMP yetmez.

Ders 3: Uzun tüneller için TCP MSS clamping

Üçüncü ders, görmediğinizde en çok zamana mal olandır, çünkü failure modu diğer her şeye benzer. Küçük operasyonlar çalışır. SSH oturumları bağlı kalır. Bir port'a telnet başarır. Kısa bir HTTP GET header döndürür. Sonra biri tünel üzerinden bir SMB share mount etmeye çalışır, ya da bir TLS handshake başlatır, ya da bir RDP oturumu başlatır — ve bağlantı sonsuza dek asılır. Hata yok, reset yok, sadece sessizlik.

Bu MTU blackhole problemidir ve uzun tünellerde, bir şey yapmadığınız sürece esasen garantilidir. WireGuard her pakete şifreli zarf artı header'lar için yaklaşık 60 byte overhead ekler, bu da tünelin içindeki etkili MTU'yu standart 1500-byte Ethernet MTU'sunun altına düşürür. İki endpoint tünel üzerinden full-size bir paket göndermeye çalıştığında, ortadaki router ya onu parçalar (genellikle izin verilmez) ya da gönderenin daha küçük yeniden denemesi için geri bir ICMP «Fragmentation Needed» mesajı gönderir.

ICMP «Fragmentation Needed» mesajları, ara firewall'lar tarafından rutin olarak drop edilir. Path MTU discovery bu şekilde kırıldığında, gönderen tüneli sessizce geçmeye başarısız olan oversized paketler göndermeye devam eder. Küçük paketler geçer; büyük paketler — sunucu sertifikaları taşıyan TLS handshake'leri, SMB negotiation'lar, RDP framing — kaybolur. Oturum hiç gelmeyecek bir cevap için bekler.

Düzeltme TCP MSS clamping'dir. WireGuard gateway'de, mangle tablosuna iptables kuralı eklersiniz; bu kural wg0 üzerinden çıkan her pakette TCP MSS option'ını path MTU'nun fiilen desteklediği değere yeniden yazar. Hesabı kernel halleder:

sudo iptables -t mangle -A FORWARD -o wg0 \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Bunu kullanıcılardan önce yakalamak için tanı düzdür: tünelden bilinçli olarak büyük bir paket gönderin ve ne olduğunu izleyin. Don't-fragment biti set edilmiş bir ping -s 1400 MSS clamping eksikse ve PMTUD kırıksa başarısız olacaktır. Bunu Ders 2'deki DNS check'in yanına deployment smoke test'imize ekleriz, çünkü iki başarısızlık birlikte triage ettiğimiz «ağ çalışıyor ama uygulama çalışmıyor» raporlarının çoğunluğunu kapsar.

Genelleştirilebilir ders şu: herhangi bir tunneled overlay üzerinde «TCP çalışır», «TCP büyük payload'lar için çalışır» ile aynı şey değildir. Ağı sağlıklı ilan etmeden önce her zaman büyük bir paketi uçtan uca test edin.

Ders 4: Doğru boyutlandırma ile aşırı mühendislik karşı karşıya

Adanmış bir render cluster tasarlamak için oturduğunuzda, bir hyperscaler whitepaper'ında bulacağınız türden bir storage stack'i belirlemek için operasyonel bir cazibe vardır. Redundancy için dört disk üzerinde RAID 10, at-rest şifreleme için LUKS, cache filesystem için XFS çünkü biri bir kez XFS'in büyük dosyaları daha iyi yönettiğini söyledi. Diyagram etkileyici görünür. Bill of materials, ihtiyacınız olmayan üç disk ve bir controller ekler. Ve eklenen her katman, başarısız olabilen başka bir katmandır.

Yaptığımız ülkeler arası deployment'lardan biri için orijinal plan tam olarak bu stack'i çağırıyordu. Deploy edilen gerçeklik, ext4 ile ve at-rest şifrelemesiz tek bir 8 TB SATA SSD'ydi. Cache sunucusu WireGuard'ın arkasında yaşar, üzerindeki veriler cloud storage'dan günler yerine saatler içinde tekrar oynatılabilir ve müşterinin tehdit modeli, birden çok ağ izolasyon katmanının arkasındaki bir datacenter rack'ine fiziksel erişim sahibi bir saldırganı içermiyordu. RAID 10, deployment'ın sahip olmadığı bir sorunu çözüyordu. LUKS, cloud-tarafı storage'ın zaten sağladığı şifrelemeyi tekrarlıyordu. XFS, ext4'ün iyi yönettiği bir yük (cache'lenmiş sahne asset'lerinin ardışık okumaları) için bir filesystem seçimi ekliyordu.

Şimdi uyguladığımız genel kural: katman, fiili deployment'taki gerçek bir failure modunu düzeltmiyorsa eklemeyin. Master veri cloud storage'da yaşadığında ve tam bir cache re-warm birkaç saat sürdüğünde, cache sunucusunda storage redundancy gereksizdir. İçerikleri zaten transit'te ve cloud kaynağında şifrelenmiş donanımda at-rest şifreleme gereksizdir. Yük varsayılan seçimin test edilmiş zarfının iyi içine düştüğünde, teorik benchmark'lar için daha az yaygın bir filesystem seçmek gereksizdir.

Kabul ettiğimiz trade-off: tek bir SSD'nin cluster üzerinde redundancy'si yoktur. O drive başarısız olursa, restore edene kadar cache gider. Mitigation'ımız düz — ayrı bir NAS'a gecelik rsync, SSD'nin SMART sayaçları üzerinde monitoring ve cache'i cloud storage'dan SLA penceresi içinde yeniden inşa eden belgelenmiş bir re-warm prosedürü. Mesele redundancy'nin kötü olduğu değil; mesele redundancy'nin varsayılan refleks olarak değil, articulable bir failure modunu düzelttiği yere ait olduğudur.

Aşırı mühendisliğin ayrıca operasyonel okunabilirlik maliyeti vardır. Her katman, sonraki operatörün debug için anlaması gereken bir katmandır. Tek bir SSD üzerinde tek bir ext4 filesystem, her Linux operatörünün ilk prensiplerden troubleshoot edebileceği bir şeydir. Deployment gözetimsiz çalışırken ve uzak bir operatör sabah 2'de onu recover etmek zorunda olduğunda, daha basit olan kazanır.

Ders 5: D-Day'den önce cache'i ön-ısıtın

Yaklaşan bir deadline parıltısı öncesinde ışıkla dolan bir rezervuar

render farm'lar, müşterinin ilk production gününe kadar görmesi kolay olan bir cold-start sorununu gizler. Birinci günde, yirmi render node ilk kez online olur ve ihtiyaç duydukları asset'leri çekmeye başlar. Cache boşsa, bu node'ların her biri aynı anda cloud storage'a vurur, aynı upstream bant genişliği için yarışır. Cloud-tarafı rate limit'ler devreye girer. Paylaşılan internet borusu doygunlaşır. Render kuyruğu takılır. Müşterinin cluster hakkındaki ilk izlenimi eski workstation'ından daha yavaş olduğudur.

Bu cold-pull sorunudur ve tamamen önlenebilir. Çözüm, cache'i müşterinin ilk planlanan render'ından yirmi dört-kırk sekiz saat önce ön-ısıtmaktır. Mekanik basittir: D-day'den önce müşteriyle birlikte çalışarak asset listesini alın — referans verilecek proje dosyaları, dokular, simulation cache'leri, plugin kütüphaneleri. Cluster üzerinde production yükü yokken hepsini cache sunucusuna çekin, böylece birinci günde render node'lar yerel LAN'da kendilerini bekleyen sıcak bir cache bulurlar.

Bir ön-ısıtma pass'i ayrıca smoke test olarak hizmet eder. Asset listesi resolve etmeyen bir path içeriyorsa, ilk render'ın paniği yerine ön-ısıtma penceresinin sakinliğinde keşfedersiniz. Müşterinin cloud hesabı ile çektiğiniz storage path arasında bir izin sorunu varsa, onu da keşfedersiniz. Asset listesi cache'e sığmayan bir hacme ulaşırsa, cache'i yeniden boyutlandırmak veya daha sıkı bir kapsam müzakere etmek için zamanınız vardır. Bu konuşmaların hiçbiri, render kuyruğu zaten submit edildiğinde ilk kez gerçekleşmemelidir.

İlgili bir uygulama: production batch'i girmeden önce küçük bir frame batch'i ile bir smoke-test render. Pipeline boyunca uçtan uca tam kalitede yirmi frame, sıfırıncı gün. Bir şey yanlış konfigüre edildiyse — eksik bir plugin lisans hakkı, yanlış bir output path, sanatçının workstation'ı ile cluster arasında bir OCIO drift'i — smoke test bunu yüzeye çıkarır. Yirmi frame, 2.000 frame'lik bir production batch'inin frame 800'ünde aynı sorunu bulmaya karşı ucuz bir sigortadır.

Genel ders: taze bir cluster üzerindeki ilk render her zaman steady state'ten daha yavaş ve hataya daha açıktır. Etrafından mühendislik yapın. Cluster'ı soğuk teslim etmeyin.

Ders 6: Dokümantasyon operasyonel bir araçtır, sonradan akla gelen bir düşünce değil

Altıncı ders bonus bir derstir, çünkü teknik bir pattern'den çok deployment'ın ekibin daha sonra destekleyebileceği bir şey haline gelmesi hakkındadır. Runbook'u deployment'tan sonra değil, deployment sırasında inşa etmeyi öğrendik.

Operate ettiğimiz her deployment gerçek zamanlı bir build log üretir: kronolojik sırada numaralı bir changelog, fiilen çalıştırılan komutlar, fiilen geri gelen output'lar ve operatörün belirli bir kararın neden alındığına dair yorumlarıyla. Bu log'u retrospektif olarak yazmıyoruz, çünkü detaylar o zaman çoktan gitmiştir. Çalışırken yazıyoruz ve onu çalışan altyapıya eşdeğer ağırlıkta bir deliverable olarak ele alıyoruz.

Build log'un iki kitlesi vardır. İlki cluster'a dokunacak bir sonraki operatördür — genellikle bir takım arkadaşı, bazen onu kuran operatörün gelecekteki versiyonu. İkincisi müşteri, build log'u temiz bir as-built referansa, kırılma durumunda kurtarma prosedürlerine ve ekibinin sahip olduğu ile bizim sahip olduğumuz arasındaki operasyonel sınırlara damıtan bir teslim belgesi formunda.

Deployment sırasında dokümantasyonun maliyeti deployment zamanının kabaca yüzde on beşidir. Dokümantasyon yapmamanın maliyeti, bir şeyin recover edilmesi gerektiğinde her seferinde bir destek döngüsü ve sistemi devralan herhangi bir takım arkadaşı için dik bir öğrenme eğrisidir. Build log her seferinde ilk ay içinde kendini amorti etmiştir.

Dürüst karşı-dersler: Yapmadığımız şeyler

Herhangi bir operasyonel raporda, final stack'i baştan beri açık seçim gibi tarif etme cazibesi vardır. Nadiren öyledir. İşte düşündüğümüz, denediğimiz veya bilinçli olarak deploy etmediğimiz bileşenler — zaten yürüttüğümüz deneyleri tekrar etmeye döngü harcamayın diye dahil edildi.

Remote desktop için RustDesk deploy etmedik. RustDesk genel ofis çalışması için kullanışlıdır, ancak streaming kalitesi ve renk doğruluğu 3D ve GPU rendering için gereken yerde değildi. Sanatçılar dokulu yüzeylerde sıkıştırma artefaktları ve viewport önizlemelerinde renk kaymaları fark etti. Bunun yerine NVIDIA NVENC hardware encoding kullanan ve yüksek frame rate yüksek fidelity streaming için tasarlanan Moonlight + Sunshine'a standardize olduk. Parsec makul bir fallback'tir; RustDesk bu yüke uygun değildir.

BBR sürüm 3 deploy etmedik. TCP BBR, uzun, jitter'a yatkın uluslararası hatları kernel default'undan daha iyi yöneten bir congestion control algoritmasıdır. Kullanıyoruz — ama BBR sürüm 1 kullanıyoruz, sürüm 3 değil. BBRv3 daha yeni, teorik olarak iyileştirilmiş ve bir müşterinin production deadline'ı önüne koyacağımız kernel olgunluğunda henüz değil. BBRv1 iyi anlaşılmıştır, modern Linux kernel'larında standart gelir ve işi yapar.

Edge router'ı NAS üzerinde VM olarak çalıştırmadık. Önceki bir plan, edge gateway'i cache'i barındıran aynı Network Attached Storage box üzerinde çalışan bir virtual machine üzerinde konsolide etmeyi düşündü. Gerçeklik, endişelerin ayrılığıdır: edge router ve cache aynı fiziksel makinede yaşadığında, NAS'ta bir kernel update gateway'i de düşürür. Kötü davranan bir disk gateway'i I/O'dan aç bırakabilir. Cache işi yapan ve başka bir şey yapmayan adanmış bir cache box operasyonel olarak daha temizdir.

AWS Global Accelerator veya Cloudflare Tunnel deploy etmedik. Her ikisi de makul opsiyonel bileşenlerdir ve her biri bazı müşteriler için latency'yi azaltır. Baseline için de gereksizdirler. BBR ve MSS clamping ile WireGuard tüneli uzun uluslararası hatları, marjinal iyileştirmenin operasyonel karmaşıklığı haklı çıkarmayacağı kadar iyi yönetir. Mimari dokümantasyonumuzda Global Accelerator ve Cloudflare Tunnel'ı faz iki opsiyonel bileşenleri olarak belirledik, ancak hiçbiri varsayılan ülkeler arası build'lerimizle gönderilmedi. Bir müşterinin latency gereksinimleri baseline'ın destekleyebileceğinden daha sıkı çıkarsa, yeniden ziyaret ederiz. O zamana kadar ihtiyacımız olmayanı deploy etmiyoruz.

Genel karşı-ders: dürüst bir deployment raporu gönderilmeyen şeyleri içermelidir. Aksi halde sonraki operatör final stack'in kaçınılmaz olduğunu varsayar ve zaten ödediğimiz deneyleri tekrar eder.

Sıkça sorulan sorular

Q: 20 node'luk adanmış ülkeler arası bir render farm cluster deploy etmek ne kadar sürer? A: Donanım tedariğinden müşteriye hazır cluster'a, tipik takvimimiz iki ila dört hafta arasında koşar. Donanım build ve OS imaging öngörülebilir kısımdır. Ağ konfigürasyonu — WireGuard, BBR, MSS clamping, DNS, NTP, firewall — birkaç gün ekler. Ön-ısıtma ve smoke testing bir-iki gün daha tüketir. Değişkenlik müşteri-tarafı önkoşullarından gelir: cloud hesap erişimi provisioning, asset listesi anlaşması ve sanatçı client setup hizalaması.

Q: Deploy gecikmesinin en yaygın nedeni nedir? A: Müşteri-tarafı kimlik bilgisi ve erişim provisioning. Altyapı işi takvime göre koşar. Darboğaz tipik olarak müşterinin cloud storage kimlik bilgilerini güvenlik politikasıyla uyumlu bir şekilde cluster'a almak ve sanatçı-tarafı client araçlarını (WireGuard, Moonlight) sanatçıların fiilen kullanacağı workstation'lara kurmaktır. O konuşmayı son haftada değil, birinci günde başlatmayı öğrendik.

Q: Bu dersleri kendi DIY render farm setup'ım için takip edebilir miyim? A: Evet. Buradaki dersler altyapı pattern'leridir, iş sırları değil. Dual-home routing tuzağı, DNS tuzağı, MSS clamping ve doğru boyutlandırma disiplini, on node ya da iki yüz, her cross-network deployment için geçerlidir. Altyapıyı kendiniz işletmek istemiyorsanız, fully managed render farm'ımız bunların hepsini paylaşılan altyapı üzerinde halleder ve adanmış cluster teklifimiz, yalnızca kendilerine ait donanım isteyen müşteriler için aynısını yapar.

Q: Hosted servisinizden ayrı olarak render farm altyapısı konusunda danışmanlık sunuyor musunuz? A: Danışmanlık saati satmak yerine altyapıyı kendimiz işletmeye odaklanıyoruz. Build ile rent arasında karar veren ekipler için, build versus cloud total cost rehberimiz ekonomiyi ortaya koyar ve ekip donanımımız üzerinde adanmış bir cluster değerlendiren prospektif müşterilerle mimari soruları konuşmaktan memnuniyet duyar.

Q: Mesafe açısından şimdiye kadar yaptığınız en uzun ülkeler arası render farm deployment hangisidir? A: Bugün işlettiğimiz deployment'lar kıtaları kapsar — sanatçılar Kuzey Amerika'dan çalışırken rendering donanımı Güneydoğu Asya'da koşar. Bağlantı ne kadar uzunsa, bu dersler o kadar önemlidir. Kısa LAN-only deployment'ları MSS clamping ve ön-ısıtmayı yok sayabilir. Kıtaları aşan deployment'lar yok sayamaz.

Q: Bu derslerin hâlâ geçerli olduğu en küçük cluster boyutu nedir? A: Bu pattern'lerin çoğu yirmincisinden değil, ilk node'dan itibaren geçerlidir. Dual-home routing tuzağı birden fazla arayüze sahip her gateway için geçerlidir. DNS artı WireGuard tuzağı internal isim çözümlemesi olan her tunneled overlay için geçerlidir. MSS clamping gereksinimi anlamlı uzunlukta bir tüneli aşan her TCP trafiği için geçerlidir. Cache ön-ısıtma, node sayısı büyüdükçe daha da önem kazanır, çünkü cold-pull bant genişliği rekabeti aynı anda cloud'a vuran node sayısıyla ölçeklenir.