BranchCache สำหรับการแชร์ไฟล์ผ่าน VPN: เมื่อไรจึงช่วย เมื่อไรไม่ช่วย

มีคนในทีมบอกว่าการแชร์ไฟล์ผ่าน VPN ช้า และข้อเสนอแรกก็คือแคชเสมอ ก่อนจะเพิ่ม BranchCache เข้าไปในการออกแบบการเข้าถึงระยะไกล ให้แยกข้อร้องเรียนออกเป็นหนึ่งในสามรูปแบบ: การดาวน์โหลดซ้ำของเนื้อหาที่ไม่เปลี่ยน การอัปโหลด หรือการท่องดูที่ใช้เมทาดาทาหนักผ่านโฟลเดอร์ที่มีรายการนับพัน BranchCache จัดการรูปแบบแรกบนเนื้อหาที่รองรับ และไม่ทำอะไรที่เป็นประโยชน์กับอีกสองรูปแบบ นี่ไม่ใช่ข้อจำกัดที่ต้องหลบเลี่ยง แต่เป็นการเปรียบเทียบที่คุณควรทำก่อนจะใช้เวลาหนึ่งสัปดาห์กับการติดตั้ง

การแชร์เดียวกัน ข้อร้องเรียนสามแบบ

สำนักงานสาขาที่มีแปดคนเปิดวิดีโอฝึกอบรมเดียวกันที่ไม่เปลี่ยน คือกรณีที่ฟีเจอร์นี้ออกแบบมาเพื่อ การดึงครั้งแรกข้าม WAN เนื้อหาถูกแคชไว้ใกล้ผู้อ่าน และการดึงครั้งต่อๆ ไปของไฟล์เดิมที่ไม่เปลี่ยนจะถูกให้บริการในเครื่อง ประโยชน์เป็นของจริงและแคบ: เนื้อหาเดิม ไม่เปลี่ยน ผู้อ่านหลายคน

แล็ปท็อปที่อัปโหลดไฟล์บันทึกใหม่ผ่านการเชื่อมต่อที่บ้านคือกรณีตรงกันข้าม ไม่มีสำเนาที่แคชไว้ก่อนหน้าของไฟล์ที่ยังไม่มีอยู่ ดังนั้นการอัปโหลดจึงไปตามเส้นทางที่จำกัดเหมือนที่เคยเป็น แคชสำหรับดาวน์โหลดไม่ได้ลบการอัปโหลด และไม่มีตัวเลือกตำแหน่งใดที่เปลี่ยนสิ่งนั้นได้

รูปแบบที่สามทำให้คนผิดหวังเพราะดูเหมือนปัญหาเรื่องการดาวน์โหลด การเปิดไดเรกทอรีที่มีไฟล์หลายหมื่นไฟล์ การเรียงลำดับ และการอ่านเมทาดาทา เป็นลำดับของการดำเนินการเล็กๆ ไม่ใช่การถ่ายโอนวัตถุขนาดใหญ่ซ้ำๆ การแคชเนื้อหาไฟล์ไม่ช่วยอะไรกับการแจกแจง

แคชแบบกระจาย: พูล VPN ไม่ใช่ LAN ของสาขา

ในโหมดกระจาย คอมพิวเตอร์ไคลเอนต์แชร์เนื้อหาที่แคชไว้ระหว่างกัน และ Microsoft ระบุว่าโหมดนี้ทำงานภายในซับเน็ตเดียว พูลไคลเอนต์ VPN ไม่ใช่ซับเน็ตในความหมายนั้น แม้ที่อยู่ทั้งหมดจะดูต่อเนื่องกัน: การค้นหาเพียร์ การเข้าถึงระหว่างไคลเอนต์ และสิทธิ์ในการแลกเปลี่ยนข้อมูลแคชเป็นคำถามแยกต่างหาก และการออกแบบการเข้าถึงระยะไกลทั่วไปตอบทั้งสามอย่างว่า «ไม่»

คุณสามารถทำให้พูลทำตัวเหมือน LAN ของสาขาได้โดยอนุญาตทราฟฟิกระหว่างไคลเอนต์ แต่นั่นคือการตัดสินใจด้านความปลอดภัย ไม่ใช่ด้านแคช การออกแบบการเข้าถึงระยะไกลส่วนใหญ่แยกไคลเอนต์ออกจากกันก็เพื่อให้แล็ปท็อปที่ถูกละเมิดเข้าถึงเครื่องอื่นไม่ได้ และการแลกการแยกนั้นกับแคชที่ทำงานสักครั้งเป็นการแลกที่ไม่ดี เว้นแต่เพียร์เป็นฝ่ายที่เชื่อถือได้เท่ากันอยูแล้ว

สำหรับผู้ใช้เคลื่อนที่คนเดียว โหมดกระจายไม่มีใครให้แชร์ด้วย แคชยังให้บริการการอ่านซ้ำของไคลเอนต์เครื่องนั้นได้ แต่นั่นเป็นประโยชน์ของแคชฝั่งไคลเอนต์ ไม่ใช่ประโยชน์ของตำแหน่งในสาขา และควรพูดเช่นนั้นก่อนที่ใครจะคาดหวังว่าสำนักงานจะเร็วขึ้น

แคชแบบโฮสต์: ตำแหน่งเป็นตัวตัดสินว่าจะช่วยหรือไม่

แคชแบบโฮสต์วางแคชที่แชร์ไว้บนเซิร์ฟเวอร์ ซึ่งเป็นโหมดเดียวที่สมเหตุผลข้ามซับเน็ต และเป็นโหมดเดียวที่ทำงานได้เมื่อไคลเอนต์คุยกันไม่ได้ คำถามแรกคือเซิร์ฟเวอร์นั้นอยู่ที่ไหน แคชแบบโฮสต์ที่เข้าถึงผ่านลิงก์จำกัดเส้นเดียวกับต้นทางได้ย้ายไบต์ ไม่ได้ย้ายปัญหา

วางไว้ใกล้ผู้อ่าน กำหนดเจ้าของ และกำหนดขนาดดิสก์ตามชุดทำงาน ไม่ใช่ตามการแชร์ทั้งหมด ภาพรวม BranchCache ของ Microsoft อธิบายทั้งสองโหมดและพฤติกรรมของไคลเอนต์ รวมถึงส่วนที่คนมักลืม: ไคลเอนต์ยังติดต่อต้นทางเพื่อขออนุญาตและข้อมูลเนื้อหาก่อนใช้ข้อมูลที่แคชไว้

การติดตั้งคือสามบทบาทที่วางแผนร่วมกัน ไม่ใช่ช่องทำเครื่องหมายเดียว เซิร์ฟเวอร์ต้นทางเผยแพร่แฮชของเนื้อหา แคชแบบโฮสต์ถูกเปิดใช้และค้นพบได้ และไคลเอนต์ถูกกำหนดค่าให้ใช้งานมัน ทางฝั่งเซิร์ฟเวอร์สามารถรู้ได้ใน PowerShell:

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

บนไคลเอนต์ ให้ชี้ไปที่เซิร์ฟเวอร์ที่ระบุชื่อ หรือปล่อยให้ค้นหาผ่านจุดเชื่อมต่อบริการ แล้วยืนยันโหมดที่มันเลือกจริง แทนที่จะอธิฐานว่านโยบายถูกนำไปใช้แล้ว:

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

สิ่งที่ยังไปถึงต้นทาง

แคชไม่ได้ลบการอนุญาต ไคลเอนต์ที่ไม่มีสิทธิ์อ่านไฟล์ไม่ได้เข้าถึงเพราะคนอื่นแคชไว้ และต้นทางยังตอบคำถามเรื่องการอนุญาตและให้ข้อมูลเนื้อหาที่ทำให้การค้นหาในแคชเป็นไปได้ หากเข้าถึงต้นทางไม่ได้ สำเนาที่แคชไว้อย่างเดียวก็ไม่ได้กลายเป็นการแชร์แบบออฟไลน์

การเปลี่ยนแปลงเนื้อหาก็ทำลายข้อสมมตินี้อย่างเงียบๆ ไฟล์ที่บันทึกใหม่ เข้ารหัสใหม่ หรือถูกผลิตภัณฑ์สำรองข้อมูลแตะต้องอาจไม่ตรงกับแฮชที่แคชไว้อีกต่อไป และการอ่านครั้งถัดไปก็กลับไปที่ต้นทาง นั่นคือพฤติกรรมที่ถูกต้อง และเป็นเหตุผลที่แคชที่ชุดทำงานเปลี่ยนทุกชั่วโมงให้ประโยชน์น้อย

การขับออกคือขีดจำกัดที่สาม แคชมีขนาดจำกัด ดังนั้นชุดทำงานขนาดใหญ่จะดันเนื้อหาเก่าออกไป และประโยชน์ขึ้นอยูกับการที่การอ่านซ้ำเกิดขึ้นก่อนการขับออก ไม่ใช่หลังจากนั้น การกำหนดขนาดแคชตามการแชร์ทั้งหมดเป็นวิธีปกติที่จะผิดหวังกับการติดตั้งที่ถูกต้องทางเทคนิค

ยอมรับด้วยการดึงสองครั้งและการอัปโหลดหนึ่งครั้ง

ทดสอบสามกระแสที่ถูกต้องและจดว่าแต่ละอย่างแสดงอะไร การดึงไฟล์ตัวแทนจากไคลเอนต์ครั้งแรก วัดที่ลิงก์ต้นทางและที่นาฬิกาของผู้ใช้ การดึงไฟล์เดิมที่ไม่เปลี่ยนครั้งที่สองจากไคลเอนต์เครื่องที่สองในกลุ่มตำแหน่งเดียวกัน การอัปโหลดไฟล์ใหม่หนึ่งครั้ง ซึ่งไม่ควรแสดงการปรับปรุงและยืนยันว่าแคชไม่ได้รับเครดิตสำหรับสิ่งที่มันไม่เคยทำ

หากการดึงครั้งที่สองยังข้ามลิงก์ต้นทางสำหรับไบต์ส่วนใหญ่ แสดงว่าไม่ได้ใช้แคช และสาเหตุที่พบบ่อยคือไคลเอนต์อยู่ในโหมดผิด การเผยแพร่แฮชที่ขาดหายบนต้นทาง หรือแคชแบบโฮสต์ที่อยู่ฝั่งผิดของลิงก์จำกัด เหล่านั้นคือการแก้ไขที่แตกต่างกันสามอย่าง และมีเพียงอย่างเดียวที่เกี่ยวกับตำแหน่งในเครือข่าย

จากนั้นกล่าวข้อสรุปในรูปแบบเดียวกับข้อร้องเรียนเดิม: การดาวน์โหลดซ้ำของเนื้อหาที่ไม่เปลี่ยนจากต้นทางนี้ไปยังผู้อ่านเหล่านี้ได้รับการให้บริการโดยแคชนี้ ทุกอย่างเกี่ยวกับการแชร์ยังคงไม่ถูกแตะต้อง รวมถึงการอัปโหลด การแจกแจงโฟลเดอร์ และเรื่องราวออฟไลน์ ซึ่งยังต้องมีคำตอบของตัวเอง