کالبدشکافی ManageEngine (بخش پنجم): بن‌بست مقیاس‌پذیری؛ چرا ManageEngine زیر بار شبکه‌های Enterprise کمر خم می‌کند؟

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

تیم عملیات یک سازمان بزرگ، سال‌هاست که از ManageEngine برای مانیتورینگ و مدیریت زیرساخت خود استفاده می‌کند. در ابتدای کار، زمانی که تعداد سرورها و endpointها محدود است، ManageEngine بدون مشکل عمل می‌کند؛ داشبوردها سریع باز می‌شوند، هشدارها به‌موقع ثبت می‌شوند و دید مناسبی از وضعیت زیرساخت ارائه می‌دهد.

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

در ابتدا این مشکلات معمولاً به کمبود منابع سخت‌افزاری نسبت داده می‌شود، اما با گذشت زمان مشخص می‌شود که با افزایش مقیاس، ManageEngine دیگر نمی‌تواند بار پردازشی شبکه‌های بزرگ را به‌خوبی مدیریت کند. مشکل اصلی تنها افزایش CPU یا RAM نیست؛ معماری ManageEngine به‌گونه‌ای است که با بزرگ‌تر شدن زیرساخت، حجم زیادی از پردازش‌ها به یک نقطه مرکزی منتقل می‌شود و این نقطه به‌سرعت به گلوگاه تبدیل می‌شود.

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

مقیاس‌پذیری در ابزارهای مدیریت زیرساخت؛ مسئله‌ای فراتر از افزایش منابع

در نگاه اول، مقیاس‌پذیری در ManageEngine ممکن است به افزایش CPU، RAM یا ظرفیت پایگاه‌داده تقلیل داده شود؛ انگار کافی است سرور مدیریت را قوی‌تر کنیم تا مشکل حل شود. اما در شبکه‌های Enterprise، مسئله دقیقاً از همین‌جا آغاز می‌شود، نه پایان آن.

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

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

گلوگاه پنهان: وقتی سرور مدیریت به نقطه فشار تبدیل می‌شود

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

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

تمرکز پردازش؛ ریشه بسیاری از مشکلات مقیاس‌پذیری

زمانی که ManageEngine بخش بزرگی از پردازش‌ها، تحلیل داده‌ها و تصمیم‌گیری‌های عملیاتی را در یک نقطه متمرکز می‌کند، ظرفیت همان نقطه عملاً سقف مقیاس‌پذیری کل سیستم را تعیین می‌کند. حتی با افزایش منابع سخت‌افزاری نیز این محدودیت به‌طور کامل برطرف نمی‌شود، زیرا مسئله فقط قدرت پردازش نیست؛ نحوه توزیع بار در معماری ManageEngine نیز نقش تعیین‌کننده دارد.

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

سه چالش اصلی مقیاس‌پذیری در شبکه‌های Enterprise

در مقیاس سازمانی، فشار وارد بر ManageEngine تنها از یک مسیر ایجاد نمی‌شود. معمولاً سه عامل هم‌زمان باعث افزایش بار سیستم ManageEngine می‌شوند.

• فشار بر پایگاه داده

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

• بار ناشی از Polling

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

• تمرکز پردازش‌ها در سرور مرکزی

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

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

نشانه‌های بن‌بست مقیاس‌پذیری در عمل

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

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

این نشانه‌ها در ظاهر مشکلات عملکردی به نظر می‌رسند، اما اغلب ریشه آن‌ها در معماری   ManageEngine است که با رشد زیرساخت، بار بیشتری را در یک نقطه متمرکز می‌کند.

جمع‌بندی

در نگاه اول، چالش مقیاس‌پذیری در ManageEngine ممکن است صرفاً یک مسئله عملکردی به نظر برسد؛ مشکلی که با افزایش منابع سخت‌افزاری قابل حل است. اما تجربه بسیاری از سازمان‌های بزرگ نشان می‌دهد که ریشه این مسئله اغلب در معماری  ManageEngine نهفته است.

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

به همین دلیل، در محیط‌های Enterprise، مقیاس‌پذیری ManageEngine تنها یک ویژگی فنی ساده نیست، بلکه مستقیماً به نحوه طراحی معماری پلتفرم وابسته است. معماری‌ای که بتواند بار سیستم را به‌صورت مؤثر توزیع کند، نقش مهمی در پایداری و کارایی ManageEngine در مقیاس‌های بزرگ خواهد داشت.

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

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