🥇 מבט נוסף על העננים. מהו ענן פרטי?

צמיחת כוח המחשוב ופיתוח טכנולוגיות וירטואליזציה של פלטפורמות x86 מחד, והתפשטות מיקור חוץ של IT מאידך גיסא, הובילו למושג מחשוב עזר (IT as a public service). למה לא לשלם עבור IT באותו אופן כמו עבור מים או חשמל - בדיוק באותה מידה ובדיוק מתי שאתה צריך את זה, ולא יותר.

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

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

"מחשוב ענן הוא טכנולוגיית עיבוד נתונים מבוזרת שבה משאבי מחשב ויכולות מסופקים למשתמש כשירות אינטרנט" ויקיפדיה
"מחשוב ענן הוא מודל לאספקת גישה נוחה לרשת למאגר משותף של משאבי מחשוב הניתנים להתאמה אישית (למשל, רשתות, שרתים, אחסון, יישומים ושירותים) לפי דרישה שניתן לספק ולהקצות במהירות עם מאמץ ניהול מינימלי או התערבות מינימלית. ספק שירות" NIST
"מחשוב ענן הוא פרדיגמה של מתן גישה ברשת למאגר ניתן להרחבה וגמיש של משאבים פיזיים או וירטואליים מבוזרים, הניתנים במצב שירות עצמי ומנוהל לפי דרישה" ISO/IEC 17788:2014. טכנולוגיית מידע - מחשוב ענן - סקירה ואוצר מילים.

לפי NIST, ישנם שלושה סוגים עיקריים של עננים:

IaaS - Infrastructure as a Service - Infrastructure as a Service
PaaS - Platform as a Service - Platform as a Service
SaaS - תוכנה כשירות

להבנה פשוטה מאוד של ההבדל, הבה נבחן את מודל הפיצה כשירות:

NIST מגדיר את התכונות ההכרחיות הבאות כדי ששירות IT ייחשב כשירות ענן.

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

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

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

יש לציין כי 5 המאפיינים הנ"ל מתאימים לענן הציבורי, אך כאשר עוברים לענן פרטי, רובם הופכים לאופציונליים.

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

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

תשובה: ענן פרטי הוא מעבר למודל אדמיניסטרטיבי חדש של אינטראקציה IT-Business, המורכב מ-80% מהאמצעים האדמיניסטרטיביים ורק 20 מטכנולוגיות.

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

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

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

ההיבט החשוב השני של האחריות החדשה של ה-CIO הוא בקרת האיכות של השירותים מהספק. כמעט כל ספקי הענן עומדים ב-SLA על פי מדדים פנימיים משלהם, דבר שיכול להשפיע בצורה עקיפה ביותר על התהליכים העסקיים של הלקוח. ובהתאם לכך, הטמעת מערכת ניטור ובקרה משלך הופך לאחד הפרויקטים המרכזיים בעת העברת מערכות IT משמעותיות לספק ענן. בהמשך לנושא ה-SLA, יש להדגיש שרובם המכריע של ספקי הענן מגבילים את האחריות לאי מילוי ה-SLA לדמי מנוי חודשיים או לחלק מהתשלום. לדוגמה, AWS ו-Azure, כאשר סף הזמינות של 95% (36 שעות בחודש) נחרג, יבצעו הנחה של 100% על דמי המנוי, ו-Yandex.Cloud - 30%.

https://yandex.ru/legal/cloud_sla_compute/

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

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

עד 2020, מחשוב הענן עבר את שיא הציפיות המנופחות והקונספט בדרך לתעלה של תסכול (לפי מחזור ההייפ של גרטנר). לפי מחקר IDC и מחקר 451 עד 80% מהלקוחות הארגוניים חוזרים ומתכננים להחזיר עומסים מהעננים למרכזי הנתונים שלהם מהסיבות הבאות:

שפר את הזמינות/ביצועים;
להפחית בהוצאות;
כדי לעמוד בדרישות IS.

מה לעשות ואיך הכל "באמת"?

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

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

מקור: www.habr.com

מבט נוסף על העננים. מהו ענן פרטי?

מה לעשות ואיך הכל "באמת"?

הוספת תגובה ביטול תגובה