به روز رسانی ESXi 6.7 به 8.0 - رفع خرابی سرور تولید

ابتدا سازگاری سخت افزار را بررسی کنید

ESXi 6.7 در 15 اکتبر 2022 به پایان پشتیبانی عمومی رسید، بنابراین این انتقال دیر شده است — اما نسخه 6.7 به 8.0 یک ارتقای نسخه اصلی است، نه یک وصله. بین دو نسخه VMware مدل درایور VMKLinux را به طور کامل حذف کرد (اکنون هر دستگاهی به یک درایور بومی نیاز دارد) و نسلی از CPU ها، آداپتورهای شبکه و کنترلرهای ذخیره سازی را بازنشسته کرد. یک هاست کاملا سالم 6.7 همچنان می تواند به شکل فعلی غیر قابل ارتقا باشد.

قبل از رزرو پنجره، راهنمای سازگاری VMware را برای مدل دقیق سرور، خانواده CPU، آداپتورهای شبکه و کنترل‌کننده ذخیره‌سازی خود در برابر ESXi 8.0 بررسی کنید و سیستم‌افزار سرور (BIOS، کنترل‌کننده ذخیره‌سازی، NIC) را به نسخه‌هایی که فروشنده فهرست می‌کند برای 8.0 به‌روزرسانی کنید. پیش‌بررسی خود نصب‌کننده نیز درباره دستگاه‌های منسوخ شده هشدار می‌دهد - اما یافتن اطلاعات در کنسول در نیمه‌شب زمان اشتباهی است. ابتدا روی کاغذ چک کنید.

از پیکربندی میزبان و ماشین های مجازی بک آپ بگیرید

از پیکربندی میزبان از پوسته میزبان نسخه پشتیبان تهیه کنید (اگر خاموش است ابتدا SSH را روی میزبان فعال کنید). دستور یک پیوند دانلود را برای بسته پیکربندی برمی گرداند - آن را باز کنید و فایل .tgz را در جایی که در این سرور نیست ذخیره کنید:

vim-cmd hostsvc/firmware/backup_config

سپس تأیید کنید که نسخه‌های پشتیبان VM جاری هستند و حداقل یک بازیابی واقعاً آزمایش شده است. نیمی از تمام صفحه‌های بنفش پس از ارتقا به سیستم‌افزاری بازمی‌گردند که هایپروایزر قدیمی آن را تحمل می‌کرد – اما خرابی‌هایی که نمی‌توانید آن‌ها را لغو کنید، مواردی هستند که پشتیبان‌گیری ندارند.

پنجره را برنامه ریزی کنید و کلید مجوز 8.0 را آماده نگه دارید

یک اسلات تعمیر و نگهداری انتخاب کنید و آن را به کاربران اعلام کنید — وقتی میزبان از کار می افتد، هیچ کس نباید در اواسط ذخیره باشد. دنباله را با زمان‌ها یادداشت کنید و یک مهلت بازگشت سخت تعیین کنید: نقطه‌ای در شب که پس از آن اشکال‌زدایی را متوقف می‌کنید و به جای خوردن کل پنجره به عقب برمی‌گردید (مرحله 7). وقتی کار تمام شد، پیام پایانی را ارسال کنید، تا صبح روز بعد با شایعات شروع نشود.

مجوز را قبل از پنجره مرتب کنید، نه در طول آن. کلیدهای مجوز به نسخه اصلی گره خورده اند — یک میزبان 8.0 کلید 6.7 را نمی پذیرد و بدون کلید در حالت ارزیابی به مدت 60 روز اجرا می شود. در Broadcom، کلیدها و دانلودها از پورتال پشتیبانی Broadcom بر خلاف حق شما می‌آیند، بنابراین این دسترسی را از قبل ترتیب دهید.

مسیر A - با بوت کردن ISO 8.0 ارتقا دهید

به کاربران بگویید، سپس میزبان را در حالت تعمیر و نگهداری قرار دهید — هر VM خاموش می شود یا به میزبان دیگری منتقل می شود. هرگز میزبانی را که هنوز VMهای تولیدی را اجرا می کند، ارتقا ندهید.

نصب کننده ESXi 8.0 را از ISO بوت کنید، دیسکی را که نصب موجود را در خود نگه می دارد انتخاب کنید و Upgrade ESXi, save VMFS datastore را انتخاب کنید. این مسیری است که در اکثر سرورها نشان داده شده است، و سروری که یک نسخه بزرگ را مدیریت می‌کند، به طور تمیز پرش می‌کند، زیرا بررسی‌های اولیه در همان زمان روی صفحه ظاهر می‌شوند.

مسیر B - ارتقاء از Shell با esxcli

مسیر انبار به طور کامل از پوسته میزبان اجرا می شود - بدون رسانه فیزیکی یا مجازی - که آن را به گزینه ای عملی برای یک میزبان راه دور تبدیل می کند. میزبان همچنان ابتدا به حالت تعمیر و نگهداری می رود، دقیقاً مانند مسیر A. به مشتری HTTP از طریق دیوار آتش میزبان اجازه دهید:

esxcli network firewall ruleset set -e true -r httpClient

نمایه های موجود در انبار آنلاین VMware را فهرست کنید و نام دقیق نمایه استاندارد 8.0 را یادداشت کنید:

esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

سپس به‌روزرسانی نمایه را با استفاده از همان نام نمایه در انبار اجرا کنید و پس از اتمام، هاست را مجدداً راه‌اندازی کنید:

esxcli software profile update -d <depot-url> -p <exact-profile-name>

همین مسیر به صورت آفلاین کار می کند: بسته انباری ZIP را در یک دیتا استور کپی کنید و به جای آن مقدار -d را روی آن فایل قرار دهید. توجه داشته باشید که به روز رسانی نمایه فرمان ارتقاء است - پیکربندی موجود و VIB های شخص ثالث شما را در جایی که سازگار هستند نگه می دارد. profile install را جایگزین تصویر نکنید.

پس از راه اندازی مجدد - مجوز، تأیید و سپس انتشار

وقتی میزبان در 8.0 پشتیبان‌گیری شد، کلید مجوز ESXi 8.0 خود را اعمال کنید — کلید 6.7 پذیرفته نمی‌شود و بدون کلید جدید، ساعت ارزیابی در حال تیک‌ک کردن است. از حالت نگهداری خارج شوید، سپس ابتدا یک ماشین مجازی غیر بحرانی را راه اندازی کنید و قبل از شروع بقیه، شبکه، فضای ذخیره سازی و کنسول آن را بررسی کنید.

در مرحله بعد از طریق خود میزبان کار کنید: گزارش رویداد و وضعیت سخت افزار برای شکایات درایور یا حسگر، هر ذخیره داده نصب شده و تنظیمات شبکه مدیریت دست نخورده است. فقط پس از آن سرور را به کاربران بازگردانید و پیام پایان را از مرحله 3 ارسال کنید.

کتاب بازی Crash - صفحه بنفش و Shift+R Rollback

اگر میزبان صفحه نمایش بنفش (PSOD) است یا پس از ارتقا به طور مفیدی بوت نمی شود، به این ترتیب کار کنید. ابتدا، قبل از دست زدن به هر چیزی، از صفحه بنفش عکس بگیرید. PSOD عبارت است از توقف عمدی VMkernel زیرا ادامه آن ماشین‌های مجازی را به خطر می‌اندازد - و صفحه تشخیص است: نوع استثنا و ماژول نام‌گذاری شده روی آن به علت اشاره می‌کند، با نام ماژول درایور که نشان‌دهنده مشکل پشتیبانی سخت‌افزاری است و خطای صفحه به حافظه یا سیستم‌افزار اشاره می‌کند.

دوم، یک بار راه اندازی مجدد و تماشا کنید. یک صفحه بنفش گذرا پس از تغییر درایور داده است. تکرار یک حکم است. اولین مظنونان، به ترتیب خود ارتقاء: یک NIC پشتیبانی نشده یا آداپتور ذخیره سازی، سیستم عامل قدیمی تر از لیست های راهنمای سازگاری، یا یک خطای حافظه که نسخه قدیمی هرگز تاکید نکرده است.

سوم، به عقب برگردید. ESXi در دو بانک بوت نصب می‌شود و ارتقاء بیلد 6.7 قبلی شما را در بانک جایگزین دست نخورده باقی می‌گذارد. هاست را مجددا راه اندازی کنید و در اعلان راه اندازی، Shift + R را فشار دهید و تأیید کنید — هاست بیلد 6.7 قبلی را که پیکربندی شامل آن می شود، دقیقاً همانطور که آن را ترک کرده اید، راه اندازی می کند. اگر برگشت کار کرد، زمان خریده‌اید: علت سازگاری را در نور روز برطرف کنید و دوباره در یک پنجره جدید ارتقا دهید.

vim-cmd hostsvc/firmware/restore_config <bundle-path>

این دستور بازیابی دومین مسیر فرار است - پیکربندی میزبان را از بسته مرحله 2 به میزبانی از همان نسخه و ساخت برمی‌گرداند، برای مواردی که یک بانک بوت کافی نیست.