در قسمت اول مقاله در مورد ویژگی های vSphere 7 و VMware NVMeoF صحبت کردیم و توضیح داده شد که منظور از NVMeoF over RDMA چیست؟ حال به ادامه مقاله خواهیم پرداخت.
استفاده از Flag رزروشده برای RDMهای ESFC
در مواردی که کاربران از چندین pRDM در محیط خود استفاده میکنند، Boot مربوط به Hostها یا اسکنهای مجدد Storage ممکن است زمان زیادی ببرد. دلیل طولانیتر شدن زمانهای اسکن این است که هر LUN متصل به یک Host در زمان Bootشدن یا درطول اسکن مجدد Storage، اسکن میشود. معمولاً RDMها برای Microsoft WSFC به VMها ارائه میشوند، مستقیماً توسط Host مورد استفاده قرار نگیرند. درطول اسکن، ESXi برای خواندن پارتیشنها روی تمام دیسکها تلاش میکند، اما نمیتواند برای دستگاههایی که بهطور توسط ESFC رزرو شدهاند خواندن را انجام دهد. درنتیجه برای Host بیشتر طول میکشد که Storage را Boot یا اسکن مجدد کند. WSFC از رزرو دائمی SCSI-3 استفاده میکند تا قفل کردن بین Nodeهای WSFC را کنترل کند که به Hostها اجازه نمیدهد بتوانند آنها را بخوانند.
VMware پیشنهاد میکند که رزروهای دائمی برای تمام ESXi Hostهایی که Nodeهای VM را با pRDMها Host میکنند، به کار گرفته شود. سپس این سؤال پیش میآید که چطور میتوان کاری کرد که Host این RDMها را اسکن نکند و زمان Boot و اسکن مجدد را کاهش دهد؟ سؤال خیلی خوبی است!
یک Device Flag به نام Perennially Reserved وجود دارد که به Host میگوید که RDM نباید اسکن شود و جای دیگری در محیط مورد استفاده قرار گرفته شده است. پیش از vSphere 7، این Flag از طریق CLI فعال میشد و نیازمند UUID و یا naa.ID بود.
جهت مشاوره رایگان و یا راه اندازی زیرساخت مجازی سازی دیتاسنتر با کارشناسان شرکت APK تماس بگیرید. |
با انتشار vSphere 7، امکان تنظیم Perennially Reserved Flag به True، تحت دستگاههای Storage به رابط کاربری اضافه شد. همچنین یک Field اضافه شده است که تنظیمات کنونی را برای Perennially Reserved Flag نشان میدهد.
وقتی که انتخاب کنیم RDM به Perennially Reserved تنظیم شود، این امکان را داریم که دستگاه انتخابی را برای Host کنونی یا چندین Host در کلاستر، بهعنوان Perennially Reserved علامتگذاری نماییم. این کار فرایند دستی تنظیم گزینه به ازای هر Host از طریق CLI را حذف میکند. اگر کاربری دوست داشته باشد، هنوز میتواند ازESXCLI ، PowerCLI یا Host Profiles استفاده کند. وقتی که روی YES کلیک شود، Flag به True تنظیم میگردد و رابط کاربری بروزرسانی میشود. همچنین میتوان با استفاده از همین فرایند، دستگاه را Unmark نمود.
تصویری از این فرایند بصورت زیر می باشد:
تنظیم Perennially Reserved Flag روی pRDMهای مورداستفاده توسط WSFC در راهنمایهای کلاسترینگ پیشنهاد میشود. وقتی این گزینه تنظیم شده باشد، ESXi دیگر سعی نمیکند دستگاهها را اسکن کند و این امر میتواند زمانهای اسکن مجدد Storage و Boot را کاهش دهد. یکی دیگر از مزیتهای Flag کردن RDMها این است که میتوان به سادگی دید کدام دستگاهها RDM هستند و کدام دستگاهها RDM نیستند.
شرح کلی و پیاده سازی VMها
برخی از مزایای پیادهسازی VMها بهعنوان Thin Provisioned VMDKها شامل استفادهی کارآمد از فضا و احیاء مجدد فضا است. یک Thin VMDK فایلی روی VMFS است که در آن Small File Blockها یا SFBها بهصورت On-Demand در زمان اولین Write IO تخصیص داده میشوند. این فرایند میتواند دارای هزینهی سربار باشد که ممکن است روی عملکرد تأثیر بگذارد. در برخی از موارد، برای حداکثر عملکرد پیشنهاد میشود که از دیسکهای Eager Zero Thick یا EZT استفاده شود تا از سربارِ تخصیص فضا برای دادههای جدید اجتناب گردد.
فرایند اولین Write در بررسی ویژگی های vSphere 7
در VMFS منابع روی دیسکها مرتب میشوند و در گروههایی به نام Resource Clusters یا کلاسترهای منبع یا RC قرار میگیرند. وقتی فایلی نیازمند منابع Storage جدید باشد یعنی دادههای جدیدی که باید نوشته شوند، دو تصمیم باید اتخاذ گردد.
1. کدام RC باید منابع را به دست آورد.
2. کدام منابع از RC باید تخصیص داده شوند.
Affinity Manager یکی از اجزای VMSF6 است که مسئول تخصیص RC میباشد. فرایند Map کردن یک منبع به یک RC ،Affinitizing نام دارد. VMFS یک Storage اشتراکی است و چندین Host میتوانند بهصورت موازی درخواست منابع کنند. تخصیصهای منابع با استفاده از یک قفل روی دیسک ATS و بدون ارتباط دیگری بین Hostها هماهنگسازی میشوند. این امر میتواند باعث شود که مشکلاتی درطول فرایند تخصیص به وجود بیاید. Resource ManagerازAffinity manager درخواست RC میکند، سپس Affinity manager به لایه فایل VMFS پاسخ میدهد.
Affinity 2.0 Manager جدید در بررسی ویژگی های vSphere 7
در بررسی ویژگی های vSphere 7، ویژگی Affinity 2.0 معرفی میگردد که طوری طراحی شده است که در تخصیص منابع هوشمندتر و کارآمدتر باشد تا سربار در مسیر IO به حداقل برسد. برای اینکه این مهم حاصل شود، یک نما از وضعیت تخصیص منابع RCها در وسعت کلاستر ایجاد میگردد که فضای دیسک را به چند حوزه تقسیم مینماید. سپس آنها براساس تعداد Blockهایی که توسط Host کنونی و همچنین Hostهای دیگر، تخصیص داده میشوند رتبهبندی میگردند. این اطلاعات «Region Map» نام دارد. با Region Map، اکنون Affinity Manager میتواند به سرعت اطلاعات روی RCهای قابلدسترسی را برای Resource Manager فراهم نماید.
همهی این موارد چه معنایی دارند؟ وقتی که Resource Manager از Affinity Manager جدید، RCها را درخواست میکند، Affinity Manager با Region Map میداند که کدام منابع RC در کجا قابلدسترسی هستند و میتواند بهسرعت Resource Manager را هدایت کند. درخواست Resource از فایل VMFS اکنون مستقیماً به Affinity Manager میرود. Affinity Manager به Region Map ایجاد شده تکیه میکند تا یک RC قابلدسترسی را برای تخصیص دادن پیدا کرده، سپس RC روی دیسک را قفل میکند، بررسی میکند تا منابع آزاد را پیدا کند و آن را به Resource Manager تحویل میدهد. این امر پرسش و پاسخ تکراری بین Affinity Manager و Resource Manager برای پیدا کردن یک RC قابلدسترسی را کاهش میدهد. درنتیجه سربار موردنیاز برای اولین Write روی دیسکهای Thin-Provisioned کاهش پیدا میکند، همچنین ممکن است تخصیص فضا برای آمادهسازی EZT یا LZT بهبود پیدا کند.
End Of Availability (EOA) vFRC و CBRC 1.0: با انتشار vSphere 7، چند ویژگی قدیمی به پایان دسترسپذیریی رسیدهاند.
vSphere Flash Read Cache (vFRC) EOL: در حال حاضر vFRC دارای حداقل تعداد کاربر است. با VAIO به Vendorهای Third-Party اجازه میدهد که راهکارهای Caching سفارشی بسازند. وقتی که ارتقا به vSphere 7 انجام شود، یک پیام هشدار دریافت میگردد که میگوید vFRC دیگر در دسترس نخواهد بود. vFRC با این ارتقا حذف خواهد شد، هرکسی که روی یک VM از vFRC استفاده میکند باید آن را غیرفعال نماید.
CBRC 1.0 دارای حداکثر اندازهی Cache دو گیگابایت است، درحالیکه این اندازه برای 2.0 سیودو گیگابایت میباشد. از vSphere 6.5 به بعد، CBRC 2.0 برای Content-Based Read Cache پیشفرض خواهد بود و همچنین از vSphere 7 به بعد، CBRC 1.0 حذف شده است تا اطمینان حاصل گردد که مورد استفاده قرار نمیگیرد، بهخصوص در محیطهای Horizon. این امر همچنین نیاز به ساخت و جمعآوری کدهای بدون استفاده را از میان برمیدارد.
قابلیت همکاری vVols با محصولات VMware
استفاده از VMware Virtual Volumes یا vVols بهطور روزافزونی درحال افزایش است و در سال 2020 هم تسریع شده است. دلیل این امر واضح است، vVols نیاز به مدیریت LUN را از بین میبرد، پیادهسازیها را تسریع میکند، عملیات را تسهیل مینماید و امکان استفاده از تمام عملکردهای Array را نیز ایجاد مینماید. VMware همچنان vVols و عملکردهای آن را توسعه داده و آن را جلو برده، در vSphere 7، ویژگیها و بهبودهای بیشتری اضافه شدهاند که نشاندهندهی تعهد متداوم این شرکت به این برنامه است.
پشتیبانی از vVols در SRM 8.3
Site Recovery Manager – SRM
ازآنجاییکه vVols از همسانسازی مبتنی بر Array استفاده میکند، بسیار کارآمد بود و همسانسازی مبتنی بر Array روشی است که برای همسانسازی دادهها به Arrayها ترجیح داده میشود. با vVols و SPBM، میتوان به سادگی مدیریت نمود که کدام VM همسانسازی شود، نه اینکه همه چیز در یک Volume یا LUN همسانسازی گردد. با انتشار Site Recovery Manager 8.3، اکنون میتوان فرایند DR را با SRM مدیریت نمود، درحالیکه از کارآمدی همسانسازی و Granularity متعلق به vVols و SPBM استفاده میشود.
پشتیبانی از vVols برای CNS
Cloud-Native Storage – CNS
استفاده از Kubernetes بهطور روزافزونی در حال افزایش است و VMware در این زمینه پیشرو میباشد. یکی از الزامات K8، Persistent Storage است و تا کنون این امر شامل vSAN ،NFS و VMFS میشد. نکته اینجاست که vVols کاملاً مناسب K8 Storage است،
پشتیبانی از vVols در vRealize Operations 8.1
vRealize Operations – vROps
یک ویژگی که مدت زیادی است درخواست میشد، پشتیبانی برای Datastoreهای vVols در vROpsمی باشد، با انتشار vROps 8.1، اکنون میتوان از مانیتورینگ vROps روی Datastoreهای vVols مثل هر Datastore دیگری استفاده نمود. این کار هشداردهی، برنامهریزی، عیبیابی و ویژگیهای دیگری را برای Datastoreهای vVols به ارمغان میآورد.
بیشتر بخوانید: نگاهی فنی به Site Recovery Manager یا SRM، بررسی ویژگی ها و مزایای آن – قسمت اول
vVols بهعنوان Storage تکمیلی در VCF در بررسی ویژگی های vSphere 7
VMware Cloud Foundation به سازمانها این توانایی را میدهد که Cloudهای خصوصی و عمومی خود را پیادهسازی و مدیریت کنند VCFدرحال حاضر از Storage اصلی NFS، vSAN و VMFS پشتیبانی کرده، کاربران درخواست پشتیبانی از vVols بهعنوان Storage اصلی را دارند و بااینکه تیم VCF همچنان این گزینه را ارزیابی کرده و توسعه میدهد، هنوز در دسترس نیست. در همین زمان، پس از اینکه ساخت Workload Domain به اتمام رسید، میتوان vVols را بهعنوان Storage تکمیلی مورد استفاده قرار داد.