اجرای خودکار دستور در Cisco IOS با Kron Job

در شبکه عملیاتی همیشه قرار نیست همه کارها دستی انجام شود. بعضی کارها زمان مشخص دارند: ذخیره کردن running-config، گرفتن خروجی ساده، ریبوت کنترل‌شده در یک maintenance window یا اجرای یک دستور تکراری روی تجهیز. در IOS سیسکو برای این نوع کارهای زمان‌بندی‌شده می‌توان از Kron استفاده کرد.

Kron شبیه cron لینوکس نیست و امکاناتش محدودتر است، اما برای چند کار ساده و قابل پیش‌بینی روی خود روتر یا سوییچ کاربرد دارد. اگر قرار است یک دستور privilege mode در زمان مشخص یا به صورت تکراری اجرا شود، Kron می‌تواند کار را بدون وابستگی به سرور بیرونی انجام دهد.

Kron در Cisco IOS چه زمانی به درد می‌خورد؟

نمونه رایج استفاده از Kron، ذخیره دوره‌ای تنظیمات است. مثلاً اگر در یک محیط چند نفر روی تجهیزات کار می‌کنند و احتمال فراموش شدن write memory وجود دارد، می‌شود هر شب running-config را در startup-config ذخیره کرد. این کار جای change management درست را نمی‌گیرد، ولی برای بعضی شبکه‌ها یک محافظ ساده است.

کارهای دیگری مثل اجرای دستورهای show، clear کردن برخی counterها یا انجام یک action ساده هم ممکن است با Kron انجام شود، به شرطی که دستور در محدوده مجاز Kron باشد و اثر جانبی خطرناک نداشته باشد.

نمونه تنظیم Kron برای ذخیره کانفیگ

اول یک policy-list تعریف می‌کنیم. داخل policy-list دستورهایی قرار می‌گیرد که Kron باید اجرا کند:

kron policy-list CopyRunToStart
 cli copy running-config startup-config

بعد occurrence را تعریف می‌کنیم تا مشخص شود این policy چه زمانی اجرا شود. مثلاً اجرای روزانه در ساعت ۲۲:

kron occurrence CopyRunToStart at 22:00 recurring
 policy-list CopyRunToStart

برای بررسی زمان اجرای بعدی می‌شود از دستور زیر استفاده کرد:

show kron schedule

خروجی معمولاً نشان می‌دهد occurrence فعال است یا نه و اجرای بعدی چه زمانی انجام می‌شود. اگر policy قبلاً fail شده باشد، باید علت fail شدن را بررسی کنید؛ چون ترتیب و نوع دستورها در Kron مهم است.

محدودیت‌های مهم Kron

مهم‌ترین محدودیت Kron این است که برای همه دستورهای configuration مناسب نیست. معمولاً دستورهایی که در privilege EXEC mode اجرا می‌شوند گزینه بهتری هستند. اگر لازم است وارد global configuration شوید، EEM معمولاً انتخاب مناسب‌تری است.

نکته دوم این است که بعد از تعریف commandها، ویرایش آن‌ها همیشه مثل یک اسکریپت آزاد نیست. اگر ترتیب دستورها اشتباه باشد یا دستور تعاملی شود، اجرای Kron fail می‌شود. مثلاً بعضی دستورهای copy ممکن است confirmation بخواهند و باید قبل از استفاده در production تست شوند.

Kron یا EEM؟

اگر فقط یک کار زمان‌بندی‌شده ساده دارید، Kron کافی است. اما اگر قرار است بر اساس event، تغییر وضعیت interface، track، syslog یا شرط خاصی دستور اجرا شود، بهتر است سراغ EEM بروید. Kron زمان‌محور است؛ EEM رویدادمحور و انعطاف‌پذیرتر است.

برای شبکه‌های حساس، اجرای خودکار دستور باید مستند باشد. مشخص کنید چه دستوری، چرا، چه زمانی و با چه اثر احتمالی اجرا می‌شود. automation بدون مستندات، بعد از چند ماه خودش تبدیل به ریسک عملیاتی می‌شود.

برچسبها
مطالب مرتبط

دیدگاهی بنویسید.

بهتر است دیدگاه شما در ارتباط با همین مطلب باشد.