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

Last reviewed 2025-08-13 UTC

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

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

ארכיטקטורה

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

אפליקציה ארגונית מרובת-שכבות משתמשת ב-Oracle Database במכונות וירטואליות של Compute Engine.

הארכיטקטורה שמוצגת בתרשים הקודם כוללת את הרכיבים הבאים:

רכיב מטרה
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) מאזן העומסים החיצוני האזורי של האפליקציות מקבל בקשות ממשתמשים ומפיץ אותן למכונות הווירטואליות בשכבת האינטרנט.
כללי מדיניות האבטחה של Google Cloud Armor מדיניות האבטחה של Cloud Armor עוזרת להגן על מערך האפליקציות מפני איומים כמו התקפות מניעת שירות מבוזרות (DDoS) ופרצות אבטחה XSS‏ (cross-site scripting).
קבוצת מופעי מכונה מנוהלים (MIG) אזורית לשכבת האינטרנט שכבת האינטרנט של האפליקציה פרוסה במכונות וירטואליות של Compute Engine ששייכות לקבוצת MIG אזורית. קבוצת ה-MIG הזו היא הבק-אנד של מאזן העומסים של אפליקציות (ALB) החיצוני. קבוצת ה-MIG מכילה מכונות וירטואליות של Compute Engine בשני אזורים. כל אחת מהמכונות הווירטואליות האלה מארחת מופע עצמאי של שכבת האינטרנט של האפליקציה.
מאזן עומסים פנימי אזורי של אפליקציות (ALB) מאזן העומסים הפנימי האזורי של האפליקציות מפזר את התעבורה ממכונות וירטואליות בשכבת האינטרנט למכונות וירטואליות בשכבת האפליקציה.
קבוצת MIG אזורית לשכבת האפליקציה שכבת האפליקציה, כמו אשכול של Oracle WebLogic Server, נפרסת במכונות וירטואליות של Compute Engine שמהוות חלק מקבוצת MIG אזורית. קבוצת ה-MIG הזו היא הקצה העורפי של מאזן העומסים הפנימי של האפליקציות. ה-MIG מכיל מכונות וירטואליות ב-Compute Engine בשני תחומים. כל מכונה וירטואלית מארחת מופע עצמאי של שרת האפליקציות.
מכונות וירטואליות של Compute Engine שפריסו בהן מופעים של Oracle Database האפליקציה בארכיטקטורה הזו משתמשת בצמד ראשי-המתנה של מופעי Oracle Database שנפרסים במכונות וירטואליות של Compute Engine באזורים נפרדים. אתם מביאים את הרישיונות שלכם (BYOL) למופעי Oracle Database האלה, ומנהלים את מכונות ה-VM ואת מופעי מסד הנתונים.
מאגרי אחסון של Google Cloud Hyperdisk המכונות הווירטואליות בכל אזור (בכל השכבות במערך האפליקציות) משתמשות בנפחי Hyperdisk Balanced מ-Hyperdisk Storage Pool. יצירה וניהול של כל הדיסקים במאגר אחסון יחיד מאפשרים לשפר את ניצול הקיבולת ולצמצם את המורכבות התפעולית, תוך שמירה על קיבולת האחסון והביצועים שהמכונות הווירטואליות צריכות.
Oracle Data Guard FSFO observer הכלי Oracle Data Guard Fast-Start Failover (FSFO) observer הוא תוכנה קלה שמפעילה מעבר גיבוי אוטומטי למופע של Oracle Database במצב המתנה, כשהמופע הראשי לא זמין. המשקיף פועל במכונה וירטואלית של Compute Engine בתחום ששונה מהתחומים שבהם פועלים מופעי מסד הנתונים הראשיים ומסד הנתונים במצב המתנה.
קטגוריה של Cloud Storage כדי לאחסן גיבויים של מופעי Oracle Database, הארכיטקטורה הזו משתמשת בקטגוריה של 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 בעזרת Cloud Monitoring אפשר לעקוב אחרי ההתנהגות, התקינות והביצועים של האפליקציה ושל Google Cloud המשאבים. סוכן התפעול אוסף מדדים ויומנים ממכונות וירטואליות ב-Compute Engine, כולל המכונות הווירטואליות שמארחות את מופעי Oracle Database. הסוכן שולח יומנים אל Cloud Logging ומדדים אל Cloud Monitoring.

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

ארכיטקטורת ההפניה הזו כוללת את המוצרים הבאים Google Cloud :

  • ‫ Compute Engine: שירות מחשוב מאובטח וניתן להתאמה אישית שמאפשר ליצור ולהריץ מכונות וירטואליות בתשתית של Google.
  • Google Cloud Hyperdisk: שירות אחסון ברשת שמאפשר להקצות ולשנות את הגודל של נפחי אחסון בלוקים באופן דינמי, עם ביצועים שניתנים להגדרה וצפויים.
  • ‫ Cloud Load Balancing: חבילה של מאזני עומסים גלובליים ואזוריים, בעלי ביצועים גבוהים וניתנים להתאמה.
  • ‫ Cloud Storage: מאגר אובייקטים ללא הגבלה בעלות נמוכה, לשימוש עם סוגים שונים של נתונים. אפשר לגשת לנתונים מתוך Google Cloudומחוץ לו, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
  • ענן וירטואלי פרטי (VPC): מערכת וירטואלית שמספקת פונקציונליות של רשתות גלובליות וניתנות להרחבה עבור עומסי העבודה שלכם ב- Google Cloud . ‫VPC כולל קישור בין רשתות VPC שכנות (peering),‏ Private Service Connect, גישה לשירותים פרטיים ו-VPC משותף.
  • ‫ Google Cloud Armor: שירות אבטחת רשת שמציע כללים של חומת אש לאפליקציות אינטרנט (WAF) ועוזר להגן מפני מתקפות DDoS ומתקפות על אפליקציות.
  • ‫ Cloud 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 ושל צד שלישי שבהם אתם משתמשים, יכול להיות שיש עוד גורמים עיצוביים ושיקולים שצריך לקחת בחשבון. Google Cloud

עיצוב המערכת

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

בחירת אזור

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

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

תשתית מחשוב

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

  • קונטיינרים: אתם יכולים להריץ אפליקציות בקונטיינרים באשכולות של Google Kubernetes Engine‏ (GKE). ‫GKE הוא מנוע לתזמור קונטיינרים שמבצע אוטומטית פריסה, התאמה לעומס וניהול של אפליקציות בקונטיינרים.
  • Serverless: אם אתם מעדיפים להתמקד בנתונים ובאפליקציות שלכם במקום בהגדרה ובהפעלה של משאבי תשתית, אתם יכולים להשתמש בשירותים serverless כמו Cloud Run.

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

אפשרויות אחסון

עבור המכונות הווירטואליות של Compute Engine בארכיטקטורה, אפשר להשתמש בHyperdisk או בPersistent Disk כנפחי אתחול. נפחי Hyperdisk מספקים ביצועים טובים יותר, גמישות ויעילות בהשוואה ל-Persistent Disk. עם 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 פנימית פרטית עדיין יכולים לגשת לשירותים ולממשקי Google API מסוימים באמצעות Private Service Connect או גישה פרטית ל-Google. מידע נוסף זמין במאמר אפשרויות גישה פרטיות לשירותים.

כדי לאפשר חיבורים יוצאים מאובטחים מ Google Cloud משאבים שיש להם רק כתובות IP פרטיות, כמו מכונות וירטואליות של Compute Engine בארכיטקטורת ההפניה הזו, אפשר להשתמש ב-Secure Web Proxy או ב-Cloud NAT.

הרשאות בחשבון שירות

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

אבטחת SSH

כדי לשפר את האבטחה של חיבורי SSH למכונות וירטואליות ב-Compute Engine בארכיטקטורה שלכם, כדאי להטמיע את Identity-Aware Proxy‏ (IAP) ואת Cloud OS Login API. ‫IAP מאפשר לכם לשלוט בגישה לרשת על סמך זהות המשתמשים ומדיניות ניהול הזהויות והרשאות הגישה (IAM). ‫Cloud OS Login API מאפשר לכם לשלוט בגישת SSH ל-Linux על סמך זהות המשתמש ומדיניות IAM. מידע נוסף על ניהול גישה לרשת זמין במאמר שיטות מומלצות לשליטה בגישה להתחברות באמצעות SSH.

הצפנת דיסק

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

אבטחת רשת

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

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

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

אמינות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

התאמה אוטומטית לעומס (autoscaling) של MIG

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

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

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

מיקום ה-VM

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

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

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

זמינות של אחסון בלוקים

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

אחסון שומר מצב (Stateful)

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

גיבוי ושחזור

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

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

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

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

הוזלת עלויות

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

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

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

מודל הקצאת הרשאות ל-VM

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

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

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

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

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

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

ניצול משאבים של אחסון בלוקים

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

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

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

יעילות תפעולית

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

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

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

תמונות של Oracle Linux

אתם יכולים להשתמש בתמונות של Oracle Linux שזמינות ב-Compute Engine, או לייבא תמונות של Oracle Linux שאתם יוצרים ומתחזקים.

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

תבניות מכונה דטרמיניסטיות

אם תבניות של הגדרות מכונה שבהן אתם משתמשים ב-MIG כוללות סקריפטים לטעינה בזמן ההפעלה כדי להתקין תוכנות של צד שלישי, חשוב לוודא שהסקריפטים מציינים באופן מפורש פרמטרים של התקנת תוכנה, כמו גרסת התוכנה. אחרת, כשקבוצת ה-MIG יוצרת את מכונות ה-VM, יכול להיות שהתוכנה שמותקנת במכונות ה-VM לא תהיה עקבית. לדוגמה, אם תבנית של הגדרות מכונה כוללת סקריפט לטעינה בזמן ההפעלה כדי להתקין את Apache HTTP Server 2.0 (החבילה apache2), צריך לוודא שהסקריפט מציין את הגרסה המדויקת של apache2 שצריך להתקין, כמו גרסה 2.4.53. מידע נוסף זמין במאמר בנושא תבניות מופעים דטרמיניסטיות.

ניהול אחסון בלוקים

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

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

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

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

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

Observability for Oracle applications

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

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

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

אופטימיזציה של הביצועים

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

ביצועי מחשוב

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

  • עבור המכונות הווירטואליות שמארחות את שכבת האינטרנט ואת שכבת האפליקציה, בוחרים סוג מכונה מתאים על סמך דרישות הביצועים של השכבות האלה. כדי לקבל רשימה של סוגי המכונות הזמינים שתומכים בנפחי אחסון של Hyperdisk ועומדים בדרישות הביצועים ובדרישות אחרות, אפשר להשתמש בטבלה השוואה בין סדרות מכונות.
  • למכונות הווירטואליות שמארחות את מופעי Oracle Database, מומלץ להשתמש בסוג מכונה מסדרת מכונות C4 ממשפחת המכונות לשימוש כללי. סוגי מכונות C4 מספקים ביצועים גבוהים באופן עקבי לעומסי עבודה של מסדי נתונים.

ריבוי שרשורים ב-VM

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

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

ביצועי הרשת

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

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

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

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

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

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

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

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

מחברים:

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

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