במאמר הזה מוצגים תרשימי עזר לארכיטקטורות שיעזרו לכם לבנות את התשתית להרצת אפליקציות של 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כדי להריץ אפליקציות של 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 region. הארכיטקטורה הזו תואמת לארכיטיפ של פריסה אזורית.
הארכיטקטורה בתרשים שלמעלה כוללת את הרכיבים הבאים:
| רכיב | תיאור |
|---|---|
| מאזן עומסים חיצוני אזורי של אפליקציות (ALB) | מאזן העומסים מחלק את בקשות המשתמשים לאפליקציות של Oracle E‑Business Suite. |
| מדיניות האבטחה של Google Cloud Armor | מדיניות האבטחה של Cloud Armor עוזרת להגן על האפליקציות מפני איומים כמו מתקפות DDoS ו-XSS. |
| Oracle E‑Business Suite (BYOL) |
הרכיבים של שכבת האפליקציה של Oracle E‑Business Suite (שרת Oracle HTTP, שרת Oracle WebLogic ושרת עיבוד בו-זמני) פועלים במכונות וירטואליות של Compute Engine. כל מכונה וירטואלית מארחת מופע עצמאי של שכבת האפליקציה. דיסק האתחול של כל מכונה וירטואלית הוא נפח של Google Cloud Hyperdisk. אתם מביאים את הרישיונות שלכם (BYOL) ל-Oracle E‑Business Suite, ומנהלים את המכונות הווירטואליות והאפליקציות. |
| קבצים בינאריים ונתונים של אפליקציות | מכונה אזורית של Filestore מכילה את קובצי ה-binary והנתונים של האפליקציה. מכונות Filestore מותקנות במכונות הווירטואליות של Compute Engine שמארחות את הרכיבים של שכבת האפליקציה. |
| Oracle Database (BYOL) |
האפליקציות של Oracle E‑Business Suite משתמשות במכונה של מסד נתונים של Oracle, שנפרסת במכונה וירטואלית של Compute Engine. דיסקי האתחול והנתונים של ה-VM הם אמצעי אחסון מסוג Hyperdisk. אתם מביאים את הרישיון שלכם (BYOL) למכונה של Oracle Database, ומנהלים את המכונה הווירטואלית ואת מסד הנתונים. |
| גיבויים של אפליקציות ומסדי נתונים | הגיבויים של נתוני האפליקציה ומסד הנתונים נוצרים, נשמרים ומנוהלים באמצעות שירות Backup and DR. |
| רשת ענן וירטואלי פרטי (VPC) ורשתות משנה |
כל המשאבים של Google Cloud בארכיטקטורה משתמשים ברשת VPC אחת. המכונות הווירטואליות שמארחות את שכבת האפליקציה ואת מסד הנתונים משתמשות ברשתות משנה נפרדות. בהתאם לדרישות שלכם, אתם יכולים לבחור לבנות ארכיטקטורה שמשתמשת בכמה רשתות 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. בדומה לארכיטקטורה שבקטע הקודם, הארכיטקטורה הזו תואמת לארכיטיפ של פריסה אזורית.
הארכיטקטורה בתרשים שלמעלה כוללת את הרכיבים הבאים:
| רכיב | תיאור |
|---|---|
| מאזן עומסים חיצוני אזורי של אפליקציות (ALB) | מאזן העומסים החיצוני מפיץ בקשות ממשתמשים חיצוניים לשכבת האפליקציה שפונה החוצה. |
| מאזן עומסים פנימי אזורי של אפליקציות (ALB) | מאזן העומסים הפנימי מחלק את הבקשות ממשתמשים פנימיים לשכבת אפליקציה פנימית. |
| מדיניות האבטחה של Cloud Armor | מדיניות האבטחה של Cloud Armor עוזרת להגן על האפליקציות מפני איומים חיצוניים כמו התקפות DDoS ו-XSS. |
| Oracle E‑Business Suite (BYOL) |
הרכיבים של שכבת האפליקציה של Oracle E‑Business Suite (שרת Oracle HTTP, שרת Oracle WebLogic ושרת עיבוד בו-זמני) פועלים במכונות וירטואליות של Compute Engine. כל מכונה וירטואלית מארחת מופע עצמאי של שכבת האפליקציה. האפליקציות הפנימיות והחיצוניות מוגשות מקבוצות נפרדות של מכונות וירטואליות. דיסק האתחול של כל VM הוא נפח Hyperdisk. אתם מביאים את הרישיונות שלכם (BYOL) ל-Oracle E‑Business Suite, ומנהלים את המכונות הווירטואליות והאפליקציות. |
| קבצים בינאריים ונתונים של אפליקציות | מכונה אזורית של Filestore מכילה את קובצי ה-binary והנתונים של האפליקציה. מכונות Filestore מותקנות במכונות הווירטואליות של Compute Engine שמארחות את הרכיבים של שכבת האפליקציה. |
| Oracle Database (BYOL) |
האפליקציות של Oracle E‑Business Suite משתמשות במכונה של מסד נתונים של Oracle, שפרוסה במכונה וירטואלית של Compute Engine. דיסקי האתחול והנתונים של ה-VM הם אמצעי אחסון מסוג Hyperdisk. אתם מביאים את הרישיון שלכם (BYOL) למכונה של Oracle Database, ומנהלים את המכונה הווירטואלית ואת מסד הנתונים. |
| גיבויים של אפליקציות ומסדי נתונים | הגיבויים של נתוני האפליקציה ומסד הנתונים נוצרים, נשמרים ומנוהלים באמצעות Backup and DR. |
| רשת VPC ורשתות משנה |
כל המשאבים של Google Cloud בארכיטקטורה משתמשים ברשת VPC אחת. המכונות הווירטואליות שמארחות את שכבת האפליקציה ואת מסד הנתונים משתמשות ברשתות משנה נפרדות. בהתאם לדרישות שלכם, אתם יכולים לבחור לבנות ארכיטקטורה שמשתמשת בכמה רשתות 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, שפרוסות בשני אזורים בתוך אזור של Google Cloud . שני פריסות האפליקציות משתמשות במכונה ראשית של מסד נתונים של Oracle שפועלת במכונה וירטואלית באחד מהאזורים. Oracle Data Guard מנהל את השכפול ואת יתירות הכשל של מסד הנתונים למכונה של Oracle Database במצב המתנה באזור השני. הארכיטקטורה הזו מבוססת על ארכיטיפ הפריסה האזורית.
הארכיטקטורה בתרשים שלמעלה כוללת את הרכיבים הבאים:
| רכיב | תיאור |
|---|---|
| מאזן עומסים חיצוני אזורי של אפליקציות (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 באזורים נפרדים. דיסקי האתחול והנתונים של ה-VM הם אמצעי אחסון מסוג Hyperdisk. Oracle Data Guard מנהל את השכפול ואת יתירות הכשל של מסד הנתונים מהמכונה הראשית למכונה במצב המתנה. אתם מביאים את הרישיונות שלכם (BYOL) למכונות של מסד הנתונים של Oracle, ומנהלים את המכונות הווירטואליות ואת מסדי הנתונים. |
| גיבויים של אפליקציות ומסדי נתונים | הגיבויים של נתוני האפליקציה ומסד הנתונים נוצרים, נשמרים ומנוהלים באמצעות Backup and DR. |
| רשת VPC ורשתות משנה |
כל המשאבים של Google Cloud בארכיטקטורה משתמשים ברשת VPC אחת. המכונות הווירטואליות שמארחות את שכבת האפליקציה ואת מסד הנתונים משתמשות ברשתות משנה נפרדות. בהתאם לדרישות שלכם, אתם יכולים לבחור לבנות ארכיטקטורה שמשתמשת בכמה רשתות 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, שפרוסות בשני אזורים בתוך אזור של Google Cloud . שני פריסות האפליקציות משתמשות במכונה ראשית של מסד נתונים של Oracle שפועלת במכונה וירטואלית באחד מהאזורים. Oracle Data Guard מנהל את הרפליקציה ואת יתירות הכשל של מסד הנתונים למכונה של Oracle Database במצב המתנה באזור השני. הארכיטקטורה כוללת רפליקה בקנה מידה קטן יותר של מחסנית האפליקציה באזור מרוחק (יתירות כשל) ל-DR. בדומה לארכיטקטורה בקטע הקודם, הארכיטקטורה הזו מבוססת על ארכיטיפ הפריסה האזורית.
הארכיטקטורה בתרשים שלמעלה כוללת את הרכיבים הבאים:
| רכיב | תיאור |
|---|---|
| מדיניות ניתוב של יתירות כשל ב-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, שרת Oracle WebLogic ושרת עיבוד בו-זמני) פועלים במכונות וירטואליות של Compute Engine, שפרוסות בשני אזורים באזור הראשי. כל מכונה וירטואלית מארחת מכונה עצמאית של שכבת האפליקציה. דיסק האתחול של כל VM הוא נפח 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, ומנהלים את המכונות הווירטואליות ואת מסדי הנתונים. |
| גיבויים של אפליקציות ומסדי נתונים | הגיבויים של נתוני האפליקציה ומסד הנתונים נוצרים, נשמרים ומנוהלים באמצעות Backup and DR. |
| רשת VPC ורשתות משנה |
כל המשאבים של Google Cloud בארכיטקטורה משתמשים ברשת VPC אחת. המכונות הווירטואליות שמארחות את שכבת האפליקציה ואת מסד הנתונים משתמשות ברשתות משנה אזוריות נפרדות. בהתאם לדרישות שלכם, אתם יכולים לבחור לבנות ארכיטקטורה שמשתמשת בכמה רשתות 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 Service: שירות מאובטח ומנוהל באופן מרכזי לגיבוי ושחזור של עומסי עבודה ב- Google Cloud , שעוזר להגן על נתוני הגיבוי מפני מחיקה זדונית או מקרית.
- Cloud DNS: שירות שמספק שירות DNS עמיד עם זמן אחזור קצר מהרשת של Google ברחבי העולם.
- Cloud Load Balancing: מגוון של מאזני עומסים גלובליים ואזוריים, עם ביצועים גבוהים ויכולת התאמה לעומס.
- Google Cloud Armor: שירות אבטחת רשת שמציע כללים של חומת אש ליישומי אינטרנט (WAF) ועוזר להגן מפני מתקפות DDoS ומתקפות על אפליקציות.
- ענן וירטואלי פרטי (VPC): מערכת וירטואלית שמספקת פונקציונליות גלובלית וסקלאבילית של רשתות לעומסי העבודה ב- Google Cloud . רשת VPC כוללת את VPC Network Peering, Private Service Connect, גישה לשירותים פרטיים ו-VPC משותף.
- Cloud NAT: שירות שמספק תרגום כתובות רשת (NAT) בביצועים גבוהים, שמנוהל על ידי Google Cloud.
- Cloud Interconnect: שירות שמרחיב את הרשת החיצונית לרשת של Google באמצעות חיבור עם זמן אחזור קצר וזמינות גבוהה.
- Cloud VPN: שירות שמרחיב באופן מאובטח את הרשת השכנה לרשת של Google באמצעות מנהרת IPsec VPN.
ארכיטקטורות העזר האלה משתמשות במוצרים הבאים של Oracle:
- Oracle E-Business Suite: חבילת אפליקציות לפעילות עסקית כמו ניהול פיננסי, משאבי אנוש ושרשרת אספקה.
- Oracle Database: מערכת ניהול של מסד נתונים (RDBMS) שמרחיבה את המודל היחסי למודל יחסי-אובייקטים.
- Oracle Data Guard: קבוצת שירותים ליצירה, לתחזוקה, לניהול ולמעקב אחרי מסד נתונים אחד או יותר במצב המתנה.
אתם אחראים לרכישת רישיונות למוצרי Oracle שאתם פורסים ב- Google Cloud, ואתם אחראים לעמוד בתנאים ובהגבלות של הרישיונות של Oracle.
שיקולים בתכנון
בקטע הזה מתוארים גורמי תכנון, שיטות מומלצות והמלצות לתכנון שכדאי להביא בחשבון כשמשתמשים בארכיטקטורות לדוגמה האלה כדי לפתח טופולוגיה שעומדת בדרישות הספציפיות שלכם בנוגע לאבטחה, אמינות, יעילות תפעולית, עלות וביצועים.
עיצוב המערכת
בקטע הזה מוסבר איך לבחור את האזורים ב- Google Cloud לפריסה ואת שירותי Google Cloud המתאימים.
בחירת אזור
כשבוחרים את Google Cloud האזורים שבהם צריך לפרוס את האפליקציות, צריך להביא בחשבון את הגורמים והדרישות הבאים:
- זמינות השירותים של Google Cloud בכל אזור. בטבלה של זמינות המוצרים לפי מיקום תוכלו לקרוא מידע נוסף.
- זמינות של סוגי מכונות ב-Compute Engine בכל אזור. למידע נוסף, קראו את המאמר אזורים ותחומים.
- דרישות זמן אחזור של משתמשי קצה.
- עלות המשאבים של Google Cloud .
- עלויות העברת נתונים בין אזורים.
- דרישות רגולטוריות.
- דרישות בנושא קיימוּת.
חלק מהגורמים והדרישות האלה עשויים להיות כרוכים בפשרות. לדוגמה, יכול להיות שהאזור הכי משתלם מבחינת עלות הוא לא האזור עם טביעת הרגל הפחמנית הכי נמוכה. שיטות מומלצות לבחירת אזורים ב-Compute Engine
העברה של מסדי נתונים
כשאתם מתכננים להעביר פריסות של מסדי נתונים של Oracle מקומיים ל-Google Cloud, אתם יכולים להעריך את סביבת מסד הנתונים הנוכחית ולקבל המלצות להגדרה ולגודל באמצעות הכלי Database Migration Assessment (DMA).
כדי להעביר נתונים מקומיים לפריסות של מסדי נתונים של Oracle ב-Google Cloud, אתם יכולים להשתמש בכלים רגילים של Oracle כמו Oracle GoldenGate.
אפשרויות אחסון
במכונות הווירטואליות של Compute Engine בארכיטקטורה, אתם יכולים להשתמש בנפחי האתחול של Google Cloud Hyperdisk או של Persistent Disk. אמצעי אחסון ב-Hyperdisk מספקים ביצועים, גמישות ויעילות טובים יותר מאשר Persistent Disk. באמצעות Google Cloud Hyperdisk Balanced, אתם יכולים להקצות IOPS וקצב העברת נתונים בנפרד ובאופן דינמי, וכך להתאים את הנפח למגוון רחב של עומסי עבודה.
כדי לאחסן קובצי אפליקציות בינאריים, משתמשים ב-Filestore. קבצים שמאוחסנים במכונה אזורית של Filestore משוכפלים באופן סינכרוני בשלושה אזורים בתוך האזור. השכפול הזה עוזר להבטיח זמינות גבוהה ועמידות בפני הפסקות זמניות בשירות באזורים. כדי להגן על המערכת מפני הפסקות חשמל באזור, אפשר לשכפל מכונה של 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 פנימית פרטית עדיין יכולים לגשת לממשקי API ולשירותים מסוימים של Google באמצעות 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 Framework: אבטחה, פרטיות ותאימות.
אמינות
בקטע הזה מתוארים גורמי התכנון שצריך להביא בחשבון כשמשתמשים בארכיטקטורות לדוגמה האלה כדי לבנות ולהפעיל תשתית אמינה לפריסה ב- Google Cloud.
עמידות שכבת האפליקציה בפני כשלים במכונות הווירטואליות
בכל אפשרויות הארכיטקטורה שמופיעות במסמך הזה, אם חלק מהמכונות הווירטואליות של האפליקציה נכשלות (אבל לא כולן), האפליקציות ממשיכות להיות זמינות כי מאזן העומסים מעביר את הבקשות למכונות וירטואליות אחרות של האפליקציה.
לפעמים מכונה וירטואלית של אפליקציה פועלת וזמינה, אבל יש בעיות באפליקציה עצמה. האפליקציה עלולה לקפוא, לקרוס או לא להכיל מספיק זיכרון. במקרה כזה, ה-VM לא יגיב לבדיקות התקינות של מאזן העומסים, ומאזן העומסים לא ינתב תנועה ל-VM שלא מגיב.
עמידות מסד הנתונים בפני כשלים במכונות וירטואליות
בארכיטקטורה אזורית, אם ה-VM של מסד הנתונים נכשל, אתם יכולים לשחזר את מסד הנתונים לסביבת הייצור ב-VM חדש באמצעות הגיבויים שמאוחסנים ב-Backup and DR. אחרי שאתם משחזרים את מסד הנתונים, אתם צריכים לחבר את האפליקציות למכונה החדשה של מסד הנתונים.
אם עקביות הנתונים היא בעדיפות גבוהה, כדאי להגדיר מכונה ראשית ומכונה חלופית של מסד נתונים, רצוי במכונות וירטואליות שנמצאות באזורים שונים, כמו שמוצג בארכיטקטורה אזורית. כדי לבצע רפליקציה ויתירות כשל למכונה של מסד הנתונים במצב המתנה, משתמשים ב-Oracle Data Guard. אתם יכולים להגדיר את Oracle Data Guard כך שישכפל טרנזקציות למכונה של מסד הנתונים החלופי לפני שהמכונה של מסד הנתונים הראשי מאשרת את ה-commits. ארכיטקטורת מסד הנתונים הראשי-המשני כרוכה בעלויות נוספות של תשתית ורישוי.
בארכיטקטורה אזורית או במספר אזורים, אם המכונה הווירטואלית שמארחת את מסד הנתונים הראשי נכשלת, Oracle Data Guard יוזם יתירות כשל למכונה של מסד הנתונים של Oracle במצב המתנה. במהלך תהליך המעבר, האפליקציות לא יכולות לגשת למסד הנתונים.
עמידות בפני הפסקות חשמל באזורים
בארכיטקטורה אזורית, אם יש הפסקה זמנית בשירות באזור שמארח את הפריסה, האפליקציות ומסד הנתונים מושבתים. אתם יכולים לשחזר את האפליקציות ומסד הנתונים לסביבת הייצור באזור אחר, באמצעות הגיבויים שמאוחסנים ב-Backup and DR.
בארכיטקטורה אזורית, אם באחד מהאזורים יש הפסקה, מאזן העומסים מעביר את הבקשות למכונות של האפליקציות שפועלות באזור השני. Filestore ממשיך להיות זמין כי הארכיטקטורה משתמשת ברמת השירות האזורית של Filestore.
כדי להבטיח זמינות גבוהה של נתונים בנפחי Hyperdisk במהלך הפסקה זמנית בפעילות באזור אחד, אתם יכולים להשתמש ב-Google Cloud 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
- Backup and DR לגיבויים של מכונות Compute Engine
- גיבוי ו-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, מומלץ להשתמש בשם ה-DNS הפנימי של האזור של המכונה הווירטואלית של מסד הנתונים, ולא בכתובת ה-IP שלה. Google Cloud פותר באופן אוטומטי את שם ה-DNS לכתובת ה-IP הפנימית הראשית של המכונה הווירטואלית. יתרון נוסף בגישה הזו הוא שלא צריך להקצות כתובות IP פנימיות סטטיות למכונות הווירטואליות של מסד הנתונים.
מסמכי תיעוד ותמיכה של Oracle
מוצרי Oracle שפועלים במכונות וירטואליות של Compute Engine דומים מבחינה תפעולית למוצרי Oracle שפועלים באופן מקומי. עם זאת, אתם לא צריכים לנהל את תשתית המחשוב, הרשת והאחסון הבסיסית.
- להנחיות לגבי הפעלה וניהול של מוצרי Oracle, עיינו במסמכי התיעוד של Oracle למוצר הרלוונטי.
- למידע על מדיניות התמיכה של Oracle במכונות של מסדי נתונים של Oracle שאתם פורסים ב- Google Cloud, קראו את המאמר Oracle Database Support for Non-Oracle Public Cloud Environments (Doc ID 2688277.1).
- לסיכום של מדיניות התמיכה של Oracle ב-Oracle E‑Business Suite, קראו את המאמר אישורי EBS.
ניראות של אפליקציות Oracle
כדי להטמיע יכולת תצפית בעומסי עבודה של Oracle שנפרסו ב- Google Cloud, אתם יכולים להשתמש בשירותי Google Cloud Observability או ב-Oracle Enterprise Manager. בחרו אסטרטגיית מעקב שמתאימה לדרישות ולאילוצים שלכם. לדוגמה, אם אתם מריצים עומסי עבודה אחרים ב- Google Cloud בנוסף לעומסי העבודה של Oracle, אתם יכולים להשתמש בשירותי Google Cloud Observability כדי ליצור לוח בקרה מאוחד למעקב אחרי כל עומסי העבודה.
שיקולים תפעוליים נוספים
כשאתם בונים את הארכיטקטורה של עומס העבודה, כדאי להביא בחשבון את השיטות המומלצות הכלליות ואת ההמלצות ליעילות תפעולית שמתוארות במאמר Google Cloud Well-Architected Framework: מצוינות תפעולית.
אופטימיזציה של הביצועים
בקטע הזה מתוארים הגורמים שצריך להביא בחשבון כשמשתמשים בארכיטקטורות לדוגמה כדי לתכנן טופולוגיה ב- Google Cloud שעומדת בדרישות הביצועים של עומסי העבודה.
ביצועי המחשוב
ב-Compute Engine יש מגוון רחב של סוגי מכונות מוגדרים מראש ובהתאמה אישית, שאפשר לבחור מביניהם בהתאם לדרישות הביצועים של עומסי העבודה.
- למכונות הווירטואליות שמארחות את האפליקציות ואת מסד הנתונים, בוחרים סוג מכונה מתאים על סמך דרישות הביצועים. במאמר השוואה בין סדרות של מכונות מוסבר אילו סוגי מכונות תומכים בנפחי Hyperdisk ועומדים בדרישות הביצועים ובדרישות אחרות.
- למכונה הווירטואלית שמארחת את המכונות של מסד הנתונים של Oracle, מומלץ להשתמש בסוג מכונה מסדרת המכונות C4 ממשפחת המכונות לשימוש כללי. סוגי המכונות C4 מספקים ביצועים גבוהים באופן עקבי לעומסי עבודה של מסדי נתונים.
ביצועי הרשת
ב-Compute Engine יש מגבלה לכל מכונה וירטואלית על רוחב הפס של הרשת לתעבורת נתונים יוצאת. המגבלה הזו תלויה בסוג המכונה של ה-VM, ובשאלה אם התנועה מנותבת דרך אותה רשת VPC כמו ה-VM המקורי. במכונות וירטואליות עם סוגי מכונות מסוימים, כדי לשפר את ביצועי הרשת, אתם יכולים להפעיל את רשת Tier_1 ולקבל רוחב פס מקסימלי גבוה יותר לתעבורת נתונים יוצאת. מידע נוסף זמין במאמר הגדרת ביצועי רשת Tier_1 לכל מכונה וירטואלית.
ביצועי האחסון ב-Hyperdisk
הארכיטקטורות שמתוארות במסמך הזה משתמשות בנפחי Hyperdisk לכל דיסקי האתחול של המכונות הווירטואליות, ולדיסקי הנתונים של המכונות הווירטואליות של מסד הנתונים. ב-Hyperdisk אפשר לשנות את הביצועים והקיבולת באופן דינמי. אתם יכולים לשנות את ה-IOPS המוקצה, את קצב הנתונים ואת הגודל של כל נפח אחסון כדי להתאים אותם לביצועי האחסון ולצורכי הקיבולת של עומס העבודה. הביצועים של אמצעי אחסון ב-Hyperdisk תלויים בסוג ה-Hyperdisk ובסוג המכונה של ה-VMs שאליהם אמצעי האחסון מחוברים. למידע נוסף על מגבלות הביצועים והכוונון של Hyperdisk, קראו את המאמרים הבאים:
- סוגי מכונות שתומכים ב-Hyperdisk
- מגבלות הביצועים של Hyperdisk
- wedge אופטימיזציה של הביצועים של Hyperdisk
שיקולים נוספים שקשורים לביצועים
כשאתם בונים את הארכיטקטורה של עומס העבודה, כדאי להביא בחשבון את השיטות המומלצות הכלליות ואת ההמלצות שמפורטות במאמר Google Cloud Well-Architected Framework: אופטימיזציה של הביצועים.
פריסה
כדי לפרוס סביבת הדגמה של Oracle E‑Business Suite Vision באזור Google Cloud יחיד, משתמשים בדוגמה להגדרת Terraform שזמינה ב-GitHub. הדוגמה הזו לא מיועדת לתרחישי שימוש בסביבת ייצור.
המאמרים הבאים
- טרנספורמציה דיגיטלית בענן באמצעות Google Cloud ו-Oracle
- ארכיטקטורות לדוגמה של Oracle MAA
- אפליקציה ארגונית במכונות וירטואליות של Compute Engine עם Oracle Exadata ב- Google Cloud
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחברים:
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- סמנתה הי | כותבת טכנית
תורמים אחרים:
- אנדי קולווין | מהנדס מסדי נתונים בכיר, Oracle ב-Google Cloud
- Balazs Pinter | ארכיטקט פתרונות לשותפים, צוות פנימי
- Celia Antonio | Database Customer Engineer
- מאג'ד אל-חלאסה | מהנדס לקוחות, מודרניזציה של תשתיות
- מארק פילדינג | ארכיטקט תשתית נתונים
- מארק שלאגנהאוף | כותב טכני, רשתות
- נלסון גונזלס | מנהל מוצר
- מישל ברטופט | מנהלת מוצר בכירה
- שון דרינגטון | מנהל קבוצת מוצרים, אחסון
- סקו פייג' | מנהל מוצר יוצא
- סוג'י מאדהוראפאנטולה | מנהלת קבוצת מוצרים
- ויקטור מורנו | מנהל מוצר, Cloud Networking