SSD VPS کیا ہے؟ Flash storage اور فوائد کی وضاحت

SSD VPS کیا ہے؟

SSD VPS ایک virtual private server ہے جس کی disk spinning hard disk کے بجائے flash memory پر مبنی ہوتی ہے۔ SSD سے مراد solid state drive ہے: ایسا storage جو NAND flash chips سے بنا ہوتا ہے اور اس کے اندر کوئی moving parts نہیں ہوتے۔ VPS سے مراد virtual private server ہے: physical host machine کا ایک isolated حصہ، جو اپنا operating system چلاتا ہے اور آپ کو اس طرح فروخت کیا جاتا ہے جیسے یہ مکمل server ہو۔ دونوں کو ملا کر اس label کا مطلب ایک بات ہے۔ جب آپ کا server data کا کوئی block پڑھتا ہے تو پہلے کسی mechanical حصے کو حرکت نہیں کرنی پڑتی۔

یہی مکمل تعریف ہے۔ ذیل کی تمام باتیں ان امور سے متعلق ہیں جو اس label میں شامل نہیں ہوتے، کیونکہ pricing page پر موجود الفاظ "SSD hosting" اس storage array کے بارے میں بہت کم معلومات دیتے ہیں جو پس پشت کام کر رہا ہوتا ہے۔

اگر آپ اب بھی یہ سمجھنے کی کوشش کر رہے ہیں کہ VPS، عام virtual machine سے کیسے مختلف ہے، تو VPS، VM اور VPC کے درمیان فرق والا صفحہ پہلے پڑھنا بہتر ہے۔

میزبان storage size کے بجائے storage speed کیوں ظاہر کرتے ہیں

ایک plan page میں CPU cores، memory، disk size اور bandwidth درج ہوتے ہیں، پھر disk کے بارے میں ایک ایسا لفظ شامل کیا جاتا ہے جو size نہیں ہوتا۔ میزبان ایسا اس لیے کرتے ہیں کہ کئی سال پہلے storage کے بارے میں capacity سب سے اہم عدد نہیں رہی۔ دو اعداد یہ طے کرتے ہیں کہ server کی کارکردگی کیسی محسوس ہوگی: IOPS (input/output operations per second) اور latency (ایک operation کے واپس آنے میں لگنے والا وقت)۔

اس کی وجہ mechanical فرق ہے۔ hard disk، data کو گھومنے والی platters پر رکھتی ہے اور moving arm پر موجود head سے اسے پڑھتی ہے۔ platter پر کسی دوسرے block تک پہنچنے کے لیے arm کو seek کرنا پڑتا ہے، پھر disk کو اس وقت تک گھومنا پڑتا ہے جب تک درست sector head کے نیچے نہ آ جائے۔ 7200 revolutions per minute پر آدھا چکر اوسطاً تقریباً 4 ms لیتا ہے، اور seek میں مزید کئی ms لگتے ہیں۔ Flash میں arm یا platter نہیں ہوتا، اس لیے read ایک electrical lookup ہوتا ہے جو tens of microseconds میں واپس آ جاتا ہے۔

[
  {
    "device": "7200 rpm hard disk",
    "random_read_iops": "125",
    "read_latency_ms": 8
  },
  {
    "device": "SATA SSD",
    "random_read_iops": "90,000",
    "read_latency_ms": 0.15
  },
  {
    "device": "NVMe SSD",
    "random_read_iops": "600,000",
    "read_latency_ms": 0.08
  }
]

ایک 7200 rpm hard disk کو تقریباً 125 random 4k reads per second کے لیے rate کیا جاتا ہے، اور ان میں سے ایک read کو واپس آنے میں تقریباً 8 ms لگتے ہیں۔ ایک NVMe drive کو اسی قسم کے reads کے تقریباً 600,000 کے لیے rate کیا جاتا ہے، اور ہر read میں تقریباً 0.08 ms لگتے ہیں۔ ان دونوں کے درمیان SATA SSD کو تقریباً 90,000 کے لیے rate کیا جاتا ہے۔ ان اعداد کو orders of magnitude کے طور پر پڑھیں، percentage improvement کے طور پر نہیں۔

اس data کے بارے میں دو انتباہات ہیں۔ یہ ہر class کی مکمل drives کے لیے شائع شدہ specifications ہیں، اس لیے یہ manufacturer sheet کے اعداد ہیں، نہ کہ VPS پر کی گئی پیمائش۔ آپ کو کبھی مکمل drive نہیں ملتی: آپ کا volume ایک device کا حصہ یا ایک array کا حصہ ہوتا ہے، اور اسی hardware پر دوسرے customers کے volumes بھی موجود ہوتے ہیں۔

یہ دونوں columns مختلف سوالات کے جواب دیتے ہیں، اس لیے انہیں ساتھ پڑھیں۔ Latency بتاتی ہے کہ ایک operation کے لیے آپ کو کتنا انتظار کرنا پڑتا ہے۔ IOPS بتاتا ہے کہ drive بیک وقت کتنے operations پر کام کر سکتی ہے۔ Flash اپنی بلند IOPS values parallelism کے ذریعے حاصل کرتی ہے، کیونکہ بہت سے flash chips بیک وقت بہت سی requests کا جواب دیتے ہیں، جبکہ ایک deep queue انہیں مصروف رکھتی ہے۔ ایک single-threaded program جو ایک read جاری کرتا ہے، اس کے مکمل ہونے کا انتظار کرتا ہے، پھر اگلا read جاری کرتا ہے، اس chart کی بلند ترین سطح کبھی نہیں دیکھے گا۔ اسے latency column نظر آتا ہے۔

SSD، NVMe، SATA اور PCIe: چار مختلف تہوں کے چار الفاظ

خریدار ان الفاظ کو اس لیے خلط ملط کرتے ہیں کیونکہ ہر لفظ نظام کے ایک مختلف حصے کی وضاحت کرتا ہے۔

• SSD ذریعۂ ذخیرہ ہے۔ اس کا مطلب ہے کہ ڈیٹا مقناطیسی پلیٹوں کے بجائے NAND flash chips پر محفوظ ہوتا ہے۔
• SATA ایک interface ہے، جسے mechanical disks کے دور میں تیار کیا گیا تھا۔ اس کی زیادہ سے زیادہ رفتار 6 Gbit/s ہے، جو حقیقی throughput میں تقریباً 550 MB/s بنتی ہے، اور اس کی command queue میں 32 زیرِ التوا commands آ سکتی ہیں۔
• NVMe (non-volatile memory express) ایک protocol ہے جسے خاص طور پر flash کے لیے لکھا گیا ہے۔ یہ متعدد queues کو سپورٹ کرتا ہے، جن میں سے ہر ایک میں ہزاروں commands ہو سکتی ہیں۔ اس طرح کئی CPU cores ایک ہی وقت میں drive سے بات کر سکتے ہیں، بغیر اس کے کہ ایک محدود queue مشترک طور پر استعمال کریں۔
• PCIe (peripheral component interconnect express) وہ bus ہے جس پر NVMe چلتا ہے۔ یہ اسی قسم کی lanes ہیں جن میں graphics card نصب ہوتا ہے۔

اس لیے SATA SSD اور NVMe SSD دونوں ڈیٹا کو flash پر محفوظ کرتے ہیں۔ فرق اس interface کا ہے جس کے ذریعے وہ مواصلت کرتے ہیں۔ SATA SSD اب بھی کسی بھی hard disk سے بہت تیز ہے، لیکن اس کی 32 commands والی queue اس parallel کام کی مقدار محدود کر دیتی ہے جسے یہ ظاہر کر سکتا ہے، جبکہ flash کے لیے parallel کام ہی موزوں ہے۔ آپ کے workload کے لحاظ سے اضافی قیمت ادا کرنا کس کے لیے مناسب ہے، یہ NVMe اور SATA SSD کے فیصلے میں تفصیل سے بیان کیا گیا ہے۔

مقامی فلیش یا نیٹ ورک سے منسلک اسٹوریج؟

ایک ہی لفظ کے تحت دو بالکل مختلف انتظامات فروخت کیے جاتے ہیں۔

مقامی اسٹوریج سے مراد ہے کہ فلیش ڈرائیوز اسی فزیکل host کے اندر موجود ہوں جس پر آپ کا VPS چل رہا ہے۔ درخواست ایک ہی مشین کے اندر PCIe کے ذریعے سفر کرتی ہے اور فوراً واپس آ جاتی ہے۔ اسی وجہ سے تاخیر دسیوں مائیکرو سیکنڈز تک محدود رہتی ہے۔

نیٹ ورک سے منسلک اسٹوریج سے مراد ہے کہ آپ کی virtual disk ایک الگ storage cluster میں موجود ہو، جو اکثر Ceph یا SAN (storage area network) ہوتا ہے، اور ہر read اور write اس تک پہنچنے کے لیے network سے گزرتا ہے۔ Providers اسے عموماً "cloud block storage" یا "elastic volumes" کہتے ہیں۔ فلیش حقیقی ہوتی ہے۔ Network کا سفر بھی حقیقی ہوتا ہے، اور یہ ہر operation میں شامل ہوتا ہے۔ اسی لیے تاخیر دسیوں مائیکرو سیکنڈز کے بجائے عموماً سیکڑوں مائیکرو سیکنڈز کے آخری حصے یا کم ملی سیکنڈز تک پہنچ جاتی ہے۔

دونوں میں سے کوئی بھی غلط انتخاب نہیں ہے۔ Network storage کسی host کے ناکام ہونے کے باوجود برقرار رہتی ہے، کیونکہ data کبھی اس host پر موجود ہی نہیں تھا۔ Provider آپ کے server کو دوسرے hardware پر شروع کر سکتا ہے اور disk اس کے ساتھ منتقل ہو جاتی ہے۔ Local NVMe زیادہ تیز ہوتی ہے اور ایک physical machine سے منسلک رہتی ہے، اس لیے وہاں hardware failure کا مطلب backup سے restore کرنا ہے۔ پوچھیں کہ plan میں کون سا استعمال ہوتا ہے۔ تقریباً کوئی نہیں پوچھتا۔

حقیقی سرور پر فرق کی عملی صورت

سرور کا کام عموماً چھوٹی بے ترتیب read اور write کارروائیوں پر مشتمل ہوتا ہے، طویل مسلسل منتقلیوں پر نہیں۔ اسی لیے مارکیٹنگ کے متن میں دی گئی MB/s کی قدر صفحے پر موجود سب سے کم مفید عدد ہوتی ہے۔

• Database commits۔ پائیداری کی ضمانت دینے والا database transaction commit ہونے پر fsync کو کال کرتا ہے، پھر drive کی تصدیق کا انتظار کرتا ہے کہ data واقعی محفوظ ہو گیا ہے۔ hard disk پر یہ انتظار milliseconds پر محیط ہوتا ہے، جس کی وجہ سے چھوٹا database فی سیکنڈ کم سینکڑوں commits تک محدود رہتا ہے۔ flash پر یہی انتظار millisecond کے ایک حصے کے برابر ہوتا ہے۔ PostgreSQL، MySQL یا پروڈکشن database کے طور پر SQLite چلانے کی صورت میں فرق سب سے زیادہ یہاں نظر آتا ہے۔
• Package installs۔ apt install ہزاروں چھوٹی files کو unpack کرتا ہے اور عمل کے دوران انہیں disk کے ساتھ sync کرتا رہتا ہے۔ اس کام کا تقریباً کوئی حصہ مسلسل نہیں ہوتا، اس لیے کارکردگی IOPS سے محدود رہتی ہے۔
• Container image pulls۔ docker pull compressed layers کو network کے ذریعے حاصل کرتا ہے، پھر انہیں ہزاروں چھوٹی files میں extract کرتا ہے۔ download کی رفتار network سے محدود ہوتی ہے۔ extraction کی رفتار disk سے محدود ہوتی ہے، اور سست volume پر آپ کو انتظار extraction کے دوران کرنا پڑتا ہے۔
• Boot اور reboot۔ Startup پہلے kernel اور initramfs کو read کرتا ہے، پھر volume پر بکھری ہوئی سینکڑوں چھوٹی unit files اور shared libraries کو read کرتا ہے۔

ان میں سے کوئی بھی عمل بڑی مسلسل read نہیں ہے۔ جو volume 500 MB/s کی رفتار سے data منتقل کرتا ہو لیکن صرف 3,000 IOPS فراہم کرتا ہو، وہ پھر بھی docker compose pull کے دوران سست محسوس ہوگا، کیونکہ انتظار ہر megabyte کے بجائے ہر file کے لیے شمار ہوتا ہے۔

قیمتوں کے صفحے پر "SSD cloud hosting" تقریباً کچھ نہیں بتاتی

یہ اصطلاح صرف اسٹوریج کے ذریعے کو بیان کرتی ہے۔ یہ نہیں بتاتی کہ drive کس interface کے ذریعے کام کرتی ہے، اور نہ یہ کہ وہ drive آپ کے server کی اسی machine میں موجود ہے یا نہیں۔ یہ بھی نہیں بتایا جاتا کہ آپ کے plan کو زیادہ سے زیادہ کس حد تک پہنچنے کی اجازت ہے۔

یہ حد سب سے زیادہ اہم ہوتی ہے، لیکن اسے سب سے کم نمایاں کیا جاتا ہے۔ Providers ہر volume کے لیے IOPS اور throughput محدود کرتے ہیں، کیونکہ ایک host بہت سے customers کو service دیتا ہے اور غیر محدود neighbour دوسرے customers کے وسائل ختم کر سکتا ہے۔ ایسے hardware پر جس کی صلاحیت hundreds of thousands IOPS ہو، چند ہزار IOPS کی حد معمول کی بات ہے اور دیانت دارانہ بھی، لیکن plan description میں یہ حد نظر نہیں آتی۔ دونوں plans میں "SSD" لکھا ہو سکتا ہے، جبکہ ایک local NVMe ہو جس پر فی volume کوئی حد نہ ہو، اور دوسرا shared cluster volume ہو جو 3,000 IOPS تک محدود ہو۔

Limits کی دو شکلیں ہوتی ہیں۔ sustained cap ایک مستقل زیادہ سے زیادہ حد ہوتی ہے جو کبھی تبدیل نہیں ہوتی۔ burst cap میں کم baseline کے ساتھ credits ملتے ہیں، جو کچھ وقت کے لیے اس حد سے تجاوز کرنے دیتے ہیں، اور volume کے idle ہونے پر یہ credits دوبارہ جمع ہوتے ہیں۔ burst cap پانچ منٹ کے test میں بہترین دکھائی دے سکتا ہے، لیکن database import یا بڑے restore کے دوران baseline تک گر جاتا ہے۔ اگر کوئی provider بڑا عدد بتائے تو پوچھیں کہ آپ کو اسے کتنی دیر تک برقرار رکھنے کی اجازت ہے۔

یہ کیسے جانچیں کہ آپ کے VPS نے حقیقت میں کیا فراہم کیا ہے

Guest کے اندر سے آپ صرف وہی دیکھ سکتے ہیں جو hypervisor آپ کو بتاتا ہے۔

lsblk -d -o NAME,ROTA,MODEL,SIZE
cat /sys/block/vda/queue/rotational

vda کو اپنے disk کے لیے پرنٹ کیے گئے device name lsblk سے تبدیل کریں۔ ROTA اور rotational فائل 0 پڑھتی ہے جب kernel کو بتایا گیا ہو کہ device غیر گردشی ہے، اور 1 جب اسے اس کے برعکس بتایا گیا ہو۔ Virtual disk یہ flag اس معلومات سے متعین کرتی ہے جو hypervisor فراہم کرتا ہے، اس لیے یہ virtual device کی وضاحت کرتا ہے، نہ کہ اس کے نیچے موجود physical hardware کی۔ virtio disk، جیسے vda، کے لیے MODEL عموماً خالی ہوتا ہے، یا emulated SATA controller پر QEMU HARDDISK جیسی عمومی string ہوتی ہے۔ Guests کو host کی array نظر آنا مقصود نہیں ہوتا، اور انہیں نظر آتی بھی نہیں۔

اس لیے flag کو صرف ایک اشارہ سمجھیں اور باقی کارکردگی ناپیں۔ fio کے ذریعے volume پر موجود کسی file کے خلاف random 4k test چلائیں، اور queue depth وہ رکھیں جو آپ کی application حقیقت میں استعمال کرتی ہے۔ Test اتنی دیر چلائیں کہ burst credit مکمل طور پر استعمال ہو جائے۔ VPS کی درست benchmarking میں fio کے commands اور ان عام غلطیوں کی وضاحت ہے جو نتائج کو حقیقت سے بہتر ظاہر کرتی ہیں۔

خرید سے پہلے فراہم کنندہ سے پوچھنے کے لیے تین سوالات

1. کیا storage hypervisor کے ساتھ مقامی ہے، یا network attached ہے؟ جواب آپ کی latency کی کم از کم سطح طے کرتا ہے، اور یہ بھی طے کرتا ہے کہ physical host کے ناکام ہونے پر آپ کے data کے ساتھ کیا ہوگا۔ جو provider اس کا واضح جواب دے، اس نے اس معاملے پر غور کیا ہے۔
2. میرے volume پر IOPS limit کیا ہے؟ ایک عدد مانگیں۔ "Unlimited" اور "enterprise grade" اعداد نہیں ہیں۔ اگر واقعی کوئی cap نہیں ہے، تو پوچھیں کہ ایک ہی host پر موجود neighbour کو اپنی backup window کے دوران پورا array استعمال کرنے سے کیا روکتا ہے۔
3. کیا یہ limit sustained ہے یا burst؟ اگر یہ burst ہے، تو baseline اور burst کی مدت پوچھیں۔ baseline وہ figure ہے جس کے ساتھ آپ کا nightly job کام کرے گا، اس لیے planning اسی کے مطابق کریں۔

کیا flash ختم ہو جاتا ہے، اور کیا یہ آپ کا مسئلہ ہے؟

Flash cells محدود تعداد میں write cycles قبول کرتے ہیں، اس لیے drives اپنی endurance rating کو TBW (terabytes written) یا DWPD (drive writes per day) میں ظاہر کرتی ہیں۔ Drive writes کو اپنی cells میں یکساں طور پر تقسیم کرتی ہے، جسے wear levelling کہتے ہیں، اور ناکام ہونے والی cells کی جگہ لینے کے لیے اضافی blocks محفوظ رکھتی ہے۔ VPS پر wear provider کا مسئلہ ہے: وہ اپنی drives کے SMART counters کی نگرانی کرتے ہیں اور rating ختم ہونے سے پہلے hardware تبدیل کر دیتے ہیں۔ آپ کا مسئلہ flash سے بھی پرانا ہے۔ Drive backup نہیں ہوتی، اور آپ کے volume کے نیچے redundancy بھی backup نہیں ہے، کیونکہ یہ data کی طرح deletion کو بھی اسی وفاداری سے نقل کرتی ہے۔

اصل سمجھوتا جو آپ کر رہے ہیں، وہ فی gigabyte قیمت ہے۔ Flash کی فی gigabyte قیمت spinning disks سے زیادہ ہوتی ہے، اس لیے ایک SSD plan عموماً اسی قیمت پر hard disk plan کے مقابلے میں کم capacity فراہم کرتا ہے۔ اگر آپ کو media یا archives کے لیے زیادہ storage درکار ہے تو fast volume کو چھوٹا رکھیں اور bulk data کو کسی سستی جگہ پر رکھیں۔ یہ backups کو server سے باہر رکھنے کے لیے بھی درست طریقہ ہے۔ Storage مجموعی bill میں کس طرح شامل ہوتی ہے، اس کی تفصیل VPS کی اصل لاگت میں دی گئی ہے۔

FAQ

کیا SSD VPS، NVMe VPS ہی ہوتا ہے؟

ہر NVMe VPS، SSD VPS ہوتا ہے، کیونکہ NVMe drives flash پر مبنی ہوتی ہیں۔ اس کے برعکس ضروری نہیں۔ "SSD" کے نام سے پیش کیا جانے والا plan، SATA SSD ہو سکتا ہے۔ اس میں flash ایسی interface کے پیچھے ہوتی ہے جو mechanical disks کے لیے بنائی گئی ہے، اس کی command queue 32 ہوتی ہے، اور رفتار تقریباً 550 MB/s تک محدود رہتی ہے۔ دونوں hard disk سے کہیں زیادہ تیز ہوتے ہیں۔ اگر یہ فرق آپ کے workload کے لیے اہم ہے تو plan کے نام سے اندازہ لگانے کے بجائے provider سے پوچھیں کہ plan میں کون سی storage استعمال ہوتی ہے۔

کیا SSD VPS میری website کو تیز کر دیتا ہے؟

یہ disk کے کام کو تیز کرتا ہے، اور صرف disk کے کام کو۔ جو page ہر request پر کئی database queries چلاتا ہے، وہ تیز ہو جاتا ہے، کیونکہ یہ queries اور ان کے commits چھوٹے random I/O ہوتے ہیں۔ جو page memory یا cache سے serve ہوتا ہے، اسے فراہم کرتے وقت disk تک رسائی نہیں ہوتی، اس لیے رفتار میں بہت کم تبدیلی آتی ہے۔ Storage کے ذریعے مسئلہ حل کرنے کے لیے ادائیگی کرنے سے پہلے یہ ناپیں کہ request کا کون سا حصہ سست ہے۔

میں کیسے جانچ سکتا ہوں کہ میرا VPS واقعی SSD storage استعمال کرتا ہے؟

Guest کے اندر سے آپ physical hardware کی تصدیق نہیں کر سکتے۔ lsblk -d -o NAME,ROTA دکھاتا ہے کہ virtual device کیا ظاہر کرتی ہے، اور hypervisor اس قدر کا فیصلہ کرتا ہے۔ اس لیے وہاں 0 کا آنا اشارہ ہے، ثبوت نہیں۔ عملی جانچ measurement ہے: کئی منٹ تک random 4k read workload کے ساتھ fio چلائیں اور اس کی رپورٹ کردہ latency دیکھیں۔ ایک ہندسے کی millisecond random reads spinning disks یا congested network volume کی طرف اشارہ کرتی ہیں۔ دسیوں microseconds local flash کی طرف اشارہ کرتے ہیں۔

کیا network attached SSD storage، local NVMe سے بدتر ہے؟

یہ ہر operation کے لحاظ سے سست ہوتی ہے، اور اس کی خرابی کا انداز بھی مختلف ہوتا ہے۔ ہر read اور ہر write میں network round trip شامل ہوتا ہے، اس لیے دونوں کے flash ہونے کے باوجود latency زیادہ ہوتی ہے۔ اس کے بدلے آپ کا data کسی ایک physical host پر موجود نہیں رہتا۔ لہذا host failure کی صورت میں volume بھی اس کے ساتھ متاثر نہیں ہوتی، اور provider کے لیے snapshots اور live migration آسان ہوتے ہیں۔ Latency sensitive database کے لیے local flash منتخب کریں۔ جب volume کا محفوظ رہنا microseconds سے زیادہ اہم ہو تو network storage منتخب کریں۔