למה אני צריך יותר מ-Domain Controller יחיד בארגון?

אחת מנקודות הכשל הבעיתיות ביותר בארגונים קטנים הוא נושא ה-Active Directory. נתנאל בן-שושן מסביר לנו על חוויית השחזור מאסון ומדוע שווה להשקיע ב-Domain Controller נוסף בארגון.

Server

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

ה- Active Directory Domain Services (או בקצרה AD DS) מכיל יתרונות רבים בהן ניתן לדון בהרחבה, אך היתרון הבולט והרלוונטי ביותר לפוסט הזה הוא עצם היותו של ה- AD DS מבוסס מנגנון של Multi-master replication. כלומר, כל Domain Controller הוא בעל הרשאות כתיבה\קריאה ל- Directory (אלא אם הוגדר אחרת, במקרה של Read-Only Domain Controller בסביבות 2008) מאפשר למידע להתרפלק (להסתנכרן) בקלות בין DCs.

בפורומים רבים, ביניהם פורום Windows Server של מיקרוסופט, נשאלות שאלות רבות סביב נושא השרידות של מערכות Active Directory. השואלים בדרך כלל מתפקדים כמנהלי רשת עבור ארגון מסוים שה- DC בו קרס ועליהם מוטלת המלאכה של להחזיר את המצב לקדמותו. מכיוון שיש להם רק DC יחיד בארגון, המצב קצת בעייתי והם זקוקים לעזרה.

נשאלת השאלה מדוע בארגון אשר משקיע כסף לא מועט על פתרונות כמו Load Balancers, Clusters ופתרונות אחסון מסודרים לא תוקצה חומרה (או מכונה וירטואלית) נוספת עבור DC נוסף בארגון אשר ישמש כעותק של ה- DC הראשי (Replica). חלק מהארגונים כן מתייחסים לתוכנית גיבוי עבור DC יחיד בארגון (ביצוע גיבויים שוטפים של ה- NTDS.DIT ו\או System State, לקיחת snapshots וכו’), אך אף על פי שהפעולות הללו אכן דרושות וחשובות, הפעולה הפשוטה של הוספה של Replica DC לא הועלתה או צויינה.

ניקח לדוגמה שתי תרחישים בשתי נקודות קיצון להבנה והפשטה:

תרחיש א’ – Domain Controller בודד בארגון

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

  1. עד לתום השחזור אנו חווים בעיות ברשת הארגונית.
  2. המנהל או משתמשים רבים (כולל צוות ה- Helpdesk) פונים אלייך כל X דקות בתקווה לדעת האם ניתן לחזור לעבוד ו\או לקבל סטטוס אודות הבעיה.
  3. במידה והבעיה איננה ברמת החומרה הפיזית אנו מבזבזים זמן על ניתוח בעיות וניסיון לאבחן את התקלה ולפטור אותה (דוגמאות שכיחות הן תולעת\וירוס שהתפשט והגיע ל- DC, בעיות עם תוכנית האנטי-וירוס, מסך כחול אשר נובע מאי תאימות דרייברים וכו’).
  4. במידה ומדובר בבעיית חומרה פיזית יש לבחון את הנושאים הבאים: במידה ויש ברשותינו שרת פיזי נוסף בעל חומרה זהה – משך זמן השחזור יהא נמוך משום שאנו עושים שימוש בגיבויים ו\או Images מותאמים לחומרה. במידה ואין ברשותינו חומרה תואמת אנו מתקינים מחדש בצורה נקייה את ה- DC על חומרה חדשה, או במקרה גרוע עוד יותר: ממתינים לטכנאי\מהנדס שירות שיגיע לאתר הלקוח לספק חומרה חלופית מתאימה – במקרים אלו זמן רב מבוזבז.
  5. בדרך כלל נשתמש בגיבוי שנלקח מבעוד מועד של ה- System State [ולעיתים הגיבוי לא רלוונטי (חלפו 60\180 יום מביצוע הגיבוי, מידע נוסף כאן) או לא עדכני] לצורך שחזור ה- Directory.

בתרחיש הראשון, ניתן לחזור לתפקוד בפרק זמן מינימאלי לכל היותר של שעתיים. שעתיים בהן הארגון היה יחסית “כבול” (אם שירותי הדואר הארגוניים מתממשקים ל- Directory, כמו במקרה של Exchange, אזי גם לא ניתן יהיה לשלוח דוא”ל וכנ”ל לגבי שירותי אינטרנט אשר מבוססים על Proxy אשר מתממשק ל- Directory). נכון, שיחות קפה וזמן איכות עם קולגות לקומה\משרד נראות כ”פיצו”‘ הולם לעובדים מסוימים (או משחק בשולה המוקשים וסוליטר), אך בסופו של יום תפקיד צוות ה-IT בארגון לדאוג לכך שהארגון יוכל להמשיך בפעולתו הרגילה, כלומר, מצב בו קיים DC יחידי מהווה בעיה חמורה.

תרחיש ב’ – שני שרתי Domain Controller בארגון

בתרחיש השני אנו עובדים עם שני DCs בארגון. אחד מה-DCs קרס בשעות הפעילות של הארגון. הנקודות הבאות יצוצו מספר דקות לאחר הקריסה:

  1. אף אחד מן העובדים אשר אינם חלק מצוות\מחלקת מערכות מידע\IT בארגון לא ירגיש בשינוי. ובמידה וכן, השינוי יהיה מזערי אלא אם מפתח מסוים לא כתב בצורה נכונה את הקוד של התוכנה שלו ופונה ל- DC מסוים בשם או כתובת IP ולא ב- DNS Domain Name.
  2. תוך כמה זמן ניתן להגיע למצב בו ה- DC שקרס פעיל וזאת על-ידי קריאה (עם כוס קפה\תה ועוגה\כריך) של תוכנית ה- Disaster Recovery הארגונית (במידה וקיימת). במידה וקיימת תוכנית DR ארגונית לאחר קריאת ההנחיות יש ליישם את הכתוב בתוכנית – וחוזרים לעבודה!
  3. במידה ולא קיימת תוכנית DR ארגונית – יש לדאוג להחזיר את ה- DC למצבו התקין על-ידי נהלים, מאמרים (KBs לדוגמה) ושאר שיטות מוסכמות בארגון להתאוששות מקריסה של DC. במקרה קיצוני (שרת ניזוק באופן קשה, לדוגמה משריפה) ניתן להתקין שרת חדש ולהוסיף אותו כ- Replica ולרפלק את המידע מה- DC הקיים. (במקרה בו ה- DC שנזוק והוחלף היה בעל תפקידים נוספים כמו FSMO Roles holder יש לבצע Seizing לאותם תפקידים לדוגמה).

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

נקודה חשובה שיש לציין היא שניתן להוסיף Replica DC כחלק מפתרון הוירטואליזציה בארגון (ESX/Hyper-V/Xen), אך לא מומלץ להסתמך אך ורק על פתרון וירטואלי אלא להקים גם DC פיזי אחד לפחות. זאת מטעמי שרידות והתאוששות מאסון (דוגמת מקרה בו הפתרון הוירטואלי הארגוני יקרוס או לא יתפקד כראוי).

לסיכום

פוסט זה הציג מספר נקודות שיש לשקול בעת תכנון והקמה של תשתית Active Directory בארגון, יחד עם שני מקרי קיצון להמחשת המצב ותיאור נקודות העולות באופן טבעי בעת טיפול ב- DC שקרס במקרים שונים הוצגו. באופן כללי, אני אמליץ לכל ארגון להתקין DC נוסף אשר יהווה עותק (Replica) של ה- DC הראשי על-מנת לאפשר טיפול יעיל יותר במקרה של אסון. כמו כן, יש לשים לב בעת הגדרת ה-Replica כי על השרת לשמש גם כ- GC ו- DNS (ועל תחנות ושרתים בארגון לדעת זאת ולעשות בו שימוש כ- Alternate DNS) על מנת שהפתרון יעבוד בצורה חלקה במקרה של קריסה של אחד מה-DCs.

הערה: הפוסט אינו מיועד להחליף התייעצות מקצועית עם איש מקצוע מתאים (אינטגרטור\יועץ וכו’), ויש להתייחס לכל מקרה לגופו.

הפוסט פורסם גם בבלוג האישי של נתנאל בן-שושן

נתנאל בן-שושן

נתנאל בן-שושן (CSA, JNCIA-SSL, MCSA/E, MCTS, MCITP) הוא יועץ טכנולוגיות ומרצה אשר עוסק בעיקר בתשתיות מיקרוסופט, תקשורת ואבטחת מערכות מידע. נתנאל מפעיל את האתר www.ben-shushan.net אשר מכיל שלל מאמרים, טיפים וטריקים בנושאי ה- IT השונים ומפעיל בנוסף לכך בלוג אישי בקהילת הבלוגים של מיקרוסופט ישראל. בזמנו הפנוי נתנאל אוהב לצייר, לבשל ולדוג.

הגב

Be the First to Comment!

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
wpDiscuz

תגיות לכתבה: