کالبدشکافی SolarWinds (بخش اول): وابستگی به SQL Server؛ گلوگاه پنهان در مقیاس‌پذیری

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

در یک محیط متوسط با چند هزار گره و ده‌ها هزار رابط، هم‌زمانی چند رویداد کاملاً معمول مانند افزایش ترافیک، تغییر وضعیت یک لینک، اجرای یک گزارش زمان‌بندی‌شده و ورود چند کاربر به داشبورد، می‌تواند در مدت کوتاهی موجب اشباع منابع و افت عملکرد SolarWinds شود.

علت اصلی این رفتار نه در موتورهای جمع‌آوری داده، بلکه در پایگاه داده‌ای قرار دارد که تقریباً تمام عملیات سامانه به آن وابسته است.

در لحظه‌ای که ماژول جمع‌آوری داده، اطلاعات را در جداول حجیم ثبت می‌کند، موتور هشدار همان جداول را برای ارزیابی می‌خواند و داشبوردها نیز هم‌زمان پرس‌وجوهای نمایشی اجرا می‌کنند. این هم‌زمانی شدید عملیات خواندن و نوشتن، SQL Server را به یک گلوگاه ذاتی تبدیل می‌کند.

این وضعیت یک نقص موردی نیست، بلکه پیامد مستقیم معماری SolarWinds است؛ معماری‌ای که دریافت داده، پردازش هشدار، گزارش‌گیری و نمایش را همگی در یک نقطه مرکزی قرار داده و هیچ تفکیک واقعی میان لایه‌ها ایجاد نکرده است.

نتیجه روشن است:

حتی در بارهای کاملاً معمول، SQL Server ممکن است به سقف توان پردازشی خود برسد و عملکرد کل سیستم را تحت‌تاثیر قرار دهد. این رفتار ناشی از کمبود سخت‌افزار نیست، بلکه خاصیت معماری متمرکز SolarWinds است.

تکیه‌گاه واحد عملیات: SQL Server

SolarWinds از چند مؤلفه تشکیل شده، اما در عمل تقریباً تمام خواندن‌ها، نوشتن‌ها و پردازش‌ها روی SQL Server متمرکز می‌شوند.

به همین دلیل Orion یک سامانه چندلایه واقعی نیست؛ بلکه یک معماری تک‌هسته‌ای با یک گلوگاه مشخص دارد.

سه جریان اصلی در SolarWinds عبارت‌اند از:

• نوشتن: ثبت پیوسته شاخص‌ها توسط ماژول جمع‌آوری داده
• خواندن: داشبوردها، گزارش‌ها، ابزار PerfStack
• پردازش همراه با خواندن: ارزیابی قوانین هشدار

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

در مقابل، معماری‌های مدرن مانیتورینگ، مسیر ثبت داده، پردازش رویداد و لایه نمایش را از هم جدا می‌کنند و هر بخش روی موتور مناسب خود اجرا می‌شود.

اما در SolarWinds: SQL Server نقش پایگاه داده سری‌زمانی، موتور پردازش قوانین، لایه گزارش‌گیری و موتور نمایشی را هم‌زمان برعهده دارد؛ نقشی که اساساً برای آن طراحی نشده است.

محدودیت‌های مدل داده رابطه‌ای در Orion

چالش SolarWinds فقط استفاده از SQL Server نیست؛ طراحی اسکیمای داده نیز در مقیاس بالا محدودیت ایجاد می‌کند.

مدل رابطه‌ای Orion به شدت به پیوندهای متعدد میان جداول متکی است و این رویکرد در محیط‌های بزرگ، هزینه پردازشی قابل توجهی ایجاد می‌کند.

سه محدودیت اصلی عبارت‌اند از:

• تجمیع‌های سنگین: داده‌های خام ابتدا در جداول جزئی ذخیره می‌شوند و سپس به خلاصه‌های ساعتی و روزانه تبدیل می‌گردند. این فرایند حجم بالایی از پردازش را به خود SQL تحمیل می‌کند.
• پیوندهای چندلایه: حتی یک داشبورد ساده نیازمند پیوندهای پشت‌سرهم است و با افزایش حجم داده، پیچیدگی و هزینه آن به صورت تصاعدی رشد می‌کند.
• عدم تناسب با داده سری‌زمانی: SQL برای تحلیل روند، خط مبنا یا پرس‌وجوهای Top N طراحی نشده و اجرای این موارد اغلب سنگین و زمان‌بر است.

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

فرسودگی معماری هشداردهی و مشکل انفجار قوانین هشدار

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

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

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

• تاخیر در پردازش هشدارها
• افزایش بار SQL Server
• ایجاد هشدارهای کاذب
• کند شدن کلی سامانه

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

در شرایط بار بالا، حتی هشدارهای حیاتی هم ممکن است با تاخیر زیاد ارسال شوند یا اصلاً اجرا نشوند.

ناتوانی معماری Orion در مواجهه با ریزسرویس‌ها و ساختارهای Cloud‑Native

معماری Orion در دوره‌ای طراحی شده که زیرساخت‌ها ثابت و قابل پیش‌بینی بودند و Polling دوره‌ای نیازهای آن زمان را پوشش می‌داد.

اما در محیط‌های امروزی، زیرساخت‌ها ماهیت پویا دارند و تغییرات پیوسته اتفاق می‌افتد:

• Podها و Containerها در چند ثانیه ایجاد و حذف می‌شوند.
• رفتار سرویس‌ها دائماً تغییر می‌کند.
• نیاز به داده‌ی لحظه‌ای و رویدادمحور وجود دارد.

مدل Polling متمرکز و متکی به SQL Server در SolarWinds توانایی همگام‌شدن با این نرخ تغییرات را ندارد.

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

چالش مهم‌تر این است که SolarWinds مفهوم «سرویس‌محور» را در معماری خود ندارد.

برای Orion، یک Pod، یک Deployment و یک Endpoint صرفاً مجموعه‌ای از شیءهای جداگانه هستند و به عنوان یک سرویس یکپارچه تحلیل نمی‌شوند. نبود تله‌متری پیوسته، نبود پشتیبانی واقعی از ردیابی و نبود تجمیع‌کننده رویداد باعث می‌شود SolarWinds در محیط‌های ریزسرویسی نه تنها ناکارآمد باشد، بلکه در مقیاس متوسط نیز به سرعت به مرز فشار عملیاتی برسد.

نتیجه‌گیری

تحلیل معماری SolarWinds نشان می‌دهد که بسیاری از چالش‌های آن ناشی از دوره‌ای است که در آن ساخته شده؛ دوره‌ای که تغییرات زیرساخت آرام‌تر بود و تمرکز بر یک هسته مرکزی منطقی به نظر می‌رسید.

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

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

مجموعه مقالات کالبدشکافی ManageEngine