Diese Referenzarchitektur zeigt, wie Sie für eine n-schichtige Anwendung konfigurierte virtuelle Computer (VMs) und ein entsprechendes virtuelles Netzwerk mit Apache Cassandra unter Linux für die Datenebene bereitstellen.
Aufbau
Laden Sie eine Visio-Datei dieser Architektur herunter.
Workflow
Diese Architektur besteht aus den folgenden Komponenten.
Allgemein
Ressourcengruppe. Ressourcengruppen dienen zum Gruppieren von Azure-Ressourcen, damit sie nach Lebensdauer, Besitzer oder anderen Kriterien verwaltet werden können.
Verfügbarkeitszonen. Verfügbarkeitszonen sind physische Standorte in einer Azure-Region. Jede Zone besteht aus mindestens einem Datencenter mit eigener Stromversorgung, Kühlung und Netzwerk. Wenn Sie VMs zonenübergreifend platzieren, wird die Anwendung in einer Zone resilient gegenüber Fehlern.
Netzwerk und Lastenausgleich
Virtuelles Netzwerk und Subnetze. Jede Azure-VM wird in einem virtuellen Netzwerk bereitgestellt, das in Subnetze segmentiert werden kann. Erstellen Sie für jede Schicht ein separates Subnetz.
Anwendungsgateway: Application Gateway ist ein Lastenausgleich auf Schicht 7 (Anwendungsschicht). Bei dieser Architektur werden HTTP-Anforderungen an das Web-Front-End geleitet. Mit Application Gateway wird auch eine Web Application Firewall (WAF) bereitgestellt, mit der die Anwendung vor häufig auftretenden Exploits und Sicherheitsrisiken geschützt wird.
Lastenausgleichsmodule. Verwenden Sie Azure Load Balancer Standard zum Verteilen von Netzwerkdatenverkehr von der Webebene auf die Geschäftsebene.
Netzwerksicherheitsgruppen (NSGs). Verwenden Sie NSGs, um den Netzwerkdatenverkehr im virtuellen Netzwerk zu beschränken. In der hier gezeigten dreischichtigen Architektur akzeptiert die Datenbankschicht beispielsweise keinen Datenverkehr vom Web-Front-End, sondern nur von der Unternehmensschicht und dem Verwaltungssubnetz.
DDoS Protection. Obwohl die Azure-Plattform grundlegenden Schutz vor verteilten Denial-of-Service-Angriffen (DDoS) beinhaltet, empfehlen wir die Verwendung von Azure DDoS-Netzwerkschutz, der erweiterte Funktionen für die DDoS-Entschärfung bietet. Weitere Informationen finden Sie unter Sicherheitshinweise.
Azure DNS: Azure DNS ist ein Hostingdienst für DNS-Domänen. Er ermöglicht eine Namensauflösung mithilfe der Microsoft Azure-Infrastruktur. Durch das Hosten Ihrer Domänen in Azure können Sie Ihre DNS-Einträge mithilfe der gleichen Anmeldeinformationen, APIs, Tools und Abrechnung wie für die anderen Azure-Dienste verwalten.
Virtuelle Computer
Apache Cassandra-Datenbank: Stellt Hochverfügbarkeit in der Datenschicht durch Replikation und Failover bereit.
OpsCenter. Stellen Sie eine Überwachungslösung wie DataStax OpsCenter bereit, um den Cassandra-Cluster zu überwachen.
Jumpbox. Wird auch als geschützter Host bezeichnet. Dies ist eine geschützte VM im Netzwerk, die von Administratoren zum Herstellen der Verbindung mit anderen VMs verwendet wird. Die Jumpbox verfügt über eine NSG, bei der Remotedatenverkehr nur von öffentlichen IP-Adressen zugelassen wird, die in einer Liste mit sicheren Adressen enthalten sind. Die NSG sollte Remotedesktopprotokoll-Datenverkehr (RDP) zulassen.
Empfehlungen
Ihre Anforderungen können von der hier beschriebenen Architektur abweichen. Verwenden Sie diese Empfehlungen als Startpunkt.
Virtuelle Computer
Empfehlungen zum Konfigurieren der VMs finden Sie unter Ausführen eines virtuellen Linux-Computers in Azure.
Virtuelles Netzwerk
Legen Sie bei der Erstellung des virtuellen Netzwerks (VNET) fest, wie viele IP-Adressen Ihre Ressourcen in jedem Subnetz benötigen. Geben Sie mithilfe der Notation [Classless Inter-Domain Routing (CIDR)] eine Subnetzmaske und einen VNET-Adressbereich an, der für die erforderlichen IP-Adressen groß genug ist. Verwenden Sie einen Adressraum, der in die standardmäßigen privaten IP-Adressblöcke 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16 fällt.
Wählen Sie einen Adressbereich, der sich nicht mit Ihrem lokalen Netzwerk überschneidet, für den Fall, dass Sie später ein Gateway zwischen dem virtuellen Netzwerk und dem lokalen Netzwerk einrichten müssen. Sobald Sie das virtuelle Netzwerk erstellt haben, können Sie den Adressbereich nicht mehr ändern.
Entwerfen Sie Subnetze unter Berücksichtigung der Funktionalität und Sicherheitsanforderungen. Alle VMs innerhalb derselben Schicht oder Rolle sollten im selben Subnetz platziert werden, was eine Sicherheitsbegrenzung darstellen kann. Weitere Informationen zum Entwerfen von VNETs und Subnetzen finden Sie unter Planen und Entwerfen von Azure Virtual Networks.
Application Gateway
Weitere Informationen zum Konfigurieren von Application Gateway finden Sie unter Application Gateway – Konfigurationsübersicht.
Load Balancer
Machen Sie die VMs nicht direkt über das Internet verfügbar. Weisen Sie stattdessen jeder VM eine private IP-Adresse zu. Clients stellen über die IP-Adresse eine Verbindung her, die dem Application Gateway zugeordnet ist.
Definieren Sie Lastenausgleichsregeln, um Netzwerkdatenverkehr an die virtuellen Computer weiterzuleiten. Um beispielsweise HTTP-Datenverkehr zu aktivieren, erstellen Sie eine Regel, die Port 80 aus der Front-End-Konfiguration Port 80 im Back-End-Adresspool zuordnet. Wenn ein Client eine HTTP-Anforderung an Port 80 sendet, wählt der Lastenausgleich mithilfe eines Hashalgorithmus, der die Quell-IP-Adresse enthält, eine Back-End-IP-Adresse aus. So werden Clientanforderungen auf alle VMs verteilt.
Netzwerksicherheitsgruppen
Verwenden Sie NSG-Regeln, um den Datenverkehr zwischen den Schichten zu beschränken. In der oben gezeigten dreischichtigen Architektur kommuniziert die Internetschicht beispielsweise nicht direkt mit der Datenbankschicht. Um dies zu erzwingen, sollte die Datenbankschicht eingehenden Datenverkehr aus dem Subnetz der Internetschicht blockieren.
- Verweigern Sie sämtlichen eingehenden Datenverkehr aus dem virtuellen Netzwerk. (Verwenden Sie den
VIRTUAL_NETWORK-Tag in der Regel.) - Lassen Sie eingehenden Datenverkehr aus dem Subnetz der Unternehmensschicht zu.
- Lassen Sie eingehenden Datenverkehr aus dem Subnetz der Datenbankschicht zu. Diese Regel ermöglicht die Kommunikation zwischen den virtuellen Datenbankcomputern, die für die Replikation und das Failover der Datenbank erforderlich ist.
- Lassen Sie SSH-Datenverkehr (Port 22) aus dem Subnetz der Jumpbox zu. Diese Regel erlaubt Administratoren, über die Jumpbox eine Verbindung mit der Datenbankschicht herzustellen.
Erstellen Sie die Regeln 2-4 mit einer höheren Priorität als die erste Regel, damit sie Vorrang haben.
Cassandra
Für die Produktion wird DataStax Enterprise empfohlen, wobei diese Empfehlungen für alle Cassandra-Editionen gelten. Weitere Informationen zur Ausführung von DataStax in Azure finden Sie im DataStax Enterprise-Bereitstellungshandbuch für Azure.
Konfigurieren Sie Knoten im rackfähigen Modus. Ordnen Sie Fehlerdomänen den Racks in der Datei cassandra-rackdc.properties zu.
Es ist kein vor dem Cluster geschaltetes Lastenausgleichsmodul erforderlich. Der Client stellt eine direkte Verbindung mit einem Knoten im Cluster her.
In den Bereitstellungsskripts für diese Architektur wird die Namensauflösung verwendet, um den Startknoten für die Kommunikation innerhalb des Clusters (gossip) zu initialisieren. Zum Aktivieren der Namensauflösung erstellt die Bereitstellung eine Azure DNS Private Zone mit A-Datensätzen für die Cassandra-Knoten. Abhängig von Ihren Initialisierungsskripts können Sie möglicherweise stattdessen die statische IP-Adresse verwenden.
Hinweis
Privates Azure-DNS ist zurzeit als öffentliche Vorschau verfügbar.
Jumpbox
Verweigern Sie den SSH-Zugriff (Remotedesktopprotokoll) über das öffentliche Internet auf die VMs, auf denen die Anwendungsworkload ausgeführt wird. Der gesamte SSH-Zugriff auf diese VMs muss stattdessen über die Jumpbox erfolgen. Ein Administrator meldet sich bei der Jumpbox und von der Jumpbox aus dann bei der anderen VM an. Die Jumpbox lässt SSH-Datenverkehr aus dem Internet zu, jedoch nur von bekannten, sicheren IP-Adressen.
Die Jumpbox hat sehr geringe Leistungsanforderungen. Wählen Sie daher einen virtuellen Computer mit geringer Größe. Erstellen Sie eine öffentliche IP-Adresse für die Jumpbox. Platzieren Sie die Jumpbox im selben virtuellen Netzwerk wie die anderen VMs, jedoch in einem separaten Verwaltungssubnetz.
Fügen Sie zum Schutz der Jumpbox eine NSG-Regel hinzu, die ausschließlich SSH-Verbindungen von einer sicheren Gruppe öffentlicher IP-Adressen zulässt. Konfigurieren Sie die NSGs für die anderen Subnetze, um SSH-Datenverkehr aus dem Verwaltungssubnetz zuzulassen.
Überlegungen
Skalierbarkeit
Skalierungsgruppen
Erwägen Sie für die Internet- und Unternehmensschichten die Verwendung von VM-Skalierungsgruppen, anstatt separate VMs in einer Verfügbarkeitsgruppe bereitzustellen. Eine Skalierungsgruppe erleichtert die Bereitstellung und Verwaltung einer Gruppe identischer VMs und ermöglicht die automatische Skalierung der VMs auf der Grundlage von Leistungsmetriken. Mit zunehmender Last auf den virtuellen Computern werden dem Lastenausgleich automatisch zusätzliche virtuelle Computer hinzugefügt.
Es gibt zwei grundlegende Methoden für das Konfigurieren von virtuellen Computern in einer Skalierungsgruppe:
Verwenden Sie Erweiterungen, um die VM nach ihrer Bereitstellung zu konfigurieren. Bei diesem Ansatz dauert das Starten neuer VM-Instanzen länger als bei virtuellen Computern ohne Erweiterungen.
Stellen Sie einen verwalteten Datenträger mit einem benutzerdefinierten Datenträgerimage bereit. Diese Option kann möglicherweise schneller bereitgestellt werden. Allerdings müssen Sie das Image auf dem neuesten Stand halten.
Weitere Informationen finden Sie unter Überlegungen zum Entwurf von Skalierungsgruppen.
Tipp
Wenn Sie eine Lösung für die automatische Skalierung verwenden, testen Sie diese im Voraus mit Workloads auf Produktionsebene.
Grenzwerte für Abonnements
Jedes Azure-Abonnement verfügt über Standardeinschränkungen, zu denen auch eine maximale Anzahl von virtuellen Computern pro Region gehört. Sie können den Grenzwert erhöhen, indem Sie eine Supportanfrage einreichen. Weitere Informationen finden Sie unter Grenzwerte für Azure-Abonnements, -Dienste und -Kontingente sowie allgemeine Beschränkungen.
Application Gateway
Application Gateway unterstützt den Modus mit fester Kapazität oder den Modus mit automatischer Skalierung. Der Modus mit fester Kapazität empfiehlt sich für Szenarien mit einheitlichen und vorhersagbaren Workloads. Verwenden Sie den Modus mit automatischer Skalierung für Workloads mit variablem Datenverkehr. Weitere Informationen finden Sie unter Automatische Skalierung und zonenredundantes Application Gateway v2.
Effiziente Leistung
Um die beste Leistung mit Cassandra auf Azure-VMs zu erzielen, befolgen Sie die Empfehlungen in Ausführen von Apache Cassandra auf Azure VMs.
Verfügbarkeit
Verfügbarkeitszonen bieten die beste Resilienz innerhalb einer einzelnen Region. Wenn Sie eine noch höhere Verfügbarkeit benötigen, erwägen Sie, die Anwendung über zwei Regionen zu replizieren.
Nicht alle Regionen unterstützen Verfügbarkeitszonen, und nicht alle VM-Größen werden in allen Zonen unterstützt. Führen Sie den folgenden Azure CLI-Befehl aus, um die unterstützten Zonen für jede VM-Größe innerhalb einer Region zu ermitteln:
az vm list-skus --resource-type virtualMachines --zone false --location <location> \
--query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table
Wenn Sie diese Architektur in einer Region bereitstellen, die keine Verfügbarkeitszonen unterstützt, platzieren Sie die VMs für jede Ebene in einer Verfügbarkeitsgruppe. VMs innerhalb derselben Verfügbarkeitsgruppe werden aus Redundanzgründen auf mehreren physischen Servern, Computerracks, Speichereinheiten und Netzwerkswitches bereitgestellt. Skalierungsgruppen verwenden automatisch Platzierungsgruppen, die als eine implizite Verfügbarkeitsgruppe fungieren.
Wenn Sie in Verfügbarkeitszonen bereitstellen, verwenden Sie die Standard-SKU von Azure Load Balancer und die SKU v2 von Application Gateway. Diese SKUs unterstützen die zonenübergreifende Redundanz. Weitere Informationen finden Sie unter
- Load Balancer im Standard-Tarif und Verfügbarkeitszonen
- Automatische Skalierung und zonenredundantes Application Gateway v2
- Wie unterstützt Application Gateway Hochverfügbarkeit und Skalierbarkeit?
In einer einzelnen Application Gateway-Bereitstellung können mehrere Instanzen des Gateways ausgeführt werden. Führen Sie für Produktionsworkloads mindestens zwei Instanzen aus.
Cassandra-Cluster
Für den Cassandra-Cluster hängen die Failoverszenarien von den Konsistenzebenen, die von der Anwendung verwendet werden, und von der Anzahl von Replikaten ab. Weitere Informationen zu Konsistenzebenen und der Verwendung in Cassandra finden Sie unter Konfigurieren der Datenkonsistenz und Cassandra: Wie viele Knoten kommunizieren mit Quorum? Die Verfügbarkeit der Daten wird in Cassandra durch die Konsistenzebene, die von der Anwendung verwendet wird, und vom Replikationsverfahren bestimmt. Weitere Informationen zur Replikation in Cassandra finden Sie unter Datenreplikation in NoSQL-Datenbanken im Überblick.
Integritätstests
Application Gateway und Load Balancer überwachen mit Integritätstests die Verfügbarkeit von VM-Instanzen.
- Application Gateway verwendet immer einen HTTP-Test.
- Load Balancer kann sowohl HTTP-Tests als auch TCP-Tests ausführen. Verwenden Sie generell einen HTTP-Test, wenn auf einer VM ein HTTP-Server ausgeführt wird. Verwenden Sie andernfalls TCP.
Kann eine Instanz bei einem Test nicht innerhalb des jeweiligen Zeitlimits erreicht werden, beendet das Gateway oder der Lastenausgleich das Senden von Datenverkehr an die betreffende VM. Der Test wird fortgesetzt. und die VM wird an den Back-End-Pool zurückgegeben, wenn sie wieder verfügbar wird.
HTTP-Tests senden eine HTTP GET-Anforderung an einen angegebenen Pfad und lauschen auf eine HTTP 200-Antwort. Bei diesem Pfad kann es sich um den Stammpfad („/“) oder einen Endpunkt zur Integritätsüberwachung handeln, der benutzerdefinierte Logik zum Überprüfen der Integrität der Anwendung implementiert. Der Endpunkt muss anonyme HTTP-Anforderungen zulassen.
Weitere Informationen zu Integritätstests finden Sie in folgenden Artikeln:
Überlegungen zum Entwerfen eines Integritätstest-Endpunkts finden Sie unter Muster für Überwachung der Integrität von Endpunkten.
Kostenoptimierung
Verwenden Sie den Azure-Preisrechner, um die Kosten zu ermitteln. Hier finden Sie einige weitere Überlegungen dazu.
VM-Skalierungsgruppen
VM-Skalierungsgruppen sind für alle Linux-VM-Größen verfügbar. Ihnen werden nur die Azure-VMs in Rechnung gestellt, die Sie bereitstellen, sowie alle zusätzlichen zugrunde liegenden Infrastrukturressourcen, die Sie genutzt haben, etwa Speicher und Netzwerk. Für den VM-Skalierungsgruppendienst selbst fallen keine inkrementellen Gebühren an.
Preisoptionen für einzelne VMS finden Sie unter Virtuelle Linux-Computer – Preise.
Load Balancer
Die Gebühren werden nur anhand der Anzahl von konfigurierten Lastenausgleichsregeln und Ausgangsregeln berechnet. Die Regeln für eingehende Netzwerkadressenübersetzung (NAT) sind kostenlos. Für Load Balancer Standard fallen keine Kosten auf Stundenbasis an, wenn keine Regeln konfiguriert sind.
Weitere Informationen finden Sie im Abschnitt zu Kosten im Microsoft Azure Well-Architected Framework.
Sicherheit
Virtuelle Netzwerke stellen in Azure eine Isolationsbegrenzung für Datenverkehr dar. Virtuelle Computer in einem virtuellen Netzwerk können nicht direkt mit virtuellen Computern in einem anderen virtuellen Netzwerk kommunizieren. VMs im selben virtuellen Netzwerk können miteinander kommunizieren, sofern Sie den Datenverkehr nicht durch die Erstellung von Netzwerksicherheitsgruppen (NSGs) beschränken. Weitere Informationen finden Sie unter Microsoft Cloud Services und Netzwerksicherheit.
Für eingehenden Internetdatenverkehr definieren die Lastenausgleichsregeln, welcher Datenverkehr an das Back-End weitergeleitet wird. Allerdings unterstützen Lastenausgleichsregeln keine IP-Sicherheitslisten. Wenn Sie also einer Sicherheitsliste bestimmte öffentliche IP-Adressen hinzufügen möchten, fügen Sie dem Subnetz eine NSG hinzu.
DMZ. Für die Erstellung einer DMZ zwischen dem Internet und dem virtuellen Azure-Netzwerk sollten Sie eventuell eine virtuelle Netzwerkappliance (Network Virtual Appliance, NVA) hinzufügen. NVA ist ein Oberbegriff für eine virtuelle Appliance, die netzwerkbezogene Aufgaben wie Erstellung von Firewalls, Paketüberprüfung, Überwachung und benutzerdefiniertes Routing ausführen kann. Weitere Informationen finden Sie unter Implementieren einer DMZ zwischen Azure und dem Internet.
Verschlüsselung. Verschlüsseln Sie sensible ruhende Daten, und verwalten Sie die Datenbankverschlüsselungsschlüssel mithilfe von Azure Key Vault. Key Vault kann Verschlüsselungsschlüssel in Hardwaresicherheitsmodulen (HSMs) speichern. Es empfiehlt sich außerdem, Anwendungsgeheimnisse wie Datenbankverbindungszeichenfolgen in Key Vault zu speichern.
DDoS Protection. Die Azure-Plattform stellt DDoS Protection Basic-Schutz standardmäßig bereit. Dieser Basisschutz ist dafür ausgelegt, die Azure-Infrastruktur als Ganzes zu schützen. Obwohl der grundlegende DDoS-Schutz automatisch aktiviert ist, empfehlen wir die Verwendung von Azure DDoS-Netzwerkschutz. Der Netzwerkschutz wendet basierend auf den Mustern des Netzwerkdatenverkehrs Ihrer Anwendung eine adaptive Optimierung an, um Bedrohungen zu erkennen. Dadurch können DDoS-Angriffe entschärft werden, die von den infrastrukturweiten DDoS-Richtlinien möglicherweise nicht erkannt werden. Der Netzwerkschutz stellt über Azure Monitor auch Warnungen, Telemetriedaten und Analysen bereit. Weitere Informationen finden Sie unter Azure DDoS Protection – Bewährte Methoden und Referenzarchitekturen.
Erstklassige Betriebsprozesse
Da sich alle Hauptressourcen und ihre Abhängigkeiten in derselben virtuellen Netzwerk in dieser Architektur befinden, sind sie in derselben grundlegenden Arbeitslast isoliert. Die Workloadisolation macht es leichter, die spezifischen Ressourcen einer Workload einem DevOps-Team zuzuordnen, damit das Team unabhängig alle Aspekte dieser Ressourcen verwalten kann. Diese Isolation ermöglicht DevOps-Teams und -Diensten die Durchführung von Continuous Integration- und Continuous Delivery-Vorgängen (CI/CD).
Außerdem können Sie verschiedene Bereitstellungsvorlagen verwenden und in Azure DevOps Services integrieren, um in wenigen Minuten unterschiedliche Umgebungen bereitzustellen. Beispielsweise können Sie das Replizieren von produktionsähnlichen Szenarien oder das Laden von Testumgebungen nur bei Bedarf durchführen, um Kosten zu sparen.
In diesem Szenario werden Ihre virtuellen Computer mit VM-Erweiterungen konfiguriert, da sie die Installation von bestimmter Zusatzsoftware ermöglichen, z. B. Apache Cassandra. Beispielsweise ermöglicht es die benutzerdefinierte Skripterweiterung, beliebigen Code auf eine VM herunterzuladen und auszuführen, um uneingeschränkte Anpassungen für das Betriebssystem einer Azure-VM durchzuführen. VM-Erweiterungen werden nur während der Erstellung einer VM installiert und ausgeführt. Das bedeutet, wenn das Betriebssystem zu einem späteren Zeitpunkt nicht ordnungsgemäß konfiguriert wird, ist manuelles Eingreifen erforderlich, um es wieder in seinen korrekten Zustand zu versetzen. Tools zur Konfigurationsverwaltung können zur Lösung dieses Problems verwendet werden.
Erwägen Sie die Nutzung von Azure Monitor, um die Leistung Ihrer Infrastruktur zu analysieren und zu optimieren, die Überwachung durchzuführen und Netzwerkprobleme zu diagnostizieren, ohne dass Sie sich bei Ihren virtuellen Computern anmelden müssen. Application Insights ist tatsächlich einer der Komponenten von Azure Monitor, die Ihnen umfassende Metriken und Protokolle zum Überprüfen des Status Ihrer gesamten Azure-Landschaft an die Hand gibt. Mit Azure Monitor können Sie den Status Ihrer Infrastruktur verfolgen.
Achten Sie darauf, nicht nur die Compute-Elemente zu überwachen, die Ihren Anwendungscode unterstützen, sondern auch Ihre Datenplattformen. Dies gilt vor allem für Ihre Datenbanken, da eine schlechte Leistung der Datenebene einer Anwendung schwerwiegende Folgen haben kann.
Um die Umgebung zu testen, in der die Anwendungen ausgeführt werden, sollte eine Versionskontrolle vorhanden sein, und für die Bereitstellung sollten die gleichen Mechanismen wie für den Anwendungscode verwendet werden. Dies ermöglicht es, die Umgebung ebenfalls anhand von DevOps-Testparadigmen zu testen und zu validieren.
Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework im Abschnitt mit den Informationen zum optimalen Betrieb.