Data center নেটওয়ার্ক — leaf-spine আর load balancer

১ · Data center কী — rack, server, ToR switch আর বিদ্যুৎ-ঠান্ডার সীমা

আপনি bKash-এ টাকা পাঠালেন, YouTube-এ ভিডিও দেখলেন, বা কোনো AI সহকারীকে প্রশ্ন করলেন — প্রতিটির পেছনে আছে একটি data center: একটি ভবন বা হলঘর, যেখানে সারি সারি লোহার আলমারিতে হাজার হাজার সার্ভার বসানো। আলমারিগুলোকে বলে rack. একটি সাধারণ rack-এ কয়েক ডজন সার্ভার থাকে, আর rack-এর ওপরের দিকে বসে একটি switch — ToR switch (top-of-rack) — rack-এর সব সার্ভার যার সাথে ছোট তারে যুক্ত।

নেটওয়ার্ক প্রকৌশলীর কাছে data center-এর তিনটি বাস্তব সীমা আছে:

• বিদ্যুৎ: প্রতিটি rack কত kilowatt নিতে পারবে, তা ভবনের নকশায় ঠিক করা। GPU-ভরা rack বহুগুণ বিদ্যুৎ টানে। বিদ্যুৎ গেলে UPS আর জেনারেটর — load-shedding-এর দেশে এর গুরুত্ব আমরা ভালোই বুঝি।
• ঠান্ডা রাখা: খরচ হওয়া প্রায় সব বিদ্যুৎ তাপ হয়ে বেরোয়; rack-গুলো এমনভাবে সাজানো হয় যে সামনে ঠান্ডা বাতাস ঢোকে, পেছনে গরম বাতাস বেরোয়। মোট বিদ্যুৎ ÷ IT যন্ত্রের বিদ্যুৎ — এই অনুপাতকে বলে PUE; ১.০ আদর্শ।
• জায়গা আর তার: নেটওয়ার্কের নকশা যত নিয়মিত, হাজারো তার লাগানো আর ভুল খোঁজা তত সহজ।

Data center মোটামুটি তিন ধরনের:

বাংলাদেশেও সরকারি জাতীয় data center আর বেসরকারি বাণিজ্যিক data center আছে; ব্যাংক আর মোবাইল অপারেটরদের নিজস্ব data center ও DR site থাকে। এদের কেউ কেউ নিজেদের নকশাকে বিদ্যুৎ ও ঠান্ডার বিকল্প ব্যবস্থার মানদণ্ডে “Tier III” বা সমমানের বলে উল্লেখ করে — কোন ভবনের সনদ কী, তা হালনাগাদ অফিসিয়াল তথ্যে দেখে নেওয়াই নিরাপদ। নেটওয়ার্কের নীতিগুলো ছোট সার্ভার-ঘর থেকে বিশাল ক্যাম্পাস পর্যন্ত একই।

২ · ট্রাফিকের দিক — north-south বনাম east-west

Data center-এর ছবি আঁকলে বাইরের ইন্টারনেট সাধারণত ওপরে, সার্ভার নিচে। তাই বাইরে থেকে ভেতরে আসা-যাওয়া ট্রাফিককে বলে north-south, আর ভেতরের সার্ভারে-সার্ভারে ট্রাফিককে east-west.

ধরুন আপনি একটি অনলাইন শপে “অর্ডার দিন” চাপলেন। সামনের সেবা কথা বলে login, cart, দাম, স্টক, পেমেন্ট আর সুপারিশের আলাদা আলাদা ছোট সেবার সাথে — এই নকশাকে বলে microservices. প্রতিটি সেবা আবার ডেটাবেস আর cache-এর কাছে যায়, ডেটাবেস তিনটি কপিতে লেখে। বাইরের একটি ছোট অনুরোধ ভেতরে কয়েক ডজন বা শত শত বার্তা জন্ম দিতে পারে।

এর সাথে আছে নেটওয়ার্কের ওপারের storage, ব্যাকআপ, বড় ডেটা বিশ্লেষণ, আর মেশিন লার্নিং training, যেখানে হাজার হাজার GPU প্রতি ধাপে বিপুল ডেটা বিনিময় করে। শিল্প-প্রতিবেদন আর বড় কোম্পানির প্রকাশিত অভিজ্ঞতা অনুযায়ী আধুনিক data center-এ east-west ট্রাফিকই বাইরের ট্রাফিকের চেয়ে অনেক বেশি — সঠিক অনুপাত কাজের ধরন ভেদে আলাদা।

৩ · পুরোনো তিন-স্তরের নকশা — আর কেন সেটি ভেঙে পড়ল

বহু বছর enterprise data center-এর প্রচলিত নকশা ছিল তিন-স্তরের (three-tier): নিচে access switch (প্রতিটি rack-এ), মাঝে aggregation (বা distribution) switch-এর জোড়া, ওপরে কয়েকটি বড় core switch বা router. Access আর aggregation-এর মাঝে সাধারণত layer 2 (VLAN), ওপরে layer 3.

              [ Core 1 ]════════[ Core 2 ]            ← বড়, দামি chassis
               ║       ╲      ╱       ║
          [ Agg 1 ]═════[ Agg 2 ]     ...           ← aggregation জোড়া
          ║   ║   ╲    ╱   ║   ║
       [Acc1][Acc2] .... [Acc3][Acc4]               ← প্রতিটি rack-এ access
        │││   │││         │││   │││
       সার্ভার                                       (একটি করে link STP-তে বন্ধ)

উত্তর-দক্ষিণ ট্রাফিকের জন্য নকশাটি যুক্তিসংগত ছিল, কিন্তু তিনটি সমস্যা ক্রমশ বড় হলো:

1. STP অর্ধেক link বন্ধ রাখে। প্রতিটি access switch দুটি aggregation switch-এ যুক্ত, যাতে একটি গেলে অন্যটি থাকে। কিন্তু layer 2-তে এতে loop তৈরি হয়, আর STP (পর্ব ১২, Ethernet আর switch) loop ভাঙতে একটি link-কে blocked রাখে। কেনা তারের অর্ধেক বসে থাকে, আর link নষ্ট হলে নতুন গাছ বানানো পর্যন্ত ট্রাফিক থামতে পারে। (MLAG বা vPC-র মতো vendor-কৌশলে দুটি switch-কে একটি LACP bundle-এর দুই প্রান্ত বানিয়ে এটি কিছুটা মেটানো হতো।)
2. Oversubscription প্রতিটি স্তরে গুণ হয়। নিচের মোট bandwidth আর ওপরের মোট bandwidth-এর অনুপাতই oversubscription. ধরুন access-এ ৪৮টি সার্ভার ×১০G = ৪৮০G, ওপরে STP-র পরে কার্যত ১০G — অনুপাত ৪৮:১; aggregation থেকে core-এ আবার কয়েক গুণ। দূরের rack-এর সাথে কথা বললে প্রতিটি সার্ভার পায় সামান্য অংশ।
3. Chokepoint আর বড় ব্যর্থতার এলাকা। দুই pod-এর মাঝের সব ট্রাফিক কয়েকটি core যন্ত্র দিয়ে যায়; একটি aggregation switch গেলে pod-এর অর্ধেক ক্ষমতা যায়; বড় layer-2 এলাকায় একটি broadcast storm সব অচল করতে পারে। বাড়াতে হলে আরও বড়, আরও দামি chassis — এটি scale-up, যার সীমা আছে।

৪ · Clos আর leaf-spine — প্রতিটি leaf প্রতিটি spine-এ

সমাধান এল একটি পুরোনো ধারণা থেকে। ১৯৫৩ সালে Bell Labs-এর প্রকৌশলী Charles Clos টেলিফোন এক্সচেঞ্জের জন্য দেখান যে অনেকগুলো ছোট switch কয়েকটি স্তরে সাজিয়ে একটি বিশাল, প্রায় বাধাহীন switch বানানো যায় — এই নকশাকে এখন বলে Clos network. অর্ধ শতাব্দীরও বেশি পরে data center একই চিন্তা নিল: একটি বিশাল দামি switch নয়, অনেকগুলো একই রকম সস্তা switch.

দুই স্তরের রূপকে বলে leaf-spine:

• Leaf = প্রতিটি rack-এর ToR switch; নিচে সার্ভার, ওপরে প্রতিটি spine-এ একটি করে uplink.
• Spine = শুধু leaf-দের মাঝে ট্রাফিক বহন করে; spine-এ কোনো সার্ভার নেই, spine-এ spine-এ সরাসরি যোগও নেই।
• নিয়ম একটাই: প্রতিটি leaf প্রতিটি spine-এ যুক্ত।

   [Spine1]   [Spine2]   [Spine3]   [Spine4]
      ║║║║       ║║║║       ║║║║       ║║║║     ← প্রতিটি spine থেকে প্রতিটি leaf-এ ১টি link
   ╔══╩╩╩╩═══════╩╩╩╩═══════╩╩╩╩═══════╩╩╩╩══╗    (পূর্ণ জাল: ৮ leaf × ৪ spine = ৩২টি link)
   [Leaf1]   [Leaf2]   ....   [Leaf7]   [Leaf8]  ← প্রতিটি leaf-এর ৪টি uplink
    │││││     │││││            │││││     │││││
   rack 1    rack 2           rack 7    rack 8

এই একটি নিয়ম থেকে চারটি সুবিধা আসে:

1. যেকোনো দুই rack-এর দূরত্ব সমান: leaf → spine → leaf, মাঝে মাত্র দুটি link — সবার জন্য প্রায় একই latency.
2. সব link একসাথে কাজ করে: Leaf ১ থেকে leaf ৭-এ ৪টি সমান পথ; layer 3 routing এগুলোকে ECMP (পর্ব ২২, Routing-এর ভিত্তি) হিসেবে flow hashing দিয়ে ভাগ করে — কিছুই বসে থাকে না।
3. বাড়ানো সহজ (scale-out): আরও সার্ভার? Leaf যোগ করুন। আরও ভেতরের bandwidth? Spine যোগ করুন — যতক্ষণ port আছে।
4. ব্যর্থতা ছোট: একটি spine গেলে প্রতিটি leaf তার ক্ষমতার ১/N হারায়।

এবার দেখি rack ১-এর একটি সার্ভার থেকে rack ৭-এর একটি সার্ভারে একটি packet কীভাবে যায়। এখানে fabric পুরোটাই layer 3 — প্রতিটি leaf নিজেই তার rack-এর default gateway (অংশ ৬-এ বিস্তারিত)।

৫ · Fabric-এর হিসাব — oversubscription, bisection bandwidth, fat-tree আর ব্যর্থতা

Oversubscription — হাতে কষা

একটি leaf-এ ৪৮টি ২৫G port সার্ভারের দিকে আর ৮টি ১০০G port ৮টি spine-এর দিকে:

১:১ মানে “non-blocking” — rack-এর বাইরেও পূর্ণ গতি। কেন সবাই ১:১ রাখে না? দাম। Uplink port, optics আর spine সবচেয়ে দামি অংশ, আর বাস্তবে সব সার্ভার একসাথে পূর্ণ গতিতে বাইরে পাঠায় না। সাধারণ ওয়েব সেবায় ৩:১ চলতে পারে; storage বা AI training-এর fabric প্রায়ই ১:১-এর কাছাকাছি রাখা হয়।

Bisection bandwidth

নেটওয়ার্ককে ঠিক মাঝখান দিয়ে দুই সমান ভাগে কাটলে দুই ভাগের মাঝে সবচেয়ে খারাপ ক্ষেত্রে যত bandwidth পাওয়া যায়, সেটাই bisection bandwidth. বাঁ অর্ধেকের সব সার্ভার একসাথে ডান অর্ধেকে পাঠালে নেটওয়ার্ক মোট কত বইতে পারবে — এটি তার মাপ। Leaf-spine-এ অর্ধেক leaf-এর মোট uplink-ই সেই সীমা: ১৬টি leaf, প্রতিটির uplink ৮০০G হলে ৮ × ৮০০G = ৬.৪ Tbps.

Switch-এর port সংখ্যা থেকে সর্বোচ্চ আকার

একটি switch-এ কয়টি port আছে, তাকে বলে তার radix; ধরা যাক k. দুই স্তরের leaf-spine-এ প্রতিটি spine-এর প্রতিটি port একটি leaf-এ যায়, তাই সর্বোচ্চ k-টি leaf. ১:১ রাখতে প্রতিটি leaf-এর অর্ধেক port নিচে, অর্ধেক ওপরে — তাই সর্বোচ্চ সার্ভার k × k/২ = k²/২. ৬৪-port switch দিয়ে ২,০৪৮টি — একটি বড় অফিসের জন্য যথেষ্ট, hyperscale-এর জন্য নয়। তখন যোগ হয় তৃতীয় স্তর।

২০০৮ সালে Al-Fares ও সহকর্মীদের একটি পরিচিত গবেষণাপত্র দেখায় যে শুধু একই রকম সস্তা k-port switch দিয়ে তিন স্তরের একটি fat-tree বানানো যায়, যার সব স্তরে ১:১ ক্ষমতা। গঠনটি এরকম:

• মোট k-টি pod. প্রতিটি pod-এ k/২টি edge (leaf) আর k/২টি aggregation switch.
• প্রতিটি edge switch-এর k/২ port সার্ভারে, k/২ port pod-এর প্রতিটি aggregation switch-এ।
• প্রতিটি aggregation switch-এর k/২ port নিচে, k/২ port ওপরে core-এ। Core switch (k/২)² = k²/৪টি, প্রতিটির k-টি port প্রতিটি pod-এ একটি করে।

এবার এসব হিসাব একসাথে একটি simulator-এ। প্রথম fabric ওপরের উদাহরণ; দ্বিতীয়টি একটু পুরোনো ধাঁচের — ১০G সার্ভার, ৪টি ৪০G uplink. শেষে k-এর কয়েকটি মানে দুই স্তর আর fat-tree-র তুলনা।

// Leaf-spine fabric calculator: every leaf has one uplink to every spine.
function fabric(name, leaves, spines, down, downG, upG, spinePorts) {
  const serverBw = down * downG, upBw = spines * upG;        // per leaf, Gbps
  const ratio = serverBw / upBw;                              // oversubscription
  const bisect = Math.min(leaves / 2 * upBw, leaves / 2 * serverBw);
  const left = (spines - 1) * upG;                            // uplink after 1 spine dies
  console.log(name);
  console.log("  servers now " + leaves * down + ", max with " + spinePorts +
    "-port spines " + spinePorts * down + " (" + spinePorts + " leaves)");
  console.log("  per leaf: down " + serverBw + "G, up " + upBw + "G -> oversubscription " +
    ratio.toFixed(2) + ":1");
  console.log("  bisection bandwidth " + (bisect / 1000).toFixed(1) + " Tbps");
  console.log("  one spine down: uplink " + left + "G (" + (100 * left / upBw).toFixed(1) +
    "% left), ratio " + (serverBw / left).toFixed(2) + ":1");
}
fabric("A) 16 leaves, 8 spines, 48x25G down, 8x100G up", 16, 8, 48, 25, 100, 64);
fabric("B) 20 leaves, 4 spines, 48x10G down, 4x40G up", 20, 4, 48, 10, 40, 32);
console.log("k-port switches: 2-tier leaf-spine (k/2 down per leaf) vs 3-tier fat tree");
console.log("    k   2-tier hosts   fat-tree hosts   fat-tree switches");
for (const k of [4, 8, 16, 48, 64]) {
  const two = k * k / 2, fat = k ** 3 / 4, sw = 5 * k * k / 4;
  console.log(String(k).padStart(5) + String(two).padStart(15) + String(fat).padStart(17) +
    String(sw).padStart(20));
}

A) 16 leaves, 8 spines, 48x25G down, 8x100G up
  servers now 768, max with 64-port spines 3072 (64 leaves)
  per leaf: down 1200G, up 800G -> oversubscription 1.50:1
  bisection bandwidth 6.4 Tbps
  one spine down: uplink 700G (87.5% left), ratio 1.71:1
B) 20 leaves, 4 spines, 48x10G down, 4x40G up
  servers now 960, max with 32-port spines 1536 (32 leaves)
  per leaf: down 480G, up 160G -> oversubscription 3.00:1
  bisection bandwidth 1.6 Tbps
  one spine down: uplink 120G (75.0% left), ratio 4.00:1
k-port switches: 2-tier leaf-spine (k/2 down per leaf) vs 3-tier fat tree
    k   2-tier hosts   fat-tree hosts   fat-tree switches
    4              8               16                  20
    8             32              128                  80
   16            128             1024                 320
   48           1152            27648                2880
   64           2048            65536                5120

ব্যর্থতায় তিন-স্তর বনাম leaf-spine

একই ব্যর্থতায় দুই নকশা কী করে, পাশাপাশি দেখি। বাঁ দিকে একটি access switch (A1) দুটি aggregation switch-এ ১০G করে যুক্ত; ডান দিকে একটি leaf (L1) চারটি spine-এ ৪০G করে যুক্ত।

৬ · Fabric-এর routing — L3 পর্যন্ত ToR, BGP underlay আর VXLAN-EVPN overlay

Leaf-spine-এ প্রতিটি leaf সাধারণত একটি layer-3 switch: rack-এর সার্ভারদের subnet-এর gateway সে নিজেই, আর leaf-spine-এর প্রতিটি link একটি ছোট point-to-point IP link. ফলে layer 2-এর এলাকা একটি rack-এর ভেতরে সীমিত, STP-র দরকার প্রায় নেই, broadcast storm rack-এর বাইরে যায় না। একে বলে “L3 to the ToR”.

Leaf আর spine-এর মাঝে route কে জানায়? এই ভৌত IP নেটওয়ার্ককে বলে underlay, আর এর routing protocol দুই রকম হয়:

• OSPF বা IS-IS (পর্ব ২৪, Link state routing) — ছোট-মাঝারি fabric-এ প্রচলিত, পরিচিত আর সরল।
• BGP (পর্ব ২৫, BGP আর ইন্টারনেটের গঠন) — বড় fabric-এ জনপ্রিয়। RFC 7938 (২০১৬) এর নকশা বর্ণনা করে: প্রতিটি leaf আর spine-স্তর আলাদা private ASN পায়, প্রতিটি link-এ eBGP session. BGP বিপুল সংখ্যক route সামলাতে অভ্যস্ত, নীতি দিয়ে নিয়ন্ত্রণ সহজ, আর ব্যর্থতার প্রভাব কাছাকাছি থাকে। BGP-র multipath বিকল্প চালু থাকলে চারটি spine থেকে শেখা একই prefix ECMP হয়ে যায়।

তাহলে layer 2 লাগলে? — VXLAN-EVPN overlay

সব অ্যাপ layer 3-এ খুশি নয়। একটি virtual machine অন্য rack-এ সরালে তার IP বদলানো যায় না; কিছু পুরোনো cluster software একই subnet চায়; আর cloud-এ প্রতিটি গ্রাহক (tenant) নিজের আলাদা নেটওয়ার্ক চায়, যার ঠিকানা অন্যের সাথে মিলেও যেতে পারে। সমাধান overlay: IP underlay-এর ওপর tunnel দিয়ে virtual layer 2.

পর্ব ১৩-এ (VLAN আর trunking) দেখেছেন, VXLAN Ethernet frame-কে UDP-র ভেতরে মুড়ে পাঠায়, আর ২৪ bit-এর VNI দিয়ে প্রায় ১.৬৮ কোটি আলাদা segment দেয় — VLAN-এর ৪,০৯৪-এর সীমা আর থাকে না। Tunnel-এর দুই প্রান্ত সাধারণত leaf switch নিজেই (বা সার্ভারের ভেতরের virtual switch); এই প্রান্তকে বলে VTEP.

বাকি প্রশ্ন: কোন MAC বা IP কোন VTEP-এর পেছনে আছে, তা সবাই জানবে কীভাবে? পুরোনো উপায় ছিল flood করে শেখা। আধুনিক উপায় EVPN: BGP-কেই control plane বানিয়ে প্রতিটি leaf ঘোষণা করে “এই MAC আর IP আমার পেছনে, এই VNI-তে” (মূল মান RFC 7432, VXLAN-এর সাথে ব্যবহার RFC 8365). ফলে অচেনা ঠিকানার জন্য flooding কমে, আর প্রতিটি leaf একই anycast gateway ঠিকানা রাখতে পারে — VM যে rack-এই যাক, gateway একই।

৭ · Data center-এর transport — incast, elephant ও mice, ECMP collision আর RDMA

Data center-এর ভেতরে RTT মাইক্রোসেকেন্ডের ঘরে, link খুব দ্রুত, আর অনেক switch-এর buffer তুলনামূলক ছোট। ইন্টারনেটের জন্য বানানো TCP এখানে কিছু অদ্ভুত সমস্যায় পড়ে।

Incast — সবাই একসাথে উত্তর দিলে

একটি search বা ডেটাবেস প্রশ্ন প্রায়ই এভাবে চলে: একটি aggregator সার্ভার একসাথে ৪০টি worker-কে প্রশ্ন পাঠায়, সবাই প্রায় একই মুহূর্তে উত্তর দেয় — সব উত্তর গিয়ে পড়ে aggregator-এর ToR port-এ। এই many-to-one ধাঁচকে বলে incast.

একটি worker দেরি করলে পুরো উত্তর দেরি করে, কারণ aggregator সবার উত্তরের অপেক্ষায় থাকে — তাই data center-এ গড় নয়, tail latency (সবচেয়ে ধীর ১% বা ০.১%) আসল মাপ। প্রতিকার কয়েক রকম: ছোট ন্যূনতম RTO, অনুরোধ ধাপে ধাপে পাঠানো বা উত্তরের আকার সীমিত রাখা, আর DCTCP (পর্ব ৩২, TCP congestion control) — যেখানে switch queue একটু বাড়লেই ECN দাগ দেয় আর প্রেরক দাগের অনুপাতে অল্প অল্প গতি কমায়, ফলে queue ছোট থাকে আর হঠাৎ ঢেউয়ের জন্য জায়গা থাকে।

Elephant আর mice — আর ECMP-র hash collision

প্রকাশিত বিভিন্ন পরিমাপে data center-এ একটি ধাঁচ বারবার দেখা গেছে: বেশিরভাগ flow ছোট (mice — কয়েক KB-র RPC), কিন্তু বেশিরভাগ বাইট বহন করে অল্প কয়েকটি বড় flow (elephant — ব্যাকআপ, VM সরানো, বড় ফাইল)। ECMP-র per-flow hash দুই ধরনের flow-কে আলাদা চেনে না — hash শুধু ঠিক করে কে কোন পথে। দুটি elephant এক link-এ পড়লে সেই link ভরে যায়, পাশের link ফাঁকা থাকে, আর একই link-এর mice-গুলো queue-তে আটকে tail latency বাড়ায়।

নিচের simulator-এ ৪টি spine uplink, প্রতিটি ৪০G. চারটি elephant (প্রতিটি ২০G) আর ২৪টি mice (প্রতিটি ০.৫G) — মোট ৯২G, যা ১৬০G-এর মধ্যে সহজেই ধরে। প্রথমে সাধারণ per-flow ECMP; তারপর flowlet switching — elephant-এর ভেতরের ছোট বিরতিগুলোতে (যখন পথ বদলালেও ক্রম ভাঙার ভয় নেই) প্রতিটি “ঝলক” নতুন করে hash করা; শেষে আদর্শ packet spraying, যেখানে প্রতিটি packet আলাদা পথে যায়।

// ECMP over 4 spine uplinks (40 Gbps each): per-flow hash vs flowlets.
function fnv(s) {                         // FNV-1a 32-bit hash of a string
  let h = 0x811c9dc5;
  for (const c of s) h = Math.imul(h ^ c.charCodeAt(0), 0x01000193) >>> 0;
  return h;
}
const LINKS = 4, CAP = 40, flows = [];
for (let i = 0; i < 4; i++) flows.push({ id: "10.0.1." + (10 + i) + ":" + (40000 + 7 * i), gbps: 20 });
for (let i = 0; i < 24; i++) flows.push({ id: "10.0.1." + (20 + i) + ":" + (50000 + 13 * i), gbps: 0.5 });
function show(title, load) {
  const max = Math.max(...load), min = Math.min(...load);
  console.log(title);
  console.log("  per-link Gbps: " + load.map(x => x.toFixed(1).padStart(5)).join(" ") +
    " | max/min " + (max / min).toFixed(2) + (max > CAP ? " | OVERLOAD on a 40G link" : " | fits"));
}
let load = Array(LINKS).fill(0);           // 1) classic: whole flow hashed once
for (const f of flows) load[fnv(f.id + "->10.0.7.5:443/6") % LINKS] += f.gbps;
show("Per-flow ECMP (5-tuple hash):", load);
console.log("  elephants on links: " + flows.slice(0, 4).map(f => fnv(f.id + "->10.0.7.5:443/6") % LINKS).join(", "));
load = Array(LINKS).fill(0);               // 2) flowlets: each burst re-hashed
for (const f of flows) {
  const bursts = f.gbps >= 10 ? 8 : 1;     // elephants pause often -> 8 flowlets
  for (let b = 0; b < bursts; b++) load[fnv(f.id + "#" + b) % LINKS] += f.gbps / bursts;
}
show("Flowlet switching (re-hash each burst):", load);
const total = flows.reduce((a, f) => a + f.gbps, 0);
show("Packet spraying (ideal round robin):", Array(LINKS).fill(total / LINKS));

Per-flow ECMP (5-tuple hash):
  per-link Gbps:  43.0   3.0  22.0  24.0 | max/min 14.33 | OVERLOAD on a 40G link
  elephants on links: 0, 2, 3, 0
Flowlet switching (re-hash each burst):
  per-link Gbps:  24.0  22.0  23.0  23.0 | max/min 1.09 | fits
Packet spraying (ideal round robin):
  per-link Gbps:  23.0  23.0  23.0  23.0 | max/min 1.00 | fits

বাস্তবে switch নিজে link-এর ভিড় দেখেও flowlet-এর পথ বাছতে পারে (CONGA-র মতো গবেষণা)। মূল আপস একই: যত সূক্ষ্মভাবে ভাগ, ভার তত সমান, কিন্তু ক্রম ভাঙার ঝুঁকি তত বেশি।

RDMA, RoCE আর lossless Ethernet

Storage আর AI-এর মতো কাজে TCP/IP stack-এর CPU খরচ আর দেরিও বোঝা। RDMA (remote direct memory access)-এ এক সার্ভারের network card সরাসরি অন্য সার্ভারের মেমরিতে লেখে বা পড়ে — দুই দিকের OS kernel প্রায় বাইরে থাকে। এর নিজস্ব নেটওয়ার্ক InfiniBand; Ethernet-এর ওপর রূপটিকে বলে RoCE (RDMA over Converged Ethernet; সংস্করণ ২ চলে UDP/IP-এর ওপর, তাই route করা যায়)।

সমস্যা: প্রচলিত RoCE-র transport loss খুব খারাপ সহ্য করে — packet হারালে বড় অংশ আবার পাঠাতে হয়। তাই নেটওয়ার্ককে প্রায় “lossless” বানানো হয় PFC (priority flow control, IEEE 802.1Qbb) দিয়ে: switch-এর buffer ভরার আগেই আগের যন্ত্রকে নির্দিষ্ট অগ্রাধিকার-শ্রেণির জন্য থামতে বলে — Ethernet-এর PAUSE frame-এর (IEEE 802.3x, পর্ব ৩১-এ উল্লেখ আছে) অগ্রাধিকার-ভিত্তিক রূপ। দাম আছে: একটি জট থেকে “থামুন” বার্তা পেছনে ছড়িয়ে নির্দোষ flow-কেও থামাতে পারে (pause storm), বিরল ক্ষেত্রে deadlock-ও সম্ভব। তাই PFC-র সাথে সাধারণত ECN-ভিত্তিক congestion control চালানো হয়, যাতে pause কদাচিৎ লাগে।

AI training cluster-এর নেটওয়ার্ক

বড় মডেল training-এ হাজার হাজার GPU প্রতিটি ধাপের শেষে নিজেদের হিসাব (gradient) মিলিয়ে নেয় — এই সম্মিলিত কাজকে বলে all-reduce. সবচেয়ে ধীর GPU-র ডেটা না পৌঁছালে কেউ এগোতে পারে না, তাই এখানেও tail-ই নির্ধারক। প্রকাশিত নকশাগুলোতে প্রতিটি GPU-র জন্য কয়েকশো Gbps-এর link, ১:১-এর কাছাকাছি fabric আর RDMA সাধারণ; ট্রাফিক অল্প কয়েকটি বিশাল, একসাথে শুরু হওয়া flow — ECMP collision-এর সবচেয়ে খারাপ ধাঁচ। এই ক্ষেত্রের গবেষণা আর মান খুব দ্রুত বদলাচ্ছে।

৮ · Load balancer — L4 আর L7, algorithm, health check আর draining

একটি সার্ভার যত শক্তিশালীই হোক, লাখো ব্যবহারকারী সামলাতে পারে না, আর সেটি নষ্ট হলে সেবা বন্ধ। সমাধান: একই সেবার অনেকগুলো কপি (backend), আর সামনে একটি load balancer (LB), যে প্রতিটি সংযোগ বা অনুরোধ কোনো একটি সুস্থ backend-এ পাঠায়। ক্লায়েন্ট দেখে একটিমাত্র ঠিকানা — VIP (virtual IP).

L4 বনাম L7

L7 LB আসলে একটি reverse proxy (পর্ব ৩৮, Web cache, proxy আর CDN): ক্লায়েন্টের সংযোগ সে নিজে শেষ করে, backend-এর সাথে আলাদা সংযোগ খোলে। ফলে backend ক্লায়েন্টের আসল IP দেখে না — তাই LB X-Forwarded-For header-এ সেটি যোগ করে।

L4-এ উত্তর ফেরার দুই পথ: NAT আর DSR

L4 LB সাধারণত দুইভাবে চলে। NAT মোডে LB গন্তব্য-ঠিকানা VIP থেকে backend-এর ঠিকানায় বদলায় (পর্ব ১৯-এর DNAT), আর উত্তরও LB দিয়েই ফেরে — সহজ, কিন্তু সব উত্তর-ট্রাফিক LB-র ঘাড়ে। DSR (direct server return)-এ backend-ও VIP ঠিকানাটি নিজের loopback-এ রাখে; LB শুধু অনুরোধ পৌঁছে দেয় (MAC বদলে বা tunnel করে), আর backend উত্তর সরাসরি ক্লায়েন্টকে পাঠায়। ওয়েবে উত্তর সাধারণত অনুরোধের চেয়ে অনেক বড় (ছোট GET, বড় ভিডিও), তাই DSR-এ LB-কে খুব কম ট্রাফিক বইতে হয়। আপস: LB উত্তর দেখে না, তাই L7-এর কাজ বা TLS termination সেখানে সম্ভব নয়।

কোন backend? — algorithm

• Round robin: পালা করে — ১, ২, ৩, ৪, ১, ২… সরল, কিন্তু কোন অনুরোধ কতটা ভারী তা জানে না।
• Weighted round robin: দ্বিগুণ শক্তিশালী সার্ভার দ্বিগুণ পালা পায়।
• Least connections: এই মুহূর্তে যার হাতে সবচেয়ে কম চলমান সংযোগ বা অনুরোধ, তাকে দেওয়া। ধীর অনুরোধে আটকে থাকা সার্ভার স্বাভাবিকভাবেই কম নতুন কাজ পায়।
• Hash-ভিত্তিক: ক্লায়েন্ট IP, user ID বা cache key থেকে hash — একই key সবসময় একই backend-এ। Cache-এর জন্য দারুণ, কিন্তু কিছু key বেশি জনপ্রিয় হলে ভার অসমান।

নিচের simulator-এ ৪টি backend, প্রতিটি একসাথে একটি অনুরোধ সামলায় (বাকিরা লাইনে)। প্রতি ৮ ms-এ একটি অনুরোধ আসে; প্রায় ১৫% ভারী (১২০ ms), বাকিরা হালকা (১০ ms); প্রতিটি অনুরোধ ৩০ জন ব্যবহারকারীর কোনো একজনের। তিনটি algorithm একই trace-এ:

// Load-balancer simulator: 4 backends, each serves one request at a time (FIFO).
let seed = 7;
const rnd = () => (seed = seed * 16807 % 2147483647) / 2147483647;     // Park-Miller PRNG
function hash(s) {                        // FNV-1a + a final bit-mixing step
  let h = 0x811c9dc5;
  for (const c of s) h = Math.imul(h ^ c.charCodeAt(0), 16777619);
  h = Math.imul(h ^ (h >>> 16), 0x85ebca6b); h = Math.imul(h ^ (h >>> 13), 0xc2b2ae35);
  return (h ^ (h >>> 16)) >>> 0;
}
const ring = [];                          // consistent-hash ring: 50 virtual nodes per backend
for (let b = 0; b < 4; b++) for (let v = 0; v < 50; v++) ring.push([hash("be" + b + "-" + v), b]);
ring.sort((x, y) => x[0] - y[0]);
const owner = h => (ring.find(p => p[0] >= h) || ring[0])[1];
const trace = [];                         // one request every 8 ms; ~15% are heavy
for (let i = 0; i < 400; i++)
  trace.push({ t: i * 8, cost: rnd() < 0.15 ? 120 : 10, user: "u" + Math.floor(rnd() * 30) });
function run(name, pick) {
  const freeAt = [0, 0, 0, 0], ends = [[], [], [], []], work = [0, 0, 0, 0], lat = [];
  trace.forEach((r, i) => {
    const active = ends.map(e => e.filter(x => x > r.t).length);   // in-flight now
    const b = pick(i, r, active);
    const start = Math.max(r.t, freeAt[b]);
    freeAt[b] = start + r.cost; ends[b].push(freeAt[b]); work[b] += r.cost;
    lat.push(freeAt[b] - r.t);
  });
  lat.sort((a, b) => a - b);
  const avg = lat.reduce((a, b) => a + b) / lat.length;
  console.log(name.padEnd(18) + "work ms" + work.map(w => String(w).padStart(6)).join("") +
    " | avg " + avg.toFixed(0).padStart(4) + " ms | p99 " + String(lat[Math.floor(0.99 * lat.length)]).padStart(4) + " ms");
}
console.log("total work " + trace.reduce((a, r) => a + r.cost, 0) + " ms in " + 400 * 8 + " ms on 4 backends");
run("Round robin", i => i % 4);
run("Least connections", (i, r, act) => act.indexOf(Math.min(...act)));
run("Consistent hash", (i, r) => owner(hash(r.user)));

total work 10380 ms in 3200 ms on 4 backends
Round robin       work ms  2870  2650  2540  2320 | avg  102 ms | p99  450 ms
Least connections work ms  2910  2690  2620  2160 | avg   50 ms | p99  240 ms
Consistent hash   work ms  2710  1840  3180  2650 | avg  111 ms | p99  568 ms

Consistent hashing — backend বদলালে কত key সরে?

সরল hash-ভিত্তিক LB লেখে backend = hash(key) mod N. সমস্যা: N বদলালেই প্রায় সব key-র ঘর বদলায়। প্রতিটি backend যদি নিজের key-গুলোর cache বা session রাখে, একটি সার্ভার যোগ করলেই প্রায় পুরো cache অকেজো — আর সব অনুরোধ একসাথে ডেটাবেসে ছুটে যায়।

Consistent hashing (Karger ও সহকর্মীরা, ১৯৯৭) একটি বৃত্ত কল্পনা করে: backend আর key দুটোকেই একই hash দিয়ে বৃত্তে বসানো হয়; প্রতিটি key ঘড়ির কাঁটার দিকে প্রথম যে backend পায়, সেটিই তার মালিক। নতুন backend E এলে সে বৃত্তের কিছু জায়গা নেয়, আর শুধু সেই জায়গার key-গুলো E-তে যায় — বাকিরা নড়ে না। N থেকে N+১ হলে আদর্শভাবে মাত্র ১/(N+১) অংশ সরে। একটি backend-কে বৃত্তে একবার নয়, অনেকগুলো virtual node হিসেবে বসালে ভাগও সমান হয়।

// How many keys move when a backend is added or removed? modulo vs consistent hashing
function hash(s) {                        // FNV-1a + a final bit-mixing step
  let h = 0x811c9dc5;
  for (const c of s) h = Math.imul(h ^ c.charCodeAt(0), 16777619);
  h = Math.imul(h ^ (h >>> 16), 0x85ebca6b); h = Math.imul(h ^ (h >>> 13), 0xc2b2ae35);
  return (h ^ (h >>> 16)) >>> 0;
}
const keys = Array.from({ length: 10000 }, (_, i) => hash("session-" + i));
function ring(backends, vnodes) {         // sorted [point, backend] pairs
  const r = [];
  for (const b of backends) for (let v = 0; v < vnodes; v++) r.push([hash(b + "#" + v), b]);
  return r.sort((x, y) => x[0] - y[0]);
}
function lookup(r, h) {                   // binary search: first point >= h, wrap around
  let lo = 0, hi = r.length;
  while (lo < hi) { const m = (lo + hi) >> 1; if (r[m][0] < h) lo = m + 1; else hi = m; }
  return r[lo % r.length][1];
}
const moved = (f, g) => (100 * keys.filter(k => f(k) !== g(k)).length / keys.length).toFixed(1) + "%";
const four = ["A", "B", "C", "D"], five = [...four, "E"], three = ["A", "B", "C"];
console.log("change      modulo  consistent(100 vnodes)");
const R4 = ring(four, 100), R5 = ring(five, 100), R3 = ring(three, 100);
console.log("add E 4->5 " + moved(k => k % 4, k => k % 5).padStart(7) + moved(k => lookup(R4, k), k => lookup(R5, k)).padStart(12));
console.log("drop D 4->3" + moved(k => k % 4, k => k % 3).padStart(7) + moved(k => lookup(R4, k), k => lookup(R3, k)).padStart(12));
for (const vn of [1, 10, 100, 1000]) {    // balance: how even is each backend's share?
  const r = ring(four, vn), count = { A: 0, B: 0, C: 0, D: 0 };
  for (const k of keys) count[lookup(r, k)]++;
  const c = Object.values(count);
  console.log("vnodes " + String(vn).padStart(4) + ": keys per backend " + c.join(" / ") +
    "  max/avg " + (Math.max(...c) / 2500).toFixed(2));
}

change      modulo  consistent(100 vnodes)
add E 4->5   79.9%       25.5%
drop D 4->3  74.7%       25.0%
vnodes    1: keys per backend 2457 / 1510 / 5477 / 556  max/avg 2.19
vnodes   10: keys per backend 2419 / 2827 / 1948 / 2806  max/avg 1.13
vnodes  100: keys per backend 2701 / 2569 / 2228 / 2502  max/avg 1.08
vnodes 1000: keys per backend 2380 / 2628 / 2513 / 2479  max/avg 1.05

Google ২০১৬ সালে তাদের software load balancer Maglev-এর নকশা প্রকাশ করে। সেখানে router ECMP দিয়ে VIP-এর ট্রাফিক অনেকগুলো সাধারণ সার্ভারে চলা LB-তে ভাগ করে, আর প্রতিটি LB একটি বিশেষ consistent-hash টেবিল (Maglev hashing) থেকে backend বাছে — প্রায় সমান ভাগ আর backend বদলালে কম পরিবর্তনের জন্য বানানো। প্রতিটি LB একই টেবিল ব্যবহার করায় একটি LB নষ্ট হয়ে ECMP সংযোগটি অন্য LB-তে পাঠালেও বেশিরভাগ ক্ষেত্রে সে একই backend বাছে, তাই চলমান সংযোগ টিকে যায়। অর্থাৎ LB নিজেরও load balancing আর redundancy লাগে।

Sticky session, health check আর connection draining

Sticky session (session affinity): একজন ব্যবহারকারীকে বারবার একই backend-এ পাঠানো — cookie দিয়ে বা IP-hash দিয়ে — যাতে সার্ভারের মেমরিতে রাখা session পাওয়া যায়। অসুবিধা অসমান ভার আর backend নষ্ট হলে session হারানো; তাই আধুনিক নকশা session সাধারণত বাইরের store-এ রাখে।

Health check দুই রকম: active — LB নিজে নির্দিষ্ট সময় পরপর প্রতিটি backend-কে পরীক্ষা করে (TCP সংযোগ, বা GET /healthz-এর উত্তর ২০০ কি না), পরপর কয়েকবার ব্যর্থ হলে DOWN, পরপর কয়েকবার সফল হলে আবার UP; passive — আসল ট্রাফিকের ত্রুটি (সংযোগ ব্যর্থ, ৫xx উত্তর) গুনে সাময়িক বাদ দেওয়া। ভালো health check শুধু “process বেঁচে আছে?” নয়, “অনুরোধ সামলাতে পারবে?” যাচাই করে — তবে এত গভীর নয় যে ডেটাবেস ধীর হলেই সব backend একসাথে DOWN হয়ে যায়।

Connection draining: নতুন সংস্করণ deploy বা রক্ষণাবেক্ষণের জন্য একটি backend সরানোর আগে LB তাতে নতুন অনুরোধ পাঠানো বন্ধ করে, কিন্তু চলমান অনুরোধ শেষ হতে দেয় (একটি সর্বোচ্চ সময়সীমা পর্যন্ত)। এটি LB-স্তরের graceful shutdown (পর্ব ৪৩-এর সার্ভারে দেখেছেন)।

Data center-এর বাইরে: GSLB আর anycast

একটি data center নিজেই নষ্ট হতে পারে — বিদ্যুৎ, বন্যা, fiber কাটা। তাই বড় সেবা কয়েকটি data center-এ চলে, আর ব্যবহারকারীকে কোনটিতে পাঠানো হবে তা ঠিক করে GSLB (global server load balancing). সাধারণ পদ্ধতি DNS (পর্ব ৩৫, DNS): authoritative সার্ভার প্রশ্নকারীর অবস্থান আর প্রতিটি সাইটের স্বাস্থ্য দেখে ভিন্ন ঠিকানা দেয়, ছোট TTL রেখে — তবে resolver-এর cache-এর কারণে বদল পুরোপুরি তাৎক্ষণিক নয়। আরেক পদ্ধতি anycast (পর্ব ২৫): একই VIP কয়েকটি সাইট থেকে BGP-তে ঘোষণা, routing নিজেই কাছের সাইটে পাঠায়; একটি সাইট ঘোষণা তুলে নিলে ট্রাফিক অন্যগুলোতে যায়।

Software বনাম hardware: আগে LB মানে ছিল দামি বিশেষ যন্ত্রের জোড়া; এখন বেশিরভাগ জায়গায় সাধারণ সার্ভারে চলা software (HAProxy, nginx, Envoy, IPVS), সামনে router-এর ECMP — সার্ভার যোগ করলেই ক্ষমতা বাড়ে। Hardware LB এখনো কিছু enterprise-এ দেখা যায়।

৯ · নির্ভরযোগ্যতা — redundancy, failure domain আর availability-র অঙ্ক

Data center-এর প্রতিটি নকশা-সিদ্ধান্তের পেছনে একটি প্রশ্ন: “এটা নষ্ট হলে কী হবে?” উত্তরের তিনটি হাতিয়ার:

• Redundancy আর N+1: দরকার N-টি হলে অন্তত একটি বাড়তি রাখা — ৩টি spine-এর ক্ষমতা লাগলে ৪টি। কিছু জায়গায় ২N: পুরো দ্বিগুণ (দুটি আলাদা বিদ্যুৎ লাইন, প্রতিটি সার্ভারে দুটি power supply).
• Failure domain: একটি ব্যর্থতা কতদূর ছড়ায় — একটি সার্ভার, একটি rack (ToR গেলে পুরো rack), একটি বিদ্যুৎ-সারি, একটি হল, পুরো data center. Redundant কপিগুলো আলাদা failure domain-এ রাখতে হয়: ডেটাবেসের তিনটি কপি একই rack-এ রাখলে একটি ToR-এই তিনটি যায়। এজন্য অনেক প্রতিষ্ঠান ToR-ও জোড়ায় রাখে আর সার্ভারকে দুটিতে যুক্ত করে।
• Single point of failure খোঁজা: প্রতিটি পথ ধরে জিজ্ঞেস করা, কোথায় একটিমাত্র কিছু আছে — একটি LB, একটি DNS সেবাদাতা, একটি fiber পথ, একটি configuration ফাইল।

Availability-র হিসাব

Availability সাধারণত সময়ের শতাংশে বলা হয়: বছরে ৮,৭৬০ ঘণ্টার কত অংশ সেবা চালু। ৯৯.৯% (“three nines”) মানে বছরে চালু নেই ০.১%:

দুটি নিয়ম, অংশগুলো একে অপরের থেকে স্বাধীনভাবে নষ্ট হয় ধরে নিয়ে:

• Series (সবগুলো লাগবে): A = a₁ × a₂ × … — শিকল তার সবচেয়ে দুর্বল কড়ার চেয়েও দুর্বল। দুটি ৯৯.৯% অংশ পরপর: ০.৯৯৯ × ০.৯৯৯ = ৯৯.৮০০১% — বছরে প্রায় ১৭.৫ ঘণ্টা।
• Parallel (যেকোনো একটি চললেই হবে): সব একসাথে নষ্ট হওয়ার সম্ভাবনা গুণ হয়, তাই A = ১ − (১ − a₁)(১ − a₂)…; দুটি একই রকম হলে ১ − (১ − a)². দুটি ৯৯% সার্ভার: ১ − ০.০১² = ৯৯.৯৯%; দুটি ৯৯.৯% LB: ৯৯.৯৯৯৯% — বছরে মাত্র প্রায় ৩১.৫ সেকেন্ড।

হাতে কষা উদাহরণ: একটি সেবার পথ — দুটি LB (প্রতিটি ৯৯.৯%, parallel) → তিনটি app সার্ভার (প্রতিটি ৯৯%, একটি চললেই হবে) → একটি ডেটাবেস (৯৯.৯৫%).

শিক্ষা: সবচেয়ে দুর্বল series অংশটিই পুরো সেবার availability ঠিক করে। ডেটাবেসেরও একটি স্বাধীন কপি (parallel) রাখলে হিসাবে বছরে প্রায় এক মিনিটে নামে। কিন্তু সাবধান — “স্বাধীন” ধারণাটিই সবচেয়ে বড় ফাঁকি: একই software bug, একই ভুল configuration বা একই বিদ্যুৎ লাইন দুটি কপিকে একসাথে ফেলে দেয়, আর failover নিজেও ব্যর্থ হতে পারে। বড় বিভ্রাটগুলো সাধারণত এই সম্পর্কযুক্ত (correlated) ব্যর্থতা থেকেই আসে।

১০ · AI-এর যুগে data center নেটওয়ার্ক — হিসাব নিজে যাচাই করুন

AI সহকারী fabric-এর খসড়া নকশা, LB-র configuration বা ক্ষমতার হিসাবে দ্রুত সাহায্য করে। কিন্তু এই বিষয়ে তার পরিচিত ভুলগুলো ব্যয়বহুল — ভুল হিসাবে কেনা switch ফেরত দেওয়া যায় না।

AI-এর data center পরামর্শ ব্যবহারের আগে — চেকলিস্ট

• Oversubscription, সার্ভারের সংখ্যা আর bisection নিজে হাতে বা ছোট script-এ আবার হিসাব করেছি (port × গতি দিয়ে)
• Availability-র দাবিতে series/parallel ঠিক আছে কি না, আর “স্বাধীন ব্যর্থতা” কোথায় ধরা হয়েছে, দেখেছি
• RFC নম্বর rfc-editor.org-এ আর vendor কমান্ড vendor-এর ডকুমেন্টেশনে মিলিয়েছি; Linux-এ পুরোনো ifconfig/netstat নয়, ip/ss দিয়ে যাচাই করেছি
• LB বা routing-এর configuration আগে ল্যাব বা VM-এ চালিয়ে একটি backend বা link থামিয়ে আচরণ দেখেছি
• Firewall বা security group-এ “সব খুলে দিন” ধরনের পরামর্শ বাতিল করে শুধু দরকারি port আর উৎস খুলেছি