جزوه کامل تایپ شده استاد اثنی عشری

فهرست مطالب

• شبکه های تلفنی آنالگ
• شبکه های ارتباط اطلاعات
• محیط پردازش توزیع شده
• اینترنت
• پروتکل ها و استانداردها
• سیستم ها ،سرویس ها و شبکه های باند پهن
• مدیریت فناوری و اطلاعات
• سیستم مدیریت شبکه
• مدیریت وضعیت جاری و آینده شبکه

مدیریت خطا 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

• Structure of Management Information (SMI)
• Management Information Base (MIB)
• ·                   ساختارMIBونحوهآدرسدهیدرMIB 
• MIB View and Access of an Object
• Managed Object

فصل پنجم   ((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): در کنار شناسه برای هر رویداد یک عنوان قرار می­گیرد.
به عنوان مثال: 1041001dti_fault یا 567E1 link fault

منبع(Source): دستگاهی که رویداد از آن آمده است.

تاریخ و زمان(Date and Time): بیانگر زمانی است که رویداد اتفاق افتاده است.

اگر کل المان­های موجود در شبکه از نظر زمانی همگام باشند، زمان وقوع رویداد(که دستگاه مبدا آن را ارسال می­کند) در تمام دستگاه­ها یکسان است ولی اگر المان­ها همگام نباشند زمان وقوع رویداد در المان­های دیگر شبکه معتبر نیست و در این جا بحث fuzziness مطرح می­شود. برای این منظور از پروتکل­های همگام سازی در شبکه مانند NTP(Network Time Protocol) در ماژول تشخیص(diagnosis module) استفاده می­کنیم. البته این پروتکل باید به گونه­ای باشد که تمام المان­های شبکه آن را پشتیبانی کنند.

شدت(Severity): میزان اهمیت رویدادی که اتفاق افتاده است را نشان می­دهد.
نوع(Type): نوع رویدادی که اتفاق افتاده است را نشان می­دهد.

 درواقع بیان می­کند که در چه حالتی از کار دستگاه این رویداد اتفاق افتاده است. مثلاً در زمان مقداردهی اولیه یا در هنگام ارتباط یا ...
علت احتمالی(Probable Cause): حدسی از ایکه چرا این رویداد اتفاق افتاده است.

این کار را خود دستگاه انجام می­دهد. مثلاً وقتی لینکی خراب شود، علت احتمای وقوع رویداد را شماره کارتی قرار می­دهد که لینک آن قطع شده است.
مثال: یک رویداد در سوئیچ NEAX: