VPN ద్వారా నెమ్మదిగా Azure Files యాక్సెస్ కోసం రెండు మార్పులు ప్రతిపాదించబడతాయి, అవి వేర్వేరు విషయాలను చిన్నవిగా చేస్తాయి. సేవా వైపు మెటాడేటా కాష్ అర్హత కలిగిన కార్యకలాపాలను సర్వర్‌కు చవకగా చేస్తుంది. స్థానిక శాఖ కాష్ బైట్లను మరియు కార్యకలాపాలను వినియోగదారుకు దగ్గరగా తెస్తుంది. ధరల జాబితా లేదా ప్రెస్ రిలీజ్ ఆధారంగా వాటి మధ్య ఎంచుకోవడం అంటే ఒక షేర్ బెంచ్‌మార్క్‌లో వేగంగా కనిపించి ఉదయం తొమ్మిది గంటలకు మారకుండా ఉండే మార్గం.

రెండు కాష్‌లు, రెండు వేర్వేరు ఆలస్యాలు

రెండు ఎంపికలు కాష్ అనే పదం కింద కనిపిస్తాయి, గందరగోళం అక్కడి నుండే ప్రారంభమవుతుంది. అవి నెట్‌వర్క్ వ్యతిరేక వైపులా ఉంటాయి.

ChangeWhere it actsWhat it does not imply
Azure Files service metadata cachingThe service's handling of supported metadata operations on eligible sharesNo removal of the client's network round trips
A supported local server or cache designSome content and operations placed nearer the usersNo universal offline access or instant cross-site consistency
Application batching or limited copy concurrencyThe number and overlap of remote operationsNo automatic speedup for every workload

Microsoft యొక్క SMB పనితీరు మార్గదర్శిని అర్హత కలిగిన SSD షేర్ల కోసం మెటాడేటా కాషింగ్‌ను మరియు దానితో వచ్చే నమోదు దశను వివరిస్తుంది. అర్హత మరియు ఫీచర్ స్థితి వాస్తవ నిల్వ ఖాతాకు చెందుతాయి, కాబట్టి రెండు సంవత్సరాల క్రితం ప్రివ్యూ ప్రకటన కాదు, ప్రస్తుత పేజీ చదవండి.

నిరీక్షణను మూడు భాగాలుగా విభజించండి

ప్రతి నెమ్మదిగా డైరెక్టరీ జాబితాకు మూడు ఖర్చు భాగాలు ఉంటాయి, అవి వేర్వేరు పరిష్కారాలకు స్పందిస్తాయి. ప్రతి అభ్యర్థనకు సేవా ప్రాసెసింగ్ సమయం ఉంది, VPN ద్వారా ఆధారపడిన రౌండ్ ట్రిప్పుల సంఖ్య మరియు కదిలించాల్సిన పేలోడ్ ఉంది. సేవా వైపు కాష్ మొదటి దానిపై దాడి చేస్తుంది. సర్వర్ వైపు ఏదీ రెండో దానిపై దాడి చేయదు.

అందుకే వినియోగదారు ఫైల్ ఎంపిక సాధనం ఇంకా ఎనిమిది సెకన్లు వేలాడుతున్నప్పటికీ షేర్ మెరుగైన సేవా కొలతలను చూపగలదు.

ప్రతి ఎంపిక తన స్థానాన్ని ఎక్కడ సంపాదిస్తుంది

పని భారం మెటాడేటా-భారీగా ఉంటే, అర్హత కలిగిన SSD షేర్‌పై చాలా తెరవడాలు, stat కాల్లు మరియు డైరెక్టరీ లెక్కలు ఉంటే, సేవా వైపు కాషింగ్ చవకైన ప్రయోగం. దానికి కొత్త మౌలిక సదుపాయాలు లేదా వినియోగదారులు షేర్‌ను చేరుకునే విధానంలో మార్పు అవసరం లేదు.

పని భారం పరస్పర చర్యాత్మకంగా మరియు ఆలస్యంతో పరిమితమైతే, పత్రీకరించిన సింక్రొనైజేషన్ మోడల్‌తో కూడిన మద్దతు ఉన్న స్థానిక సర్వర్ డిజైన్ నిజాయితీ ఎంపిక. ఇది దాని స్వంత నిర్వహణ ఖర్చులతో కూడిన వేరే ఆర్కిటెక్చర్, స్విచ్ కాదు.

రెండు ఎంపికలు మార్చనిది

SMB సంతకం మరియు ఎన్‌క్రిప్షన్ ఇప్పటికీ వర్తిస్తాయి, అవి ఇప్పటికీ తమ ఖర్చును తీసుకుంటాయి. యాక్సెస్ నియంత్రణ ఇప్పటికీ ప్రతి వినియోగదారుకు పరిష్కరించబడుతుంది, కాబట్టి కాష్ చేసిన కాపీ అనుమతిని సులభతరం చేయదు. సైట్ల మధ్య స్థిరత్వానికి ఇప్పటికీ నిర్వచించిన మోడల్ అవసరం, ఎందుకంటే శాఖ-స్థానిక పఠనాలు మరియు క్లౌడ్ వైపు రాతలు ఏదో ఒకదానిపై అంగీకరించాలి. మరియు ఆఫ్‌లైన్ యాక్సెస్ క్లయింట్ సెట్టింగ్‌గానే ఉంటుంది, సర్వర్ ఫీచర్ యొక్క దుష్ప్రభావం కాదు.

సేవా ఫీచర్ WAN రౌండ్ ట్రిప్పులను తొలగిస్తుందని ఎవరైనా వాగ్దానం చేసినప్పుడు, మొదట పరీక్షించాల్సిన దావా అదే.

వినియోగదారులు ఫిర్యాదు చేసే కార్యకలాపానికి వ్యతిరేకంగా కొలవండి

కృత్రిమ కాపీకి బదులుగా ఖచ్చితమైన కార్యకలాపాన్ని సమయం కొలవండి. శాఖ క్లయింట్‌పై Measure-Command { Get-ChildItem \\files\projects -Recurse } ముందు మరియు తర్వాత పోల్చగల సంఖ్యను ఇస్తుంది, Get-SmbMultichannelConnection క్లయింట్ ఒకటి కంటే ఎక్కువ మార్గాన్ని ఉపయోగిస్తున్నదా చూపిస్తుంది. దాన్ని అదే విండో కోసం సేవా వైపు ఆలస్య కొలతల పక్కన ఉంచండి.

షేర్, క్లయింట్ స్థానం, VPN మార్గం మరియు భద్రతా విధానాన్ని స్థిరంగా ఉంచండి, లేకపోతే మీరు ఫీచర్‌ను కాదు, మీ మార్పు విండోను కొలుస్తున్నారు. ఫైల్ల సంఖ్య మరియు పరిమాణ పంపిణీని కూడా నమోదు చేయండి, ఎందుకంటే చిన్న ఫైళ్ల పని భారాలు మరియు పెద్ద ఎత్తున కాపీలు పూర్తిగా వేరే లివర్లకు స్పందిస్తాయి.

నిలుపుకోదగిన ఫలితం నిజంగా నెమ్మదిగా ఉన్న పరిమితికి సరిపోయే మార్పు, మరియు దాని నిర్వహణ మరియు స్థిరత్వ ఖర్చులు రాసి ఉండటం. స్లైడ్‌పై పెద్ద నిల్వ IOPS సంఖ్య ఆ ఫలితం కాదు.

సంబంధిత వ్యాసాలు