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 ہو۔ دونوں اصطلاحات کو ملا کر ایک بات بیان کی جاتی ہے۔ جب آپ کا 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 نہیں ہوتا۔ Hosts ایسا اس لیے کرتے ہیں کہ کئی سال پہلے storage کے بارے میں capacity سب سے اہم عدد نہیں رہی۔ سرور کی کارکردگی محسوس ہونے کا فیصلہ کرنے والے دو اعداد IOPS (input/output operations per second) اور latency (ایک operation کے واپس آنے میں لگنے والا وقت) ہیں۔

اس کی وجہ storage کا مکینکی فرق ہے۔ Hard disk ڈیٹا کو گھومنے والی 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 کو اسی قسم کے تقریباً 600,000 reads کے لیے rate کیا جاتا ہے، جن میں ہر read کو تقریباً 0.08 ms لگتے ہیں۔ ان دونوں کے درمیان موجود SATA SSD کو تقریباً 90,000 کے لیے rate کیا جاتا ہے۔ ان اعداد کو percentage improvement کے طور پر نہیں، بلکہ orders of magnitude کے طور پر پڑھیں۔

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

یہ دونوں columns مختلف سوالوں کے جواب دیتے ہیں، اس لیے انہیں ساتھ پڑھیں۔ Latency بتاتی ہے کہ ایک operation کے لیے آپ کو کتنا انتظار کرنا پڑتا ہے۔ IOPS بتاتے ہیں کہ drive بیک وقت کتنے operations پر کام کر سکتی ہے۔ Flash parallelism کے ذریعے اپنی بلند IOPS figures حاصل کرتی ہے، کیونکہ متعدد 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 کو support کرتا ہے، اور ہر queue میں ہزاروں commands رک سکتی ہیں۔ اس طرح متعدد CPU cores ایک ہی تنگ queue کو share کیے بغیر بیک وقت drive سے رابطہ کر سکتے ہیں۔
• PCIe (peripheral component interconnect express) وہ bus ہے جس پر NVMe چلتا ہے۔ یہ اسی قسم کی lanes ہیں جن میں graphics card نصب ہوتا ہے۔

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

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

ایک ہی اصطلاح کے تحت دو بالکل مختلف arrangements فروخت کیے جاتے ہیں۔

Local storage سے مراد ہے کہ flash drives اسی physical host کے اندر موجود ہوں جس پر آپ کا VPS چل رہا ہے۔ درخواست ایک ہی machine کے اندر PCIe کے ذریعے سفر کرتی ہے اور فوراً واپس آ جاتی ہے۔ اسی وجہ سے latency دسیوں microseconds تک محدود رہتی ہے۔

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

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

حقیقی سرور پر فرق کیسا محسوس ہوتا ہے

سرور کا کام عموماً طویل sequential transfers کے بجائے چھوٹی random reads اور writes پر مشتمل ہوتا ہے۔ اسی لیے marketing copy میں درج MB/s کا عدد صفحے پر موجود سب سے کم مفید عدد ہوتا ہے۔

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

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

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

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

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

Caps کی دو بنیادی اقسام ہیں۔ 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 سے تبدیل کریں۔ جب kernel کو بتایا گیا ہو کہ device non-rotational ہے تو ROTA اور rotational file 0 پڑھتے ہیں، جبکہ اس کے برعکس صورت میں 1 پڑھتے ہیں۔ Virtual disk یہ flag اس معلومات کی بنیاد پر set کرتی ہے جو hypervisor فراہم کرتا ہے، اس لیے یہ virtual device کی خصوصیات بیان کرتا ہے، نہ کہ اس کے نیچے موجود physical hardware کی۔ Virtio disk کے لیے MODEL عموماً خالی ہوتا ہے، مثلاً vda، یا emulated SATA controller پر QEMU HARDDISK جیسی عمومی string ہوتی ہے۔ Guest کو host کی storage array نظر نہیں آنی چاہیے، اور حقیقتاً نظر نہیں آتی۔

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

خرید سے پہلے provider سے پوچھے جانے والے تین سوالات

1. کیا storage hypervisor کے لیے local ہے، یا network attached ہے؟ جواب آپ کی latency کی کم از کم سطح متعین کرتا ہے اور یہ بھی طے کرتا ہے کہ physical host fail ہونے پر آپ کے 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 چلے گا، اس لیے منصوبہ بندی اسی کو بنیاد بنا کر کریں۔

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

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

اصل سمجھوتا فی 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 ہو سکتا ہے۔ SATA SSD ایسی interface کے ذریعے flash storage فراہم کرتا ہے جو mechanical disks کے لیے بنائی گئی ہے۔ اس میں 32 commands کی queue اور تقریباً 550 MB/s کی زیادہ سے زیادہ رفتار ہوتی ہے۔ دونوں hard disk سے کہیں زیادہ تیز ہوتے ہیں۔ اگر آپ کے workload کے لیے ان دونوں کا فرق اہم ہے تو plan کے نام سے اندازہ لگانے کے بجائے provider سے پوچھیں کہ plan میں کون سی storage استعمال ہوتی ہے۔

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

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

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

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

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

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