Services یا vCLS یک ویژگی جدید در بروزرسانی از vSphere 7.0 است. این ویژگی اطمینان حاصل می‌کند که خدمات کلاستر مثل vSphere DRS و vSphere HA، همگی قابل‌دسترسی بوده تا منابع و سلامت بارهای کاری درحال‌اجرا در کلاسترها، مستقل از دسترس‌پذیری vCenter Server Instance حفظ شود. در بروزرسانی 1 از vSphere 7.0، یک پلتفرم منتشر شده است که کمک می‌کند این بارهای کاری به‌طور مستقل از دسترس‌پذیری vCenter Server Instance اجرا گردد. در این نسخه، VCenter Server هنوز برای اجرای خدمات کلاستر مثل VSphere DRS، vSphere HA و غیره مورد نیاز است.
راهکار
vCLS یک ویژگی اجباری است که وقتی vCenter Server به بروزرسانی 1 ارتقا می‌یابد یا پس از یک پیاده‌سازی تازه از بروزرسانی 1 از vSphere 7.0، باید روی هر کلاستر vSphere پیاده‌سازی گردد. Hostهای ESXi می‌توانند از هر نسخه‌ی قدیمی باشند که با بروزرسانی 1 از vCenter Server سازگاری داشته باشد.
بسته به سایز کلاستر، یک تا سه عدد vCLS VM روی هر کلاستر vSphere اجرا خواهد شد. vSphere DRS در یک کلاستری که دارای قابلیت DRS باشد بستگی به دسترس‌پذیری حداقل یک vCLS VM دارد، برخلاف VMهای برنامه کاربردی، باید با vCLS VMها مثل VMهای سیستم رفتار شود. نباید هیچ عملیاتی روی این VMها انجام گردد، مگر اینکه پشتیبانی VMware این را بگوید یا به‌طور مشخص به‌عنوان عملیات تحت پشتیبانی ذکر شده باشد.
بیشتر بخوانید: نحوه‌ی پاسخ vSphere HA و vSphere DRS به خرابی‌ها در محیط های کلاستر شده
امکان غیرفعال کردن vCLS روی یک کلاستر vSphere و فعال بودن vSphere DRS به‌طور هم‌زمان وجود ندارد. اما اگر لازم باشد، می‌توان با دنبال کردن قدم‌های مربوط به Retreat Mode که در ادامه شرح داده می‌شوند، vCLS را روی یک کلاستر غیرفعال کرد، اما این کار روی برخی از خدمات کلاستر برای آن کلاستر تأثیر خواهد گذاشت.
نکته: باید با احتیاط از Retreat Mode استفاده کرد و فقط باید برای اهدافی که در این مقاله بیان می‌شود مورد استفاده قرار گیرد. در ادامه، جزئیات خدمات کلاستر تحت تأثیر به دلیل فعال‌سازی Retreat Mode روی یک کلاستر بیان می‌گردد.
- اگر DRS روی کلاستری فعال باشد، vSphere DRS روی آن کلاستر عمل نخواهد کرد. این یعنی بارهای کاری که داخل آن کلاستر اجرا می‌شوند تعدیل بار نمی‌گردند، درنتیجه وقتی منابع Hostی که آن VM را اجرا می‌کند تمام شود، به Hostهای متفاوت درون کلاستر منتقل نخواهند شد. یا وقتی‌که کاربری بخواهد یک Host را قطع کند، VMهای در حال اجرا به‌طور خودکار به Hostهای دیگر درون آن کلاستر منتقل نخواهند شد.
- vSphere HA در یک سناریوی خرابی Host جایگذاری بهینه‌ای را انجام نمی‌دهد، زیرا HA برای پیشنهادات جایگذاری به DRS تکیه می‌کند. HA همچنان VMها را روشن می‌کند، اما ممکن است این VMها روی Hostی روشن شود که کمتر بهینه باشد.
شناسایی VMهای vCLS
- در رابط کاربری vSphere Client، نام‌گذاری VMها به‌صورت vCLS (<number>) است و بخش number به‌طور خودکار ایجاد می‌شود. تمام VMهای vCLS با دیتاسنتر یک vSphere Client در VMها و Template Tab مربوط به Client داخل VM و پوشه‌ی Templateها به نام vCLS قابل‌مشاهده هستند. برای مثال:
اگر روی خلاصه‌ی این VMها کلیک شود، یک بنر می‌بینیم که روی آن نوشته شده: vSphere Cluster Service VM برای حفظ سلامت vSphere Cluster Services ضروری است. وضعیت قدرت و منبع این VM توسط vSphere Cluster Services مدیریت می‌شود؛ همچنین یک لینک برای کسب اطلاعات بیشتر وجود دارد که کاربر را به مقاله‌ی مربوطه هدایت می‌کند.
- استفاده از vSphere Managed Object Browser یا MOB
شناسایی تمام VMهای vCLS برای یک دیتاسنتر مشخص
مثال‌هایی از MOB Query نمونه:
جایگزین کردن آدرس IP و Moid به یک vCLS VM در Queryهای نمونه‌ی زیر:
MOC Query نمونه، جایگزین کردن آدرس IP و Moid به یک پوشه‌ی VM به نام vCLS در Query نمونه
سایز VMهای vCLS
VMهای vSphere Cluster Service در مقایسه با VMهای بار کاری بسیار کوچک هستند. هر کدام از آن‌ها 1 vCPU و 128 MB حافظه و حدود 500 MB از Storage را مصرف می‌کند. جدول زیر مشخصات این VMها را نشان می‌دهد:
| حافظه | 128 MB |
| ذخیره‌ی حافظه | 100 MB |
| سایز مبادله (Swap Size) | 256 MB |
| CPU | 1 |
| ذخیره‌ی CPU | 100 MHz |
| Hard Disk | 2 GB |
| آداپتور اترنت | 0 (یک No NIC VM است) |
| سایز VMDK | -245 MB |
| فضای Storage | -480 MB |
vCLS در طول Maintenance زیرساخت
- Maintenance رایانش کلاستر
- وقتی‌که فقط یک Host وجود داشته باشد – وقتی‌که کلاستر Host واحد در Maintenance Mode قرار بگیرد VMهای vCLS به‌طور خودکار خاموش می‌شوند و جریان کاری Maintenance متوقف نمی‌گردد.
- وقتی‌که 2 یا چند Host وجود داشته باشد – در یک کلاستر vSphere که بیش از یک Host وجود داشته باشد و Hostی که برای Maintenance مورد نظر قرار می‌گیرد دارای VMهای vCLS در حال اجرا باشد، اگر منابع آزاد وجود داشته باشد و اگر این VMها اتصال Storage داشته باشند (Storage اشتراکی) این VMها به Hostهای دیگر منتقل می‌شوند. اگر به علت عدم دسترس‌پذیری منابع روی Hostهای دیگر نتوان این VMها را انتقال داد یا اگر این VMها در یک Local Datastore قرار داشته باشند، به‌طور خودکار خاموش می‌شوند تا عملیات Maintenance Mode در Host ترجیح داده شود. همانطور که قبلاً گفته شد، vSphere DRS برای یک کلاستر که در آن حداقل 1 vCLS VM وجود نداشته باشد، عملیاتی نخواهد بود.
بیشتر بخوانید: بررسی ویژگی ها و مفهوم Datastore Cluster و Storage DRS
- اگر یک کلاستر را از رده خارج کنیم، باید پیش از حذف کلاستر برای پاکسازی مناسب vCLS VMها، تمام Hostها را در Maintenance Mode قرار دهیم. اگر بدون قرار دادن Hostها در Maintenance Mode کلاستر را حذف کنیم، وقتی‌که Hostها با VMهای اجرایی به کلاستر جدیدی اضافه شوند، vCLS VMهای کهنه که درون Hostها اجرا می‌شوند مشکل ایجاد خواهند کرد.
- Host قطع شده – زمانی که اتصال Host قطع شود، VMهای vCLS از این Hostها پاکسازی نمی‌گردند، زیرا قطع شده‌اند و قابل‌دسترسی نیستند. VMهای vCLS جدید در Hostهای دیگر کلاستر ساخته نمی‌شوند، زیرا مشخص نیست که Host چه مدتی قطع خواهد بود. وقتی Host غیرمتصل، دوباره متصل گردد، vCLS VM در این Host دوباره روی vCenter Inventory ثبت می‌گردد. اگر یک Host غیرمتصل از Inventory حذف گردد، درصورتی‌که به حدنصاب (Quorum) رسیده نشود، ممکن است VMهای vCLS جدید در Hostهای دیگر با کلاسترهای سفارشی ایجاد گردند.
- Datastore Maintenance.
تعامل‌پذیری محصولات دیگر VMware
- SRM – انتقال برنامه‌ریزی‌شده
SRM 8.3.1 در بروزرسانی vSphere 7.0 تحت پشتیبانی نیست.
- vRealize Operations Manager
- بازیابی ظرفیت – جریان کاری بهینه‌سازی ظرفیت vRealize Operations Manager ممکن است VMهای vCLS را به‌عنوان VMهای بدون کاربرد تشخیص دهد و ممکن است آن‌ها را در پیشنهادات برای بازیابی ظرفیت قرار دهد. اگر VMهای vCLS به‌عنوان بخشی از جریان کاری بازیابی تشخیص داده شوند، سرویس vCLS دوباره این VMها را خواهد ساخت. اگر DRS قبل از بازگردانی VM اجرا شود، ممکن است وضعیت vCLS برای آن کلاستر ناسالم گردد. گزینه‌ی پیشنهادی این است که این VMها از جریان کاری بازیابی ظرفیت مستثنا شوند. این VMها را می‌توان از طریق نام‌شان vCLS یا با نگاه کردن به مشخصاتی که توضیح داده شد شناسایی کرد.
- خدمات بین کلاسترها – اگر به دلیل vCLS ناسالم، که WLP پیشنهاد می‌دهد جایگذاری بارهای کاری روی آن انجام شود، DRS روی کلاستر عملیاتی نباشد جریان‌های کاری vRealize Operation Manager Workload Placement یا همان WLP ممکن است تحت تأثیر قرار بگیرند.
- vSAN
رجوع شود به Datastore Maintenance.
- خودکارسازی vRealize
vCLS نباید روی هیچ جریان کاری همکار مثل پشتیبان‌گیری، مانیتورینگ و غیره تأثیر بگذارد. ازآنجایی‌که این VMها توسط vCLS مدیریت می‌شوند، هیچ دلیلی برای پیکربندی پشتیبان‌گیری روی این VMها وجود ندارد، زیرا بازیابی پشتیبان‌گیری در یک عملیات بازیابی ضروری نیست یا ممکن است دچار خرابی شود. این VMها را می‌توان با استفاده از APIهایی که در بخش شناسایی VMهای vCLS فهرست شده‌اند، شناسایی کرد.
- محصولات/راهکارها بدون هیچ مشکلی در تعامل‌پذیری
- VMware Cloud Foundation – Cloud Builder و SDDC Manager هیچ تأثیری نخواهند داشت، تأثیرات vRA، vROps و vSAN بالاتر بررسی شد.
- NSX Data Center برای vSphere
- NSX -T Data Center برای vSphere
- vCPP
- vCD
- vCDA
- vXRail
- Horizon Enterprise
ManagedByInfo
- extensionKey == “com.vmware.vim.eam”
- type == “cluster-agent”
etraconfig[HDCS.agent] = true
