مجله بلاگ
DHCP Failover در شبکه سازمانی؛ راهنمای پایداری آدرس‌دهی
DHCP Failover راهکاری برای ادامه آدرس‌دهی شبکه هنگام از دسترس خارج شدن یکی از سرورهای DHCP است. اهمیت آن معمولاً زمانی آشکار می‌شود که کارکنان قدیمی هنوز به شبکه وصل‌اند، اما لپ‌تاپ تازه‌وارد یا تلفن IP جدید آدرس نمی‌گیرد. در چنین وضعیتی، پاسخ‌گویی سرورها به Ping به‌تنهایی نشان نمی‌دهد که سرویس آدرس‌دهی سالم است.
این راهنما بر طراحی و بهره‌برداری DHCP Failover در محیط‌های Windows Server تمرکز دارد: انتخاب حالت مناسب، کنترل مسیر Relay، همگام‌سازی تنظیمات و آزمونی که نتیجه قابل اندازه‌گیری داشته باشد. هدف، کاهش اختلال برای کاربر و جلوگیری از تصمیم عجولانه هنگام خرابی است. مراحل پیشنهادی را ابتدا روی Scope آزمایشی و متناسب با نسخه سیستم‌عامل و معماری سازمان ارزیابی کنید.
DHCP Failover چیست و چه مشکلی را حل می‌کند؟
در پیاده‌سازی مایکروسافت، دو سرور برای Scopeهای مشخص با یکدیگر شریک می‌شوند و اطلاعات اجاره آدرس یا Lease را مبادله می‌کنند. هر رابطه فقط دو عضو دارد؛ این قابلیت برای Scopeهای IPv4 است و به DHCPv6 تعمیم داده نمی‌شود. در حالت Load Balance هر دو سرور خدمت می‌دهند؛ در Hot Standby یکی نقش فعال و دیگری نقش آماده‌به‌کار دارد. جزئیات این تفاوت‌ها در معرفی رسمی DHCP Failover مایکروسافت آمده است.
وجود شریک دوم همه وابستگی‌های شبکه را مقاوم نمی‌کند. اگر هر دو ماشین مجازی روی یک میزبان قرار داشته باشند، خاموشی همان میزبان می‌تواند هر دو را متوقف کند. همچنین خرابی سوئیچ مشترک یا قطع مسیر شعبه ممکن است دسترسی به هر دو سرور را ببندد. بنابراین پیش از خرید سرور جدید، نقشه نقاط خرابی مشترک را روی کاغذ مشخص کنید.
چرا اختلال برای همه کاربران هم‌زمان دیده نمی‌شود؟
کلاینت دارای Lease معتبر ممکن است تا زمان نیاز به تمدید، از آدرس فعلی استفاده کند؛ دستگاه تازه‌متصل چنین امکانی ندارد. چرخه تمدید و اعتبار Lease در استاندارد DHCP، یعنی RFC 2131 تعریف شده است. نتیجه عملی این است که آزمون «یک کاربر هنوز اینترنت دارد» برای تأیید سلامت DHCP کافی نیست؛ باید دریافت آدرس جدید و تمدید آدرس موجود جدا بررسی شوند.
انتخاب بین Load Balance و Hot Standby
دو سرور در یک مرکز با مسیر ارتباطی پایدار
Load Balance معمولاً گزینه قابل بررسی برای این معماری است. نسبت پیش‌فرض ۵۰ به ۵۰، سیاست تقسیم پاسخ‌گویی است و نباید آن را تعهدی برای برابری دقیق تعداد کلاینت‌ها در هر لحظه دانست. ظرفیت هر سرور، مسیر دسترسی و رفتار شبکه هنگام خرابی همچنان باید آزموده شود. انتخاب نهایی را با نتیجه آزمون انجام دهید، نه صرفاً با پیش‌فرض نرم‌افزار.
شعبه با سرور محلی و شریک در مرکز
Hot Standby می‌تواند برای سناریویی مناسب باشد که خدمت عادی در شعبه ارائه شود و مرکز نقش پشتیبان داشته باشد. اما اگر با قطع ارتباط شعبه، سرور جایگزین هم از دسترس کاربران خارج شود، آن طراحی خرابی هم‌زمان مسیر و سرور محلی را پوشش نمی‌دهد. قبل از انتخاب حالت، دقیق بنویسید کدام خرابی باید قابل تحمل باشد و کدام سناریو هنوز نیازمند مسیر مستقل است.
برای هر انتخاب، یک برگه تصمیم بسازید: محل دو سرور، میزبان مجازی‌سازی، برق، سوئیچ بالادست، مسیر کاربران و مسئول رسیدگی. این برگه به تیم پشتیبانی کمک می‌کند محدودیت طراحی را با رفتار غیرمنتظره اشتباه نگیرد.
پیش‌نیازهای طراحی DHCP در شبکه سازمانی
فهرست Scopeها را با نقشه تفکیک شبکه سازمانی با VLAN تطبیق دهید. برای هر محدوده، شبکه، ماسک، Gateway، DNS، آدرس‌های رزروشده و استثناها را ثبت کنید. همچنین مشخص کنید کدام دستگاه‌ها آدرس دستی دارند تا محدوده تخصیص خودکار با آن‌ها تداخل نداشته باشد.
- موجودی واقعی: تعداد کاربران، تلفن‌ها، مهمان‌ها و دستگاه‌های دوره‌ای را جدا بشمارید.
- ظرفیت رشد: ظرفیت آزاد را با الگوی ورود دستگاه‌های جدید بسنجید، نه فقط تعداد کارکنان.
- وابستگی‌ها: دسترسی مدیریتی، نام سرورها، همگامی ساعت و مسیرهای فایروال را ثبت کنید.
- قابلیت بازگشت: نسخه پشتیبان تنظیمات و مسئول تصمیم درباره توقف تغییر مشخص باشد.
- معیار پذیرش: دریافت آدرس، صحت DNS و Gateway و دسترسی به برنامه کاری تعریف شود.
یک خطای رایج، شروع تغییر از شلوغ‌ترین VLAN است. محدوده‌ای با چند کلاینت آزمایشی انتخاب کنید که بتوان رفتار آن را مشاهده کرد. نتیجه همان آزمون را مبنای اجرای تدریجی روی سایر محدوده‌ها قرار دهید؛ موفقیت در یک VLAN لزوماً تنظیم درست Relay در VLAN دیگر را ثابت نمی‌کند.
راه‌اندازی DHCP Failover؛ ترتیب اجرای پیشنهادی
پس از نصب و آماده‌سازی نقش DHCP و انجام مجوزدهی لازم در محیط دامنه، مسیر مدیریتی هر دو سرور را بررسی کنید. Scope مبنا باید روی مبدأ وجود داشته باشد و از قبل به‌صورت مستقل روی شریک ساخته نشده باشد. اگر شبکه از Split Scope استفاده می‌کند، مهاجرت آن نیازمند بررسی Leaseهای موجود و برنامه جداگانه است؛ حذف عجولانه Scope راه‌حل عمومی نیست.
- از تنظیمات فعلی خروجی و نسخه پشتیبان بگیرید و مشخص کنید نسخه معتبر روی کدام سرور است.
- در کنسول DHCP، از بخش IPv4 گزینه Configure Failover را برای محدوده آزمایشی انتخاب کنید.
- شریک، نام رابطه و حالت عملیاتی را تعیین کنید و پارامترهای زمانی را ثبت کنید.
- احراز اصالت پیام‌های بین شریک‌ها را با راز مشترک مدیریت‌شده تنظیم کنید؛ این گزینه به معنی رمزنگاری همه ترافیک DHCP نیست.
- نتیجه عملیات، Scope منتقل‌شده و وضعیت رابطه را روی هر دو سمت کنترل کنید.
روند کنسول در راهنمای مدیریت رابطه Failover و معنای پارامترهای احراز اصالت در مرجع Add-DhcpServerv4Failover توضیح داده شده است. رمز مشترک را در تیکت عمومی، تصویر آموزشی یا فایل اشتراکی بدون کنترل دسترسی قرار ندهید.
Relay و فایروال را جداگانه آزمایش کنید
کلاینت باید مستقیم یا از طریق DHCP Relay به هر دو شریک دسترسی داشته باشد. در شبکه چند VLAN، فهرست مقصدهای Relay را بررسی کنید؛ وجود فقط آدرس سرور اول، مسیر جایگزین را ناقص می‌گذارد. ارتباط TCP روی پورت ۶۴۷ برای مبادله پیام میان شریک‌هاست و سلامت آن، عبور درخواست DHCP از VLAN کاربر را اثبات نمی‌کند. این تفکیک در مستند معماری DHCP Failover تشریح شده است.
MCLT و Partner Down؛ تفاوتی که هنگام قطعی مهم است
MCLT مخفف Maximum Client Lead Time است و حد مجاز جلو افتادن زمان اعتبار Lease از اطلاعات تأییدشده شریک را مشخص می‌کند. این پارامتر بر زمان در اختیار گرفتن کل محدوده پس از ورود به Partner Down نیز اثر دارد؛ اما تایمر تشخیص خرابی نیست. State Switchover Interval مفهوم دیگری دارد و به گذار خودکار وضعیت مربوط می‌شود. تعریف این دو را می‌توان در مستند تنظیمات DHCP Failover دید.
وقتی وضعیت Communications Interrupted دیده می‌شود، فقط می‌دانیم ارتباط شریک‌ها برقرار نیست؛ ممکن است هر دو سرور همچنان به کاربران پاسخ بدهند. تغییر دستی به Partner Down بدون بررسی وضعیت سمت مقابل، می‌تواند خطر تخصیص متعارض را ایجاد کند. خاموشی سرویس و قطع مسیر میان دو سرور را دو حادثه جدا در دستورالعمل عملیات تعریف کنید.
نمونه واقعیِ مستند: هر دو سرور زنده‌اند، ارتباط قطع است
مایکروسافت در نمونه‌های رسمی رفتار Failover سناریوی جدایی ارتباطی شریک‌ها را بررسی می‌کند. اگر دو سمتِ جداشده هر دو خود را مسئول کامل محدوده بدانند، احتمال تعارض آدرس به وجود می‌آید. این نمونه مستند محصول است، نه گزارش پروژه یک مشتری نصیر ارتباط.
قاعده عملی تیم عملیات باید روشن باشد: ابتدا وضعیت واقعی شریک را از مسیر مدیریتی مستقل بررسی کنید؛ سپس درباره جداسازی کنترل‌شده یا تغییر وضعیت تصمیم بگیرید. کم‌کردن بی‌دلیل تایمرها برای رسیدن به «بازیابی فوری» جای این تشخیص را نمی‌گیرد. زمان مشاهده‌شده بازیابی را در مانور ثبت کنید تا تعهد پشتیبانی بر شواهد تکیه کند.
همگام‌سازی Lease با تکثیر تنظیمات یکی نیست
پس از ایجاد رابطه، اطلاعات Lease در سازوکار Failover همگام می‌شود، اما نباید فرض کنید تغییر هر تنظیمی نیز خودکار منتقل خواهد شد. تغییر Reservation، گزینه‌های Scope یا Policy باید در فرایند تکثیر تنظیمات پوشش داده شود. سروری که تنظیم صحیح روی آن قرار دارد باید مبدأ باشد؛ اجرای تکثیر از سمت اشتباه، تنظیمات مقصد را با نسخه نامطلوب بازنویسی می‌کند.
در نمونه زیر، نام سرور و شناسه Scope صرفاً آموزشی‌اند. این فرمان تغییر ایجاد می‌کند؛ فقط پس از کنترل مبدأ، گرفتن نسخه پشتیبان و در پنجره تغییر اجرا شود. دامنه عملیات عمداً به یک Scope محدود شده است:
Invoke-DhcpServerv4FailoverReplication -ComputerName "dhcp-a.example.com" -ScopeId 10.20.30.0 -Confirmمرجع رسمی فرمان Replication، ویژگی‌های Scope، Reservationها، Scope Optionها و Policyها را در دامنه تکثیر معرفی می‌کند. این فهرست به معنی انتقال همه تنظیمات سطح سرور نیست. بعد از عملیات، مقدار تغییرکرده را روی شریک هم بخوانید و نتیجه را در همان درخواست تغییر ثبت کنید.
اگر DHCP از طرف کلاینت‌ها رکورد DNS را به‌روزرسانی می‌کند، دو شریک باید اعتبارنامه یکسان و مناسب برای این کار داشته باشند. این الزام در معرفی رسمی مایکروسافت بیان شده است. کنترل نام و مالکیت رکورد را همراه با راهنمای امنیت DNS سازمانی انجام دهید؛ دریافت IP صحیح، صحت ثبت نام در DNS را تضمین نمی‌کند.
آزمون پذیرش؛ چه چیزی را ثبت کنیم؟
جدول زیر یک الگوی پیشنهادی برای تحویل کار است، نه گزارش آزمون انجام‌شده روی شبکه شما. زمان شروع، دستگاه آزمایشی، VLAN، سرور پاسخ‌دهنده و نتیجه هر ردیف را ثبت کنید. اگر معیار پذیرش تأمین نشد، قبل از تعمیم تنظیمات، همان اختلاف را بررسی کنید.
| سناریو | کنترل لازم | شاهد قابل ثبت |
|---|---|---|
| وضعیت عادی | گرفتن Lease تازه و گزینه‌های صحیح | IP، DNS، Gateway و زمان اجاره |
| توقف کنترل‌شده یک سرویس | کلاینت جدید و تمدید کلاینت موجود | سرور پاسخ‌دهنده و زمان پاسخ |
| قطع ارتباط شریک‌ها در آزمایشگاه | تشخیص وضعیت و هشدار مناسب | رخدادهای هر دو سرور و تصمیم اپراتور |
| بازگشت سرویس | بازگشت رابطه به وضعیت سالم | وضعیت دو سمت و نبود تعارض مشاهده‌شده |
| تغییر یک Reservation آزمایشی | تکثیر از مبدأ صحیح | مقایسه تنظیم دو سرور |
برای تولید اختلال آزمایشی، همه کاربران را وادار به آزادکردن آدرس نکنید. یک دستگاه مشخص با دسترسی جایگزین انتخاب کنید و نتیجه آن را ثبت کنید. از سوی دیگر، تنها تست دستگاهی که از قبل Lease دارد کافی نیست؛ یک کلاینت تازه نیز باید در سناریو حضور داشته باشد.
مثال آموزشی: دفتر مرکزی با چند VLAN
فرض کنید شرکت نمونه‌ای ۱۲۰ کاربر، تلفن‌های IP و شبکه مهمان دارد. دو سرور DHCP روی میزبان‌های جدا مستقر شده‌اند، اما Relay شبکه مهمان فقط به سرور اول اشاره می‌کند. در مانور توقف سرویس اول، لپ‌تاپ تازه در شبکه مهمان آدرس نمی‌گیرد؛ درحالی‌که کاربر اداری همچنان به برنامه مالی وصل است.
در این مثال فرضی، اضافه‌کردن سرور سوم اولین اقدام مناسب نیست. ابتدا مقصدهای Relay و سیاست عبور ترافیک بررسی می‌شوند، سپس همان آزمایش دریافت آدرس تازه تکرار می‌شود. اگر اصلاح مسیر مشکل را حل کرد، این نتیجه به چک‌لیست همه VLANها اضافه می‌شود. ارزش مانور در کشف چنین تفاوت‌هایی است؛ نمایش سبز دو سرور روی داشبورد به‌تنهایی آن‌ها را آشکار نمی‌کند.
پایش و نگهداری پس از راه‌اندازی
برای مشاهده آمار Scope و وضعیت رابطه، از فرمان‌های خواندنی زیر با نام سرور واقعی استفاده کنید. این فرمان‌ها به‌خودی‌خود تنظیمات DHCP را تغییر نمی‌دهند:
Get-DhcpServerv4Failover -ComputerName "dhcp-a.example.com"
Get-DhcpServerv4ScopeStatistics -ComputerName "dhcp-a.example.com"آمار محدوده‌ها در مرجع Get-DhcpServerv4ScopeStatistics توضیح داده شده است. خروجی را همراه با نرخ ورود دستگاه جدید و رخدادهای سرویس تحلیل کنید. یک درصد ثابت ظرفیت آزاد برای همه سازمان‌ها مناسب نیست؛ شبکه مهمان پرتردد با شبکه تجهیزات ثابت الگوی مصرف متفاوتی دارد.
- برای قطع رابطه، کاهش ظرفیت آزاد و شکست عملیات تکثیر، مسئول پاسخ‌گویی مشخص کنید.
- بعد از هر تغییر DNS، Gateway یا Reservation، کنترل شریک را جزو پایان کار قرار دهید.
- پس از جابه‌جایی VLAN، تغییر فایروال یا ارتقای سیستم‌عامل، آزمون مسیر کاربران را تکرار کنید.
- پشتیبان تنظیمات و روش بازیابی مستقل را نگه دارید؛ افزونگی جای بکاپ را نمی‌گیرد.
این کنترل‌ها را به برنامه مانیتورینگ زیرساخت وصل کنید تا هشدار DHCP صرفاً در کنسول سرور باقی نماند. در گزارش دوره‌ای، علت حادثه، زمان کشف و اقدام اصلاحی را کنار هم بیاورید؛ شمارش هشدارها بدون تعیین مسئول، کیفیت پشتیبانی را نشان نمی‌دهد.
پرسش‌های متداول DHCP Failover
آیا داشتن دو DHCP Server مستقل کافی است؟
خیر. دو Scope هم‌پوشان بدون هماهنگی ممکن است آدرس متعارض تخصیص دهند. باید رابطه پشتیبانی‌شده یا طراحی مستقلِ معتبر وجود داشته باشد و نتیجه آن آزموده شود.
آیا پس از خرابی یک سرور همه کاربران قطع می‌شوند؟
الزاماً خیر؛ وضعیت Lease و دسترسی به سرویس‌های دیگر مؤثر است. به همین علت، آزمون کاربر موجود و دریافت آدرس تازه را جدا انجام دهید.
برای انتخاب تایمرها یک مقدار مناسب همه شرکت‌ها وجود دارد؟
خیر. ظرفیت آزاد، حالت رابطه، کیفیت مسیر، سرعت تشخیص حادثه و توان تیم عملیات باید بررسی شوند. مقدار نهایی را مستند و در مانور ارزیابی کنید.
آیا Failover از خطای تنظیم DNS یا Gateway جلوگیری می‌کند؟
خیر. یک تنظیم اشتباه می‌تواند به شریک هم منتقل شود. کنترل تغییر و آزمون برنامه‌های کاری باید در کنار افزونگی انجام شود.
جمع‌بندی و گام بعدی
DHCP Failover زمانی به پایداری شبکه کمک می‌کند که مسیر کاربران به هر دو سرور، تنظیمات یکسان و رفتار هنگام خرابی بررسی شده باشد. نقطه شروع مناسب، فهرست Scopeها و وابستگی‌هاست؛ سپس یک محدوده آزمایشی، مانور قابل ثبت و برنامه نگهداری مستمر تعریف کنید.
در پشتیبانی ماهانه سازمانی نصیر ارتباط، خدمات از کاربر و تجهیزات روزمره تا زیرساخت و سرورها پوشش داده می‌شود. برای بررسی پایداری DHCP، درخواست ارزیابی شبکه ثبت کنید تا وضعیت آدرس‌دهی، مسیرهای جایگزین و برنامه آزمون متناسب با شرایط سازمان شما تعیین شود.