במסמך הזה מפורטות ארכיטקטורות לדוגמה שיעזרו לכם לבנות את התשתית להפעלת אפליקציות של Oracle E‑Business Suite עם Oracle Database במכונות וירטואליות של Compute Engine ב- Google Cloud. Oracle E‑Business Suite היא חבילה של אפליקציות ארגוניות לפונקציות עסקיות כמו פיננסים, משאבי אנוש, שרשרת אספקה ויחסי לקוחות.
קהל היעד של המסמך הזה הוא אדריכלי ענן ואדמינים של מסדי נתונים של 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 , במצב פעיל-פעיל או פעיל-סביל. ארכיטיפ הפריסה הזה אידיאלי לתרחישי התאוששות מאסון. אנחנו ממליצים על הארכיטיפ הזה לאפליקציות קריטיות שצריכות עמידות להפסקות חשמל באזור ולאסונות.
בחירה של ארכיטיפ פריסה מתאים עוזרת לפשט את ההחלטות הבאות לגבי המוצרים והתכונות שדרושים לארכיטקטורה שלכם. Google Cloud
בקטעים הבאים מוצגות ארבע אפשרויות ארכיטקטורה. כל אפשרות מבוססת על אחד מאבות הטיפוס של הפריסה:
- ארכיטקטורה אזורית
- ארכיטקטורה אזורית עם DMZ
- ארכיטקטורה אזורית
- ארכיטקטורה פעילה-סבילה (DR) בכמה אזורים
ארכיטקטורה אזורית
בתרשים הבא מוצגת ארכיטקטורה של אפליקציות Oracle E‑Business Suite עם Oracle Database שפועלת באזור אחד בתוך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. דיסקי האתחול והנתונים של המכונה הווירטואלית הם נפחי 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. בדומה לארכיטקטורה שמוצגת בקטע הקודם, הארכיטקטורה הזו תואמת לארכיטיפ של פריסה אזורית.
הארכיטקטורה בתרשים שלמעלה כוללת את הרכיבים הבאים:
| רכיב | תיאור |
|---|---|
| מאזן עומסים חיצוני אזורי של אפליקציות (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. דיסקי האתחול והנתונים של המכונה הווירטואלית הם נפחי 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 במצב המתנה באזור השני. הארכיטקטורה הזו מבוססת על ארכיטיפ של פריסה אזורית.
הארכיטקטורה בתרשים שלמעלה כוללת את הרכיבים הבאים:
| רכיב | תיאור |
|---|---|
| מאזן עומסים חיצוני אזורי של אפליקציות (ALB) | מאזן העומסים מחלק את בקשות המשתמשים לאפליקציות של Oracle E‑Business Suite. |
| מדיניות אבטחה של Cloud Armor | מדיניות האבטחה של Cloud Armor עוזרת להגן על האפליקציות מפני איומים כמו התקפות DDoS מבוזרות ו-XSS. |
| Oracle E‑Business Suite (BYOL) |
רכיבי שכבת האפליקציה של Oracle E‑Business Suite (שרת Oracle HTTP, שרת Oracle WebLogic ושרת לעיבוד מקביל) פועלים במכונות וירטואליות של Compute Engine שמפוזרות על פני שני אזורים. כל מכונה וירטואלית מארחת מופע עצמאי של שכבת האפליקציה. דיסק האתחול של כל מכונה וירטואלית הוא נפח Hyperdisk. אתם מביאים את הרישיונות שלכם (BYOL) ל-Oracle E‑Business Suite, ומנהלים את המכונות הווירטואליות ואת האפליקציות. |
| קובצי הפעלה של אפליקציות ונתונים | מופע אזורי של Filestore מכיל את הקבצים הבינאריים והנתונים של האפליקציה. מופע Filestore מותקן בכל המכונות הווירטואליות של Compute Engine שמארחות את הרכיבים של שכבת האפליקציה בשני התחומים. |
| Oracle Database (BYOL) |
אפליקציות Oracle E‑Business Suite משתמשות בצמד ראשי-משני של מופעי Oracle Database שנפרסים במכונות וירטואליות של Compute Engine באזורים נפרדים. דיסקי האתחול והנתונים של המכונה הווירטואלית הם נפחי 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 במצב המתנה באזור השני. הארכיטקטורה כוללת העתק בקנה מידה קטן יותר של מחסנית האפליקציות באזור מרוחק (מעבר לגיבוי) לצורך התאוששות מאסון. כמו הארכיטקטורה בקטע הקודם, הארכיטקטורה הזו מבוססת על ארכיטיפ של פריסה אזורית.
הארכיטקטורה בתרשים שלמעלה כוללת את הרכיבים הבאים:
| רכיב | תיאור |
|---|---|
| מדיניות ניתוב למעבר אוטומטי לגיבוי (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 באזורים נפרדים באזור הראשי. דיסקי האתחול והנתונים של המכונה הווירטואלית הם נפחי 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 האזורים שבהם צריך לפרוס את האפליקציות, חשוב לקחת בחשבון את הגורמים והדרישות הבאים:
- זמינות השירותים Google Cloud בכל אזור. מידע נוסף מופיע במאמר זמינות המוצרים לפי מיקום.
- זמינות של סוגי מכונות ב-Compute Engine בכל אזור. מידע נוסף זמין במאמר אזורים ותחומים.
- דרישות לזמן האחזור של משתמשי הקצה.
- העלות של 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.
הרשאות בחשבון שירות
עבור ה-VMs של 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.
כדי להבטיח זמינות גבוהה של נתונים בווליומים של 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 תומך בשיטות הבאות ליצירת גיבויים:
- אחסון בכספת הגיבוי: נתוני הגיבוי מאוחסנים באותו אזור שבו מאוחסנים נתוני המקור, ואי אפשר לשנות או למחוק את הנתונים.
- אחסון בניהול עצמי: משתמשים מורשים יכולים לשנות או למחוק את נתוני הגיבוי, ואפשר לאחסן נתונים בכמה אזורים.
מידע נוסף זמין במשאבי העזרה הבאים:
- סקירה כללית על Backup and DR
- גיבוי ושחזור של מכונות ב-Compute Engine באמצעות Backup and DR
- גיבוי ו-DR ל-Filestore ולמערכות קבצים
- Backup and DR ל-Oracle
שיקולים נוספים בנושא מהימנות
כשיוצרים את ארכיטקטורת הענן של עומס העבודה, כדאי לעיין בשיטות המומלצות ובהמלצות שקשורות למהימנות, שמפורטות במסמכים הבאים:
- Google Cloud מדריך לאמינות התשתית
- תבניות לאפליקציות עמידות שניתנות להרחבה
- תכנון מערכות חסינות
- Google Cloud Well-Architected Framework: אמינות
הוזלת עלויות
בקטע הזה מוסבר איך לבצע אופטימיזציה של העלות של הגדרת Google Cloud טופולוגיה שאתם בונים באמצעות הארכיטקטורות האלה, ושל התפעול שלה.
סוגי מכונות וירטואליות
כדי לעזור לכם לייעל את השימוש במשאבים של המכונות הווירטואליות, Compute Engine מספק המלצות לסוגי מכונות. תוכלו להשתמש בהמלצות כדי לבחור סוגי מכונות שמתאימים לדרישות המחשוב של עומס העבודה. לעומסי עבודה עם דרישות צפויות של משאבים, תוכלו להתאים אישית את סוג המכונה לצרכים שלכם ולחסוך כסף באמצעות סוגי מכונות בהתאמה אישית.
רישיונות למוצרי Oracle
באחריותכם לרכוש רישיונות למוצרי Oracle שאתם פורסים ב-Compute Engine, ובאחריותכם לפעול בהתאם לתנאים ולהגבלות של רישיונות Oracle. מידע נוסף זמין במאמר בנושא רישוי תוכנת Oracle בסביבת מחשוב ענן.
שיקולי עלות נוספים
כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי גם לעיין בשיטות המומלצות ובהמלצות הכלליות שמופיעות במאמר 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 שפועלים בפריסה מקומית. עם זאת, אתם לא צריכים לנהל את התשתית הבסיסית של המחשוב, הרשת והאחסון.
- הוראות להפעלה ולניהול של מוצרי Oracle מפורטות במסמכי העזרה של המוצר הרלוונטי שסופקו על ידי Oracle.
- למידע על מדיניות התמיכה של Oracle לגבי מופעים של Oracle Database שאתם פורסים ב- Google Cloud, אפשר לעיין במאמר Oracle Database Support for Non-Oracle Public Cloud Environments (תמיכה ב-Oracle Database בסביבות ענן ציבורי שאינן של Oracle) (מסמך מספר 2688277.1).
- סיכום של מדיניות התמיכה של Oracle ב-Oracle E‑Business Suite מופיע במאמר EBS Certifications.
Observability for Oracle applications
כדי להטמיע יכולות ניטור של עומסי עבודה של Oracle שנפרסו ב- Google Cloud, אפשר להשתמש בשירותי Google Cloud Observability או ב-Oracle Enterprise Manager. כדאי לבחור אסטרטגיית ניטור מתאימה בהתאם לדרישות ולמגבלות שלכם. לדוגמה, אם אתם מריצים עומסי עבודה אחרים ב- Google Cloud בנוסף לעומסי עבודה של Oracle, אתם יכולים להשתמש בשירותי Google Cloud Observability כדי ליצור לוח בקרה מאוחד לניטור של כל עומסי העבודה.
שיקולים תפעוליים נוספים
כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי לקחת בחשבון את השיטות המומלצות הכלליות ואת ההמלצות ליעילות תפעולית שמתוארות במאמר Google Cloud Well-Architected Framework: Operational excellence.
אופטימיזציה של הביצועים
בקטע הזה מתוארים הגורמים שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורות ההפניה האלה כדי לתכנן טופולוגיה ב- Google Cloud שעומדת בדרישות הביצועים של עומסי העבודה.
ביצועי מחשוב
ב-Compute Engine יש מגוון רחב של סוגי מכונות מוגדרים מראש וניתנים להתאמה אישית, שאפשר לבחור מתוכם בהתאם לדרישות הביצועים של עומסי העבודה.
- למכונות הווירטואליות שמארחות את האפליקציות ואת מסד הנתונים, בוחרים סוג מכונה מתאים בהתאם לדרישות הביצועים. למידע על סוגי המכונות שתומכים בנפחי 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.
פריסה
המאמרים הבאים
- טרנספורמציה בענן עם Google Cloud ו-Oracle
- ארכיטקטורות לדוגמה של Oracle MAA
- אפליקציה ארגונית במכונות וירטואליות של Compute Engine עם Oracle Exadata ב- Google Cloud
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחברים:
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- Samantha He | Technical Writer
תורמי תוכן אחרים:
- Andy Colvin | Database Black Belt Engineer, Oracle on Google Cloud
- Balazs Pinter | Staff Partner Solutions Architect
- Celia Antonio | Database Customer Engineer
- מאג'ד אל-הלאסה | Customer Engineer, Infrastructure Modernization
- Marc Fielding | Data Infrastructure Architect
- מארק שלגנהוף | כותב טכני, רשתות
- נלסון גונזלס | מנהל מוצר
- Michelle Burtoft | Senior Product Manager
- שון דרינגטון | מנהל קבוצת מוצרים, אחסון
- Sekou Page | Outbound Product Manager
- Souji Madhurapantula | Group Product Manager
- Victor Moreno | Product Manager, Cloud Networking