VPN ಫೈಲ್ ಹಂಚಿಕೆಗೆ BranchCache: ಯಾವಾಗ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಯಾವಾಗ ಇಲ್ಲ

ತಂಡದಲ್ಲಿ ಯಾರೋ VPN ಮೇಲಿನ ಫೈಲ್ ಹಂಚಿಕೆ ನಿಧಾನ ಎನ್ನುತ್ತಾರೆ, ಮತ್ತು ಮೊದಲ ಸಲಹೆ ಯಾವಾಗಲೂ ಕ್ಯಾಶ್. ರಿಮೋಟ್-ಆಕ್ಸೆಸ್ ವಿನ್ಯಾಸಕ್ಕೆ BranchCache ಸೇರಿಸುವ ಮೊದಲು ದೂರನ್ನು ಮೂರು ರೂಪಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಬೇರ್ಪಡಿಸಿ: ಬದಲಾಗದ ವಿಷಯದ ಪುನರಾವರ್ತಿತ ಡೌನ್‌ಲೋಡ್‌ಗಳು, ಅಪ್‌ಲೋಡ್‌ಗಳು, ಅಥವಾ ಸಾವಿರಾರು ನಮೂದುಗಳಿರುವ ಫೋಲ್ಡರ್‌ಗಳಲ್ಲಿ ಮೆಟಾಡೇಟಾ-ಭಾರೀ ಬ್ರೌಸಿಂಗ್. BranchCache ಬೆಂಬಲಿತ ವಿಷಯದಲ್ಲಿ ಮೊದಲ ರೂಪವನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಮತ್ತು ಉಳಿದೆರಡಕ್ಕೆ ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ಮಾಡುವುದಿಲ್ಲ. ಇದು ತಪ್ಪಿಸಬೇಕಾದ ಮಿತಿ ಅಲ್ಲ; ನಿಯೋಜನೆಗೆ ಒಂದು ವಾರ ಕಳೆಯುವ ಮೊದಲು ನೀವು ಮಾಡಬೇಕಾದ ಹೋಲಿಕೆ ಇದು.

ಅದೇ ಹಂಚಿಕೆ, ಮೂರು ವಿಭಿನ್ನ ದೂರುಗಳು

ಎಂಟು ಮಂದಿ ಅದೇ ಬದಲಾಗದ ತರಬೇತಿ ವೀಡಿಯೊ ತೆರೆಯುವ ಶಾಖಾ ಕಚೇರಿ ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಸಂದರ್ಭ. ಮೊದಲ ಮರುಪಡೆಯುವಿಕೆ WAN ದಾಟುತ್ತದೆ, ವಿಷಯ ಓದುಗರ ಹತ್ತಿರ ಕ್ಯಾಶ್ ಆಗುತ್ತದೆ, ಮತ್ತು ಅದೇ ಬದಲಾಗದ ಫೈಲ್‌ನ ನಂತರದ ಮರುಪಡೆಯುವಿಕೆಗಳು ಸ್ಥಳೀಯವಾಗಿ ನೀಡಲಾಗುತ್ತವೆ. ಲಾಭ ನಿಜವಾದದ್ದು ಮತ್ತು ಸಂಕುಚಿತ: ಅದೇ ವಿಷಯ, ಬದಲಾಗದ, ಹಲವು ಓದುಗರು.

ಮನೆ ಸಂಪರ್ಕದ ಮೂಲಕ ಹೊಸ ರೆಕಾರ್ಡಿಂಗ್ ಅಪ್‌ಲೋಡ್ ಮಾಡುವ ಲ್ಯಾಪ್‌ಟಾಪ್ ವಿರುದ್ಧ ಸಂದರ್ಭ. ಇನ್ನೂ ಇಲ್ಲದ ಫೈಲ್‌ನ ಹಿಂದೆ ಕ್ಯಾಶ್ ಮಾಡಿದ ಪ್ರತಿ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಅಪ್‌ಲೋಡ್ ಯಾವಾಗಲಿನಂತೆಯೇ ಅದೇ ಸೀಮಿತ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಡೌನ್‌ಲೋಡ್ ಕ್ಯಾಶ್ ಅಪ್‌ಲೋಡ್ ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೇ ಸ್ಥಾನ ಆಯ್ಕೆ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

ಮೂರನೇ ರೂಪ ಜನರನ್ನು ನಿರಾಶೆಗೊಳಿಸುವುದು ಏಕೆಂದರೆ ಅದು ಡೌನ್‌ಲೋಡ್ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ. ಸಾವಿರಾರು ಫೈಲ್‌ಗಳಿರುವ ಡೈರೆಕ್ಟರಿ ತೆರೆಯುವುದು, ಅದನ್ನು ಜೋಡಿಸುವುದು ಮತ್ತು ಮೆಟಾಡೇಟಾ ಓದುವುದು ಸಣ್ಣ ಕಾರ್ಯಾಚರಣೆಗಳ ಹರಿವು, ಒಂದು ದೊಡ್ಡ ವಸ್ತುವಿನ ಪುನರಾವರ್ತಿತ ವರ್ಗಾವಣೆ ಅಲ್ಲ. ಫೈಲ್‌ಗಳ ದೇಹಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡುವುದು ಪಟ್ಟಿಗೆ ಏನೂ ಮಾಡುವುದಿಲ್ಲ.

ವಿತರಿತ ಕ್ಯಾಶ್: VPN ಪೂಲ್ ಶಾಖಾ LAN ಅಲ್ಲ

ವಿತರಿತ ಮೋಡ್‌ನಲ್ಲಿ ಕ್ಲೈಂಟ್ ಕಂಪ್ಯೂಟರ್‌ಗಳು ಕ್ಯಾಶ್ ಮಾಡಿದ ವಿಷಯವನ್ನು ಪರಸ್ಪರ ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು Microsoft ಆ ಮೋಡ್ ಅನ್ನು ಒಂದೇ ಸಬ್‌ನೆಟ್ ಒಳಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವಂತೆ ದಾಖಲಿಸುತ್ತದೆ. VPN ಕ್ಲೈಂಟ್ ಪೂಲ್ ಆ ಅರ್ಥದಲ್ಲಿ ಸಬ್‌ನೆಟ್ ಅಲ್ಲ, ಎಲ್ಲಾ ವಿಳಾಸಗಳು ಪಕ್ಕಪಕ್ಕದಂತೆ ಕಂಡರೂ: ಪೀರ್ ಶೋಧನೆ, ಕ್ಲೈಂಟ್-ಇಂದ-ಕ್ಲೈಂಟ್ ತಲುಪುವಿಕೆ ಮತ್ತು ಕ್ಯಾಶ್ ಡೇಟಾ ವಿನಿಮಯದ ಅನುಮತಿ ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಗಳು, ಮತ್ತು ಸಾಮಾನ್ಯ ರಿಮೋಟ್-ಆಕ್ಸೆಸ್ ವಿನ್ಯಾಸ ಮೂರಕ್ಕೂ ಇಲ್ಲ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ.

ಕ್ಲೈಂಟ್-ಇಂದ-ಕ್ಲೈಂಟ್ ಸಂಚಾರಕ್ಕೆ ಅನುಮತಿ ನೀಡಿ ಪೂಲ್ ಅನ್ನು ಶಾಖಾ LAN ನಂತೆ ವರ್ತಿಸುವಂತೆ ಮಾಡಬಹುದು, ಆದರೆ ಅದು ಭದ್ರತಾ ನಿರ್ಣಯ, ಕ್ಯಾಶ್ ನಿರ್ಣಯ ಅಲ್ಲ. ಹೆಚ್ಚಿನ ರಿಮೋಟ್-ಆಕ್ಸೆಸ್ ವಿನ್ಯಾಸಗಳು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಪರಸ್ಪರ ಪ್ರತ್ಯೇಕಿಸುವುದು ಒಂದು ಹಾನಿಗೊಳಗಾದ ಲ್ಯಾಪ್‌ಟಾಪ್ ಇನ್ನೊಂದನ್ನು ತಲುಪದಂತೆ, ಮತ್ತು ಪೀರ್‌ಗಳು ಈಗಾಗಲೇ ವಿಶ್ವಾಸಾರ್ಹ ಸಮಾನರು ಅಲ್ಲದಿದ್ದರೆ ಆ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಕ್ಯಾಶ್ ಹಿಟ್‌ಗೆ ಬದಲಿಸುವುದು ಕೆಟ್ಟ ವ್ಯವಹಾರ.

ಒಬ್ಬನೇ ಸಂಚರಿಸುವ ಬಳಕೆದಾರನಿಗೆ ವಿತರಿತ ಮೋಡ್‌ನಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳಲು ಯಾರೂ ಇಲ್ಲ. ಕ್ಯಾಶ್ ಆ ಒಬ್ಬ ಕ್ಲೈಂಟ್‌ನ ಪುನರಾವರ್ತಿತ ಓದುಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸಬಹುದು, ಆದರೆ ಅದು ಕ್ಲೈಂಟ್-ಬದಿಯ ಕ್ಯಾಶ್ ಲಾಭ, ಶಾಖಾ ಸ್ಥಾನದ ಲಾಭ ಅಲ್ಲ, ಮತ್ತು ಕಚೇರಿ ವೇಗವಾಗುತ್ತದೆ ಎಂದು ಯಾರಾದರೂ ನಿರೀಕ್ಷಿಸುವ ಮೊದಲು ಅದನ್ನು ಹೇಳುವುದು ಯೋಗ್ಯ.

ಹೋಸ್ಟ್ ಮಾಡಿದ ಕ್ಯಾಶ್: ಸ್ಥಾನವೇ ಸಹಾಯವಾಗುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ

ಹೋಸ್ಟ್ ಮಾಡಿದ ಕ್ಯಾಶ್ ಹಂಚಿಕೆಯ ಕ್ಯಾಶ್ ಅನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಇಡುತ್ತದೆ, ಇದು ಸಬ್‌ನೆಟ್‌ಗಳ ನಡುವೆ ಅರ್ಥಪೂರ್ಣವಾದ ಏಕೈಕ ಮೋಡ್ ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳು ಪರಸ್ಪರ ಮಾತನಾಡಲು ಸಾಧ್ಯವಿಲ್ಲದಾಗ ಕೆಲಸ ಮಾಡುವ ಏಕೈಕ ಮೋಡ್. ತಕ್ಷಣದ ಪ್ರಶ್ನೆ ಆ ಸರ್ವರ್ ಎಲ್ಲಿದೆ ಎಂಬುದು. ಮೂಲದಂತೆಯೇ ಅದೇ ಸೀಮಿತ ಲಿಂಕ್ ಮೂಲಕ ತಲುಪುವ ಹೋಸ್ಟ್ ಮಾಡಿದ ಕ್ಯಾಶ್ ಬೈಟ್‌ಗಳನ್ನು ಸರಿಸಿದೆ, ಸಮಸ್ಯೆಯನ್ನಲ್ಲ.

ಅದನ್ನು ಓದುಗರ ಹತ್ತಿರ ಇರಿಸಿ, ಅದಕ್ಕೆ ಮಾಲೀಕರನ್ನು ನೀಡಿ, ಮತ್ತು ಅದರ ಡಿಸ್ಕ್ ಅನ್ನು ಇಡೀ ಹಂಚಿಕೆಗೆ ಅಲ್ಲ, ಕೆಲಸದ ಗುಂಪಿಗೆ ಅಳೆಯಿರಿ. Microsoft ನ BranchCache ಅವಲೋಕನ ಎರಡೂ ಮೋಡ್‌ಗಳನ್ನು ಮತ್ತು ಕ್ಲೈಂಟ್ ವರ್ತನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಜನರು ಮರೆಯುವ ಭಾಗವೂ ಸೇರಿದಂತೆ: ಕ್ಯಾಶ್ ಮಾಡಿದ ಡೇಟಾ ಬಳಸುವ ಮೊದಲು ಕ್ಲೈಂಟ್‌ಗಳು ಇನ್ನೂ ಅಧಿಕಾರ ಮತ್ತು ವಿಷಯ ಮಾಹಿತಿಗಾಗಿ ಮೂಲವನ್ನು ಸಂಪರ್ಕಿಸುತ್ತವೆ.

ನಿಯೋಜನೆ ಒಟ್ಟಿಗೆ ಯೋಜಿಸಿದ ಮೂರು ಪಾತ್ರಗಳು, ಒಂದು ಚೆಕ್‌ಬಾಕ್ಸ್ ಅಲ್ಲ. ಮೂಲ ಸರ್ವರ್ ವಿಷಯಕ್ಕೆ ಹ್ಯಾಶ್‌ಗಳನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ, ಹೋಸ್ಟ್ ಮಾಡಿದ ಕ್ಯಾಶ್ ಸಕ್ರಿಯ ಮತ್ತು ಪತ್ತೆಮಾಡಬಹುದಾದದ್ದು, ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳು ಅದನ್ನು ಬಳಸಲು ಸಂರಚಿಸಲಾಗಿದೆ. ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಇದು PowerShell ನಲ್ಲಿ ಗುರುತಿಸಬಹುದಾದದ್ದು:

Enable-BCHostedServer -RegisterSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode, HostedCacheServerList

ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಅದನ್ನು ಹೆಸರಿಸಿದ ಸರ್ವರ್‌ಗಳಿಗೆ ತೋರಿಸಿ ಅಥವಾ ಸೇವಾ ಸಂಪರ್ಕ ಬಿಂದುವಿನ ಮೂಲಕ ಅವುಗಳನ್ನು ಪತ್ತೆ ಮಾಡಲು ಬಿಡಿ; ನಂತರ ನೀತಿ ಅನ್ವಯವಾಗಿದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಅದು ವಾಸ್ತವವಾಗಿ ಆಯ್ಕೆ ಮಾಡಿದ ಮೋಡ್ ಅನ್ನು ದೃಢೀಕರಿಸಿ:

Enable-BCHostedClient -ServerNames cache1.corp.example -UseSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode

ಮೂಲಕ್ಕೆ ಇನ್ನೂ ಏನು ತಲುಪುತ್ತದೆ

ಕ್ಯಾಶಿಂಗ್ ಅಧಿಕಾರವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ. ಫೈಲ್ ಓದುವ ಅನುಮತಿ ಇಲ್ಲದ ಕ್ಲೈಂಟ್ ಬೇರೊಬ್ಬರು ಅದನ್ನು ಕ್ಯಾಶ್ ಮಾಡಿದ್ದರಿಂದ ಪ್ರವೇಶ ಪಡೆಯುವುದಿಲ್ಲ, ಮತ್ತು ಮೂಲ ಇನ್ನೂ ಅಧಿಕಾರದ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಯಾಶ್ ಹುಡುಕಾಟವನ್ನು ಸಾಧ್ಯವಾಗಿಸುವ ವಿಷಯ ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಮೂಲ ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲದಿದ್ದರೆ, ಕ್ಯಾಶ್ ಮಾಡಿದ ಪ್ರತಿ ಒಂದೇ ಆಗಿ ಆಫ್‌ಲೈನ್ ಹಂಚಿಕೆಯಾಗುವುದಿಲ್ಲ.

ವಿಷಯ ಬದಲಾವಣೆಗಳು ಸಹ ಊಹೆಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ಮುರಿಯುತ್ತವೆ. ಮತ್ತೆ ಉಳಿಸಿದ, ಮತ್ತೆ ಎನ್‌ಕೋಡ್ ಮಾಡಿದ ಅಥವಾ ಬ್ಯಾಕಪ್ ಉತ್ಪನ್ನ ಸ್ಪರ್ಶಿಸಿದ ಫೈಲ್ ಇನ್ನು ಕ್ಯಾಶ್ ಹ್ಯಾಶ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗದೇ ಇರಬಹುದು, ಮತ್ತು ಮುಂದಿನ ಓದು ಮೂಲಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತದೆ. ಅದು ಸರಿಯಾದ ವರ್ತನೆ, ಮತ್ತು ಕೆಲಸದ ಗುಂಪು ಪ್ರತಿ ಗಂಟೆಗೆ ಬದಲಾಗುವ ಕ್ಯಾಶ್ ಕಡಿಮೆ ನೀಡುವುದಕ್ಕೆ ಇದೇ ಕಾರಣ.

ಹೊರಹಾಕುವಿಕೆ ಮೂರನೇ ಮಿತಿ. ಕ್ಯಾಶ್ ಸೀಮಿತ, ಆದ್ದರಿಂದ ದೊಡ್ಡ ಕೆಲಸದ ಗುಂಪು ಹಳೆಯ ವಿಷಯವನ್ನು ಹೊರಗೆ ತಳ್ಳುತ್ತದೆ, ಮತ್ತು ಲಾಭವು ಪುನರ್‌ಓದುಗಳು ಹೊರಹಾಕುವಿಕೆಯ ಮೊದಲು ನಡೆಯುವುದನ್ನು ಅವಲಂಬಿಸಿದೆ, ನಂತರ ಅಲ್ಲ. ಇಡೀ ಹಂಚಿಕೆಗೆ ಕ್ಯಾಶ್ ಅಳೆಯುವುದು ತಾಂತ್ರಿಕವಾಗಿ ಸರಿಯಾದ ನಿಯೋಜನೆಯಿಂದ ನಿರಾಶೆಗೊಳ್ಳುವ ಸಾಮಾನ್ಯ ದಾರಿ.

ಎರಡು ಮರುಪಡೆಯುವಿಕೆ ಮತ್ತು ಒಂದು ಅಪ್‌ಲೋಡ್‌ನೊಂದಿಗೆ ಅದನ್ನು ಸ್ವೀಕರಿಸಿ

ಸರಿಯಾದ ಮೂರು ಹರಿವುಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಏನನ್ನು ತೋರಿಸುತ್ತದೆ ಎಂದು ಬರೆಯಿರಿ. ಕ್ಲೈಂಟ್‌ನಿಂದ ಪ್ರತಿನಿಧಿ ಫೈಲ್‌ನ ಮೊದಲ ಮರುಪಡೆಯುವಿಕೆ, ಮೂಲ ಲಿಂಕ್‌ನಲ್ಲಿ ಮತ್ತು ಬಳಕೆದಾರರ ಗಡಿಯಾರದಲ್ಲಿಯೂ ಅಳೆಯಲಾಗಿದೆ. ಅದೇ ಸ್ಥಾನ ಗುಂಪಿನ ಎರಡನೇ ಕ್ಲೈಂಟ್‌ನಿಂದ ಅದೇ ಬದಲಾಗದ ಫೈಲ್‌ನ ಎರಡನೇ ಮರುಪಡೆಯುವಿಕೆ. ಹೊಸ ಫೈಲ್‌ನ ಒಂದು ಅಪ್‌ಲೋಡ್, ಅದು ಯಾವುದೇ ಸುಧಾರಣೆ ತೋರಿಸಬಾರದು ಮತ್ತು ಕ್ಯಾಶ್‌ಗೆ ಅದು ಎಂದಿಗೂ ಮಾಡದ್ದಕ್ಕೆ ಶ್ರೇಯ ನೀಡುತ್ತಿಲ್ಲ ಎಂದು ದೃಢೀಕರಿಸುತ್ತದೆ.

ಎರಡನೇ ಮರುಪಡೆಯುವಿಕೆ ಇನ್ನೂ ಹೆಚ್ಚಿನ ಬೈಟ್‌ಗಳಿಗೆ ಮೂಲ ಲಿಂಕ್ ದಾಟಿದರೆ, ಕ್ಯಾಶ್ ಬಳಕೆಯಾಗುತ್ತಿಲ್ಲ, ಮತ್ತು ಕಾರಣ ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪು ಮೋಡ್‌ನಲ್ಲಿರುವ ಕ್ಲೈಂಟ್, ಮೂಲದಲ್ಲಿ ಕಾಣೆಯಾದ ಹ್ಯಾಶ್ ಪ್ರಕಟಣೆ, ಅಥವಾ ಸೀಮಿತ ಲಿಂಕ್‌ನ ತಪ್ಪು ಬದಿಯಲ್ಲಿರುವ ಹೋಸ್ಟ್ ಮಾಡಿದ ಕ್ಯಾಶ್. ಇವು ಮೂರು ವಿಭಿನ್ನ ಸರಿಪಡಿಸುವಿಕೆಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ನೆಟ್‌ವರ್ಕ್ ಸ್ಥಾನದ ಬಗ್ಗೆ.

ನಂತರ ತೀರ್ಮಾನವನ್ನು ಮೂಲ ದೂರಿನ ಅದೇ ರೂಪದಲ್ಲಿ ಹೇಳಿ: ಈ ಮೂಲದಿಂದ ಈ ಓದುಗರಿಗೆ ಬದಲಾಗದ ವಿಷಯದ ಪುನರಾವರ್ತಿತ ಡೌನ್‌ಲೋಡ್‌ಗಳನ್ನು ಈ ಕ್ಯಾಶ್ ನೀಡುತ್ತದೆ. ಹಂಚಿಕೆಯ ಬಗ್ಗೆ ಉಳಿದ ಎಲ್ಲವೂ ಅಸ್ಪೃಷ್ಟವಾಗಿದೆ, ಅಪ್‌ಲೋಡ್‌ಗಳು, ಫೋಲ್ಡರ್ ಪಟ್ಟಿ ಮತ್ತು ಆಫ್‌ಲೈನ್ ಕಥೆ ಸೇರಿದಂತೆ, ಅದಕ್ಕೆ ಇನ್ನೂ ತನ್ನದೇ ಉತ್ತರ ಬೇಕು.