Date: Mei 16, 2022
Kinerja Azure Shared Disk Dengan Zone Redundant Storage (ZRS)
Pada 9 September 2021, Microsoft diumumkan ketersediaan umum Penyimpanan Zona-Redundan (ZRS) untuk Penyimpanan Disk Azure , termasuk Disk Bersama Azure.
Yang membuat hal ini menarik adalah Anda sekarang dapat membangun instans cluster failover berbasis penyimpanan bersama yang menjangkau Availability Zone (AZ).Dengan node cluster yang berada di AZ yang berbeda, pengguna kini dapat memenuhi syarat untuk SLA ketersediaan 99,99%. Sebelum dukungan untuk Zone Redundant Storage, Azure Shared Disks hanya mendukung Locally Redundant Storage (LRS), membatasi penerapan cluster ke satu AZ, membuat pengguna rentan terhadap pemadaman jika AZ offline.
Namun ada beberapa batasan yang harus diperhatikan saat menggunakan Azure Shared Disk dengan ZRS.
- Hanya didukung dengan solid-state drive (SSD) premium dan SSD standar. Azure Ultra Disk tidak didukung.
- Disk Bersama Azure dengan ZRS saat ini hanya tersedia di wilayah AS Barat 2, Eropa Barat, Eropa Utara, dan Prancis Tengah
- Disk Caching, baik membaca dan menulis, tidak didukung dengan Premium SSD Azure Shared Disks
- Disk bursting tidak tersedia untuk SSD premium
- Dukungan Pemulihan Situs Azure belum tersedia.
- Azure Backup hanya tersedia melalui Azure Disk Backup.
- Hanya enkripsi sisi server yang didukung, Enkripsi Disk Azure saat ini tidak didukung.
Saya juga menemukan catatan menarik di dokumentasi .
“Kecuali untuk latensi tulis yang lebih banyak, disk yang menggunakan ZRS identik dengan disk yang menggunakan LRS, mereka memiliki target skala yang sama. Benchmark disk Anda untuk mensimulasikan beban kerja aplikasi Anda dan membandingkan latensi antara disk LRS dan ZRS.” Sementara dokumentasi menunjukkan bahwa ZRS akan menimbulkan beberapa latensi tulis tambahan, terserah pengguna untuk menentukan berapa banyak latensi tambahan yang dapat mereka harapkan. Tautan ke patokan disk dokumen disediakan untuk membantu memandu Anda dalam pengujian kinerja Anda.
Mengikuti panduan dalam dokumen, saya menggunakan DiskSpd untuk mengukur latensi tulis tambahan yang mungkin Anda alami. Tentu saja hasil akan bervariasi dengan beban kerja, jenis disk, ukuran instans, dll., tetapi inilah hasil saya.
| Penyimpanan Lokal Redundan (LRS) | Penyimpanan Berlebihan Zona (ZRS) | |
| Tulis IOPS | 5099.82 | 4994.63 |
| Latensi Rata-rata | 7.830 | 7.998 |
Tes DiskSpd yang saya jalankan menggunakan parameter berikut.
diskspd -c200G -w100 -b8K -F8 -r -o5 -W30 -d10 -Sh -L testfile.dat Saya menulis ke disk P30 dengan ZRS dan P30 dengan LRS terpasang ke Standar DS3 v2 (4 vcpus, memori 14 GiB ) jenis contoh. ZRS P30 bersama juga dilampirkan ke instans identik di AZ berbeda dan ditambahkan sebagai penyimpanan bersama ke aplikasi klaster kosong.
Overhead 2% tampaknya merupakan harga yang wajar untuk dibayar agar data Anda didistribusikan secara sinkron di dua AZ. Namun, saya bertanya-tanya apa yang akan terjadi jika Anda memindahkan aplikasi berkerumun ke node jarak jauh, secara efektif menempatkan disk Anda di satu AZ dan instans Anda di AZ yang berbeda.
Berikut adalah hasilnya.
| Penyimpanan Lokal Redundan (LRS) | Penyimpanan Berlebihan Zona (ZRS) | ZRS saat menulis dari remote AZ | |
| Tulis IOPS | 5099.82 | 4994.63 | 4079.72 |
| Latensi Rata-rata | 7.830 | 7.998 | 9.800 |
Dalam skenario itu saya mengukur peningkatan latensi tulis 25%. Jika Anda mengalami kegagalan total pada AZ, penyimpanan dan instans akan dialihkan ke AZ sekunder dan Anda tidak akan mengalami peningkatan latensi ini sama sekali. Namun, skenario kegagalan lain yang tidak seluas AZ dapat membuat aplikasi terklaster Anda berjalan di satu AZ dengan Azure Shared Disk Anda berjalan di AZ yang berbeda. Dalam skenario tersebut, Anda ingin memindahkan beban kerja yang dikelompokkan kembali ke node yang berada di AZ yang sama dengan penyimpanan Anda sesegera mungkin untuk menghindari overhead tambahan.
Microsoft mendokumentasikan cara memulai failover akun penyimpanan ke wilayah yang berbeda saat menggunakan GRS, tetapi tidak ada cara untuk secara manual memulai failover akun penyimpanan ke AZ yang berbeda saat menggunakan Penyimpanan Zona Redundan. Anda harus memantau instans kluster failover untuk memastikan Anda diberi tahu setiap kali beban kerja kluster pindah ke server lain dan berencana untuk memindahkannya kembali segera setelah aman untuk melakukannya.
Anda dapat menemukan diri Anda dalam situasi ini secara tak terduga, tetapi itu juga pasti akan terjadi selama pemeliharaan terencana dari server aplikasi berkerumun saat Anda melakukan pembaruan bergulir. Kesadaran adalah kunci untuk membantu Anda meminimalkan jumlah waktu penyimpanan Anda bekerja dalam keadaan terdegradasi.
Saya berharap di masa depan Microsoft mengizinkan pengguna untuk memulai failover manual dari disk ZRS sama seperti yang mereka lakukan dengan GRS. Alasan mereka menambahkan fitur ke GRS adalah untuk menempatkan kekuasaan di tangan pengguna jika kegagalan otomatis tidak terjadi seperti yang diharapkan. Dalam kasus Zone Redundant Storage, saya dapat melihat orang-orang yang ingin mencoba menyatukan penyimpanan dan aplikasi, memastikan keduanya selalu berjalan di AZ yang sama, mirip dengan cara solusi replikasi berbasis host seperti SIOS DataKeeper melakukannya.