Mã hoá WireGuard · Kiểm soát tắc nghẽn BBR · Cache dùng chung · Dành cho đội ngũ sáng tạo phân tán toàn cầu.
Công việc sáng tạo hiện đại ngày càng phân tán. Một pipeline 3D có thể có một art director ở New York, một đội lighting ở Berlin, các artist look-dev freelance ở Seoul, và một render farm ở một châu lục khác nữa. Khi cả bốn cùng nằm trên một LAN gigabit, việc truy cập render farm không thành vấn đề. Khi không như vậy, workflow chạy qua internet công cộng, và mọi đặc tính của định tuyến đường dài bắt đầu lộ ra trong lịch trình.
Ba vấn đề lặp lại trong loại cấu hình này. Thứ nhất là độ trễ — thời gian round-trip 150 đến 250 ms giữa các châu lục làm thay đổi cảm giác của remote desktop và khuếch đại mọi sự rườm rà trong render manager hay giao thức streaming asset. Thứ hai là jitter — các đường truyền quốc tế thường chạy sát giới hạn và timing gói tin thay đổi. Thứ ba là chi phí và tranh chấp băng thông — kéo một scene 40 GB qua đường liên lục địa một lần là chấp nhận được; kéo hai mươi lần vì mỗi node render có cache riêng thì không.
Một render farm cục bộ né được phần lớn điều này. Các đội đã có cluster trong cùng vùng datacenter với artist của họ không cần phần lớn nội dung trang này mô tả. Render cross-country trở thành lựa chọn kiến trúc đúng khi một trong những điều sau là đúng:
Khi một trong số đó đúng, câu hỏi trở thành vấn đề vận hành: làm sao để một render farm ở phía bên kia thế giới hành xử như một phần của mạng local của artist. Phần còn lại của trang này mô tả cách chúng tôi tiếp cận vấn đề tại Super Renders Farm.
Chúng tôi tối ưu các liên kết cross-country bằng bốn thành phần, áp dụng cùng nhau thay vì lần lượt.
Mọi kết nối từ endpoint của khách hàng tới render farm đều đi qua WireGuard. Máy của khách hàng trở thành một peer WireGuard; main datacenter vận hành một hub. Mã hoá là tự động và end-to-end; khách hàng không thấy traffic rõ trên internet công cộng, và chúng tôi cũng vậy. WireGuard cũng đủ nhẹ để không trở thành nút cổ chai trên đường dài — overhead nhỏ hơn rõ rệt so với một stack IPsec truyền thống.
Thuật toán kiểm soát tắc nghẽn mặc định của Linux kernel (CUBIC) tỏ ra dè dặt khi gặp jitter và mất gói — nó hiểu mất gói là tín hiệu để giảm tốc, ngay cả khi mất gói đến từ định tuyến quốc tế chập chờn chứ không phải tắc nghẽn thật. BBR (Bottleneck Bandwidth and RTT) đo tích bandwidth × delay thực của đường truyền và giữ ống đầy bao lâu còn dung lượng. Trên một tuyến liên lục địa ổn định, BBR thường mang lại gấp hai đến ba lần throughput của CUBIC với cùng phần cứng. Trên tuyến nhiều jitter, khoảng cách còn lớn hơn.
Khi một gói đi qua một tunnel như WireGuard, MTU hữu hiệu nhỏ hơn so với interface bên dưới. Nếu một kết nối TCP thương lượng MSS lớn hơn mức tunnel có thể tải, hai chuyện xảy ra: gói nhỏ đi qua được, gói lớn bị drop âm thầm. Triệu chứng thuộc loại bực bội nhất trong làm việc từ xa — SSH chạy, ping chạy, nhưng handshake TLS, phiên RDP và copy file SMB có kích thước đáng kể đều treo. Chúng tôi clamp MSS tại gateway WireGuard để mọi kết nối TCP thương lượng kích thước segment mà tunnel có thể chuyển thật.
Bên trong farm, chúng tôi chạy `dnsmasq` cho phân giải DNS nội bộ và `chrony` cho đồng bộ thời gian. Cả hai là những mảnh hạ tầng yên lặng nhưng quan trọng hơn vẻ ngoài. DNS nội bộ cho phép các node render tham chiếu cache dùng chung bằng `cache.lan` thay vì địa chỉ IP, làm cho topology an toàn để sắp xếp lại. Đồng bộ thời gian quan trọng vì hầu hết render manager và pipeline log không chịu được lệch giờ — một node lệch 30 giây so với phần còn lại của parc có thể tạo hành vi gán job khó hiểu. Cả hai dịch vụ chỉ lắng nghe trên mạng nội bộ; không gì từ internet công cộng nói chuyện trực tiếp với chúng.
Cùng nhau, bốn thành phần này khiến một render farm đường dài cảm thấy ít giống một máy ở xa và giống hơn một phần mở rộng LAN chậm của workstation artist. Không thành phần nào kỳ lạ; giá trị nằm ở chỗ áp dụng chúng như một stack và tinh chỉnh tham số cho các tuyến mà traffic của khách hàng thực sự đi qua.
Hình thức triển khai chúng tôi dùng cho cấu hình cross-country là topology hub-and-spoke, với một datacenter chính làm hub và một hoặc nhiều site phụ kết nối qua WireGuard site-to-site.
Vài quyết định trong topology này đáng nhắc vì lặp lại ở mỗi lần triển khai.
Edge và cache chạy trên một box, không phải ba. Cùng một máy Ubuntu kết thúc WireGuard từ bên ngoài cũng host cache Samba, DNS nội bộ và dịch vụ thời gian. Chúng tôi không tách các vai trò này ra nhiều máy trừ khi có lý do cụ thể. Right-sizing là chủ ý. Một box cache dedicated duy nhất có một đường mạng vào và một đường ra, làm cho phép tính định tuyến đơn giản. Nó cũng làm các chế độ lỗi dễ suy luận — nếu cache đang chạy, các dịch vụ nội bộ đang chạy; nếu không, không có gì nội bộ chạy được, và tín hiệu duy nhất đó dễ cảnh báo hơn ba tín hiệu tách biệt.
WireGuard site-to-site lo cho vị trí phụ. Khi triển khai trải trên hai vị trí vật lý — ví dụ, một datacenter chính cộng một site thuê nhỏ hơn cùng metro — hai bên kết nối bằng một tunnel WireGuard site-to-site qua ISP công. Traffic giữa chúng, theo góc nhìn của host, trông như một subnet lớn. Nhóm render B ở site phụ đọc cache ở Main DC theo cùng cách nhóm A đọc, chỉ là qua nhiều hop hơn.
Mạng định tuyến được ở Layer-3. Mỗi node là một host IP thực mà các node khác có thể đánh địa chỉ trực tiếp. Chúng tôi không bắt buộc một render manager nào. Đội ưa Deadline có thể chạy repository Deadline riêng trên một node coordinator phía khách hàng; đội ưa cái khác có thể dùng cái đó. Farm cung cấp host, network, cache và stack tối ưu; lớp orchestration phía trên là lựa chọn của khách hàng.
Để đi sâu hơn, hướng dẫn triển khai vận hành bao quát toàn bộ quy trình theo từng bước, và phân tích kiến trúc chi tiết đi sâu hơn vào thiết kế WireGuard và cache.
Băng thông liên lục địa đắt theo hai nghĩa: tốn tiền trên hoá đơn egress cloud, và tốn thời gian khi artist chờ một asset xuống đường ống. Một parc render không nghĩ đến điều này có thể tiêu một phần đáng kể wall-time của mỗi job để kéo lạnh các file scene đã có sẵn trong cache ở đâu đó khác trong toà nhà.
Pattern cache dùng chung là đòn bẩy đơn giản nhất và lớn nhất. Một server cache Samba (SMB3) ở main datacenter giữ asset dự án. Mỗi node render mount cache và đọc file scene qua LAN. Khi một asset mới được job tham chiếu, cache kéo nó từ cloud storage của khách hàng đúng một lần. Mỗi node tiếp theo cần đến nó sẽ đọc từ bản LAN. Một parc 20 node lẽ ra kéo file scene 40 GB hai mươi lần thì chỉ kéo một lần.
Về nguyên tắc, điều này thẳng thắn. Trong thực tế, hai phần thiết kế quan trọng.
Tránh cache theo từng node. Cám dỗ là cho mỗi node render một SSD local lớn và để nó cache bất cứ gì nó muốn. Với một parc 20 node có 10 TB dữ liệu dự án, điều đó trở thành 200 TB lưu trữ trùng lặp mà không có logic invalidation chung. Chúng tôi không làm vậy. Cache dùng chung là cache duy nhất; các node coi đĩa local là không gian scratch, không phải kho lưu dự án.
Làm ấm cache trước ngày D. Khi khách hàng thông báo dự án bắt đầu vào thứ Hai, chúng tôi làm ấm cache trong cuối tuần. Job đầu tiên ngày thứ Hai đọc từ cache đã ấm thay vì kích hoạt hai mươi tiếng kéo lạnh. Đây là phương pháp đáng tin cậy nhất để khiến lần render đầu của một dự án cảm thấy nhanh.
Một ghi chú về right-sizing: box cache dùng một SSD SATA duy nhất với hệ thống file ext4. Đối với cache (khác với storage chính), một bố cục đĩa đơn là sự đánh đổi đúng. Cache không phải nguồn sự thật — nguồn sự thật là cloud storage của khách hàng — và cache có thể xây lại bằng cách kéo lại từ cloud hoặc rsync từ một bản backup dự án. Xây một mảng dự phòng trên một volume mã hoá sẽ thêm chi phí và độ phức tạp mà không thay đổi câu chuyện vận hành; một node mất cache là việc xây lại trong một buổi tối, không phải sự kiện mất dữ liệu. Định kích thước phần cứng cache phù hợp vai trò của nó là một trong những cách dễ nhất để giữ chi phí vận hành có thể dự đoán.
Với các đội đang cân nhắc một cluster lâu dài thay vì một triển khai cross-country đơn lẻ, trang dedicated cluster options bao quát cấu hình đó chi tiết hơn.
Cross-country render farm không phải lựa chọn tốt hơn một cách phổ quát. Nó có ý nghĩa cho một loại workflow cụ thể và có những đánh đổi dự đoán được so với một farm cục bộ.
Với artist cần điều khiển một node GPU theo cách tương tác — ví dụ, mở một scene Cinema 4D với Redshift, làm preview IPR, hoặc framing render trước khi submit job đầy đủ — chúng tôi dùng Moonlight làm client và Sunshine làm host. Cả hai dùng encode phần cứng NVENC trên GPU của node render, tạo ra stream mượt rõ rệt hơn so với các giao thức remote desktop encode bằng phần mềm. Video đã encode chạy qua một đường dài đã được tinh chỉnh mang lại trải nghiệm dùng được cho công việc thực, bao gồm tương tác viewport chi tiết cao; cùng workload chạy qua RDP thường thì không. Parsec được cấu hình làm dự phòng cho các trường hợp hiếm khi Sunshine không thương lượng được phiên.
Một đường liên lục địa được tinh chỉnh tốt thường nằm ở mức 150 đến 250 ms round-trip. Con số phụ thuộc vào khoảng cách địa lý và tuyến mà traffic của khách hàng thực sự đi qua. Chúng tôi không công bố độ trễ cụ thể theo cặp thành phố trên trang này vì nó không tổng quát hoá được — ISP của bạn, peering của bạn và các hop local của bạn chi phối trải nghiệm nhiều ngang bất kỳ con số nào chúng tôi có thể nêu. Chúng tôi có thể chạy một probe từ một endpoint ứng viên trong giai đoạn lập kế hoạch và chia sẻ các đo đạc thực cho tuyến mà đội bạn sẽ dùng.
Các triển khai cross-country của chúng tôi đã chạy ở quy mô cluster 20 node với GPU consumer thế hệ hiện hành (phần cứng lớp RTX 5090), với storage dự án trên nền tảng cloud của chính khách hàng. Đó là quy mô mà những lựa chọn kiến trúc ở các phần trước bắt đầu trở nên quan trọng — ở parc nhỏ hơn, một setup ít được tối ưu hơn vẫn có thể tạm được.
Render cross-country phù hợp khi artist phân tán và parc render phải nằm đâu đó, khi dữ liệu dự án đã nằm sẵn ở một vùng cloud cụ thể, khi khách hàng cần hạ tầng cô lập theo IP mà các lựa chọn local không cung cấp được, hoặc khi khả năng có sẵn hoặc chi phí GPU ưu ái một vùng cụ thể.
Nếu mọi người trong đội làm việc từ cùng văn phòng hoặc cùng quốc gia với parc render, các tối ưu trên trang này phần lớn là overhead không cần thiết. Một farm cục bộ với đường ống ngắn hơn và định tuyến đơn giản hơn sẽ dễ vận hành hơn và không hưởng lợi từ BBR hay clamping MSS theo cùng cách. Đối vị trí thành thật quan trọng: không phải mọi đội cần kiến trúc này. Với workload mà artist và phần cứng render có thể ngồi cùng vùng, trang chuẩn render farm rental options bao quát tình huống tốt.
Nói theo cách tổng quát, các đường dài được tinh chỉnh tốt nằm ở khoảng 150 đến 250 mili-giây round-trip, với con số chính xác phụ thuộc vào ISP của artist, tuyến mà traffic đi qua và vị trí địa lý của endpoint. Chúng tôi có thể chạy một probe từ một workstation ứng viên trong giai đoạn lập kế hoạch và chia sẻ những con số đo được thực tế cho tuyến của bạn.
Kiểm soát tắc nghẽn BBR là biện pháp chính — nó giữ throughput ổn định khi đường có jitter, thay vì sụp đổ khi mất gói như CUBIC mặc định. Bản thân WireGuard cũng dễ chịu với các gián đoạn mạng ngắn vì nó không duy trì trạng thái phiên như một tunnel IPsec. Với sự cố ở mức ISP, tunnel tự kết nối lại ngay khi tuyến upstream quay lại; các job render đang chạy tiếp tục ở phía farm bất kể trạng thái kết nối của artist.
Có. Mọi liên kết đều được mã hoá WireGuard: từ endpoint artist tới main datacenter, và site-to-site giữa Main DC và bất kỳ site phụ nào. Không có điểm nào trên internet công cộng mà một quan sát viên có thể đọc được traffic rõ giữa đội bạn và parc render. Chúng tôi không yêu cầu sự tin tưởng vào bất kỳ transport trung gian nào; mã hoá nằm ở lớp WireGuard, không phải gắn thêm như tuỳ chọn lên trên.
Có. Hub WireGuard chấp nhận nhiều peer, nên bao nhiêu artist từ bao nhiêu vị trí cũng có thể kết nối vào cùng farm cùng lúc. Mỗi artist chạy client WireGuard trên workstation, mở Moonlight, và kết nối tới node render đã được gán. Các dịch vụ nội bộ như cache và DNS được dùng chung trên parc, nên hai artist làm việc trên cùng scene từ hai châu lục khác nhau thấy cùng tập asset.
Qua cache SMB dùng chung. Khi một job render tham chiếu một asset mà cache chưa thấy, cache kéo nó từ cloud storage của khách hàng đúng một lần. Các node tiếp theo cần asset đó đọc từ cache qua LAN ở tốc độ đường truyền, không qua đường liên lục địa. Với dự án có ngày bắt đầu dự đoán được, chúng tôi làm ấm cache trước ngày D để lần render đầu của dự án hưởng lợi từ cache ấm thay vì kích hoạt thác kéo lạnh.
Vẫn hoạt động theo cách giống nhau; khoảng cách địa lý chỉ có nghĩa là lần kéo đầu tiên vào cache mất nhiều thời gian hơn so với storage cùng vùng. Một khi asset đã ở trong cache, khoảng cách địa lý không còn quan trọng — các node render đọc qua LAN. Trong kịch bản này chúng tôi thường làm ấm cache để pull cross-region xảy ra ở phía chúng tôi trước khi dự án bắt đầu, chứ không trong lần render đầu.
Data residency phụ thuộc vào nơi parc render được provisioning, điều mà chúng tôi lên kế hoạch cùng khách hàng từ trước. Với các đội có yêu cầu residency cụ thể, cuộc trao đổi cần bao quát nơi dữ liệu dự án được giữ, nơi render được tạo, nơi log được lưu, và cách dữ liệu được xoá khi kết thúc engagement. Đây là một cuộc trao đổi lập kế hoạch chứ không phải một câu trả lời có-hoặc-không đơn giản; vui lòng liên hệ chúng tôi để trao đổi chi tiết tình huống của bạn.
Bản thân render vẫn tiếp tục. Các job render chạy ở phía farm bất kể trạng thái tunnel của artist — một khi job đã được phân phối, artist có thể ngắt kết nối hoàn toàn và các frame vẫn tiếp tục được tạo. Khi tunnel quay lại, artist thiết lập lại peer WireGuard và kết nối lại qua Moonlight vào cùng phiên. Hệ quả thực tế phổ biến nhất của một tunnel rớt giữa lúc render là artist không thể theo dõi tiến độ trực tiếp trong khoảng thời gian gián đoạn; render không khởi động lại.
