ڈیزاسٹر ریکوری سلوشنز مارکیٹ میں نوجوان کھلاڑیوں میں سے ایک Hystax ہے، جو 2016 میں ایک روسی اسٹارٹ اپ ہے۔ چونکہ ڈیزاسٹر ریکوری کا موضوع بہت مشہور ہے اور مارکیٹ انتہائی مسابقتی ہے، اس لیے اسٹارٹ اپ نے مختلف کلاؤڈ انفراسٹرکچر کے درمیان منتقلی پر توجہ مرکوز کرنے کا فیصلہ کیا۔ ایک پروڈکٹ جو آپ کو کلاؤڈ پر ایک سادہ اور فوری منتقلی کو منظم کرنے کی اجازت دیتا ہے اونلانٹا کے صارفین کے لیے بہت مفید ہو گا - صارفین . اس طرح میں نے Hystax کو جان لیا اور اس کی خصوصیات کو جانچنا شروع کیا۔ اور اس سے کیا نکلا، میں اس مضمون میں بتاؤں گا۔
Hystax کی اہم خصوصیت مختلف ورچوئلائزیشن پلیٹ فارمز، گیسٹ OS اور کلاؤڈ سروسز کو سپورٹ کرنے کے لیے اس کی وسیع فعالیت ہے، جو آپ کے کام کے بوجھ کو کہیں سے بھی اور کہیں سے بھی منتقل کرنا ممکن بناتی ہے۔
یہ آپ کو خدمات کی خرابی برداشت کو بہتر بنانے کے لیے نہ صرف DR حل تخلیق کرنے کی اجازت دیتا ہے، بلکہ لاگت کی بچت کو بڑھانے کے لیے مختلف سائٹس اور ہائپر اسکیلرز کے درمیان وسائل کو تیزی سے، لچکدار طریقے سے منتقل کرنے اور اس وقت کسی خاص سروس کے لیے بہترین حل کا انتخاب کرنے کی اجازت دیتا ہے۔ عنوان کی تصویر میں درج پلیٹ فارمز کے علاوہ، کمپنی روسی کلاؤڈ فراہم کنندگان کے ساتھ بھی فعال طور پر تعاون کرتی ہے: Yandex.Cloud، CROC Cloud Services، Mail.ru اور بہت سے دوسرے۔ یہ بات بھی قابل غور ہے کہ 2020 میں کمپنی نے Skolkovo میں ایک R&D سنٹر کھولا۔
مارکیٹ میں کھلاڑیوں کی ایک بڑی تعداد کے ذریعہ ایک حل کا انتخاب ایک اچھی قیمتوں کی پالیسی اور مصنوعات کی اعلی قابل اطلاقیت کی نشاندہی کرتا ہے، جسے ہم نے عملی طور پر جانچنے کا فیصلہ کیا ہے۔
لہذا، ہمارا ٹیسٹ ٹاسک میری VMware ٹیسٹ سائٹ اور جسمانی مشینوں سے VMware چلانے والے فراہم کنندہ کی سائٹ پر منتقل ہونے پر مشتمل ہوگا۔ ہاں، ایسے بہت سے حل ہیں جو اس طرح کی ہجرت کو لاگو کر سکتے ہیں، لیکن ہم Hystax کو ایک عالمگیر ٹول کے طور پر سمجھتے ہیں، اور تمام ممکنہ مجموعوں میں منتقلی کی جانچ کرنا محض ایک غیر حقیقی کام ہے۔ جی ہاں، اور Oncloud.ru کلاؤڈ خاص طور پر VMware پر بنایا گیا ہے، اس لیے یہ پلیٹ فارم، ایک ہدف کے طور پر، ہماری دلچسپی زیادہ حد تک رکھتا ہے۔ اگلا، میں آپریشن کے بنیادی اصول کی وضاحت کروں گا، جو مجموعی طور پر پلیٹ فارم پر منحصر نہیں ہے، اور VMware کو کسی بھی طرف سے کسی دوسرے وینڈر کے پلیٹ فارم سے تبدیل کیا جا سکتا ہے۔
پہلا قدم Hystax Acura کو تعینات کرنا ہے، جو سسٹم کا کنٹرول پینل ہے۔
یہ ٹیمپلیٹ سے پھیلتا ہے۔ کسی وجہ سے، ہمارے معاملے میں، یہ مکمل طور پر درست نہیں تھا اور تجویز کردہ 8CPU کے بجائے، 16Gb کو نصف وسائل کے ساتھ تعینات کیا گیا تھا۔ لہذا، آپ کو ان کو تبدیل کرنا یاد رکھنا ہوگا، ورنہ VM کے اندر کا انفراسٹرکچر، جس پر سب کچھ بنایا گیا ہے، صرف کنٹینرز سے شروع نہیں ہوگا اور پورٹل دستیاب نہیں ہوگا۔ میں مطلوبہ وسائل کو تفصیل سے بیان کیا گیا ہے، نیز سسٹم کے تمام اجزاء کے لیے بندرگاہیں بھی۔
اور ٹیمپلیٹ کے ذریعے آئی پی ایڈریس سیٹ کرنے میں بھی مشکلات تھیں، اس لیے ہم نے اسے کنسول سے تبدیل کر دیا۔ اس کے بعد، آپ ایڈمن ویب انٹرفیس پر جا کر ابتدائی کنفیگریشن وزرڈ کو مکمل کر سکتے ہیں۔
اختتامی نقطہ - ہمارے vCenter کا IP یا FQDN۔
لاگ ان اور پاس ورڈ - یہ یہاں واضح ہے۔
ٹارگٹ ESXi ہوسٹ نام ہمارے کلسٹر میں ان میزبانوں میں سے ایک ہے جس کی نقل تیار کی جائے گی۔
ٹارگٹ ڈیٹا اسٹور ہمارے کلسٹر میں موجود ڈیٹا اسٹورز میں سے ایک ہے جس کی نقل تیار کی جائے گی۔
Hystax Acura Control Panel Public IP - وہ پتہ جہاں کنٹرول پینل دستیاب ہوگا۔
میزبان اور ڈیٹا اسٹور پر تھوڑی سی وضاحت درکار ہے۔ حقیقت یہ ہے کہ Hystax کی نقل میزبان اور ڈیٹا اسٹور کی سطح پر کام کرتی ہے۔ اگلا، میں آپ کو بتاؤں گا کہ آپ کرایہ دار کے لیے میزبان اور ڈیٹا اسٹور کیسے تبدیل کر سکتے ہیں، لیکن مسئلہ مختلف ہے۔ Hystax وسائل جمع کرنے کی حمایت نہیں کرتا، یعنی نقل ہمیشہ کلسٹر کی جڑ سے ہوتی ہے (اس مواد کو لکھنے کے وقت، Hystax کے لڑکوں نے ایک تازہ ترین ورژن جاری کیا، جہاں انہوں نے وسائل کے تالابوں کے لیے سپورٹ کے حوالے سے میری فیچر کی درخواست کو تیزی سے نافذ کیا)۔ نیز وی کلاؤڈ ڈائریکٹر تعاون یافتہ نہیں ہے، یعنی۔ اگر، جیسا کہ میرے معاملے میں، کرایہ دار کے پاس پورے کلسٹر کے منتظم کے حقوق نہیں ہیں، بلکہ صرف ایک مخصوص وسائل کے پول تک، اور ہم نے Hystax تک رسائی دی ہے، تو وہ آزادانہ طور پر ان VMs کو نقل کرنے اور چلانے کے قابل ہو جائے گا، لیکن وہ انہیں VMware کے بنیادی ڈھانچے میں دیکھنے کے قابل نہیں ہے، جس تک اسے رسائی حاصل ہے اور اس کے مطابق، ورچوئل مشینوں کا مزید انتظام کرتا ہے۔ کلسٹر ایڈمنسٹریٹر کو VM کو صحیح وسائل کے پول میں منتقل کرنے یا اسے vCloud ڈائریکٹر میں درآمد کرنے کی ضرورت ہے۔
میں ان لمحات پر اتنی توجہ کیوں دیتا ہوں؟ کیونکہ، جہاں تک میں پروڈکٹ کے تصور کو سمجھتا ہوں، صارف کو Acura پینل کا استعمال کرتے ہوئے آزادانہ طور پر کسی بھی منتقلی یا DR کو لاگو کرنے کے قابل ہونا چاہیے۔ لیکن اب تک، VMware سپورٹ اسی OpenStack کے لیے سپورٹ کی سطح سے قدرے پیچھے ہے، جہاں اس طرح کے میکانزم پہلے ہی لاگو کیے جا چکے ہیں۔
لیکن واپس تعیناتی پر۔ سب سے پہلے، پینل کے ابتدائی سیٹ اپ کے بعد، ہمیں اپنے سسٹم میں پہلا کرایہ دار بنانے کی ضرورت ہے۔
یہاں تمام فیلڈز واضح ہیں، میں آپ کو صرف کلاؤڈ فیلڈ کے بارے میں بتاؤں گا۔ ہمارے پاس پہلے سے ہی ایک "ڈیفالٹ" کلاؤڈ ہے جسے ہم نے ابتدائی ترتیب کے دوران بنایا تھا۔ لیکن اگر ہم چاہتے ہیں کہ ہر کرایہ دار کو اس کے اپنے ڈیٹا اسٹور پر اور اس کے اپنے وسائل کے پول میں رکھا جائے، تو ہم اپنے ہر صارف کے لیے علیحدہ بادل بنا کر اسے نافذ کر سکتے ہیں۔
ایک نئے کلاؤڈ کو شامل کرنے کی صورت میں، ہم ابتدائی کنفیگریشن کے دوران وہی پیرامیٹرز بیان کرتے ہیں (ہم ایک ہی میزبان کو بھی استعمال کر سکتے ہیں)، کسی خاص صارف کے لیے درکار ڈیٹا اسٹور کی وضاحت کرتے ہیں، اور اب اضافی پیرامیٹرز میں ہم پہلے ہی انفرادی طور پر مخصوص کر سکتے ہیں۔ پول وسائل کی ضرورت ہے {"resource_pool" :"YOUR_POOL_NAME"}
جیسا کہ آپ نے دیکھا ہوگا، کرایہ دار بنانے کی صورت میں وسائل کی تقسیم یا کسی قسم کے کوٹے کے بارے میں کچھ نہیں ہوتا ہے - سسٹم میں ایسا کچھ بھی نہیں ہے۔ آپ کرایہ دار کو بیک وقت نقل کی تعداد، نقل کے لیے مشینوں کی تعداد، یا کسی دوسرے پیرامیٹرز کے ذریعے محدود نہیں کر سکتے۔ لہذا، ہم نے پہلا کرایہ دار بنایا ہے۔ اب ایک مکمل طور پر منطقی نہیں، لیکن لازمی چیز ہے - کلاؤڈ ایجنٹ کو انسٹال کرنا۔ یہ غیر منطقی ہے، کیونکہ ایجنٹ کو کسی مخصوص صارف کے صفحہ پر ڈاؤن لوڈ کیا جاتا ہے۔
ایک ہی وقت میں، یہ تخلیق شدہ کرایہ دار سے منسلک نہیں ہے، اور ہمارے تمام صارفین اس کے ذریعے کام کریں گے (یا کئی کے بعد، اگر ہم انہیں تعینات کرتے ہیں)۔ ایک ایجنٹ بیک وقت 10 سیشنوں کی حمایت کرتا ہے۔ ایک سیشن ایک کار کے طور پر شمار ہوتا ہے۔ اس سے کوئی فرق نہیں پڑتا کہ اس میں کتنی ڈسکیں ہیں۔ آج تک، VMware کے لیے Acura میں ہی اسکیلنگ ایجنٹس کا کوئی طریقہ کار موجود نہیں ہے۔ ایک اور ناخوشگوار لمحہ ہے - ہم Acura پینل سے اس ایجنٹ کے "استعمال" کو دیکھنے کے قابل نہیں ہیں تاکہ یہ نتیجہ اخذ کریں کہ آیا ہمیں مزید تعینات کرنے کی ضرورت ہے یا موجودہ تنصیب کافی ہے۔ نتیجے کے طور پر، اسٹینڈ اس طرح لگتا ہے:
ہمارے گاہک کے پورٹل تک رسائی حاصل کرنے کا اگلا مرحلہ ایک اکاؤنٹ بنانا ہے (اور پہلے، ایک کردار بھی جو اس صارف پر لاگو کیا جائے گا)۔
اب ہمارا صارف پورٹل کو آزادانہ طور پر استعمال کر سکتا ہے۔ اسے صرف پورٹل سے ایجنٹوں کو ڈاؤن لوڈ کرنے اور اپنی طرف انسٹال کرنے کی ضرورت ہے۔ ایجنٹوں کی تین اقسام ہیں: لینکس، ونڈوز اور وی ایم ویئر۔
پہلے دو فزکس پر یا کسی بھی غیر VMware ہائپر وائزر پر ورچوئل مشینوں پر رکھے جاتے ہیں۔ یہاں کسی اضافی کنفیگریشن کی ضرورت نہیں ہے، ایجنٹ ڈاؤن لوڈ کرتا ہے اور پہلے ہی جانتا ہے کہ کہاں دستک دینا ہے، اور لفظی طور پر ایک منٹ میں کار Acura پینل میں نظر آئے گی۔ VMware ایجنٹ کے ساتھ، صورت حال تھوڑی زیادہ پیچیدہ ہے. مسئلہ یہ ہے کہ VMware کے لیے ایجنٹ بھی پہلے سے تیار اور ضروری کنفیگریشن کے حامل پورٹل سے ڈاؤن لوڈ کیا جاتا ہے۔ لیکن VMware ایجنٹ، ہمارے Acura پورٹل کے بارے میں جاننے کے علاوہ، ورچوئلائزیشن سسٹم کے بارے میں بھی جاننے کی ضرورت ہے جس پر اسے تعینات کیا جائے گا۔
دراصل، جب آپ پہلی بار VMware ایجنٹ ڈاؤن لوڈ کریں گے تو سسٹم ہم سے اس ڈیٹا کی وضاحت کرنے کو کہے گا۔ مسئلہ یہ ہے کہ سیکورٹی کے لیے ہمارے عالمگیر محبت کے دور میں، ہر کوئی اپنے ایڈمن پاس ورڈ کو کسی اور کے پورٹل پر ظاہر نہیں کرنا چاہے گا، جو کہ کافی سمجھ میں آتا ہے۔ اندر سے، تعیناتی کے بعد، ایجنٹ کو کسی بھی طرح سے کنفیگر نہیں کیا جا سکتا (آپ صرف اس کے نیٹ ورک کی ترتیبات کو تبدیل کر سکتے ہیں)۔ یہاں میں خاص طور پر محتاط صارفین کے ساتھ مشکلات کا اندازہ لگا رہا ہوں۔
لہذا، ایجنٹوں کو انسٹال کرنے کے بعد، ہم Acura پینل پر واپس جا سکتے ہیں اور اپنی تمام کاریں دیکھ سکتے ہیں۔
چونکہ میں ایک دن سے زیادہ عرصے سے سسٹم کے ساتھ کام کر رہا ہوں، اس لیے میرے پاس مختلف ریاستوں میں مشینیں ہیں۔ یہ سب پہلے سے طے شدہ گروپ میں ہیں، لیکن آپ کی ضرورت کے مطابق الگ الگ گروپ بنانا اور ان میں مشینیں منتقل کرنا ممکن ہے۔ اس سے کچھ بھی متاثر نہیں ہوتا ہے - صرف ڈیٹا کی منطقی نمائندگی اور زیادہ آسان کام کے لیے ان کی گروپ بندی۔ اس کے بعد سب سے پہلا اور سب سے اہم کام جو ہمیں کرنا ہے وہ ہے ہجرت کا عمل شروع کرنا۔ ہم یہ دونوں زبردستی دستی طور پر کر سکتے ہیں، اور ایک شیڈول ترتیب دے سکتے ہیں، بشمول تمام مشینوں کے لیے ایک ساتھ۔
میں آپ کو یاد دلاتا ہوں کہ Hystax کو منتقلی کے لیے ایک پروڈکٹ کے طور پر رکھا گیا تھا۔ لہذا، یہ حیرت کی بات نہیں ہے کہ ہماری نقل شدہ مشینوں کو چلانے کے لیے، ہمیں ایک DR پلان بنانے کی ضرورت ہے۔ آپ ان مشینوں کے لیے ایک منصوبہ بنا سکتے ہیں جو پہلے سے مطابقت پذیر حالت میں ہیں۔ آپ ایک مخصوص VM کے لیے اور ایک ساتھ تمام مشینوں کے لیے دونوں پیدا کر سکتے ہیں۔
DR پلان تیار کرتے وقت پیرامیٹرز کا سیٹ اس انفراسٹرکچر کے لحاظ سے مختلف ہوگا جس میں آپ ہجرت کر رہے ہیں۔ VMware ماحول کے لیے اختیارات کا ایک کم سے کم سیٹ دستیاب ہے۔ مشینوں کے لیے دوبارہ آئی پی بھی تعاون یافتہ نہیں ہے۔ اس سلسلے میں، ہم مندرجہ ذیل نکات میں دلچسپی رکھتے ہیں: VM کی تفصیل میں، "سب نیٹ" پیرامیٹر: "VMNetwork"، جہاں ہم VM کو کلسٹر میں ایک مخصوص نیٹ ورک سے منسلک کرتے ہیں۔ رینک - متعدد VMs کو منتقل کرتے وقت متعلقہ، اس ترتیب کا تعین کرتا ہے جس میں وہ لانچ کیے جاتے ہیں۔ ذائقہ VM کنفیگریشن کی وضاحت کرتا ہے، اس معاملے میں 1CPU، 2GB RAM۔ سب نیٹ سیکشن میں، ہم اس کی وضاحت کرتے ہیں کہ "سب نیٹ": "VMNetwork" VMware کے "VM نیٹ ورک" سے وابستہ ہے۔
DR پلان بناتے وقت، مختلف ڈیٹا اسٹورز میں ڈسکوں کو "تقسیم" کرنے کا کوئی طریقہ نہیں ہے۔ وہ اسی ڈیٹا اسٹور پر واقع ہوں گے جس کی تعریف اس کلائنٹ کلاؤڈ کے لیے کی گئی تھی، اور اگر آپ کے پاس مختلف کلاسز کی ڈسکیں ہیں، تو یہ مشین کو شروع کرتے وقت کچھ مشکلات کا باعث بن سکتی ہے، اور VM کو Hystax سے شروع کرنے اور "علیحدہ" کرنے کے بعد، یہ بھی مطلوبہ ڈیٹا اسٹورز کے لیے علیحدہ مائیگریشن ڈسک کی ضرورت ہے۔ پھر ہمیں صرف اپنا DR پلان چلانا ہے اور اپنی کاروں کے اٹھنے کا انتظار کرنا ہے۔ P2V/V2V تبدیلی کے عمل میں بھی وقت لگتا ہے۔ تین ڈسکوں والی میری سب سے بڑی 100GB ٹیسٹ مشین پر، اس میں زیادہ سے زیادہ 10 منٹ لگے۔
اس کے بعد، آپ کو چل رہا VM، اس پر خدمات، ڈیٹا کی مستقل مزاجی اور دیگر جانچ پڑتال کرنی چاہیے۔
پھر ہمارے پاس دو اختیارات ہیں:
- حذف کریں - چلتے ہوئے DR پلان کو حذف کریں۔ اس عمل سے چلنے والے VM کو آسانی سے بند کر دیا جائے گا۔ یہ نقلیں کہیں نہیں جا رہی ہیں۔
- الگ کریں - ایکورا سے نقل شدہ کار کو پھاڑ دیں، یعنی اصل میں منتقلی کے عمل کو مکمل کریں.
حل کے فوائد:
- کلائنٹ کی طرف اور فراہم کنندہ دونوں طرف تنصیب اور ترتیب میں آسانی؛
- ہجرت کو ترتیب دینے، DR پلان بنانے اور نقلیں شروع کرنے میں آسانی؛
- سپورٹ اور ڈویلپرز پائے جانے والے مسائل کا فوری جواب دیتے ہیں اور انہیں پلیٹ فارم یا ایجنٹ اپ ڈیٹس کے ساتھ حل کرتے ہیں۔
Cons
- ناکافی Vmware سپورٹ۔
- پلیٹ فارم سے کرایہ داروں کے لیے کسی کوٹہ کی عدم موجودگی۔
میں نے ایک خصوصیت کی درخواست بھی کی، جسے ہم نے وینڈر کے حوالے کیا:
- کلاؤڈ ایجنٹس کے لیے Acura مینجمنٹ کنسول سے استعمال کی نگرانی اور تعیناتی؛
- کرایہ داروں کے لیے کوٹے کی دستیابی؛
- ہر کرایہ دار کے لیے بیک وقت نقل کی تعداد اور رفتار کو محدود کرنے کی صلاحیت؛
- VMware vCloud ڈائریکٹر کے لیے سپورٹ؛
- وسائل کے تالابوں کے لیے سپورٹ (ٹیسٹنگ کے دوران لاگو کیا گیا)؛
- Acura پینل میں کلائنٹ کے بنیادی ڈھانچے سے اسناد داخل کیے بغیر، ایجنٹ کی طرف سے VMware ایجنٹ کو ترتیب دینے کی صلاحیت؛
- DR پلان شروع کرتے وقت VM شروع کرنے کے عمل کا "تصویر"۔
صرف ایک چیز جس کی وجہ سے مجھے بڑی شکایات تھیں وہ دستاویزات تھیں۔ مجھے واقعی میں "بلیک باکسز" پسند نہیں ہیں اور جب پروڈکٹ کے اندر کام کرنے کے بارے میں تفصیلی دستاویزات موجود ہوں تو میں ترجیح دیتا ہوں۔ اور اگر AWS اور OpenStack کے لیے پروڈکٹ کو اس سے بھی کم یا زیادہ بیان کیا گیا ہے، تو VMware کے لیے بہت کم دستاویزات ہیں۔
ایک انسٹالیشن گائیڈ ہے جو صرف Acura پینل کی تعیناتی کی وضاحت کرتا ہے، اور جہاں کلاؤڈ ایجنٹ کی ضرورت کے بارے میں کوئی لفظ نہیں ہے۔ مصنوعات کے لئے وضاحتیں کا ایک مکمل سیٹ ہے، جو اچھا ہے. ایسی دستاویزات موجود ہیں جو AWS اور OpenStack کا استعمال کرتے ہوئے ایک مثال کے طور پر سیٹ اپ کی وضاحت کرتی ہے (حالانکہ یہ مجھے بلاگ پوسٹ کی زیادہ یاد دلاتا ہے)، اور ایک بہت ہی چھوٹا نالج بیس ہے۔
عام طور پر، یہ وہ دستاویزی شکل نہیں ہے جس کا میں استعمال کرتا ہوں، کہتے ہیں، بڑے دکانداروں سے، اس لیے میں پوری طرح آرام دہ نہیں تھا۔ ایک ہی وقت میں، مجھے اس دستاویز میں سسٹم کے آپریشن "اندر" کی کچھ باریکیوں کے بارے میں جوابات نہیں ملے - مجھے تکنیکی مدد کے ساتھ بہت سارے سوالات کو واضح کرنا پڑا، اور اس نے اسٹینڈ کی تعیناتی کے عمل کو گھسیٹا اور ٹیسٹنگ
خلاصہ کرتے ہوئے، میں یہ کہہ سکتا ہوں کہ عام طور پر مجھے پروڈکٹ اور کمپنی کے کام کو نافذ کرنے کا طریقہ پسند آیا۔ جی ہاں، خامیاں ہیں، فنکشنلٹی کی واقعی ایک اہم کمی ہے (VMware کے ساتھ مل کر)۔ یہ دیکھا جا سکتا ہے کہ، سب سے پہلے، کمپنی اب بھی عوامی بادلوں پر توجہ مرکوز کرتی ہے، خاص طور پر AWS، اور کچھ کے لیے یہ کافی ہوگا۔ آج جب بہت سی کمپنیاں ملٹی کلاؤڈ حکمت عملی کا انتخاب کرتی ہیں تو اتنی سادہ اور آسان پروڈکٹ کا ہونا انتہائی اہم ہے۔ حریفوں کے مقابلے میں بہت کم قیمت کو دیکھتے ہوئے، یہ مصنوعات کو انتہائی پرکشش بناتا ہے۔
ہم ایک ٹیم کی تلاش میں ہیں۔ . شاید یہ آپ ہیں؟
ماخذ: www.habr.com