AI ফ্যাব্রিকে লিংকের নির্ভরযোগ্যতা ও মনিটরিং

একটি ট্রেনিং জব হাজার হাজার GPU জুড়ে চলা সিঙ্ক্রোনাস গণনা: প্রতিটি সমষ্টিগত অপারেশন (collectives) সবচেয়ে ধীর লিংকের জন্য অপেক্ষা করে। একটি ফ্ল্যাপ করা ট্রান্সিভার একটিমাত্র সার্ভারকে সামান্য ধীর করে না; এটি পুরো জবকে থামিয়ে দেয়, আর সেটি পুরোপুরি বিকল হলে জব সর্বশেষ চেকপয়েন্ট থেকে আবার শুরু হয়। তাই অপটিক্স আর শুধু একটি উপাদান থাকে না, হয়ে ওঠে নির্ভরযোগ্যতার বাজেট। এই পেজে আছে বিকল হওয়ার হিসাব, সমস্যার পূর্বাভাস দেওয়া মেট্রিক, ফ্যাব্রিক কীভাবে খারাপ লিংক মনিটর করে ও আলাদা করে, এবং বিকল হওয়ার হার কমিয়ে রাখার পরিচালনার অনুশীলন।

একটি লিংকের প্রভাব

ঘটনা	ট্রেনিং জবের ওপর প্রভাব
লিংক ফ্ল্যাপ (কয়েক সেকেন্ডের)	সমষ্টিগত অপারেশন (collectives) টাইমআউট হয় বা আবার চেষ্টা করে; ধাপের সময় হঠাৎ বেড়ে যায়; NCCL/RCCL-এর ক্ষেত্রে যথেষ্ট দীর্ঘ স্থবিরতা জবটিকে বাতিল করে দেয়
কম গতি/প্রস্থে চলা লিংক	প্রতিটি অল-রিডিউস সেই লিংকের গতিতে বাঁধা পড়ে; পুরো ক্লাস্টারের থ্রুপুট ওই লিংকের গতিতে নেমে আসে
প্রি-FEC BER বেশি, অসংশোধনযোগ্য ত্রুটি নেই	এখনো কিছু নয়, কিন্তু মার্জিন শেষ; পরের গরম বিকেলেই এটি ফ্ল্যাপ করবে
অসংশোধনযোগ্য FEC ত্রুটি	প্যাকেট লস → RDMA পুনঃপ্রেরণের ঝড় → স্থবিরতা
সম্পূর্ণ বিকল হওয়া	চেকপয়েন্ট থেকে জব নতুন করে চালু: পুরো ক্লাস্টার জুড়ে কয়েক মিনিট থেকে এক ঘণ্টা পর্যন্ত কম্পিউট হারায়

এক হাজার GPU-র একটি জবে চেকপয়েন্ট থেকে পুনরায় শুরুর খরচ মাপা হয় GPU-ঘণ্টায়; উন্নত অপটিক্স ও উন্নত QA-এর দামের সঙ্গে এই সংখ্যাটিই তুলনা করতে হয়।

বিকল হওয়ার অঙ্ক

ট্রান্সিভারের নির্ভরযোগ্যতা সাধারণত FIT (প্রতি 10⁹ ডিভাইস-ঘণ্টায় বিকল হওয়ার সংখ্যা) অথবা MTBF-এ উল্লেখ করা হয়।

অনুমান	মান
ফ্যাব্রিকে অপটিক্যাল প্রান্ত	4 000 (1 024 GPU-র দুই স্তরের ক্লাস্টার)
প্রতি প্রান্তে FIT (পরিপক্ব 400G অপটিক্স, ভালোভাবে ঠান্ডা করা)	200–500
প্রতি মাসে প্রত্যাশিত সম্পূর্ণ বিকল হওয়ার সংখ্যা	4 000 × 350 × 10⁻⁹ × 720 h ≈ 1
বাস্তবে পর্যবেক্ষণ করা লিংক ফ্ল্যাপের হার	সম্পূর্ণ বিকল হওয়ার চেয়ে 5–20 × বেশি: ময়লা, সীমান্তবর্তী মার্জিন, তাপ, ফার্মওয়্যার

অর্থাৎ সম্পূর্ণ বিকল হওয়া বিরল ও আগাম অনুমানযোগ্য; সংখ্যায় বেশি হলো ফ্ল্যাপ ও খারাপ হতে থাকা লিংক, আর সেগুলোর বেশিরভাগই ঠেকানো যায়। এ কারণেই মনিটরিং ও QA নিজেদের খরচ নিজেরাই মিটিয়ে দেয়।

যেসব মেট্রিক সমস্যার পূর্বাভাস দেয়

মেট্রিক	উৎস	সুস্থ অবস্থা	পদক্ষেপ
প্রতি লেনে প্রি-FEC BER	CMIS VDM; হোস্টের FEC কাউন্টার	< 10⁻⁷	> 10⁻⁶ ও বাড়ছে; > 10⁻⁵ হলে বদলানোর সূচি ঠিক করুন
FEC অসংশোধনযোগ্য কোডওয়ার্ড	হোস্ট	0	যেকোনো বৃদ্ধি = ইনসিডেন্ট
প্রতি লেনে সিম্বল ত্রুটি	হোস্ট (Ethernet) / `perfquery` (IB)	সুষম, শূন্যের কাছাকাছি	একটি লেনে ত্রুটির আধিক্য
বেসলাইনের তুলনায় প্রতি লেনের Rx পাওয়ার	DDM	প্রথম দিনের মানের 1 dB-এর মধ্যে, লেনগুলো পরস্পরের 2 dB-এর মধ্যে	বেসলাইন থেকে −2 dB
Tx বায়াসের ট্রেন্ড	DDM	স্থির	বেসলাইন থেকে +15–20 % (Tx বায়াস ও এজিং)
মডিউলের তাপমাত্রা	DDM	< 60 °C	> 65 °C, অথবা পাশের মডিউলগুলোর চেয়ে +10 °C বেশি
eSNR (CMIS)	VDM	> 18–20 dB	একটি লেনে কমছে
প্রতি পোর্টে লিংক ফ্ল্যাপ	সুইচের লগ, ফ্যাব্রিক ম্যানেজার	0	যেকোনো একটি
নেগোশিয়েট করা গতি/প্রস্থ	সুইচ / `ibstat`	পূর্ণ	রেটেড মানের নিচে

সংজ্ঞা ও ফরম্যাট: VDM ও FEC মেট্রিক, মনিটরিং।

মনিটরিংয়ের আর্কিটেকচার

ফ্যাব্রিক	তথ্য সংগ্রহ	টুল
InfiniBand	সাবনেট/ফ্যাব্রিক ম্যানেজার প্রতিটি পোর্টের কাউন্টার এবং ক্যাবলের EEPROM/DDM পোল করে	UFM ধরনের ম্যানেজার, `ibdiagnet`, `mlxlink -m`
Ethernet (RoCE)	10–60 s ব্যবধানে gNMI/OpenConfig স্ট্রিমিংয়ের মাধ্যমে ট্রান্সিভার ও FEC-এর অবস্থা সংগ্রহ; বিকল্প হিসেবে SNMP	gnmic → Prometheus/Grafana, ভেন্ডরের টেলিমেট্রি (টুল দিয়ে DDM পড়া)
হোস্টের দিক	NIC কাউন্টার: পুনঃপ্রেরণ, CNP, ক্রমভঙ্গ প্যাকেট; টাইমআউটের জন্য NCCL/RCCL-এর লগ	Node Exporter
জবের দিক	ধাপের সময়ের তারতম্য, স্ট্র্যাগলার শনাক্তকরণ	ট্রেনিং ফ্রেমওয়ার্কের মেট্রিক

তিনটিকে মিলিয়ে দেখুন: 14:05-এ ধাপের সময়ের হঠাৎ বৃদ্ধি, 14:04-এ লিফ 7-এর লেন 3-এ প্রি-FEC BER-এর লাফ এবং র‍্যাক 12-এ মডিউলের তাপমাত্রার শীর্ষ মান মিলে একটি পূর্ণাঙ্গ ডায়াগনসিস।

বিচ্ছিন্নকরণ ও প্রতিকার

অসংশোধনযোগ্য ত্রুটি বা ফ্ল্যাপ থ্রেশহোল্ড ছাড়ালে স্বয়ংক্রিয়ভাবে পোর্ট বন্ধ করা / পাশ কাটিয়ে রুট করা: ফ্যাব্রিক ম্যানেজার ও NOS লিংক-ত্রুটি নীতি সমর্থন করে; এর মধ্যে অ্যাডাপটিভ রাউটিং খারাপ লিংককে এড়িয়ে ফ্লো ঘুরিয়ে দেয়।
NIC পোর্টই দোষী হলে নোডটি ড্রেন করুন; জবের সময়সূচি নোডটিকে বাদ রেখে করুন।
মডিউলটি টেস্ট বেঞ্চে পরীক্ষা করুন: শনাক্তকরণ তথ্য, প্রথম দিনের বেসলাইনের সঙ্গে প্রতি লেনের DDM, চেকসাম, ফার্মওয়্যারের সংস্করণ (Check transceiver, DDM)।
মডিউলকে দোষ দেওয়ার আগে দুই দিকের MPO পরিষ্কার করে আবার পরিদর্শন করুন; ময়লাই সবচেয়ে সাধারণ কারণ (ফিজিক্যাল লেয়ারের অমিল)।
বদলে দেখুন: ত্রুটি মডিউলের সঙ্গে গেলে সেটি RMA করুন; পোর্টেই থেকে গেলে কেজ, ফাইবার ও অপর প্রান্ত দেখুন।

বিকল হওয়ার হার কমানোর অনুশীলন

অনুশীলন	প্রভাব
ইনকামিং পরিদর্শন ও বার্ন-ইন (লোড ও তাপমাত্রার অধীনে 24–72 h)	শুরুর দিকের ত্রুটিপূর্ণ মডিউল জবে পৌঁছানোর আগেই সরিয়ে দেয়
প্রথম দিনে প্রতি লেনের DDM বেসলাইন নেওয়া	পরম নির্ভুলতার (±3 dB) বদলে নির্ভুল পার্থক্য পাওয়া যায়
মডিউল < 60 °C-এ রাখুন: এয়ারফ্লো, ফিনযুক্ত/ফ্ল্যাট OSFP সঠিকভাবে ব্যবহার, ইনটেক আটকে না থাকা	প্রতি −10 °C-এ আয়ু দ্বিগুণ হয়
প্রতিবার সংযোগের আগে প্রতিটি কানেক্টর পরিষ্কার করুন; অব্যবহৃত পোর্টে ক্যাপ রাখুন	বেশিরভাগ ফ্ল্যাপের কারণ ময়লা
মডিউল ও হোস্টের ফার্মওয়্যার হালনাগাদ রাখা	CMIS ইন্টারঅপারেবিলিটির সংশোধন (CMIS সংক্রান্ত সমস্যা)
প্রতিটি স্তরে অভিন্ন, যাচাই করা অপটিক্স	হোস্ট/মডিউলের DSP ইন্টারঅপারেবিলিটির অপ্রত্যাশিত সমস্যা কমে
বার্ন-ইন ও বেসলাইন নেওয়া স্পেয়ার, 3–5 %	দ্বিতীয় ইনসিডেন্ট ছাড়াই বদলানো যায়
সাপ্তাহিক ট্রেন্ড পর্যালোচনা	বিকল হওয়ার পর নয়, সময়সূচি অনুযায়ী পুরোনো হয়ে আসা লেজার বদলানো যায়

প্রযুক্তি কোন দিকে যাচ্ছে

উচ্চতর লেন রেট (200G/লেন, 1.6T) মার্জিনকে আরও সংকুচিত করে; লিনিয়ার (LPO) ও কো-প্যাকেজড অপটিক্স DSP এবং তার মনিটরিং সরিয়ে দেয়, ফলে BER দেখার দায়িত্ব হোস্টের ওপর চলে যায়, আর বিনিময়ে কম উপাদান ও কম তাপের প্রতিশ্রুতি মেলে (মডুলেশন ও DSP, AI-তে অপটিক্স)। মডিউল যা-ই হোক, নিয়মটা একই থাকে: বেসলাইন নিন, পার্থক্য মনিটর করুন, ট্রেন্ড দেখে পদক্ষেপ নিন।

CodingBox-এ

CodingBox এই চক্রের টেস্ট বেঞ্চের দিক: ইনকামিং পরিদর্শন ও বার্ন-ইনের সময় মডিউল পড়া, সিরিয়াল নম্বর ধরে Code database-এ রাখা প্রথম দিনের প্রতি লেনের বেসলাইন, আর খুলে আনা মডিউলের ঘটনা-পরবর্তী পাঠ (শনাক্তকরণ তথ্য, ফার্মওয়্যার, চেকসাম ও DDM মডিউলের নিজের ইতিহাসের সঙ্গে তুলনা করে), যাতে RMA-র সিদ্ধান্ত পোর্টের শেষ লগ লাইনের বদলে ডেটার ওপর দাঁড়ায়।

এই নিবন্ধে কোনো অশুদ্ধ তথ্য বা ভুল পেলে সংশ্লিষ্ট অংশটি নির্বাচন করুন এবং Ctrl+Enter চেপে ।