Azure Files मेटाडेटा कैशिंग बनाम स्थानीय शाखा कैश
सेवा-पक्ष का मेटाडेटा कैश सर्वर का काम घटाता है। यह आपके WAN से राउंड ट्रिप नहीं हटाता। दोनों की तुलना इस आधार पर करें कि वे वास्तव में क्या छोटा करते हैं।
VPN के ज़रिए धीमी Azure Files पहुँच के लिए दो बदलाव प्रस्तावित किए जाते हैं, और वे अलग-अलग चीज़ें छोटी करते हैं। सेवा-पक्ष का मेटाडेटा कैश योग्य संचालनों को सर्वर के लिए सस्ता बनाता है। स्थानीय शाखा कैश बाइट्स और संचालनों को उपयोगकर्ता के और करीब लाता है। मूल्य सूची या प्रेस विज्ञप्ति के आधार पर इनमें से चुनना वह रास्ता है जिससे कोई शेयर बेंचमार्क में तेज़ दिखता है और सुबह नौ बजे अपरिवर्तित रहता है।
दो कैश, दो अलग विलंब
दोनों विकल्प कैश शब्द के अंतर्गत आते हैं, और उलझन वहीं से शुरू होती है। वे नेटवर्क के विपरीत पक्षों पर बैठे हैं।
| 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 |
Microsoft की SMB प्रदर्शन मार्गदर्शिका योग्य SSD शेयरों के लिए मेटाडेटा कैशिंग का वर्णन करती है, साथ ही उसके साथ आने वाले पंजीकरण चरण का भी। योग्यता और सुविधा की स्थिति वास्तविक स्टोरेज खाते की होती है, इसलिए वर्तमान पृष्ठ पढ़ें, दो साल पहले की पूर्वावलोकन घोषणा नहीं।
प्रतीक्षा को तीन भागों में बाँटें
हर धीमी निर्देशिका सूची में तीन लागत घटक होते हैं, और वे अलग-अलग सुधारों पर प्रतिक्रिया देते हैं। प्रति अनुरोध सेवा प्रसंस्करण समय है, VPN के ज़रिए निर्भर राउंड ट्रिप की संख्या और वह पेलोड जिसे खिसकाना है। सेवा-पक्ष का कैश पहले पर हमला करता है। सर्वर पक्ष पर कुछ भी दूसरे पर हमला नहीं करता।
इसीलिए कोई शेयर बेहतर सेवा मीट्रिक दिखा सकता है, जबकि उपयोगकर्ता का फ़ाइल चयनकर्ता अब भी आठ सेकंड के लिए अटका रहता है।
कहाँ हर विकल्प अपनी जगह कमाता है
यदि कार्यभार मेटाडेटा-भारी है, योग्य SSD शेयर के विरुद्ध बहुत सारे खोलने, stat कॉल और निर्देशिका गणनाएँ हैं, तो सेवा-पक्ष का कैशिंग सस्ता प्रयोग है। इसे नए ढाँचे की और इस बात में बदलाव की ज़रूरत नहीं कि उपयोगकर्ता शेयर तक कैसे पहुँचते हैं।
यदि कार्यभार इंटरैक्टिव और विलंब-सीमित है, तो प्रलेखित सिंक्रोनाइज़ेशन मॉडल वाला समर्थित स्थानीय सर्वर डिज़ाइन ईमानदार विकल्प है। यह अपने संचालन खर्चों वाला अलग आर्किटेक्चर है, कोई स्विच नहीं।
दोनों में से कोई विकल्प क्या नहीं बदलता
SMB हस्ताक्षर और एन्क्रिप्शन अब भी लागू होते हैं, और वे अब भी वही खर्च करते हैं जो वे करते हैं। पहुँच नियंत्रण अब भी प्रति उपयोगकर्ता तय होता है, इसलिए कैश की गई प्रति प्राधिकरण को सरल नहीं बनाती। साइटों के बीच सुसंगतता को अब भी परिभाषित मॉडल चाहिए, क्योंकि शाखा-स्थानीय पठन और क्लाउड-पक्ष के लेखन को किसी बात पर सहमत होना पड़ता है। और ऑफ़लाइन पहुँच क्लाइंट सेटिंग ही रहती है, सर्वर सुविधा का दुष्प्रभाव नहीं।
जब कोई वादा करता है कि कोई सेवा सुविधा WAN राउंड ट्रिप हटा देती है, तो पहले वही दावा जाँचना चाहिए।
उस संचालन के विरुद्ध मापें जिसकी उपयोगकर्ता शिकायत करते हैं
कृत्रिम प्रति के बजाय ठीक उसी संचालन का समय लें। शाखा क्लाइंट पर Measure-Command { Get-ChildItem \\files\projects -Recurse } एक संख्या देता है जिसे आप पहले और बाद में तुलना कर सकते हैं, और Get-SmbMultichannelConnection दिखाता है कि क्लाइंट एक से अधिक पथ का उपयोग कर रहा है या नहीं। इसे उसी विंडो के सेवा-पक्ष विलंब मीट्रिक के बगल में रखें।
शेयर, क्लाइंट का स्थान, VPN पथ और सुरक्षा नीति को स्थिर रखें, अन्यथा आप सुविधा के बजाय अपनी परिवर्तन-विंडो माप रहे होंगे। फ़ाइलों की संख्या और आकार वितरण भी दर्ज करें, क्योंकि छोटी फ़ाइलों का कार्यभार और थोक प्रतियाँ पूरी तरह अलग लीवरों पर प्रतिक्रिया देती हैं।
जो परिणाम रखने योग्य है वह उस सीमा से मेल खाता बदलाव है जो वास्तव में धीमी थी, और उसके संचालन और सुसंगतता खर्च लिखे हुए हैं। स्लाइड पर बड़ा स्टोरेज IOPS आँकड़ा वह परिणाम नहीं है।