Meningkatkan performa untuk berbagi file NFS Azure

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

Berlaku pada

Model manajemen	Model tagihan	Peringkat media	Pemborosan	Usaha Kecil dan Menengah (UKM)	Network File System (NFS)
Microsoft.Storage	Versi 2 yang telah disediakan	HDD (standar)	Lokal (LRS)
Microsoft.Storage	Versi 2 yang telah disediakan	HDD (standar)	Zona (ZRS)
Microsoft.Storage	Versi 2 yang telah disediakan	HDD (standar)	Geo (GRS)
Microsoft.Storage	Versi 2 yang telah disediakan	HDD (standar)	GeoZone (GZRS)
Microsoft.Storage	Versi 1 yang telah disediakan	SSD (kelas atas)	Lokal (LRS)
Microsoft.Storage	Versi 1 yang telah disediakan	SSD (kelas atas)	Zona (ZRS)
Microsoft.Storage	Bayar per penggunaan	HDD (standar)	Lokal (LRS)
Microsoft.Storage	Bayar per penggunaan	HDD (standar)	Zona (ZRS)
Microsoft.Storage	Bayar per penggunaan	HDD (standar)	Geo (GRS)
Microsoft.Storage	Bayar per penggunaan	HDD (standar)	GeoZone (GZRS)

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
   

NFS nconnect

NFS nconnect adalah opsi pemasangan sisi klien untuk berbagi file NFS yang memungkinkan Anda menggunakan beberapa koneksi TCP antara klien dan berbagi file NFS Anda.

Keuntungan

Dengan nconnect, Anda dapat meningkatkan performa dalam skala besar menggunakan lebih sedikit komputer klien untuk mengurangi total biaya kepemilikan (TCO). Fitur 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 / detik) yang ditawarkan oleh ukuran provisi berbagi file SSD 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 ini.

Metrik (operasi)	Ukuran I/O	Peningkatan performa
IOPS (tulis)	64 KiB, 1.024 KiB	3x
IOPS (baca)	Semua ukuran I/O	2-4x
Throughput (tulis)	64 KiB, 1.024 KiB	3x
Throughput (baca)	Semua ukuran I/O	2-4x

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

Kami mencapai hasil performa berikut saat menggunakan opsi pemasangan nconnect 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

Ikuti rekomendasi ini untuk mendapatkan hasil terbaik dari nconnect.

Atur nconnect=4

Meskipun Azure Files mendukung pengaturan nconnect hingga pengaturan maksimum 16, sebaiknya konfigurasikan opsi pemasangan dengan pengaturan optimal nconnect=4. Saat ini, tidak ada keuntungan di luar empat saluran untuk implementasi Azure Files 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.

Konfigurasi per pemasangan

Jika beban kerja memerlukan pemasangan beberapa berbagi dengan satu atau beberapa akun penyimpanan dengan pengaturan nconnect yang berbeda dari satu klien, kami tidak dapat menjamin bahwa pengaturan tersebut 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: per konfigurasi 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: per konfigurasi 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

Nota

Bahkan jika akun penyimpanan diselesaikan ke alamat IP yang berbeda, kami tidak dapat menjamin bahwa alamat tetap ada karena titik akhir publik bukan alamat statis.

Skenario 3: per konfigurasi 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
• SISTEM OPERASI: Linux (Ubuntu 20.40)
• Penyimpanan NFS: Berbagi file SSD (disediakan 30 TiB, set nconnect=4)

Ukuran	vCPU	Memori	Penyimpanan sementara (SSD)	Disk data maksimum	Maksimum NICs	Bandwidth jaringan yang diharapkan
Standard_D16_v4	16	64 GiB	Hanya penyimpanan jarak jauh	32	8	12.500 Mbps

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: Bacaan 100%

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: 100 pembacaan%

Ukuran I/O 64 KiB - 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 1.024 KiB - 100% baca acak - 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: Penulisan 100%

Ukuran I/O 4 KiB - 100% tulis acak - 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 8 KiB - 100% tulis acak - 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 penulisan%

Ukuran I/O 64 KiB - 100% tulis acak - kedalaman antrean 64

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 1024 KiB - 100% tulis acak - 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