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 संख्या त्यो नतिजा होइन।