הערה: הפוסט אינו מיועד להחליף התייעצות מקצועית עם איש מקצוע מתאים (אינטגרטור\יועץ וכו'), ויש להתייחס לכל מקרה לגופו.
ה- Active Directory Domain Services (או בקצרה AD DS) מכיל יתרונות רבים אשר ניתן לדסקס אודותם שעות רבות. היתרון הבולט והרלוונטי לפוסט זה הוא עצם היותו של ה- AD DS מבוסס מנגנון של Multi-master replication, כלומר כל DC בעל הרשאות כתיבה\קריאה ל- Directory (אלא אם הוגדר אחרת, במקרה של RODC לדוגמה...) מאפשר למידע להתרפלק (להסתנכרן) בקלות בין DCs.
בפורומים רבים, ביניהם פורום Windows Server של מיקרוסופט, נשאלות שאלות רבות סביב נושא השרידות: הם מתפקדים כמנהלי רשת עבור ארגון מסוים שה- DC בו קרס, ועליהם להחזיר את המצב לקדמותו. מכיוון שיש להם רק DC יחיד בארגון המצב קצת בעייתי והם זקוקים לעזרה...
נשאלת השאלה, מדוע בארגון אשר משקיע כסף לא מועט על פתרונות כמו Load Balancers, Clusters ופתרונות אחסון מסודרים לא תוקצה חומרה (או מכונה וירטואלית) נוספת עבור DC נוסף בארגון אשר ישמש כעותק של ה- DC הראשי (Replica). כמו כן, ניתן לשים לב אשר חלקם מתייחסים גם לתוכנית גיבוי עבור DC יחיד בארגון (ביצוע גיבויים שוטפים של ה- NTDS.DIT ו\או System State, לקיחת snapshots וכו'). הפעולות הללו אכן דרושות וחשובות, אך הפעולה הפשוטה של הוספה של Replica DC לא הועלתה או צויינה...
ניקח מקרי קיצון להבנה והפשטה, במקרה # 1 קיים ארגון עם DC יחיד. במקרה זה ה- DC קרס בשעות הפעילות של הארגון ואנו צריכים לשחזר אותו בהקדם האפשרי. הנקודות הבאות יצוצו בעת השחזור:
· עד לתום השחזור אנו חווים בעיות ברשת הארגונית
· המנהל או משתמשים רבים (כולל צוות ה- Helpdesk) פונים אלייך כל X דקות בתקווה לדעת האם ניתן לחזור לעבוד ו\או לקבל סטטוס אודות הבעיה
· במידה והבעיה איננה ברמת החומרה הפיזית אנו מבזבזים זמן על ניתוח בעיות וניסיון לאבחן את התקלה ולפטור אותה (דוגמאות שכיחות הן תולעת\וירוס שהתפשט והגיע ל- DC, בעיות עם תוכנית האנטי-וירוס, מסך כחול אשר נובע מאי תאימות דרייברים וכו')
· במידה ומדובר בבעיית חומרה פיזית יש לבחון את הנושאים הבאים:
o במידה ויש ברשותינו שרת פיזי נוסף בעל חומרה זהה – משך זמן השחזור יהא נמוך משום שאנו עושים שימוש בגיבויים ו\או Images מותאמים לחומרה
o במידה ואין ברשותינו חומרה תואמת אנו מתקינים מחדש בצורה נקייה את ה- DC על חומרה חדשה, או במקרה גרוע עוד יותר: ממתינים לטכנאי\מהנדס שירות שיגיע לאתר הלקוח לספק חומרה חלופית מתאימה – במקרים אלו זמן רב מבוזבז
· בדרך כלל נשתמש בגיבוי שנלקח מבעוד מועד של ה- System State [ולעיתים הגיבוי לא רלוונטי (חלפו 60\180 יום מביצוע הגיבוי, מידע נוסף כאן) או לא עדכני] לצורך שחזור ה- Directory
במקרה # 1 ניתן לחזור לתפקוד בפרק זמן מינימאלי לכל היותר של שעתיים. שעתיים בהן הארגון היה די 'כבול' (אם שירותי הדואר הארגוניים מתממשקים ל- Directory, כמו Exchange לדוגמה אזי לא ניתן לשלוח גם דוא"ל, כנ"ל לגבי שירותי אינטרנט אשר מבוססים על Proxy אשר מתממשק ל- Directory...) ומושבת... נכון, שיחות קפה וזמן איכות עם קולגות לקומה\משרד נראות כ'פיצוי' הולם לעובדים מסוימים (או משחק בשולה המוקשים וסוליטר) אבל... בסופו של יום תפקיד צוות ה- IT בארגון לדאוג לכך שהארגון יוכל להמשיך בפעולתו הרגילה, כלומר, מצב בו קיים DC יחידי מהווה בעיה חמורה.
מקרה קיצון נוסף, הוא מקרה # 2, בתרחיש זה אנו עובדים עם שני DCs בארגון. במקרה # 2 אחד מן ה- DCs קרס בשעות הפעילות של הארגון. הנקודות הבאות יצוצו מספר דקות לאחר הקריסה:
· אף אחד מן העובדים אשר אינם חלק מצוות\מחלקת מערכות מידע\IT בארגון לא ירגיש בשינוי (ובמידה וכן, השינוי יהיה מזערי*)
*אלא אם מפתח מסוים לא כתב בצורה נכונה את הקוד של התוכנה שלו ופונה ל- DC מסוים בשם או כתובת IP ולא ב- DNS Domain Name...
· תוך כמה זמן ניתן להגיע למצב בו ה- DC שקרס פעיל וזאת על-ידי קריאה (עם כוס קפה\תה ועוגה\כריך) של תוכנית ה- Disaster Recovery הארגונית (במידה וקיימת)
· במידה וקיימת תוכנית DR ארגונית לאחר קריאת ההנחיות יש ליישם את הכתוב בתוכנית – וחוזרים לעבודה!
· במידה ולא קיימת תוכנית DR ארגונית – יש לדאוג להחזיר את ה- DC למצבו התקין על-ידי נהלים, מאמרים (KBs לדוגמה) ושאר שיטות מוסכמות בארגון להתאוששות מקריסה של DC. במקרה קיצוני (שרת ניזוק באופן קשה, לדוגמה משריפה) ניתן להתקין שרת חדש ולהוסיף אותו כ- Replica ולרפלק את המידע מה- DC הקיים. (במקרה בו ה- DC שנזוק והוחלף היה בעל תפקידים נוספים כמו FSMO Roles holder יש לבצע Seizing לאותם תפקידים לדוגמה).
במקרה # 2 קיים חופש פעולה רחב עקב התמשכות העסקים כרגיל, אין זה אומר שעלינו לשבת על עלי הדפנה ודברים יסתדרו מעצמם, אך לפחות לא קיים לחץ גדול בדומה למקרה # 1 בו עלינו לפעול מיידית על-מנת להחזיר את המצב לקדמותו.
נקודה חשובה שיש לציין היא שניתן להוסיף Replica DC לפתרון וירטואלי (ESX/Hyper-V/Xen) ארגוני שקיים, אך לא להסתמך אך ורק על פתרון וירטואלי אלא להקים גם DC פיזי בארגון, וזאת מטעמי שרידות והתאוששות מאסון (תארו מה יקרה אם הפתרון הוירטואלי הארגוני יקרוס או לא יתפקד כראוי...).
לסיכום
פוסט זה הציג נקודות שיש לשקול בעת תכנון והקמה של תשתית AD DS בארגון, כמו כן שני מקרי קיצון להמחשת המצב ותיאור נקודות אשר 'עולות' באופן טבעי בעת טיפול ב- DC שקרס במקרים שונים הוצגו. מומלץ בארגונים להתקין DC נוסף אשר יהווה עותק (Replica) של ה- DC הראשי, כאשר על ה- Replica DC לשמש גם כ- GC ו- DNS (ועל תחנות ושרתים בארגון לדעת זאת ולעשות בו שימוש כ- Alternate DNS).
פוסט זה מוקדש לאברהם (אבי) מועלם, מומחה לתשתיות מיקרוסופט (בדגש על PowerShell, Exchange & Directory Services) באגף המודיעין של צה"ל.