فرض کنید دهها شعبه از SD-WAN استفاده میکنند و کاربران فقط در بعضی ساعات از کندی ERP، VoIP یا دسترسی به دیتاسنتر شکایت دارند. Linkها Up هستند، Routerها Alarm واضحی ندارند و ISP هم میگوید سرویس سالم است. در چنین شرایطی، مسئله معمولاً در کیفیت مسیر، Tunnel، Latency، Jitter، Packet Loss یا رفتار Application پنهان است.
مانیتورینگ SD-WAN با OpManager کمک میکند تیم NOC بهجای اتکا به Up/Down، کیفیت واقعی ارتباط بین Siteها را ببیند. این راهنما روی طراحی Monitoring برای Tunnel، WAN Path، Interface، QoS و User Experience تمرکز دارد.
چرا Up بودن Link به معنی سالم بودن SD-WAN نیست؟
یک Link ممکن است Up باشد اما Packet Loss یا Jitter بالا داشته باشد. برای Voice و Video این وضعیت میتواند تجربه کاربر را خراب کند بدون اینکه Alarm ساده Availability فعال شود.
| متریک | معنا | اثر احتمالی |
|---|---|---|
| Latency | زمان رفتوبرگشت | کندی Application |
| Jitter | نوسان Delay | افت کیفیت VoIP/Video |
| Packet Loss | از دسترفتن Packet | Retransmission و قطع صدا |
| Utilization | مصرف Link | Congestion |
| Error/Discard | خطای Interface | کیفیت پایین Link |
OpManager چه دادههایی را برای WAN میتواند کنار هم قرار دهد؟
OpManager برای Monitoring شبکه، Interface، Device Availability، WAN Performance، IP SLA و مسیرهای شبکه استفاده میشود. در طراحی SD-WAN، هدف این است که Health هر Site با کیفیت واقعی مسیر ترکیب شود.
صفحه OpManager Plus در مدانت Pillar اصلی بررسی لایسنس و معماری ITOM است.
IP SLA؛ تست مصنوعی کیفیت مسیر
Cisco IP SLA و قابلیتهای مشابه میتوانند Probeهای فعال برای اندازهگیری Delay، Jitter و Packet Loss ایجاد کنند. OpManager میتواند این دادهها را برای تحلیل WAN استفاده کند.
مزیت Probe فعال این است که لازم نیست منتظر شکایت کاربر بمانید. NOC میتواند کیفیت مسیرهای حیاتی را بهصورت مداوم بسنجد.
Network Path Analysis را کنار SD-WAN ببینید
اگر Latency بالا رفت، سؤال بعدی این است که «در کدام بخش مسیر؟». مقاله Network Path Analysis در OpManager روش بررسی Hopهای پرتاخیر و Packet Loss را توضیح میدهد و مکمل طبیعی این سناریو است.
سناریوی شعبه: ERP کند است اما Internet خوب است
- کاربر شعبه کندی ERP را گزارش میکند.
- Availability Router و Tunnel بررسی میشود.
- Latency و Packet Loss مسیر دیتاسنتر اندازهگیری میشود.
- Interface Utilization و Error/Discard بررسی میشوند.
- Path Analysis مشخص میکند Delay در ISP یا مسیر داخلی است.
- اگر Link سالم باشد، Application Monitoring یا Database بررسی میشود.
Jitter برای Voice حیاتی است
برای VoIP، Average Latency بهتنهایی کافی نیست. نوسان شدید Delay میتواند حتی با Average قابلقبول، کیفیت تماس را خراب کند. بنابراین Jitter باید Threshold مستقل داشته باشد.
Threshold ثابت یا Baseline؟
برای Siteهای مختلف، یک Threshold یکسان همیشه منطقی نیست. یک شعبه داخل شهر و یک Site ماهوارهای Baseline متفاوتی دارند. بهتر است Thresholdها بر اساس نوع Link، سرویس و Criticality تعریف شوند.
| نوع Site | پیشنهاد Monitoring |
|---|---|
| HQ | Strict Threshold + High Frequency |
| Branch | Baseline + Business Hour Profile |
| Remote/Backup | Availability + Trend |
| Voice-heavy Site | Jitter/Packet Loss Priority |
SD-WAN و Capacity Planning
اگر مسیرها دائماً نزدیک Saturation هستند، Routing هوشمند هم معجزه نمیکند. برای تحلیل روند مصرف Flow و زمان Upgrade، مقاله Capacity Planning با NetFlow Analyzer خوشه مرتبط مناسبی است.
Correlation بین Tunnel و Interface
یکی از خطاهای رایج این است که Tunnel Alarm جدا از Physical Interface دیده شود. اگر Interface WAN Error دارد، مشکل Tunnel ممکن است Symptom باشد نه Root Cause.
طراحی Dashboard برای NOC
یک Dashboard مفید SD-WAN بهتر است این موارد را نشان دهد:
- Site Availability؛
- Tunnel Health؛
- Top Sites by Latency؛
- Top Sites by Packet Loss؛
- Jitter برای Voice Pathها؛
- Interface Utilization؛
- Active Critical Alarms؛
- Trend هفتگی کیفیت WAN.
چه زمانی Alert بسازیم؟
Alert باید Actionable باشد. اگر Packet Loss برای ۳۰ ثانیه ۱ درصد شد اما هیچ Business Impact ندارد، Alarm بحرانی ممکن است فقط Noise تولید کند.
الگوی بهتر
- Warning برای انحراف کوتاهمدت؛
- Critical برای تداوم یا همراهی چند متریک؛
- Correlation با Availability و Utilization؛
- Rearm مناسب برای جلوگیری از Flapping.
اتصال SD-WAN Monitoring به ServiceDesk Plus
Alarm مهم باید با Site، Device، Interface، Metric و Timestamp وارد Ticket شود. این کار باعث میشود تیم پشتیبانی بهجای Ticket مبهم «اینترنت کند است»، Evidence دقیق داشته باشد.
برای Workflowهای Incident، دانشنامه Service Desk مدانت میتواند مرجع تکمیلی باشد.
KPIهای SD-WAN
- WAN Availability؛
- Median و P95 Latency؛
- Packet Loss Rate؛
- Jitter؛
- MTTR شعب؛
- تعداد Flap در Tunnel؛
- درصد Alarmهای قابل اقدام؛
- زمان تشخیص Root Cause.
چکلیست پیادهسازی
- همه Edge Deviceها Discovery شدهاند.
- Interfaceهای WAN درست Label شدهاند.
- IP SLA یا Probe فعال برای مسیرهای حیاتی تعریف شده است.
- Thresholdهای Latency/Jitter/Loss بر اساس Site تنظیم شدهاند.
- Path Analysis برای Critical Routeها فعال است.
- Integration با Ticketing تست شده است.
- Dashboard NOC بر اساس Site طراحی شده است.
نکات کلیدی
- Up/Down برای SD-WAN کافی نیست.
- Latency، Jitter و Packet Loss باید مستقل دیده شوند.
- Path Analysis به پیدا کردن محل واقعی Delay کمک میکند.
- Capacity و Flow Data باید کنار Availability دیده شوند.
- Thresholdها باید Site-aware باشند.
منابع
- ManageEngine OpManager — Network Monitoring
- ManageEngine OpManager — WAN Monitoring
- ManageEngine — Cisco IP SLA Monitoring
سخن پایانی
در SD-WAN، Availability فقط اولین سؤال است. سؤال مهمتر این است که آیا مسیر واقعاً کیفیت لازم برای سرویسهای حیاتی را دارد. OpManager با ترکیب Device، Interface، WAN Metric و Path Analysis به NOC کمک میکند کیفیت واقعی شعب را بهصورت قابل اندازهگیری مدیریت کند.
مدانت خدمات استعلام و خرید لایسنس OpManager، طراحی معماری NOC، مانیتورینگ SD-WAN و WAN، IP SLA، Dashboard، Integration با ServiceDesk Plus، آموزش و پشتیبانی ارائه میکند. برای بررسی معماری به OpManager Plus مدانت یا تماس با مدانت مراجعه کنید.
