ভার্চুয়াল মেশিন ও ইনস্ট্যান্স টাইপ

Virtual machines & instance types

৮ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

এক নজরে · TL;DR

ভার্চুয়াল মেশিন (VM) — শেয়ার্ড ফিজিক্যাল হার্ডওয়্যারে একটি হাইপারভাইজারের মাধ্যমে চলা একটি এমুলেটেড কম্পিউটার — IaaS-এর মৌলিক বিল্ডিং ব্লক।
ইনস্ট্যান্স ফ্যামিলি বিভিন্ন ওয়ার্কলোডের জন্য অপ্টিমাইজড — জেনারেল-পারপাস (ব্যালেন্সড), কম্পিউট-অপ্টিমাইজড, মেমরি-অপ্টিমাইজড, স্টোরেজ-অপ্টিমাইজড।
সঠিক ফ্যামিলি বেছে নিলে অব্যবহৃত ক্যাপাসিটির জন্য টাকা দেওয়া এড়ানো যায়।
ভার্টিক্যাল স্কেলিং (বড় ইনস্ট্যান্স) বনাম হরাইজন্টাল স্কেলিং (আরও ইনস্ট্যান্স, L06-এ বিস্তারিত)।

এই পাঠে যা শিখবেন

ভার্চুয়াল মেশিন কী এবং হাইপারভাইজার কীভাবে একে শেয়ার্ড হার্ডওয়্যারে সম্ভব করে
ইনস্ট্যান্স ফ্যামিলি — কেন বিভিন্ন ওয়ার্কলোডের জন্য বিভিন্ন হার্ডওয়্যার প্রোফাইল দরকার
ভার্টিক্যাল বনাম হরাইজন্টাল স্কেলিং-এর পার্থক্য
Python দিয়ে একটি ওয়ার্কলোডের প্রয়োজন মেটানো সবচেয়ে সাশ্রয়ী ইনস্ট্যান্স বেছে নেওয়ার ফাংশন

১ · ভার্চুয়াল মেশিন কী

ভার্চুয়াল মেশিন (VM)Virtual Machineশেয়ার্ড ফিজিক্যাল হার্ডওয়্যারে একটি হাইপারভাইজারের মাধ্যমে চলা একটি এমুলেটেড কম্পিউটার — নিজস্ব OS, নিজস্ব বরাদ্দকৃত vCPU ও মেমরিসহ। হলো একটি এমুলেটেড কম্পিউটার — এটি শেয়ার্ড ফিজিক্যাল হার্ডওয়্যারের উপর একটি হাইপারভাইজার (একটি বিশেষ সফটওয়্যার লেয়ার) দিয়ে চলে, যা একই ফিজিক্যাল সার্ভারে একাধিক স্বাধীন VM চালানো সম্ভব করে — প্রতিটি VM-এর নিজস্ব OS, নিজস্ব বরাদ্দকৃত vCPU (ভার্চুয়াল CPU) ও মেমরি থাকে, যদিও আন্ডারলাইং ফিজিক্যাল হার্ডওয়্যার শেয়ার্ড (L02-এর মাল্টি-টেন্যান্সি ধারণার প্রয়োগ)। VM হলো IaaS-এর সবচেয়ে মৌলিক বিল্ডিং ব্লক — L01-এর IaaS ধারণাটির সবচেয়ে সাধারণ বাস্তবায়ন।

২ · ইনস্ট্যান্স ফ্যামিলি — বিভিন্ন ওয়ার্কলোডের জন্য বিভিন্ন হার্ডওয়্যার

প্রতিটি প্রোভাইডার VM-কে বিভিন্ন "ইনস্ট্যান্স টাইপ" বা "সাইজ"-এ অফার করে — প্রতিটির নির্দিষ্ট vCPU/মেমরি/স্টোরেজ কম্বিনেশন থাকে, এবং এগুলো ফ্যামিলিতে সাজানো থাকে যা নির্দিষ্ট ধরনের ওয়ার্কলোডের জন্য অপ্টিমাইজড।

জেনারেল-পারপাস
CPU ও মেমরির ব্যালেন্সড অনুপাত — বেশিরভাগ সাধারণ ওয়েব অ্যাপের জন্য উপযুক্ত।

কম্পিউট-অপ্টিমাইজড
উচ্চ vCPU-থেকে-মেমরি অনুপাত — CPU-ভারী ওয়ার্কলোড (ব্যাচ প্রসেসিং, ভিডিও এনকোডিং)-এর জন্য।

মেমরি-অপ্টিমাইজড
উচ্চ মেমরি-থেকে-vCPU অনুপাত — ডেটাবেস, ইন-মেমরি ক্যাশিং-এর জন্য।

স্টোরেজ-অপ্টিমাইজড
উচ্চ, দ্রুত ডিস্ক I/O — বড় ডেটাবেস বা ডেটা-ওয়্যারহাউজ ওয়ার্কলোডের জন্য।

সঠিক ফ্যামিলি বেছে না নিলে কী হয়

একটি ডেটাবেস ওয়ার্কলোডের জন্য কম্পিউট-অপ্টিমাইজড ইনস্ট্যান্স বেছে নিলে হয়তো পর্যাপ্ত মেমরি না পেয়ে পারফরম্যান্স সমস্যায় পড়বেন, অথবা প্রয়োজনের চেয়ে বেশি vCPU-এর জন্য টাকা দিয়ে ফেলবেন যা কখনও ব্যবহার হবে না। সঠিক ফ্যামিলি বেছে নেওয়া মানে ঠিক যে রিসোর্স দরকার তার জন্যই টাকা দেওয়া — L03-এর CapEx/OpEx ইকোনমিক্সের একটি ব্যবহারিক প্রয়োগ।

৩ · ভার্টিক্যাল বনাম হরাইজন্টাল স্কেলিং

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

৪ · সঠিক ইনস্ট্যান্স বেছে নেওয়া — Python উদাহরণ

একটি ওয়ার্কলোডের ন্যূনতম vCPU ও মেমরি প্রয়োজন জেনে, আমরা প্রোগ্রাম্যাটিকভাবে সেই প্রয়োজন মেটানো সবচেয়ে সাশ্রয়ী ইনস্ট্যান্স খুঁজে বের করতে পারি — এটিই বাস্তব-জগতের রাইটসাইজিং সিদ্ধান্তের একটি সরলীকৃত সংস্করণ (L50-এ বিস্তারিত)।

Python

# ইনস্ট্যান্স ফ্যামিলি ক্যাটালগ (illustrative, ঘণ্টাপ্রতি খরচ কাল্পনিক)
instance_catalog = {
    "general-small":    {"vcpus": 2,  "memory_gb": 4,  "hourly_cost": 0.05},
    "general-medium":   {"vcpus": 4,  "memory_gb": 16, "hourly_cost": 0.12},
    "compute-large":    {"vcpus": 8,  "memory_gb": 16, "hourly_cost": 0.20},
    "memory-large":     {"vcpus": 4,  "memory_gb": 32, "hourly_cost": 0.22},
    "memory-xlarge":    {"vcpus": 8,  "memory_gb": 64, "hourly_cost": 0.40},
}

def pick_cheapest_meeting_requirements(min_vcpus, min_memory_gb):
    """প্রয়োজন মেটানো ইনস্ট্যান্সগুলোর মধ্যে সবচেয়ে সাশ্রয়ীটি বেছে নেয়।"""
    eligible = {
        name: info for name, info in instance_catalog.items()
        if info["vcpus"] >= min_vcpus and info["memory_gb"] >= min_memory_gb
    }
    if not eligible:
        return None
    return min(eligible.items(), key=lambda item: item[1]["hourly_cost"])

# উদাহরণ ১: একটি ছোট ওয়েব অ্যাপ (কম vCPU, কম মেমরি যথেষ্ট)
requirement_1 = pick_cheapest_meeting_requirements(min_vcpus=2, min_memory_gb=4)
print("ওয়েব অ্যাপের জন্য সেরা পছন্দ:", requirement_1)

# উদাহরণ ২: একটি ইন-মেমরি ক্যাশ সার্ভার (উচ্চ মেমরি দরকার)
requirement_2 = pick_cheapest_meeting_requirements(min_vcpus=4, min_memory_gb=30)
print("ইন-মেমরি ক্যাশের জন্য সেরা পছন্দ:", requirement_2)

লক্ষ্য করুন প্রথম উদাহরণে সবচেয়ে সস্তা "general-small" বেছে নেওয়া হয়েছে (যথেষ্ট), কিন্তু দ্বিতীয় উদাহরণে "memory-large" বেছে নেওয়া হয়েছে কারণ উচ্চ মেমরি প্রয়োজন — যদিও "compute-large"-এর vCPU বেশি, তার মেমরি যথেষ্ট নয়, তাই তা বাদ পড়ে যায়। এই ধরনের ফিল্টার-অ্যান্ড-সিলেক্ট লজিকই বাস্তব রাইটসাইজিং টুলের মূল ভিত্তি।

মূল কথা · Key takeaway

VM হলো ক্লাউড কম্পিউটের ভিত্তি — সঠিক ইনস্ট্যান্স ফ্যামিলি ও সাইজ বেছে নেওয়া মানে ঠিক প্রয়োজনীয় রিসোর্সের জন্যই টাকা দেওয়া, না বেশি (অপচয়) না কম (পারফরম্যান্স সমস্যা)। L06-এ আমরা দেখব কীভাবে একাধিক VM একসাথে স্বয়ংক্রিয়ভাবে বাড়ানো-কমানো যায়।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ কেন একটি হাইপারভাইজার একই ফিজিক্যাল সার্ভারে একাধিক VM নিরাপদে আলাদা রাখতে পারে?

হাইপারভাইজার প্রতিটি VM-কে ফিজিক্যাল হার্ডওয়্যার রিসোর্স (CPU, মেমরি, ডিস্ক) থেকে বিমূর্ত (abstract) করে, প্রতিটিকে তার নিজস্ব ভার্চুয়ালাইজড রিসোর্স বরাদ্দ দেয় এবং একটি VM-কে সরাসরি ফিজিক্যাল হার্ডওয়্যার বা অন্য VM-এর মেমরি অ্যাক্সেস করতে বাধা দেয় — এই আইসোলেশন লেয়ারই মাল্টি-টেন্যান্সিকে (L02) নিরাপদ করে তোলে, যদিও কন্টেইনারের (L22) তুলনায় শক্তিশালী, কারণ প্রতিটি VM-এর সম্পূর্ণ আলাদা OS কার্নেল থাকে।

প্র ০২ কেন হরাইজন্টাল স্কেলিং সাধারণত ভার্টিক্যাল স্কেলিংয়ের চেয়ে বেশি নির্ভরযোগ্যতা দেয়?

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

প্র ০৩ একটি ওয়ার্কলোডের জন্য "প্রয়োজনের চেয়ে বড়" ইনস্ট্যান্স বেছে নেওয়া কেন সবসময় "নিরাপদ" পছন্দ নয়?

"নিরাপদ থাকার জন্য" বড় ইনস্ট্যান্স বেছে নেওয়া আসলে L03-এর ওভার-প্রভিশনিং সমস্যার পুনরাবৃত্তি — আপনি অব্যবহৃত ক্যাপাসিটির জন্য অপ্রয়োজনীয় টাকা দিচ্ছেন। কোড সেলের উদাহরণে দেখা গেছে, প্রয়োজন সঠিকভাবে পরিমাপ করে (min_vcpus, min_memory_gb) সবচেয়ে সাশ্রয়ী বিকল্প বেছে নেওয়া সম্ভব — এবং যদি ভবিষ্যতে চাহিদা বাড়ে, হরাইজন্টাল স্কেলিং (L06) বা ভার্টিক্যাল আপগ্রেড পরে যেকোনো সময় করা যায়, তাই আগে থেকেই ওভার-প্রভিশন করার প্রয়োজন নেই।

অনুশীলন

চিন্তা করুন: একটি ভিডিও-এনকোডিং সার্ভিস (যা প্রচুর CPU ব্যবহার করে কিন্তু তুলনামূলক কম মেমরি) কোন ইনস্ট্যান্স ফ্যামিলি বেছে নেবে বলে মনে হয়?

কম্পিউট-অপ্টিমাইজড ফ্যামিলি — কারণ ভিডিও এনকোডিং একটি CPU-ভারী (উচ্চ vCPU-থেকে-মেমরি অনুপাত) ওয়ার্কলোড। একটি মেমরি-অপ্টিমাইজড ইনস্ট্যান্স বেছে নিলে অতিরিক্ত মেমরির জন্য টাকা দিতে হবে যা এই ওয়ার্কলোড কখনও ব্যবহার করবে না।
পরীক্ষা করুন: উপরের কোড সেলে একটি নতুন ইনস্ট্যান্স টাইপ "storage-large" যোগ করুন (vcpus=4, memory_gb=8, hourly_cost=0.15) এবং `pick_cheapest_meeting_requirements(min_vcpus=4, min_memory_gb=6)` কল করে দেখুন এটি বাছাই হয় কিনা।

নতুন এন্ট্রি catalog dict-এ যোগ করার পর, ফাংশনটি সব যোগ্য (eligible) বিকল্পের মধ্যে সবচেয়ে কম hourly_cost-ওয়ালাটি বেছে নেবে — যদি "storage-large" প্রয়োজন মেটায় এবং সবচেয়ে সস্তা হয়, এটিই ফলাফল হিসেবে আসবে, দেখাচ্ছে ফাংশনটি সহজেই নতুন ইনস্ট্যান্স টাইপের সাথে সম্প্রসারণযোগ্য।