DHCP Failover و بررسی مفاهیم MCLT و ASSI

DHCP Failover چیست؟

پروتکل DHCP که مخفف (Dynamic Host Configuration Protocol) است یکی از پروتکل های پرکاربرد لایه Application در مدل OSI است که وظیفه تخصیص خودکار آیپی آدرس به کلاینت های موجود در شبکه را دارد و همچنین در کنار آیپی دهی به کلاینت ها آپشن های متنوعی از جمله دادن تخصیص آدرس DNS,Gateway,Bootp و … شبکه را دارد. با توجه به اهمیت این سرویس در شبکه و لزوم تحمل خرابی (Fault Tolerance) و افزایش دردسترس پذیری(High Availability) شبکه، پیکربندی سرویس DHCP Failover در شبکه امری ضروری است.

به طور کلی در DHCP به دو صورت می توان DHCP Failover را پیاده سازی کرد:

• Split Scope: از این گزینه جهت تقسیم رنج آیپی های Scope بین DHCP سرورها با توجه به درصد اعلام شده می توان استفاده نمود.
• Failover: شامل دو حالت Load Balance و Hot Standby می شود.

1. در هر دو حالت DHCP Failover ما 2 پارامتر به نام های Maximum Client Lead Time (MCLT) وAuto State Switchover Interval (ASSI)  را داریم که در این مقاله سعی می شود به صورت عمیق تر عملکرد این 2 پارامتر مورد بررسی قرار گیرد.

در اینجا DHCP Server به اختصار سرور در نظر گرفته می شود

سرور اصلی DHCP1 و سرور ثانویه DHCP2

در ابتدا باید دید مشکل کلیدی در Fail overing چه زمانی رخ می دهد؟

برای lease updates سرورها از دو مکانیزیم eager updates و lazy updates استفاده می کنند:

در eager updates سرور اصلی به سرور ثانویه زمانی که می خواهد به کلاینت آیپی بدهد یا lease time آیپی از قبل داده شده را تمدید کند باید ابتدا به سرور ثانویه جهت بروزرسانی بانک آن سرور اعلام کند و پس از پاسخ سرور ثانویه مبنی بر دریافت و بروز رسانی، سرور اصلی می تواند آن آیپی را به کلاینت اختصاص دهد که این امر باعث ایجاد تاخیر در پاسخگویی درخواست از سمت کلاینت می شود.

در lazy updates سرور اصلی به طور آنی با سرور ثانویه ارتباط نمی گیرد و برای دوره زمانی صبر می کند و ابتدا به کلاینت آیپی می دهد یا درخواست lease را تمدید می کند و سپس نتایج حاصله را به سرور ثانویه اعلام می کند که امر باعث افزایش کارایی شبکه می شود اما اگه سرور اصلی به هر علتی قبل از ارسال آخرین نسخه بانک اطلاعاتی خود به سرور ثانویه از کار بیفتد باعث می شود که سرور ثانویه آخرین اطلاعات بروزرسانی شده را دریافت نکند که این مسئله باعث ایجاد دو مشکل دیگر می شود:

• سرور ثانویه ممکن است باور کند که یک lease منقضی شده است حتی زمانی که کلاینت دارای یک lease معتبر است که این مسئله می تواند باعث جلوگیری از تمدید lease کلاینت شود و کلاینت آن آیپی خود را از دست دهد.
• سرور ثانویه اطلاعات lease که سرور اصلی به کلاینت داده است را ندارد، این مورد باعث می شود که سرور ثانویه آیپی آدرسی که سرور اصلی به کلاینت اختصاص داده است را به دستگاه دیگری در شبکه اختصاص دهد که این باعث ایجادIP address conflict در شبکه می شود.

برای برطرف کردن این موضوع DHCP failover از مکانیزمی به نام Maximum Client Lead Time (MCLT) استفاده می کند.

وظایف MCLT به اختصار بدین شرح است:

• اختصاص مدت زمان lease برای درخواست کلاینت.
• مدت زمانی که یک سرور برای سرور دیگر صبر می کند تا کنترل کامل Scope آیپی را به عهده گیرد.
• مدت زمانی که یک سرور از کار افتاده باید صبر کند تا از وضعیت Partner Down به وضعیت Normal تغییر پیدا کند.

فرض کنید دو سرور تنظیم شده با یک Scope در حالت Hot standby تنظیم شده است. سرور یک در حالت Active و سرور دو در حالت Standby است. و MCLT 5 دقیقه و ASSI 30 دقیقه تنظیم شده است.

در حالت عادی مدت زمان lease پیش فرض 8 روز است و کلاینت اگر از سرور یک درخواست آیپی کند بعد از تخصیص آن به کلاینت به سرور دو نیز اطلاع رسانی می کند که این آیپی به کلاینت اختصاص پیدا کرده و به کلاینت دیگر نده.

حالا اگر کلاینت به مدت 8 روز آدرس آیپی را در اختیار بگیرد و سرور یک از کار بیفتد و نتواند اطلاعات بروز شده را به سرور دو بدهد، به صورت تئوری سرور دوم کنترل Scope را به عهده می گیرید در این صورت سرور دوم فرض می کند که آن آیپی که توسط سرور اول به کلاینت داده شده، آزاد است و می تواند به کلاینت دیگر اختصاص دهد؛ برای حل این مشکل مکانیزم  MCLT طراحی شده است.

اگر زمان MCTL 5 دقیقه تنظیم شده باشد سرور یک به جای اختصاص آیپی به مدت 8 روز به کلاینت، به مدت 5 دقیقه آن را اجاره می دهد و به سرور دوم اطلاع می دهد که آدرس آیپی به کلاینت اختصاص داده شده است. سرور دو اطلاعات کلاینت را در بانک اطلاعاتی خود ذخیره می کند و مدت آن را به 8 روز تغییر می دهد، بعد 5 دقیقه کلاینت با سرور یک مجدد ارتباط می گیرید و همان آدرس را دریافت می کند ولی در این حالت هم در بانک سرور یک و هم در بانک سرور دو آن آدرس آیپی به مدت 8 روز برای کلاینت رزرو شده است.

در هنگام از کار افتادن سرور یک عملکرد MCLT بدین شرح است:

بعد از تخصیص آدرس آیپی توسط سرور یک به مدت 5 دقیقه به کلاینت، سرور یک قبل از اطلاع به سرور دو از کار میفتد؛ در این حالت چون دو سرور با هم ارتباط TCP روی پورت 647 داشتند و سرور یک دیگه در ارتباط TCP وجود ندارد، پس سرور دو وضعیت ارتباطی را به Communication interrupted تغییر می دهد و اگر کلاینت مجدد بعد 5 دقیقه جهت تمدید به سرور یک مراجعه کند در نتیجه با عدم پاسخ مواجه می شود و به صورت مداوم در شبکه پیغام broadcast می فرستد و به دنبال DHCP فعال در شبکه می گردد. در این صورت سرور دو می بیند که کلاینت دارای یک آیپی آدرسی است که توسط سرور یک به مدت 5 دقیقه اختصاص داده شده (همان زمان MCLT مشترک بین دو سرور) و اکنون به اتمام رسیده است در این صورت سرور دو به کلاینت همان آدرس آیپی را به مدت 8 روز اختصاص می دهد و آن را در بانک اطلاعاتی خود ذخیره می کند، این در حالی است سرور دو هنوز حتی کنترل کلی Scope را به عهده نگرفته است. بدون MCTL کلاینت آدرس را به مدت 8 روز دریافت می کند و کلاینت برای تمدید اقدامی نمی کند و زمانی که سرور دوم کنترل کلی Scope رو به عهده بگیرد، با توجه به اینکه سرور یک از کار افتاده، در نظر می گیرد که آدرس آیپی اختصاص داده شده به کلاینت آزاد است و آن را به کلاینت دیگر اختصاص می دهد که همین امر باعث ایجاد IP address conflict می شود.

وضعیت ارتباطی در سرور اصلی و ثانویه به سه صورت است:

• Normal: زمانی که ارتباط دو سرور با هم برقرار است و با توجه به حالت Fail over به کلاینت ها سرویس می دهد.
• Communication interrupted: اگر مشکل ارتباطی بین دو سرور رخ دهد هر سرور به Communication interrupted تغییر وضعیت می دهد.
• Partner Down: در این وضعیت سرور فرض می کند که سرور پارتنر در حالت عملیاتی نیست پس اداره Scope را به عهده می گیرد.

هنگام از کار افتادن سرور فعال، سرور پارتنر جهت گرفتن کنترل رنج آدرس ها باید به مقدار MCLT توجه کند. به طور مثال این پارامتر 60 دقیقه تنظیم شده باشد بعد از یک ساعت کنترل رنج آدرس ها را به عهده می گیرد. البته در تنظیمات DHCP failover ما پارامتر دیگری به نام Auto State Switchhover (ASSI) داریم که کارایی آن در این حالت است:

زمانی که ارتباط سرور ها با هم قطع می شود به حالت Communication interrupted می روند چون آن ها دانشی در خصوص علت قطعی ارتباط ندارند پس باید صبر کنند تا مدیر سیستم اقدامات لازم را به صورت دستی انجام دهد و سروری را که قطع شده است در وضعیت Partner Down قرار دهد. به کمک آپشن ASSI می توان این پروسه را به صورت اتوماتیک تنظیم کرد.

در این حالت سرور که پارتنر خود را در وضعیت Partner Down می بیند فرض می کند که آن سرور در حالت عملیاتی نیست پس با در نظر گرفتن مقادیر MCLT و ASSI اقدام به پاسخ دهی به درخواست کلاینت ها در شبکه می کند.

هدف از ASSI این است که حالت های ارتباطی به صورت اتوماتیک تغییر پیدا کند و نیاز به تغییرات دستی توسط مدیر سیستم نباشد. اگر ASSI به مدت 30 دقیقه تنظیم شده باشد و سرور ها در حالت Communication interrupted باشند بعد مدت 30 دقیقه سرور پارتنر به وضعیت Partner Down تغییر پیدا می کند اما سرور فعال همچنان کنترل Scope را به عهده نمی گیرد تا زمانی که مقدار MCLT تمام شود پس در نتیجه بعد 35 دقیقه سرور دوم یا پارتنر، کنترل کل Scope را به عهده می گیرد.

باید دقت نمود که تنظیم مقدار بهینه پارامتر MCLT و ASSI با توجه به سناریو شبکه دارای اهمیت است مخصوصا اگر مقدار MCLT خیلی پایین باشد باعث افت کارایی شبکه به علت افزایش ترافیک می شود و اگر خیلی بالا باشد باعث می شود در صورت از کار افتادن DHCP عملیات Fail over دیرتر انجام شود.

منابع:

https://datatracker.ietf.org/doc/html/draft-ietf-dhc-failover

https://datatracker.ietf.org/doc/html/rfc8156

https://www.itprotoday.com/windows-78/dhcp-failover-windows-server-2012

https://blog.ittoby.com/2013/05/windows-server-2012-superfeature-dhcp.html