Dużo wolnego RAMu, NVMe Intel P4500 i wszystko strasznie wolno - historia nieudanego dodania partycji wymiany

W tym artykule opowiem o sytuacji, która niedawno miała miejsce z jednym z serwerów w naszej chmurze VPS, która wprawiła mnie w zakłopotanie na kilka godzin. Konfiguruję i rozwiązuję problemy z serwerami Linux od około 15 lat, ale ten przypadek w ogóle nie pasuje do mojej praktyki - przyjąłem kilka fałszywych założeń i wpadłem w lekką desperację, zanim udało mi się poprawnie określić przyczynę problemu i go rozwiązać .

Preambuła

Obsługujemy średniej wielkości chmurę, którą budujemy na standardowych serwerach o następującej konfiguracji - 32 rdzenie, 256 GB RAM i dysk PCI-E Intel P4500 NVMe 4 TB. Naprawdę podoba nam się ta konfiguracja, ponieważ eliminuje potrzebę martwienia się o narzut we/wy poprzez zapewnienie prawidłowego ograniczenia na poziomie typu instancji maszyny wirtualnej. Ponieważ NVMe Intel P4500 ma imponującą wydajność, możemy jednocześnie zapewnić zarówno pełne przydzielanie IOPS maszynom, jak i przechowywanie kopii zapasowych na serwerze kopii zapasowych przy zerowym IOWAIT.

Należymy do tych starych wyznawców, którzy nie używają hiperkonwergentnych SDN i innych stylowych, modnych, młodzieżowych rzeczy do przechowywania woluminów VM, wierząc, że im prostszy system, tym łatwiej jest go rozwiązać w warunkach „odszedł główny guru” W góry." W rezultacie przechowujemy woluminy maszyn wirtualnych w formacie QCOW2 w XFS lub EXT4, które są wdrażane na LVM2.

Do korzystania z QCOW2 jesteśmy zmuszeni także przez produkt, którego używamy do orkiestracji - Apache CloudStack.

Aby wykonać kopię zapasową, wykonujemy pełny obraz woluminu w postaci migawki LVM2 (tak, wiemy, że migawki LVM2 są powolne, ale Intel P4500 też nam w tym pomaga). My robimy lvmcreate -s .. i z pomocą dd wysyłamy kopię zapasową na zdalny serwer z pamięcią ZFS. Tutaj nadal jesteśmy lekko postępowi – w końcu ZFS może przechowywać dane w formie skompresowanej, a my możemy je szybko przywrócić za pomocą DD lub uzyskaj indywidualne woluminy maszyn wirtualnych za pomocą mount -o loop ....

Możesz oczywiście usunąć nie pełny obraz woluminu LVM2, ale zamontować system plików w RO i skopiować same obrazy QCOW2, jednak stanęliśmy przed faktem, że XFS stał się z tego powodu zły i to nie od razu, ale w nieprzewidywalny sposób. Bardzo nie lubimy, gdy hosty hypervisorów „zacinają się” nagle w weekendy, w nocy lub w święta z powodu błędów, które nie są jasne, kiedy wystąpią. Dlatego w przypadku XFS nie używamy montażu migawkowego RO aby wyodrębnić woluminy, po prostu kopiujemy cały wolumin LVM2.

Szybkość tworzenia kopii zapasowych na serwerze kopii zapasowych jest w naszym przypadku uzależniona od wydajności serwera kopii zapasowych, która wynosi około 600-800 MB/s dla danych nieskompresowanych; dodatkowym ograniczeniem jest kanał 10Gbit/s, z którym połączony jest serwer kopii zapasowych do klastra.

W tym przypadku kopie zapasowe 8 serwerów hypervisor są jednocześnie przesyłane na jeden serwer zapasowy. Zatem podsystemy dyskowe i sieciowe serwera kopii zapasowych, ponieważ są wolniejsze, nie pozwalają na przeciążenie podsystemów dyskowych hostów hypervisora, ponieważ po prostu nie są one w stanie przetworzyć, powiedzmy, 8 GB/s, co hosty hypervisora ​​mogą z łatwością produkować.

Powyższy proces kopiowania jest bardzo ważny dla dalszej historii, łącznie ze szczegółami - przy użyciu szybkiego dysku Intel P4500, przy użyciu NFS i prawdopodobnie przy użyciu ZFS.

Historia kopii zapasowej

Na każdym węźle hypervisora ​​mamy małą partycję SWAP o rozmiarze 8 GB i „wdrażamy” sam węzeł hypervisora ​​za pomocą DD z obrazu referencyjnego. Do wolumenu systemowego na serwerach używamy 2xSATA SSD RAID1 lub 2xSAS HDD RAID1 na kontrolerze sprzętowym LSI lub HP. Ogólnie rzecz biorąc, nie obchodzi nas w ogóle, co jest w środku, ponieważ nasz wolumin systemowy działa w trybie „prawie tylko do odczytu”, z wyjątkiem SWAP. A ponieważ mamy dużo RAM-u na serwerze i jest on 30-40% darmowy, nie myślimy o SWAP-ie.

Proces tworzenia kopii zapasowych. To zadanie wygląda mniej więcej tak:

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

Zwróć uwagę na ionice -c3w rzeczywistości jest to całkowicie bezużyteczne w przypadku urządzeń NVMe, ponieważ harmonogram IO dla nich jest ustawiony jako:

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

Mamy jednak wiele starszych węzłów z konwencjonalnymi macierzami RAID SSD, dla nich jest to istotne, więc się przenoszą JAK JEST. Ogólnie rzecz biorąc, jest to po prostu interesujący fragment kodu wyjaśniający daremność ionice w przypadku takiej konfiguracji.

Zwróć uwagę na flagę iflag=direct dla DD. Używamy bezpośredniego IO z pominięciem pamięci podręcznej bufora, aby uniknąć niepotrzebnej wymiany buforów IO podczas odczytu. Jednakże, oflag=direct nie robimy tego, ponieważ napotkaliśmy problemy z wydajnością ZFS podczas jego używania.

Stosujemy ten schemat z sukcesem od kilku lat i bez problemów.

I wtedy się zaczęło... Odkryliśmy, że jeden z węzłów nie miał już kopii zapasowej, a poprzedni działał z monstrualnym IOWAIT wynoszącym 50%. Próbując zrozumieć, dlaczego kopiowanie nie występuje, napotkaliśmy następujące zjawisko:

Volume group "images" not found

Zaczęliśmy myśleć o tym, że „nadszedł koniec Intela P4500”, jednak przed wyłączeniem serwera w celu wymiany dysku konieczne było jeszcze wykonanie kopii zapasowej. Naprawiliśmy LVM2, przywracając metadane z kopii zapasowej LVM2:

vgcfgrestore images

Uruchomiliśmy kopię zapasową i zobaczyliśmy ten obraz olejny:

Znów było nam bardzo smutno – było jasne, że nie możemy tak żyć, bo ucierpią na tym wszystkie VPS-y, co oznacza, że ​​i my ucierpimy. To, co się stało, jest całkowicie niejasne - iostat pokazał żałosny IOPS i najwyższy IOWAIT. Nie było innych pomysłów niż „wymieńmy NVMe”, ale pomysł pojawił się w samą porę.

Analiza sytuacji krok po kroku

Magazyn historyczny. Kilka dni wcześniej na tym serwerze trzeba było stworzyć duży VPS ze 128 GB RAM. Wydawało się, że jest wystarczająco dużo pamięci, ale dla bezpieczeństwa przeznaczyliśmy kolejne 32 GB na partycję wymiany. VPS został utworzony, pomyślnie wykonał swoje zadanie i o incydencie zapomniano, ale partycja SWAP pozostała.

Funkcje konfiguracyjne. Dla wszystkich serwerów w chmurze parametr vm.swappiness zostało ustawione jako domyślne 60. A SWAP został stworzony na SAS HDD RAID1.

Co się stało (według redaktorów). Podczas cofania DD wygenerował dużo danych do zapisu, które zostały umieszczone w buforach RAM przed zapisem do NFS. Rdzeń systemu, kierując się polityką swappiness, przenosił wiele stron pamięci VPS do obszaru wymiany, który znajdował się na wolnym wolumenie HDD RAID1. Doprowadziło to do bardzo silnego wzrostu IOWAIT, ale nie z powodu IO NVMe, ale z powodu IO HDD RAID1.

Jak problem został rozwiązany. Partycja wymiany 32 GB została wyłączona. Zajęło to 16 godzin; możesz przeczytać osobno o tym, jak i dlaczego SWAP wyłącza się tak wolno. Ustawienia zostały zmienione swappiness do wartości równej 5 w całej chmurze.

Jak to się nie mogło zdarzyć?. Po pierwsze, gdyby SWAP był na dysku SSD RAID lub urządzeniu NVMe, a po drugie, gdyby nie było urządzenia NVMe, ale wolniejsze urządzenie, które nie generowałoby takiej ilości danych - o ironio, problem pojawił się, ponieważ ten NVMe jest za szybki.

Potem wszystko zaczęło działać jak poprzednio - z zerowym IOWAIT.

Źródło: www.habr.com