Storage VPS یا regular VPS: کون سا بہتر ہے؟

Storage VPS بمقابلہ regular VPS: مختصر جواب

Storage VPS ایک virtual private server ہے جو terabyte کے حساب سے فروخت کیا جاتا ہے، جبکہ regular VPS کو core کے حساب سے فروخت کیا جاتا ہے۔ Storage plan میں کم CPU share کے ساتھ کئی terabytes کی سست disk ملتی ہے۔ Standard plan میں تیز NVMe (non-volatile memory express) disk ملتی ہے جو عموماً بیس گنا چھوٹی ہوتی ہے، اور اسی قیمت میں زیادہ processor اور زیادہ memory بھی ملتی ہے۔ دونوں products کی باقی خصوصیات یکساں ہوتی ہیں: ایک ہی hypervisor، ایک ہی root shell، ایک ہی Ubuntu image اور ایک ہی network stack۔

یہی ایک فرق طے کرتا ہے کہ کون سا plan موزوں ہے۔ Storage VPS backup targets، media libraries، cold archives اور ایسی دیگر چیزوں کے لیے موزوں ہے جنہیں ایک بار لکھا جائے اور کم ہی پڑھا جائے۔ یہ database کے لیے یا ایسے کسی page کے لیے موزوں نہیں ہے جس کے سامنے user انتظار کرتا رہے، کیونکہ ایسے workloads میں چھوٹی random reads تقریباً ایک millisecond میں مکمل ہونی چاہییں۔ سستی capacity سستی اس لیے ہوتی ہے کہ وہ یہی کام نہیں کر سکتی۔

قیمتوں کے صفحے پر نظر آنے والے plan کے نام

تقریباً ہر provider کے plans کو چار labels میں شامل کیا جا سکتا ہے، لیکن ان میں سے صرف دو کا مخصوص مطلب ہوتا ہے۔

• 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 disks یا زیادہ گنجائش والی SATA SSDs، 1 سے 4 shared vCPU، اور محدود مقدار میں RAM۔ اس کی ماہانہ قیمت اکثر چھوٹے standard plan جتنی ہوتی ہے۔
• VDS۔ یہ virtual dedicated server کا مخفف ہے۔ اس اصطلاح کی کوئی متفقہ تعریف نہیں ہے، اس لیے نیچے دیا گیا section بتاتا ہے کہ اس کے بجائے کن معلومات کو پڑھنا چاہیے۔
• Block storage volume۔ یہ کوئی plan نہیں ہے، بلکہ network-attached disk ہے جسے آپ موجودہ VPS میں شامل کرتے ہیں اور جس کی ادائیگی GB فی ماہ کے حساب سے کرتے ہیں۔ ان چاروں میں صرف اسی volume کو server منتقل کیے بغیر بڑھایا جا سکتا ہے۔

یہ ranges مارکیٹ میں عام ساخت کو ظاہر کرتی ہیں، کسی ایک company کی offer کو نہیں۔ Plan پر موجود label ایک category ہوتا ہے، اس لیے یہ صرف اتنا بتاتا ہے کہ آپ کا server تقریباً کس chassis پر چلتا ہے۔ یہ disk type، CPU allocation policy یا bandwidth allowance کے بارے میں نہیں بتاتا، حالانکہ یہی وہ تفصیلات ہیں جو طے کرتی ہیں کہ آپ کا workload اچھی طرح چلے گا یا نہیں۔

دونوں منصوبوں کے درمیان اصل فرق کیا ہے

ڈسک کی قسم اور مقدار۔ مصنوعات میں بنیادی فرق یہی ہے۔ standard plan میں آپ کو PCI Express bus کے ذریعے حاصل ہونے والی NVMe flash ملتی ہے۔ storage plan میں بڑی spinning disks یا high-capacity SATA SSDs شامل ہوتی ہیں۔ اگر آپ کو یقین نہیں کہ ان اصطلاحات میں سے کون سی آپ کے لیے اہم ہے تو پہلے SSD VPS کیا ہے اور یہ پرانے disk plans سے کیسے مختلف ہے پڑھیں، پھر NVMe اور SATA SSD کے درمیان عملی فرق دیکھیں۔

CPU تناسب۔ storage plans میں ہر terabyte کے مقابلے میں vCPU کم ہوتے ہیں، اور یہ vCPU تقریباً ہمیشہ دوسرے tenants کے ساتھ shared ہوتے ہیں۔ یہ کوئی خامی نہیں ہے۔ backup target اپنا زیادہ وقت network کا انتظار کرتے ہوئے گزارتا ہے، اس لیے اسے زیادہ cores کی ضرورت نہیں ہوتی۔

RAM۔ قیمت کے مقابلے میں storage plans میں RAM کم ہوتی ہے۔ اس کا اثر ایک مخصوص جگہ پر پڑتا ہے: filesystem metadata۔ لاکھوں چھوٹی files کے لیے directory اور inode cache میں memory درکار ہوتی ہے۔ اس کے بغیر ہر listing کے لیے disk دوبارہ پڑھنی پڑتی ہے۔

Network allowance۔ storage plan کی یہ سطر احتیاط سے پڑھیں۔ جس data کو 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 میں متعدد providers کے public price pages سے لیے گئے ہیں۔ یہ کسی ایک company کی quote نہیں ہیں اور ان میں تبدیلی ہو سکتی ہے۔ مستقل اہمیت اس مجموعی رجحان کی ہے۔ spinning storage plan میں ایک terabyte کی لاگت تقریباً 3 US dollars ماہانہ ہوتی ہے۔ standard plan میں اتنی ہی NVMe کی لاگت تقریباً 40 ہوتی ہے، جبکہ network-attached block volume 4 options میں سب سے مہنگا ہے، جس کی لاگت 90 ہے۔ ماہانہ bill کن اجزا سے بنتا ہے، اس کی وسیع تر وضاحت کے لیے VPS کی ماہانہ اصل لاگت کیا ہوتی ہے دیکھیں۔

قیمت فی TB اور قیمت فی core ایک دوسرے کے مخالف سمت کیوں جاتی ہیں

Storage node ایک chassis ہوتا ہے جس میں بارہ سے سولہ بڑی disks اور ان کے سامنے ایک معمولی processor ہوتا ہے۔ Compute node اس کے برعکس ہوتا ہے: اس میں متعدد cores، کافی RAM، اور دو یا چار NVMe drives ہوتی ہیں۔ Provider اس chassis میں دستیاب spare resources ہی فروخت کرتا ہے۔ اسی لیے جو plan فی terabyte سستا ہوتا ہے، وہ فی core مہنگا ہوتا ہے، اور جو plan فی core سستا ہوتا ہے، وہ فی terabyte مہنگا ہوتا ہے۔ ایسا کوئی plan نہیں جو دونوں اعتبار سے سستا ہو، کیونکہ کوئی chassis اسی طرح تیار نہیں کیا جاتا۔

اسی وجہ سے "مجھے کون سا خریدنا چاہیے" کا دیانت دار جواب اکثر "دونوں" ہوتا ہے۔ Application چلانے والا ایک چھوٹا NVMe VPS، اور اس کے backups رکھنے والا ایک storage VPS، ایسے ایک machine سے کم لاگت رکھتے ہیں جو دونوں کام مناسب طور پر کر سکے۔ جب واقعی ایک machine کو دونوں کام کرنے ہوں تو آپ VPS کی حدود سے آگے جا چکے ہیں: جب dedicated server، VPS سے بہتر ہوتا ہے۔

سستی disk random reads نہیں کر سکتی

[
  {
    "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
  }
]

یہ figures کسی provider کا benchmark نہیں بلکہ datasheet class figures ہیں۔ 7200 rpm disk فی سیکنڈ تقریباً 180 random 4k reads فراہم کرتی ہے، کیونکہ head کو track تک جسمانی طور پر منتقل ہونا پڑتا ہے اور پھر platter کو sector کو head کے نیچے لانے کا انتظار کرنا پڑتا ہے۔ اس عمل میں ہر بار تقریباً 8.5 ms لگتے ہیں۔ Flash میں حرکت کرنے والا کوئی head نہیں ہوتا، اس لیے SATA SSD تقریباً 75,000 اور NVMe device تقریباً 600,000 IOPS فراہم کرتی ہے، جس کی latency 0.08 ms ہوتی ہے۔ یہ فرق تین ہزار گنا سے زیادہ ہے، اور RAM یا CPU کی کوئی بھی مقدار اسے ختم نہیں کر سکتی۔

Sequential کام بالکل مختلف ہے، اسی لیے storage plans مفید ہوتے ہیں۔ ایک single spinning disk اب بھی 150 MB/s سے 250 MB/s تک مسلسل data stream کر سکتی ہے، جبکہ disks کی array اس سے زیادہ رفتار دیتی ہے۔ یہ 1 Gbit/s port کو مکمل طور پر استعمال کر لیتی ہے، اس لیے backup upload مکمل network speed پر چلتا ہے اور disk کبھی limit نہیں بنتی۔ آپ کے figures اس بات پر بھی منحصر ہیں کہ array کیسے بنائی گئی ہے، کیونکہ striping ایک request کو کئی disks میں تقسیم کرتی ہے: RAID 10 storage plan کی performance کیسے بدلتا ہے اس کی وضاحت کرتا ہے۔

VDS سے کیا مراد ہے؟

عام طور پر یہ ایک marketing label ہوتا ہے۔ اس کے تین عام مفاہیم ہیں، اور provider شاذونادر ہی بتاتا ہے کہ یہاں کون سا مفہوم لاگو ہوتا ہے۔ کچھ providers VDS سے مراد pinned یا dedicated CPU cores لیتے ہیں، اس لیے کوئی دوسرا tenant آپ کے CPU cycles کے لیے مقابلہ نہیں کرتا۔ کچھ اسے KVM جیسی full virtualization کے لیے استعمال کرتے ہیں، جو LXC یا OpenVZ جیسی container virtualization سے مختلف ہے، کیونکہ وہاں آپ host kernel شیئر کرتے ہیں۔ کچھ providers اسے محض ایسے نام کے طور پر استعمال کرتے ہیں جو VPS سے زیادہ مضبوط محسوس ہو، اس کے علاوہ اس کا کوئی خاص مطلب نہیں ہوتا۔

اس کا کچھ حصہ آپ server کے اندر سے معلوم کر سکتے ہیں۔ systemd-detect-virt ایک full virtual machine پر kvm اور container پر lxc دکھاتا ہے۔ Container کا مطلب یہ ہے کہ آپ kernel modules load نہیں کر سکتے اور اپنا kernel نہیں چلا سکتے۔ Dedicated CPU کے دعوے کی تصدیق آپ کو نیچے دیے گئے steal time check کے ذریعے خود ناپ کر کرنی ہوگی۔ Plan پر درج حروف کو صرف ایک اشارہ سمجھیں، جبکہ specification کی سطور کو اصل معاہدہ سمجھیں۔

نام کے بجائے کن specification لائنوں کو دیکھیں

• capacity کے ساتھ درج لفظ: NVMe، SSD، SATA یا HDD۔ اگر صفحے پر کہیں بھی disk کا لفظ موجود نہ ہو تو قیمت میں موزوں سب سے سستا hardware فرض کریں۔
• یہ دیکھیں کہ disk node کے ساتھ local ہے یا network attached۔ Network attached storage ہر request میں latency بڑھاتی ہے اور node failure کے بعد بھی برقرار رہتی ہے۔ Local disk تیز ہوتی ہے، لیکن node کے ساتھ ہی ناکام ہو جاتی ہے۔
• CPU کی وضاحت: "dedicated" یا "pinned" کے مقابلے میں "shared"، "fair share" یا کوئی وضاحت موجود نہ ہونا۔
• plan میں درج IOPS یا MB/s کی کوئی cap۔ 500 IOPS کی cap disk type کو تقریباً غیر اہم بنا دیتی ہے۔
• ماہانہ transfer allowance اور port speed، جو یہ طے کرتے ہیں کہ مکمل restore میں کتنا وقت لگے گا۔
• یہ دیکھیں کہ snapshots، backups اور اضافی IP addresses شامل ہیں یا الگ سے billed ہیں۔

اصل میں فراہم کردہ disk کو کیسے جانچیں

پہلے 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 اس چیز کو بیان کرتا ہے جسے hypervisor نے ظاہر کیا ہے، نہ کہ rack میں گھومنے والی disk کو؛ اس لیے خود پیمائش کریں۔

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 کو bypass کرتا ہے، اس لیے آپ RAM کے بجائے disk کی پیمائش کرتے ہیں۔ پڑھنے والی لائن read: IOPS= ہے، اور اس کے نیچے clat percentiles (usec) میں distribution دی گئی ہے۔ ایک standard NVMe plan عموماً دسیوں ہزار IOPS رپورٹ کرتا ہے، جبکہ 99th percentile ایک millisecond سے کم ہوتا ہے۔ spinning storage plan چند سو IOPS رپورٹ کرتا ہے، جبکہ 99th percentile دو ہندسوں والے milliseconds میں ہوتا ہے۔ اگر 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 ہے: وہ وقت کا حصہ جس میں آپ کا vCPU run ہونے کے لیے ready تھا، لیکن host نے وہ cycles کسی دوسرے guest کو دے دیں۔ مسلسل 5 سے زیادہ قدر ظاہر کرتی ہے کہ node پر ضرورت سے زیادہ guests موجود ہیں۔ یہی "dedicated CPU" کے دعوے کا حقیقی امتحان ہے۔ iostat -x میں %util، r_await اور w_await کو monitor کریں۔ تقریباً 100 کا %util، جبکہ w_await دسیوں milliseconds میں ہو، اس بات کی علامت ہے کہ disk bottleneck ہے؛ application tuning سے مسئلہ حل نہیں ہوگا۔ Flash سے متعلق مخصوص جانچ کے لیے تصدیق کریں کہ NVMe disk واقعی NVMe ہے میں مزید تفصیل دی گئی ہے۔

کام کے بوجھ کے مطابق انتخاب

• restic، Borg یا rsync کے لیے backup target۔ Storage VPS اس استعمال کے لیے بنایا گیا ہے۔ Writes بڑی اور sequential ہوتی ہیں، deduplication source machine پر ہوتی ہے، اور کوئی عمل result کا انتظار نہیں کر رہا ہوتا۔ ایک اہم نکتہ: restic prune اور restic check --read-data پورے repository کو چھوٹے حصوں میں پڑھتے ہیں، اس لیے ان کے لیے کئی گھنٹوں کا وقت مختص کریں اور انہیں schedule کے مطابق چلائیں۔ VPS پر restic backups چلانا دیکھیں۔
• Immich یا Jellyfin media library۔ فائلوں کے لیے Storage VPS موزوں ہے، لیکن CPU کے بارے میں محتاط رہیں۔ Immich import کے وقت thumbnails بناتا ہے اور machine learning jobs چلاتا ہے، جبکہ Jellyfin playback کے دوران transcode کرتا ہے۔ دو shared vCPU، 200 GB تصاویر کے پہلے import کو مکمل کرنے میں بہت وقت لیں گے۔ Database اور thumbnail cache کو machine کی تیز ترین disk پر رکھیں۔ sizing کی تفصیل Google Photos کے متبادل کے طور پر Immich کی self-hosting میں ہے۔
• PostgreSQL یا MySQL۔ Standard NVMe plan استعمال کریں۔ ہر commit ایک fsync پر ختم ہوتا ہے جسے transaction کے واپس ہونے سے پہلے durable storage تک پہنچنا ضروری ہے۔ اس لیے commit latency دراصل disk latency ہوتی ہے، جبکہ index lookup ایک random 8 kB read ہوتا ہے، جو spinning disk کے لیے بدترین کام ہے۔
• Web application، API یا control plane۔ Standard plan استعمال کریں۔ ان workloads کو cores اور predictable latency درکار ہوتی ہے، اور انہیں شاذونادر ہی 100 GB سے زیادہ storage چاہیے ہوتی ہے۔
• CI cache یا artifact store۔ یہ file size پر منحصر ہے۔ بڑے tarballs، storage plan سے پوری network speed پر stream ہو جاتے ہیں۔ سینکڑوں ہزاروں چھوٹی files کا cache، جنہیں کئی runners parallel طور پر pull کریں، بظاہر random IO ہی ہوتا ہے اور اس سے کارکردگی مایوس کن رہے گی۔

جب یہ غلط طریقے سے کیا جائے تو صورتِ حال کیسی نظر آتی ہے

خرابی کبھی فوری طور پر ظاہر نہیں ہوتی۔ spinning storage plan پر موجود database ایک user کے ساتھ درست محسوس ہوتا ہے، لیکن دس users کے بوجھ تلے ناکام ہونے لگتا ہے، کیونکہ جو queries پہلے RAM سے مکمل ہو جاتی تھیں وہ disk تک پہنچنے لگتی ہیں، اور اب ہر query کی لاگت microseconds کے بجائے milliseconds ہوتی ہے۔ Load average بڑھتا جاتا ہے، جبکہ top دکھاتا ہے کہ CPU زیادہ تر idle ہے اور %wa کی قدر زیادہ ہے۔ اس کا مطلب ہے کہ processes computation کرنے کے بجائے disk کا انتظار کرتے ہوئے blocked ہیں۔ iostat -x 1، %util کو تقریباً 100 پر مستقل دکھاتا ہے۔

PostgreSQL اپنے log میں یہ بات واضح طور پر بتاتا ہے، کیونکہ version 15 سے log_checkpoints بطور default enabled ہے:

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

اہم قدر sync= ہے۔ یہ وہ وقت ہے جو checkpoint نے fsync کے واپس آنے کا انتظار کرتے ہوئے گزارا۔ اس لیے seconds میں ظاہر ہونے والی قدر کا مطلب ہے کہ disk اتنی تیزی سے writes قبول نہیں کر سکتی جتنی تیزی سے database انہیں پیدا کرتا ہے۔ اس وقفے کے دوران client connections رک جاتی ہیں، حالانکہ query خود سستی ہوتی ہے۔ اس کا حل configuration تبدیل کرنا نہیں ہے۔ data directory کو NVMe پر منتقل کریں، اور storage plan کو اس کام کے لیے استعمال کریں جس میں وہ مؤثر ہے: اس database کے backups محفوظ رکھنے کے لیے۔

FAQ

کیا storage VPS عام VPS سے سست ہوتا ہے؟

Random reads اور writes کے لیے ہاں، اور نمایاں فرق کے ساتھ۔ Spinning storage plan تقریباً 8 ms میں فی سیکنڈ چند سو چھوٹی random requests مکمل کرتا ہے، جبکہ NVMe plan 1 ms سے بھی کم وقت میں دسیوں ہزار requests مکمل کرتا ہے۔ Sequential transfers میں دونوں کے درمیان فرق بہت کم ہوتا ہے، کیونکہ storage array اب بھی 150 MB/s یا اس سے زیادہ رفتار سے data stream کر سکتا ہے، جو 1 Gbit/s port کو بھرنے کے لیے کافی ہے۔ فیصلہ کرنے سے پہلے fio --rw=randread --bs=4k --direct=1 کے ذریعے اپنے سسٹم کی پیمائش کریں۔

کیا میں storage VPS پر PostgreSQL چلا سکتا ہوں؟

آپ اسے start کر سکتے ہیں، اور یہ اس وقت تک کام کرے گا جب تک working set RAM میں سما سکے۔ اس کے بعد ہر commit ایک سست disk پر fsync کا انتظار کرتا ہے، اور Postgres اسے checkpoint complete کے اندر سیکنڈز میں sync= figure کے طور پر log کرتا ہے، جبکہ iostat -x 1 w_await کی بلند قدر کے ساتھ %util کو تقریباً 100 دکھاتا ہے۔ عام انتظام یہ ہے کہ database کے لیے ایک چھوٹا NVMe VPS استعمال کیا جائے اور اس کے dumps کے ہدف کے طور پر storage VPS رکھا جائے۔

کیا VDS کا مطلب ہے کہ مجھے dedicated hardware ملتا ہے؟

قابلِ اعتماد طور پر نہیں۔ VDS کا کوئی standard meaning نہیں ہے۔ کچھ providers اسے pinned CPU cores کے لیے استعمال کرتے ہیں، کچھ shared kernel container کے مقابلے میں مکمل KVM virtualization کے لیے، اور کچھ اسے محض ایک نام کے طور پر استعمال کرتے ہیں۔ یہ دیکھنے کے لیے systemd-detect-virt چلائیں کہ آپ kvm یا lxc پر ہیں، اور vmstat 1 5 چلائیں، پھر st column کو monitor کریں تاکہ معلوم ہو سکے کہ آیا دوسرے tenants آپ کے CPU cycles استعمال کر رہے ہیں۔

میں کیسے معلوم کروں کہ میرے VPS کی disk واقعی NVMe ہے؟

lsblk -d -o NAME,ROTA,MODEL پر بھروسا نہ کریں، کیونکہ virtio disk عموماً ROTA=0 report کرتی ہے اور hardware کچھ بھی ہو، model string خالی دکھاتی ہے۔ --direct=1 کے ساتھ 30 سیکنڈ کا fio random read test چلائیں، پھر IOPS اور 99th percentile latency دیکھیں۔ دو ہندسوں والی milliseconds latency کے ساتھ سیکڑوں IOPS spinning array کی علامت ہیں۔ 1 millisecond سے کم latency کے ساتھ دسیوں ہزار IOPS flash کی علامت ہیں۔