Kami menghemat pengontrol RAID, atau cara memberi makan Varia dengan Iops

Di zaman kami layanan cloud, AWS Lambda dan hosting berbagi lainnya dari sumber daya komputasi yang benar - benar tidak berwujud, kadang-kadang saya ingin sedikit dari saya sendiri. Selain keinginan, terkadang ada juga perlu memelintir satu atau lebih produk perangkat lunak dengan biaya platform minimal. Anda hampir selalu dapat menemukan beberapa peralatan berlebih, kadang-kadang bahkan ternyata menyatukan semuanya dan menyalakannya. Jika surplus ini mewakili CPU dengan setidaknya 4-6 core dan memori dari 64GB - umumnya sangat baik, Anda dapat mengambil ESXi dan bekerja dengan apa saja. Satu masalah: dengan kapasitas disk pada perangkat keras rumah tangga di VMWare - sama sekali tidak ada. Kinerja HDD tunggal lokal rendah, dan kehilangan konten sekrup tunggal dalam ruang hampa di abad ke-21 adalah halo. Mari kita coba sambungkan sesuatu melalui jaringan.

TL; DR> asosiasi, keseimbangan, batas rr, itu saja.

Sebenarnya, teks di bawah ini bukan tentang fakta bahwa ini umumnya mungkin atau semacam pengetahuan. Internet penuh dengan artikel untuk boneka (lihat di sini, lalu Berikutnya, Selanjutnya, Selesai) tentang cara mengirimkan kapasitas disk iSCSI. Saya menulis hanya untuk mengecualikan "kesalahan orang yang selamat" dan berbagi momen ketika "semuanya akan salah" (dan itu akan berjalan, Murphy benar), dan ketika Anda mencoba memuat solusinya, itu hanya crash.

Jadi, kami akan mencoba untuk menutupi "hypervisor rumah tangga" kami dengan array disk eksternal yang terhubung melalui jaringan. Karena semuanya berputar di sekitar "murah", biarlah itu FreeNAS dan 4 disk SATA, yang dilayani oleh 3 GHz 45-nm persen biasa-biasa saja. Kami melihat Ebay, dan untuk uang yang sebanding dengan pengontrol RAID yang digunakan, mereka menyeret beberapa kartu jaringan i350-T4 dari sana. Ini adalah empat port gigabit adapter dari Intel. Menurut mereka, kami akan mengaitkan penyimpanan dengan hypervisor.

Hitung sedikit. Kecepatan transfer data rata-rata dari disk SATA rata-rata adalah 160-180 MB / s dengan lebar antarmuka 6 Gb / s. Bahkan, kecepatan transfer data aktual dari HDD tidak melebihi 2 Gb / s. Ini bukan angka yang besar, mengingat kami berencana untuk port 4-gigabit (bagaimana mengubah 4x1Gbps menjadi 4Gbps - kami akan membahas lebih lanjut). Segala sesuatu dengan kecepatan akses acak jauh lebih buruk - di sini semuanya jatuh hampir ke tingkat floppy disk.


Mengingat bahwa profil beban disk banyak OS tamu jauh dari linear, saya ingin melihat angka yang lebih menyenangkan. Untuk memperbaiki situasi dalam sistem file hypervisor (VMFS v6), ukuran blok adalah 1 MB, yang membantu untuk memadatkan banyak operasi acak dan mempercepat akses ke data pada disk virtual. Tetapi bahkan dengan ini, satu disk fisik tidak akan cukup untuk menangani operasi I / O dari semua "tamu".

Saya akan segera melakukan reservasi - semuanya lebih masuk akal jika Anda memiliki lebih dari dua adapter untuk "jaringan penyimpanan". ESXi dengan lisensi uniprocessor gratis dapat terhubung, selain disk lokal, ke dua jenis penyimpanan - NFS dan iSCSI. NFS melibatkan akses tingkat file dan juga bagus dengan caranya sendiri. Di atasnya, Anda dapat menggunakan tamu yang tidak menuntut kinerja disk. Dengan senang hati mencadangkannya. Anda dapat membuka bola NFS yang sama di tempat lain dan menyalin snapshot vm. Secara umum, dengan satu antarmuka jaringan (jika bukan 10GE, tentu saja) - NFS adalah pilihan Anda.

ISCSI memiliki beberapa keunggulan dibandingkan NFS. Untuk benar-benar mewujudkannya, kami telah menyiapkan - telah menyiapkan 4 port gigabit untuk jaringan penyimpanan. Bagaimana ekspansi bandwidth jaringan biasanya terjadi pada kecepatan antarmuka yang dikenal? Itu benar, agregasi. Tetapi untuk pemanfaatan lengkap saluran agregat, sejumlah kondisi diperlukan, dan ini lebih cocok untuk komunikasi antar sakelar atau untuk uplink jaringan hypervisor. Implementasi protokol iSCSI menyediakan fungsi seperti multipathing (secara harfiah, banyak jalur) - kemampuan untuk menghubungkan volume yang sama melalui antarmuka jaringan yang berbeda. Tentu saja, tentang kemungkinan penyeimbangan beban di sana juga, meskipun tujuan utamanya adalah toleransi kesalahan dari jaringan penyimpanan. (Dalam keadilan, NFSv4.1 mendukung trunking sesi berdasarkan sihir paling canggih seperti RDMA dan MPTCP, tetapi ini adalah upaya untuk mengalihkan masalah akses file dari sakit kepala ke yang sehat ke tingkat yang lebih rendah.)

Jadi, sebagai permulaan kami akan menerbitkan target kami. Kami percaya bahwa FreeNAS diinstal, alamat IP manajemen secara teratur mengirimkan antarmuka web, kami memotong array dan zvol sesuai dengan keyakinan internal kami. Dalam kasus kami, ini adalah drive 4 x 500GB yang dikombinasikan dalam raidz1 (yang hanya memberikan kapasitas efektif 1,3 TiB), dan zvol berukuran tepat 1 TB. Kami akan mengonfigurasi antarmuka jaringan i350, untuk kesederhanaan kami menerima bahwa setiap orang akan menjadi milik subnet yang berbeda.


Kemudian kita mengkonfigurasi bola iSCSI menggunakan metode "Next, Next, Done". Saat mengkonfigurasi portal, jangan lupa untuk menambahkan semua antarmuka jaringan yang didedikasikan untuk iSCSI di sana. Seharusnya terlihat seperti pada gambar.



Perhatian yang lebih besar perlu diberikan untuk mengatur batas - ketika menyajikan volume, perlu untuk memaksa ukuran blok 512 byte. Tanpa ini, inisiator ESXi menolak untuk mengidentifikasi volume yang disajikan sama sekali. Demi kesetiaan, lebih baik menonaktifkan ukuran probros dari blok fisik (yang pada zvol tidak dan tidak bisa) dan mengaktifkan mode dukungan Xen.
Dengan FreeNAS untuk saat ini.

Di sisi ESXi, agak sulit untuk membuat jaringan. Sekali lagi, kami percaya bahwa hypervisor itu sendiri diinstal dan juga dikelola pada port terpisah. Anda harus memilih 4 antarmuka VM Kernel yang dimiliki oleh 4 grup port yang berbeda dalam 4 switch virtual yang berbeda. Masing-masing switch memiliki port fisik uplink sendiri. Kami mengambil alamat vmk #, tentu saja, dalam subnet yang sesuai, mirip dengan mengkonfigurasi port penyimpanan. Urutan pengaturan alamat, secara umum, penting - baik kita menghubungkan kartu port-to-port tanpa switch, atau kami memberikan tautan yang berbeda ke jaringan yang berbeda (well, itu jika dengan cara dewasa), jadi pencocokan port secara fisik penting.




Saat mengatur jaringan untuk iSCSI, kami memberikan perhatian khusus pada parameter MTU. Ini persis seperti ketika "ukuran penting" - kami mengambil yang maksimum yang dapat dipasang oleh semua komponen jaringan. Jika kartu-kartu terhubung secara langsung, Anda dapat mengarahkan mtu 9000 di kedua sisi, pada ESXi dan FreeNAS. Namun, sakelar normal akan mendukung nilai ini. Kami ping, kami melihat bahwa jaringan itu normal, dan paket-paket ukuran yang diperlukan berlalu. Bagus Kami membakar inisiator.

Nyalakan iSCSI, tambahkan alamat IP ke bagian konfigurasi dinamis (Penyimpanan -> Adaptor -> Konfigurasikan iSCSI -> Target dinamis). Setelah menyimpan, portal iSCSI akan disurvei di alamat-alamat ini, pemrakarsa akan menentukan bahwa masing-masing memiliki volume yang sama dan terhubung ke semua alamat yang tersedia (multipath yang sama). Selanjutnya, kita perlu membuat datastore pada perangkat yang muncul.

Setelah itu, Anda dapat meluncurkan mesin virtual dan mengukur apa yang kami dapatkan.


Hasil tidak begitu mengesankan. Buka konsol penyimpanan, tampilkan status jaringan saat ini dan jalankan tes.

root@freenas:~ # systat -ifstat

Hanya satu dari empat port jaringan (igb1) yang digunakan. Ini terjadi karena mekanisme balancing yang disediakan secara default untuk multipath memilih adaptor yang sama dengan setiap paket data. Kita perlu menggunakan semuanya.
Kami terhubung ke hypervisor melalui SSH dan perintah.
Pertama, mari kita lihat ID apa yang dimiliki bulan dengan multipath, dan cara kerjanya:

[root@localhost:~] esxcfg-mpath -b
naa.6589cfc000000b478db42ca922bb9308 : FreeNAS iSCSI Disk (naa.6589cfc000000b478db42ca922bb9308)

[root@localhost:~] esxcli storage nmp device list -d naa.6589cfc000000b478db42ca922bb9308 | grep PSP
Path Selection Policy: VMW_PSP_MRU

Kebijakan pemilihan jalur adalah MRU, yaitu yang paling baru digunakan. Semua data masuk ke port yang sama, pemilihan ulang jalur hanya terjadi ketika koneksi jaringan tidak tersedia. Kami mengubah ke round-robin, di mana semua antarmuka berubah pada gilirannya setelah sejumlah operasi:

[root@localhost:~] esxcli storage nmp device set -d naa.6589cfc000000b478db42ca922bb9308 -P VMW_PSP_RR

Kami reboot ESXi, buka pemantauan, jalankan tes. Kami melihat bahwa beban didistribusikan secara merata di seluruh adapter jaringan (setidaknya nilai puncak, terlalu banyak tergores), hasil pengujian juga lebih menyenangkan.

  Interface Peak igb3 in 43.233 MB/s out 46.170 MB/s igb2 in 42.806 MB/s out 45.773 MB/s igb1 in 43.495 MB/s out 45.489 MB/s igb0 in 43.208 MB/s out 46.079 MB/s 

Ada beberapa penyimpangan pada port, ini disebabkan oleh batasan Path Selection Policy - jumlah operasi atau byte, setelah itu beralih ke port lain terjadi. Secara default, 1000 IOPS, yaitu, jika pertukaran data dalam 999 operasi, itu akan melalui satu port jaringan. Anda dapat mengubah, membandingkan, dan memilih nilai yang sesuai. Anda tidak dapat mengubah, standar sudah cukup untuk sebagian besar tugas.

Kami melakukan pengukuran, pengujian, pekerjaan. Hasilnya secara signifikan lebih unggul daripada kemampuan satu drive, jadi sekarang mesin virtual kami mungkin tidak menyikut operasi I / O. Kecepatan dan toleransi kesalahan array yang dihasilkan akan tergantung pada perangkat keras dan bagaimana volume dikonfigurasi.