সবচেয়ে কম দক্ষ ডেটা সেন্টার তৈরির গাইড

আপনি কী তৈরি করছেন

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

আমাদের একটি মেট্রিক প্রয়োজন, তাই আমরা ইন্ডাস্ট্রির নিজস্ব মেট্রিকটি ব্যবহার করব: PUE, Power Usage Effectiveness — মোট ফ্যাসিলিটি পাওয়ার এবং কম্পিউটিং ইকুইপমেন্টে পৌঁছানো পাওয়ারের অনুপাত। একটি হাইপারস্কেল ডেটা সেন্টার প্রায় 1.1:1 এ চলে — যেখানে প্রায় প্রতিটি ওয়াট প্রয়োজনীয় কাজে ব্যবহৃত হয়। একটি উন্নত এন্টারপ্রাইজ সার্ভার রুম 1.5 ম্যানেজ করে। আমাদের লক্ষ্য হলো 4.0 বা তার বেশি, যার অর্থ হলো প্রতি ১ ওয়াট কম্পিউটিংয়ের জন্য আরও ৩ ওয়াট অকারণে নষ্ট হয়। আমরা এই সংখ্যাটি প্রায়ই ব্যবহার করব, ঠিক যেভাবে সিরিয়াস গাইডগুলোতে ব্যাকআপের কথা বলা হয়।

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

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

শীতকালে, জানালা খুলে কুলিং করা হয়। বাস্তব ডেটা সেন্টারগুলো বাইরের বাতাস ব্যবহার করে — এই কৌশলটিকে বলা হয় free cooling, যা ইঞ্জিনিয়ারিং, ফিল্টারিং এবং আর্দ্রতা নিয়ন্ত্রণের মাধ্যমে করা হয়। আমরা এটি দুর্ঘটনাবশত ব্যবহার করব, এমন একটি জানালার মাধ্যমে যা বৃষ্টি, পরাগরেণু এবং প্রতি কোয়ার্টারে অন্তত একটি বিভ্রান্ত পাখি প্রবেশ করতে দেয়।

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

একটি সার্ভার, বিশাল, প্রিয়

Redundancy বা অতিরিক্ত ব্যবস্থা কাজের প্রতি দায়বদ্ধতাকে কমিয়ে দেয়। আমাদের ডেটা সেন্টারে ঠিক একটি সার্ভার আছে এবং এটি বিশাল, কারণ 512 GB RAM বিশিষ্ট একটি একক মেশিনকে অবকাঠামো মনে হয়, যেখানে চারটি ছোট মেশিন কেবল একটি কাজের তালিকা মনে হয়।

সার্ভারটির একটি নাম আছে। এটি কোনো 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

এই সংখ্যাটি গর্বের বিষয়, তাই আপনি এর স্ক্রিনশট নেন এবং পোস্ট করেন, এবং যে কোনো অ্যাটাকার যখন এই স্ক্রিনশট দেখে তখন সেও এটি দেখে মুগ্ধ হয়: 1,847 দিন আপটাইম মানে হলো 1,847 দিন কার্নেল ভালনারেবিলিটি, যা কেউ প্যাচ করেনি। রিবুট করা তো অসম্ভবই — রিবুট করার মাধ্যমেই আপনি জানতে পারবেন কোন সার্ভিসগুলো 2021 সালে হাতে স্টার্ট করা হয়েছিল এবং কখনও systemd unit হিসেবে লেখা হয়নি। কারিগরিভাবে কেউ জানে না কোনগুলো। সার্ভারটি এখন সাংগঠনিক চার্টে একটি অপরিহার্য অংশ।

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

পারফরম্যান্সের জন্য ডিস্কগুলো RAID 0 কনফিগারেশনে রাখা হয়েছে। এখানে শূন্য (zero) নির্দেশ করে যে কতটি ডিস্ক ফেইল করতে পারে। সর্বোচ্চ প্রভাবের জন্য, মিশ্র উৎসের স্টোরেজে অ্যারেটি স্ট্রাইপ করুন: দুটি প্রপার SSD, একটি পুরনো স্পিনার, এবং একটি কনফারেন্সের USB স্টিক। অ্যারেটি ঠিক ততটাই নির্ভরযোগ্য যতটা কনফারেন্সের স্টিকটি, এটাই ডিজাইন।

ব্যাকআপ backup_final_v2_REAL নামক একটি ডিরেক্টরি দ্বারা পরিচালিত হয় যা একই অ্যারেতে থাকে এবং এতে পূর্ববর্তী নামকরণ পদ্ধতির একটি tarball থাকে। অফ-সাইট ব্যাকআপ হিসেবে একটি স্টিকি নোট রাখা হয়েছে যাতে লেখা আছে "set up off-site backups," যা প্রযুক্তিগতভাবে আপনার ল্যাপটপের ঢাকনার সাথে বাড়ি নিয়ে গেলে অফ-সাইট হিসেবে গণ্য হয়।

একটি সঠিক ফলাফল হলো: df যেখানে 97% ব্যবহার রিপোর্ট করা হয়েছে এবং পরবর্তী স্প্রিন্টে এটি সমাধানের একটি পরিকল্পনা আছে।

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

DNS সার্ভারটি নিজেই মেশিনে চলে, যাতে সার্ভার ডাউন হয়ে গেলে আপনি কেন ডাউন হয়েছে তা জানার জন্য যে DNS রেকর্ডটি ব্যবহার করতেন সেটিও সাথে নিয়ে চলে যায়। একে বলা হয় কনসোলিডেশন।

ফায়ারওয়ালটি 2021 সালে ডিজেবল করা হয়েছিল — সাময়িকভাবে, কিছু ডিবাগ করার জন্য। ডিবাগিং শেষ হয়েছে; কিন্তু ফায়ারওয়াল ফিরে আসেনি। রাউটারের প্রতিটি পোর্ট "পরে সময় বাঁচানোর জন্য" সার্ভারে ফরওয়ার্ড করা হয়েছে, এবং রাউটারের অ্যাডমিন প্যানেল WAN সাইড থেকে ফ্যাক্টরি পাসওয়ার্ড দিয়ে অ্যাক্সেস করা যায়, যাতে সুবিধাজনক রিমোট ম্যানেজমেন্ট করা যায়। আপনার এবং অন্যদের জন্য।

সার্ভারটি ইদানীং অস্বাভাবিক গরম হচ্ছে, এমনকি অ্যাটিক স্ট্যান্ডার্ড অনুযায়ীও, এবং top দেখাচ্ছে যে সবচেয়ে ব্যস্ত প্রসেসটি হলো xmrig। আমরা ধরে নিচ্ছি এটি সেই মনিটরিং টুল যা আমরা ব্যবহার করছি। আমরা এটি ইনস্টল করিনি — পোর্টগুলো ফরওয়ার্ড করার কিছুকাল পরেই এটি নিজে থেকেই উপস্থিত হয়েছে, যা আমরা ইকোসিস্টেমের সমৃদ্ধ হওয়ার লক্ষণ হিসেবে ধরি। এটি চব্বিশ ঘণ্টা মনিটর করে।

বিদ্যুৎ আসে কনজিউমার পাওয়ার স্ট্রিপের একটি চেইনের মাধ্যমে যার সম্মিলিত দৈর্ঘ্য ব্রেকার প্যানেল পর্যন্ত হাঁটার দূরত্বের চেয়ে বেশি — যা এক অর্থে দক্ষ, কারণ আপনাকে প্রায়ই ব্রেকার প্যানেলে যেতে হবে।

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

যেখানে প্রয়োজন ছিল সেখানে redundancy না রেখে, আমরা এখন সেখানে যোগ করছি যেখানে প্রয়োজন নেই। কোম্পানির হোমপেজ — একটি স্ট্যাটিক HTML ফাইল — একটি ১২-নোড Kubernetes ক্লাস্টার দ্বারা সার্ভ করা হয়। এটি সেই কাজ করে যাকে ইঞ্জিনিয়াররা বলেন resume-driven architecture: পেজটি ঠিক তত দ্রুত লোড হয় যতটা nginx দিত, কিন্তু এখন এটি এমনভাবে ফেইল করতে পারে যার জন্য একজন কনসালট্যান্টের প্রয়োজন হবে।

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

Heating as a service

একটি আধুনিক সার্ভার বিদ্যুৎকে কম্পিউটেশন এবং তাপে রূপান্তরিত করে, এবং আমরা দ্বিতীয় আউটপুটটি সর্বোচ্চ করতে চাই। একটি GPU ছাড়া মিডিয়া সার্ভার হলো ক্লাসিক পদ্ধতি: একটি মাত্র 4K স্ট্রিম CPU-transcoding করলে ১৬টি কোর পূর্ণ হয়ে যাবে এবং একটি ছোট বেডরুম গরম করে দেবে—এমন একটি স্পেস হিটার যা মুভিও প্লে করে। উচ্চাকাঙ্ক্ষী অপারেটররা CPU-তে একটি লার্জ ল্যাঙ্গুয়েজ মডেল চালানো তে উন্নীত হন — একটি ৭০-বিলিয়ন প্যারামিটারের স্পেস হিটার যার একটি API আছে, যা এমন গতিতে টোকেন তৈরি করে যা ঋতুভিত্তিক হিসেবে পরিমাপ করা সবচেয়ে ভালো।

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

Observability বা পর্যবেক্ষণ গুরুত্বপূর্ণ, তাই আমরা একটি সেলফ-হোস্টেড আপটাইম মনিটর ডেপ্লয় করি — সেই একই সার্ভারে যা এটি মনিটর করে। যখন Odin মারা যায়, মনিটরটিও তার সাথে মারা যায়, এবং এখানেই চমৎকার বিষয়টি হলো: কোনো অ্যালার্ট ফায়ার হয় না। কোনো অ্যালার্ট মানে কোনো ইনসিডেন্ট নেই। কোনো ইনসিডেন্ট মানে পরিমাপ অনুযায়ী নিখুঁত আপটাইম। মাসিক রিপোর্টটি এর চেয়ে ভালো আগে কখনও দেখিনি।

সম্পূর্ণতার জন্য, অ্যালার্ট ইমেলগুলো একটি মেইল সার্ভারের মাধ্যমে রিলে করা হয় যা Odin-এর মধ্যেই চলে। ফলে অ্যালার্ট পাইপলাইনটি সম্পূর্ণভাবে সেলফ-কন্টেইনড, ঠিক যেমন একটি সাপ তার নিজের লেজ খাচ্ছে।

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

এটি সেই অংশ যা আমি এড়িয়ে চলছিলাম। এর কোনোটিই কল্পনা নয়। সেই প্রিয় অপূরণীয় সার্ভার, একই ভলিউমে ব্যাকআপসহ RAID 0, "সাময়িকভাবে" ডিজেবল করা ফায়ারওয়াল, একটি পেজ সার্ভ করার জন্য Kubernetes ক্লাস্টার, নিজেকে পর্যবেক্ষণ করা মনিটর — আমি প্রোডাকশনে এগুলোর প্রতিটি দেখেছি। এগুলোর মধ্যে কিছু আমি এই বছরই দেখেছি। আমার শুরুর দিনগুলোতে এক বা দুটি আমি নিজেই তৈরি করেছি।

প্রকৃত দক্ষতা কেমন দেখতে তা একঘেয়ে, তাই এটি তাৎক্ষণিক তর্কে হেরে যায় কিন্তু এক দশকের মধ্যে জয়ী হয়: একটি PUE যা নিয়ে আপনি কখনও ভাবেন না কারণ অন্য কেউ এটি ইঞ্জিনিয়ারিং করেছে। মালিকের আত্ম-প্রতিমতার পরিবর্তে কাজের চাপ অনুযায়ী সাইজ করা মেশিন। একটি বিস্ফোরণ ঘটার আগেই তার blast radius বিবেচনা করা। ব্যাকআপ যা রিস্টোর করার মাধ্যমে নিয়মিত পরীক্ষা করা হয়, ক্যালেন্ডার রিমাইন্ডার এবং কোনো বীরত্ব ছাড়াই। Redundancy যা একঘেয়ে — আমি যে সব ইনসিডেন্টের জন্য পেজ পেয়েছি, সেখানে একটি দামী জিনিসের চেয়ে দুটি সস্তা জিনিস সবসময়ই জয়ী হয়েছে।

এবং আপনি যে সবচেয়ে দক্ষ ডেটা সেন্টার চালাতে পারেন তা হলো সেটি যা আপনি চালান না। একটি VPS বিদ্যুৎ, কুলিং, redundancy এবং রাত ৩টার হার্ডওয়্যার ফেইলিউর সেই সব মানুষের কাছে হস্তান্তর করে যারা এগুলো বড় পরিসরে এবং একঘেয়েভাবে করে, যা অবকাঠামোর জন্য সর্বোচ্চ প্রশংসা — এবং এটি আপনাকে প্রকৃত মজার অংশটি দেয়, যা হলো এর ওপর আপনার নিজস্ব সার্ভিস চালানো, এমন একটি মেশিনে যা আপনি হারাতে পারেন, যা একমাত্র ধরনের মেশিন যেখানে আপনার পরীক্ষা করা উচিত।

FAQ

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

না। এই গাইডের প্রতিটি বিভাগ একটি প্রমাণিত anti-pattern যার কারণে অনেক সপ্তাহান্ত নষ্ট হয়েছে। যদি আপনার বর্তমান সেটআপ দুটি বা তার বেশি বিভাগের মতো হয়, তবে এই FAQ-এর শেষ প্রশ্নটিতে চলে যান — যেভাবে সাজানো আছে সেই ক্রমে, কারণ ক্রমটি হলো ট্রায়াজ (triage)।

আসলে একটি ভালো PUE কত?

হাইপারস্কেল ডেটা সেন্টারগুলো প্রায় 1.1 এ চলে, একটি সুগঠিত এন্টারপ্রাইজ রুম 1.4 থেকে 1.6 ম্যানেজ করে, এবং একটি স্পেস হিটারের লড়াই থাকা আনকুলড ক্লোজেট সত্যিকার অর্থেই 3 এর বেশি হতে পারে। আপনি ঘরে বসে 1.1 এর সাথে প্রতিযোগিতায় আসতে পারবেন না, যা হলো যারা এটি করতে পারে তাদের কাছ থেকে কম্পিউট ভাড়া নেওয়ার একটি অর্থনৈতিক যুক্তি।

সার্ভার দিয়ে বিল্ডিং গরম করা কি বাস্তবসম্মত?

হ্যাঁ — সঠিকভাবে করা হলে। অনেক দেশে ডিস্ট্রিক্ট-হিটিং প্রজেক্টগুলো হিট এক্সচেঞ্জারের মাধ্যমে ডেটা সেন্টারের বর্জ্য তাপ সংগ্রহ করে এবং ইঞ্জিনিয়ারিং ও চুক্তির মাধ্যমে তা বাড়িঘরে পৌঁছে দেয়। উপরের ব্যঙ্গটি এই নয় যে সার্ভারের তাপ একটি রুম গরম করতে পারে; ব্যঙ্গটি হলো ভুলবশত এটি করা এবং সেই ভুলকে একটি কৌশল হিসেবে দাবি করা।

আমার সার্ভার ইতিমধ্যে দেখতে ঠিক এইরকম। আমি প্রথমে কী করব?

আজ রাতে ব্যাকআপ নিন, এমন কোথাও যা সার্ভার নয়, এবং তারপর একটি টেস্ট রিস্টোর করুন — পরীক্ষা না করা ব্যাকআপ কেবল একটি গুজব। দ্বিতীয়ত, প্যাচ এবং রিবুট যা আপনি এড়িয়ে চলছেন, একটি পরিকল্পিত সময়ে করুন, যাতে আপনি দেখেন কী ভেঙে যাচ্ছে। তৃতীয়ত, সিঙ্গেল পয়েন্ট অফ ফেইলিউর আলাদা করুন: DNS এবং মনিটরিং বক্স থেকে সরিয়ে ফেলুন। বাকি সব পরে করা যাবে; এই তিনটি নয়।