Delen via

Uw Linux-VM optimaliseren voor Azure

  • Artikel

Het maken van een virtuele Linux-machine (VM) is eenvoudig te doen vanaf de opdrachtregel of vanuit de portal. Deze zelfstudie laat zien hoe u ervoor kunt zorgen dat u deze hebt ingesteld om de prestaties op het Microsoft Azure optimaliseren. In dit onderwerp wordt gebruikgemaakt van een Ubuntu Server-VM, maar u kunt ook een virtuele Linux-machine maken met behulp van uw eigen installatieversies als sjablonen.

Vereisten

In dit onderwerp wordt ervan uitgenomen dat u al een werkend Azure-abonnement hebt (aanmelden voor een gratis proefversie) en dat u al een VM hebt ingericht in uw Azure-abonnement. Zorg ervoor dat u de meest recente Versie van Azure CLI hebt geïnstalleerd en aangemeld bij uw Azure-abonnement met az login voordat u een VM maakt.

Azure-besturingssysteemschijf

Wanneer u een virtuele Linux-VM in Azure maakt, zijn er twee schijven aan gekoppeld. /dev/sda is uw besturingssysteemschijf, /dev/sdb is uw tijdelijke schijf. Gebruik de hoofdbesturingssysteemschijf (/dev/sda) voor niets behalve het besturingssysteem, omdat deze is geoptimaliseerd voor snelle opstarttijd van de VM en geen goede prestaties biedt voor uw workloads. U wilt een of meer schijven aan uw VM koppelen om permanente en geoptimaliseerde opslag voor uw gegevens te krijgen.

Schijven toevoegen voor grootte- en prestatiedoelen

Op basis van de VM-grootte kunt u maximaal 16 extra schijven koppelen op een A-serie, 32 schijven op een D-serie en 64 schijven op een machine uit de G-serie, elk tot 32 TB groot. U voegt naar behoefte extra schijven toe volgens uw vereisten voor ruimte en IOps. Elke schijf heeft een prestatiedoel van 500 IOps voor Standard Storage en maximaal 20.000 IOps per schijf voor Premium Storage.

Als u de hoogste IOps wilt bereiken op Premium Storage schijven waarop de cache-instellingen zijn ingesteld op ReadOnly of Geen, moet u barrières uitschakelen tijdens het aanmaken van het bestandssysteem in Linux. U hebt geen barrières nodig omdat de schrijf-Premium Storage back-schijven duurzaam zijn voor deze cache-instellingen.

  • Als u reiserFS gebruikt, schakelt u barrières barrier=none uit met behulp van de optie Voor het inschakelen van barrières, gebruikt u barrier=flush)
  • Als u ext3/ext4 gebruikt, schakelt u barrières barrier=0 uit met behulp van de optie Voor het inschakelen van barrières, gebruikt u barrier=1)
  • Als u XFS gebruikt, schakelt u barrières nobarrier uit met behulp van de optie Voor het inschakelen van barrières, gebruikt u de optie barrier)

Overwegingen voor onmanaged opslagaccount

De standaardactie bij het maken van een VM met de Azure CLI is het gebruik van Azure Managed Disks. Deze schijven worden verwerkt door het Azure-platform en vereisen geen voorbereiding of locatie om ze op te slaan. Voor niet-mande schijven is een opslagaccount vereist en zijn er enkele aanvullende prestatieoverwegingen. Zie voor meer informatie over beheerde schijven overzicht Azure Managed Disks. In de volgende sectie worden alleen prestatieoverwegingen beschreven wanneer u niet-mande schijven gebruikt. De standaard- en aanbevolen opslagoplossing is om beheerde schijven te gebruiken.

Als u een VM met niet-beherende schijven maakt, moet u ervoor zorgen dat u schijven koppelt van opslagaccounts die zich in dezelfde regio bevinden als uw VM om de nabijheid te garanderen en de netwerklatentie te minimaliseren. Elk Standard-opslagaccount heeft maximaal 20.000 IOps en een capaciteit van 500 TB. Deze limiet geldt voor ongeveer 40 intensief gebruikte schijven, inclusief zowel de besturingssysteemschijf als alle gegevensschijven die u maakt. Voor Premium Storage-accounts is er geen maximumlimiet voor IOps, maar is er een limiet van 32 TB.

Wanneer u te maken hebt met hoge IOps-workloads en u Hebt gekozen voor Standard Storage voor uw schijven, moet u mogelijk de schijven splitsen in meerdere opslagaccounts om ervoor te zorgen dat u de limiet van 20.000 IOps voor Standard Storage-accounts niet hebt bereikt. Uw VM kan een combinatie van schijven uit verschillende opslagaccounts en opslagaccounttypen bevatten om uw optimale configuratie te bereiken.

Uw tijdelijke station van de VM

Wanneer u een VM maakt, biedt Azure u standaard een besturingssysteemschijf (/dev/sda) en een tijdelijke schijf (/dev/sdb). Alle extra schijven die u toevoegt, worden als /dev/sdc, /dev/sdd, /dev/sde , en meer. Alle gegevens op uw tijdelijke schijf (/dev/sdb) zijn niet duurzaam en kunnen verloren gaan als specifieke gebeurtenissen, zoals het vergroten of vergroten of juist het formaat, de herindeling of het onderhoud van de VM, het opnieuw opstarten van de VM in de weg staan. De grootte en het type van de tijdelijke schijf zijn gerelateerd aan de VM-grootte die u tijdens de implementatie hebt gekozen. Alle VM's van de premium-grootte (DS-, G- en DS_V2-serie) van het tijdelijke station worden door een lokale SSD gebruikt voor extra prestaties van maximaal 48.000 IOps.

Linux-wisselpartitie

Als uw Azure-VM afkomstig is van een Ubuntu- of CoreOS-installatier, kunt u CustomData gebruiken om een cloud-config te verzenden naar cloud-init. Als u een aangepaste Linux-afbeelding hebt geüpload die gebruikmaakt van cloud-init, configureert u ook swappartities met behulp van cloud-init.

U kunt het bestand /etc/waagent.conf niet gebruiken om wisseling te beheren voor alle afbeeldingen die zijn ingericht en ondersteund door cloud-init. Zie Cloud-init gebruiken voor een volledige lijst met afbeeldingen.

De eenvoudigste manier om het wisselen van deze afbeeldingen te beheren, is door de volgende stappen uit te voeren:

  1. Maak in de map /var/lib/cloud/scripts/per-boot een bestand met de naam create_swapfile.sh:

    $ sudo touch /var/lib/cloud/scripts/per-boot/create_swapfile.sh

  2. Voeg de volgende regels toe aan het bestand:

    $ 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 ; fi

    Notitie

    U kunt de waarde wijzigen op basis van uw behoefte en op basis van de beschikbare ruimte op de resourceschijf, die varieert op basis van de gebruikte VM-grootte.

  3. Maak het bestand uitvoerbaar:

    $ sudo chmod +x /var/lib/cloud/scripts/per-boot/create_swapfile.sh

  4. Als u het wisselbestand wilt maken, voert u het script direct na de laatste stap uit:

    $ sudo /var/lib/cloud/scripts/per-boot/./create_swapfile.sh

Voor afbeeldingen zonder cloud-init-ondersteuning hebben VM-afbeeldingen die zijn geïmplementeerd vanuit de Azure Marketplace VM Linux-agent geïntegreerd met het besturingssysteem. Met deze agent kan de VM communiceren met verschillende Azure-services. Ervan uitgaande dat u een standaardafbeelding hebt geïmplementeerd vanuit de Azure Marketplace, moet u het volgende doen om de instellingen van uw Linux-wisselbestand correct te configureren:

Zoek en wijzig twee vermeldingen in het bestand /etc/waagent.conf . Ze bepalen het bestaan van een toegewezen wisselbestand en de grootte van het wisselbestand. De parameters die u moet controleren, zijn en ResourceDisk.EnableSwapResourceDisk.SwapSizeMB

Zorg ervoor dat de parameters de volgende instellingen hebben om een correct ingeschakelde schijf en een gemonteerd wisselbestand in teschakelen:

  • ResourceDisk.EnableSwap=Y
  • ResourceDisk.SwapSizeMB={grootte in MB om aan uw behoeften te voldoen}

Nadat u de wijziging hebt aangebracht, moet u de waagent opnieuw opstarten of de Linux-VM opnieuw opstarten om deze wijzigingen weer te geven. U weet dat de wijzigingen zijn geïmplementeerd en dat er een wisselbestand is free gemaakt wanneer u de opdracht gebruikt om vrije ruimte weer te geven. In het volgende voorbeeld is een wisselbestand van 512 MB gemaakt als gevolg van het wijzigen van het bestand 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

I/O-planningsalgoritme voor Premium Storage

Met de Linux-kernel 2.6.18 is het standaard I/O-planningsalgoritme gewijzigd van Deadline in CFQ (Volledig fair queuing-algoritme). Voor I/O-patronen voor willekeurige toegang is er een verwaarloosbaar verschil in prestatieverschillen tussen CFQ en Deadline. Voor SSD-schijven waarbij het schijf-I/O-patroon hoofdzakelijk sequentieel is, kunnen betere I/O-prestaties worden bereikt als u terugschakelt naar het algoritme NOOP of Deadline.

De huidige I/O-scheduler weergeven

Gebruik de volgende opdracht:

cat /sys/block/sda/queue/scheduler

U ziet de volgende uitvoer, die de huidige scheduler aangeeft.

noop [deadline] cfq

Het huidige apparaat (/dev/sda) van het I/O-planningsalgoritme wijzigen

Gebruik de volgende opdrachten:

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

Notitie

Het is niet handig om deze instelling alleen toe te passen op /dev/sda . Ingesteld op alle gegevensschijven waarbij sequentiële I/O het I/O-patroon de overgenomen heeft.

Als het goed is, ziet u de volgende uitvoer, waarmee wordt aangegeven dat grub.cfg is hersteld en dat de standaardplanster is bijgewerkt naar 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

Voor de Red Hat-distributiefamilie hebt u alleen de volgende opdracht nodig:

echo 'echo noop >/sys/block/sda/queue/scheduler' >> /etc/rc.local

Ubuntu 18.04 met de op Azure afgestemde kernel maakt gebruik van I/O-schedulers met meerdere wachtrijen. In dat scenario none is de juiste selectie in plaats van noop. Zie Ubuntu I/O Schedulers voor meer informatie.

Software RAID gebruiken om hogere I/Ops te bereiken

Als uw workloads meer IOps vereisen dan één schijf kan bieden, moet u een RAID-softwareconfiguratie van meerdere schijven gebruiken. Omdat Azure al schijf resiliency op de lokale fabriclaag uitvoert, bereikt u het hoogste prestatieniveau met behulp van een RAID-0 striping-configuratie. Schijven inrichten en maken in de Azure-omgeving en deze koppelen aan uw Linux-VM voordat u de stations partitioneert, opmaakt en koppelt. Meer informatie over het configureren van een software-RAID-installatie op uw Linux-VM in Azure vindt u in het document Software RAID configureren in Linux .

Als alternatief voor een traditionele RAID-configuratie kunt u er ook voor kiezen om Logical Volume Manager (LVM) te installeren om een aantal fysieke schijven te configureren in één gestreept logisch opslagvolume. In deze configuratie worden lees- en schrijfgegevens gedistribueerd naar meerdere schijven in de volumegroep (vergelijkbaar met RAID0). Uit prestatieoverwegingen wilt u waarschijnlijk uw logische volumes stripen, zodat lees- en schrijfgegevens gebruikmaken van al uw gekoppelde gegevensschijven. Meer informatie over het configureren van een gestreept logisch volume op uw Linux-VM in Azure vindt u in het document Configure LVM on a Linux VM in Azure (LVM configureren op een Linux-VM in Azure ).

Volgende stappen

Zoals bij alle optimalisatiediscussaties moet u tests uitvoeren vóór en na elke wijziging om de impact van de wijziging te meten. Optimalisatie is een stapsgewijs proces met verschillende resultaten op verschillende computers in uw omgeving. Wat voor de ene configuratie werkt, werkt mogelijk niet voor andere configuraties.

Enkele nuttige koppelingen naar aanvullende bronnen: