Plannen voor grootte en netwerken

  • 10 minuten

Azure VM is een populair iaaS-resourcetype (infrastructure-as-a-service) in Azure. Vergeleken met PaaS-rekenservices (Platform-as-a-Service), bieden Azure-VM's meer flexibiliteit en controle over het besturingssysteem van de VM en de configuratie ervan. De toegenomen controle en flexibiliteit vereisen meer planning om optimale resultaten te ondersteunen.

In deze les worden algemene factoren en overwegingen beschreven voor het plannen van Azure Linux VM-implementaties. Het planningsproces moet rekening houden met de reken-, netwerk- en opslagaspecten van de VM-configuratie. Sommige van deze kenmerken zijn besturingssysteemspecifiek, met implementatiedetails die variëren in verschillende Linux-distributies.

Microsoft werkt samen met prominente Linux-leveranciers om hun producten te integreren met het Azure-platform. Om volledig te profiteren van deze integratie, kunt u Azure-VM's maken op basis van vooraf gedefinieerde installatiekopieën voor verschillende populaire Linux-distributies, zoals SUSE, Red Hat en Ubuntu. U kunt eventueel een aangepaste installatiekopieën maken van een Linux-distributie die in de cloudomgeving moet worden uitgevoerd. In dit geval zijn er mogelijk meer stappen in het inrichtingsproces voor azure-VM's.

In beide gevallen kan deze leermodule u helpen uw resulterende implementatie verder te optimaliseren. Voor optimalisatie moet u een goed begrip hebben van de Azure VM-resource en de bijbehorende afhankelijkheden.

Resourceafhankelijkheden begrijpen

Wanneer u een Virtuele Azure-machine maakt, moet u ook verschillende gekoppelde resources maken die afhankelijk zijn van de Azure-VM om volledige functionaliteit te bieden aan het gevirtualiseerde besturingssysteem. Deze resources zijn onder andere:

  • Virtuele schijven voor het opslaan van het besturingssysteem, toepassingen en gegevens.

  • Een virtueel netwerk met een of meer subnetten om de Virtuele Azure-machine te verbinden met andere Azure-services of met uw on-premises datacenters.

  • Een netwerkinterface om de Virtuele Azure-machine te verbinden met een subnet van het virtuele netwerk.

    Notitie

    Aan elke netwerkinterface moet ten minste één privé-IP-adres dynamisch of statisch zijn toegewezen. Privé-IP-adressen zijn geen afzonderlijke Azure-resources, maar maken deel uit van de subnetconfiguratie.

  • Een resourcegroep voor het hosten van de Virtuele Azure-machine.

  • Optioneel, een openbaar IP-adres dat is gekoppeld aan de netwerkinterface van de VIRTUELE machine, om directe binnenkomende toegang tot de virtuele machine vanaf internet te bieden.

Nu u inzicht hebt in de afhankelijkheden van de Azure-VM-resource, kunt u beginnen met het plannen van de grootte van vm's.

Grootte plannen

Als u de juiste grootte voor uw Azure-VM wilt bepalen, moet u rekening houden met de beoogde workload. De grootte die u kiest, bepaalt de volgende kenmerken van de virtuele machine:

  • Verwerkingskracht
  • Geheugen
  • Opslagcapaciteit
  • Prestaties
  • Ondersteuning voor geavanceerde netwerkfuncties

Belangrijk

Azure-VM's hebben quotumlimieten voor virtuele CPU (vCPU's), waarvoor u rekening moet houden bij de planning. Als u quotumlimieten wilt verhogen na de implementatie, moet u een onlineaanvraag indienen bij De ondersteuning van Azure.

Azure biedt een breed scala aan grootten met verschillende specificaties en prijspunten om te voldoen aan een groot aantal behoeften. VM-grootten worden gegroepeerd in verschillende categorieën die de typen workloads vertegenwoordigen waarvoor ze zijn geoptimaliseerd. Elke categorie bevat een of meer reeksen of families, die algemene onderliggende hardwarekenmerken delen, maar een reeks verschillende grootten bieden.

De volgende lijst bevat de workloadtypen en veelvoorkomende gebruiksvoorbeelden voor elk type werkbelasting. Elk workloadtype heeft bijbehorende families met verschillende grootten.

  • Algemeen gebruik: testen en ontwikkelen, kleine tot middelgrote databases en webservers met weinig tot gemiddeld verkeer.
  • Rekenintensief: webservers met gemiddeld verkeer, netwerkapparaten, batchprocessen en toepassingsservers.
  • Geheugenintensief: relationele databaseservers, middelgrote tot grote caches en analyse in het geheugen.
  • Opslagintensief: Big data-, SQL- en NoSQL-databases waarvoor hoge schijfdoorvoer en invoer/uitvoer (I/O) is vereist.
  • Graphics Processing Unit (GPU)-enabled: Zware grafische rendering of videobewerking, en modeltraining en deductie met deep learning.
  • High Performance Computing (HPC):snelste en krachtigste CPU-VM's, met optionele netwerkinterfaces met hoge doorvoer die REMOTE Direct Memory Access (RDMA) ondersteunen.

Houd rekening met de volgende factoren wanneer u azure-VM-grootten plant:

  • Als u de Azure VM-serie of -grootte wijzigt, moet het besturingssysteem eenvoudig en gebruikelijk opnieuw worden opgestart. Als u opnieuw wilt opstarten wilt voorkomen, moet u de VM zo mogelijk vanaf het begin de juiste grootte geven.
  • Beschikbaarheid van VM-grootte varieert per regio, dus houd rekening met regionale beschikbaarheid wanneer u uw implementatie plant.
  • Het maximum aantal schijven dat u aan een Azure-VM kunt koppelen, is afhankelijk van de grootte.

Andere overwegingen voor grootte

Overweeg het gebruik van de Microsoft Azure VM-selector om de meest geschikte VM-grootte te bepalen op basis van het workloadtype, het besturingssysteem, de geïnstalleerde software en de implementatieregio.

Als u van plan bent om gedurende een langere periode dezelfde of vergelijkbare grootte te gebruiken voor Azure-VM's in dezelfde regio, kunt u Overwegen Om Azure-reserveringen te gebruiken om de rekenkosten met maximaal 72 procent te verlagen.

Als u de kosten van Azure-VM's wilt verlagen voor workloads die onderbrekingen kunnen afhandelen, zoals batchverwerkingstaken, gebruikt u Azure Spot-VM's.

Netwerken plannen

VM's communiceren met externe resources met behulp van een virtueel netwerk. Een virtueel netwerk vertegenwoordigt een particulier netwerk binnen een Azure-regio. U kunt virtuele netwerken verbinden met andere netwerken, inclusief netwerken in uw on-premises datacenters, en verkeersregels toepassen om binnenkomende en uitgaande connectiviteit te beheren.

Elk virtueel netwerk wijst een IP-adresruimte aan die doorgaans bestaat uit een of meer privéadresbereiken, zoals gedefinieerd door RFC 1918. Net als bij on-premises netwerken kunt u de adresruimte van het virtuele netwerk verdelen in meerdere subnetten om Azure VM-workloads te isoleren. Elk subnet in een virtueel netwerk vertegenwoordigt een privéadresbereik. Als u isolatie van werkbelastingen wilt afdwingen, koppelt u een netwerkbeveiligingsgroep (NSG) aan elk subnet.

Elke Azure-VM bevat een of meer netwerkinterfaces en elke interface maakt verbinding met een subnet binnen hetzelfde virtuele netwerk. Azure wijst automatisch elke VIRTUELE machine in het subnet een IP-adres toe vanuit het bereik van het subnet. Azure reserveert de eerste vier en het laatste IP-adres op elk subnet voor eigen gebruik en wijst deze niet toe.

Hoewel het mogelijk is om een virtueel netwerk en subnetten te maken als onderdeel van een VM-inrichtingsproces, is de aanbevolen methode om azure VM-implementatieplanning te starten met de netwerkomgeving. Nadat u rekening hebt gehouden met alle netwerkvereisten en de bijbehorende virtuele netwerken hebt gemaakt, kunt u doorgaan met het implementeren van de Virtuele Azure-machines.

Houd rekening met de volgende ontwerpprincipes wanneer u van plan bent voor virtuele Netwerken en subnetten van Azure:

  • Zorg ervoor dat adresruimten niet overlappen. Als u uw virtuele netwerken en on-premises netwerken wilt verbinden, kunnen de IP-adresruimten elkaar niet overlappen.
  • Gebruik een kleiner aantal grotere virtuele netwerken in plaats van een groter aantal kleinere virtuele netwerken. Met deze procedure kunt u beheeroverhead minimaliseren en schaalbaarheid vergemakkelijken.

Netwerkbandbreedte

Hoewel een Virtuele Azure-machine meerdere netwerkinterfaces kan hebben, is de beschikbare bandbreedte volledig afhankelijk van de grootte. Over het algemeen worden grotere VM-grootten meer bandbreedte toegewezen dan kleinere grootten.

Om de hoeveelheid werkelijke netwerkbandbreedte te meten ten opzichte van de toegewezen limiet, richt Azure zich alleen op uitgaand verkeer. Al het netwerkverkeer dat de VIRTUELE machine verlaat, telt mee voor die limiet, ongeacht de verkeersbestemming.

Azure beperkt de bandbreedte voor inkomend verkeer niet rechtstreeks. Factoren zoals opslag- en rekenresourcegebruik zijn echter van invloed op het volume van binnenkomende gegevens dat een Azure-VM kan verwerken.

Plannen voor externe connectiviteit

Overweeg als onderdeel van uw implementatieplanning de meest geschikte benadering om externe connectiviteit te bieden. Voor Linux-VM's omvat externe connectiviteit doorgaans het gebruik van Secure Shell (SSH) voor het implementeren van in-transit-versleuteling van een terminal shell-sessie.

Als u zich wilt verifiëren via een SSH-verbinding, kunt u een gebruikersnaam en wachtwoord of een SSH-sleutelpaar gebruiken. Als u wachtwoorden gebruikt voor SSH-verbindingen, blijft de VM kwetsbaar voor beveiligingsaanvallen. Het gebruik van SSH-sleutels is een veiligere en voorkeursmethode voor het maken van verbinding met een Linux-VM met SSH.

Zelfs met SSH-sleutels moet u standaard de verbinding openen met een openbaar IP-adres dat is gekoppeld aan de netwerkadapter van de Doel-Azure-VM. Dit openbare IP-adres is kwetsbaar voor externe bedreigingen en vertegenwoordigt een mogelijke aanvalsvector. U kunt dit risico beperken door azure Bastion- of Just-In-Time-VM-toegang (Just-In-Time) te implementeren.

Notitie

In hybride scenario's kunt u een site-naar-site virtueel particulier netwerk (VPN) of Azure ExpressRoute gebruiken om openbare IP-adressen uit uw on-premises omgeving te verbinden met virtuele Azure-machines.

Azure Bastion

U implementeert de Azure Bastion-service in een toegewezen subnet van een virtueel netwerk dat verbinding heeft met de doel-VM. Azure Bastion fungeert als broker voor externe SSH-verbindingen via HTTPS die alleen beschikbaar zijn vanuit Azure Portal. Azure Bastion elimineert de noodzaak voor het toewijzen van openbare IP-adressen aan de netwerkinterface van de doel-VM en zorgt er ook voor dat alleen geverifieerde en correct geautoriseerde gebruikers SSH-verbindingen kunnen initiëren.

JIT VM-toegang

JIT VM-toegang is een Microsoft Defender voor Cloud functie die de toegang beperkt tot een openbaar IP-adres dat is gekoppeld aan de netwerkinterface van een Azure-VM. Met deze limieten wordt de netwerkbeveiligingsgroep dynamisch aangepast om binnenkomende verbindingen alleen vanaf een aangewezen IP-adresbereik toe te staan tijdens een aangewezen tijdvenster. Net als bij Azure Bastion moeten gebruikers zich verifiëren voordat ze een verbinding vanuit Azure Portal starten.