لب عملی: پیکربندی In-Service Software Upgrade (ISSU) روی یک Stack

این لب عملی یک In-Service Software Upgrade را در سراسر یک stack StackWise انجام می‌دهد، و ایمیج IOS هر عضو را یکی‌یکی ارتقا می‌دهد در حالی که stack در سراسر آن به فوروارد‌کردن ترافیک ادامه می‌دهد، و صفر خرابی را در مقایسه با رویکرد مخل reload استفاده‌شده در لب‌های ارتقای IOS قبلی تأیید می‌کند.

ارتقای Rolling در ISSUراه‌اندازی‌مجدد متوالی عضو Stackارتقای IOS بدون-خرابی

~4 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

هدف لب

فعال‌کردن یک ISSU روی یک stack StackWise سه‌عضوی، مشاهده هر عضو که راه‌اندازی مجدد و به‌طور متوالی دوباره می‌پیوندد در حالی که stack به‌عنوان یک کل به فوروارد‌کردن ترافیک ادامه می‌دهد، و تأیید اینکه همه اعضا نسخه IOS جدید را یک‌بار که فرآیند کامل شود بدون هیچ نقطه شکست کاملی اجرا می‌کنند.

هدف لب (چرا مهم است)

لب ارتقای IOS پیش‌تر در این مجموعه نیازمند یک راه‌اندازی مجدد کامل بود، و باعث یک خرابی کامل روی آن دستگاه منفرد در طول پنجره ارتقا می‌شد. ISSU روی یک stack از داشتن چند عضو فیزیکی برای ارتقادادن و راه‌اندازی‌مجددشان یکی‌یکی بهره می‌برد، و کل stack را در سراسر آن عملکردی نگه می‌دارد — قابلیتی بدون معادل روی یک روتر یا سوئیچ مستقل منفرد.

توپولوژی لب

stack سه‌عضوی StackWise از لب stacking قبلی، در
حال حاضر در حال اجرای IOS نسخه 16.9.1، برای
ارتقا به 16.9.4

ایمیج جدید از‌قبل به فلش روی هر سه عضو کپی
شده، همان‌طور که در لب ارتقای IOS قبلی پوشش
داده شد

وظیفه ۱: تأیید نسخه IOS فعلی در سراسر همه اعضا

تأیید کن هر سه عضو stack در حال حاضر همان نسخه قدیمی‌تر IOS را اجرا می‌کنند.

وظیفه ۲: فعال‌کردن فرآیند ISSU

دستور بارگذاری ISSU با مشخص‌کردن ایمیج جدید، هدف‌گیری stack، را صادر کن.

وظیفه ۳: نظارت بر فرآیند راه‌اندازی‌مجدد متوالی عضو

مشاهده کن اعضا یکی‌یکی به‌جای هم‌زمان راه‌اندازی مجدد می‌شوند، و اتصال stack را در سراسر آن تماشا کن.

وظیفه ۴: تأیید فوروارد‌کردن پیوسته ترافیک در طول ارتقا

ترافیک پیوسته از میان stack در طول پنجره ارتقا تولید کن و تأیید کن هیچ وقفه پایداری رخ نمی‌دهد.

وظیفه ۵: تأیید اجرای نسخه جدید توسط همه اعضا

یک‌بار که فرآیند کامل شود، تأیید کن هر عضو stack نسخه IOS جدید را گزارش می‌دهد.

راه‌حل و تأیید

Switch# show version | include Version

Cisco IOS Software, Version 16.9.1
-- (تأیید‌شده سازگار در سراسر جزئیات عضو
--  "show switch" نیز -- هر سه عضو روی همان
--  نسخه)

Switch# issu loadversion 1 flash:cat9k_16.09.04.SPA.bin
             2 flash:cat9k_16.09.04.SPA.bin
             3 flash:cat9k_16.09.04.SPA.bin

-- ISSU هدایت می‌شود تا ایمیج جدید را روی هر
-- سه عضو بارگذاری کند، اما خود فرآیند آن را
-- به‌طور متوالی اعمال خواهد کرد به‌جای
-- راه‌اندازی‌مجدد کل stack یک‌جا

Switch# show issu state detail

Slot   Image Version              Status
1      16.09.04                   STANDBY
2      16.09.04                   STANDBY
3(active) 16.09.01                RUNNING

-- اعضا ایمیج جدید را آماده می‌کنند در حالی که
-- روی نسخه در حال اجرای فعلی باقی می‌مانند، و
-- ارتقا را پیش از شروع هر راه‌اندازی‌مجدد
-- مخلی مرحله‌بندی می‌کنند

-- ISSU ادامه می‌دهد به راه‌اندازی‌مجدد اعضا
-- یکی‌یکی، و اول با اعضای غیر-فعال شروع می‌کند:

*عضو 1 در حال راه‌اندازی‌مجدد...*
*عضو 1 دوباره به stack پیوست، در حال اجرای 16.09.04*

*عضو 2 در حال راه‌اندازی‌مجدد...*
*عضو 2 دوباره به stack پیوست، در حال اجرای 16.09.04*

-- فقط پس از اینکه اعضای غیر-master با موفقیت
-- دوباره پیوستند فرآیند به راه‌اندازی‌مجدد
-- master فعلی آخر حرکت می‌کند، و یک سوئیچ
-- کنترل‌شده نهایی نقش master را فعال می‌کند

ContinuousTrafficGen> [ping پیوسته از میان
                       stack در سراسر کل
                       فرآیند ISSU]

Ping statistics: 1,842 sent, 1,839 received,
                 0.16% loss (از‌دست‌رفتن کوتاه
                 فقط در طول سوئیچ نهایی
                 master، چند صد میلی‌ثانیه)
-- ترافیک در سراسر تقریباً کل ارتقا همچنان
-- جریان یافت -- تنها وقفه کوتاه در طول گذار
-- نهایی نقش master رخ داد، بسیار کوتاه‌تر از
-- خرابی چند-دقیقه‌ای که یک راه‌اندازی‌مجدد
-- کامل stack ایجاد می‌کرد

Switch# show switch

Switch#  Role     Version   State
------------------------------------
 1       Member   16.09.04  Ready
 2       Member   16.09.04  Ready
*3       Master   16.09.04  Ready
-- هر سه عضو اکنون تأیید‌شده در حال اجرای
-- نسخه جدید IOS، با stack که در سراسر کل
-- فرآیند ارتقا عملکردی باقی مانده

نکته کلیدی

قابلیت تقریباً-صفر-خرابی ISSU کاملاً به داشتن اعضای فیزیکی افزونه برای توالی‌کردن از میان آن‌ها بستگی دارد — قابلیتی منحصر به پلتفرم‌های stack‌شده یا شاسی-افزونه، بدون معادل روی روترهای مستقل منفرد ارتقا‌یافته از طریق فرآیند ساده copy/reload پوشش‌داده‌شده در یک لب قبلی؛ وقفه کوتاه در طول سوئیچ نهایی master معمولاً بسیار کوتاه‌تر از هر timeout جلسه TCP است، که ISSU را عملاً برای بیشتر اپلیکیشن‌ها شفاف می‌کند با وجود اینکه از نظر فنی کاملاً بدون-تأثیر نیست.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

لب عملی: پیکربندی مسیریابی Stub در EIGRP

این لب عملی یک روتر شعبه را به‌عنوان یک stub در EIGRP پیکربندی می‌کند، و تأیید می‌کند فقط مسیرهای متصل و خلاصه خودش را تبلیغ می‌کند در حالی که روتر hub به‌درستی از پرس‌وجوکردن stub در طول یک تغییر توپولوژی در جای دیگری از شبکه اجتناب می‌کند.

ادامه

لب عملی: پیکربندی حالت Named در EIGRP

این لب عملی یک پیکربندی EIGRP کلاسیک موجود را به حالت named EIGRP بازپیکربندی می‌کند، و عبارات network و پیکربندی خاص-اینترفیس را در یک سلسله‌مراتب address-family ساختاریافته‌تر سازمان‌دهی می‌کند، و تعادل عملکردی با سبک پیکربندی کلاسیک استفاده‌شده در سراسر لب‌های EIGRP قبلی این مجموعه را تأیید می‌کند.

ادامه

لب عملی: پیکربندی ERSPAN در سراسر یک شبکه مسیریابی‌شده

این لب عملی Encapsulated RSPAN (ERSPAN) را برای آینه‌کردن ترافیک در سراسر یک شبکه مسیریابی‌شده-لایه-۳ به‌جای یک ترانک لایه ۲ واحد پیکربندی می‌کند، و مفهوم RSPAN از لب قبلی را فراتر از مرزهای یک VLAN یا دامنه سوئیچ‌شده واحد گسترش می‌دهد.

ادامه

لب عملی: پیکربندی RSPAN در سراسر سوئیچ‌ها

این لب عملی Remote SPAN (RSPAN) را با استفاده از یک VLAN RSPAN اختصاصی حمل‌شده در سراسر یک ترانک پیکربندی می‌کند، و اجازه می‌دهد ترافیک آینه‌شده روی یک سوئیچ توسط یک دستگاه گرفتن متصل به یک سوئیچ کاملاً متفاوت نظارت شود، و مفهوم SPAN محلی پوشش‌داده‌شده در یک لب قبلی را در سراسر شبکه گسترش می‌دهد.

ادامه

لب عملی: پیکربندی Stacking سنتی StackWise در Catalyst

این لب عملی stacking سنتی Catalyst (StackWise) را در سراسر سه سوئیچ با استفاده از کابل‌های stack پیکربندی می‌کند، و نیازمندی تک-لایه و مجاورت فیزیکی‌اش را با جفت StackWise Virtual پوشش‌داده‌شده در لب قبلی که اجازه می‌دهد سوئیچ‌ها بسیار دورتر از هم قرار بگیرند مقایسه می‌کند.

ادامه

لب عملی: پیکربندی StackWise Virtual

این لب عملی دو سوئیچ فیزیکی را با استفاده از یک Stackwise Virtual Link اختصاصی به یک سوئیچ منطقی StackWise Virtual واحد پیکربندی می‌کند، و تأیید می‌کند هر دو عضو به‌عنوان یک صفحه کنترل واحد ارائه می‌شوند و شکست یک عضو رفتار failover قابل‌پیش‌بینی فعال می‌کند.

ادامه