Optymalizowanie maszyny wirtualnej systemu Linux na platformie Azure
Tworzenie maszyny wirtualnej z systemem Linux jest łatwe do utworzenia z wiersza polecenia lub z portalu. W tym samouczku pokazano, jak upewnić się, że został on ustawiony w celu zoptymalizowania wydajności na Microsoft Azure platformie. W tym temacie użyto maszyny wirtualnej z systemem Ubuntu Server, ale można również utworzyć maszynę wirtualną z systemem Linux przy użyciu własnych obrazów jako szablonów.
Wymagania wstępne
W tym temacie założono, że masz już roboczą subskrypcję platformy Azure (rejestracja w bezpłatnej wersji próbnej) i że maszyna wirtualna została już aprowizowana w ramach subskrypcji platformy Azure. Przed utworzeniem maszyny wirtualnej upewnij się, że masz zainstalowany najnowszy interfejs wiersza polecenia platformy Azure i zalogowano się do subskrypcji platformy Azure za pomocą poleceniaaz login.
Dysk systemu operacyjnego platformy Azure
Po utworzeniu maszyny wirtualnej z systemem Linux na platformie Azure są z nią skojarzone dwa dyski. /dev/sda to dysk systemu operacyjnego, a /dev/sdb to dysk tymczasowy. Nie używaj głównego dysku systemu operacyjnego (/dev/sda) dla żadnych innych dysków oprócz systemu operacyjnego, ponieważ jest on zoptymalizowany pod kątem szybkiego czasu rozruchu maszyny wirtualnej i nie zapewnia dobrej wydajności dla obciążeń. Chcesz dołączyć co najmniej jeden dysk do maszyny wirtualnej, aby uzyskać trwały i zoptymalizowany magazyn dla danych.
Dodawanie dysków dla docelowych rozmiarów i wydajności
W zależności od rozmiaru maszyny wirtualnej można dołączyć do 16 dodatkowych dysków w serii A, 32 dyski w serii D i 64 dyski na maszynie z serii G — każdy o rozmiarze do 32 TB. W razie potrzeby dodasz dodatkowe dyski zgodnie z wymaganiami w zakresie miejsca i we/wy na sekundę. Każdy dysk ma cel wydajności 500 IOps dla standardowego Storage i do 20 000 IOps na dysk dla Premium Storage.
Aby osiągnąć najwyższą liczbę IOps na dyskach Premium Storage, gdzie ich ustawienia pamięci podręcznej zostały ustawione na tylko do odczytu lub brak, należy wyłączyć bariery podczas instalacji systemu plików w systemie Linux. Nie potrzebujesz barier, ponieważ zapisu na dyskach Premium Storage są trwałe dla tych ustawień pamięci podręcznej.
- Jeśli używasz systemu plików reiserFS, wyłącz bariery przy użyciu opcji instalacji
barrier=none(aby włączyć bariery, użyj opcjibarrier=flush) - Jeśli używasz rozszerzeń ext3/ext4,
barrier=0wyłącz bariery przy użyciu opcji instalacji (aby włączyć bariery, użyj opcjibarrier=1) - Jeśli używasz systemu plików XFS, wyłącz bariery przy
nobarrierużyciu opcji instalacji (aby włączyć bariery, użyj opcjibarrier)
Zagadnienia dotyczące niezamanagenego konta magazynu
Domyślną akcją podczas tworzenia maszyny wirtualnej przy użyciu interfejsu wiersza polecenia platformy Azure jest użycie usługi Azure Dyski zarządzane. Te dyski są obsługiwane przez platformę Azure i nie wymagają przygotowania ani lokalizacji do ich przechowywania. Dyski niezadawani wymagają konta magazynu i mają pewne dodatkowe zagadnienia dotyczące wydajności. Aby uzyskać więcej informacji o dyskach zarządzanych, zobacz Omówienie usługi Azure Managed Disks. W poniższej sekcji przedstawiono zagadnienia dotyczące wydajności tylko w przypadku używania dysków niezamandowych. Ponownie domyślnym i zalecanym rozwiązaniem magazynu jest użycie dysków zarządzanych.
Jeśli tworzysz maszynę wirtualną z dyskami niezadawanimi, upewnij się, że dołączyć dyski z kont magazynu znajdujących się w tym samym regionie co maszyna wirtualna, aby zapewnić bliskość i zminimalizować opóźnienie sieci. Każde konto magazynu w chmurze w chmurze ma maksymalnie 20 000 i pojemność o rozmiarze 500 TB. Ten limit działa do około 40 intensywnie używanych dysków, w tym dysk systemu operacyjnego i wszystkie dyski danych, które tworzysz. W Premium Storage nie ma limitu maksymalnej liczby IOps, ale 32 TB.
Podczas pracy z dużymi obciążeniami IOps i wybrano standardową liczbę Storage dla dysków, może być konieczne podzielenie dysków na wiele kont magazynu, aby upewnić się, że limit 20 000 IOps dla kont usługi Storage w warstwie Standardowa nie został Storage. Maszyna wirtualna może zawierać kombinację dysków z różnych kont magazynu i typów kont magazynu w celu osiągnięcia optymalnej konfiguracji.
Dysk tymczasowy maszyny wirtualnej
Domyślnie podczas tworzenia maszyny wirtualnej platforma Azure udostępnia dysk systemu operacyjnego (/dev/sda) i dysk tymczasowy (/dev/sdb). Wszystkie dodatkowe dyski, które dodajesz, są wyświetlane jako /dev/sdc, /dev/sdd, /dev/sde i tak dalej. Wszystkie dane na dysku tymczasowym (/dev/sdb) nie są trwałe i mogą zostać utracone, jeśli określone zdarzenia, takie jak zmiana rozmiaru, ponowne uruchomienie lub konserwacja maszyny wirtualnej, mogą zostać utracone. Rozmiar i typ dysku tymczasowego są powiązane z rozmiarem maszyny wirtualnej wybranej podczas wdrażania. Wszystkie maszyny wirtualne o rozmiarze Premium (serii DS, G i DS_V2) dysk tymczasowy jest zapasowy przez lokalny dysk SSD, aby uzyskać dodatkową wydajność do 48 000 we/wy.
Partycja zamiany systemu Linux
Jeśli maszyna wirtualna platformy Azure pochodzi z obrazu z systemem Ubuntu lub CoreOS, możesz użyć funkcji CustomData do wysłania konfiguracji cloud-config do pliku cloud-init. Jeśli został przekazany niestandardowy obraz systemu Linux korzystający z pliku cloud-init, należy również skonfigurować partycje wymiany przy użyciu pliku cloud-init.
Pliku /etc/waagent.conf nie można używać do zarządzania zamianą wszystkich obrazów, które są aprowowane i obsługiwane przez cloud-init. Aby uzyskać pełną listę obrazów, zobacz Using cloud-init (Korzystanie z cloud-init).
Najprostszym sposobem zarządzania zamianą tych obrazów jest ukończenie tych kroków:
W folderze /var/lib/cloud/scripts/per-boot utwórz plik o nazwie create_swapfile.sh:
$ sudo touch /var/lib/cloud/scripts/per-boot/create_swapfile.sh
Dodaj następujące wiersze do pliku:
$ sudo vi /var/lib/cloud/scripts/per-boot/create_swapfile.sh
#!/bin/sh if [ ! -f '/mnt/swapfile' ]; then fallocate --length 2GiB /mnt/swapfile chmod 600 /mnt/swapfile mkswap /mnt/swapfile swapon /mnt/swapfile swapon -a ; fiUwaga
Wartość można zmienić zgodnie z potrzebami i na podstawie dostępnego miejsca na dysku zasobów, które różni się w zależności od używanego rozmiaru maszyny wirtualnej.
Nadaj plikowi plik wykonywalny:
$ sudo chmod +x /var/lib/cloud/scripts/per-boot/create_swapfile.sh
Aby utworzyć plik swapfile, wykonaj skrypt bezpośrednio po ostatnim kroku:
$ sudo /var/lib/cloud/scripts/per-boot/./create_swapfile.sh
W przypadku obrazów bez obsługi cloud-init obrazy maszyn wirtualnych wdrożone z Azure Marketplace mają agenta maszyny wirtualnej z systemem Linux zintegrowanego z systemem operacyjnym. Ten agent umożliwia maszynie wirtualnej interakcję z różnymi usługami platformy Azure. Przy założeniu, że obraz standardowy został wdrożony z poziomu Azure Marketplace, należy wykonać następujące czynności, aby poprawnie skonfigurować ustawienia pliku wymiany systemu Linux:
Znajdź i zmodyfikuj dwa wpisy w pliku /etc/waagent.conf . Kontrolują istnienie dedykowanego pliku wymiany i rozmiar pliku wymiany. Parametry, które należy sprawdzić, to i ResourceDisk.EnableSwapResourceDisk.SwapSizeMB
Aby włączyć prawidłowo włączony dysk i zainstalowany plik wymiany, upewnij się, że parametry mają następujące ustawienia:
- ResourceDisk.EnableSwap=Y
- ResourceDisk.SwapSizeMB={rozmiar w MB spełniający Twoje potrzeby}
Po wymuś zmianę należy ponownie uruchomić usługę waagent lub ponownie uruchomić maszynę wirtualną z systemem Linux, aby odzwierciedlić te zmiany. Wiesz, że zmiany zostały zaimplementowane i plik wymiany został utworzony po użyciu free polecenia w celu wyświetlenia wolnego miejsca. Poniższy przykład zawiera plik wymiany o rozmiarze 512 MB utworzony w wyniku zmodyfikowania pliku waagent.conf :
azuseruser@myVM:~$ free
total used free shared buffers cached
Mem: 3525156 804168 2720988 408 8428 633192
-/+ buffers/cache: 162548 3362608
Swap: 524284 0 524284
Algorytm planowania operacji we/wy dla Premium Storage
W przypadku jądra systemu Linux w wersji 2.6.18 domyślny algorytm planowania we/wy został zmieniony z Deadline na CFQ (całkowicie uczciwy algorytm kolejkowania). W przypadku wzorców we/wy dostępu losowego istnieje niewielka różnica w wydajności między cfq i termin. W przypadku dysków opartych na dyskach SSD, w których wzorzec we/wy dysku jest głównie sekwencyjny, przełączenie z powrotem do algorytmu NOOP lub Deadline może osiągnąć lepszą wydajność we/wy.
Wyświetlanie bieżącego harmonogramu we/wy
Użyj następującego polecenia:
cat /sys/block/sda/queue/scheduler
Zobaczysz następujące dane wyjściowe, które wskazują bieżący harmonogram.
noop [deadline] cfq
Zmiana bieżącego urządzenia (/dev/sda) algorytmu planowania we/wy
Użyj następujących poleceń:
azureuser@myVM:~$ sudo su -
root@myVM:~# echo "noop" >/sys/block/sda/queue/scheduler
root@myVM:~# sed -i 's/GRUB_CMDLINE_LINUX=""/GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=noop"/g' /etc/default/grub
root@myVM:~# update-grub
Uwaga
Stosowanie tego ustawienia tylko dla /dev/sda nie jest przydatne. Ustaw na wszystkich dyskach danych, na których wzorzec we/wy dominuje sekwencyjne we/wy.
Powinny zostać wyświetlony następujące dane wyjściowe, wskazujące, że grub.cfg został pomyślnie ponownie skonfektowana i że domyślny harmonogram został zaktualizowany do NOOP.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.13.0-34-generic
Found initrd image: /boot/initrd.img-3.13.0-34-generic
Found linux image: /boot/vmlinuz-3.13.0-32-generic
Found initrd image: /boot/initrd.img-3.13.0-32-generic
Found memtest86+ image: /memtest86+.elf
Found memtest86+ image: /memtest86+.bin
done
W przypadku rodziny dystrybucji Red Hat potrzebne jest tylko następujące polecenie:
echo 'echo noop >/sys/block/sda/queue/scheduler' >> /etc/rc.local
System Ubuntu 18.04 z jądrem dostosowanym do platformy Azure używa harmonogramów we/wy z wieloma kolejkami. W tym scenariuszu jest none to odpowiedni wybór zamiast noop. Aby uzyskać więcej informacji, zobacz Ubuntu I/O Schedulers (Harmonogramy we/wy systemu Ubuntu).
Korzystanie z programowej macierzy RAID w celu osiągnięcia większej wartości we/wy
Jeśli obciążenia wymagają większej liczby IOps niż jeden dysk może zapewnić, należy użyć konfiguracji RAID oprogramowania wielu dysków. Ponieważ platforma Azure już zapewnia odporność dysku w lokalnej warstwie sieci szkieletowej, można osiągnąć najwyższy poziom wydajności dzięki konfiguracji rozsyłania RAID-0. Aprowizowanie i tworzenie dysków w środowisku platformy Azure oraz dołączanie ich do maszyny wirtualnej z systemem Linux przed partycjonowaniem, formatowaniem i instalowaniem dysków. Więcej szczegółów na temat konfigurowania programowej konfiguracji RAID na maszynie wirtualnej z systemem Linux na platformie Azure można znaleźć w dokumencie Configuring Software RAID on Linux (Konfigurowanie programowej macierzy RAID w systemie Linux ).
Alternatywą dla tradycyjnej konfiguracji RAID jest zainstalowanie Menedżera woluminów logicznych (LVM) w celu skonfigurowania wielu dysków fizycznych w jednym woluminie magazynu logicznego rozłożonego. W tej konfiguracji odczyty i zapis są dystrybuowane do wielu dysków zawartych w grupie woluminów (podobnie jak RAID0). Ze względu na wydajność prawdopodobnie będziesz chcieć rozłożone woluminy logiczne, aby operacje odczytu i zapisu wykorzystywały wszystkie dołączone dyski danych. Więcej szczegółów na temat konfigurowania rozłożonego woluminu logicznego na maszynie wirtualnej z systemem Linux na platformie Azure można znaleźć w dokumencie Configure LVM on a Linux VM in Azure (Konfigurowanie maszyny wirtualnej LVM na maszynie wirtualnej z systemem Linux na platformie Azure ).
Następne kroki
Należy pamiętać, że podobnie jak w przypadku wszystkich dyskusji na temat optymalizacji, należy wykonać testy przed i po każdej zmianie, aby zmierzyć wpływ zmiany. Optymalizacja to proces krok po kroku, który ma różne wyniki na różnych maszynach w środowisku. To, co działa w przypadku jednej konfiguracji, może nie działać dla innych.
Kilka przydatnych linków do dodatkowych zasobów: