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

ה- 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) באגף המודיעין של צה"ל.

• קרא עוד
• 2 תגובות

הי,

מיקרוסופט מציעה לזמן מוגבל את ה- Office 2010 First Look e-Book להורדה חינם.

ה- e-Book שוקל כ- 10.5 מגה בפורמט PDF ומכיל מידע בנושא Office 2010; הספר מחולק לשלושה חלקים עיקריים: Envision the Possibilities אשר פותח את הספר, Hit the Ground Running באמצע הספר, ולסיום Next Steps with Office 2010.

מעוניינים לדעת עוד? הורידו עכשיו (זה חינמי!) מפה.

מידע נוסף ניתן למצוא כאן אודות ה- e-Book.

קריאה מהנה,

נתנאל.

• קרא עוד
• 1 תגובות

קיימות שאלות וסוגיות רבות סביב נושא ה- Paging file, לעיתים גם נוכחתי לוויכוחים קשים ותפיסות עבודה שונות (ולעיתים גם משונות) בארגונים לגבי איך, מה ולמה אודות ה- Paging file.

הערה: ה- Paging file מוכר גם בשמות Pagefile, Swap file. הכוונה לאותו קובץ אשר כולם מכוונים אליו בשמותיהם השונים, קובץ ה- pagefile.sys.

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

למי יש יותר גדול?

גודלו של ה- Paging file אינו דבר שרירותי; במידה והמחשב שלך מכיל מתחת ל- 2GB של RAM אזי קובץ ה- Paging file שברשותך יהיה גדול פי 1.5 מהזיכרון הפיזי.

במקרה בו המחשב שברשותך מגיע עם יותר מ- 2GB של RAM קובץ ה- Paging file כברירת מחדל יהא בסדר גודל שבין 2046-4092MB. זוהי שיטת העבודה הנהוגה כברירת מחדל אך לעיתים איננה אופטימלית ו\או מתאימה כנדרש.

דרך אחת מיני רבות, אך מועדפת עליי, לקביעת גודל ה- Paging file של המערכות הנוכחיות (64 ביט) היא להשתמש ב- Perfmon ולנטר אחר ה- Counters הבאים, כאשר יש להתייחס גם לערכים שלהם:

· Memory\\Available Bytes – לא פחות מ- 4MB

· Memory\\Pages Input/sec – לא יותר מ- 10 pages

· Paging file\\%Usage – לא יותר מ- 70%

· Paging file\\%Usage Peak – לא יותר מ- 70%

· Process\\Page File Bytes Peak – בעל הערך Not applicable

כאשר Paging file\\%Usage שווה או גדול יותר מ- 70% ייתכן וניאלץ להגדיל את ה- Paging file או לצור Paging file נוסף על דיסק נפרד.

לא על ה- Counters לבדו חי האדם...

בנוסף, לאלו מכם שמעוניינים בחוות דעת שנייה, הינכם מוזמנים לעיין ב- Process Explorer ב- System Information (ניתן ללחוץ על Ctrl+I בכדי להגיע לחלון הנ"ל, או פשוט לאתרו תחת תפריט View).

באם תשימו לב תוכלו לראות את ה- Commit Charge Limit שזהו למעשה ה- Virtual Memory ללא הגדלת ה- Paging file (כלומר כלל הזיכרון הפיזי במחשב, ה- RAM + גודלם של כל קבצי ה- Paging במחשב).

ה- Commit Charge Peak, כשמו כן הוא, מהווה את נקודות השיא של השימוש ב- Paging file מאז שהמחשב אותחל (Booted) לאחרונה.

מטרת בדיקת ה- Commit Charges הללו היא לוודא שה- Limit גדול יותר מן ה- Peak; מלבד זאת, חשוב לוודא כי ההפרש בין ה- Limit ל- Peak עולה או שווה ל- 70%, כלומר שתמיד יהיה קיים מצב בו ה- Peak אינו מגיע ל- 70% ו\או גדול מן ה- Limit.

מידע נוסף אודות המידע הכלול ב- System Information כולל נושא ה- Commit Charges ניתן למצוא בספר Windows Internals בעמודים 446-447.

נקודה נוספת שמומלץ לשקול היא לוודא שהערכים Initial Size ו- Maximum Size זהים. מצב שכזה ימנע מן ה- Paging file לגדול, פעולה אשר עלולה לגרוע מביצועי המערכת ולגרום לבסוף לפרגמנטציה של ה- Paging file.

מבחינת ביצועים שווה לשקול גם חלוקה של ה- Paging file בין דיסקים שונים.

מערכות עם ים של RAM

במערכות עם כמות גדולה של RAM (שרתים לדוגמה) דוגמת 32GB של RAM שרצות על מערכת הפעלה x64 מומלץ להגדיר את ה- Paging file שבמחיצת מערכת ההפעלה ל- 8GB הן בערך Initial והן בערך Maximum. פעולה זו תגרום לכך שלמערכת תהיה יד חופשית בכל הקשור ל- Paging ומלבד זאת, במקרה של Crash (מסך כחול, טפו טפו... חמסה חמסה...) יכתבו אך ורק Kernel memory dumps (די מפחיד ולא יעיל לכתוב Full memory dump של מכונה עם 32GB RAM. חשבו מה היה קורה במערכות Windows Server 2008 R2 Enterprise/Datacenter עם מקסימום זיכרון, ורק תזכורת קלה: התמיכה המקסימאלית במערכות אלו היא ב- 2TB RAM...).

למה דווקא 8GB Paging file במערכות עם 32GB של RAM? חשוב לציין תחילה שמלבד נוכח העובדה שיצירה של Paging file של 32GB x 1.5 איננה מעשית עקב היותו קובץ עצום, חשבו על הנקודות הבאות:

• כיצד תעביר קבצים גדולים לצורכי ניתוח?
• משך הזמן אשר נדרש ליצירת קובץ Paging גדול
• איזה שימוש פרקטי ייעשה בו
• כתיבת Full memory crash dump אינה ריאלית ובזבזנית
• כמות שטח הדיסק שתוקצה ל- Paging file תהא גדולה

לכן, באופן מעשי הדבר ניתן לביצוע. אך מבחינה ריאלית הוא לא יישים (לפחות לא נכון לתאריך שבו נכתב פוסט זה).

מארק רוסינוביץ', האיש מאחורי Sysinternals וספרי Windows Internals, מציין בפוסט נהדר בנושא Virtual Memory המהווה חלק מסדרת פוסטים רחבה (ששווה קריאה בלי שום קשר, אלא אם כן קראתם את Windows Internals 5^th Edition...) את סוגיית גודל ה- Paging file (תחת How Big Should I Make the Paging File?), שווה קריאה.

חשוב לציין את המשפט הבא בפוסט שלו:

“The maximum is either three times the size of RAM or 4GB, whichever is larger.”

המשפט הנ"ל נכתב עבור מערכות ויסטה ו- 2008, אך נכון גם ל- 2003.

הצעה נוספת של מארק רוסונוביץ'

ד"ר מארק רוסוניביץ', האיש והאגדה, מספק בפוסט שלו בנושא Virtual Memory, שקישרתי אליו טרם לכן בפוסט זה, הסבר די יעיל ששווה לשקול עבודה לפיו גם והוא פתיחת כלל האפליקציות שאמורות לרוץ על המחשב במקביל כולל עבודה שוטפת עם המחשב והזנת נתונים ולפי הנתון המוצג ב- Commit Charge Peak.

לסיכום: מה הגודל שעליי להקצות ל- Paging file שלי?

השאלה הזו, שהיא אחת מהמתבקשות בסופו של פוסט שכזה היא שאין גודל קבוע עבור כלל המחשבים. כפי שפתחתי את הפוסט כל מקרה לגופו – יש להתחשב בכל מחשב באופן נפרד עקב כמות הזיכרון שמותקנת בו וה- Virtual Memory שדרוש לעבודה. במידה ואין מידע נוסף זמין עבורינו עבור אותו מחשב, ההגדרה של גודל הזיכרון הפנימי (RAM) x 1.5 היא נקודת התחלה טובה.

במערכות מאסיביות ושרתים יש להקצות מספיק זיכרון פנימי לאפליקציות (דוגמת Exchange Server) ולמערכת ההפעלה שרצה על-גבו כך שלא יווצר מצב בו קיים מחסור ב- RAM ולמעשה לא ייעשה שימוש ב- Paging file. במערכות שמכילות כמות עצומה של RAM (כמו דוגמת ה- 32GB לדוגמה של 32GB x 1.5) שימוש ב- Paging file עצום אינו ריאלי וחסר תועלת.

מצד שני, דיסקים היום הם מצרך זול, והקצאה של Paging file גדול לפי הנוסחא של RAM x 1.5 אפשרית עבור מערכות מסוימות (לא להשתולל ולהקצות למערכות עם 32GB קובץ עצום).

כמו כן, חשוב לציין כי שימוש רצוף ב- Paging file על-ידי מערכת ההפעלה מעיד על חוסר ב- RAM, ולכן, מומלץ להתקין זיכרון נוסף במחשב על-מנת לשפר את ביצועי המערכת.

חשוב לציין שוב, בשורה לתחתונה לסיכום שגודל של Paging file במכונה מסוימת אינו שרירותי לכלל המכונות בארגון. כלומר, הגודל של Paging file במכונה מסוימת לא קובע (את גודל ה- Paging file של כלל המכונות בארגון) :-).

• קרא עוד
• 2 תגובות

בשעה טובה ומוצלחת ובעיקר תודות ל- Steven Bink ניתן לצפות בתמונות של הקופסאות של Office 2010, התמונות מוצגות לראשונה ב- Centrumxp והנה הן לפניכם רבותיי:

• קרא עוד
• אין תגובות