Exchange Server 2010 - DAG, DAC and Site Resilience important notes

בתקופה האחרונה במסגרת ייעוצים של הסבות/שדרוגים מתשתית Exchange Server 2003/7 לארכיטקטורה מבוססת על Exchange Server 2010 ליוויתי וסקרתי מסמכי תכנון שנכתבו על ידי שותפים וגיליתי שיש מספר נקודות מהותיות בתפישת הארכיטקטורה בגרסה זו של Exchange שאינן ברורות מספיק, ולכן החלטתי לפרסם Blog קצר זה והפניות ללינקים חשובים שיספקו פירוט נוסף.

ב Exchange Server 2010 חשפנו יכולות שרידות וזמינות משופרות לתפקיד ה Mailbox Server, מאילו שהיו בגרסאות ה Exchange עד כה. היכולות כלולות במושג חדש המכונה Database Availability Group (בקיצור "דג" - DAG).

ה DAG הינו אוסף של שרתי Mailbox ובסיסי נתונים (של תיבות דואר בלבד), שיכולים להיות משוכפלים בין שרתי ה Mailbox בהתאם לדרישות הארגון (ניתן להגדיר עד 16 שרתי תיבות ועד 16 עותקים של כל אחד מבסיסי הנתונים בתצורה זו).

להלן איור כללי של תשתית Exchange 2010 הפרושה על פני שני Datacenters - "ראשי" (Redmond) ו"משני" (Dublin):

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

לרוב, בתצורה בה מוגדר Datacenter "ראשי" (פעיל) ו Datacenter "משני" (למטרות Disaster Recovery בלבד) - מומלץ יהיה להגדיר DAG יחיד, כאשר ה File Share Witness - FSW, נמצא ב Datacenter ה"ראשי".

יש לשים לב כי בתצורה זו, במקרה של כשל בתקשורת בין שני ה Datacenters, במידה והיו בסיסי נתונים פעילים ב Datacenter ה"משני" (בו לא נמצא ה FSW) - בסיסי הנתונים יבצעו Dismount ולכן לא יהיה שירות למשתמשים ב Datacenter ה"משני".

מכאן, שבמקרה שבו מעוניינים שגם שרתי ה Exchange 2010 באתר ה"משני" יהיו פעילים בשוטף (ולא רק במקרה של DR) - הפתרון המומלץ יהיה: שימוש בשני DAG (אחד עבור כל Datacenter) והגדרת ה FSW "מקומי" בכל אחד מה Datacenter. יש לשים לב, שבמקרה זה נדרשים עוד שני שרתי Exchange 2010 Mailbox Role (אחד עבור כל Datacenter, אשר ישמשו במקרה של DR באתר השני)

נקודה נוספת שחשוב להבהיר היא שבמידה והגדרתם כחלק מה DAG גם Alternate File Share Witness ומיקמתם אותו על שרת ב Datacenter "המשני", הרי שבמקרה של כשל ב Datacenter "הראשי" אותו Alternate File Share Witness אינו מתפקד כלל בצורה אוטומטית! נדרשת התערבות ידנית של מנהל המערכת, על מנת להפוך את ה Alternate File Share Witness ל File Share Witness "רגיל"!

שימו לב שהמעבר במקרה של כשל באחד מה Datacenters הוא ידני (ולא אוטומטי)!

שימו לב גם, כי נדרש גם עדכון ידני של כתובת ה IP של שירות ה CAS (הפניית ה IP Address של ה CAS Array מה Datacenter "הראשי" אל ה IP Address של ה CAS Array המצוי ב Datacenter "המשני")!

בנוסף, על מנת למנוע מצב של Split-Brain Syndrome, שעלול להיווצר במקרה שה Datacenter "הראשי" חוזר לתפקד לאחר הכשל, וה Datacenter "המשני" עדיין משרת את המשתמשים שתיבותיהם נמצאות בבסיסי הנתונים שפעלו קודם לכן ב Datacenter ה"ראשי", מומלץ להגדיר את ה DAG בתצורה המכונה: "Datacenter Activation Coordination" (בקיצור DAC). שימוש בתצורה זו ימנע מבסיסי הנתונים ב Datacenter שכשל מלבצע Mount אוטומטית.

לינקים שימושיים בנושא:

-        מידע אודות DAC ומטרתו: http://technet.microsoft.com/en-us/library/dd979790.aspx

-        מידע אודות Datacenter Switchovers: http://technet.microsoft.com/en-us/library/dd351049.aspx

בהצלחה ו"דיג" נעים,

אפי ברגמן.