دسته: شبکه های کامپیوتری
حجم فایل: 13775 کیلوبایت
تعداد صفحه: 200
فهرست مطالب
مدیریت خطا 3
معماری رایج برای مدیریت خطا 3
خصیصه های رایج رویدادها 4
میزان اهمیت های معمول رویداد 5
میزان اهمیت های معمول رویداد (severity of evenets) در استانداردهای ITU-T/X. 733 و IETF syslog. 6
انواع معمول root cause: 7
مشکل تشخیص خطا 7
الگوریتم های تشخیص خطا 8
§متدهای تحلیل توپولوژی 8
§متد مبتنی بر قانون (rule-based) و یا سیستم خبره (expert system) 9
§درخت های تصمیم 10
§گراف وابستگی (dependency graph) 11
§ Code book. 12
§استدلال مبنی بر نمونه (case-based reasoning) 13
روش های گزارش خطا 14
بعد از گزارش دهی. 14
جلوگیری از خطا 15
مدیریت پیکربندی (configuration management) 17
فعالیت های اصلی. 17
تکنیک های تنظیم پیکربندی.. 17
پایگاه داده مدیریت تنظیمات (configuration management DB) 18
مدیریت pathها 19
معماری NMPv3: 1
1- موتور SNMP. 2
2- کاربردها 2
واسط انتزاعی خدمات.. 3
Notification Originator. 6
Notification Receiver. 7
Proxy Forwarder. 7
فصل پنجم ((Communication and Functional ModelsSNMP v1. 3
فصل ششمSNMP v2. 15
و...
مدیریت خطا
کار اصلی این قسمت کنترل خطاهای درون شبکه و پردازش و گزارش آنها میباشد.
در مدیریت خطاها، به صورت معمول از سه اصطلاح استفاده میشود:
event (رویداد) : هر دستگاه (device) در شبکه، زمانی که با خطا مواجه میشود، آن را گزارش میکند. این گزارش "رویداد" نامیده میشود.
نشانه (symptom) : به رویدادهایی که یکسان سازی شده و با فرمت یکسان در دیتابیس قرار میگیرند، "نشانه" گفته میشود.
علت اصلی (root cause) : به علت بروز رویدادها گفته میشود.
ماژول مدیریت خطا، این نشانهها را جمع آوری میکند (علت این که مستقیما رویدادها را جمعآوری نمیکند این است که رویدادها داری فرمت متفاوتی هستند و پس از یکسانسازی فرمت در قالب نشانه در دیتابیس قرار میگیرند و ماژول مدیریت خطاها نیز با دیتابیس در ارتباط است) و آنها را آنالیز کرده و علت اصلی را شناسایی میکند.
نکتهای که باید به آن توجه شود این است که الزاماً برای هر نشانه یک علت (root cause) منحصر بهفرد وجود ندارد و ممکن است چندین نشانه یک علت وقوع داشته باشند. شکل زیر را در نظر بگیرید:
اگر لینک بین دو قطعه A و B قطع شود، یک رویداد از طریق A و یک رویداد توسط B ایجاد میشود. در این حالت دو نشانه با یک علت وقوع یکسان داریم.
معماری رایج برای مدیریت خطا
مجموعهای از دستگاههای 1 تا m موجود میباشد که ممکن است از نظر سختافزاری یا نرمافزاری متفاوت باشند. این دستگاههای رویدادهایشان را در چایگاه دادهای ثبت میکنند. در کنار این رویدادهای داخلی شبکه ممکن است اطلاعات و رویدادهایی از کاربران دریافت شده و از طریق پشتیبانها در این پایگاه داده ثبت شود.
شکل 1 – معماری رایج در مدیریت خطا
نشانهها از این پایگاه داده استخراج میشود و در اختیار ماژولی به نام "ماژول تشخیص" (diagnosis module) یا "ماژول ارتباط" (correlation module) قرار میگیرد. وظیفه این ماژول تشخیص علت اصلی خطا (root cause) از نشانهها (symptoms) میباشد.
این علت وقوع خطا (root cause) ی یافت شده ممکن است نیازمند اعتبار سنجی (validation) باشد زیرا الزاماً در این مرحله یک علت واحد برای خطا مشخص نمیشود پس برای تشخیص علت اصلی نیاز به اعتبارسنجی میباشد.
در مرحله پایانی علت وقوع خطا به مدیر شبکه گزارش داده میشود.
خصیصه های رایج رویدادها
در استانداردهای مختلف خصیصههای مختلفی برای رویدادها وجود دارد ولی اکثراً در تعداد زیادی از خصیصهها یکسان هستند. در زیر تعدادی از آنها آورده شده است:
شناسه (ID) : مقدار منحصر بفردی که هر المان به رویداد اختصاص میدهد.
برای مثال هشدار قطعی لینک E1 در سوئیچ NEAX برابر است با: 1041001 در حالی که این هشدار در سوئیچ Huawei مقدار 567 و در سوئیچ EWSD مقدار 01809 است (به این معنی که در سوئیچ EWSD اگر رویدادی با شماره 01809 را دریافت شود قطعی لینک E1 نتیجهگیری میشود.)
عنوان (Title) : در کنار شناسه برای هر رویداد یک عنوان قرار میگیرد.
به عنوان مثال: 1041001<->dti_fault یا 567<->E1 link fault
منبع (Source) : دستگاهی که رویداد از آن آمده است.
تاریخ و زمان (Date and Time) : بیانگر زمانی است که رویداد اتفاق افتاده است.
اگر کل المانهای موجود در شبکه از نظر زمانی همگام باشند، زمان وقوع رویداد (که دستگاه مبدا آن را ارسال میکند) در تمام دستگاهها یکسان است ولی اگر المانها همگام نباشند زمان وقوع رویداد در المانهای دیگر شبکه معتبر نیست و در این جا بحث fuzziness مطرح میشود. برای این منظور از پروتکلهای همگام سازی در شبکه مانند NTP (Network Time Protocol) در ماژول تشخیص (diagnosis module) استفاده میکنیم. البته این پروتکل باید به گونهای باشد که تمام المانهای شبکه آن را پشتیبانی کنند.
شدت (Severity) : میزان اهمیت رویدادی که اتفاق افتاده است را نشان میدهد.
نوع (Type) : نوع رویدادی که اتفاق افتاده است را نشان میدهد.
درواقع بیان میکند که در چه حالتی از کار دستگاه این رویداد اتفاق افتاده است. مثلاً در زمان مقداردهی اولیه یا در هنگام ارتباط یا...
علت احتمالی (Probable Cause) : حدسی از ایکه چرا این رویداد اتفاق افتاده است.
این کار را خود دستگاه انجام میدهد. مثلاً وقتی لینکی خراب شود، علت احتمای وقوع رویداد را شماره کارتی قرار میدهد که لینک آن قطع شده است.
مثال: یک رویداد در سوئیچ NEAX:
قیمت: 1,000 تومان