به منظور تسهیل فرآیند مهاجرت ماشین‌های مجازی از نسخه ۱ به نسخه ۲، تیم فنی ستون اقدام به ارائه دو راهکار نموده است که در ادامه توضیح داده شده‌اند.

انتقال ماشین

امکان انتقال دیسک سیستم‌عامل و دیسک‌های اضافی ماشین مجازی از نسخه ۱ به نسخه ۲ توسط تیم فنی ستون میسر شده و در صورت درخواست انجام می‌گردد.

فرآیند درخواست

بدین منظور، لازم است تا موارد زیر به تیم فنی اعلام شود:

  • نام ماشین مبدا (نسخه ۱)،
  • نام ماشین مقصد (نسخه ۲) که درآینده ایجاد خواهد شد و می‌تواند هم‌نام ماشین مبدا باشد،
  • نام subnetای که ماشین مقصد (نسخه ۲) باید به آن متصل شود.
  • نوع مصرف منابع اپلیکیشن‌های مستقر روی ماشین (Memory-intensive بودن یا نبودن)
  • روز و ساعت شروع عملیات انتقال

نکات مهم

نکات زیر درخصوص فرآیند انتقال قابل توجه هستند:

  • درحال حاضر، امکان انتقال آی‌پی ماشین مبدا به مقصد وجود ندارد و آی‌پی داخلی و خارجی (درصورت وجود) ماشین مقصد، با ماشین مبدا متفاوت خواهد بود.
  • برای شروع عملیات انتقال لازم است تا ماشین مبدا خاموش شود. درصورت هماهنگ شدن با تیم فنی ستون روی یک روز و ساعت خاص برای شروع عملیات، ماشین توسط تیم فنی ستون خاموش خواهد شد. بنابراین لازم است قبل از فرارسیدن زمان توافق شده، کاربر اقدامات لازم پیش از Downtime سرویس را انجام داده باشد.
  • ماشین مبدا هرگز نباید در طول انجام عملیات انتقال روشن شود.
  • به منظور کاهش هزینه‌های کاربران، تیم ستون از داده‌های پایش شده آماری خود جهت بهینه‌سازی منابع مصرفی ماشین مقصد مطابق با نوع مصرف منابع اعلامی توسط کاربر استفاده خواهد کرد و در صورت عدم درخواست نوع خاصی از منابع برای ماشین مقصد توسط کاربر، بطور پیش‌فرض نوع ماشین مقصد را مطابق صدک ۹۹ مصرف پردازنده در ۱ ماه گذشته تنظیم خواهد کرد.
  • پس از روشن شدن ماشین مقصد (نسخه ۲)، مشخصات آن از طریق پنل قابل مشاهده خواهد بود و لازم است تا توسط کاربر، صحت و سلامت آن بررسی شود. در صورت استاندارد نبودن نامگذاری دیسک‌ها در ماشین مبدا، ممکن است نیاز به remount کردن برخی از دیسک‌های اضافی در ماشین مقصد باشد
  • در صورتی که ماشین مقصد (نسخه ۲) از نوع ماشین‌های اقتصادی (Economy) باشد، امکان ایجاد دیسک ریموت از نوع Ultra و بیشتر را نخواهد داشت و به نوع Premium تغییر خواهند کرد.
  • در ماشین‌های مجازی نسخه ۲، فقط دیسک سیستم‌عامل می‌تواند از نوع Local باشد. بنابراین در صورتی‌که در ماشین مبدا (نسخه ۱) دیسک اضافه‌ای از نوع Local باشد، در ماشین مقصد (نسخه ۲) بصورت یک دیسک اضافه ریموت از نوع Premium افزوده خواهد شد.
  • پس از انتقال به نسخه ۲، امکان تغییر نوع و منابع ماشین مقصد از طریق پنل وجود خواهد داشت.

مدت زمان لازم انتقال

در صورتی‌که ماشین مبدا در دیتاسنتر ندا قرار داشته باشد، زمان Downtime مورد نیاز بطور حدودی از این رابطه پیروی خواهد کرد:

Downtime (minutes) = 10 + (5 * RemoteDisksGB / 100) + (15 * LocalDisksGB / 100)

ارتباط بین ماشین‌های مجازی نسخه۱ و ۲

اگر در فرآیند مهاجرت از ماشین مجازی نسخه۱ به نسخه۲ نیاز به ارتباط شبکه‌ایی بین ماشین‌های مجازی بین این دو نسخه وجود داشته باشد امکان راه‌اندازی تانل برای برقراری این ارتباط از سمت تیم فنی ستون میسر است. سناریو راه اندازی این تانل به شکل زیر است:

این تانل با استفاده از پروتکل BGP ارتباط بین سابنت‌های نسخه۱ و ۲ را امکان پذیر میکند.

نیازمندی‌های راه‌اندازی

برای راه‌اندازی تانل نیاز به موارد زیر میباشد:

  • ساخت دو ماشین مجازی در سابنت مورد نظر در هر دو نسخه(مجموعا ۴ ماشین مجازی)
  • اضافه کردن آدرس آیپی پابلیک به ماشین‌های ساخته شده
  • هماهنگی برای ایجاد دسترسی SSH تیم فنی ستون به ماشین‌های ساخته شده

نیازمندی‌های ارتباطی

در خصوص ارتباط بین شبکه ماشین‌های مجازی نسخه۱ و ۲ سناریو‌های زیر مطرح میباشد:

  • ارتباط ماشین‌های مجازی بین دو نسخه(ماشین‌های خارج از کلاستر کوبرنتیز)
  • ارتباط workerهای کلاستر کوبرنتیز در نسخه۱و ۲
  • ارتباط پادها و سرویس‌های داخل کلاستر کوبرنتیز در نسخه۱ و ۲

با توجه به نیازمندی‌های مطرح شده موارد زیر باید در نظر گرفته شود:

  • بعد از ساخت ماشین‌های مجازی لازم، پیاده‌سازی تانل توسط تیم فنی ستون انجام خواهد شد.
  • بعد از پیاده سازی تانل برای ارتباط ماشین‌های مجازی با یکدیگر باید روت مربوط به دسترسی سابنت مقابل روی ماشین‌های مجازی توسط کاربر اضافه شود. این کار به صورت استاتیک و یا با استفاده از سرویس bird قابل انجام است. لازم به ذکر است که در این سناریو ارتباطی در واقع دو تانل مجزا بین ماشین‌های دو سمت پیاده‌سازی میشود اما این موضوع به معنی انتقال ترافیک به صورت توزیع شده بین این دو تانل نیست.
    • نمونه دستور برای اضافه کردن روت در ماشین مجازی
      ip r add <destination subnet> via <tunnel gateway address>
      
  • اگه محدوده آدرس آیپی پاد و سرویس در کلاسترهای کوبرنتیز ۱و ۲ یکسان باشد امکان ارتباط پاد به پاد و یا سرویس به سرویس از طریق تانل وجود نخواهد داشت چون این کار باعث ایجاد کانفلیکت در مسیریابی خواهد شد. پس ضروری است در صورت نیاز به ارتباط بین پادها و سرویس‌ها در کلاسترهای نسخه۱ و ۲ محدوده آدرس پاد و سرویس در دو کلاستر متفاوت باشد.
  • برای برقراری ارتباط پاد به پاد باید BGP بر روی کلیکو یا سیلیوم فعال شود. منیفست‌های این کار توسط تیم فنی ستون در اختیار کاربران قرار خواهد گرفت.
  • به صورت پیش فرض در کلاسترهای کوبرنتیز نسخه۲ که از سیلیوم استفاده میکنند پروتکل BGP و CRDهای مربوط به آن در کلاستر نصب نیست. انجام این تغییرات با اطلاع کاربر توسط تیم فنی ستون بر روی کلاستر صورت میپذیرد.
  • پروتکل BGP در سیلیوم فقط آدرس‌های شبکه را به سمت BGP peer منتشر میکند اما هیچ آدرسی را از سمت peer بر روی کرنل نصب نمیکند و نیاز است که مسیر برگشت همانند مثال ذکر شده توسط کاربر بر روی تمامی ماشین‌های کلاستر کوبرنتیز اضافه شود.

انتقال PVC به کوبرنتیز نسخه ۲

امکان انتقال PVCهای کوبرنتیز از نسخه ۱ به نسخه ۲ توسط تیم فنی ستون میسر شده و در صورت درخواست انجام می‌گردد.

فرآیند درخواست

بدین منظور، ابتدا لازم است تا یک PVC دقیقا هم‌اندازه با PVC کلاستر نسخه ۱ در کلاستر نسخه ۲ ایجاد شود. سپس موارد زیر به تیم فنی اعلام شود:

  • نام Persistant Volume (PV) در کلاستر کوبرنتیز نسخه ۱ (مبدا)
  • مقدار موجود در مسیر .spec.csi.volumeHandle در Persistant Volume (PV) ایجاد شده در کلاستر نسخه ۲ (مقصد)
  • روز و ساعت شروع عملیات انتقال

نکات مهم

نکات زیر درخصوص فرآیند انتقال قابل توجه هستند:

  • PVC کلاستر کوبرنتیز مبدا (نسخه ۱) نباید به هیچ پادی متصل باشد.
  • PVC ایجاد شده در کلاستر نسخه ۲ نباید به هیچ پادی متصل باشد. همچنین از لحظه ساخت تا لحظه انتقال نباید هیچ تغییری روی آن داده شده باشد.
  • از زمان ساخت PVC در کلاستر نسخه ۲ باید کمتر از یک ساعت گذشته باشد.
  • پس از انتقال محتویات PVC به کلاستر کوبرنتیز مقصد (نسخه ۲)، لازم است تا توسط کاربر، صحت و سلامت آن بررسی شود.

مدت زمان لازم انتقال

مدت زمان مورد نیاز برای انتقال برای یک PVC با اندازه pvcGB گیگابایت بطور حدودی از این رابطه پیروی خواهد کرد:

MigrationTime (minutes) = 5 + (5 * pvcGB / 100)