Container Service for Kubernetes：Praktik terbaik untuk optimalisasi kinerja volume persisten OSS

Pemilihan klien

Dibandingkan dengan ossfs 1.0, volume persisten ossfs 2.0 dan strmvol menawarkan peningkatan kinerja signifikan untuk operasi baca/tulis berurutan dan pembacaan konkuren tinggi file kecil. Jika aplikasi Anda tidak melakukan penulisan acak, kami merekomendasikan penggunaan ossfs 2.0.

Jika Anda tidak yakin apakah aplikasi Anda melakukan penulisan acak, coba pasang volume persisten ossfs 2.0 di lingkungan pengujian. Jika aplikasi melakukan operasi penulisan acak, kesalahan EINVAL akan dikembalikan.

Untuk memaksimalkan kinerja saat menggunakan klien ossfs 2.0, operasi chmod dan chown tidak melaporkan kesalahan tetapi tidak berpengaruh. Untuk mengatur izin file atau folder di bawah titik pemasangan, tambahkan parameter pemasangan ke bidang otherOpts volume persisten (PV). Untuk chmod, gunakan -o file_mode=<permission_code> atau -o dir_mode=<permission_code>. Untuk chown, gunakan -o gid= atau -o uid=.

Untuk rekomendasi pemilihan detail, lihat Referensi pemilihan klien.

Ekspektasi kinerja

Sebagai sistem file jaringan, kinerja volume persisten OSS dipengaruhi oleh lapisan jaringan dan protokol. Masalah kinerja biasanya menunjukkan penyimpangan signifikan dari hasil benchmark yang disediakan, bukan perbedaan kinerja dibandingkan dengan sistem file lokal. Kinerja dasar untuk klien yang berbeda adalah sebagai berikut.

• Kinerja dasar baca/tulis volume persisten ossfs 1.0

• Kinerja dasar baca/tulis volume persisten ossfs 2.0

• Kinerja dasar baca/tulis volume persisten strmvol

Titik akhir Internet dikonfigurasi pada PV

Ketika kluster dan bucket OSS Anda berada di wilayah yang sama, gunakan titik akhir internal untuk mengurangi latensi jaringan secara signifikan.

• Metode pemecahan masalah: Jalankan perintah berikut untuk memeriksa titik akhir OSS yang dikonfigurasi untuk PV.

  kubectl get pv <pv-name> -o jsonpath='{.spec.csi.volumeAttributes.url}'

• Solusi: Jika keluarannya adalah titik akhir Internet, seperti http://oss-<region-id>.aliyuncs.com, buat ulang PV dan gunakan titik akhir internal, seperti http://oss-<region-id>-internal.aliyuncs.com.

Throttling pada server OSS

OSS memiliki batasan pada bandwidth total dan permintaan per detik (QPS) untuk satu bucket. Untuk layanan di beberapa wilayah dan skenario yang melibatkan akses konkuren tinggi ke OSS, seperti alur kerja, throttling bandwidth dan QPS dapat terjadi.

• Metode pemecahan masalah: Di Konsol OSS, Anda dapat melihat metrik pemantauan untuk bucket OSS untuk memeriksa apakah metrik seperti penggunaan bandwidth dan jumlah permintaan mendekati atau melebihi batas.

• Solusi:

  • Ubah wilayah: Batasan bandwidth dan QPS untuk satu bucket OSS bervariasi berdasarkan wilayah. Jika aplikasi Anda masih dalam tahap pengujian, pertimbangkan untuk memindahkannya ke wilayah lain.

  • Hambatan bandwidth:

    • Jika data tidak perlu dibaca berulang kali: Anda dapat menyambungkan disk secara dinamis ke pod untuk penyimpanan sementara. Untuk data sementara, gunakan disk elastis sementara (EED). Untuk informasi selengkapnya, lihat Gunakan volume penyimpanan dinamis. Untuk metrik kinerja tipe disk yang berbeda, lihat Kinerja Elastic Block Storage.

    • Jika data dibaca berulang kali di antara replika atau batch aplikasi: Gunakan cache terdistribusi, seperti Fluid dengan JindoFS, untuk mempramuat data dari OSS ke sistem caching kluster. Hal ini menghindari permintaan data berulang ke OSS. Untuk informasi selengkapnya, lihat Mempercepat akses ke file OSS menggunakan JindoFS.

  • Bottleneck QPS (atau IOPS): Untuk sebagian besar aplikasi, konkurensi tinggi menyebabkan batas bandwidth tercapai sebelum batas QPS. Jika hanya bottleneck QPS yang dipicu, penyebabnya mungkin pengambilan metadata yang sering, seperti ls dan stat, atau pembukaan dan penutupan file yang sering. Dalam kasus ini, periksa konfigurasi klien dan metode baca/tulis aplikasi. Untuk informasi optimalisasi, lihat Optimalkan logika baca/tulis aplikasi dan parameter klien.

Bandwidth internal node aplikasi mencapai bottleneck

Klien dan pod aplikasi berjalan di node yang sama dan berbagi sumber daya jaringannya. Dalam skenario komputasi tanpa server, mereka berbagi sumber daya instance ACS tunggal. Oleh karena itu, batas bandwidth jaringan node membatasi kinerja maksimum volume persisten OSS.

• Metode pemecahan masalah: Anda dapat melihat informasi pemantauan node atau informasi pemantauan instance ECS untuk memeriksa adanya bottleneck bandwidth.

• Solusi:

  • Prioritaskan penjadwalan pod aplikasi ke node yang memiliki bandwidth jaringan tersedia lebih tinggi.

  • Anda dapat melakukan peningkatan dan penurunan konfigurasi node untuk mendapatkan bandwidth lebih banyak.

  • Jika solusi ini tidak memungkinkan dan tugas bersifat intensif I/O, pertimbangkan beralih ke volume persisten berbasis disk.

Caching data volume persisten ossfs 1.0 dibatasi oleh throughput disk maksimum

Untuk mendukung operasi penulisan POSIX penuh dan memastikan konsistensi data untuk satu klien, klien ossfs 1.0 secara default menyimpan cache sebagian data ke disk saat mengakses file. Operasi caching ini terjadi di direktori /tmp pod ossfs. Ruang ini sesuai dengan disk di node yang digunakan untuk data runtime kontainer. Oleh karena itu, kinerja ossfs 1.0 secara langsung dibatasi oleh operasi input/output per detik (IOPS) dan batas throughput disk ini.

• Metode pemecahan masalah:

  Metode berikut tidak berlaku untuk node ContainerOS.

  1. Jalankan perintah berikut untuk menemukan ID disk data runtime kontainer di node tempat pod aplikasi berjalan.

     kubectl get node <node-name> -o yaml | grep alibabacloud.com/data-disk-serial-id

     Berdasarkan data-disk-serial-id dalam keluaran, ruang sementara berada di instance disk d-uf69tilfftjoa3qb****.

     alibabacloud.com/data-disk-serial-id: uf69tilfftjoa3qb****

     Jika ID dalam keluaran kosong, buka Konsol ECS - Elastic Block Storage - Disk. Temukan disk berdasarkan instance yang terpasang dan periksa informasi pemantauannya.

  2. Berdasarkan ID instance, Anda dapat melihat informasi pemantauan disk untuk menentukan apakah disk mengalami bottleneck IOPS atau throughput.

• Solusi:

  • Untuk skenario read-only atau penulisan berurutan: Klien ossfs 1.0 tidak dapat memprediksi apakah file yang dibuka akan ditulis secara acak. Oleh karena itu, bahkan operasi read-only pun dapat memicu caching data ke disk. Kami merekomendasikan beralih ke klien yang lebih sesuai, seperti ossfs 2.0, atau menerapkan Pemisahan baca/tulis untuk aplikasi tersebut.

  • Untuk skenario penulisan acak: Kinerja penulisan acak melalui klien Filesystem in Userspace (FUSE), seperti ossfs 1.0, biasanya buruk. Kami merekomendasikan memodifikasi aplikasi untuk mengakses OSS secara langsung melalui SDK OSS, atau beralih ke volume persisten NAS, yang lebih cocok untuk skenario ini.

Penggunaan tinggi disk yang menyimpan data sementara untuk volume persisten ossfs 1.0

Jika pemantauan disk menunjukkan bahwa penggunaan disk untuk caching data ossfs 1.0 secara konsisten tinggi, terutama dalam skenario komputasi tanpa server, eviksi dan rotasi data sementara yang sering dapat semakin menurunkan kinerja akses.

• Metode pemecahan masalah:

  1. Ikuti solusi dalam Caching data volume persisten ossfs 1.0 dibatasi oleh throughput disk maksimum untuk mengidentifikasi disk yang digunakan untuk data runtime kontainer.

  2. Anda dapat memeriksa penggunaan sumber daya disk melalui pemantauan disk. Jika penggunaan tetap stabil pada level tinggi, tetapi aplikasi itu sendiri hanya menulis sedikit data ke disk, masalah kinerja mungkin disebabkan oleh rotasi data sementara oleh klien ossfs 1.0.

• Solusi:

  1. Periksa logika aplikasi: Pastikan apakah kode aplikasi mempertahankan deskriptor file dalam waktu lama (yaitu, menjaga file tetap terbuka dalam periode panjang). Selama deskriptor file dipertahankan, data sementara terkait tidak dapat dilepaskan. Hal ini dapat menghabiskan banyak ruang disk lokal.

  2. Tingkatkan kapasitas disk lokal: Jika logika aplikasi benar dan throughput maksimum disk saat ini memenuhi persyaratan, pertimbangkan untuk menambah kapasitas disk.

TTL autentikasi singkat menyebabkan banyak permintaan RAM

Saat Anda menggunakan peran Resource Access Management (RAM) untuk autentikasi, klien ossfs (versi 1.0 dan 2.0) memperoleh token dan mencatat waktu kedaluwarsanya pada akses pertama ke OSS. Untuk memastikan kontinuitas sesi, klien memperoleh token baru dan memperbarui waktu kedaluwarsa 20 menit sebelum token saat ini kedaluwarsa.

Oleh karena itu, durasi sesi maksimum (max_session_duration) untuk peran RAM harus lebih dari 20 menit.

Sebagai contoh, jika durasi sesi adalah 30 menit, klien memperbarui token setelah 10 menit penggunaan (30 - 20 = 10), yang tidak memengaruhi throughput normal. Jika durasi sesi kurang dari 20 menit, klien menganggap token selalu hampir kedaluwarsa dan mencoba memperoleh token baru sebelum setiap permintaan ke OSS. Hal ini memicu banyak permintaan RAM dan memengaruhi kinerja.

• Metode pemecahan masalah: Tingkat log klien default mungkin tidak mencatat perilaku pembaruan token yang sering. Pastikan peran RAM yang digunakan oleh aplikasi dikonfigurasi dengan benar.

• Solusi: Lihat Atur durasi sesi maksimum untuk peran RAM untuk memeriksa dan memodifikasi durasi sesi maksimum peran RAM. Pastikan konfigurasinya benar.

Optimalkan caching metadata (dan hindari menonaktifkannya)

Caching metadata adalah mekanisme inti untuk meningkatkan kinerja operasi frekuensi tinggi, seperti ls dan stat. Caching ini secara signifikan mengurangi permintaan jaringan yang memakan waktu. Jika Anda menonaktifkan atau salah mengonfigurasinya, klien mungkin sering meminta data dari OSS untuk memastikan konsistensi data, yang menciptakan bottleneck kinerja.

• Metode pemecahan masalah:
  Jalankan perintah berikut untuk memeriksa apakah parameter klien yang dikonfigurasi untuk PV mencakup opsi untuk menonaktifkan cache.
  

  kubectl get pv <pv-name> -o jsonpath='{.spec.csi.volumeAttributes.otherOpts}'

• Solusi:

  • Hindari menonaktifkan cache: Jika keluaran perintah mencakup max_stat_cache_size=0 (untuk ossfs 1.0) atau close_to_open=true (untuk ossfs 2.0), dan skenario Anda tidak memerlukan konsistensi kuat, buat ulang volume persisten dan hapus parameter ini.

  • Optimalkan konfigurasi cache: Jika data yang dibaca aplikasi Anda jarang diperbarui, tingkatkan ukuran dan waktu kedaluwarsa cache metadata untuk lebih meningkatkan kinerja.

    • Volume persisten ossfs 1.0: Lihat Cache metadata.

    • Volume persisten ossfs 2.0: Lihat Kurangi permintaan OSS dan tingkatkan kinerja titik pemasangan.

    • Volume persisten strmvol: Secara default, semua metadata di bawah titik pemasangan di-cache dan tidak kedaluwarsa. Biasanya tidak diperlukan konfigurasi tambahan.

Hindari mempertahankan informasi objek tambahan (hanya untuk ossfs 1.0)

Metadata sistem file, seperti mode, gid, dan uid, dianggap sebagai informasi tambahan untuk objek di OSS. Klien ossfs 1.0 perlu melakukan permintaan HTTP tambahan untuk mengambil informasi ini. Meskipun klien secara default menyimpan cache metadata ini (termasuk properti dasar dan tambahan) untuk meningkatkan kinerja akses data, pengambilan metadata yang sering—terutama untuk properti tambahan—tetap menjadi bottleneck kinerja.

Oleh karena itu, optimalisasi kinerja untuk skenario ini berfokus pada dua poin:

1. Minimalkan jumlah operasi pengambilan metadata. Untuk informasi selengkapnya, lihat Optimalkan caching metadata (dan hindari menonaktifkannya).

2. Hindari meminta properti tambahan yang memiliki overhead tinggi untuk mengurangi biaya waktu setiap pengambilan.

Solusi:

• Aplikasi tidak bergantung pada metadata sistem file: Kami merekomendasikan mengatur parameter readdir_optimize untuk menonaktifkan pemeliharaan informasi tambahan. Perilaku operasi chmod, chown, stat, dan lainnya kemudian akan sama seperti di ossfs 2.0.

• Aplikasi hanya memerlukan konfigurasi izin global: Untuk skenario di mana kontainer non-root memerlukan izin, kami merekomendasikan mengatur parameter readdir_optimize. Pada saat yang sama, Anda dapat menggunakan parameter gid, uid, dan file_mode/dir_mode untuk memodifikasi secara global pengguna atau izin default sistem file.

• Aplikasi memerlukan kebijakan akses detail halus: Kami merekomendasikan tidak menggunakan izin sistem file untuk kontrol akses. Sebagai gantinya, gunakan sistem autentikasi sisi server OSS untuk menerapkan isolasi jalur. Misalnya, buat pengguna atau peran RAM berbeda untuk aplikasi berbeda dan gunakan kebijakan bucket atau kebijakan RAM untuk membatasi subjalur yang dapat mereka akses. Anda tetap harus mengatur parameter readdir_optimize untuk mengoptimalkan kinerja.

Optimalkan mode penulisan file

Operasi penulisan default untuk objek OSS adalah overwrite. Saat klien menangani modifikasi file, klien harus mengikuti pola baca-kemudian-tulis: membaca objek lengkap dari OSS ke mesin lokal, lalu mengunggah kembali seluruh file ke server setelah file ditutup. Oleh karena itu, dalam kasus ekstrem pembukaan, penulisan, dan penutupan file yang sering, aplikasi berulang kali mengunduh dan mengunggah data lengkap.

Solusi:

• Gunakan penulisan batch daripada beberapa penulisan: Hindari penulisan berulang yang tidak perlu sebisa mungkin. Siapkan konten di memori dan panggil satu operasi penulisan untuk menyelesaikannya. Perhatikan bahwa beberapa fungsi penulisan terenkapsulasi, seperti FileUtils.write Java, sudah mencakup alur lengkap open, write, dan close. Jika Anda memanggil fungsi semacam ini berulang kali dalam loop, masalah kinerja akan terjadi.

• Gunakan file sementara untuk modifikasi sering: Jika file perlu dibuka dan dimodifikasi beberapa kali selama tugas pemrosesan data, salin terlebih dahulu dari titik pemasangan OSS ke jalur sementara di kontainer, seperti /tmp. Lakukan semua modifikasi pada file sementara lokal, lalu salin versi akhir ke titik pemasangan OSS dalam satu operasi untuk mengunggahnya.

• Aktifkan fitur appendable untuk skenario penulisan append: Jika skenario aplikasi Anda hanya melibatkan penulisan append kecil yang sering, seperti menulis log, pertimbangkan menggunakan ossfs 2.0 dan mengaktifkan parameter enable_appendable_object=true. Setelah parameter ini diaktifkan, klien menggunakan Objek Appendable OSS. Saat menambahkan data, klien tidak perlu mengunduh dan mengunggah ulang seluruh file setiap kali. Namun, perhatikan hal berikut:

  • Jika file objek sudah ada tetapi bukan objek Appendable, Anda tidak dapat menggunakan solusi ini untuk menambahkan data ke dalamnya.

  • enable_appendable_object adalah parameter global untuk seluruh volume persisten. Setelah diaktifkan, semua operasi penulisan pada volume ini dilakukan melalui API AppendObject. Hal ini memengaruhi kinerja overwrite file besar tetapi tidak memengaruhi pembacaannya. Kami merekomendasikan membuat volume persisten khusus untuk jenis aplikasi penulisan-append ini.

Optimalkan mode pembacaan konkuren (terutama untuk skenario pemuatan model)

Saat beberapa proses membaca data secara konkuren dari lokasi berbeda dalam satu file besar, pola aksesnya mirip dengan pembacaan acak. Hal ini dapat menyebabkan klien membaca data secara berlebihan, yang mengakibatkan penggunaan bandwidth sangat tinggi. Misalnya, dalam skenario pemuatan model AI, framework model utama sering memiliki beberapa proses konkuren yang membaca file parameter model yang sama. Hal ini dapat memicu bottleneck kinerja.

Jika Anda menemukan bahwa kinerja ossfs 2.0 dalam skenario semacam ini lebih buruk daripada ossfs 1.0, atau kinerjanya berbeda secara signifikan dari kinerja uji stres klien ossfs 2.0, Anda dapat memastikan bahwa inilah masalahnya.

Solusi:

• Pra-ambil data (direkomendasikan): Sebelum pod aplikasi dimulai, gunakan skrip untuk mempramuat data. Prinsip intinya adalah menggunakan pembacaan berurutan konkuren berbandwidth tinggi untuk memuat seluruh file model ke memori node (Page Cache) terlebih dahulu. Setelah pra-ambil selesai, pembacaan acak aplikasi langsung mengenai memori, yang melewati bottleneck kinerja.

  Anda dapat menggunakan skrip pra-ambil mandiri berikut, yang membaca konten file secara konkuren ke /dev/null:

  #!/bin/bash
  # Tetapkan konkurensi maksimum.
  MAX_JOBS=4
  
  # Periksa apakah folder disediakan sebagai argumen.
  if [ -z "$1" ]; then
      echo "Penggunaan: $0 <folder_path>"
      exit 1
  fi
  
  DIR="$1"
  
  # Periksa apakah folder tersebut ada.
  if [ ! -d "$DIR" ]; then
      echo "Kesalahan: '$DIR' bukan folder yang valid."
      exit 1
  fi
  
  # Gunakan find untuk menemukan semua file reguler dan gunakan xargs untuk menjalankan cat ke /dev/null secara konkuren.
  find "$DIR" -type f -print0 | xargs -0 -I {} -P "$MAX_JOBS" sh -c 'cat "{}" > /dev/null'
  
  echo "Selesai membaca semua file."

  Anda dapat menyederhanakan logika inti skrip ini dan menjalankannya di hook lifecycle.postStart pod.

  # ...
  spec:
    containers:
    - image: your-image
      env:
      # Tentukan jalur folder tempat file model berada. Jika tidak dikonfigurasi atau folder tidak ada, skrip melewati pra-ambil data.
      - name: MODEL_DIR
        value: /where/is/your/model/
      # Tentukan konkurensi untuk skrip pra-ambil. Default adalah 4.
      - name: PRELOADER_CONC
        value: "8"
      lifecycle:
        postStart:
          exec:
            command: ["/bin/sh", "-c", "CONC=${PRELOADER_CONC:-4}; if [ -d \"$MODEL_DIR\" ]; then find \"$MODEL_DIR\" -type f -print0 | xargs -0 -I {} -P \"$CONC\" sh -c 'cat \"{}\" > /dev/null'; fi"]
  # ...

• Refaktor logika aplikasi: Evaluasi dan refaktor logika aplikasi untuk beralih dari pembacaan konkuren multi-proses dalam satu file ke pembacaan konkuren beberapa file berbeda. Perubahan ini dapat memanfaatkan keunggulan throughput tinggi OSS.