Hari ini kita akan menganalisis metrik subsistem cakera dalam vSphere. Masalah storan ialah sebab paling biasa untuk mesin maya yang perlahan. Jika, dalam kes CPU dan RAM, penyelesaian masalah berakhir pada tahap hipervisor, maka jika terdapat masalah dengan cakera, anda mungkin perlu berurusan dengan rangkaian data dan sistem storan.
Saya akan membincangkan topik menggunakan contoh akses blok kepada sistem storan, walaupun untuk akses fail, kaunter adalah lebih kurang sama.
Sedikit teori
Apabila bercakap tentang prestasi subsistem cakera mesin maya, orang biasanya memberi perhatian kepada tiga parameter yang saling berkaitan:
- bilangan operasi input/output (Operasi Input/Output Sesaat, IOPS);
- daya pengeluaran;
- kelewatan operasi input/output (Latensi).
Bilangan IOPS biasanya penting untuk beban kerja rawak: akses kepada blok cakera yang terletak di tempat yang berbeza. Contoh beban sedemikian boleh menjadi pangkalan data, aplikasi perniagaan (ERP, CRM), dsb.
Throughput penting untuk beban berurutan: akses kepada blok yang terletak satu demi satu. Contohnya, pelayan fail (tetapi tidak selalu) dan sistem pengawasan video boleh menjana beban sedemikian.
Throughput berkaitan dengan bilangan operasi I/O seperti berikut:
Throughput = IOPS * Saiz blok, dengan saiz blok ialah saiz blok.
Saiz blok adalah ciri yang agak penting. Versi moden ESXi membenarkan blok bersaiz sehingga 32 KB. Jika blok itu lebih besar, ia dibahagikan kepada beberapa. Tidak semua sistem storan boleh berfungsi dengan cekap dengan blok besar sedemikian, jadi terdapat parameter DiskMaxIOSize dalam Tetapan Lanjutan ESXi. Menggunakannya, anda boleh mengurangkan saiz blok maksimum yang dilangkau oleh hypervisor (maklumat lanjut ). Sebelum menukar parameter ini, saya syorkan anda berunding dengan pengeluar sistem storan atau sekurang-kurangnya menguji perubahan pada bangku makmal.
Saiz blok yang besar boleh memberi kesan buruk pada prestasi storan. Walaupun bilangan IOPS dan throughput agak kecil, latensi tinggi boleh diperhatikan dengan saiz blok yang besar. Oleh itu, perhatikan parameter ini.
Latency β parameter prestasi yang paling menarik. Latensi I/O untuk mesin maya terdiri daripada:
- kelewatan di dalam hipervisor (KAVG, Average Kernel MilliSec/Read);
- kelewatan yang disediakan oleh rangkaian data dan sistem storan (DAVG, Average Driver MilliSec/Command).
Jumlah kependaman yang boleh dilihat dalam OS tetamu (GAVG, Average Guest MilliSec/Command) ialah jumlah KAVG dan DAVG.
GAVG dan DAVG diukur dan KAVG dikira: GAVGβDAVG.
Mari kita lihat lebih dekat KAVG. Semasa operasi biasa, KAVG harus cenderung kepada sifar atau sekurang-kurangnya lebih kecil daripada DAVG. Satu-satunya kes yang saya tahu di mana KAVG dijangka tinggi ialah had IOPS pada cakera VM. Dalam kes ini, apabila anda cuba melebihi had, KAVG akan meningkat.
Komponen KAVG yang paling penting ialah QAVG - masa giliran pemprosesan di dalam hipervisor. Baki komponen KAVG boleh diabaikan.
Barisan gilir dalam pemacu penyesuai cakera dan baris gilir ke bulan mempunyai saiz tetap. Untuk persekitaran yang sarat tinggi, mungkin berguna untuk meningkatkan saiz ini. menerangkan bagaimana untuk meningkatkan baris gilir dalam pemacu penyesuai (pada masa yang sama baris gilir ke bulan akan meningkat). Tetapan ini berfungsi apabila hanya satu VM yang berfungsi dengan bulan, yang jarang berlaku. Jika terdapat beberapa VM di bulan, anda juga mesti meningkatkan parameter Disk.SchedNumReqOutstanding (arahan ). Dengan meningkatkan baris gilir, anda mengurangkan QAVG dan KAVG masing-masing.
Tetapi sekali lagi, baca dahulu dokumentasi daripada vendor HBA dan uji perubahan pada bangku makmal.
Saiz baris gilir ke bulan boleh dipengaruhi oleh kemasukan mekanisme SIOC (Storage I/O Control). Ia menyediakan akses seragam kepada bulan daripada semua pelayan dalam kelompok dengan menukar baris gilir secara dinamik kepada bulan pada pelayan. Iaitu, jika salah satu hos menjalankan VM yang memerlukan jumlah prestasi yang tidak seimbang (VM jiran yang bising), SIOC mengurangkan panjang baris gilir ke bulan pada hos ini (DQLEN). Maklumat lanjut .
Kami telah menyelesaikan KAVG, sekarang sedikit tentang DAVG. Segala-galanya mudah di sini: DAVG ialah kelewatan yang diperkenalkan oleh persekitaran luaran (rangkaian data dan sistem storan). Setiap sistem storan moden dan tidak begitu moden mempunyai kaunter prestasinya sendiri. Untuk menganalisis masalah dengan DAVG, masuk akal untuk melihatnya. Jika semuanya baik pada bahagian ESXi dan storan, semak rangkaian data.
Untuk mengelakkan masalah prestasi, pilih Dasar Pemilihan Laluan (PSP) yang betul untuk sistem storan anda. Hampir semua sistem storan moden menyokong PSP Round-Robin (dengan atau tanpa ALUA, Akses Unit Logikal Asymmetric). Dasar ini membolehkan anda menggunakan semua laluan yang tersedia ke sistem storan. Dalam kes ALUA, hanya laluan ke pengawal yang memiliki bulan digunakan. Tidak semua sistem storan pada ESXi mempunyai peraturan lalai yang menetapkan dasar Round-Robin. Jika tiada peraturan untuk sistem storan anda, gunakan pemalam daripada pengilang sistem storan, yang akan membuat peraturan yang sepadan pada semua hos dalam gugusan atau cipta peraturan sendiri. Butiran .
Selain itu, sesetengah pengeluar sistem storan mengesyorkan menukar bilangan IOPS setiap laluan daripada nilai standard 1000 kepada 1. Dalam amalan kami, ini memungkinkan untuk "memerah" lebih banyak prestasi daripada sistem storan dan mengurangkan dengan ketara masa yang diperlukan untuk failover sekiranya berlaku kegagalan atau kemas kini pengawal. Semak cadangan vendor, dan jika tiada kontraindikasi, cuba ubah parameter ini. Butiran .
Kaunter prestasi subsistem cakera mesin maya asas
Kaunter prestasi subsistem cakera dalam vCenter dikumpul dalam bahagian Datastore, Cakera, Cakera Maya:
Dalam seksyen Simpanan data terdapat metrik untuk storan cakera vSphere (stor data) di mana cakera VM terletak. Di sini anda akan menemui kaunter standard untuk:
- IOPS (Purata permintaan baca/tulis sesaat),
- daya tampung (kadar Baca/Tulis),
- kelewatan (Baca/Tulis/Latensi tertinggi).
Pada dasarnya, semuanya jelas dari nama kaunter. Izinkan saya menarik perhatian anda sekali lagi kepada fakta bahawa statistik di sini bukan untuk VM tertentu (atau cakera VM), tetapi statistik umum untuk keseluruhan stor data. Pada pendapat saya, adalah lebih mudah untuk melihat statistik ini dalam ESXTOP, sekurang-kurangnya berdasarkan fakta bahawa tempoh pengukuran minimum terdapat 2 saat.
Dalam seksyen Cakera terdapat metrik pada peranti blok yang digunakan oleh VM. Terdapat pembilang untuk IOPS jenis penjumlahan (bilangan operasi input/output semasa tempoh pengukuran) dan beberapa pembilang yang berkaitan dengan akses menyekat (Perintah dibatalkan, tetapan semula Bas). Pada pendapat saya, ia juga lebih mudah untuk melihat maklumat ini dalam ESXTOP.
Seksyen Cakera Maya β yang paling berguna dari sudut pandangan mencari masalah prestasi subsistem cakera VM. Di sini anda boleh melihat prestasi untuk setiap cakera maya. Maklumat inilah yang diperlukan untuk memahami sama ada mesin maya tertentu mempunyai masalah. Sebagai tambahan kepada pembilang standard untuk bilangan operasi I/O, volum baca/tulis dan kelewatan, bahagian ini mengandungi pembilang berguna yang menunjukkan saiz blok: Saiz permintaan Baca/Tulis.
Dalam gambar di bawah ialah graf prestasi cakera VM, di mana anda boleh melihat bilangan IOPS, kependaman dan saiz blok.
Anda juga boleh melihat metrik prestasi untuk keseluruhan stor data jika SIOC didayakan. Berikut ialah maklumat asas mengenai purata Latensi dan IOPS. Secara lalai, maklumat ini hanya boleh dilihat dalam masa nyata.
ESXTOP
ESXTOP mempunyai beberapa skrin yang menyediakan maklumat tentang subsistem cakera hos secara keseluruhan, mesin maya individu dan cakeranya.
Mari kita mulakan dengan maklumat mengenai mesin maya. Skrin "Disk VM" dipanggil dengan kekunci "v":
NVDISK ialah bilangan cakera VM. Untuk melihat maklumat bagi setiap cakera, tekan "e" dan masukkan GID VM yang diminati.
Maksud parameter yang tinggal pada skrin ini jelas daripada nama mereka.
Skrin lain yang berguna semasa menyelesaikan masalah ialah Penyesuai cakera. Dipanggil dengan kekunci βdβ (medan A,B,C,D,E,G dipilih dalam gambar di bawah):
NPTH β bilangan laluan ke bulan yang boleh dilihat daripada penyesuai ini. Untuk mendapatkan maklumat bagi setiap laluan pada penyesuai, tekan "e" dan masukkan nama penyesuai:
AQLEN β saiz baris gilir maksimum pada penyesuai.
Juga pada skrin ini adalah kaunter kelewatan yang saya bincangkan di atas: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.
Skrin peranti cakera, yang dipanggil dengan menekan kekunci "u", memberikan maklumat mengenai peranti blok individu - bulan (medan A, B, F, G, I dipilih dalam gambar di bawah). Di sini anda boleh melihat status baris gilir untuk bulan.
DQLEN β saiz baris gilir untuk peranti blok.
ACTV β bilangan arahan I/O dalam kernel ESXi.
QUED β bilangan arahan I/O dalam baris gilir.
%DOLAR AMERIKA β ACTV / DQLEN Γ 100%.
LOAD β (ACTV + QUED) / DQLEN.
Jika %USD tinggi, anda harus mempertimbangkan untuk meningkatkan baris gilir. Lebih banyak arahan dalam baris gilir, lebih tinggi QAVG dan, sewajarnya, KAVG.
Anda juga boleh melihat pada skrin peranti cakera sama ada VAAI (vStorage API for Array Integration) sedang berjalan pada sistem storan. Untuk melakukan ini, pilih medan A dan O.
Mekanisme VAAI membolehkan anda memindahkan sebahagian daripada kerja daripada hypervisor terus ke sistem storan, contohnya, sifar, menyalin blok atau menyekat.
Seperti yang anda lihat dalam gambar di atas, VAAI berfungsi pada sistem storan ini: Sifar dan primitif ATS digunakan secara aktif.
Petua untuk mengoptimumkan kerja dengan subsistem cakera pada ESXi
- Beri perhatian kepada saiz blok.
- Tetapkan saiz baris gilir yang optimum pada HBA.
- Jangan lupa untuk mendayakan SIOC pada stor data.
- Pilih PSP mengikut cadangan pengeluar sistem storan.
- Pastikan VAAI berfungsi.
Artikel berguna mengenai topik:
Sumber: www.habr.com