מה לאגף הפיתוח ול- VDI ?

טכנולוגיית ה- VDI היא טכנולוגיה תשתיתית מובהקת אשר מעניינת ארגונים רבים בתקופה האחרונה.
מסתבר שלמרות העובדה שמדובר בטכנולוגיה תשתיתית קלאסית - הרצה של סביבת משתמש מלאה בשרת והעברת תמונת המסך - ישנם מקרים שבהם אגף הפיתוח משפיע בצורה משמעותית האם להכניס טכנולוגיה כזו לארגון או לא.
זאת מכיוון שהטכנולוגיה הקרובה לטכנולוגיה זו היא טכנולוגיית ה- Terminal Server (מוצרים כמו CITRIX או Windows Terminal Server או Jetro). טכנולוגיה זו הנה בשלה יותר ועל פי המסתמן גם מסוגלת לספק יחסים משופרים יותר מבחינת מספר משתמשים סופיים לשרת.
אולם טכנולוגיה זו מחייבת לפעמים שינויים באפליקציות כך שיתאימו לסביבת ה- Terminal Server - העתק אחד של האפליקציה אשר נמצא בשימוש בין כל המשתמשים על אותו השרת.
ישנם ארגונים שבהם אגף הפיתוח עמוס כל כך עד שאינו יכול להקדיש את התשומות לביצוע השינוי באפליקציות (שינוי שלאחריהם מתחייבות בדיקות קפדניות) ובמקרים אלו אין ברירה לגוף התשתיות אלא לפנות לטכנולוגיית ה- VDI למרות שבפועל היה מעדיף לפנות לטכנולוגית ה- Terminal Server הבשלה יותר.
כלומר אגף הפיתוח "מחליט" בסופו של דבר איזה טכנולוגיה תשתיתית תיושם.

סיכום מפגש שולחן עגול בנושא תפעול תחנות קצה

לפני מספר שבועות קיימנו במשרדי STKI אשר בבני ציון מפגש שולחן עגול בנושא ניהול ותפעול תחנות קצה עם דגש על טכנולוגיות מתקדמות שמתפתחות בתחום. המפגש היה מעניין ופורה במיוחד. להלן סיכום קצר שלו.
הסיכום המלא זמין ללקוחות STKI בתוך docsNtalks בלינק הבא.
1. תחום תחנות הקצה הוא אחד התחומים ה"נראים" ביותר בארגון. המטרה הראשית של מנהלי התשתיות היא להוריד את מספר המקרים שבהם נדרש טיפול בשטח של תקלה. מטרות נוספות הן העלאת הזמינות, חסכון כללי בעלויות (לדוגמה שימוש ב- PC אחד במקום בכמה) ואף חסכון בחשמל.
2. הטכנולוגיה הבשלה בתחום היא terminal services כאשר המוצר המוביל הוא CITRIX. לקוחות משתמשים בטכנולוגיה זו בצורה משמעותית.
3. מימוש הטכנולוגיה של terminal services אפשרי הן באמצעות thin clients והן באמצעות PC ישנים ונעולים. שימוש ב- PC נותן גמישות מסוימת אך פחות חסכוני מבחינת חשמל, מקום וגם האמינות פחות טובה מ- thin clients.
4. לקוחות מאוד מתעניינים בטכנולוגיות חדשות – הן ב – VDI (נהוג לקרוא לתחום זה HVD – hosted virtual desktops) , הן ב- application virtualization (מוצרים כ- softgrid או thinapp של VMWARE) ואף ב- VSE – Virtual Software Appliance.
5. טכנולוגיות אלו הנן בתחילת דרכן כאשר השימוש המומלץ הוא ברמה של נישה ספציפית – עוד לא לרמה של מימוש כלל ארגוני.
6. כדוגמה, לקוח בבחינה של פתרון VDI\HVD הגיע ל – sizing של 24 PC וירטואליים על שרת 2 מעבדים QUAD עם 48M זיכרון ראשי כאשר שטח הדיסק לכל PC וירטואלי הוא נפרד וקבוע (משהו כמו 40G). כלומר רכיב האחסון הוא מאוד משמעותי.
7. כאשר מדברים על פתרון של VDI\HVD יש לשים לב לדרישות רישוי כאשר על פי מיקרוסופט יש לבצע רכישה של רישוי VECD – Vista Enterprise Centralized Desktop. על פי המידע שנמצא ברשותי כרגע רישוי זה אינו חלק מחבילה (כמו desktop pro) ולכן יש לרכוש אותו בנפרד – שימו לב לכניסה שלי בבלוג http://pinicohenstki.blogspot.com/2009/05/vdi.html.
8. בתחום תחנות הקצה מתפתחות גם טכנולוגיות של Graphic Acceleration אשר אמורות לבצע שיפור הן בתוצאה שמתקבלת ברמה הגרפית אך גם במספר המשתמשים שניתן להעמיס כל שרת (על ידי ביצוע חלק מהפקודות הגרפיות ב- thin client ולא בשרת עצמו). שחקן בתחום זה הנו לדוגמה http://www.teradici.com/ שפיתח תחום להרחקת מסך\מקלדת\פריפראלים מהמחשב באמצעות chip חומרה (או גם תוכנה). תחום זה מתפתח ביותר ועדיין אינו בשל.
9. לקוחות דיברו על כך שלצרכים משרדיים רגילים ניתן כיום לרכוש מחשבים משומשים במחירים אטרקטיביים ביותר (כולל אחריות ל-3 שנים).

המלצות לשימוש חלקי בטכנולוגיית SBC

להלו מקרים בהם רצוי לשקול את סביבת ה- SBC כך תיתן פתרון חלקי לסביבת המשתמש כלומר חלק מהאפליקציות יעבדו בתצורה של SBC וחלק מהאפליקציות יעבדו לוקלית (במידה והאפליקציה המדוברת הנה האפליקציה היחידה או החשובה ביותר ניתן לעבור לסביבת SBC מלאה) :
גישה לאינטרנט (הרצה של דפדפן) מתוך סביבת הארגון המאובטחת באמצעות טכנולוגיית SBC. מקובל בארגונים שאינם המאובטחים ביותר אך בכל זאת מחזיקים רשת שאינה פתוחה לאינטרנט (דוגמה - בנקים).
במקרה יש אפליקציה שאינה חלק מה- image שקיים בארגון, ולא רוצים לבנות image חדש, אזי נגשים לאפליקציה זו באמצעות טכנולוגיית SBC.
במקרה וישנה אפליקציה שהיא מסובכת להתקנה, ישנם בה הרבה שינויים, או צריכה מחשב חזק או מתנגשת עם אפליקציות אחרות, אזי הגישה לאפליקציה זו באמצעות SBC. דוגמה פופולארית הינה SAP – לקוחות רבים מרצים את ה- client של SAP בצורה כזו (כ- 40% ויותר מהלקוחות הגדולים בישראל). מקרה דומה אחר בו ישנה אפליקציה מסובכת להתקנה אשר מספר המשתמשים בה מועט.
כנ"ל לגבי אפליקציה שבה לא משתמשים הרבה והתמחור הוא לפי concurrent user - זה מאפשר לחסוך רישיונות והתקנה.
במקרה וישנה אפליקציה שצריכה תעבורת תקשורת מאוד חזקה לשרת, תקשורת שאינה קיימת או קיבולת כזו שמפריעה למשתמשים אחרים – SBC מהווה פתרון טוב.
במקרה וישנה אפליקציה שאינה רצה בסביבת Windows אלא לדוגמה רצה בסביבת Unix ופתרון ה- SBC מהווה כאמולציה. ולהיפך – אם רוצים מתוך סביבה שאינה Windows להריצה אפליקציית Windows.
קונסולידציה של אפליקציה (או של סביבת מחשוב שלמה). מדובר על מצב בו ארגון מבוזר העביר אפליקציה ספציפת (או את כל האפליקציות כלומר את כל סביבת המחשוב) מהסניפים. תמיכה של אפליקציה שמבוזרת לסניפים הנה קשה ביותר (עדכוני תוכנה לתחנות העבודה ולשרתים, גיבוי, טיפול בתקלות וכד'). ישנם מקרים בהם מתבצעת קונסולידציה של האפליקציה או סביבת המחשוב כולה למרכז באמצעות טכנולוגיה של SBC.

לגבי אפליקציות סטנדרטיות (דוגמה OFFICE ), אשר מופצות בצורה קלה יחסית לא ברור אם ישנו חסכון כלכלי בשימוש ב- SBC.