# একটি নোড হলো ক্লাস্টার, অথচ কোনো অ্যাপ্লিকেশন বদলাতে হয়নি

Company: Webanion
Service: ডেভঅপস ইঞ্জিনিয়ারিং
Period: 2026-07 - 2026-09
Tech: Kubernetes, Traefik, Linux, systemd, Go, Grafana, VictoriaMetrics, GitHub Actions
Canonical: https://webanion.com/bn/portfolio/scaling-a-homelab-from-one-node-to-a-multi-node-cluster

যেকোনো মুহূর্তে বন্ধ হতে পারে এমন একটি দ্বিতীয় মেশিন কোনো অ্যাপ্লিকেশন না বদলেই চলমান একটি এক-নোডের ক্লাস্টারে যোগ দিয়েছে। সবসময় চালু থাকা একটি সার্ভার রাখে কন্ট্রোল প্লেন, প্রতিটি ডেটাবেস ও ভলিউম আর প্রতিটি সার্ভিসের প্রথম কপি; বিল্ড মেশিন একটি taint-এর আড়ালে বিল্ড আর স্টেটলেস সার্ভিসের দ্বিতীয় কপিগুলো নেয়, আর সেটি ঘুমিয়ে থাকলে সেই কপিগুলো ফিরে না গিয়ে অপেক্ষা করে। কাজ ফুরোলে সেটি নিজেই বন্ধ হয় আর কোনো জব সারিতে এলে ফিরে আসে, একটি কনসোল প্রতিটি নোড, ওয়ার্কলোড আর উপস্থিতির সময়সীমা দেখায়, আর সবসময় চালু সার্ভারের প্রতিটি CPU request মাপা হয়েছে, যাতে তার রিজার্ভেশন বরাদ্দযোগ্য সক্ষমতার ৮৪ থেকে ৫৬ শতাংশে নেমে এসেছে।

## পুরো গল্পটা

চলমান একটি ব্যবস্থায় কোনো মাইগ্রেশন ছাড়াই কীভাবে সক্ষমতা বাড়ানো হলো, আর ভাড়া না নিয়ে নিজে অবকাঠামো চালানোর ব্যাপারে এটি কী প্রমাণ করে।

### একটি মেশিনই সব করত, আর তার রিজার্ভেশন ফুরিয়ে গেল

<p>প্রথম কয়েক মাস ক্লাস্টার বলতে ছিল সবসময় চালু থাকা একটিমাত্র সার্ভার, আর সবকিছু ছিল তার ওপর: কন্ট্রোল প্লেন, প্রতিটি ডেটাবেস ও ভলিউম, প্রতিটি পাবলিক সাইট, রেজিস্ট্রি, আর প্রতিটি ডিপ্লয়ের সময় খোদ বিল্ডটাও। যেকোনো নোডে একটি CPU request আসলে একটি রিজার্ভেশন, কাজটি সেটা ব্যবহার করুক বা না করুক শিডিউলার তা আলাদা করে রাখে, তাই ব্যস্ত একটি নোডের কাজ ফুরোনোর অনেক আগেই রিজার্ভেশন ফুরিয়ে যায়। সবসময় চালু সার্ভারটি তার বরাদ্দযোগ্য CPU-র ৮৪ শতাংশে পৌঁছে গিয়েছিল, তাই মেশিনটিকে যত শান্তই দেখাক, পরের ওয়ার্কলোডটি আর জায়গা পেত না।</p><p>নতুন মেশিন কখনো হারিয়ে না গেলে সক্ষমতা বাড়ানো সহজ। কঠিন রূপটি হলো এমন একটি দ্বিতীয় মেশিন যা যেকোনো মুহূর্তে বন্ধ হয়ে যেতে পারে, আর সেটি নিরাপদ কেবল তখনই যখন ক্লাস্টার ঠিক জানে সেই মেশিনে কী চলতে পারে আর কোন কিছু কখনো তার ওপর নির্ভর করবে না। যে নিয়ম একে নিরাপদ করেছে তা এক লাইনে বলা যায়: ডেটা রাখে এমন কিছুই কখনো এমন কোনো মেশিনে চলে না যা হারিয়ে যেতে পারে।</p>

### বিপরীত দায়িত্বের মেশিনগুলো

<p>একটি সার্ভার কখনো বন্ধ হয় না, আর তার ওপর থাকে কন্ট্রোল প্লেন, প্রতিটি ডেটাবেস ও ভলিউম, রেজিস্ট্রিগুলো আর প্রতিটি সার্ভিসের প্রথম কপি। বিল্ড মেশিনটি যেকোনো মুহূর্তে বন্ধ থাকতে পারে, আর চালু থাকলে বিল্ড ও দ্বিতীয় কপিগুলোর দায়িত্ব নেয়। একটি রোল লেবেল আর একটি taint ঠিক করে কী কোথায় বসতে পারে, আর নিজে না চাইলে কিছুই বিল্ড মেশিনে গিয়ে বসে না।</p>

### প্রতিটি নোডের অবস্থা এক স্ক্রিনে, ঘুমন্ত নোডগুলোসহ

<p>কনসোলের Estate ভিউ প্রতিটি নোডকে একটি কার্ড দেয়: তার রোল, তার ওয়ার্কলোডগুলো যা চেয়েছে আর আসলে যা ব্যবহার করছে, কতগুলো pod সে বহন করছে, আর গত এক দিন বা এক সপ্তাহের একটি উপস্থিতির রেখা, যেখানে Ready ও Away-এর প্রতিটি সময়সীমা তালিকায় আছে। কার্ডগুলো ইচ্ছে করেই একে অন্যের বিপরীত দেখায়। ছবি তোলার দিনে সবসময় চালু সার্ভারটি আগের পুরো সাত দিনই Ready ছিল, আর বিল্ড মেশিনটি তার ৩৭ শতাংশ সময়, ৩০টি রেকর্ড করা পরিবর্তনসহ, কারণ কাজ না থাকলেই সেটি ঘুমিয়ে পড়ে।</p><p>আশা নয়, রোল আর একটি taint-ই ওয়ার্কলোডকে তার ঠিক জায়গায় রাখে। সবসময় চালু সার্ভারটিতে আছে তার রোল, কোনো taint নেই, তাই সাধারণ ওয়ার্কলোড সেখানেই বসে। বিল্ড মেশিনে আছে একটি taint, যা এমন প্রতিটি pod-কে ফিরিয়ে দেয় যে ঘোষণা করেনি যে হারিয়ে যেতে পারে এমন নোডেও সে টিকে থাকতে পারবে, তাই ভুল করে কিছুই সেখানে বসে না, আর যে ওয়ার্কলোডগুলো ডিস্কে ডেটা রাখে সেগুলো সেই ডিস্ক যে সার্ভারে আছে তাতেই পিন করা।</p>

### ভুল নোডে কিছুই বসে না, আর কাউকে নোডের অপেক্ষায় থাকতে হয় না

<p>বাড়তি সক্ষমতায় লাভবান একটি স্টেটলেস সার্ভিস অন্য কোথাও সরে যায় না, বরং একটি দ্বিতীয় কপি পায়। মূল কপিটি সবসময় চালু সার্ভারেই থাকে, আর বিল্ড মেশিন বন্ধ থাকলে একাই সেবা দেয়। দ্বিতীয় কপিটি কেবল বিল্ড মেশিনেই চলতে পারে, আর কোথাও নয়: সেই মেশিন ঘুমিয়ে থাকলে কপিটি পার্ক করা অবস্থায় অপেক্ষা করে, আর কখনো সবসময় চালু সার্ভারে ফিরে আসে না, কারণ সেখানকার রিজার্ভেশনই সবচেয়ে দুর্লভ সম্পদ। মেশিনটি ফিরে এলে কপিগুলো নিজে থেকেই চালু হয়ে আবার ট্রাফিকে যোগ দেয়।</p><p>এজ-কে সাজানো হয়েছে এমন নোডের কথা ভেবে যা কিছু না জানিয়েই হারিয়ে যায়। বিদ্যুৎ হারানো মেশিনের একটি কপি সংযোগ প্রত্যাখ্যান করে না, সেটি শুধু সাড়া দেওয়া বন্ধ করে, তাই রাউটার আধা মিনিটের বদলে কয়েক সেকেন্ডের মধ্যেই তাকে ছেড়ে দেয় আর একবার আবার চেষ্টা করে, কেবল পেজ রিকোয়েস্টে, ফলে একজন ভিজিটর ঘুরতে থাকা লোডিং চিহ্নের বদলে সামান্য দেরিতে পেজটি পান। ২২ সেপ্টেম্বর আটটি সার্ভিসের দ্বিতীয় কপি ছিল, তাদের মধ্যে ওয়েবসাইট আর পাবলিক MCP সার্ভারও; ডেটাবেস, CMS আর প্রতিটি ব্যাকএন্ড সবসময় চালু সার্ভারে একক কপিতেই থাকে। ছবিগুলোতে দুটি অবস্থাই দেখা যায়: বিল্ড মেশিন ঘুমিয়ে থাকার সময় পার্ক করা কপি, আর সেটি চালু থাকার সময় প্রতিটি নোড থেকে সেবা দেওয়া ওয়েবসাইট ও MCP সার্ভার।</p>

### কাজ না আসা পর্যন্ত ঘুমিয়ে থাকা সক্ষমতা

<p>বিল্ড মেশিনটি কিছু না করেও ষাট থেকে সত্তর ওয়াট বিদ্যুৎ টানে, তাই সেটি অকারণে বসে থাকে না। কাজ ফুরিয়ে গেলে সেটি নিজেই বন্ধ হয়ে যায়, আর কোনো জব সারিতে এলে কয়েক মিনিটের মধ্যেই আবার ক্লাস্টারে ফিরে আসে, কাউকে মনে করে সেটি চালু করতে হয় না। Hosts ভিউ মেশিনগুলোকে পাশাপাশি দেখায়: এক দিনের ইতিহাসসহ লোড, মেমোরি, ডিস্ক, তাপমাত্রা, আর সীমার তুলনায় বিল্ড ক্যাশ।</p><p>ফোনের ভিউ নকশার বাকি অর্ধেকটা দেখায়। বিল্ড মেশিন অনুপস্থিত থাকলে তার শেষ রিডিংগুলো স্ক্রিনে থেকে যায়, কত পুরোনো তা চিহ্নিত করে, তাই একটি খালি জায়গা কোনো ত্রুটি নয়, বিশ্রামে থাকা একটি মেশিন হিসেবেই পড়া যায়। এর ফল এমন সক্ষমতা যা কাজ এলে চালু থাকে আর না এলে বন্ধ থাকে।</p>

### রিকোয়েস্টই ছিল দুর্লভ সম্পদ, তাই প্রতিটি মাপা হয়েছে

<p>সবসময় চালু সার্ভারের প্রতিটি রিকোয়েস্ট ত্রিশ সেকেন্ড পরপর নেওয়া চল্লিশটি নমুনায় মাপা হয়েছে, আর প্রতিটি ওয়ার্কলোডের সর্বোচ্চ ব্যবহারের সঙ্গে কিছুটা বাড়তি জায়গা রেখে ঠিক করা হয়েছে। সার্ভারটি তার ওয়ার্কলোডগুলোর আসল ব্যবহারের প্রায় নয় গুণ রিজার্ভ করে রাখছিল; এরপর তার রিজার্ভেশন বরাদ্দযোগ্য সক্ষমতার ৮৪ থেকে ৫৬ শতাংশে নেমে আসে, যা আরেকটি মেশিন ছাড়াই পরের সার্ভিসের জন্য জায়গা করে দেয়।</p>

### পরের মেশিনটি একটি রোল, কোনো প্রজেক্ট নয়

<p>এই পুরো পথে কোনো অ্যাপ্লিকেশন বদলায়নি। প্লেসমেন্ট থাকে একটি রোল লেবেল, একটি taint, affinity আর প্রতিটি সার্ভিসের নিজস্ব overlay-তে, তাই সার্ভিসগুলো কখনো জানতেই পারেনি মেশিন কয়টি। পরের ধাপকে রুটিন কাজে পরিণত করে এটাই: পরের মেশিনটি একটি রোল আর বিল্ড রানারের একটি ভাগ পেয়েই যোগ দেয়, একটি সার্ভিস নিজের রিপোজিটরি থেকেই দ্বিতীয় কপি বেছে নেয়, আর একই ধাঁচের আরেকটি ক্লাস্টার নতুন নকশা ছাড়াই একই ধাপগুলো আবার করে। এটি দুই দিকেই বাড়ানো বা কমানো যায়, কারণ বিল্ড মেশিন বন্ধ করলে কিছুই হারায় না আর কোনো drain লাগে না; চলে যায় শুধু বাড়তি গতিটুকু।</p><p>সীমাটি আগেই বলে দেওয়া, পরে খুঁজে পেতে হয় না: বিল্ডের মাঝপথে বিদ্যুৎ চলে গেলে সেই বিল্ড ব্যর্থ হয়, আর সেটি আবার চালানো হয়। এটি এমন ব্যবসার জন্য উপযুক্ত যার নিজস্ব হার্ডওয়্যার আছে আর যার মাইগ্রেশন ছাড়াই বেশি সক্ষমতা দরকার, আর এটি সেই প্রশ্নের উত্তর দেয় যা একজন CTO অবকাঠামো হাতে তুলে দেওয়ার আগে জানতে চান: সামনের মানুষটি কি এর জন্য কোড লেখার পাশাপাশি এটি চালাতেও পারেন। এর নিচের প্ল্যাটফর্মটি হলো <a href="/portfolio/self-hosted-homelab-that-runs-the-studio-infrastructure">স্টুডিও চালানো সেলফ-হোস্টেড হোমল্যাবের</a> গল্প, আর ডেলিভারির জন্য বিল্ড মেশিন কী করেছে তা <a href="/portfolio/replacing-hosted-ci-with-a-home-runner-pool-and-private-registries">হোস্টেড CI-এর জায়গায় নিজস্ব রানার পুল আনার</a> গল্প।</p>
