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

Last reviewed 2026-08-12 UTC

במאמר הזה מוצגת ארכיטקטורת הפניה לפריסת מסדי נתונים של Microsoft SQL Server עם זמינות גבוהה (HA) ב- Google Cloud באמצעות קבוצת זמינות Always On. המסמך כולל גם שיקולי עיצוב לזמינות גבוהה (HA) ולשחזור לאחר אסון (DR), אפשרויות פריסה, המלצות לאוטומציה והנחיות ל-Backup and 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 עם הגדרת HA ב- Google Cloud:

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

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

קבוצת זמינות Always On היא תבנית פריסה סטנדרטית בתחום שמאפשרת להשיג יעדי מהימנות למסדי נתונים של SQL Server שחיוניים לפעילות. קבוצות זמינות AlwaysOn מספקות זמינות גבוהה מקומית (יתירות כשל באזור) וגם יתירות כשל בין אזורים לצורך DR. תבנית הפריסה הזו היא חלופה ברמה שמתאימה לארגונים לשיקוף מסדי נתונים. קבוצת זמינות 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 שכנות (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 (שירותי דומיין של Active Directory): שירות ספריות של Windows Server לניהול משאבים שמשותפים לדומיין, כמו מחשבים, תפקידים ומשתמשים.
  • DNS: שרת שמתרגם שמות של דומיינים לכתובות IP תואמות.
  • Quorum witness: יכול להיות server message block (SMB) שיתוף קבצים או דיסק משותף שמחובר באופן מקומי.

שיקולים בתכנון

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

אמינות

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

בחירת אסטרטגיה של זמינות גבוהה (HA) והתאוששות מאסון (DR)

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

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

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

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

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

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

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

  • גיבוי ישירות לקטגוריה ב-Cloud Storage: אפשר לכתוב גיבויים של מסד הנתונים ישירות ל-Cloud Storage באמצעות הפקודה BACKUP TO URL ומחבר S3 ב-SQL Server (גרסה 2022 ואילך). בסביבות ייצור, אפשר להשתמש במפתח גישה של קוד אימות הודעות (HMAC) מבוסס-גיבוב (hash). אפשרות הגיבוי הזו מספקת הגנה משתלמת למסדי נתונים וליומנים, ללא צורך באחסון מקומי ביניים.
  • תמונות מצב מיידיות ב-Compute Engine: אפשר לצלם תמונות מצב בו-זמנית בכמה דיסקים (לדוגמה, בדיסקים מסוג Hyperdisk Balanced) תוך פחות משנייה, באמצעות פעולות הקפאה והפשרה של Transact-SQL ‏ (T-SQL) בשילוב עם קבוצות עקביות ב-Compute Engine. האפשרות הזו מאפשרת גיבויים ברמת המכונה הווירטואלית עם ביצועים גבוהים למסדי נתונים עם כמה דיסקים, והיא כמעט לא דורשת הקפאה של פעולות כתיבה.
  • ‫Backup and DR: ארגון של תמונות מצב עקביות של אפליקציות באמצעות ספקי Microsoft VSS וקבוצות עקביות. אפשרות הגיבוי הזו מתאימה כשצריך שחזור גרנולרי של כמה מסדי נתונים לנקודת זמן מסוימת (PITR), וגם כשרוצים להשתמש ביומנים כדי להעביר מסדי נתונים קדימה.
  • ‫Google Cloud NetApp Volumes: יצירת תמונות מצב מיידיות וגיבויים אסינכרוניים לכספות מרוחקות באמצעות מנוע האחסון 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 כדי להצפין אוטומטית את כל הנתונים במצב מנוחה בדיסקים של מסדי נתונים, בקבצים זמניים ובגיבויים. כדי לעמוד בדרישות של סביבות תאימות, אתם יכולים להטמיע הצפנה ברמת מסד הנתונים באמצעות היכולת transparent data encryption (TDE) של SQL Server.
  • כדי להבטיח את ריבונות הנתונים, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) ב-Cloud Key Management Service. מפתחות CMEK מאפשרים לכם שליטה מלאה בהצפנה. אתם יכולים לנהל את מחזורי החיים של המפתחות, להגדיר לוחות זמנים לרוטציה אוטומטית ולבטל באופן מיידי את הגישה למסד הנתונים ולגיבויים שלו כשצריך.

אימות והרשאה

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

הוזלת עלויות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פריסה

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

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

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

מחברים:

תורם נוסף: קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים