Cloud VM — instance type, vCPU, boot আর lifecycle

১ · Cloud VM আসলে কী — একটি বড় যন্ত্রের ভাড়া করা ভাগ

আগের মডিউলে ধরে নিয়েছিলাম, একটি server হাতে আছে। এবার প্রশ্ন, সেই server আসে কোথা থেকে? ক্লাউডে একটি কমান্ড চালালে এক মিনিটের মতো সময়ের মধ্যে একটি Linux যন্ত্র পাওয়া যায়, যার public ঠিকানা আছে, আর আপনি SSH করতে পারেন। কেউ তো দৌড়ে গিয়ে একটি নতুন server বসিয়ে দিলেন না। আসলে কী ঘটল?

Provider-এর data center-এ শক্তিশালী physical server চালু হয়েই আছে। একে বলে host. তার ওপর চলে hypervisor, যা একটি host-এর CPU, memory, disk আর network ভাগ করে কয়েকটি virtual machine বানায়। Cloud VM মানে সেই host-এর একটি ভাগ। AWS একে বলে EC2 instance, Azure বলে Virtual Machine, আর Google Cloud বলে Compute Engine VM. আমরা “VM” আর “instance”, দুটি শব্দই একই অর্থে ব্যবহার করব।

Virtualization কীভাবে কাজ করে, CPU-র VT-x, memory-র EPT, virtio: এসব তাত্ত্বিক দিক আছে Operating Systems-এর virtual machine পর্বে। এখানে আবার নতুন করে করব না। আমাদের প্রশ্ন operational: কোন VM নেবেন, তার কী কী হারাতে পারে, আর বিল কত আসবে।

২ · Instance type — নামের ভেতরের সংকেত

Instance type হলো VM-এর ঠিক করে দেওয়া মাপ: কতগুলো vCPU, কত memory, কোন ধরনের disk সংযোগ, কত network bandwidth. আপনি ইচ্ছামতো ৩ vCPU আর ১৭ GiB চাইতে সাধারণত পারেন না, তালিকা থেকে বেছে নেন। Host-কে সমান টুকরোয় ভাগ করা সহজ, আর এতে ফাঁকা জায়গা কম নষ্ট হয়। ভাতের হোটেলের নির্দিষ্ট প্লেটের মতো: ফুল, হাফ, কোয়ার্টার। (Google Cloud-এ custom machine type-ও আছে, তবে সেখানেও সীমা থাকে।)

পাঁচটি family

কাজের ধরন অনুযায়ী অনুপাত বদলায়। নিচের অনুপাতগুলো চলতি পরিচিত নকশা; সঠিক মান প্রতিটি type-এর পাতায় দেখে নিন।

তিন provider-এর নাম ভেঙে পড়া

AWS-এর অনেক family-তে আকারের সিঁড়ি দ্বিগুণ হয়ে চলে: large সাধারণত 2 vCPU, xlarge 4, 2xlarge 8. দামও মোটামুটি একই হারে বাড়ে, তাই দুটি ছোট VM আর একটি দ্বিগুণ VM-এর ঘণ্টার দাম প্রায়ই কাছাকাছি। নতুন generation প্রায়ই একই দামে বা কম দামে বেশি কাজ দেয়, তবে সেটি নিজের কাজে মেপে দেখাই ভালো। নতুন type-এর তালিকা আর অক্ষরের অর্থ বদলাতে থাকে, তাই ডকুমেন্ট মিলিয়ে নিন।

৩ · vCPU — আসলে কতটা CPU পাচ্ছেন

vCPU মানে virtual CPU. আধুনিক x86 server-এর একটি physical core সাধারণত দুটি hardware thread চালায়। Intel একে বলে Hyper-Threading, সাধারণ নাম SMT. Linux প্রতিটি thread-কে একটি আলাদা CPU হিসেবে দেখে। অনেক x86 instance-এ একটি vCPU মানে এই একটি thread. তাহলে 2 vCPU প্রায়ই একটি core-এর দুই thread, দুটি আলাদা core নয়।

সব জায়গায় নিয়মটি এক নয়। ARM-ভিত্তিক instance-এ, যেমন AWS Graviton-এ, সাধারণত একটি vCPU একটি পুরো physical core, কারণ এই chip-এ SMT নেই। AMD-র কিছু নতুন generation-এও provider vCPU-কে পুরো core হিসেবে দেয়। তাই “৪ vCPU” দুটি ভিন্ন type-এ একই শক্তি বোঝায় না। Linux-এ দেখার পরিচিত উপায় lscpu:

$ lscpu | grep -E 'Architecture|^CPU\(s\)|Thread|Core'
Architecture:          x86_64
CPU(s):                4
Thread(s) per core:    2
Core(s) per socket:    2

এটি নমুনা আউটপুট, যন্ত্র আর version-ভেদে আলাদা হবে। এখানে 4 vCPU আসলে 2 core × 2 thread.

x86 বনাম ARM

Python, Node.js বা Java-র মতো ভাষায় বদল প্রায়ই সহজ, যতক্ষণ native library-র ARM build আছে। Provider-এর “৩০% কম খরচ” ধরনের দাবি বিজ্ঞাপন হিসেবে পড়ুন, আর নিজের কাজ চালিয়ে মাপুন: প্রতি ডলারে কতগুলো অনুরোধ সামলানো গেল।

৪ · Burstable instance আর CPU credit

অনেক কাজ সারাদিন প্রায় অলস থাকে, মাঝে মাঝে হঠাৎ ব্যস্ত হয়: ছোট blog, অফিসের ভেতরের টুল, dev server. এদের জন্য পুরো vCPU সারাক্ষণ ধরে রাখা অপচয়। Burstable instance তাই কম দামে একটি baseline দেয়, আর বাড়তি দরকার হলে জমানো CPU credit খরচ করে ওপরে উঠতে দেয়। AWS-এর t family আর Azure-এর B series এই ধারণায় চলে। Google Cloud-এর shared-core type, যেমন e2-medium, ও bursting দেয়, তবে নিয়ম একই রকম নয়।

হিসাবের নিয়ম

AWS-এর সংজ্ঞায় ১ credit = ১ vCPU ১০০% গতিতে ১ মিনিট। ধরে নিই একটি VM-এর 2 vCPU, আর baseline প্রতি vCPU-তে ২০%.

• প্রতি ঘণ্টার আয়: 2 × 0.20 × 60 = 24 credit.
• প্রতি ঘণ্টার খরচ: vCPU × CPU ব্যবহার × 60. ৮০% ব্যবহারে 2 × 0.80 × 60 = 96 credit.
• নিট: 24 − 96 = −72 credit প্রতি ঘণ্টায়।
• জমার সীমা: ধরে নিই ২৪ ঘণ্টার আয়, 24 × 24 = 576 credit. এর বেশি জমে না।
• কতক্ষণ টিকবে: জমা 304 হলে 304 ÷ 72 ≈ 4.22 ঘণ্টা, অর্থাৎ প্রায় ৪ ঘণ্টা ১৩ মিনিট।

নিচের simulator একটি পুরো দিন চালায়। রাতে ৫%, দিনে ১৫%, সন্ধ্যা ৬টা থেকে রাত ১১টা পর্যন্ত ৮০%, শেষ ঘণ্টায় ২০%. শুরুর জমা ১০০ ধরা হয়েছে। আগে নিজে অনুমান করুন credit কখন ফুরাবে।

// Burstable VM: credit balance over one day (simplified, no-overage mode).
// Assumed VM: 2 vCPU, baseline 20% per vCPU. 1 credit = 1 vCPU at 100% for 1 minute.
const VCPU = 2, BASELINE = 0.20, START = 100;
const EARN = Math.round(VCPU * BASELINE * 60);  // credits earned per hour
const CAP = EARN * 24;                          // assumed cap: one day of earning
const load = h => (h < 8 ? 5 : h < 18 ? 15 : h < 23 ? 80 : 20);  // wanted CPU %

let balance = START, unserved = 0;
console.log("earn", EARN, "per hour, cap", CAP, ", start", START);
console.log("hour want% got% balance note");
for (let h = 0; h < 24; h++) {
  const want = VCPU * 60 * load(h) / 100;       // credits this hour would use
  const spend = Math.min(want, balance + EARN); // cannot spend more than exists
  balance = Math.min(CAP, balance + EARN - spend);
  unserved += want - spend;
  const got = 100 * spend / (VCPU * 60);
  const note = spend < want ? "THROTTLED" : "";
  console.log(String(h).padStart(4), String(load(h)).padStart(5),
    got.toFixed(1).padStart(5), String(Math.round(balance)).padStart(7), note);
}
console.log("work not served today:", Math.round(unserved), "credits");
// Try: VCPU = 4 with the same percentages, or BASELINE = 0.40, or 80 -> 60.

  22    80  33.3       0 THROTTLED

এবার সন্ধ্যার সেই সময়টি ধীরে দেখা যাক। “পরে” চাপুন আর জমা-র ঘরটি লক্ষ করুন।

1earn  = 24 credit/h2spend = 96 credit/h (80%)3time left = balance / 724if balance == 0: CPU = 20%5spend = earn: balance stays 0

কিছু provider-এ overage-এর পথ আছে। লেখার সময়ে AWS T3 আর T4g-তে unlimited mode ডিফল্ট (পুরোনো T2-তে standard): জমা ফুরালেও CPU ওপরে থাকে, আর বাড়তি অংশের জন্য টাকা কাটে। এতে throttling এড়ানো যায়, কিন্তু টানা ব্যস্ত VM-এ বিল এমন হতে পারে যে সাধারণ VM-ই সস্তা ছিল। নিয়ম আর ডিফল্ট type-ভেদে আলাদা, তাই নিজের type-এর ডকুমেন্ট দেখুন।

৫ · Shared host, dedicated host আর noisy neighbour

সাধারণ VM multi-tenant: একই host-এ অন্য গ্রাহকও থাকেন। Hypervisor তাঁদের ডেটা আলাদা রাখে, কিন্তু কিছু সম্পদ সবাই ভাগ করেন: CPU-র shared cache, memory-র পথ, host-এর network. তাই পাশের ভাড়াটিয়া ব্যস্ত হলে আপনার কাজের গতি একটু কাঁপতে পারে। এই সমস্যার নাম noisy neighbour. পাশের ঘরে বিয়েবাড়ির সাউন্ড বক্স বাজলে আপনার ঘরের তালা ঠিকই থাকে, শুধু পড়াশোনায় মন বসে না।

আধুনিক dedicated-CPU type-এ এই সমস্যা অনেক কম, কারণ vCPU সাধারণত নির্দিষ্ট core-এ বাঁধা থাকে। Burstable আর shared-core type-এ এটি বেশি দেখা যায়, কারণ সেখানে CPU ভাগ করার জন্যই কম দাম। লক্ষণ হলো steal time (পর্ব ১১), অর্থাৎ VM চলতে চেয়েছিল কিন্তু hypervisor অন্য কাউকে CPU দিয়েছিল। Latency-র অকারণ ওঠানামাও একটি ইঙ্গিত, তবে আগে নিজের অ্যাপ বাদ দিন। Stop করে আবার start করলে VM সাধারণত অন্য host-এ যায়, তাই এটি একটি সহজ পরীক্ষা, অবশ্য ডাউনটাইমের দামে।

Dedicated host-এ আপনি সাধারণত পুরো host-এর দাম দেন, VM কম চললেও। আর এটি নিজে থেকে বেশি নিরাপত্তা দেয়, এমন ধরে নেবেন না। Provider-এর নিয়ন্ত্রক স্তর, আপনার configuration আর আপনার অ্যাপের ভুল আগের মতোই থাকে। আগে কারণটি লিখুন, তারপর খরচের হিসাব করুন।

৬ · Disk আর network — boot volume, instance store আর bandwidth

ছবি ১৫.১-এ দুই রকম disk দেখেছেন। পার্থক্যটি এই পর্বের সবচেয়ে দামি কথা।

ডেটা কেন হারায়? কোনো জাদু নয়, শুধু পদার্থবিদ্যা। Disk-টি একটি নির্দিষ্ট host-এ স্ক্রু দিয়ে লাগানো। Stop করলে আপনার VM সেই host-এর জায়গা ছেড়ে দেয়, পরের গ্রাহক সেখানে আসতে পারেন, তাই provider সেই disk মুছে ফেলে। পরে start করলে VM হয়তো অন্য host-এ উঠবে, যেখানে খালি অন্য একটি disk আছে। Reboot-এ VM একই host-এ থাকে, তাই ডেটা সাধারণত টিকে থাকে।

তাহলে এত ঝুঁকি নিয়ে instance store কেন? কারণ কিছু কাজে ডেটা অন্য জায়গায় আগে থেকেই আছে: cache, temporary ফাইল, batch-এর মধ্যবর্তী ফলাফল, অথবা তিনটি node-এ replicate করা database. একটি node গেলে বাকিরা তাকে আবার ভরে দেয়। Boot volume-এর ক্ষেত্রে আরেকটি সেটিং মনে রাখুন: delete on termination. অনেক সময় এটি boot volume-এ ডিফল্টে চালু থাকে, তাই VM মুছলে disk-ও যায়। আলাদা data volume-এ অনেক সময় বন্ধ থাকে, তাই disk রয়ে যায় আর বিল চলতে থাকে।

Network bandwidth-ও instance-এর অংশ

VM কত দ্রুত network-এ কথা বলবে, তা তার type-এর সাথে বাঁধা। ছোট type সাধারণত কম পায়। অনেক জায়গায় “Up to 10 Gbps” লেখা থাকে। এর মানে সর্বোচ্চ সীমা, নিশ্চিত গতি নয়; বেশিক্ষণ টানলে baseline-এ নেমে আসতে পারে। Block storage-এর ট্রাফিকও অনেক type-এ আলাদা সীমায় চলে। তাই disk দ্রুত কিনেও লাভ নাও হতে পারে, যদি instance সেই IOPS বা গতি বহন করতে না পারে। Instance আর disk, দুটির মধ্যে যেটি ছোট, সেটিই সীমা।

একটি হিসাব। ৫০০ GB ডেটা 1 Gbps-এ কপি করতে কত সময়? 500 × 10⁹ × 8 bit ÷ 10⁹ bit/s = 4000 সেকেন্ড, অর্থাৎ প্রায় ১ ঘণ্টা ৭ মিনিট, আর protocol-এর বাড়তি অংশ ধরলে আরও বেশি। আর 1 Gbps = 125 MB/s, তাই disk 1000 MB/s দিতে পারলেও network-এই আটকে যাবে।

৭ · VM-এর জীবনচক্র — boot, অবস্থা, খরচ আর IP

একটি VM তৈরির কমান্ডের পরে ভেতরে কী হয়, তা ধাপে ধাপে দেখি। সময়গুলো নমুনা, আসল সময় provider, image আর region-ভেদে আলাদা।

RunInstances  type=gen.large  zone=a
Identity OK   Quota OK
InstanceId: i-0123456789abcdef0

host-17  free 1 vCPU    no
host-42  free 6 vCPU    picked
host-58  type mismatch  no

boot volume  50 GB from image
private IP   10.0.1.25
public IP    203.0.113.7

firmware -> bootloader -> kernel
billing starts around here
SSH: not yet

cloud-init: read instance metadata
cloud-init: install SSH public key
cloud-init: run user-data script

sshd: listening on port 22
app : listening on port 3000
GET /healthz 200

তিন provider-এ একই কাজের কমান্ড নিচে আছে। এগুলো উদাহরণ; চালালে সত্যিকারের resource তৈরি হয় আর টাকা লাগতে পারে। Account থাকলেও চালানো জরুরি নয়। চালালে budget alert রাখুন (পর্ব ৬), আর শেষে অবশ্যই মুছে দিন।

# AWS: --dry-run checks permission and validity, creates nothing
aws ec2 run-instances --dry-run --image-id ami-0123456789abcdef0 \
  --instance-type t3.micro --subnet-id subnet-0123456789abcdef0

# Azure (the resource group must exist first)
az group create --name demo-rg --location southeastasia
az vm create --resource-group demo-rg --name web-1 \
  --image Ubuntu2404 --size Standard_B2s --generate-ssh-keys

# Google Cloud
gcloud compute instances create web-1 --zone=asia-south1-a \
  --machine-type=e2-medium \
  --image-family=ubuntu-2404-lts-amd64 --image-project=ubuntu-os-cloud

# Clean-up (deletes for good; the az line removes the whole group,
# because "az vm delete" alone leaves the disk, NIC and public IP behind)
aws ec2 terminate-instances --instance-ids i-0123456789abcdef0
az group delete --name demo-rg
gcloud compute instances delete web-1 --zone=asia-south1-a

পাঁচটি মূল অবস্থা, আর কোনটিতে কী বিল

নিচের lifecycle ছকটি AWS-এর নামে লেখা, কারণ এই নামগুলোই সবচেয়ে পরিচিত। বিলের কলামটি ধারণা হিসেবে পড়ুন; সঠিক নিয়ম, যেমন প্রতি সেকেন্ডে হিসাব আর ন্যূনতম সময়, provider আর OS-ভেদে আলাদা।

Hibernation তৃতীয় একটি পথ: RAM-এর ছবি boot volume-এ লিখে বন্ধ হওয়া, আর পরে সেখান থেকেই ফেরা। সব type আর image এটি সমর্থন করে না। আর ভুল করে মোছা ঠেকাতে termination protection রাখা যায়: AWS-এ termination protection, Google Cloud-এ deletion protection, Azure-এ resource lock.

Stop আর terminate-এ কী থাকে, কী যায়

নিচের stepper একটি VM-কে পাঁচটি কাজের মধ্য দিয়ে নেয়। এর একটি boot volume আছে, একটি আলাদা data volume আছে (delete on termination বন্ধ), আর একটি instance store. প্রতিটি ধাপে সারিগুলো মিলিয়ে দেখুন। মানগুলো AWS-এর সাধারণ আচরণ ধরে লেখা।

1run-instances2reboot-instances3stop-instances4start-instances5terminate-instances

Public আর private IP

Private IP VM-এর network interface-এ সত্যিই থাকে, আর সাধারণত VM যতদিন আছে ততদিন একই থাকে। Public IP সাধারণত VM-এর OS-এ দেখা যায় না; provider-এর network তাকে private IP-তে NAT করে। তাই ঠিকানাটি বদলানো সহজ। স্থির ঠিকানা চাইলে আলাদা resource নিতে হয়: static public IP. AWS-এ Elastic IP, Azure-এ static public IP address, Google Cloud-এ static external IP. এটি VM-এর জীবন থেকে আলাদা, stop আর terminate-এও আপনার থাকে, আর তাই বিলও চলতে পারে। অনেক provider এখন public IPv4-এর জন্য আলাদা টাকা নেয়। Route আর subnet-এর বিস্তারিত পর্ব ২৫ আর ২৬-এ আসবে।

বিলের হিসাব

এবার সব টাকায় রূপান্তর করি। ধরে নিই VM ঘণ্টায় $০.১০, disk প্রতি GB-মাসে $০.১০, snapshot $০.০৫, static IP ঘণ্টায় $০.০০৫. Boot volume ৫০ GB, data volume ২০০ GB. এগুলো সব অনুমিত সংখ্যা, আসল দাম provider-এর pricing পাতায় দেখুন।

// Monthly bill of one VM's resources in different end states (720-hour month).
// All prices are assumed round numbers: check the provider's pricing page.
const VM_PER_HOUR = 0.10, DISK_GB_MONTH = 0.10, SNAP_GB_MONTH = 0.05;
const IP_PER_HOUR = 0.005, HOURS = 720;
const BOOT_GB = 50, DATA_GB = 200, SNAP_GB = 30;

const scenarios = [
  // name, VM hours, boot disk?, data disk?, static IP?, snapshot?
  ["running all month",     720, 1, 1, 1, 0],
  ["office hours only",     220, 1, 1, 1, 0],
  ["stopped all month",       0, 1, 1, 1, 0],
  ["terminated, leftovers",   0, 0, 1, 1, 0],
  ["terminated, snapshot",    0, 0, 0, 0, 1],
  ["terminated, all clean",   0, 0, 0, 0, 0],
];

function bill([, vmH, boot, data, ip, snap]) {
  const vm = vmH * VM_PER_HOUR;
  const disk = (boot * BOOT_GB + data * DATA_GB) * DISK_GB_MONTH;
  const addr = ip * IP_PER_HOUR * HOURS;
  const snapshot = snap * SNAP_GB * SNAP_GB_MONTH;
  return { vm, disk, addr, snapshot, total: vm + disk + addr + snapshot };
}

console.log("state".padEnd(24), "vm".padStart(6), "disk".padStart(6),
  "ip".padStart(5), "snap".padStart(5), "total".padStart(7));
for (const s of scenarios) {
  const b = bill(s);
  console.log(s[0].padEnd(24), b.vm.toFixed(2).padStart(6), b.disk.toFixed(2).padStart(6),
    b.addr.toFixed(2).padStart(5), b.snapshot.toFixed(2).padStart(5), b.total.toFixed(2).padStart(7));
}
const forgotten = 20 * bill(scenarios[2]).total * 12;
console.log("20 forgotten stopped VMs for a year: $" + forgotten.toFixed(2));

৮ · Metadata service, maintenance আর placement

Instance metadata service

VM-এর ভেতরের প্রোগ্রাম অনেক সময় নিজের সম্পর্কে জানতে চায়: আমার instance id কী, কোন zone, কোন role? এজন্য প্রতিটি VM-এর ভেতর থেকে একটি বিশেষ ঠিকানায় পৌঁছানো যায়: 169.254.169.254. এটি একটি link-local address, যা VM-এর বাইরে route হয় না। এই ব্যবস্থাই instance metadata service. cloud-init এখান থেকেই SSH key পড়ে। আর VM-এ যুক্ত instance role-এর temporary credential-ও এখান থেকেই আসে, যাতে কোডে কোনো key রাখতে না হয়।

এটিই ঝুঁকির জায়গা। ধরুন আপনার অ্যাপ ব্যবহারকারীর দেওয়া URL থেকে ছবি আনে, আর URL যাচাই করে না। তাহলে বাইরের কেউ অ্যাপকে দিয়ে ভেতরের ঠিকানায় অনুরোধ পাঠাতে পারে। এই ধরনের দুর্বলতার নাম SSRF (Server-Side Request Forgery). প্রথম দিকের metadata service সাধারণ GET-এই উত্তর দিত, তাই অ্যাপের এমন ভুল মানেই credential ফাঁসের ঝুঁকি। ২০১৯ সালে Capital One-এর তথ্য ফাঁসের প্রকাশিত বিবরণে এই ধরনের পথের কথা এসেছে।

সমাধান হিসেবে AWS ২০১৯ সালে IMDSv2 আনে। এতে আগে একটি আলাদা ধরনের অনুরোধে অল্প সময়ের session token নিতে হয়, তারপর সেই token header-এ পাঠাতে হয়। সাধারণ SSRF সাধারণত ইচ্ছামতো method আর header পাঠাতে পারে না, তাই পথটি অনেক কঠিন হয়। Token-এর উত্তরের hop limit ১ রাখলে VM-এর ভেতরের container থেকে পৌঁছানোও সাধারণত আটকে যায়। Azure আর Google Cloud নিজের মতো করে একটি বিশেষ header বাধ্যতামূলক রাখে (Metadata: true, Metadata-Flavor: Google).

# AWS: refuse old-style requests on one VM (fake id, sample only)
aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required --http-put-response-hop-limit 1

• Token-ভিত্তিক version বাধ্যতামূলক, পুরোনো পথ বন্ধ
• Instance role-এ শুধু দরকারি অনুমতি (least privilege)
• ব্যবহারকারীর দেওয়া URL allowlist দিয়ে যাচাই
• দরকার না হলে metadata service বন্ধ, অথবা container থেকে পৌঁছানো বন্ধ
• Audit log-এ role-এর অস্বাভাবিক ব্যবহারে নজর (পর্ব ৩৪)

Live migration আর scheduled maintenance

Host-এরও patch লাগে, hardware-ও নষ্ট হয়। তখন আপনার VM-এর কী হয়? Live migration-এ VM চলতে চলতেই অন্য host-এ সরে যায়; মাঝে খুব অল্প থামা হতে পারে। কৌশলটি Operating Systems-এর পর্বে আছে। Clark ও সহকর্মীদের ২০০৫ সালের NSDI paper এর পরিচিত ভিত্তি।

Provider-ভেদে আচরণ আলাদা। Google Cloud-এ অনেক VM ডিফল্টে live migrate হয়, তবে GPU-র মতো কিছু ক্ষেত্রে থামাতে হতে পারে। Azure memory-preserving maintenance আর live migration ব্যবহার করে। AWS-এ সাধারণত scheduled maintenance বা retirement event-এর নোটিশ দেখা যায়, তখন আপনাকে সময়মতো stop-start করে অন্য host-এ যেতে হতে পারে। তাই metadata বা কনসোলের event-এ চোখ রাখুন, আর ধরে নিন যেকোনো VM যেকোনো দিন যেতে পারে। মনে রাখবেন, হঠাৎ hardware নষ্ট হলে migration-এর সুযোগই নেই।

Placement group

সাধারণত provider ঠিক করে VM কোন host-এ বসবে। Placement group দিয়ে আপনি শুধু একটি ইচ্ছা জানান: VM-গুলো কাছাকাছি বসবে, না দূরে দূরে। AWS-এর নামে তিন ধরন:

Azure-এ proximity placement group আর availability set, Google Cloud-এ compact আর spread placement policy একই ধরনের কাজ করে। আসল কথা failure domain: গতি চাইলে কাছাকাছি, টিকে থাকা চাইলে দূরে। দুটি একসাথে পুরোপুরি পাওয়া যায় না।

৯ · VM-এর আকার ঠিক করা — মেপে, আন্দাজে নয়

নতুনদের সাধারণ অভ্যাস: “বড়টাই নিই, নিরাপদ।” এতে over-provisioning হয়, মানে প্রতি মাসে অকারণ টাকা। ক্লাউডে বদলানো সহজ বলেই শুরুতে অনুমান করা যায়, তারপর মেপে ঠিক করতে হয়। চারটি জিনিস মাপুন: CPU, memory, disk I/O আর network. কোনটি আগে ফুরায়, সেটিই আপনার সীমা।

গড় দেখলে ভিড় ঢেকে যায়, আর সর্বোচ্চ দেখলে একবারের spike-এ সব ঠিক হয়। তাই সাধারণ পথ percentile, বিশেষত p95. নিচের Bash block একটি 4-vCPU VM-এর এক দিনের ২০টি নমুনা থেকে গড়, p95 আর সর্বোচ্চ বের করে। ডেটা বানানো, এবং block-এর ভেতরেই আছে।

#!/usr/bin/env bash
# p95 of a day's samples from a 4-vCPU VM. The data is a made-up sample.
set -euo pipefail
cat > metrics.csv <<'EOF'
time,cpu_pct,mem_gib,iops,net_mbps
00:00,18,7.4,1800,120
01:12,16,7.4,1500,100
02:24,97,8.2,11800,1400
03:36,14,7.3,1300,90
04:48,15,7.3,1400,95
06:00,20,7.5,2000,160
07:12,28,7.8,2900,260
08:24,38,8.1,3900,410
09:36,47,8.4,4800,560
10:48,52,8.6,5400,640
12:00,58,8.8,6100,730
13:12,55,8.7,5800,700
14:24,60,8.9,6600,790
15:36,62,9.1,7200,850
16:48,57,8.8,6200,740
18:00,49,8.5,5100,600
19:12,44,8.3,4500,520
20:24,36,8.0,3600,380
21:36,27,7.7,2700,240
22:48,21,7.5,2100,170
EOF
summary() {  # column number -> average, nearest-rank p95, maximum
  tail -n +2 metrics.csv | cut -d, -f"$1" | sort -n | awk '{ v[NR] = $1; s += $1 }
    END { r = int(NR * 0.95 + 0.999); printf "%.1f %s %s\n", s / NR, v[r], v[NR] }'
}
echo "metric avg p95 max"
n=2
for name in cpu_pct mem_gib iops net_mbps; do echo "$name $(summary "$n")"; n=$((n + 1)); done
summary 2 | awk '{ printf "p95 CPU on 4 vCPU = %.2f vCPU\n", 4 * $2 / 100 }'

এবার মাপা মানকে type-এ রূপান্তর। প্রতিটি সীমার ৭০% পর্যন্ত ব্যবহারের লক্ষ্য রাখা হলো, যাতে ভিড় আর নতুন বৃদ্ধির জায়গা থাকে। সূত্র: দরকার = মাপা p95 ÷ 0.70. ক্যাটালগের নামগুলো কাল্পনিক, দামও অনুমিত।

// Pick the cheapest type that fits measured p95 values plus headroom.
// Fictional catalogue. Prices are assumed: check the provider's pricing page.
const types = [
  ["gen.large",   2,  8, 10000,  1250, 0.10],
  ["cpu.xlarge",  4,  8, 20000,  2500, 0.17],
  ["gen.xlarge",  4, 16, 20000,  2500, 0.20],
  ["mem.xlarge",  4, 32, 20000,  2500, 0.26],
  ["net.xlarge",  4, 16, 20000, 12500, 0.28],
  ["cpu.2xlarge", 8, 16, 40000,  5000, 0.34],
  ["gen.2xlarge", 8, 32, 40000,  5000, 0.40],
].map(([name, vcpu, mem, iops, mbps, usd]) => ({ name, vcpu, mem, iops, mbps, usd }));

const TARGET = 0.70;   // keep p95 at or below 70% of each limit
const dims = ["vcpu", "mem", "iops", "mbps"];

function size(job) {
  const need = {};
  for (const d of dims) need[d] = job[d] / TARGET;
  const fits = t => dims.every(d => t[d] >= need[d]);
  const best = types.filter(fits).sort((a, b) => a.usd - b.usd)[0];
  const shown = dims.map(d => d + "=" + need[d].toFixed(d === "vcpu" ? 2 : 0));
  console.log(job.name, "needs", shown.join(" "));
  if (!best) return console.log("  no type fits: split the work or scale out");
  const month = (best.usd * 720).toFixed(0);
  console.log("  pick", best.name, "at $" + best.usd + "/h, about $" + month + "/month");
}

size({ name: "web-app",    vcpu: 2.48, mem: 8.9, iops: 7200, mbps: 850 });
size({ name: "cache",      vcpu: 1.1,  mem: 20,  iops: 900,  mbps: 700 });
size({ name: "batch",      vcpu: 5.0,  mem: 7,   iops: 3000, mbps: 400 });
size({ name: "video-edge", vcpu: 2.0,  mem: 6,   iops: 2000, mbps: 3000 });
size({ name: "huge-db",    vcpu: 7.0,  mem: 60,  iops: 35000, mbps: 2000 });

ব্যবহারিক ক্রম

1. একটি যুক্তিসঙ্গত ছোট আকার দিয়ে শুরু করুন।
2. অন্তত একটি পুরো ব্যবসায়িক চক্র (সপ্তাহ বা মাস) মাপুন, শুধু একটি শান্ত দিন নয়।
3. Memory-র মাপে নজর দিন। Cloud-এর ডিফল্ট VM metric-এ OS-এর memory প্রায়ই থাকে না, তাই agent লাগতে পারে। page cache-কে ব্যবহৃত ধরে নেবেন না (পর্ব ১১)।
4. Load test করে দেখুন আসলে কোনটি আগে ভরে যায় (পর্ব ৬৮)।
5. একটি ধাপ বদলান, মাপুন, লিখে রাখুন। Resize করতে সাধারণত stop-start লাগে, তাই সময় ঠিক করে নিন।
6. একটি বড় VM-এর বদলে কয়েকটি ছোট VM, এ প্রশ্নও ভাবুন (পর্ব ১৭)। Discount আর spot-এর হিসাব পর্ব ৭২-এ, নিয়মিত rightsizing পর্ব ৭৩-এ।

১০ · AI-এর যুগে VM বাছাই আর চালানো

AI এক মিনিটে VM তৈরির script লিখে দেয়। সমস্যা হলো script চলবে, VM উঠবে, কিন্তু ভুলটি ধরা পড়বে মাসের শেষে বিলে, অথবা নিরাপত্তার ঘটনায়।

AI-এর দেওয়া VM নকশা চালানোর আগে — চেকলিস্ট

• Instance type আর প্রতিটি flag সরকারি ডকুমেন্টে পেয়েছি, আমার region-এ আছে
• আকারের পেছনে মাপা সংখ্যা আছে, আন্দাজ নয়
• কোন ডেটা কোন disk-এ থাকে, আর stop করলে কী হারায় জানি
• Public IP বদলালে কী ভাঙবে, তা ভেবেছি
• --dry-run আগে চালিয়েছি, পরীক্ষা হয়েছে আলাদা throwaway account বা project-এ
• Metadata token বাধ্যতামূলক, role সরু, port সরু
• Burstable হলে credit-এর alert আছে
• Budget alert আছে, আর শেষে VM, disk, IP আর snapshot মুছেছি
• Prompt-এ কোনো secret দিইনি