Understanding Data Center Fabrics - Part 3: Characteristics Of Data Center Fabrics
Mục lục
- 1. Non-blocking vs Non-contending
- 2. Cách scale một spine-leaf fabric: Scale Out
- 3. Ba đặc điểm nhận dạng một fabric: non-planar, replicating, regular
- 4. Benes fabric
- 5. Folded fabric và vì sao nó trở thành non-contending
- 6. Các cách vẽ sơ đồ: spine-in-center, top-of-spine, fat tree
- 7. Universal topology: fat tree có thể giả lập mọi topology khác
- 8. Butterfly topology
1. Non-blocking vs Non-contending
Hai khái niệm này rất hay bị nhầm lẫn hoặc dùng thay thế cho nhau, nhưng thực chất là hai thứ hoàn toàn khác biệt.
Non-blocking: xét một Clos fabric nguyên bản (dùng crossbar, giống mạng điện thoại) với các thiết bị dev1-dev4 có logical send side và receive side tách biệt. Khi device 1 tạo circuit tới device 4, circuit đó chiếm trọn send side của dev1 và receive side của dev4 — nghĩa là tại một thời điểm, một thiết bị chỉ có thể nói chuyện với đúng một thiết bị khác. Mạng được gọi là non-blocking vì: nếu device 2 muốn nói chuyện với device 3 trong khi dev1-dev4 đang bận, luôn tồn tại một đường đi thay thế — bất kỳ cặp thiết bị nào cũng có thể nói chuyện với nhau miễn là không có hai input device cùng cố gắng nói chuyện với cùng một output device tại cùng một thời điểm.
Trong một mạng non-blocking thật sự, có cơ chế gọi là admission control — kiểm soát ai được phép "make circuit" và khi nào. Đặc điểm cốt lõi của non-blocking: fabric không bao giờ drop traffic, và điều này chỉ khả thi nhờ admission control hiệu quả kết hợp với một bộ scheduler nào đó.
💡 Hình dung như thế này: non-blocking giống một khách sạn chỉ nhận đặt phòng đúng bằng số phòng thực có — không bao giờ overbook, ai đặt cũng chắc chắn có phòng. Non-contending giống một khách sạn nhận đặt phòng thoải mái, đặt cược rằng không phải khách nào cũng nhận phòng đúng ngày — bình thường thì ổn, nhưng vào đúng cao điểm khi tất cả cùng nhận phòng một lúc, sẽ có người bị từ chối dù đã đặt trước.
Khái niệm non-contending sẽ được nói ở phần sau, khi chuyển sang mạng packet switch. Điểm khác biệt cốt lõi giữa hai khái niệm nằm ở chỗ nào trong luồng xử lý mà request bị từ chối: non-blocking từ chối request trước khi nó được nhận vào mạng (tại cổng admission control), còn non-contending nhận mọi request vào mạng rồi mới có thể drop nó giữa đường nếu xảy ra tranh chấp (contention) tại một liên kết. Diagram dưới đây so sánh trực quan hai cơ chế này.
Vì sao packet-switched network không thể "non-blocking" theo đúng nghĩa gốc?
Non-blocking là khái niệm sinh ra từ mạng chuyển mạch kênh (circuit-switched) thời tổng đài điện thoại: mỗi cuộc gọi chiếm trọn một circuit cố định (một khe thời gian hoặc một đường dây vật lý) xuyên suốt thời gian gọi, và vì tổng đài biết trước chính xác mỗi cuộc gọi cần bao nhiêu tài nguyên, nó có thể tính toán trước — bằng một thuật toán ghép cặp kiểu bipartite matching — xem có tồn tại đường rảnh cho tổ hợp cuộc gọi mới hay không, trước khi cho phép cuộc gọi bắt đầu. Đó chính là "admission control" nói ở trên: từ chối ngay tại cổng vào (busy tone) chứ không bao giờ nhận cuộc gọi vào mạng rồi giữa chừng cắt ngang.
Ethernet fabric hiện đại vận hành hoàn toàn khác. Switch không biết trước một flow sẽ tồn tại bao lâu hay cần bao nhiêu băng thông, và cũng không có bước "xin phép trước khi gửi" — packet đến là được forward ngay theo bảng định tuyến, bất kể link đích có đang bận hay không. Muốn một mạng Ethernet có tính non-blocking đúng nghĩa, phải xây thêm hẳn một lớp reservation/admission control ở trên (ví dụ traffic engineering kiểu RSVP trong MPLS-TE) — đây không phải cách vận hành mặc định của một fabric spine-leaf thông thường. Đó là lý do gần như mọi spine-leaf fabric hiện nay không thực sự "non-blocking" mà chỉ dừng ở mức "non-contending" với một tỷ lệ chấp nhận rủi ro drop nhất định.
2. Cách scale một spine-leaf fabric: Scale Out
Trong kiến trúc spine-leaf, cách chuẩn để tăng số port ở biên (edge port) là scale out: thêm nhiều thiết bị hơn ở lớp leaf, trong khi kích thước (số port) của từng thiết bị giữ nguyên không đổi — ví dụ đi từ 3 cột thiết bị lên 4 cột. Đây là điểm khác biệt so với cách scale up truyền thống, nơi người ta tăng kích thước của chính thiết bị (thêm line card, thêm port) thay vì thêm thiết bị mới.
Vì sao scale out lại là lựa chọn mặc định cho fabric?
Lý do đầu tiên nằm ở giới hạn vật lý của chip chuyển mạch (switching ASIC): mỗi thế hệ ASIC có một con số port cố định gọi là radix, không thể "hàn thêm" port vào một con chip đã sản xuất xong. Muốn có nhiều port hơn tổng thể mà không đổi sang ASIC khác, cách duy nhất là thêm thiết bị mới (scale out) thay vì cố mở rộng thiết bị hiện có (scale up).
Lý do thứ hai nằm ở chính tính chất replicating của fabric (xem mục 3 bên dưới): vì mọi leaf trong cùng một stage đều là bản sao chính xác của nhau về cách đấu nối, thêm một leaf mới không đòi hỏi tính toán lại hay đấu nối lại các leaf đang chạy — chỉ đơn giản lặp lại đúng khuôn mẫu sẵn có (leaf mới cắm đúng 1 uplink lên mỗi spine, theo đúng thứ tự các leaf cũ đã làm). Đây là điều gần như không thể có ở kiến trúc scale-up bằng chassis, nơi thêm dung lượng nghĩa là cắm thêm line card vào một thiết bị đang chạy — có rủi ro downtime, bị giới hạn bởi số khe card còn trống, và đôi khi phải nâng cấp cả supervisor/fabric module trung tâm.
Lý do thứ ba là blast radius: mất một leaf switch trong kiến trúc scale-out chỉ mất đúng capacity của leaf đó — một phần rất nhỏ trên tổng số leaf toàn fabric. Mất một chassis lớn trong kiến trúc scale-up có thể mất hàng chục port cùng lúc, vì toàn bộ line card bên trong chia sẻ chung fabric nội bộ, nguồn điện, và processor điều khiển.
💡 Hình dung như thế này: scale-out giống việc mở rộng bãi đỗ xe bằng cách kẻ thêm ô đỗ giống hệt các ô đã có — ô nào hỏng chỉ mất đúng một chỗ đỗ, muốn thêm chỗ cứ kẻ thêm theo đúng khuôn mẫu cũ. Scale-up giống việc xây một bãi đỗ xe nhiều tầng duy nhất — muốn thêm chỗ phải xây thêm tầng vào đúng cái khung nhà đó, và nếu cái khung chịu lực đó gặp sự cố, toàn bộ các tầng phía trên đều bị ảnh hưởng theo.
3. Ba đặc điểm nhận dạng một fabric: non-planar, replicating, regular
Để xác định một topology có thực sự là "fabric" hay không, cần nhìn vào ba đặc điểm:
-
Non-planar: các liên kết trong sơ đồ có điểm giao cắt (cross point) mà không thực sự kết nối với nhau — giống cách vẽ hai dây dẫn trên board mạch điện tử cắt qua nhau nhưng không chạm, thể hiện bằng một "hop nhỏ" ở điểm giao. Nếu tưởng tượng xoay hình này theo chiều dọc, điểm "hop" đó tương ứng với một mặt phẳng (plane) thứ hai — đây cũng chính là nguồn gốc khái niệm mạch nhiều lớp (multi-planar circuit board), nơi hai đường mạch nằm trên hai lớp khác nhau, muốn nối với nhau phải khoan lỗ xuyên lớp (via) rồi hàn dây/thiếc vào. Cấu trúc Clos hay bất kỳ spine-leaf nào đều bắt buộc có các điểm giao cắt kiểu này nên được gọi là non-planar topology.
💡 Hình dung như thế này: non-planar giống một nút giao thông kiểu cầu vượt — nhìn trên bản đồ hai làn đường cắt ngang nhau, nhưng thực tế xe không va chạm vì một làn chạy trên cầu, một làn chạy dưới gầm cầu. "Hop nhỏ" trong sơ đồ mạch điện chính là kiểu cầu vượt đó: hai đường dây trông như giao nhau nhưng thực chất không hề chạm.
Ví dụ thực tế: trong một sơ đồ spine-leaf vẽ trên giấy, đường cáp từ leaf1 lên spine2 rất hay được vẽ băng qua đường cáp từ leaf2 lên spine1 — trên hình chúng cắt nhau tại một điểm, nhưng đó chỉ là giới hạn của việc vẽ trên mặt phẳng 2D, ngoài đời hai sợi cáp quang này không hề nối vào nhau. Đó chính là "cross point" nói ở trên.
Tính không-phẳng này không phải là đặc điểm ngẫu nhiên mà là hệ quả bắt buộc về mặt toán học. Trong lý thuyết đồ thị, kết nối leaf-spine của một fabric chính là một đồ thị hai phía (bipartite graph): một phía là các leaf, phía kia là các spine, mọi leaf đều nối tới mọi spine. Theo định lý Kuratowski, một đồ thị chỉ vẽ được trên mặt phẳng mà không có cạnh nào cắt nhau khi nó không chứa (dưới dạng subdivision) đồ thị đầy đủ K5 hoặc đồ thị hai phía đầy đủ K3,3. Ngay khi một fabric có từ 3 leaf và 3 spine trở lên — tức đúng cấu hình K3,3 hoặc lớn hơn — nó buộc phải là non-planar, không có cách vẽ nào trên giấy tránh được điểm giao cắt. Đây là lý do vì sao mọi sơ đồ spine-leaf có kích thước thực tế (vài chục leaf, vài spine trở lên) đều phải chấp nhận các đường cáp "hop qua nhau" khi vẽ.
-
Replicating: mỗi nhóm thiết bị trong cùng một stage/khu vực của fabric có đúng cùng một tập kết nối như nhau — ví dụ các leaf trong cùng một stage là bản sao chính xác của nhau, các router trong cùng stage khác cũng vậy. Đây gọi là dạng micro-modularization (mô-đun hóa vi mô) — mỗi phần của fabric có thể được nhân bản (replicate) theo cùng khuôn mẫu. Ví dụ cụ thể: trong một fabric 4-spine, mọi leaf switch đều cắm đúng 1 uplink lên mỗi spine theo cùng thứ tự — nhìn cấu hình interface của leaf1 và leaf2, phần khai báo uplink gần như giống hệt nhau, chỉ khác IP/hostname. Nhờ vậy, thêm một leaf mới chỉ là lặp lại đúng khuôn mẫu cấu hình có sẵn, không cần thiết kế lại từ đầu.
-
Regular: về bản chất là hệ quả của tính replicating — cấu trúc trông giống hệt nhau ở mọi vị trí tương ứng, mọi thứ được chia đều và bố trí theo quy luật. Ví dụ: nếu vẽ fabric ra và che hết nhãn tên thiết bị, người xem không thể phân biệt được đây là leaf thứ 3 hay leaf thứ 30 — vì tại vị trí nào trong sơ đồ, số lượng uplink, số lượng downlink, và cách đấu nối đều tuân theo đúng một quy luật lặp lại.
Vì sao ba đặc điểm này lại quan trọng khi thiết kế fabric thực tế?
Ba đặc điểm non-planar, replicating, regular không chỉ là mô tả hình học suông — chúng là điều kiện cần để một fabric có thể tự động hóa được. Vì replicating và regular đảm bảo mọi leaf (hoặc mọi spine) trong cùng stage đều giống hệt nhau về logic đấu nối, toàn bộ cấu hình có thể sinh ra từ một template duy nhất (Infrastructure-as-Code, zero-touch provisioning) thay vì phải viết tay cấu hình riêng cho từng thiết bị. Đây cũng là lý do các công cụ tự động hóa fabric hiện đại (Ansible, hoặc các nền tảng intent-based networking) đều giả định trước cấu trúc fabric tuân theo đúng ba tính chất này — nếu một topology phá vỡ tính replicating (ví dụ một vài leaf có số uplink khác các leaf còn lại vì lý do lịch sử), việc tự động hóa cấu hình sẽ phức tạp hơn hẳn.
4. Benes fabric
Benes fabric do Václav E. Beneš mô tả qua công trình công bố năm 1964-1965 (có thể tìm đọc bài báo gốc — xem ghi chú fact-check ở cuối bài). Mục tiêu của Beneš là tìm ra một rearrangeable Clos fabric — lấy ý tưởng Clos fabric và làm cho nó có thể sắp xếp lại (rearrange) để giải các bài toán khác nhau.
Benes fabric chia sẻ nhiều đặc điểm kỹ thuật với Clos fabric: nó cũng là một fabric, cũng non-planar (có điểm giao cắt), cũng replicating (micro-modular). Điểm khác biệt: Clos fabric luôn có đúng ba tầng (stage), trong khi Benes fabric hầu như luôn có năm tầng. Ở dạng nguyên bản dùng crossbar trong mạng điện thoại, Benes fabric cũng là non-blocking vì nó vẫn là unidirectional (một chiều).
Khi chuyển Benes fabric sang packet switching: đặt các Clos fabric ở trung tâm, các leaf node ở phía ngoài. Khi thay các crossbar fabric bằng switch (packet switch), cấu trúc này trở thành folded fabric.
Cách dễ nhất để hình dung 5 tầng của Beneš là ghép hai nửa Clos 3-tầng lại với nhau, dùng chung tầng giữa: Leaf (in) → Spine 1 → Mid-Spine → Spine 2 → Leaf (out). Ba tầng ở giữa (Spine 1, Mid-Spine, Spine 2) tự nó đã hoạt động như một Clos fabric 3-tầng thu nhỏ — đó là lý do Beneš được gọi là "rearrangeable Clos": nó lấy đúng cấu trúc Clos rồi nối thêm một tầng leaf ở mỗi đầu.
"Rearrangeable" nghĩa là gì, và vì sao nó dẫn tới 5 tầng thay vì 3?
Lý thuyết chuyển mạch phân biệt rõ hai mức độ "không nghẽn" cho một Clos fabric 3-tầng. Fabric là strict-sense non-blocking khi số thiết bị tầng giữa m thỏa m ≥ 2n − 1 (n là số port input trên mỗi thiết bị tầng biên) — với độ dư thừa này, bất kỳ kết nối mới nào cũng luôn tìm được ngay một đường rảnh, không bao giờ cần đụng tới các kết nối đang chạy. Fabric chỉ rearrangeably non-blocking khi m ≥ n — ít thiết bị tầng giữa hơn hẳn (gần một nửa), nhưng đổi lại: để nhét vừa một kết nối mới, đôi khi một bộ điều khiển trung tâm phải tính toán lại và di chuyển (rearrange) đường đi của một số kết nối đang chạy sang thiết bị tầng giữa khác, dù bản thân các kết nối đó không đổi input/output.
Beneš network chính là trường hợp cực hạn của hướng "rearrangeable" này: thay vì dùng m = n thiết bị tầng giữa kích thước lớn, người ta thay tầng giữa đó bằng chính một mạng con nhỏ hơn có cấu trúc y hệt (đệ quy) — và tầng giữa nhỏ nhất có thể dùng là các crossbar 2×2. Khi áp dụng đệ quy này một lần cho một Clos 3-tầng, tầng giữa (vốn chỉ là 1 tầng) được thay bằng cả một Clos 3-tầng con — cộng với 2 tầng leaf ở ngoài cùng đã có sẵn, tổng cộng thành 5 tầng: Leaf (in) → Spine 1 → Mid-Spine → Spine 2 → Leaf (out). Đây là lý do Beneš được gọi là "rearrangeable Clos": đổi bớt số thiết bị tầng giữa (theo chiều rộng) lấy thêm số tầng (theo chiều sâu), cùng với một bộ điều khiển trung tâm phải chạy thuật toán ghép cặp (matching) mỗi khi có kết nối mới. Trong mạng điện thoại nguyên bản, đánh đổi này hợp lý vì phần cứng crossbar đắt đỏ còn việc tính toán lại vài mili-giây là chấp nhận được; khi mô hình này được mượn sang thiết kế fabric packet-switching hiện đại, phần "rearrange theo mỗi cuộc gọi" không còn cần thiết theo đúng nghĩa circuit-switching nữa (packet switch không giữ circuit cố định, mỗi gói tự tìm đường qua ECMP), nhưng cấu trúc nhiều tầng dùng thiết bị port-count thấp vẫn được giữ lại vì nó cho phép scale fabric lớn hơn nhiều so với chỉ dùng 3 tầng.
5. Folded fabric và vì sao nó trở thành non-contending
Từ "folded" khi nói về spine-leaf network có thể mang hai nghĩa khác nhau, cần phân biệt rõ:
- Nghĩa thứ nhất: traffic có thể di chuyển bi-directional trên liên kết — không còn khái niệm "make/break circuit", mỗi thiết bị đơn giản gửi và nhận traffic tùy ý.
Khi fold một spine-leaf fabric theo nghĩa này, fabric không còn là non-blocking nữa — lý do là không còn admission control để ép các cạnh (edge) chỉ gửi đúng lượng traffic mà mạng có thể gánh mà không drop bất kỳ gói nào. Một khi tồn tại xác suất thống kê rằng mạng có thể drop traffic, fabric trở thành non-contending (khái niệm này chỉ áp dụng cho một số kiểu/dạng fabric nhất định — hầu hết các spine-leaf fabric có xu hướng non-contending; ở mức tỷ lệ over-subscription đủ cao, tính chất non-contending có thể mất đi).
Ví dụ minh họa: một router muốn gửi traffic tới đích, nó có thể rải traffic (scatter) qua nhiều đường trong mạng — đây chính là equal cost multi-path (ECMP), hay wide fan-out multi-path. Cái giá phải trả: nếu hai nguồn A và C cùng gửi full-bandwidth traffic stream qua hai liên kết khác nhau nhưng cùng hướng tới đích B, thì tại điểm hội tụ ở B, tổng lưu lượng đến sẽ vượt quá khả năng của một liên kết ra — giả sử các liên kết cùng tốc độ, khoảng 50% traffic sẽ bị drop. Đây chính là lý do fabric trở thành non-contending: một khi đã fold để truyền traffic bi-directional, hoàn toàn có thể "tràn" (overrun) một Benes hay spine-leaf fabric theo cách khiến mạng tự drop traffic.
Cơ chế ECMP hoạt động ra sao, và vì sao nó chỉ "rải đều" chứ không "đảm bảo"?
ECMP không hề biết trước tương lai — mỗi switch chỉ quyết định đường ra cho một gói tin dựa trên một phép băm (hash) trên một số trường cố định của gói (thường là địa chỉ IP nguồn/đích, port nguồn/đích, giao thức — gọi là 5-tuple), rồi ánh xạ kết quả hash đó vào một trong số các next-hop có cost bằng nhau. Vì hash là hàm xác định (deterministic) trên cùng một flow, mọi gói của cùng một flow luôn đi cùng một đường — giữ đúng thứ tự gói cho flow đó — nhưng các flow khác nhau thì được rải ngẫu nhiên (giả-ngẫu nhiên) qua các đường khác nhau dựa theo phân bố của hàm hash, không dựa theo việc đường nào đang rảnh hay bận thực tế tại thời điểm đó.
Chính vì ECMP "mù" trước tải thực tế của từng liên kết, nó chỉ đảm bảo cân bằng tải theo kỳ vọng thống kê khi có đủ nhiều flow độc lập — giống việc tung một đồng xu nhiều lần thì tỷ lệ ngửa/sấp tiến gần 50/50, nhưng từng lần tung riêng lẻ vẫn có thể ra một mặt liên tiếp. Với số lượng flow nhỏ hoặc traffic pattern có tính "đồng bộ" (nhiều nguồn cùng gửi burst lớn tới cùng một đích tại cùng thời điểm — hiện tượng gọi là incast, thường gặp trong các job phân tán như MapReduce hay all-to-all traffic của huấn luyện AI), xác suất nhiều flow cùng bị hash trùng vào một liên kết ra tăng lên đáng kể, gây tràn buffer và drop — đúng như ví dụ A/C hội tụ vào B nêu trên. Bộ đệm (buffer) trên switch chỉ mua được vài micro-giây dung sai cho các đợt trùng tải ngắn hạn (micro-burst); khi tình trạng hội tụ kéo dài hơn khả năng hấp thụ của buffer, gói tin buộc phải bị drop — đây chính là cơ chế vật lý đứng sau khái niệm "non-contending" vừa nêu.
6. Các cách vẽ sơ đồ: spine-in-center, top-of-spine, fat tree
Cùng một fabric Benes/Clos có thể được vẽ theo nhiều cách khác nhau — xoay và gập lại vẫn là cùng một sơ đồ đấu nối. Đây là hệ quả trực tiếp của khái niệm đồ thị đẳng cấu (isomorphic graph) trong toán học: hai sơ đồ có thể trông khác hẳn nhau về vị trí đặt node trên giấy, nhưng nếu ma trận kề (adjacency — ai nối với ai) giống hệt nhau, chúng vẫn là cùng một mạng vật lý, chỉ khác cách bố trí (layout/embedding). Một cách vẽ phổ biến gọi là top-of-spine (hay "spine top") — đặt spine ở trên cùng. Tác giả cá nhân thích vẽ với spine (hoặc "top of fabric") ở trung tâm vì dễ quan sát cấu trúc fabric hơn, dù cách vẽ này khiến nhiều người thấy rối vì các port biên (edge port của top-of-rack switch) nằm ở cả trên lẫn dưới sơ đồ.
Fat tree: vẫn là một dạng spine-leaf, nhưng khác ở chỗ băng thông tăng gấp đôi ở mỗi hop — ví dụ liên kết ở biên là 10 Gig thì liên kết ở giữa (core) là 20 Gig. Đây là nghĩa kỹ thuật chính xác của "fat tree": băng thông nhân đôi ở mỗi bước vào sâu trong mạng (1 → 2 → 4…). Tuy vậy, nhiều người dùng từ "fat tree" theo nghĩa thông tục hơn — chỉ cần có sự chênh lệch tốc độ giữa edge port và các liên kết lõi (không nhất thiết đúng tỷ lệ gấp đôi) — ví dụ trong hầu hết mạng hyperscale: edge port 25 Gig còn liên kết lõi 100 Gig, hoặc edge 100 Gig còn lõi 400 Gig — miễn là có một tốc độ ở cạnh và một tốc độ khác ở các liên kết bên trong.
Cả ba cách vẽ thực chất là cùng một đồ thị
Nguyên gốc trong công trình của Leiserson năm 1985, ý tưởng "fat tree" xuất phát từ việc mỗi liên kết đi lên gần root phải gánh đủ băng thông tổng hợp mà toàn bộ nhánh phía dưới nó có thể tạo ra — nếu mỗi node phân nhánh (fan-out) ra 2 nhánh con, để không tạo nút thắt cổ chai (bottleneck), liên kết đi lên tối thiểu phải gánh gấp đôi so với liên kết đi xuống, đó là gốc rễ của cách nói "băng thông nhân đôi ở mỗi hop". Diagram dưới đây đặt cạnh nhau ba cách vẽ của đúng một topology nhỏ (2 spine, 3 leaf) để thấy chúng chỉ khác layout, không khác kết nối vật lý.
7. Universal topology: fat tree có thể giả lập mọi topology khác
Fat tree nguyên bản còn được gọi là universal topology. Lý do: có rất nhiều kiểu topology mạng khác nhau — ring, hub-and-spoke, partial mesh, full mesh… Dùng tunnel, có thể giả lập (emulate) bất kỳ topology nào chồng lên trên một topology khác — ví dụ giả lập full mesh bằng cách xây tunnel link nối thẳng mọi cặp thiết bị, hoặc giả lập ring bằng tunnel nối các edge device thành vòng.
Sau khi emulate, có thể tính được mức độ hao hụt hiệu năng (efficiency) bằng khái niệm stretch — số hop bổ sung phải đi thêm. Ví dụ để emulate một bước trên ring topology, có thể phải đi lên rồi xuống nhiều lần.
Ví dụ số cụ thể để dễ hình dung: trên một ring topology vật lý thật, đi từ node 1 sang node 2 (hàng xóm liền kề) chỉ tốn 1 hop. Nếu đem ring này emulate bằng tunnel chồng lên một fat tree 3-tầng (leaf-spine-leaf), gói tin phải đi leaf1 → spine → leaf2, tức 2 hop vật lý cho cùng một bước logic đáng lẽ chỉ cần 1 hop. Stretch ở đây là 2 (2 hop thực tế / 1 hop logic mong muốn). Nếu ring có N node và phải emulate một bước "đi vòng" xa hơn (ví dụ từ node 1 sang node N để hoàn tất vòng), số hop vật lý qua fat tree vẫn chỉ là 2 (leaf-spine-leaf) bất kể N lớn cỡ nào — đây chính là lý do fat tree được xem là emulate hiệu quả: stretch gần như không đổi dù topology gốc có bao nhiêu node, khác hẳn so với việc build một ring vật lý thật nơi số hop tăng tuyến tính theo khoảng cách trên vòng.
Fat tree là topology duy nhất có thể build mọi topology khác lên trên nó với mức hao hụt hiệu năng thấp nhất. Điều này khiến spine-leaf mang tính "vạn năng" — dù bản thân không phải universal như fat tree — theo nghĩa: nếu một ứng dụng thích kiểu full mesh giữa các node, spine-leaf có thể emulate điều đó với hao hụt hiệu năng thấp nhất so với việc build full mesh vật lý thật sự; tương tự nếu ứng dụng thích ring topology.
Vì sao stretch của fat tree gần như không đổi dù mạng lớn cỡ nào?
Cốt lõi nằm ở đường kính đồ thị (graph diameter) — số hop tối đa giữa hai node bất kỳ. Trong một ring N node, đường kính tăng tuyến tính theo N (đi càng xa trên vòng càng tốn nhiều hop). Trong một fat tree/Clos 3-tầng, đường kính giữa hai leaf bất kỳ luôn cố định ở 2 hop (leaf → spine → leaf) bất kể fabric có 4 leaf hay 4.000 leaf, miễn là còn nằm trong cùng một Clos 3-tầng — vì mọi leaf đều có đường trực tiếp lên mọi spine, không cần đi qua leaf trung gian nào khác. Đây chính là lý do stretch của việc emulate gần như không đổi theo quy mô: dù topology gốc (ring, mesh...) có bao nhiêu node, số hop vật lý cần thiết trên fat tree để nối hai điểm bất kỳ vẫn bị chặn trên bởi đường kính cố định của chính fat tree, chứ không phụ thuộc vào N của topology đang được emulate. Đây cũng đúng là nội dung chứng minh hình thức trong bài báo gốc của Leiserson: với cùng một ngân sách phần cứng, fat tree luôn mô phỏng được mạng khác với độ trễ chỉ chậm hơn một hệ số polylogarit theo kích thước mạng — chứ không tăng tuyến tính như hầu hết các topology khác.
8. Butterfly topology
Một topology fabric thú vị khác là butterfly. Đặc điểm nhận dạng: có các pod được định nghĩa rõ ràng — khi ai đó nói về việc xây "pod" trong môi trường hyperscale/data center, phần lớn (không phải luôn luôn) họ đang nói tới butterfly topology.
Mỗi pod về cơ bản là một nửa của một Clos fabric ba tầng — chỉ có hai tầng (stage) trong pod. Tầng thứ ba (hoặc thứ năm, tùy cách nhìn) được tạo bởi các "fabric device" đặt ở giữa: có một fabric màu xanh (blue fabric), với một spine device trong mỗi pod kết nối tới nó; có một fabric màu cam (orange fabric), cũng có một spine device trong mỗi pod kết nối tới nó. Tầng trung tâm này đôi khi gọi là top of fabric, super spine, hoặc đơn giản là "the fab".
Hai đặc điểm quan trọng của butterfly:
- Một khi top-of-rack switch dùng ECMP để quyết định đi vào một fabric màu (ví dụ blue), traffic sẽ ở lại trong fabric màu đó xuyên suốt — không có đường nào dẫn traffic đó sang một fabric màu khác. Hệ quả: nếu mất toàn bộ một fabric màu, chỉ mất 1/4 khả năng (capability) trên toàn bộ backplane/fabric (với ví dụ 4 màu).
- Một khi traffic đã đến "the fab", chỉ có đúng một đường đi (one path) tới bất kỳ đích nào trên toàn mạng — điều này rất hữu ích cho traffic engineering, nhưng đổi lại làm giảm mạnh bisectional bandwidth. Bù lại, butterfly vẫn là non-contending, và cho phép scale rất lớn với thiết bị có port-count thấp.
Ví dụ một butterfly tối đa dùng thiết bị 8-port: 4 port hướng xuống, 4 port hướng lên ở mỗi tầng, lặp lại cho các tầng kế tiếp.
Butterfly cũng có thể được "fold" (gộp lại) và vẽ theo nhiều cách: dạng phẳng (flat) nhìn từ trên xuống, dạng 3D thể hiện đầy đủ kết nối giữa top-of-rack, spine mỗi pod và các fab router, hoặc theo cách hyperscaler hay vẽ (top-of-rack → spine → fab). Nhìn từ trên xuống, cấu trúc pod chạy một hướng và fab chạy hướng còn lại trông giống crossbar, nhưng thực chất không phải crossbar — vì các fab router chỉ là điểm trung chuyển (pivot point), không thực hiện make/break circuit như crossbar thật.
Vì sao butterfly đánh đổi khả năng rearrange lấy khả năng scale?
So với Beneš fabric ở mục 4 — nơi một bộ điều khiển trung tâm có thể tính toán lại đường đi để nhét vừa kết nối mới — butterfly đi theo hướng ngược lại: từ bỏ hoàn toàn khả năng "rearrange". Một khi ECMP tại top-of-rack đã băm traffic vào fabric màu nào, gói tin bị khoá cứng trong fabric màu đó tới hết hành trình, không có cơ chế nào định tuyến lại giữa chừng sang màu khác kể cả khi màu đó đang nghẽn còn màu kia đang rảnh. Đổi lại, mỗi fab router chỉ cần biết định tuyến trong phạm vi đúng một mặt phẳng màu của nó — không cần biết trạng thái toàn mạng, không cần đồng bộ trạng thái với các mặt phẳng màu khác. Đây chính là lý do butterfly cho phép ghép rất nhiều pod bằng các thiết bị port-count thấp mà không cần một control plane phức tạp kiểu tập trung: mỗi mặt phẳng màu vận hành gần như độc lập, đơn giản hoá cả phần cứng lẫn phần mềm quản lý so với một Clos monolithic có mọi spine đều biết đường tới mọi leaf.
Cái giá phải trả nằm ở đúng hai điểm đã nêu: mất một đường thay thế khi nghẽn cục bộ trong một màu (vì không cross-color reroute được), và bisectional bandwidth — băng thông tối đa nếu chia đôi toàn mạng thành hai nửa bằng nhau rồi đo tổng băng thông các liên kết nối hai nửa đó — bị giảm so với một Clos fabric đầy đủ, vì số đường độc lập nối hai nửa mạng bị giới hạn bởi chính số lượng "màu" (mặt phẳng) hiện có, không phải bởi tổng số spine như trong Clos. Đây là đánh đổi kinh điển trong thiết kế fabric hyperscale: chấp nhận giảm bisectional bandwidth và mất một phần linh hoạt traffic engineering, để đổi lấy khả năng scale ra hàng chục nghìn port bằng thiết bị rẻ, đơn giản, dễ vận hành.
Nguồn tham khảo
Nguồn gốc: Understanding Data Center Fabrics, Part 3: Characteristics Of Data Center Fabrics — kênh Packet Pushers
Ghi chú fact-check (truy cập 2026-07-13): tên đúng của nhà toán học là Václav E. Beneš. Công trình nền tảng cho mạng rearrangeable-nonblocking (Beneš network) là bài báo "Permutation groups, complexes, and rearrangeable connecting networks", Bell System Technical Journal, 1964, cùng cuốn sách "Mathematical Theory of Connecting Networks and Telephone Traffic" (Academic Press, 1965) — mốc năm 1965 trong bài khớp với cuốn sách này. (Wikipedia — Václav E. Beneš)
Ghi chú fact-check bổ sung (truy cập 2026-07-14): thuật ngữ "universal topology/network" gán cho fat tree là có nguồn gốc chính thức — bắt nguồn từ bài báo "Fat-Trees: Universal Networks for Hardware-Efficient Supercomputing" của Charles E. Leiserson (MIT), đăng trên IEEE Transactions on Computers, Vol. C-34, Issue 10, tháng 10/1985. Bài báo chứng minh fat tree là "universal" theo nghĩa hình thức: với một ngân sách phần cứng (số dây + diện tích VLSI) cho trước, fat tree có thể mô phỏng (emulate/route) hiệu quả gần như bất kỳ mạng nào khác cùng ngân sách đó. (IEEE Xplore, Wikipedia — Fat tree)