שאלת ראיון: מה זה DHCP Failover?

אתם בראיון לתפקיד System Administrator. דיברתם על Active Directory, על DNS, על GPO, והכול הלך חלק. ואז המראיין שואל שאלה שנשמעת פשוטה: ״מה זה DHCP Failover?״

זו שאלה שמפרידה בין מי שהתקין שרת DHCP פעם אחת לבין מי שחשב על מה קורה כשהשרת הזה נופל. כי ברגע ששרת ה־DHCP היחיד בארגון מת, מחשבים חדשים לא מקבלים כתובת, טלפונים לא מתחברים, והמדפסות שוכחות מי הן. ה־Help Desk מוצף בקריאות, וכולם מסתכלים על איש הסיסטם.

למה בכלל צריך את זה? רגע על הבעיה

DHCP הוא אחד השירותים הכי שקטים וכי קריטיים ברשת. כל מכשיר שמתחבר מבקש כתובת IP, Gateway ו־DNS, וכל זה קורה ברקע בלי שאף אחד שם לב. הבעיה היא שבארגון טיפוסי יש שרת DHCP אחד. כל עוד הוא חי, אף אחד לא חושב עליו. ברגע שהוא נופל, מתחילה שעת חול: מחשבים שה־Lease שלהם פג לא מצליחים לחדש אותו, עובדים חדשים שמחברים את הנייד לא מקבלים כתובת בכלל, ורשת ה־WiFi מתמלאת במכשירים תקועים.

חשוב להבין: מחשב שכבר קיבל כתובת ימשיך לעבוד עד שה־Lease שלו יפוג. אז התקלה לא מפילה את כולם בבת אחת, אלא בולעת את הרשת לאט. בדיוק בגלל זה Failover הוא לא מותרות, אלא חלק בסיסי מתכנון תשתית מסודרת.

איך זה עובד מאחורי הקלעים?

שני השרתים מקימים ביניהם קשר Failover, ערוץ תקשורת ייעודי על TCP פורט 647. דרך הערוץ הזה הם מעבירים אחד לשני עדכונים על כל הקצאה: מי קיבל איזו כתובת, מתי ה־Lease פג, ומה שמור. כך לשני השרתים יש תמונה כמעט זהה של ה־Scope, וכל אחד מהם יכול לשרת לקוח בלי לחלק כתובת שכבר נתבעה.

• ▸Scope משותף: ה־Failover מוגדר ברמת ה־Scope, לא ברמת השרת. אפשר לשים Scope אחד ב־Failover ואחר לא.
• ▸סנכרון הקצאות: כל Lease חדש או מחודש מדווח לשרת השותף, כך ששניהם יודעים מי מחזיק מה.
• ▸אימות: התקשורת בין השרתים יכולה להיות מאומתת עם סיסמה משותפת, כדי שאף שרת זר לא יתחבר לזוג.
• ▸שמות: כל זוג Failover מקבל שם יחסים, Relationship Name, שמזהה את השותפות.

Load Balance מול Hot Standby: שני הסגנונות

זה החלק שהמראיין באמת רוצה לשמוע. מי שיודע להבדיל בין שני המצבים, ולהסביר מתי בוחרים בכל אחד, משדר שהבין את העניין ולא רק שנן הגדרה.

• ▸Load Balance: שני השרתים פעילים ומשרתים לקוחות במקביל. מחלקים ביניהם את העומס באחוזים, בדרך כלל 50/50, ולפעמים 80/20 כשרוצים ששרת מרכזי יישא את רוב העבודה. מתאים לשני שרתים באותו אתר או באתרים קרובים.
• ▸Hot Standby: שרת אחד פעיל ומשרת את כולם, והשני במתנה. השרת הממתין מקבל רק אחוז קטן מהכתובות לשעת חירום, בדרך כלל 5 אחוזים, ונכנס לפעולה מלאה כשהראשי נופל. מתאים כשהשרת המגבה יושב באתר מרוחק או חלש יותר.
• ▸מתי מה? אם שני השרתים שווים בכוח ובמיקום, Load Balance נותן גם שרידות וגם חלוקת עומס. אם הגיבוי רחוק או חלש, Hot Standby הגיוני יותר.

MCLT: הפרמטר הקטן שכולם שוכחים

MCLT, קיצור של Maximum Client Lead Time, הוא הזמן המקסימלי ששרת אחד יכול להאריך Lease ללקוח בלי ליידע את השותף. ברירת המחדל היא שעה אחת. למה זה חשוב? כי אם שרת נופל, השותף לא יודע בוודאות אילו הקצאות הוא נתבע ברגעים האחרונים. ה־MCLT מגדיר חלון בטיחות: השרת שנשאר מחכה את פרק הזמן הזה לפני שהוא לוקח בעלות מלאה על ה־Scope ומתחיל לחלק כתובות חדשות בחופשיות.

MCLT גבוה מדי משאיר את הרשת בלי שירות מלא זמן רב מדי אחרי נפילה. MCLT נמוך מדי מגביר את הסיכון לכתובות כפולות אם השרת השני רק איטי ולא מת. בארגון רגיל ברירת המחדל של שעה סבירה לגמרי.

מה חשוב לשים לב כשמגדירים?

• ▸הגדירו Failover לכל Scope שחשוב. קל לשכוח Scope של טלפוניה או של רשת אורחים ולגלות את זה ביום שהשרת נופל.
• ▸ודאו שה־Scope זהה בשני השרתים: טווח כתובות, Subnet Mask, Gateway, DNS וחריגים. אי התאמה שקטה יוצרת תקלות שקשה לאבחן.
• ▸פתחו את פורט TCP 647 בחומות האש בין השרתים. בלי זה הסנכרון פשוט לא עובד, והשרתים נראים תקינים עד שצריך אותם באמת.
• ▸בדקו את ה־Failover לפני שצריכים אותו. עצרו את שירות ה־DHCP בשרת אחד במעבדה או בשעות ערב, וודאו שהשני ממשיך לחלק כתובות.
• ▸עקבו אחרי אחוז הכתובות הפנויות ב־Scope. Failover לא פותר Scope שהתמלא, הוא רק דואג שמישהו ימשיך לחלק.
• ▸זכרו שה־Failover מסנכרן הקצאות, אבל הגדרות שרת כלליות כמו אפשרויות ברמת שרת או Reservations מסוימים צריכים תשומת לב נפרדת.

Get-DhcpServerv4Failover
Get-DhcpServerv4Scope | Select ScopeId, State
Get-DhcpServerv4ScopeStatistics -ScopeId 10.0.1.0

# בדיקת שירות ה־DHCP בשני השרתים
Get-Service DHCPServer -ComputerName DHCP01, DHCP02

ומה עם Split Scope? השיטה הישנה

לפני שהיה Failover מובנה, נהוג היה לחלק את ה־Scope ידנית בין שני שרתים, בדרך כלל 80/20: שרת אחד מחזיק 80 אחוזים מהכתובות והשני 20. הרעיון הוא שאין חפיפה, אז אין סיכון לכתובות כפולות, ואין צורך בסנכרון. החיסרון ברור: אין סנכרון אמיתי, כתובות שהוקצו על ידי השרת שנפל לא ידועות לשני, והתאוששות מלאה מצריכה עבודה ידנית. אם המראיין מזכיר Split Scope, כדאי להכיר אותו כהקשר היסטורי ולהסביר למה Failover החליף אותו.

איך זה נראה ביום עבודה של איש סיסטם?

נניח שיום שלישי בבוקר, ושרת ה־DHCP הראשי לא עולה אחרי עדכון. בלי Failover, עד צהריים ה־Help Desk שקוע בקריאות על מחשבים בלי רשת. עם Failover מוגדר נכון, איש סיסטם מקבל התראת ניטור, רואה ב־PowerShell שהשרת המשני לקח פיקוד, ומתקן את הראשי בנחת בלי שאף משתמש הרגיש. זה ההבדל בין יום אבוד לבין אירוע שאף אחד לא זוכר. וזו בדיוק הסיבה שהשאלה הזו חוזרת בראיונות: היא בודקת אם אתם בונים תשתית שמחזיקה מעמד, או רק מתקינים שירותים.

שאלות המשך שהמראיין עשוי לשאול

• ▸מה ההבדל בין Failover ל־Split Scope? ב־Failover יש סנכרון הקצאות חי בין השרתים. ב־Split Scope כל שרת מחזיק חלק נפרד מהכתובות בלי סנכרון, וזו שיטה ישנה ופחות גמישה.
• ▸מה קורה ללקוח שכבר קיבל כתובת כשהשרת נופל? הוא ממשיך לעבוד עד שה־Lease פג, ואז מחדש מול השרת שנשאר.
• ▸האם אפשר Failover בין שרתים באתרים שונים? כן, וזה אף נפוץ, אבל צריך לוודא שהקו בין האתרים יציב ושפורט 647 פתוח. באתר מרוחק נוטים לבחור Hot Standby.
• ▸איך בודקים שה־Failover עובד? Get-DhcpServerv4Failover מראה את מצב השותפות, ובדיקה אמיתית היא לעצור את השירות בשרת אחד ולראות שהשני מחלק כתובות.
• ▸מה קורה אם שני השרתים חוזרים לחיים אחרי נפילה משותפת? הם מסנכרנים מחדש את מצב ההקצאות דרך ערוץ ה־Failover לפני שחוזרים לשרת לקוחות כרגיל.