אפליקציה ארגונית ב-Compute Engine עם Oracle Exadata

Last reviewed 2025-08-18 UTC

במסמך הזה מוצגת ארכיטקטורת הפניה לאפליקציה ארגונית בעלת זמינות גבוהה שמתארחת במכונות וירטואליות (VM) של Compute Engine עם קישוריות של זמן אחזור נמוך למסדי נתונים של Oracle Cloud Infrastructure‏ (OCI) Exadata שפועלים ב- Google Cloud. המסמך הזה מיועד למומחי Cloud Architect ולאדמינים של מסדי נתונים של אורקל. ההנחה היא שאתם מכירים את Compute Engine ואת Oracle Exadata Database Service.

אם אתם משתמשים ב-Oracle Exadata או ב-Oracle Real Application Clusters ‏ (Oracle RAC) כדי להריץ מסדי נתונים של Oracle בשרתים מקומיים, אתם יכולים להעביר את האפליקציות שלכם ביעילות אל Google Cloud ולהריץ את מסדי הנתונים ב-Oracle Database@Google Cloud. ‫Oracle Database@Google Cloud הוא מוצר ב-Google Cloud Marketplace שמאפשר להריץ את Oracle Exadata Database Service ואת Oracle Autonomous Database ישירות בתוך Google Cloud.

אם אתם לא צריכים את היכולת של Oracle RAC או אם אתם צריכים גרסה של Oracle Database שאינה 19c ו-23ai, אתם יכולים להפעיל מסדי נתונים של Oracle בניהול עצמי במכונות וירטואליות של Compute Engine. למידע נוסף, ראו יישום Enterprise עם Oracle Database ב-Compute Engine.

ארכיטקטורה

התרשים הבא מציג תצוגה כללית של הארכיטקטורה:

תצוגה ברמה גבוהה של ארכיטקטורה שמשתמשת ב-Oracle Database@Google Cloud.

בתרשים שלמעלה, מאזן עומסים חיצוני מקבל בקשות ממשתמשים באפליקציה שפונה לציבור, ומפיץ את הבקשות לשרתי אינטרנט של חזית האפליקציה. שרתי האינטרנט מעבירים את בקשות המשתמשים דרך מאזן עומסים פנימי לשרתי האפליקציות. שרתי האפליקציות קוראים נתונים ממסדי נתונים ב-Oracle Database@Google Cloud וכותבים נתונים למסדי נתונים ב-Oracle Database@Google Cloud. אדמינים ושירותי OCI יכולים להתחבר למסדי הנתונים של Oracle ולבצע בהם פעולות.

התרשים הבא מציג תצוגה מפורטת של הארכיטקטורה:

תצוגה מפורטת של ארכיטקטורה שמשתמשת ב-Oracle Database@Google Cloud.

באדריכלות הזו, שכבת האינטרנט ושכבת האפליקציה פועלות במצב פעיל-פעיל במכונות וירטואליות של Compute Engine שמפוזרות על פני שני אזורים בתוך Google Cloud אזור. האפליקציה משתמשת במסדי נתונים של Oracle Exadata באותו אזור Google Cloud.

כל הרכיבים בארכיטקטורה נמצאים באותו אזור ב- Google Cloud. הארכיטקטורה הזו תואמת לארכיטיפ של פריסה אזורית. אתם יכולים להתאים את הארכיטקטורה הזו כדי ליצור טופולוגיה חזקה מפני הפסקות חשמל אזוריות באמצעות ארכיטיפ הפריסה הרב-אזורית. מידע נוסף זמין במאמר פריסה בכמה אזורים ב-Compute Engine וגם בהנחיות שבקטע מהימנות בהמשך המאמר הזה.

הארכיטקטורה שמוצגת בתרשים הקודם כוללת את הרכיבים הבאים:

רכיב מטרה
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מאזן העומסים החיצוני האזורי של האפליקציות מקבל בקשות ממשתמשים ומפיץ אותן למכונות הווירטואליות בשכבת האינטרנט.
כללי מדיניות האבטחה של Google Cloud Armor מדיניות האבטחה של Cloud Armor עוזרת להגן על מערך האפליקציות מפני איומים כמו התקפות מניעת שירות מבוזרות (DDoS) ופרצות אבטחה XSS‏ (cross-site scripting).
קבוצת מופעי מכונה מנוהלים (MIG) אזורית לשכבת האינטרנט שכבת האינטרנט של האפליקציה נפרסת במכונות וירטואליות של Compute Engine ששייכות לקבוצת מופעים מנוהלת (MIG) אזורית. ה-MIG הזה הוא הבק-אנד של מאזן העומסים החיצוני של האפליקציות. ה-MIG מכיל מכונות וירטואליות ב-Compute Engine בשני תחומים. כל מכונה וירטואלית כזו מארחת מופע עצמאי של שכבת האינטרנט של האפליקציה.
מאזן עומסים פנימי אזורי של אפליקציות (ALB) מאזן העומסים הפנימי האזורי של האפליקציות מפזר את התנועה ממכונות וירטואליות בשכבת האינטרנט למכונות וירטואליות בשכבת האפליקציה.
קבוצת MIG אזורית לשכבת האפליקציה שכבת האפליקציה, כמו אשכול של Oracle WebLogic Server, נפרסת במכונות וירטואליות של Compute Engine שמהוות חלק מקבוצת MIG אזורית. ה-MIG הזה הוא הקצה העורפי של מאזן העומסים הפנימי של האפליקציות. ה-MIG מכיל מכונות וירטואליות ב-Compute Engine בשני תחומים. כל מכונה וירטואלית מארחת מופע עצמאי של שרת האפליקציות.
רשת של ענן וירטואלי פרטי (VPC) ותת-רשת כל Google Cloud המשאבים בארכיטקטורה משתמשים ברשת VPC אחת. בהתאם לדרישות שלכם, אתם יכולים לבנות ארכיטקטורה שמשתמשת בכמה רשתות. מידע נוסף זמין במאמר האם כדאי ליצור כמה רשתות VPC.
Oracle Database@Google Cloud

שרתי האפליקציות קוראים נתונים ממסדי נתונים של Oracle וכותבים נתונים במסדי נתונים של Oracle ב-Oracle Exadata Database Service. אתם יכולים להקצות את Oracle Exadata Database Service באמצעות Oracle Database@Google Cloud, מוצר ב-Cloud Marketplace שמאפשר לכם להריץ מסדי נתונים של Oracle על חומרה שמנוהלת על ידי Oracle במרכז נתונים. Google Cloud

אתם משתמשים בממשקים כמו מסוף Google Cloud,‏ Google Cloud CLI וממשקי API כדי ליצור מופעים של Exadata Infrastructure. Google Cloud Google Cloud ‫Oracle מגדירה ומנהלת את תשתית המחשוב, האחסון והרשת הנדרשת במרכז נתונים באזור Google Cloud בציוד שמוקדש לפרויקט שלכם.

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

בתוך מכונת Exadata Infrastructure, יוצרים מכונת Exadata VM Cluster אחת או יותר. לדוגמה, אתם יכולים לבחור ליצור ולהשתמש באשכול נפרד של מכונות וירטואליות של Exadata כדי לארח את מסדי הנתונים שנדרשים לכל אחת מהיחידות העסקיות שלכם. כל Exadata VM Cluster contains one or more Oracle Linux VMs that host Oracle Database instances.

כשיוצרים Exadata VM Cluster, מציינים את הפרטים הבאים:

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

המכונות הווירטואליות באשכולות של מכונות וירטואליות ב-Exadata לא הן מכונות וירטואליות של Compute Engine.

מכונות Oracle Database אתם יוצרים ומנהלים מסדי נתונים של Oracle דרך מסוף OCI וממשקים אחרים של OCI. תוכנת Oracle Database פועלת במכונות הווירטואליות באשכול המכונות הווירטואליות של Exadata. כשיוצרים את אשכול מכונות וירטואליות של Exadata, מציינים את הגרסה של Oracle Grid Infrastructure. אתם גם בוחרים את סוג הרישיון: או להביא את הרישיונות שלכם (BYOL) או לבחור במודל שכולל רישיון.
‫OCI VCN ורשתות משנה כשיוצרים Exadata VM Cluster, נוצרת באופן אוטומטי רשת וירטואלית בענן (VCN) של OCI. ל-VCN יש תת-רשת של לקוח ותת-רשת לגיבוי עם טווחי כתובות IP שאתם מציינים. רשת המשנה של הלקוח משמשת לקישוריות מרשת ה-VPC למסדי הנתונים של Oracle. רשת המשנה של הגיבוי משמשת לשליחת גיבויים של מסד הנתונים אל OCI Object Storage.
‫Cloud Router, ‏ Partner Interconnect, ו-OCI DRG התנועה בין רשת ה-VPC לבין ה-VCN מנותבת על ידי Cloud Router שמצורף לרשת ה-VPC, ודרך שער ניתוב דינמי (DRG) שמצורף ל-VCN. התעבורה עוברת דרך חיבור עם זמן אחזור נמוך ש-Google מגדירה באמצעות Partner Interconnect.
תחום פרטי ב-Cloud DNS כשיוצרים אשכול של מכונות וירטואליות ב-Exadata, נוצר באופן אוטומטי אזור פרטי ב-Cloud DNS. כששרתי האפליקציות שלכם שולחים בקשות קריאה וכתיבה למסדי הנתונים של Oracle,‏ Cloud DNS פותר את שמות המארחים של מסד הנתונים לכתובות ה-IP המתאימות.
‫OCI Object Storage ו-OCI Service Gateway כברירת מחדל, הגיבויים של מסדי הנתונים של Oracle Exadata מאוחסנים ב-OCI Object Storage. גיבויים של מסדי נתונים מנותבים אל OCI Object Storage דרך Service Gateway.
שער Cloud NAT ציבורי הארכיטקטורה כוללת שער Cloud NAT ציבורי כדי לאפשר חיבורים יוצאים מאובטחים ממכונות וירטואליות ב-Compute Engine, שיש להן רק כתובות IP פנימיות.
‫Cloud Interconnect ו- ‫Cloud VPN כדי לחבר את הרשת המקומית לרשת ה-VPC ב- Google Cloud, אפשר להשתמש ב-Cloud Interconnect או ב-Cloud VPN. מידע על היתרונות היחסיים של כל גישה זמין במאמר בחירת מוצרים של Network Connectivity.
Cloud Monitoring אתם יכולים להשתמש ב-Cloud Monitoring כדי לעקוב אחרי ההתנהגות, המצב והביצועים של האפליקציה והמשאבים שלכם, כולל משאבי Oracle Exadata. Google Cloud אפשר גם לעקוב אחרי המשאבים במשאבי Oracle Exadata באמצעות שירות OCI Monitoring.

המוצרים שהשתמשו בהם

הארכיטקטורה הזו כוללת את המוצרים הבאים: Google Cloud

  • ‫ Compute Engine: שירות מחשוב מאובטח וניתן להתאמה אישית שמאפשר ליצור ולהריץ מכונות וירטואליות בתשתית של Google.
  • ‫ Cloud Load Balancing: חבילה של מאזני עומסים גלובליים ואזוריים בעלי ביצועים גבוהים וניתנים להתאמה.
  • ענן וירטואלי פרטי (VPC): מערכת וירטואלית שמספקת פונקציונליות של רשתות גלובליות וניתנות להרחבה עבור עומסי העבודה שלכם ב- Google Cloud . ‫VPC כולל קישור בין רשתות VPC שכנות (peering),‏ Private Service Connect, גישה לשירותים פרטיים ו-VPC משותף.
  • ‫ Google Cloud Armor: שירות אבטחת רשת שמציע כללים של חומת אש ליישומי אינטרנט (WAF) ועוזר להגן מפני מתקפות DDoS ומתקפות על אפליקציות.
  • ‫ Cloud NAT: שירות שמספק תרגום כתובות רשת בניהול Google Cloud, עם ביצועים גבוהים.
  • ‫ Cloud Monitoring: שירות שמאפשר לראות את הביצועים, הזמינות והתקינות של האפליקציות והתשתית שלכם.
  • ‫ Cloud Interconnect: שירות שמרחיב את הרשת החיצונית שלכם לרשת של Google באמצעות חיבור עם זמינות גבוהה וזמן אחזור קצר.
  • ‫ Partner Interconnect: שירות שמספק קישוריות בין הרשת המקומית שלכם לבין רשתות הענן הווירטואלי הפרטי (VPC) שלכם ורשתות אחרות, באמצעות ספק שירות נתמך.
  • ‫ Cloud VPN: שירות שמרחיב באופן מאובטח את הרשת השכנה לרשת של Google באמצעות מנהרת IPsec VPN.

ארכיטקטורת העזר הזו כוללת את מוצרי OCI הבאים:

  • שירות מסד נתונים של Exadata בתשתית ייעודית: שירות שמאפשר להריץ מופעים של Oracle Database בחומרה של Exadata שמוקדשת לכם.
  • אחסון אובייקטים: שירות לאחסון כמויות גדולות של נתונים מובנים ולא מובנים כאובייקטים.
  • ‫VCN ותת-רשתות: VCN היא רשת וירטואלית פרטית למשאבים באזור OCI. תת-רשת היא טווח רציף של כתובות IP עם VCN.
  • שער ניתוב דינמי: נתב וירטואלי לתעבורה בין VCN לבין רשתות חיצוניות.
  • שער שירות: שער שמאפשר למשאבים ב-VCN לגשת לשירותים ספציפיים של Oracle באופן פרטי.

שיקולים בתכנון

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

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

עיצוב המערכת

בקטע הזה מוסבר איך לבחור Google Cloud אזורים לפריסה ואיך לבחור Google Cloud שירותים מתאימים. Google Cloud

בחירת אזור

כשבוחרים את Google Cloud האזורים שבהם צריך לפרוס את האפליקציות, חשוב לקחת בחשבון את הגורמים והדרישות הבאים:

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

תשתית מחשוב

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

  • קונטיינרים: אתם יכולים להריץ אפליקציות בקונטיינרים באשכולות של Google Kubernetes Engine‏ (GKE). ‫GKE הוא מנוע לתזמור קונטיינרים שמבצע אוטומטית פריסה, התאמה לעומס וניהול של אפליקציות בקונטיינרים.
  • Serverless: אם אתם מעדיפים להתמקד בנתונים ובאפליקציות שלכם במקום בהגדרה ובהפעלה של משאבי תשתית, אתם יכולים להשתמש בשירותים serverless כמו Cloud Run.

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

אפשרויות אחסון

עבור המכונות הווירטואליות של Compute Engine בארכיטקטורה, אפשר להשתמש בHyperdisk או בPersistent Disk כנפחי אתחול. נפחי Hyperdisk מספקים ביצועים טובים יותר, גמישות ויעילות בהשוואה ל-Persistent Disk. עם Hyperdisk Balanced, אפשר להקצות IOPS וקצב העברת נתונים בנפרד ובאופן דינמי, וכך להתאים את עוצמת הקול למגוון רחב של עומסי עבודה.

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

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

תכנון הרשת ב-Oracle Database@Google Cloud

בוחרים עיצוב רשת שעונה על הדרישות העסקיות והטכניות שלכם. לדוגמה, אפשר להשתמש ברשת VPC אחת או בכמה רשתות VPC. מידע נוסף זמין במאמר בחירת טופולוגיות של רשת עבור Oracle Database@Google Cloud.

כשמקצים טווחי כתובות IP לרשתות המשנה של הלקוח ושל הגיבוי לשימוש באשכולות של מכונות וירטואליות ב-Exadata, צריך לקחת בחשבון את דרישות הגודל המינימלי של רשתות המשנה. מידע נוסף זמין במאמר בנושא תכנון מרחב כתובות ה-IP ב-Oracle Database@Google Cloud.

העברה של מסדי נתונים

כשמתכננים להעביר מסדי נתונים מקומיים אל Oracle Database@Google Cloud, כדאי להשתמש בכלי Database Migration Assessment (DMA) כדי להעריך את סביבת מסד הנתונים הנוכחית ולקבל המלצות לגבי הגדרות וגודל.

מידע על התהליך והכלים שבהם אפשר להשתמש כדי להעביר מסדי נתונים של Oracle אל Google Cloudזמין בOracle Migration Methods Advisor.

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

אבטחה, פרטיות ותאימות

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

הגנה מפני איומים חיצוניים

כדי להגן על האפליקציה מפני איומים כמו התקפות מניעת שירות מבוזרות (DDoS) ופרצות אבטחה XSS‏ (cross-site scripting), אפשר להשתמש במדיניות אבטחה של Google Cloud Armor. כל מדיניות היא קבוצת כללים שמציינת תנאים מסוימים שצריך לבדוק ופעולות שצריך לבצע כשהתנאים מתקיימים. לדוגמה, כלל יכול לציין שאם כתובת ה-IP של המקור של התנועה הנכנסת תואמת לכתובת IP ספציפית או לטווח CIDR, אז הגישה לתנועה הזו תיחסם. אפשר גם להחיל כללים מוגדרים מראש של חומת אש לאפליקציות אינטרנט (WAF). מידע נוסף זמין במאמר סקירה כללית של מדיניות האבטחה.

גישה חיצונית למכונות וירטואליות

בארכיטקטורת ההפניה שמתוארת במסמך הזה, למכונות הווירטואליות ב-Compute Engine לא נדרשת גישה נכנסת מהאינטרנט. לא מקצים כתובות IP חיצוניות למכונות הווירטואליות. Google Cloud משאבים שיש להם רק כתובת IP פנימית פרטית עדיין יכולים לגשת לשירותים ולממשקי Google API מסוימים באמצעות Private Service Connect או גישה פרטית ל-Google. מידע נוסף זמין במאמר אפשרויות גישה פרטיות לשירותים.

כדי לאפשר חיבורים יוצאים מאובטחים מ Google Cloud משאבים שיש להם רק כתובות IP פרטיות, כמו מכונות וירטואליות של Compute Engine בארכיטקטורת ההפניה הזו, אפשר להשתמש ב-Secure Web Proxy או ב-Cloud NAT.

לגבי תת-הרשתות שבהן נעשה שימוש במכונות וירטואליות של Exadata, ‏ Oracle ממליצה להקצות טווחי כתובות IP פרטיות.

הרשאות בחשבון שירות

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

אבטחת SSH

כדי לשפר את האבטחה של חיבורי SSH למכונות וירטואליות ב-Compute Engine בארכיטקטורה שלכם, כדאי להטמיע את Identity-Aware Proxy‏ (IAP) ואת Cloud OS Login API. ‫IAP מאפשר לכם לשלוט בגישה לרשת על סמך זהות המשתמשים ומדיניות ניהול הזהויות והרשאות הגישה (IAM). ‫Cloud OS Login API מאפשר לכם לשלוט בגישת SSH ל-Linux על סמך זהות המשתמש ומדיניות IAM. מידע נוסף על ניהול גישה לרשת זמין במאמר שיטות מומלצות לשליטה בגישה להתחברות באמצעות SSH.

הצפנת נתונים

כברירת מחדל, הנתונים שמאוחסנים ב-Hyperdisk, ב-Persistent Disk וב-Filestore מוצפנים באמצעותGoogle-owned and Google-managed encryption keys. כדי להוסיף שכבת הגנה נוספת, אתם יכולים להצפין את Google-owned and managed key באמצעות מפתחות שבבעלותכם ושאתם מנהלים ב-Cloud Key Management Service‏ (Cloud KMS). מידע נוסף מופיע במאמר בנושא הצפנת דיסקים לגבי נפחי Hyperdisk ו-Persistent Disk, ובמאמר בנושא הצפנת נתונים באמצעות מפתחות הצפנה בניהול הלקוח לגבי Filestore.

כברירת מחדל, מסדי נתונים של Exadata משתמשים ב-Transparent Data Encryption (TDE), שמאפשר להצפין מידע אישי רגיש שמאוחסן בטבלאות ובאזורי טבלאות.

אבטחת רשת

כדי לשלוט בתעבורת הרשת בין המשאבים בארכיטקטורה, צריך להגדיר מדיניות מתאימה של Cloud Next Generation Firewall (NGFW).

אבטחה ותאימות ב-Oracle Exadata

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

שיקולי אבטחה נוספים

כשמפתחים את הארכיטקטורה של עומס העבודה, כדאי להביא בחשבון את השיטות המומלצות וההמלצות לאבטחה ברמת הפלטפורמה שמפורטות בתוכנית לניהול יסודות האבטחה בארגון ובGoogle Cloud מסגרת Well-Architected: אבטחה, פרטיות ותאימות.

אמינות

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

עמידות בפני כשלים במכונות וירטואליות

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

תיקון אוטומטי של מכונות וירטואליות

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

עמידות בפני הפסקות חשמל באזור

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

  • שומרים על עותק משוכפל פסיבי (מעבר לגיבוי) של שכבת האינטרנט ושל שכבת האפליקציה באזור Google Cloud אחר.
  • יוצרים מופע של Exadata Infrastructure במצב המתנה עם Exadata VM Clusters הנדרשים באותו אזור שבו נמצא העותק הפסיבי של מחסנית האפליקציות. אפשר להשתמש ב-Oracle Data Guard לשכפול נתונים ומעבר אוטומטי לגיבוי של מסדי הנתונים של Exadata. אם האפליקציה שלכם צריכה יעד להתאוששות מאסון (RPO) נמוך יותר, אתם יכולים לגבות את מסדי הנתונים ולשחזר אותם באמצעות Oracle Autonomous Recovery Service.
  • אם מתרחשת הפסקת שירות באזור הראשי, אפשר להשתמש בעותק המשוכפל של מסד הנתונים או בגיבוי כדי לשחזר את מסד הנתונים לסביבת הייצור ולהפעיל את האפליקציה באזור המעבר לגיבוי.
  • משתמשים במדיניות ניתוב של DNS כדי לנתב תנועה למאזן עומסים חיצוני באזור היתירות.

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

‫Oracle מנהלת את התשתית ב-Oracle Database@Google Cloud. מידע על היעדים למדידת רמת השירות (SLO) של Oracle Exadata Database Service on Dedicated Infrastructure זמין במאמר יעדים למדידת רמת השירות (SLO) של שירותי Oracle PaaS ו-IaaS בענן ציבורי.

התאמה אוטומטית לעומס (autoscaling) של MIG

הארכיטקטורה שמתוארת במסמך הזה משתמשת ב-MIG אזוריים בשכבת האינטרנט ובשכבת האפליקציה. היכולת של קבוצות מנוהלות (MIG) בלי שמירת מצב להתאמה אוטומטית לעומס מבטיחה שמכונות וירטואליות ב-Compute Engine שמארחות את שכבת האינטרנט ואת שכבת האפליקציה לא יושפעו מהפסקות חשמל בתחום יחיד.

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

מגבלת הגודל של MIG

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

מיקום ה-VM

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

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

תכנון הקיבולת של מכונות וירטואליות

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

אחסון שומר מצב (Stateful)

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

קיבולת Oracle Exadata

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

עמידות הנתונים

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

כדי להבטיח את עמידות הנתונים במופעי Filestore, אפשר ליצור גיבויים ותמונות מצב של המופע או להשתמש ב-Backup and DR for Filestore and file systems.

כברירת מחדל, גיבויים של מסדי נתונים ב-Oracle Exadata Database Service on Dedicated Infrastructure מאוחסנים ב-OCI Object Storage. כדי להשיג RPO נמוך יותר, אפשר לגבות ולשחזר את מסדי הנתונים באמצעות Oracle Autonomous Recovery Service.

שיקולים נוספים בנושא מהימנות

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

הוזלת עלויות

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

סוגי מכונות וירטואליות

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

מודל הקצאת הרשאות למכונות וירטואליות

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

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

ניצול משאבים של מכונות וירטואליות

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

רישיונות למוצרי Oracle

באחריותכם להשיג רישיונות למוצרי Oracle שאתם פורסים ב-Compute Engine, ובאחריותכם לציית לתנאים ולהגבלות של רישיונות Oracle. מידע נוסף זמין במאמר Licensing Oracle Software in the Cloud Computing Environment.

רישיונות למסד נתונים של Oracle Exadata

כשיוצרים Exadata VM Cluster, אפשר להשתמש ברישיון משלכם (BYOL) או ברישיון שרכשתם כחלק מהזמנה ב-Google Cloud Marketplace ל-Oracle Database@Google Cloud.

המחיר של Oracle Database@Google Cloud כולל את עלויות הרשת של העברת נתונים בין האפליקציות שלכם לבין מסדי נתונים של Oracle Exadata שנמצאים באותו אזור.

שיקולי עלות נוספים

כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי גם לעיין בשיטות המומלצות ובהמלצות הכלליות שמופיעות במאמר Google Cloud Well-Architected Framework: הוזלת העלויות.

יעילות תפעולית

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

עדכוני הגדרות של מכונות וירטואליות

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

תמונות של Oracle Linux

אתם יכולים להשתמש בתמונות של Oracle Linux שזמינות ב-Compute Engine, או לייבא תמונות של Oracle Linux שאתם יוצרים ומתחזקים.

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

תבניות מכונה דטרמיניסטיות

אם תבניות המופעים שבהן אתם משתמשים ב-MIG כוללות סקריפטים להפעלה כדי להתקין תוכנה של צד שלישי, ודאו שהסקריפטים מציינים במפורש פרמטרים של התקנת תוכנה, כמו גרסת התוכנה. אחרת, כשה-MIG יוצר את המכונות הווירטואליות, יכול להיות שהתוכנה שמותקנת במכונות הווירטואליות לא תהיה עקבית. לדוגמה, אם תבנית של הגדרות מכונה שלכם כוללת סקריפט לטעינה בזמן ההפעלה להתקנת Apache HTTP Server 2.0 (החבילה apache2), צריך לוודא שהסקריפט מציין את הגרסה המדויקת של apache2 שצריך להתקין, כמו גרסה 2.4.53. מידע נוסף זמין במאמר תבניות דטרמיניסטיות של מכונות וירטואליות.

ניהול מסד נתונים של Oracle Exadata

‫Oracle מנהלת את שרתי מסד הנתונים הפיזיים, שרתי האחסון וציוד הרשת ב-Oracle Exadata Database Service on Dedicated Infrastructure. אפשר לנהל את מופעי התשתית של Exadata ואת אשכולות ה-VM של Exadata דרך ממשקי OCI או Google Cloud . אתם יוצרים ומנהלים מסדי נתונים דרך הממשקים של OCI. בדפי המסוף של Oracle Database@Google Cloud יש קישורים שבעזרתם אפשר לעבור ישירות לדפים הרלוונטיים במסוף OCI. Google Cloud כדי שלא תצטרכו להיכנס שוב ל-OCI, אתם יכולים להגדיר איחוד זהויות בין OCI לבין Google Cloud.

Observability for Oracle applications

כדי להטמיע יכולות Observability לעומסי עבודה של Oracle שנפרסו ב- Google Cloud, אפשר להשתמש בשירותי Google Cloud Observability או ב-Oracle Enterprise Manager. בוחרים אסטרטגיית מעקב מתאימה בהתאם לדרישות ולמגבלות. לדוגמה, אם אתם מריצים עומסי עבודה אחרים ב-Google Cloud בנוסף לעומסי עבודה של Oracle, אתם יכולים להשתמש בשירותי Google Cloud Observability כדי ליצור לוח בקרה מאוחד למעקב אחרי כל עומסי העבודה. Google Cloud

מסמכי תמיכה של Oracle

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

למידע על מדיניות התמיכה של Oracle לגבי מופעים של Oracle Database שאתם פורסים ב- Google Cloud, אפשר לעיין במאמר Oracle Database Support for Non-Oracle Public Cloud Environments (תמיכה ב-Oracle Database בסביבות ענן ציבוריות שאינן של Oracle) (מסמך מספר 2688277.1).

שיקולים תפעוליים נוספים

כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי לקחת בחשבון את השיטות המומלצות הכלליות ואת ההמלצות ליעילות תפעולית שמתוארות במאמר Google Cloud Well-Architected Framework: Operational excellence.

אופטימיזציה של הביצועים

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

ביצועי מחשוב

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

ריבוי שרשורים ב-VM

כל מעבד וירטואלי (vCPU) שמוקצה למכונה וירטואלית ב-Compute Engine מיושם כריבוי נימים (multithreading) של חומרה יחידה. כברירת מחדל, שני מעבדים וירטואליים חולקים ליבה פיזית של מעבד. ביישומים שכוללים פעולות מקבילות מאוד או שמבצעים חישובים של נקודה צפה (כמו ניתוח רצף גנטי ומידול של סיכונים פיננסיים), אפשר לשפר את הביצועים על ידי הקטנת מספר השרשורים שפועלים בכל ליבת CPU פיזית. מידע נוסף זמין במאמר בנושא הגדרת מספר השרשורים לכל ליבה.

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

ביצועי הרשת

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

תעבורת הנתונים ברשת בין מכונות וירטואליות של האפליקציה לבין רשת Oracle Exadata מנותבת דרך חיבור Partner Interconnect עם זמן אחזור נמוך שמוגדר על ידי Google.

תשתית Exadata משתמשת ב-RDMA over Converged Ethernet (RoCE) כדי ליצור רשת עם רוחב פס גבוה וזמן אחזור נמוך בין שרתי מסדי הנתונים ושרתי האחסון שלה. השרתים מחליפים נתונים ישירות בזיכרון הראשי בלי שהמעבד, המטמון או מערכת ההפעלה מעורבים.

שיקולי ביצועים נוספים

כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי לפעול לפי השיטות המומלצות וההמלצות הכלליות שמופיעות במאמר Google Cloud Well-Architected Framework: Performance optimization.

המאמרים הבאים

שותפים ביצירת התוכן

מחברים:

תורמי תוכן אחרים: