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 ಸಂಖ್ಯೆ ಆ ಫಲಿತಾಂಶವಲ್ಲ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು