Tolok ukur performa volume reguler Azure NetApp Files untuk Linux

Artikel ini menjelaskan tolok ukur performa yang dikirimkan Azure NetApp Files untuk Linux dengan volume reguler.

Seluruh beban kerja streaming file (pengujian tolok ukur peluasan skala)

Niat pengujian peluasan skala adalah untuk menunjukkan performa volume Azure NetApp File saat meluaskan skala (atau meningkatkan) jumlah klien yang menghasilkan beban kerja bersamaan ke volume yang sama. Pengujian ini umumnya dapat mendorong volume ke tepi batas performanya dan menunjukkan beban kerja seperti penyajian media, AI/ML, dan beban kerja lainnya yang menggunakan farm komputasi besar untuk melakukan pekerjaan.

Konfigurasi tolok ukur peluasan skala I/OP tinggi

Tolok ukur ini menggunakan yang berikut:

• Satu volume reguler Azure NetApp Files 100-TiB dengan himpunan data 1 TiB menggunakan tingkat performa Ultra
• FIO (dengan dan tanpa pengaturan randrepeat=0)
• Ukuran blok 4-KiB dan 8 KiB
• 6 D32s_v5 komputer virtual yang menjalankan RHEL 9.3
• NFSv3
• Manual QoS
• Opsi pemasangan: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Konfigurasi tolok ukur peluasan skala throughput tinggi

Tolok ukur ini menggunakan yang berikut:

• Satu volume reguler Azure NetApp Files dengan himpunan data 1-TiB menggunakan FIO tingkat performa Ultra (dengan dan tanpa mengatur randrepeat=0)
• FIO (dengan dan tanpa pengaturan randrepeat=0)
• Ukuran blok 64-KiB dan 256 KiB
• 6 D32s_v5 komputer virtual yang menjalankan RHEL 9.3
• NFSv3
• Manual QoS
• Opsi pemasangan: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Konfigurasi tolok ukur koneksi jaringan paralel (nconnect)

Tolok ukur ini menggunakan yang berikut:

• Satu volume reguler Azure NetApp Files dengan himpunan data 1-TiB menggunakan tingkat performa Ultra
• FIO (dengan dan tanpa pengaturan randrepeat=0)
• 4-KiB dan 64-KiB wsize/rsize
• Satu D32s_v4 komputer virtual yang menjalankan RHEL 9.3
• NFSv3 dengan dan tanpa nconnect
• Opsi pemasangan: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Meningkatkan pengujian tolok ukur

Tujuan pengujian peningkatan skala adalah untuk menunjukkan performa volume Azure NetApp File saat meningkatkan (atau meningkatkan) jumlah pekerjaan yang menghasilkan beban kerja bersamaan di beberapa koneksi TCP pada satu klien ke volume yang sama (seperti dengan nconnect).

Tanpa nconnect, beban kerja ini tidak dapat mendorong batas performa maksimum volume, karena klien tidak dapat menghasilkan cukup IO atau throughput jaringan. Pengujian ini umumnya menunjukkan pengalaman satu pengguna dalam beban kerja seperti penyajian media, database, AI/ML, dan berbagi file umum.

Tolok ukur peluasan skala I/OP tinggi

Tolok ukur berikut menunjukkan performa yang dicapai untuk Azure NetApp Files dengan beban kerja I/OP tinggi menggunakan:

• 32 klien
• Baca dan tulis acak 4-KiB dan 8-KiB
• Himpunan data 1-TiB
• Rasio baca/tulis sebagai berikut: 100%:0%, 90%:10%, 80%:20%, dan seterusnya
• Dengan dan tanpa penembolokan sistem file yang terlibat (menggunakan randrepeat=0 di FIO)

Untuk informasi selengkapnya, lihat Metodologi pengujian.

Hasil: 4 KiB, acak, penembolokan klien disertakan

Dalam tolok ukur ini, FIO berjalan tanpa randrepeat opsi untuk mengacak data. Dengan demikian, jumlah penembolokan yang tidak ditentukan mulai dimainkan. Konfigurasi ini menghasilkan jumlah performa keseluruhan yang sedikit lebih baik daripada pengujian yang dijalankan tanpa penembolokan dengan seluruh tumpukan IO yang digunakan.

Dalam grafik berikut, pengujian menunjukkan volume reguler Azure NetApp Files dapat menangani antara sekitar 130.000 tulisan 4-KiB acak murni dan sekitar 460.000 pembacaan 4 KiB acak murni selama tolok ukur ini. Campuran baca-tulis untuk beban kerja yang disesuaikan sebesar 10% untuk setiap eksekusi.

Ketika campuran I/OP baca-tulis meningkat menuju write-heavy, total I/OPS berkurang.

Hasil: 4 KiB, acak, penembolokan klien dikecualikan

Dalam tolok ukur ini, FIO dijalankan dengan pengaturan randrepeat=0 untuk mengacak data, mengurangi pengaruh penembolokan pada performa. Hal ini mengakibatkan pengurangan sekitar 8% dalam I/OPS tulis dan pengurangan sekitar 17% dalam I/OPS baca, tetapi menampilkan angka performa lebih mewakili apa yang benar-benar dapat dilakukan penyimpanan.

Dalam grafik berikut, pengujian menunjukkan volume reguler Azure NetApp Files dapat menangani antara sekitar 120.000 tulisan 4-KiB acak murni dan sekitar 388.000 bacaan 4-KiB acak murni. Campuran baca-tulis untuk beban kerja yang disesuaikan sebesar 25% untuk setiap eksekusi.

Ketika campuran I/OP baca-tulis meningkat menuju write-heavy, total I/OPS berkurang.

Hasil: 8 KiB, acak, penembolokan klien dikecualikan

Ukuran baca dan tulis yang lebih besar akan menghasilkan lebih sedikit total I/OPS, karena lebih banyak data dapat dikirim dengan setiap operasi. Ukuran baca dan tulis 8 KiB digunakan untuk mensimulasikan dengan lebih akurat apa yang digunakan sebagian besar aplikasi modern. Misalnya, banyak aplikasi EDA menggunakan baca dan tulis 8-KiB.

Dalam tolok ukur ini, FIO berlari dengan randrepeat=0 untuk mengacak data sehingga dampak penembolokan klien berkurang. Dalam grafik berikut, pengujian menunjukkan bahwa volume reguler Azure NetApp Files dapat menangani antara sekitar 111.000 tulisan 8-KiB acak murni dan sekitar 293.000 bacaan 8-KiB acak murni. Campuran baca-tulis untuk beban kerja yang disesuaikan sebesar 25% untuk setiap eksekusi.

Ketika campuran I/OP baca-tulis meningkat menuju write-heavy, total I/OPS berkurang.

Perbandingan berdampingan

Untuk menggambarkan bagaimana penembolokan dapat memengaruhi pengujian tolok ukur performa, grafik berikut menunjukkan total I/OPS untuk pengujian 4-KiB dengan dan tanpa mekanisme penembolokan di tempat. Seperti yang ditunjukkan, penembolokan memberikan sedikit peningkatan performa untuk Tren I/OPS yang cukup konsisten.

Offset tertentu, streaming beban kerja baca/tulis acak: pengujian peningkatan skala menggunakan koneksi jaringan paralel (nconnect)

Pengujian berikut menunjukkan tolok ukur I/OP tinggi menggunakan satu klien dengan beban kerja acak 4-KiB dan himpunan data 1-TiB. Campuran beban kerja yang dihasilkan menggunakan kedalaman I/O yang berbeda setiap kali. Untuk meningkatkan performa beban kerja klien tunggal, nconnect opsi pemasangan digunakan untuk meningkatkan paralelisme dibandingkan dengan pemasangan klien tanpa nconnect opsi pemasangan.

Saat menggunakan koneksi TCP standar yang hanya menyediakan satu jalur ke penyimpanan, lebih sedikit total operasi yang dikirim per detik daripada ketika pemasangan dapat memanfaatkan lebih banyak koneksi TCP (seperti dengan nconnect) per titik pemasangan. Saat menggunakan nconnect, total latensi untuk operasi umumnya lebih rendah. Pengujian ini juga dijalankan dengan randrepeat=0 untuk dengan sengaja menghindari penembolokan. Untuk informasi selengkapnya tentang opsi ini, lihat Metodologi pengujian.

Hasil: 4 KiB, acak, dengan dan tanpa nconnect, penembolokan dikecualikan

Grafik berikut menunjukkan perbandingan berdampingan dari pembacaan dan penulisan 4 KiB dengan dan tanpa nconnect menyoroti peningkatan performa yang terlihat saat menggunakan nconnect: I/OPS keseluruhan yang lebih tinggi, latensi yang lebih rendah.

Tolok ukur throughput tinggi

Tolok ukur berikut menunjukkan performa yang dicapai untuk Azure NetApp Files dengan beban kerja throughput tinggi.

Beban kerja throughput tinggi bersifat lebih berurutan dan seringkali baca/tulis berat dengan metadata rendah. Throughput umumnya lebih penting daripada I/OPS. Beban kerja ini biasanya memanfaatkan ukuran baca/tulis yang lebih besar (64K hingga 256K), yang menghasilkan latensi yang lebih tinggi daripada ukuran baca/tulis yang lebih kecil, karena payload yang lebih besar secara alami akan memakan waktu lebih lama untuk diproses.

Contoh beban kerja throughput tinggi meliputi:

• Repositori media
• Komputasi performa tinggi
• AI/ML/LLP

Pengujian berikut menunjukkan tolok ukur throughput tinggi menggunakan beban kerja berurutan 64-KiB dan 256 KiB dan himpunan data 1 TiB. Campuran beban kerja yang dihasilkan mengurangi persentase yang ditetapkan pada satu waktu dan menunjukkan apa yang dapat Anda harapkan saat menggunakan berbagai rasio baca/tulis (misalnya, 100%:0%, 90%:10%, 80%:20%, dan sebagainya).

Hasil: I/O berurutan 64 KiB, penembolokan disertakan

Dalam tolok ukur ini, FIO berjalan menggunakan logika perulangan yang lebih agresif mengisi cache, sehingga jumlah penembolokan yang tidak ditentukan memengaruhi hasilnya. Ini menghasilkan jumlah performa keseluruhan yang sedikit lebih baik daripada pengujian yang dijalankan tanpa penembolokan.

Dalam grafik di bawah ini, pengujian menunjukkan bahwa volume reguler Azure NetApp Files dapat menangani antara sekitar 4.500MiB/dtk baca berurutan murni 64-KiB dan sekitar 1.600 MiB/dtk tulis 64-KiB berurutan murni. Campuran baca-tulis untuk beban kerja disesuaikan sebesar 10% untuk setiap eksekusi.

Hasil: I/O berurutan 64 KiB, baca vs. tulis, garis besar tanpa penembolokan

Dalam tolok ukur dasar ini, pengujian menunjukkan bahwa volume reguler Azure NetApp Files dapat menangani antara sekitar 3.600 MiB/dtk baca berurutan murni 64-KiB dan sekitar 2.400 MiB/detik tulisan 64-KiB murni berurutan. Selama pengujian, campuran 50/50 menunjukkan total throughput seterusnya dengan beban kerja baca berurutan murni.

Sehubungan dengan bacaan murni, garis besar 64-KiB berkinerja sedikit lebih baik daripada garis besar 256-KiB. Namun, dalam hal penulisan murni dan semua beban kerja baca/tulis campuran, namun, garis besar 256-KiB mengungguli 64 KiB, menunjukkan ukuran blok yang lebih besar 256 KiB lebih efektif secara keseluruhan untuk beban kerja throughput tinggi.

Campuran baca-tulis untuk beban kerja disesuaikan sebesar 25% untuk setiap eksekusi.

Hasil: I/O berurutan 256 KiB tanpa penembolokan

Dalam dua tolok ukur dasar berikut, FIO digunakan untuk mengukur jumlah I/O berurutan (baca dan tulis) satu volume reguler di Azure NetApp Files dapat dikirimkan. Untuk menghasilkan garis besar yang mencerminkan bandwidth sejati yang dapat dicapai oleh beban kerja baca yang sepenuhnya tidak di-cache, FIO dikonfigurasi untuk dijalankan dengan parameter randrepeat=0 untuk pembuatan himpunan data. Setiap perulangan pengujian diimbangi dengan membaca himpunan data besar yang sepenuhnya terpisah bukan bagian dari tolok ukur untuk menghapus penembolokan apa pun yang mungkin terjadi dengan himpunan data tolok ukur.

Dalam grafik ini, pengujian menunjukkan bahwa volume reguler Azure NetApp Files dapat menangani antara sekitar 3.500 MiB/dtk baca berurutan murni 256-KiB dan sekitar 2.500 MiB/dtk tulis 256-KiB berurutan murni. Selama pengujian, campuran 50/50 menunjukkan total throughput memuncak lebih tinggi dari beban kerja baca berurutan murni.

Koneksi jaringan paralel (nconnect)

Pengujian berikut menunjukkan tolok ukur I/OP tinggi menggunakan satu klien dengan beban kerja acak 64 KiB dan himpunan data 1-TiB. Campuran beban kerja yang dihasilkan menggunakan kedalaman I/O yang berbeda setiap kali. Untuk meningkatkan performa untuk beban kerja klien tunggal, nconnect opsi pemasangan dimanfaatkan untuk paralelisme yang lebih baik dibandingkan dengan pemasangan klien yang tidak menggunakan nconnect opsi pemasangan. Pengujian ini hanya dijalankan dengan penembolokan yang dikecualikan.

Hasil: I/O berurutan 64KiB, perbandingan cache throughput baca

Untuk menunjukkan bagaimana penembolokan memengaruhi hasil performa, FIO digunakan dalam perbandingan tolok ukur mikro berikut untuk mengukur jumlah I/O berurutan (baca dan tulis) yang dapat dikirimkan oleh satu volume reguler di Azure NetApp Files. Pengujian ini berbeda dengan manfaat yang mungkin diberikan oleh beban kerja yang dapat di-cache sebagian.

Dalam hasilnya tanpa penembolokan, pengujian dirancang untuk mengurangi penembolokan apa pun yang terjadi seperti yang dijelaskan dalam tolok ukur garis besar di atas. Dalam hasil lain, FIO digunakan terhadap volume reguler Azure NetApp Files tanpa randrepeat=0 parameter dan menggunakan logika iterasi pengujian perulangan yang secara perlahan mengisi cache dari waktu ke waktu. Kombinasi faktor-faktor ini menghasilkan jumlah penembolokan yang tidak ditentukan, meningkatkan throughput keseluruhan. Konfigurasi ini menghasilkan jumlah performa baca keseluruhan yang sedikit lebih baik daripada pengujian yang dijalankan tanpa penembolokan.

Hasil pengujian yang ditampilkan dalam grafik menampilkan perbandingan berdampingan dari performa baca dengan dan tanpa pengaruh penembolokan, di mana penembolokan menghasilkan hingga ~4500 MiB/detik throughput baca, sementara tidak ada penembolokan yang dicapai sekitar ~3600 MiB/detik.

Perbandingan berdampingan (dengan dan tanpa nconnect)

Grafik berikut menunjukkan perbandingan berdampingan dari bacaan dan tulis berurutan 64 KiB dengan dan tanpa nconnect menyoroti peningkatan performa yang terlihat saat menggunakan nconnect: throughput keseluruhan yang lebih tinggi, latensi yang lebih rendah.

Informasi selengkapnya

• Metodologi pengujian