تقریباً 7 سال پہلے، سب سے پہلے منصوبے ہمارے کلاؤڈ پر سادہ اور غیر واضح طور پر منتقل ہوئے۔ ورچوئل مشین کی تصاویر FTP سرور پر اپ لوڈ کی گئی تھیں، یا انہیں ہارڈ ڈرائیوز پر ڈیلیور کیا گیا تھا۔ پھر، ایک خصوصی درآمدی سرور کے ذریعے، VMs کو کلاؤڈ پر اپ لوڈ کیا گیا۔
اگر کلائنٹ کے لیے ورچوئل مشین کو ایک یا دو دن کے لیے بند کرنا کوئی مسئلہ نہیں ہے (یا کوئی اور آپشن نہیں ہے)، تو یہ کیا جا سکتا ہے۔ لیکن اگر ڈاؤن ٹائم زیادہ سے زیادہ ایک گھنٹہ ہونا چاہیے تو یہ طریقہ کام نہیں کرے گا۔ آج میں آپ کو بتاؤں گا کہ کون سے ٹولز آپ کو کم سے کم ٹائم ٹائم کے ساتھ کلاؤڈ پر ہجرت کرنے میں مدد کریں گے اور ہمارا ہجرت کا عمل خود کیسے کام کرتا ہے۔
ویم بیک اپ اور نقل کے ساتھ ہجرت
ہر کوئی Veeam Backup اور Replication کو بیک اپ اور replicas بنانے کے ایک ٹول کے طور پر جانتا ہے۔ ہم اسے اپنی سائٹس کے درمیان منتقلی اور کلائنٹس کو پرائیویٹ ورچوئلائزیشن سے اپنے کلاؤڈ تک لے جانے کے لیے استعمال کرتے ہیں۔ کلائنٹ کی ورچوئل مشینیں ہمارے vCenter میں نقل کی جاتی ہیں، جس کے بعد انجینئر انہیں vCloud ڈائریکٹر میں شامل کرتا ہے۔
پرائمری نقل ایک پاور آن ورچوئل مشین پر ہوتی ہے۔ متفقہ وقت پر، کلائنٹ سائیڈ مشین بند کردی جاتی ہے۔ پہلی نقل کے بعد سے ہونے والی تبدیلیوں کو لے جانے کے لیے نقل دوبارہ چلتی ہے۔ اس کے بعد، ورچوئل مشین ہمارے کلاؤڈ میں شروع ہوتی ہے۔
عام طور پر، کلائنٹ کے انفراسٹرکچر پر مشین کے بند ہونے سے لے کر ہمارے کلاؤڈ میں اس کے آن ہونے تک، آدھے گھنٹے سے زیادہ نہیں گزرتا، بلکہ 15-20 منٹ۔
اس صورت میں، اصل ورچوئل مشین کلائنٹ کی سائٹ پر رہتی ہے۔ اگر اچانک کچھ غلط ہو جاتا ہے، تو آپ ہمیشہ واپس رول کر سکتے ہیں اور اسے آن کر سکتے ہیں۔ یہ طریقہ کلائنٹ کے لیے بھی آسان ہے کیونکہ اس کے لیے اسے Veeam رکھنے کی ضرورت نہیں ہے۔
کیس 1
کلائنٹ کے پاس VMware - 40 TB کی گنجائش کے ساتھ 30 VMs پر مبنی اپنا ورچوئل انفراسٹرکچر تھا۔ وہ سامان جس پر کلسٹر تعینات کیا گیا تھا وہ پہلے ہی پرانا تھا، اور کلائنٹ نے فیصلہ کیا کہ نئے کی خریداری کی زحمت نہ کی جائے اور وہ عوامی کلاؤڈ پر چلا گیا۔ اہم نظاموں کے لیے ڈاؤن ٹائم کی ضرورت ایک گھنٹے سے زیادہ نہیں تھی۔ Veeam Replication کو آلے کے طور پر منتخب کیا گیا تھا۔ ایک اور فائدہ یہ تھا کہ کلائنٹ کا انٹرنیٹ فراہم کنندہ ہمارے ڈیٹا سینٹر میں موجود تھا، جس کی وجہ سے ایک اچھا چینل ترتیب دینا ممکن ہوا۔ منتقلی میں تقریباً ایک مہینہ لگا، سوئچنگ کے دوران ڈاون ٹائم 30 منٹ فی ورچوئل مشینوں کے گروپ تک تھا۔
Veeam Cloud Connect کے ساتھ ہجرت کریں۔
Veeam Cloud Connect ایک ایسا ٹول ہے جو آپ کو ورچوئل مشین کی نقل ترتیب دینے اور سروس فراہم کنندہ کے کلاؤڈ میں نقلیں لانچ کرنے میں مدد کرتا ہے۔ اپ ڈیٹ کرنے کے بعد سال، ورچوئل مشینوں کو براہ راست vCloud ڈائریکٹر پر نقل کرنا ممکن ہو گیا۔ شرط صرف یہ ہے کہ کلائنٹ کی طرف، Veeam Backup اور Replication کو کم از کم ورژن 9 تعینات کیا جانا چاہیے۔ مختصر میں (تفصیلی ورژن )، پھر پورا عمل اس طرح لگتا ہے۔
وی کلاؤڈ ڈائریکٹر میں، ایک تنظیم ضروری وسائل اور نیٹ ورکس کے ساتھ بنائی جاتی ہے۔ Veeam Cloud Connect میں، ہم ایک اکاؤنٹ بناتے ہیں، کلائنٹ اپنے Veeam B&R سے اس سے جڑتا ہے، ڈیٹا لائن فراہم کنندہ اور تنظیم کا انتخاب کرتا ہے، اور نقل کے لیے کاموں کو ترتیب دیتا ہے۔ اس حقیقت کے علاوہ کہ اس طرح کی منتقلی کے دوران، ڈاؤن ٹائم 15-20 منٹ کے اندر ہو گا، کلائنٹ کسی بھی طرح سے فراہم کنندہ کی تکنیکی مدد پر انحصار نہیں کرتا ہے اور پورے عمل کو آزادانہ طور پر منظم کرتا ہے: نقل کے کام تخلیق کرتا ہے، نقل خود ہی بند ہو جاتا ہے۔ مشینیں اور انہیں نئی سائٹ پر شروع کرتا ہے۔
کیس 2
کلائنٹ کا انفراسٹرکچر، جہاں سے ہجرت کا منصوبہ بنایا گیا تھا، بیلاروس میں واقع تھا۔ انٹرنیٹ چینل 90 Mbit/sec ہونے کے باوجود 27 TB کے کل حجم کے ساتھ 100 VMs کو منتقل کرنا ضروری تھا۔ اگر آپ بیک اپ بناتے ہیں اور اسے فوری طور پر ہمارے کلاؤڈ پر اپ لوڈ کرتے ہیں، تو کچھ VMs کے لیے کئی دن لگیں گے۔ اس وقت کے دوران، VM پر ایک بڑا ڈیلٹا بڑھ چکا ہوگا، اور اس سے مشینوں کی کارکردگی پر منفی اثر پڑ سکتا ہے یا اس سے بھی بدتر، ڈیٹا اسٹور کی جگہ ختم ہو چکی ہوگی۔ ہم نے اس طرح آگے بڑھا: سب سے پہلے، کلائنٹ نے مقامی مکمل بیک اپ بنایا اور اس کی ایک کاپی ہمارے کلاؤڈ کو Veeam Cloud Connect کے ذریعے منتقل کی۔ پھر میں نے انکریمنٹ کو کلاؤڈ میں بنایا اور منتقل کیا۔ اصل ورچوئل مشین چلتی رہی۔ VM کو بند کرنے کے بعد، کلائنٹ نے ایک اور اضافہ کیا اور اسے کلاؤڈ میں بھی منتقل کر دیا۔ اپنی طرف، ہم نے ایک مکمل بیک اپ سے ایک ورچوئل مشین کو تعینات کیا، اور پھر اس پر دو انکریمنٹ کو رول کیا۔ اس اسکیم نے بالآخر ہماری سائٹ پر سوئچ کرتے وقت ڈاؤن ٹائم کو 2 گھنٹے تک کم کرنا ممکن بنایا۔
VMware vCloud دستیابی کے ساتھ ہجرت
اس سال مارچ میں، VMware نے vCloud Availability 3.0 جاری کیا، جو آپ کو مختلف کلاؤڈز (vCloud Director - vCloud Director) اور پرائیویٹ کلائنٹ ورچوئلائزیشن اسٹینڈ سے کلاؤڈ (vCenter - vCloud Director) کے درمیان ورچوئل مشینوں کو منتقل کرنے کی اجازت دیتا ہے۔ اہم سہولت vCloud ڈائریکٹر انٹرفیس کے ساتھ انضمام ہے۔ یہ نقل کے انتظام کے عمل کو بہت آسان بناتا ہے اور سوئچ اوور کے دوران ڈاؤن ٹائم کو کم کرتا ہے۔
اس ٹول کا استعمال کرتے ہوئے، ہم نے اپنے ماسکو کلاؤڈ سے ایک کلائنٹ کو سینٹ پیٹرزبرگ میں اپنے کلاؤڈ میں منتقل کیا۔ 18 ٹی بی کی کل صلاحیت کے ساتھ 14 ورچوئل مشینوں کو منتقل کرنا ضروری تھا۔ سینٹ پیٹرزبرگ کلاؤڈ میں کلائنٹ کے لیے ایک تنظیم بنائی گئی اور ضروری نیٹ ورکس کو منظم کیا گیا۔ اس کے بعد، وی کلاؤڈ ڈائریکٹر انٹرفیس سے، کلائنٹ vCloud دستیابی کی ترتیبات پر گیا، نقل کی نوکریاں تخلیق کیں اور اپنے لیے مناسب وقت پر سینٹ پیٹرزبرگ کی سائٹ پر سوئچ کیا۔ سوئچنگ کے دوران ڈاؤن ٹائم 12 منٹ تھا۔
سینٹ پیٹرزبرگ اور ماسکو میں ڈیٹا لائن کے بادلوں کے درمیان ہجرت کی اسکیم۔
vCloud Availability میں VMs کو کلائنٹ کی سائٹ سے ہمارے کلاؤڈ پر منتقل کرنے کا طریقہ کار ہے۔ ایسا کرنے کے لیے، کلائنٹ کے vCenter میں ایک خصوصی vCloud Availability ایپلیکیشن تعینات کی گئی ہے۔ سادہ سیٹ اپ کے بعد، آپ کلاؤڈ سے جڑ جاتے ہیں اور منتقلی کے کاموں کو ترتیب دیتے ہیں۔ کلائنٹ بھی آزادانہ طور پر پورے عمل کا انتظام کرتا ہے اور منتقلی کا وقت کم سے کم رکھا جاتا ہے۔
ورچوئل مشینوں کو نجی تنصیب سے کلاؤڈ میں منتقل کرنے کی اسکیم۔
VMware vCloud کی دستیابی میں استعمال کے بہت سے دوسرے معاملات ہیں؛ ہم جلد ہی ان کے بارے میں ایک علیحدہ مضمون میں بات کریں گے۔
ہجرت کی تیاری
کسی ٹول کا انتخاب کرنے اور اصل میں ہجرت شروع کرنے کے لیے، آپ کو درج ذیل نکات پر فیصلہ کرنا ہوگا:
ہم کہاں سے ہجرت کریں؟ اگر آپ نجی حل سے ہجرت کر رہے ہیں، تو آپ کو ٹولز کے انتخاب میں مکمل آزادی ہے۔ اگر آپ اپنے فراہم کنندہ سے دور چلے جاتے ہیں، تو یہ زیادہ پیچیدہ ہے۔ زیادہ تر امکان ہے کہ، دو فراہم کنندگان کے بنیادی ڈھانچے کو جوڑنا اور صرف VM کو گھسیٹنا اور چھوڑنا سیکیورٹی وجوہات کی بناء پر کام نہیں کرے گا۔ بعض اوقات وہ فراہم کنندہ جسے کلائنٹ انکار کرنے والا ہے شرارتی ہونا شروع کر دیتا ہے اور وقت کے لیے رک جاتا ہے۔ آپ پرانے زمانے کے طریقے سے فراہم کنندہ سے دور جا سکتے ہیں: VMs کو ڈسک اور FTP پر اپ لوڈ کر کے، یا ایپلیکیشن کی سطح پر منتقل کر کے۔ مؤخر الذکر کا نام مشروط ہے، اور یہ کچھ اس طرح لگتا ہے۔
کیس 3
کلائنٹ کے SAP سسٹم کو یورپی فراہم کنندہ سے منتقل کرنا ضروری تھا: 34 TB کی صلاحیت کے ساتھ 54 VMs۔ کلائنٹ کو ہمارے کلاؤڈ میں وسائل مختص کیے گئے تھے۔ ہمارے اور یورپی فراہم کنندہ کے بنیادی ڈھانچے کے درمیان نیٹ ورک کنیکٹیویٹی کا اہتمام کیا گیا تھا۔ ایپلیکیشن سرورز کو دوبارہ تعینات کیا گیا، ضروری کنفیگریشنز کو رول اوور کر دیا گیا۔ ہمارے کلاؤڈ پر بیک اپ اپ لوڈ کرنے کے ذریعے بڑے ڈیٹا بیسز کو منتقل کیا گیا تھا۔ اس کے بعد، ہماری اور اصل سائٹس کے ڈیٹا بیس کے درمیان نقل تیار کی گئی۔ طے شدہ وقت پر، ہم نے اپنے کلاؤڈ میں ڈیٹا بیس کو تبدیل کیا۔
ڈیٹا کا حجم اور انٹرنیٹ چینل۔ ہم عام طور پر کلائنٹ سے سسٹم کے ذریعے میموری، CPU، اور ڈسک کے پیرامیٹرز کے ساتھ اپ لوڈ فراہم کرنے کو کہتے ہیں۔ ہم جائزہ لیتے ہیں کہ آیا چینل براہ راست نقل یا ورچوئل مشینوں کے بیک اپ بھیجنے کے لیے کافی ہے۔
قابل قبول ڈاؤن ٹائم۔ مختلف سسٹمز اور، اس کے مطابق، ورچوئل مشینوں کے لیے، یہ ان کی کاروباری تنقید کے لحاظ سے مختلف ہو سکتے ہیں۔ عام طور پر کلائنٹ ہجرت کے دوران ڈاؤن ٹائم کے لیے تیار ضروریات کے ساتھ آتا ہے، اور اس کی بنیاد پر ہم مناسب ٹول اور ہجرت کا منصوبہ منتخب کرتے ہیں۔ ہم رات کو یا اختتام ہفتہ پر حتمی سوئچ اوور کو شیڈول کرنے کی کوشش کرتے ہیں تاکہ کلائنٹ کے اختتامی صارفین کے لیے معمولی بند وقت بھی قابل توجہ نہ ہو۔
اس ڈیٹا کی بنیاد پر، آپ ایک ٹول منتخب کر سکتے ہیں اور خود منتقلی شروع کر سکتے ہیں۔ آگے کیا ہوتا ہے یہ ہے۔
- نیٹ ورک کنیکٹیویٹی سیٹ اپ کرنا۔ ہم اپنے کلاؤڈ اور کلائنٹ کے انفراسٹرکچر کے درمیان نیٹ ورک کنیکٹیویٹی کو منظم کرتے ہیں۔ ورچوئل مشینیں اس نیٹ ورک پر کاپی کی جائیں گی۔ اگر Veeam بیک اپ اور نقل استعمال کیا جاتا ہے، تو یہ ایک وقف شدہ چینل ہے، کم ہی اکثر وی پی این چینل۔ اگر Veeam Cloud Connect، تو پھر سب کچھ انٹرنیٹ یا اسی سرشار چینل کے ذریعے ہوتا ہے۔
پھر نیٹ ورک کو کلاؤڈ میں VM کے لیے ترتیب دیا گیا ہے۔ کاریں عام طور پر گروپوں میں اور ایک دن سے زیادہ کے لیے چلتی ہیں۔ ایک بار جب VMs کو ہمارے پاس لایا جاتا ہے اور لانچ کیا جاتا ہے، تو انہیں ان مشینوں کے ساتھ بات چیت کرنی چاہیے جو اب بھی اصل جگہ پر موجود ہیں۔
- ہجرت کا شیڈول۔ جب بہت ساری کاریں ہوتی ہیں تو انہیں گروپوں میں تقسیم کرنا اور بیچوں میں منتقل کرنا سمجھ میں آتا ہے۔ کلائنٹ کے ساتھ مل کر، ہم ایک ایسے منصوبے پر متفق ہیں جس میں ہم یہ بتاتے ہیں کہ کب اور کون سی مشینیں حرکت میں آئیں گی اور نئی سائٹ پر حتمی نقل اور سوئچ اوور کب انجام دیا جائے گا۔
- ٹیسٹ ہجرت۔ ہم ٹیسٹ ورچوئل مشین کو منتقل کرتے ہیں اور چیک کرتے ہیں کہ آیا سب کچھ صحیح طریقے سے ترتیب دیا گیا ہے: سائٹس کے درمیان نیٹ ورک کنیکٹیویٹی، سورس سائٹ پر مشینوں کے لیے ورچوئل مشین کی دستیابی، اکاؤنٹ کے حقوق وغیرہ۔ یہ ٹیسٹ جنگی ہجرت کے مرحلے میں رکاوٹوں سے بچنے میں مدد کرتا ہے۔
یہ سب میرے لیے ہے۔ تبصروں میں، سوالات پوچھیں اور ہمیں اپنے ہجرت کے تجربے کے بارے میں بتائیں۔
ماخذ: www.habr.com