کالبدشکافی SolarWinds (بخش دوم): معماری Legacy؛ چالش هم‌راستایی با زیرساخت‌های امروزی

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

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

معماری سه‌لایه‌ای که به ظاهر مدرن است، اما درواقع یک مونولیت متمرکز باقی مانده

در ظاهر، SolarWinds  یک معماری سه‌لایه دارد: وب، اپلیکیشن و پایگاه‌داده. اما این تفکیک صرفاً یک تقسیم‌بندی منطقی است، نه معماری واقعی. Orion Core- قلب تپنده پلتفرم - تمام ماژول‌ها را در در ساختاری نگه می‌دارد که میزان  coupling در آن بالاست، حتی با وجود لایه SWIS API هر افزونه‌ای، از NPM گرفته تا SAM و VMAN، داده و متادیتای خود را در یک Schema  مشترک ذخیره می‌کند و برای کوچک‌ترین عملیات باید از مسیرهای ثابتی عبور کند. این یعنی SolarWinds، حتی اگر ظاهراً چند لایه داشته باشد، در هسته خود یک Orion Monolith است که به‌جای گسترش افقی، تنها با افزودن سرورهای بیشترِ ویندوزی می‌تواند «بزرگ‌تر» شود.

مسیری که داده طی می‌کند: یک خط تولید قدیمی، نه یک pipeline مدرن

برای فهمیدن اینکه چرا SolarWinds در شبکه‌های بزرگ یا پویا به مشکل می‌خورد، کافی است مسیر حرکت داده را دنبال کنیم. تقریباً هر چیزی که مانیتور می‌شود – از SNMP و WMI تا NetFlow – باید از یک چرخه Polling عبور کند. داده‌ها ابتدا وارد Polling Engine می‌شوند، سپس Job Engine آن‌ها را صف‌بندی می‌کند و در نهایت تمام این حجم به سوی SQL Server مرکزی رانده می‌شود.

در نتیجه، SolarWinds به‌طور غالب یک سیستم Batch-Based است، نه جریان‌محور. حتی در مواردی مثل Syslog یا Trap که ظاهراً real time هستند، داده در بسیاری از پیاده‌سازی‌ها باید از SQL عبور کند، مگر زمانی که Log Analyzer به‌طور کامل در معماری فعال شده باشد. این طراحی شاید برای شبکه‌هایی با چند صد دستگاه مناسب باشد، اما در دنیای امروز – که دستگاه‌ها پویا هستند، حجم تلومتری چند برابر شده و انتظار پاسخ لحظه‌ای وجود دارد – عملاً یک گلوگاه بزرگ ایجاد می‌کند.

کافی است در شبکه یک Burst رخ دهد؛ مثلاً صدها کانتینر بالا و پایین بروند یا حجم NetFlow برای چند دقیقه افزایش یابد. Job Engine که گرچه چندین queue داخلی دارد، اما همچنان از یک مسیر پردازشی مشترک و وابسته به SQL استفاده می‌کند، شروع به عقب‌ماندن می‌کند و این تأخیر خود را به Polling Engine و سپس به SQL منتقل می‌کند. خروجی نهایی: داده‌ها دیرتر می‌رسند، گراف‌ها به‌روز نمی‌شوند و بخشی از واقعیت شبکه در لحظه دیده نمی‌شود.

SQL Server؛ ستون فقرات مطلق و هم‌زمان بزرگ‌ترین محدودیت

یکی از ویژگی‌های SolarWinds – یا شاید بهتر است بگوییم ضعف بنیادین آن – این است که در نسخه‌های On-Premise تقریباً اکثر بار سیستم روی SQL Server متمرکز است. این پایگاه داده نقش datastore، transaction engine، historical archive و بخش زیادی از analytics backend را ایفا می‌کند. در سیستم‌های مدرن، این نقش‌ها میان سرویس‌های متفاوت تقسیم می‌شوند، اما اینجا در یک نقطه متمرکز شده‌اند.

مشکلات از همین‌جا آغاز می‌شود. در شبکه‌های بزرگ، SQL ناچار است با حجم عظیمی از Insert، Update و Query برخورد کند که نتیجه آن، Lock شدن جداول، کندی در نوشتن داده‌ها، افزایش latency در خواندن، و در نهایت افت کارایی کنسول است. حتی برخی Jobها مجبورند تا آزاد شدن Lockها صبر کنند. رشد حجم داده نیز اجبار به SQL Enterprise را به‌همراه دارد، یعنی افزایش چندبرابری هزینه – نه به دلیل نیاز کاربردی، بلکه به دلیل محدودیت معماری.

Polling Engine؛ گسترش‌پذیری که به‌جای حل مسئله، مسئله را بزرگ‌تر می‌کند

بسیاری از سازمان‌ها تصور می‌کنند با اضافه‌کردن چند Polling Engine مشکل ظرفیت حل می‌شود. اما واقعیت این است که Polling Engine در SolarWinds یک کلکتور مستقل نیست، بلکه از نظر مسیر داده و وابستگی به SQL بخشی از همان ساختار متمرکز به‌شمار می‌رود. این یعنی هر چه Polling Engine بیشتر شود، ترافیک SQL بیشتر می‌شود، هماهنگی  Core پیچیده‌تر می‌شود و احتمال خطا بالا می‌رود. به عبارت دیگر، SolarWinds با افزایش سرورها به‌سختی و با پیچیدگی زیاد Scale  می‌شود، و در بسیاری از سناریوها فقط «بزرگ‌تر» می‌شود.

وابستگی سخت به Microsoft Stack؛ قدرت یا محدودیت؟

اجرای SolarWinds کاملاً به ویندوز متکی است:  Windows Services، SQL Server WebForms  و این مدل برای سازمان‌هایی که از ابتدا Windows First بوده‌اند شاید آشنا باشد، اما برای شبکه‌های مدرن – جایی که  Kubernetes، Linux، Containerها و محیط‌های multi cloud به یک استاندارد تبدیل شده‌اند – به‌معنای محدودیت است. استقرار، بروزرسانی، نگهداری Backup و Tuning همگی در یک چارچوب خاص انجام می‌شوند و این چارچوب عملاً جلوی بسیاری از الگوهای مدرن معماری را می‌گیرد. هرچند SolarWinds با معرفی Hybrid Cloud Observability تلاش کرده برخی از این محدودیت‌ها را کاهش دهد، اما بخش اصلی Orion Core همچنان به همان زیرساخت متکی است.

شکاف عمیق میان طراحی SolarWinds و واقعیت شبکه‌های توزیع‌شده امروز

تمام ایرادهای بالا، در نهایت یک حقیقت را آشکار می‌کنند: SolarWinds برای جهانی ساخته شده بود که در آن زیرساخت‌ها ثابت، شبکه‌ها قابل پیش‌بینی و داده‌ها کم‌حجم بودند. دوره‌ای که چند Polling Cycle پنج دقیقه‌ای برای «مانیتور کردن» کافی بود. اما امروز ما با محیط‌هایی سروکار داریم که روزانه هزاران Endpoint بالا و پایین می‌شوند، داده‌های Telemetry پیوسته و حجیم‌اند، و نیاز به تحلیل آنی و توزیع‌شده وجود دارد. در چنین دنیایی، یک معماری متمرکز با پایگاه‌داده واحد و پردازش Batch دیگر جواب نمی‌دهد.

جمع‌بندی؛ SolarWinds هنوز مفید است، اما در معماری‌اش به گذشته گره خورده

SolarWinds همچنان در شبکه‌های پایدار و سنتی، و سازمان‌هایی با مقیاس متوسط، عملکرد قابل قبولی دارد. اما اگر بخواهیم از منظر معماری آن را قضاوت کنیم، باید بپذیریم که این پلتفرم در برابر شبکه‌های توزیع‌شده، سیستم‌های مبتنی بر Cloud و محیط‌های پویا، نه مشکل تنظیمات یا سخت‌افزار، بلکه محدودیت‌های ساختاری دارد. مونولیت Orion Core، وابستگی کامل به SQL Server، نبود pipelineهای توزیع‌شده، و مدل Polling Cycle محور، همه نشانه‌هایی هستند که می‌گویند SolarWinds برای دوره‌ای ساخته شده که دیگر وجود ندارد.

این مقاله می‌خواهد به همین نکته برسد: SolarWinds خراب نیست؛ فقط متعلق به معماری یک نسل قبل است. و این محدودیتی است که هرچقدر هم سرور اضافه کنیم، هیچ‌گاه برطرف نمی‌شود.

 در مقابل، پلتفرم‌هایی مانند پلتفرم مانیتورینگ معین با معماری  Event-Driven  و ذخیره‌سازی توزیع‌شده، نمونه‌ای از رویکرد نسل جدید محسوب می‌شوند؛ نه لزوماً بهتر یا بدتر، بلکه سازگارتر با الگوی داده و مقیاسی که شبکه‌های امروز تولید می‌کنند.

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