בדף הזה מוסבר על אפשרויות הביצועים שזמינות למופעי 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.