آپ کے اعلی دستیابی اسٹوریج (99,9999%) پر سافٹ ویئر کی توثیق کرنا کیوں ضروری ہے

کون سا فرم ویئر ورژن سب سے زیادہ "درست" اور "کام کرنے والا" ہے؟ اگر سٹوریج سسٹم 99,9999% کی غلطی برداشت کرنے کی ضمانت دیتا ہے، تو کیا اس کا مطلب یہ ہے کہ یہ بغیر کسی سافٹ ویئر اپ ڈیٹ کے بھی بلاتعطل کام کرے گا؟ یا، اس کے برعکس، زیادہ سے زیادہ غلطی برداشت کرنے کے لیے، آپ کو ہمیشہ جدید ترین فرم ویئر انسٹال کرنا چاہیے؟ ہم اپنے تجربے کی بنیاد پر ان سوالات کا جواب دینے کی کوشش کریں گے۔

چھوٹا تعارف

ہم سب سمجھتے ہیں کہ سافٹ ویئر کا ہر ورژن، خواہ وہ آپریٹنگ سسٹم ہو یا ڈیوائس کا ڈرائیور، اکثر اس میں نقائص/بگز اور دیگر "خصوصیات" ہوتے ہیں جو ہو سکتا ہے کہ آلات کی سروس لائف کے اختتام تک "ظاہر" نہ ہوں، یا "کھلا" صرف کچھ شرائط کے تحت. اس طرح کی باریکیوں کی تعداد اور اہمیت سافٹ ویئر کی پیچیدگی (کارکردگی) اور اس کی نشوونما کے دوران جانچ کے معیار پر منحصر ہے۔ 

اکثر، صارفین "فیکٹری سے فرم ویئر" پر رہتے ہیں (مشہور "یہ کام کرتا ہے، لہذا اس کے ساتھ گڑبڑ نہ کریں") یا ہمیشہ تازہ ترین ورژن انسٹال کرتے ہیں (ان کی سمجھ میں، تازہ ترین کا مطلب ہے سب سے زیادہ کام کرنے والا)۔ ہم ایک مختلف طریقہ استعمال کرتے ہیں - ہم استعمال شدہ ہر چیز کے لیے ریلیز نوٹ دیکھتے ہیں۔ mClouds کے بادل میں سامان اور احتیاط سے سامان کے ہر ٹکڑے کے لیے مناسب فرم ویئر کا انتخاب کریں۔

ہم اس نتیجے پر پہنچے، جیسا کہ وہ کہتے ہیں، تجربے سے۔ ہمارے آپریشن کی مثال کا استعمال کرتے ہوئے، ہم آپ کو بتائیں گے کہ اگر آپ فوری طور پر سافٹ ویئر اپ ڈیٹس اور تفصیل کی نگرانی نہیں کرتے ہیں تو سٹوریج سسٹم کی 99,9999% بھروسہ مندی کا وعدہ کیوں نہیں ہوتا۔ ہمارا کیس کسی بھی وینڈر کے سٹوریج سسٹم کے استعمال کرنے والوں کے لیے موزوں ہے، کیونکہ ایسی ہی صورت حال کسی بھی مینوفیکچرر کے ہارڈ ویئر کے ساتھ ہو سکتی ہے۔

نئے اسٹوریج سسٹم کا انتخاب

پچھلے سال کے آخر میں، ہمارے بنیادی ڈھانچے میں ایک دلچسپ ڈیٹا اسٹوریج سسٹم شامل کیا گیا: IBM FlashSystem 5000 لائن کا ایک جونیئر ماڈل، جسے خریداری کے وقت Storwize V5010e کہا جاتا تھا۔ اب اسے FlashSystem 5010 کے نام سے فروخت کیا جاتا ہے، لیکن درحقیقت یہ وہی ہارڈ ویئر بیس ہے جس کے اندر ایک ہی Spectrum Virtualize ہے۔ 

یونیفائیڈ مینجمنٹ سسٹم کی موجودگی، ویسے، IBM FlashSystem کے درمیان بنیادی فرق ہے۔ چھوٹی سیریز کے ماڈلز کے لیے، یہ عملی طور پر زیادہ پیداواری ماڈلز سے مختلف نہیں ہے۔ ایک مخصوص ماڈل کا انتخاب صرف مناسب ہارڈ ویئر کی بنیاد فراہم کرتا ہے، جس کی خصوصیات ایک یا دوسری فعالیت کو استعمال کرنا یا اعلی درجے کی توسیع پذیری فراہم کرنا ممکن بناتی ہیں۔ سافٹ ویئر ہارڈ ویئر کی شناخت کرتا ہے اور اس پلیٹ فارم کے لیے ضروری اور کافی فعالیت فراہم کرتا ہے۔

آئی بی ایم فلیش سسٹم 5010

مختصراً ہمارے ماڈل 5010 کے بارے میں۔ یہ ایک انٹری لیول کا ڈوئل کنٹرولر بلاک اسٹوریج سسٹم ہے۔ یہ NLSAS، SAS، SSD ڈسکوں کو ایڈجسٹ کر سکتا ہے۔ اس میں NVMe پلیسمنٹ دستیاب نہیں ہے، کیونکہ یہ سٹوریج ماڈل ان مسائل کو حل کرنے کے لیے رکھا گیا ہے جن کے لیے NVMe ڈرائیوز کی کارکردگی کی ضرورت نہیں ہے۔

اسٹوریج سسٹم کو آرکائیو کی معلومات یا ڈیٹا کو ایڈجسٹ کرنے کے لیے خریدا گیا تھا جس تک اکثر رسائی نہیں ہوتی ہے۔ لہذا، اس کی فعالیت کا معیاری سیٹ ہمارے لیے کافی تھا: ٹائرنگ (آسان ٹائر)، پتلا پروویژن۔ 1000-2000 IOPS کی سطح پر NLSAS ڈسکوں پر کارکردگی بھی ہمارے لیے کافی تسلی بخش تھی۔

ہمارا تجربہ - کس طرح ہم نے فرم ویئر کو وقت پر اپ ڈیٹ نہیں کیا۔

اب خود سافٹ ویئر اپ ڈیٹ کے بارے میں۔ خریداری کے وقت، سسٹم کے پاس پہلے سے ہی سپیکٹرم ورچوئلائز سافٹ ویئر کا تھوڑا پرانا ورژن تھا، یعنی، 8.2.1.3.

ہم نے فرم ویئر کی تفصیل کا مطالعہ کیا اور اپ ڈیٹ کرنے کا منصوبہ بنایا 8.2.1.9. اگر ہم تھوڑا زیادہ موثر ہوتے، تو یہ مضمون موجود نہ ہوتا - ایک حالیہ فرم ویئر پر بگ پیدا نہ ہوتا۔ تاہم، بعض وجوہات کی بناء پر، اس نظام کی اپ ڈیٹ کو ملتوی کر دیا گیا تھا۔

نتیجے کے طور پر، ایک معمولی اپ ڈیٹ کی تاخیر ایک انتہائی ناخوشگوار تصویر کا باعث بنی، جیسا کہ لنک پر دی گئی تفصیل میں ہے: https://www.ibm.com/support/pages/node/6172341. 

ہاں، اس ورژن کے فرم ویئر میں نام نہاد APAR (مجاز پروگرام تجزیہ رپورٹ) HU02104 متعلقہ تھا۔ یہ مندرجہ ذیل طور پر ظاہر ہوتا ہے. بوجھ کے تحت، مخصوص حالات میں، کیش اوور فلو ہونا شروع ہو جاتا ہے، پھر سسٹم حفاظتی موڈ میں چلا جاتا ہے، جس میں یہ پول کے لیے I/O کو غیر فعال کر دیتا ہے۔ ہمارے معاملے میں، یہ RAID 3 موڈ میں RAID گروپ کے لیے 6 ڈسکوں کو منقطع کرنے کی طرح لگتا ہے۔ منقطع 6 منٹ کے لیے ہوتا ہے۔ اگلا، پول میں والیوم تک رسائی بحال ہو جاتی ہے۔

اگر کوئی IBM Spectrum Virtualize کے تناظر میں منطقی اداروں کی ساخت اور ناموں سے واقف نہیں ہے، تو میں اب مختصراً وضاحت کروں گا۔

اسٹوریج سسٹم کی ساخت منطقی عناصر

ڈسکوں کو گروپوں میں جمع کیا جاتا ہے جسے MDisk (منیجڈ ڈسک) کہتے ہیں۔ MDisk ایک کلاسک RAID (0,1,10,5,6) یا ورچوئلائزڈ - DRAID (تقسیم شدہ RAID) ہو سکتا ہے۔ DRAID کا استعمال آپ کو صف کی کارکردگی بڑھانے کی اجازت دیتا ہے، کیونکہ... گروپ میں موجود تمام ڈسکوں کو استعمال کیا جائے گا، اور دوبارہ تعمیر کا وقت کم ہو جائے گا، اس حقیقت کی وجہ سے کہ صرف مخصوص بلاکس کو بحال کرنے کی ضرورت ہوگی، اور ناکام ڈسک کے تمام ڈیٹا کو نہیں۔

RAID-5 موڈ میں ڈسٹری بیوٹڈ RAID (DRAID) کا استعمال کرتے وقت ڈسکوں میں ڈیٹا بلاکس کی تقسیم۔

اور یہ خاکہ اس منطق کو ظاہر کرتا ہے کہ ایک ڈسک کی ناکامی کی صورت میں DRAID دوبارہ تعمیر کیسے کرتا ہے:

جب ایک ڈسک ناکام ہوجاتی ہے تو DRAID کی دوبارہ تعمیر کی منطق

اگلا، ایک یا زیادہ MDisks ایک نام نہاد پول بناتے ہیں۔ ایک ہی پول کے اندر، ایک ہی قسم کی ڈسکوں پر مختلف RAID/DRAID لیولز کے ساتھ MDisk استعمال کرنے کی سفارش نہیں کی جاتی ہے۔ ہم اس میں زیادہ گہرائی میں نہیں جائیں گے، کیونکہ... ہم مندرجہ ذیل مضامین میں سے ایک میں اس کا احاطہ کرنے کا ارادہ رکھتے ہیں۔ ٹھیک ہے، حقیقت میں، پول کو حجم میں تقسیم کیا گیا ہے، جو میزبانوں کو ایک یا دوسرے بلاک رسائی پروٹوکول کا استعمال کرتے ہوئے پیش کیا جاتا ہے۔

لہذا، ہم، میں بیان کردہ صورت حال کے نتیجے میں APAR HU02104، تین ڈسکوں کی منطقی ناکامی کی وجہ سے، MDisk نے کام کرنا چھوڑ دیا، جس کے نتیجے میں، پول اور متعلقہ والیوم کی ناکامی ہوئی۔

چونکہ یہ سسٹم کافی سمارٹ ہیں، ان کو IBM سٹوریج انسائٹس کلاؤڈ بیسڈ مانیٹرنگ سسٹم سے منسلک کیا جا سکتا ہے، جو خود بخود IBM سپورٹ کو سروس کی درخواست بھیجتا ہے اگر کوئی مسئلہ پیش آتا ہے۔ ایک ایپلیکیشن بنائی جاتی ہے اور IBM ماہرین دور سے تشخیص کرتے ہیں اور سسٹم کے صارف سے رابطہ کرتے ہیں۔ 

اس کی بدولت، مسئلہ کافی تیزی سے حل ہو گیا تھا اور سپورٹ سروس سے ہمارے سسٹم کو پہلے سے منتخب کردہ فرم ویئر 8.2.1.9 پر اپ ڈیٹ کرنے کے لیے فوری سفارش موصول ہوئی تھی، جو اس وقت پہلے ہی طے ہو چکی تھی۔ تصدیق کرتا ہے۔ متعلقہ ریلیز نوٹ.

نتائج اور ہماری سفارشات

جیسا کہ کہاوت ہے: "سب ٹھیک ہے جو اچھا ہوتا ہے۔" فرم ویئر میں بگ نے سنگین مسائل پیدا نہیں کیے - سرورز کو جلد از جلد بحال کیا گیا اور ڈیٹا کے نقصان کے بغیر۔ کچھ کلائنٹس کو ورچوئل مشینوں کو دوبارہ شروع کرنا پڑا، لیکن عام طور پر ہم مزید منفی نتائج کے لیے تیار تھے، کیونکہ ہم تمام بنیادی ڈھانچے کے عناصر اور کلائنٹ مشینوں کا روزانہ بیک اپ بناتے ہیں۔ 

ہمیں تصدیق موصول ہوئی ہے کہ 99,9999% وعدہ شدہ دستیابی کے ساتھ قابل اعتماد سسٹم بھی توجہ اور بروقت دیکھ بھال کی ضرورت ہے۔ صورتحال کی بنیاد پر، ہم نے اپنے لیے بہت سے نتائج اخذ کیے ہیں اور اپنی سفارشات کا اشتراک کرتے ہیں:

• یہ ضروری ہے کہ اپ ڈیٹس کے اجراء کی نگرانی کریں، ممکنہ طور پر نازک مسائل کی اصلاح کے لیے ریلیز نوٹس کا مطالعہ کریں، اور منصوبہ بند اپ ڈیٹس کو بروقت انجام دیں۔

  یہ ایک تنظیمی اور یہاں تک کہ بالکل واضح نکتہ ہے، جس پر ایسا لگتا ہے کہ اس پر توجہ دینے کے قابل نہیں ہے۔ تاہم، اس "لیول گراؤنڈ" پر آپ کافی آسانی سے ٹھوکر کھا سکتے ہیں۔ درحقیقت، یہی وہ لمحہ تھا جس نے اوپر بیان کی گئی پریشانیوں میں اضافہ کیا۔ اپ ڈیٹ کے ضوابط تیار کرتے وقت بہت محتاط رہیں اور ان کی تعمیل کو کم احتیاط سے مانیٹر کریں۔ یہ نکتہ "نظم و ضبط" کے تصور سے زیادہ تعلق رکھتا ہے۔

• سسٹم کو جدید ترین سافٹ ویئر ورژن کے ساتھ رکھنا ہمیشہ بہتر ہے۔ مزید برآں، موجودہ وہ نہیں ہے جس کا عددی عہدہ بڑا ہو، بلکہ وہ ہے جو بعد میں ریلیز کی تاریخ کے ساتھ ہو۔ 

  مثال کے طور پر، IBM اپنے اسٹوریج سسٹم کے لیے کم از کم دو سافٹ ویئر ریلیز کو تازہ ترین رکھتا ہے۔ اس تحریر کے وقت، یہ 8.2 اور 8.3 ہیں۔ 8.2 کے لیے اپ ڈیٹس پہلے سامنے آتے ہیں۔ 8.3 کے لیے اسی طرح کی تازہ کاری عام طور پر تھوڑی تاخیر کے ساتھ جاری کی جاتی ہے۔

  ریلیز 8.3 کے بہت سے فنکشنل فوائد ہیں، مثال کے طور پر، ایک یا زیادہ نئی ڈسکیں شامل کر کے MDisk (DRAID موڈ میں) کو پھیلانے کی صلاحیت (یہ خصوصیت ورژن 8.3.1 سے ظاہر ہوئی ہے)۔ یہ کافی بنیادی فعالیت ہے، لیکن 8.2 میں، بدقسمتی سے، ایسی کوئی خصوصیت نہیں ہے۔

• اگر کسی وجہ سے اپ ڈیٹ کرنا ممکن نہ ہو، تو اسپیکٹرم ورچوئلائز سافٹ ویئر کے ورژن 8.2.1.9 اور 8.3.1.0 (جہاں اوپر بیان کیا گیا بگ متعلقہ ہے) سے پہلے کے ورژن کے لیے، اس کی موجودگی کے خطرے کو کم کرنے کے لیے، IBM تکنیکی معاونت تجویز کرتی ہے۔ پول کی سطح پر سسٹم کی کارکردگی کو محدود کرنا، جیسا کہ نیچے دی گئی تصویر میں دکھایا گیا ہے (تصویر GUI کے Russified ورژن میں لی گئی تھی)۔ 10000 IOPS کی قدر کو مثال کے طور پر دکھایا گیا ہے اور آپ کے سسٹم کی خصوصیات کے مطابق منتخب کیا گیا ہے۔

IBM اسٹوریج کی کارکردگی کو محدود کرنا

• سٹوریج سسٹمز پر بوجھ کا صحیح حساب لگانا اور اوور لوڈنگ سے بچنا ضروری ہے۔ ایسا کرنے کے لیے، آپ یا تو IBM سائزر (اگر آپ کو اس تک رسائی حاصل ہے)، یا شراکت داروں کی مدد، یا تیسرے فریق کے وسائل استعمال کر سکتے ہیں۔ اسٹوریج سسٹم پر لوڈ پروفائل کو سمجھنا ضروری ہے، کیونکہ MB/s اور IOPS میں کارکردگی کم از کم درج ذیل پیرامیٹرز پر منحصر ہوتی ہے:

  • آپریشن کی قسم: پڑھنا یا لکھنا،

  • آپریشن بلاک سائز،

  • کل I/O سلسلہ میں پڑھنے اور لکھنے کی کارروائیوں کا فیصد۔

  نیز، آپریشنز کی رفتار اس سے متاثر ہوتی ہے کہ ڈیٹا بلاکس کو کیسے پڑھا جاتا ہے: ترتیب وار یا بے ترتیب ترتیب میں۔ ایپلی کیشن سائیڈ پر ڈیٹا تک رسائی کے متعدد آپریشنز انجام دیتے وقت، منحصر آپریشنز کا تصور موجود ہے۔ اس کو بھی مدنظر رکھنا مناسب ہے۔ یہ سب OS، سٹوریج سسٹم، سرورز/ہائپر وائزرز کے پرفارمنس کاؤنٹرز سے ڈیٹا کی مجموعی تعداد کے ساتھ ساتھ ایپلی کیشنز، DBMSs اور ڈسک وسائل کے دوسرے "صارفین" کی آپریٹنگ خصوصیات کو سمجھنے میں مدد کر سکتے ہیں۔

• اور آخر میں، بیک اپ اپ ٹو ڈیٹ اور کام کرنے کو یقینی بنائیں۔ بیک اپ شیڈول کو کاروبار کے لیے قابل قبول RPO اقدار کی بنیاد پر ترتیب دیا جانا چاہیے، اور ایک قابل قبول RTO قدر کو یقینی بنانے کے لیے بیک اپس کی وقفہ وقفہ سے انٹیگریٹی چیکس کی تصدیق کی جانی چاہیے (کئی بیک اپ سافٹ ویئر فروشوں نے اپنی مصنوعات میں خودکار تصدیق نافذ کی ہے)۔

آخر تک پڑھنے کا شکریہ۔
ہم کمنٹس میں آپ کے سوالات اور تبصروں کا جواب دینے کے لیے تیار ہیں۔ بھی ہم آپ کو ہمارے ٹیلیگرام چینل کو سبسکرائب کرنے کی دعوت دیتے ہیں۔، جس میں ہم باقاعدہ پروموشنز (IaaS پر چھوٹ اور VPS پر 100% تک پروموشنل کوڈز کے لیے تحفے) رکھتے ہیں، دلچسپ خبریں لکھتے ہیں اور Habr بلاگ پر نئے مضامین کا اعلان کرتے ہیں۔

ماخذ: www.habr.com