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

הסקירה המורחבת בדרך – עניין של שבוע שבועיים אני מאמין – אבל בנתיים מה שהגניב אותי (ברר… גיקי) הכי בגירסא החדשה זה ה- Desktop Viewer החדש (מחליפו של ה- Desktop Reciever) שבא כחלק
מ- Citrix On-Line Plugin להתחברות לסביבות עבודה מרוחקות.

 

 

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

 

 

התחברות לסביבה אחת (מסך מלא). שימו לב לריבוע Home Desktop בצד שמאל, לחיצה עליו תחזיר את המשתמש לדסקטופ המקומי שלו -

 

על- Zones בקצה קצהו של המזלג:

חוות Citrix גדולות מחולקות לא פעם ל- Zones לשם חלוקה גאוגרפית של השרתים. בדומה מאוד לחלוקה של Active Directory domain, שם החלוקה היא ל- Sites.
לרוב, כל Zone מכיל את כל שרתי ה- XenApp הקרובים גאוגרפית אחד לשני ולכל Zone שכזה ישנו Zone Data Collector האחראי על אותו ה- Zone (נתונים בדבר חיבורי משתמשים, עומסים וכו’). החלוקה ל- Zones נעשית כדי להחזיק שרתים הקרובים גאוגרפית כמה שניתן למיקום המשתמשים או/ו למיקום ה- Data Center האזורי.

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

אני אתייחס כאן לאופן העבודה עם Web Interface (על אופניו השונים, Site או Service) בעיקר כי ה- Zone Preference and Failover עובד רק כאשר מתחברים דרך ה- Web Interface וגם כי תצורת ההתחברות מקליינט מלא הולכת לא להיתמך יותר לקראת סוף השנה הבאה – למעשה Citrix Client 11 הוא הקליינט האחרון שמכיל את התצורה המלאה.

 

קצת רקע על איך הכל עובד. כאשר משתמש ניגש ל- Web Interface ומזדהה מולו, ה- WI פונה לשרתי ה- XML שהוגדרו בשבילו ובודק איזה אפליקציות נגישות למשתמש. כאשר המשתמש לוחץ על אפליקציה מסוימת, ה- Zone Data Collector של אותו שרת XML בודק את השרתים הזמינים לאותה האפליקציה (הגדרה לכל אפלקיציה) ומה השרת הכי פחות עמוס בין שרתים אלו. לאחר ההחלטה, המשתמש מופנה לשרת הרוולנטי ומתחיל לעבוד על האפליקציה.

במקרה ויש לנו מספר Zones הפזורים ברחבי העולם עם מספר שרתים בכל אחד מהם ואם נגדיר את כל השרתים האלה כזמינים עבור אפליקציה מסוימת, יכול להיווצר מצב שמשתמשים מיפן יופנו לעבוד על שרתים בארה”ב במקום על שרתים הממוקמים ביפן. לדוגמא, אם שרת ה- XML המוגדר ב- WI אליו פונים המשתמשים מיפן נמצא בארה”ב, ה- Zone Data Collector שיהיה אחראי למצוא שרת זמין עבור משתמשים אלה יהיה אמריקאי בכל רמח איבריו, מה שאומר שהוא לא ישים יותר מדי על שרתים מה- Zone היפני ויפנה את היפנים המסכנים לעבוד על שרת בארה”ב. באסה להם.

 

אבל… יש פיתרון. קיים Citrix Policy הנקרא Zone Preference and failover. תפקידו הוא להפנות את המשתמשים ל- Zone המתאים להם ביותר ולהגדיר מה קורה אם אותו Zone לא זמין. את הפוליסי אפשר להגדיר לפי כתובות ה- IP של המשתמשים הניגשים לחווה, לפי שייכות לקבוצות ב- AD, או לפי כל סינון אחר. בצורה זאת, ניתן באפליקציה אחת להגדיר את כל מספר שרתים מ- Zones שונים, והמשתמשים יופנו לשרתים המתאים להם ביותר.
ההגדרה היא כזאת, כאשר משתמש X ניגש, מה יהיה ה- Zone אליו החיבור שלו יופנו (וממנו יבחר השרת המתאים לו ביותר) והאם להפנות את המשתמש ל- Zone אחר במקרה שה- Zone שבחרנו עבורו (Primary Group) לא זמין.

 

לשם ההמחשה, קיימים אצלי שני Zones, בשמות המפתיעים Zone1 ו- Zone2.

כדי להפנות את המשתמשים הקרובים יותר לכל Zone, יצרתי שני Policies, הלא הם Zone1 Policy
ו- Zone2 Policy.

 

ב- Zone1 Policy הגדרתי שמשתמשים מכתובות 192.168.1.1-200 יעבדו עם Zone1, ואם הוא לא פעיל, הוא יופנו לעבוד עם Zone2. הערת שוליים – כמובן שיכולתי להגדיר שהם לא יוכלו לעבוד מול אף Zone אחר פרט ל- Zone1.

 

וב- Zone2 Policy הגדרתי שמשתמשים מכתובות 192.168.2.1-200 יעבדו עם Zone2, ואם הוא לא פעיל, הוא יופנו לעבוד עם Zone1.

 

כאשר משתמש עם כתובת 192.168.1.3 ניגש ל- WI (במקרה הזה לא משנה לאיזה שרת XML באיזה Zone הוא מופנה), הוא יופנה תמיד לעבוד עם שרתים ב- Zone1. כמובן במקרה והם אכן זמינים. אם לא, המשתמש יופנו לעבוד על שרתים ב- Zone2.
אותו הסיפור יקרה עם משתמשים מרשת 192.168.2, רק הפוך. ה- Zone הראשי יהיה Zone2 והמשני -במקרה ו- Zone2 לא יהיה זמין – יהיה Zone1.

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

 

בכל אופן, למרות שאני בטוח שרובכם רוצים לשמוע יותר על המחלה המסתורית, לא זאת הסיבה לשמה התכנסנו כאן היום. הסיבה היא הפוסט “Virtualization I get it (I even love it) but VDI....WTF?” שנכתב ע”י אריק פרקינס ב- Inside the registry והיווה השפעה למה שאתם הולכים לקרוא.

 

כדי לתקצר את הפוסט המדובר – עדיין מומלץ להשקיע 3 דקות ולקרוא – והמוגב מאוד הזה. בקטע ההזוי משהו, אפשר למצוא את זה שאריק טוען שה- VDI היא המצאה של VMware כדי למשוך אש מ- Citrix וממיקרוסופט. אז נכון, VMware אכן התחילו לדבר על ה- VDI מעט מוקדם יותר מאשר Citrix – והרבה מוקדם יותר מאשר מיקרוסופט – אבל מכאן ועד לכך שכל העניין הוא קונספירציה למשוך אש ותקציבים מהמתחרות שלה. נו, נגיד.
בקטע היותר שפוי, אריק כותב שב- 95% מהמקרים, ה- VDI בכלל איננו מתאים לארגון, וכל ההתעניינות מסביב הטכנולוגיה/קונספט החדש היא בעיקר באזז וכל אותם הארגונים שחושבים על ה- VDI בכלל לא צריכים את כל הטירוף שכרוך סביבו – חומרה במרכז, מאות/אלפי מכונות וירטואליות לנהל, אימאג’ אחיד לכולם, אפליקציות ועוד ועוד – ומה שהם מחפשים עכשיו ב- VDI (מירכוז, ניהול סביבה אחידה וכו’) הם היו יכולים למצוא כבר מזמן ב- SBC (או Terminal Services או Citrix XenApp במילים אחרות).

 

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

 

הרי כולנו מבינים שמשתמשים במוקדי שירות לא ממש צריכים את כל הטירוף הזה סביב הקמה של סביבת VDI וממש אין להם מה לעשות עם ה- Windows XP\7 שהם יקבלו, גם ככה הם מבלים את רוב זמן ב- CRM. רוב העובדים הנותרים בארגון לא שונים בהרבה מהם, הם משתמשים בעיקר ב- Office ותוכנות ERP ו- BI שונות ומשונות ואינטרנט. שום דבר ששרת טרמינל לא יכול לספק. והופ, כבר כיסינו 80% מהמשתמשים בארגון. אז נותרו לנו 20% שצריכים מעבר, למעשה מעבר למה ששרת טרמינל יכול לספק. התקנים חיצוניים מיוחדים – טלפונים חכמים, מצלמות ושאר גאדג’טים, תוכנות מיוחדות, משאבי עיבוד גבוהים יחסית, הרשאות מעבר למה שהיו יכולים לקבל בשרת הטרמינל. כל אותם המשתמשים אכן כנראה צריכים לקבל סביבת עבודה משלהם כל Windows XP\7 (או VDI אם תרצו).

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

 

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

 

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

למרבה האירוניה, VMware הם החוליה דווקא החלשה כאן, הם היחדים שלא ממש יכולים לספק את הפתרון המלא – סביבת עבודה על גבי שרת Terminal, סביבת עבודה על גבי VM עם Windows XP\7, סביבה פיזית אך עדיין מרכזית ואספקת של אפליקציות בלבד. מיקרוסופט ו- Citrix דווקא כן.

אז, האם הגולם קם על יוצרו?