Understanding Data Center Fabrics - Part 1: Justifying Fabrics
Mục lục
- 1. Mạng phân cấp truyền thống: switched vs routed
- 2. Hai loại failure domain: transport layer và control plane
- 3. Scale Up vs Scale Out: hai cách mở rộng ứng dụng
- 4. Traffic Bắc-Nam (North-South) vs Đông-Tây (East-West)
- 5. Ba thách thức của thiết kế mạng truyền thống
1. Mạng phân cấp truyền thống: switched vs routed
Trước khi đi vào chi tiết, cần thống nhất một thuật ngữ sẽ xuất hiện xuyên suốt tài liệu này: failure domain — hiểu đơn giản là phạm vi bị ảnh hưởng khi một thành phần trong mạng (một link, một switch, một tiến trình routing) gặp sự cố. Failure domain càng nhỏ, sự cố càng bị khoanh vùng, càng ít thiết bị khác bị vạ lây.
Với một mạng data center đơn giản dạng ba lớp (access – distribution – core), nếu mạng này được switch hóa hoàn toàn (switched network) thì trên thực tế nó không còn là ba failure domain riêng biệt nữa — toàn bộ mạng trở thành một failure domain duy nhất ở control plane, vì cả mạng chạy chung spanning tree (Spanning Tree Protocol - STP, giao thức có nhiệm vụ dò toàn bộ topology layer 2 và tự động chặn bớt các liên kết dư thừa để không xảy ra loop vô hạn) hoặc giao thức tương đương. Có thể dùng VLAN/802.1Q để chia nhỏ broadcast domain, nhưng control-plane failure domain thì vẫn là một khối duy nhất.
Trong một mạng spanning tree, một số liên kết bắt buộc phải bị block để tránh loop. Ví dụ với đường đi B → C → E → D → B, đây là một vòng lặp (loop), nên spanning tree sẽ block bớt một số cổng (ví dụ cổng B-C, cổng E-D) để phá vòng lặp. Hệ quả là một phần dung lượng (capacity) của mạng bị bỏ không sử dụng vì bị block.
Nếu chuyển sang mạng đã được route hóa (routed network) — vẫn cùng sơ đồ nhưng các switch giờ là router — mọi thứ thay đổi:
- Có thể xây dựng đúng nghĩa kiến trúc phân cấp access – distribution – core, thông qua việc aggregate tại các cặp router.
- Cho phép dùng ECMP (Equal Cost Multipath — kỹ thuật cho phép router chia đều traffic ra nhiều liên kết có cùng chi phí/metric thay vì chỉ chọn một đường rồi bỏ không các đường còn lại) để load-share trên các cặp liên kết, nên không có liên kết nào bị block.
- Mỗi liên kết giờ là một failure domain layer 2 (broadcast domain) riêng biệt.
- Toàn bộ mạng vẫn có thể là một failure domain lớn ở góc độ routing protocol, tùy vào việc có aggregate tại distribution layer hay không.
Ngoài mô hình ba lớp, có thể bố trí thành kiến trúc hai lớp — coi các cặp thiết bị là các module aggregation, và lớp trên cùng là core (hoặc ngược lại) — có nhiều cách chia tùy theo thiết kế.
Vì sao Layer 2 bắt buộc phải có STP, còn Layer 3 thì không
Gốc rễ của khác biệt giữa mạng switched và mạng routed nằm ở một chi tiết rất nhỏ trong header: Ethernet frame không có trường TTL (time-to-live), trong khi IP packet có. Khi một frame layer 2 đi vào một vòng lặp vật lý (ví dụ do có nhiều đường đi song song giữa hai switch), frame đó — đặc biệt là broadcast hoặc unknown-unicast — sẽ bị switch flood ra mọi cổng còn lại, quay vòng qua switch kế tiếp, quay lại switch ban đầu qua một cổng khác, rồi tiếp tục bị flood — cứ thế nhân bản theo cấp số nhân mà không có cơ chế nào tự hủy nó, cho tới khi băng thông toàn bộ segment bị chiếm dụng hoàn toàn (hiện tượng gọi là broadcast storm). STP tồn tại chính là để ngăn kịch bản này: bằng cách đảm bảo tại một thời điểm chỉ có đúng một đường logic loop-free giữa hai điểm bất kỳ trong mạng, spanning tree loại trừ khả năng tồn tại vòng lặp vật lý đang active — đổi lại phải trả giá bằng việc block bớt các liên kết dư thừa như đã thấy ở trên.
Ở layer 3 thì khác: mỗi khi một router forward một IP packet, nó giảm trường TTL đi 1; nếu packet đó lỡ rơi vào một vòng lặp định tuyến, TTL sẽ về 0 sau một số hữu hạn hop và packet bị hủy ngay tại đó. Vì có "van an toàn" tự nhiên này, layer 3 không bắt buộc phải giữ đúng một đường đi duy nhất giữa hai điểm — nó có thể giữ đồng thời nhiều đường có cùng chi phí (ECMP) mà không sợ loop vô hạn, chỉ cần router chạy đúng thuật toán định tuyến (shortest-path) để tránh forward ngược lại vào chính đường vừa đi qua. Đây là lý do kỹ thuật cốt lõi vì sao route hóa mạng lại "giải phóng" được toàn bộ capacity vốn bị lãng phí trong mạng switched.
Cơ chế bầu chọn root bridge và vì sao STP hội tụ chậm
Để biết cổng nào bị block, các switch trong cùng một STP domain trao đổi với nhau các gói BPDU (Bridge Protocol Data Unit) chứa Bridge ID (kết hợp priority cấu hình được và địa chỉ MAC) của chính nó. Switch có Bridge ID nhỏ nhất toàn mạng sẽ tự động trở thành root bridge — gốc của cây spanning tree. Từ đó, mỗi switch còn lại chọn ra root port (cổng có đường đi rẻ nhất — path cost thấp nhất — về root bridge), mỗi segment mạng chọn ra một designated port (cổng có đường về root rẻ nhất trên chính segment đó), còn lại tất cả các cổng khác đều bị chuyển sang trạng thái blocking.
Vấn đề là: quá trình này không chỉ chạy một lần lúc khởi động mà phải chạy lại mỗi khi có bất kỳ thay đổi topology nào — đúng như bản chất "một control-plane failure domain duy nhất" đã nói ở trên. Với STP truyền thống (IEEE 802.1D), thời gian để một cổng đi từ blocking sang forwarding sau một thay đổi topology thường mất khoảng 50 giây (Max Age 20 giây để BPDU cũ hết hạn, cộng thêm hai lần Forward Delay 15 giây cho các trạng thái listening và learning) — nghĩa là trong suốt gần một phút đó, một phần mạng có thể mất kết nối dù bản thân link/thiết bị vật lý liên quan không hề hỏng. Bản nâng cấp RSTP (IEEE 802.1w) rút ngắn thời gian này xuống dưới một giây bằng cách bỏ qua các trạng thái chờ, dùng cơ chế bắt tay proposal/agreement giữa các switch lân cận và tính sẵn các cổng dự phòng (alternate port, backup port) từ trước — nhưng về bản chất, RSTP vẫn không thay đổi việc toàn bộ cây phải được tính lại mỗi khi có sự cố, nó chỉ làm việc tính lại đó nhanh hơn.
2. Hai loại failure domain: transport layer và control plane
Một điểm quan trọng cần phân biệt khi phân tích failure domain trong mạng: failure domain ở transport layer và failure domain ở control plane là hai khái niệm khác nhau, cần tách bạch rõ ràng trong tư duy thiết kế thay vì gộp chung.
Failure domain ở transport layer nói về phạm vi vật lý/dữ liệu bị mất khi một link hoặc một thiết bị chuyển tiếp (forwarding) hỏng. Ví dụ nếu một sợi cáp giữa Access 1 và Distribution A đứt, thì chỉ traffic đi qua đúng sợi cáp đó bị rớt — các link khác trong mạng vẫn truyền dữ liệu bình thường, không ai khác phải "biết" hay phản ứng gì thêm. Đây là loại failure domain dễ hình dung nhất: hỏng cái gì thì mất đúng cái đó, không lan ra ngoài phạm vi vật lý của nó.
Failure domain ở control plane lại nói về phạm vi các thiết bị buộc phải tính toán lại (recompute) khi có một thay đổi topology, bất kể thay đổi đó có ảnh hưởng trực tiếp đến traffic của thiết bị đó hay không. Một route flap, một link lên/xuống, hay một node rớt khỏi topology đều là tín hiệu buộc control plane phải phản ứng. Với spanning tree, mọi switch trong cùng cây STP phải tham gia tính lại root bridge và trạng thái forwarding/blocking của toàn bộ cổng — kể cả những switch không hề nằm gần vị trí sự cố. Với một giao thức routing như OSPF, phạm vi recompute phụ thuộc vào việc topology change đó được flood tới bao xa (area, vùng aggregate,...) — nhưng về nguyên tắc, càng nhiều thiết bị phải tính lại, phạm vi ảnh hưởng của một sự cố nhỏ càng lớn.
Nối lại với ví dụ switched vs routed ở mục 1: một mạng đã switch hóa hoàn toàn có transport failure domain rất nhỏ (đứt một link chỉ mất đúng link đó), nhưng lại có control-plane failure domain lớn nhất có thể — toàn bộ mạng chạy chung một cây spanning tree, nên bất kỳ thay đổi nào (dù nhỏ) cũng buộc mọi switch phải tính lại toàn bộ cây. Ngược lại, khi route hóa mạng và dùng ECMP, mỗi liên kết vừa là một transport failure domain riêng, vừa giúp giới hạn phạm vi control-plane failure domain nếu thiết kế có aggregate route hợp lý ở distribution layer — một sự cố cục bộ không nhất thiết phải làm cả mạng phải tính toán lại.
Vì sao lựa chọn giao thức định tuyến lại quyết định kích thước control-plane failure domain
Không phải mọi giao thức routing đều flood thông tin đi xa như nhau, và chính cách mỗi giao thức truyền tin lại quyết định phạm vi recompute lớn hay nhỏ. Với giao thức link-state như OSPF hay IS-IS, mỗi router phải xây một bản đồ topology giống hệt nhau (link-state database) bằng cách flood nguyên trạng thái link của mình (LSA với OSPF, LSP với IS-IS) tới toàn bộ router khác trong cùng area — nghĩa là bất kỳ router nào trong area đó cũng nhận được và phải xử lý lại thông tin, dù nó ở cách xa sự cố bao nhiêu hop. Ranh giới area chính là công cụ chính để giới hạn phạm vi flood này lại, nhưng bên trong một area, control-plane failure domain gần như trùng với toàn bộ area.
Với BGP thì cơ chế truyền tin khác hẳn: mỗi router chỉ quảng bá cho neighbor route tốt nhất mà chính nó đang dùng, chứ không gửi nguyên một bản sao toàn bộ database như link-state. Một thay đổi ở xa vì vậy thường bị "hấp thụ" dần qua từng hop — router nào không đổi route tốt nhất của mình thì không cần thông báo tiếp cho neighbor kế tiếp, và các kỹ thuật như route summarization/aggregation càng làm giảm thêm số router phải biết tới thay đổi đó. Đây chính là lý do các thiết kế fabric hiện đại (sẽ được phân tích ở các phần sau của tài liệu này) thường ưu tiên BGP làm control plane chính thay vì dùng thuần một giao thức link-state — mục tiêu là chủ động thu hẹp control-plane failure domain xuống gần với transport failure domain nhất có thể, thay vì để cả hai lệch pha nhau như trong ví dụ mạng switched ở trên.
💡 Hình dung như thế này: transport failure domain giống như một bóng đèn trong nhà bị cháy — chỉ căn phòng đó tối, các phòng khác không bị ảnh hưởng gì. Control-plane failure domain giống như hệ thống báo cháy trung tâm của cả tòa nhà — chỉ cần một cảm biến ở tầng 3 báo động, toàn bộ tòa nhà phải kích hoạt quy trình kiểm tra, kể cả tầng 1 và tầng 10 vốn chẳng liên quan gì đến đám cháy đó.
3. Scale Up vs Scale Out: hai cách mở rộng ứng dụng
Xét một server (gọi là server G) chạy một ứng dụng phục vụ user từ bên ngoài qua TCP/QUIC. Ứng dụng này thường gồm nhiều thành phần: database (DB), business logic (BL), và rendering engine (RE) — tất cả cùng nằm trên một server.
Scale Up (mở rộng theo chiều dọc):
Để phục vụ nhiều user hơn, cách đơn giản là "nhồi" thêm tài nguyên vào chính server đó — thêm processor, thêm storage, thêm network capability — cho đến khi hết chỗ chứa. Có thể ghép thêm server thứ hai cạnh nó (server aggregation / multi-processor) để coi như một server lớn hơn.
Về phía hạ tầng mạng, cách phổ biến để scale up là mua chassis box, lắp line card vào, chừa slot trống để lắp thêm sau; hoặc dùng stackable unit nối với nhau qua một mini-fabric rồi coi như một thiết bị lớn.
Vấn đề của scale up: mạng được mua theo chunk lớn (theo kích thước chassis), trong khi tốc độ tăng trưởng của business lại không đều. Kết quả là:
- Overshoot: có những giai đoạn network capacity vượt quá nhu cầu thực tế của business → tiền đầu tư vào mạng bị "chôn" không dùng tới.
- Undershoot: có những giai đoạn network trở thành nút thắt (bottleneck), khiến business không thể tăng trưởng nhanh như khả năng thực tế → mất cơ hội kinh doanh.
Sự lệch pha (mismatch) này gây áp lực lên business ở cả hai chiều — vừa overpay, vừa lost opportunity.
Vì sao chi phí scale up lại tăng theo bậc thang chứ không mượt
Nguyên nhân sâu xa của overshoot/undershoot nằm ở kiến trúc bên trong của chính thiết bị. Một chassis switch/router có một backplane (hay switching fabric nội bộ) chịu trách nhiệm chuyển traffic giữa các line card cắm vào nó; băng thông của backplane này là cố định theo thiết kế phần cứng, không phải vô hạn. Khi còn slot trống, thêm line card gần như là chi phí biên nhỏ và tuyến tính. Nhưng khi băng thông backplane bắt đầu chạm ngưỡng — dù vẫn còn slot vật lý trống — thêm line card mới không còn mang lại thêm capacity thực sự nữa, vì bản thân "đường ống" bên trong đã nghẽn. Lúc đó, cách duy nhất để tiếp tục scale là thay nguyên cả chassis bằng một model có backplane lớn hơn — một khoản đầu tư rời rạc (lumpy), tốn kém, và thường đòi hỏi downtime hoặc migration phức tạp, khác hẳn việc chỉ mua thêm một line card. Với thiết bị dạng stackable unit, vấn đề tương tự xảy ra ở cấp độ khác: các unit nối với nhau qua một vài cáp/cổng stacking tốc độ cố định, nên khi traffic đi giữa các unit trong stack tăng lên, chính các cổng stacking đó lại trở thành điểm nghẽn nội bộ, y hệt backplane của chassis.
Đây là lý do vì sao đường cong chi phí của scale up không phải một đường thẳng mượt theo nhu cầu, mà là một chuỗi bậc thang: chi phí gần như phẳng trong lúc còn slot/backplane trống, rồi nhảy vọt mỗi khi phải đổi sang thế hệ chassis lớn hơn — và chính những bước nhảy này tạo ra overshoot (mua trước nhu cầu thực tế nhiều bậc) hoặc undershoot (chờ đến lúc thực sự cần mới nâng cấp, trong lúc đó network đã là bottleneck).
Scale Out (mở rộng theo chiều ngang):
Thay vì nhồi tất cả vào một server, tách riêng từng thành phần ứng dụng ra các server độc lập: database đặt trên server G, business logic đặt trên server H, rendering engine đặt trên server K. Mỗi thành phần giờ có thể scale độc lập — hết chỗ ở server chạy DB thì thêm server thứ hai, thậm chí shard database; hết processor ở server RE thì thêm một bản sao và đặt load balancer phân traffic giữa hai bản sao.
Cách này cho phép mở rộng ứng dụng mà không cần liên tục mua box ngày càng lớn hơn. Về bản chất, thay vì trả tiền cho một bước nhảy lớn (đổi chassis), scale out cho phép thêm capacity theo từng đơn vị nhỏ, gần như tuyến tính với nhu cầu thực tế — mỗi server mới thêm vào chỉ giải quyết đúng phần bị thiếu (ví dụ chỉ thêm server RE khi RE quá tải, không cần đụng tới DB hay BL).
Ý tưởng "nhiều đơn vị nhỏ giống hệt nhau thay cho một khối lớn" không phải là mới
Việc thay một thiết bị lớn, đắt, khó mở rộng bằng nhiều đơn vị nhỏ, rẻ, giống hệt nhau ghép lại — vốn đã có tiền lệ lâu đời trong ngành viễn thông chứ không phải khái niệm riêng của điện toán đám mây. Năm 1953, kỹ sư Charles Clos của Bell Labs công bố nghiên cứu "A Study of Non-Blocking Switching Networks" trên Bell System Technical Journal, chứng minh rằng có thể ghép nhiều tầng crossbar switch nhỏ lại với nhau theo một cấu trúc toán học cụ thể để đạt được đặc tính non-blocking — nghĩa là bất kỳ đầu vào rảnh nào cũng luôn kết nối được tới bất kỳ đầu ra rảnh nào — giống hệt như thể đó là một crossbar switch khổng lồ duy nhất, dù trên thực tế không tồn tại thiết bị lớn như vậy. Ý tưởng cốt lõi này — dùng toán học sắp xếp nhiều đơn vị nhỏ để giả lập một khối lớn không-nghẽn — sau này trở thành nền tảng lý thuyết cho chính câu hỏi mà tài liệu này đang dẫn tới: liệu có thể áp dụng cùng một logic "scale out" cho hạ tầng mạng, giống như đã áp dụng cho server, hay không.
💡 Hình dung như thế này: scale up giống như thuê một đầu bếp giỏi làm hết mọi việc trong một gian bếp — khách đông hơn thì chỉ có cách thuê đầu bếp giỏi hơn hoặc mở rộng chính gian bếp đó. Scale out giống như tách gian bếp thành các trạm chuyên biệt: trạm sơ chế, trạm nấu, trạm trang trí món — mỗi trạm có thể thuê thêm người riêng khi quá tải, nhưng đổi lại các trạm phải chuyển nguyên liệu và món ăn qua lại với nhau liên tục, nhiều hơn hẳn so với khi mọi việc nằm trong tay một đầu bếp duy nhất.
4. Traffic Bắc-Nam (North-South) vs Đông-Tây (East-West)
Khi ứng dụng được scale out, một user vào request tại server K sẽ khiến K phải gọi ngược vào business logic server (H) để lấy dữ liệu dựng trang, và H lại phải gọi tiếp tới database server. Nghĩa là với mỗi byte traffic đi vào từ bên ngoài (northbound), mạng nội bộ phải cõng thêm nhiều byte traffic đi qua lại giữa các server — số liệu ngành đo được (ví dụ Cisco Global Cloud Index) cho thấy traffic đông-tây thường chiếm phần lớn tổng traffic trong data center, tương đương tỷ lệ đông-tây so với bắc-nam vào khoảng gấp 4-6 lần trong các báo cáo phổ biến, dù con số cụ thể dao động khá nhiều tùy loại ứng dụng và mức độ phân rã service.
Cách gọi tên hướng traffic:
- North-South: traffic giữa server (phía nam) và mạng bên ngoài (phía bắc).
- East-West: traffic chạy giữa các server với nhau.
Khi scale out, phần lớn traffic north-south trước đây được thay thế bằng một lượng traffic east-west lớn hơn hẳn, tạo áp lực rất lớn lên hạ tầng mạng và buộc phải scale mạnh các router ở giữa để gánh lượng traffic east-west này.
Vì sao một request lại nhân bản thành nhiều lượt gọi east-west
Chuỗi gọi K → H → DB ở trên chỉ là ví dụ đơn giản nhất — một request tuần tự qua ba tầng. Trong kiến trúc microservices thực tế, một service ở tầng trên thường phải gọi song song nhiều service con khác nhau (fan-out) rồi gộp kết quả lại (fan-in) trước khi trả về cho user: ví dụ RE có thể phải gọi đồng thời service giỏ hàng, service khuyến mãi, service gợi ý sản phẩm, mỗi service đó lại có thể gọi tiếp xuống service khác hoặc database riêng của nó. Mỗi lượt gọi như vậy là một round-trip TCP/QUIC hoàn chỉnh — có request, có response, có thể có thêm cả bước xác thực hoặc mã hoá riêng — nên độ sâu (depth) và độ rộng (fan-out) của chuỗi gọi càng lớn thì lượng traffic đông-tây sinh ra từ một request gốc duy nhất càng tăng, và mức tăng này không tuyến tính theo số lượng service mà theo tích của depth và fan-out ở từng tầng.
Hệ quả trực tiếp với thiết kế mạng: các thiết bị core/aggregation vốn trước đây chỉ cần được sizing theo lượng traffic ra/vào (north-south), giờ phải được sizing theo một chỉ số khác gọi là oversubscription ratio — tỷ lệ giữa tổng băng thông các cổng hướng xuống (downlink, nối tới server) so với tổng băng thông các cổng hướng lên (uplink, nối lên core). Một thiết kế tối ưu cho traffic ra/vào có thể chấp nhận oversubscription ratio cao (nhiều server chia nhau ít băng thông uplink), nhưng khi phần lớn traffic lại chạy ngang giữa các server, tỷ lệ oversubscription cao đó biến uplink thành nút thắt cổ chai ngay lập tức — đây chính là động lực khiến các kiến trúc mạng hiện đại hướng tới mô hình gần như non-blocking thay vì mô hình phân cấp truyền thống vốn được tối ưu cho lưu lượng bắc-nam.
5. Ba thách thức của thiết kế mạng truyền thống
Từ những phân tích trên, thiết kế mạng phân cấp truyền thống gặp ba vấn đề chính:
- Khớp tốc độ scale của mạng và server với tốc độ tăng trưởng business — cần tránh overshoot/undershoot vì cả hai đều gây tốn kém và giảm tính linh hoạt.
- Đáp ứng lượng traffic east-west tăng vọt do service bị disaggregate — với mỗi phần traffic đi vào từ hướng bắc, mạng nội bộ phải cõng thêm gấp khoảng 4-6 lần lượng đó dưới dạng traffic đông-tây.
- Giải quyết vấn đề scale ở network core — càng mở rộng, hai router core càng phải lớn hơn, đến khi hết slot trong chassis thì phải mua chassis lớn hơn hoặc ghép nhiều thiết bị bằng các giao thức độc quyền như M-LAG để giả lập thành một thiết bị — đây là hướng tiếp cận có giới hạn (run out of potential scale).
Vì sao ba thách thức này không tách rời mà cộng hưởng lẫn nhau
Nhìn riêng lẻ, mỗi thách thức trông như một bài toán kỹ thuật khác nhau — một cái về tài chính (overshoot/undershoot), một cái về lưu lượng (east-west), một cái về phần cứng (giới hạn chassis). Nhưng thực chất cả ba đều bắt nguồn từ đúng một giả định thiết kế: mạng được xây theo mô hình phân cấp cứng, nơi một vài thiết bị core/aggregation đóng vai trò "điểm hội tụ" cho toàn bộ traffic đi qua. Chính giả định đó khiến ba vấn đề khuếch đại lẫn nhau thay vì cộng dồn đơn thuần: traffic east-west tăng (thách thức 2) đổ dồn áp lực lên đúng những thiết bị core đang bị giới hạn bởi backplane (thách thức 3), và vì backplane chỉ nâng cấp được theo bậc thang lớn (thách thức 1), đội vận hành buộc phải đoán trước một mức tăng trưởng traffic đông-tây trong tương lai để mua đủ chassis ngay từ bây giờ — một bài toán dự báo gần như bất khả thi, vì tốc độ phân rã service (số lượng microservices, độ sâu fan-out) thường do đội phát triển ứng dụng quyết định, không nằm trong tầm kiểm soát của đội hạ tầng mạng.
Vì sao ghép nhiều switch bằng M-LAG chỉ là giải pháp vá tạm, không phải scale out thật
Thách thức thứ ba nhắc tới M-LAG (Multi-Chassis Link Aggregation) — một kỹ thuật cho phép hai switch vật lý riêng biệt cùng tham gia một nhóm link aggregation (LAG) duy nhất với thiết bị downstream, khiến thiết bị đó "nhìn thấy" hai switch như thể chỉ là một switch logic duy nhất. Về cơ chế, hai switch trong cặp M-LAG trao đổi trạng thái với nhau qua một liên kết riêng gọi là peer link (hoặc ICL — Inter-Chassis Link), đồng bộ bảng MAC và trạng thái các cổng LAG để cả hai cùng "diễn" đúng vai một thiết bị thống nhất.
Vấn đề nằm ở chỗ đây vẫn là hai control plane hoàn toàn độc lập đang giả lập một control plane chung, chứ không thực sự hợp nhất — và sự giả lập đó có ba giới hạn cố hữu. Thứ nhất, giao thức đồng bộ giữa hai switch trong một cặp M-LAG là độc quyền theo từng hãng (Cisco gọi là vPC, Arista gọi là MLAG, Juniper gọi là MC-LAG,...), nên không thể ghép M-LAG giữa hai switch khác hãng với nhau, gây khóa chặt vào một nhà cung cấp (vendor lock-in). Thứ hai, hầu hết các triển khai M-LAG chỉ hỗ trợ đúng hai thành viên trong một cặp — nghĩa là kỹ thuật này giúp nhân đôi khả năng chịu lỗi (redundancy) chứ không giúp mở rộng số lượng thiết bị core theo yêu cầu tăng trưởng traffic, nên vẫn phải quay lại chuyện đổi chassis lớn hơn khi hai switch trong cặp đã đầy tải. Thứ ba, nếu peer link giữa hai switch bị đứt trong khi cả hai vẫn còn kết nối bình thường lên phía trên, mỗi switch có thể tưởng nhầm mình đang là thiết bị duy nhất còn sống và tiếp tục forward traffic độc lập — tình huống gọi là split-brain, dễ dẫn tới duplicate traffic hoặc mất đồng bộ bảng MAC nếu cơ chế phát hiện lỗi (thường dựa trên keepalive qua một đường quản lý riêng) không kịp phản ứng.
💡 Hình dung như thế này: M-LAG giống như hai người sinh đôi mặc chung một bộ đồng phục và đứng cạnh nhau để khách hàng tưởng là đang giao dịch với một nhân viên duy nhất — họ phải liên tục thì thầm trao đổi qua lại (peer link) để giữ đúng kịch bản đồng bộ. Nhưng đó vẫn là hai người thật, có giới hạn là chỉ ghép được đúng một cặp, chỉ hoạt động nếu cả hai học chung một "kịch bản nội bộ" của cùng một công ty đào tạo (cùng hãng thiết bị) — và nếu đường dây thì thầm giữa họ bị cắt mà không ai nhận ra, cả hai có thể cùng lúc tưởng người kia đã nghỉ việc rồi tự ý hành động theo ý mình, làm khách hàng bối rối vì nhận được hai câu trả lời khác nhau.
Từ ba vấn đề trên dẫn tới câu hỏi cốt lõi: đã scale out được server và service, vậy tại sao không tìm cách scale out chính mạng theo cùng cách đó? Đây chính là nội dung sẽ được nói tới ở phần tiếp theo về data center fabric.
Nguồn tham khảo
Nguồn gốc: Understanding Data Center Fabrics, Part 1: Justifying Fabrics — kênh Packet Pushers.
Ghi chú fact-check (truy cập 2026-07-14): tỷ lệ traffic east-west:north-south "1:10 đến 1:100" nêu ở mục 4 không tìm thấy một benchmark chính thức duy nhất nào trích dẫn đúng con số này. Các số liệu ngành gần nhất tìm được đều thấp hơn: Cisco Global Cloud Index từng ước tính east-west chiếm khoảng 76% (có bản báo cáo khác nêu tới 86% vào năm 2020) tổng traffic trong data center, tương đương tỷ lệ đâu đó quanh 3:1-6:1 so với north-south chứ không phải 10:1-100:1 (Cisco blog); một nghiên cứu của VMware cũng chỉ ghi nhận traffic east-west lớn gấp khoảng 4 lần traffic north-south. Vì vậy nên xem tỷ lệ "1:10 đến 1:100" trong tài liệu này là quan sát/kinh nghiệm thực tế phổ biến trong ngành khi mô tả xu hướng bùng nổ traffic nội bộ lúc scale out — không phải một số đo tuyệt đối hay benchmark chính thức duy nhất được cả ngành thống nhất trích dẫn.