Planen der Größenanpassung und des Netzwerks

  • 10 Minuten

Azure VM ist ein beliebter Infrastruktur-as-a-Service (IaaS)-Computeressourcentyp in Azure. Im Vergleich zu PaaS-Computediensten (Platform-as-a-Service) bieten Azure-VMs mehr Flexibilität und Kontrolle über das VM-Betriebssystem und seine Konfiguration. Die erhöhte Kontrolle und Flexibilität erfordern mehr Planung, um optimale Ergebnisse zu erhalten.

Diese Einheit beschreibt allgemeine Faktoren und Überlegungen zur Planung von Azure Linux-VM-Bereitstellungen. Bei diesem Planungsprozess sollten die Compute-, Netzwerk- und Speicheraspekte der VM-Konfiguration berücksichtigt werden. Einige dieser Merkmale sind betriebssystemspezifisch, wobei die Implementierungsdetails zwischen verschiedenen Linux-Distributionen variieren.

Microsoft arbeitet mit bekannten Linux-Anbietern zusammen, um deren Produkte in die Azure-Plattform zu integrieren. Um von dieser Integration in vollem Umfang zu profitieren, können Sie Azure-VMs aus vordefinierten Images für eine Vielzahl beliebter Linux-Distributionen wie SUSE, Red Hat und Ubuntu erstellen. Optional können Sie ein benutzerdefiniertes Image einer Linux-Verteilung erstellen, die in der Cloudumgebung ausgeführt werden soll. In diesem Fall gibt es möglicherweise weitere Schritte in Ihrem Azure VM-Bereitstellungsprozess.

In beiden Fällen kann dieses Lernmodul dazu beitragen, die resultierende Bereitstellung weiter zu optimieren. Diese Optimierung erfordert ein fundiertes Verständnis der Azure-VM-Ressource und ihrer Abhängigkeiten.

Grundlegendes zu Ressourcenabhängigkeiten

Wenn Sie eine Azure-VM erstellen, müssen Sie auch mehrere zugeordnete Ressourcen erstellen, von denen die Azure-VM abhängig ist, um vollständige Funktionen für das virtualisierte Betriebssystem bereitzustellen. Diese Ressourcen umfassen Folgendes:

  • Virtuelle Datenträger, auf denen das Betriebssystem, die Anwendungen und Daten gespeichert werden.

  • Ein virtuelles Netzwerk mit mindestens einem Subnetz, um die Azure-VM mit anderen Azure-Diensten oder mit Ihren lokalen Rechenzentren zu verbinden.

  • Eine Netzwerkschnittstelle zum Verbinden der Azure-VM mit einem Subnetz des virtuellen Netzwerks.

    Hinweis

    Jeder Netzwerkschnittstelle muss mindestens eine private IP-Adresse dynamisch oder statisch zugewiesen sein. Private IP-Adressen sind keine separaten Azure-Ressourcen, sie sind Teil der Subnetzkonfiguration.

  • Eine Ressourcengruppe zum Hosten der Azure-VM.

  • Optional, eine öffentliche IP-Adresse, die der Netzwerkschnittstelle des virtuellen Computers zugeordnet ist, um direkten eingehenden Zugriff auf die VM über das Internet bereitzustellen.

Nachdem Sie sich nun mit den Abhängigkeiten der Azure-VM-Ressource vertraut gemacht haben, können Sie mit der Planung der VM-Dimensionierung beginnen.

Planen der Größenanpassung

Um die geeignete Größe für Ihren virtuellen Azure-Computer zu ermitteln, müssen Sie seinen geplanten Workload berücksichtigen. Die von Ihnen ausgewählte Größe bestimmt die folgenden Merkmale des virtuellen Computers:

  • Verarbeitungsleistung
  • Arbeitsspeicher
  • Speicherkapazität
  • Leistung
  • Unterstützung für erweiterte Netzwerkfeatures

Wichtig

Azure-VMs verfügen über Kontingentbeschränkungen für virtuelle CPU (vCPU), die Sie bei der Planung berücksichtigen sollten. Um Kontingentbeschränkungen nach der Bereitstellung zu erhöhen, müssen Sie eine Onlineanfrage an den Azure-Support senden.

Azure bietet eine breite Palette von Größen mit unterschiedlichen Spezifikationen und Preispunkten, um eine Vielzahl von Anforderungen zu erfüllen. VM-Größen sind in mehrere Kategorien unterteilt, welche die Arten von Workloads darstellen, für die sie optimiert sind. Jede Kategorie enthält eine oder mehrere Serien oder Familien, die gemeinsame zugrunde liegende Hardwaremerkmale aufweisen, aber eine Reihe unterschiedlicher Größen bieten.

In der folgenden Liste sind Workloadtypen mit häufigen Anwendungsfällen für jeden Workloadtyp aufgeführt. Jeder Workloadtyp verfügt über entsprechende Familien, die verschiedene Größen enthalten.

  • Allgemein: Für Tests und Entwicklung kleiner bis mittlerer Datenbanken und Webserver mit geringer bis mittlerer Auslastung.
  • Compute-intensiv: Für Webserver, Netzwerkgeräte, Stapelverarbeitungsvorgänge und Anwendungsserver mit mittlerer Auslastung.
  • Arbeitsspeicherintensiv: Für relationale Datenbankserver, mittlere bis große Caches und In-Memory-Analysen.
  • Speicherintensiv: Big Data-, SQL- und NoSQL-Datenbanken, für die ein hoher Datenträgerdurchsatz und hohe Eingabe-/Ausgaberaten (E/A) erforderlich sind.
  • GPU-fähig (Grafikprozessor): Aufwendiges Grafikrendering oder Videobearbeitung, sowie Modelltraining und Rückschlüsse mit Deep Learning.
  • High Performance Computing (HPC): Schnellste und leistungsfähigste CPU-VMs mit optionalen Netzwerkschnittstellen mit hohem Durchsatz, die Remotezugriff auf den direkten Speicher (RDMA) unterstützen.

Berücksichtigen Sie bei der Planung von Azure VM-Größen auch die folgenden Faktoren:

  • Das Ändern der Azure-VM-Serie oder -Größe ist zwar einfach und wird auch häufig durchgeführt, erfordert jedoch einen Neustart des Betriebssystems. Um Neustarts zu vermeiden, sollten Sie den virtuellen Computer nach Möglichkeit von Anfang an entsprechend anpassen.
  • Die Verfügbarkeit der VM variiert je nach Region. Berücksichtigen Sie daher die regionale Verfügbarkeit, wenn Sie Ihre Bereitstellung planen.
  • Die maximale Anzahl der Datenträger, die Sie an eine Azure-VM anfügen können, hängt von deren Größe ab.

Weitere Überlegungen zu Größen

Erwägen Sie die Verwendung des Microsoft Azure-VM-Selektors, um die am besten geeignete VM-Größe auf Grundlage des Workloadtyps, des Betriebssystems, der installierten Software und der Bereitstellungsregion zu ermitteln.

Wenn Sie beabsichtigen, virtuelle Azure-Computer derselben oder einer ähnlichen Größe in derselben Region über einen längeren Zeitraum zu verwenden, sollten Sie die Verwendung von Azure-Reservierungen in Betracht ziehen, um die Computekosten um bis zu 72 Prozent zu reduzieren.

Verwenden Sie Azure Spot-VMs, um die Kosten für Azure-VMs mit Workloads zu senken, die mit Unterbrechungen umgehen können (z. B. Batchverarbeitungsaufträge).

Planen von Netzwerken

VMs kommunizieren über ein virtuelles Netzwerk mit externen Ressourcen. Ein virtuelles Netzwerk stellt ein privates Netzwerk innerhalb einer Azure-Region dar. Sie können virtuelle Netzwerke auch mit anderen Netzwerken verbinden, einschließlich von Netzwerken, die sich in Ihren lokalen Rechenzentren befinden, und Datenverkehrsregeln anwenden, um die ein- und ausgehende Konnektivität zu steuern.

Jedes virtuelle Netzwerk legt einen IP-Adressraum fest, der in der Regel aus einem oder mehreren privaten Adressbereichen besteht, wie in (Request For Comments) RFC 1918 definiert. Wie bei lokalen Netzwerken können Sie den virtuellen Netzwerkadressraum in mehrere Subnetze unterteilen, um Azure VM-Workloads zu isolieren. Jedes Subnetz innerhalb eines virtuellen Netzwerks stellt einen privaten Adressbereich dar. Um diese Workload-Isolation zu erzwingen, ordnen Sie jedem Subnetz eine Netzwerksicherheitsgruppe (NSG) zu.

Jede Azure-VM enthält eine oder mehrere Netzwerkschnittstellen und jede Schnittstelle stellt eine Verbindung mit einem Subnetz innerhalb desselben virtuellen Netzwerks her. Azure weist jedem virtuellen Computer im Subnetz automatisch eine IP-Adresse aus dem Subnetzbereich zu. Azure reserviert die ersten vier und die letzte IP-Adresse in jedem Subnetz für die eigene Verwendung und weist sie nicht zu.

Es ist zwar möglich, ein virtuelles Netzwerk mit seinen Subnetzen im Rahmen eines VM-Bereitstellungsprozesses zu erstellen, der empfohlene Ansatz besteht jedoch darin, Ihre Azure-VM-Bereitstellung bei der Netzwerkumgebungsplanung zu beginnen. Nachdem Sie alle Netzwerkanforderungen berücksichtigt und die entsprechenden virtuellen Netzwerke erstellt haben, können Sie mit der Bereitstellung von Azure-VMs fortfahren.

Beachten Sie bei der Planung den virtuellen Azure-Netzwerken und Subnetzen die folgenden allgemeinen Designprinzipien:

  • Stellen Sie sicher, dass sich die Adressräume nicht überlappen. Wenn Sie Ihre virtuellen Netzwerke und lokalen Netzwerke verbinden möchten, dürfen sich die IP-Adressräume nicht überlappen.
  • Verwenden Sie eine kleinere Anzahl von größeren virtuellen Netzwerken anstelle einer größeren Anzahl kleinerer virtueller Netzwerke. Diese Praxis trägt dazu bei, den Verwaltungsaufwand zu minimieren und die Skalierbarkeit zu erleichtern.

Netzwerkbandbreite

Obwohl eine Azure-VM über mehrere Netzwerkschnittstellen verfügen kann, hängt ihre verfügbare Bandbreite ausschließlich von ihrer Größe ab. Im Allgemeinen wird größeren VMs mehr Bandbreite zugewiesen als kleineren.

Um die tatsächliche Netzwerkbandbreite mit dem zugewiesenen Grenzwert zu messen, zielt Azure nur auf den ausgehenden Datenverkehr ab. Der gesamte Netzwerkdatenverkehr, der den virtuellen Computer verlässt, wird auf diesen Grenzwert angerechnet, unabhängig vom Datenverkehrsziel.

Azure schränkt die eingehende Bandbreite nicht direkt ein. Faktoren wie Speicher- und Computeressourcennutzung wirken sich jedoch auf das Volumen eingehender Daten aus, die eine Azure-VM verarbeiten kann.

Planen der Remotekonnektivität

Berücksichtigen Sie im Rahmen Ihrer Bereitstellungsplanung auch den am besten geeigneten Ansatz für die Bereitstellung von Remotekonnektivität. Bei Linux-VMs umfasst die Remotekonnektivität in der Regel die Verwendung von Secure Shell (SSH), um die In-Transit-Verschlüsselung einer Terminalshellsitzung zu implementieren.

Zur Authentifizierung über eine SSH-Verbindung können Sie einen Benutzernamen und ein Kennwort oder ein SSH-Schlüsselpaar verwenden. Wenn Sie Kennwörter für SSH-Verbindungen verwenden, ist die VM anfällig für Brute-Force-Angriffe. Die Verwendung von SSH-Schlüsseln ist eine sicherere und bevorzugte Methode zum Herstellen einer Verbindung mit einer Linux-VM über SSH.

Selbst mit SSH-Schlüsseln müssen Sie standardmäßig die Konnektivität mit einer öffentlichen IP-Adresse öffnen, die dem Netzwerkadapter der Azure-Ziel-VM zugeordnet ist. Diese öffentliche IP ist jedoch anfällig für externe Bedrohungen und stellt einen potenziellen Angriffsvektor dar. Um dieses Risiko zu minimieren, sollten Sie die Implementierung von Azure Bastion oder JIT-VM-Zugriff (Just-in-Time) in Betracht ziehen.

Hinweis

In Hybridszenarien können Sie Site-to-Site-VPN (virtuelles privates Netzwerk) oder Azure ExpressRoute verwenden, um die Notwendigkeit öffentlicher IP-Adressen beim Herstellen einer Verbindung aus Ihrer lokalen Umgebung mit Azure-VMs zu beseitigen.

Azure Bastion

Sie stellen den Azure Bastion-Dienst in einem dedizierten Subnetz eines virtuellen Netzwerks bereit, das über eine Verbindung mit dem virtuellen Zielcomputer verfügt. Azure Bastion dient als Broker für externe SSH-Verbindungen über HTTPS, die nur über das Azure-Portal verfügbar sind. Azure Bastion beseitigt die Notwendigkeit, öffentliche IP-Adressen der Netzwerkschnittstelle der Ziel-VM zuzuweisen, und stellt außerdem sicher, dass nur authentifizierte und ordnungsgemäß autorisierte Benutzer SSH-Verbindungen initiieren können.

JIT-VM-Zugriff

JIT-VM-Zugriff ist ein Microsoft Defender für Cloud-Feature, das den Zugriff auf eine öffentliche IP-Adresse beschränkt, die der Netzwerkschnittstelle einer Azure-VM zugeordnet ist. Diese Grenzwerte passen die NSG dynamisch an, um eingehende Verbindungen nur aus einem bestimmten IP-Adressbereich während eines festgelegten Zeitfensters zuzulassen. Wie bei Azure Bastion muss sich ein Benutzer authentifizieren, bevor er eine Verbindung aus dem Azure-Portal initiieren kann.