Banyak RAM percuma, NVMe Intel P4500 dan semuanya sangat perlahan - kisah penambahan partition swap yang tidak berjaya

Dalam artikel ini, saya akan bercakap tentang situasi yang baru-baru ini berlaku dengan salah satu pelayan dalam awan VPS kami, yang membuatkan saya buntu selama beberapa jam. Saya telah mengkonfigurasi dan menyelesaikan masalah pelayan Linux selama kira-kira 15 tahun, tetapi kes ini tidak sesuai dengan amalan saya sama sekali - Saya membuat beberapa andaian palsu dan menjadi sedikit terdesak sebelum saya dapat menentukan dengan betul punca masalah dan menyelesaikannya .

Mukadimah

Kami mengendalikan awan bersaiz sederhana, yang kami bina pada pelayan standard dengan konfigurasi berikut - 32 teras, 256 GB RAM dan pemacu 4500TB PCI-E Intel P4 NVMe. Kami sangat menyukai konfigurasi ini kerana ia menghilangkan keperluan untuk bimbang tentang overhed IO dengan menyediakan sekatan yang betul pada peringkat jenis contoh VM. Kerana NVMe Intel P4500 mempunyai prestasi yang mengagumkan, pada masa yang sama kami boleh menyediakan kedua-dua peruntukan IOPS penuh kepada mesin dan storan sandaran kepada pelayan sandaran dengan IOWAIT sifar.

Kami adalah salah seorang penganut lama yang tidak menggunakan SDN hyperconverged dan perkara lain yang bergaya, bergaya, belia untuk menyimpan volum VM, percaya bahawa lebih mudah sistem, lebih mudah untuk menyelesaikan masalah dalam keadaan "guru utama telah pergi. ke pergunungan.” Akibatnya, kami menyimpan volum VM dalam format QCOW2 dalam XFS atau EXT4, yang digunakan di atas LVM2.

Kami juga terpaksa menggunakan QCOW2 oleh produk yang kami gunakan untuk orkestra - Apache CloudStack.

Untuk melakukan sandaran, kami mengambil imej penuh volum sebagai petikan LVM2 (ya, kami tahu bahawa petikan LVM2 adalah perlahan, tetapi Intel P4500 membantu kami di sini juga). Kami buat lvmcreate -s .. dan dengan bantuan dd kami menghantar salinan sandaran ke pelayan jauh dengan storan ZFS. Di sini kami masih sedikit progresif - lagipun, ZFS boleh menyimpan data dalam bentuk termampat, dan kami boleh memulihkannya dengan cepat menggunakan DD atau dapatkan volum VM individu menggunakan mount -o loop ....

Anda boleh, sudah tentu, tidak mengalih keluar imej penuh volum LVM2, tetapi memasang sistem fail dalam RO dan menyalin imej QCOW2 sendiri, bagaimanapun, kami berhadapan dengan fakta bahawa XFS menjadi buruk daripada ini, dan bukan serta-merta, tetapi dengan cara yang tidak dapat diramalkan. Kami benar-benar tidak suka apabila hypervisor menjadi hos "melekat" secara tiba-tiba pada hujung minggu, pada waktu malam atau pada hari cuti kerana ralat yang tidak jelas bila ia akan berlaku. Oleh itu, untuk XFS kami tidak menggunakan pelekap gambar masuk RO untuk mengekstrak volum, kami hanya menyalin keseluruhan volum LVM2.

Kelajuan sandaran ke pelayan sandaran ditentukan dalam kes kami oleh prestasi pelayan sandaran, iaitu kira-kira 600-800 MB/s untuk data tidak boleh mampat; pengehad lagi ialah saluran 10Gbit/s yang mana pelayan sandaran disambungkan kepada kluster.

Dalam kes ini, salinan sandaran 8 pelayan hipervisor dimuat naik secara serentak ke satu pelayan sandaran. Oleh itu, cakera dan subsistem rangkaian pelayan sandaran, menjadi lebih perlahan, tidak membenarkan subsistem cakera hos hipervisor membebankan, kerana mereka tidak dapat memproses, katakan, 8 GB/saat, yang boleh menjadi hos hipervisor dengan mudah. menghasilkan.

Proses penyalinan di atas adalah sangat penting untuk cerita selanjutnya, termasuk butiran - menggunakan pemacu Intel P4500 yang pantas, menggunakan NFS dan, mungkin, menggunakan ZFS.

Cerita sandaran

Pada setiap nod hypervisor kami mempunyai partition SWAP kecil bersaiz 8 GB, dan kami "melancarkan" nod hypervisor itu sendiri menggunakan DD daripada imej rujukan. Untuk volum sistem pada pelayan, kami menggunakan 2xSATA SSD RAID1 atau 2xSAS HDD RAID1 pada pengawal perkakasan LSI atau HP. Secara umum, kami tidak peduli sama sekali apa yang ada di dalamnya, kerana volum sistem kami beroperasi dalam mod "hampir baca sahaja", kecuali untuk SWAP. Dan kerana kami mempunyai banyak RAM pada pelayan dan ia adalah 30-40% percuma, kami tidak memikirkan tentang SWAP.

Proses sandaran. Tugasan ini kelihatan seperti ini:

#!/bin/bash

mkdir -p /mnt/backups/volumes

DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)

lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snap

Beri perhatian kepada ionice -c3, sebenarnya, perkara ini tidak berguna sama sekali untuk peranti NVMe, kerana penjadual IO untuknya ditetapkan sebagai:

cat /sys/block/nvme0n1/queue/scheduler
[none] 

Walau bagaimanapun, kami mempunyai beberapa nod lama dengan RAID SSD konvensional, bagi mereka ini adalah berkaitan, jadi mereka bergerak SEBAGAIMANA ADANYA. Secara keseluruhan, ini hanyalah sekeping kod yang menarik yang menerangkan kesia-siaan ionice dalam kes konfigurasi sedemikian.

Perhatikan bendera iflag=direct untuk DD. Kami menggunakan IO langsung memintas cache penimbal untuk mengelakkan penggantian penimbal IO yang tidak perlu semasa membaca. Walau bagaimanapun, oflag=direct kami tidak melakukannya kerana kami telah menghadapi masalah prestasi ZFS semasa menggunakannya.

Kami telah menggunakan skim ini dengan jayanya selama beberapa tahun tanpa masalah.

Dan kemudian ia bermula... Kami mendapati bahawa salah satu nod tidak lagi disandarkan dan yang sebelumnya sedang berjalan dengan IOWAIT yang dahsyat sebanyak 50%. Apabila cuba memahami mengapa penyalinan tidak berlaku, kami menghadapi fenomena berikut:

Volume group "images" not found

Kami mula berfikir tentang "penghujung telah tiba untuk Intel P4500," namun, sebelum mematikan pelayan untuk menggantikan pemacu, masih perlu melakukan sandaran. Kami membetulkan LVM2 dengan memulihkan metadata daripada sandaran LVM2:

vgcfgrestore images

Kami melancarkan sandaran dan melihat lukisan minyak ini:

Sekali lagi kami sangat sedih - jelas bahawa kami tidak boleh hidup seperti ini, kerana semua VPS akan menderita, yang bermakna kami juga akan menderita. Apa yang berlaku tidak jelas - iostat menunjukkan IOPS yang menyedihkan dan IOWAIT tertinggi. Tiada idea selain "mari ganti NVMe", tetapi cerapan berlaku tepat pada masanya.

Analisis keadaan langkah demi langkah

Majalah sejarah. Beberapa hari sebelum ini, pada pelayan ini adalah perlu untuk mencipta VPS yang besar dengan 128 GB RAM. Nampaknya terdapat memori yang mencukupi, tetapi untuk berada di bahagian yang selamat, kami memperuntukkan 32 GB lagi untuk partition swap. VPS telah dibuat, berjaya menyelesaikan tugasnya dan kejadian itu dilupakan, tetapi partition SWAP kekal.

Ciri Konfigurasi. Untuk semua pelayan awan parameter vm.swappiness telah ditetapkan kepada lalai 60. Dan SWAP telah dicipta pada SAS HDD RAID1.

Apa yang berlaku (menurut editor). Apabila membuat sandaran DD menghasilkan banyak data tulis, yang diletakkan dalam penimbal RAM sebelum menulis kepada NFS. Teras sistem, berpandukan dasar swappiness, telah mengalihkan banyak halaman memori VPS ke kawasan swap, yang terletak pada volum HDD RAID1 yang perlahan. Ini menyebabkan IOWAIT berkembang dengan sangat kuat, tetapi bukan disebabkan oleh IO NVMe, tetapi disebabkan oleh IO HDD RAID1.

Bagaimana masalah itu diselesaikan. Partition swap 32GB telah dilumpuhkan. Ini mengambil masa 16 jam; anda boleh membaca secara berasingan tentang cara dan sebab SWAP dimatikan dengan perlahan. Tetapan telah ditukar swappiness kepada nilai yang sama dengan 5 seluruh awan.

Bagaimana ini tidak boleh berlaku?. Pertama, jika SWAP berada pada peranti SSD RAID atau NVMe, dan kedua, jika tiada peranti NVMe, tetapi peranti yang lebih perlahan yang tidak akan menghasilkan volum data sedemikian - ironinya, masalah berlaku kerana NVMe itu terlalu pantas.

Selepas itu, semuanya mula berfungsi seperti sebelum ini - dengan sifar IOWAIT.

Sumber: www.habr.com