Hari ini kita akan menganalisis metrik subsistem disk di vSphere. Masalah penyimpanan adalah alasan paling umum mengapa mesin virtual lambat. Jika, dalam kasus CPU dan RAM, pemecahan masalah berakhir pada tingkat hypervisor, maka jika ada masalah dengan disk, Anda mungkin harus berurusan dengan jaringan data dan sistem penyimpanan.
Saya akan membahas topik ini menggunakan contoh blok akses ke sistem penyimpanan, meskipun untuk akses file penghitungnya kurang lebih sama.
Sedikit teori
Ketika berbicara tentang kinerja subsistem disk mesin virtual, orang biasanya memperhatikan tiga parameter yang saling terkait:
- jumlah operasi input/output (Operasi Input/Output Per Detik, IOPS);
- hasil;
- penundaan operasi input/output (Latensi).
Jumlah IOPS biasanya penting untuk beban kerja acak: akses ke blok disk yang terletak di tempat berbeda. Contoh beban tersebut dapat berupa database, aplikasi bisnis (ERP, CRM), dll.
Bandwidth penting untuk pemuatan berurutan: akses ke blok yang terletak satu demi satu. Misalnya, server file (tetapi tidak selalu) dan sistem pengawasan video dapat menghasilkan beban seperti itu.
Throughput terkait dengan jumlah operasi I/O sebagai berikut:
Throughput = IOPS * Ukuran blok, di mana Ukuran blok adalah ukuran blok.
Ukuran blok merupakan karakteristik yang cukup penting. Versi modern ESXi mengizinkan blok berukuran hingga 32 KB. Jika bloknya lebih besar lagi, maka dibagi menjadi beberapa. Tidak semua sistem penyimpanan dapat bekerja secara efisien dengan blok sebesar itu, jadi ada parameter DiskMaxIOSize di Pengaturan Lanjutan ESXi. Dengan menggunakannya, Anda dapat mengurangi ukuran blok maksimum yang dilewati oleh hypervisor (lebih detailnya ). Sebelum mengubah parameter ini, saya menyarankan Anda berkonsultasi dengan produsen sistem penyimpanan atau setidaknya menguji perubahan tersebut di meja laboratorium.
Ukuran blok yang besar dapat berdampak buruk pada kinerja penyimpanan. Meskipun jumlah IOPS dan throughput relatif kecil, latensi tinggi dapat diamati dengan ukuran blok yang besar. Oleh karena itu, perhatikan parameter ini.
Latensi β parameter kinerja paling menarik. Latensi I/O untuk mesin virtual terdiri dari:
- penundaan di dalam hypervisor (KAVG, Average Kernel MilliSec/Read);
- penundaan yang disediakan oleh jaringan data dan sistem penyimpanan (DAVG, Average Driver MilliSec/Command).
Total latensi yang terlihat di OS tamu (GAVG, Rata-rata Tamu MilliSec/Command) adalah jumlah dari KAVG dan DAVG.
GAVG dan DAVG diukur dan KAVG dihitung: GAVGβDAVG.
Mari kita lihat lebih dekat KAVG. Selama pengoperasian normal, KAVG seharusnya cenderung nol atau setidaknya jauh lebih kecil dari DAVG. Satu-satunya kasus yang saya tahu di mana KAVG diperkirakan tinggi adalah batas IOPS pada disk VM. Dalam hal ini, ketika Anda mencoba melampaui batas tersebut, KAVG akan meningkat.
Komponen KAVG yang paling penting adalah QAVG - waktu antrian pemrosesan di dalam hypervisor. Komponen KAVG lainnya dapat diabaikan.
Antrian di driver adaptor disk dan antrian ke bulan memiliki ukuran tetap. Untuk lingkungan dengan muatan tinggi, mungkin berguna untuk meningkatkan ukuran ini. menjelaskan cara menambah antrian di driver adaptor (pada saat yang sama antrian ke bulan akan meningkat). Pengaturan ini berfungsi ketika hanya satu VM yang bekerja dengan bulan, dan hal ini jarang terjadi. Jika ada beberapa VM di bulan, Anda juga harus meningkatkan parameternya Disk.SchedNumReqLuar Biasa (instruksi ). Dengan menambah antrian, Anda masing-masing menurunkan QAVG dan KAVG.
Namun sekali lagi, baca dulu dokumentasi dari vendor HBA dan uji perubahannya di meja lab.
Besar kecilnya antrian ke bulan dapat dipengaruhi oleh masuknya mekanisme SIOC (Storage I/O Control). Ini memberikan akses seragam ke bulan dari semua server di cluster dengan secara dinamis mengubah antrian ke bulan di server. Artinya, jika salah satu host menjalankan VM yang memerlukan jumlah kinerja yang tidak proporsional (VM tetangga yang berisik), SIOC mengurangi panjang antrian ke bulan pada host ini (DQLEN). Keterangan lebih lanjut .
Kami telah memilah KAVG, sekarang sedikit tentangnya DAVG. Semuanya sederhana di sini: DAVG adalah penundaan yang disebabkan oleh lingkungan eksternal (jaringan data dan sistem penyimpanan). Setiap sistem penyimpanan modern dan tidak terlalu modern memiliki penghitung kinerjanya sendiri. Untuk menganalisis masalah dengan DAVG, masuk akal untuk melihatnya. Jika semuanya baik-baik saja di sisi ESXi dan penyimpanan, periksa jaringan data.
Untuk menghindari masalah kinerja, pilih Kebijakan Pemilihan Jalur (PSP) yang benar untuk sistem penyimpanan Anda. Hampir semua sistem penyimpanan modern mendukung PSP Round-Robin (dengan atau tanpa ALUA, Asymmetric Logical Unit Access). Kebijakan ini memungkinkan Anda untuk menggunakan semua jalur yang tersedia ke sistem penyimpanan. Dalam kasus ALUA, hanya jalur menuju pengontrol yang memiliki bulan yang digunakan. Tidak semua sistem penyimpanan di ESXi memiliki aturan default yang menetapkan kebijakan Round-Robin. Jika tidak ada aturan untuk sistem penyimpanan Anda, gunakan plugin dari produsen sistem penyimpanan, yang akan membuat aturan terkait pada semua host di cluster, atau buat aturan sendiri. Detail .
Selain itu, beberapa produsen sistem penyimpanan menyarankan untuk mengubah jumlah IOPS per jalur dari nilai standar 1000 menjadi 1. Dalam praktik kami, hal ini memungkinkan untuk βmemerasβ lebih banyak kinerja dari sistem penyimpanan dan secara signifikan mengurangi waktu yang diperlukan untuk failover jika terjadi kegagalan atau pembaruan pengontrol. Periksa rekomendasi vendor, dan jika tidak ada kontraindikasi, coba ubah parameter ini. Detail .
Penghitung kinerja subsistem disk mesin virtual dasar
Penghitung kinerja subsistem disk di vCenter dikumpulkan di bagian Datastore, Disk, Virtual Disk:
Pada bagian Penyimpanan data ada metrik untuk penyimpanan disk vSphere (penyimpanan data) tempat disk VM berada. Di sini Anda akan menemukan penghitung standar untuk:
- IOPS (Rata-rata permintaan baca/tulis per detik),
- throughput (tingkat Baca/Tulis),
- penundaan (Baca/Tulis/latensi tertinggi).
Prinsipnya semuanya jelas dari nama counternya. Izinkan saya menarik perhatian Anda sekali lagi pada fakta bahwa statistik di sini bukan untuk VM (atau disk VM) tertentu, tetapi statistik umum untuk seluruh datastore. Menurut pendapat saya, lebih mudah untuk melihat statistik ini di ESXTOP, setidaknya berdasarkan fakta bahwa periode pengukuran minimum adalah 2 detik.
Pada bagian Piringan ada metrik pada perangkat blok yang digunakan oleh VM. Terdapat penghitung untuk IOPS tipe penjumlahan (jumlah operasi input/output selama periode pengukuran) dan beberapa penghitung yang terkait dengan akses blok (Perintah dibatalkan, Bus disetel ulang). Menurut pendapat saya, melihat informasi ini juga lebih nyaman di ESXTOP.
Bagian Disk Virtual β yang paling berguna dalam hal menemukan masalah kinerja subsistem disk VM. Di sini Anda dapat melihat kinerja setiap disk virtual. Informasi inilah yang diperlukan untuk memahami apakah mesin virtual tertentu mengalami masalah. Selain penghitung standar untuk jumlah operasi I/O, volume baca/tulis, dan penundaan, bagian ini berisi penghitung berguna yang menunjukkan ukuran blok: Ukuran permintaan Baca/Tulis.
Pada gambar di bawah ini adalah grafik performa disk VM, di mana Anda dapat melihat jumlah IOPS, latensi, dan ukuran blok.
Anda juga dapat melihat metrik kinerja untuk seluruh datastore jika SIOC diaktifkan. Berikut adalah informasi dasar tentang Latensi rata-rata dan IOPS. Secara default, informasi ini hanya dapat dilihat secara real time.
ESXTOP
ESXTOP memiliki beberapa layar yang memberikan informasi tentang subsistem disk host secara keseluruhan, masing-masing mesin virtual dan disknya.
Mari kita mulai dengan informasi tentang mesin virtual. Layar βDisk VMβ dipanggil dengan tombol βvβ:
NVDISK adalah jumlah disk VM. Untuk melihat informasi setiap disk, tekan "e" dan masukkan GID VM yang diinginkan.
Arti dari parameter yang tersisa di layar ini jelas dari namanya.
Layar lain yang berguna saat memecahkan masalah adalah Adaptor disk. Dipanggil dengan tombol βdβ (bidang A,B,C,D,E,G dipilih pada gambar di bawah):
NPTH β jumlah jalur menuju bulan yang terlihat dari adaptor ini. Untuk mendapatkan informasi setiap jalur pada adaptor, tekan βeβ dan masukkan nama adaptor:
AQLEN β ukuran antrian maksimum pada adaptor.
Juga di layar ini terdapat penghitung penundaan yang saya bicarakan di atas: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.
Layar Perangkat disk, yang dipanggil dengan menekan tombol "u", memberikan informasi tentang masing-masing perangkat blok - bulan (bidang A, B, F, G, I dipilih pada gambar di bawah). Di sini Anda dapat melihat status antrian bulan.
DQLEN β ukuran antrian untuk perangkat blok.
ACTV β jumlah perintah I/O di kernel ESXi.
PERTANYAAN β jumlah perintah I/O dalam antrian.
%USD β ACTV/DQLEN Γ 100%.
LOAD β (ACTV + QED) / DQLEN.
Jika %USD tinggi, Anda harus mempertimbangkan untuk menambah antrean. Semakin banyak perintah dalam antrian, semakin tinggi QAVG dan, karenanya, KAVG.
Anda juga dapat melihat di layar Perangkat disk apakah VAAI (vStorage API for Array Integration) berjalan di sistem penyimpanan. Untuk melakukan ini, pilih bidang A dan O.
Mekanisme VAAI memungkinkan Anda mentransfer sebagian pekerjaan dari hypervisor langsung ke sistem penyimpanan, misalnya, memusatkan perhatian, menyalin blok, atau memblokir.
Seperti yang Anda lihat pada gambar di atas, VAAI bekerja pada sistem penyimpanan ini: primitif Zero dan ATS digunakan secara aktif.
Tips untuk mengoptimalkan pekerjaan dengan subsistem disk di ESXi
- Perhatikan ukuran blok.
- Tetapkan ukuran antrian optimal pada HBA.
- Jangan lupa untuk mengaktifkan SIOC di datastore.
- Pilihlah PSP sesuai dengan rekomendasi pabrikan sistem penyimpanannya.
- Pastikan VAAI berfungsi.
Artikel Terkait yang bermanfaat:
Sumber: www.habr.com