כיצד לתכנן ארכיטקטורת ענן לזמינות גבוהה

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

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

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

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

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

להלן רשימה של שיטות עבודה מומלצות בענן על מנת לשפר את הזמינות:

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

· אחסון מידע בכמה העתקים במתקנים שונים המרוחקים פיזית אחד מהשני או בכמה אזורים

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

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

· הגדרת שרידות לשירותי ה-DNS - רכיב קריטי בסביבה. מומלץ להשתמש בשירות חיצוני לספק הענן.

· הגדרת תהליכים אוטומטיים לשרידות במערכת -HA / FAILOVER של כלל המערכות.

· שימוש בכלים לבדיקת שרידות המערכת באופן אוטומטי על בסיס תקופתי.

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

למידע נוסף:

https://en.wikipedia.org/wiki/Service-level_agreement

https://en.wikipedia.org/wiki/Service_level_objective