מידע על ביצועי המכונה

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

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

טווח קיבולת רמת שירות קיבולת ‫IOPS שהוקצו לכל TiB
טווח קיבולת נמוך יותר אזורי ‫100 GiB עד 10,239 GiB 4,000 עד 17,000
אזורי ‫1TiB עד 9.75TiB 4,000 עד 17,000
טווח קיבולת גבוה יותר אזורי ‫10TiB עד 100TiB 3,000 עד 7,500
אזורי ‫10TiB עד 100TiB 3,000 עד 7,500

הסבר על חישובי הביצועים

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

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

טווח הקיבולת מינימום ומקסימום של
IOPS שהוקצו לכל TiB
קיבולת פעולות קלט/פלט לשנייה (IOPS) של קריאה פעולות קלט/פלט לשנייה (IOPS) של כתיבה קצב העברת נתונים בקריאה (MiBps) כתיבת נתוני התפוקה (MiBps) קצב העברת נתונים בקריאה של לקוח יחיד (MiBps) קצב העברת נתונים בכתיבה של לקוח יחיד (MiBps)
טווח קיבולת נמוך יותר
(100 GiB עד 10,239 GiB)
4,000 100 GiB 2,000* 600 47 16 47 16
600 GiB 2,344 703 55 19 55 19
‫1,024 GiB 4,000 1,200 94 32 94 32
‫10,239 GiB 39,996 11,999 940 320 450 260
17,000 100 GiB 2,000 600 47 16 47 16
600 GiB 9,961 2,988 234 80 234 80
‫1,024 GiB 17,000 5,100 400 136 400 136
‫10,239 GiB 169,983 50,995 3,995 1,360 450 260
טווח קיבולת גבוה יותר
(10 TiB עד 100 TiB)
3,000 ‫10 TiB 30,000 9,000 705 240 705 240
7,500 ‫100 TiB 750,000 225,000 17,625 6,000 1,600 800

‫* כדי להשתמש במופעים של ‎1,024 GiB, צריך להפעיל ביצועים בהתאמה אישית עם מינימום של 2,000 IOPS. מידע נוסף זמין במאמר מכונות עם קיבולת קטנה.

שינוי קנה המידה של הביצועים

בתרחישים עם לקוח אחד או עם כמה לקוחות, צריך להגדיל את מספר חיבורי ה-TCP באמצעות אפשרות ההרכבה nconnect כדי להשיג ביצועים מקסימליים של NFS.

ברמות שירות ספציפיות, מומלץ לציין את מספר החיבורים הבא בין הלקוח לשרת:

רמה קיבולת מספר החיבורים
אזורי, תחום מוגדר ‫‎1-9.75 TiB nconnect=2
אזורי, תחום מוגדר ‫10 עד 100‏ TiB nconnect=7
SSD בסיסי - nconnect=7
Enterprise - nconnect=2
דיסק SSD לביצועים גבוהים - nconnect=7

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

סוג המכונה המומלץ ללקוח

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

אפשרויות טעינה של לקוח Linux

כדי להשיג את הביצועים הטובים ביותר במופעי מכונות וירטואליות של לקוחות Linux, מומלץ להשתמש באפשרויות הבאות של NFS mount, במיוחד באפשרויות hard mount, async ו-rsize ו-wsize. מידע נוסף על אפשרויות הטעינה של NFS זמין במאמר nfs.

אפשרות ברירת המחדל תיאור
hard לקוח ה-NFS מנסה שוב ושוב לשלוח בקשות NFS.
timeo=600 לקוח ה-NFS ממתין 600 עשיריות שנייה (60 שניות) לפני שהוא מנסה שוב לשלוח בקשת NFS.
retrans=3 לקוח ה-NFS מנסה לשלוח בקשות NFS שלוש פעמים לפני שהוא מבצע פעולת שחזור נוספת.
rsize=524288 לקוח ה-NFS יכול לקבל עד 524,288 בייטים משרת ה-NFS לכל בקשת READ.
הערה: במופעים ברמה הבסיסית, צריך להגדיר את הערך rsize ל-1048576.
wsize=524288 לקוח ה-NFS יכול לשלוח לשרת ה-NFS עד 524,288 בייטים לכל בקשת WRITE.
resvport לקוח ה-NFS משתמש ביציאת מקור בעלת הרשאות כשהוא מתקשר עם שרת ה-NFS לנקודת הטעינה הזו.
async לקוח ה-NFS מעכב את השליחה של כתיבות האפליקציה לשרת ה-NFS עד שמתקיימים תנאים מסוימים.
זהירות: השימוש באפשרות sync מפחית משמעותית את הביצועים.

אופטימיזציה של קצב הקריאה של NFS באמצעות הפרמטר read_ahead_kb

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

בגרסאות 5.4 ומעלה של ליבת Linux, לקוח ה-NFS של Linux משתמש בערך ברירת מחדל של 128KB ל-read_ahead_kb. מומלץ להגדיל את הערך הזה ל-20MB כדי לשפר את קצב הקריאה הרציפה.

אחרי שמתקינים בהצלחה את התיקייה המשותפת במכונה הווירטואלית של הלקוח ב-Linux, אפשר להשתמש בסקריפט הבא כדי לשנות ידנית את ערך הפרמטר read_ahead_kb:

mount_point=MOUNT_POINT_DIRECTORY
device_number=$(stat -c '%d' $mount_point)
((major = ($device_number & 0xFFF00) >> 8))
((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00)))
sudo bash -c "echo 20480 > /sys/class/bdi/$major:$minor/read_ahead_kb"

מחליפים את מה שכתוב בשדות הבאים:

‫MOUNT_POINT_DIRECTORY הוא הנתיב לספרייה שבה נמצא הקובץ המשותף.

ביצועי VM של לקוח יחיד ושל כמה לקוחות

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

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

לשם השוואה, באשכול הניתן להרחבה הקטן ביותר של Filestore יש ארבע מכונות וירטואליות. כל מכונת VM של לקוח מתקשרת רק עם מכונת VM אחת של אשכול Filestore, ללא קשר למספר חיבורי ה-NFS לכל לקוח שצוין באמצעות אפשרות ההרכבה nconnect. אם משתמשים במכונה וירטואלית אחת של לקוח, פעולות הקריאה והכתיבה מתבצעות רק ממכונה וירטואלית אחת של אשכול Filestore.

מגבלות ביצועים שמבוססות על קיבולת

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

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

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

רמת שירות קיבולת פעולות קלט/פלט לשנייה (IOPS) של קריאה פעולות קלט/פלט לשנייה (IOPS) של כתיבה קצב העברת נתונים בקריאה (MiBps) כתיבת נתוני התפוקה (MiBps) קצב העברת נתונים בקריאה של לקוח יחיד (MiBps) קצב העברת נתונים בכתיבה של לקוח יחיד (MiBps)
אזורי ‫1 TiB 9,200 2,600 260 88 260 88
9.75 TiB 89,700 25,350 2,535 858 450 260
‫‎10 TiB 92,000 26,000 2,600 880 1,600 800
‫100 TiB 920,000 260,000 26,000 8,800 1,600 800
אזורי ‫1 TiB 12,000 4,000 120 100 120 100
9.75 TiB 117,000 39,000 1,170 975 450 260
‫‎10 TiB 92,000 26,000 2,600 880 1,600 800
‫100 TiB 920,000 260,000 26,000 8,800 1,600 800
Enterprise ‫1 TiB 12,000 4,000 120 100 120 100
‫10 TiB 120,000 40,000 1,200 1,000 450 260
HDD בסיסי ‫‎1 TiB - 10 TiB 600 1,000 100 100 100 100
‫10 TiB עד 63.9 TiB 1,000 5,000 180 120 180 120
SSD בסיסי ‫2.5 TiB עד 63.9 TiB 60,000 25,000 1,200 350 1,200 350

שיפור הביצועים במשאבים Google Cloud

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

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

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

  • לשם השוואה, כדאי לבדוק את הביצועים של מכונת VM עם דיסק אחסון מתמיד (PD) שמצורף אליה, ולהשוות אותם לביצועים של מופע Filestore.

    • אם הביצועים של ה-VM שמחובר ל-PD דומים או איטיים יותר בהשוואה למכונה של Filestore, יכול להיות שיש צוואר בקבוק בביצועים שלא קשור ל-Filestore. כדי לשפר את הביצועים הבסיסיים של משאבים שהם לא של Filestore, אתם יכולים לשנות את המאפיינים של ה-CLI של gcloud שמשויכים להעלאות משולבות במקביל. מידע נוסף זמין במאמר איך כלים וממשקי API משתמשים בהעלאות מורכבות במקביל.
    • אם הביצועים של מופע Filestore איטיים באופן משמעותי מהביצועים של
      מכונת ה-VM שמחוברת ל-PD, כדאי לנסות לפצל את הפעולה בין כמה מכונות וירטואליות כדי לשפר את הביצועים של פעולות קריאה מ-Cloud Storage.

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