‫Oracle E-Business Suite עם Oracle Database ב-Compute Engine

Last reviewed 2026-02-09 UTC

במאמר הזה מפורטות ארכיטקטורות לדוגמה שיעזרו לכם לבנות את התשתית להרצת אפליקציות של Oracle E‑Business Suite עם Oracle Database במכונות וירטואליות של Compute Engine ב- Google Cloud. ‫Oracle E‑Business Suite היא חבילה של אפליקציות ארגוניות לפונקציות עסקיות כמו פיננסים, משאבי אנוש, שרשרת אספקה ויחסי לקוחות.

המסמך הזה מיועד למומחי Cloud Architect ולאדמינים של מסדי נתונים של Oracle ושל אפליקציות Oracle E‑Business Suite. המסמך מניח שהצוות שלכם מכיר את Oracle Database ואת סטאק התוכנות והארכיטקטורה של Oracle E‑Business Suite.

אם אתם צריכים להשתמש ב-Oracle Exadata או ב-Oracle Real Application Clusters ‏ (Oracle RAC), אתם יכולים להעביר את האפליקציות שלכם אל Google Cloud ולהריץ את מסדי הנתונים שלכם ב-Oracle Database@Google Cloud. למידע נוסף, ראו Oracle E‑Business Suite ב-Compute Engine עם Oracle Exadata.

ארכיטקטורה

בהתאם לתרחיש השימוש ולדרישות הזמינות וההתאוששות מאסון (DR), אתם יכולים לבחור אחד מ Google Cloud ארכיטיפים של פריסה Google Cloudכדי להריץ אפליקציות של Oracle E‑Business Suite ב-Google Cloud:

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

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

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

ארכיטקטורה אזורית

בתרשים הבא מוצגת ארכיטקטורה של אפליקציות Oracle E‑Business Suite עם Oracle Database שפועל באזור אחד בתוךGoogle Cloud אזור. הארכיטקטורה הזו תואמת לארכיטיפ של פריסה אזורית.

ארכיטקטורה של אפליקציות Oracle E-Business Suite פועלת בתחום אחד באזור Google Cloud .

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

רכיב תיאור
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מאזן העומסים מפזר את בקשות המשתמשים לאפליקציות של Oracle E‑Business Suite.
מדיניות האבטחה של Google Cloud Armor מדיניות האבטחה של Cloud Armor עוזרת להגן על האפליקציות מפני איומים כמו התקפות DDoS וXSS.
Oracle E‑Business Suite (BYOL)

רכיבי שכבת האפליקציה של Oracle E‑Business Suite (‏Oracle HTTP Server,‏ Oracle WebLogic Server ושרת לעיבוד מקביל) פועלים במכונות וירטואליות של Compute Engine. כל מכונה וירטואלית מארחת מופע עצמאי של שכבת האפליקציה. דיסק האתחול של כל מכונה וירטואלית הוא נפח Google Cloud Hyperdisk.

אתם מביאים את הרישיונות שלכם (BYOL) ל-Oracle E‑Business Suite, ומנהלים את המכונות הווירטואליות ואת האפליקציות.
קובצי הפעלה של אפליקציות ונתונים מופע אזורי של Filestore מכיל את הקבצים הבינאריים והנתונים של האפליקציה. מופע Filestore מותקן במכונות וירטואליות של Compute Engine שמארחות את הרכיבים של שכבת האפליקציה.
‫Oracle Database (BYOL)

אפליקציות Oracle E‑Business Suite משתמשות במופע של Oracle Database שנפרס במכונה וירטואלית ב-Compute Engine. דיסקי האתחול והנתונים של ה-VM הם נפחי Hyperdisk.

אתם מביאים את הרישיון שלכם (BYOL) למופע של Oracle Database ומנהלים את המכונה הווירטואלית ואת מסד הנתונים.
גיבויים של אפליקציות ומסדי נתונים גיבויים של נתוני האפליקציה ומסד הנתונים נוצרים, מאוחסנים ומנוהלים באמצעות שירות Backup and DR.
רשת של ענן וירטואלי פרטי (VPC) ורשתות משנה

כל המשאבים בארכיטקטורה משתמשים ברשת VPC אחת. Google Cloud המכונות הווירטואליות שמארחות את שכבת האפליקציה ואת מסד הנתונים משתמשות ברשתות משנה נפרדות.

בהתאם לדרישות שלכם, אתם יכולים לבנות ארכיטקטורה שמשתמשת בכמה רשתות VPC. מידע נוסף זמין במאמר האם כדאי ליצור כמה רשתות VPC.
שער NAT ציבורי הארכיטקטורה כוללת שער Cloud NAT ציבורי לחיבורים יוצאים מאובטחים ממכונות וירטואליות של Compute Engine, שיש להן רק כתובות IP פנימיות. לדוגמה, המכונות הווירטואליות יכולות לגשת לשרת Oracle Linux Yum כדי להוריד חבילות של מערכת ההפעלה.
‫Cloud Interconnect ו-Cloud VPN כדי לחבר את הרשת המקומית לרשת ה-VPC ב-Google Cloud, אפשר להשתמש ב-Cloud Interconnect או ב-Cloud VPN. מידע על היתרונות היחסיים של כל גישה זמין במאמר בחירת מוצר של Network Connectivity.

ארכיטקטורה אזורית עם DMZ

התרשים הבא מציג ארכיטקטורה עם שתי שכבות אפליקציה עצמאיות של Oracle E‑Business Suite שפועלות במכונות וירטואליות של Compute Engine. אחת משכבות האפליקציה היא אזור מפורז (DMZ), שמשמש משתמשים חיצוניים של אפליקציות Oracle E-Business Suite. השכבה השנייה מיועדת למשתמשים פנימיים. שתי שכבות האפליקציה פועלות בתחום אחד באזור Google Cloud ומשתמשות במופע אחד של Oracle Database. בדומה לארכיטקטורה שמוצגת בקטע הקודם, הארכיטקטורה הזו תואמת לארכיטיפ של פריסה אזורית.

ארכיטקטורה של אפליקציות Oracle E-Business Suite פועלת באזור יחיד עם DMZ באזור Google Cloud .

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

רכיב תיאור
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מאזן העומסים החיצוני מפזר בקשות ממשתמשים חיצוניים לשכבת האפליקציה שפונה לחוץ.
מאזן עומסים פנימי אזורי של אפליקציות (ALB) מאזן העומסים הפנימי מפזר בקשות ממשתמשים פנימיים לשכבת אפליקציה פנימית.
מדיניות אבטחה של Cloud Armor מדיניות האבטחה של Cloud Armor עוזרת להגן על האפליקציות מפני איומים חיצוניים כמו התקפות DDoS ו-XSS.
Oracle E‑Business Suite (BYOL)

רכיבי שכבת האפליקציה של Oracle E‑Business Suite (‏Oracle HTTP Server,‏ Oracle WebLogic Server ושרת לעיבוד מקביל) פועלים במכונות וירטואליות של Compute Engine. כל מכונה וירטואלית מארחת מופע עצמאי של שכבת האפליקציה. האפליקציות הפנימיות והחיצוניות מוגשות ממערכות שונות של מכונות וירטואליות. דיסק האתחול של כל מכונה וירטואלית הוא נפח Hyperdisk.

אתם מביאים את הרישיונות שלכם (BYOL) ל-Oracle E‑Business Suite, ומנהלים את המכונות הווירטואליות ואת האפליקציות.
קובצי הפעלה של אפליקציות ונתונים מופע אזורי של Filestore מכיל את הקבצים הבינאריים והנתונים של האפליקציה. מוסיפים את מופע Filestore למכונות הווירטואליות של Compute Engine שמארחות את הרכיבים של שכבת האפליקציה.
‫Oracle Database (BYOL)

אפליקציות Oracle E‑Business Suite משתמשות במופע של Oracle Database שנפרס במכונה וירטואלית ב-Compute Engine. דיסקי האתחול והנתונים של ה-VM הם נפחי Hyperdisk.

אתם מביאים את הרישיון שלכם (BYOL) למופע של Oracle Database ומנהלים את המכונה הווירטואלית ואת מסד הנתונים.
גיבויים של אפליקציות ומסדי נתונים גיבויים של נתוני האפליקציה ומסד הנתונים נוצרים, מאוחסנים ומנוהלים באמצעות Backup and DR.
רשת של ענן וירטואלי פרטי (VPC) ורשתות משנה

כל המשאבים בארכיטקטורה משתמשים ברשת VPC אחת. Google Cloud המכונות הווירטואליות שמארחות את שכבת האפליקציה ואת מסד הנתונים משתמשות ברשתות משנה נפרדות.

בהתאם לדרישות שלכם, אתם יכולים לבנות ארכיטקטורה שמשתמשת בכמה רשתות VPC. מידע נוסף זמין במאמר האם כדאי ליצור כמה רשתות VPC.
שער NAT ציבורי הארכיטקטורה כוללת שער Cloud NAT ציבורי לחיבורים יוצאים מאובטחים ממכונות וירטואליות ב-Compute Engine, שיש להן רק כתובות IP פנימיות. לדוגמה, המכונות הווירטואליות יכולות לגשת לשרת Oracle Linux Yum כדי להוריד חבילות של מערכת ההפעלה.
‫Cloud Interconnect ו-Cloud VPN כדי לחבר את הרשת המקומית לרשת ה-VPC ב-Google Cloud, אפשר להשתמש ב-Cloud Interconnect או ב-Cloud VPN. אדמינים ומשתמשים פנימיים באפליקציה משתמשים בחיבורים האלה כדי לגשת למשאבים ולאפליקציות, בהתאמה. מידע על היתרונות היחסיים של כל גישה זמין במאמר בחירת מוצרים של Network Connectivity.

אדריכלות אזורית

בתרשים הבא מוצגת ארכיטקטורה שבה אפליקציות של Oracle E‑Business Suite פועלות במצב פעיל-פעיל במכונות וירטואליות של Compute Engine שמפוזרות על פני שני תחומים (zones) בתוך אזור Google Cloud . שני פריסות האפליקציות משתמשות במופע ראשי של Oracle Database שפועל במכונה וירטואלית באחד מהאזורים. ‫Oracle Data Guard מנהל את השכפול והמעבר האוטומטי של מסד הנתונים למופע של מסד נתונים של Oracle במצב המתנה באזור השני. הארכיטקטורה הזו מבוססת על ארכיטיפ של פריסה אזורית.

ארכיטקטורה של אפליקציות Oracle E-Business Suite פועלת בשני אזורים באזור Google Cloud .

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

רכיב תיאור
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מאזן העומסים מחלק את בקשות המשתמשים לאפליקציות של Oracle E‑Business Suite.
מדיניות אבטחה של Cloud Armor מדיניות האבטחה של Cloud Armor עוזרת להגן על האפליקציות מפני איומים כמו התקפות DDoS מבוזרות ו-XSS.
Oracle E‑Business Suite (BYOL)

רכיבי שכבת האפליקציה של Oracle E‑Business Suite (Oracle HTTP Server,‏ Oracle WebLogic Server ושרת לעיבוד מקביל) פועלים במכונות וירטואליות ב-Compute Engine שמופצות בשני אזורים. כל מכונה וירטואלית מארחת מופע עצמאי של שכבת האפליקציה. דיסק האתחול של כל מכונה וירטואלית הוא נפח Hyperdisk.

אתם מביאים את הרישיונות שלכם (BYOL) ל-Oracle E‑Business Suite, ומנהלים את המכונות הווירטואליות ואת האפליקציות.
קובצי הפעלה של אפליקציות ונתונים מופע אזורי של Filestore מכיל את הקבצים הבינאריים והנתונים של האפליקציה. מופע Filestore מותקן בכל המכונות הווירטואליות של Compute Engine שמארחות את הרכיבים של שכבת האפליקציה בשני התחומים.
‫Oracle Database (BYOL)

אפליקציות Oracle E‑Business Suite משתמשות בצמד ראשי-המתנה של מופעי Oracle Database שנפרסים במכונות וירטואליות של Compute Engine באזורים נפרדים. דיסקי האתחול והנתונים של ה-VM הם נפחי Hyperdisk.

‫Oracle Data Guard מנהל את השכפול והמעבר האוטומטי של מסד הנתונים מהמופע הראשי למופע ההמתנה.

אתם מביאים את הרישיונות שלכם (BYOL) למופעים של Oracle Database ומנהלים את המכונות הווירטואליות ואת מסדי הנתונים.
גיבויים של אפליקציות ומסדי נתונים גיבויים של נתוני האפליקציה ומסד הנתונים נוצרים, מאוחסנים ומנוהלים באמצעות Backup and DR.
רשת של ענן וירטואלי פרטי (VPC) ורשתות משנה

כל המשאבים בארכיטקטורה משתמשים ברשת VPC אחת. Google Cloud המכונות הווירטואליות שמארחות את שכבת האפליקציה ואת מסד הנתונים משתמשות ברשתות משנה נפרדות.

בהתאם לדרישות שלכם, אתם יכולים לבנות ארכיטקטורה שמשתמשת בכמה רשתות VPC. מידע נוסף זמין במאמר האם כדאי ליצור כמה רשתות VPC.
שער NAT ציבורי הארכיטקטורה כוללת שער Cloud NAT ציבורי לחיבורים יוצאים מאובטחים ממכונות וירטואליות ב-Compute Engine, שיש להן רק כתובות IP פנימיות. לדוגמה, המכונות הווירטואליות יכולות לגשת לשרת Oracle Linux Yum כדי להוריד חבילות של מערכת ההפעלה.
‫Cloud Interconnect ו-Cloud VPN כדי לחבר את הרשת המקומית לרשת ה-VPC ב-Google Cloud, אפשר להשתמש ב-Cloud Interconnect או ב-Cloud VPN. מידע על היתרונות היחסיים של כל גישה זמין במאמר בחירת מוצר של Network Connectivity.

ארכיטקטורה פעילה-סבילה (DR) במספר אזורים

בתרשים הבא מוצגת ארכיטקטורה שבה אפליקציות של Oracle E‑Business Suite פועלות במצב פעיל-פעיל במכונות וירטואליות של Compute Engine שמפוזרות על פני שני תחומים (zones) בתוך אזור Google Cloud . שני פריסות האפליקציות משתמשות במופע ראשי של Oracle Database שפועל במכונה וירטואלית באחד מהאזורים. ‫Oracle Data Guard מנהל את השכפול והמעבר לגיבוי בעת כשל של מסד הנתונים למופע של Oracle Database במצב המתנה באזור השני. הארכיטקטורה כוללת העתק בקנה מידה קטן יותר של מחסנית האפליקציות באזור מרוחק (מעבר לגיבוי במקרה של כשל) לצורך DR. כמו הארכיטקטורה בקטע הקודם, הארכיטקטורה הזו מבוססת על ארכיטיפ של פריסה אזורית.

ארכיטקטורה של אפליקציות Oracle E-Business Suite פועלת בשני אזורים באזור Google Cloud , עם העתק באזור מרוחק לצורך התאוששות מאסון (DR).

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

רכיב תיאור
מדיניות ניתוב למעבר אוטומטי לגיבוי (failover) של DNS אזור ציבורי של Cloud DNS שמוגדר עם מדיניות ניתוב ליתירות כשל מנתב בקשות של משתמשים למאזן העומסים באזור שמשרת את הבקשות.
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מאזן העומסים מחלק את בקשות המשתמשים לאפליקציות של Oracle E‑Business Suite.
מדיניות אבטחה של Cloud Armor מדיניות האבטחה של Cloud Armor עוזרת להגן על האפליקציות מפני איומים כמו התקפות DDoS מבוזרות ו-XSS.
Oracle E‑Business Suite (BYOL)

רכיבי שכבת האפליקציה של Oracle E‑Business Suite (Oracle HTTP Server,‏ Oracle WebLogic Server ושרת לעיבוד מקביל) פועלים במכונות וירטואליות של Compute Engine שמפוזרות בשני אזורים באזור הראשי. כל מכונה וירטואלית מארחת מופע עצמאי של שכבת האפליקציה. דיסק האתחול של כל מכונה וירטואלית הוא נפח Hyperdisk.

אתם מביאים את הרישיונות שלכם (BYOL) ל-Oracle E‑Business Suite, ומנהלים את המכונות הווירטואליות ואת האפליקציות.
קובצי הפעלה של אפליקציות ונתונים

מופע אזורי של Filestore באזור הראשי מכיל את הקבצים הבינאריים של האפליקציה ואת הנתונים. מופע Filestore מותקן בכל המכונות הווירטואליות של Compute Engine שמארחות את הרכיבים של שכבת האפליקציה בשני התחומים באזור הראשי. המכונה של Filestore משוכפלת לאזור המעבר לגיבוי.
‫Oracle Database (BYOL)

אפליקציות Oracle E‑Business Suite משתמשות בצמד ראשי-המתנה של מופעי Oracle Database שנפרסים במכונות וירטואליות של Compute Engine באזורים נפרדים באזור הראשי. דיסקי האתחול והנתונים של ה-VM הם נפחי Hyperdisk.

‫Oracle Data Guard מנהל את השכפול והמעבר האוטומטי של מסד הנתונים מהמופע הראשי למופע ההמתנה.

אתם מביאים את הרישיונות שלכם (BYOL) למופעים של Oracle Database ומנהלים את המכונות הווירטואליות ואת מסדי הנתונים.
גיבויים של אפליקציות ומסדי נתונים גיבויים של נתוני האפליקציה ומסד הנתונים נוצרים, מאוחסנים ומנוהלים באמצעות Backup and DR.
רשת של ענן וירטואלי פרטי (VPC) ורשתות משנה

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

בהתאם לדרישות שלכם, אתם יכולים לבנות ארכיטקטורה שמשתמשת בכמה רשתות VPC. מידע נוסף זמין במאמר האם כדאי ליצור כמה רשתות VPC.
שער NAT ציבורי הארכיטקטורה כוללת שער Cloud NAT ציבורי בכל אזור לחיבורים יוצאים מאובטחים ממכונות וירטואליות של Compute Engine, שיש להן רק כתובות IP פנימיות. לדוגמה, המכונות הווירטואליות יכולות לגשת לשרת Oracle Linux Yum כדי להוריד חבילות של מערכת ההפעלה.
‫Cloud Interconnect ו-Cloud VPN כדי לחבר את הרשת המקומית לרשת ה-VPC ב-Google Cloud, אפשר להשתמש ב-Cloud Interconnect או ב-Cloud VPN. מידע על היתרונות היחסיים של כל גישה זמין במאמר בחירת מוצר של Network Connectivity.

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

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

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

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

  • ‫Oracle E-Business Suite: חבילת אפליקציות לפעילות עסקית כמו פיננסים, משאבי אנוש ושרשרת אספקה.
  • מסד הנתונים של Oracle: מערכת לניהול מסד נתונים יחסי (RDBMS) שמרחיבה את המודל היחסי למודל יחסי של אובייקטים.
  • ‫Oracle Data Guard: חבילת שירותים ליצירה, לתחזוקה, לניהול ולמעקב של מסד נתונים אחד או יותר במצב המתנה.

באחריותכם להשיג רישיונות למוצרי Oracle שאתם פורסים ב- Google Cloud, ובאחריותכם לציית לתנאים ולהגבלות של רישיונות Oracle.

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

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

Google Cloud

עיצוב המערכת

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

בחירת אזור

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

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

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

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

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

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

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

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

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

עיצוב רשת

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

ניתוח נתונים

לניתוחים מתקדמים, אתם יכולים להשתמש ב-Google Cloud Cortex Framework כדי להטמיע נתונים מהאפליקציות של Oracle E‑Business Suite ב-BigQuery. מידע נוסף זמין במאמר בנושא Cortex Framework: שילוב עם Oracle E‑Business Suite.

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

בקטע הזה מתוארים גורמים שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורות ההפניה האלה כדי לתכנן טופולוגיה ב- 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.

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

במקום להשתמש בחשבונות השירות שמוגדרים כברירת מחדל במכונות הווירטואליות של 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 וב-Filestore מוצפנים באמצעותGoogle-owned and Google-managed encryption keys. כדי להוסיף שכבת הגנה נוספת, אתם יכולים להצפין את Google-owned and managed key באמצעות מפתחות שבבעלותכם ושאתם מנהלים ב-Cloud Key Management Service‏ (Cloud KMS). מידע נוסף זמין במאמרים בנושא הצפנת דיסקים לנפחי אחסון של Hyperdisk והצפנת נתונים באמצעות מפתחות הצפנה בניהול הלקוח ל-Filestore.

אבטחת רשת

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

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

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

אמינות

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

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

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

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

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

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

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

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

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

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

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

כדי להבטיח זמינות גבוהה של נתונים בווליומים של Hyperdisk במהלך הפסקת חשמל באזור יחיד, אפשר להשתמש ב-Hyperdisk Balanced High Availability. כשנתונים נכתבים לנפח אחסון מסוג Hyperdisk Balanced High Availability, הנתונים משוכפלים באופן סינכרוני בין שני אזורים באותו אזור.

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

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

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

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

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

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

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

‫Backup and DR תומך בשיטות הבאות ליצירת גיבויים:

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

מידע נוסף זמין במשאבי העזרה הבאים:

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

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

הוזלת עלויות

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

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

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

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

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

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

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

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

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

תמונות של Oracle Linux

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

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

קישוריות משרת האפליקציות למסד הנתונים

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

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

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

Observability for Oracle applications

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

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

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

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

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

ביצועי מחשוב

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

  • למכונות ה-VM שמארחות את האפליקציות ואת מסד הנתונים, בוחרים סוג מכונה מתאים על סמך דרישות הביצועים. למידע על סוגי המכונות שתומכים בנפחי Hyperdisk ועומדים בדרישות הביצועים ובדרישות אחרות, אפשר לעיין בהשוואה בין סדרות של מכונות.
  • למכונה הווירטואלית שמארחת את המופעים של Oracle Database, מומלץ להשתמש בסוג מכונה מתוך סדרת מכונות C4 של משפחת המכונות לשימוש כללי. סוגי המכונות C4 מספקים ביצועים גבוהים באופן עקבי לעומסי עבודה של מסדי נתונים.

ביצועי הרשת

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

ביצועי אחסון ב-Hyperdisk

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

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

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

פריסה

כדי לפרוס סביבת הדגמה של Oracle E‑Business Suite Vision באזור אחד Google Cloud , משתמשים בדוגמה להגדרת Terraform שזמינה ב-GitHub. הדוגמה הזו לא מיועדת לתרחישי שימוש בייצור.

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

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

מחברים:

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