در قسمت اول بیان کردیم بسته به سایز کلاستر، یک تا سه عدد vCLS VM روی هر کلاستر vSphere اجرا خواهد شد. vSphere DRS در یک کلاستری که دارای قابلیت DRS باشد بستگی به دسترسپذیری حداقل یک vCLS VM دارد، برخلاف VMهای برنامه کاربردی، باید با vCLS VMها مثل VMهای سیستم رفتار شود. در این قسمت به ادامه مقاله خواهیم پرداخت.
مشکلات شناسایی شده/موارد خاص
اگر کاربری سعی کند هر عملیات که تحت پشتیبانی نیست را روی VMهای vCLS اجرا کند ازجمله پیکربندی FT، قواعد DRS یا Overrideهای HA روی این VMها، Clone کردن این VMها یا انتقال آنها به یک Resource Pool یا vAppمیتواند روی سلامت vCLS برای کلاستر تأثیر بگذارد و این امر منجر میشود به اینکه DRS از حالت عملیاتی خارج گردد.
برخی از عملیات تحت پشتیبانی روی VMهای vCLS مربوط به انتقال این VMها به Hostها یا Datastoreهای دیگر و مرتبط کردن ویژگیهای سفارشی یا Tagها روی آنها میباشند. ازآنجاییکه بهمحض اضافه شدن اولین Host به یک کلاستر جدید، VMهای vCLS پیادهسازی میشوند، هر اسکریپت تست برای اعتبارسنجی کلاستر خالی در یک پیادهسازی Greenfield باید تغییر کند. این VMهای vCLS باید در بررسیهای ظرفیت کلاستر نادیده گرفته شوند.
- پیش از اینکه اولین vCLS VM برای کلاستر در یک کلاستر با DRS فعال روشن شود، اگر کاربر تلاش کند هر عملیاتی را انجام دهد که الگوریتم DRS را فعالسازی نماید، این عملیات قطع میشود. در ادامه عملیاتی فهرست میشوند که اگر DRS کاربردی نباشد، ممکن است دچار خرابی گردند:
- جایگذاری و روشن شدن یک VM بار کاری جدید.
- انتخاب Host برای یک VM که از یک کلاستر یا Host دیگر درون vCenter Server انتقال مییابد.
- VM منتقل شده میتواند روی یک Host انتخابی بدون DRS روشن شود.
- قرار دادن یک Host در Maintenance Mode ممکن است دچار توقف شود، اگر این Host دارای VM روشن باشد.
- فرا خواندن APIهای DRS مانند ClusterComputeResource.placeVm و ClusterComputeResource.enterMaintenanceMode ،InvalidState را دریافت خواهد کرد. عملیات زیر به سلامت vCLS بستگی نخواهد داشت، پس کاربر میتواند فارغ از پیادهسازی vCLS VM این عملیات را به انجام برساند.
- ایجاد Resource Pool.
- پیکربندی DRS مثل سطح خودکارسازی، Overrideها و غیره.
- ویرایش قواعد VM/Host.
- پیکربندی کلاستر vSphere with Tanzu Supervisor.
- ازآنجاییکه VMهای vCLS درست پس از اضافه کردن اولین مجموعه Hostها به کلاستر پیادهسازی میشوند، اگر Storage اشتراکی برای کلاستر هنوز پیکربندی نشده باشد، این VMها را میتوان در Local Datastoreها برای Hostها قرار داد. وقتی Storage اشتراکی برای این کلاستر پیکربندی شود، این VMها بهطور خودکار به این Storage منتقل نخواهند شد. VMwareپیشنهاد میکند که پس از پیکربندی Storage اشتراکی برای کلاستر، این VMهای vCLS بهطور دستی به یک Datastore اشتراکی منتقل شوند. اگر این VMها به Datastore اشتراکی منتقل نشوند، HA از آنها در مقابل خرابیهای Host حفاظت نخواهد کرد.
- نباید نسخهی سختافزاری از VMهای vCLS را بروزرسانی نمود. آنها در نسخهی 11 از HW نگهداری میشوند تا با vSphere 6.5 تطبیقپذیر باشند.
- تمام VMهای vCLS برای یک دیتاسنتر درون یک vCenter Server، در یک پوشهی بهخصوص به نام vCLS ذخیره میگردد. کاربران نباید این پوشه را حذف کنند یا نامش را تغییر دهند. چنین عملیاتی از نامگذاری یا حذف پوشه میتواند منجر شود به عدم موفقیت در ایجاد VMهای vCLS جدید برای کلاسترها که روی سلامت vCLS تأثیر میگذارد.
- ممکن است مواردی پیش بیاید که تعداد کمتری از VMهای بار کاری در یک کلاستر با HA فعال که با کنترل پذیرش پالیسی Slot پیکربندی میشود، روشن شوند.
- CPUای که توسط VMهای vCLS مصرف میشوند در صفحهی خلاصهی VM داخل vSphere Client نمایش داده نمیشود، زیرا این VMها کوچک هستند.
- در زمان Downsizing کلاسترها کاهش تعداد Hostها، ممکن است مواردی وجود داشته باشد که موارد بیشتر از نیاز از VMهای vCLS اجرا گردد. همچنین در این موقعیت، برخی یا همهی VMهای vCLS میتوانند در Host یکسانی قرار داشته باشند.
- VMهای vCLS که Orphaned شدهاند ممکن است بهعنوان VMهای بار کاری در Hostها پدیدار شوند و وقتی یک Host حاوی Orphaned VM به کلاستر اضافه شود، حرکت در کلاسترها، Clusters Navigation بهعنوان EAM این VMها را بهعنوان بخشی از پاکسازی حذف نمیکند.
- این VMها باید بهصورت دستی از vCenter Server Inventory لغو ثبت یا Unregister شوند.
- حذف کلاستر یا Host بدون قرار دادن Hostها در Maintenance Mode ممکن است برخی VMهای vCLS را در حالت Orphaned نگه دارد.
- وقتی چنین Hostهایی دوباره به کلاسترها اضافه میشوند، این VMها ممکن است با VMهای vCLS جدید تداخل پیدا کنند.
پیشنهاد میشود که با استفاده از یکی از روشهای زیر Hostهایی اضافه شود تا این مشکل برطرف گردد:
- اضافه کردن Host به VC Inventory بهعنوان یک Host مستقل و سپس انتقال آن به کلاستر.
- خاموش کردن تمام VMهایی که روی Host اجرا میشوند و سپس اضافه کردن Hostها.
- اضافه کردن Host به VC Inventory بهعنوان یک Host مستقل و سپس انتقال آن به کلاستر.
- VMهای vCLS را نمیتوان در Quarantine Mode که از سوی HA پیشگیرانه فعال میشود، تخلیه کرد.
- اگر DPM روی کلاستر پیکربندی شده باشد، وقتیکه vCLS VM روی یک Host اجرا شود، آن Host را نمیتوان در حالت Standby قرار داد، حتی وقتیکه هیچ VM بار کاری در حال اجرا نباشد.
- VMهای vCLS نمیتوانند روی Hostی اجرا شوند که vt-x در آن غیرفعال است. از آنجاییکه از نسخهی vSphere 6.7 به بعد، MMU منسوخ شده است، اجرای VMهای vCLS نیازمند این است که vt-x یا AMD-v همراه با پشتیبانی از جدول صفحهی Nested فعال باشد.
بیشتر بخوانید: نحوهی پاسخ vSphere HA و vSphere DRS به خرابیها در محیط های کلاستر شده
- اگر برای اینکه Hostهایی که توسط یک کلاستر در یک vCenter Server درحالاجرا مدیریت میشوند در Maintenance Mode قرار گیرند، از دستور esxcli استفاده شود و اگر این Host دارای VMهای vCLS باشد، Task مربوط به Maintenance Mode گیر خواهد کرد و درنتیجه اجرای CLI هم گیر میکند. راه حل این است که پسازاینکه CLI یا از طریق Login کردن به vSphere Client یا ESXi Host Client یا از طریق esxcli در یک Session جدید اجرا شد، VMهای vCLS خاموش شوند. خاموش شدن با موفقیت انجام میشود و وضعیت Host در حالتِ ورود به Maintenance Mode قرار میگیرد و هر عملیات روشن شدن جدید روی یک Host در آن وضعیت قطع میگردد.
- در پیادهسازیهایی مثل vSphere برای ROBO Licensing که از License مبتنی بر VM استفاده میکنند، vMهای vCLS در رابط کاربری Licensing بهعنوان یکی از الزامات VMهای Licenseشده، نمایش داده میشود. اما این VMها اینگونه نیستند، زیرا VMهای سیستم میباشند.
- Hostهای ESXi 6.5 با پردازندههای (AMD Opteron Generation 3 (Greyhound نمیتوانند وارد کلاسترهای Enhanced vMotion Compatibility (EVC) AMD REV E یا AMD REV F روی یک سیستم با بروزرسانی 1 از vCenter Server 7.0 شوند. مبنای CPU برای پردازندههای AMD از ماشینهای مجازی ESX Agent دارای دستورالعملهای POPCNT SSE4A هستند که باعث میشود Hostهای ESXi 6.5 با پردازندههای Opteron Generation 3 (Greyhound) نتوانند EVC mode AMD REV E و AMD REV F را روی سیستمی با بروزرسانی 1 از vCenter Server 7.0 فعال کنند.
بیشتر بخوانید: دلایل استفاده از قابلیت HA در مجازی سازی سرور VMware
- حذف یا آلودگی VMDK – وقتیکه VMDK از VMهای vCLS حذف میشود، این VMها همچنان Orphaned میشوند. در چنین سناریویی VMهای vCLS دوباره ایجاد نمیشود زیرا VMها میتوانند به دلایل مختلفی ازجمله مدیریت VMها توسط vSphere HA وارد وضعیت Orphaned شوند. برای بازیابی از این شرایط، کاربر باید بهصورت دستی چنین VMهای vCLS را حذف کند، جایی که VMهای جدید ایجاد میشوند.
ملاحظات ویژه
- درصورتیکه یک خرابی Host در یک کلاستر با HA فعال رخ دهد و وقتیکه این Host دارای VMهای vCLS بوده است، این VMها توسط HA در یک Host دیگر روشن میشوند، اگر پیکربندی Storage اشتراکی برای کلاستر وجود داشته باشد. در برخی از موارد، ممکن است ESX Agent Manager سعی کند این VMها را روشن کند که این کار منجر میشود به Taskهای دچار خرابی، اما VMها روشن خواهند شد تا وضعیت سلامت vCLS حفظ شود. میتواند خرابی این Taskها را نادیده گرفت.
- درصورتیکه نیاز به پایین بردن vCenter Server به یک نسخهی قدیمیتر وجود داشته باشد که vCLS در آن تحت پشتیبانی نباشد، میتوان VMهای vCLS را پاکسازی نمود. کاربران باید پس از پایین بردن نسخهی vCenter Server، بهصورت دستی این VMهای vCLS را حذف کنند.