Date: พฤษภาคม 16, 2022
ประสิทธิภาพของ Azure Shared Disk พร้อม Zone Redundant Storage (ZRS)
เมื่อวันที่ 9 กันยายน 2564 Microsoft ประกาศ ความพร้อมใช้งานทั่วไปของ Zone-Redundant Storage (ZRS) สำหรับ Azure Disk Storage รวมถึง Azure Shared Disk
สิ่งที่ทำให้สิ่งนี้น่าสนใจคือตอนนี้คุณสามารถสร้างอินสแตนซ์คลัสเตอร์ล้มเหลวที่จัดเก็บข้อมูลที่ใช้ร่วมกันซึ่งครอบคลุม Availability Zone (AZ)ด้วยโหนดคลัสเตอร์ที่อยู่ใน AZ ต่างๆ ผู้ใช้จึงมีสิทธิ์ได้รับ SLA ความพร้อมใช้งาน 99.99% ก่อนที่จะรองรับ Zone Redundant Storage นั้น Azure Shared Disks รองรับ Locally Redundant Storage (LRS) เท่านั้น ซึ่งจำกัดการปรับใช้คลัสเตอร์เป็น AZ เดียว ทำให้ผู้ใช้เสี่ยงต่อไฟดับหาก AZ ออฟไลน์
อย่างไรก็ตาม มีข้อจำกัดบางประการที่ต้องระวังเมื่อปรับใช้ Azure Shared Disk กับ ZRS
- รองรับเฉพาะไดรฟ์โซลิดสเทตระดับพรีเมียม (SSD) และ SSD มาตรฐานเท่านั้น ไม่รองรับดิสก์ Azure Ultra
- ปัจจุบัน Azure Shared Disk ที่มี ZRS พร้อมให้บริการในภูมิภาค West US 2, West Europe, North Europe และ France Central เท่านั้น
- Disk Caching ทั้งอ่านและเขียนไม่รองรับ Premium SSD Azure Shared Disks
- การระเบิดดิสก์ไม่พร้อมใช้งานสำหรับ SSD ระดับพรีเมียม
- การสนับสนุน Azure Site Recovery ยังไม่พร้อมใช้งาน
- Azure Backup พร้อมใช้งานผ่าน Azure Disk Backup เท่านั้น
- รองรับการเข้ารหัสฝั่งเซิร์ฟเวอร์เท่านั้น ในขณะนี้ไม่รองรับการเข้ารหัสดิสก์ Azure
ฉันยังพบบันทึกที่น่าสนใจใน เอกสาร .
“ยกเว้นเวลาแฝงในการเขียนที่มากขึ้น ดิสก์ที่ใช้ ZRS จะเหมือนกับดิสก์ที่ใช้ LRS โดยมีเป้าหมายขนาดเดียวกัน เปรียบเทียบดิสก์ของคุณเพื่อจำลองปริมาณงานของแอปพลิเคชันของคุณและเปรียบเทียบเวลาแฝงระหว่างดิสก์ LRS และ ZRS” แม้ว่าเอกสารประกอบจะระบุว่า ZRS จะทำให้เกิดเวลาในการตอบสนองในการเขียนเพิ่มเติม แต่ก็ขึ้นอยู่กับผู้ใช้ที่จะกำหนดว่าพวกเขาสามารถคาดหวังเวลาในการตอบสนองเพิ่มเติมได้มากเพียงใด ลิงก์ไปยัง มาตรฐานดิสก์ เอกสารนี้จัดทำขึ้นเพื่อช่วยแนะนำคุณในการทดสอบประสิทธิภาพของคุณ
ตามคำแนะนำในเอกสาร ฉันใช้ DiskSpd เพื่อวัดเวลาแฝงในการเขียนเพิ่มเติมที่คุณอาจพบ แน่นอนว่าผลลัพธ์จะแตกต่างกันไปตามปริมาณงาน ประเภทดิสก์ ขนาดอินสแตนซ์ ฯลฯ แต่นี่คือผลลัพธ์ของฉัน
| พื้นที่จัดเก็บซ้ำซ้อนในเครื่อง (LRS) | พื้นที่จัดเก็บซ้ำซ้อน (ZRS) | |
| เขียน IOPS | 5099.82 | 4994.63 |
| เวลาในการตอบสนองเฉลี่ย | 7.830 | 7.998 |
การทดสอบ DiskSpd ที่ฉันเรียกใช้ใช้พารามิเตอร์ต่อไปนี้
diskspd -c200G -w100 -b8K -F8 -r -o5 -W30 -d10 -Sh -L testfile.dat ฉันเขียนไปยังดิสก์ P30 ที่มี ZRS และ P30 พร้อม LRS ที่ต่อกับ Standard DS3 v2 (4 vcpus, หน่วยความจำ 14 GiB ) ประเภทอินสแตนซ์ นอกจากนี้ ZRS P30 ที่แชร์ยังแนบกับอินสแตนซ์ที่เหมือนกันใน AZ อื่น และเพิ่มเป็นที่จัดเก็บข้อมูลที่ใช้ร่วมกันในแอปพลิเคชันคลัสเตอร์ที่ว่างเปล่า
ค่าใช้จ่าย 2% ดูเหมือนจะเป็นราคาที่สมเหตุสมผลที่จะจ่ายเพื่อให้ข้อมูลของคุณกระจายพร้อมกันใน AZ สองแห่ง อย่างไรก็ตาม ฉันสงสัยว่าจะเกิดอะไรขึ้นหากคุณย้ายแอปพลิเคชันแบบคลัสเตอร์ไปยังโหนดระยะไกล โดยทำให้ดิสก์ของคุณอยู่ใน AZ เดียวและอินสแตนซ์ของคุณใน AZ อื่น
นี่คือผลลัพธ์
| พื้นที่จัดเก็บซ้ำซ้อนในเครื่อง (LRS) | พื้นที่จัดเก็บซ้ำซ้อน (ZRS) | ZRS เมื่อเขียนจาก AZ . ระยะไกล | |
| เขียน IOPS | 5099.82 | 4994.63 | 4079.72 |
| เวลาในการตอบสนองเฉลี่ย | 7.830 | 7.998 | 9.800 |
ในสถานการณ์นั้น ฉันวัดเวลาแฝงในการเขียนที่เพิ่มขึ้น 25% หากคุณพบความล้มเหลวโดยสมบูรณ์ของ AZ ทั้งพื้นที่จัดเก็บและอินสแตนซ์จะเฟลโอเวอร์ไปยัง AZ สำรอง และคุณไม่ควรพบกับเวลาแฝงที่เพิ่มขึ้นนี้เลย อย่างไรก็ตาม สถานการณ์ความล้มเหลวอื่นๆ ที่ไม่ได้ครอบคลุม AZ อาจทำให้แอปพลิเคชันแบบคลัสเตอร์ของคุณทำงานใน AZ เดียวโดยมี Azure Shared Disk ทำงานใน AZ อื่น ในสถานการณ์เหล่านี้ คุณจะต้องย้ายเวิร์กโหลดแบบคลัสเตอร์ของคุณกลับไปยังโหนดที่อยู่ใน AZ เดียวกันกับที่เก็บข้อมูลของคุณโดยเร็วที่สุดเพื่อหลีกเลี่ยงโอเวอร์เฮดเพิ่มเติม
Microsoft เอกสารวิธีการ เริ่มต้นความล้มเหลวของบัญชีการจัดเก็บ ไปยังภูมิภาคอื่นเมื่อใช้ GRS แต่ไม่มีวิธีเริ่มต้นการเฟลโอเวอร์ของบัญชีพื้นที่จัดเก็บด้วยตนเองไปยัง AZ อื่นเมื่อใช้ Zone Redundant Storage คุณควรตรวจสอบอินสแตนซ์ของคลัสเตอร์ที่ล้มเหลวเพื่อให้แน่ใจว่าคุณได้รับการแจ้งเตือนทุกครั้งที่ปริมาณงานของคลัสเตอร์ย้ายไปที่เซิร์ฟเวอร์อื่น และวางแผนที่จะย้ายกลับทันทีที่ปลอดภัย
คุณสามารถพบว่าตัวเองอยู่ในสถานการณ์นี้โดยไม่คาดคิด แต่จะเกิดขึ้นอย่างแน่นอนในระหว่างการบำรุงรักษาที่วางแผนไว้ของแอปพลิเคชันเซิร์ฟเวอร์แบบคลัสเตอร์เมื่อคุณทำการอัปเดตทีละน้อย การรับรู้เป็นกุญแจสำคัญที่จะช่วยให้คุณลดระยะเวลาที่จัดเก็บข้อมูลของคุณในสถานะที่เสื่อมโทรมลง
ฉันหวังว่าในอนาคต Microsoft จะอนุญาตให้ผู้ใช้เริ่มต้นการเฟลโอเวอร์ด้วยตนเองของดิสก์ ZRS เช่นเดียวกับที่ทำกับ GRS เหตุผลที่พวกเขาเพิ่มคุณลักษณะนี้ให้กับ GRS ก็คือการให้อำนาจแก่ผู้ใช้ในกรณีที่เกิดข้อผิดพลาดโดยอัตโนมัติไม่เกิดขึ้นตามที่คาดไว้ ในกรณีของ Zone Redundant Storage ฉันเห็นว่าผู้คนต้องการลองเชื่อมโยงพื้นที่จัดเก็บและแอปพลิเคชันเข้าด้วยกัน เพื่อให้มั่นใจว่าพวกเขาจะทำงานใน AZ เดียวกันเสมอ คล้ายกับวิธีที่โซลูชันการจำลองแบบอิงโฮสต์ เช่น SIOS DataKeeper ทำ