Dela via

Optimera din virtuella Linux-dator på Azure

  • Artikel

Det är enkelt att skapa en virtuell Linux-dator (VM) från kommandoraden eller från portalen. Den här självstudien visar hur du ser till att du har ställt in den för att optimera dess prestanda på Microsoft Azure plattformen. Det här avsnittet använder en virtuell Ubuntu Server-dator, men du kan också skapa en virtuell Linux-dator med egna avbildningar som mallar.

Förutsättningar

Det här avsnittet förutsätter att du redan har en fungerande Azure-prenumeration (kostnadsfri utvärderingsversion) och redan har etablerat en virtuell dator i din Azure-prenumeration. Kontrollera att du har installerat och loggat in på azure-prenumerationen med az login innan du skapar en virtuell dator.

Azure OS-disk

När du har skapat en virtuell Linux-dator i Azure har den två diskar som är kopplade till den. /dev/sda är din OS-disk, /dev/sdb är din tillfälliga disk. Använd inte huvudoperativsystemdisken (/dev/sda) för något annat än operativsystemet eftersom den är optimerad för snabb starttid för virtuella datorer och inte ger bra prestanda för dina arbetsbelastningar. Du vill ansluta en eller flera diskar till den virtuella datorn för att få beständig och optimerad lagring för dina data.

Lägga till diskar för storleks- och prestandamål

Baserat på vm-storleken kan du ansluta upp till 16 ytterligare diskar på en A-serie, 32 diskar på en D-serie och 64 diskar på en dator i G-serien , var och en med en storlek på upp till 32 TB. Du lägger till extra diskar efter behov enligt dina utrymmes- och IOps-krav. Varje disk har ett prestandamål på 500 IOps för Standard Storage och upp till 20 000 IOps per disk för Premium Storage.

För att uppnå högsta IOps på Premium Storage diskar där deras cacheinställningar har ställts in på antingen ReadOnly eller None måste du inaktivera barriärer när du monterar filsystemet i Linux. Du behöver inga hinder eftersom skrivningarna till de Premium Storage diskarna är beständiga för dessa cacheinställningar.

  • Om du använder reiserFS inaktiverar du barriärer med monteringsalternativet barrier=none (För att aktivera barriärer använder du barrier=flush)
  • Om du använder ext3/ext4 inaktiverar du barriärer barrier=0 med monteringsalternativet (Använd för att aktivera barriärer barrier=1)
  • Om du använder XFS inaktiverar du barriärer med monteringsalternativet nobarrier (Om du vill aktivera barriärer använder du alternativet barrier)

Överväganden för ohanterade lagringskonto

Standardåtgärden när du skapar en virtuell dator med Azure CLI är att använda Azure Managed Disks. De här diskarna hanteras av Azure-plattformen och kräver ingen förberedelse eller plats för att lagra dem. Ohanterade diskar kräver ett lagringskonto och har några ytterligare prestandaöverväganden. Mer information om hanterade diskar finns i Översikt över Azure Managed Disks. I följande avsnitt beskrivs prestandaöverväganden endast när du använder ohanterade diskar. Återigen är standardlösningen och den rekommenderade lagringslösningen att använda hanterade diskar.

Om du skapar en virtuell dator med ohanterade diskar ska du se till att ansluta diskar från lagringskonton som finns i samma region som den virtuella datorn för att säkerställa närhet och minimera nätverksfördröjningen. Varje Standard-lagringskonto har en kapacitet på högst 20 000 IOps och en storlek på 500 TB. Den här gränsen motsvarar cirka 40 mycket använda diskar, inklusive både OS-disken och alla datadiskar som du skapar. För Premium Storage-konton finns det ingen maximal IOps-gräns, men det finns en storleksgräns på 32 TB.

När du hanterar höga IOps-arbetsbelastningar och du har valt Standard Storage för dina diskar kan du behöva dela upp diskarna på flera lagringskonton för att se till att du inte har kommit upp till gränsen på 20 000 IOps för Standard Storage-konton. Den virtuella datorn kan innehålla en blandning av diskar från olika lagringskonton och lagringskontotyper för att uppnå optimal konfiguration.

Den tillfälliga virtuella datorns enhet

Som standard när du skapar en virtuell dator ger Azure dig en OS-disk (/dev/sda) och en tillfällig disk (/dev/sdb). Alla ytterligare diskar som du lägger till visas som /dev/sdc, /dev/sdd, /dev/sde och så vidare. Alla data på den tillfälliga disken (/dev/sdb) är inte beständiga och kan gå förlorade om specifika händelser som vm-storleksändring, omdistribution eller underhåll tvingar en omstart av den virtuella datorn. Storleken och typen för den tillfälliga disken är relaterad till den VM-storlek som du valde vid distributionen. Alla virtuella datorer i premiumstorlek (DS, G och DS_V2) som den tillfälliga enheten backas upp av en lokal SSD för ytterligare prestanda på upp till 48 000 IOps.

Linux-växlingspartition

Om din virtuella Azure-dator kommer från en Ubuntu- eller CoreOS-avbildning kan du använda CustomData för att skicka en cloud-config till cloud-init. Om du har laddat upp en anpassad Linux-avbildning som använder cloud-init konfigurerar du även växlingspartitioner med hjälp av cloud-init.

Du kan inte använda filen /etc/waagent.conf för att hantera växling för alla avbildningar som har etablerats och stöds av cloud-init. En fullständig lista över avbildningar finns i Använda cloud-init.

Det enklaste sättet att hantera bytet för dessa avbildningar är att utföra följande steg:

  1. I mappen /var/lib/cloud/scripts/per-boot skapar du en fil med namnet create_swapfile.sh:

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

  2. Lägg till följande rader i filen:

    $ 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

    Anteckning

    Du kan ändra värdet efter behov och baserat på det tillgängliga utrymmet på resursdisken, vilket varierar beroende på vilken VM-storlek som används.

  3. Gör filen körbar:

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

  4. Skapa växlingsfilen genom att köra skriptet direkt efter det sista steget:

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

För avbildningar utan stöd för cloud-init har VM-avbildningar som distribuerats från Azure Marketplace linux-agent för virtuella datorer integrerade med operativsystemet. Med den här agenten kan den virtuella datorn interagera med olika Azure-tjänster. Förutsatt att du har distribuerat en standardavbildning från Azure Marketplace måste du göra följande för att konfigurera inställningarna för Linux-växlingsfilen korrekt:

Leta upp och ändra två poster i filen /etc/waagent.conf . De styr förekomsten av en dedikerad växlingsfil och växlingsfilens storlek. De parametrar som du behöver verifiera är och ResourceDisk.EnableSwapResourceDisk.SwapSizeMB

Om du vill aktivera en korrekt aktiverad disk och monterad växlingsfil måste du kontrollera att parametrarna har följande inställningar:

  • ResourceDisk.EnableSwap=Y
  • ResourceDisk.SwapSizeMB={size in MB to meet your needs}

När du har gjort ändringen måste du starta om waagenten eller starta om den virtuella Linux-datorn för att återspegla ändringarna. Du vet att ändringarna har implementerats och att en växlingsfil har skapats när du använder kommandot free för att visa ledigt utrymme. I följande exempel skapas en växlingsfil på 512 MB som ett resultat av att filen waagent.conf har modifierats:

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-schemaläggningsalgoritm för Premium Storage

Med Linux-kerneln 2.6.18 ändrades standardalgoritmen för I/O-schemaläggning från Deadline till CFQ (Helt fair queuing-algoritm). För I/O-mönster för slumpmässig åtkomst finns det minimal skillnad i prestandaskillnaderna mellan CFQ och Deadline. För SSD-baserade diskar där disk-I/O-mönstret främst är sekventiellt kan växling tillbaka till NOOP- eller Deadline-algoritmen uppnå bättre I/O-prestanda.

Visa aktuell I/O-schemaläggare

Ange följande kommando:

cat /sys/block/sda/queue/scheduler

Du ser följande utdata, som visar den aktuella schemaläggaren.

noop [deadline] cfq

Ändra den aktuella enheten (/dev/sda) för I/O-schemaläggningsalgoritmen

Använd följande kommandon:

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

Anteckning

Det är inte användbart att tillämpa den här inställningen enbart för /dev/sda . Ställ in på alla datadiskar där sekventiella I/O-mönster dominerandes.

Du bör se följande utdata som anger att grub.cfg har återskapats och att standardschemat har uppdaterats till 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

För Red Hat-distributionsfamiljen behöver du bara följande kommando:

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

Ubuntu 18.04 med Den Azure-finjusterade kerneln använder I/O-schemaläggare med flera köer. I det scenariot none är det lämpliga valet i stället för noop. Mer information finns i Ubuntu I/O-schemaläggare.

Använda programvaru-RAID för att uppnå högre I/Ops

Om dina arbetsbelastningar kräver mer IOps än vad en enskild disk kan tillhandahålla måste du använda en RAID-programvarukonfiguration för flera diskar. Eftersom Azure redan utför diskåter återhämtning på det lokala infrastrukturlagret får du högsta möjliga prestanda från en RAID-0-stripingkonfiguration. Etablera och skapa diskar i Azure-miljön och anslut dem till din virtuella Linux-dator innan du partitionering, formatering och montering av enheterna. Mer information om hur du konfigurerar en PROGRAMVARU-RAID-konfiguration på din virtuella Linux-dator i Azure finns i dokumentet Configuring Software RAID on Linux (Konfigurera programvaru-RAID på Linux ).

Som ett alternativ till en traditionell RAID-konfiguration kan du också välja att installera LVM (Logical Volume Manager) för att konfigurera ett antal fysiska diskar till en enda stripe logisk lagringsvolym. I den här konfigurationen distribueras läsningar och skrivningar till flera diskar i volymgruppen (liknar RAID0). Av prestandaskäl vill du förmodligen strimlar dina logiska volymer så att läsningar och skrivningar använder alla anslutna datadiskar. Mer information om hur du konfigurerar en stripe-logisk volym på din virtuella Linux-dator i Azure finns i dokumentet Configure LVM on a Linux VM in Azure (Konfigurera LVM på en virtuell Linux-dator i Azure ).

Nästa steg

Kom ihåg att precis som med alla optimeringsdiskussioner måste du utföra tester före och efter varje ändring för att mäta effekten av ändringen. Optimering är en steg-för-steg-process som har olika resultat för olika datorer i din miljö. Det som fungerar för en konfiguration kanske inte fungerar för andra.

Några användbara länkar till ytterligare resurser: