כאשר ארגונים שוקלים מעבר תשתיות לענן ציבורי, לעיתים קיימת תחושה שגויה שהמעבר לענן בהכרח יעלה על רמת השרידות של המערכות.
במאמר זה נסקור מספר עולמות תוכן ונבדוק מה האמת ומה בגדר מיתוס שגוי בנוגע לשרידות תשתיות בענן.
היבטי מחשוב (Compute)
כברירת מחדל, כאשר אנו מקימים שרת וירטואלי חדש, אין לו כל שרידות. היה ואנו זקוקים לשרידות השירותים אשר מותקנים על גבי השרת, יש להקים לפחות שני שרתים נפרדים, כל אחד ב-Availability zone נפרד, באותו אזור גיאוגרפי (Region) ולחשוב על פתרון גישה שריד עבור השירות, החל מהפניית תעבורת תקשורת על-בסיס פניה לשירות DNS (בתצורת Round Robin) ועד מיקום השרתים מאחורי שירות Load Balancer אשר ידע לנתב את התעבורה בין השרתים, לבדוק Health של כל אחד מהשרתים לפני הפניית תעבורה וכו'.
בעיית שרידות של שרת וירטואלי לא חייבת להיגרם בשל תקלה בלתי צפויה. היא יכולה להיגרם בשל עבודת תחזוקה יזומה מצידנו בתור לקוחות התשתית (דוגמת התקנת עדכוני אבטחה המחייבים אתחול השרת) או תחזוקה יזומה מצד ספק הענן, דוגמת עדכון firmware או הפצת עדכוני אבטחה על שרת ה-Host המנהל מעליו שרתים וירטואליים של לקוחות שונים.
על-מנת שתצורת cluster או High availability תפעל בצורה תקינה, חשוב לוודא כי קיים מנגנון אשר ידע לסנכרן את הנתונים בין השרתים (לעיתים זה יקרה בשכבת האפליקציה).
כמו-כן, חשוב לוודא כי בתצורה זו, לא נשמר session state על גבי השרתים, אלא בשירות חיצוני דוגמת Redis.
פתרונות אחסון (Storage)
פתרון אחסון מסוג Object Storage (דוגמת Amazon S3, Azure Blob storage, Google Cloud Storage, Oracle Cloud Object Storage), הינו פתרון אחסון מנוהל המיועד לאחסון קבצים בתצורת online ובתצורת ארכיון.
לצורכי שרידות ספק הענן מיישם שרידות באמצעות סנכרון קבצים בין מספר Availability zones באותו ה-Region (ולעיתים אף בין Regions).
פתרון אחסון מסוג Block Storage (דוגמת Amazon EBS, Azure Disk Storage, Google Persistent Disk, Oracle Cloud Block Volumes), הינו פתרון אחסון מנוהל, המאפשר לבצע mount לכונן/ Volume.
המגבלה של שירות Block Storage היא העובדה שהוא משויך ל-Availability Zone מסוים, כך שאין סנכרון מידע בין Availability zones באותו ה-Region.
קיים פתרון אחסון מנוהל המיועד לשיתוף קבצים בפרוטוקול NFS (דוגמת Amazon EFS, Google Cloud Filestore, Oracle File Storage).
לצורכי שרידות ספק הענן מיישם שרידות באמצעות סנכרון volumes בין מספר Availability zones באותו ה-Region.
קיים פתרון אחסון מנוהל המיועד לשיתוף קבצים בפרוטוקול SMB/CIFS (דוגמת Amazon FSx for Windows File Server, Azure Files).
במקרה של Azure Files, ספק הענן דואג לשרידות הפתרון.
במקרה של Amazon FSx for Windows File Server, הלקוח בוחר האם הוא מעוניין בהטמעה עם שרידות (Multi-AZ) או ללא שרידות (Single-AZ).
היבטי תקשורת (Networking)
על-מנת ליישם שרידות לשירותים, כדאי לבחור בפתרונות Load Balance מנוהלים (דוגמת Amazon ELB, Azure Load Balancer, Google Cloud Load Balancing, Oracle Cloud Load Balancing).
מכיוון שמדובר בשירותים מנוהלים, ספק הענן דואג ל-scale (בהתאם לעומסים) ולשרידות הפתרון (חלוקה על פני מספר Availability zones).
היבטי בסיסי נתונים
קיימים פתרונות מנוהלים ל-Relational databases (דוגמת Amazon RDS, Azure SQL Database, Azure Database for MySQL, Google Cloud SQL, Oracle MySQL Database Service).
חשוב להבין כי אמנם מדובר בפתרון מנוהל הכולל בתוכו עדכוני אבטחה וגיבויים, אך כברירת מחדל הטמעת instance בודד אינה מהווה פתרון שריד.
לעיתים (בהתאם לתמיכת מנוע בסיס הנתונים) נדרש להקים cluster של שרתים בתוך הסביבה המנוהלת ולעיתים זה עניין של מודל רישוי (Premium tier) על-מנת לאפשר שרידות מקסימלית של פתרון בסיס הנתונים.
סיכום
כפי שניתן לקרוא במאמר זה, קיים מגוון רחב של עולמות תוכן בכל הנוגע לשירותים הניתנים על גבי ענן ציבורי. אם נתעלם מהמיתוסים על כך ש"הענן תמיד שריד ביחס לסביבת ה-On Premise", כדאי לקרוא את תיעוד היצרן אודות כל אחד מהשירותים, להבין את מודל התמחור ולהקים מערכות בהתאם לדרישות הארגון או לקוחות השירותים.
מידע נוסף
· AWS Well-Architected Framework - Reliability Pillar
· Microsoft Azure Well-Architected Framework - Reliability Pillar
· Google Cloud Architecture Framework – Reliability
· Oracle Cloud Infrastructure - Reliability and Resilience
המאמר נכתב ע"י אייל אסטרין, ארכיטקט ענן במרכז החישובים הבינאוניברסיטאי
המאמר המקורי מופיע בקישור
כאשר ארגונים שוקלים מעבר תשתיות לענן ציבורי, לעיתים קיימת תחושה שגויה שהמעבר לענן בהכרח יעלה על רמת השרידות של המערכות.
במאמר זה נסקור מספר עולמות תוכן ונבדוק מה האמת ומה בגדר מיתוס שגוי בנוגע לשרידות תשתיות בענן.
היבטי מחשוב (Compute)
כברירת מחדל, כאשר אנו מקימים שרת וירטואלי חדש, אין לו כל שרידות. היה ואנו זקוקים לשרידות השירותים אשר מותקנים על גבי השרת, יש להקים לפחות שני שרתים נפרדים, כל אחד ב-Availability zone נפרד, באותו אזור גיאוגרפי (Region) ולחשוב על פתרון גישה שריד עבור השירות, החל מהפניית תעבורת תקשורת על-בסיס פניה לשירות DNS (בתצורת Round Robin) ועד מיקום השרתים מאחורי שירות Load Balancer אשר ידע לנתב את התעבורה בין השרתים, לבדוק Health של כל אחד מהשרתים לפני הפניית תעבורה וכו'.
בעיית שרידות של שרת וירטואלי לא חייבת להיגרם בשל תקלה בלתי צפויה. היא יכולה להיגרם בשל עבודת תחזוקה יזומה מצידנו בתור לקוחות התשתית (דוגמת התקנת עדכוני אבטחה המחייבים אתחול השרת) או תחזוקה יזומה מצד ספק הענן, דוגמת עדכון firmware או הפצת עדכוני אבטחה על שרת ה-Host המנהל מעליו שרתים וירטואליים של לקוחות שונים.
על-מנת שתצורת cluster או High availability תפעל בצורה תקינה, חשוב לוודא כי קיים מנגנון אשר ידע לסנכרן את הנתונים בין השרתים (לעיתים זה יקרה בשכבת האפליקציה).
כמו-כן, חשוב לוודא כי בתצורה זו, לא נשמר session state על גבי השרתים, אלא בשירות חיצוני דוגמת Redis.
פתרונות אחסון (Storage)
פתרון אחסון מסוג Object Storage (דוגמת Amazon S3, Azure Blob storage, Google Cloud Storage, Oracle Cloud Object Storage), הינו פתרון אחסון מנוהל המיועד לאחסון קבצים בתצורת online ובתצורת ארכיון.
לצורכי שרידות ספק הענן מיישם שרידות באמצעות סנכרון קבצים בין מספר Availability zones באותו ה-Region (ולעיתים אף בין Regions).
פתרון אחסון מסוג Block Storage (דוגמת Amazon EBS, Azure Disk Storage, Google Persistent Disk, Oracle Cloud Block Volumes), הינו פתרון אחסון מנוהל, המאפשר לבצע mount לכונן/ Volume.
המגבלה של שירות Block Storage היא העובדה שהוא משויך ל-Availability Zone מסוים, כך שאין סנכרון מידע בין Availability zones באותו ה-Region.
קיים פתרון אחסון מנוהל המיועד לשיתוף קבצים בפרוטוקול NFS (דוגמת Amazon EFS, Google Cloud Filestore, Oracle File Storage).
לצורכי שרידות ספק הענן מיישם שרידות באמצעות סנכרון volumes בין מספר Availability zones באותו ה-Region.
קיים פתרון אחסון מנוהל המיועד לשיתוף קבצים בפרוטוקול SMB/CIFS (דוגמת Amazon FSx for Windows File Server, Azure Files).
במקרה של Azure Files, ספק הענן דואג לשרידות הפתרון.
במקרה של Amazon FSx for Windows File Server, הלקוח בוחר האם הוא מעוניין בהטמעה עם שרידות (Multi-AZ) או ללא שרידות (Single-AZ).
היבטי תקשורת (Networking)
על-מנת ליישם שרידות לשירותים, כדאי לבחור בפתרונות Load Balance מנוהלים (דוגמת Amazon ELB, Azure Load Balancer, Google Cloud Load Balancing, Oracle Cloud Load Balancing).
מכיוון שמדובר בשירותים מנוהלים, ספק הענן דואג ל-scale (בהתאם לעומסים) ולשרידות הפתרון (חלוקה על פני מספר Availability zones).
היבטי בסיסי נתונים
קיימים פתרונות מנוהלים ל-Relational databases (דוגמת Amazon RDS, Azure SQL Database, Azure Database for MySQL, Google Cloud SQL, Oracle MySQL Database Service).
חשוב להבין כי אמנם מדובר בפתרון מנוהל הכולל בתוכו עדכוני אבטחה וגיבויים, אך כברירת מחדל הטמעת instance בודד אינה מהווה פתרון שריד.
לעיתים (בהתאם לתמיכת מנוע בסיס הנתונים) נדרש להקים cluster של שרתים בתוך הסביבה המנוהלת ולעיתים זה עניין של מודל רישוי (Premium tier) על-מנת לאפשר שרידות מקסימלית של פתרון בסיס הנתונים.
סיכום
כפי שניתן לקרוא במאמר זה, קיים מגוון רחב של עולמות תוכן בכל הנוגע לשירותים הניתנים על גבי ענן ציבורי. אם נתעלם מהמיתוסים על כך ש"הענן תמיד שריד ביחס לסביבת ה-On Premise", כדאי לקרוא את תיעוד היצרן אודות כל אחד מהשירותים, להבין את מודל התמחור ולהקים מערכות בהתאם לדרישות הארגון או לקוחות השירותים.
מידע נוסף
· AWS Well-Architected Framework - Reliability Pillar
· Microsoft Azure Well-Architected Framework - Reliability Pillar
· Google Cloud Architecture Framework – Reliability
· Oracle Cloud Infrastructure - Reliability and Resilience
המאמר נכתב ע"י אייל אסטרין, ארכיטקט ענן במרכז החישובים הבינאוניברסיטאי
המאמר המקורי מופיע בקישור
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר