בהמשך לפוסט על מה חדש ב Windows Server 2008 Terminal Server ובהמשך לפוסט על Windows Server 2008 TS RemoteApps, המשך של סקירת ה feature-ים החדשים לעומק.

והיום.... TS Session Broker.
ה Session Broker מכיל למעשה שני אלמנטים, הראשון זה הפעלת load balancing לשרתים (עפ"י מיקרוסופט יעבוד טוב עד 5 שרתים) והשני מיועד לאפשר למשתמשים להתחבר בחזרה ל sessions שלהם בחוות ה TS אשר עובדת עם load balancing.

בטח חלקכם תוהים, מה כבר כל הסיפור, הרי כבר יש לנו את ה Session Directory שיודע לחבר את המשתמשים ל disconnected sessions שלהם עוד מ Windows Server 2003, קודם כל זה נכון, זה באמת קיים... אבל, זה הדבר היחידי שזה עושה, אין שום נגיעה ב load balancing וה session directory קיים רק בגרסת ה enterprise של ה Windows server 2003.

אז איך על העניין הזה עובד, session broker הוא role השייך ל Terminal Services, אבל אין שום צורך להתקין את ה TS עצמו כדי שהשרת הרלוונטי יהיה ה session broker של חוות ה TS.
בכדי ליצור "חוות TS" ולגרום לשרתים לעבוד עם ה session broker יש צורך במספר דברים,להתקין את ה session broker role על אחד השרתים (לווא דווקא TS), להגדיר את שרתי ה TS שיהיו חברים ב Farm ולהגדיר רשומת DNS עם כתובות כל שרתי ה TS כדי שיהיה סוג של load balancing לפני ההתחברות.
למשל, אלה ההגדרות שמוגדרות באחד משרתי ה TS אצלי:

כמו שאפשר לראות, אין פה יותר מדי הגדרות, סה"כ מה שיש פה זה אפשרות להגדיר האם השרת יהיה חבר בחווה עם session broker, מהו שרת ה session broker שלי, מה שם החווה שלי, האם להכניס את השרת לשרתים המשתתפים ב load balanacing ומה המשקל שרוצים לתת לשרת יחסית לשרתים האחרים בחווה (מאין הגדרה מספרית שאנחנו ניתן כדי להגדיר מי השרתים החזקים יותר).
מבחינת ה DNS, אני יוצר רשומה חדשה עם שם החווה שלי (לא חובה, אבל מומלץ) ומקשר לרשומה הזאת את ה ip-ים של שרתי ה TS שלי אשר אני רוצה לכלול בחווה (ה round robin מופעל ב default בשרתי ה DNS של Windows 2003 ו- 2008).

למעשה, ה load balancing נעשה על ידי חלוקה וספירה של sessions בשרתים, אבל ישנם עוד כמה דברים שעוזרים לייצב את המערכת כולה, הראשון ה black hole protection ומובנה בתוך ה session broker, שלמעשה מונע העמסת השרת בכניסות חדשות (login throttling) ופה מגיע סוג של חח למיקרוסופט, כי כמה שנותים לזלזל ב TS הרגיל שלהם (ואני מאמין ד"א שזה ייעלם מהעולם ממש עוד מעט), Citrix הוסיפו את אותו ה feature רק בגרסא האחרונה של ה Presentation Server.
הדבר השני הוא האפשרות לקבוע מספר מרבי של session על שרת ספציפי, ככה שאם אם יש לנו שרת אחד חלש יחסית לאחרים בחווה, אני ארצה להגביל את מספר ה sessions עליו לאותו מספר שבו אני אראה שהוא יוכל לחיות איתו בשלום, אין GUI לעניין הזה, אז נצטרך לשאת פעמינו ל registry ולהגדיר את העניין שם...
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\UserSessionLimit,
דבר נוסף, הוא ה session sharing, עם המשתמש פתח session נגיד עם RemoteApp של Word על שרת מסוים בחווה, כשהוא ירצה להתחבר ל RemoteApp אחר ה session broker יפנה אותו לשרת שאליו המשתמש כבר מחובר, פה יש בעיתיות מסוימת כי מבחינת ה session broker כל שרתי ה TS בחווה דומים ולכולם יש את כל האפליקציות של האחרים ואם זה לא ככה המשתמש יקבל הודעת שגיאה שהאפליקציה לא נמצאה (את האמת, אני לא מבין למה הם לא הוסיפו בדיקה האם האפליקציה קיימת בכלל או לא, זה לא נראה דבר כ"כ מטורף).

עכשיו רק נותר רק לראות איך כל התהליך של חיבור משתמשים לחווה מתרחש...
ובדוגמאות שאני פה, אני אתייחס לתצורה שלי (שני שרתי TS מוגדרים לעבוד עם session broker, שם החווה שלי הוא Commart_TS_Farm, ומוגדר dns round robin בין שני השרתים).
1. המשתמש מתחבר לשרת TS ע"י התחברות למעשה לחווה, (כותב Commart_TS_Farm ב RDP client למשל).
2. הוא מתחיל התחברות לשרת הראשון שהוא קיבל מה DNS (כאמור, מוגדר לי round robin), אם השרת לא זמין מסיבה כזאת או אחרת, הוא ממשיך לשרת הבא ברשימה.
3. כשנוצר connection לשרת, נעשית בדיקה האם הוא חבר ב Session Broker והוא משתתף ב load balancing של החווה.
4. אם כן, השלב הראשון הוא לבדוק האם למשתמש אשר מנסה להתחבר ישנם disconnected sessions באחד מהשרתים, אם כן, אז המשתמש מופנה ל session הישן שלו.
5. אם אין למשתמש שום disconnected sessions בחווה, נעשית ספירה של ה sessions על השרתים (גם הפעילים וגם המנותקים), נלקח בחשבון המשקל שניתן לכל שרת והאם השרת פתוח להתחברות או לא.
6.לאחר כל החישובים המשתמש מופנה לשרת הפחות עמוס בחווה (לפי החישובים בסעיף הקודם).

קצת להמחשה של כל העניין:

סיכומים, עניינים...
כל העניין הזה נראה די מבטיח את האמת, וכן, אני רואה שיש פה סיבוכיות קצת מיותרת ואין התייחסות ל load balancing עפ"י עומס או כל דבר פרט לספירת sessions והתחשבות בנתונים יבשים אחרים, וגם די מוזר לי את האמת למה מיקרוסופט מדגישים בכל פעם שכל הסיפור הזה יעבוד טוב עד למשהו כמו 7 שרתים, כי טכנולוגית אני לא רואה למה זה לא יכול להחזיק גם עם עשרות שרתים, אולי כל זה נועד כדי למנוע בריחה מסיבית של חברות בינוניות מה Presentation Server (ובעיקר ממנו, כי למיקרוסופט ו Citrix יש שותפות עתיקת יומין, ולא נראה שיש רצון מצד שתי החברות לפגוע כך או אחרת אחת בשניה) וכל החלופות השונות.