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 आकडा तो निकाल नाही.