Çok fazla boş RAM, NVMe Intel P4500 ve her şey son derece yavaş - başarısız bir takas bölümünün eklenmesinin hikayesi

Bu yazımda yakın zamanda VPS bulutumuzdaki sunuculardan birinde meydana gelen ve beni saatlerce şaşkına çeviren bir durumdan bahsedeceğim. Yaklaşık 15 yıldır Linux sunucularını yapılandırıyor ve sorunlarını gideriyorum, ancak bu durum benim uygulamalarıma hiç uymuyor - birkaç yanlış varsayımda bulundum ve sorunun nedenini doğru bir şekilde belirleyip çözemeden biraz umutsuzluğa kapıldım. .

önsöz

Aşağıdaki yapılandırmaya sahip standart sunucular üzerine oluşturduğumuz orta büyüklükte bir bulutu işletiyoruz: 32 çekirdek, 256 GB RAM ve 4500 TB PCI-E Intel P4 NVMe sürücü. Bu yapılandırmayı gerçekten seviyoruz çünkü VM bulut sunucusu türü düzeyinde doğru kısıtlamayı sağlayarak GÇ ek yükü konusunda endişelenme ihtiyacını ortadan kaldırıyor. Çünkü NVMe Intel P4500 Etkileyici bir performansa sahip olduğundan, aynı anda hem makinelere tam IOPS provizyonu hem de sıfır IOWAIT ile bir yedekleme sunucusuna yedekleme depolaması sağlayabiliriz.

VM hacimlerini depolamak için hiper birleşik SDN ve diğer şık, modaya uygun, gençlik şeylerini kullanmayan eski inananlardan biriyiz; sistem ne kadar basit olursa, "ana guru gitti" koşullarında sorun gidermenin o kadar kolay olacağına inanıyoruz. dağlara." Sonuç olarak, VM birimlerini QCOW2 formatında, LVM4'nin üzerine dağıtılan XFS veya EXT2'te saklıyoruz.

Ayrıca düzenleme için kullandığımız ürün olan Apache CloudStack nedeniyle QCOW2'yi kullanmak zorunda kalıyoruz.

Yedekleme gerçekleştirmek için birimin tam görüntüsünü LVM2 anlık görüntüsü olarak alıyoruz (evet, LVM2 anlık görüntülerinin yavaş olduğunu biliyoruz, ancak Intel P4500 de bize bu konuda yardımcı oluyor). Yaparız lvmcreate -s .. ve yardımı ile dd yedek kopyayı ZFS depolama alanına sahip uzak bir sunucuya gönderiyoruz. Burada hala biraz ilerleme kaydediyoruz - sonuçta ZFS, verileri sıkıştırılmış biçimde saklayabilir ve bunu kullanarak hızlı bir şekilde geri yükleyebiliriz. DD veya kullanarak bireysel VM birimlerini alın mount -o loop ....

Elbette LVM2 biriminin tam görüntüsünü kaldıramazsınız ancak dosya sistemini RO ve QCOW2 görüntülerini kendileri kopyalayın, ancak XFS'nin bundan dolayı kötüleştiği gerçeğiyle karşı karşıya kaldık, hem de hemen değil, öngörülemeyen bir şekilde. Hipervizör ana bilgisayarların hafta sonları, geceleri veya tatil günlerinde, ne zaman olacağı belli olmayan hatalar nedeniyle aniden "yapışmasından" gerçekten hoşlanmıyoruz. Bu nedenle, XFS için anlık görüntü montajını kullanmıyoruz. RO Birimleri çıkarmak için LVM2 biriminin tamamını kopyalamanız yeterlidir.

Yedekleme sunucusuna yedekleme hızı, bizim durumumuzda, sıkıştırılamaz veriler için yaklaşık 600-800 MB/s olan yedekleme sunucusunun performansına göre belirlenir; başka bir sınırlayıcı, yedekleme sunucusunun bağlı olduğu 10 Gbit/s kanaldır. kümeye.

Bu durumda, 8 hipervizör sunucusunun yedek kopyaları aynı anda bir yedekleme sunucusuna yüklenir. Bu nedenle, yedekleme sunucusunun disk ve ağ alt sistemleri, daha yavaş olduğundan, hipervizör ana bilgisayarlarının disk alt sistemlerinin aşırı yüklenmesine izin vermez, çünkü hipervizör ana bilgisayarlarının kolayca işleyebileceği, örneğin 8 GB/sn'yi işleyemezler. üretmek.

Yukarıdaki kopyalama işlemi, ayrıntılar da dahil olmak üzere sonraki hikaye için çok önemlidir - hızlı bir Intel P4500 sürücüsü kullanmak, NFS kullanmak ve muhtemelen ZFS kullanmak.

Yedekleme hikayesi

Her hipervizör düğümünde 8 GB boyutunda küçük bir SWAP bölümümüz var ve hipervizör düğümünün kendisini şunu kullanarak "yayıyoruz": DD referans görselinden. Sunuculardaki sistem birimi için LSI veya HP donanım denetleyicisinde 2xSATA SSD RAID1 veya 2xSAS HDD RAID1 kullanıyoruz. Genel olarak, sistem birimimiz SWAP dışında "neredeyse salt okunur" modda çalıştığı için içeride ne olduğu hiç umurumuzda değil. Ve sunucumuzda çok fazla RAM olduğu ve %30-40 oranında ücretsiz olduğu için SWAP'ı düşünmüyoruz.

Yedekleme işlemi. Bu görev şuna benzer:

#!/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

Not ionice -c3Aslında bu şey NVMe cihazları için tamamen işe yaramaz çünkü onlar için GÇ zamanlayıcı şu şekilde ayarlanmıştır:

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

Bununla birlikte, geleneksel SSD RAID'lere sahip bir dizi eski düğümümüz var; bu onlar için önemli olduğundan hareket ediyorlar OLDUĞU GİBİ. Genel olarak, bu sadece yararsızlığı açıklayan ilginç bir kod parçasıdır. ionice böyle bir konfigürasyon durumunda.

Bayrağa dikkat edin iflag=direct için DD. Okuma sırasında GÇ arabelleklerinin gereksiz yere değiştirilmesini önlemek için arabellek önbelleğini atlayarak doğrudan GÇ kullanıyoruz. Fakat, oflag=direct bunu yapmıyoruz çünkü ZFS'yi kullanırken performans sorunlarıyla karşılaştık.

Bu planı birkaç yıldır sorunsuz bir şekilde başarıyla kullanıyoruz.

Ve sonra başladı... Düğümlerden birinin artık yedeklenmediğini ve öncekinin %50 gibi korkunç bir IOWAIT ile çalıştığını keşfettik. Kopyalamanın neden gerçekleşmediğini anlamaya çalışırken aşağıdaki olayla karşılaştık:

Volume group "images" not found

“Intel P4500'ün sonu geldi” diye düşünmeye başladık ancak sürücüyü değiştirmek için sunucuyu kapatmadan önce yine de yedekleme yapmak gerekiyordu. LVM2 yedeklemesinden meta verileri geri yükleyerek LVM2'yi düzelttik:

vgcfgrestore images

Bir yedekleme başlattık ve şu yağlı boya tabloyu gördük:

Yine çok üzüldük; bu şekilde yaşayamayacağımız açıktı, çünkü tüm VPS'ler acı çekecek, bu da bizim de acı çekeceğimiz anlamına geliyor. Ne olduğu tamamen belirsiz - iostat acınası IOPS ve en yüksek IOWAIT gösterdi. "Hadi NVMe'yi değiştirelim" dışında bir fikir yoktu ancak tam zamanında bir fikir ortaya çıktı.

Durumun adım adım analizi

Tarihsel dergi. Birkaç gün önce bu sunucuda 128 GB RAM'e sahip büyük bir VPS oluşturmak gerekiyordu. Yeterli bellek var gibi görünüyordu, ancak güvenli tarafta olmak adına takas bölümü için 32 GB daha ayırdık. VPS oluşturuldu, görevi başarıyla tamamlandı ve olay unutuldu ancak SWAP bölümü kaldı.

Yapılandırma Özellikleri. Tüm bulut sunucuları için parametre vm.swappiness varsayılan olarak ayarlandı 60. Ve SWAP, SAS HDD RAID1'de oluşturuldu.

Ne oldu (editörlere göre). Yedeklerken DD NFS'ye yazılmadan önce RAM arabelleklerine yerleştirilen çok sayıda yazma verisi üretti. Politika tarafından yönlendirilen sistem çekirdeği swappiness, birçok VPS belleği sayfasını yavaş bir HDD RAID1 biriminde bulunan takas alanına taşıyordu. Bu, IOWAIT'in çok güçlü bir şekilde büyümesine yol açtı, ancak IO NVMe nedeniyle değil, IO HDD RAID1 nedeniyle.

Sorun nasıl çözüldü. 32GB takas bölümü devre dışı bırakıldı. Bu 16 saat sürdü; SWAP'ın nasıl ve neden bu kadar yavaş kapandığını ayrı ayrı okuyabilirsiniz. Ayarlar değiştirildi swappiness eşit bir değere 5 bulutun her yerinde.

Bu nasıl olmaz?. Birincisi, SWAP bir SSD RAID veya NVMe cihazındaysa ve ikinci olarak, NVMe cihazı yoksa, ancak bu kadar veri hacmi üretmeyecek daha yavaş bir cihaz varsa, ironik bir şekilde, sorun NVMe'nin çok hızlı olmasından kaynaklanıyordu.

Bundan sonra her şey eskisi gibi sıfır IOWAIT ile çalışmaya başladı.

Kaynak: habr.com