دستور TRIM در vSphere چیست؟ چرا مورد نیاز است؟

دستور TRIM چیست؟ در vSphere 6.0 بهینه‌سازی های بیشتر UNMAP باعث تسهیل بازیابی فضای محبوس از داخل Guest OS شد. اکنون این قابلیت برای Guest OS دارای Thin Provisioned VMDK وجود دارد تا بطور موثر ذخیره‌ساز پشتیبان را آگاه ساخت که بلاک‌ها می‌توانند بازیابی شوند، بازگردند و اندازه VMDK را کاهش دهند. 

در ابتدا پشتیبانی In-Guest UNMAP جهت بازیابی Native فضای مرده In-Guest تنها محدود به Windows 2012 R2 بود. توزیعات Linux نتوانست به واسطه نسخه SCSI بکار رفته در Virtual Hardware و SCSI نسخه 2 بازیابی In-Guest را انجام دهد. توزیعات Linux نسخه SCSI را بررسی کرده و تا زمانی که نسخه 5 یا بالاتر نباشد UNMAPها را ارسال نمی‌نماید. با پشتیبانی SPC-4 که در vSphere 6.5 برای Virtual Hardware معرفی شده، اکنون Linux Guest OSها قادرند تا UNMAPها را صادر نمایند.

یک Best Practice این است که بخش‌بندی‌های  Guest OS به حد Granularity یک مگابایت برسند. اگر Guest OS Filesystem به این حد نرسد، UNMAPها ممکن است به درستی کار نکنند.

برای توزیعات Linux، فرمان fstrim می‌تواند برای بازیابی دستی فضای مرده از درون Guest OS مورد استفاده قرار گیرد. به منظور انجام اینکار بصورت خودکار، Filesystem مورد نظر باید با قابلیت –O Discard نصب شود. با این قابلیت، همانطور که فایل‌ها از Filesystem حذف می‌شوند، OS بطور خودکار درخواست‌های Discard را صادر می‌کند.

نکته آخر درباره UNMAPهای In-Guest این است که اگر در نسخه‌های پیش از vSphere 6.5 ،Change Block Tracking یا CBT در ماشین مجازی فعال بود آنها کار نمی‌کردند. CBT می‌توانست برای پشتیبان‌گیری یا همسان‌سازی ماشین مجازی مورد استفاده قرار گیرد. در vSphere 6.5 ،In-Guest UNMAP درصورت فعال بودن CBT در ماشین مجازی نیز کار می‌کند و این یک پیشرفت بزرگ است.

ملاحضات دستور TRIM چیست؟

دستور TRIM چیست؟ TRIM معادل ATA SCSI UNMAP است، عملیات TRIM در Stack ،I/O که SCSI است به UNMAP تبدیل می‌شود. با این‌حال، مشکلاتی پیرامون تبدیل TRIM به UNMAP وجود دارد. UNMAP در محدوده بلاک خاصی از VMFS عمل می‌کند اما TRIM چنین محدودیتی ندارد. درحالی که این مورد باید در VMFS-6 که اکنون با 4K هم‌راستا شده بدون مشکل باشد، تبدیل برخی TRIMها به UNMAPها به دلیل مشکلات هم‌راستایی بلاک در نسخه‌های قبلی VMFS با شکست مواجه شد.  

VAAI NAS Primitives: این بخش کارکردها و قابلیت‌های انواع مختلف VAAI NAS Primitives را توضیح می‌دهد. پیش از vSphere 5.0، VMware از شتاب‌دهی سخت‌افزار در تجهیزات ذخیره‌ساز بلاک پشتیبانی می‌نمود. با انتشار vSphere 5.0 ،VMware تعدادی از Primitiveهای شتاب‌دهی سخت‌افزار جدید NAS را لحاظ نمود. برخلاف Primitiveهای Block، Primitiveهای VAAI NAS تنها از طریق استفاده از یک Plug-In VAAI-NAS Vendor که توسط Vendor مربوط به Array ذخیره‌ساز NAS ارائه می‌شود قابل دسترسی هستند.

بیشتر بخوانید: منظور از VMware vSphere APIs – Array Integration یا VAAI چیست؟ – قسمت اول

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 پشتیبانی‌شده است.

در 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 ذخیره‌ساز خود، دیدگاه بهتری به مصرف منابع ذخیره‌ساز داشته باشند.

بیشتر بخوانید: راهکار پشتیبان گیری از NAS Storage با استفاده از Veeam

در نسخه‌های قبلی vSphere، تنها یک Thin VMDK می‌توانست در Datastoreهای NAS ایجاد شود. Primitive جدید حفظ فضا ایجاد فایل‌های Thick VMDK را در Datastoreهای NAS ممکن می‌سازد، بنابراین مدیران می‌توانند تمامی فضای مورد نیاز VMDK را حفظ کنند حتی اگر Datastore متعلق به NAS باشد. همانطور که در شکل زیر نمایش داده شده، کاربران اکنون این قابلیت را دارند تا دیسک‌های Lazy-Zero یا Eager-Zero را در Datastore مربوط به NAS انتخاب کنند.

آماده‌سازی Thick-Disk در Datastoreهای NFS

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 پشتیبانی بیشتری شود.

Thin Provisioning Stun: زمانی که استفاده از  Thin Provisioned Datastore به 100 درصد از ظرفیت رسید، اولین بهینه‌سازی جهت رسیدگی به مشکلات مربوط به تاثیر ماشین‌های مجازی معرفی شد. پیش از آن این امر تمامی ماشین‌های مجازی فعال در Datastore را تحت تاثیر قرار داد. با انتشار Primitive مربوط به vSphere 5.0 VAAI Thin Provisioning، اگر مصرف Thin Provisioned Datastore به 100 درصد می‌رسید تنها آن دسته از ماشین‌های مجازی که نیازمند بلاک‌های اضافی ذخیره‌ساز بودند متوقف می‌شدند و سایرین به فعالیت خود ادامه می‌دادند. پس از آن که فضای اضافی به Thin Provisioned Datastore اختصاص داده شد، ماشین‌های مجازی متوقف شده می‌توانند دوباره آغاز به فعالیت کنند.