বিশ্বের সবচেয়ে অদক্ষ datacenter তৈরির কাল্পনিক guide

আপনি যা তৈরি করছেন

এই সাইটের প্রতিটি গাইডে কোনো কাজ সঠিকভাবে করার পদ্ধতি শেখানো হয়: সঠিক ক্রমে command, সঠিক ফলাফল দেখতে কেমন, এবং কোন কোন failure mode হতে পারে। এই গাইড আলাদা। আজ আমরা সম্পূর্ণ কাল্পনিকভাবে এমন একটি datacenter-এর নকশা করব, যা টাকা, বিদ্যুৎ এবং অতিরিক্ত আত্মবিশ্বাস কাজে লাগিয়ে যতটা সম্ভব অদক্ষ করা যায়।

আমাদের একটি metric দরকার। তাই industry-র নিজস্ব metric ধার করছি: PUE, Power Usage Effectiveness। এটি হলো পুরো facility-এর মোট power-কে computing equipment-এ বাস্তবে পৌঁছানো power দিয়ে ভাগ করার ফল। একটি hyperscale datacenter-এর PUE সাধারণত 1.1-এর কাছাকাছি থাকে; অর্থাৎ প্রায় প্রতিটি watt কার্যকর কাজে ব্যবহৃত হয়। একটি মানসম্মত enterprise server room-এর PUE প্রায় 1.5। আমাদের লক্ষ্য 4.0 বা তার বেশি। এর অর্থ, computing-এর জন্য ব্যবহৃত প্রতি watt-এর বিপরীতে আরও তিন watt কোনো কাজে না লেগে নষ্ট হবে। আমরা এই সংখ্যাটি প্রায়ই উল্লেখ করব, যেভাবে গুরুতর guide-গুলো backups-এর কথা উল্লেখ করে।

সাইট নির্বাচন: তাপই মূল বিষয়

বাস্তব ডেটাসেন্টারে cooling সবচেয়ে বড় একক overhead। তাই আমাদের অবস্থান thermodynamics-এর নিজস্ব ক্ষেত্রে তার বিরুদ্ধে লড়াই করবে। আদর্শ স্থান হলো attic। দক্ষিণমুখী। সম্ভব হলে এমন একটি skylight রাখুন, যার আলো সরাসরি server-এর ওপর পড়ে। এতে machine নিজের waste heat এবং সূর্যের তাপ—দুটিই পাবে। এটি আপনার electricity bill এবং একটি নক্ষত্রের যৌথ উদ্যোগ।

শীতে window খুলে cooling করা হবে। বাস্তব ডেটাসেন্টারেও বাইরেের air ব্যবহার করা হয়। এই পদ্ধতিকে free cooling বলা হয়। এটি engineering, filtering এবং humidity control-এর মাধ্যমে পরিচালিত হয়। আমরা এটি অনিচ্ছাকৃতভাবে ব্যবহার করব, এমন একটি window দিয়ে যা rain, pollen এবং প্রতি quarter-এ অন্তত একটি বিভ্রান্ত bird-ও ভেতরে ঢুকতে দেয়।

আরও নিখুঁত ফলের জন্য একটি air conditioner install করুন। এরপর তার thermostat থেকে দুই feet দূরে একটি space heater রাখুন। space heater-টি air conditioner-এর target-এর চেয়ে দুই degree বেশি temperature-এ set করুন। এখন উভয় machine নিরবচ্ছিন্নভাবে, চিরকাল, সম্পূর্ণ ভিন্ন সিদ্ধান্তে চলবে। বিদ্যুৎ কোম্পানি Christmas-এ আপনাকে একটি card পাঠাবে।

একটি সার্ভার, বড় এবং প্রিয়

Redundancy প্রতিশ্রুতিকে দুর্বল করে। আমাদের datacenter-এ ঠিক একটি server আছে, এবং সেটি বিশাল। কারণ 512 GB RAM-সহ একটি machine-কে infrastructure মনে হয়, যেখানে চারটি ছোট machine-কে শুধু করণীয় কাজের তালিকা মনে হয়।

serverটির একটি নাম আছে। hostname নয়, নাম। সাধারণত Gandalf অথবা Odin। Odin-কে decommission করা যায় না। Odin পাঁচ বছর ধরে চালু আছে:

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

এই সংখ্যাটি গর্বের বিষয়। তাই আপনি এর screenshot নিয়ে পোস্ট করেন। যে attacker screenshotটি দেখবে, সেও এটিকে চমৎকার মনে করবে। 1,847 দিনের uptime মানে 1,847 দিন kernel vulnerability অমীমাংসিত রয়েছে। কেউ patch করেনি। Reboot করার কথাও ভাবা যায় না। কারণ reboot করলেই বোঝা যায়, 2021 সালে কোন service হাতে চালু করা হয়েছিল এবং কখনো systemd unit-এ লেখা হয়নি। কোনগুলো ছিল, তা কেউ মনে রাখতে পারে না। serverটি এখন সাংগঠনিক কাঠামোরও একটি অপরিহার্য অংশ।

স্টোরেজ: গতি এবং ডেটা হারানোর অন্যান্য উপায়

পারফরম্যান্সের জন্য ডিস্কগুলো RAID 0-এ কনফিগার করা হয়েছে। শূন্য সংখ্যাটি ব্যর্থ হতে পারে এমন ডিস্কের সংখ্যা নির্দেশ করে। সর্বোচ্চ প্রভাবের জন্য ভিন্ন উৎসের স্টোরেজে array-টি stripe করুন: দুটি নির্ভরযোগ্য SSD, একটি পুরোনো spinning disk এবং একটি conference থেকে পাওয়া USB stick। array-টির নির্ভরযোগ্যতা conference-এর সেই stick-এর সমান—এটাই নকশা।

Backup একই array-তে থাকা backup_final_v2_REAL নামের একটি directory দিয়ে পরিচালিত হয়। এতে আগের naming scheme-এর একটি tarball আছে। Off-site backup-এর প্রতিনিধিত্ব করছে “set up off-site backups” লেখা একটি sticky note। আপনি সেটি laptop-এর ঢাকনার ওপর করে বাড়িতে নিয়ে গেলে, প্রযুক্তিগতভাবে সেটি off-site-এ সংরক্ষিত হয়।

সঠিক ফলাফল দেখতে এমন হবে: df 97% usage দেখাচ্ছে এবং পরবর্তী sprint-এ এটি মোকাবিলার একটি plan রয়েছে।

নেটওয়ার্কিং: সবকিছুকে এক সুতোয় বাঁধা

DNS server-টি একই machine-এ চলে। তাই server down হলে, সমস্যার কারণ জানতে যে DNS record ব্যবহার করবেন সেটিও আর পাওয়া যায় না। একে consolidation বলা হয়।

কোনো একটি বিষয় debug করার জন্য 2021 সালে firewall সাময়িকভাবে disabled করা হয়েছিল। debugging শেষ হয়েছে, কিন্তু firewall আর চালু করা হয়নি। “পরে সময় বাঁচবে” এই উদ্দেশ্যে router-এর প্রতিটি port server-এ forward করা হয়েছে। সুবিধাজনক remote management-এর জন্য router-এর admin panel factory password ব্যবহার করে WAN side থেকেও accessible। আপনার জন্য, এবং অন্যদের জন্যও।

ইদানীং server-টি অস্বাভাবিকভাবে গরম চলছে, attic-এর স্বাভাবিক তাপমাত্রা বিবেচনায় নিলেও। আর top দেখাচ্ছে, সবচেয়ে বেশি ব্যস্ত process-এর নাম xmrig। আমরা ধরে নিচ্ছি, এটিই আমাদের ব্যবহার করা monitoring tool। আমরা এটি install করিনি; port forward করার কিছু পরেই এটি নিজে থেকেই উপস্থিত হয়েছে। আমরা এটিকে ecosystem সমৃদ্ধ হওয়ার লক্ষণ হিসেবে দেখছি। এটি দিনরাত monitor করে।

বিদ্যুৎ consumer power strip-এর একটি ধারাবাহিক সংযোগের মাধ্যমে আসছে। সেগুলোর সম্মিলিত দৈর্ঘ্য breaker panel পর্যন্ত হেঁটে যাওয়ার দূরত্বের চেয়েও বেশি। এক অর্থে এটি কার্যকর, কারণ আপনাকে breaker panel-এ প্রায়ই যেতে হবে।

জটিলতার মাধ্যমে redundancy

যেখানে redundancy গুরুত্বপূর্ণ, সেখানে তা প্রত্যাখ্যান করার পর এখন যেখানে এর কোনো প্রয়োজন নেই, সেখানে redundancy যোগ করা হচ্ছে। কোম্পানির homepage, একটি static HTML file, একটি twelve-node Kubernetes cluster থেকে পরিবেশিত হয়। এর ফলে engineers যাকে resume-driven architecture বলেন, তা অর্জিত হয়: page-টি nginx যে forty milliseconds-এ পরিবেশন করত, একই সময়ে load হয়; তবে এখন এটি এমনভাবে ব্যর্থ হতে পারে, যার জন্য consultant প্রয়োজন।

isolation-এর জন্য cluster-টি নিজেই একটি virtual machine-এর ভেতরে আরেকটি virtual machine-এর ভেতরে আরও একটি virtual machine-এর মধ্যে চালানো হয়। প্রতিটি layer security যোগ করে, যেমন turducken-এর প্রতিটি layer আরও একটি পাখি যোগ করে। contact form-টি nine microservices নিয়ে গঠিত। এর মধ্যে twoটি কখনও invoke করা হয়নি। কোনটি load-bearing, তা কেউ জানে না।

সেবা হিসেবে Heating

একটি আধুনিক সার্ভার বিদ্যুৎকে computation এবং heat-এ রূপান্তর করে। আমরা দ্বিতীয় output সর্বাধিক করতে চাই। GPU ছাড়া media server ব্যবহার করা এ ক্ষেত্রে প্রচলিত পদ্ধতি: CPU দিয়ে একটি 4K stream transcode করলে sixteenটি core সম্পূর্ণ ব্যস্ত হয়ে পড়ে এবং একটি ছোট bedroom উষ্ণ হয়। এটি এমন একটি space heater, যা movie-ও চালায়। আরও উচ্চাভিলাষী operator CPU-তে একটি large language model চালানো শুরু করেন। এটি API-সহ 70-billion-parameter space heater, যা token তৈরি করে এমন গতিতে, যার হিসাব season অনুযায়ী করাই ভালো।

মনিটর নিজেকেই পর্যবেক্ষণ করে

Observability গুরুত্বপূর্ণ। তাই একই সার্ভারে একটি নিজস্ব সার্ভারে চালিত uptime monitor স্থাপন করি, যে সার্ভারটি সেটি পর্যবেক্ষণ করে। Odin বন্ধ হলে monitor-টিও বন্ধ হয়ে যায়। এর ফল আরও সুবিধাজনক: কোনো alert পাঠানো হয় না। কোনো alert না থাকলে কোনো incident নেই। কোনো incident না থাকলে পরিমাপ অনুযায়ী uptime নিখুঁত। মাসিক report-ও এত ভালো আগে কখনো দেখায়নি।

সম্পূর্ণতার জন্য বলা যায়, alert email এমন একটি mail server-এর মাধ্যমে relay করা হয়, যেটিও Odin-এ চলে। ফলে alerting pipeline সম্পূর্ণ self-contained। titi?

অস্বস্তিকর অংশ

এখানেই সেই অংশ, যেটি আমি এতদিন এড়িয়ে যাচ্ছিলাম। এর কোনোটিই কাল্পনিক নয়। অত্যন্ত প্রিয় ও অপরিবর্তনীয় সার্ভার, একই volume-এ backup রাখা RAID 0, “সাময়িকভাবে” বন্ধ রাখা firewall, মাত্র একটি page পরিবেশন করা Kubernetes cluster, নিজেকেই monitor করা monitor—production environment-এ আমি এগুলোর প্রতিটিই দেখেছি। এর কয়েকটি আমি এই বছরও দেখেছি। আর আমার কর্মজীবনের শুরুর দিকে, এর এক বা দুটিও আমি নিজেই তৈরি করেছিলাম।

প্রকৃত efficiency কেমন, তা বিরক্তিকর; এই কারণেই তাৎক্ষণিক সিদ্ধান্তের সময় এটি যুক্তিতে হেরে যায়, কিন্তু এক দশকের হিসাবে জয়ী হয়: এমন একটি PUE, যা নিয়ে আপনাকে কখনও ভাবতে হয় না, কারণ অন্য কেউ সেটি পরিকল্পনা ও প্রকৌশল করেছে। মালিকের আত্মপরিচয়ের আকার অনুযায়ী নয়, workload অনুযায়ী নির্ধারিত machine। বিস্ফোরণ ঘটার আগে বিবেচনা করা blast radius। নির্দিষ্ট সময়সূচি ও calendar reminder মেনে restore করে পরীক্ষা করা backup—এখানে কোনো heroism-এর প্রয়োজন নেই। নিরস redundancy; প্রতিটি ব্যর্থতায়, যার জন্য আমাকে কখনও page করা হয়েছে, একটি অসাধারণ জিনিসের বদলে দুটি সস্তা জিনিসই সব সময় ভালো ফল দিয়েছে।

আর আপনি যে সবচেয়ে efficient datacenter চালাতে পারেন, সেটি হলো যে datacenter আপনি চালান না। একটি VPS power, cooling, redundancy এবং ভোর 3টার hardware failure এমন লোকদের হাতে তুলে দেয়, যারা এগুলো বৃহৎ পরিসরে, নিরসভাবে পরিচালনা করে। Infrastructure-এর ক্ষেত্রে এটিই সর্বোচ্চ প্রশংসা। আর এতে আপনার জন্য সত্যিকারের আনন্দের অংশটি থেকে যায়—নিজের service-গুলো এর ওপর চালানো—এমন একটি machine-এ, যেটি হারালেও আপনি সামলাতে পারবেন। কারণ পরীক্ষা-নিরীক্ষার জন্য আপনার সব সময় এমন machine-ই ব্যবহার করা উচিত।

FAQ

আমার কি আসলেই এগুলোর কোনোটি করা উচিত?

না। এই গাইডের প্রতিটি অংশই এমন documented anti-pattern, যার কারণে অসংখ্য weekend নষ্ট হয়েছে। আপনার বর্তমান setup যদি দুটির বেশি section-এর মতো হয়, তাহলে এই FAQ-এর শেষ প্রশ্নে দেওয়া ক্রম অনুযায়ী যান, কারণ সেটিই triage-এর সঠিক ক্রম।

আসলে ভালো PUE কত?

Hyperscale datacenter-গুলো প্রায় 1.1-এ চলে। ভালোভাবে পরিচালিত enterprise room সাধারণত 1.4 থেকে 1.6 বজায় রাখে। আর cooling-বিহীন closet-এ space heater-এর সঙ্গে দ্বন্দ্ব থাকলে PUE সত্যিই 3-এর বেশি হতে পারে। বাড়িতে 1.1-এর সঙ্গে অর্থবহভাবে প্রতিযোগিতা করা সম্ভব নয়। আপনি যে compute ভাড়া নিতে পারেন, এই সীমাবদ্ধতাই তার পক্ষে একটি নীরব অর্থনৈতিক যুক্তি।

server দিয়ে কোনো building গরম করা কি সত্যিই সম্ভব?

হ্যাঁ, সঠিকভাবে করলে সম্ভব। কয়েকটি দেশের district-heating প্রকল্পে heat exchanger ব্যবহার করে datacenter-এর waste heat সংগ্রহ করা হয় এবং engineering পরিকল্পনা ও contract অনুযায়ী pipe-এর মাধ্যমে বাড়িতে পাঠানো হয়। উপরের satire-এর বিষয় server-এর heat দিয়ে কোনো room গরম করা সম্ভব কি না, তা নয়। বিষয় হলো দুর্ঘটনাবশত তা করা এবং সেই দুর্ঘটনাকে strategy বলা।

আমার server ইতিমধ্যে এমন দেখাচ্ছে। প্রথমে কী করব?

আজ রাতেই backup নিন। Backup server-এর বাইরে অন্য কোথাও রাখুন। এরপর test restore করুন; test না করা backup কেবল একটি দাবি। দ্বিতীয়ত, patch প্রয়োগ করুন এবং যে reboot এতদিন এড়িয়ে যাচ্ছেন তা একটি নির্ধারিত maintenance window-তে করুন। এতে আপনি নজরদারির মধ্যে থেকেই কী ভাঙে তা জানতে পারবেন। তৃতীয়ত, single point of failure ভাগ করুন: DNS এবং monitoring server থেকে সরিয়ে নিন। অন্য সব কাজ শান্ত একটি সপ্তাহ পর্যন্ত অপেক্ষা করতে পারে; এই তিনটি পারে না।