KVM বনাম Xen বনাম LXC: আপনার VPS-এ কী চলছে

আপনার VPS plan আসলে কী দিচ্ছে

KVM, Xen এবং LXC হলো VPS plan তৈরির তিনটি virtualisation family। কোনটি ব্যবহার করা হয়েছে, তা provider-এর rack-এর একটি গৌণ বিষয় নয়। এর মাধ্যমে নির্ধারিত হয় আপনি নিজের kernel পাবেন কি না। একজন buyer-এর গুরুত্বপূর্ণ সব বিষয় এই একটি তথ্যের ওপর নির্ভর করে: module load করা, swap নিয়ন্ত্রণ করা, nested virtualisation চালানো, /proc আপনার server নাকি অন্য কারও server তা বোঝা, এবং steal time আদৌ পরিমাপ করা যায় কি না।

Full virtualisation (KVM এবং Xen HVM) প্রতিটি tenant-কে একটি kernel এবং একটি virtual machine দেয়। Paravirtualised Xen-ও আপনাকে একটি kernel দেয়, তবে সেই kernel জানে যে এটি একটি guest এবং privileged কাজ করার জন্য hypervisor-এর কাছে অনুরোধ করে। একটি container plan (LXC, অথবা OpenVZ এবং Virtuozzo line) আপনাকে provider-এর kernel-এর ওপর একটি filesystem এবং একগুচ্ছ namespace দেয়। তিনটিই একই তিনটি অক্ষরের নামে বিক্রি হয়।

KVM বনাম Xen বনাম LXC: প্রতিটির জন্য আলাদা kernel, নাকি একটি kernel ভাগাভাগি

KVM এবং Xen-এ uname -r আপনার kernel নির্ধারণ করে। আপনি আলাদা kernel install করতে, তাতে module load করতে এবং সেটি দিয়ে reboot করতে পারেন। সেখানে আপনার কোনো কাজ অন্য tenant-কে প্রভাবিত করে না। Container plan-এ uname -r provider-এর kernel নির্ধারণ করে। এটি host-এ চলে এবং ওই মেশিনের অন্য সব container-এর সঙ্গে shared থাকে। আপনি এটি পরিবর্তন করতে পারবেন না, আর apt install linux-image-generic এমন ফাইল unpack করবে যেগুলো দিয়ে কখনও boot করা যাবে না।

এই একটি পার্থক্যের গুরুত্ব যেকোনো spec sheet-এর চেয়ে বেশি। এই guide-এর বাকি অংশটি এই পার্থক্যের ফলাফল হিসেবে পড়ুন।

সম্পূর্ণ virtualisation: KVM এবং Xen HVM

KVM (kernel-based virtual machine) হলো Linux kernel-এর একটি module, যা CPU-তে থাকা Intel VT-x বা AMD-V instruction ব্যবহার করে সাধারণ Linux host-কে hypervisor-এ রূপান্তর করে। এর চারপাশের virtual hardware QEMU সরবরাহ করে: disk, network card এবং serial console। Xen-এর নকশা আলাদা। Xen নিজেই একটি hypervisor এবং Linux চালু হওয়ার আগে boot হয়। dom0 নামে একটি privileged control domain management stack চালায়, আর প্রতিটি tenant হলো একটি domU। Xen HVM (hardware virtual machine) KVM-এর মতো একই CPU extension ব্যবহার করে। তবে emulated hardware ধীর হওয়ায় disk ও network-এর জন্য সাধারণত paravirtual driver ব্যবহৃত হয়। এই সমন্বয়কে PVHVM বলা হয়।

একজন tenant-এর দৃষ্টিতে দুটির আচরণ প্রায় একই। আপনি একটি kernel, একটি bootloader, একটি বাস্তব block device, একটি কার্যকর modprobe, একটি প্রকৃত /proc, আপনার নিয়ন্ত্রণাধীন swap এবং এমন reboot পান যা সত্যিই আবার boot হয়। Provider ISO attach করার অনুমতি দিলে তারা কখনও অফার করেনি এমন distribution-ও install করতে পারবেন।

এর বিনিময়ে density কমে। আপনার 4 GB আপনার machine-এর জন্য বরাদ্দ থাকে। আপনি নিষ্ক্রিয় থাকলেও সেটি প্রতিবেশী tenant-কে দেওয়া যায় না। প্রতিটি guest-এর সঙ্গে একটি QEMU process, নিজস্ব page table এবং নিজস্ব page cache থাকে। একই resource সংখ্যা দেখানো container plan-এর চেয়ে KVM plan-এর দাম বেশি হওয়ার কারণ এই overhead।

Paravirtualised Xen এবং এটি কীভাবে শনাক্ত করবেন

Xen PV এমন সময়ের প্রযুক্তি, যখন CPU-তে virtualisation instruction ছিল না। privileged instruction trap করার পরিবর্তে guest kernel পরিবর্তন করে hypervisor-কে সরাসরি call করা হয়। এটি VT-x ছাড়াই চলে। 2005 সালে এটাই ছিল এর মূল উদ্দেশ্য। pygrub বা pvgrub আপনার নিজের disk image-এর ভেতর থেকে kernel load করে। তাই এটি আপনার kernel, তবে সেটি PV guest support দিয়ে build করা থাকতে হবে।

আপনি Xen PV-তে আছেন কি না বোঝার কয়েকটি লক্ষণ আছে: lscpu virtualisation type হিসেবে full নয়, para দেখায়; /sys/hypervisor/type বিদ্যমান এবং সেখানে Xen-এর নাম থাকে; আপনার disk হলো xvda, vda বা sda নয়। SMBIOS বা DMI table পড়ার tool কোনো তথ্য পায় না। কারণ PV guest-এর এমন firmware নেই যা এই table প্রকাশ করে।

এর স্থায়ী সীমাবদ্ধতা হলো nested virtualisation ব্যবহার করা যায় না। PV guest-কে CPU virtualisation extension কখনও দেখানো হয় না। তাই এর ভেতরে কোনো hypervisor চালানো সম্ভব নয়। Xen নিজে অপ্রচলিত নয়। নির্দিষ্টভাবে Xen PV-এর ব্যবহার কমে গেছে, এবং প্রকল্পটির নিজস্ব দিক PVH ও HVM-এর দিকে গেছে। কোনো plan-এ শুধু “Xen” লেখা থাকলে কোন ধরনের Xen বোঝানো হয়েছে তা জিজ্ঞাসা করুন। HVM হলো আধুনিক সাধারণ VPS। PV হলে এর দাম কম হওয়া উচিত।

Container VPS: LXC এবং OpenVZ ধারার

একটি container VPS হলো Linux namespace-এর একটি সেট (process ID, mount, network interface, hostname এবং user-এর পৃথক view) এবং cgroup (control group, অর্থাৎ kernel-এর resource limit), যা provider-এর kernel-এ চলে। আপনার init হলো host-এর একটি process। আপনার ls সরাসরি host-এর kernel-এ চলে; মাঝখানে কোনো emulation বা দ্বিতীয় scheduler থাকে না। এ কারণেই container দ্রুত এবং একই host-এ বেশি সংখ্যায় চালানো যায়।

Order page-এ সাধারণত LXC, Proxmox VE container (যা LXC), OpenVZ এবং Virtuozzo নামগুলো দেখা যায়। OpenVZ 7 এবং Virtuozzo একই ধারণার commercial উত্তরসূরি।

আপনার ক্ষেত্রে 4টি বিষয় পরিবর্তিত হয়:

• Module। modprobe কোনো কিছু insert করবে না। WireGuard, ZFS বা নির্দিষ্ট netfilter module provider-এর kernel-এ আগে থেকেই না থাকলে আপনি সেটি ব্যবহার করতে পারবেন না।
• sysctl। /proc/sys-এর অধিকাংশই read only। Networking একটি প্রকৃত namespace, তাই net.ipv4.ip_forward এবং এর সংশ্লিষ্ট অংশগুলো সাধারণত writable থাকে। vm.swappiness বা fs.file-max-এর মতো machine-wide knob host-এর অধীনে থাকে।
• Nested container। Provider nesting সক্রিয় করলে এবং storage driver সহযোগিতা করলে তবেই LXC container-এর ভিতরে Docker কাজ করে। এটি ধরে না নিয়ে কেনার আগে পরীক্ষা করুন।
• Kernel version। Reboot-সহ provider-এর upgrade schedule আপনাকেও অনুসরণ করতে হবে।

কোনটি কিনেছেন তা কীভাবে বুঝবেন

সার্ভারে এই কমান্ডগুলো চালিয়ে ফলাফলগুলো একসঙ্গে দেখুন। কোনো একক কমান্ডই চূড়ান্ত সিদ্ধান্ত দেয় না।

systemd-detect-virt
systemd-detect-virt -c
lscpu | grep -iE 'hypervisor|virtualization'
uname -r
ls /lib/modules/$(uname -r) 2>/dev/null | head -n 3
cat /sys/hypervisor/type 2>/dev/null

systemd-detect-virt একটি নির্দিষ্ট তালিকা থেকে একটি সংক্ষিপ্ত identifier প্রিন্ট করে। মেশিন-সংক্রান্ত ফলাফলের মধ্যে kvm, qemu, xen, amazon এবং vmware রয়েছে। container-সংক্রান্ত ফলাফলের মধ্যে lxc, lxc-libvirt, openvz, docker এবং systemd-nspawn রয়েছে। কিছু শনাক্ত করতে না পারলে এটি none প্রিন্ট করে এবং non-zero status-এ শেষ হয়। -c ফর্মটি শুধু container technology-এর ক্ষেত্রে উত্তর দেয়। তাই সেখানে none ছাড়া অন্য কোনো উত্তর এলে sales page-এ যা-ই লেখা থাকুক, প্রশ্নটির উত্তর নিশ্চিত।

lscpu hypervisor vendor-এর নাম দেয় এবং virtualisation type full নাকি para তা জানায়। এভাবেই Xen HVM এবং Xen PV আলাদা করা যায়। /sys/hypervisor/type শুধু Xen-এর অধীনে থাকে।

/lib/modules পরীক্ষাটি অনেকে বাদ দেন, অথচ এটিই সবচেয়ে সরাসরি পরীক্ষা। চলমান kernel version-এর directory অনুপস্থিত বা খালি, কিন্তু সিস্টেম যে ওই kernel-এই চলছে তা স্পষ্ট হলে kernel আপনার filesystem থেকে আসেনি। এটি host থেকে এসেছে, এবং এর module tree আপনার image-এ কখনো install করা হয়নি। অর্থাৎ এটি একটি container।

স্বাধীনভাবে দ্বিতীয় মতামত পেতে sudo apt install -y virt-what && sudo virt-what detection test-গুলো একটি dedicated tool হিসেবে চালায়। এটির জন্য root প্রয়োজন, এবং bare metal-এ এটি একেবারেই কিছু প্রিন্ট করে না।

কনটেইনারে কেন /proc ভুল মেশিনের তথ্য দেখায়

KVM বা Xen guest-এ /proc/meminfo হলো hypervisor আপনাকে দেওয়া মেমরির আপনার kernel-এর নিজস্ব হিসাব। এটি আপনার মেশিন সম্পর্কে সঠিক তথ্য দেয়, কিন্তু host সম্পর্কে কিছুই বলে না। Virtual machine-এর উদ্দেশ্যই এটি।

কনটেইনারে এই হিসাব করার জন্য দ্বিতীয় কোনো kernel থাকে না। তাই /proc হলো host-এর /proc। LXCFS একটি ছোট filesystem, যা কিছু ফাইল rewrite করে আপনার cgroup limit-এর সঙ্গে সামঞ্জস্যপূর্ণ করে। এটি /proc/cpuinfo, /proc/meminfo, /proc/stat, /proc/uptime, /proc/swaps, /proc/diskstats এবং /sys/devices/system/cpu/online কভার করে। Proxmox এটি default হিসেবে mount করে। অনেক ছোট provider তা করে না। তখন free -m host-এর মোট memory দেখায়, nproc মেশিনের প্রতিটি core দেখাতে পারে, এবং uptime host কতক্ষণ ধরে চলছে তা দেখায়।

এটি শুধু cosmetic বিষয় নয়, কারণ software এই ফাইলগুলোর তথ্য ব্যবহার করে নিজের resource size নির্ধারণ করে। nginx, worker_processes auto ব্যবহার করে, দৃশ্যমান core-এর সংখ্যা গণনা করে। 2 core quota-সহ 64 core host-এ make -j$(nproc) 64টি compiler চালু করে। কোনো JVM বা database MemTotal থেকে cache size নির্ধারণ করলে এমন একটি সংখ্যা বেছে নিতে পারে, যা আপনার cgroup প্রত্যাখ্যান করবে। সীমায় পৌঁছালে kernel process-টি kill করে। এই kill-এর ঘটনা host-এর kernel log-এ লেখা হয়, যা আপনি পড়তে পারবেন না।

নির্ভরযোগ্য সংখ্যাগুলো /proc-এ নয়, cgroup-এ থাকে:

cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/cpu.max

এগুলো cgroup v2 path। বর্তমান distribution-গুলোতে এটিই ব্যবহৃত হয়। memory.max পড়ে max পাওয়া গেলে ওই স্তরে কোনো limit সেট করা নেই। cpu.max microsecond-এ quota এবং period প্রিন্ট করে। তাই 200000 100000 প্রতি period-এ CPU time-এর 2 core সমতুল্য। পুরোনো cgroup v1 host-এ একই মান /sys/fs/cgroup/memory/memory.limit_in_bytes এবং /sys/fs/cgroup/cpu/cpu.cfs_quota_us-এর অধীনে থাকে।

Swap এবং এর প্রকৃত মালিক

KVM এবং Xen-এ swap আপনার নিয়ন্ত্রণে থাকে। এটি আপনার disk-এর একটি file বা partition, এবং paging আপনার kernel পরিচালনা করে।

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

swapon --show এখন file-টি তার size এবং priority-সহ দেখানোর কথা। swapon file-টি গ্রহণ না করলে পরিবর্তে dd if=/dev/zero of=/swapfile bs=1M count=2048 ব্যবহার করে এটি তৈরি করুন, কারণ unwritten extents-সহ preallocated file কিছু filesystem-এ প্রত্যাখ্যাত হয়। /swapfile none swap sw 0 0-কে /etc/fstab-এ যোগ করুন। তা না হলে পরবর্তী reboot-এর পরে swap আর থাকবে না।

Container-এ এর কোনোটিই আপনার নিয়ন্ত্রণে থাকে না। swapon-এর জন্য এমন একটি capability প্রয়োজন, যা unprivileged container-এর কাছে থাকে না। তাই নিজের swap file তৈরি করার চেষ্টা permission error-এ ব্যর্থ হয় এবং disk-এ পৌঁছায় না। Plan-এ swap নামে যা দেওয়া থাকে, তা host-এর একটি cgroup setting: cgroup v2-এ এটি memory.swap.max, এবং এর পেছনে host-এর নিজস্ব swap device থাকে। পুরোনো OpenVZ plan-গুলো এমন একটি "vswap" allowance বিক্রি করত, যা disk-এর চেয়ে burst credit-এর কাছাকাছি আচরণ করত। আপনি এর ceiling পড়তে পারেন। এর নিচে থাকা device আপনি নিয়ন্ত্রণ করতে পারেন না।

Nested virtualisation এবং যে CPU flag মিথ্যা তথ্য দেয়

Nested virtualisation বলতে আপনার VPS-এর ভেতরে একটি hypervisor চালানো বোঝায়: একটি QEMU guest, একটি Vagrant box, অথবা নিজস্ব VM-সহ nested virtualisation lab। দুটি শর্তই পূরণ হতে হবে। Provider-কে host-এ nesting সক্রিয় করতে হবে, এবং আপনার guest-কে CPU-এর virtualisation extension দেখাতে হবে।

lscpu | grep -i virtualization
ls -l /dev/kvm
sudo apt install -y cpu-checker && sudo kvm-ok

Nesting সক্রিয় থাকা KVM guest-এ /dev/kvm থাকে, এবং kvm-ok স্পষ্টভাবে জানায় acceleration ব্যবহার করা যাবে কি না। Xen HVM-এ এটি প্রযুক্তিগতভাবে সম্ভব, তবে খুব কমই দেওয়া হয়। Xen PV-এ এটি সম্ভব নয়।

Container-এ পরীক্ষা ব্যর্থ হয়, তবে এর কারণটি গুরুত্বপূর্ণ। /proc/cpuinfo হলো host-এর file, তাই vmx বা svm flag উপস্থিত থাকে এবং সেটি সত্যও: আপনার নিচে থাকা physical CPU-তে সত্যিই ওই instruction রয়েছে। তবু সেটি আপনার নয়। আপনার namespace-এ /dev/kvm নেই, আপনি kvm_intel module load করতে পারবেন না, এবং আপনি যে flag পড়েছেন তা এমন একটি machine-এর বৈশিষ্ট্য জানায় যার ওপর আপনি guest হিসেবে চলছেন; এটি আপনার নিয়ন্ত্রণাধীন machine-এর বৈশিষ্ট্য নয়। এটি সাধারণ নিয়মটির সবচেয়ে স্পষ্ট উদাহরণ। Container-এ /proc namespace এবং তার চারপাশের hardware বর্ণনা করে, আপনার মালিকানাধীন server নয়।

AES-NI এবং আপনার প্ল্যানে প্রকাশিত CPU feature

AES-NI (advanced encryption standard new instructions) হলো CPU instruction-এর একটি সেট, যা software-এ একই গণনা করার তুলনায় AES encryption কয়েক গুণ দ্রুত করে। TLS termination, disk encryption, SSH এবং backup pipeline—সবই এর ওপর নির্ভর করে।

KVM-এ আপনার guest কী দেখতে পাবে, তা নির্ধারিত হয় provider QEMU-এর জন্য যে CPU model configure করেছে তার ভিত্তিতে। host passthrough ব্যবহার করলে আপনি প্রকৃত flag দেখতে পান। qemu64-এর মতো generic model ব্যবহার করলে, অথবা ভিন্ন host-এর মধ্যে guest migration সম্ভব করার জন্য ইচ্ছাকৃতভাবে পুরোনো baseline বেছে নিলে, aes flag অনুপস্থিত থাকতে পারে এবং OpenSSL নীরবে software path-এ ফিরে যায়।

lscpu | grep -ow aes | head -n 1
openssl speed -evp aes-128-gcm
env OPENSSL_ia32cap='~0x200000000000000:~0x20000000000:~0x0:~0x0:~0x0' openssl speed -evp aes-128-gcm

তৃতীয় command-টি OpenSSL manual-এ দেওয়া library-এর ভেতরে এই instruction বন্ধ করার উদাহরণ: এটি AES-NI bit এবং VAES bit clear করে, কিন্তু বাকি অংশ অপরিবর্তিত রাখে। দুইটি throughput figure তুলনা করুন। যদি দুটির ফল কাছাকাছি হয়, তাহলে fast path শুরু থেকেই ব্যবহৃত হচ্ছিল না। সে ক্ষেত্রে কোনো plan নেওয়ার আগে VPS-এ সঠিকভাবে AES-NI পরীক্ষা করা-তে পাঁচ মিনিট দেওয়া উপযোগী।

Container-এর সামনে কোনো CPU model থাকে না। তাই /proc/cpuinfo-এর flag-গুলো host-এর প্রকৃত flag এবং সেগুলো আপনার ক্ষেত্রেও প্রযোজ্য। Container plan-এর এটি একটি বাস্তব সুবিধা। এই guide-এর একমাত্র ক্ষেত্রে shared kernel আপনার পক্ষে কাজ করে।

Steal time কোথা থেকে আসে এবং container-এ এটি কেন থাকে না

Steal time হলো সেই সময়, যখন আপনার virtual CPU চালানোর জন্য প্রস্তুত ছিল কিন্তু চলেনি, কারণ hypervisor অন্য কোনো workload চালাচ্ছিল। এটি st-এ top ও vmstat হিসেবে এবং /proc/stat-এর cpu লাইনের অষ্টম field হিসেবে দেখা যায়।

Guest নিজে এটি মাপতে পারে না, কারণ সময়টি নেওয়া হচ্ছে যখন guest কোনো instruction execute করছে না। Hypervisor-কে এই তথ্য জানাতে হয়। KVM paravirtual clock interface-এর মাধ্যমে guest যে page register করে, সেখানে চলমান মোট মান লিখে রাখে। একই কাজের জন্য Xen প্রতি vCPU-এর জন্য আলাদা run state area সংরক্ষণ করে। আপনি যে সংখ্যাটি পড়েন, সেটি hypervisor-এর নিজস্ব হিসাব। তাই এটি পাওয়া যায় এবং সাধারণত নির্ভরযোগ্য।

Steal বেশি হলে বোঝায় যে host-এ অতিরিক্ত vCPU বরাদ্দ করা হয়েছে এবং সেই মুহূর্তে আপনার প্রতিবেশী workload-গুলো সক্রিয়। বিক্রি করা vCPU এবং physical core-এর অনুপাতের দৃশ্যমান ফল এটি। noisy neighbour শনাক্ত করতে steal time পড়া এমন একটি পরিমাপ, যা দেখায় পরিকল্পনায় যত resource দাবি করা হয়েছে, বাস্তবে তা তত বড় কি না।

vmstat 1 5
cat /sys/fs/cgroup/cpu.stat

Container-এ ওই column-এর মান পরিবর্তিত হবে না, কারণ আপনার এবং scheduler-এর মধ্যে কোনো hypervisor নেই। আপনার process-গুলো host-এর নিজস্ব CPU scheduler-এ অন্য tenant-এর process-গুলোর সঙ্গে সাধারণ task হিসেবে queue-তে অপেক্ষা করে। ফলে contention-এর প্রকাশ হলো কাজ সম্পন্ন হতে বেশি সময় লাগা; এর কারণ নির্দেশ করার মতো কোনো counter থাকে না। এর সবচেয়ে কাছের সমতুল্য হলো quota throttling। Provider cpu.max সেট করলে /sys/fs/cgroup/cpu.stat পরবর্তী quota window-এর জন্য অপেক্ষা করা nr_throttled period এবং throttled_usec microsecond গণনা করে। এটি শুধু আপনার নিজের quota-কে নির্দেশ করে; প্রতিবেশী workload-এর প্রতিযোগিতা এতে ধরা পড়ে না। একটি বিষয় মনে রাখুন: provider-এর container host নিজেই যদি একটি virtual machine হয়, তাহলে /proc/stat-এ steal-এর মান দেখা যেতে পারে। সেই মান host-এর জন্য প্রযোজ্য, আপনার জন্য নয়।

Overselling এবং কেন container plan সস্তা

সৎ উত্তরটি সংক্ষিপ্ত। container plan-এর খরচ কম, কারণ provider একই machine বেশি মানুষের মধ্যে ভাগ করে দেয়।

Memory-তেই পার্থক্য সবচেয়ে বেশি। KVM guest-এর RAM তার জন্য নির্ধারিত থাকে। তাই 256 GB-র host থেকে overhead বাদ দিয়ে প্রায় 256 GB guest বিক্রি করা যায়। Container-এর memory limit reservation নয়, বরং সর্বোচ্চ সীমা। কোনো container যে memory ব্যবহার করছে না, তা সঙ্গে সঙ্গে অন্য container-গুলো ব্যবহার করতে পারে। তাই provider physical RAM-এর কয়েক গুণের সমান memory limit বিক্রি করতে পারে এবং প্রায় সব সময় তা কার্যকর থাকে। এখানে কিছু জাল করা হয় না। পর্যাপ্ত tenant একসঙ্গে ব্যস্ত না হওয়া পর্যন্ত এটি কাজ করে। সবাই একসঙ্গে ব্যস্ত হলে এটি সবার জন্য কাজ করা বন্ধ করে।

প্রতিটি plan type-এই CPU oversell করা হয়, KVM-সহ। এর অর্থ, host-এ যত core আছে তার চেয়ে বেশি vCPU বিক্রি করা। প্রায় সব জায়গাতেই disk thin provision করা হয়। Container এতে আরও বেশি density যোগ করে: একটি kernel, একটি page cache এবং প্রতিটি guest-এর জন্য আলাদা QEMU process নেই। তাই একটি host-এ কয়েক গুণ বেশি tenant রাখা যায়।

এর বিনিময়ে আপনি isolation হারান। এটি ভয় দেখানোর গল্প নয়; এটি বাস্তব engineering trade-off। আপনি একটি kernel ভাগ করে নেন। তাই kernel-এর bug সবার জন্য shared সমস্যা হয়ে দাঁড়ায়। Container escape হলে তা সরাসরি host-এ পৌঁছে যায়। Virtual machine থেকে escape করতে hypervisor-এর bug প্রয়োজন। এটি তুলনামূলকভাবে অনেক ছোট এবং কঠিন target। Provider-এর kernel upgrade ও reboot schedule-ও আপনাকে মেনে নিতে হয়। এসবের কোনোটি আপনার জন্য গুরুত্বপূর্ণ হলে শুধু দামের ভিত্তিতে সিদ্ধান্ত নেওয়ার আগে VPS hosting কতটা নিরাপদ পড়ুন।

কোনটি কিনবেন

নিজস্ব kernel প্রয়োজন হলে KVM কিনুন। যেমন WireGuard বা ZFS module, নির্দিষ্ট kernel version, nested virtualisation, swap-এর ওপর প্রকৃত নিয়ন্ত্রণ, অথবা auditor-কে ব্যাখ্যা করা যায় এমন একটি isolation boundary দরকার হলে KVM বেছে নিন। সীমিত budget-এ সাধারণ service চালালে container plan কিনুন, যদি provider-এর kernel বর্তমান থাকে এবং আপনার প্রয়োজনীয় feature-গুলো তাতে ইতিমধ্যে compile করা আছে বলে নিশ্চিত হন। অধিকাংশ ক্ষেত্রে Xen HVM-কে KVM-এর সমতুল্য ধরুন। এখনও Xen PV হিসেবে বিক্রি হয় এমন কোনো plan কেনার আগে এই বিষয়টি জিজ্ঞাসা করুন।

এই বিভাজনের বাইরে আরও দুটি ধরন আছে। Firecracker microVM প্রতিটি tenant-কে একটি প্রকৃত kernel দেয়, তবে startup cost container-এর কাছাকাছি থাকে। Serverless platform-গুলো এভাবেই চলে। Incus system container আপনাকে নিজের নিয়ন্ত্রণাধীন hardware-এ container model চালাতে দেয়। এটি কোনো provider-এর বিক্রি করা container পাওয়ার চেয়ে ভিন্ন ব্যবস্থা। পরিভাষাই যদি মূল বাধা হয়, VPS আসলে কী এবং VPS, VM ও VPC-এর পার্থক্য অংশে এই guide-এ ধরে নেওয়া শব্দগুলোর ব্যাখ্যা আছে।

FAQ

আমার VPS KVM নাকি container, তা কীভাবে বুঝব?

systemd-detect-virt -c চালান। none ছাড়া অন্য যেকোনো উত্তর দেখালে আপনি container-এর ভিতরে আছেন, plan-এ যে product name-ই থাকুক না কেন। Detection ভুল হতে পারে, তাই আরও দুইভাবে নিশ্চিত করুন। lscpu একটি hypervisor vendor-এর নাম এবং virtualisation type full নাকি para, তা জানায়। Container-এ ls /lib/modules/$(uname -r) অনুপস্থিত বা খালি থাকে, কারণ চলমান kernel host থেকে এসেছে এবং তার module tree আপনার filesystem-এ কখনো install করা হয়নি। শুধু এই প্রশ্নের জন্য তৈরি tool থেকে sudo virt-what স্বাধীন উত্তর দেয়।

আমার plan-এ থাকা memory-এর চেয়ে free -m এত বেশি memory কেন দেখায়?

আপনি LXCFS mount না-করা container plan ব্যবহার করছেন। তাই /proc/meminfo host-এর file, এবং free host-এর memory সঠিকভাবে report করছে। আপনার প্রকৃত সীমা cgroup নির্ধারণ করে। সীমার জন্য /sys/fs/cgroup/memory.max এবং বর্তমান ব্যবহারের জন্য /sys/fs/cgroup/memory.current পড়ুন। পুরোনো cgroup v1 host-এ /sys/fs/cgroup/memory/memory.limit_in_bytes ব্যবহার করুন। কোনো service cache বা worker pool-এর আকার নির্ধারণ করলে free-এর বদলে এই সংখ্যা ব্যবহার করার জন্য configure করুন।

LXC VPS-এ Docker বা WireGuard চালাতে পারি?

কখনো কখনো পারেন, তবে আপনি কিছু install করেছেন বলে নয়। উভয়ই provider-এর kernel-এর ওপর নির্ভর করে, কারণ সেই kernel-এ আপনি module load করতে পারবেন না। Host-এ module আগে থেকেই উপস্থিত এবং আপনার জন্য exposed থাকলে WireGuard কাজ করে। তা না হলে userspace wireguard-go implementation fallback হিসেবে কাজ করে। Docker-এর জন্য provider-কে nesting অনুমোদন করতে হবে। Container-এর ভিতরে কাজ করে এমন storage driver-ও প্রয়োজন। কেনার আগে জিজ্ঞাসা করুন। অথবা এমন term-এ পরীক্ষা করুন, যা ব্যর্থ হলে সহজে ছেড়ে দিতে পারবেন।

আমার container VPS কখনো steal time report করে না কেন?

Hypervisor virtual CPU schedule করলেই কেবল steal time থাকে। Hypervisor একটি page-এ এই মান লিখে, এবং আপনার kernel সেই page পড়ে বলে এটি report করা হয়। Container-এর নিচে কোনো hypervisor থাকে না। আপনার process-গুলো host-এর scheduler-এর সাধারণ task হিসেবে চলে। তাই contention হলে কোনো counter-এ কারণ দেখা যায় না; শুধু সবকিছু বেশি সময় নেয়। এর বদলে /sys/fs/cgroup/cpu.stat পড়ুন। nr_throttled এবং throttled_usec আপনার cgroup পরবর্তী CPU quota window-এর জন্য কত সময় অপেক্ষা করেছে, তা গণনা করে। Container-এর ক্ষেত্রে steal time-এর সবচেয়ে কাছাকাছি মাপ এটিই।