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

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

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

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

در این مقاله تلاش می‌کنیم برخی از هزینه‌های پنهان SolarWinds را بررسی کنیم؛ هزینه‌هایی که معمولاً در مرحله خرید چندان دیده نمی‌شوند اما در بلندمدت می‌توانند سهم قابل توجهی از بودجه IT سازمان‌ها را به خود اختصاص دهند.

هزینه معماری: وابستگی به SQL Server

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

یکی از مهم‌ترین هزینه‌هایی که در نگاه اول به چشم نمی‌آید، وابستگی عمیق معماری SolarWinds به پایگاه داده Microsoft SQL Server است. در معماری Orion تقریباً تمام داده‌های سیستم—از نتایج polling گرفته تا اطلاعات inventory، هشدارها و داده‌های تاریخی—در SQL Server ذخیره می‌شوند.

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

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

در بسیاری از این محیط‌ها، استفاده از SQL Server Standard در بلندمدت پاسخگوی حجم پردازش و داده نخواهد بود (و حتی تلاش برای سرپا نگه داشتن آن با نسخه استاندارد، نیازمند استخدام متخصصان گران‌قیمت DBA و تجهیزات ذخیره‌سازی All-Flash است.) در نتیجه سازمان ناچار می‌شود به نسخه Enterprise مهاجرت کند. تفاوت هزینه این دو نسخه قابل توجه است؛ در مدل لایسنس مبتنی بر هسته پردازشی (Per‑Core)، هزینه SQL Server Enterprise معمولاً حدود سه تا چهار برابر نسخه Standard است.

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

هزینه زیرساخت: معماری Polling و رشد سرورهای مانیتورینگ

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

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

در چنین شرایطی یک سرور مانیتورینگ به‌تنهایی دیگر قادر به مدیریت تمام این درخواست‌ها نخواهد بود. به همین دلیل در محیط‌های بزرگ‌تر معمولاً نیاز به اضافه کردن سرورهای جدیدی با عنوان Additional Polling Engine به وجود می‌آید تا بار پردازشی بین چند سرور توزیع شود.

در ظاهر این کار یک راهکار فنی برای افزایش ظرفیت سیستم است، اما در عمل به معنای افزایش هزینه‌های زیرساخت نیز خواهد بود. برخلاف پلتفرم‌های مدرن که از  collectorهای سبک یا agentهای کم‌هزینه استفاده می‌کنند،. هر Polling Engine جدید به یک سرور مجزا، منابع پردازشی و حافظه بیشتر و در بسیاری موارد لایسنس‌های نرم‌افزاری اضافی نیاز دارد. علاوه بر این، پیچیدگی نگهداری سیستم نیز افزایش پیدا می‌کند زیرا هر سرور جدید باید نصب، پیکربندی و مدیریت شود.

به همین دلیل در بسیاری از پیاده‌سازی‌های بزرگ، زیرساخت SolarWinds به مجموعه‌ای از چندین سرور تبدیل می‌شود؛ شامل سرور اصلی Orion، سرور پایگاه داده SQL، چند Polling Engine و گاهی سرورهای جداگانه برای Web Console یا High Availability. در چنین معماری‌ای هزینه واقعی سیستم مانیتورینگ دیگر فقط به قیمت نرم‌افزار محدود نمی‌شود، بلکه مجموعه‌ای از منابع زیرساختی نیز به‌تدریج به آن اضافه می‌شوند.

برای درک بهتر این موضوع، می‌توان یک سناریوی ساده را در نظر گرفت. فرض کنید سازمانی قصد مانیتورینگ حدود ۲۰۰۰ تا ۳۰۰۰ دستگاه شبکه و سرور را دارد. در چنین محیطی معمولاً حداقل یک سرور Orion Core، یک سرور SQL Server و یک Polling Engine اضافی مورد نیاز است. با رشد محیط—برای مثال افزایش تعداد دستگاه‌ها یا متریک‌هایی که باید مانیتور شوند—اغلب لازم است Polling Engineهای بیشتری به زیرساخت اضافه شود.

هر Polling Engine جدید به معنای تهیه یک سرور دیگر، افزایش منابع مورد نیاز برای پایگاه داده و هزینه‌های نگهداری بیشتر است. در عمل، اضافه شدن تنها دو Polling Engine می‌تواند هزینه زیرساخت مانیتورینگ را در مقایسه با استقرار اولیه بین ۳۰ تا ۶۰ درصد افزایش دهد.

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

هزینه افزایش لایسنس: مدل لایسنس مبتنی بر Element و رشد تدریجی هزینه‌ها

یکی دیگر از عواملی که می‌تواند در بلندمدت هزینه استفاده از SolarWinds را افزایش دهد، مدل لایسنس این پلتفرم است. اگرچه این شرکت در محصولات جدیدتر خود (مانند پلتفرم HCO) تلاش کرده تا مدل قیمت‌گذاری را تغییر دهد، اما در ساختارهای سنتی و رایجِ اکوسیستم Orion که همچنان در اکثر سازمان‌ها استفاده می‌شود، لایسنس بر اساس مفهومی به نام Element  محاسبه می‌شود. Element می‌تواند شامل اجزای مختلفی مانند  Node، Interface، Volume  یا برخی متریک‌های قابل مانیتور باشد.

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

برای مثال، فرض کنید یک سازمان قصد مانیتورینگ ۱۰۰ سوئیچ شبکه را دارد. اگر هر سوئیچ به‌طور متوسط ۴۸ پورت فعال داشته باشد و این Interfaceها مانیتور شوند، تنها برای Interfaceها حدود ۴۸۰۰ Element ایجاد خواهد شد. اگر در کنار آن وضعیت خود دستگاه‌ها (Node)، برخی Volumeها یا متریک‌های دیگر نیز مانیتور شوند، تعداد کل Elementها به‌سرعت افزایش پیدا می‌کند.

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

برای درک بهتر این موضوع، فرض کنید یک سازمان در ابتدا لایسنس مناسب برای حدود ۵۰۰۰ Element تهیه کرده است. با اضافه شدن چند سوئیچ جدید، مانیتورینگ Interfaceهای بیشتر یا فعال شدن چند قابلیت اضافی، تعداد Elementها ممکن است از این حد عبور کند. در این حالت سازمان ناچار خواهد بود لایسنس خود را به سطح بعدی—برای مثال ۱۰٬۰۰۰ Element—ارتقا دهد، حتی اگر استفاده واقعی از ظرفیت جدید بسیار کمتر از این مقدار باشد.

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

به همین دلیل، اگرچه مدل Element‑based در ابتدا انعطاف‌پذیر به نظر می‌رسد، اما در مقیاس بزرگ می‌تواند به یکی از عوامل مهم در افزایش هزینه کل مالکیت (TCO) سیستم مانیتورینگ تبدیل شود.

جمع‌بندی: عبور از معماری‌های منسوخ با پلتفرم مانیتورینگ معین

مدل Element-Based و معماری متکی بر SQL Server متعلق به دهه‌ی گذشته شبکه‌هاست. سازمان شما نباید تاوانِ مقیاس‌ناپذیری معماری یک نرم‌افزار را با خرید سخت‌افزارهای گران‌قیمت و لایسنس‌های پنهان بپردازد.

در پلتفرم معین، ما این معماری پرهزینه را دگرگون کرده‌ایم. با استفاده از پایگاه داده سری‌زمانی (TSDB) اختصاصی، شما دیگر نیازی به خرید و نگهداری دیتابیس‌های سنگینِ رابطه‌ای ندارید. مهم‌تر از آن، مدل قیمت‌گذاری معین کاملاً شفاف و بر اساس شاخص‌های کلان زیرساخت است، نه شمارش دانه به دانه‌ی پورت‌ها و اینترفیس‌ها (Elements).

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