Memecahkan masalah konfigurasi NAS dan target penyimpanan NFS

Artikel
10/26/2023

Artikel ini memberikan solusi untuk beberapa kesalahan konfigurasi umum dan masalah lain yang dapat mencegah Azure HPC Cache menambahkan sistem penyimpanan NFS sebagai target penyimpanan.

Artikel ini mencakup detail tentang cara memeriksa port dan cara mengaktifkan akses yang diperlukan ke sistem NAS. Ini juga mencakup informasi mendetail tentang masalah yang kurang umum yang mungkin menyebabkan pembuatan target penyimpanan NFS gagal.

Tip

Sebelum menggunakan panduan ini, baca prasyarat untuk target penyimpanan NFS.

Jika solusi untuk masalah Anda tidak disertakan di sini, harap buka tiket dukungan sehingga Layanan dan Dukungan Microsoft dapat bekerja sama dengan Anda untuk menyelidiki dan menyelesaikan masalah.

Menyediakan utas koneksi yang memadai

Sistem HPC Cache besar membuat beberapa permintaan koneksi ke target penyimpanan. Misalnya, jika target penyimpanan Anda menggunakan modul Linux nfs-kernel-server Ubuntu, jumlah default utas daemon NFS bisa serendah delapan. Tingkatkan jumlah utas menjadi 128 atau 256, yang merupakan angka yang lebih masuk akal untuk mendukung HPC Cache sedang atau besar.

Anda dapat memeriksa atau mengatur jumlah utas di Ubuntu dengan menggunakan nilai RPCNFSDCOUNT di /etc/init.d/nfs-kernel-server.

Memeriksa pengaturan port

Azure HPC Cache memerlukan akses baca/tulis ke beberapa port UDP/TCP pada sistem penyimpanan NAS back-end. Pastikan port ini dapat diakses di sistem NAS serta lalu lintas diizinkan ke port ini melalui firewall apa pun antara sistem penyimpanan dan subnet cache. Anda mungkin perlu bekerja dengan firewall dan administrator jaringan untuk pusat data Anda guna memverifikasi konfigurasi ini.

Port berbeda untuk sistem penyimpanan dari vendor yang berbeda, jadi periksa persyaratan sistem Anda saat menyiapkan target penyimpanan.

Secara umum, cache memerlukan akses ke port ini:

Protokol	Port	Layanan
TCP/UDP	111	rpcbind
TCP/UDP	2049	NFS
TCP/UDP	4045	nlockmgr
TCP/UDP	4046	mountd
TCP/UDP	4047	status

Untuk mempelajari port khusus yang diperlukan untuk sistem Anda, gunakan perintah rpcinfo berikut. Perintah di bawah ini mencantumkan port dan memformat hasil yang relevan dalam sebuah tabel. (Gunakan alamat IP sistem Anda sebagai pengganti <> istilah storage_IP.)

Anda dapat mengeluarkan perintah ini dari klien Linux mana pun yang telah memasang infrastruktur NFS. Jika Anda menggunakan klien di dalam subnet kluster, itu juga dapat membantu memverifikasi konektivitas antara subnet dan sistem penyimpanan.

rpcinfo -p <storage_IP> |egrep "100000\s+4\s+tcp|100005\s+3\s+tcp|100003\s+3\s+tcp|100024\s+1\s+tcp|100021\s+4\s+tcp"| awk '{print $4 "/" $3 " " $5}'|column -t

Pastikan semua port yang dikembalikan oleh kueri rpcinfo mengizinkan lalu lintas tidak terbatas dari subnet Azure HPC Cache.

Periksa pengaturan ini baik pada NAS itu sendiri dan juga pada semua firewall antara sistem penyimpanan dan subnet cache.

Periksa pengaturan root squash

Pengaturan root squash dapat mengganggu akses file jika tidak dikonfigurasi dengan benar. Anda harus memeriksa apakah pengaturan pada setiap ekspor penyimpanan dan pada kebijakan akses klien HPC Cache yang cocok sesuai.

Root squash mencegah permintaan yang dikirim oleh akar superuser lokal pada klien agar tidak dikirim ke sistem penyimpanan back-end sebagai root. Ini menetapkan ulang permintaan dari root ke ID pengguna (UID) non-istimewa seperti 'tidak ada'.

Tip

Versi Azure HPC Cache sebelumnya memerlukan sistem penyimpanan NAS untuk memungkinkan akses root dari HPC Cache. Sekarang, Anda tidak perlu mengizinkan akses root pada ekspor target penyimpanan kecuali Anda ingin klien HPC Cache memiliki akses root ke ekspor.

Root squash dapat dikonfigurasi dalam sistem HPC Cache di tempat-tempat berikut:

Di Azure HPC Cache - Gunakan kebijakan akses klien untuk mengonfigurasi root squash untuk klien yang cocok dengan aturan filter tertentu. Kebijakan akses klien adalah bagian dari setiap jalur namespace layanan target penyimpanan NFS.

Kebijakan akses klien default tidak melakukan squash root.
Pada ekspor penyimpanan - Anda dapat mengonfigurasi sistem penyimpanan untuk menetapkan ulang permintaan masuk dari root ke ID pengguna (UID) yang tidak istimewa.

Jika ekspor sistem penyimpanan Anda melakukan squash root, Anda harus memperbarui aturan akses klien HPC Cache untuk target penyimpanan tersebut untuk juga melakukan squash root. Jika tidak, Anda dapat memiliki masalah akses saat mencoba membaca atau menulis ke sistem penyimpanan back-end melalui HPC Cache.

Tabel ini menggambarkan perilaku untuk skenario root squash yang berbeda ketika permintaan klien dikirim sebagai UID 0 (root). Skenario yang ditandai dengan * tidak disarankan karena dapat menyebabkan masalah akses.

Pengaturan	UID yang dikirim dari HPC Cache	UID yang efektif pada penyimpanan back-end
tidak ada akar squash	0 (root)	0 (root)
root squash hanya di HPC Cache	65534 (tidak ada)	65534 (tidak ada)
*root squash hanya di penyimpanan NAS	0 (root)	65534 (tidak ada)
root squash di HPC Cache dan NAS	65534 (tidak ada)	65534 (tidak ada)

(UID 65534 adalah contoh; ketika Anda mengaktifkan root squash dalam kebijakan akses klien, Anda dapat menyesuaikan UID.)

Memeriksa akses pada jalur direktori

Untuk sistem NAS yang mengekspor direktori hierarkis, periksa apakah Azure HPC Cache memiliki akses yang sesuai ke setiap tingkat ekspor di jalur ke file yang Anda gunakan.

Misalnya, suatu sistem mungkin menampilkan tiga ekspor seperti ini:

/ifs
/ifs/accounting
/ifs/accounting/payroll

Ekspor /ifs/accounting/payroll adalah anak dari /ifs/accounting, dan /ifs/accounting itu sendiri adalah anak dari /ifs.

Jika Anda menambahkan payroll ekspor sebagai target penyimpanan HPC Cache, cache sebenarnya memasang /ifs/ dan mengakses direktori penggajian dari sana. Jadi Azure HPC Cache membutuhkan akses /ifs yang memadai untuk mengakses /ifs/accounting/payroll ekspor.

Persyaratan ini terkait dengan cara cache mengindeks file dan menghindari tabrakan file, menggunakan handel file yang disediakan oleh sistem penyimpanan.

Sistem NAS dengan ekspor hierarkis dapat memberikan handel file yang berbeda untuk file yang sama jika file tersebut diambil dari ekspor yang berbeda. Misalnya, klien dapat memasang /ifs/accounting dan mengakses file payroll/2011.txt. Klien lain memasang /ifs/accounting/payroll dan mengakses file 2011.txt. Bergantung pada bagaimana sistem penyimpanan menetapkan handel file, kedua klien ini mungkin menerima file yang sama dengan handel file yang berbeda (satu untuk <mount2>/payroll/2011.txt dan satu untuk <mount3>/2011.txt).

Sistem penyimpanan back-end menyimpan alias internal untuk handel file, tetapi Azure HPC Cache tidak dapat membedakan file mana yang menangani dalam indeks referensi item yang sama. Jadi ada kemungkinan bahwa cache dapat memiliki penulisan yang berbeda yang ditembolokan untuk file yang sama, dan salah menerapkan perubahan karena tidak mengetahui bahwa mereka adalah file yang sama.

Untuk menghindari kemungkinan tabrakan file ini untuk file dalam beberapa ekspor, Azure HPC Cache secara otomatis memasang ekspor paling dangkal yang tersedia di jalur (/ifs dalam contoh) dan menggunakan handel file yang diberikan dari ekspor itu. Jika beberapa ekspor menggunakan jalur dasar yang sama, Azure HPC Cache memerlukan akses ke jalur tersebut.

Menyesuaikan pembatasan ukuran paket VPN

Jika Anda memiliki VPN antara cache dan perangkat NAS Anda, VPN mungkin memblokir paket Ethernet 1500-byte berukuran penuh. Anda mungkin mengalami masalah ini jika pertukaran besar antara NAS dan instans Azure HPC Cache tidak selesai, tetapi pembaruan yang lebih kecil berfungsi seperti yang diharapkan.

Tidak ada cara sederhana untuk mengetahui apakah sistem Anda memiliki masalah ini atau tidak, kecuali Anda mengetahui detail konfigurasi VPN Anda. Berikut adalah beberapa metode yang dapat membantu Anda memeriksa masalah ini.

Gunakan pelacak paket di kedua sisi VPN untuk mendeteksi paket mana yang berhasil ditransfer.
Jika VPN Anda mengizinkan perintah ping, Anda dapat menguji pengiriman paket berukuran penuh.

Jalankan perintah ping melalui VPN ke NAS dengan opsi ini. (Gunakan alamat IP sistem penyimpanan Anda sebagai pengganti <> nilai storage_IP.)
```
ping -M do -s 1472 -c 1 <storage_IP>
```
Ini adalah opsi dalam perintah:
- -M do - Jangan melakukan fragmen
- -c 1 - Kirim hanya satu paket
- -s 1472 - Atur ukuran payload menjadi 1472 byte. Ini adalah payload ukuran maksimum untuk paket 1500-byte setelah memperhitungkan overhead Ethernet.
Respons yang berhasil akan terlihat seperti:
```
PING 10.54.54.11 (10.54.54.11) 1472(1500) bytes of data.
1480 bytes from 10.54.54.11: icmp_seq=1 ttl=64 time=2.06 ms
```
Jika ping gagal dengan 1472 byte, mungkin ada masalah ukuran paket.

Untuk memperbaiki masalah, Anda mungkin perlu mengonfigurasi penjepitan MSS pada VPN agar sistem jarak jauh mendeteksi ukuran bingkai maksimum dengan benar. Baca dokumentasi parameter VPN Gateway IPsec/IKE untuk mempelajari lebih lanjut.

Dalam beberapa kasus, mengubah pengaturan MTU untuk Azure HPC Cache ke 1400 dapat membantu. Namun, jika Anda membatasi MTU pada cache, Anda juga harus membatasi pengaturan MTU untuk klien dan sistem penyimpanan back-end yang berinteraksi dengan cache. Baca Mengonfigurasi pengaturan Azure HPC Cache tambahan untuk detailnya.

Memeriksa gaya keamanan ACL

Beberapa sistem NAS menggunakan gaya keamanan hibrida yang menggabungkan daftar kontrol akses (ACL) dengan keamanan POSIX atau UNIX tradisional.

Jika sistem Anda melaporkan gaya keamanannya sebagai UNIX atau POSIX tanpa menyertakan akronim "ACL", masalah ini tidak memengaruhi Anda.

Untuk sistem yang menggunakan ACL, Azure HPC Cache perlu melacak nilai khusus pengguna tambahan untuk mengontrol akses file. Ini dilakukan dengan mengaktifkan cache akses. Tidak ada kontrol yang menghadap pengguna untuk mengaktifkan cache akses, tetapi Anda dapat membuka tiket dukungan untuk meminta agar diaktifkan untuk target penyimpanan yang terpengaruh pada sistem cache Anda.

Langkah berikutnya

Jika Anda mengalami masalah yang tidak dibahas dalam artikel ini, hubungi dukungan untuk mendapatkan bantuan pakar.

Share via