راهنمای جامع راه‌اندازی کلاسترینگ High Availability و دیتابیس همیشه در دسترس در ManageEngine

در سازمان‌های بزرگ، سامانه‌های مدیریت خدمات فناوری اطلاعات (ITSM) و پایش زیرساخت مانند ManageEngine ServiceDesk Plus، OpManager و Endpoint Central به عنوان شاهرگ حیاتی پایش و پشتیبانی عملیات روزمره شناخته می‌شوند. از کار افتادن (Downtime) این سامانه‌ها حتی برای چند دقیقه می‌تواند موجب توقف فرآیندهای پشتیبانی کاربران، عدم ثبت تیکت‌های بحرانی و کور شدن دید تیم‌های NOC/SOC نسبت به وضعیت تجهیزات شبکه گردد.

پیاده‌سازی معماری پایداری بالا (High Availability - HA) و افزونگی خودکار (Failover Service - FOS) امکان جابجایی بدون اختلال سرویس را بین دو سرور Primary و Secondary در صورت خرابی‌های سخت‌افزاری یا خطاهای سیستم‌عامل فراهم می‌سازد. در این مقاله جامع، معماری کلاسترینگ ManageEngine، سناریوهای اتصال به SQL Server AlwaysOn، مکانیزم همگام‌سازی شاخه‌های فایل (File Attachments) و فرآیند نگهداری لایسنس دائمی در بستر بدون اینترنت با جزئیات کامل فنی تشریح می‌شود.

۱. توپولوژی معماری کلاسترینگ ManageEngine (FOS Architecture) #

ساختار استاندارد افزونگی دو سروری (Active/Passive) در ManageEngine از سه لایه مستقل تشکیل یافته است:

۱. لایه اپلیکیشن (Master & Standby Application Nodes): دو ماشین مجازی یا فیزیکی مجزا با منابع سخت‌افزاری کاملاً یکسان.

۲. لایه دیتابیس مشترک (Shared Central Database): کلاستر SQL Server با قابلیت AlwaysOn Availability Groups یا سرور PostgreSQL با مکانیزم Streaming Replication.

۳. لایه فایل‌های استاتیک مشترک (Shared Network Storage - NAS/SAN): دایرکتوری اشتراکی مبتنی بر پروتکل SMB 3.0 یا NFS جهت نگهداری فایل‌های ضمیمه تیکت‌ها، لوگوها، مستندات پایگاه دانش (Knowledge Base) و پکیج‌های نصبی.

                  ┌─────────────────────────────────────────┐
                  │      Virtual IP / Load Balancer VIP     │
                  │              192.168.10.100             │
                  └───────────────────┬─────────────────────┘
                                      │
            ┌─────────────────────────┴─────────────────────────┐
            │                                                   │
            ▼                                                   ▼
┌───────────────────────┐                           ┌───────────────────────┐
│ Primary Server (Node1)│◄────── Heartbeat IP ─────►│Secondary Server(Node2)│
│    Active Instance    │      (192.168.20.101/102) │   Passive Standby     │
│     192.168.10.101    │                           │    192.168.10.102     │
└───────────┬───────────┘                           └───────────┬───────────┘
            │                                                   │
            ├─────────────────────────┬─────────────────────────┤
            │                         │                         │
            ▼                         ▼                         ▼
┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────────┐
│   Shared Storage NAS  │ │  MSSQL AlwaysOn Node1 │ │  MSSQL AlwaysOn Node2 │
│  \\nas-core\me-shared │ │    Primary Replica    │◄┼►│   Secondary Replica   │
│ (Custom, Attachments) │ │       (Read/Write)    │ │ (Synchronous-Commit)  │
└───────────────────────┘ └───────────────────────┘ └───────────────────────┘

الزامات شبکه و تخصیص اینترفیس‌ها

برای دستیابی به حداقل زمان تاخیر (Latency) و جلوگیری از پدیده Split-Brain، پیکربندی حداقل دو کارت شبکه (NIC) فیزیکی یا مجازی روی هر گره الزامی است:

• کارت شبکه اول (Public Management NIC): تبادل ترافیک با کلاینت‌ها، ادمین‌ها و سنسورهای شبکه (SNMP/WMI).
• کارت شبکه دوم (Dedicated Heartbeat NIC): لینک مستقیم ایزوله (Point-to-Point یا VLAN مستقل) بدون عبور از فایروال جهت بررسی زنده بودن گره‌ها با پورت‌های TCP 8090 و UDP 8091.

۲. راه‌اندازی لایه پایگاه داده با MSSQL AlwaysOn Availability Groups #

سامانه‌های ManageEngine در بار کاری بالا حجم انبوهی از تراکنش‌های درج لاگ رویدادها را تولید می‌کنند. پایگاه داده نباید به صورت Local روی سرور اپلیکیشن نصب باشد. بهترین معماری، استقرار پایگاه داده روی کلاستر همیشه در دسترس Microsoft SQL Server است.

اسکریپت آماده‌سازی دیتابیس و اعطای دسترسی‌های مورد نیاز

بر روی Instance اولیه SQL Server، دیتابیس را در حالت لاگین کامل (Full Recovery Model) قرار داده و حساب کاربری سرویس را پیکربندی نمایید:

-- ایجاد دیتابیس اختصاصی ServiceDesk Plus
CREATE DATABASE [servicedesk]
COLLATE SQL_Latin1_General_CP1_CI_AS;
GO

ALTER DATABASE [servicedesk] SET RECOVERY FULL;
GO

-- تهیه نسخه پشتیبان اولیه برای پیوستن به Availability Group
BACKUP DATABASE [servicedesk] 
TO DISK = N'\\backup-share\sql\servicedesk_full.bak' 
WITH INIT, STATS = 10;
GO

BACKUP LOG [servicedesk] 
TO DISK = N'\\backup-share\sql\servicedesk_log.trn' 
WITH INIT, STATS = 10;
GO

-- ایجاد حساب سرویس با دسترسی db_owner
CREATE LOGIN [me_service_user] WITH PASSWORD = N'StrongP@ssw0rd2026!#', CHECK_POLICY = ON;
GO

USE [servicedesk];
GO
CREATE USER [me_service_user] FOR LOGIN [me_service_user];
GO
ALTER ROLE [db_owner] ADD MEMBER [me_service_user];
GO

اتصال به دیتابیس از طریق ChangeDBServer

پیش از آغاز راه‌اندازی کلاسترینگ نرم‌افزار، اتصال هر دو سرور Primary و Secondary را به Listener نامگذاری‌شده کلاستر SQL برقرار کنید:

# اجرای ابزار تغییر پایگاه داده در محیط متنی
cd "C:\ManageEngine\ServiceDesk\bin"
.\changeDBServer.bat

در کادر باز شده، گزینه‌های زیر را تعیین نمایید:

• Database Server: MSSQL
• Host Name / Listener: sql-ag-listener.corp.local
• Port: 1433
• Instance Name: (در صورت استفاده از Default Instance خالی بگذارید)
• Database Name: servicedesk
• Authentication: SQL Authentication
• Username: me_service_user

۳. پیکربندی افزونگی Failover Service (FOS) در ManageEngine #

شرکت ManageEngine برای پیاده‌سازی FOS ابزار خط فرمانی اختصاصی ConfigureFOS.bat را در شاخه bin قرار داده است. مراحل زیر به ترتیب اولویت اجرا می‌شوند:

مرحله اول: تنظیم مسیر ذخیره‌سازی اشتراکی (Shared Repository)

روی سرور Primary، پوشه‌ای با دسترسی Read/Write کامل برای حساب کاربری ویندوز اجرای سرویس ManageEngine بر روی NAS به آدرس \\nas-core.corp.local\servicedesk-share آماده کنید. این پوشه محل نگهداری:

• custom/ (قالب‌های پرینت و فایل‌های محلی‌سازی)
• fileAttachments/ (فایل‌های ضمیمه تیکت‌ها و مکاتبات)
• inlineimages/ (تصاویر متن ایمیل‌ها و تیکت‌ها)

مرحله دوم: اجرای جادوگر ConfigureFOS بر روی سرور Primary

در کنسول PowerShell با سطح دسترسی Local Administrator:

cd "C:\ManageEngine\ServiceDesk\bin"
.\ConfigureFOS.bat

پارامترهای زیر را وارد کنید:

۱. Role: Primary

۲. Public IP of Primary: 192.168.10.101

۳. Redundant (Heartbeat) IP of Primary: 192.168.20.101

۴. Public IP of Secondary: 192.168.10.102

۵. Redundant (Heartbeat) IP of Secondary: 192.168.20.102

۶. Virtual IP (VIP) for Service: 192.168.10.100 (اختیاری در صورت استفاده از IP شناور یا ثبت رکوردهای DNS چندگانه)

۷. Shared Path: \\nas-core.corp.local\servicedesk-share

۸. Heartbeat Frequency: 5 ثانیه

۹. Heartbeat Retries / Failover Threshold: 3 بار تلاش متوالی (۱۵ ثانیه تشخیص قطعی)

مرحله سوم: همگام‌سازی و پیکربندی سرور Secondary

کل شاخه نصب نرم‌افزار را از سرور Primary (به جز شاخه log و فایل‌های موقت tmp) به سرور Secondary کپی کنید، سپس روی سرور دوم دستور زیر را اجرا نمایید:

cd "C:\ManageEngine\ServiceDesk\bin"
.\ConfigureFOS.bat

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

۴. لایسنسینگ آفلاین و پایدارسازی کلاستر در بستر Air-Gapped #

یکی از معضلات رایج در کلاسترینگ ManageEngine، سازوکار اعتبارسنجی لایسنس است؛ زیرا فایل لایسنس رسمی در اکثر ماژول‌ها شناسه سخت‌افزاری (MAC Address یا UUID) سرور Primary را بررسی می‌کند و در صورت سوییچ کردن به سرور Standby، با خطای Invalid License مواجه شده و سرویس در حالت محدود یا Expired بالا می‌آید.

استراتژی حل معضل لایسنسینگ با بسته Licentra:

۱. Dual-Node Licensing: پکیج انترپرایز ارائه‌شده توسط Licentra اثرانگشت هر دو سرور Node1 و Node2 را در قالب یک کلید متمرکز امضا می‌کند.

۲. عدم وابستگی به کالبک‌های Cloud: غیرفعال‌سازی سرویس‌های تله‌متری سازنده نظیر Zoho Analytics Sync و فرآیندهای استعلام خودکار پرتال Zoho Creator.

۳. پایداری پس از Failover: با انتقال سرویس به ماشین ثانویه، انجین لایسنس نیازی به فعال‌سازی مجدد یا دریافت تاییدیه شبکه نداشته و عملیات به صورت پیوسته ادامه می‌یابد.

# بررسی وضعیت سلامت سرویس و لایسنس کلاستر
Get-Service -Name "ManageEngine ServiceDesk Plus" | Select-Object Name, Status, StartType

# تست سلامت پورت‌های هارت‌بیت بین دو سرور
Test-NetConnection -ComputerName 192.168.20.102 -Port 8090 -InformationLevel Detailed

۵. چک‌لیست تست سناریوهای Failover و بازگشت به کار (Failback) #

قبل از بردن سامانه به زیر بار واقعی پروداکشن، سناریوهای بحران زیر را به دقت شبیه‌سازی کنید:

پیاده‌سازی این معماری، پایداری ۹۹.۹۹٪ سامانه‌های مانیتورینگ و تیکتینگ را در شبکه‌های حساس سازمانی تضمین کرده و مخاطرات ناشی از خطای تک‌نقطه‌ای (Single Point of Failure) را به طور کامل از بین می‌برد.