ڈیزاسٹر ریسیلینٹ کلاؤڈ: یہ کیسے کام کرتا ہے۔

ارے حبر!

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

OST سائٹ پر آفات سے بچنے والا کلاؤڈ اسٹوریج سسٹم۔

اندر کیا ہے؟

ہڈ کے نیچے، کلسٹر میں VMware ESXi ہائپر وائزر کے ساتھ Cisco UCS سرورز، دو INFINIDAT InfiniBox F2240 اسٹوریج سسٹم، Cisco Nexus نیٹ ورک کا سامان، نیز Brocade SAN سوئچز ہیں۔ کلسٹر کو دو سائٹس میں تقسیم کیا گیا ہے - OST اور NORD، یعنی ہر ڈیٹا سینٹر میں آلات کا ایک جیسا سیٹ ہوتا ہے۔ درحقیقت، یہی چیز اسے تباہی کے خلاف مزاحم بناتی ہے۔

ایک سائٹ کے اندر، اہم عناصر کو بھی نقل کیا جاتا ہے (میزبان، SAN سوئچز، نیٹ ورکنگ)۔
دونوں سائٹیں مخصوص فائبر آپٹک راستوں سے منسلک ہیں، جو بھی محفوظ ہیں۔

اسٹوریج سسٹم کے بارے میں چند الفاظ۔ ہم نے NetApp پر ڈیزاسٹر پروف کلاؤڈ کا پہلا ورژن بنایا ہے۔ یہاں ہم نے INFINIDAT کا انتخاب کیا، اور اس کی وجہ یہ ہے:

• فعال-فعال نقل کا اختیار۔ یہ ورچوئل مشین کو کام کرنے کی اجازت دیتا ہے یہاں تک کہ اگر اسٹوریج سسٹم میں سے کوئی ایک مکمل طور پر ناکام ہو جائے۔ نقل کے بارے میں میں آپ کو بعد میں بتاؤں گا۔
• سسٹم کی خرابی کی رواداری کو بڑھانے کے لیے تین ڈسک کنٹرولرز۔ عام طور پر دو ہوتے ہیں۔
• تیار حل۔ ہمیں ایک پہلے سے جمع شدہ ریک موصول ہوا جسے صرف نیٹ ورک سے منسلک کرنے اور ترتیب دینے کی ضرورت ہے۔
• توجہ تکنیکی مدد. INFINIDAT انجینئرز اسٹوریج سسٹم لاگز اور ایونٹس کا مسلسل تجزیہ کرتے ہیں، نئے فرم ویئر ورژن انسٹال کرتے ہیں، اور کنفیگریشن میں مدد کرتے ہیں۔

پیک کھولنے سے کچھ تصاویر یہ ہیں:

یہ کیسے کام کرتا ہے

بادل پہلے ہی اپنے اندر غلطی برداشت کرنے والا ہے۔ یہ کلائنٹ کو سنگل ہارڈ ویئر اور سافٹ ویئر کی ناکامیوں سے بچاتا ہے۔ ڈیزاسٹر ریزسٹنٹ ایک سائٹ کے اندر بڑے پیمانے پر ہونے والی ناکامیوں سے بچانے میں مدد کرے گا: مثال کے طور پر، سٹوریج سسٹم کی ناکامی (یا ایس ڈی ایس کلسٹر، جو اکثر ہوتا ہے 🙂)، اسٹوریج نیٹ ورک میں بڑی خرابیاں وغیرہ۔ ٹھیک ہے، اور سب سے اہم بات: اس طرح کا بادل اس وقت بچاتا ہے جب آگ، بلیک آؤٹ، حملہ آوروں کے قبضے، یا اجنبی لینڈنگ کی وجہ سے پوری سائٹ ناقابل رسائی ہو جاتی ہے۔

ان تمام معاملات میں، کلائنٹ کی ورچوئل مشینیں کام کرتی رہتی ہیں، اور اس کی وجہ یہ ہے۔

کلسٹر ڈیزائن اس طرح ڈیزائن کیا گیا ہے کہ کلائنٹ ورچوئل مشینوں کے ساتھ کوئی بھی ESXi میزبان دو اسٹوریج سسٹمز میں سے کسی تک رسائی حاصل کر سکے۔ اگر OST سائٹ پر اسٹوریج سسٹم ناکام ہوجاتا ہے تو، ورچوئل مشینیں کام کرتی رہیں گی: وہ میزبان جن پر وہ چل رہے ہیں ڈیٹا کے لیے NORD پر اسٹوریج سسٹم تک رسائی حاصل کریں گے۔

یہ ایک کلسٹر میں کنکشن ڈایاگرام کی طرح لگتا ہے.

یہ اس حقیقت کی وجہ سے ممکن ہے کہ ایک انٹر-سوئچ لنک کو دو سائٹس کے SAN فیبرکس کے درمیان کنفیگر کیا گیا ہے: Fabric A OST SAN سوئچ Fabric A NORD SAN سوئچ سے جڑا ہوا ہے، اور اسی طرح Fabric B SAN سوئچز کے لیے۔

ٹھیک ہے، تاکہ SAN فیکٹریوں کی یہ تمام پیچیدگیاں سمجھ میں آئیں، Active-Active نقل کو دو سٹوریج سسٹمز کے درمیان ترتیب دیا گیا ہے: معلومات تقریباً بیک وقت مقامی اور ریموٹ اسٹوریج سسٹمز پر لکھی جاتی ہیں، RPO = 0۔ یہ پتہ چلتا ہے کہ اصل ڈیٹا ایک سٹوریج سسٹم میں محفوظ ہے، اور اس کی نقل دوسرے پر ذخیرہ کیا جاتا ہے. ڈیٹا کو سٹوریج والیوم کی سطح پر نقل کیا جاتا ہے، اور VM ڈیٹا (اس کی ڈسکیں، کنفیگریشن فائل، سویپ فائل وغیرہ) ان پر محفوظ ہوتا ہے۔

ESXi میزبان بنیادی حجم اور اس کی نقل کو ایک ڈسک ڈیوائس (اسٹوریج ڈیوائس) کے طور پر دیکھتا ہے۔ ESXi میزبان سے ہر ڈسک ڈیوائس تک 24 راستے ہیں:

12 راستے اسے مقامی اسٹوریج سسٹم (بہترین راستے) سے جوڑتے ہیں، اور بقیہ 12 ریموٹ اسٹوریج سسٹم (غیر بہترین راستے) سے۔ عام صورت حال میں، ESXi "بہترین" راستوں کا استعمال کرتے ہوئے مقامی اسٹوریج سسٹم پر ڈیٹا تک رسائی حاصل کرتا ہے۔ جب یہ سٹوریج سسٹم ناکام ہو جاتا ہے، ESXi بہترین راستے کھو دیتا ہے اور "غیر بہترین" پر سوئچ کر دیتا ہے۔ یہ وہی ہے جو خاکہ پر نظر آتا ہے۔

ڈیزاسٹر پروف کلسٹر کی اسکیم۔

تمام کلائنٹ نیٹ ورک ایک مشترکہ نیٹ ورک فیبرک کے ذریعے دونوں سائٹس سے جڑے ہوئے ہیں۔ ہر سائٹ ایک Provider Edge (PE) چلاتی ہے، جس پر کلائنٹ کے نیٹ ورکس کو ختم کر دیا جاتا ہے۔ PEs ایک مشترکہ کلسٹر میں متحد ہیں۔ اگر ایک سائٹ پر PE ناکام ہوجاتا ہے، تو تمام ٹریفک کو دوسری سائٹ پر بھیج دیا جاتا ہے۔ اس کی بدولت، PE کے بغیر چھوڑی گئی سائٹ کی ورچوئل مشینیں کلائنٹ کے لیے نیٹ ورک پر قابل رسائی رہتی ہیں۔

آئیے اب دیکھتے ہیں کہ مختلف ناکامیوں کے دوران کلائنٹ ورچوئل مشینوں کا کیا ہوگا۔ آئیے سب سے ہلکے اختیارات کے ساتھ شروع کریں اور سب سے زیادہ سنگین - پوری سائٹ کی ناکامی کے ساتھ ختم کریں۔ مثالوں میں، مرکزی پلیٹ فارم OST ہو گا، اور بیک اپ پلیٹ فارم، ڈیٹا کی نقلوں کے ساتھ، NORD ہو گا۔

کلائنٹ کی ورچوئل مشین کا کیا ہوتا ہے اگر...

نقل کا لنک ناکام ہو جاتا ہے۔ دو سائٹس کے اسٹوریج سسٹم کے درمیان نقل رک جاتی ہے۔
ESXi صرف مقامی ڈسک ڈیوائسز کے ساتھ کام کرے گا (بہترین راستوں کے ذریعے)۔
ورچوئل مشینیں کام کرتی رہتی ہیں۔

آئی ایس ایل (انٹر سوئچ لنک) ٹوٹ جاتا ہے۔ کیس کا امکان نہیں ہے۔ جب تک کہ کوئی پاگل کھدائی کرنے والا ایک ساتھ کئی آپٹیکل راستے کھودتا ہے، جو آزاد راستوں پر چلتے ہیں اور مختلف ان پٹ کے ذریعے سائٹس تک لائے جاتے ہیں۔ لیکن ویسے بھی. اس صورت میں، ESXi میزبان آدھے راستے کھو دیتے ہیں اور صرف اپنے مقامی اسٹوریج سسٹم تک رسائی حاصل کر سکتے ہیں۔ نقلیں جمع کی جاتی ہیں، لیکن میزبان ان تک رسائی حاصل نہیں کر سکیں گے۔

ورچوئل مشینیں معمول کے مطابق کام کر رہی ہیں۔

SAN سوئچ سائٹس میں سے ایک پر ناکام ہوجاتا ہے۔ ESXi میزبان اسٹوریج سسٹم کے کچھ راستے کھو دیتے ہیں۔ اس صورت میں، اس سائٹ پر میزبان جہاں سوئچ ناکام ہوا ہے صرف اپنے HBAs میں سے ایک کے ذریعے کام کریں گے۔

ورچوئل مشینیں معمول کے مطابق کام کرتی رہیں۔

سائٹس میں سے ایک پر تمام SAN سوئچ ناکام ہو جاتے ہیں۔ مان لیں کہ او ایس ٹی سائٹ پر ایسی تباہی ہوئی ہے۔ اس صورت میں، اس سائٹ پر موجود ESXi میزبان اپنے ڈسک ڈیوائسز کے تمام راستے کھو دیں گے۔ معیاری VMware vSphere HA میکانزم کام میں آتا ہے: یہ NORD میں OST سائٹ کی تمام ورچوئل مشینوں کو زیادہ سے زیادہ 140 سیکنڈ میں دوبارہ شروع کر دے گا۔

NORD سائٹ کے میزبانوں پر چلنے والی ورچوئل مشینیں معمول کے مطابق کام کر رہی ہیں۔

ESXi میزبان ایک سائٹ پر ناکام ہو جاتا ہے۔ یہاں vSphere HA میکانزم دوبارہ کام کرتا ہے: ناکام ہوسٹ کی ورچوئل مشینیں دوسرے میزبانوں پر دوبارہ شروع ہوتی ہیں - اسی یا ریموٹ سائٹ پر۔ ورچوئل مشین کے دوبارہ شروع ہونے کا وقت 1 منٹ تک ہے۔

اگر OST سائٹ پر تمام ESXi میزبان ناکام ہو جاتے ہیں، تو کوئی آپشن نہیں ہے: VMs کو کسی اور پر دوبارہ شروع کیا جاتا ہے۔ دوبارہ شروع کرنے کا وقت ایک ہی ہے۔

اسٹوریج سسٹم ایک سائٹ پر ناکام ہو جاتا ہے۔ فرض کریں کہ اسٹوریج سسٹم OST سائٹ پر ناکام ہو جاتا ہے۔ پھر OST سائٹ کے ESXi میزبان NORD میں سٹوریج کی نقلوں کے ساتھ کام کرنے کے لیے سوئچ کرتے ہیں۔ ناکام سٹوریج سسٹم کے سروس پر واپس آنے کے بعد، جبری نقل تیار کی جائے گی اور ESXi OST میزبان دوبارہ مقامی اسٹوریج سسٹم تک رسائی شروع کر دیں گے۔

ورچوئل مشینیں اس سارے عرصے میں عام طور پر کام کر رہی ہیں۔

سائٹس میں سے ایک ناکام ہو جاتی ہے۔ اس صورت میں، تمام ورچوئل مشینیں بیک اپ سائٹ پر vSphere HA میکانزم کے ذریعے دوبارہ شروع کی جائیں گی۔ VM دوبارہ شروع کرنے کا وقت 140 سیکنڈ ہے۔ اس صورت میں، ورچوئل مشین کی تمام نیٹ ورک سیٹنگز محفوظ ہو جائیں گی، اور یہ نیٹ ورک پر کلائنٹ کے لیے قابل رسائی رہے گی۔

اس بات کو یقینی بنانے کے لیے کہ بیک اپ سائٹ پر مشینوں کا دوبارہ آغاز آسانی سے ہو، ہر سائٹ صرف آدھی بھری ہوئی ہے۔ دوسرا نصف ایک ریزرو ہے اگر تمام ورچوئل مشینیں دوسری، تباہ شدہ سائٹ سے منتقل ہو جائیں۔

دو ڈیٹا سینٹرز پر مبنی ڈیزاسٹر ریزسٹنٹ کلاؤڈ ایسی ناکامیوں سے بچاتا ہے۔

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

ذرائع کے مطابق:

1. www.infinidat.com/sites/default/files/resource-pdfs/DS-INFBOX-190331-US_0.pdf
2. support.infinidat.com/hc/en-us/articles/207057109-InfiniBox-best-practices-guides

ماخذ: www.habr.com