پیش از vSphere 5.0 ،VMware از شتاب‌دهی سخت‌افزار در تجهیزات ذخیره‌ساز بلاک پشتیبانی می‌نمود. با انتشار vSphere 5.0، VMware تعدادی از Primitiveهای شتاب‌دهی سخت‌افزار جدید NAS را لحاظ نمود. برخلاف Primitiveهای Block ،Primitiveهای VAAI NAS تنها از طریق استفاده از یک Plug-In VAAI-NAS Vendor که توسط Vendor مربوط به Array ذخیره‌ساز NAS ارائه می‌شود قابل دسترسی هستند.
Full File Clone
Full File Clone یا Full Copy مشابه Primitive شتاب‌دهی سخت‌افزار Extended Copy یا XCOPY است که برای Arrayهای بلاک ارائه شده است. این Primitive به دیسک‌های مجازی این امکان را می‌دهد تا بجای Data Mover با NAS Array بتوانند Clone شوند؛ زیرا Data Mover از پهنای باند و منابع حافظه و CPU مربوط به ESXi Host استفاده می‌کند. یک تفاوت فاحش میان این Primitive و Primitive متعلق به XCOPY موجود دارد و آن این است که VAAI-NAS Primitive نمی‌تواند برای عملیات Storage vMotion که همچنان از Data Mover استفاده می‌کنند بکار گرفته شود. تنها ماشین‌های مجازی خاموش و انتقال یافته می‌توانند با استفاده از این Primitive به Array ذخیره‌ساز Offload کنند. فارق از محدودیت Storage vMotion، مزیت آن این است که عملیات Cold Cloneها یا Deploy From Template می‌توانند به سخت‌افزار ذخیره‌ساز Offload شوند و این باعث کاهش مصرف منابع ESXi Host می‌شود.
Fast File Clone/Native Snapshot Support
Fast File Clone باعث ایجاد Snapshotهای ماشین مجازی برای Offload شدن به یک NAS Storage Array می‌شود. این یک Primitive است که پایه VMware View Composer™ Array Integration یا VCAI که به عنوان یک پیش‌نمایش فنی در VMware Horizon View™ 5.1 منتشر شده بود را بنا می‌کند. VMware View Composer می‌تواند دسکتاپ‌ها را براساس Cloneهایی که بطور مستقیم ایجاد شده‌اند انتخاب کند بجای آنکه اینکار را با استفاده از حافظه و CPU متعلق به ESXi Host انجام دهد. این مهم بطور کامل در VMware Horizon View™ 5.3 پشتیبانی‌شده است.
بیشتر بخوانید: منظور از Data Mover نرم‌افزاری چیست؟ نحوه‌ی استفاده از آن برای انواع مختلف هشدارهای VAAI
در vSphere 5.1 این Primitive به VMware vCloud® vApps™ توسعه یافته که بوسیله آنVMware vCloud Director™ می‌تواند با استفاده از Array ذخیره‌ساز بجای ESXi Host، براساس Cloneهای لینک شده و نمونه‌سازی شده‌اند vCloud Appها را انتخاب کند.
آمارهای توسعه‌یافته
این Primitive در Datastoreهای NAS یک قابلیت دید بر استفاده از فضا را فراهم می‌کند که به ویژه برای Datastoreهای Thin-Provisioned مفید است زیرا به vSphere این امکان را می‌دهد تا آمار واقعی مصرف فضا را در شرایط Oversubscription نشان دهد. قبلا مدیران vSphere باید از ابزارهای مبتنی بر Array استفاده می‌کردند تا میزان فضای مصرفی یک Thin Provisioned VMDK در یک Datastore Back-End را مدیریت و مانیتور کنند. با این Primitive جدید، این اطلاعات می‌توانند در VMware vSphere Client™ نمایش داده شوند و چنین چیزی مدیران vSphere را قادر می‌سازد تا بدون وابستگی به ابزارهای Third-Party یا همکاری با مدیران مربوط به Array ذخیره‌ساز خود، دیدگاه بهتری به مصرف منابع ذخیره‌ساز داشته باشند.
حفظ فضا
در نسخه‌های قبلی vSphere، تنها یک Thin VMDK می‌توانست در Datastoreهای NAS ایجاد شود. Primitive جدید حفظ فضا ایجاد فایل‌های Thick VMDK را در Datastoreهای NAS ممکن می‌سازد بنابراین مدیران می‌توانند تمامی فضای مورد نیاز VMDK را حفظ کنند حتی اگر Datastore متعلق به NAS باشد. همانطور که در شکل زیر نمایش داده شده، کاربران اکنون این قابلیت را دارند تا دیسک‌های Lazy-Zero یا Eager-Zero را در Datastore مربوط به NAS انتخاب کنند.
VAAI Thin Provisioning Primitives
این بخش انواع مختلف VAAI Thin Provisioning Primitives را معرفی نموده و شرح می‌دهد که چرا Primitiveهای جدید اضافه شده‌اند. در محیط‌هایی که برای مدیریت و مانیتور کردن Datastoreها از Thin Provisioning استفاده شده، شکایات متعددی مبنی بر عدم آگاهی Array از آزاد شدن بلاک‌ها به هنگام حذف یا انتقال ماشین‌های مجازی از Datastore مطرح شده‌اند. این امر منجر می‌شود تا ابزارهای مدیریت Array فضای مصرفی بسیار بیشتر از آنچه واقعا مصرف شده را گزارش دهند. مشکلات Out-of-Space نیز بسیار شایع هستند. در گذشته شرایط OOS می‌توانست تمامی ماشین‌های مجازی درون Datastore Thin Provisioned مربوط به OOS را تحت تاثیر قرار دهد. جهت رسیدگی به این مشکلات بهینه‌سازی‌های بسیاری برای VAAI در vSphere 5.0 لحاظ شد. به همین جهت چندین Primitive جدید اضافه شدند تا از Thin Provisioning پشتیبانی بیشتری شود.
بیشتر بخوانید: نگاهی به تنظیم دقیق و مانیتورینگ مبناهای VAAI در vSphere
Thin Provisioning Stun
زمانی که استفاده از Thin Provisioned Datastore به 100 درصد از ظرفیت رسید، اولین بهینه‌سازی جهت رسیدگی به مشکلات مربوط به تاثیر ماشین‌های مجازی معرفی شد. پیش از آن این امر تمامی ماشین‌های مجازی فعال در Datastore را تحت تاثیر قرار داد. با انتشار Primitive مربوط به vSphere 5.0 VAAI Thin Provisioning، اگر مصرف Thin Provisioned Datastore به 100 درصد می‌رسید تنها آن دسته از ماشین‌های مجازی که نیازمند بلاک‌های اضافی ذخیره‌ساز بودند متوقف می‌شدند و سایرین به فعالیت خود ادامه می‌دادند. پس از آن که فضای اضافی به Thin Provisioned Datastore اختصاص داده شد، ماشین‌های مجازی متوقف شده می‌توانند دوباره آغاز به فعالیت کنند.
هشدار آستانه‌ی فضای آماده‌سازی Thin Provisioning
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 کرده و چطور باید آن را تغییر داد:
# esxcfg-advcfg -g /DataMover/MaxHWTransferSize
Value of MaxHWTransferSize is 4096
# esxcfg-advcfg -s 16384 /DataMover/MaxHWTransferSize
Value of MaxHWTransferSize is 16384 حتماً باید در هنگام تغییر این پارامتر پیشرفته احتیاط لازم را به خرج داد. این پارامتر سراسری است پس روی تمام Arrayهای Storage که به Host متصل هستند تأثیر می‌گذارد. بااینکه ممکن است یک Storage Array Vendor پیشنهاد کند که این پارامتر تغییر نماید تا عملکرد روی Array به‌خصوص آن بهبود یابد، این کار می‌تواند منجر شود به مشکلاتی روی Arrayهای دیگر که به‌خوبی با این تغییرات جدید کار نمی‌کنند و عملکردشان کاهش پیدا می‌کند
