پرش به مطلب اصلی

معرفی درخت نظارت

· خواندن 4 دقیقه
علی
مهندس نرم‌افزار

در بخش قبل پیرامون یکی از مهمترین الزامات سیستم‌های مخابراتی، یعنی حفظ عملکرد سیستم در مواجهه با خطا و رویکرد زبان ارلنگ برای پاسخ به این نیاز صحبت کردیم. گفته شد که زبان ارلنگ با الهام از مفهوم پردازه‌ها در سیستم عامل، زیرساختِ اجرای همروند انبوهی از پردازه‌ها را فراهم می‌کند و از طریق آن می‌توان دامنه انتشار خطا را محدود کرد. اما برای ارائه عملکرد قابل قبول در مواجهه با خطا، نیاز به نظارت، تشخیص سریع خطا و راه‌ اندازی مجدد پردازه مربوطه است. در این نوشته به معرفی درخت نظارت1، که در واقع تکمیل کننده رویکرد ارلنگ برای توسعه سیستم‌های پایدار در مواجهه با خطا است، می‌پردازیم.

شرکت فرضی زوتِل2 را در نظر بگیرد که به ارائه خدمات مخابراتی در باغ وحش‌های جهان مشغول است. جهت کنترل بیشتر روی تماس‌ها، این شرکت از یک هسته مرکزی برای تبادل بسته‌های صوتیِ هر تماس استفاده می‌کند. همان‌طور که در شکل زیر نمایش داده شده، تمام بسته‌های RTP مربوط به تماس‌ها از این هسته مرکزی، که به صورت یک پردازه سیستم عامل اجرا می‌شود، عبور می‌کند.

ZooTel Media Engine

به خاطر پراکندگی حیوانات در کشورهای مختلف، این شرکت با تنوع بسیار بالایی از گوشی‌ها مواجه است. این تنوع بالا می‌تواند چالش‌های بسیاری هم در حوزه سیگنال‌دهی3، مشابه آنچه در نوشته پیشین ذکر شد، و هم در حوزه تبادل بسته‌های صوتی، مشابه بسته‌های مرموز RTP که در این نوشته به آن‌ها اشاره شده، برای شرکت زوتل ایجاد کند. حتی اگر در هسته مرکزی تمام حالات محتمل که منجر به خطا می‌شوند، بررسی شده باشد، باز هم به دلیل استفاده از کتابخانه‌های دیگر امکان مختل شدن فعالیت هسته مرکزی و از دست رفتن تمامی تماس‌ها وجود دارد، مشابه آنچه در این مساله ذکر شده است.

Bad RTP Media Engine

با استفاده از مدل پردازه‌های ارلنگ می‌توان جلوی انتشار خطا را گرفت و تنها یک تماس را از دست داد. برای این منظور پس از اینکه مشخصات مبدا و مقصد برای ارسال بسته‌های صوتی در مرحله سیگنال‌دهی مشخص شد، مطابق آنچه در شکل زیر نمایش داده شده، به ازای هر تماس یک پردازه ارلنگ جهت تبادل بسته‌های صوتی بین طرفین ایجاد می‌کنیم.

Bad RTP Media Engine

با توجه به اینکه هر پردازه مسئول انتقال بسته‌ها در یک تماس است، دریافت بسته‌های مرموز تنها عملکرد یک پردازه را مختل می‌کند و عملا تنها یک تماس را از دست می‌دهیم، بر خلاف حالت قبل که کل تماس‌ها از دست می‌رفت.

Bad RTP Media Engine

با این وجود از دست دادن کامل یک تماس نیز مطلوب نیست. بهتر است که تنها شاهد یک اختلال جزئی در انتقال پیام‌های صوتی باشیم. برای رسیدن به این هدف، ابتدا باید متوجه مختل شدن پردازه‌ مربوطه شویم و سپس در سریع‌ترین زمان ممکن آن پردازه را مجددا اجرا کنیم.

پیش‌تر اشاره شد که پردازه‌ها در ارلنگ به صورت کاملا مستقل از یکدیگر اجرا می‌شوند. با این حال توابعی برای نظارت بر عملکرد یک پردازه نیز در نظر گرفته شده است. می‌توانیم پردازه‌ای جدید ایجاد کنیم که با استفاده از آن توابع، ناظر عملکرد دیگر پردازه‌ها باشد و در صورت رخداد مشکل در هر یک از آن پردازه‌ها، رویه‌ای که از قبل مشخص شده را اجرا کند. این رویه می‌تواند به سادگی اجرای مجدد پردازه مختل شده باشد یا مشابه این قطعه کد کمی پیچیده‌تر باشد. در شکل زیر پردازه ناظر و پردازه‌های مربوط به هر تماس نمایش داده شده.

Bad RTP Media Engine

پردازه‌ای که به عنوان ناظر ایجاد کردیم خود نیز یک پردازه ارلنگ است و می‌تواند توسط یک پردازه نظارت شود. در واقع این ویژگی ساده امکان تعریف درخت نظارت را ایجاد می‌کند. از طریق درخت نظارت می‌توان مسائل پیچیده‌ را به صورت پردازه‌هایی ساده در یک درخت نظارت مدل‌سازی کرد. به عنوان نمونه در شکل زیر درخت نظارت مربوط به پشته4 SIP پروژه yxa را مشاهده می‌کنید.

Bad RTP Media Engine

انشالله در مطلب بعدی، به پیاده‌سازی، تست و بررسی عملکرد یک درخت نظارت ساده برای استفاده در هسته تبادل تماس شرکت زوتل می‌پردازیم.

پاورقی‌ها

  1. Supervision Tree

  2. ZooTel

  3. Signaling

  4. Stack