در قسمت اول از مقاله معماری Hyper-V به بررسی ساختار اصلی و قابلیتهای این Hypervisor مایکروسافتی پرداختیم که از آن جمله میتوان به نحوهی ارتباط ماشینهای مجازی با دستگاههای فیزیکی خارجی, تاثیر خدمات یکپارچهسازی ماشین مجازی در عملکرد پردازنده و همچنین بهینهسازی فعالیتهای پیش زمینهای در ماشینهای مجازی اشاره کرد. در این قسمت از مقاله که قسمت پایانی از این مجموعه است به بررسی تکنولوژی NUMA و Live Migration در بهبود عملکرد ماشینهای مجازی می پردازیم.
تاثیر NUMA مجازی در عملکرد ماشین های مجازی
جهت فعال نمودن مجازیسازی بارهای کاری با مقیاس وسیع، Hyper-V در Windows Server 2016 محدودیتهای مقیاس ماشین مجازی را توسعه بخشیده است. یک ماشین مجازی این قابلیت را دارد که حداکثر240 پردازندهی مجازی و 12 ترابایت حافظه را در بر گیرد. حین ساخت چنین ماشینهای مجازی بزرگی، ممکن است از چندین NUMA Node بر سیستم Host، حافظه به کار گرفته شود. در چنین پیکربندی ماشین مجازیای، اگر حافظه و پردازندههای مجازی از همان NUMA Node تخصیص داده نشده باشند، بارهای کاری ممکن است به خاطر عدم توانایی در بهرهگیری از بهینهسازیهای NUMA، عملکرد بدی داشته باشند.
Hyper-V در Windows Server 2016 یک توپولوژی NUMAی مجازی به ماشینهای مجازی ارائه مینماید. به طور پیشفرض، این توپولوژی NUMAی مجازی جهت تطابق با توپولوژی NUMAی Host اصلی، بهینهسازی میگردد. ارائهی توپولوژی NUMAی مجازی به یک ماشین مجازی، سیستم عامل Guest و هرگونه برنامهی کاربردی با توجه به NUMAیی (NUMA-aware Applications) را که در آن اجرا میگردد، قادر میسازد تا از بهینهسازیهای عملکرد NUMA بهره ببرند، درست همانگونه که حین اجرا روی یک کامپیوتر فیزیکی این کار را انجام میدهند.
از نظر بار کاری هیچ تفاوتی میان NUMAی فیزیکی و مجازی وجود ندارد. درون یک ماشین مجازی، زمانی که یک بار کاری حافظهی Local را برای دادهها اختصاص میدهد و در همان NUMA Node به آن دادهها دسترسی مییابد، دسترسی سریع حافظهی Local بر روی سیستم فیزیکی اصلی به دست میآید. به خاطر دسترسی حافظهی Remote، از محدودیتهای عملکرد (Performance Penalties) به خوبی جلوگیری به عمل میآید. تنها برنامههای کاربردی با توجه به NUMA میتوانند از vNUMA یا همان NUMA مجازی سود ببرند.
Microsoft SQL Server یک نمونه از برنامههای کاربردی با توجه به NUMA میباشد. ویژگیهای حافظهی دینامیک (Dynamic Memory) و NUMAی مجازی نمیتوانند به صورت همزمان مورد استفاده قرار گیرند. یک ماشین مجازی که حافظهی دینامیک را فعال کرده باشد، به طور موثر تنها یک NUMA Node مجازی دارد و هیچ توپولوژی NUMAیی بدون درنظر گرفتن تنظیمات NUMAی مجازی، به ماشین مجازی ارائه نمیگردد.همچنینHypervisor، حافظهی فیزیکی Guest را مجازیسازی مینماید تا ماشینهای مجازی را از یکدیگر مجزا نماید و یک فضای حافظهی Zero-based و پیوسته برای هر سیستم عامل Guest، همانند سیستمهای مجازیسازینشده، ارائه کند.
جهت مشاوره رایگان و یا راه اندازی زیرساخت مجازی سازی دیتاسنتر با کارشناسان شرکت APK تماس بگیرید. |
ارزیابی صحیح حافظه برای بخشبندیهای Child
شخص باید حافظهی ماشین مجازی را اندازهگیری نماید، همانگونه که معمولا برای برنامههای کاربردی سرور روی یک سیستم فیزیکی انجام میدهد باید آن را اندازهگیری کند تا بار را به طور معقولی در ساعات پرمصرف و معمول کنترل کند زیرا حافظهی ناکافی ممکن است مصرف I/O یا CPU و زمان پاسخگویی را به طور قابل توجهی افزایش دهد.
فرد میتواند حافظهی دینامیک را فعال کند تا Windows را قادر سازد که به طور دینامیک و پویا حافظهی ماشین مجازی را اندازهگیری نماید. اگر برنامههای کاربردی در ماشین مجازی حین اختصاصدهیهای بزرگ و ناگهانی حافظه با مشکل مواجه شوند، با حافظهی دینامیک میتوان حجم Page File را برای ماشین مجازی افزایش داد تا پشتیبانی موقت را حین پاسخگویی حافظهی دینامیک به فشار حافظه، میسر نمود.
حین اجرای Windows در بخشبندی Child، میتوان تحت این بخشبندی از جدول محاسبهگر عملکرد ذیل استفاده نمود تا تشخیص داد که آیا بخشبندی Child با فشار حافظه مواجه است و احتمال عملکرد بهتر با حجم بالاتری از حافظهی ماشین مجازی وجود دارد یا خیر.
محاسبهگر عملکرد | مقادیر پیشنهادی آستانه (Threshold) |
حافظه – بایتهای Standby Cache Reserve | مجموع بایتهای Standby Cache Reserve و بایتهای Free and Zero Page List باید روی سیستمهایی با 1 گیگابایت Visible RAM، 200 مگابایت یا بیشتر و روی سیستمهایی با 2 گیگابایت Visible RAM یا بیشتر، 300 مگابایت یا بیش از 300 مگابایت باشد. |
حافظه – بایتهای Free & Zero Page List | مجموع بایتهای Standby Cache Reserve و بایتهای Free and Zero Page List باید روی سیستمهایی با 1 گیگابایت Visible RAM، 200 مگابایت یا بیشتر و روی سیستمهایی با 2 گیگابایت Visible RAM یا بیشتر، 300 مگابایت یا بیش از 300 مگابایت باشد. |
حافظه – ورودی Page بر ثانیه (Pages Input/Sec) | میانگین برای یک بازهی زمانی یک ساعته، کمتر از 10 میباشد. |
ارزیابی صحیح حافظه برای بخشبندی Root
بخشبندی Root باید از حافظهی کافی برای ارائهی سرویسهایی نظیر مجازیسازی I/O، Snapshot ماشین مجازی و مدیریت برخوردار باشد تا از بخشبندیهای Child پشتیبانی نماید. Hyper-V در Windows Server 2016 صحت عملکرد Runtime سیستم عامل مدیریت بخشبندی Root را مانیتور مینماید تا میزان حافظهی قابل اختصاصدهی ایمن به بخشبندیهای Child را، در حالی که همچنان از قابلیت اطمینان و عملکرد بالای بخشبندی Root اطمینان حاصل میکند، مشخص کند.
عملکرد I/Oی شبکهی Hyper-V
Server 2016 حاوی چندین بهبود و عملکرد جدید، جهت بهینهسازی عملکرد شبکه تحت Hyper-V میباشد. ثبت اسناد بر چگونگی بهینهسازی عملکرد شبکه در یکی از نسخههای آتی این مقاله، مورد بحث قرار خواهد گرفت.
Live Migration چیست؟
Live Migration این امکان را برای فرد فراهم میکند که به طور Transparent ماشینهای مجازی در حال اجرا را بدون هیچگونه قطع اتصال شبکه یا Downtime محسوسی، از Nodeی از یک کلاستر Failover به Node دیگری در همان کلاستر منتقل نماید.
Clustering Failover برای Nodeهای کلاستر به Shared Storage نیاز دارد. فرآیند انتقال یک ماشین مجازی در حال اجرا به دو فاز اصلی تقسیم میشود. فاز اول، حافظهی ماشین مجازی را از Host کنونی به Host جدید کپی میکند و فاز دوم، وضعیت ماشین مجازی را از Host کنونی به Host جدید انتقال میدهد. مدت زمان هردو فاز تا حد زیادی با سرعت انتقال دادهها از Host کنونی به Host جدید مشخص میگردد.فراهم کردن یک ارتباط شبکهی اختصاصی برای ترافیک Live Migration برای به حداقل رساندن زمان لازم برای تکمیل یک Live Migration مفید است و هماهنگی زمانهای Migration را تضمین مینماید.
به علاوه، افزایش تعداد بافرهای ارسال و دریافت روی هر آداپتور شبکهای که در Migration دخیل است، ممکن است عملکرد Migration را بهبود بخشد. در صورتی که سختافزار شخص بتواند پشتیبانی کند، Windows Server 2012 R2 قابلیتی را ارائه نمودهاست که برای سرعت بخشیدن به Live Migration حافظه را پیش از انتقال بر شبکه فشرده میکند و یا از (Remote Direct Memory Access (RDMA استفاده مینماید.