Delen via

Uw Virtuele Linux-machine optimaliseren in Azure

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

Benodigdheden

In dit onderwerp wordt ervan uitgegaan dat u al een werkend Azure-abonnement hebt (gratis proefregistratie) en dat u al een virtuele machine hebt ingericht in uw Azure-abonnement. Zorg ervoor dat je de nieuwste Azure CLI hebt geïnstalleerd en bent aangemeld bij je Azure-abonnement met az login voordat je een VM maakt.

Azure OS Disk

Wanneer u een Virtuele Linux-machine in Azure hebt gemaakt, zijn er twee schijven aan gekoppeld. /dev/sda- uw besturingssysteemschijf is, /dev/sdb uw tijdelijke schijf is. Gebruik niet de hoofdschijf van het besturingssysteem (/dev/sda) voor alles behalve het besturingssysteem omdat deze is geoptimaliseerd voor snelle VM-opstarttijd en biedt geen goede prestaties voor uw workloads. U wilt een of meer schijven koppelen aan uw virtuele machine 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 G-serie machine , elk tot 32 TB groot. U voegt extra schijven toe wanneer dat nodig is op basis van uw behoeften aan opslagruimte 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 I/O-prestaties wilt bereiken op Premium-opslag schijven waar de cache-instellingen zijn ingesteld op ReadOnly of None, moet u barrières uitschakelen tijdens het koppelen van het bestandssysteem in Linux. U hebt geen obstakels nodig omdat de schrijfbewerkingen naar schijven met Premium Storage-ondersteuning duurzaam zijn voor deze cache-instellingen.

  • Als u reiserFSgebruikt, schakelt u barrières uit met behulp van de koppelingsoptie barrier=none (voor het inschakelen van barrières gebruikt u barrier=flush)
  • Als u ext3/ext4-gebruikt, schakelt u barrières uit met behulp van de koppelingsoptie barrier=0 (Gebruik barrier=1voor het inschakelen van barrières )
  • Als u XFS-gebruikt, schakelt u barrières uit met behulp van de koppelingsoptie nobarrier (voor het inschakelen van barrières gebruikt u de optie barrier)

Overwegingen voor niet-beheerde opslagaccounts

De standaardactie wanneer u een virtuele machine met de Azure CLI maakt, 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. Onbeheerde schijven vereisen een opslagaccount en hebben enkele aanvullende prestatieoverwegingen. Zie overzicht van Azure Managed Disksvoor meer informatie over beheerde schijven. In de volgende sectie worden prestatieoverwegingen alleen beschreven wanneer u niet-beheerde schijven gebruikt. Ook hier is de standaard- en aanbevolen opslagoplossing het gebruik van beheerde schijven.

Als u een virtuele machine met niet-beheerde schijven maakt, moet u ervoor zorgen dat u schijven koppelt vanuit opslagaccounts die zich in dezelfde regio bevinden als uw virtuele machine, 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 werkt tot ongeveer 40 intensief gebruikte schijven, waaronder zowel de besturingssysteemschijf als alle gegevensschijven die u maakt. Voor Premium Storage-accounts is er geen maximale IOps-limiet, maar er is een limiet van 32 TB.

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

Uw VM-tijdelijke station

Wanneer u een virtuele machine maakt, beschikt Azure standaard over een besturingssysteemschijf (/dev/sda) en een tijdelijke schijf (/dev/sdb-). Alle extra schijven die u toevoegt, worden weergegeven als /dev/sdc, /dev/sdd, /dev/sde enzovoort. Alle gegevens op uw tijdelijke schijf (/dev/sdb) zijn niet duurzaam en kunnen verloren gaan als specifieke gebeurtenissen, zoals het wijzigen van het formaat van de VM, het opnieuw implementeren of onderhoud, het opnieuw opstarten van uw virtuele machine afdwingt. De grootte en het type van uw tijdelijke schijf zijn gerelateerd aan de VM-grootte die u tijdens de implementatie hebt gekozen. Alle VM's met een premium-grootte (DS, G en DS_V2 serie) hebben een tijdelijke schijf ondersteund door een lokale SSD voor extra prestaties tot maximaal 48.000 IOps.

Linux-wisselpartitie

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

U kunt het bestand /etc/waagent.conf niet gebruiken om swap te beheren voor alle images die zijn geconfigureerd en ondersteund door cloud-init. Zie Het gebruik van cloud-initvoor de volledige lijst met afbeeldingen.

De eenvoudigste manier om swap voor deze afbeeldingen te beheren, is door deze 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 behoeften 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 uit direct na de laatste stap:

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

Voor installatiekopieën zonder cloud-init-ondersteuning hebben VM-installatiekopieën die zijn geïmplementeerd vanuit Azure Marketplace een VM Linux-agent die is geïntegreerd in het besturingssysteem. Met deze agent kan de VIRTUELE machine communiceren met verschillende Azure-services. Ervan uitgaande dat u een standaardinstallatiekopie hebt geïmplementeerd vanuit 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 speciaal wisselbestand en de grootte van het wisselbestand. De parameters die u moet controleren, zijn ResourceDisk.EnableSwap en ResourceDisk.SwapSizeMB

Als u een correct ingeschakelde schijf en gekoppeld wisselbestand wilt inschakelen, moet u ervoor zorgen dat de parameters de volgende instellingen hebben:

  • ResourceDisk.EnableSwap=Y
  • ResourceDisk.SwapSizeMB={hoeveelheid in MB die aan uw behoeften voldoet}

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 gemaakt wanneer u de opdracht free gebruikt om vrije ruimte weer te geven. In het volgende voorbeeld is een 512 MB-wisselbestand 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-planningsalgoritmen voor Premium Storage

Met de Linux-kernel 2.6.18 is het standaard I/O-planningsalgoritmen gewijzigd van Deadline in CFQ (Volledig eerlijk wachtrij-algoritme). Voor I/O-patronen voor willekeurige toegang is er een verwaarloosbaar verschil in prestatieverschillen tussen CFQ en Deadline. Voor schijven op basis van SSD waarbij het I/O-schijfpatroon voornamelijk opeenvolgend is, kan het overschakelen naar het NOOP- of Deadline-algoritme betere I/O-prestaties bereiken.

De huidige I/O-planner 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 toepassen van deze instelling alleen voor /dev/sda is niet nuttig. Ingesteld op alle gegevensschijven waar sequentiële I/O het I/O-patroon overheerst.

U ziet de volgende uitvoer, die aangeeft dat grub.cfg is herbouwd en dat de standaardplanner 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 Azure-afgestemde kernel maakt gebruik van I/O-planners met meerdere wachtrijen. In dat scenario is none de juiste selectie in plaats van noop. Zie Ubuntu I/O Schedulersvoor meer informatie.

Software RAID gebruiken om hogere I/Ops te bereiken

Als uw workloads meer IOps nodig hebben dan één schijf kan bieden, moet u een software-RAID-configuratie van meerdere schijven gebruiken. Omdat Azure al schijftolerantie uitvoert op de lokale infrastructuurlaag, bereikt u het hoogste prestatieniveau van een RAID-0-stripingconfiguratie. Voorzie en creëer schijven in de Azure-omgeving en bevestig ze aan uw Linux-VM, voordat u de drives partitioneert, formatteert 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 op Linux.

Als alternatief voor een traditionele RAID-configuratie kunt u er ook voor kiezen om LVM (Logical Volume Manager) te installeren om een aantal fysieke schijven te configureren in één gestreept logisch opslagvolume. In deze configuratie worden lees- en schrijfbewerkingen gedistribueerd naar meerdere schijven in de volumegroep (vergelijkbaar met RAID0). Om prestatieredenen wilt u waarschijnlijk uw logische volumes stripen, zodat lees- en schrijfbewerkingen 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 de LVM configureren op een Virtuele Linux-machine in Azure document.

Volgende stappen

Zoals bij alle optimalisatiediscussies moet u tests uitvoeren voor 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 een configuratie werkt, werkt mogelijk niet voor anderen.

Enkele nuttige koppelingen naar aanvullende bronnen:

  • Last updated on