مجازی‌سازی و کلاسترینگ‌ در مایکروسافت (قسمت سوم

دوستان گران‌قدر ازینکه قدم به قدم ما را همراهی می‌نمایید اظهار تشکر داریم. در قسمت قبل وارد مبحث Hyper-V Setting شدیم و تا دو قسمت دیگر با تنظیمات هایپروی با شما همراه خواهیم بود.

Live Migration:

یکی از قابلیت هایی که با ظهور هایپروی سرور 2012 فعال شد Live Migration است که امکان جابجایی VMها، بدون هیچ قطعی و از کار افتادگی، بین Hyper-V‌ های مجزا را مقدور می‌سازد. با توجه به اینکه دو سرور Hyper-V هیچ فضای اشتراکی باهم ندارند این فرآیند Nothing-shared Live Migration شناخته می‌شود.

پیش نیازها:

هر دو سرور Hyper-V حتما 2012 باشند.
در هردو هاست بایستی در یک دامین باشند.
پروسسور هر دو سرور باید یک مدل باشند.
سرورها هارد Path-Through نداشته باشند(این اصطلاح در قسمت ششم توضیح داده خواهد شد).
سرورها حداقل یک ارتباط 1G داشته باشند.

آماده سازی Hostها:

جهت پیاده سازی ابتدا در تنظیمات Hyper-V Setting تب Live Migration وارد می‌شویم.

گزینه Enable Incoming and Outgoing Live Migration را مارک می‌کنیم.
در simultaneous live migrations تعداد Migrateهای هم زمان قابل تنظم است که با توجه به پهنای باند می‌توان آنرا تغییر دهیم. پیش فرض 2 است که ترجیحا تغییر نمی‌دهیم.
در Incoming live migrations باید ارتباطات شبکه ای را تنظیم کرد. در حالت پیش فرض از تمام سرورها می‌توان Migrate کرد اما توصیه اکید می‌شود IP سیستمی که می‌خواهد Listening Live Migration داشته باشد اضافه کنیم در حقیقت IP همان سروری که داریم روی آن تنظیمات انجام می‌دهیم.

پس از گذر از تنظیمات مذکور نوبت به Advance Feature می‌رسد.

پروتکل‌های Authentication:

در محیط کلاستر تمام هاست‌هایی که Nodeهای آن هستند از یک اکانت مشترک استفاده می‌کنند که این اکانت برای ارتباط و اهراز هویت بین Nodeهای کلاستر استفاده می‌شوند.

در محیط هایی خارج از کلاسترینگ هاست‌ها کامپیوتر اکانت خودشان را دارند که ممکن است هیچ تشابهی بین مجوزهایشان وجود نداشته باشد با این تفاسیر جهت اهراز هویت از یوزر اکانتی که Live Migration را پیاده سازی کرده استفاده می‌شود.

در Live Migration فعالیت‌ها و منابع VM بین مبدا و مقصد جابجا می‌شود حتی اگر VM روی (Server Message Block(SMB باشد، به هر حال نیاز به Authenticate است. در این پروسه دو پروتکل احراز هویت وجود دارد که به تفصیل شرح داده می‌شود:

1- پروتکل (Credential Security Support Provider (CredSSP :

اگر در مرحله Incoming گزینه using any available network for live migration مارک شود آنگاه در ساده ترین حالت پروتکل (Credential Security Support Provider (CredSSP بصورت پیش فرض فعال می‌شود. اما دو دلیل وجود دارد که Kerberos مقدم می‌شود.

* با CredSSP پشت صحنه پورت Hyper-V (MIG-TCP-In) TCP 6600 در فایروال هاست فعال می‌شود اما چنانچه فایروال دیگری بر سر راه وجود داشته باشد این امکان مقدور نیست مگر اینکه دستی این پورت باز شود.

* با CredSSP یوزری که سطح دسترسی ادمین دارد و قادر به لاگین در سرور مبدا و مقصد باشد می‌تواند از سیستم کلاینت به کنسولHyper-V Manager وصل شود و اقدامات لازم برای Migrate را در هاست A فراهم آورد اما در Live Migrate یک شرط لازم بین دو هاست A و B وجود دارد تا پروسه انتقال کامل شود. شرط اینست که هاستA باید قادر به اتصال ریموت به هاست B باشد. متاسفانه پروتکل CredSSP تنها از یک گام اتصال ریموت ساپورت میکند یعنی پس از اینکه با هایپروی منیجر هاست وصل شدیم نمی‌توانیم فرمان Live Migrate را کامل کنیم(زیرا در این حالت 2گام ریموت لازم است). اگر ازین پروتکل استفاده کنیم باید مستقیم به هاستA وارد شویم و با کامند فرمان Migrate به هاست B را اجرا کنیم (در این حالت تنها یک گام ریموت از A به B دارد).

PS C:\> Move-VM LMTest TestServer02 -IncludeStorage -DestinationStoragePath D:\LMTest

2- پروتکل Kerberos:

با توجه به اینکه هدف سرورهای نسل2012 بهبود مدیریت ریموت و کنترل اتوماتیک است، وصل شدن مستقیم به سرور مبدا و مقصد برای انجام Live Migrate حرکت غیر اصولی است از آنجا پروتکل CredSSP تنها قادر به اعتبار سنجی یک گام است پس در اینجاست که به سراغ پروتکل Kerberos می‌رویم چراکه این پروتکل خاصیت Full Remote Management دارد.

با توجه به آن خاصیت آیا زمانی که ما با هایپروی منیجر به هاستA وصل شدیم و دستور Move زدیم (عملا فرآیند Live Migrate آغاز کردیم) هاستA بدون اطلاع با همان یوزر به هاستB ریموت می‌زند؟ قطعا خیر…

در این مرحله است که delegation of authentication نقش نمایی می‌کند. حتما قبل از استفاده از Kerberos باید یک سری تنظیمات انجام دهیم. بایستی Delegation را در کامپیوتر اکانت هر هاست پیکربندی کنیم تا اجازه داده شود با یوزر دیگر عملیات Migrate اجرا شود.

وارد کنسول اکتیو دایرکتوری می‌شویم و از کامپیوتر اکانت ها Properties گرفته. سپس از تب Delegation سرویس‌های Migrate Service را برای مقصد و همچنین سرویس Common Internet File System (CIFS را برای مبدا و مقصد اضافه می‌کنیم.

Cifs جهت جابجایی VMهایی است که SMB استفاده می‌کنند.

گزینه‌های Performance:

برای کاهش سربار شبکه و کارایی بهتر CPU و همچنین کاهش زمان انتقال باید با توجه به شرایط یکی از گزینه های Performance را انتخاب کرد.

1- TCP/IT:

در این حالت اطلاعات RAM ماشین مجازی را با اتصالات شبکه های در سرور مقصد کپی و منتقل می‌کند.

2- Compression:

برای افزایش کارایی و سرعت بالاتر استفاده می‌شود زیرا در این حالت ابتدا محتوایات RAM ماشین مجازی فشرده کرده و بعد در سرور مقصد کپی می‌کند. گزینه پیش فرض این مدل است که ترجیح داده می‌شود در همین حالت بماند.

3- SMB:

اطلاعات RAM را با اتصالات SMB 3.0 در سرور مقصد کپی می‌کند.

عملیات Migrate کردن ماشین مجازی:

با انتخاب گزینه Move در VM مورد نظر پروسه جابجایی شروع می‌شود.

قطعا در این مرحله گزینه Move Virtual Machine باید انتخاب شود.

سرور فیزیکی مقصد را مشخص می‌کنیم.

در این مرحله باید تعین کرد محتویات ماشین مجازی چگونه به مقصد منتقل شوند. با توجه به اینکه تمرکز به Shared-Nothing داریم و در این سناریو مکان به اشتراک گذاشته شده‌ی SMB نداریم یکی از دو گزینه اول را باید انتخاب کرد.

گزینه اول: تمام محتویات ماشین مجازی را در یک مسیر ذخیره می‌کند.(این گزینه توصیه می‌‎شود)

گزینه دوم: هر فایل را می‌تواند در موقعیت جداگانه قرار دهد. که در ادامه پیاده سازی برای هر فایل باید مسیرهای مورد نظر را معرفی کنیم.

گزینه سوم: زمانی که فضای به اشتراک گذاشته شده بین سرورها باشد.

همانطور که می‌بینید در خلاصه وضعیت مسیر ذخیره شدن فایل‌ها آورده شده نهایتا در صورت اطمینان از انتخاب خود Finish را زده تا پروسه انتقال شروع می‌شود.

در پایان خاطر نشان می‌کنیم shared-nothing live migration یک mobility solution است که صرفا قابلیت انعطاف پذیری بین دو هاست مجزا را ایجاد می‌کند و هرگز جاگزینی برای Failover Clustering نمی‌تواند باشد زیرا کلاسترینگ High Availability Solution است.

Storage Migration:

این تنظیم تعیین می‌کند چه تعداد Migrate همزمان مقدور است. در حالت پیش فرض این عدد 2 است یعنی فقط دو ماشین مجازی از یک هاست میتوان باهم جابجا کرد و اگر سومی را بخواهیم منتقل کنیم در حالت Migration Queue می‌رود تا یکی از انتقال ها تمام شود.

Enhance Session Mode Policy:

در نسخه های قبل از R2 2012 فقط فعالیت های خاصی از طریق VMBus بین ماشین مجازی و هاست هدایت می شدند مثل دسکتاپ و موس و کیبورد. برای امکانات بیشتر باید به ماشین مجازی ریموت می‌زدیم که این نیازمند داشتن یک ارتباط شبکه ای بین ماشین مجازی و سرور هاست بود.اما در نسخهR2 2012 بجای VMBus با RDP Session ارتباط برقرار می‌شود که نیاز به ارتباط شبکه ای بین ماشین مجازی و هاست نیست،پس زمانی که به ماشین مجازی وصل هستید به راحتی می‌توانید به منابع لوکال هاست دسترسی داشته باشید.

که این موارد عبارتند از:

Display configuration

Audio

Printers

Clipboard

Smart cards

Drives

USB devices

Supported Plug and Play devices

این گزینه به صورت پیش فرض در کلاینت‌های 8.1 فعال هستند اما در ویندوز سرور باید آنرا فعال کرد.شایان ذکر است کلاینت حتمــــا باید نسخه 8.1 باشد. این فیچر با ماشین مجازی Genration1 هم کار می‌کند.اما متاسفانه با RemoteFX سازگار نیست.

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

عیب‌یابی ماشین‌های مجازی بدون اتصالات شبکه های با هاست.

قابلیت Copy & Paste بین ماشین مجازی و هاست.

لاگین به ماشین مجازی با کارت هوشمند.

ارسال پرینت از یک ماشین مجازی به یک پرینتر متصل به هاست.

در این قسمت به ادامه تنظیمات هایپروی پرداختیم که مهم‌ترین آن Live Migrate بود.در بخش بعدی توضیحات کامل Hyper-v Replica را خواهیم داشت و در ادامه مسیر به اتفاق خواهیم دید که مایکروسافت راهکارهای متعددی جهت تحمل خطا فراهم کرده است.

امیدواریم بستر شایسته‌ای جهت ترفیع سطح علمی و دانش عملی شما عزیزان گرد آورده باشیم.

windowsitpro.com . Live Migration
//blogs.technet.microsoft.com . Enhance Session Mode Policy