راهنمای DHCP Failover در DDI Central؛ طراحی Primary/Secondary، Synchronization Lease، High Availability، Failback Test و کنترل Scope Capacity.

شرکت مدانت

اگر DHCP Server از دسترس خارج شود، مشکل فقط «نگرفتن IP» نیست. کل زنجیره دسترسی کاربران، VoIP، Wi-Fi، Endpointها و حتی بعضی سرویس‌های وابسته می‌تواند دچار اختلال شود. در شبکه‌های بزرگ، داشتن یک DHCP Server ثانویه بدون Synchronization درست نیز کافی نیست؛ چون Leaseها باید هماهنگ بمانند و در زمان Failover، Scope به شکل کنترل‌شده سرویس بدهد.

DHCP Failover در ManageEngine DDI Central برای ایجاد Redundancy و High Availability در سرویس DHCP IPv4 طراحی شده است. طبق مستندات رسمی ManageEngine، Primary و Secondary DHCP Server با یکدیگر هماهنگ می‌شوند تا در صورت اختلال یکی از آن‌ها، سرویس Lease ادامه پیدا کند.

DHCP Failover چه مسئله‌ای را حل می‌کند؟

در معماری تک‌سروره، DHCP یک Single Point of Failure است. اگر Server Down شود یا Service مشکل پیدا کند، دستگاه‌های جدید IP نمی‌گیرند و Clientهایی که Lease آن‌ها نیاز به Renewal دارد نیز به‌تدریج دچار اختلال می‌شوند.

مدل ریسک نتیجه
Single DHCP خرابی Server یا Service قطع تخصیص Lease
دو DHCP مستقل Overlap و عدم Synchronization IP Conflict و مدیریت سخت
DHCP Failover نیاز به طراحی صحیح Pair Redundancy و Continuity بهتر

Primary و Secondary چگونه کار می‌کنند؟

ManageEngine در DDI Central برای Failover یک Primary DHCP و Secondary DHCP تعریف می‌کند. Primary معمولاً بخش اصلی Requestها را مدیریت می‌کند و Secondary برای Redundancy آماده است. Synchronization اطلاعات Lease باعث می‌شود Secondary Context لازم برای ادامه سرویس را داشته باشد.

نکته مهم: مستندات فعلی ManageEngine تصریح می‌کنند که DHCP Failover در DDI Central برای IPv4 ارائه می‌شود و برای IPv6 Address Space در این قابلیت Failover پشتیبانی نمی‌شود.

Failover با Split Scope چه تفاوتی دارد؟

در Split Scope سنتی، بخشی از Pool روی Server اول و بخش دیگر روی Server دوم قرار می‌گیرد. این مدل می‌تواند Redundancy ابتدایی ایجاد کند، اما Lease Database به شکل Native میان دو Server هماهنگ نیست. Failover مدرن‌تر تلاش می‌کند State و Lease Information را میان Pair هماهنگ نگه دارد.

چه پارامترهایی باید قبل از ساخت Failover مشخص شوند؟

  • Primary و Secondary DHCP Server
  • Scopeهای تحت پوشش
  • Network Connectivity میان دو Server
  • Port و Communication موردنیاز
  • Lease Synchronization
  • Role و Policy Failover
  • Monitoring و Alerting برای Health Pair

سناریوی شعب؛ یک Failover Pair برای هر سایت یا مرکزی؟

در سازمان چندشعبه‌ای، پاسخ یکسانی وجود ندارد. اگر WAN ناپایدار است، وابسته‌کردن DHCP شعبه به Data Center مرکزی می‌تواند ریسک ایجاد کند. در مقابل، نگهداری Server مستقل در هر شعبه نیز هزینه و پیچیدگی عملیاتی دارد.

سناریو مزیت ریسک
Failover Pair مرکزی مدیریت ساده‌تر وابستگی بیشتر به WAN
Pair محلی در شعبه استقلال Site هزینه و تعداد Server بیشتر
Hybrid تعادل بین Critical Site و شعب کوچک نیاز به Design دقیق

DHCP Failover و IPAM باید کنار هم باشند

High Availability بدون Visibility کافی نیست. اگر Scope Utilization، Reserved IP، Conflict و Lease History دیده نشوند، ممکن است Failover سالم باشد ولی Pool پر شود. DDI Central DNS، DHCP و IPAM را در یک Context مشترک مدیریت می‌کند.

برای سناریوی اتصال Lease به Endpoint Context، مقاله یکپارچه‌سازی DDI Central و Endpoint Central را ببینید. صفحه محصول ManageEngine DDI Central نیز معرفی Pillar این راهکار در مدانت است.

آزمون Failover؛ چیزی که نباید فقط روی کاغذ باشد

۱. Failure Primary را شبیه‌سازی کنید

در Maintenance Window کنترل‌شده بررسی کنید Secondary واقعاً Request جدید را پاسخ می‌دهد و Clientها Lease معتبر دریافت می‌کنند.

۲. Recovery را هم تست کنید

فقط Failover مهم نیست؛ Failback نیز مهم است. پس از بازگشت Primary باید Synchronization و State به وضعیت سالم برگردد.

۳. Scope نزدیک ظرفیت را جداگانه بررسی کنید

Failover زمانی که Scope ۳۰ درصد مصرف دارد با زمانی که ۹۵ درصد پر است یکسان نیست. Capacity Headroom باید بخشی از Test باشد.

چه KPIهایی برای DHCP HA مناسب‌اند؟

  • DHCP Service Availability
  • Failover Pair Health
  • Lease Allocation Success Rate
  • Scope Utilization
  • IP Conflict Count
  • Failover/Failback Test Success
  • Mean Time to Detect DHCP Failure

اتصال به Incident و Change

خرابی DHCP می‌تواند تعداد زیادی Incident هم‌زمان ایجاد کند. بهتر است Alert زیرساخت قبل از تماس کاربران به Service Desk برسد و هر تغییر Scope/Failover Pair نیز Change Record داشته باشد. برای طراحی مسیر رخداد می‌توانید راهنمای Incident Management را ببینید.

چک‌لیست اجرای DHCP Failover

  1. Scope و Leaseهای فعلی را Inventory کنید.
  2. Primary و Secondary مناسب را انتخاب کنید.
  3. Connectivity و Time Synchronization را بررسی کنید.
  4. Scopeهای Critical را اولویت‌بندی کنید.
  5. Failover Configuration را مرحله‌ای بسازید.
  6. Health و Synchronization را Verify کنید.
  7. Failure و Failback Test انجام دهید.
  8. Scope Utilization Alert تعریف کنید.
  9. Runbook Incident بنویسید.
  10. تست دوره‌ای را به Maintenance Calendar اضافه کنید.

نکات کلیدی

  • دو DHCP مستقل الزاماً Failover واقعی نیستند.
  • Failover نیازمند Synchronization Lease و State است.
  • DDI Central قابلیت DHCP Failover را برای IPv4 ارائه می‌دهد.
  • Failover باید همراه با IPAM و Scope Capacity دیده شود.
  • Failback به اندازه Failover مهم است.
  • تست دوره‌ای بخشی از High Availability است، نه یک کار اختیاری.

منابع رسمی

سخن پایانی

DHCP از آن سرویس‌هایی است که تا زمانی که کار می‌کند کمتر دیده می‌شود، اما خرابی آن می‌تواند تعداد زیادی Endpoint را هم‌زمان از شبکه خارج کند. DHCP Failover در DDI Central با ایجاد Pair و Synchronization Lease، Redundancy را به یک کنترل قابل مدیریت تبدیل می‌کند؛ به شرط آنکه Capacity، Monitoring و Test دوره‌ای نیز کنار آن باشند.

مدانت خدمات خرید و تمدید لایسنس DDI Central، طراحی DNS/DHCP/IPAM، مهاجرت، استقرار، آموزش و پشتیبانی را ارائه می‌دهد. برای استعلام لایسنس از صفحه لایسنس ManageEngine و برای طراحی DDI سازمانی از جلسه فنی مدانت استفاده کنید.

11

دیدگاه شما

دیدگاه مرتبط و محترمانه بنویسید.