ערן ישי
Cloud Systems
זמינות גבוהה בענן של אורקל

זמינות גבוהה בענן של אורקל

המלצות ליישום של זמינות גבוהה ב Oracle Cloud Infrastructure (OCI)

מאת: ערן ישי, יועץ תשתיות ענן באגף הטכנולוגיות של אורקל

 

למה לי HA עכשיו ?

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

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

איך בנוי ה OCI באופן שמאפשר תצורת HA ?

OCI בנוי ב- 3 שכבות – Availability Domains, Regions ו- Fault Domains, כפי שמודגם באיור הבא:

Region מכסה אזור גאוגרפי (כגון מערב או מזרח ארה"ב, מערב אירופה, וכדומה), ומורכב מדאטה סנטר אחד או יותר, הנקראים Availability Domains (AD). ה ADs באותו Region מרוחקים מספיק ביניהם כדי להיות מבודדים מבחינת תקלות ואירועים משביתים, אך קרובים מספיק כדי לאפשר תקשורת מהירה עם שיהוי נמוך ביותר (כמעט כמו ב LAN).

כל AD מורכב מ- 3 Fault Domains, כאשר כל (FD) Fault Domain הוא אזור פיזי נפרד בדאטה סנטר המבודד מהאחרים מבחינת תחזוקה או תקלות חומרה.

ע"י פריסה נכונה של שירותי הענן שלנו בין ADs ו/או FDs שונים ניתן להבטיח HA עבור היישומים שלנו.

כדי לאפשר DR אמיתי בין אזורים גאוגרפיים מרוחקים (למשל בין אירופה לארה"ב) – תוך עמידה ביעדי RTO ו RPO ארגוניים – נשתמש ב Regions שונים, אך על כך נדון במאמר אחר בסדרה …

בואו נסתכל עכשיו על כל אחד ממרכיבי התשתית ונבין כיצד מומלץ לבנות אותם בתצורת HA:

שרתים (Compute)

ארכיטקטורה אופיינית של אפליקציה מורכבת משכבת Web/Application ושכבת DB, וכדי ליישם אותה בתצורת HA נזדקק לשני מופעי שרתים לפחות בכל שכבה. ניתן ליישם ארכיטקורה כזו בשתי חלופות:

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

האיור הבא מדגים פריסת שירותי Web בשיטה זו:

השרתים יכולים לעבוד בתצורת Active/Standby או Active/Active – בהתאם לדרישות האפליקציה.

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

בתצורת Active/Standby ניתן להפעיל מנגנון של "כתובת צפה" כך שמופע ה Standby יקבל את אותה כתובת ה IP של מופע ה Active בעת ביצוע Failover. ב OCI ניתן לממש זאת באמצעות Reserved Public IP – כתובת ציבורית שאינה מקושרת רק לשרת בה היא פועלת ונשארת קבועה גם בעת מעבר בין שרתים.

רשת וקישוריות החוצה (Networking & Connectivity)

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

  • VPN – שימוש בתווך של רשת האינטרנט להעברה מוצפנת של המידע.
  • FastConnect – שימוש בקו תמסורת ייעודי המקושר לדאטה סנטר הארגוני.

נקודת הקצה בצד של OCI שתומכת בחיבורים אלה נקראת Dynamic Routing Gateway – DRG. ה- DRG הוא נתב לוגי שיש לו שני מופעים פיזיים, והזמינות הגבוהה היא תכונה מובנית שלו.

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

במקרה של חיבור חיצוני מסוג FastConnect – ניתן להגדיר מספר קוים ייעודיים שונים המתחברים לנתבים פיזיים שונים ב Colocation Site כדי להגיע לזמינות גבוהה.

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

אחסון (Storage)

OCI מציע 3 סוגים של שירותי אחסון: Block Storage (SAN), File Storage (NAS) ו- Object Storage. כל שירותי האחסון מספקים כברירת מחדל יתירות גבוהה של המידע המאוחסן ע"י שמירה של כל בלוק, קובץ או אובייקט בכמה עותקים. עבור שירותי ה  Block וה File העותקים נשמרים ברמה של AD בודד, בעוד שעבור ה Object העותקים נשמרים ברמת ה Region בכל ה ADs שלו – כך שהמידע שריד גם במצב ש AD שלם מושבת (אירוע נדיר כשלעצמו …).

לאור זאת – הקצאה של שטחי אחסון עבור מופעי Compute בתצורות NAS ו SAN  מבטיחה את זמינות/יתירות המידע ברמת ה AD בו המופע פועל.

כדי לאפשר שימוש במידע גם במצב בו ה AD כולו מושבת ניתן לבחור באחת משתי גישות:

  • לסנכרן את את המידע באופן רציף ל AD (או אפילו ל Region) אחר, ובאופן זה ניתן להקים מופע Compute חדש ב AD החלופי, שישתמש באותו המידע שהיה קיים ב AD המושבת. האיור הבא מדגים סינכרון של מידע בין שירותי File Storage בין שני Regions: 
  • לגבות את המידע משירותי ה NAS/SAN לשירות ה Object. מכיון ששירות זה מחזיק עותקים של המידע בכל ה ADs – ניתן להשתחזר ממנו בכל AD אחר. הגיבוי והשחזור הם חלק מובנה משירות האחסון ומבוצעים באופן אוטומטי בהתאם לרמת השירות הנבחרת, כך שקל מאד לממש גישה זו.

איזון עומסים (Load Balancing)

ב OCI ניתן להשתמש בשני סוגים של שירותי Load Balancing (LB): ציבורי ופרטי.

LB ציבורי ישמש בד"כ לאיזון עומסים ולזמינות גבוהה של שכבת ה Front end של השירות, בעוד ש LB פרטי ישמש לאיזון עומסים מול שירות פנימי כגון שירות DB.

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

האיור הבא מדגים פריסה של שירות LB ציבורי עם HA מובנה ב OCI:

בסיסי נתונים (Database)

אחד השירותים המתקדמים ביותר ב OCI הוא שירות ה Oracle DB המנוהל.

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

שרידות וזמינות גבוהה של שירות ה Oracle DB ב OCI ניתן ליישום באופנים הבאים:

  • שירות מבוסס Exadata – שירות זה מפעיל את ה DB על גבי פלטפורמת Exadata, הזהה לזו המותקנת בדאטה סנטר הארגוני. פלטפורמה זו מגיעה עם תכונות שרידות מובנות בכל הרמות: השרתים, האחסון והרשת, ואין בה נקודת כשל בודדת.
  • שירות מבוסס RAC – שירות זה מבוסס על צמד שרתי DB שמוגדרים באופן מובנה כ RAC Cluster, המשתמש בשירותי אחסון Block Storage. שירות זה מבטיח רציפות תפעולית גם במקרה של השבתה של אחד משרתי ה DB, תוך שימוש בשירותי אחסון (שגם הם פועלים בזמינות גבוהה כפי שתואר לעיל). 
  • שירות מבוסס על שני מופעים יחידים של Oracle DB עם שירות מנוהל של Data Guard ביניהם – בזכות השיהוי הנמוך בין כל שני AD (פחות מ 1ms) ניתן בהחלט (ואפילו מומלץ) להפעיל Data Guard במוד סינכרוני, כך שהמידע יהיה זהה בין שני המופעים בכל רגע נתון. השירות מאפשר ביצוע של Failover אוטומטי (או באישור המפעיל) בין העותק הפעיל לעותק ה Standby.

 

אז מה היה לנו ?

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

עיקרי ההמלצות:

  • פריסת שירותים תוך שימוש נכון במבנה ההיררכי של  ADs, Regions ו FDs שונים, ומניעה של נקודות כשל בודדות
  • שכפול נתוני אפליקציות בין ADs שונים (או אפילו Regions שונים)
  • הגנה על ה DB באמצעות טכנולוגית RAC או סנכרון נתוני DB באמצעות מנגנוני Data Guard (בעולמות של Oracle DB)
  • הכנסת אוטומציה לתהליכים של זיהוי ופתרון תקלות ולהעברת עומסי עבודה בעת תקלה למופעים פעילים (Failover)

אם אתם מעוניינים להעמיק בנושא אתם מוזמנים לעיין ב White Paper המפרט את המלצות אורקל ליישום זמינות גבוהה בענן:

https://cloud.oracle.com/iaas/whitepapers/best-practices-deploying-ha-architecture-oci.pdf

וכמובן אשמח לענות על כל שאלה שתתעורר, תוכלו למצוא אותי בלינקדאין או לשלוח לי מייל ל- eran.ishai@oracle.com.

Share on FacebookShare on LinkedInTweet about this on Twitter
זמינות גבוהה בענן של אורקל Reviewed by on . זמינות גבוהה בענן של אורקל המלצות ליישום של זמינות גבוהה ב Oracle Cloud Infrastructure (OCI) מאת: ערן ישי, יועץ תשתיות ענן באגף הטכנולוגיות של אורקל   למה זמינות גבוהה בענן של אורקל המלצות ליישום של זמינות גבוהה ב Oracle Cloud Infrastructure (OCI) מאת: ערן ישי, יועץ תשתיות ענן באגף הטכנולוגיות של אורקל   למה Rating: 0

הגיבו באמצעות פייסבוק

scroll to top
%d בלוגרים אהבו את זה: