מטמון מטא-נתונים של Azure Files מול מטמון סניף מקומי
מטמון מטא-נתונים בצד השירות מפחית את עבודת השרת. הוא אינו מוציא את ההלוך-חזור מה-WAN שלכם. השוו בין השניים לפי מה שהם מקצרים בפועל.
לגישה איטית ל-Azure Files דרך VPN מוצעים שני שינויים, והם מקצרים דברים שונים. מטמון מטא-נתונים בצד השירות הופך פעולות מתאימות לזולות יותר עבור השרת. מטמון סניף מקומי מקרב את הביטים ואת הפעולות אל המשתמש. בחירה בין השניים לפי מחירון או הודעה לעיתונות היא הדרך שבה נתח משותף הופך למהיר יותר במבחן ונשאר ללא שינוי בתשע בבוקר.
שני מטמונים, שני זמני השהיה שונים
שתי האפשרויות מופיעות תחת המילה מטמון, ושם מתחיל הבלבול. הן יושבות בצדדים מנוגדים של הרשת.
| Change | Where it acts | What it does not imply |
|---|---|---|
| Azure Files service metadata caching | The service's handling of supported metadata operations on eligible shares | No removal of the client's network round trips |
| A supported local server or cache design | Some content and operations placed nearer the users | No universal offline access or instant cross-site consistency |
| Application batching or limited copy concurrency | The number and overlap of remote operations | No automatic speedup for every workload |
מדריך הביצועים של SMB של Microsoft מתאר מטמון מטא-נתונים עבור נתחי SSD מתאימים יחד עם שלב הרישום הנלווה לו. ההתאמה ומצב התכונה שייכים לחשבון האחסון בפועל, לכן קראו את העמוד הנוכחי ולא הודעת תצוגה מקדימה מלפני שנתיים.
חלקו את ההמתנה לשלושה חלקים
לכל רשימת תיקיה איטית יש שלושה מרכיבי עלות, והם מגיבים לתיקונים שונים. יש זמן עיבוד בקשה בצד השירות, מספר ההלוך-חזור התלויים דרך ה-VPN והמטען שצריך להעביר. מטמון בצד השירות תוקף את הראשון. שום דבר בצד השרת לא תוקף את השני.
לכן נתח משותף יכול להציג מדדי שירות טובים יותר בעוד בורר הקבצים של המשתמש עדיין תלוי במשך שמונה שניות.
היכן כל אפשרות מזכה את מקומה
אם עומס העבודה כבד במטא-נתונים, עם שפע פתיחות, קריאות stat וספירות תיקיות מול נתח SSD מתאים, מטמון בצד השירות הוא הניסוי הזול. הוא אינו דורש תשתית חדשה ואינו משנה את הדרך שבה משתמשים מגיעים לנתח.
אם עומס העבודה אינטראקטיבי ומוגבל בהשהיה, האפשרות הכנה היא עיצוב שרת מקומי נתמך עם מודל סנכרון מתועד. זו ארכיטקטורה אחרת עם עלויות התפעלות שלה, לא מתג.
מה שאף אחת מהאפשרויות לא משנה
חתימה והצפנה של SMB עדיין חלות, ועדיין עולות את מה שהן עולות. בקרת גישה עדיין נפתרת לכל משתמש, כך שעותק במטמון אינו מפשט הרשאה. עקביות בין אתרים עדיין דורשת מודל מוגדר, כי קריאות מקומיות בסניף וכתיבות בצד הענן חייבות להסכים על משהו. וגישה ללא קוו נשארת הגדרה של הלקוח, לא תופעת לוואי של תכונת שרת.
כשמישהו מבטיח שתכונת שירות מסירה את ההלוך-חזור של ה-WAN, זו הטענה שיש לבדוק קודם.
מדדו מול הפעולה שהמשתמשים מתלוננים עליה
תזמנו את הפעולה המדויקת ולא עותק סינתטי. Measure-Command { Get-ChildItem \\files\projects -Recurse } בלקוח סניף נותן מספר שאפשר להשוות לפני ואחרי, ו-Get-SmbMultichannelConnection מראה אם הלקוח משתמש ביותר מנתיב אחד. שימו זאת לצד מדדי ההשהיה בצד השירות לאותו חלון.
השאירו את הנתח, מיקום הלקוח, נתיב ה-VPN ומדיניות האבטחה קבועים, אחרת אתם מודדים את חלון השינוי שלכם ולא את התכונה. רשמו גם מספר קבצים והתפלגות גדלים, כי עומסי קבצים קטנים והעתקות גורפות מגיבים למנופים שונים לחלוטין.
התוצאה שראויה שתהיה לכם היא שינוי מותאם לגבול שהיה איטי באמת, עם עלויות התפעלות ועקביות שלו כתובות. מספר IOPS אחסון גדול יותר בשקופית אינו התוצאה הזו.