במאמר הזה מוצגת ארכיטקטורת הפניה שתעזור לכם לבנות את התשתית להרצת אפליקציות Oracle PeopleSoft במכונות וירטואליות של Compute Engine עם קישוריות בהשהיה נמוכה ל-Oracle Database@Google Cloud (מסדי נתונים של Oracle Cloud Infrastructure Exadata שפועלים בתוך Google Cloud). Oracle PeopleSoft היא חבילה של אפליקציות ארגוניות לניהול הון אנושי, לפתרונות לקמפוסים ולתכנון משאבים ארגוניים.
המסמך הזה מיועד למומחי Cloud Architect ולאדמינים של מסדי נתונים של Oracle ואפליקציות Oracle PeopleSoft. ההנחה במאמר הזה היא שאתם מכירים את אפליקציות Oracle PeopleSoft ואת מסדי הנתונים של Oracle.
ארכיטקטורה
בתרשים הבא מוצגת ארכיטקטורה שבה אפליקציות Oracle PeopleSoft פועלות במכונות וירטואליות ב-Compute Engine ב Google Cloud אזור מסוים, ומשתמשות במסדי נתונים של Oracle Exadata באותו אזור Google Cloud .
הארכיטקטורה בתרשים שלמעלה כוללת את הרכיבים הבאים:
| רכיב | מטרה |
|---|---|
| מאזן עומסים חיצוני אזורי של אפליקציות (ALB) | מאזן העומסים מקבל בקשות ממשתמשים ומפיץ אותן לשרתי האינטרנט של Oracle PeopleSoft. כדי להבטיח זיקה לסשן (session affinity), מאזן העומסים מוגדר להשתמש בקובצי Cookie שנוצרו. |
| כללי מדיניות האבטחה של Google Cloud Armor | מדיניות האבטחה של Cloud Armor עוזרת להגן על חבילת האפליקציות מפני איומים כמו התקפות מניעת שירות מבוזרות (DDoS) ופרצות אבטחה XSS (cross-site scripting). |
| Oracle PeopleSoft web tier (BYOL) | שכבת האינטרנט של Oracle PeopleSoft מורכבת משרתי אינטרנט שפועלים באופן עצמאי בשתי מכונות וירטואליות ב-Compute Engine. אתם מביאים את הרישיונות שלכם (BYOL) ל-Oracle PeopleSoft, ומנהלים את המכונות הווירטואליות ואת תוכנת שרת האינטרנט. |
| קבצים בינאריים של שרת אינטרנט | מופע Filestore מכיל את קובצי ההפעלה של שרת האינטרנט. המופע של Filestore מותקן בכל המכונות הווירטואליות של Compute Engine שמארחות את שרתי האינטרנט. |
| Oracle PeopleSoft mid tier (BYOL) |
השכבה האמצעית של Oracle PeopleSoft מורכבת מהרכיבים הבאים:
כל אחד מהרכיבים האלה פועל באופן עצמאי בשתי מכונות וירטואליות של Compute Engine. אתם מביאים את הרישיונות שלכם (BYOL) לרכיבי Oracle PeopleSoft, ומנהלים את המכונות הווירטואליות ואת תוכנת השכבה האמצעית. |
| קבצים בינאריים ברמה בינונית | מופע Filestore מכיל את הקבצים הבינאריים של השכבה האמצעית. המופע של Filestore מותקן בכל המכונות הווירטואליות של Compute Engine שמארחות את רכיבי השכבה האמצעית. |
| גיבויים של אפליקציות | גיבויים של האפליקציה נוצרים, מאוחסנים ומנוהלים על ידי שירות Backup and DR. |
| רשת של ענן וירטואלי פרטי (VPC) | כל Google Cloud המשאבים בארכיטקטורה משתמשים ברשת VPC אחת. שרתי האינטרנט, רכיבי הביניים ומסדי הנתונים נמצאים ברשתות משנה נפרדות. |
| Oracle Database@Google Cloud |
אפליקציות Oracle PeopleSoft קוראות נתונים ממסדי נתונים של Oracle וכותבות נתונים למסדי נתונים של Oracle בשירות Oracle Exadata Database. אתם יכולים להקצות את שירות מסד הנתונים של Oracle Exadata באמצעות Oracle Database@Google Cloud, מוצר ב-Cloud Marketplace שמאפשר לכם להריץ מסדי נתונים של Oracle בחומרה שמנוהלת על ידי Oracle במרכז נתונים Google Cloud . אתם משתמשים Google Cloud בממשקים כמו המסוף Google Cloud , Google Cloud CLI וממשקי API כדי ליצור מופעים של Exadata Infrastructure. Oracle מגדירה ומנהלת את תשתית המחשוב, האחסון והרשת הנדרשת במרכז נתונים באזור Google Cloud בשרתים שמוקדשים לפרויקט שלכם. כדי לייעל את זמן האחזור בין האפליקציה לבין מסד הנתונים, כדאי לפרוס את האפליקציה באותו אזור שבו יוצרים את מופעי Exadata Infrastructure. |
| Exadata Infrastructure instance | מופע של תשתית Exadata מכיל שני שרתים פיזיים או יותר של מסד נתונים ושלושה שרתים או יותר של אחסון. השרתים האלה, שלא מוצגים בתרשים, מחוברים ביניהם באמצעות רשת עם השהיה נמוכה. כשיוצרים את מופע Exadata Infrastructure, מציינים את מספר שרתי מסדי הנתונים ושרתי האחסון שצריך להקצות. |
| Exadata VM Clusters | בתוך מופע Exadata Infrastructure, יוצרים קלאסטר וירטואלי אחד או יותר של Exadata. לדוגמה, אתם יכולים לבחור ליצור ולהשתמש באשכול נפרד של מכונות וירטואליות של Exadata כדי לארח את מסדי הנתונים שנדרשים לכל אחת מהיחידות העסקיות שלכם. כל Exadata VM Cluster מכיל מכונה וירטואלית אחת או יותר של Oracle Linux שמארחות מופעים של Oracle Database. כשיוצרים Exadata VM Cluster, מציינים את הפרטים הבאים:
המכונות הווירטואליות באשכולות של מכונות וירטואליות ב-Exadata לא הן מכונות וירטואליות של Compute Engine. |
| מכונות Oracle Database | אתם יוצרים ומנהלים מופעים של Oracle Database דרך מסוף Oracle Cloud Infrastructure (OCI) וממשקי OCI אחרים. תוכנת מסד הנתונים של Oracle פועלת במכונות הווירטואליות באשכול המכונות הווירטואליות של Exadata. כשיוצרים את Exadata VM Cluster, מציינים את הגרסה של Oracle Grid Infrastructure ובוחרים את סוג הרישיון. אתם יכולים להביא רישיונות משלכם (BYOL) או לבחור במודל שכולל רישיון. |
| OCI VCN ורשתות משנה | כשיוצרים Exadata VM Cluster, נוצרת באופן אוטומטי רשת וירטואלית בענן OCI (VCN). ל-VCN יש רשת משנה של לקוח ורשת משנה לגיבוי עם טווחי כתובות IP שאתם מציינים. רשת המשנה של הלקוח משמשת לקישוריות מרשת ה-VPC למסדי הנתונים של Oracle. רשת המשנה של הגיבוי משמשת לשליחת גיבויים של מסדי נתונים אל OCI Object Storage. |
| Cloud Router, Partner Interconnect, ו- OCI DRG | התנועה בין רשת ה-VPC ב- Google Cloudלבין רשת ה-VCN ב-OCI מנותבת על ידי Cloud Router דרך שער ניתוב דינמי (DRG) שמצורף לרשת ה-VCN ב-OCI. התעבורה עוברת דרך חיבור עם זמן אחזור נמוך ש-Google מגדירה באמצעות Partner Interconnect. |
| תחום פרטי של Cloud DNS | כשיוצרים אשכול של מכונות וירטואליות ב-Exadata, נוצר באופן אוטומטי אזור פרטי של Cloud DNS. כשהאפליקציות שלכם שולחות בקשות קריאה וכתיבה למסדי הנתונים של Oracle, Cloud DNS מבצע המרה של שמות המארחים של מסדי הנתונים לכתובות ה-IP המתאימות. |
| OCI Object Storage ו- OCI Service Gateway | כברירת מחדל, הגיבויים של מסדי הנתונים של Oracle Exadata מאוחסנים ב-OCI Object Storage. גיבויים של מסדי נתונים מנותבים אל OCI Object Storage דרך Service Gateway. |
| שער Cloud NAT ציבורי (אופציונלי) | הארכיטקטורה כוללת שער Cloud NAT ציבורי אופציונלי. השער מאפשר חיבורים יוצאים מאובטחים ממכונות וירטואליות ב-Compute Engine, שיש להן רק כתובות IP פנימיות. |
| Cloud Interconnect או Cloud VPN | כדי לחבר את הרשת המקומית לרשת ה-VPC ב- Google Cloud, אפשר להשתמש ב-Cloud Interconnect או ב-Cloud VPN. מידע על היתרונות היחסיים של כל אחת מהגישות זמין במאמר בחירת מוצרים של Network Connectivity. |
| Cloud Monitoring | אתם יכולים להשתמש ב-Cloud Monitoring כדי לעקוב אחרי ההתנהגות, המצב ו הביצועים של האפליקציה והמשאבים Google Cloud שלכם, כולל משאבי Oracle Exadata. אפשר גם לעקוב אחרי משאבי Oracle Exadata באמצעות שירות הניטור של OCI. |
המוצרים שהשתמשו בהם
הארכיטקטורה הזו כוללת את המוצרים הבאים: Google Cloud
- Compute Engine: שירות מחשוב מאובטח וניתן להתאמה אישית שמאפשר ליצור ולהריץ מכונות וירטואליות בתשתית של Google.
- Cloud Load Balancing: חבילה של מאזני עומסים גלובליים ואזוריים בעלי ביצועים גבוהים ורמת מדרגיות גבוהה.
- Google Cloud Armor: שירות אבטחת רשת שמציע כללים של חומת אש ליישומי אינטרנט (WAF) ועוזר להגן מפני מתקפות DDoS ומתקפות על אפליקציות.
- ענן וירטואלי פרטי (VPC): מערכת וירטואלית שמספקת פונקציונליות של רשתות גלובליות וניתנות להרחבה עבור עומסי העבודה שלכם ב- Google Cloud . VPC כולל קישור בין רשתות VPC שכנות (peering), Private Service Connect, גישה לשירותים פרטיים ו-VPC משותף.
- Cloud Interconnect: שירות שמרחיב את הרשת החיצונית שלכם לרשת של Google באמצעות חיבור עם זמינות גבוהה וזמן אחזור קצר.
- Partner Interconnect: שירות שמספק קישוריות בין הרשת המקומית שלכם לבין רשתות הענן הווירטואלי הפרטי (VPC) שלכם ורשתות אחרות, באמצעות ספק שירות נתמך.
- Cloud VPN: שירות שמרחיב באופן מאובטח את הרשת השכנה לרשת של Google באמצעות מנהרת VPN מסוג IPsec.
- Cloud NAT: שירות שמספק תרגום כתובות רשת בניהול Google Cloud, עם ביצועים גבוהים.
- שירות Backup and DR: שירות מאובטח ומנוהל באופן מרכזי לגיבוי ושחזור של Google Cloud עומסי עבודה, שעוזר להגן על נתוני הגיבוי מפני מחיקה זדונית או מקרית.
- Cloud DNS: שירות שמספק DNS אמין עם זמן אחזור קצר שממלא בקשות מהרשת העולמית של Google.
ארכיטקטורת העזר הזו משתמשת במוצרי Oracle הבאים:
- Oracle PeopleSoft: חבילת אפליקציות לארגונים לניהול הון אנושי, פתרונות לקמפוסים ותכנון משאבים ארגוניים.
- שירות מסד נתונים של Exadata בתשתית ייעודית: שירות שמאפשר להריץ מופעים של Oracle Database בחומרה של Exadata שמוקדשת לכם.
- VCN ותת-רשתות: VCN היא רשת וירטואלית פרטית למשאבים באזור OCI. תת-רשת היא טווח רציף של כתובות IP עם VCN.
- שער ניתוב דינמי: נתב וירטואלי לתעבורה בין VCN לבין רשתות חיצוניות.
- אחסון אובייקטים: שירות לאחסון כמויות גדולות של נתונים מובנים ולא מובנים כאובייקטים.
- שער שירות: שער שמאפשר למשאבים ב-VCN לגשת לשירותים ספציפיים של Oracle באופן פרטי.
באחריותכם להשיג רישיונות למוצרי Oracle שאתם פורסים ב- Google Cloud, ובאחריותכם לציית לתנאים ולהגבלות של רישיונות Oracle.
שיקולים בתכנון
בקטע הזה מתוארים גורמים בתכנון, שיטות מומלצות והמלצות לתכנון שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לפתח טופולוגיה שעונה על הדרישות הספציפיות שלכם בנוגע לאבטחה, למהימנות, ליעילות תפעולית, לעלות ולביצועים. כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי לעיין גם בשיטות המומלצות ובהמלצות שבGoogle Cloud Well-Architected Framework.
עיצוב המערכת
בקטע הזה מוסבר איך לבחור 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 Migration Methods Advisor.
לפני שמשתמשים במסדי הנתונים שהועברו בסביבת ייצור, צריך לוודא שיש קישוריות מהאפליקציות למסדי הנתונים.
אפשרויות אחסון
עבור המכונות הווירטואליות של Compute Engine בארכיטקטורה, אפשר להשתמש בHyperdisk או בPersistent Disk כנפחי אתחול. נפחי Hyperdisk מספקים ביצועים טובים יותר, גמישות ויעילות בהשוואה ל-Persistent Disk. עם Hyperdisk Balanced, אפשר להקצות IOPS וקצב העברת נתונים בנפרד ובאופן דינמי, וכך להתאים את עוצמת הקול למגוון רחב של עומסי עבודה.
כדי לאחסן קבצים בינאריים של אפליקציות, משתמשים ב-Filestore. קבצים שמאוחסנים במופע Filestore Regional משוכפלים באופן סינכרוני בשלושה אזורים בתוך האזור. השכפול הזה עוזר להבטיח זמינות גבוהה ועמידות מפני הפסקות חשמל באזורים. כדי להבטיח עמידות במקרה של הפסקות חשמל באזור מסוים, אפשר לשכפל מופע Filestore לאזור אחר. מידע נוסף זמין במאמר בנושא שכפול של מופעים.
כשמתכננים את האחסון של עומסי העבודה, צריך לקחת בחשבון את המאפיינים הפונקציונליים של עומסי העבודה, את דרישות העמידות, את הביצועים הצפויים ואת יעדי העלות. למידע נוסף, אפשר לעיין במאמר תכנון אסטרטגיית אחסון אופטימלית לעומס העבודה בענן.
תכנון הרשת ב-Oracle Database@Google Cloud
בוחרים עיצוב רשת שעונה על הדרישות העסקיות והטכניות שלכם. לדוגמה, אפשר להשתמש ברשת VPC אחת או בכמה רשתות VPC. מידע נוסף זמין במאמר בחירת טופולוגיות של רשת עבור Oracle Database@Google Cloud.
כשמקצים טווחי כתובות IP לרשתות המשנה של הלקוח ושל הגיבוי לשימוש באשכולות של מכונות וירטואליות ב-Exadata, צריך לקחת בחשבון את דרישות הגודל המינימלי של רשתות המשנה. מידע נוסף זמין במאמר בנושא תכנון מרחב כתובות ה-IP ב-Oracle Database@Google Cloud.
אבטחה, פרטיות ותאימות
בקטע הזה מתוארים גורמים שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לתכנן טופולוגיה ב- Google Cloud שעומדת בדרישות האבטחה והתאימות של עומסי העבודה.
הגנה מפני איומים חיצוניים
כדי להגן על האפליקציה מפני איומים כמו התקפות מניעת שירות מבוזרות (DDoS) ופרצות אבטחה XSS (cross-site scripting), אפשר להשתמש במדיניות אבטחה של Google Cloud Armor. כל מדיניות היא קבוצה של כללים שמציינים תנאים מסוימים שצריך לבדוק ופעולות שצריך לבצע כשהתנאים מתקיימים. לדוגמה, כלל יכול לציין שאם כתובת ה-IP של המקור של התנועה הנכנסת תואמת לכתובת IP ספציפית או לטווח CIDR, אז צריך לדחות את התנועה. אפשר גם להחיל כללים מוגדרים מראש של חומת אש לאפליקציות אינטרנט (WAF). מידע נוסף זמין במאמר סקירה כללית של מדיניות האבטחה.
גישה חיצונית למכונות וירטואליות
בארכיטקטורת ההפניה שמתוארת במסמך הזה, למכונות הווירטואליות ב-Compute Engine לא נדרשת גישה נכנסת מהאינטרנט. לא מקצים כתובות IP חיצוניות למכונות הווירטואליות. Google Cloud משאבים שיש להם רק כתובת IP פנימית פרטית עדיין יכולים לגשת לשירותים ולממשקי Google API מסוימים באמצעות Private Service Connect או גישה פרטית ל-Google. מידע נוסף זמין במאמר אפשרויות גישה פרטיות לשירותים.
כדי לאפשר חיבורים יוצאים מאובטחים מ Google Cloud משאבים שיש להם רק כתובות IP פרטיות, כמו מכונות וירטואליות של Compute Engine בארכיטקטורת ההפניה הזו, אפשר להשתמש ב-Secure Web Proxy או ב-Cloud NAT.
לגבי תת-הרשתות שבהן נעשה שימוש במכונות וירטואליות של Exadata, Oracle ממליצה להקצות טווחי כתובות IP פרטיות.
הרשאות בחשבון שירות
במקום להשתמש בחשבונות השירות שמוגדרים כברירת מחדל, מומלץ ליצור חשבונות שירות ייעודיים למכונות הווירטואליות של Compute Engine בארכיטקטורה ולציין את המשאבים שלחשבון השירות תהיה גישה אליהם. לחשבון השירות שמוגדר כברירת מחדל יש מגוון רחב של הרשאות, כולל כאלה שאולי לא נחוצות. אפשר להתאים חשבונות שירות ייעודיים כך שיהיו להם רק ההרשאות החיוניות. מידע נוסף זמין במאמר הגבלת ההרשאות של חשבון שירות.
אבטחת SSH
כדי לשפר את האבטחה של חיבורי SSH למכונות וירטואליות ב-Compute Engine בארכיטקטורה שלכם, כדאי להטמיע את Identity-Aware Proxy (IAP) ואת Cloud OS Login API. IAP מאפשר לכם לשלוט בגישה לרשת על סמך זהות המשתמשים ומדיניות ניהול הזהויות והרשאות הגישה (IAM). Cloud OS Login API מאפשר לכם לשלוט בגישת SSH ל-Linux על סמך זהות המשתמש ומדיניות IAM. מידע נוסף על ניהול גישה לרשת זמין במאמר שיטות מומלצות לשליטה בגישה להתחברות באמצעות SSH.
הצפנת נתונים
כברירת מחדל, הנתונים שמאוחסנים ב-Hyperdisk, ב-Persistent Disk וב-Filestore מוצפנים באמצעותGoogle-owned and Google-managed encryption keys. כדי להוסיף שכבת הגנה נוספת, אתם יכולים להצפין את Google-owned and managed key באמצעות מפתחות שבבעלותכם ושאתם מנהלים ב-Cloud Key Management Service (Cloud KMS). מידע נוסף מופיע במאמר בנושא הצפנת דיסקים לגבי נפחי Hyperdisk ו-Persistent Disk, ובמאמר בנושא הצפנת נתונים באמצעות מפתחות הצפנה בניהול הלקוח לגבי Filestore.
כברירת מחדל, מסדי נתונים של Exadata משתמשים ב-Transparent Data Encryption (TDE), שמאפשר להצפין מידע אישי רגיש שמאוחסן בטבלאות ובאזורי טבלאות.
אבטחת רשת
כדי לשלוט בתעבורת הרשת בין המשאבים בארכיטקטורה, צריך להגדיר מדיניות מתאימה של Cloud Next Generation Firewall (NGFW).
במכונות וירטואליות של שרת אינטרנט, מוודאים ששדה המקור של מדיניות הכניסה כולל את הפרטים הבאים:
- ה-CIDR של תת-הרשת של שרת ה-proxy בלבד של מאזן העומסים.
- בלוקי ה-CIDR של בדיקות התקינות.
אבטחה ותאימות ב-Oracle Exadata
שירות מסד הנתונים Oracle Exadata כולל את Oracle Data Safe, שעוזר לכם לנהל את דרישות האבטחה והתאימות למסדי נתונים של Oracle. אתם יכולים להשתמש ב-Oracle Data Safe כדי להעריך את אמצעי הבקרה של האבטחה, לעקוב אחרי פעילות המשתמשים ולהסתיר נתונים רגישים. מידע נוסף זמין במאמר בנושא ניהול אבטחת מסד הנתונים באמצעות Oracle Data Safe.
שיקולי אבטחה נוספים
כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי להביא בחשבון את השיטות המומלצות וההמלצות לאבטחה ברמת הפלטפורמה שמפורטות בתוכנית לניהול יסודות האבטחה בארגון ובGoogle Cloud מסגרת Well-Architected: יסודות האבטחה, הפרטיות והתאימות.
אמינות
בקטע הזה מתוארים גורמים עיצוביים שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לבנות ולהפעיל תשתית אמינה לפריסה ב-Google Cloud.
חוסן שכבת האפליקציה מפני כשלים במכונות וירטואליות
אם אחת משתי מכונות וירטואליות שמארחות כל רכיב של Oracle PeopleSoft נכשלת, האפליקציה ממשיכה להיות זמינה. הבקשות מנותבות למכונה הווירטואלית השנייה.
לפעמים יכול להיות שמכונה וירטואלית פועלת וזמינה, אבל יש בעיות ברכיב Oracle Peoplesoft עצמו. יכול להיות שהרכיב יקפא, יקרוס או שלא יהיה לו מספיק זיכרון. בתרחישים האלה, המכונה הווירטואלית לא תגיב לבדיקות התקינות של מאזן העומסים, ומאזן העומסים לא ינתב תעבורה למכונה הווירטואלית שלא מגיבה.
עמידות בפני הפסקות חשמל באזורים או באזורי זמינות
אם מתרחש הפסקת חשמל באזור או בתחום, האפליקציה לא זמינה. כדי לצמצם את זמן ההשבתה שנגרם כתוצאה מהפסקות שירות כאלה, אפשר ליישם את הגישה הבאה:
- שומרים על רפליקה פסיבית (יתירות כשל) של סטאק האפליקציות באזור או בתחום (zone) אחר שלGoogle Cloud .
- יוצרים מופע של Exadata Infrastructure במצב המתנה עם Exadata VM Clusters הנדרשים באותו אזור שבו נמצא העותק הפסיבי של מחסנית האפליקציות. משתמשים ב-Oracle Active Data Guard לשכפול נתונים ולמעבר אוטומטי לגיבוי במקרה של כשל במסדי הנתונים של Exadata. אם האפליקציה שלכם צריכה יעד להתאוששות מאסון (RPO) נמוך יותר, אתם יכולים לגבות את מסדי הנתונים ולשחזר אותם באמצעות Oracle Autonomous Recovery Service.
- אם מתרחש שיבוש באזור הראשי או בתחום המוגדר הראשי, אפשר להשתמש ברפליקה או בגיבוי של מסד הנתונים כדי לשחזר את מסד הנתונים בסביבת הייצור ולהפעיל את האפליקציה באזור או בתחום המוגדר של המעבר לגיבוי.
- אם העותק הפסיבי נמצא באזור אחר, צריך להשתמש במדיניות הניתוב של Cloud DNS כדי לנתב את התעבורה למאזן העומסים החיצוני באזור הזה.
מידע נוסף זמין במאמר בנושא ארכיטקטורת זמינות מקסימלית (MAA) של Oracle ל-Oracle Database@Google Cloud.
Oracle מנהלת את התשתית ב-Oracle Database@Google Cloud. מידע על היעדים למדידת רמת השירות (SLO) של Oracle Exadata Database Service on Dedicated Infrastructure זמין במאמר בנושא יעדים למדידת רמת השירות (SLO) של שירותי ענן ציבורי של Oracle PaaS ו-IaaS.
תכנון הקיבולת של מכונות וירטואליות
כדי לוודא שהקיבולת של מכונות וירטואליות ב-Compute Engine תהיה זמינה כשצריך להקצות מכונות וירטואליות, אפשר ליצור שמירת מקום. הזמנה מספקת קיבולת מובטחת באזור ספציפי למספר מסוים של מכונות וירטואליות מסוג מכונה שאתם בוחרים. אפשר להגדיר הזמנה לפרויקט ספציפי, או לשתף אותה בין כמה פרויקטים. מידע נוסף על הזמנות זמין במאמר בחירת סוג הזמנה.
קיבולת Oracle Exadata
אפשר להרחיב את Exadata Infrastructure על ידי הוספה של שרתי מסדי נתונים ושרתי אחסון לפי הצורך. אחרי שמוסיפים את שרתי מסד הנתונים או שרתי האחסון הנדרשים ל-Exadata Infrastructure, כדי להשתמש במשאבי האחסון או במעבד הנוספים, צריך להוסיף את הקיבולת לאשכול ה-VM של Exadata שמשויך אליהם. מידע נוסף זמין במאמר שינוי גודל של משאבי מחשוב ואחסון ב-Exadata.
עמידות הנתונים
אתם יכולים להשתמש בשירות Backup and DR כדי ליצור גיבויים של מכונות וירטואליות ב-Compute Engine, לאחסן אותם ולנהל אותם. שירות Backup and DR מאחסן נתוני גיבוי בפורמט המקורי שניתן לקריאה על ידי האפליקציה. כשנדרש, אפשר לשחזר עומסי עבודה לסביבת הייצור באמצעות נתונים מאחסון גיבוי לטווח ארוך, בלי לבצע פעולות של העברת נתונים או הכנה של נתונים שגוזלות זמן. למידע נוסף, ראו Backup and DR לגיבויים של מופעים ב-Compute Engine.
כדי להבטיח את עמידות הנתונים במופעי Filestore, אפשר ליצור גיבויים ותמונות מצב של המופע או להשתמש ב-Backup and DR for Filestore and file systems.
כברירת מחדל, גיבויים של מסדי נתונים ב-Oracle Exadata Database Service on Dedicated Infrastructure מאוחסנים ב-OCI Object Storage. כדי להשיג RPO נמוך יותר, אפשר לגבות ולשחזר את מסדי הנתונים באמצעות Oracle Autonomous Recovery Service.
שיקולים נוספים בנושא מהימנות
כשיוצרים את ארכיטקטורת הענן של עומס העבודה, כדאי לעיין בשיטות המומלצות ובהמלצות שקשורות למהימנות, שמפורטות במסמכים הבאים:
- Google Cloud מדריך לאמינות התשתית
- תבניות לאפליקציות עמידות שניתנות להרחבה
- תכנון מערכות חסינות
- Google Cloud Well-Architected Framework: אמינות
הוזלת עלויות
בקטע הזה מוסבר איך לבצע אופטימיזציה של העלות של הגדרת טופולוגיה של Google Cloud והפעלתה, שאתם בונים באמצעות ארכיטקטורת ההפניה הזו.
סוגי מכונות וירטואליות
כדי לעזור לכם לייעל את השימוש במשאבים של המכונות הווירטואליות, Compute Engine מספק המלצות לגבי סוגי מכונות. אפשר להשתמש בהמלצות כדי לבחור סוגי מכונות שתואמים לדרישות החישוב של עומס העבודה. אם אתם יכולים לחזות את השימוש שלכם במשאבים בעומסי העבודה, אתם יכולים להתאים אישית את סוג המכונה לצרכים שלכם ולחסוך כסף באמצעות סוגי מכונות בהתאמה אישית.
רישיונות למוצרי Oracle
באחריותכם לרכוש רישיונות למוצרי Oracle שאתם פורסים ב-Compute Engine, ובאחריותכם לציית לתנאים ולהגבלות של רישיונות Oracle. מידע נוסף זמין במאמר Licensing Oracle Software in the Cloud Computing Environment.
רישוי של מסד נתונים Oracle Exadata
כשיוצרים Exadata VM Cluster, אפשר להשתמש ברישיון משלכם (BYOL) או ברישיון שרכשתם כחלק מההזמנה שלכם ב-Google Cloud Marketplace ל-Oracle Database@Google Cloud.
המחיר של Oracle Database@Google Cloud כולל את העלויות של תעבורת נתונים ברשת בין האפליקציות שלכם לבין מסדי הנתונים של Oracle Exadata שנמצאים באותו אזור.
שיקולי עלות נוספים
כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי גם לעיין בשיטות המומלצות ובהמלצות הכלליות שמופיעות במאמר Google Cloud Well-Architected Framework: הוזלת העלויות.
יעילות תפעולית
בקטע הזה מתוארים הגורמים שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לתכנן טופולוגיה של Google Cloud שאפשר להפעיל ביעילות.
תמונות של Oracle Linux
אתם יכולים להשתמש בתמונות של Oracle Linux שזמינות ב-Compute Engine או לייבא תמונות של Oracle Linux שאתם יוצרים ומתחזקים.
אפשר גם ליצור ולהשתמש בקובצי אימג' של מערכת הפעלה בהתאמה אישית שכוללים את ההגדרות והתוכנות שהאפליקציות שלכם צריכות. לקבץ את התמונות המותאמות אישית למשפחת תמונות מותאמות אישית. משפחת תמונות תמיד מצביעה על התמונה האחרונה במשפחה, כך שתבניות המופעים והסקריפטים יכולים להשתמש בתמונה הזו בלי שתצטרכו לעדכן הפניות לגרסת תמונה ספציפית. חשוב לעדכן באופן קבוע את התמונות המותאמות אישית כדי לכלול את עדכוני האבטחה והתיקונים שמסופקים על ידי ספק מערכת ההפעלה.
ניהול מסד נתונים של Oracle Exadata
Oracle מנהלת את שרתי מסד הנתונים הפיזיים, שרתי האחסון וציוד הרשת ב-Oracle Exadata Database Service on Dedicated Infrastructure. אתם יכולים לנהל את מופעי Exadata Infrastructure ואת Exadata VM Clusters דרך ממשקי OCI או Google Cloud . אתם יוצרים ומנהלים מסדי נתונים דרך הממשקים של OCI. בדפי Google Cloud המסוף של Oracle Database@Google Cloud יש קישורים שבעזרתם אפשר לעבור ישירות לדפים הרלוונטיים במסוף OCI. כדי שלא תצטרכו להיכנס שוב ל-OCI, אתם יכולים להגדיר איחוד זהויות בין OCI לבין Google Cloud.
Observability for Oracle applications
כדי להטמיע יכולות Observability לעומסי עבודה של Oracle שנפרסו ב- Google Cloud, אפשר להשתמש בשירותי Google Cloud Observability או ב-Oracle Enterprise Manager. בוחרים אסטרטגיית מעקב מתאימה בהתאם לדרישות ולמגבלות. לדוגמה, אם אתם מריצים עומסי עבודה אחרים Google Cloud בנוסף לעומסי עבודה של Oracle, אתם יכולים להשתמש בשירותי Google Cloud Observability כדי ליצור לוח בקרה מאוחד למעקב אחרי כל עומסי העבודה.
מסמכי תמיכה של Oracle
מוצרי Oracle שפועלים במכונות וירטואליות של Compute Engine מעלים חששות תפעוליים דומים לאלה של מוצרי Oracle שפועלים בפריסה מקומית. עם זאת, אתם לא צריכים לנהל את התשתית הבסיסית של המחשוב, הרשת והאחסון. הנחיות להפעלה ולניהול של מוצרי Oracle זמינות במסמכי התיעוד הרלוונטיים של Oracle.
למידע על מדיניות התמיכה של Oracle לגבי מופעים של Oracle Database שאתם פורסים ב- Google Cloud, אפשר לעיין במאמר Oracle Database Support for Non-Oracle Public Cloud Environments (Doc ID 2688277.1).
שיקולים תפעוליים נוספים
כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי לקחת בחשבון את השיטות המומלצות הכלליות ואת ההמלצות ליעילות תפעולית שמתוארות במאמר Google Cloud Well-Architected Framework: Operational excellence.
אופטימיזציה של הביצועים
בקטע הזה מתוארים הגורמים שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לתכנן טופולוגיה ב- Google Cloud שעומדת בדרישות הביצועים של עומסי העבודה.
ביצועי מחשוב
Compute Engine מציע מגוון רחב של סוגי מכונות מוגדרים מראש וניתנים להתאמה אישית לעומסי העבודה שאתם מריצים במכונות וירטואליות. בוחרים סוג מכונה מתאים בהתאם לדרישות הביצועים. מידע נוסף זמין במאמר השוואה בין משפחות של מכונות ומשאבים.
ביצועי הרשת
ב-Compute Engine יש מגבלה לכל מכונה וירטואלית על רוחב הפס ברשת של תעבורת נתונים יוצאת. המגבלה הזו תלויה בסוג המכונה של המכונה הווירטואלית ובשאלה אם התנועה מנותבת דרך אותה רשת VPC כמו המכונה הווירטואלית של המקור. במכונות וירטואליות עם סוגי מכונות מסוימים, אפשר להגדיל את רוחב הפס המקסימלי של תעבורת הנתונים היוצאת על ידי הפעלת Tier_1 networking. מידע נוסף זמין במאמר בנושא הגדרת ביצועים של רשת Tier_1 לכל מכונה וירטואלית.
תעבורת הנתונים ברשת בין מכונות ה-VM של האפליקציה לבין רשת Oracle Exadata מנותבת דרך חיבור Partner Interconnect עם השהיה נמוכה, שמוגדר על ידי Google.
תשתית Exadata משתמשת ב-RDMA over Converged Ethernet (RoCE) כדי ליצור רשת עם רוחב פס גבוה וזמן אחזור נמוך בין שרתי מסדי הנתונים ושרתי האחסון שלה. השרתים מחליפים נתונים ישירות בזיכרון הראשי בלי שהמעבד, המטמון או מערכת ההפעלה מעורבים.
כדי לייעל את זמן האחזור בין האפליקציה למסד הנתונים, כדאי לפרוס את האפליקציה באותו אזור שבו יוצרים את מופע Exadata Infrastructure.
שיקולי ביצועים נוספים
כשמגדירים את הארכיטקטורה של עומס העבודה, כדאי לפעול לפי השיטות המומלצות וההמלצות הכלליות שמופיעות במאמר Google Cloud Well-Architected Framework: Performance optimization.
המאמרים הבאים
- טרנספורמציה בענן עם Google Cloud ו-Oracle
- מאמרי עזרה של Oracle
- סקירה כללית של Oracle Database@Google Cloud
- Oracle Maximum Availability Architecture (MAA) for Oracle Database@Google Cloud
- תכנון של מרחב כתובות IP ב-Oracle Database@Google Cloud
- מידע נוסף על בחירת טופולוגיות של רשתות ל-Oracle Database@Google Cloud
- פריסת Oracle Database@Google Cloud
- Oracle MAA Reference Architectures
- תיעוד של Google
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: קומאר דהנגופל | מפתח פתרונות חוצי-מוצרים
תורמי תוכן אחרים:
- Andy Colvin | Database Black Belt Engineer, Oracle on Google Cloud
- Balazs Pinter | Staff Partner Solutions Architect
- ביג'ו נארייאנן (Biju Narayanan) | מנהל בכיר, פיתוח אפליקציות (Oracle)
- Bikash Kar | Project Leader, Application Development (Oracle)
- Celia Antonio | Database Customer Engineer
- צ'ארלס אליוט | ראש צוות אדריכלים בתחום
- Gustavo Jimenez | Senior Staff Partner Solutions Architect
- Hari G I | Senior Principal Software Engineer (Oracle)
- Jignesh Patel | Customer Engineer
- Jon Pawlowski | Partner Engineer
- Karteek Kotamsetty | Lead Customer Engineer
- Kenny He | Customer Engineer, Data Specialist
- מאג'ד אל-הלאסה | Customer Engineer, Infrastructure Modernization
- Marc Fielding | Data Infrastructure Architect
- Maria Zuliani | Customer Engineer, Database Specialist
- Michelle Burtoft | Senior Product Manager
- נלסון גונזלס | מנהל מוצר
- שון דרינגטון | מנהל קבוצת מוצרים, אחסון