بازگرداندن فضای دیسک با VMware vSphere و HPE Storage

امکان بازیابی فضای دیسک با استفاده از VMware vSphere UNMAP و HPE 3PAR و Nimble Storage برای کاربر، با هدف دستیابی به بیشترین کارایی از ظرفیت فضای ذخیره سازیتوانایی بازگرداندن Storage ارائه شده، یک قابلیت مهم در vSphere است که Storage Arrayها را قادر می‌سازد تا با حداکثر کارایی عمل کرده و همچنین اطمینان حاصل می‌کند که فضایی که قبلا استفاده شده، دوباره قابل استفاده باشد. فرایند بازگردانی حافظه که UNMAP نامیده می شود، یک دستور SCSI است که توسط Storage Arrayها برای بازگردانی Disk Blockهایی که اطلاعات‌شان حذف شده استفاده می‌شود. فرمان UNMAP به طور معمول توسط میزبان صادر می‌شود و برای Storage Arrayها دقیقا مشخص می‌کند که کدام Disk Blockها حاوی داده‌های حذف شده می‌باشند که بدین ترتیب Storage Array می‌تواند آن‌ها را  Unallocate کرده، و در نتیجه مقدار فضای آزاد موجود درStorage  افزایش می‌یابد.

دلیل اینکه Storage Array به فرمان میزبان برای بازگرداندن فضای حافظه نیاز دارد این است که Storage Arrayها از داخل File System، چه Windows File System باشد و چه VMFS Datastore، اطلاعی نداشته و اساسا هیچ نظارتی بر اتفاقاتی که داخل یک LUN می‌افتد ندارند. در نتیجه، هیچوقت نمی‌دانند چه زمانی فایل‌ها و یا VMها حذف شده و یا بر روی چه Disk Blockی ساکن هستند. به همین دلیل آن چیزی که File System را مدیریت می‌کند (برای مثال Windows و یا ESXi) باید به Storage Array اطلاع دهد که چه زمانی اطلاعات حذف شده می‌توانند دوباره استفاده شوند.

نحوه بازگرداندن فضای Storage Array توسط vSphere

بازگردانی فضای دیسک بسیار مهم می‌باشد. vSphere چندین عملیات مختلف را که به پاک شدن اطلاعات بر روی Storage Array منجر می‌شوند ارائه نموده است. این عملیات‌ها شامل اجرای Storage vMotion می‌باشد، که در آن یک VM از یک Datastore به دیگری انتقال می‌یابد، وقتی که VM Snapshotها حذف می‌شوند و وقتی که VMها حذف می‌گردند. از بین این عملیات‌ها Storage vMotion بیشترین تاثیر را بر روی Thin Provisioning دارد، زیرا در این عملیات، Diskهای مجازی به طور کامل در میان Diskها جابجا می‌شوند که موجب هدر رفتن فضای زیادی می‌گردد که غیر قابل بازگردانی می‌باشد. به علاوه زمانی که داده در یک VM که Thin Provision شده است حذف می‌شود، با فرستادن فرمان‌های UNMAP توسط سیستم عامل Guest به Storage Arrayها می توان از فضای ذخیره سازی آزاد مجددا استفاده نمود.

اجرای UNMAP بر روی Disk Blockها می‌تواند یک عملیات سنگین و زمان‌بر برای Storage Arrayها باشد و به همین دلیل رفتار عملیات UNMAP در طول انتشار نسخه‌های مختلف vSphere، از معرفی‌اش در vSphere 5.0 بسیار تغییر کرده است. UNMAP در ابتدا یک عملیات هم‌گام و هم‌زمان بود، به این معنی که Disk Blockها پس از حذف شدن اطلاعات در vSphere بی‌درنگ و به صورت Real-Time بازگردانی می‌شدند. به دلیل مشکلاتی که سریعا کشف شدند، فرایند UNMAP از vSphere نسخه‌ی 5.0 UI1 تا نسخه‌ی 6.0، به یک فرایند دستی تبدیل شد که باید توسط دستورهای CLI آغاز می‌شد. فرایند دستی موثر اما بسیار زمان‌بر، سنگین و کم بازده بود، به دلیل اینکه این فرایند به‌جای آنکه از فضاهایی که نیاز به بازگردانی داشتند آگاه باشد، یک Balloon File ایجاد کرده و سعی می‌کرد هرچه را که می‌تواند بازگردانی کند.

سرانجام در vSphere نسخه‌ی 6.5، فرایند UNMAP دوباره به یک عملیات خودکار تبدیل شده، با این تفاوت که این بار غیر هم‌گام می‌باشد، به این معنی که Disk Blockها بی‌درنگ و به صورت Real-Time بازگردانی نشده بلکه توسط یک عملیات پس‌زمینه با نرخ ثابت پایین (25 مگابایت بر ثانیه) بازگردانی می‌شوند. این یک تغییر خوشایند و بسیار مورد انتظار بود، به این ترتیب که سرانجام vSphere دقیقا Disk Blockهایی که باید بازگردانی شوند را به Storage Array معرفی می‌کرد، فقط عملیات بازگردانی با یک سرعت پایین انجام می‌شد. در vSphere نسخه 6.7 این عملیات با ارائه گزینه‌ی تغییر نرخ بازگردانی که توسط کاربر قابل پیکربندی است بازهم بسیار بهبود یافت و در نتیجه امکان کنترل کردن سرعت معرفی Disk Blockهایی که باید بازگردانی شوند ممکن شد. در vSphere Client می‌توان نرخ بازگردانی را از 100 تا 2.000 مگابایت بر ثانیه تنظیم کرد. اما در صورتی که برای بازگردانی عجله‌ای وجود نداشته باشد، توصیه می‌شود که نرخ بازگردانی را پایین نگه داشته تا اثرات عملیات UNMAP بر روی بار کاری VM کاهش یابد. در صورتی که فضای Disk به اندازه کافی وجود داشته باشد و نیازی به بازگردانی نباشد، می‌توان این عملیات را به کلی غیرفعال نمود تا هیچ تاثیری از اجرای UNMAP بر منابع گذاشته نشود.

نکته‌ی قابل ذکر دیگر این است که اجرای UNMAP در سطح VM (نه در سطح سیستم عامل میهمان) فقط در صورت استفاده از VMFS Datastore‌‌ها امکان پذیر می‌باشد. با استفاده از قابلیت جدید VMware Virtual Volumes و یا (VVols)، دیگر نیازی به اجرای UNMAP در سطح VM نمی‌باشد، زیرا در این نوع معماری Storage Array از Disk Blockهایی که VM بر روی آن‌ها قرار دارد کاملا مطلع است، به این دلیل که VMهای به صورت Native و بدون File System بر روی Disk Array نوشته می‌شوند. همچنین دیگر لازم نیست vSphere به Host بگوید که چه Disk Blockهایی را UNMAP کند، به این دلیل که Storage Array آگاهی کامل دارد و می‌تواند با هر نرخی که می‌خواهد فضا را بازگردانی کند. با VVols، Storage Arrayها بسیار پربازده‌تر خواهند بود، زیرا تمام عملیات‌های Provisioning و بازگردانی به صورت پویا انجام خواهند شد.

چه از VMFS و چه از VVols در فضای مهمان استفاده شود، بازگردانی برای سیستم عامل‌هایی که از آن پشتیبانی می‌کنند به صورت دقیق و جزئی‌تر قابل انجام می‌باشد. این امر از اهمیت ویژه‌ای برخوردار است زیرا vSphere هیچ اطلاعی از داخل File System سیستم عامل میزبان ندارد که بداند چه فایل‌هایی حذف شده‌‌اند. در صورت فرستادن فرمان‌های UNMAP توسط سیستم عامل میزبان، vSphere آن‌ها را به Storage Array می‌فرستد تا پردازش شوند و فضا را بازگردانی ‌کنند.

نقش HPE Storage در بازگردانی فضای ذخیره سازی

امکان بازگردانی فضای ذخیره سازی کاربر را قادر می‌سازد از ظرفیت Storage کارآمد‌ترین استفاده را داشته باشد و نیاز به افزایش ظرفیت را کاهش می‌دهد. به طور کامل از بازگردانی فضا در هر دو Storage Arrayهای HPE 3PAR StoreServ و HPE Nimble پشتیبانی می‌شود. در حقیقت، در مورد 3PAR، HPE یکی از اولین شرکت‌هایی بوده است که از روز اول انتشار این نوع Storage Array( بیش از هفت سال پیش با vSphere نسخه‌ی 5.0) از UNMAP پشتیبانی می‌کرده است.

در HPE، یک سنت طولانی برای حمایت از تمام قابلیت های VMware وجود داشته است. این امر تا امروز هم با پشتیبانی پیشرو در صنعت برای VVols به عنوان یک شریک VMware ادامه پیدا کرده است. چه UNMAP، چه VVols و چه افزونه‌های نرم‌افزاری برای VMware مدنظر باشد، HPE 3PAR و HPE Nimble پلتفرم‌هایی ایده آل با معماری مدرن برای Storage می‌باشند که با قادر ساختن کاربران در بهینه‌سازی زیرساخت‌های مجازی خود، تسهیل مدیریت Storage و کاهش هزینه‌های مجازی‌سازی، VMware ROI را بالا می‌برند.