עצות לבניית תשתיתי ענן

המודלים של הענן היום מאפשרים את כל קשת האפשרויות לצרוך IT בצורה מושלמת לדרישה הקיימת כיום בתצורה המסורתית והנהוגה על כל היתרונות ובעת ובעונה אחת לחסוך מעצם הארגון את החסרונות של מערכות IT כנכס (IT CAPITAL). 

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

השיטות הללו מאפשרות לתשתיות אלו לפעול מתוך הארגון (הגדול בד"כ) או מחוץ לארגונים קטנים כמו גם ארגונים גדולים שאינם מעוניינים בהקמה תחזוקה וניהול של מרכזי נתונים אלה בעצמם, שיטות הענן מאפשרות להגדיל בחופשיות או לצמצם ללא חשש את משאבי הIT בהתאם לגודל השקעה או הצורך ו\או הפתרון המוצע כשלבסוף חווית המשתמש נשארת בעינה אותה החוויה. 

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

מדוע הענן מצליח לחדור ומהר 

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

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

השוואת מודלים של תשתיות הענן 

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

ענן ציבורי 

הענן הציבורי הוא ענן המאפשר לכלל הלקוחות לעשות שימוש ולצרוך את תשתיות המחשוב מתוך POOL מרכזי בספק, כאן גם יעשו ספקי שירות מאמץ לרכוש תשתיות וגם POOL-ים ולמכור לרמה נוספת תשתיות הללו כשהענן הציבורי בנוי במודל של לשלם לפי הגדילה PAY AS YOU GROW ומאפשר גדילה והקטנה לפי דרישה ייכלל בקטגוריה של עננים ציבוריים, בענן הציבורי המחיר לשימוש בתשתית משותפת לכאורה זו נמוך יותר ואינו מאפשר התאמות עדינות או צרכים מיוחדים ללקוחות שלו . וזה הבסיס למחיר הנמוך יחסית לעננים פרטיים. 

הענן הפרטי 

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

הענן המשולב (היברידי) 

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

היבט הפיתוח FRAMEWORK 

יש להתייחס אל הענן הפרטי כאל כל סביבת חומרה ותוכנה לכל דבר ועניין וככאלה יש לקחת בחשבון את רמת הפתיחות לשינויים והתאמות חודרניות הן ספקטי טכנולוגיות הענן יאפשרו הן בשימוש ב- API והן בדרכים אחרות גישה אל מנגנונים מרכזיים והפעלתן מתוך סביבות שכינות ואוטומציות לפי דרישת ניהול הענן, ענן המחשוב מציע סביבה אחודה לנושא זה. פלטפורמות כגון VMWARE \ XEN \ RED HAT מאפשרות סט כלים לשינויים והתאמות בידי המשתמש או מנהלי מרכדי הנתונים להתאמות מכסימליות לצרכים הפרטניים ביותר. 

דרישות להקמת ענן תשתיות אלסטי 

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

1) הטרוגניות 

בבניית הענן אל למתכנן לחשוב על הטכנולוגיות מרכזי הנתונים החדשות ביותר אלא לתמוך בטווח הרחב ביותר של מערכות ומרכזי נתונים והעניין נעוץ בעיקר בשל העובדה שלמרות שרוב הטכנולוגיות והפתרונות נכתבו לסביבות גנריות כמו WINDOWS\X86 CENTOS או דומים עדיין קיימים הרבה פתרונות שנתפרו לפי דרישה על בסיס טכנולוגיות פרטניות ליצרן מסיים 
מי שלא ייקח בחשבון רוחב יריעה ותמיכה בתוך הענן למגוון הרחב ביותר של פלטפורמות וטכנולוגיות תשתית תוכנה עלול למצוא עצמו ללא פתרון אמיתי לבעיה נוקבת 

2) ניהול שירות 

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

3) ניהול עומסים וניהול משאבים 

כדי לעמוד בהסכם שירות נתון (SLA) על מערכת הקצאת המשאבים להיות SERVICE AWARE וגם RESOURCE AWARE שתי הערנויות הללו מאפשרים לפשט את שכבות השירות והמשאבים עד לרמה שאפשרי לקבל עליהם משוב חוזר מידי ביחס לרמת השירות. ז"א שכדי לתת את רמת השירות כלי הניהול חייבים לדבר עם מערכת ההקצאה ולאפשר את הפשטות הנדרשת שבלחייב לקוח על מה שצרך או לזכות אל מה שלא קיבל. 

4) אמינות , זמינות, המשכיות ואבטחת מידע 

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

5) התאמה לכלי ניהול של מרכזי נתונים קיימים 

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

6) דוחות 

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

7) ממשקי משתמש וממשקי אדמין 

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

רמת משתמש - ממשק SELF SERVICE. מאחר שהפתרון מכיל עננים פרטיים ואת עקרון ה- PAY AS YOU GROW חובה על נותן השירות הן כדי למכסם רווחיו והן כדי לתת את ההצעה העסקית לפרטיה לאפשר ממשק ניהול עצמי למנהל הענן מהצד לקוח - בדיקת גודלך האחסון הקטנה והגדלה הוספת משאבים במסגרת ה- POOL המוצע, בדיקת חיובים וכו - כל אלה שכבת ההפשטה אמורה לתת כחלק מהפתרון הכולל. 

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