Skip to main content

Understanding Data Center Fabrics - Part 5: Butterfly Scaling

Mục lục​

1. Nhắc lại cấu trúc butterfly fabric: pod, fabric, fab router​

Butterfly fabric có cách đấu dây rất giống Clos fabric. Sơ đồ thường vẽ với spine ở giữa, và top-of-rack switch xuất hiện ở cả trên lẫn dưới sơ đồ (cách vẽ này dễ gây rối cho một số người, nhưng lại giúp nhìn rõ cấu trúc đấu nối của fabric hơn).

Butterfly fabric được xây từ các pod, và các fabric (mỗi fabric thường được gán một màu để phân biệt, ví dụ "blue fabric" gồm toàn bộ thiết bị/link màu xanh). Tên gọi chuẩn cho các loại thiết bị trong một butterfly fabric, từ trên xuống — tổng cộng tạo thành 5 tầng do cấu trúc đối xứng (leaf → spine → fab router → spine → leaf):

  • Fab router (fabric router) — tầng trên cùng
  • Spine
  • Leaf (hay top-of-rack)
Butterfly Fabric Topology Overview: Pods + Fab RouterPod APod BFab RouterSpine ASpine BLeaf A1Leaf A2Leaf B1Leaf B25 tiers, symmetric: Leaf → Spine → Fab Router → Spine → LeafFab router = top of fabric = super spine — the layer connecting pods together

Vì sao cần thêm hẳn một tầng fab router, thay vì chỉ phình to tầng spine?​

Nhắc lại quy tắc port-count đã nêu ở phần trước của tài liệu này: số leaf tối đa của một Clos 3-tier bị chặn cứng bởi số port trên mỗi spine — hết port trên spine là hết chỗ cho leaf mới, bất kể muốn hay không. Khi một tổ chức cần nhiều leaf hơn mức một tầng spine đơn có thể phục vụ, có hai hướng đi: (1) đổi thiết bị spine sang dạng chassis để có nhiều port hơn — nhưng cách này biến 3-tier Clos thành 5-tier Benes fabric ẩn bên trong vỏ máy, kéo theo failure domain lớn hơn và mất tính single-skew; hoặc (2) giữ nguyên thiết bị fixed-form-factor nhỏ, nhưng thêm hẳn một tầng thiết bị mới — fab router — để nối nhiều nhóm spine-leaf (giờ gọi là pod) lại với nhau. Butterfly fabric chọn hướng thứ hai. Kết quả là fabric vẫn có 5 tầng giống hệt về số hop với trường hợp dùng chassis, nhưng khác nhau ở chỗ: mọi tầng đều là thiết bị vật lý độc lập, minh bạch, cùng kích thước RU và cùng phần mềm — không có tầng nào "ẩn bên trong vỏ máy". Đây chính là lý do vì sao butterfly fabric giữ được thiết kế single-skew ở quy mô lớn, trong khi Clos-với-chassis thì không.

Một điểm hay gây nhầm lẫn khi nhìn sơ đồ butterfly fabric: leaf xuất hiện ở cả phía trên lẫn phía dưới hình vẽ (như trong sơ đồ bên trên), khiến người mới nhìn dễ tưởng có hai tầng leaf khác nhau. Thực chất đây chỉ là quy ước vẽ để giảm số đường dây cắt chéo nhau trên giấy — pod A và pod B là hai module hoàn toàn độc lập, mỗi module chỉ có đúng một tầng leaf, một tầng spine; việc đặt leaf của pod A ở dưới và leaf của pod B ở trên (hoặc ngược lại) chỉ nhằm mục đích vẽ sao cho các đường nối lên fab router không đè lên nhau, chứ không phản ánh khác biệt gì về mặt vật lý giữa hai pod.

💡 Hình dung như thế này: một pod giống như một khu dân cư có hệ thống đường nội bộ riêng (leaf-spine) — cư dân trong cùng khu đi lại với nhau qua các con đường nhỏ, không cần ra khỏi khu. Fab router giống như đường vành đai nối nhiều khu dân cư lại thành một thành phố — muốn đi từ khu này sang khu khác, xe phải ra đường vành đai rồi mới rẽ vào khu đích. Thêm một khu dân cư mới không đòi hỏi xây lại đường nội bộ của các khu cũ, chỉ cần nối thêm một nhánh vào đường vành đai — đó chính là lý do fab router luôn là một tầng độc lập, tách biệt khỏi từng pod.

2. Yếu tố giới hạn quy mô: số port và độ rộng pod​

Tương tự Clos fabric, quy mô của butterfly fabric bị giới hạn bởi số port trên từng loại thiết bị:

  • Số pod tối đa bị giới hạn bởi số port có sẵn trong một fabric ở tầng trên (ví dụ nếu một fabric gồm 2 router, thì số port giữa 2 router đó — gộp lại — quyết định số leaf/pod có thể nối tới).
  • Nói chính xác hơn: số pod = (số port trong một fabric) chia cho độ rộng của pod (pod width).

Nguyên tắc thường dùng: độ rộng pod = đúng một nửa số port của thiết bị. Ví dụ thiết bị 32-port → pod rộng 16; thiết bị 64-port → pod rộng 32. Luôn build tất cả các pod cùng một kích thước.

Cụ thể hơn với ví dụ 32 port: 16 port dùng để nối xuống leaf (chính là độ rộng pod, tức tối đa 16 leaf switch trong một pod), 16 port còn lại dùng để nối lên tầng fabric. Tại sao phải chia đúng một nửa, chứ không phải tỷ lệ khác (ví dụ 20 port xuống leaf và 12 port lên fabric để pod rộng hơn)? Vì thiết kế ở đây nhắm tới oversubscription 1:1 — nghĩa là băng thông đi vào pod từ phía leaf phải bằng đúng băng thông đi ra khỏi pod lên fabric. Nếu chia lệch, ví dụ dồn nhiều port hơn xuống leaf, pod sẽ rộng hơn nhưng lại thiếu port lên fabric — traffic giữa các pod dễ bị nghẽn (bottleneck) đúng vào giờ cao điểm. Ngược lại nếu dồn nhiều port hơn lên fabric, số port xuống leaf bị lãng phí vì pod không đủ rộng để tận dụng. Chia đúng một nửa là điểm cân bằng giữ oversubscription ở mức 1:1 mà không lãng phí port ở tầng nào.

Port Split Mechanism: How One Switch Reaches 1:1 OversubscriptionN-port Switchexample: 32 ports totalleft halfright halfDownlink to Leaf / ToR16 ports (N / 2)pod width = this halfUplink to Fabric16 ports (N / 2)connects toward fab routerN / 2N / 2Equal split keeps downlink bandwidth = uplink bandwidth-> oversubscription 1:1, no wasted or bottlenecked ports on either side

💡 Hình dung như thế này: một switch N-port trong butterfly/Clos fabric giống một cây cầu hai chiều bắc qua sông — nửa làn đường dành cho xe từ bờ này (leaf) đổ vào cầu, nửa làn còn lại dành cho xe thoát sang bờ kia (fabric). Nếu xây cầu lệch làn — nhiều làn vào hơn làn ra — xe sẽ dồn ứ ngay tại điểm nối hai bờ dù mặt cầu trông có vẻ rộng rãi. Chia đúng một nửa mỗi bên là cách duy nhất giữ dòng xe lưu thông đều ở cả hai chiều cùng lúc, bất kể giờ cao điểm ở bờ nào.

Công thức số pod tối đa, minh hoạ bằng một ví dụ số học đơn giản​

Diễn giải công thức "số pod = số port trong một fabric ÷ pod width" bằng một ví dụ thuần số học (không gắn với thiết bị thật, chỉ để thấy công thức vận hành ra sao): giả sử một fabric có tổng cộng 64 port hướng xuống các pod, và pod width là 16 — khi đó fabric này phục vụ tối đa 64 ÷ 16 = 4 pod. Muốn phục vụ 8 pod mà vẫn giữ nguyên pod width = 16, fabric phải có tối thiểu 128 port hướng xuống — tức phải thêm switch vào fab layer (mỗi switch góp thêm một số port cố định), hoặc thêm hẳn một fabric mới (một màu mới) chạy song song. Đây chính là hai đòn bẩy scale độc lập ở tầng fab layer: tăng switch trong một fabric, hoặc tăng số fabric — cả hai đều làm tăng số port khả dụng ở tầng trên, từ đó tăng số pod tối đa theo đúng công thức chia ở trên.

Điều gì xảy ra cụ thể nếu chia lệch tỷ lệ 50/50?​

Thử hình dung cụ thể hơn với ví dụ 32 port đã nêu, nhưng chia lệch 20/12 thay vì 16/16: pod lúc này rộng 20 leaf thay vì 16, tức phục vụ được nhiều rack hơn — nghe có vẻ lợi. Nhưng tổng băng thông từ 20 leaf đó giờ phải dồn qua chỉ 12 port lên fabric thay vì 16 — tỷ lệ oversubscription giữa trong-pod và liên-pod bị đẩy lên khoảng 20:12, xấp xỉ 1,67:1, thay vì 1:1. Ở điều kiện tải thấp, khác biệt này gần như không nhận ra; nhưng khi nhiều pod cùng gửi traffic liên-pod vào giờ cao điểm (ví dụ đồng bộ dữ liệu hàng loạt, backup job chạy đồng thời), 12 port đó bão hoà nhanh hơn hẳn so với thiết kế 16 port, khiến hàng đợi (queue) trên các port uplink tăng độ trễ hoặc bắt đầu rớt gói. Ngược lại, nếu chia 12/20 (ít port xuống leaf hơn, nhiều port lên fabric hơn), pod chỉ rộng 12 leaf — 4 port fabric dư ra gần như không dùng hết công suất vì phía dưới không đủ traffic để lấp đầy, lãng phí port vốn đắt tiền ở tầng cao nhất của fabric. Không có cách chia lệch nào vừa giữ oversubscription 1:1 vừa tăng được pod width cùng lúc — đây là lý do quy tắc 50/50 trở thành mặc định trong thiết kế butterfly/Clos hiện đại, trừ khi cố ý chấp nhận một tỷ lệ oversubscription khác 1:1 để đổi lấy pod rộng hơn.

Có thể xây pod nhỏ hơn và dùng nhiều kết nối hơn ở khu vực fabric, nhưng cách này khiến việc tính toán phức tạp hơn — dùng đúng một nửa số port cho pod, sau đó điều chỉnh số fabric và số switch trong mỗi fabric để đạt quy mô mong muốn, sẽ dễ tính hơn nhiều. Nếu build pod nhỏ hơn mức này rồi tăng số switch trong fabric, sẽ có lúc bị mắc kẹt (stuck) — hết port từ pod lên tầng spine/fabric và không thể scale tiếp.

3. Ví dụ các mức scale thực tế​

Bài nói đưa ra hai nhóm ví dụ, dùng thiết bị 32×100G (1RU) và 64×100G (2RU), tất cả đều ở tỷ lệ oversubscription 1:1 và các cổng workload đều là 100G.

Cách đọc mỗi dòng bên dưới: (số fabric) × (số switch/fabric) → (số pod tương ứng) → tổng số port workload đạt được. Số fabric và số switch/fabric càng tăng thì càng nhiều port rảnh ở tầng trên để nối thêm pod — nên tổng port workload cuối dòng chính là quy mô server tối đa mà cấu hình đó phục vụ được, ở đúng tỷ lệ 1:1 đã nêu ở trên:

Với thiết bị 32×100G (1RU), pod width cố định = 16:

  • 8 fabric × 4 switch/fabric → 4 pod → 1.024×100G port
  • 8 fabric × 16 switch/fabric (tối đa) → 16 pod → 4.096×100G port (có thể nhân 4 bằng optical splitter → khoảng 16K port 25G)

Với thiết bị 64×100G (2RU), pod width cố định = 32:

  • 16 fabric × 4 switch/fabric → 4 pod → 4.096×100G port
  • Tiếp tục tăng số fabric/switch mỗi fabric/số pod → có thể đạt 8.192×100G port
  • Quy mô lớn nhất: 32 fabric × 16 switch/fabric → 32 pod → 32.768×100G port, nhân 4 bằng optical splitter → khoảng 131.000 port 25G

Vì sao quy mô tăng nhanh như vậy chỉ với vài lần nhân đôi thiết bị?​

Nhìn kỹ chuỗi số trong hai bảng trên sẽ thấy: tổng port workload không tăng tuyến tính theo số thiết bị bỏ thêm vào, mà tăng theo tích của nhiều đại lượng cùng lúc — số pod (quyết định bởi số switch/fabric), pod width (quyết định bởi port count của thiết bị), và số port downlink workload trên mỗi leaf (cũng chính là một nửa port count thiết bị, do single-skew). Vì ba đại lượng này nhân với nhau chứ không cộng, mỗi lần tăng gấp đôi một trong ba đại lượng, tổng port workload cũng tăng gấp đôi theo — nhưng nếu tăng gấp đôi cả số pod lẫn đổi sang thiết bị port-count gấp đôi cùng lúc (như bước chuyển từ tier 32×100G sang tier 64×100G), tổng port workload có thể tăng gấp bốn chỉ trong một bước. Đây là lý do các bảng scale của butterfly fabric (và Clos fabric nói chung, xem thêm phần trước của tài liệu này) luôn trông như tăng "nhảy vọt" giữa các dòng, dù về bản chất mỗi dòng chỉ đơn giản là nhân thêm một hoặc hai lần thiết bị.

Điểm cần lưu ý khi đọc con số ở mức optical-splitter-×4: 32.768×100G port nhân 4 cho ra khoảng 131.000 port 25G — lớn hơn nhiều so với quy mô cần thiết của tuyệt đại đa số data center hiện nay. Con số này tồn tại trong bảng scale chủ yếu để minh hoạ giới hạn lý thuyết của kiến trúc butterfly, chứ không phải mức mà đa số tổ chức thực sự build tới.

Điểm đáng chú ý: các mức scale của tier 32×100G và tier 64×100G thường chồng lấn nhau — quy mô lớn nhất của tier thấp hơn (32×100G) rơi vào khoảng quy mô trung bình của tier cao hơn (64×100G). Đây là hiện tượng thường gặp khi nhìn vào các bảng số scale của spine-leaf/butterfly fabric nói chung.

Với các quy mô cực lớn (hàng trăm nghìn port), thực tế không nhiều data center cần lớn đến vậy — nhưng điều quan trọng là: hoàn toàn có thể đạt tới quy mô rất lớn mà không cần dùng chassis box ở spine/leaf, tức là vẫn giữ được thiết kế single-skew (mọi thiết bị trong fabric giống hệt nhau về kích thước RU và phần mềm chạy trên đó) nhờ dùng kiểu butterfly fabric.

Về cách đặt tên: các fabric thường được đặt tên theo màu (blue, red, green…), nhưng khi số lượng fabric lớn (ví dụ 32 fabric) thì hết màu dễ nhớ, nên nhiều nơi chuyển sang đặt tên theo kiểu khác cho sáng tạo hơn. Lưu ý: số lượng fabric/device lẻ (ví dụ 12 hoặc 24) khá khó đấu dây vì không chia đều số kết nối port giữa các pod và fab layer — nên thường khuyến nghị dùng số chẵn, trừ khi đang cố tình scale từng bước nhỏ.

4. Rewiring khi scale: di chuyển optic để thêm fabric/switch​

Khi tăng số thiết bị trong mỗi fab layer (ví dụ thêm switch vào một fabric), phải đấu lại dây (rewire): một số port trước đó nối từ pod 1 vào một fabric device phải được tháo ra và chuyển sang các fabric device mới thêm vào. Đây là lý do vì sao cần dành sẵn không gian (1-2 rack) riêng cho mỗi fabric — để có chỗ thao tác optic khi cần mở rộng.

Ví dụ minh họa: với cấu hình 4 pod, dùng thiết bị 32×100G, 16 fabric, 2 switch/fabric — mỗi spine switch có 16 port nối lên fab layer và 16 port nối xuống top-of-rack. Với chỉ 2 switch trong fab layer, mỗi switch đó nhận 8x kết nối (16÷2=8). Khi tăng số switch trong fab layer lên 4, mỗi kết nối trước đó (8x) phải chia lại thành 4x cho mỗi switch — để lại 4 port dư trên mỗi spine, đủ để nối thêm 2-4 pod mới vào mạng. Đây chính là cách butterfly fabric scale out từng bước một.

Butterfly Rewiring: Adding Fabric Switches to Scale OutBefore — 2 switches/fabric (8x each)SpineFab 1Fab 28x8xAfter — 4 switches/fabric (4x each) → 4 free ports for 2 more podsSpineFab 1Fab 2Fab 3Fab 44x each

Vì sao rewiring lại là bước bắt buộc, không thể tránh?​

Về bản chất, rewiring xảy ra vì các port ở fab layer đã đấu dây theo đúng tỷ lệ chia đều cho số switch hiện có tại thời điểm build ban đầu — thêm switch mới vào fabric không tự động "rảnh port" ở những switch cũ, mà đòi hỏi phân bổ lại toàn bộ tỷ lệ port-to-pod cho công bằng giữa các switch, cả cũ lẫn mới. Nếu không rewire, switch mới thêm vào sẽ đứng ngoài lề — không nhận traffic từ bất kỳ pod nào, vì mọi pod vẫn đang đấu cứng vào các switch cũ theo cấu hình gốc. Đây là điểm khác biệt quan trọng so với việc chỉ đơn giản "cắm thêm switch vào rack": phải chủ động di chuyển optic đang chạy sống (live) từ port cũ sang port mới, thường phải làm từng pod một để tránh gây gián đoạn đồng thời cho nhiều pod cùng lúc.

Vì thao tác rút/cắm optic ảnh hưởng trực tiếp tới traffic đang chạy, quy trình rewiring trong thực tế gần như luôn đi kèm một bước "drain" trước đó: chuyển traffic ra khỏi các link sắp bị rút bằng cách điều chỉnh routing (hạ trọng số route hoặc rút hẳn quảng bá qua link đó), đợi traffic trên link giảm gần về 0, rồi mới rút optic — giảm thiểu số gói tin bị rớt trong lúc thao tác vật lý. Đây cũng là lý do vì sao rewiring thường được lên lịch theo từng pod, từng khung giờ bảo trì (maintenance window) nhỏ, thay vì làm đồng loạt toàn bộ fab layer cùng lúc — cùng tinh thần với canary và rolling upgrade sẽ nói kỹ hơn ở mục 5.

5. Pod như một module độc lập: canary, rolling upgrade, "cattle not pets"​

Một điểm hay của cách tổ chức theo pod: mỗi pod trở thành một module trong mạng, có thể "nhấc lên và thay thế" toàn bộ cùng lúc. Điều này cho phép chạy nhiều generation (thế hệ phần cứng/phần mềm) song song trong cùng một hệ thống — ví dụ:

  • Cài đặt thế hệ đầu tiên (gen 1) trên tất cả pod và fabric ban đầu.
  • Khi muốn nâng cấp phần mềm, không đẩy bản mới ra toàn bộ data center cùng lúc — thay vào đó chọn một fabric và một pod, đẩy phiên bản mới (phần cứng hoặc phần mềm) chỉ vào đó — đây gọi là canary.
  • Có thể chuyển workload sang pod khác rồi từ từ đưa traffic trở lại pod đang chạy canary, hoặc đưa traffic giả (false workload) vào để kiểm chứng — mà pod đó vẫn đang nằm trong fabric production.
  • Sau khi canary chạy ổn, dần dần chuyển các pod/fabric còn lại sang generation mới — một kiểu rolling upgrade.

💡 Hình dung như thế này: coi mỗi pod như một chi nhánh trong một chuỗi cửa hàng bán lẻ — muốn thử một quy trình vận hành mới, không ai áp dụng đồng loạt cho cả chuỗi cùng lúc. Chọn đúng một chi nhánh để thử nghiệm, theo dõi xem có ổn không, rồi mới nhân rộng dần sang các chi nhánh còn lại — nếu chi nhánh thử nghiệm gặp vấn đề, thiệt hại chỉ giới hạn ở đúng chi nhánh đó.

Điều kiện để làm được việc này: phải dùng cùng kích thước vật lý box (cùng 1RU hoặc cùng 2RU, cùng layout port) và cùng tốc độ link trong suốt vòng đời của pod/fabric đó — vì chuyển đổi tốc độ (ví dụ từ 40G sang 100G) giữa chừng là rất khó. Vì vậy cần xác định trước quy mô tối đa dự kiến của fabric ngay từ đầu. Khi hết chỗ trong spine/fabric hoặc hết băng thông, giải pháp là forklift — thay thế toàn bộ fabric bằng một quy mô lớn hơn.

Cơ chế kỹ thuật đằng sau canary: vì sao một pod có thể vừa test vừa production?​

Để một pod chạy canary mà không ảnh hưởng toàn bộ fabric, underlay phải hỗ trợ điều chỉnh traffic engineering ở mức route — cùng cơ chế "drain" đã nhắc ở phần trước của tài liệu này: trước khi đẩy thay đổi vào pod canary, hạ trọng số (hoặc rút hẳn) các route quảng bá từ pod đó lên fab router, khiến traffic thật giảm dần rồi gần như ngừng chảy qua pod đó mà không cần tắt hẳn kết nối vật lý. Sau khi pod đã "rảnh" traffic thật, kỹ sư mới đẩy thay đổi (nâng cấp phần mềm, đổi cấu hình, thay thiết bị) rồi kiểm chứng bằng traffic tổng hợp (synthetic/false workload) — các gói tin dựng riêng để đo độ trễ, tỷ lệ mất gói, hành vi ECMP — mà không cần rủi ro tới dữ liệu khách hàng thật. Nếu mọi chỉ số đều ổn, route quảng bá của pod canary được khôi phục dần dần (tăng trọng số từng bước) để traffic thật quay lại — đúng bản chất một rolling upgrade ở cấp pod.

Một hệ quả kỹ thuật cần lưu ý: trong giai đoạn nhiều generation cùng chạy song song (gen 1 và gen 2 cùng tồn tại), giao thức underlay (BGP hoặc link-state, sẽ được bàn kỹ ở các phần sau của tài liệu này) phải tương thích được giữa các phiên bản phần mềm khác nhau chạy trên từng gen — nếu không, việc quảng bá route qua lại giữa pod gen 1 và fab router gen 2 có thể gãy. Đây là lý do vì sao canary thường bắt đầu ở quy mô rất nhỏ (một pod, một fabric) và giữ thời gian chạy song song đủ dài để phát hiện các lỗi tương thích tinh vi trước khi nhân rộng ra toàn bộ data center.

Về forklift: đây là lựa chọn cuối cùng khi một fabric generation đã chạm trần quy mô (hết port, hết băng thông) mà không còn cách rewiring hay thêm switch nào cứu được nữa. Forklift đồng nghĩa với việc build song song một fabric mới — thường ở quy mô lớn hơn hẳn — rồi di chuyển toàn bộ pod cũ sang, thay vì cố nới rộng fabric hiện tại. Cách này tốn kém hơn rewiring rất nhiều vì đòi hỏi thêm không gian rack, thêm thiết bị hoàn toàn mới, và một giai đoạn di trú (migration) traffic kéo dài; nhưng đổi lại tránh được rủi ro cố vá một kiến trúc đã hết dư địa mở rộng tự nhiên.

Nguyên tắc thiết kế then chốt: cần xây dựng vòng đời (lifecycle) rõ ràng ở cấp pod và fabric generation, chứ không phải ở cấp từng thiết bị riêng lẻ. Đây cũng chính là tinh thần "cattle, not pets" — một thuật ngữ phổ biến trong giới vận hành hạ tầng lớn từ đầu thập niên 2010, mang ý coi mỗi thiết bị như một đơn vị hàng hóa thông thường (commodity), dù được mua từ nhà cung cấp yêu thích nào đi nữa, thay vì đối xử với từng thiết bị như một "con thú cưng" cần chăm sóc riêng.

Nguồn tham khảo​

Nguồn gốc: Understanding Data Center Fabrics, Part 5: Butterfly Scaling (Russ White) — kênh Packet Pushers. Xem thêm tại packetpushers.net và bản video trên YouTube.

Ghi chú fact-check (truy cập 2026-07-14, re-verify 2026-08-17):

  • Nguyên tắc "pod width = đúng một nửa số port thiết bị": đây khớp với design principle kinh điển của mạng fat-tree/Clos non-blocking, đã được mô tả trong paper học thuật "A Scalable, Commodity Data Center Network Architecture" (Al-Fares, Loukissas, Vahdat — SIGCOMM 2008) — mỗi switch k-port dùng k/2 port xuống tầng dưới và k/2 port lên tầng trên để đạt oversubscription 1:1 (full bisection bandwidth). Không tìm thấy tài liệu vendor chính thức nào (Cisco/Arista/Juniper) đặt tên riêng cho quy tắc này trong ngữ cảnh spine-leaf, nhưng về bản chất toán học nó trùng khớp hoàn toàn với công thức fat-tree chuẩn — tức đây không chỉ là kinh nghiệm cá nhân của diễn giả gốc mà có nền tảng học thuật vững. Đã re-verify 2026-08-17, paper và công thức k/2 vẫn khớp. Nguồn: Al-Fares et al., SIGCOMM 2008.
  • Thuật ngữ "cattle, not pets": nguồn gốc là Bill Baker (Distinguished Engineer, Microsoft), dùng trong một bài trình bày so sánh scale-up và scale-out cho SQL Server. Randy Bias (CloudScaling) là người phổ biến thuật ngữ này rộng rãi trong giới điện toán đám mây/hạ tầng qua bài trình bày "Architectures for Open and Scalable Clouds" năm 2012, sau khi tìm thấy ý tưởng gốc của Baker qua tìm kiếm. Đã re-verify 2026-08-17, trang nguồn vẫn còn hoạt động và nội dung không đổi. Nguồn: The History of Pets vs Cattle — Cloudscaling.
  • Tổng port 25G ở mức scale lớn nhất (32.768×100G port nhân 4 qua optical splitter) là khoảng 131.000 port, không phải khoảng 120.000 như bản gốc — 2026-08-17, phép nhân trực tiếp từ số liệu 32.768×100G đã nêu trong cùng đoạn.
  • Thuật ngữ "super spine" cho tầng nối các pod leaf-spine lại với nhau trong kiến trúc 5-tier (tương đương fab router trong bài) là cách gọi phổ biến trong ngành, khớp với mô tả trong bài — 2026-08-17, The History of Spine and Leaf Architectures — PacketCoders.