แคชเมทาดาทาของ Azure Files กับการแคชสาขาในเครื่อง
แคชเมทาดาทาฝั่งบริการช่วยลดงานของเซิร์ฟเวอร์ แต่ไม่ได้ย้ายการไปกลับออกจาก WAN ของคุณ เปรียบเทียบทั้งสองด้วยสิ่งที่ลดลงจริง
สำหรับการเข้าถึง Azure Files ที่ช้าผ่าน VPN มีการเสนอการเปลี่ยนแปลงสองอย่าง และทั้งสองลดสิ่งที่แตกต่างกัน แคชเมทาดาทาฝั่งบริการทำให้การดำเนินการที่เข้าเกณฑ์มีต้นทุนต่ำลงสำหรับเซิร์ฟเวอร์ แคชสาขาในเครื่องนำไบต์และการดำเนินการเข้ามาใกล้ผู้ใช้มากขึ้น การเลือกระหว่างสองวิธีด้วยรายการราคาหรือข่าวประชาสัมพันธ์คือหนทางที่แชร์จะเร็วขึ้นในการทดสอบและไม่เปลี่ยนแปลงตอนเก้าโมงเช้า
สองแคช สองความหน่วงที่ต่างกัน
ทั้งสองทางเลือกปรากฏอยู่ใต้คำว่าแคช และนั่นคือจุดที่ความสับสนเริ่มต้น ทั้งสองอยู่คนละด้านของเครือข่าย
| 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 |
คู่มือ ประสิทธิภาพ SMB ของ Microsoft อธิบายการแคชเมทาดาทาสำหรับแชร์ SSD ที่เข้าเกณฑ์ พร้อมขั้นตอนการลงทะเบียนที่มาด้วย ความเข้าเกณฑ์และสถานะของคุณลักษณะขึ้นกับบัญชีที่เก็บข้อมูลจริง ดังนั้นอ่านหน้าปัจจุบัน ไม่ใช่ประกาศตัวอย่างจากสองปีก่อน
แบ่งการรอออกเป็นสามส่วน
ทุกรายการไดเรกทอรีที่ช้ามีส่วนประกอบต้นทุนสามอย่าง และตอบสนองต่อการแก้ไขที่ต่างกัน มีเวลาประมวลผลคำขอฝั่งบริการ จำนวนการไปกลับที่พึ่งพาผ่าน VPN และเพย์โหลดที่ต้องย้าย แคชฝั่งบริการโจมตีอย่างแรก ไม่มีสิ่งใดฝั่งเซิร์ฟเวอร์โจมตีอย่างที่สอง
นั่นคือเหตุผลที่แชร์สามารถแสดงเมตริกบริการที่ดีกว่าได้ ในขณะที่ตัวเลือกไฟล์ของผู้ใช้ยังค้างอยู่แปดวินาที
แต่ละทางเลือกได้ที่ทางของตนที่ใด
หากภาระงานหนักด้านเมทาดาทา มีการเปิดจำนวนมาก การเรียก stat และการนับไดเรกทอรีกับแชร์ SSD ที่เข้าเกณฑ์ การแคชฝั่งบริการคือการทดลองที่ถูก ไม่ต้องใช้โครงสร้างพื้นฐานใหม่และไม่เปลี่ยนวิธีที่ผู้ใช้เข้าถึงแชร์
หากภาระงานเป็นแบบโต้ตอบและถูกจำกัดด้วยความหน่วง ทางเลือกที่ซื่อตรงคือการออกแบบเซิร์ฟเวอร์ในเครื่องที่รองรับพร้อมแบบจำลองการซิงโครไนซ์ที่มีเอกสาร นี่คือสถาปัตยกรรมอื่นที่มีต้นทุนการดำเนินงานของตัวเอง ไม่ใช่สวิตช์
สิ่งที่ทั้งสองทางเลือกไม่เปลี่ยน
การลงนามและการเข้ารหัส SMB ยังมีผล และยังมีต้นทุนตามที่เป็นอยู่ การควบคุมการเข้าถึงยังคงแก้ไขตามผู้ใช้แต่ละราย ดังนั้นสำเนาที่แคชไว้ไม่ทำให้การอนุญาตง่ายขึ้น ความสอดคล้องระหว่างไซต์ยังต้องมีแบบจำลองที่กำหนดไว้ เพราะการอ่านในสาขาและการเขียนฝั่งคลาวด์ต้องตกลงกันในบางสิ่ง และการเข้าถึงแบบออฟไลน์ยังเป็นการตั้งค่าของไคลเอนต์ ไม่ใช่ผลข้างเคียงของคุณลักษณะเซิร์ฟเวอร์
เมื่อมีคนสัญญาว่าคุณลักษณะของบริการจะขจัดการไปกลับของ WAN นั่นคือข้อกล่าวอ้างที่ต้องทดสอบก่อน
วัดกับการดำเนินการที่ผู้ใช้ร้องเรียน
จับเวลาการดำเนินการที่แน่นอน ไม่ใช่สำเนาสังเคราะห์ Measure-Command { Get-ChildItem \\files\projects -Recurse } บนไคลเอนต์สาขาให้ตัวเลขที่คุณเปรียบเทียบก่อนและหลังได้ และ Get-SmbMultichannelConnection แสดงว่าไคลเอนต์ใช้เส้นทางมากกว่าหนึ่งหรือไม่ วางสิ่งนั้นไว้ข้างเมตริกความหน่วงฝั่งบริการสำหรับหน้าต่างเวลาเดียวกัน
รักษาแชร์ ตำแหน่งไคลเอนต์ เส้นทาง VPN และนโยบายความปลอดภัยให้คงที่ มิฉะนั้นคุณกำลังวัดหน้าต่างการเปลี่ยนแปลงของคุณ ไม่ใช่คุณลักษณะ บันทึกจำนวนไฟล์และการกระจายขนาดด้วย เพราะภาระงานไฟล์เล็กและการคัดลอกจำนวนมากตอบสนองต่อคันโยกที่ต่างกันโดยสิ้นเชิง
ผลลัพธ์ที่ควรค่าแก่การมีคือการเปลี่ยนแปลงที่ตรงกับขอบเขตที่ช้าจริง โดยมีต้นทุนการดำเนินงานและความสอดคล้องเขียนไว้ ตัวเลข IOPS ของที่เก็บข้อมูลที่ใหญ่ขึ้นบนสไลด์ไม่ใช่ผลลัพธ์นั้น