במסמך הזה מוצגת ארכיטקטורה לדוגמה של אפליקציה ארגונית בזמינות גבוהה, שמתארחת במכונות וירטואליות (VM) של Compute Engine עם קישוריות בזמן אחזור קצר למסדי נתונים של Oracle Cloud Infrastructure (OCI) Exadata שפועלים ב- Google Cloud. קהל היעד של המאמר הזה הוא מומחי Cloud Architect ומנהלי מסדי נתונים של Oracle. המסמך מבוסס על ההנחה שאתם מכירים את Compute Engine ואת Oracle Exadata Database Service.
אם אתם משתמשים ב-Oracle Exadata או ב-Oracle Real Application Clusters (Oracle RAC) כדי להריץ מסדי נתונים של Oracle באופן מקומי, אתם יכולים להעביר ביעילות את האפליקציות ל- Google Cloud ולהריץ את מסדי הנתונים ב-Oracle Database@Google Cloud. Oracle Database@Google Cloud הוא מוצר ב-Google Cloud Marketplace שמאפשר להריץ את Oracle Exadata Database Service ואת Oracle Autonomous Database ישירות ב- Google Cloud.
אם אתם לא צריכים את היכולת של Oracle RAC או אם אתם צריכים גרסה של מסד נתונים של Oracle שהיא לא 19c ו-23ai, אתם יכולים להריץ מסדי נתונים של Oracle בניהול עצמי במכונות וירטואליות של Compute Engine. מידע נוסף זמין במאמר אפליקציה ארגונית עם מסד נתונים של Oracle ב-Compute Engine.
ארכיטקטורה
התרשים הבא מציג מבט כללי על הארכיטקטורה:
בתרשים שלמעלה, מאזן עומסים חיצוני מקבל בקשות ממשתמשים של אפליקציה שפונה לציבור, ומפיץ את הבקשות לשרתי אינטרנט של ממשק קצה. שרתי האינטרנט מעבירים את בקשות המשתמשים דרך מאזן עומסים פנימי לשרתי האפליקציות. שרתי האפליקציות קוראים נתונים ממסדי נתונים ב-Oracle Database@Google Cloud וכותבים אליהם. אדמינים ושירותי OCI יכולים להתחבר למסדי הנתונים של Oracle ולתקשר איתם.
התרשים הבא מציג תצוגה מפורטת של הארכיטקטורה:
בארכיטקטורה הזו, שכבת האינטרנט ושכבת האפליקציה פועלות במצב פעיל-פעיל במכונות וירטואליות של Compute Engine, שפרוסות בשני אזורים בתוך אזור Google Cloud. האפליקציה משתמשת במסדי נתונים של Oracle Exadata באותו אזור ב- Google Cloud.
כל הרכיבים בארכיטקטורה נמצאים באזור אחד ב- Google Cloud. הארכיטקטורה הזו תואמת לארכיטיפ של פריסה אזורית. אתם יכולים להתאים את הארכיטקטורה הזו כדי ליצור טופולוגיה שעמידה בפני הפסקות חשמל אזוריות, באמצעות ארכיטיפ הפריסה במספר אזורים. למידע נוסף, קראו את המאמר פריסה בכמה אזורים ב-Compute Engine ואת ההנחיות בקטע אמינות בהמשך המאמר.
הארכיטקטורה שמוצגת בתרשים הקודם כוללת את הרכיבים הבאים:
| רכיב | מטרה |
|---|---|
| מאזן עומסים חיצוני אזורי של אפליקציות (ALB) | מאזן העומסים החיצוני האזורי של האפליקציות מקבל בקשות מהמשתמשים ומפיץ אותן למכונות הווירטואליות של שכבת האינטרנט. |
| מדיניות האבטחה של Google Cloud Armor | מדיניות האבטחה של Cloud Armor עוזרת להגן על מחסנית האפליקציות מפני איומים כמו התקפות מניעת שירות מבוזרות (DDoS) ופרצות אבטחה XSS (cross-site scripting). |
| קבוצת מופעי מכונה מנוהלים (MIG) אזורית לשכבת האינטרנט | שכבת האינטרנט של האפליקציה פרוסה במכונות וירטואליות של Compute Engine, שהן חלק מקבוצת MIG אזורית. קבוצת ה-MIG הזו היא הקצה העורפי של מאזן העומסים החיצוני של האפליקציות. קבוצת ה-MIG מכילה מכונות וירטואליות של Compute Engine בשני אזורים. כל אחת מהמכונות הווירטואליות האלה מארחת מכונה עצמאית של שכבת האינטרנט של האפליקציה. |
| מאזן עומסים פנימי אזורי של אפליקציות (ALB) | מאזן העומסים הפנימי האזורי של האפליקציות מחלק את התנועה מהמכונות הווירטואליות של שכבת האינטרנט למכונות הווירטואליות של שכבת האפליקציות. |
| קבוצת MIG אזורית לשכבת האפליקציה | שכבת האפליקציה, כמו אשכול של Oracle WebLogic Server, נפרסת במכונות וירטואליות של Compute Engine שהן חלק מקבוצת מכונות מנוהלת (MIG) אזורית. קבוצת ה-MIG הזו היא הקצה העורפי של מאזן העומסים הפנימי של האפליקציות. קבוצת ה-MIG מכילה מכונות וירטואליות של Compute Engine בשני אזורים. כל מכונה וירטואלית מארחת מכונה עצמאית של שרת האפליקציה. |
| רשת VPC ותת-רשת | כל המשאבים של Google Cloud בארכיטקטורה משתמשים ברשת VPC אחת. בהתאם לדרישות, אתם יכולים לבחור לבנות ארכיטקטורה שמשתמשת בכמה רשתות. מידע נוסף זמין במאמר החלטה אם ליצור כמה רשתות VPC. |
| Oracle Database@Google Cloud |
שרתי האפליקציות קוראים נתונים ממסדי נתונים של Oracle ב-Oracle Exadata Database Service וכותבים אליהם. אתם מקצים את Oracle Exadata Database Service באמצעות Oracle Database@Google Cloud, מוצר ב-Cloud Marketplace שמאפשר להריץ מסדי נתונים של Oracle בחומרה שמנוהלת על ידי Oracle במרכז נתונים של Google Cloud . אתם משתמשים בממשקי Google Cloud כמו מסוף Google Cloud , Google Cloud CLI וממשקי API כדי ליצור מכונות של תשתית Exadata. Oracle מגדירה ומנהלת את התשתית הנדרשת למחשוב, לאחסון ולרשת במרכז נתונים באזור של Google Cloud , בחומרה שמיועדת לפרויקט שלכם. |
| מכונות של Exadata Infrastructure | כל מכונה של Exadata Infrastructure מכילה שני שרתי מסדי נתונים פיזיים או יותר, ושלושה שרתי אחסון או יותר. השרתים האלה, שלא מוצגים בתרשים, מקושרים ביניהם באמצעות מארג רשת עם זמן אחזור קצר. כשיוצרים מכונה של Exadata Infrastructure, מציינים את מספר שרתי מסד הנתונים ושרתי האחסון שצריך להקצות. |
| אשכולות של מכונות וירטואליות ב-Exadata |
בתוך מכונה של Exadata Infrastructure, יוצרים אשכול אחד או יותר של מכונות וירטואליות של Exadata. לדוגמה, אתם יכולים ליצור אשכול נפרד של Exadata VM ולהשתמש בו כדי לארח את מסדי הנתונים שנדרשים לכל אחת מהיחידות העסקיות שלכם. כל Exadata VM Cluster מכיל מכונה וירטואלית אחת או יותר של Oracle Linux שמארחות מכונות של Oracle Database. כשיוצרים אשכול מכונות וירטואליות של Exadata, צריך לציין את הפרטים הבאים:
המכונות הווירטואליות באשכולות של Exadata הן לא מכונות וירטואליות של Compute Engine. |
| מכונות של Oracle Database | אתם יוצרים ומנהלים מסדי נתונים של Oracle באמצעות מסוף OCI וממשקי OCI אחרים. תוכנת Oracle Database פועלת במכונות הווירטואליות באשכול המכונות הווירטואליות של Exadata. כשיוצרים את אשכול המכונות הווירטואליות של Exadata, מציינים את הגרסה של Oracle Grid Infrastructure. אתם גם בוחרים את סוג הרישיון: החברה מביאה את הרישיון שלה (BYOL) או בוחרת במודל שכולל רישיון. |
| OCI VCN ורשתות משנה | כשיוצרים אשכול של מכונות וירטואליות ב-Exadata, נוצרת באופן אוטומטי רשת וירטואלית בענן (VCN) של OCI. ל-VCN יש רשת משנה של לקוח ורשת משנה של גיבוי עם טווחי כתובות IP שאתם מציינים. רשת המשנה של הלקוח משמשת לקישוריות מרשת ה-VPC למסדי הנתונים של Oracle. רשת המשנה לגיבוי משמשת לשליחת גיבויים של מסדי נתונים אל OCI Object Storage. |
| Cloud Router, Partner Interconnect ו-OCI DRG | תעבורת הנתונים בין רשת ה-VPC לבין ה-VCN מנותבת על ידי Cloud Router שמחובר לרשת ה-VPC, ודרך שער ניתוב דינמי (DRG) שמחובר ל-VCN. תעבורת הנתונים זורמת דרך חיבור עם זמן אחזור קצר ש-Google מגדירה באמצעות Partner Interconnect. |
| תחום Cloud DNS פרטי | כשיוצרים אשכול Exadata VM, נוצר באופן אוטומטי אזור פרטי ב-Cloud DNS. כששרתי האפליקציה שולחים בקשות קריאה וכתיבה למסדי הנתונים של Oracle, Cloud DNS מבצע פענוח 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: מגוון של מאזני עומסים גלובליים ואזוריים, עם ביצועים גבוהים ויכולת התאמה לעומס.
- ענן וירטואלי פרטי (VPC): מערכת וירטואלית שמספקת פונקציונליות גלובלית וניתנת להתאמה של רשתות לעומסי העבודה ב- Google Cloud . VPC כולל את VPC Network Peering, Private Service Connect, גישה לשירותים פרטיים ו-VPC משותף.
- Google Cloud Armor: שירות אבטחת רשת שמציע כללים של חומת אש ליישומי אינטרנט (WAF) ועוזר להגן מפני מתקפות DDoS ומתקפות על אפליקציות.
- Cloud NAT: שירות שמספק תרגום כתובות רשת (NAT) בניהול של Google Cloud, עם ביצועים גבוהים.
- Cloud Monitoring: שירות שמאפשר לראות את נתוני הביצועים, הזמינות והתקינות של האפליקציות והתשתית.
- Cloud Interconnect: שירות שמרחיב את הרשת החיצונית לרשת של Google באמצעות חיבור עם זמינות גבוהה וזמן אחזור קצר.
- Partner Interconnect: שירות שמספק קישוריות בין הרשת המקומית לבין רשתות VPC ורשתות אחרות, באמצעות ספק שירות נתמך.
- Cloud VPN: שירות שמרחיב באופן מאובטח את הרשת השכנה לרשת של Google באמצעות מנהרת IPsec VPN.
בארכיטקטורה הזו נעשה שימוש במוצרי OCI הבאים:
- Exadata Database Service on Dedicated Infrastructure: שירות שמאפשר להריץ מכונות של Oracle Database בחומרת Exadata ייעודית.
- אחסון אובייקטים: שירות לאחסון כמויות גדולות של נתונים מובְנים ולא מובְנים כאובייקטים.
- VCN ותת-רשתות: VCN היא רשת וירטואלית ופרטית למשאבים באזור OCI. רשת משנה היא טווח רציף של כתובות IP עם VCN.
- שער ניתוב דינמי: נתב וירטואלי לתעבורת נתונים בין VCN לבין רשתות חיצוניות.
- שער שירות: שער שמאפשר למשאבים ב-VCN לגשת באופן פרטי לשירותים ספציפיים של Oracle.
שיקולים שקשורים לעיצוב
בקטע הזה מתוארים גורמי תכנון, שיטות מומלצות והמלצות לתכנון שכדאי להביא בחשבון כשמשתמשים בארכיטקטורה לדוגמה הזו כדי לפתח טופולוגיה שעומדת בדרישות הספציפיות שלכם לאבטחה, לאמינות, ליעילות תפעולית, לעלות ולביצועים.
ההנחיות בקטע הזה הן חלקיות. בהתאם לדרישות הספציפיות של האפליקציה שלכם, ובהתאם למוצרים ולתכונות של Google Cloud ושל צדדים שלישיים שבהם אתם משתמשים, יכול להיות שתצטרכו להביא בחשבון גורמי תכנון ושיקולים נוספים.
עיצוב המערכת
בקטע הזה מוסבר איך לבחור את האזורים ב- Google Cloud לפריסה ואת שירותי Google Cloud המתאימים.
בחירת אזור
כשבוחרים את Google Cloud האזורים שבהם צריך לפרוס את האפליקציות, צריך להביא בחשבון את הגורמים והדרישות הבאים:
- זמינות השירותים של Google Cloud בכל אזור. בטבלה של זמינות המוצרים לפי מיקום תוכלו לקרוא מידע נוסף.
- זמינות של סוגי מכונות ב-Compute Engine בכל אזור. למידע נוסף, קראו את המאמר אזורים ותחומים.
- דרישות זמן אחזור של משתמשי קצה.
- עלות המשאבים של Google Cloud .
- עלויות העברת נתונים בין אזורים.
- דרישות רגולטוריות.
- דרישות בנושא קיימוּת.
חלק מהגורמים והדרישות האלה עשויים להיות כרוכים בפשרות. לדוגמה, יכול להיות שהאזור הכי משתלם מבחינת עלות הוא לא האזור עם טביעת הרגל הפחמנית הכי נמוכה. למידע נוסף, קראו את המאמר שיטות מומלצות לבחירת אזורים ב-Compute Engine.
תשתית המחשוב
ארכיטקטורת העזר במאמר הזה משתמשת במכונות וירטואליות של Compute Engine בשכבות מסוימות של האפליקציה. בהתאם לדרישות של האפליקציה, אתם יכולים לבחור מבין שירותי המחשוב האחרים של Google Cloud :
- קונטיינרים: אתם יכולים להריץ אפליקציות בקונטיינרים באשכולות של Google Kubernetes Engine (GKE). GKE הוא מנוע לתזמור קונטיינרים, שמאפשר לבצע אוטומציה של פריסה, התאמה לעומס וניהול של אפליקציות בקונטיינרים.
- בלי שרת (serverless): אם אתם מעדיפים להתמקד בנתונים ובאפליקציות במקום להגדיר ולהפעיל משאבי תשתית, אתם יכולים להשתמש בשירותים בלי שרת (serverless) כמו Cloud Run.
ההחלטה אם להשתמש במכונות וירטואליות, בקונטיינרים או בשירותים בלי שרת (serverless) כרוכה בפשרה בין גמישות ההגדרה לבין מאמצי הניהול. מכונות וירטואליות ומאגרים מספקים גמישות רבה יותר בהגדרות האישיות, אבל אתם אחראים לניהול המשאבים. בארכיטקטורה בלי שרת (serverless), אתם פורסים עומסי עבודה בפלטפורמה שהוגדרה מראש ודורשת מאמץ ניהולי מינימלי. למידע נוסף על בחירת שירותי מחשוב שמתאימים לעומסי העבודה שלכם ב-Google Cloud, קראו את המאמר אירוח אפליקציות ב- Google Cloud.
אפשרויות אחסון
במכונות הווירטואליות של Compute Engine בארכיטקטורה, אתם יכולים להשתמש בנפחי אתחול של Google Cloud Hyperdisk או של Persistent Disk. אמצעי אחסון ב-Hyperdisk מספקים ביצועים, גמישות ויעילות טובים יותר מאשר Persistent Disk. באמצעות Google Cloud Hyperdisk Balanced, אתם יכולים להקצות IOPS וקצב העברת נתונים בנפרד ובאופן דינמי, וכך להתאים את הנפח למגוון רחב של עומסי עבודה.
כדי לאחסן קובצי אפליקציה בינאריים, משתמשים ב-Filestore. קבצים שמאוחסנים במכונה של Filestore Regional משוכפלים באופן סינכרוני בשלושה אזורים בתוך האזור. השכפול הזה עוזר להבטיח זמינות גבוהה ועמידות בפני הפסקות זמניות בשירות באזורים. כדי להגן על המערכת מפני הפסקות חשמל באזור, אתם יכולים לשכפל מכונה של Filestore לאזור אחר. מידע נוסף זמין במאמר רפליקציה של מכונות.
כשאתם מתכננים את האחסון לעומסי העבודה, כדאי להביא בחשבון את המאפיינים הפונקציונליים של עומסי העבודה, את דרישות העמידות, את הציפיות לגבי הביצועים ואת יעדי העלות. מידע נוסף זמין במאמר תכנון אסטרטגיית אחסון אופטימלית לעומסי העבודה בענן.
תכנון הרשת של Oracle Database@Google Cloud
בוחרים עיצוב רשת שעונה על הדרישות העסקיות והטכניות שלכם. לדוגמה, אתם יכולים להשתמש ברשת VPC אחת או בכמה רשתות VPC. מידע נוסף זמין במאמר מידע ולמידה על בחירת הטופולוגיה של הרשת ל-Oracle Database@Google Cloud.
כשמקצים טווחי כתובות IP לרשתות המשנה של הלקוח ושל הגיבוי שישמשו את אשכולות ה-VM של Exadata, חשוב להביא בחשבון את דרישות הגודל המינימלי של רשת המשנה. מידע נוסף זמין במאמר תכנון מרחב כתובות ה-IP ב-Oracle Database@Google Cloud.
העברה של מסדי נתונים
כשאתם מתכננים להעביר מסדי נתונים מקומיים ל-Oracle Database@Google Cloud, אתם יכולים להשתמש בכלי Database Migration Assessment (DMA) כדי להעריך את סביבת מסד הנתונים הנוכחית ולקבל המלצות להגדרה ולגודל.
במאמר Oracle Migration Methods Advisor מוסבר על התהליך והכלים שבהם אפשר להשתמש כדי להעביר מסדי נתונים של Oracle אל Google Cloud.
לפני שמשתמשים במסדי הנתונים שהועברו בסביבת ייצור, צריך לוודא את הקישוריות מהאפליקציות למסדי הנתונים.
אבטחה, פרטיות ותאימות
בקטע הזה מתוארים הגורמים שצריך להביא בחשבון כשמשתמשים בארכיטקטורה לדוגמה הזו כדי לתכנן טופולוגיה ב- 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.
לגבי רשתות המשנה שמשמשות את המכונות הווירטואליות של Exadata, Oracle ממליצה להקצות טווחים של כתובות IP פרטיות.
הרשאות של חשבון שירות
במכונות הווירטואליות של Compute Engine בארכיטקטורה, במקום להשתמש בחשבונות השירות שמוגדרים כברירת מחדל, מומלץ ליצור חשבונות שירות ייעודיים ולציין את המשאבים שחשבון השירות יכול לגשת אליהם. לחשבון השירות שמוגדר כברירת מחדל יש מגוון רחב של הרשאות, כולל כאלה שלא בהכרח נדרשות. אתם יכולים להתאים אישית חשבונות שירות ייעודיים כך שיהיו להם רק ההרשאות החיוניות. למידע נוסף, קראו את המאמר הגבלת ההרשאות של חשבון שירות.
אבטחת SSH
כדי לשפר את האבטחה של חיבורי SSH למכונות הווירטואליות של Compute Engine בארכיטקטורה, צריך להטמיע את Identity-Aware Proxy (IAP) ואת Cloud OS Login API. באמצעות IAP אפשר לשלוט בגישה לרשת על סמך זהות המשתמש וכללי המדיניות של ניהול זהויות והרשאות גישה (IAM). באמצעות Cloud OS Login API אפשר לשלוט בגישת SSH ל-Linux על סמך זהות המשתמש ומדיניות IAM. למידע נוסף על ניהול הגישה לרשת, קראו את המאמר שיטות מומלצות לבקרת הגישה להתחברות באמצעות SSH.
הצפנת נתונים
כברירת מחדל, הנתונים שמאוחסנים ב-Hyperdisk, ב-Persistent Disk וב-Filestore מוצפנים באמצעותGoogle-owned and Google-managed encryption keys. כדי להוסיף שכבת הגנה, אתם יכולים להצפין את Google-owned and managed key באמצעות מפתחות שבבעלותכם ובניהולכם ב-Cloud Key Management Service (Cloud KMS). מידע נוסף זמין במאמר מידע על הצפנת דיסקים לנפחי Hyperdisk ו-Persistent Disk, ובמאמר הצפנת נתונים באמצעות מפתחות הצפנה בניהול הלקוח ל-Filestore.
כברירת מחדל, מסדי הנתונים של Exadata משתמשים ב-Transparent Data Encryption (TDE), שמאפשר להצפין מידע רגיש שמאוחסן בטבלאות ובמרחבי טבלאות.
אבטחת רשת
כדי לשלוט בתנועה ברשת בין המשאבים בארכיטקטורה, צריך להגדיר כללי מדיניות מתאימים של Cloud Next Generation Firewall (NGFW).
אבטחה ותאימות ב-Oracle Exadata
Oracle Exadata Database Service כולל את Oracle Data Safe, שעוזר לנהל את דרישות האבטחה והתאימות של מסדי הנתונים של Oracle. אתם יכולים להשתמש ב-Oracle Data Safe כדי להעריך את אמצעי האבטחה, לעקוב אחרי פעילות המשתמשים ולהסתיר מידע אישי רגיש. מידע נוסף זמין במאמר ניהול אבטחת מסד הנתונים באמצעות Oracle Data Safe.
שיקולי אבטחה נוספים
כשאתם בונים את הארכיטקטורה של עומס העבודה, כדאי להביא בחשבון את השיטות המומלצות וההמלצות לאבטחה ברמת הפלטפורמה שמפורטות בתוכנית היסודות לארגונים ובGoogle Cloud Well-Architected Framework: אבטחה, פרטיות ותאימות.
אמינות
בקטע הזה מתוארים גורמי התכנון שצריך להביא בחשבון כשמשתמשים בארכיטקטורה לדוגמה הזו כדי לבנות ולהפעיל תשתית אמינה לפריסה ב-Google Cloud.
עמידות בפני כשלים במכונות וירטואליות
בארכיטקטורה שמוצגת במסמך הזה, אם מכונה וירטואלית של Compute Engine בשכבת האינטרנט או בשכבת האפליקציה קורסת, קבוצת המכונות המנוהלת הרלוונטית יוצרת מחדש את המכונה הווירטואלית באופן אוטומטי. מאזני העומסים מעבירים בקשות רק למכונות הזמינות של שרת האינטרנט ולמכונות של שרת האפליקציות.
תיקון אוטומטי של מכונות וירטואליות
לפעמים המכונות הווירטואליות שמארחות את האפליקציה פועלות וזמינות, אבל יש בעיות באפליקציה עצמה. יכול להיות שהאפליקציה תקפא, תקרוס או שלא יהיה לה מספיק זיכרון. כדי לוודא שאפליקציה מגיבה כצפוי, אפשר להגדיר בדיקות תקינות שמבוססות על אפליקציות כחלק ממדיניות התיקון האוטומטי של קבוצות ה-MIG. אם האפליקציה במכונה וירטואלית מסוימת לא מגיבה, ה-MIG מתקן את המכונה הווירטואלית באופן אוטומטי. מידע נוסף על הגדרת תיקון אוטומטי זמין במאמר תיקון מכונות וירטואליות לזמינות גבוהה.
עמידות בפני הפסקות חשמל באזור
אם יש הפסקה זמנית בשירות באזור, האפליקציה לא זמינה. כדי לצמצם את זמן ההשבתה שנגרם כתוצאה מהפסקות זמניות בשירות באזור, אפשר ליישם את הגישה הבאה:
- שמירה על רפליקה פסיבית (יתירות כשל) של שכבת האינטרנט ושכבת האפליקציה באזור אחר של Google Cloud .
- יוצרים מכונה של תשתית Exadata במצב המתנה עם אשכולות ה-VM הנדרשים של Exadata באותו אזור שבו נמצא הרפליקה הפסיבית של סטאק האפליקציה. משתמשים ב-Oracle Data Guard כדי לשכפל נתונים ולהגדיר יתירות כשל אוטומטית למסדי הנתונים של Exadata במצב המתנה. אם האפליקציה שלכם צריכה יעד להתאוששות מאסון (RPO) נמוך יותר, אתם יכולים לגבות ולשחזר את מסדי הנתונים באמצעות Oracle Autonomous Recovery Service.
- אם מתרחשת הפסקה באזור הראשי, משתמשים ברפליקה או בגיבוי של מסד הנתונים כדי לשחזר את מסד הנתונים לסביבת הייצור ולהפעיל את האפליקציה באזור של יתירות הכשל.
- משתמשים במדיניות הניתוב של DNS כדי לנתב את התנועה למאזן עומסים חיצוני באזור של יתירות הכשל.
לאפליקציות קריטיות לעסק שחייבות להמשיך לפעול גם כשיש הפסקה זמנית בשירות באזור מסוים, כדאי להשתמש בארכיטיפ של פריסה במספר אזורים. אתם יכולים להשתמש ב-Oracle Active Data Guard כדי לספק מסד נתונים לקריאה בלבד במצב המתנה באזור של יתירות הכשל.
Oracle מנהלת את התשתית ב-Oracle Database@Google Cloud. למידע על יעדי רמת השירות (SLO) של Oracle Exadata Database Service on Dedicated Infrastructure, קראו את המאמר Service Level Objectives for Oracle PaaS and IaaS Public Cloud Services.
התאמה לעומס (autoscaling) ב-MIG
הארכיטקטורה במסמך הזה משתמשת בקבוצות MIG אזוריות לשכבת האינטרנט ולשכבת האפליקציה. היכולת של קבוצות MIG ללא שמירת מצב להתאים את עצמן לעומס מבטיחה שהמכונות הווירטואליות של Compute Engine שמארחות את שכבת האינטרנט ואת שכבת האפליקציה לא יושפעו מהפסקות זמניות בשירות באזור יחיד.
כדי לשלוט בהתנהגות של ההתאמה האוטומטית לעומס של קבוצות MIG בלי שמירת מצב, אתם יכולים לציין מדדי ניצול יעד, כמו ניצול ממוצע של המעבד (CPU). אפשר גם להגדיר התאמה אוטומטית לעומס (scaling) מבוססת-תזמון לקבוצות MIG ללא שמירת מצב. אי אפשר לשנות את קנה המידה של קבוצות MIG עם שמירת מצב באופן אוטומטי. מידע נוסף מופיע במאמר התאמה אוטומטית לעומס (autoscaling) של קבוצות מכונות.
מגבלת הגודל של MIG
כשמחליטים על הגודל של קבוצות ה-MIG, צריך להביא בחשבון את מגבלות ברירת המחדל והמגבלות המקסימליות על מספר המכונות הווירטואליות שאפשר ליצור בקבוצת MIG. מידע נוסף זמין במאמר הוספה והסרה של מכונות וירטואליות מ-MIG.
מיקום של מכונות וירטואליות
בארכיטקטורה שמתוארת במאמר הזה, שכבת האפליקציה ושכבת האינטרנט פועלות במכונות וירטואליות של Compute Engine שפזורות בכמה אזורים. ההפצה הזו עוזרת להבטיח ששכבת האינטרנט ושכבת האפליקציה יהיו עמידות בפני הפסקות חשמל באזור אחד.
כדי לשפר את העמידות של הארכיטקטורה, אפשר ליצור מדיניות למיקום מרווח ולהחיל אותה על התבנית של ה-MIG. כשה-MIG יוצר מכונות וירטואליות, הוא ממקם אותן בכל אזור בשרתים פיזיים שונים (שנקראים מארחים), כך שהמכונות הווירטואליות עמידות בפני כשלים של מארחים בודדים. מידע נוסף זמין במאמר יצירה והחלה של כללי מדיניות למיקום מרווח במכונות וירטואליות.
תכנון קיבולת של מכונות וירטואליות
כדי לוודא שהקיבולת של המכונות הווירטואליות ב-Compute Engine זמינה כשצריך להקצות אותן, אתם יכולים ליצור מקומות שמורים. הזמנה מספקת קיבולת מובטחת באזור ספציפי למספר מסוים של מכונות וירטואליות מסוג מכונה שאתם בוחרים. הזמנה יכולה להיות ספציפית לפרויקט, או משותפת לכמה פרויקטים. למידע נוסף על הזמנות, ראו בחירת סוג הזמנה.
אחסון עם שמירת מצב (stateful)
אחת מהשיטות המומלצות בתכנון אפליקציות היא להימנע מהצורך בדיסקים מקומיים עם שמירת מצב (stateful). אבל אם יש דרישה כזו, אתם יכולים להגדיר את הדיסקים הקבועים כ-stateful כדי לוודא שהנתונים יישמרו כשהמכונות הווירטואליות יתוקנו או ייווצרו מחדש. עם זאת, מומלץ להשאיר את דיסקי האתחול בלי שמירת מצב, כדי שתוכלו לעדכן אותם לתמונות העדכניות ביותר עם גרסאות חדשות ותיקוני אבטחה. מידע נוסף זמין במאמר הגדרת דיסקים קבועים עם שמירת מצב בקבוצות MIG.
קיבולת של Oracle Exadata
אתם יכולים לשנות את הגודל של Exadata Infrastructure על ידי הוספה של שרתי מסדי נתונים ושרתי אחסון לפי הצורך. אחרי שמוסיפים את שרתי מסד הנתונים או שרתי האחסון הנדרשים לתשתית Exadata, כדי להשתמש במשאבי המעבד (CPU) או האחסון הנוספים, צריך להוסיף את הקיבולת לאשכול ה-VM המשויך של Exadata. מידע נוסף זמין במאמר Scaling Exadata Compute and Storage.
עמידות הנתונים
אתם יכולים להשתמש בשירות Backup and DR כדי ליצור, לאחסן ולנהל גיבויים של מכונות וירטואליות ב-Compute Engine. הנתונים לגיבוי נשמרים ב-Backup and DR בפורמט המקורי שלהם, שניתן לקריאה על ידי האפליקציה. במקרה הצורך, אתם יכולים לשחזר עומסי עבודה לסביבת הייצור ישירות באמצעות נתונים מאחסון הגיבוי לטווח ארוך, בלי פעילויות של העברת נתונים או הכנה שגוזלות זמן. מידע נוסף זמין במאמר Backup and DR של גיבויי מכונות Compute Engine.
כדי להבטיח את עמידות הנתונים במכונות Filestore, אתם יכולים ליצור גיבויים ותמונות מצב של המכונה או להשתמש ב-Backup and DR למערכות קבצים ול-Filestore.
כברירת מחדל, גיבויים של מסדי נתונים ב-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 מספק המלצות לסוגי מכונות. אתם יכולים להשתמש בהמלצות כדי לבחור סוגי מכונות שמתאימים לדרישות המחשוב של עומס העבודה. אם אתם יכולים לחזות את דרישות המשאבים של עומסי העבודה, אתם יכולים להתאים אישית את סוג המכונה לצרכים שלכם ולחסוך כסף באמצעות סוגי מכונות בהתאמה אישית.
מודל הקצאת המשאבים של המכונה הווירטואלית
אם האפליקציה שלכם עמידה בפני תקלות, מכונות וירטואליות במחיר Spot יכולות לעזור לכם להפחית את העלויות של Compute Engine למכונות הווירטואליות בשכבות האפליקציה והאינטרנט. העלות של VM במודל Spot נמוכה משמעותית מזו של מכונות וירטואליות רגילות. עם זאת, יכול להיות ש-Compute Engine יפסיק או ימחק מכונות VM במודל Spot כדי לפנות קיבולת.
VM במודל Spot מתאימות למשימות באצווה שיכולות לסבול הפסקה זמנית, ואין להן דרישות לזמינות גבוהה. VMs במודל Spot מציעות את אותם סוגי מכונות, אפשרויות וביצועים כמו VMs רגילות. עם זאת, כשהקיבולת של המשאבים באזור מסוים מוגבלת, יכול להיות שקבוצות ה-MIG לא יוכלו להתרחב אופקית (כלומר, ליצור מכונות וירטואליות) באופן אוטומטי לגודל היעד שצוין, עד שהקיבולת הנדרשת תהיה זמינה שוב.
ניצול המשאבים של המכונה הווירטואלית
יכולת ההתאמה האוטומטית לעומס של קבוצות MIG ללא שמירת מצב מאפשרת לאפליקציה להתמודד עם עליות בתנועה בצורה חלקה, ועוזרת להפחית את העלויות כשהצורך במשאבים נמוך. אי אפשר לשנות את קנה המידה של קבוצות MIG עם שמירת מצב באופן אוטומטי.
רישיונות למוצרי Oracle
אתם אחראים לרכוש רישיונות למוצרי Oracle שאתם פורסים ב-Compute Engine, ואתם אחראים לעמוד בתנאים ובהגבלות של הרישיונות של Oracle. למידע נוסף, קראו את המאמר רישוי תוכנת Oracle בסביבת מחשוב ענן.
רישיונות למסדי נתונים של Oracle Exadata
כשיוצרים אשכול Exadata VM, אפשר להביא רישיון משלכם (BYOL) או להשתמש ברישיון שרכשתם כחלק מההזמנה ב-Google Cloud Marketplace ל-Oracle Database@Google Cloud.
המחיר של Oracle Database@Google Cloud כולל את חיובי הרשת על העברת נתונים בין האפליקציות שלכם לבין מסדי הנתונים של Oracle Exadata שנמצאים באותו אזור.
שיקולי עלות נוספים
כשאתם בונים את הארכיטקטורה של עומס העבודה, כדאי גם להביא בחשבון את השיטות המומלצות הכלליות ואת ההמלצות שמפורטות במאמר Google Cloud Well-Architected Framework: הוזלת העלויות.
יעילות תפעולית
בקטע הזה מתוארים הגורמים שצריך להביא בחשבון כשמשתמשים בארכיטקטורה לדוגמה הזו כדי לתכנן טופולוגיית Google Cloud שאפשר להפעיל ביעילות.
עדכונים בהגדרות של המכונה הווירטואלית
כדי לעדכן את ההגדרות של המכונות הווירטואליות בקבוצת MIG (למשל, סוג המכונה או קובץ האימג' של דיסק האתחול), יוצרים תבנית חדשה של הגדרות מכונה עם ההגדרות הנדרשות, ואז מחילים את התבנית החדשה על קבוצת ה-MIG. קבוצת ה-MIG מעדכנת את המכונות הווירטואליות באמצעות שיטת העדכון שבחרתם: אוטומטית או סלקטיבית. בחרו שיטה מתאימה בהתאם לדרישות שלכם לגבי זמינות ויעילות תפעולית. מידע נוסף על השיטות האלה לעדכון קבוצות MIG מופיע במאמר החלת הגדרות חדשות של מכונות וירטואליות בקבוצת MIG.
תמונות של Oracle Linux
למכונות הווירטואליות שלכם, אתם יכולים להשתמש בתמונות של Oracle Linux שזמינות ב-Compute Engine, או לייבא תמונות של Oracle Linux שאתם יוצרים ומתחזקים.
אתם יכולים גם ליצור ולהשתמש בקובצי אימג' של מערכת הפעלה בהתאמה אישית שכוללים את ההגדרות והתוכנות שהאפליקציות שלכם צריכות. אפשר לקבץ את התמונות בהתאמה אישית למשפחת תמונות בהתאמה אישית. משפחת תמונות תמיד מצביעה על התמונה הכי עדכנית במשפחה, כך שהתבניות של הגדרות המכונה והסקריפטים יכולים להשתמש בתמונה הזו בלי שתצטרכו לעדכן את ההפניות לגרסת תמונה ספציפית. חשוב לעדכן באופן קבוע את קובצי האימג' המותאמים אישית כדי לכלול את עדכוני האבטחה והתיקונים שמספק ספק מערכת ההפעלה.
תבניות דטרמיניסטיות של הגדרות מכונה
אם התבניות של הגדרות המכונה שבהן אתם משתמשים בקבוצות ה-MIG כוללות סקריפטים לטעינה בזמן ההפעלה כדי להתקין תוכנות צד שלישי, ודאו שהסקריפטים מציינים במפורש את הפרמטרים של התקנת התוכנה, כמו גרסת התוכנה. אחרת, כשהתוכנה מותקנת במכונות הווירטואליות שנוצרות על ידי ה-MIG, יכול להיות שהיא לא תהיה עקבית. לדוגמה, אם תבנית של הגדרות מכונה כוללת סקריפט לטעינה בזמן ההפעלה שמתקין את Apache HTTP Server 2.4 (החבילה apache2), צריך לוודא שהסקריפט מציין את הגרסה המדויקת של apache2 שצריך להתקין, כמו גרסה 2.4.69. מידע נוסף זמין במאמר תבניות דטרמיניסטיות של הגדרות מכונה.
ניהול מסד נתונים של Oracle Exadata
Oracle מנהלת את השרתים הפיזיים של מסדי הנתונים, שרתי האחסון וחומרת הרשת ב-Oracle Exadata Database Service on Dedicated Infrastructure. אתם יכולים לנהל את המכונות של Exadata Infrastructure ואת אשכולות המכונות הווירטואליות של Exadata דרך הממשקים של OCI או של Google Cloud . אתם יוצרים ומנהלים מסדי נתונים דרך ממשקי OCI. בדפי מסוף Google Cloud של Oracle Database@Google Cloud יש קישורים שאפשר להשתמש בהם כדי לעבור ישירות לדפים הרלוונטיים במסוף OCI. כדי שלא תצטרכו להיכנס שוב ל-OCI, אתם יכולים להגדיר איחוד שירותי אימות הזהות בין OCI ל- Google Cloud.
ניראות של אפליקציות Oracle
כדי להטמיע יכולת תצפית בעומסי עבודה של Oracle שנפרסו ב- Google Cloud, אתם יכולים להשתמש בשירותי Google Cloud Observability או ב-Oracle Enterprise Manager. בחרו אסטרטגיית מעקב שמתאימה לדרישות ולאילוצים שלכם. לדוגמה, אם אתם מריצים עומסי עבודה אחרים ב- Google Cloud בנוסף לעומסי העבודה של Oracle, אתם יכולים להשתמש בשירותי Google Cloud Observability כדי ליצור לוח בקרה מאוחד למעקב אחרי כל עומסי העבודה.
מסמכי תיעוד ותמיכה של Oracle
מוצרי Oracle שפועלים במכונות וירטואליות של Compute Engine דומים מבחינה תפעולית למוצרי Oracle שפועלים באופן מקומי. עם זאת, אתם לא צריכים לנהל את התשתית הבסיסית של המחשוב, הרשת והאחסון. לקבלת הנחיות לגבי הפעלה וניהול של מוצרי Oracle, עיינו במסמכי התיעוד הרלוונטיים של Oracle.
למידע על מדיניות התמיכה של Oracle במכונות של מסדי נתונים של Oracle שאתם פורסים ב- Google Cloud, קראו את המאמר Oracle Database Support for Non-Oracle Public Cloud Environments (Doc ID 2688277.1).
שיקולים תפעוליים נוספים
כשאתם בונים את הארכיטקטורה של עומס העבודה, כדאי להביא בחשבון את השיטות המומלצות הכלליות ואת ההמלצות ליעילות תפעולית שמתוארות במאמר Google Cloud Well-Architected Framework: מצוינות תפעולית.
אופטימיזציה של הביצועים
בקטע הזה מתוארים הגורמים שצריך להביא בחשבון כשמשתמשים בארכיטקטורה לדוגמה כדי לתכנן טופולוגיה ב- Google Cloud שעומדת בדרישות הביצועים של עומסי העבודה.
ביצועי המחשוב
ב-Compute Engine יש מגוון רחב של סוגי מכונות מוגדרים מראש ובהתאמה אישית, לעומסי העבודה שאתם מריצים במכונות וירטואליות. בוחרים סוג מכונה שמתאים לדרישות הביצועים שלכם. למידע נוסף, קראו את המדריך להשוואה בין משפחות של מכונות ומשאבים.
ריבוי הליכי משנה (multithreading) של VM
כל מעבד וירטואלי (vCPU) שאתם מקצים למכונה וירטואלית ב-Compute Engine מוטמע כריבוי הליכי משנה (multithread) בחומרה אחת. כברירת מחדל, שני מעבדים וירטואליים חולקים ליבת מעבד פיזית. באפליקציות שכוללות פעולות מקבילות מאוד או שמבצעות חישובים של נקודה צפה (כמו ניתוח רצף גנטי ומודלים של סיכון פיננסי), אפשר לשפר את הביצועים על ידי הפחתת מספר השרשורים שפועלים בכל ליבת מעבד פיזית. מידע נוסף זמין במאמר הגדרת מספר הליכי המשנה לכל ליבה.
לריבוי הליכים במכונה וירטואלית עשויות להיות השלכות על הרישוי של תוכנות מסוימות של צד שלישי, כמו מסדי נתונים. למידע נוסף, קראו את מסמכי התיעוד בנושא רישוי של תוכנת הצד השלישי.
ביצועי הרשת
ב-Compute Engine יש מגבלה לכל מכונה וירטואלית על רוחב הפס של הרשת לתעבורת נתונים יוצאת. המגבלה הזו תלויה בסוג המכונה הווירטואלית, ובשאלה אם התנועה מנותבת דרך אותה רשת VPC כמו המכונה הווירטואלית המקורית. במכונות וירטואליות מסוגים מסוימים, אפשר להגדיל את רוחב הפס המקסימלי לתעבורת נתונים יוצאת על ידי הפעלת רשת Tier_1. מידע נוסף זמין במאמר הגדרת ביצועי רשת Tier_1 לכל מכונה וירטואלית.
תנועת הרשת בין המכונות הווירטואליות של האפליקציה לבין הרשת של Oracle Exadata מנותבת דרך חיבור Partner Interconnect עם זמן אחזור קצר ש-Google מגדירה.
ב-Exadata Infrastructure נעשה שימוש ב-RDMA over Converged Ethernet (RoCE) כדי לספק רוחב פס גבוה וזמן אחזור נמוך ברשת בין שרתי מסד הנתונים לשרתי האחסון. השרתים מחליפים נתונים ישירות בזיכרון הראשי (RAM) בלי לערב את המעבד, המטמון או מערכת ההפעלה.
שיקולים נוספים שקשורים לביצועים
כשאתם בונים את הארכיטקטורה של עומס העבודה, כדאי להביא בחשבון את השיטות המומלצות הכלליות ואת ההמלצות שמפורטות במאמר Google Cloud Well-Architected Framework: אופטימיזציה של הביצועים.
המאמרים הבאים
- האצת המעבר לענן באמצעות Google Cloud ו-Oracle
- מסמכי התיעוד של Oracle
- מסמכי התיעוד של Google
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחברים:
- קומאר דהנגופאל | מפתח פתרונות למוצרים שונים
- סמנתה הי | כותבת טכנית
תורמים אחרים:
- אנדי קולווין | מהנדס מסדי נתונים בכיר, Oracle ב-Google Cloud
- ג'ף וולש | מנהל, ניהול מוצר
- לי גייטס | מנהל קבוצת מוצרים
- מארק פילדינג | ארכיטקט תשתיות נתונים
- מארק שלאגנהאוף | כותב טכני, רשתות
- מישל בורטופט | מנהלת מוצר בכירה
- Rajesh Kasanagottu | מנהל הנדסה
- רוברטו מנדז | מהנדס בכיר להטמעת רשתות
- סמנתה הי | כותבת טכנית
- סקו פייג' | מנהל מוצר יוצא
- סוג'י מאדהוראפאנטולה | מנהלת קבוצת מוצרים
- ויקטור מורנו | מנהל מוצר, Cloud Networking