קבוצת זמינות Always On של Microsoft SQL Server ב-Google Cloud

Last reviewed 2026-08-12 UTC

במאמר הזה מוצגת ארכיטקטורה לדוגמה לפריסת מסדי נתונים של Microsoft SQL Server בזמינות גבוהה (HA) ב- Google Cloud באמצעות קבוצת זמינות Always On. המסמך כולל גם שיקולי תכנון לזמינות גבוהה ולהתאוששות מאסון (DR), אפשרויות פריסה, המלצות לאוטומציה והנחיות לפעולות גיבוי והתאוששות מאסון. המסמך הזה מיועד לאנשי מקצוע טכניים שבוחנים את Google Cloud כפלטפורמה להרצת מסדי נתונים של SQL Server. ההנחה היא שיש לכם ידע בסיסי ב-Compute Engine וב-SQL Server.

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

כדי להפעיל פריסה של SQL Server ב- Google Cloudשלא מיועדת לפיתוח, צריך להשתמש באחת מאפשרויות הרישוי הבאות:

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

ארכיטקטורה

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

ארכיטקטורה שמציגה פריסה של SQL Server עם קבוצת זמינות Always On שכוללת מכונות וירטואליות של Compute Engine באזורים שונים.

בארכיטקטורה שלמעלה מוצגת קבוצת זמינות Always On עם שלושה צמתים ב-Windows Server Failover Cluster (WSFC)‎. כל צומת הוא מכונה וירטואלית של Compute Engine שמריצה את SQL Server.

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

  • אין צורך ברכיבי תשתית מיוחדים: SQL Server מנהל את הרפליקציה בכל הרפליקות של מסד הנתונים שהוגדרו.
  • הגדרת ה-SLA הגבוהה ביותר ל-SQL Server: יעד זמן התאוששות (RTO) של פחות מדקה ויעד להתאוששות מאסון (RPO) קרוב לאפס.
  • היכולת להעביר עומסי עבודה לקריאה בלבד לרפליקות משניות: הרחבה יעילה של הפריסה לניתוח נתונים ולתרחישים נפוצים אחרים.
  • צמתים באזורים נוספים עבור DR: פריסה של רפליקה ראשית ועד שמונה רפליקות משניות.
  • אפשר לפרוס ב-Windows וב-Linux: אתם יכולים להשתמש בכלי של צד שלישי כמו Pacemaker בתור התוכנה לניהול אשכולות בפריסות של Linux.

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

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

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

הארכיטקטורה משתמשת במוצרים וברכיבים הבאים של Google Cloud ושל מיקרוסופט.

Google Cloud מוצרים

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

מוצרים ורכיבים של מיקרוסופט

הרכיבים הבאים כלולים או מופעלים בצומתי SQL Server:

  • ‫Windows Server (גרסה 2019 ואילך).
  • ‫WSFC: קבוצה של מכונות SQL Server שמותקנות בכמה צמתים של אשכולות Windows Server או בכמה רשתות משנה.
  • קבוצת זמינות Always On: חלופה ברמה שמתאימה לארגונים ל-HA ול-DR, במקום שיקוף של מסד הנתונים.
  • מאזין לקבוצת זמינות: שם רשת וירטואלית (VNN) שלקוחות יכולים להשתמש בו כדי לגשת למסד נתונים ברפליקה ראשית או משנית של קבוצת זמינות Always On. הלקוחות לא צריכים לדעת את השם הפיזי של המכונה של הרפליקות. מכיוון שהמאזין מנתב את התנועה, אין צורך לשנות את מחרוזת החיבור של הלקוח אחרי יתירות כשל.

כדי לפרוס את הארכיטקטורה הזו, נדרשים הרכיבים הנוספים הבאים:

  • Active Directory Domain Services: שירות ספריות של Windows Server לניהול משאבים שמשותפים לדומיין, כמו מחשבים, תפקידים ומשתמשים.
  • DNS: שרת שמתרגם שמות דומיינים לכתובות IP תואמות.
  • עדות קוורום: יכולה להיות פרוטוקול SMB לשיתוף קבצים או דיסק משותף שמחובר באופן מקומי.

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

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

אמינות

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

בחירת אסטרטגיית HA ו-DR

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

כשמתכננים את אסטרטגיית הזמינות הגבוהה וההתאוששות מאסון לפריסת SQL Server, חשוב להביא בחשבון את הגורמים הבאים:

  • RPO: כמה נתונים אפשר לאבד במקרה של כשל?
  • ‫RTO: אחרי תקלה, תוך כמה זמן מסד הנתונים צריך לחזור לפעול?
    • כדי להשיג RTO נמוך, השתמשו בקבוצת זמינות Always On.
    • אם זמן השבתה מסוים מקובל, שחזרו את מסדי הנתונים מגיבויים או השתמשו בהעברת יומנים עם יתירות כשל ידנית.
  • ‫Budget: כדאי לשקול את היתרונות והחסרונות של עלות לעומת אמינות.
    • עלות גבוהה אבל אמינות: שימוש בקבוצת זמינות Always On עם רפליקציה אסינכרונית לצמתים נוספים באזור DR. תכננו תשתית ורישיונות מיותרים.
    • עלות בינונית: הטמעה של רפליקציית דיסק אסינכרונית לאזור אחר או שימוש ב-Backup and DR.
    • עלות נמוכה אבל זמן שחזור ארוך: גיבוי מסדי הנתונים בקטגוריה של Cloud Storage במספר אזורים.
  • סוגי כשלים: באילו סוגי כשלים צריך לטפל?
    • כדי לטפל בכשלים ברמת החומרה, ברמת המכונה וברמת האזור, אפשר להשתמש בקבוצות זמינות.
    • כדי להתאושש מהפסקות זמניות בשירות או מאסונות שמשפיעים על כל האתר, צריך פתרון DR שמפוזר גיאוגרפית, כמו העברת יומנים או קבוצות זמינות של Always On עם שכפול אסינכרוני של מסד הנתונים.
  • חשיבות עסקית: עד כמה האפליקציה קריטית לעסק?
    • באפליקציות קריטיות לארגון צריך אסטרטגיה שמספקת את רמת הזמינות הגבוהה ביותר, אובדן נתונים מינימלי והתאוששות מהירה.
    • במערכות פחות קריטיות, כדאי לשקול אסטרטגיה שמניחה זמן השבתה קביל או אובדן נתונים מסוים.

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

  1. האם הגיבויים מחוץ לאתר עומדים ביעדי ה-RPO וה-RTO?
    • כן: משתמשים בגיבויים מחוץ לאתר או ב-log shipping.
    • לא: עוברים לשאלה הבאה.
  2. האם ה-RTO או ה-RPO שלכם קצרים מדקה?
    • כן (RPO קרוב לאפס): שימוש בקבוצת זמינות של SQL Server Always On עם רפליקה של מסד נתונים להתאוששות מאסון.
    • לא: עוברים לשאלה הבאה.
  3. מהו יעד זמן ההתאוששות (RTO) שלכם?
    • פחות מ-5 דקות: משתמשים בקבוצת זמינות של SQL Server Always On עם רפליקה אסינכרונית של הדיסק.
    • שעה או יותר: עוברים לשאלה הבאה.
  4. מהו ה-RPO שלכם?
    • פחות משעתיים: שימוש בקבוצת זמינות Always On של SQL Server עם Backup and DR.
    • שמונה שעות או יותר: השתמשו בגיבויים מחוץ לאתר או בהעברת יומנים.

בחירת אפשרויות גיבוי מתאימות

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

  • גיבוי ישיר לקטגוריה של Cloud Storage: כותבים גיבויים של מסדי נתונים ישירות ל-Cloud Storage באמצעות הפקודה BACKUP TO URL ומחבר S3 ב-SQL Server (גרסה 2022 ואילך). בסביבות ייצור, אפשר להשתמש במפתח גישה של קוד אימות הודעות מבוסס-גיבוב (HMAC). אפשרות הגיבוי הזו מספקת הגנה משתלמת למסדי נתונים וליומנים, בלי צורך באחסון מקומי זמני.
  • קובצי snapshot מואצים של Compute Engine: יצירת קובצי snapshot בו-זמנית בכמה דיסקים (לדוגמה, בדיסקים של Google Cloud Hyperdisk Balanced) תוך פחות משנייה, באמצעות פעולות הקפאה והפשרה של Transact-SQL‏ (T-SQL) בשילוב עם קבוצות של אפליקציות עקביות ב-Compute Engine. האפשרות הזו מאפשרת גיבויים ברמת המכונה הווירטואלית עם ביצועים גבוהים למסדי נתונים עם כמה דיסקים, והיא דורשת הקפאת כתיבה כמעט אפסית.
  • ‫Backup and DR: תזמור של קבוצות אפליקציות עקביות באמצעות ספקי Microsoft VSS וקבוצות עקביות. אפשרות הגיבוי הזו מתאימה כשצריך שחזור מערכת מנקודה מסוימת בזמן (PITR) של כמה מסדי נתונים, וגם את היכולת להשתמש ביומנים כדי להריץ קדימה מסדי נתונים.
  • ‫Google Cloud NetApp Volumes: יצירת קובצי snapshot מיידיים וגיבויים אסינכרוניים לכספות מרוחקות באמצעות מנוע האחסון ONTAP. אנחנו ממליצים על NetApp Volumes לאפליקציות ארגוניות שרגישות לזמן אחזור, ודורשות צמצום מהיר של מתקפות כופרה ושיבוטים שחוסכים במקום.

בפריסות מרובות עננים והיברידיות שצריכות מדיניות אחידה להגנה על נתונים, אתם יכולים לבחור מוצר גיבוי של צד שלישי כמו Veeam,‏ Veritas NetBackup או Cohesity.

תפעול

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

  • עוקבים באופן רציף אחרי מדדים של משאבי ליבה, כמו ניצול המעבד (CPU) ועומס הזיכרון. כדאי להגדיר התראות בסיסיות כדי לזהות עומס על המשאבים לפני שמתחילה ירידה בביצועים של השאילתות.
  • כדי למנוע עצירות בכתיבה למסד הנתונים, צריך לעקוב באופן רציף אחרי ניצול המקום בכונן. מעקב אחרי הסטטוס הכללי של השירות והגדרת התראות כדי לקבל הודעות כשמסדי נתונים מפסיקים לפעול באופן בלתי צפוי.
  • בפריסות עם זמינות גבוהה, עקבו אחרי כל מעבר לא מתוכנן לגיבוי במקרה של כשל, וודאו שיש לכם הרשאות גישה מלאות במהלך אירועים אוטומטיים של התאוששות מאסון.
  • בנוסף לטלמטריה ברמת המערכת, Google Cloud מספק חבילה נרחבת של מדדים ספציפיים למסד הנתונים, כמו מגבלות חיבור של משתמשים פעילים, זמן אחזור של שכפול ושיעורי עסקאות. כדאי לעקוב אחרי המדדים האלה כדי לבדוק את הזמינות והביצועים של מסדי הנתונים של SQL Server.
  • כדי לתעד שגיאות ברמת האפליקציה, כמו מבוי סתום, פגיעה במסד הנתונים וכשלים במשימות של הסוכן, ישירות מיומני השגיאות של SQL Server, צריך להגדיר התראות מותאמות אישית שמבוססות על יומנים ב-Logging.

אבטחה

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

אבטחת רשת ובידוד

  • כדי למנוע חשיפה חיצונית של מסדי הנתונים, פורסים את המכונות של SQL Server עם כתובות IP פרטיות בתוך VPC. משתמשים בגישה לשירותים פרטיים כדי לנתב את התנועה באופן פנימי. הגישה הזו עוזרת להבטיח שהתנועה במסד הנתונים אף פעם לא תעבור באינטרנט הציבורי.
  • כדי להגביל עוד יותר את הגישה למסדי הנתונים, מגדירים כללים מחמירים של חומת אש ב-VPC שמאפשרים תעבורת נתונים רק מתת-רשתות מורשות של אפליקציות או מבלוקים ספציפיים של CIDR.
  • כדי להגן על נתונים במעבר מפני ציתות ויירוט, צריך להטמיע קישוריות מוצפנת על ידי אכיפת TLS/SSL לכל החיבורים של מסד הנתונים.

הצפנה ושליטה במפתחות

  • כברירת מחדל, ב- Google Cloud נעשה שימוש במפתחות AES-256 בניהול Google כדי להצפין באופן אוטומטי את כל הנתונים במצב מנוחה בדיסקים של מסדי נתונים, בקבצים זמניים ובגיבויים. כדי לעמוד בדרישות של סביבות תאימות, אתם יכולים להטמיע הצפנה ברמת מסד הנתונים באמצעות היכולת הצפנת נתונים שקופה (TDE) של SQL Server.
  • כדי להבטיח את ריבונות הנתונים, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) ב-Cloud Key Management Service. מפתחות CMEK נותנים לכם שליטה קריפטוגרפית מלאה. אתם יכולים לנהל את מחזורי החיים של המפתחות, להגדיר לוחות זמנים לרוטציה אוטומטית ולבטל באופן מיידי את הגישה למסד הנתונים ולגיבויים שלו במקרה הצורך.

אימות והרשאה

  • לשלב את מסד הנתונים עם Microsoft Active Directory, או לרכז את ניהול הזהויות בכל מסדי הנתונים של SQL Server ובמשאבים אחרים שלGoogle Cloud באמצעות ניהול זהויות והרשאות גישה (IAM).
  • אחרי שיוצרים את הזהויות, צריך להחיל את העיקרון של הרשאות מינימליות כדי שלמשתמשים ולחשבונות השירות של האפליקציות יהיו רק ההרשאות שנדרשות לביצוע הפונקציות שלהם. למפות זהויות לתפקידים מפורטים במסד הנתונים של SQL Server.

הוזלת עלויות

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

כדאי לשקול את ההמלצות הבאות:

  • השבתת ריבוי הליכי משנה בו-זמניים (SMT): השבתת SMT מאפשרת להפחית ב-50% את מספר הליבות שמדווחות למטרות רישוי. אם תקצו 20% יותר מעבדים מהנדרש ואז תשביתו את ה-SMT, תוכלו לחסוך הרבה בעלויות הרישוי בלי לפגוע בביצועים. מידע נוסף זמין במאמר הגדרת מספר הליכי המשנה לכל ליבה.
  • שימוש ב-SQL Server Standard Edition: בהתאם לדרישות שלכם לזמינות גבוהה ולהתאוששות מאסון, אתם יכולים להפחית את עלות הרישוי על ידי שימוש ב-SQL Server Standard Edition במקום ב-Enterprise Edition. מידע נוסף זמין במאמר מהדורות ותכונות נתמכות של SQL Server.
  • אופטימיזציה של האחסון: ב-Google Cloud Hyperdisk יש אפשרויות שונות לדיסקים, שאפשר לבחור בהתאם לצרכים של פריסת SQL Server. ‫Hyperdisk Balanced מספק איזון בין עלות לביצועים. אתם יכולים לשנות את קצב הנתונים ואת פעולות הקלט/פלט לשנייה (IOPS) באופן עצמאי, כדי שההוצאות על התשתית יתאימו בדיוק לצורכי עומס העבודה. מידע נוסף זמין בקטע בחירת סוג מתאים של דיסק אחסון.

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

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

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

בחירת משפחת מכונות וירטואליות מתאימה

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

בוחרים משפחת מכונות וירטואליות שמתאימה לצוואר הבקבוק העיקרי בביצועים. לדוגמה, אם מסד הנתונים של SQL Server נמצא כל הזמן בשימוש גבוה ב-CPU, בחרו סוג מכונה ממשפחת המכונות המותאמות לצריכת מעבד גבוהה (compute-optimized). אם מסד הנתונים של SQL Server מציג קריאות איטיות מהדיסק, בחרו סוג מכונה עם זיכרון אופטימלי (memory-optimized).

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

משפחה וסדרה של מכונות תרחיש ראשי לדוגמה ההשפעה על הביצועים של SQL Server
לשימוש כללי (סדרת מכונות N4) איזון בין מחיר לביצועים משפחת המכונות הזו מתאימה כנקודת התחלה לרוב עומסי העבודה. סדרת מכונות N4 מספקת איזון אופטימלי בין המעבד (CPU) לזיכרון, למסדי נתונים בשימוש משולב, לאפליקציות אינטרנט ולסביבות פיתוח או בדיקה.
מותאמת לצריכת מעבד גבוהה (סדרת מכונות C3 או C4) הביצועים הכי גבוהים לכל ליבה משפחת המכונות הזו מתאימה לעומסי עבודה שמוגבלים על ידי המעבד (CPU). למסדי נתונים שמריצים שאילתות מורכבות, מעבדים כמויות גדולות של נתונים או משרתים מספר גבוה של פעולות עיבוד עסקאות אונליין (OLTP), כדאי להשתמש בסדרות המכונות C3 ו-C4. סוגי המכונות מהסדרות האלה עוזרים לצמצם באופן משמעותי את זמן הביצוע של השאילתות.
מותאמת לצריכת זיכרון גבוהה (סדרת מכונות M3 או M4) יחסים גדולים בין זיכרון ל-vCPU משפחת המכונות הזו מתאימה במיוחד לאפליקציות שדורשות הרבה זיכרון. ‫SQL Server שומר נתונים ותוכניות ביצוע במטמון בזיכרון, מה שמאפשר ביצועים טובים יותר מאשר קריאה מדיסקים. במסדי נתונים גדולים מאוד או במחסני נתונים לעיבוד אנליטי אונליין (OLAP), השאילתות בדרך כלל סורקות טבלאות ומערכי נתונים גדולים. במקרים כאלה, זיכרון גדול יותר עוזר לשפר את הביצועים.

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

בחירת סוג מתאים של דיסק אחסון

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

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

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

סוג הדיסק מאפייני ביצועים התאמה לעומס העבודה
דיסק מתמיד שמבוסס על SSD‏ (pd-ssd) ביצועים בינוניים עד גבוהים, בהתאם לסוג המכונה הווירטואלית ולגודל הדיסק עומסי עבודה שדורשים ביצועים שמותאמים לגודל הדיסק ולמעבדי ה-vCPU של המכונה הווירטואלית. מידע נוסף זמין במאמר סקירה כללית על הביצועים של Persistent Disk.
Hyperdisk Balanced ביצועים גבוהים עם תפוקה ופעולות קלט/פלט לשנייה (IOPS) שניתנות להגדרה קבצי נתונים ויומנים של SQL Server בסביבת הייצור. ב-Hyperdisk Balanced אפשר להגדיר את IOPS ואת התפוקה בלי קשר לגודל הדיסק, ובהתאם לצורכי עומס העבודה.
Google Cloud Hyperdisk Extreme ביצועים גבוהים מאוד עם IOPS שניתן להגדרה עומסי עבודה של OLTP מתקדמים וחיוניים שדורשים IOPS מקסימלי וזמן אחזור מינימלי, כמו מערכות פיננסיות או מערכות מסחר אלקטרוני בקנה מידה גדול.
SSD מקומי הערכים הגבוהים ביותר של IOPS וקצב העברת נתונים בהשוואה לסוגי הדיסקים האחרים נתונים זמניים שלא צריכים את העמידות של דיסקים של אחסון מתמיד (persistent disks). לנתונים כמו מסד הנתונים של מערכת tempdb וקובץ הדף של Windows, כונני SSD מקומיים מספקים את זמן האחזור הקצר ביותר כי הם מחוברים פיזית למכונות הווירטואליות.

התאמת התשתית לדרישות הביצועים

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

תרחיש דרישות לגבי ביצועים סוג המכונה והגדרת הדיסק המומלצים
מסד נתונים של מסחר אלקטרוני עם נפח עסקאות גבוה ל-OLTP ‫IOPS גבוה כדי לטפל באלפי פעולות קריאה וכתיבה קטנות בו-זמנית

סוג המכונה הווירטואלית: בוחרים מכונה וירטואלית מותאמת לצריכת מעבד גבוהה (compute-optimized) (לדוגמה, מסדרת המכונות C4) כדי לעבד טרנזקציות ביעילות.

דיסקים של נתונים ויומנים: משתמשים בדיסקים מסוג Hyperdisk Balanced. מקצים רמה גבוהה של IOPS כדי לעמוד בדרישות של הטרנזקציות. השתמשו בדיסקים נפרדים לנתונים וליומנים.

‫tempdb: שימוש בדיסקי SSD מקומיים כדי להעביר פעולות זמניות ולמקסם את הביצועים.
מחסן נתונים (data warehouse) של החברה ל-OLAP תפוקה גבוהה לסריקה וצבירה של טרה-בייטים של נתונים לצורך דיווח

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

דיסק נתונים: משתמשים בדיסקים מסוג Hyperdisk Balanced. הקצאת קצב העברת נתונים גבוה כדי להאיץ סריקות של נתונים גדולים.
שרת פיתוח או שרת Staging יעילות כלכלית במקום ביצועים מקסימליים

סוג מכונה וירטואלית: בחרו מכונה וירטואלית לשימוש כללי בגודל קטן מסדרת המכונות E2 או סדרת מכונות N4.

דיסקים: משתמשים בדיסק אחסון מתמיד מאוזן (pd-balanced) לכל קובצי מסד הנתונים, כדי להשיג ביצועים סבירים בעלות נמוכה.

פריסה

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

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

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

מחברים:

משתתף נוסף: Kumar Dhanagopal | מפתח פתרונות חוצי-מוצרים