Banyak RAM kosong, NVMe Intel P4500 dan semuanya sangat lambat - kisah penambahan partisi swap yang gagal

Pada artikel ini, saya akan berbicara tentang situasi yang baru-baru ini terjadi pada salah satu server di cloud VPS kami, yang membuat saya bingung selama beberapa jam. Saya telah mengonfigurasi dan memecahkan masalah server Linux selama sekitar 15 tahun, tetapi kasus ini sama sekali tidak sesuai dengan praktik saya - saya membuat beberapa asumsi yang salah dan menjadi sedikit putus asa sebelum saya dapat menentukan dengan benar penyebab masalah dan menyelesaikannya. .

Preamble

Kami mengoperasikan cloud berukuran sedang, yang kami bangun di server standar dengan konfigurasi berikut - 32 core, RAM 256 GB, dan drive PCI-E Intel P4500 NVMe 4 TB. Kami sangat menyukai konfigurasi ini karena menghilangkan kebutuhan akan overhead IO dengan memberikan batasan yang benar pada tingkat jenis instance VM. Karena NVMe Intel P4500 memiliki kinerja yang mengesankan, kami secara bersamaan dapat menyediakan penyediaan IOPS penuh ke mesin dan penyimpanan cadangan ke server cadangan tanpa IOWAIT.

Kami adalah salah satu dari orang-orang percaya lama yang tidak menggunakan SDN hyperconverged dan barang-barang muda lainnya yang bergaya dan modis untuk menyimpan volume VM, percaya bahwa semakin sederhana sistemnya, semakin mudah untuk memecahkan masalah dalam kondisi “guru utama telah pergi ke pegunungan." Hasilnya, kami menyimpan volume VM dalam format QCOW2 di XFS atau EXT4, yang diterapkan di atas LVM2.

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

Untuk melakukan pencadangan, kami mengambil gambar penuh volume sebagai snapshot LVM2 (ya, kami tahu bahwa snapshot LVM2 lambat, tetapi Intel P4500 juga membantu kami dalam hal ini). Kami melakukannya lvmcreate -s .. dan dengan bantuan dd kami mengirim salinan cadangan ke server jauh dengan penyimpanan ZFS. Di sini kami masih sedikit progresif - lagi pula, ZFS dapat menyimpan data dalam bentuk terkompresi, dan kami dapat memulihkannya dengan cepat menggunakan DD atau dapatkan volume VM individual menggunakan mount -o loop ....

Tentu saja Anda tidak dapat menghapus gambar penuh dari volume LVM2, tetapi memasang sistem file di RO dan menyalin gambar QCOW2 itu sendiri, namun, kami dihadapkan pada kenyataan bahwa XFS menjadi buruk karenanya, dan tidak segera, tetapi dengan cara yang tidak dapat diprediksi. Kami sangat tidak suka jika host hypervisor “menempel” secara tiba-tiba di akhir pekan, malam hari, atau hari libur karena kesalahan yang tidak jelas kapan akan terjadi. Oleh karena itu, untuk XFS kami tidak menggunakan snapshot mount RO untuk mengekstrak volume, kita cukup menyalin seluruh volume LVM2.

Kecepatan pencadangan ke server pencadangan dalam kasus kami ditentukan oleh kinerja server pencadangan, yaitu sekitar 600-800 MB/dtk untuk data yang tidak dapat dimampatkan; pembatas selanjutnya adalah saluran 10Gbit/dtk yang terhubung dengan server pencadangan. ke cluster.

Dalam hal ini, salinan cadangan dari 8 server hypervisor diunggah secara bersamaan ke satu server cadangan. Dengan demikian, subsistem disk dan jaringan dari server cadangan, karena lebih lambat, tidak memungkinkan subsistem disk dari host hypervisor kelebihan beban, karena mereka tidak mampu memproses, katakanlah, 8 GB/detik, yang mana host hypervisor dapat dengan mudah menghasilkan.

Proses penyalinan di atas sangat penting untuk cerita selanjutnya, termasuk detailnya - menggunakan drive Intel P4500 yang cepat, menggunakan NFS dan, mungkin, menggunakan ZFS.

Cerita cadangan

Pada setiap node hypervisor kami memiliki partisi SWAP kecil berukuran 8 GB, dan kami “meluncurkan” node hypervisor itu sendiri menggunakan DD dari gambar referensi. Untuk volume sistem di server, kami menggunakan 2xSATA SSD RAID1 atau 2xSAS HDD RAID1 pada LSI atau pengontrol perangkat keras HP. Secara umum, kami tidak peduli sama sekali apa yang ada di dalamnya, karena volume sistem kami beroperasi dalam mode “hampir hanya dapat dibaca”, kecuali untuk SWAP. Dan karena kami memiliki banyak RAM di server dan gratis 30-40%, kami tidak memikirkan SWAP.

Proses pencadangan. Tugas ini terlihat 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

Perhatikan ionice -c3, sebenarnya, hal ini sama sekali tidak berguna untuk perangkat NVMe, karena penjadwal IO untuk perangkat tersebut disetel sebagai:

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

Namun, kami memiliki sejumlah node lama dengan RAID SSD konvensional, bagi mereka hal ini relevan, sehingga mereka dipindahkan DENGAN ADANYA. Secara keseluruhan, ini hanyalah sepotong kode menarik yang menjelaskan kesia-siaannya ionice dalam hal konfigurasi seperti itu.

Perhatikan benderanya iflag=direct untuk DD. Kami menggunakan IO langsung dengan melewati cache buffer untuk menghindari penggantian buffer IO yang tidak perlu saat membaca. Namun, oflag=direct kami tidak melakukannya karena kami mengalami masalah kinerja ZFS saat menggunakannya.

Kami telah berhasil menggunakan skema ini selama beberapa tahun tanpa masalah.

Dan kemudian itu dimulai... Kami menemukan bahwa salah satu node tidak lagi dicadangkan, dan node sebelumnya berjalan dengan IOWAIT yang sangat besar sebesar 50%. Saat mencoba memahami mengapa penyalinan tidak terjadi, kami menemui fenomena berikut:

Volume group "images" not found

Kami mulai berpikir tentang “akhir dari Intel P4500 telah tiba,” namun, sebelum mematikan server untuk mengganti drive, kami masih perlu melakukan pencadangan. Kami memperbaiki LVM2 dengan memulihkan metadata dari cadangan LVM2:

vgcfgrestore images

Kami meluncurkan cadangan dan melihat lukisan cat minyak ini:

Sekali lagi kami sangat sedih - jelas bahwa kami tidak dapat hidup seperti ini, karena semua VPS akan menderita, yang berarti kami juga akan menderita. Apa yang terjadi sama sekali tidak jelas - iostat menunjukkan IOPS yang menyedihkan dan IOWAIT tertinggi. Tidak ada ide selain “mari kita ganti NVMe”, namun sebuah wawasan muncul tepat pada waktunya.

Analisis situasi langkah demi langkah

Majalah sejarah. Beberapa hari sebelumnya, di server ini perlu dibuat VPS besar dengan RAM 128 GB. Tampaknya ada cukup memori, tetapi untuk amannya, kami mengalokasikan 32 GB lagi untuk partisi swap. VPS telah dibuat, berhasil menyelesaikan tugasnya dan kejadian tersebut terlupakan, namun partisi SWAP tetap ada.

Fitur Konfigurasi. Untuk semua server cloud, parameternya vm.swappiness telah disetel ke default 60. Dan SWAP dibuat pada SAS HDD RAID1.

Apa yang terjadi (menurut redaksi). Saat membuat cadangan DD menghasilkan banyak data tulis, yang ditempatkan di buffer RAM sebelum ditulis ke NFS. Inti sistem, dipandu oleh kebijakan swappiness, memindahkan banyak halaman memori VPS ke area swap, yang terletak pada volume HDD RAID1 yang lambat. Hal ini menyebabkan IOWAIT tumbuh sangat kuat, namun bukan karena IO NVMe, namun karena IO HDD RAID1.

Bagaimana masalahnya diselesaikan. Partisi swap 32GB dinonaktifkan. Ini memakan waktu 16 jam; Anda dapat membaca secara terpisah tentang bagaimana dan mengapa SWAP mati begitu lambat. Pengaturan telah diubah swappiness ke nilai yang sama dengan 5 seluruh awan.

Bagaimana ini tidak terjadi?. Pertama, jika SWAP berada pada perangkat SSD RAID atau NVMe, dan kedua, jika tidak ada perangkat NVMe, tetapi perangkat lebih lambat yang tidak menghasilkan data sebanyak itu - ironisnya, masalah terjadi karena NVMe tersebut terlalu cepat.

Setelah itu, semuanya mulai berfungsi seperti sebelumnya - dengan nol IOWAIT.

Sumber: www.habr.com