Storage VPS বনাম সাধারণ VPS: কোনটি আপনার জন্য?

Storage VPS বনাম সাধারণ VPS: সংক্ষিপ্ত উত্তর

Storage VPS হলো টেরাবাইটের হিসাবে বিক্রি করা virtual private server, আর সাধারণ VPS বিক্রি করা হয় CPU core-এর হিসাবে। Storage plan-এ অল্প CPU share-এর সঙ্গে কয়েক টেরাবাইটের ধীর disk থাকে। একই দামে standard plan-এ fast NVMe (non-volatile memory express) disk থাকে, যা প্রায়ই আকারে বিশ গুণ ছোট; এর সঙ্গে বেশি processor এবং বেশি memory-ও থাকে। বাকি সব দিক থেকে দুটি product একই: একই hypervisor, একই root shell, একই Ubuntu image এবং একই network stack।

এই একটি পার্থক্যই নির্ধারণ করে কোনটির ব্যবহার উপযুক্ত। Backup target, media library, cold archive এবং একবার লিখে খুব কম পড়া হয়—এমন যেকোনো ব্যবহারের জন্য Storage VPS উপযুক্ত। Database-এর জন্য এটি উপযুক্ত নয়। ব্যবহারকারী যে page খুলে অপেক্ষা করে, এমন page-এর জন্যও এটি উপযুক্ত নয়। কারণ এসব workload-এ ছোট random read প্রায় এক millisecond-এর মধ্যে শেষ হওয়া দরকার। সস্তা capacity সস্তা হওয়ার কারণই হলো এটি তা করতে পারে না।

প্রাইসিং পেজে দেখা প্ল্যানের নাম

চারটি লেবেল প্রায় সব provider-এর ক্ষেত্রে দেখা যায়, তবে এর মধ্যে মাত্র দুটি নির্দিষ্ট অর্থ বহন করে।

• Standard VPS। 2 থেকে 8 vCPU, 2 GB থেকে 32 GB RAM, এবং 20 GB থেকে 400 GB NVMe বা SATA SSD, যা সরাসরি host node-এ থাকে।
• Storage VPS। 1 TB থেকে 20 TB বা তার বেশি storage, সাধারণত spinning SATA disk অথবা উচ্চ-ধারণক্ষমতার SATA SSD, সঙ্গে 1 থেকে 4টি shared vCPU এবং সীমিত পরিমাণ RAM। এর মাসিক খরচ প্রায়ই একটি ছোট standard plan-এর সমান।
• VDS। এটি virtual dedicated server-এর সংক্ষিপ্ত রূপ। এই শব্দটির কোনো সর্বজনস্বীকৃত সংজ্ঞা নেই। নিচের section-এ এর পরিবর্তে কী পড়তে হবে তা ব্যাখ্যা করা হয়েছে।
• Block storage volume। এটি কোনো plan নয়। এটি network-attached disk, যা একটি বিদ্যমান VPS-এ যোগ করা হয় এবং প্রতি GB, প্রতি মাস হিসেবে এর মূল্য নির্ধারিত হয়। server সরানো ছাড়াই আকার বাড়াতে পারবেন—এই চারটির মধ্যে একমাত্র এটিই সেই সুবিধা দেয়।

এই range-গুলো বাজারজুড়ে প্রচলিত কাঠামো বোঝায়; কোনো নির্দিষ্ট company-এর offer নয়। plan-এর label একটি category। তাই এটি মোটামুটি জানায় আপনার server কোন chassis-এ থাকবে। তবে এটি disk-এর ধরন, CPU allocation policy বা bandwidth allowance জানায় না। আপনার workload ভালোভাবে চলবে কি না, তা মূলত এই বিষয়গুলোর ওপর নির্ভর করে।

দুটি plan-এর মধ্যে আসলে কী পরিবর্তন হয়

Disk type এবং quantity। এটাই product-এর মূল পার্থক্য। একটি standard plan-এ আপনি PCI Express bus-এর মাধ্যমে ব্যবহৃত NVMe flash storage পান। একটি storage plan-এ আপনি spinning disk-এর বড় array অথবা high-capacity SATA SSD পান। এই শব্দগুলোর মধ্যে কোনটি আপনার জন্য গুরুত্বপূর্ণ তা নিশ্চিত না হলে আগে SSD VPS কী এবং পুরোনো disk plan থেকে এটি কীভাবে আলাদা পড়ুন। এরপর NVMe এবং SATA SSD-এর মধ্যে বাস্তব পার্থক্য দেখুন।

CPU ratio। Storage plan-এ প্রতি terabyte-এ vCPU কম থাকে, এবং এই vCPU প্রায় সব সময় অন্যান্য tenant-এর সঙ্গে shared থাকে। এটি কোনো ত্রুটি নয়। একটি backup target অধিকাংশ সময় network-এর জন্য অপেক্ষা করে, তাই এর বেশি core প্রয়োজন হয় না।

RAM। দামের তুলনায় storage plan-এ RAM কম থাকে। এটি একটি নির্দিষ্ট ক্ষেত্রে সমস্যা তৈরি করে: filesystem metadata। লক্ষ লক্ষ ছোট file-এর জন্য directory এবং inode cache-এ memory প্রয়োজন হয়। memory না থাকলে প্রতিটি listing-এর জন্য আবার disk access করতে হয়।

Network allowance। Storage plan-এর ক্ষেত্রে এই লাইনটি সতর্কতার সঙ্গে পড়ুন। যে capacity থেকে restore করা যায় না, সেটি backup নয়। মাসিক transfer allowance TB-তে এবং port speed Gbit/s-এ পরীক্ষা করুন। কারণ 1 Gbit/s port-এ 4 TB সম্পূর্ণ restore করতে line rate অনুযায়ী প্রায় নয় ঘণ্টা লাগে, আর port shared হলে আরও বেশি সময় লাগে।

[
  {
    "plan": "Storage VPS, HDD",
    "usd_per_tb_month": 3
  },
  {
    "plan": "Storage VPS, SATA SSD",
    "usd_per_tb_month": 9
  },
  {
    "plan": "Standard VPS, NVMe",
    "usd_per_tb_month": 40
  },
  {
    "plan": "Block storage add-on",
    "usd_per_tb_month": 90
  }
]

এগুলো August 2026-এ কয়েকটি provider-এর public price page থেকে নেওয়া rounded figure। এগুলো কোনো একটি company-এর quote নয়, এবং সময়ের সঙ্গে পরিবর্তিত হয়। যে বিষয়টি সাধারণত অপরিবর্তিত থাকে, তা হলো সামগ্রিক ধরণ। Spinning storage plan-এ 1 terabyte storage-এর মাসিক খরচ প্রায় 3 US dollar। Standard plan-এ একই 1 terabyte NVMe storage-এর খরচ প্রায় 40। Network-attached block volume হলো 4টি option-এর মধ্যে সবচেয়ে ব্যয়বহুল, যার খরচ 90। মাসিক bill কীভাবে তৈরি হয়, তার বিস্তৃত ধারণার জন্য একটি VPS-এর মাসিক প্রকৃত খরচ কত দেখুন।

প্রতি TB-এর দাম এবং প্রতি core-এর দাম কেন বিপরীতমুখী

একটি storage node হলো এমন একটি chassis, যাতে বারো থেকে ষোলোটি বড় disk এবং সেগুলোর সামনে একটি সাধারণ processor থাকে। একটি compute node এর বিপরীত: এতে অনেক core, প্রচুর RAM এবং দুই বা চারটি NVMe drive থাকে। Provider chassis-এ অব্যবহৃত যা থাকে, সেটিই বিক্রি করে। তাই প্রতি terabyte-এ সস্তা plan প্রতি core-এ ব্যয়বহুল, আর প্রতি core-এ সস্তা plan প্রতি terabyte-এ ব্যয়বহুল। একই সঙ্গে উভয় দিক থেকে সস্তা কোনো plan নেই, কারণ কোনো chassis-ই সেভাবে তৈরি নয়।

এই কারণেই "কোনটি কেনা উচিত" প্রশ্নের সৎ উত্তর প্রায়ই "দুটিই"। একটি ছোট NVMe VPS-এ application চালিয়ে এবং একটি storage VPS-এ তার backup রাখলে, উভয় কাজ ভালোভাবে করার জন্য যথেষ্ট বড় একটি machine কেনার চেয়ে খরচ কম হয়। একটি machine-কে সত্যিই উভয় কাজ করতে হলে আপনি VPS-এর সীমা পেরিয়ে গেছেন: দেখুন কখন dedicated server VPS-এর চেয়ে ভালো।

সস্তা ডিস্ক random read করতে পারে না

[
  {
    "disk": "7200 rpm SATA HDD",
    "random_read_iops": "180",
    "typical_latency_ms": 8.5
  },
  {
    "disk": "SATA SSD",
    "random_read_iops": "75,000",
    "typical_latency_ms": 0.2
  },
  {
    "disk": "NVMe SSD",
    "random_read_iops": "600,000",
    "typical_latency_ms": 0.08
  }
]

এগুলো কোনো provider-এর benchmark নয়; এগুলো datasheet-ভিত্তিক শ্রেণিগত পরিসংখ্যান। 7200 rpm-এর একটি disk প্রতি সেকেন্ডে আনুমানিক 180টি random 4k read সম্পন্ন করে। কারণ head-কে track-এ শারীরিকভাবে সরতে হয় এবং এরপর platter-কে sector-টি head-এর নিচে আনতে অপেক্ষা করতে হয়। প্রতিবার এতে প্রায় 8.5 ms সময় লাগে। Flash-এ সরানোর মতো কোনো head নেই। তাই SATA SSD প্রায় 75,000 IOPS এবং NVMe device প্রায় 600,000 IOPS অর্জন করে, যেখানে latency 0.08 ms। এই পার্থক্য তিন হাজার গুণেরও বেশি। RAM বা CPU বাড়িয়ে এই ব্যবধান পূরণ করা যায় না।

Sequential কাজের ক্ষেত্রে চিত্র সম্পূর্ণ ভিন্ন। এ কারণেই storage plan এখনও কার্যকর। একটি spinning disk একাই 150 MB/s থেকে 250 MB/s গতিতে data stream করতে পারে। একাধিক disk-এর array আরও বেশি গতি দিতে পারে। এতে 1 Gbit/s port-এর পূর্ণ capacity ব্যবহার হয়। ফলে backup upload পূর্ণ network speed-এ চলে এবং disk bottleneck হয় না। Array কীভাবে তৈরি করা হয়েছে তার ওপরও আপনার পরিসংখ্যান নির্ভর করে। কারণ striping একটি request কয়েকটি disk-এর মধ্যে ভাগ করে দেয়। RAID 10 কীভাবে storage plan-এর performance পরিবর্তন করে অংশে এটি ব্যাখ্যা করা হয়েছে।

VDS বলতে কী বোঝায়?

সাধারণত এটি একটি marketing label। প্রচলিত ব্যবহারে এর তিনটি অর্থ আছে, কিন্তু provider খুব কম ক্ষেত্রেই জানায় কোন অর্থটি প্রযোজ্য। কেউ কেউ pinned বা dedicated CPU core-কে VDS বলে, যাতে অন্য কোনো tenant আপনার CPU cycle-এর সঙ্গে প্রতিযোগিতা না করে। কেউ কেউ KVM-এর মতো full virtualization-কে বোঝাতে এটি ব্যবহার করে। এর বিপরীতে LXC বা OpenVZ-এর মতো container virtualization-এ host kernel ভাগ করে ব্যবহার করতে হয়। আবার কেউ কেউ VPS-এর চেয়ে শক্তিশালী শোনায় এমন একটি নাম ছাড়া আর কোনো অর্থেই VDS ব্যবহার করে না।

Server-এর ভেতর থেকেই এর কিছুটা যাচাই করা যায়। systemd-detect-virt full virtual machine-এ kvm এবং container-এ lxc প্রিন্ট করে। Container ব্যবহার করলে আপনি kernel module load করতে বা নিজের kernel চালাতে পারবেন না। Dedicated CPU-এর দাবি যাচাই করতে হলে নিচে দেওয়া steal time check ব্যবহার করে মাপতে হবে। Plan-এ থাকা অক্ষরগুলোকে একটি ইঙ্গিত হিসেবে দেখুন, আর specification-এর line-গুলোকে চুক্তির শর্ত হিসেবে বিবেচনা করুন।

নামের বদলে যে specification লাইনগুলো পরীক্ষা করবেন

• capacity-এর পাশে লেখা শব্দটি: NVMe, SSD, SATA অথবা HDD। পৃষ্ঠার কোথাও disk-সংক্রান্ত কোনো শব্দ না থাকলে, ওই দামের মধ্যে মানানসই সবচেয়ে সস্তা hardware ধরে নিন।
• disk-টি node-এর local কিনা, নাকি network-attached। Network-attached storage প্রতিটি request-এ latency যোগ করে এবং node ব্যর্থ হলেও টিকে থাকে। Local disk দ্রুততর, কিন্তু node-এর সঙ্গে সেটিও অচল হয়ে যায়।
• CPU-সংক্রান্ত ভাষা: "dedicated" বা "pinned" লেখা আছে কি না, অথবা "shared", "fair share" কিংবা কিছুই লেখা নেই কি না।
• plan-এ কোনো IOPS বা MB/s সীমা লেখা আছে কি না। সীমা 500 IOPS হলে disk-এর ধরন প্রায় অপ্রাসঙ্গিক হয়ে যায়।
• মাসিক transfer allowance এবং port speed, যা full restore সম্পন্ন হতে কত সময় লাগবে তা নির্ধারণ করে।
• snapshots, backups এবং অতিরিক্ত IP address অন্তর্ভুক্ত কি না, নাকি আলাদাভাবে বিল করা হয়।

আপনি আসলে যে ডিস্ক পেয়েছেন তা কীভাবে পরীক্ষা করবেন

প্রথমে kernel কী জানাচ্ছে তা দেখুন। এরপর সেই তথ্যকে চূড়ান্ত সত্য ধরে নেওয়া বন্ধ করুন।

lsblk -d -o NAME,ROTA,SIZE,MODEL
df -h /
nproc
free -h

ROTA rotational device হলে 1 এবং flash হলে 0। VPS-এর মধ্যে এটির ওপর নির্ভর করবেন না। virtio disk সাধারণত ROTA=0 রিপোর্ট করে, কারণ hypervisor একটি generic block device উপস্থাপন করে এবং guest physical drive দেখতে পায় না। একই কারণে MODEL খালি থাকে। এই flag-টি rack-এ ঘুরতে থাকা physical drive কী, তা নয়; hypervisor কী ঘোষণা করেছে, তা বর্ণনা করে। তাই পরিবর্তে পরিমাপ করুন।

sudo apt update && sudo apt install -y fio
fio --name=randread --filename=/var/tmp/fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fio.test

--direct=1 page cache এড়িয়ে চলে। তাই RAM নয়, disk-এর কর্মক্ষমতা পরিমাপ হয়। পড়ার মতো মূল লাইনটি হলো read: IOPS=। তার নিচে distribution থাকে clat percentiles (usec)। একটি standard NVMe plan সাধারণত কয়েক দশ হাজার IOPS দেখায় এবং 99th percentile এক millisecond-এর কম থাকে। একটি spinning storage plan সাধারণত কয়েকশ IOPS দেখায় এবং 99th percentile দুই অঙ্কের millisecond-এ থাকে। fio যদি জানায় যে libaio engine load করা যাচ্ছে না, তাহলে --ioengine=psync --iodepth=1 ব্যবহার করুন এবং কম সংখ্যা প্রত্যাশা করুন। কারণ ওই engine একবারে একটি request পাঠায়।

vmstat 1 5
sudo apt install -y sysstat
iostat -x 1 5

vmstat-এ st column হলো steal time। host অন্য guest-কে ওই CPU cycle দেওয়ার সময় আপনার vCPU run করার জন্য ready ছিল—এই সময়ের অনুপাতকে এটি বোঝায়। 5-এর বেশি স্থির মান দেখালে node-টি oversubscribed। "dedicated CPU" দাবির ক্ষেত্রে এটিই প্রকৃত পরীক্ষা। iostat -x-এ %util, r_await এবং w_await পর্যবেক্ষণ করুন। %util প্রায় 100 এবং w_await দশকের millisecond-এ থাকলে disk-ই bottleneck। কোনো application tuning এতে সাহায্য করবে না। flash-এর নির্দিষ্ট পরীক্ষার জন্য NVMe disk সত্যিই NVMe কি না যাচাই করা আরও বিস্তারিতভাবে দেখুন।

কাজের ধরন অনুযায়ী নির্বাচন

• restic, Borg বা rsync-এর জন্য backup target। Storage VPS এই কাজের জন্য উপযুক্ত, এবং এটি সেই উদ্দেশ্যেই তৈরি। Write বড় ও sequential হয়, deduplication source machine-এ ঘটে, এবং ফলাফলের জন্য কোনো প্রক্রিয়াকে অপেক্ষা করতে হয় না। একটি সীমাবদ্ধতা আছে: restic prune এবং restic check --read-data পুরো repository ছোট ছোট অংশে পড়ে, তাই এগুলোর জন্য কয়েক ঘণ্টা সময় বরাদ্দ করুন এবং schedule অনুযায়ী চালান। VPS-এ restic backup চালানো দেখুন।
• Immich বা Jellyfin media library। ফাইলের জন্য Storage VPS ব্যবহার করুন, তবে CPU সম্পর্কে সতর্ক থাকুন। Import-এর সময় Immich thumbnail তৈরি করে এবং machine learning job চালায়। Playback-এর সময় Jellyfin transcode করে। দুইটি shared vCPU দিয়ে 200 GB ছবির প্রথম import খুব ধীর হবে। Database এবং thumbnail cache সার্ভারের দ্রুততম disk-এ রাখুন। Sizing সম্পর্কে Google Photos-এর বিকল্প হিসেবে Immich self-host করা দেখুন।
• PostgreSQL বা MySQL। Standard NVMe plan ব্যবহার করুন। প্রতিটি commit-এর শেষে একটি fsync তৈরি হয়, transaction return করার আগে যেটি durable storage-এ পৌঁছাতে হয়। তাই commit latency মূলত disk latency। Index lookup হলো নির্দিষ্টভাবে 8 kB-এর একটি random read, যে ধরনের কাজ spinning disk-এ সবচেয়ে খারাপ হয়।
• Web application, API বা control plane। Standard plan ব্যবহার করুন। এগুলোর CPU core এবং predictable latency দরকার। সাধারণত 100 GB-এর বেশি storage প্রয়োজন হয় না।
• CI cache বা artifact store। এটি file size-এর ওপর নির্ভর করে। বড় tarball storage plan থেকে সম্পূর্ণ network speed-এ stream করা যায়। কয়েক লক্ষ ছোট file-এর cache একাধিক runner parallel-ভাবে pull করলে সেটি আসলে random IO-এর মতো আচরণ করে এবং প্রত্যাশিত performance দেবে না।

এটি ভুলভাবে করলে যা দেখা যায়

ব্যর্থতা কখনও তাৎক্ষণিক হয় না। একজন ব্যবহারকারীর ক্ষেত্রে spinning storage plan-এ থাকা database স্বাভাবিক মনে হতে পারে, কিন্তু 10 জন ব্যবহারকারীর চাপেই এটি অচল হয়ে পড়ে। কারণ যে query-গুলো আগে RAM থেকে ডেটা নিত, সেগুলো disk-এ যেতে শুরু করে। ফলে প্রতিটি query সম্পন্ন হতে microseconds-এর বদলে milliseconds সময় লাগে। Load average বাড়তে থাকে, আর top দেখায় যে CPU বেশিরভাগ সময় idle অবস্থায় আছে এবং %wa-এর মান বেশি। এর অর্থ process-গুলো কোনো গণনা না করে disk-এর কাজ শেষ হওয়ার অপেক্ষায় blocked হয়ে আছে। iostat -x 1 দেখায় যে %util প্রায় 100-এ স্থির রয়েছে।

PostgreSQL-এর নিজস্ব log-এ বিষয়টি স্পষ্টভাবে দেখা যায়, কারণ version 15 থেকে log_checkpoints ডিফল্টভাবে চালু থাকে:

LOG:  checkpoint complete: wrote 8241 buffers (2.5%); ... write=112.402 s, sync=9.318 s, total=121.914 s

এখানে sync=-এর মানটিই গুরুত্বপূর্ণ। এটি checkpoint-টি fsync-এর ফল ফেরার জন্য অপেক্ষা করার সময়। তাই এই মান seconds-এ থাকলে বোঝা যায়, database যত দ্রুত write তৈরি করছে disk তত দ্রুত সেগুলো গ্রহণ করতে পারছে না। ওই সময়ে client connection আটকে থাকে, যদিও query-টি নিজে ব্যয়বহুল নয়। এর সমাধান configuration পরিবর্তন নয়। data directory-টি NVMe-তে সরান। আর storage plan-টি তার উপযোগী কাজেই ব্যবহার করুন: ওই database-এর backup সংরক্ষণে।

FAQ

একটি storage VPS কি সাধারণ VPS-এর চেয়ে ধীর?

Random read এবং write-এর ক্ষেত্রে হ্যাঁ, এবং ব্যবধান অনেক। একটি spinning storage plan প্রতি সেকেন্ডে কয়েক শত ছোট random request প্রায় 8 ms করে সম্পন্ন করে। অন্যদিকে, একটি NVMe plan প্রতি সেকেন্ডে কয়েক দশ হাজার request 1 ms-এর অনেক কম সময়ে সম্পন্ন করে। Sequential transfer-এর ক্ষেত্রে পার্থক্য অনেক কম, কারণ একটি storage array এখনও 150 MB/s বা তার বেশি গতিতে data stream করতে পারে। 1 Gbit/s port পূর্ণ করার জন্য এটুকুই যথেষ্ট। সিদ্ধান্ত নেওয়ার আগে fio --rw=randread --bs=4k --direct=1 ব্যবহার করে নিজের সিস্টেমের performance মাপুন।

আমি কি একটি storage VPS-এ PostgreSQL চালাতে পারি?

আপনি এটি চালু করতে পারবেন, এবং working set RAM-এ আর না ধরার আগ পর্যন্ত এটি কাজ করবে। এরপর প্রতিটি commit ধীর disk-এ একটি fsync সম্পন্ন হওয়ার জন্য অপেক্ষা করবে। Postgres এটি checkpoint complete-এর মধ্যে সেকেন্ডে একটি sync= figure হিসেবে log করবে, আর iostat -x 1-এ উচ্চ w_await সহ %util প্রায় 100 দেখা যাবে। সাধারণ ব্যবস্থা হলো database-এর জন্য একটি ছোট NVMe VPS এবং dump সংরক্ষণের target হিসেবে একটি storage VPS ব্যবহার করা।

VDS বলতে কি আমি dedicated hardware পাব?

নির্ভরযোগ্যভাবে তা বলা যায় না। VDS-এর কোনো standard meaning নেই। কিছু provider pinned CPU core বোঝাতে এটি ব্যবহার করে। কিছু provider shared kernel container-এর বিপরীতে full KVM virtualization বোঝাতে ব্যবহার করে। আবার কিছু provider শুধু একটি নাম হিসেবে এটি ব্যবহার করে। আপনি systemd-detect-virt চালিয়ে দেখুন আপনি kvm নাকি lxc-এ আছেন। অন্য tenant-রা আপনার CPU cycle ব্যবহার করছে কি না দেখতে vmstat 1 5 চালান এবং st column monitor করুন।

আমার VPS-এর disk সত্যিই NVMe কি না কীভাবে বুঝব?

lsblk -d -o NAME,ROTA,MODEL-কে বিশ্বাস করবেন না, কারণ virtio disk সাধারণত hardware-এর নিচে যা-ই থাকুক, ROTA=0 এবং একটি খালি model string report করে। --direct=1 ব্যবহার করে 30 second-এর fio random read test চালান। এরপর IOPS এবং 99th percentile latency দেখুন। Double-digit millisecond latency-সহ কয়েক শত IOPS হলে সেটি spinning array। 1 millisecond-এর কম latency-সহ কয়েক দশ হাজার IOPS হলে সেটি flash।