Meningkatkan performa untuk berbagi file NFS Azure

Artikel ini menjelaskan bagaimana Anda dapat meningkatkan performa untuk berbagi file Azure sistem file jaringan (NFS).

Berlaku untuk

Jenis berbagi File	SMB	NFS
Berbagi file standar (GPv2), LRS/ZRS
Berbagi file standar (GPv2), GRS/GZRS
Berbagi file premium (FileStorage), LRS/ZRS

Meningkatkan ukuran read-ahead untuk meningkatkan throughput baca

Parameter read_ahead_kb kernel di Linux mewakili jumlah data yang harus "dibaca di depan" atau diambil sebelumnya selama operasi baca berurutan. Versi kernel Linux sebelum 5.4 mengatur nilai read-ahead ke setara dengan 15 kali sistem rsizefile yang dipasang , yang mewakili opsi pemasangan sisi klien untuk ukuran buffer baca. Ini menetapkan nilai read-ahead yang cukup tinggi untuk meningkatkan throughput baca berurutan klien dalam banyak kasus.

Namun, dimulai dengan kernel Linux versi 5.4, klien Linux NFS menggunakan nilai default read_ahead_kb 128 KiB. Nilai kecil ini dapat mengurangi jumlah throughput baca untuk file besar. Pelanggan yang meningkatkan dari rilis Linux dengan nilai read-ahead yang lebih besar ke rilis dengan default 128 KiB mungkin mengalami penurunan performa baca berurutan.

Untuk kernel Linux 5.4 atau yang lebih baru, sebaiknya tetap mengatur read_ahead_kb ke 15 MiB untuk meningkatkan performa.

Untuk mengubah nilai ini, atur ukuran read-ahead dengan menambahkan aturan di udev, manajer perangkat kernel Linux. Ikuti langkah-langkah ini:

1. Di editor teks, buat file /etc/udev/rules.d/99-nfs.rules dengan memasukkan dan menyimpan teks berikut:

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. Di konsol, terapkan aturan udev dengan menjalankan perintah udevadm sebagai superuser dan memuat ulang file aturan dan database lainnya. Anda hanya perlu menjalankan perintah ini sekali, untuk membuat udev mengetahui file baru.

   sudo udevadm control --reload
   

Nconnect

Nconnect adalah opsi pemasangan Linux sisi klien yang meningkatkan performa dalam skala besar dengan memungkinkan Anda menggunakan lebih banyak koneksi Protokol Kontrol Transmisi (TCP) antara klien dan layanan Azure Premium Files untuk NFSv4.1.

Manfaat nconnect

Dengan nconnect, Anda dapat meningkatkan performa dalam skala besar menggunakan lebih sedikit komputer klien untuk mengurangi total biaya kepemilikan (TCO). Nconnect meningkatkan performa dengan menggunakan beberapa saluran TCP pada satu atau beberapa NIC, menggunakan satu atau beberapa klien. Tanpa nconnect, Anda memerlukan sekitar 20 komputer klien untuk mencapai batas skala bandwidth (10 GiB/dtk) yang ditawarkan oleh ukuran provisi berbagi file Azure premium terbesar. Dengan nconnect, Anda dapat mencapai batas tersebut hanya menggunakan 6-7 klien, mengurangi biaya komputasi hampir 70% sambil memberikan peningkatan signifikan dalam operasi I/O per detik (IOPS) dan throughput dalam skala besar. Lihat tabel berikut.

Prasyarat

• Distribusi Linux terbaru sepenuhnya mendukung nconnect. Untuk distribusi Linux yang lebih lama, pastikan bahwa versi kernel Linux adalah 5.3 atau lebih tinggi.
• Konfigurasi per pemasangan hanya didukung saat satu berbagi file digunakan per akun penyimpanan melalui titik akhir privat.

Dampak performa nconnect

Kami mencapai hasil performa berikut saat menggunakan nconnect opsi pemasangan dengan berbagi file NFS Azure pada klien Linux dalam skala besar. Untuk informasi selengkapnya tentang cara kami mencapai hasil ini, lihat konfigurasi pengujian performa.

Rekomendasi untuk nconnect

Ikuti rekomendasi ini untuk mendapatkan hasil terbaik dari nconnect.

Mengeset nconnect=4

Meskipun Azure Files mendukung pengaturan nconnect hingga pengaturan maksimum 16, sebaiknya konfigurasikan opsi pemasangan dengan pengaturan nconnect=4optimal . Saat ini, tidak ada keuntungan di luar empat saluran untuk implementasi Azure Files dari nconnect. Bahkan, melebihi empat saluran ke satu berbagi file Azure dari satu klien mungkin berdampak buruk pada performa karena saturasi jaringan TCP.

Mengukur komputer virtual dengan hati-hati

Bergantung pada persyaratan beban kerja Anda, penting untuk mengukur komputer virtual (VM) klien dengan benar untuk menghindari dibatasi oleh bandwidth jaringan yang diharapkan. Anda tidak memerlukan beberapa pengontrol antarmuka jaringan (NIC) untuk mencapai throughput jaringan yang diharapkan. Meskipun umum untuk menggunakan VM tujuan umum dengan Azure Files, berbagai jenis VM tersedia tergantung pada kebutuhan beban kerja dan ketersediaan wilayah Anda. Untuk informasi selengkapnya, lihat Pemilih Azure VM.

Jaga kedalaman antrean kurang dari atau sama dengan 64

Kedalaman antrean adalah jumlah permintaan I/O yang tertunda yang dapat dilayvisikan oleh sumber daya penyimpanan. Kami tidak menyarankan untuk melebihi kedalaman antrean optimal 64 karena Anda tidak akan melihat peningkatan performa lagi. Untuk informasi selengkapnya, lihat Kedalaman antrean.

Nconnect konfigurasi per pemasangan

Jika beban kerja memerlukan pemasangan beberapa berbagi dengan satu atau beberapa akun penyimpanan dengan pengaturan yang berbeda nconnect dari satu klien, kami tidak dapat menjamin bahwa pengaturan tersebut akan bertahan saat memasang di titik akhir publik. Konfigurasi per pemasangan hanya didukung saat satu berbagi file Azure digunakan per akun penyimpanan melalui titik akhir privat seperti yang dijelaskan dalam Skenario 1.

Skenario 1: nconnect konfigurasi per pemasangan melalui titik akhir privat dengan beberapa akun penyimpanan (didukung)

• StorageAccount.file.core.windows.net = 10.10.10.10
• StorageAccount2.file.core.windows.net = 10.10.10.11
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Skenario 2: nconnect konfigurasi per pemasangan melalui titik akhir publik (tidak didukung)

• StorageAccount.file.core.windows.net = 52.239.238.8
• StorageAccount2.file.core.windows.net = 52.239.238.7
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Skenario 3: nconnect konfigurasi per pemasangan melalui titik akhir privat dengan beberapa berbagi pada akun penyimpanan tunggal (tidak didukung)

• StorageAccount.file.core.windows.net = 10.10.10.10
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

Konfigurasi pengujian performa

Kami menggunakan sumber daya dan alat tolok ukur berikut untuk mencapai dan mengukur hasil yang diuraikan dalam artikel ini.

• Klien tunggal: Azure VM (Seri DSv4) dengan NIC tunggal
• OS: Linux (Ubuntu 20.40)
• Penyimpanan NFS: Berbagi file premium Azure Files (disediakan 30 TiB, set nconnect=4)

Alat dan pengujian tolok ukur

Kami menggunakan Flexible I/O Tester (FIO), alat I/O disk sumber terbuka gratis yang digunakan baik untuk verifikasi tolok ukur maupun stres/perangkat keras. Untuk menginstal FIO, ikuti bagian Paket Biner di file FIO README untuk menginstal platform pilihan Anda.

Meskipun pengujian ini berfokus pada pola akses I/O acak, Anda mendapatkan hasil yang sama saat menggunakan I/O berurutan.

IOPS tinggi: 100% bacaan

Ukuran I/O 4k - baca acak - Kedalaman antrean 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Ukuran I/O 8k - baca acak - Kedalaman antrean 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Throughput tinggi: Bacaan 100%

Ukuran I/O 64k - baca acak - Kedalaman antrean 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Ukuran I/O 1024k - Baca acak 100% - kedalaman antrean 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

IOPS tinggi: 100% menulis

Ukuran I/O 4k - Tulis acak 100% - kedalaman antrean 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Ukuran I/O 8k - Penulisan acak 100% - kedalaman antrean 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Throughput tinggi: 100% menulis

Ukuran I/O 64k - Penulisan acak 100% - kedalaman antrean 64k

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Ukuran I/O 1024k - Tulis acak 100% - kedalaman antrean 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Pertimbangan performa untuk nconnect

Saat menggunakan nconnect opsi pemasangan, Anda harus mengevaluasi beban kerja yang memiliki karakteristik berikut:

• Beban kerja tulis sensitif latensi yang berutas tunggal dan/atau menggunakan kedalaman antrean rendah (kurang dari 16)
• Beban kerja baca sensitif latensi yang berutas tunggal dan/atau menggunakan kedalaman antrean rendah dalam kombinasi dengan ukuran I/O yang lebih kecil

Tidak semua beban kerja memerlukan IOPS skala tinggi atau seluruh performa. Untuk beban kerja skala yang lebih kecil, nconnect mungkin tidak masuk akal. Gunakan tabel berikut untuk memutuskan apakah nconnect menguntungkan untuk beban kerja Anda. Skenario yang disorot berwarna hijau disarankan, sementara skenario yang disorot dengan warna merah tidak. Skenario yang disorot dengan warna kuning netral.

Lihat juga

• Pasang berbagi file NFS ke Linux
• Daftar opsi pemasangan
• Memahami performa Azure Files