در بحث تنظیم و مانیتورینگ VAAI باید گفت vSphere نمی‌تواند تشخیص دهد که یک Datastore که Thin-Provision شده است، چقدر فضا مصرف می‌کند. اولین نشانه‌ای که باعث می‌شود یک ادمین متوجه شود یک Datastore بیش‌ازحد مورد استفاده قرار گرفته و دارای فضای قابل‌دسترسی نیست، این است که دیگر نمی‌توان ماشین‌های مجازی بیشتری را آماده‌سازی کرده و ماشین‌های مجازی متوقف می‌شوند. با این Primitive جدید، اگر یک Datastore که Thin-Provision شده است به آستانه‌ی به‌خصوصی برسد، هشداری از طریق یک VAAI در VMware vCenter منتشر می‌گردد. در صورت امکان، مقادیر این آستانه روی Array تنظیم می‌شوند و توسط ادمین Storage تعریف می‌گردند؛ vSphere این آستانه را تنظیم نمی‌کند. این امر به ادمین این توانایی را می‌دهد که به‌صورت فعال و پیشگیرانه Storage بیشتری را اضافه کند، Datastore را گسترش دهد یا یک عملیات Storage vMotion را اجرا نماید تا برای اجتناب از شرایط OOS، برخی از ماشین‌های مجازی را به خارج از Datastore منتقل کند. به‌طور پیش‌فرض به نظر می‌رسد که آستانه‌ی اکثر Arrayهایی که از این مبنا پشتیبانی می‌کنند 75 درصد است.
تنظیم و مانیتورینگ VAAI
در این بخش برخی از گزینه‌های قابل‌دسترسی برای تنظیم دقیق و مانیتورینگ مبناهای VAAI شرح داده می‌شود. این امر به ادمین‌ها کمک می‌کند که مشخص کنند آیا VAAI در محیط‌شان به‌درستی کار می‌کند یا خیر.
در ابتدا در مورد XCOPY صحبت می‌گردد، سایز پیش‌فرض XCOPY چهار مگابایت است. با یک I/O سی‌ودو مگابایتی، انتظار می‌رود که در یک شمارنده در Esxtop تعداد آیتم‌های کاری که برای ارائه‌ی یک I/O سی‌ودو مگابایتی ایجاد می‌گردد، دیده شود که به مرور به‌صورت هشت‌تایی بالا می‌رود. در صورت نیاز، می‌توان سایز پیش‌فرض XCOPY را به حداکثر 16 مگابایت رساند، اما این کار فقط باید تحت نظر Storage Array Vendor انجام گردد. دستور زیر نشان می‌دهد که چطور باید سایز انتقال کنونی را Query کرده و چطور باید آن را تغییر داد:
نکته ای که باید دقت کرد این است که حتماً باید در هنگام تغییر این پارامتر پیشرفته احتیاط لازم را به خرج داد. این پارامتر سراسری است پس روی تمام Arrayهای Storage که به Host متصل هستند تأثیر می‌گذارد. بااینکه ممکن است یک Storage Array Vendor پیشنهاد کند که این پارامتر تغییر نماید تا عملکرد روی Array به‌خصوص آن بهبود یابد، این کار می‌تواند منجر شود به مشکلاتی روی Arrayهای دیگر که به‌خوبی با این تغییرات جدید کار نمی‌کنند و عملکردشان کاهش پیدا می‌کند.
بافر Data-Out از دستور WRITE_SAME تماماً از صفر تشکیل شده است، یک عملیات صفر واحد دارای سایز Zeroing پیش‌فرض یک مگابایت است. حداکثر تعداد دستورات WRITE_SAME برجسته 32 عدد است، درحال‌حاضر از تغییر اندازه‌ی WRITE_SAME از یک مگابایت به اندازه‌ای دیگر پشتیبانی نمی‌شود.
می‌توان عملیات Clone (XCOPY)؛ عملیات ATS و Zero (WRITE_SAME) را در یک خروجی Esxtop مشاهده نمود. در ادامه یک خروجی Esxtop نمایش داده می‌شود که نشان‌گر مبناهای بلاک مختلف است:
برای مشاهده‌ی این خروجی در Esxtop، در ابتدا باید u را برای نمای دستگاه انتخاب کرده و سپس f را انتخاب نمود تا Fieldهایی که نمایش داده می‌شوند تغییر کند. گزینه‌های o و p آمار VAAI را نمایش می‌دهند. هر مبنا همچنین دارای ستونی برای آمار خرابی است، یعنی CLONE_F، ATSF و ZERO_F. این موارد باید برای هر عملیات دچار خرابی مانیتور شوند.
یکی از عوارض جانبی این است که Offloadهای VAAI می‌توانند به تحریف میزان تأخیر متوسط Kernel یا KAVG منجر شوند. وقتی دستورهای VAAI از طریق فیلتر VAAI منتشر می‌شوند، در حقیقت دو دستور ارسال می‌گردد. این دستورات، دستورات در لایه بالایی هستند که منتشر می‌شوند اما هرگز به دستگاه ارسال نمی‌گردند، بلکه در چارچوب VMkernel باقی می‌مانند. این دستورات توسط فیلتر VAAI و افزونه‌ی VAAI رهگیری شده و توسط دستورات مخصوص به Vendor که به دستگاه ارسال می‌شوند، جایگزین می‌گردند.
بیشتر بخوانید: منظور از VMware vSphere APIs – Array Integration یا VAAI چیست؟ – قسمت اول
به همین دلیل، Esxtop آمار دستگاه را فقط برای دستورات در سطح بالا نشان می‌دهد. درنتیجه در مقایسه با نتایجی که در زمان غیرفعال بودن VAAI به‌دست آمده است، مقادیر تأخیر غیرعادی به نظر می‌رسند.
در این مورد، تأخیرهایی که در Esxtop مشاهده می‌شود را نباید به‌عنوان مشکلی در عملکرد تفسیر کرد، مگر اینکه علائم دیگری نیز وجود داشته باشند.
چک کردن پشتیبانی VAAI
این بخش فرایندی را توصیف می‌کند که برای بررسی وضعیت VAAI طی می‌شود، برای بررسی وضعیت VAAI، تعدادی از دستورات Esxcli در دسترس هستند. در یک خروجی قبلی، وضعیت ATS، وضعیت Clone (XCOPY)، وضعیت Zero (WRITE_SAME) و وضعیت Delete (UNMAP) تحت پشتیبانی معرفی شده‌اند. رابط کاربری vSphere نیز می‌تواند برای تائید پشتیبانی از VAAI مورد استفاده قرار بگیرد. درکل وضعیت VAAI در قسمت Hardware Acceleration در رابط کاربری، تحت یکی از وضعیت‌های Supported ،Not Supported یا Unkown نمایش داده می‌شود، همانطور که در شکل زیر مشاهده می‌شود:
وضعیت Hardware Acceleration توسط وضعیت پشتیبانی از مبناهای مختلف تعیین می‌شود. اگر ATS تحت پشتیبانی باشد، رابط کاربری Hardware Acceleration را تحت عنوان Supported نمایش می‌دهد.
اما اگر ATS، XCOPY و Zero هیچ‌کدام تحت پشتیبانی نباشند، Hardware Acceleration تحت عنوان Unsupported نمایش داده می‌شود.
تمام وضعیت‌های پشتیبانی دیگر، وضعیت Hardware Acceleration را به Unkown تنظیم می‌کنند که معمولاً وضعیتی است که تا شروع اولین Clone و عملیات Zero نمایش داده می‌شود. بسیاری از کاربران یک Eagerzeroedthick Clone از یک فایل را راه‌اندازی می‌کنند تا وضعیت VAAI را تست نمایند.
در vSphere 6.5 نیز VMFS6 Datastore یک Space Reclamation Field را نمایش می‌دهد. این امر نشان می‌دهد که آیا UNMAP خودکار قابل‌دسترسی هست یا خیر. در vSphere 6.5، تنها اولویت Space Reclamation روی Low است و نمی‌توان این مورد را تغییر داد.
فعال‌سازی و غیرفعال‌سازی مبنای VAAI
این بخش روی فعال‌سازی و غیرفعال‌سازی انواع مختلف مبناهای VAAI تمرکز دارد. برای غیرفعال‌سازی برخی از مبناهای بلاک VAAI مثلاً برای هدف عیب‌یابی باید از دستورات CLI زیر استفاده کرد که نشان می‌دهند چطور می‌توان مبناهای VAAI را فعال و غیرفعال نمود.
ATS
برای چک کردن وضعیت مبناهای ATS و روشن و خاموش کردن دستور خط، می‌توان دستورات زیر را مورد استفاده قرار داد:
XCOPY
برای روشن و خاموش کردن مبنای Extended Copy برای Cloning، باید از دستورات قبلی با تنظیمات پیشرفته‌ی زیر استفاده نمود:
WRITE_SAME
برای روشن و خاموش کردن مبنای Write Same برای بلاک‌های Zeroing، باید از تنظیمات پیشرفته‌ی زیر استفاده کرد:
UNMAP
پیش از vSphere 6.5 و نسخه‌های قبلی VMFS، برای روشن و خاموش کردن مبنای UNMAP برای پس گرفتن فضا، باید از تنظیمات پیشرفته‌ی زیر استفاده می‌شد:
برای VMFS6 روی vSphere 6.5 تنظیمات پیشرفته‌ی دیگری وجود دارد:
در vSphere 4.1، می‌توان تعریف کرد که یک ESXi Host هر چند وقت یک بار تائید می‌کرد که تسریع سخت‌افزار روی Storage Array قابل پشتیبانی هست یا خیر.
بیشتر بخوانید: VMware vSphere VMFS چیست؟ معرفی و بررسی عملکردها و قابلیت های آن – قسمت اول
این یعنی اگر در پیاده‌سازی ابتدایی، یک Array از مبناهای Offload پشتیبانی نکند، اما در تاریخ دیگری Firmware روی Arrayها ارتقا پیدا کند و مبناهای Offload تحت پشتیبانی قرار گیرند، هیچ کاری نباید در مورد ESXi انجام شود، زیرا به‌طور خودکار شروع به استفاده از مبناهای Offload می‌کند.
این مقدار مربوط است به تعداد درخواست‌های I/O که پیش از اقدام به یک Offload دیگر رخ می‌دهند. با سایز 32MB از I/O، باید پیش از اینکه یک مبنا VAAI کنار گذاشته شود، 512GB از I/O جریان پیدا کند.
همین امر برای خرابی یک Offload نیز صدق می‌کند. اگر Array برای یک عملیات Offload به وضعیت خرابی بازگردد، Data Mover نرم‌افزاری برای ادامه‌ی عملیات مورد استفاده قرار خواهد گرفت. پس از اینکه 16384 درخواست I/O دیگر با استفاده از Data Mover نرم‌افزاری انجام شدند، دوباره برای VAAI Offload اقدام صورت می‌گیرد.
HardwareAcceleratedMoveFrequency فقط در vSphere 4.1 وجود دارد. در نسخه‌های بعدی از vSphere، این پارامتر با یک وضعیت VAAI دوره‌ی جایگزین شده بود که هر پنج دقیقه اجرا می‌شد.
