VCF Log Management 9.1؛ مهاجرت از Log Insight

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

VCF Log Management 9.1 ادامه ساده VMware Aria Operations for Logs یا همان Log Insight قدیمی نیست. Broadcom در این نسخه، معماری محصول را از مجموعه‌ای از Applianceهای مستقل به یک سرویس کانتینری در بستر VCF Services Runtime منتقل کرده و تجربه کاربری آن را مستقیماً داخل VCF Operations قرار داده است. این تغییر، شیوه استقرار، ارتقا، مدیریت هویت، گواهی‌ها، نگهداری و حتی برنامه مهاجرت را عوض می‌کند.

در این مقاله، VCF Log Management 9.1 را از زاویه معماری و بهره‌برداری بررسی می‌کنیم، تفاوت آن را با vRealize Log Insight و Aria Operations for Logs نسخه ۸ و VCF Operations for Logs نسخه ۹ توضیح می‌دهیم و در پایان به این پرسش می‌رسیم که اجرای آن در یک دیتاسنتر ایرانی چه پیش‌نیازها و محدودیت‌هایی دارد.

VCF Log Management 9.1 دقیقاً چیست؟

VCF Log Management 9.1 سرویس متمرکز جمع‌آوری، پردازش، ذخیره‌سازی، جست‌وجو و تحلیل لاگ در VMware Cloud Foundation است. Broadcom در مستندات و رابط‌های مختلف گاهی از عبارت‌های Log Management، VCF Operations Log Management و در برخی KBها از نام میراثی VCF Operations for Logs استفاده می‌کند؛ اما نام معماری جدید در نسخه 9.1 همان VCF Log Management است.

این سرویس لاگ‌های اجزای VCF مانند ESX، vCenter، NSX، SDDC Manager و سرویس‌های مدیریتی را دریافت می‌کند و امکاناتی مانند جست‌وجوی تعاملی، فیلتر و استخراج فیلدها، مقایسه بازه‌های زمانی، ساخت Alert، پردازش رویدادها، داشبوردهای سلامت و ارسال لاگ به سامانه‌های ثالث را در اختیار تیم عملیات قرار می‌دهد. نکته مهم این است که در 9.1 رابط مستقل برای کار روزمره حذف شده و بخش‌های اصلی تحلیل و مدیریت لاگ در مسیر Operate > Logs در VCF Operations قرار گرفته‌اند.

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

از Log Insight تا VCF Log Management؛ چه چیزی تغییر کرده است؟

نسخه ۸: Appliance مستقل و مدیریت جداگانه

در خانواده vRealize Log Insight و سپس VMware Aria Operations for Logs 8.x، محصول به‌صورت یک یا چند Appliance مجازی مستقر می‌شد. کلاستر، VIP، گواهی، حساب‌های مدیریتی، Content Packها، Retention و Lifecycle محصول ساختار مستقلی داشتند. در معماری‌های مبتنی بر VCF 4.x و 5.x نیز چرخه عمر این اجزا معمولاً از طریق Aria Suite Lifecycle یا vRealize Suite Lifecycle Manager مدیریت می‌شد.

این مدل بالغ و شناخته‌شده بود، اما تیم عملیات برای مشاهده متریک‌ها، لاگ‌ها، جریان شبکه و وضعیت Lifecycle ناچار بود میان چند رابط جابه‌جا شود. همچنین نگهداری چند Appliance، طراحی Load Balancer، مدیریت گواهی و ارتقای جداگانه محصول سربار عملیاتی ایجاد می‌کرد.

نسخه ۹: تجربه یکپارچه، زیرساخت هنوز مستقل

در VCF 9.0 تجربه تحلیل لاگ وارد VCF Operations شد. قابلیت‌هایی مانند Logs Analysis، مقایسه لاگ‌ها، ایجاد Alert و هم‌بستگی متریک و لاگ از کنسول VCF Operations قابل دسترس شدند. این مرحله، مشکل جابه‌جایی میان رابط‌ها را تا حد زیادی کاهش داد؛ اما VCF Operations for Logs 9.0.x همچنان بر Applianceهای مستقل خود متکی بود.

به بیان ساده، نسخه ۹ رابط را یکپارچه‌تر کرد، ولی معماری اجرایی Log Management هنوز به مدل پیشین شباهت داشت. Fleet Management Appliance نیز در VCF 9.0 بخشی از مدیریت چرخه عمر اجزای VCF بود.

نسخه 9.1: سرویس کانتینری روی Runtime مشترک

در VCF 9.1 تغییر اصلی زیر رابط کاربری اتفاق افتاده است. Broadcom موتور Log Management را از Applianceهای مستقل به معماری میکروسرویس کانتینری روی VCF Services Runtime منتقل کرده است. طبق معرفی رسمی قابلیت‌های VCF 9.1، سرویس‌های مدیریتی مانند Lifecycle، Software Depot، Log Management و Real-time Data روی Runtime مشترک توزیع می‌شوند.

در Hands-on Lab رسمی VCF 9.1 نیز معماری جدید Log Management مبتنی بر OpenSearch معرفی شده است. بنابراین تغییر 9.1 صرفاً Rebranding نیست؛ موتور ذخیره و جست‌وجو، مدل استقرار و سطح یکپارچگی محصول بازطراحی شده‌اند.

موضوع	Log Insight / Aria Operations for Logs 8.x	VCF Operations for Logs 9.0	VCF Log Management 9.1
مدل استقرار	Appliance یا کلاستر مستقل	Appliance مستقل با یکپارچگی بیشتر	سرویس کانتینری روی VCF Services Runtime
رابط اصلی	رابط مستقل Log Insight	تحلیل لاگ در VCF Operations؛ مدیریت زیرساخت مستقل	تجربه کامل لاگ در VCF Operations
موتور و معماری داده	معماری قدیمی Log Insight مبتنی بر Appliance	تداوم معماری Appliance	معماری جدید مبتنی بر OpenSearch
Lifecycle	Aria Suite Lifecycle / مدیریت محصول	VCF Fleet Management	VCF Management Services و Fleet Lifecycle
روش انتقال به 9.1	استقرار مقصد جدید و انتقال داده	Side-by-Side و Migration	معماری مقصد
UI مستقل	لازم و اصلی	هنوز برای برخی امور وجود دارد	برای کار عادی لازم نیست؛ Break-glass برای شرایط اضطراری

معماری VCF Log Management 9.1

VCF Management Services در نسخه 9.1 یک لایه اجباری برای VMware Cloud Foundation است و سرویس‌های مدیریتی را روی یک Runtime مشترک میزبانی می‌کند. Log Management یکی از سرویس‌هایی است که روی این بستر مستقر می‌شود. این معماری چند پیامد عملی دارد:

Lifecycle متمرکز: استقرار، Patch، ارتقا و کنترل سلامت از گردش‌کارهای VCF Operations و VCF Management Services انجام می‌شود.
هویت و امنیت یکپارچه: منوهای مستقل Password و SSO مربوط به Appliance قدیمی دیگر معیار مدیریت 9.1 نیستند. این حذف، رفتار مورد انتظار معماری جدید است.
کاهش Applianceهای مستقل: پس از انتقال موفق داده و تنظیمات، Applianceهای قدیمی 9.0 یا 8.x باید طبق برنامه رسمی Decommission شوند.
موتور جست‌وجوی جدید: OpenSearch پایه معماری Native Log Management در نسخه 9.1 است.
تجربه یکپارچه: متریک، Log، Flow، Finding و Audit Trail در یک کنسول کنار یکدیگر قرار می‌گیرند.

VCF Log Management را نباید صرفاً یک Syslog Server با رابط زیبا دانست. ارزش اصلی آن زمانی مشخص می‌شود که یک رخداد را از سطح Alert و Metric به لاگ مرتبط، تغییر پیکربندی، هویت کاربر و اثر آن بر سرویس دنبال می‌کنیم.

قابلیت‌های مهم در VCF 9.1

تحلیل لاگ در همان کنسول VCF Operations

در نسخه 9.1 قابلیت‌های رابط مستقل VCF Operations for Logs، از جمله Log Processing Rules، تنظیمات مدیریتی کلاستر، APIهای عمومی، Global Settings و صفحات تحلیل لاگ، داخل VCF Operations ادغام شده‌اند. نتیجه این تغییر برای تیم NOC و SRE، کاهش زمان جابه‌جایی میان ابزارها و امکان مشاهده هم‌زمان شواهد متریک و لاگ است.

جست‌وجو، فیلتر، مقایسه و هم‌بستگی

مدیر زیرساخت می‌تواند رخدادها را براساس زمان، منبع، Hostname، Severity و فیلدهای استخراج‌شده جست‌وجو کند. قابلیت Logs Compare که در VCF 9 معرفی شد، امکان مقایسه الگوی رخدادها میان دو بازه زمانی را فراهم می‌کند. در یک Incident واقعی، این قابلیت کمک می‌کند تفاوت رفتار سیستم قبل و بعد از تغییر، Patch یا افت سرویس سریع‌تر دیده شود.

استانداردسازی لاگ و Audit Trail

VCF 9.1 قالب لاگ و Audit Record را میان اجزای پلتفرم استانداردتر کرده است. Audit Trail در VCF Operations یک نمای زمان‌محور از فعالیت کاربران و تغییرات اجزای VCF، از جمله VKS، ارائه می‌کند. برای بررسی تغییر Firewall، ورود ناموفق، تغییر تنظیمات یا تحلیل زنجیره یک رخداد امنیتی، این قابلیت بسیار کاربردی است.

ارسال به راهکارهای ثالث

یکپارچه‌شدن Log Management به معنای بسته‌شدن اکوسیستم نیست. Broadcom بر Log Forwarding به راهکارهای ثالث و استفاده از APIها تأکید کرده است. بنابراین سازمانی که SIEM، Data Lake یا Pipeline دیگری دارد می‌تواند VCF Log Management را به‌عنوان لایه جمع‌آوری و تحلیل عملیاتی VCF نگه دارد و رویدادهای مورد نیاز را به مقصد دیگری ارسال کند.

داشبوردهای سلامت و تشخیص اختلال

داشبوردهای Log Management وضعیت Ingestion، صف، زمان پاسخ نوشتن، سلامت Log Store و Shardها را نمایش می‌دهند. البته برخی هشدارهای نسخه GA باید با شناخت معماری تفسیر شوند. برای مثال Broadcom اعلام کرده در کلاستر تک‌نودی ممکن است Replica Shard کنار Primary قرار نگیرد و وضعیت سلامت به‌اشتباه Degraded یا Critical دیده شود. همچنین Dynamic Threshold نامناسب می‌تواند هشدار کاذب Ingestion ایجاد کند.

مسیر مهاجرت از Aria Operations for Logs و Log Insight

مهم‌ترین نکته این بخش ساده است: برای VCF Log Management 9.1 مسیر Upgrade درجا وجود ندارد. دلیل، تفاوت بنیادی معماری مبدأ و مقصد است. Broadcom این فرایند را به‌صورت استقرار Side-by-Side و سپس انتقال تنظیمات و داده اجرا می‌کند.

اگر مبدأ Aria Operations for Logs 8.x است

ابتدا توالی ارتقای کلی VCF و پیش‌نیازهای VCF Operations 9.1 را بررسی کنید.
VCF Management Services و Runtime مورد نیاز را مستقر کنید.
Log Management 9.1 را از مسیر Build > Lifecycle > VCF Management مستقر کنید.
جمع‌آوری‌کننده‌ها، مقصدها، گواهی‌ها و ارتباطات شبکه را اعتبارسنجی کنید.
انتقال داده‌های تاریخی و تنظیمات لازم را با Workflow رسمی انجام دهید.
پس از تأیید Ingestion، جست‌وجو، Forwarding و Retention، Appliance قدیمی را Decommission کنید.

طبق KB رسمی Broadcom، Aria Log Insight 8.x در طول ارتقای اجزای مدیریتی از کار نمی‌افتد و می‌تواند تا زمان فعال‌سازی سرویس جدید به کار خود ادامه دهد. این موضوع امکان برنامه‌ریزی مهاجرت با ریسک کمتر را فراهم می‌کند.

اگر مبدأ VCF Operations for Logs 9.0.x است

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

برای انتقال داده، همه Nodeهای مبدأ باید با SSH از Nodeهای Log Management 9.1 قابل دسترس باشند و اعتبارنامه Root آن‌ها یکسان باشد. Broadcom در KB 443711 صراحتاً اعلام کرده است که ردشدن اتصال SSH یا متفاوت‌بودن Credentialها باعث شکست Data Transfer می‌شود. همچنین FQDN مقصد باید با FQDN محیط مبدأ متفاوت باشد؛ استفاده مجدد از FQDN می‌تواند خطای Thumbprint و شکست Workflow ایجاد کند.

یک نکته مهم درباره Precheck

در برخی Buildهای 9.1، رابط کاربری دکمه Run Prechecks را برای انتقال از 9.0 نمایش می‌دهد، در حالی که Backend برای این مسیر Task Definition مستقلی ندارد. نتیجه، خطای 500 است. براساس KB 442588، اعتبارسنجی‌ها در جریان Deployment انجام می‌شوند و برای این مورد مشخص باید طبق دستور Broadcom مستقیماً Workflow ارتقا را اجرا کرد. این یک استثنای مستند است، نه توصیه عمومی برای نادیده‌گرفتن Precheckها.

پیش‌نیازها و نکات طراحی

VCF Management Services

در VCF 9.1، Management Services برای VCF اجباری و برای VVF اختیاری است. Broadcom حداقل ۱۲ آدرس IP روی Management Network برای استقرار اولیه این لایه اعلام کرده و امکان افزودن ۱۸ آدرس دیگر را برای توسعه آینده در نظر گرفته است. همه IP Rangeها باید روی شبکه مدیریتی باشند.

Runtime به‌صورت پیش‌فرض از محدوده داخلی 198.18.0.0/15 استفاده می‌کند. اگر این محدوده با طراحی فعلی شبکه تداخل داشته باشد، باید پیش از استقرار با JSON Specification به 240.0.0.0/15 یا 250.0.0.0/15 تغییر کند. اصلاح این موضوع بعد از استقرار، بسیار پرهزینه‌تر از بررسی آن در مرحله طراحی است.

DNS، FQDN، زمان و گواهی

برای سرویس Log Management یک FQDN یکتا، رکوردهای DNS معتبر، همگام‌سازی NTP و گواهی کامل لازم است. IP مربوط به FQDN باید در همان Management Network اجزای VCF Management Services قرار گیرد و نباید قبلاً به Node دیگری از Runtime اختصاص یافته باشد.

در محیط‌هایی که Microsoft CA دارای Intermediate CA استفاده می‌شود، Buildهای ابتدایی 9.1 مشکل شناخته‌شده‌ای در دریافت خودکار زنجیره کامل گواهی داشتند. این ایراد در VCF Operations 9.1.0.0200 اصلاح شده است. در Buildهای قدیمی‌تر باید CSR تولید و زنجیره کامل Leaf، Intermediate و Root به‌صورت دستی Import شود.

Sizing را با نرخ Ingestion طراحی کنید

انتخاب پروفایل Log Management باید با ظرفیت VCF Management Instance سازگار باشد. ترکیب یک Management Instance کوچک با پروفایل Large می‌تواند استقرار را در مرحله Initialize VCF Services Runtime متوقف کند. نرخ رخداد روزانه، دوره Retention، تعداد منابع، Peak Ingestion، Replica و HA باید پیش از انتخاب Profile اندازه‌گیری شوند.

یک سناریوی واقعی عیب‌یابی

فرض کنید پس از تغییر یک Policy در NSX، چند ماشین مجازی به سرویس بانک اطلاعاتی دسترسی ندارند. در رویکرد سنتی، مدیر شبکه Flowها را در یک ابزار می‌بیند، مدیر VMware رویدادهای vCenter را بررسی می‌کند و تیم امنیت سراغ لاگ Firewall می‌رود. زمان زیادی صرف هم‌زمان‌سازی Timestampها و اثبات رابطه رویدادها می‌شود.

در VCF Operations 9.1 می‌توان از Alert یا Finding شروع کرد، بازه زمانی اختلال را مشخص کرد، لاگ‌های NSX و ESX را در همان فضای عملیاتی فیلتر کرد، تغییر ثبت‌شده در Audit Trail را دید و سپس Flow مرتبط را بررسی کرد. هدف این نیست که یک ابزار جای تخصص شبکه یا امنیت را بگیرد؛ هدف این است که شواهد مرتبط در یک خط زمانی مشترک دیده شوند.

آیا VCF Log Management 9.1 در ایران قابل استفاده است؟

در اسناد رسمی بررسی‌شده، قفل فنی منطقه‌ای برای اجرای محلی VCF Log Management 9.1 ذکر نشده است. پردازش، ذخیره‌سازی و جست‌وجوی لاگ در زیرساخت خصوصی سازمان انجام می‌شود و VCF 9.1 برای Software Depot از سناریوهای Connected و Disconnected پشتیبانی می‌کند. بنابراین از نظر معماری، راه‌اندازی در دیتاسنتر داخلی و محیط بدون دسترسی دائمی اینترنت ممکن است.

اما «قابل اجرا بودن فنی» با «دسترسی تجاری و پشتیبانی رسمی» یکسان نیست. تهیه Subscription معتبر، دسترسی به Broadcom Support Portal، دریافت Binary و Patch، فعال‌سازی Entitlement، دسترسی به KBهای محدود و دریافت Support ممکن است تابع قرارداد، کشور حساب، قوانین صادراتی و سیاست‌های Broadcom باشد. برای این بخش نمی‌توان بدون بررسی قرارداد و وضعیت حساب مشتری حکم کلی صادر کرد.

برای اجرای Disconnected در ایران باید این موارد از ابتدا طراحی شوند:

Depot داخلی و روش کنترل‌شده ورود Bundleها، Patchها و Metadata؛
License Server محلی و Entitlement معتبر؛
DNS، NTP، CA و مخزن گواهی داخلی؛
IP Range کافی برای VCF Management Services؛
مسیر پشتیبان برای دریافت به‌روزرسانی‌های امنیتی و KBهای مورد نیاز؛
ظرفیت ذخیره‌سازی متناسب با Retention و نرخ واقعی Ingestion؛
برنامه Export یا Forwarding رخدادهای ضروری به SIEM سازمان.

در یک پروژه ایرانی، بزرگ‌ترین ریسک معمولاً خود موتور Log Management نیست؛ ریسک اصلی، بی‌توجهی به زنجیره تأمین نرم‌افزار، لایسنس، Patch و ظرفیت Runtime است.

VCF Log Management برای چه تیم‌هایی ارزش بیشتری دارد؟

این سرویس برای سازمانی بیشترین ارزش را دارد که چندین Workload Domain، حجم بالای رخداد، تیم‌های مجزای شبکه و امنیت، نیاز Audit یا الزام کاهش MTTR دارد. در یک محیط کوچک با چند Host، استفاده از همه قابلیت‌ها ممکن است در برابر منابع مورد نیاز توجیه اقتصادی نداشته باشد؛ به‌خصوص اگر VVF 9.1 استفاده شود و Management Services در آن اختیاری باشد.

برای متخصصانی که مسیر آموزش VMware و نقشه راه تخصص‌های VMware در ابرکلاس را دنبال می‌کنند، یادگیری Log Management فقط آموزش یک رابط جست‌وجو نیست. در مسیر آموزش مجازی سازی مدرن باید ارتباط میان Log، Metric، Flow، Audit، Lifecycle و Security را درک کرد. همین نگاه در آموزش VCF نقش محوری دارد و برای افرادی که آموزش VVF را دنبال می‌کنند نیز در طراحی Observability و انتخاب اجزای اختیاری اهمیت پیدا می‌کند.

جمع‌بندی فنی

VCF Log Management 9.1 پایان تدریجی مدل Applianceمحور Log Insight و آغاز یک سرویس Native در معماری VCF است. ادغام رابط کاربری، استفاده از OpenSearch، اجرای سرویس روی VCF Services Runtime و انتقال Lifecycle به VCF Management Services، مدیریت روزمره را یکپارچه‌تر می‌کند؛ اما مهاجرت را نیز حساس‌تر می‌سازد.

اگر از نسخه ۸ یا ۹ حرکت می‌کنید، پروژه را Upgrade ساده نبینید. مقصد جدید را کنار محیط فعلی طراحی کنید، FQDN و IP مستقل بدهید، سازگاری Sizing و Certificate را کنترل کنید، Data Transfer را با دسترسی SSH معتبر انجام دهید و تنها پس از تأیید Ingestion و Retention، Applianceهای قدیمی را کنار بگذارید. تفاوت یک مهاجرت موفق و یک شکاف لاگ چندروزه معمولاً در همین جزئیات است.

پرسش‌های متداول

آیا VCF Log Management 9.1 همان VMware Aria Operations for Logs است؟

از نظر مأموریت محصول، ادامه همان خانواده است؛ اما از نظر معماری یک نسخه عادی یا تغییر نام ساده محسوب نمی‌شود. نسخه 9.1 به سرویس کانتینری روی VCF Services Runtime و موتور OpenSearch منتقل شده است.

آیا برای مهاجرت از Log Insight 8.x می‌توان In-place Upgrade انجام داد؟

خیر. مقصد 9.1 با معماری جدید در کنار محیط مبدأ مستقر می‌شود و سپس داده و تنظیمات لازم منتقل می‌شوند. Appliance قدیمی بعد از تأیید کامل محیط مقصد Decommission می‌شود.

آیا VCF Log Management رابط مستقل دارد؟

قابلیت‌های اصلی آن در VCF Operations ادغام شده‌اند و برای عملیات عادی رابط مستقل لازم نیست. Broadcom برای شرایط اضطراری که VCF Operations در دسترس نیست، مسیر Break-glass را مستند کرده است.

آیا Log Management در VCF 9.1 اجباری است؟

VCF Management Services در VCF 9.1 اجباری است و Log Management یکی از سرویس‌های قابل استقرار روی آن محسوب می‌شود. در VVF 9.1، Management Services اختیاری است؛ بنابراین طراحی و نیاز عملیاتی سازمان تعیین می‌کند این سرویس مستقر شود یا نه.

برای انتقال داده از نسخه 9.0 چه شبکه‌ای لازم است؟

Nodeهای Log Management 9.1 باید بتوانند از طریق پورت 22 به همه Nodeهای VCF Operations for Logs 9.0.x متصل شوند. Credentialهای Root مبدأ باید بین Nodeها یکسان و معتبر باشند و FQDN مقصد نیز باید با مبدأ تفاوت داشته باشد.

آیا می‌توان لاگ‌ها را به SIEM دیگری ارسال کرد؟

بله. VCF 9.1 قابلیت Forwarding به راهکارهای ثالث و APIهای مرتبط با مدیریت و تحلیل لاگ را حفظ کرده است. طراحی دقیق به مقصد، قالب مورد انتظار، ظرفیت شبکه و سیاست امنیتی سازمان وابسته است.

مرکز حقیقت؛ VCF Log Management 9.1