Pertimbangan performa

Halaman ini memberikan panduan tentang cara mengonfigurasi lingkungan Google Cloud Managed Lustre untuk mendapatkan performa terbaik.

Untuk melihat angka performa khusus untuk setiap tingkat performa, lihat Tingkat performa.

Performa setelah meningkatkan kapasitas

Meningkatkan kapasitas penyimpanan instance yang ada akan meningkatkan throughput dan IOPS maksimumnya, serta kemungkinan performa metadatanya.

Performa throughput baca akan meningkat secara bertahap saat data baru ditulis dan didistribusikan ulang di seluruh penyimpanan tambahan. Performa throughput tulis meningkat dengan cepat.

Pemanfaatan kapasitas tinggi

Setelah penggunaan kapasitas penyimpanan instance mencapai 90%, performa instance dapat menurun. Pertimbangkan untuk meningkatkan kapasitas instance Managed Lustre Anda. Anda mungkin perlu meminta kuota tambahan sebelum melakukan perluasan.

Jika Anda melihat error No space left on device, tetapi instance Anda menunjukkan kapasitas yang tersisa, lihat Error No space left on device.

Unit transmisi maksimum (MTU) jaringan VPC

Saat membuat jaringan VPC, menetapkan nilai mtu (unit transmisi maksimum, atau ukuran paket IP terbesar yang dapat ditransmisikan di jaringan ini) ke nilai maksimum yang diizinkan, yaitu 8896, akan meningkatkan performa hingga 10% dibandingkan dengan nilai default 1460 byte.

Anda dapat melihat nilai MTU jaringan saat ini dengan perintah berikut:

gcloud compute networks describe NETWORK_NAME --format="value(mtu)"

Nilai MTU jaringan dapat diperbarui setelah jaringan dibuat, tetapi ada pertimbangan penting. Lihat Mengubah MTU jaringan untuk mengetahui detailnya.

Jenis mesin Compute Engine

Throughput jaringan dapat dipengaruhi oleh pilihan jenis mesin Anda. Secara umum, untuk mendapatkan throughput terbaik:

  • Menambah jumlah vCPU. Bandwidth traffic keluar maksimum per instance umumnya adalah 2 Gbps per vCPU, hingga maksimum jenis mesin.
  • Pilih seri mesin yang mendukung batas masuk dan keluar yang lebih tinggi. Misalnya, instance C2 dengan jaringan Tier_1 mendukung bandwidth traffic keluar hingga 100 Gbps. Instance C3 dengan jaringan Tier_1 mendukung hingga 200 Gbps.
  • Aktifkan performa jaringan per VM Tier_1 dengan jenis mesin yang lebih besar.
  • Gunakan NIC Virtual Google (gVNIC). gVNIC adalah satu-satunya opsi untuk jenis mesin Generasi 3 dan yang lebih baru. gVNIC diperlukan saat menggunakan jaringan Tier_1.

Untuk mengetahui informasi mendetail, lihat Bandwidth jaringan.

Konfigurasi multi-NIC

Dengan menggunakan kemampuan multi-rail bawaan Lustre, klien dapat membagi-bagi traffic jaringan di beberapa kartu antarmuka jaringan (multi-NIC). Hal ini menggabungkan bandwidth untuk memenuhi kapasitas instance Managed Lustre yang tinggi.

Untuk mengonfigurasi multi-NIC, Anda harus:

  • Pilih jenis mesin dengan beberapa NIC fisik.
  • Buat subnet untuk setiap NIC dan tetapkan setiap NIC ke subnetnya.
  • Ikuti langkah-langkah multi-NIC saat menghubungkan dari Compute Engine atau GKE.

Memverifikasi penyeimbangan traffic

Setelah mengonfigurasi multi-NIC, pastikan data diseimbangkan dengan benar.

Compute Engine

Verifikasi penyeimbangan data langsung di VM dengan memantau antarmuka jaringan yang dikonfigurasi (misalnya, eth0 dan eth1) menggunakan nload saat membuat traffic ke backend Managed Lustre:

nload -m eth0 eth1

Dalam konfigurasi multi-NIC yang berhasil, bitrate keluar harus kira-kira setara di semua antarmuka yang dikonfigurasi.

GKE

Pastikan traffic jaringan dari workload Anda diseimbangkan di beberapa NIC dengan men-deploy Pod network-debugger sementara ke node tempat workload Anda dijadwalkan:

  1. Identifikasi node tempat workload Anda dijadwalkan:

    kubectl get pod POD_NAME -o wide

    Ganti POD_NAME dengan nama Pod Anda. Di output perintah, catat nama di kolom NODE.

  2. Luncurkan debugger jaringan di node tersebut:

    kubectl run multi-nic-debug --rm -i --tty --image=nicolaka/netshoot \
  --overrides='{"spec": {"hostNetwork": true, "nodeSelector": {"kubernetes.io/hostname": "NODE_NAME"}, "tolerations": [{"key": "nvidia.com/gpu", "operator": "Exists", "effect": "NoSchedule"}]}}' \
  -- /bin/bash -c "apk update && apk add nload && nload -m eth0 eth1"

    Ganti NODE_NAME dengan nama node dari langkah sebelumnya.

  3. Pada output, analisis bitrate kolom Outgoing untuk eth0 dan eth1. Jika konfigurasi berhasil, bitrate akan hampir sama. Outputnya mirip dengan hal berikut ini:

    Device eth0 [10.1.0.50] (1/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.63 MBit/s                       Curr: 1.46 GBit/s
Avg: 1.60 MBit/s                        Avg: 1.44 GBit/s
Min: 1.40 MBit/s                        Min: 1.25 GBit/s
Max: 1.64 MBit/s                        Max: 1.47 GBit/s
Ttl: 590.94 GByte                       Ttl: 405.19 GByte

Device eth1 [172.16.15.5] (2/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.64 MBit/s                       Curr: 1.47 GBit/s
Avg: 1.62 MBit/s                        Avg: 1.44 GBit/s
Min: 1.42 MBit/s                        Min: 1.26 GBit/s
Max: 1.66 MBit/s                        Max: 1.47 GBit/s
Ttl: 587.68 GByte                       Ttl: 406.36 GByte

  4. Keluar dari debugger dengan menekan Ctrl+C.

Memecahkan masalah bottleneck umum

Jika performa workload Anda jauh lebih rendah dari yang diharapkan untuk tingkat performa Managed Lustre Anda, periksa masalah umum berikut:

  • Jumlah mesin klien tidak mencukupi: Satu mesin klien mengalami hambatan karena batas pemrosesan jaringan link tunggal dan CPU virtual (vCPU) miliknya. Untuk mencapai tingkat throughput tinggi, Anda harus mendistribusikan beban. Misalnya, untuk mencapai titik jenuh sistem file Managed Lustre 100.000 MBps, Anda biasanya memerlukan setidaknya 60 mesin klien standar (atau 12 mesin klien yang dikonfigurasi untuk menggunakan jaringan bandwidth tinggi Tingkat 1) yang menulis secara paralel. Untuk ukuran instance maksimum dari tingkat performa apa pun, Anda mungkin memerlukan lebih dari 2.500 mesin klien yang dikonfigurasi untuk menggunakan jaringan bandwidth tinggi Tingkat 1.

  • MTU Virtual Private Cloud (VPC) yang tidak ideal: Secara default, jaringan VPC menggunakan MTU 1460 (frame Ethernet standar). Untuk penyimpanan berperforma tinggi seperti Managed Lustre, Anda harus mengonfigurasi frame jumbo dengan MTU 8896. Menjalankan dengan MTU 1460 standar akan memaksa CPU memproses lebih dari dua kali lipat jumlah paket jaringan, sehingga menambah biaya tambahan CPU dan membatasi bandwidth maksimum.

  • Konfigurasi Bandwidth Jaringan Tingkat 1 tidak ada: Banyak jenis mesin berperforma tinggi mengharuskan Anda memilih untuk menggunakan bandwidth jaringan Tingkat 1 secara eksplisit.

    • Di Compute Engine dan node pool GKE Standard, gunakan flag --network-performance-configs=total-egress-bandwidth-tier=TIER_1 selama pembuatan. Tanpa tanda ini, VM atau node dapat dibatasi pada batas keluar default yang lebih rendah.
    • Di GKE Autopilot, Anda tidak menentukan flag ini secara langsung. Sebagai gantinya, pilih deret mesin yang mendukung bandwidth lebih tinggi (seperti c3) menggunakan pemilih node dalam spesifikasi Pod Anda.

    Untuk mengetahui informasi selengkapnya, lihat Jenis mesin Compute Engine.

  • Penggunaan Target Penyimpanan Objek (OST) Lustre yang tidak seimbang: Managed Lustre membagi data file di beberapa Target Penyimpanan Objek (OST). Jika pengujian atau beban kerja Anda menulis ke satu file yang tidak di-striping, atau jika tugas klien menulis pola yang membebani satu OST, OST tersebut akan menjadi hambatan sementara sistem file lainnya tidak digunakan. Untuk menghindarinya, pastikan Anda menyeimbangkan payload tulis secara merata di semua OST yang tersedia (misalnya, dengan menggunakan mode file per proses dalam tolok ukur).

  • Persaingan bandwidth jaringan bersama: Bandwidth keluar pada mesin klien (VM Compute Engine atau node GKE) digunakan bersama di semua operasi jaringan pada mesin. Jika mesin atau pod klien Anda mendownload paket besar secara bersamaan, menjalankan pembersihan logging yang berat, atau berkomunikasi secara intensif dengan node cluster lain, performa penyimpanan Anda akan dibatasi oleh bandwidth jaringan yang tersisa.