אפליקציה ארגונית עם Oracle Database ב-Compute Engine

Last reviewed 2025-08-13 UTC

במסמך הזה מוצגת ארכיטקטורה לדוגמה, שתעזור לכם לבנות את התשתית לאירוח אפליקציה ארגונית בזמינות גבוהה שמשתמשת במסד נתונים של Oracle, כשכל ה-stack פרוס במכונות וירטואליות של Compute Engine. אתם יכולים להשתמש בארכיטקטורה לדוגמה הזו כדי לארח מחדש (lift and shift) ביעילות אפליקציות מקומיות שמשתמשות במסדי נתונים של Oracle ב- Google Cloud. בנוסף, המסמך כולל הנחיות שיעזרו לכם לבנות טופולוגיה של מסד נתונים של Oracle ב-Google Cloud שעומדת בדרישות של ארכיטקטורת הזמינות המקסימלית (MAA) של Oracle. המסמך הזה מיועד למומחי Cloud Architect ולאדמינים של מסדי נתונים ב-Oracle. ההנחה במאמר היא שאתם מכירים את Compute Engine ואת מסד הנתונים של Oracle.

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

ארכיטקטורה

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

אפליקציה ארגונית עם כמה שכבות משתמשת במסד נתונים של Oracle במכונות וירטואליות של 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 בשני אזורים. כל מכונה וירטואלית מארחת מכונה עצמאית של שרת האפליקציה.
מכונות של Oracle Database שנפרסו במכונות וירטואליות של Compute Engine האפליקציה בארכיטקטורה הזו משתמשת בזוג מכונות של מסד נתונים של Oracle, אחת ראשית ואחת לגיבוי, שנפרסות במכונות וירטואליות של Compute Engine באזורים נפרדים. אתם מביאים את הרישיונות שלכם (BYOL) למכונות של Oracle Database, ומנהלים את המכונות הווירטואליות ואת המכונות של מסד הנתונים.
מאגרי אחסון של Google Cloud Hyperdisk המכונות הווירטואליות בכל אזור (בכל השכבות במקבץ האפליקציות) משתמשות בנפחי Google Cloud Hyperdisk Balanced מתוך Google Cloud Hyperdisk Storage Pool. יצירה וניהול של כל הדיסקים ב-Storage Pool אחד מאפשרים לשפר את ניצול הקיבולת ולהפחית את המורכבות התפעולית, תוך שמירה על קיבולת האחסון והביצועים שהמכונות הווירטואליות צריכות.
Oracle Data Guard FSFO observer ה-observer של Oracle Data Guard Fast-Start Failover‏ (FSFO) הוא תוכנה קלה שמפעילה מעבר אוטומטי לגיבוי בעת כשל למופע של Oracle Database במצב המתנה, כשהמופע הראשי לא זמין. ה-observer פועל במכונה וירטואלית של Compute Engine באזור שונה מהאזורים שבהם נפרסו מכונות מסד הנתונים הראשי והמשני.
קטגוריה של Cloud Storage כדי לאחסן גיבויים של מכונות מסד הנתונים של Oracle, הארכיטקטורה הזו משתמשת בקטגוריה של Cloud Storage. כדי לאפשר שחזור של מסד הנתונים במהלך הפסקה זמנית בפעילות באזור, אתם יכולים לאחסן את הגיבויים באופן משוכפל גיאוגרפית בקטגוריה של שני אזורים או של מספר אזורים.
רשת VPC ותת-רשת כל המשאבים של Google Cloud בארכיטקטורה משתמשים ברשת VPC אחת וברשת משנה אחת. בהתאם לדרישות, אתם יכולים לבחור לבנות ארכיטקטורה שמשתמשת בכמה רשתות VPC או בכמה רשתות משנה. מידע נוסף זמין במאמר החלטה אם ליצור כמה רשתות VPC.
שער Cloud NAT ציבורי הארכיטקטורה כוללת שער Cloud NAT ציבורי כדי לאפשר חיבורים יוצאים מאובטחים מהמכונות הווירטואליות של Compute Engine שיש להן רק כתובות IP פנימיות.
‫Cloud Interconnect ו-Cloud VPN כדי לחבר את הרשת המקומית לרשת ה-VPC ב- Google Cloud, אתם יכולים להשתמש ב-Cloud Interconnect או ב-Cloud VPN. למידע על היתרונות היחסיים של כל גישה, קראו את המאמר בחירת מוצרים של Network Connectivity.
‫Cloud Monitoring ו-Cloud Logging בעזרת המעקב תוכלו לבחון את ההתנהגות, התקינות והביצועים של האפליקציה ושל משאבי Google Cloud . סוכן תפעול אוסף מדדים ויומנים מהמכונות הווירטואליות של Compute Engine, כולל המכונות הווירטואליות שמארחות את המכונות של מסד הנתונים של Oracle. הסוכן שולח יומנים ל-Logging ומדדים ל-Monitoring.

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

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

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

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

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

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

שיקולים שקשורים לעיצוב

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

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

עיצוב המערכת

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

בחירת אזור

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

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

עיצוב הרשת

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

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

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

אבטחת רשת

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

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

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

אמינות

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

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

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

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

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

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

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

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

  • שכבת האינטרנט ושכבת האפליקציה זמינות (ומגיבות) כי המכונות הווירטואליות נמצאות בקבוצות MIG אזוריות. קבוצות ה-MIG האזוריות מבטיחות שמכונות וירטואליות חדשות ייווצרו באופן אוטומטי באזור השני, כדי לשמור על המספר המינימלי של מכונות וירטואליות שהוגדר. מאזני העומסים מעבירים את הבקשות למכונות הווירטואליות של שרת האינטרנט ולמכונות הווירטואליות של שרת האפליקציות שזמינות.
  • אם הפסקת השירות משפיעה על האזור שבו נמצא המכונה הראשית של מסד הנתונים של Oracle, אז ה-observer של Oracle Data Guard FSFO יוזם מעבר אוטומטי לגיבוי במקרה של כשל למכונה של מסד הנתונים של Oracle במצב המתנה. הצופה של FSFO פועל במכונה וירטואלית באזור שונה מהאזורים שבהם נמצאים המכונות של מסד הנתונים הראשי ומסד הנתונים לגיבוי.
  • כדי להבטיח זמינות גבוהה של נתונים בנפחי Hyperdisk במהלך הפסקה זמנית בפעילות של אזור אחד, אתם יכולים להשתמש ב-Google Cloud Hyperdisk Balanced High Availability. כשנתונים נכתבים בנפח, נוצרת רפליקה של הנתונים באופן סינכרוני בין שני אזורים באותו מחוז.

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

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

  • שמירה על רפליקה פסיבית (יתירות כשל) של מחסנית התשתית באזור אחר של Google Cloud .

  • משתמשים בקטגוריה של Cloud Storage בשני אזורים או במספר אזורים כדי לאחסן את הגיבויים של Oracle Database. הגיבויים משוכפלים באופן אסינכרוני בשני מיקומים גיאוגרפיים לפחות. עם גיבויים משוכפלים של מסדי נתונים, הארכיטקטורה שלכם ממופה לרמת Silver של Maximum Availability Architecture (MAA)‎ של Oracle.

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

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

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

התאמה לעומס (autoscaling) ב-MIG

כדי לשלוט בהתנהגות של ההתאמה האוטומטית לעומס של קבוצות MIG בלי שמירת מצב, אתם יכולים לציין מדדי ניצול יעדים, כמו ניצול ממוצע של המעבד (CPU). אפשר גם להגדיר התאמה אוטומטית לעומס (scaling) מבוססת-תזמון לקבוצות MIG ללא שמירת מצב. אי אפשר לשנות את קנה המידה של קבוצות MIG עם שמירת מצב באופן אוטומטי. מידע נוסף מופיע במאמר התאמה אוטומטית לעומס (autoscaling) של קבוצות מכונות.

מגבלת הגודל של MIG

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

מיקום של מכונות וירטואליות

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

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

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

זמינות של אחסון בלוקים (block storage)

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

אחסון עם שמירת מצב (stateful)

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

גיבוי ושחזור

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

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

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

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

הוזלת עלויות

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

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

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

מודל הקצאת VM

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

VM במודל Spot מתאימות למשימות באצווה שיכולות לסבול הפסקה זמנית, ואין להן דרישות לזמינות גבוהה. VMs במודל Spot מציעות את אותם סוגי מכונות, אפשרויות וביצועים כמו VMs רגילות. עם זאת, כשהקיבולת של המשאבים באזור מסוים מוגבלת, יכול להיות שקבוצות ה-MIG לא יוכלו להתרחב אופקית (כלומר, ליצור מכונות וירטואליות) באופן אוטומטי לגודל היעד שצוין, עד שהקיבולת הנדרשת תהיה זמינה שוב.

ניצול המשאבים של המכונה הווירטואלית

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

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

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

ניצול משאבים של אחסון בלוקים (block storage)

הארכיטקטורה במסמך הזה משתמשת ב-Hyperdisk Storage Pool בכל אזור כדי לספק אחסון בלוקים למכונות הווירטואליות של Compute Engine. כדי לשפר את הניצול הכולל של נפח האחסון של הבלוקים ולהוזיל את העלויות, אתם יכולים להשתמש במאגרי אחסון מתקדמים, שמשתמשים בהקצאת אחסון לפי צורך (Thin Provisioning) ובטכנולוגיות לצמצום נתונים כדי לשפר את יעילות האחסון.

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

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

ניהול אחסון בלוקים (block storage)

הארכיטקטורה במסמך הזה משתמשת ב-Hyperdisk Storage Pool בכל אזור כדי לספק אחסון בלוקים למכונות הווירטואליות של Compute Engine. מאגרי אחסון ב-Hyperdisk עוזרים לפשט את ניהול האחסון. במקום להקצות ולנהל קיבולת בנפרד להרבה דיסקים, אתם מגדירים מאגר קיבולת שאפשר לשתף בין כמה עומסי עבודה באזור. אחר כך יוצרים נפחי Hyperdisk ב-Storage Pool ומצרפים את הנפחים למכונות הווירטואליות בתחום (zone). מאגר האחסון מנסה להוסיף קיבולת באופן אוטומטי כדי לוודא ששיעור הניצול לא חורג מ-80% מהקיבולת שהוקצתה למאגר.

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

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

ניהול ותמיכה של מסד נתונים של Oracle

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

  • לקבלת הנחיות לגבי הפעלה וניהול של מכונות של Oracle Database, עיינו במסמכי התיעוד שסופקו על ידי Oracle לגרסה הרלוונטית.
  • למידע על מדיניות התמיכה של Oracle במכונות של מסדי נתונים של Oracle שאתם פורסים ב- Google Cloud, קראו את המאמר Oracle Database Support for Non-Oracle Public Cloud Environments (Doc ID 2688277.1).

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

ריבוי הליכי משנה (multithreading) של VM

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

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

ביצועי הרשת

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

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

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

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

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

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

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

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

מחברים:

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

  1. למידע נוסף על שיקולים ספציפיים לאזור, קראו את המאמר מיקום גיאוגרפי ואזורים.  ↩