بررسی پیکربندی و نحوه عملکرد Enhanced vMotion Compatibility یا EVC

Enhanced vMotion Compatibility یا EVC چیست؟

vSphere Enhanced vMotion Compatibility یا به‌اختصار VMware EVC چیست؟ تضمین می‌کند که می‌توان بارکاری را با استفاده از vMotion، بین ESXi Hostهای یک کلاستر که روی نسل‌های مختلفی از CPU اجرا می‌گردند، بدون قطعی انتقال داد یا به‌اصطلاح آن را Live Migrate کرد. توصیه‌ی کلی این است که EVC فعال گردد زیرا در آینده، وقتی که کاربر بخواهد کلاسترهای خود را با Hostهای جدیدی توسعه دهد که ممکن است مدل‌های جدید از CPU را داشته باشند، به وی کمک می‌کند. فعال‌سازی EVC در یک سناریوی که سرورهای قدیم و جدید مشارکت دارند و حتی ممکن است در آینده به این ساختار سرورهای جدید افزوده شود، ممکن است چالش‌برانگیز باشد، به همین دلیل تاکید می‌شود که از همان ابتدا فعال گردد. در ادامه به جزئیات EVC و ویژگی‌های Per-VM EVC می‌پردازیم.

نحوه‌ی عملکرد EVC

VMware EVC از طریق اعمال یک مبنای اصلی دستورالعمل‌ها برای ماشین‌های مجازی‌ که در Hostهای ESXi اجرا می‌شوند، تطبیق‌پذیری یکپارچه‌ی vMotion را فراهم می‌کند. به این معنا که EVC مجموعه دستورالعمل‌های از CPU را میسر می‌سازد که با توجه به سطح سازگاری انتخاب شده و تحت پشتیبانی در دسترس ماشین‌های مجازی قرار می‌دهد. اگر Host جدیدتری به کلاستر اضافه شود که حاوی پکیج‌های CPU جدیدتر باشد، ممکن است EVC دستورالعمل‌های جدید CPU برای ماشین‌های مجازی را پنهان کند. با این کار، EVC تضمین می‌کند که همه‌ی ماشین‌های مجازی درون کلاستر با یک دستورالعمل CPU یکسان کار می‌کنند و به ماشین‌های مجازی این امکان را می‌دهد تا بین Hostهای ESXi به‌صورت زنده (vMotion) انقال یابند (Live Migrate).

EVC مشخص می‌کند که چه دستورالعمل‌هایی با استفاده از CPUID از سیستم عامل Guest پنهان شوند. اساسا می‌توان دید که CPUID نقش یک API را برای CPU بازی می‌کند و به EVC کمک می‌کند بیاموزد که CPU می‌تواند چه مجموعه دستورالعمل‌هایی را انجام دهد و براساس مبنای اصلی پیکربندی‌شده‌ی EVC چه دستورالعمل‌هایی باید مخفی شوند. وقتی EVC در کلاستر فعال شود، همه‌ی Hostهای ESXi در کلاستر باید از آن تنظیمات تبعیت کنند.

Per-VM EVC چیست؟

EVC تنظیمی در سطح کلاستر است که از تحرک‌پذیری ماشین‌‌های مجازی درون یک کلاستر پشتیبانی می‌کند. وقتی که یک ماشین مجازی به کلاستر دیگری منتقل می‌شود، چه به‌صورت On-premise و چه در یک محیط Cloud Hybrid، پیکربندی EVC‌اش را بسته به محیط مقصد از دست می‌دهد. علاوه بر این، تغییر مبنای اصلی EVC یک کلاستر در فضایی که بار کاریِ Live دارد، چالش برانگیز است.

با اجرا کردن Per-VM EVC، حالت EVC به‌جای اینکه یکی از ویژگی‌های یک نسل خاص پردازنده باشد که اتفاقا در کلاستر روی آن بوت شده است، یکی از ویژگی‌های ماشین مجازی می‌شود. به این ترتیب انعطاف بیشتری در فعال‌سازی EVC و مبناهای اصلی آن ایجاد می‌گردد. وِیژگیِ Per-VM EVC در vSphere 6.7 معرفی گشت. برای فعال‌سازی Per-VM EVC، سخت افزار ماشین مجازیِ بایستی نسخه‌ی 14 یا بالاتر باشد. وقتی که ماشین مجازی خاموش است می‌توان مبنای اصلی Per-VM EVC را تغییر داد.

پیکربندیِ Per-EVC در فایل vmx ذخیره می‌شود. فایل vmx فایلی است که به‌عنوان نوعی دیکشنری برای ورودی‌ها (Value Dictionary) استفاده می‌شود و شامل اطلاعات پیکربندی ماشین مجازی می باشد. اگر ماشین مجازی به کلاستر دیگری منتقل شود، پیکرندی Per-EVC  هم به‌همراه خود ماشین مجازی جا‌به‌جا می‌شود. وقتی Per-VM EVC فعال گردد، فایل vmx حاوی خطوط featMask.vm.cpuid، شبیه به نمونه‌های زیر خواهد بود:

featMask.vm.cpuid.Intel = “Val:1”

featMask.vm.cpuid.FAMILY = “Val:6”

featMask.vm.cpuid.MODEL = “Val:0x4f”

featMask.vm.cpuid.STEPPING = “Val:0”

featMask.vm.cpuid.NUMLEVELS = “Val:0xd”

مرور نظر کاربران

یک نظرسنجیِ توییتری اخیرا نتایج و نظرات جالبی را نشان داده است. از قرار معلوم 80 درصد از مشتری‌ها از EVC استفاده می‌کنند. در‌حالی‌که، با نگاهی به داده‌های Telemetry (یک فرایند ارتباطی خودکار است که با استفاده از آن داده ها در نقاط دورافتاده جمع آوری می‌شوند و به تجهیزات دریافت برای نظارت منتقل می‌شوند)، تعداد کلاسترها یا ماشین‌های مجازی که EVC فعال شده دارند، تصویر کمی متفاوت‌تری به‌دست می‌دهند. به هر حال خوب است که می‌بینیم تعداد زیادی از مشتری‌ها با فعالسازیِ EVC روی کلاسترها و یا روی ماشین‌های مجازیشان، از آن سود می‌برند.

با توجه به کامنت‌ها، نظر افراد درباره‌ی فعالسازیِ VMware EVC به‌صورت پیش‌فرض، مختلف است. بسیاری از مشتری‌ها معتقدند فعالسازیِ EVC در یک فضای Brownfield چالش برانگیز است، بنابراین با فعالسازیِ EVC از ابتدا، موافق هستند. Brownfield به زیرساخت هایی گفته می‌شود که سرور‌های جدید در کنار سرور‌های قدیم افزوده و سرویس می دهند، در حقیقت شما نمی‌توانید سرویس های قدیم را نیز کنار بگزارید. از طرف دیگر، مشتری‌هایی هستند که EVC را فعال نکردند چون یک کلاستر یکپارچه دارند و ارزشی در فعالسازیِ آن نمی‌بینند. باید بدانیم که خود ویژگیِ EVC هیچ سرباری بر زیرساخت مجازی ندارد، اما می‌تواند در آینده، وقتی که کاربر بخواهد کلاستر خود را با Hostهای اضافی که ممکن است نسخه‌های جدیدتر CPU را داشته باشند توسعه دهد، وی را از زحمتِ فعالسازی EVC کلاستر نجات دهد.

یکی دیگر از نگرانی‌های مشتری‌ها تاثیر بر عملکرد است. سوال این است که بارهای کاری که به دلیل مبناهای اصلی پیکربندی‌شده‌ی EVC، نمی‌توانند از جدیدترین دستورالعمل‌های CPU استفاده کنند چه می‌شوند؟ مسلما به بارهای کاری بستگی دارد اما به‌طور کلی تاثیر قابل توجهی روی عملکرد نمی‌بینم چرا که همه‌ی دستورالعمل‌های جدید CPU در معرض برنامه‌های کاربردی در حال اجرا در سیستم عامل Guest، نیستند.

برای فعالسازیِ EVC روی یک فضای Live با ماشین‌های مجازی روشن، باید ماشین‌های مجازی خاموش شوند تا پیکربندی EVC تغییر کند. Per-VM EVC در این حوزه کمک کننده خواهد بود.

بررسیِ پیکربندیِ EVC

برای بدست آوردن اطلاعات در مورد پیکربندی EVC محیط خود می توان از اسکریپت‌ نویسی استفاده کرد. نمونه‌های زیر امکان ایجاد شرحی مختصر را فراهم می‌کند که شامل ماشین‌های مجازی و سطح EVC ماشین‌های مجازی و همچنین سطح EVC کلاستر می‌باشد. از آنجایی که این اطلاعات فهرست‌وار هستند، با اضافه کردن Convert To-CSV، به‌سادگی در یک فایل CSV استخراج می‌شوند.

اجرا کردن این دستور PowerCLI  به کاربر نشان می‌دهد که در هنگام فعالسازی EVC، کدام مبناهای اصلی EVC پیکربندی شده‌اند. وقتی حالت EVC کلاستر فعال شود، اسکریپت مبناهای اصلی استفاده‌شده را نشان می‌دهد. علاوه بر آن، نسخه‌ی سخت‌افزارVM  را هم نشان می‌دهد زیرا Per-VM EVC صرفا برای نسخه‌ی 14 به بالای سخت افزار VM در دسترس است. اگر یک ماشین مجازی با Per-VM EVC پیکربندی شده باشد، ممکن است مبنا‌ی اصلی با پیکربندی EVC کلاستر متفاوت باشد. در Outputی که به‌عنوان نمونه در پایین آمده است ماشین مجازی DB01 با مبنای اصلی Per-VM EVC متفاوتی دیده می‌شود که با تنظیمات کلاستر مغایرت دارد.

این وضعیت تحت پشتیبانی است. بااین‌حال، اگر مبنای اصلی یک ماشین مجازی Per-VM EVC بالاتر مقدار تحت پشتیبانی Hostهای ESXi درون کلاستر باشد، ماشین‌های مجازی روشن نمی‌شوند زیرا هیچ Host متناسب و سازگاری با مبنای اصلی Per-VM EVC آن وجود ندارد.

کاربر باید همیشه مطمئن شود که Hostهای ESXi وی می‌توانند از مبناهای اصلی EVC پیکربندی‌شده پشتیبانی کنند تا تضمین شود که می‌توانند ماشین‌های‌ مجازی‌ را که یک پیکربندیِ Per-VM EVC را اجرا می‌کنند، تطبیق دهند. اگر لازم باشد اطلاعاتی درباره‌ی Hostهای ESXi به دست آید و مشخص گردد که بالاترین سطح توانایی آن‌ها در پشتیبانی از EVC چیست، می‌توان دستور PowerCLI زیر را وارد نمود:

1	Get-VMHost | Select-Object Name,ProcessorType,MaxEVCMode

در خروجی زیر می‌توان Hostهای ESXi را به علاوه‌ی پکیج‌های CPUای که به‌کار می‌برند و بالاترین سطح توانایی آن‌ها در پشتیبانی از EVC دید.

همانطور که پیشتر اشاره شد، به طور کلی توصیه‌ می‌شود که VMware EVC فعال گردد. برای رویکردی جزئی‌تر و دقیق‌تر و پشتیبانی از Hybrid Cloud، ویژگی Per-VM EVC نقطه‌ی شروع خوبی  برای فعال سازی EVC است. فعال کردن ویژگیِ EVC به کاربر این امکان را می‌دهد تا از تحرک‌پذیری بارکاری به‌صورت حداکثری سود ببرد.