בדף הזה מוסבר על אפשרויות הביצועים שזמינות למופעי Filestore, ומוצגות המלצות כלליות לאופטימיזציה של הביצועים. כשמשתמשים ב- Google Cloud console כדי ליצור מופעים אזוריים ואזוריים, הביצועים המותאמים אישית מופעלים כברירת מחדל כדי לאפשר לכם להגדיל את מספר פעולות הקלט/פלט בשנייה באופן עצמאי מהקיבולת, בהתאם לצרכים הספציפיים של עומס העבודה.
בטבלה הבאה מופיע סיכום של מגבלות הביצועים לטווחים הנמוכים והגבוהים יותר של הקיבולת בהגדרות ביצועים בהתאמה אישית:
| טווח הקיבולת | רמת שירות | קיבולת | IOPS שהוקצו לכל TiB |
|---|---|---|---|
| טווח קיבולת נמוך יותר | אזורי (מכונות קטנות זמינות באזור) | 100 GiB עד 10,239 GiB | 4,000 עד 17,000 |
| אזורי (אי אפשר להשתמש באזור הזה במופעים קטנים) | 1 TiB עד 9.75 TiB | 4,000 עד 17,000 | |
| אזורי | 1 TiB עד 9.75 TiB | 4,000 עד 17,000 | |
| טווח קיבולת גבוה יותר | אזורי | 10 TiB עד 100 TiB | 3,000 עד 7,500 |
| אזורי | 10 TiB עד 100 TiB | 3,000 עד 7,500 |
הסבר על חישובי הביצועים
בטבלה הבאה מוצגים חישובי הביצועים על סמך פעולות קלט/פלט שהוקצו לכל TiB והקיבולת שהוקצתה. החישובים מבוססים על טווחי קיבולת שונים כדי להראות איך הערכים של פעולות קלט/פלט בשנייה (IOPS) לקריאה, פעולות קלט/פלט בשנייה (IOPS) לכתיבה, קצב העברת הנתונים לקריאה וקצב העברת הנתונים לכתיבה משתנים עבור ערכי ה-IOPS המינימליים והמקסימליים לכל TiB.
מידע נוסף זמין במאמר בנושא קריאה וכתיבה של IOPS.
| טווח הקיבולת | 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 |
* בהתאם לגישה לתכונה של מכונות בקיבולת קטנה, טווח הקיבולת הנמוך של מכונות אזוריות ב-Filestore יכול להיות 100 GiB עד 10,239 GiB או 1 TiB עד 9.75 TiB. מידע נוסף זמין במאמר בנושא איך יוצרים אירועים קטנים של Filestore.
שינוי גורף בביצועים
בתרחישים של לקוח יחיד או כמה לקוחות, צריך להגדיל את מספר חיבורי ה-TCP באמצעות אפשרות ההרכבה nconnect כדי להשיג ביצועים מקסימליים של NFS.
במקרה של רמות שירות ספציפיות, מומלץ לציין את מספר החיבורים הבא בין הלקוח לשרת:
| רמה | קיבולת | מספר החיבורים |
|---|---|---|
| אזורי | 1-9.75 TiB | nconnect=2 |
| אזורי | 10-100 TiB | nconnect=7 |
| Enterprise | - | nconnect=2 |
| דיסק SSD לביצועים גבוהים | - | nconnect=7 |
באופן כללי, ככל שקיבולת שיתוף הקבצים גדולה יותר ומספר מכונות ה-VM של הלקוח שמחוברות קטן יותר, כך הביצועים משתפרים יותר כשמציינים חיבורים נוספים באמצעות nconnect.
סוג המכונה המומלץ ללקוח
מומלץ להשתמש בסוג מכונה ב-Compute Engine, כמו n2-standard-8, שמספק רוחב פס של לפחות 16 Gbps ליציאה. רוחב הפס הזה של תעבורת נתונים יוצאת (egress) מאפשר ללקוח להשיג רוחב פס קריאה של כ-16 Gbps עבור עומסי עבודה (workload) שמתאימים לשימוש במטמון. מידע נוסף זמין במאמר בנושא רוחב פס ברשת.
אפשרויות טעינה של לקוח 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 יכול לקבל משרת ה-NFS עד 524,288 בייטים לכל READ בקשה. הערה: במופעים ברמה הבסיסית, צריך להגדיר את הערך rsize ל-1048576. |
wsize=524288 |
לקוח NFS יכול לשלוח עד 524,288 בייטים לשרת NFS לכל WRITE בקשה. |
resvport |
לקוח ה-NFS משתמש ביציאת מקור בעלת הרשאות כשהוא מתקשר עם שרת ה-NFS לנקודת הטעינה הזו. |
async |
לקוח NFS מעכב את השליחה של פעולות כתיבה של אפליקציות לשרת NFS עד שמתקיימים תנאים מסוימים. זהירות: שימוש באפשרות sync מפחית באופן משמעותי את הביצועים. |
אופטימיזציה של קצב העברת הנתונים לקריאה ב-NFS באמצעות הפרמטר read_ahead_kb
הפרמטר NFS read_ahead_kb מציין את כמות הנתונים, בקילובייטים, שגרעין Linux צריך לאחזר מראש במהלך פעולת קריאה רציפה. כתוצאה מכך, אפשר לטפל בבקשות קריאה עוקבות ישירות מהזיכרון כדי לצמצם את זמן האחזור ולשפר את הביצועים הכוללים.
בגרסאות של ליבת Linux 5.4 ומעלה, לקוח ה-NFS של Linux משתמש בערך ברירת מחדל read_ahead_kb של 128 KB.
מומלץ להגדיל את הערך הזה ל-20 MB כדי לשפר את קצב העברת הנתונים של קריאה רציפה.
אחרי שמצליחים לטעון את שיתוף הקבצים במכונה הווירטואלית של לקוח 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 הוא הנתיב לספרייה שבה מותקן שיתוף הקבצים.
ביצועים של מכונות וירטואליות של לקוח יחיד ושל כמה לקוחות
רמות השירות של Filestore ניתנות להרחבה ומותאמות לביצועים של כמה מכונות וירטואליות של לקוחות, ולא של מכונה וירטואלית אחת של לקוח.
במקרים של מכונות וירטואליות אזוריות, אזוריות וארגוניות, צריך לפחות ארבע מכונות וירטואליות של לקוחות כדי ליהנות מביצועים מלאים. כך מוודאים שכל המכונות הווירטואליות באשכול Filestore הבסיסי מנוצלות במלואן.
כדי לספק הקשר נוסף, האשכול הקטן ביותר של Filestore שניתן להרחבה כולל ארבע מכונות וירטואליות. כל מכונת VM של לקוח מתקשרת רק עם מכונת VM אחת של אשכול Filestore, ללא קשר למספר חיבורי ה-NFS לכל לקוח שצוין באמצעות אפשרות ההרכבה nconnect. אם משתמשים במכונת VM אחת של לקוח, פעולות קריאה וכתיבה מתבצעות רק ממכונת VM אחת של אשכול 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.