ہیلو، حبر قارئین! اس مضمون کا موضوع AERODISK انجن اسٹوریج سسٹمز میں ڈیزاسٹر ریکوری ٹولز کا نفاذ ہوگا۔ ابتدا میں، ہم دونوں ٹولز کے بارے میں ایک مضمون میں لکھنا چاہتے تھے: نقل اور میٹرو کلسٹر، لیکن بدقسمتی سے مضمون بہت لمبا نکلا، اس لیے ہم نے مضمون کو دو حصوں میں تقسیم کیا۔ آئیے سادہ سے پیچیدہ کی طرف چلتے ہیں۔ اس مضمون میں، ہم ہم وقت ساز نقل کو ترتیب دیں گے اور جانچیں گے - ہم ایک ڈیٹا سینٹر چھوڑ دیں گے، اور ڈیٹا سینٹرز کے درمیان مواصلاتی چینل کو بھی توڑ دیں گے اور دیکھیں گے کہ کیا ہوتا ہے۔
ہمارے گاہک اکثر ہم سے نقل کے بارے میں مختلف سوالات پوچھتے ہیں، لہٰذا نقل کے عمل کو ترتیب دینے اور جانچنے سے پہلے، ہم آپ کو تھوڑا سا بتائیں گے کہ اسٹوریج میں نقل کیا ہے۔
تھوڑا سا اصول
سٹوریج سسٹمز میں ریپلیکشن بیک وقت کئی سٹوریج سسٹمز پر ڈیٹا کی شناخت کو یقینی بنانے کا ایک مسلسل عمل ہے۔ تکنیکی طور پر، نقل دو طریقوں سے مکمل کی جاتی ہے۔
ہم وقت ساز نقل - یہ مرکزی اسٹوریج سسٹم سے ڈیٹا کو بیک اپ میں کاپی کر رہا ہے، اس کے بعد دونوں سٹوریج سسٹمز سے لازمی تصدیق ہے کہ ڈیٹا ریکارڈ اور تصدیق ہو چکا ہے۔ یہ دونوں اطراف (دونوں سٹوریج سسٹمز) کی تصدیق کے بعد ہے کہ ڈیٹا کو ریکارڈ شدہ سمجھا جاتا ہے اور اس کے ساتھ کام کیا جا سکتا ہے۔ یہ ریپلیکا میں حصہ لینے والے تمام سٹوریج سسٹمز پر ڈیٹا کی شناخت کو یقینی بناتا ہے۔
اس طریقہ کار کے فوائد:
- تمام اسٹوریج سسٹمز پر ڈیٹا ہمیشہ ایک جیسا ہوتا ہے۔
Cons:
- حل کی زیادہ قیمت (تیز مواصلاتی چینلز، مہنگے آپٹیکل فائبر، لانگ ویو ٹرانسسیور وغیرہ)
- فاصلے کی پابندیاں (کئی دسیوں کلومیٹر کے اندر)
- مین سٹوریج سسٹم پر منطقی ڈیٹا کرپٹ ہونے کے خلاف کوئی تحفظ نہیں ہے (اگر ڈیٹا کرپٹ ہو گیا ہے (جان بوجھ کر یا غلطی سے) تو یہ بیک اپ پر خود بخود اور فوری طور پر کرپٹ ہو جائے گا، کیونکہ ڈیٹا ہمیشہ یکساں ہوتا ہے (یہی تضاد ہے)
غیر مطابقت پذیر نقل - یہ مرکزی سٹوریج سسٹم سے ڈیٹا کو بیک اپ والے میں بھی کاپی کر رہا ہے، لیکن ایک خاص تاخیر کے ساتھ اور دوسری طرف تحریر کی تصدیق کی ضرورت کے بغیر۔ آپ ڈیٹا کو مین سٹوریج سسٹم میں ریکارڈ کرنے کے فوراً بعد اس کے ساتھ کام کر سکتے ہیں، اور بیک اپ سٹوریج سسٹم پر کچھ دیر بعد ڈیٹا دستیاب ہو جائے گا۔ اس معاملے میں ڈیٹا کی شناخت بالکل یقینی نہیں ہے۔ بیک اپ اسٹوریج سسٹم پر ڈیٹا ہمیشہ "ماضی میں" تھوڑا سا ہوتا ہے۔
غیر مطابقت پذیر نقل کے فوائد:
- کم لاگت کا حل (کوئی بھی مواصلاتی چینلز، آپٹکس اختیاری)
- دوری کی کوئی پابندی نہیں۔
- بیک اپ سٹوریج سسٹم پر، ڈیٹا خراب نہیں ہوتا ہے اگر یہ مین پر خراب ہو جائے (کم از کم کچھ وقت کے لیے)؛ اگر ڈیٹا کرپٹ ہو جاتا ہے، تو آپ بیک اپ اسٹوریج سسٹم پر ڈیٹا کرپٹ کو روکنے کے لیے ریپلیکا کو ہمیشہ روک سکتے ہیں۔
Cons:
- مختلف ڈیٹا سینٹرز میں موجود ڈیٹا ہمیشہ ایک جیسا نہیں ہوتا ہے۔
اس طرح، نقل کے موڈ کا انتخاب کاروباری مقاصد پر منحصر ہے۔ اگر یہ آپ کے لیے اہم ہے کہ بیک اپ ڈیٹا سینٹر میں بالکل وہی ڈیٹا ہے جو مرکزی ڈیٹا سینٹر (یعنی RPO = 0 کے لیے کاروباری ضرورت) پر مشتمل ہے، تو آپ کو نقد رقم نکالنی ہوگی اور ہم وقت سازی کی حدود کو برداشت کرنا ہوگا۔ نقل اور اگر ڈیٹا کی حالت میں تاخیر قابل قبول ہے یا صرف پیسہ نہیں ہے، تو آپ کو یقینی طور پر غیر مطابقت پذیر طریقہ استعمال کرنے کی ضرورت ہے۔
آئیے ہم میٹرو کلسٹر کے طور پر اس طرح کے موڈ (زیادہ واضح طور پر ٹوپولوجی) کو بھی الگ سے اجاگر کرتے ہیں۔ میٹرو کلسٹر موڈ میں، ہم وقت ساز نقل کا استعمال کیا جاتا ہے، لیکن، ایک باقاعدہ نقل کے برعکس، میٹرو کلسٹر دونوں سٹوریج سسٹم کو فعال موڈ میں کام کرنے کی اجازت دیتا ہے۔ وہ. آپ کو فعال اور اسٹینڈ بائی ڈیٹا سینٹرز کے درمیان کوئی فرق نہیں ہے۔ ایپلی کیشنز بیک وقت دو سٹوریج سسٹمز کے ساتھ کام کرتی ہیں، جو جسمانی طور پر مختلف ڈیٹا سینٹرز میں واقع ہیں۔ ایسی ٹوپولوجی میں حادثات کے دوران ڈاؤن ٹائم بہت چھوٹا ہوتا ہے (RTO، عام طور پر منٹ)۔ اس مضمون میں ہم میٹرو کلسٹر کے نفاذ پر غور نہیں کریں گے، چونکہ یہ ایک بہت بڑا اور وسعت والا موضوع ہے، اس لیے ہم اسی کے تسلسل میں اس کے لیے ایک الگ، اگلا مضمون مختص کریں گے۔
اس کے علاوہ، اکثر اوقات، جب ہم سٹوریج سسٹم کا استعمال کرتے ہوئے نقل تیار کرنے کے بارے میں بات کرتے ہیں، تو بہت سے لوگوں کے پاس ایک معقول سوال ہوتا ہے: > "بہت سی ایپلی کیشنز کے اپنے ریپلییکشن ٹولز ہوتے ہیں، اسٹوریج سسٹمز پر نقل کیوں استعمال کرتے ہیں؟ کیا یہ بہتر ہے یا بدتر؟
یہاں کوئی واضح جواب نہیں ہے، لہذا یہاں FOR اور CONS کے دلائل ہیں:
ذخیرہ نقل کے لیے دلائل:
- حل کی سادگی۔ ایک ٹول کے ساتھ، آپ لوڈ کی قسم اور ایپلیکیشن سے قطع نظر اپنے پورے ڈیٹا سیٹ کو نقل کر سکتے ہیں۔ اگر آپ ایپلی کیشنز سے نقل استعمال کرتے ہیں، تو آپ کو ہر ایپلیکیشن کو الگ سے کنفیگر کرنا ہوگا۔ اگر ان میں سے 2 سے زیادہ ہیں، تو یہ انتہائی محنت طلب اور مہنگا ہے (درخواست کی نقل کے لیے عام طور پر ہر درخواست کے لیے علیحدہ اور مفت لائسنس کی ضرورت ہوتی ہے۔ لیکن ذیل میں اس پر مزید)۔
- آپ کسی بھی چیز کی نقل تیار کر سکتے ہیں - کوئی بھی ایپلیکیشن، کوئی بھی ڈیٹا - اور یہ ہمیشہ مستقل رہے گا۔ بہت سے (زیادہ تر) ایپلی کیشنز میں نقل کی صلاحیتیں نہیں ہیں، اور سٹوریج سسٹم سے نقلیں آفات سے تحفظ فراہم کرنے کا واحد طریقہ ہیں۔
- درخواست کی نقل کی فعالیت کے لیے زیادہ ادائیگی کرنے کی ضرورت نہیں ہے۔ ایک اصول کے طور پر، یہ سستا نہیں ہے، بالکل اسی طرح جیسے اسٹوریج سسٹم کی نقل کے لائسنس۔ لیکن آپ کو ایک بار سٹوریج کی نقل کے لیے لائسنس کے لیے ادائیگی کرنی ہوگی، اور درخواست کی نقل کے لیے ایک لائسنس کو ہر درخواست کے لیے الگ سے خریدنا ہوگا۔ اگر اس طرح کی بہت سی ایپلی کیشنز ہیں، تو اس پر ایک پیسہ خرچ ہوتا ہے اور سٹوریج کی نقل تیار کرنے کے لیے لائسنس کی قیمت بالٹی میں ایک گراوٹ بن جاتی ہے۔
اسٹوریج کی نقل کے خلاف دلائل:
- ایپلی کیشنز کے ذریعے ریپلیکا میں خود ایپلی کیشنز کے نقطہ نظر سے زیادہ فعالیت ہوتی ہے، ایپلی کیشن اپنے ڈیٹا کو بہتر جانتی ہے (ظاہر ہے)، اس لیے ان کے ساتھ کام کرنے کے لیے مزید آپشنز موجود ہیں۔
- کچھ ایپلی کیشنز کے مینوفیکچررز ان کے ڈیٹا کی مستقل مزاجی کی ضمانت نہیں دیتے ہیں اگر اس کی نقل تھرڈ پارٹی ٹولز کا استعمال کرتے ہوئے کی جاتی ہے۔ *
* - متنازعہ مقالہ۔ مثال کے طور پر، ایک معروف DBMS مینوفیکچرر کافی عرصے سے باضابطہ طور پر اعلان کر رہا ہے کہ ان کے DBMS کو صرف ان کے ذرائع کا استعمال کرتے ہوئے عام طور پر نقل کیا جا سکتا ہے، اور باقی نقل (بشمول اسٹوریج سسٹم) "سچ نہیں ہے۔" لیکن زندگی نے دکھایا ہے کہ ایسا نہیں ہے۔ زیادہ تر امکان ہے (لیکن یہ یقینی نہیں ہے) یہ صارفین کو مزید لائسنس فروخت کرنے کی سب سے ایماندارانہ کوشش نہیں ہے۔
نتیجے کے طور پر، زیادہ تر معاملات میں، اسٹوریج سسٹم سے نقل بہتر ہے، کیونکہ یہ ایک آسان اور کم مہنگا آپشن ہے، لیکن ایسے پیچیدہ معاملات ہوتے ہیں جب مخصوص ایپلیکیشن کی فعالیت کی ضرورت ہوتی ہے، اور ایپلیکیشن کی سطح کی نقل کے ساتھ کام کرنا ضروری ہوتا ہے۔
تھیوری کے ساتھ ہو گیا، اب پریکٹس کریں۔
ہم اپنی لیب میں نقل تیار کریں گے۔ لیبارٹری کے حالات میں، ہم نے دو ڈیٹا سینٹرز کی تقلید کی (حقیقت میں، دو ملحقہ ریک جو مختلف عمارتوں میں لگ رہے تھے)۔ اسٹینڈ دو انجن N2 اسٹوریج سسٹمز پر مشتمل ہے، جو آپٹیکل کیبلز کے ذریعے ایک دوسرے سے جڑے ہوئے ہیں۔ Windows Server 2016 چلانے والا ایک فزیکل سرور 10Gb ایتھرنیٹ کا استعمال کرتے ہوئے دونوں اسٹوریج سسٹم سے منسلک ہے۔ موقف کافی آسان ہے، لیکن اس سے جوہر نہیں بدلتا۔
اسکیماتی طور پر یہ اس طرح لگتا ہے:
منطقی طور پر، نقل کو اس طرح ترتیب دیا گیا ہے:
اب آئیے نقل کی فعالیت کو دیکھتے ہیں جو ہمارے پاس اب ہے۔
دو طریقوں کی حمایت کی جاتی ہے: متضاد اور ہم وقت ساز۔ یہ منطقی ہے کہ ہم وقت ساز موڈ فاصلے اور مواصلاتی چینل کے ذریعہ محدود ہے۔ خاص طور پر، سنکرونس موڈ میں فزکس اور 10 گیگابٹ ایتھرنیٹ (یا اس سے زیادہ) فائبر کے استعمال کی ضرورت ہوتی ہے۔
ہم وقت ساز نقل کے لیے تعاون یافتہ فاصلہ 40 کلومیٹر ہے، ڈیٹا سینٹرز کے درمیان آپٹیکل چینل کی تاخیر کی قیمت 2 ملی سیکنڈ تک ہے۔ عام طور پر، یہ بڑی تاخیر کے ساتھ کام کرے گا، لیکن پھر ریکارڈنگ کے دوران سخت سست روی ہوگی (جو کہ منطقی بھی ہے)، اس لیے اگر آپ ڈیٹا سینٹرز کے درمیان ہم وقت ساز نقل تیار کرنے کی منصوبہ بندی کر رہے ہیں، تو آپ کو آپٹکس کے معیار اور تاخیر کو چیک کرنا چاہیے۔
غیر مطابقت پذیر نقل کے تقاضے اتنے سنگین نہیں ہیں۔ زیادہ واضح طور پر، وہ وہاں بالکل نہیں ہیں۔ کوئی بھی کام کرنے والا ایتھرنیٹ کنکشن کرے گا۔
فی الحال، AERODISK ENGINE اسٹوریج سسٹم ایتھرنیٹ پروٹوکول (کاپر یا آپٹیکل سے زیادہ) کے ذریعے بلاک ڈیوائسز (LUNs) کی نقل تیار کرنے کی حمایت کرتا ہے۔ ایسے منصوبوں کے لیے جہاں فائبر چینل پر SAN فیبرک کے ذریعے نقل کی ضرورت ہوتی ہے، ہم فی الحال ایک مناسب حل شامل کر رہے ہیں، لیکن یہ ابھی تک تیار نہیں ہے، لہذا ہمارے معاملے میں، صرف ایتھرنیٹ۔
نقل کسی بھی انجن سیریز سٹوریج سسٹمز (N1, N2, N4) کے درمیان جونیئر سسٹمز سے لے کر بڑے سسٹمز اور اس کے برعکس کام کر سکتی ہے۔
نقل کے دونوں طریقوں کی فعالیت مکمل طور پر ایک جیسی ہے۔ ذیل میں دستیاب چیزوں کے بارے میں مزید تفصیلات ہیں:
- نقل "ایک سے ایک" یا "ایک سے ایک"، یعنی دو ڈیٹا سینٹرز کے ساتھ کلاسک ورژن، مین اور بیک اپ
- نقل "ایک سے کئی" یا "ایک سے بہت سے" ہے، یعنی ایک LUN کو بیک وقت کئی سٹوریج سسٹمز میں نقل کیا جا سکتا ہے۔
- نقل کی سمت کو فعال، غیر فعال، یا تبدیل کرنے کے لیے بالترتیب نقل کو چالو، غیر فعال، اور "ریورس" کریں۔
- نقل آر ڈی جی (ریڈ ڈسٹری بیوٹڈ گروپ) اور ڈی ڈی پی (ڈائنیمک ڈسک پول) دونوں پولز کے لیے دستیاب ہے۔ تاہم، RDG پول کے LUNs کو صرف دوسرے RDG میں نقل کیا جا سکتا ہے۔ ڈی ڈی پی کے ساتھ بھی۔
اس کے علاوہ اور بھی بہت سی چھوٹی خصوصیات ہیں، لیکن ان کی فہرست میں کوئی خاص بات نہیں ہے؛ جیسا کہ ہم ترتیب دیں گے ہم ان کا ذکر کریں گے۔
نقل ترتیب دینا
سیٹ اپ کا عمل کافی آسان ہے اور تین مراحل پر مشتمل ہے۔
- نیٹ ورک سیٹ اپ
- اسٹوریج سیٹ اپ
- قواعد (کنکشن) اور نقشہ سازی کو ترتیب دینا
نقل ترتیب دینے میں ایک اہم نکتہ یہ ہے کہ پہلے دو مراحل کو ریموٹ اسٹوریج سسٹم پر دہرایا جانا چاہئے، تیسرا مرحلہ - صرف اہم پر۔
نیٹ ورک کے وسائل کو ترتیب دینا
پہلا مرحلہ نیٹ ورک پورٹس کو کنفیگر کرنا ہے جس کے ذریعے نقلی ٹریفک کو منتقل کیا جائے گا۔ ایسا کرنے کے لیے، آپ کو پورٹس کو فعال کرنے اور ان کے آئی پی ایڈریس کو فرنٹ اینڈ اڈاپٹر سیکشن میں سیٹ کرنے کی ضرورت ہے۔
اس کے بعد، ہمیں ایک پول بنانے کی ضرورت ہے (ہمارے معاملے میں RDG) اور ایک ورچوئل آئی پی برائے نقل (VIP)۔ VIP ایک تیرتا ہوا IP ایڈریس ہے جو سٹوریج کنٹرولرز کے دو "جسمانی" پتوں سے جڑا ہوا ہے (وہ بندرگاہیں جنہیں ہم نے ابھی ترتیب دیا ہے)۔ یہ مرکزی نقل کا انٹرفیس ہوگا۔ اگر آپ کو ٹیگ شدہ ٹریفک کے ساتھ کام کرنے کی ضرورت ہو تو آپ VIP کے ساتھ نہیں بلکہ VLAN کے ساتھ بھی کام کر سکتے ہیں۔
نقل کے لیے VIP بنانے کا عمل I/O (NFS, SMB, iSCSI) کے لیے VIP بنانے سے زیادہ مختلف نہیں ہے۔ اس صورت میں، ہم ایک باقاعدہ VIP بناتے ہیں (بغیر VLAN)، لیکن اس بات کی نشاندہی کرنا یقینی بنائیں کہ یہ نقل کے لیے ہے (اس پوائنٹر کے بغیر ہم اگلے مرحلے میں اصول میں VIP شامل نہیں کر سکیں گے)۔
VIP کا اسی ذیلی نیٹ میں ہونا چاہیے جس میں IP پورٹس کے درمیان یہ تیرتا ہے۔
ہم ان ترتیبات کو ریموٹ اسٹوریج سسٹم پر دہراتے ہیں، یقیناً ایک مختلف IP کے ساتھ۔
مختلف سٹوریج سسٹمز کے VIPs مختلف سب نیٹس میں ہو سکتے ہیں، اہم بات یہ ہے کہ ان کے درمیان روٹنگ ہوتی ہے۔ ہمارے معاملے میں، یہ مثال بالکل دکھائی گئی ہے (192.168.3.XX اور 192.168.2.XX)
یہ نیٹ ورک کے حصے کی تیاری کو مکمل کرتا ہے۔
اسٹوریج ترتیب دے رہا ہے۔
نقل کے لیے سٹوریج ترتیب دینا معمول سے صرف اس میں مختلف ہوتا ہے کہ ہم ایک خاص مینو "ریپلیکیشن میپنگ" کے ذریعے میپنگ کرتے ہیں۔ ورنہ سب کچھ ویسا ہی ہے جیسا کہ عام سیٹ اپ کے ساتھ ہوتا ہے۔ اب، ترتیب میں.
پہلے بنائے گئے پول R02 میں، آپ کو ایک LUN بنانے کی ضرورت ہے۔ آئیے اسے بنائیں اور اسے LUN1 کہتے ہیں۔
ہمیں ایک جیسے سائز کے ریموٹ اسٹوریج سسٹم پر ایک ہی LUN بنانے کی بھی ضرورت ہے۔ ہم تخلیق کرتے ہیں۔ الجھن سے بچنے کے لیے، آئیے ریموٹ LUN LUN1R کو کال کریں۔
اگر ہمیں ایک LUN لینے کی ضرورت ہے جو پہلے سے موجود ہے، تو نقل ترتیب دیتے وقت، ہمیں میزبان سے اس پیداواری LUN کو ان ماؤنٹ کرنا ہوگا، اور ریموٹ اسٹوریج سسٹم پر ایک جیسی سائز کا خالی LUN بنانا ہوگا۔
سٹوریج سیٹ اپ مکمل ہو گیا ہے، آئیے نقل کرنے کا اصول بنانے کی طرف بڑھتے ہیں۔
نقل کے قواعد یا نقل کے لنکس کو ترتیب دینا
اسٹوریج سسٹم پر LUNs بنانے کے بعد، جو اس وقت بنیادی ہوگا، ہم اسٹوریج سسٹم 1 پر LUN1 سے LUN1R کو اسٹوریج سسٹم 2 پر کنفیگر کرتے ہیں۔
ترتیب "ریموٹ ریپلیکیشن" مینو میں بنائی گئی ہے۔
آئیے ایک اصول بنائیں۔ ایسا کرنے کے لیے، آپ کو نقل کے وصول کنندہ کی وضاحت کرنے کی ضرورت ہے۔ وہاں ہم نے کنکشن کا نام اور نقل کی قسم (مطابقت پذیر یا غیر مطابقت پذیر) بھی مقرر کی ہے۔
"ریموٹ سسٹمز" فیلڈ میں ہم اپنا اسٹوریج سسٹم 2 شامل کرتے ہیں۔ شامل کرنے کے لیے، آپ کو مینجمنٹ IP اسٹوریج سسٹمز (MGR) اور ریموٹ LUN کا نام استعمال کرنے کی ضرورت ہے جس میں ہم نقل تیار کریں گے (ہمارے معاملے میں، LUN1R)۔ کنٹرول آئی پی کی ضرورت صرف کنکشن جوڑنے کے مرحلے پر ہوتی ہے؛ نقل کی ٹریفک ان کے ذریعے منتقل نہیں کی جائے گی؛ اس کے لیے پہلے سے تشکیل شدہ VIP استعمال کیا جائے گا۔
پہلے سے ہی اس مرحلے پر ہم "ایک سے کئی" ٹوپولوجی کے لیے ایک سے زیادہ ریموٹ سسٹم شامل کر سکتے ہیں: "ایڈ نوڈ" بٹن پر کلک کریں، جیسا کہ نیچے دی گئی تصویر میں ہے۔
ہمارے معاملے میں، صرف ایک ریموٹ سسٹم ہے، لہذا ہم خود کو اس تک محدود رکھتے ہیں۔
قاعدہ تیار ہے۔ براہ کرم نوٹ کریں کہ یہ تمام نقل کے شرکاء پر خود بخود شامل ہوجاتا ہے (ہمارے معاملے میں ان میں سے دو ہیں)۔ آپ اپنی مرضی کے مطابق LUNs کی کسی بھی تعداد کے لیے اور کسی بھی سمت میں اس طرح کے اصول بنا سکتے ہیں۔ مثال کے طور پر، بوجھ کو متوازن کرنے کے لیے، ہم LUNs کے کچھ حصے کو اسٹوریج سسٹم 1 سے اسٹوریج سسٹم 2 تک اور دوسرے حصے کو، اس کے برعکس، اسٹوریج سسٹم 2 سے اسٹوریج سسٹم 1 تک نقل کر سکتے ہیں۔
اسٹوریج سسٹم 1۔ تخلیق کے فوراً بعد، ہم آہنگی شروع ہو گئی۔
اسٹوریج سسٹم 2۔ ہم ایک ہی اصول دیکھتے ہیں، لیکن مطابقت پذیری پہلے ہی ختم ہو چکی ہے۔
اسٹوریج سسٹم 1 پر LUN1 بنیادی کردار میں ہے، یعنی یہ فعال ہے۔ سٹوریج سسٹم 1 پر LUN2R سیکنڈری کے کردار میں ہے، یعنی اسٹوریج سسٹم 1 کے ناکام ہونے کی صورت میں یہ اسٹینڈ بائی پر ہے۔
اب ہم اپنے LUN کو میزبان سے جوڑ سکتے ہیں۔
ہم iSCSI کے ذریعے جڑیں گے، حالانکہ یہ FC کے ذریعے بھی کیا جا سکتا ہے۔ ایک نقل میں iSCSI LUN کے ذریعے نقشہ سازی کو ترتیب دینا عملی طور پر معمول کے منظر نامے سے مختلف نہیں ہے، اس لیے ہم یہاں اس پر تفصیل سے غور نہیں کریں گے۔ اگر کچھ بھی ہے تو، اس عمل کو مضمون میں بیان کیا گیا ہے "'.
فرق صرف یہ ہے کہ ہم نقشہ سازی کو "Replication Mapping" مینو میں بناتے ہیں۔
ہم نے میپنگ ترتیب دی اور LUN میزبان کو دے دیا۔ میزبان نے LUN دیکھا۔
ہم اسے مقامی فائل سسٹم میں فارمیٹ کرتے ہیں۔
بس، سیٹ اپ مکمل ہو گیا ہے۔ اگلے ٹیسٹ ہوں گے۔
ٹیسٹنگ
ہم تین اہم منظرناموں کی جانچ کریں گے۔
- ثانوی > پرائمری میں باقاعدہ رول سوئچنگ۔ اس صورت میں باقاعدہ رول سوئچنگ کی ضرورت ہوتی ہے، مثال کے طور پر، ہمیں مرکزی ڈیٹا سینٹر میں کچھ احتیاطی کارروائیاں کرنے کی ضرورت ہے اور اس دوران، ڈیٹا دستیاب ہونے کے لیے، ہم لوڈ کو بیک اپ ڈیٹا سینٹر میں منتقل کرتے ہیں۔
- ایمرجنسی رول سوئچنگ سیکنڈری > پرائمری (ڈیٹا سینٹر کی ناکامی)۔ یہ وہ اہم منظر نامہ ہے جس کے لیے نقل موجود ہے، جو کمپنی کو طویل مدت تک روکے بغیر ڈیٹا سینٹر کی مکمل ناکامی سے بچنے میں مدد کر سکتی ہے۔
- ڈیٹا سینٹرز کے درمیان مواصلاتی چینلز کی خرابی۔ دو سٹوریج سسٹمز کے درست رویے کی جانچ کرنا ان حالات میں جہاں کسی وجہ سے ڈیٹا سینٹرز کے درمیان کمیونیکیشن چینل دستیاب نہیں ہے (مثال کے طور پر، ایک کھدائی کرنے والے نے غلط جگہ کھودی اور تاریک آپٹکس کو توڑ دیا)۔
سب سے پہلے، ہم اپنے LUN پر ڈیٹا لکھنا شروع کریں گے (فائلوں کو بے ترتیب ڈیٹا کے ساتھ لکھنا)۔ ہم فوری طور پر دیکھتے ہیں کہ سٹوریج کے نظام کے درمیان مواصلاتی چینل کا استعمال کیا جا رہا ہے. یہ سمجھنا آسان ہے اگر آپ ان بندرگاہوں کی لوڈ مانیٹرنگ کو کھولتے ہیں جو نقل کے لیے ذمہ دار ہیں۔
دونوں اسٹوریج سسٹمز میں اب "مفید" ڈیٹا موجود ہے، ہم ٹیسٹ شروع کر سکتے ہیں۔
صرف اس صورت میں، آئیے کسی ایک فائل کے ہیش سمس کو دیکھیں اور انہیں لکھیں۔
باقاعدہ رول سوئچنگ
رولز کو تبدیل کرنے کا عمل (نقل کی سمت تبدیل کرنا) کسی بھی سٹوریج سسٹم کے ساتھ کیا جا سکتا ہے، لیکن آپ کو پھر بھی دونوں پر جانا پڑے گا، کیونکہ آپ کو پرائمری پر میپنگ کو غیر فعال کرنے کی ضرورت ہوگی، اور اسے سیکنڈری پر فعال کرنا ہو گا (جو پرائمری بن جائے گا۔ )۔
شاید اب ایک معقول سوال پیدا ہوتا ہے: اسے خودکار کیوں نہیں؟ جواب یہ ہے کہ: یہ آسان ہے، نقل تیار کرنا تباہی کی لچک کا ایک آسان ذریعہ ہے، جس کی بنیاد صرف دستی کارروائیوں پر ہے۔ ان آپریشنز کو خودکار کرنے کے لیے، ایک میٹرو کلسٹر موڈ ہے؛ یہ مکمل طور پر خودکار ہے، لیکن اس کی ترتیب بہت زیادہ پیچیدہ ہے۔ ہم اگلے مضمون میں میٹرو کلسٹر کے قیام کے بارے میں لکھیں گے۔
مرکزی اسٹوریج سسٹم پر، ہم اس بات کو یقینی بنانے کے لیے میپنگ کو غیر فعال کر دیتے ہیں کہ ریکارڈنگ رک جائے۔
پھر سٹوریج سسٹمز میں سے ایک پر (اس سے کوئی فرق نہیں پڑتا، مین یا بیک اپ پر) "ریموٹ ریپلیکشن" مینو میں، ہمارا کنکشن REPL1 منتخب کریں اور "رول تبدیل کریں" پر کلک کریں۔
چند سیکنڈ کے بعد، LUN1R (بیک اپ اسٹوریج سسٹم) پرائمری بن جاتا ہے۔
ہم اسٹوریج سسٹم1 کے ساتھ LUN2R کا نقشہ بناتے ہیں۔
اس کے بعد، ہماری E: ڈرائیو خود بخود میزبان کے ساتھ منسلک ہو جاتی ہے، صرف اس بار یہ LUN1R سے "پہنچی"۔
صرف اس صورت میں، ہم ہیش رقوم کا موازنہ کرتے ہیں۔
یکساں طور پر۔ ٹیسٹ پاس ہو گیا۔
فیل اوور ڈیٹا سینٹر کی ناکامی۔
اس وقت، ریگولر سوئچنگ کے بعد اہم اسٹوریج سسٹم بالترتیب اسٹوریج سسٹم 2 اور LUN1R ہے۔ کسی حادثے کی تقلید کرنے کے لیے، ہم دونوں سٹوریج کنٹرولرز2 پر پاور آف کر دیں گے۔
اس تک مزید رسائی نہیں ہے۔
آئیے دیکھتے ہیں کہ اسٹوریج سسٹم 1 پر کیا ہو رہا ہے (اس وقت بیک اپ والا)۔
ہم دیکھتے ہیں کہ بنیادی LUN (LUN1R) دستیاب نہیں ہے۔ نوشتہ جات میں، معلوماتی پینل میں، اور خود نقل کے اصول میں بھی ایک غلطی کا پیغام نمودار ہوا۔ اس کے مطابق، میزبان سے ڈیٹا فی الحال دستیاب نہیں ہے۔
LUN1 کے کردار کو پرائمری میں تبدیل کریں۔
میں میزبان سے نقشہ سازی کر رہا ہوں۔
یقینی بنائیں کہ ڈرائیو E میزبان پر ظاہر ہوتی ہے۔
ہم ہیش چیک کرتے ہیں۔
سب کچھ ٹھیک ہے. اسٹوریج سسٹم ڈیٹا سینٹر کے گرنے سے کامیابی سے بچ گیا، جو فعال تھا۔ ہم نے نقل "ریورسل" کو جوڑنے اور بیک اپ ڈیٹا سینٹر سے LUN کو جوڑنے میں جو وقت گزارا وہ تقریباً 3 منٹ تھا۔ یہ واضح ہے کہ حقیقی پیداوار میں سب کچھ بہت زیادہ پیچیدہ ہے، اور سٹوریج کے نظام کے ساتھ کارروائیوں کے علاوہ، آپ کو نیٹ ورک پر، میزبانوں پر، ایپلی کیشنز میں بہت سے آپریشن کرنے کی ضرورت ہے. اور زندگی میں یہ مدت بہت طویل ہو گی۔
یہاں میں یہ لکھنا چاہوں گا کہ سب کچھ، ٹیسٹ کامیابی سے مکمل ہو گیا ہے، لیکن آئیے جلدی نہ کریں۔ مرکزی اسٹوریج سسٹم "جھوٹ بول رہا ہے"، ہم جانتے ہیں کہ جب یہ "گرا"، یہ بنیادی کردار میں تھا۔ اگر یہ اچانک آن ہو جائے تو کیا ہوگا؟ دو بنیادی کردار ہوں گے، جو ڈیٹا کرپشن کے برابر ہے؟ آئیے اب اسے چیک کرتے ہیں۔
آئیے اچانک بنیادی اسٹوریج سسٹم کو آن کریں۔
یہ چند منٹوں کے لیے لوڈ ہوتا ہے اور پھر مختصر ہم آہنگی کے بعد سروس پر واپس آجاتا ہے، لیکن سیکنڈری کے کردار میں۔
سب ٹھیک. سپلٹ برین نہیں ہوا۔ ہم نے اس کے بارے میں سوچا، اور ہمیشہ زوال کے بعد سٹوریج کا نظام ثانوی کے کردار کی طرف بڑھتا ہے، اس سے قطع نظر کہ یہ "زندگی کے دوران" میں کیا کردار تھا۔ اب ہم یقین سے کہہ سکتے ہیں کہ ڈیٹا سینٹر فیل ہونے کا ٹیسٹ کامیاب رہا۔
ڈیٹا سینٹرز کے درمیان مواصلاتی چینلز کی ناکامی۔
اس ٹیسٹ کا بنیادی کام اس بات کو یقینی بنانا ہے کہ اسٹوریج سسٹم عجیب کام کرنا شروع نہیں کرتا ہے اگر یہ عارضی طور پر دو اسٹوریج سسٹم کے درمیان مواصلاتی چینلز کھو دیتا ہے اور پھر دوبارہ ظاہر ہوتا ہے۔
تو ہم تاروں کو اسٹوریج سسٹم کے درمیان منقطع کرتے ہیں (آئیے تصور کریں کہ انہیں ایک کھدائی کرنے والے نے کھودیا تھا)۔
پرائمری پر ہم دیکھتے ہیں کہ سیکنڈری سے کوئی تعلق نہیں ہے۔
سیکنڈری پر ہم دیکھتے ہیں کہ پرائمری سے کوئی تعلق نہیں ہے۔
سب کچھ ٹھیک کام کرتا ہے، اور ہم مرکزی اسٹوریج سسٹم میں ڈیٹا لکھنا جاری رکھتے ہیں، یعنی ان کے بیک اپ والے سے مختلف ہونے کی ضمانت دی جاتی ہے، یعنی وہ "علیحدہ" ہو چکے ہیں۔
چند منٹوں میں ہم مواصلاتی چینل کی "مرمت" کرتے ہیں۔ جیسے ہی اسٹوریج سسٹم ایک دوسرے کو دیکھتے ہیں، ڈیٹا کی مطابقت پذیری خود بخود چالو ہوجاتی ہے۔ یہاں منتظم سے کسی چیز کی ضرورت نہیں ہے۔
کچھ وقت کے بعد، مطابقت پذیری مکمل ہو جاتی ہے.
کنکشن بحال ہو گیا، کمیونیکیشن چینلز کے ٹوٹنے سے کوئی ہنگامی صورتحال پیدا نہیں ہوئی، اور سوئچ آن کرنے کے بعد، ہم آہنگی خود بخود ہو گئی۔
نتائج
ہم نے نظریہ کا تجزیہ کیا - کس چیز کی ضرورت ہے اور کیوں، کہاں کے فائدے ہیں اور کہاں نقصانات ہیں۔ پھر ہم دو سٹوریج سسٹمز کے درمیان ہم وقت ساز نقل ترتیب دیتے ہیں۔
اس کے بعد، نارمل سوئچنگ، ڈیٹا سینٹر کی ناکامی اور کمیونیکیشن چینل کی ناکامی کے لیے بنیادی ٹیسٹ کیے گئے۔ تمام معاملات میں، سٹوریج کے نظام نے اچھی طرح سے کام کیا. کوئی ڈیٹا ضائع نہیں ہوتا ہے اور انتظامی کارروائیوں کو دستی منظر نامے کے لیے کم سے کم رکھا جاتا ہے۔
اگلی بار ہم صورت حال کو پیچیدہ کریں گے اور دکھائیں گے کہ یہ تمام منطق کس طرح ایک آٹومیٹڈ میٹرو کلسٹر میں ایکٹیو ایکٹیو موڈ میں کام کرتی ہے، یعنی جب دونوں سٹوریج سسٹم پرائمری ہوتے ہیں، اور سٹوریج سسٹم کی ناکامی کی صورت میں رویہ مکمل طور پر خودکار ہوتا ہے۔
براہ کرم تبصرے لکھیں، ہمیں اچھی تنقید اور عملی مشورے ملنے پر خوشی ہوگی۔
اگلے وقت تک.
ماخذ: www.habr.com