Bearbeiten

Freigeben über


Azure Local Baseline Reference Architecture

Azure Stack HCI
Azure Arc
Azure Blob Storage
Azure Monitor
Microsoft Defender für Cloud

Diese Basisreferenzarchitektur bietet workloadunabhängige Anleitungen und Empfehlungen für die Konfiguration von Azure Local, Version 23H2, Release 2311 und höher infrastruktur, um eine zuverlässige Plattform sicherzustellen, die hochverwendbare virtualisierte und containerisierte Workloads bereitstellen und verwalten kann. Diese Architektur beschreibt die Ressourcenkomponenten und Clusterdesignoptionen für die physischen Knoten, die lokale Compute-, Speicher- und Netzwerkfeatures bereitstellen. Außerdem wird beschrieben, wie Sie Azure-Dienste verwenden, um die tägliche Verwaltung von Azure Local zu vereinfachen und zu optimieren.

Weitere Informationen zu Workloadarchitekturmustern, die für die Ausführung auf Azure Local optimiert sind, finden Sie im Navigationsmenü azure Local workloads.

Diese Architektur ist ein Ausgangspunkt für die Verwendung des Netzwerkdesigns für den Speicherswitch zum Bereitstellen einer lokalen Azure-Instanz mit mehreren Knoten. Die workload-Anwendungen, die in einer lokalen Azure-Instanz bereitgestellt werden, sollten gut architekturiert sein. Anwendungen mit gut durchdachter Workload müssen mithilfe mehrerer Instanzen oder einer hohen Verfügbarkeit kritischer Workloaddienste bereitgestellt werden und über geeignete BcDR-Steuerelemente (Business Continuity and Disaster Recovery) verfügen. Diese BCDR-Steuerelemente umfassen regelmäßige Sicherungen und Failoverfunktionen für die Notfallwiederherstellung. Um sich auf die HCI-Infrastrukturplattform zu konzentrieren, werden diese Workloaddesignaspekte absichtlich von diesem Artikel ausgeschlossen.

Weitere Informationen zu Richtlinien und Empfehlungen für die fünf Säulen des Azure Well-Architected Framework finden Sie im Azure Local Well-Architected Framework-Dienstleitfaden.

Artikellayout

Architektur Designentscheidungen Well-Architected Framework-Ansatz
Architektur
potenzielle Anwendungsfälle
Szenariodetails
Plattformressourcen
plattformgestützte Ressourcen
Bereitstellen dieses Szenarios
Auswahlmöglichkeiten des Clusterdesigns
Physische Festplattenlaufwerke
Netzwerkdesign-
Monitoring
Updateverwaltung
Zuverlässigkeit
Security
Kostenoptimierung
Operational Excellence
Leistungseffizienz

Trinkgeld

GitHub-Logo Die lokale Azure-Vorlage veranschaulicht, wie Sie eine Azure Resource Management-Vorlage (ARM-Vorlage) und Parameterdatei verwenden, um eine switched Multi-Server-Bereitstellung von Azure Local bereitzustellen. Alternativ wird im Bicep-Beispiel veranschaulicht, wie Sie eine Bicep-Vorlage verwenden, um eine lokale Azure-Instanz und die erforderlichen Ressourcen bereitzustellen.

Architektur

Diagramm, das eine Referenzarchitektur für mehrere Lokale Azure-Instanzen mit dualen Top-of-Rack (ToR)-Switches für die externe Nord-Süd-Konnektivität zeigt.

Weitere Informationen finden Sie unter Verwandte Ressourcen.

Potenzielle Anwendungsfälle

Typische Anwendungsfälle für Azure Local umfassen die Möglichkeit, Hochverfügbarkeitsworkloads (HA) an lokalen oder Edgestandorten auszuführen, die eine Lösung für die Anforderungen an die Arbeitsauslastung bieten. Sie können:

  • Stellen Sie eine hybride Cloudlösung bereit, die lokal bereitgestellt wird, um Datenhoheit, Regulierung und Compliance oder Latenzanforderungen zu erfüllen.

  • Bereitstellen und Verwalten von HA-virtualisierten oder containerbasierten Edgearbeitslasten, die an einem einzigen Ort oder an mehreren Standorten bereitgestellt werden. Mit dieser Strategie können geschäftskritische Anwendungen und Dienste auf widerstandsfähige, kostengünstige und skalierbare Weise betrieben werden.

  • Senken Sie die Gesamtbetriebskosten (TCO) mithilfe von Lösungen, die von Microsoft zertifiziert sind, cloudbasierte Bereitstellung, zentralisierte Verwaltung und Überwachung und Warnung.

  • Stellen Sie eine zentrale Bereitstellungsfunktion bereit, indem Sie Azure und Azure Arc verwenden, um Workloads an mehreren Standorten einheitlich und sicher bereitzustellen. Tools wie das Azure-Portal, die Azure CLI oder die Infrastruktur als Codevorlagen (IaC) verwenden Kubernetes für containerisierung oder herkömmliche Workloadvirtualisierung, um Automatisierung und Wiederholbarkeit zu fördern.

  • Einhaltung strenger Sicherheits-, Compliance- und Überwachungsanforderungen. Azure Local wird standardmäßig mit einem gehärteten Sicherheitsstatus bereitgestellt, der standardmäßig konfiguriert ist, oder standardmäßig sicheren. Azure Local enthält zertifizierte Hardware, sicherer Start, Trusted Platform Module (TPM), virtualisierungsbasierte Sicherheit (VBS), Credential Guard und erzwungene Windows Defender-Anwendungssteuerungsrichtlinien. Es ist auch in moderne cloudbasierte Sicherheits- und Bedrohungsverwaltungsdienste wie Microsoft Defender für Cloud und Microsoft Sentinel integriert.

Szenariodetails

In den folgenden Abschnitten finden Sie weitere Informationen zu szenarien und potenziellen Anwendungsfällen für diese Referenzarchitektur. Diese Abschnitte enthalten eine Liste der Geschäftlichen Vorteile und Beispielressourcentypen für Arbeitsauslastungen, die Sie in Azure Local bereitstellen können.

Verwenden von Azure Arc mit Azure Local

Azure Local ist direkt in Azure integriert, indem Azure Arc verwendet wird, um die TCO und den Betriebsaufwand zu senken. Azure Local wird über Azure bereitgestellt und verwaltet, das eine integrierte Integration von Azure Arc über die Bereitstellung der Azure Arc-Ressourcenbrücke Komponente bietet. Diese Komponente wird während des HCI-Clusterbereitstellungsprozesses installiert. Azure Local cluster nodes are enrolled with Azure Arc for servers as a prerequisite to initiate the cloud-based deployment of the cluster. Während der Bereitstellung werden obligatorische Erweiterungen auf jedem Clusterknoten installiert, z. B. Lifecycle Manager, Microsoft Edge Device Management und Telemetrie und Diagnose. Sie können Azure Monitor und Log Analytics verwenden, um den HCI-Cluster nach der Bereitstellung zu überwachen, indem Sie Insights für Azure Local aktivieren. Featureupdates für azure Local werden regelmäßig veröffentlicht, um die Kundenerfahrung zu verbessern. Updates werden über Azure Update Managergesteuert und verwaltet.

Sie können Workloadressourcen wie virtuellen Azure Arc-Computer (VMs), Azure Arc-fähigen Azure Kubernetes Service (AKS)bereitstellen und Azure Virtual Desktop-Sitzungshosts, die das Azure-Portal verwenden, indem Sie einen benutzerdefinierten Azure-Instanzspeicherort als Ziel für die Workloadbereitstellung auswählen. Diese Komponenten bieten eine zentrale Verwaltung, Verwaltung und Unterstützung. Wenn Sie über aktive Software Assurance für Ihre vorhandenen Windows Server Datacenter-Kernlizenzen verfügen, können Sie die Kosten weiter reduzieren, indem Sie den Azure-Hybridvorteil auf lokale Azure-, Windows Server-VMs und AKS-Cluster anwenden. Diese Optimierung trägt dazu bei, kosteneffizient für diese Dienste zu verwalten.

Die Azure- und Azure Arc-Integration erweitern die Funktionen von azure Localized and containerized workloads to include:

  • Azure Arc-VMs für herkömmliche Anwendungen oder Dienste, die in virtuellen Computern auf Azure Local ausgeführt werden.

  • AKS auf azure Local für containerisierte Anwendungen oder Dienste, die von der Nutzung von Kubernetes als Orchestrierungsplattform profitieren.

  • Azure Virtual Desktop, um Ihre Sitzungshosts für Azure Virtual Desktop-Workloads auf Azure Local (lokal) bereitzustellen. Sie können die Steuerungs- und Verwaltungsebene in Azure verwenden, um die Erstellung und Konfiguration des Hostpools zu initiieren.

  • Azure Arc-fähige Datendienste für containerisierte verwaltete Azure SQL-Instanz oder eine Azure-Datenbank für PostgreSQL-Server, die Azure Arc-fähige AKS verwenden, die auf Azure Local gehostet werden.

  • Die Azure Arc-fähige Azure Event Grid-Erweiterung für Kubernetes, um den Ereignisrasterbroker und den Ereignisrasteroperator Komponenten bereitzustellen. Diese Bereitstellung ermöglicht Funktionen wie Ereignisrasterthemen und Abonnements für die Ereignisverarbeitung.

  • Azure Arc-fähige maschinelles Lernen mit einem AKS-Cluster, der auf Azure Local als Computeziel zum Ausführen von Azure Machine Learning bereitgestellt wird. Sie können diesen Ansatz verwenden, um Machine Learning-Modelle am Edge zu trainieren oder bereitzustellen.

Azure Arc-verbundene Workloads bieten eine verbesserte Azure-Konsistenz und Automatisierung für lokale Azure-Bereitstellungen, z. B. das Automatisieren der Gastbetriebssystemkonfiguration mit Azure Arc-VM-Erweiterungen oder die Bewertung der Einhaltung von Branchenvorschriften oder Unternehmensstandards über Azure Policy. Sie können Azure Policy über das Azure-Portal oder die IaC-Automatisierung aktivieren.

Nutzen der Azure Local-Standardsicherheitskonfiguration

Die Azure Local Default Security-Konfiguration bietet eine detaillierte Verteidigungsstrategie zur Vereinfachung der Sicherheits- und Compliancekosten. Die Bereitstellung und Verwaltung von IT-Diensten für Einzelhandels-, Fertigungs- und Remotebüroszenarien stellt einzigartige Sicherheits- und Compliance-Herausforderungen dar. Die Sicherung von Workloads vor internen und externen Bedrohungen ist in Umgebungen mit eingeschränkter IT-Unterstützung oder fehlenden oder dedizierten Rechenzentren von entscheidender Bedeutung. Azure Local verfügt über eine standardmäßige Sicherheitshärtung und umfassende Integration in Azure-Dienste, die Ihnen bei der Bewältigung dieser Herausforderungen helfen.

Die lokal zertifizierte Azure-Hardware stellt die integrierte sichere Start-, Unified Extensible Firmware Interface (UEFI)- und TPM-Unterstützung sicher. Verwenden Sie diese Technologien in Kombination mit VBS-, um Ihre sicherheitsrelevanten Workloads zu schützen. Sie können die BitLocker-Laufwerkverschlüsselung verwenden, um Startdatenträgervolumes und ruhende Speicherplätze zu verschlüsseln. Die SMB-Verschlüsselung (Server Message Block) bietet eine automatische Verschlüsselung des Datenverkehrs zwischen Servern im Cluster (im Speichernetzwerk) und das Signieren von SMB-Datenverkehr zwischen den Clusterknoten und anderen Systemen. Die SMB-Verschlüsselung trägt auch dazu bei, Relayangriffe zu verhindern und die Einhaltung gesetzlicher Standards zu erleichtern.

Sie können lokale Azure-VMs in Defender for Cloud- integrieren, um cloudbasierte Verhaltensanalysen, Bedrohungserkennung und -behebung, Warnungen und Berichte zu aktivieren. Verwalten Sie lokale Azure-VMs in Azure Arc, damit Sie Azure-Richtlinie verwenden können, um ihre Einhaltung von Branchenvorschriften und Unternehmensstandards zu bewerten.

Komponenten

Diese Architektur besteht aus physischer Serverhardware, die Sie zum Bereitstellen von lokalen Azure-Instanzen oder Edgestandorten verwenden können. Um die Plattformfunktionen zu verbessern, integriert Azure Local in Azure Arc und andere Azure-Dienste, die unterstützende Ressourcen bereitstellen. Azure Local bietet eine robuste Plattform zum Bereitstellen, Verwalten und Betreiben von Benutzeranwendungen oder Geschäftssystemen. Plattformressourcen und -dienste werden in den folgenden Abschnitten beschrieben.

Plattformressourcen

Für die Architektur sind die folgenden obligatorischen Ressourcen und Komponenten erforderlich:

  • Azure Local ist eine Hyperconverged Infrastructure (HCI)-Lösung, die lokal oder an Edgestandorten mithilfe physischer Serverhardware und Netzwerkinfrastruktur bereitgestellt wird. Azure Local bietet eine Plattform zum Bereitstellen und Verwalten virtualisierter Workloads wie VMs, Kubernetes-Cluster und anderer Dienste, die von Azure Arc aktiviert sind. Azure Local instances can scale from a single-node deployment to a maximum of sixteen nodes using validated, integrated, or premium hardware categories that are provided by original equipment manufacturer (OEM) partners.

  • Azure Arc ist ein cloudbasierter Dienst, der das Verwaltungsmodell basierend auf Azure Resource Manager auf Azure Local und andere Nicht-Azure-Standorte erweitert. Azure Arc verwendet Azure als Steuerungs- und Verwaltungsebene, um die Verwaltung verschiedener Ressourcen wie VMs, Kubernetes-Cluster und containerisierte Daten- und Machine Learning-Dienste zu ermöglichen.

  • Azure Key Vault ist ein Clouddienst, mit dem Sie geheime Schlüssel sicher speichern und darauf zugreifen können. Ein geheimer Schlüssel ist alles, was Sie eng einschränken möchten, z. B. API-Schlüssel, Kennwörter, Zertifikate, kryptografische Schlüssel, lokale Administratoranmeldeinformationen und BitLocker-Wiederherstellungsschlüssel.

  • Cloudzeugen- ist ein Feature von Azure Storage, das als Failovercluster-Quorum fungiert. Azure Local cluster nodes use this quorum for voting, which ensures high availability for the cluster. Das Speicherkonto und die Zeugenkonfiguration werden während des Azure Local Cloud Deployment Process erstellt.

  • Update Manager- ist ein einheitlicher Dienst zum Verwalten und Steuern von Updates für Azure Local. Sie können den Update-Manager verwenden, um Workloads zu verwalten, die auf Azure Local bereitgestellt werden, einschließlich der Compliance für Gastbetriebssysteme für Windows- und Linux-VMs. Dieser einheitliche Ansatz optimiert die Patchverwaltung in Azure, lokalen Umgebungen und anderen Cloudplattformen über ein einziges Dashboard.

Plattformgestützte Ressourcen

Die Architektur umfasst die folgenden optionalen unterstützenden Dienste, um die Funktionen der Plattform zu verbessern:

  • Monitor ist ein cloudbasierter Dienst zum Sammeln, Analysieren und Handeln von Diagnoseprotokollen und Telemetrie aus Ihrer Cloud und lokalen Workloads. Sie können Monitor verwenden, um die Verfügbarkeit und Leistung Ihrer Anwendungen und Dienste durch eine umfassende Überwachungslösung zu maximieren. Stellen Sie Insights für Azure Local bereit, um die Erstellung der Datensammlungsregel (Monitor Data Collection Rule, DCR) zu vereinfachen und die Überwachung lokaler Azure-Instanzen schnell zu ermöglichen.

  • Azure Policy ist ein Dienst, der Azure- und lokale Ressourcen auswertet. Azure Policy wertet Ressourcen über die Integration in Azure Arc mithilfe der Eigenschaften dieser Ressourcen auf Geschäftsregeln aus, die Richtliniendefinitionengenannt werden, um Compliance oder Funktionen zu bestimmen, die Sie zum Anwenden der VM-Gastkonfiguration mithilfe von Richtlinieneinstellungen verwenden können.

  • Defender for Cloud ist ein umfassendes System zur Infrastruktursicherheit. Es verbessert den Sicherheitsstatus Ihrer Rechenzentren und bietet erweiterten Bedrohungsschutz für Hybridworkloads, unabhängig davon, ob sie sich in Azure oder an anderer Stelle befinden, und über lokale Umgebungen hinweg.

  • Azure Backup ist ein cloudbasierter Dienst, der eine einfache, sichere und kostengünstige Lösung bietet, um Ihre Daten zu sichern und aus der Microsoft Cloud wiederherzustellen. Azure Backup Server wird verwendet, um Sicherungen von VMs zu übernehmen, die auf Azure Local bereitgestellt werden, und sie im Sicherungsdienst zu speichern.

  • Site Recovery- ist ein Notfallwiederherstellungsdienst, der BCDR-Funktionen bereitstellt, indem Geschäfts-Apps und Arbeitslasten fehlschlagen können, wenn ein Notfall oder Ausfall auftritt. Site Recovery verwaltet die Replikation und das Failover von Workloads, die auf physischen Servern und virtuellen Computern zwischen ihrem primären Standort (lokal) und einem sekundären Standort (Azure) ausgeführt werden.

Auswahlmöglichkeiten für den Clusterentwurf

Es ist wichtig, die Workloadleistungs- und Ausfallsicherheitsanforderungen zu verstehen, wenn Sie eine lokale Azure-Instanz entwerfen. Zu diesen Anforderungen gehören RTO-Zeiten (Recovery Time Objective) und RPO-Zeiten (Recovery Point Objective), Compute (CPU), Arbeitsspeicher und Speicheranforderungen für alle Workloads, die in der lokalen Azure-Instanz bereitgestellt werden. Mehrere Merkmale der Arbeitsauslastung wirken sich auf den Entscheidungsprozess aus und umfassen:

  • Cpu-Architekturfunktionen (Central Processing Unit), einschließlich Hardware-Sicherheitstechnologiefeatures, anzahl der CPUs, der GHz-Frequenz (Geschwindigkeit) und der Anzahl der Kerne pro CPU-Socket.

  • Anforderungen der Grafikverarbeitungseinheit (GPU) der Workload, z. B. für KI oder maschinelles Lernen, Ableiten oder Rendern von Grafiken.

  • Der Arbeitsspeicher pro Knoten oder die Menge des physischen Arbeitsspeichers, der zum Ausführen der Workload erforderlich ist.

  • Die Anzahl der physischen Knoten im Cluster, die 1 bis 16 Knoten im Maßstab sind. Die maximale Anzahl von Knoten ist drei, wenn Sie die Speicherswitchless-Netzwerkarchitekturverwenden.

    • Um die Rechenresilienz aufrechtzuerhalten, müssen Sie mindestens N+1 Knoten im Cluster reservieren. Diese Strategie ermöglicht den Knotenabfluss für Updates oder Die Wiederherstellung von plötzlichen Ausfällen wie Stromausfällen oder Hardwarefehlern.

    • Bei geschäftskritischen oder unternehmenskritischen Workloads sollten Sie in Betracht ziehen, N+2-Knoten zu reservieren, um die Resilienz zu erhöhen. Wenn beispielsweise zwei Knoten im Cluster offline sind, kann die Workload online bleiben. Dieser Ansatz bietet Resilienz für Szenarien, in denen ein Knoten, der eine Workload ausführt, während eines geplanten Updatevorgangs offline geht, und führt dazu, dass zwei Knoten gleichzeitig offline sind.

  • Speicherresilienz, Kapazität und Leistungsanforderungen:

    • Resilienz-: Es wird empfohlen, drei oder mehr Knoten bereitzustellen, um die Drei-Wege-Spiegelung zu ermöglichen, die drei Kopien der Daten für die Infrastruktur und die Benutzervolumes bereitstellt. Die Drei-Wege-Spiegelung erhöht die Leistung und maximale Zuverlässigkeit für den Speicher.

    • Kapazität: Der gesamte erforderliche verwendbare Speicher nach Fehlertoleranz oder Kopienwird berücksichtigt. Diese Zahl beträgt ca. 33% des rohen Speicherplatzes ihrer Kapazitätsebenendatenträger, wenn Sie die Drei-Wege-Spiegelung verwenden.

    • Leistung: Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) der Plattform, die die Speicherdurchsatzfunktionen für die Workload bestimmen, wenn sie mit der Blockgröße der Anwendung multipliziert werden.

Um eine lokale Azure-Bereitstellung zu entwerfen und zu planen, empfehlen wir, das Azure Local-Größenanpassungstool zu verwenden und ein Neues Projekt für die Größenanpassung Ihrer HCI-Cluster zu erstellen. Die Verwendung des Größentools erfordert, dass Sie Ihre Workloadanforderungen verstehen. Berücksichtigen Sie bei Der Betrachtung der Anzahl und Größe von Workload-VMs, die auf Ihrem Cluster ausgeführt werden, Faktoren wie die Anzahl der vCPUs, die Speicheranforderungen und die erforderliche Speicherkapazität für die virtuellen Computer.

Das Größentool Einstellungen Abschnitt führt Sie durch Fragen zum Systemtyp (Premier, Integrated System oder Validated Node) und CPU-Familienoptionen. Außerdem können Sie Ihre Resilienzanforderungen für den Cluster auswählen. Stellen Sie sicher, dass:

  • Reservieren Sie mindestens N+1 Knoten, die Kapazität oder einen Knoten über den Cluster hinweg haben.

  • Reservieren Sie N+2 Knoten im gesamten Cluster für zusätzliche Resilienz. Diese Option ermöglicht es dem System, einem Knotenfehler während eines Updates oder eines anderen unerwarteten Ereignisses standzuhalten, das sich auf zwei Knoten gleichzeitig auswirkt. Außerdem wird sichergestellt, dass genügend Kapazität im Cluster vorhanden ist, damit die Workload auf den verbleibenden Onlineknoten ausgeführt werden kann.

Dieses Szenario erfordert die Drei-Wege-Spiegelung für Benutzervolumes. Dies ist die Standardeinstellung für Cluster mit drei oder mehr physischen Knoten.

Die Ausgabe des Tools für lokale Azure-Größenanpassung ist eine Liste empfohlener Hardwarelösungs-SKUs, die die erforderlichen Workloadkapazitäts- und Plattformresilienzanforderungen basierend auf den Eingabewerten im Sizer-Projekt bereitstellen können. Weitere Informationen zu verfügbaren OEM-Hardwarepartnerlösungen finden Sie im Azure Local Solutions Catalog. Wenden Sie sich an Ihren bevorzugten Hardwarelösungsanbieter oder Systemintegrationspartner, um lösungsbasierte SKUs zur Erfüllung Ihrer Anforderungen zu unterstützen.

Physische Datenträgerlaufwerke

Direkte Speicherplätze unterstützt mehrere physische Festplattenlaufwerktypen, die in Leistung und Kapazität variieren. Wenn Sie eine lokale Azure-Instanz entwerfen, arbeiten Sie mit Ihrem ausgewählten Hardware-OEM-Partner zusammen, um die am besten geeigneten physischen Datenträgerlaufwerktypen zu ermitteln, um die Kapazitäts- und Leistungsanforderungen Ihrer Workload zu erfüllen. Beispiele hierfür sind spinnende Festplattenlaufwerke (HDDs) oder Solid State Drives (SSDs) und NVMe-Laufwerke. Diese Laufwerke werden häufig als Flashlaufwerkeoder Speicher für beständigen Speicher (Persistent Memory, PMem)bezeichnet, der als Speicherklassenspeicher (Storage Class Memory, SCM)bezeichnet wird.

Die Zuverlässigkeit der Plattform hängt von der Leistung kritischer Plattformabhängigkeiten ab, z. B. physische Datenträgertypen. Stellen Sie sicher, dass Sie die richtigen Datenträgertypen für Ihre Anforderungen auswählen. Verwenden Sie All-Flash-Speicherlösungen, z. B. NVMe- oder SSD-Laufwerke für Workloads, die hohe Oder niedrige Latenzanforderungen aufweisen. Diese Workloads umfassen, sind jedoch nicht auf hochtransaktionale Datenbanktechnologien, Produktions-AKS-Cluster oder unternehmenskritische oder unternehmenskritische Workloads beschränkt, die über Speicheranforderungen mit geringer Latenz oder hohem Durchsatz verfügen. Verwenden Sie All-Flash-Bereitstellungen, um die Speicherleistung zu maximieren. All-NVMe Laufwerk- oder SSD-Laufwerkkonfigurationen, insbesondere in kleinem Maßstab, verbessern die Speichereffizienz und maximieren die Leistung, da keine Laufwerke als Cacheebene verwendet werden. Weitere Informationen finden Sie unter All-Flash-basierten Speicher.

Bei allgemeinen Workloads kann eine Hybridspeicherkonfiguration, z. B. NVMe-Laufwerke oder SSDs für Cache und HDDs für Kapazität, mehr Speicherplatz bieten. Der Kompromiss besteht darin, dass spinnende Datenträger eine geringere Leistung aufweisen, wenn Ihre Workload den Cachearbeitssatzüberschreitet, und HDDs haben einen niedrigeren Mittelwert zwischen Fehlerwert im Vergleich zu NVMe- und SSD-Laufwerken.

Die Leistung des Clusterspeichers wird durch den physischen Laufwerktyp beeinflusst, der je nach den Leistungsmerkmalen der einzelnen Laufwerktypen und dem von Ihnen ausgewählten Zwischenspeicherungsmechanismus variiert. Der Typ des physischen Datenträgerlaufwerks ist ein integraler Bestandteil des Direct Storage Spaces-Designs und der Konfiguration. Abhängig von den Anforderungen der lokalen Azure-Workload und Budgeteinschränkungen können Sie die Leistungmaximieren, die Kapazitätmaximieren oder eine Konfiguration mit gemischten Laufwerktypen implementieren, die die Leistung und Kapazität.

Direkte Speicherplätze bieten eine integrierten, beständigen, Echtzeit-, Lese-, Schreib-, serverseitigen Cache-, die die Speicherleistung maximiert. Der Cache sollte so angepasst und konfiguriert werden, dass der Arbeitssatz Ihrer Anwendungen und Workloads. Direkte virtuelle Datenträger für Direkte Speicherplätze oder Volumeswerden in Kombination mit csv-Speicherspeicher (Cluster Shared Volume) im Speicherlesecache verwendet, um Hyper-V Leistungzu verbessern, insbesondere für nicht gebufferten Eingabezugriff auf workload virtual hard disk (VHD) oder virtuelle Festplatte v2 (VHDX)-Dateien.

Trinkgeld

Für hochleistungs- oder latenzempfindliche Workloads empfehlen wir, eine Konfiguration des gesamten Flashspeichers (alle NVMe oder alle SSD) und eine Clustergröße von drei oder mehr physischen Knoten zu verwenden. Die Bereitstellung dieses Designs mit der Standardspeicherkonfiguration Einstellungen verwendet Drei-Wege-Spiegelungs- für die Infrastruktur und Benutzervolumes. Diese Bereitstellungsstrategie bietet höchste Leistung und Resilienz. Wenn Sie eine all-NVMe- oder all-SSD-Konfiguration verwenden, profitieren Sie von der vollen verwendbaren Speicherkapazität jedes Flashlaufwerks. Im Gegensatz zu hybriden oder gemischten NVMe + SSD-Setups ist keine Kapazität für die Zwischenspeicherung reserviert. Dadurch wird eine optimale Auslastung Ihrer Speicherressourcen sichergestellt. Weitere Informationen zum Ausgleich von Leistung und Kapazität zur Erfüllung Ihrer Workloadanforderungen finden Sie unter Planen von Volumes – Wenn die Leistung am wichtigstenist.

Netzwerkdesign

Das Netzwerkdesign ist die allgemeine Anordnung von Komponenten innerhalb der physischen Infrastruktur und logischen Konfigurationen des Netzwerks. Sie können die gleichen physischen Netzwerkschnittstellenkarten (NIC)-Ports für alle Kombinationen aus Verwaltungs-, Compute- und Speichernetzwerkabsichten verwenden. Die Verwendung der gleichen NIC-Ports für alle absichtsbezogenen Zwecke wird als vollständig konvergente Netzwerkkonfigurationbezeichnet.

Obwohl eine vollständig konvergente Netzwerkkonfiguration unterstützt wird, ist die optimale Konfiguration für Leistung und Zuverlässigkeit für die Speicherabsicht, dedizierte Netzwerkadapterports zu verwenden. Daher bietet diese Basisarchitektur Beispielanleitungen für die Bereitstellung einer lokalen Azure-Instanz mit speichergeschalteter Netzwerkarchitektur mit zwei Netzwerkadapterports, die für die Verwaltung und Berechnung von Absichten konvergent sind, und zwei dedizierte Netzwerkadapterports für die Speicherabsicht. Weitere Informationen finden Sie unter Netzwerküberlegungen für Cloudbereitstellungen von Azure Local.

Diese Architektur erfordert zwei oder mehr physische Knoten und bis zu maximal 16 Knoten im Maßstab. Jeder Knoten erfordert vier Netzwerkadapterports, die mit zwei Top-of-Rack (ToR)-Switches verbunden sind. Die beiden ToR-Schalter sollten über MLAG-Verbindungen (Multi-Chassis Link Aggregation Group) miteinander verbunden werden. Die beiden Netzwerkadapterports, die für den Speicherabsichtdatenverkehr verwendet werden, müssen Remote Direct Memory Access (RDMA)unterstützen. Für diese Ports ist eine Mindestverbindungsgeschwindigkeit von 10 GBit/s erforderlich, es wird jedoch eine Geschwindigkeit von 25 GBit/s oder höher empfohlen. Die beiden Netzwerkadapterports, die für die Verwaltung und Die Berechnung von Absichten verwendet werden, werden mithilfe der Set-Technologie (Switch Embedded Teaming) zusammengeführt. SET-Technologie bietet Verbindungsredundanz- und Lastenausgleichsfunktionen. Für diese Ports ist eine Mindestverbindungsgeschwindigkeit von 1 GBit/s erforderlich, es wird jedoch eine Geschwindigkeit von 10 GBit/s oder höher empfohlen.

Physische Netzwerktopologie

Die folgende physische Netzwerktopologie zeigt die tatsächlichen physischen Verbindungen zwischen Knoten und Netzwerkkomponenten.

Sie benötigen die folgenden Komponenten, wenn Sie eine umgestellte Azure Local-Bereitstellung mit Multinode-Speicher entwerfen, die diese Basisarchitektur verwendet:

Diagramm, das die physische Netzwerktopologie für eine lokale Azure-Instanz mit mehreren Knoten zeigt, die eine speichergeschaltete Architektur mit dualen ToR-Switches verwendet.

  • Dual ToR-Schalter:

    • Dual ToR-Netzwerkswitche sind für die Netzwerkresilienz und die Möglichkeit, Firmwareupdates zu warten oder anzuwenden, auf die Switches ohne Ausfallzeiten erforderlich. Diese Strategie verhindert einen einzigen Fehlerpunkt (SPoF).

    • Die dualen ToR-Schalter werden für den Speicher- oder Ost-West-Datenverkehr verwendet. Diese Switches verwenden zwei dedizierte Ethernet-Ports, die über spezifische Speichernetzwerke für virtuelle Lokale Bereiche (VLANs) und PFC-Datenverkehrsklassen (Priority Flow Control) verfügen, die definiert sind, um verlustfreie RDMA-Kommunikation bereitzustellen.

    • Diese Switches verbinden sich über Ethernet-Kabel mit den Knoten.

  • Mindestens zwei physische Knoten und bis zu maximal 16 Knoten:

    • Jeder Knoten ist ein physischer Server, auf dem das Azure Stack HCI-Betriebssystem ausgeführt wird.

    • Jeder Knoten erfordert insgesamt vier Netzwerkadapterports: zwei RDMA-fähige Ports für Speicher und zwei Netzwerkadapterports für die Verwaltung und den Computedatenverkehr.

    • Speicher verwendet die beiden dedizierten RDMA-fähigen Netzwerkadapterports, die eine Verbindung mit einem Pfad zu jedem der beiden ToR-Switches herstellen. Dieser Ansatz bietet Linkpfadredundanz und dedizierte priorisierte Bandbreite für SMB Direct Storage-Datenverkehr.

    • Für die Verwaltung und Berechnung werden zwei Netzwerkadapterports verwendet, die einen Pfad zu jedem der beiden ToR-Switches zur Redundanz von Linkspfaden bereitstellen.

  • Externe Konnektivität:

    • Dual ToR switches connect to the external network, such as your internal corporate LAN, to provide access to the required outbound URLs by using your edge border network device. Dieses Gerät kann eine Firewall oder ein Router sein. Diese Schalter wechseln den Datenverkehr, der in die lokale Azure-Instanz oder nord-süd-Verkehr ein- und ausgeht.

    • Externe Nord-Süd-Datenverkehrskonnektivität unterstützt die Clusterverwaltungsabsicht und die Berechnung von Absichten. Dies wird erreicht, indem zwei Switchports und zwei Netzwerkadapterports pro Knoten verwendet werden, die über switch embedded teaming (SET) und einen virtuellen Switch innerhalb Hyper-V zusammengeführt werden, um die Resilienz zu gewährleisten. Diese Komponenten funktionieren, um externe Konnektivität für Azure Arc-VMs und andere Workloadressourcen bereitzustellen, die in den logischen Netzwerken bereitgestellt werden, die im Ressourcen-Manager mithilfe von Azure-Portal-, CLI- oder IaC-Vorlagen erstellt werden.

Logische Netzwerktopologie

Die logische Netzwerktopologie zeigt eine Übersicht darüber, wie Netzwerkdaten unabhängig von ihren physischen Verbindungen zwischen Geräten fließen.

Eine Zusammenfassung der logischen Einrichtung für diese Switched Baseline-Architektur für Multinode-Speicher für Azure Local lautet wie folgt:

Diagramm, das die logische Netzwerktopologie für eine lokale Azure-Instanz mit mehreren Knoten mit der speichergeschalteten Architektur mit dualen ToR-Switches zeigt.

  • Dual ToR-Schalter:

    • Bevor Sie den Cluster bereitstellen, müssen die beiden ToR-Netzwerkswitche mit den erforderlichen VLAN-IDs, den maximalen Übertragungseinheitseinstellungen und der Überbrückungskonfiguration für die Management-konfiguriert werden, berechnenund Speicher Ports. Weitere Informationen finden Sie unter Physische Netzwerkanforderungen für azure Local, oder bitten Sie Ihren Switch-Hardwareanbieter oder SI-Partner um Unterstützung.
  • Azure Local verwendet den Netzwerk ATC-Ansatz, um die Netzwerkautomatisierung und die absichtsbasierte Netzwerkkonfiguration anzuwenden.

    • Network ATC wurde entwickelt, um eine optimale Netzwerkkonfiguration und den Datenverkehrsfluss sicherzustellen, indem Netzwerkdatenverkehr Absichtenverwendet wird. Netzwerk-ATC definiert, welche physischen Netzwerkadapterports für die verschiedenen Netzwerkdatenverkehrsabsichten (oder Typen) verwendet werden, z. B. für die Cluster--Verwaltungs-, Workload berechnenund Cluster Speicher Absichten.

    • Absichtsbasierte Richtlinien vereinfachen die Netzwerkkonfigurationsanforderungen, indem die Knotennetzwerkkonfiguration basierend auf Parametereingaben automatisiert wird, die als Teil des Azure Local Cloud Deployment Process angegeben werden.

  • Externe Kommunikation:

    • Wenn die Knoten oder Arbeitsauslastungen extern kommunizieren müssen, indem sie auf das Unternehmens-LAN, das Internet oder einen anderen Dienst zugreifen, leiten sie mithilfe der dualen ToR-Switches weiter. Dieser Vorgang wird im vorherigen abschnitt physischen Netzwerktopologie beschrieben.

    • Wenn die beiden ToR-Switches als Layer 3-Geräte fungieren, verarbeiten sie Routing und stellen verbindungen über den Cluster hinaus zum Edge-Border-Gerät bereit, z. B. Ihre Firewall oder Ihren Router.

    • Die Absicht des Verwaltungsnetzwerks verwendet die konvergierte virtuelle SET-Teamschnittstelle, wodurch die Clusterverwaltungs-IP-Adresse und Steuerungsebenenressourcen extern kommunizieren können.

    • Für die Absicht des Computenetzwerks können Sie ein oder mehrere logische Netzwerke in Azure mit den spezifischen VLAN-IDs für Ihre Umgebung erstellen. Die Workloadressourcen, z. B. VMs, verwenden diese IDs, um Zugriff auf das physische Netzwerk zu gewähren. Die logischen Netzwerke verwenden die beiden physischen Netzwerkadapterports, die mit einem SET-Team für die Berechnungs- und Verwaltungsabsichten zusammengeführt werden.

  • Speicherdatenverkehr:

    • Die physischen Knoten kommunizieren miteinander, indem zwei dedizierte Netzwerkadapterports verwendet werden, die mit den ToR-Switches verbunden sind, um hohe Bandbreite und Ausfallsicherheit für Speicherdatenverkehr bereitzustellen.

    • Die SMB1 und SMB2 Speicherports verbinden sich mit zwei separaten nicht routingfähigen (oder Layer 2)-Netzwerken. Jedes Netzwerk verfügt über eine bestimmte VLAN-ID, die mit der Konfiguration der Switchports auf der standardspeicher-VLAN-IDs der ToR-Switches übereinstimmen muss: 711 und 712.

    • Es gibt kein Standardgateway für die beiden Speicherabsicht-Netzwerkadapterports im Azure Stack HCI-Betriebssystem konfiguriert.

    • Jeder Knoten kann auf direkte Speicherplätze-Funktionen des Clusters zugreifen, z. B. physische Remotedatenträger, die im Speicherpool, virtuellen Datenträgern und Volumes verwendet werden. Der Zugriff auf diese Funktionen wird über das SMB-Direct RDMA-Protokoll über die beiden dedizierten Speichernetzwerkadapterports erleichtert, die in jedem Knoten verfügbar sind. SMB Multichannel wird zur Resilienz verwendet.

    • Diese Konfiguration bietet eine ausreichende Datenübertragungsgeschwindigkeit für speicherbezogene Vorgänge, z. B. die Aufrechterhaltung konsistenter Kopien von Daten für gespiegelte Volumes.

Netzwerkswitchanforderungen

Ihre Ethernet-Switches müssen die verschiedenen Spezifikationen erfüllen, die von Azure Local benötigt werden und vom Institute of Electrical and Electronics Engineers Standards Association (IEEE SA) festgelegt werden. Beispielsweise wird das Speichernetzwerk für multinode-Speicherswitched-Bereitstellungen für RDMA über RoCE v2- oder iWARP-verwendet. Dieser Prozess erfordert IEEE 802.1Qbb PFC, um die verlustlose Kommunikation für die Speicherdatenverkehrklassesicherzustellen. Ihre ToR-Switches müssen Unterstützung für IEEE 802.1Q für VLANs und IEEE 802.1AB für das Link Layer Discovery Protocol bereitstellen.

Wenn Sie beabsichtigen, vorhandene Netzwerkswitche für eine lokale Azure-Bereitstellung zu verwenden, lesen Sie die Liste der obligatorischen IEEE-Standards und -Spezifikationen, die die Netzwerkswitche und -konfiguration bereitstellen müssen. Überprüfen Sie beim Kauf neuer Netzwerkswitche die Liste der vom Hardwareanbieter zertifizierten Switchmodelle, die die Anforderungen an das lokale Azure-Netzwerkunterstützen.

IP-Adressanforderungen

Bei einer switched-Bereitstellung mit mehreren Knoten erhöht sich die Anzahl der benötigten IP-Adressen mit dem Hinzufügen jedes physischen Knotens bis zu maximal 16 Knoten innerhalb eines einzelnen Clusters. Um z. B. eine Konfiguration mit Zwei-Knoten-Speicherswitched-Konfiguration von Azure Local bereitzustellen, muss die Clusterinfrastruktur mindestens 11 x IP-Adressen zugewiesen werden. Weitere IP-Adressen sind erforderlich, wenn Sie Mikrosegmentierung oder softwaredefinierte Netzwerke verwenden. Weitere Informationen finden Sie unter Überprüfen der Anforderungen des Speicherreferenzmusters für zwei Knoten für ip-Adressanforderungen für azure Local.

Wenn Sie IP-Adressanforderungen für Azure Local entwerfen und planen, denken Sie daran, zusätzliche IP-Adressen oder Netzwerkbereiche zu berücksichtigen, die für Ihre Workload erforderlich sind, die für die Lokalen Azure-Instanzen und Infrastrukturkomponenten erforderlich sind. Wenn Sie beabsichtigen, AKS auf Azure Local bereitzustellen, lesen Sie von Azure Arc-Netzwerkanforderungenaktivierte AKS.

Überwachung

Um die Überwachung und Warnung zu verbessern, aktivieren Sie Überwachen von Insights in azure Local. Insights können skaliert werden, um mehrere lokale Cluster mithilfe einer konsistenten Azure-Umgebung zu überwachen und zu verwalten. Insights verwendet Clusterleistungsindikatoren und Ereignisprotokollkanäle, um die wichtigsten lokalen Azure-Features zu überwachen. Protokolle werden vom DCR erfasst, der über Monitor- und Log Analytics konfiguriert ist.

Insights für Azure Local wird mithilfe von Monitor- und Log Analytics erstellt, wodurch eine immer up-to-datum, skalierbare Lösung sichergestellt wird, die hochgradig anpassbar ist. Insights bietet Zugriff auf Standardarbeitsmappen mit grundlegenden Metriken sowie spezielle Arbeitsmappen, die für die Überwachung der wichtigsten Features von Azure Local erstellt wurden. Diese Komponenten bieten eine nahezu Echtzeitüberwachungslösung und ermöglichen die Erstellung von Diagrammen, die Anpassung von Visualisierungen durch Aggregation und Filterung sowie die Konfiguration von benutzerdefinierten Warnungsregeln für den Ressourcenstatus.

Updateverwaltung

Lokale Azure-Instanzen und die bereitgestellten Workloadressourcen, z. B. Azure Arc-VMs, müssen regelmäßig aktualisiert und gepatcht werden. Durch regelmäßiges Anwenden von Updates stellen Sie sicher, dass Ihre Organisation einen starken Sicherheitsstatus aufrecht erhält, und sie verbessern die gesamte Zuverlässigkeit und Supportierbarkeit Ihres Nachlasses. Es wird empfohlen, automatische und regelmäßige manuelle Bewertungen für die frühzeitige Ermittlung und Anwendung von Sicherheitspatches und Betriebssystemupdates zu verwenden.

Infrastrukturupdates

Azure Local wird kontinuierlich aktualisiert, um die Kundenerfahrung zu verbessern und neue Features und Funktionen hinzuzufügen. Dieser Prozess wird durch Release-Züge verwaltet, die vierteljährlich neue Basisplanbuilds liefern. Basisbuilds werden auf lokale Azure-Instanzen angewendet, um sie auf dem neuesten Stand zu halten. Zusätzlich zu regulären Basisbuildupdates wird Azure Local mit monatlichen Betriebssystemsicherheits- und Zuverlässigkeitsupdates aktualisiert.

Update Manager ist ein Azure-Dienst, mit dem Sie Updates für Azure Local anwenden, anzeigen und verwalten können. Dieser Dienst bietet einen Mechanismus zum Anzeigen von allAzure Local-Instanzen über Ihre gesamte Infrastruktur und Edgestandorte, indem sie das Azure-Portal verwenden, um eine zentrale Verwaltungsoberfläche bereitzustellen. Weitere Informationen finden Sie in den folgenden Ressourcen:

Es ist wichtig, regelmäßig nach neuen Treiber- und Firmwareupdates zu suchen, z. B. alle drei bis sechs Monate. Wenn Sie eine Premier-Lösungskategorieversion für Ihre lokale Azure-Hardware verwenden, werden die Paketupdates der Lösungs-Generator-Erweiterung in Update Manager integriert, um eine vereinfachte Updateerfahrung bereitzustellen. Wenn Sie überprüfte Knoten oder eine integrierte Systemkategorie verwenden, müssen Sie möglicherweise ein OEM-spezifisches Updatepaket herunterladen und ausführen, das die Firmware- und Treiberupdates für Ihre Hardware enthält. Wenn Sie ermitteln möchten, wie Updates für Ihre Hardware bereitgestellt werden, wenden Sie sich an Ihren Hardware-OEM oder SI-Partner.

Workload-Gastbetriebssystempatching

Sie können Azure Arc-VMs registrieren, die auf Azure Local bereitgestellt werden, indem Sie Azure Update Manager (AUM)- verwenden, um eine einheitliche Patchverwaltung zu ermöglichen, indem Sie denselben Mechanismus verwenden, mit dem die physischen Azure-Clusterknoten aktualisiert werden. Sie können AUM verwenden, um Gastwartungskonfigurationenzu erstellen. Diese Konfigurationen steuern Einstellungen wie die Neustarteinstellung Neustart bei Bedarf, den Zeitplan (Datumsangaben, Uhrzeiten und Wiederholungsoptionen) und entweder eine dynamische (Abonnement) oder eine statische Liste der Azure Arc-VMs für den Bereich. Diese Einstellungen steuern die Konfiguration für die Installation von Betriebssystemsicherheitspatches im Gastbetriebssystem Ihrer Workload-VM.

Betrachtungen

Diese Überlegungen implementieren die Säulen des Azure Well-Architected-Frameworks, das eine Reihe von leitden Tenets ist, die verwendet werden können, um die Qualität einer Workload zu verbessern. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie an Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Übersicht über die Zuverlässigkeitssäule.

Identifizieren der potenziellen Fehlerpunkte

Jede Architektur ist anfällig für Fehler. Sie können Fehler antizipieren und mit Entschärfungen mit Fehlermodusanalyse vorbereitet werden. In der folgenden Tabelle werden vier Beispiele für mögliche Fehlerpunkte in dieser Architektur beschrieben:

Bestandteil Risiko Wahrscheinlichkeit Effekt/Entschärfung/Hinweis Ausfall
Ausfall der lokalen Azure-Instanz Strom-, Netzwerk-, Hardware- oder Softwarefehler Mittel Um einen längeren Anwendungsausfall zu verhindern, der durch den Ausfall einer lokalen Azure-Instanz für geschäfts- oder unternehmenskritische Anwendungsfälle verursacht wird, sollte Ihre Workload mithilfe von HA- und DR-Prinzipien erstellt werden. Sie können z. B. branchenübliche Workload-Datenreplikationstechnologien verwenden, um mehrere Kopien persistenter Zustandsdaten zu verwalten, die mit mehreren Azure Arc-VMs oder AKS-Instanzen bereitgestellt werden, die auf separaten lokalen Azure-Instanzen und an separaten physischen Standorten bereitgestellt werden. Potenzieller Ausfall
Ausfall eines lokalen physischen Knotens in Azure Strom-, Hardware- oder Softwarefehler Mittel Um einen längeren Anwendungsausfall zu verhindern, der durch den Ausfall eines einzelnen lokalen Azure-Computers verursacht wird, sollte Ihre lokale Azure-Instanz mehrere physische Knoten aufweisen. Ihre Workloadkapazitätsanforderungen während der Clusterentwurfsphase bestimmen die Anzahl der Knoten. Es wird empfohlen, drei oder mehr Knoten zu haben. Außerdem wird empfohlen, die Drei-Wege-Spiegelung zu verwenden, bei der es sich um den Standardmäßigen Speicherresilienzmodus für Cluster mit drei oder mehr Knoten handelt. Um eine SPoF zu verhindern und die Arbeitslastresilienz zu erhöhen, stellen Sie mehrere Instanzen Ihrer Workload bereit, indem Sie zwei oder mehr Azure Arc-VMs oder Container-Pods verwenden, die in mehreren AKS-Arbeitsknoten ausgeführt werden. Wenn ein einzelner Knoten fehlschlägt, werden die Azure Arc-VMs und Workload/-Anwendungsdienste auf den verbleibenden physischen Onlineknoten im Cluster neu gestartet. Potenzieller Ausfall
Azure Arc VM- oder AKS-Workerknoten (Workload) Fehlkonfiguration Mittel Anwendungsbenutzer können sich nicht anmelden oder auf die Anwendung zugreifen. Fehlkonfigurationen sollten während der Bereitstellung abgefangen werden. Wenn diese Fehler während eines Konfigurationsupdates auftreten, muss das DevOps-Team Änderungen zurücksetzen. Sie können den virtuellen Computer bei Bedarf erneut bereitstellen. Die erneute Bereitstellung dauert weniger als 10 Minuten, kann jedoch je nach Bereitstellungstyp länger dauern. Potenzieller Ausfall
Konnektivität mit Azure Netzwerkausfall Mittel Der Cluster muss die Azure-Kontrollebene regelmäßig für Abrechnungs-, Verwaltungs- und Überwachungsfunktionen erreichen. Wenn Ihr Cluster die Verbindung mit Azure verliert, wird er in einem beeinträchtigten Zustand ausgeführt. Beispielsweise wäre es nicht möglich, neue Azure Arc-VMs oder AKS-Cluster bereitzustellen, wenn Ihr Cluster die Verbindung zu Azure verliert. Vorhandene Workloads, die auf dem HCI-Cluster ausgeführt werden, werden weiterhin ausgeführt, aber Sie sollten die Verbindung innerhalb von 48 bis 72 Stunden wiederherstellen, um einen unterbrechungsfreien Betrieb sicherzustellen. Nichts

Weitere Informationen finden Sie unter Empfehlungen für die Durchführung der Fehlermodusanalyse.

Zuverlässigkeitsziele

In diesem Abschnitt wird ein Beispielszenario beschrieben. Ein fiktiver Kunde namens Contoso Manufacturing verwendet diese Referenzarchitektur, um Azure Local bereitzustellen. Sie möchten ihre Anforderungen erfüllen und Workloads lokal bereitstellen und verwalten. Contoso Manufacturing hat ein internes Ziel auf Dienstebene (SLO) von 99,8%, dass die Beteiligten von Unternehmen und Anwendungen sich für ihre Dienste einig sind.

  • Ein SLO von 99,8% Betriebszeit oder Verfügbarkeit führt zu den folgenden Zeiträumen zulässiger Ausfallzeiten oder nicht verfügbarer Anwendungen für die Anwendungen, die mit Azure Arc-VMs bereitgestellt werden, die auf Azure Local ausgeführt werden:

    • Wöchentlich: 20 Minuten und 10 Sekunden

    • Monatlich: 1 Stunde, 26 Minuten und 56 Sekunden

    • Vierteljährlich: 4 Stunden, 20 Minuten und 49 Sekunden

    • Jährlich: 17 Stunden, 23 Minuten und 16 Sekunden

  • Um die SLO-Zielezu erfüllen, implementiert Contoso Manufacturing das Prinzip der geringsten Rechte (PoLP), um die Anzahl der lokalen Azure-Instanzadministratoren auf eine kleine Gruppe vertrauenswürdiger und qualifizierter Personen zu beschränken. Dieser Ansatz trägt dazu bei, Ausfallzeiten aufgrund versehentlicher oder versehentlicher Aktionen für Produktionsressourcen zu vermeiden. Darüber hinaus werden die Sicherheitsereignisprotokolle für lokale Active Directory Domain Services (AD DS)-Domänencontroller überwacht, um Änderungen der Benutzerkontengruppenmitgliedschaft zu erkennen und zu melden, die als Hinzufügen von und entfernen Aktionen, für die Administratoren der lokalen Azure-Instanz Gruppe mithilfe einer SIEM-Lösung (Security Information Event Management). Die Überwachung erhöht die Zuverlässigkeit und verbessert die Sicherheit der Lösung.

    Weitere Informationen finden Sie unter Empfehlungen für identitäts- und zugriffsverwaltung.

  • strenge Änderungskontrollverfahren für die Produktionssysteme von Contoso Manufacturing eingerichtet sind. Dieser Prozess erfordert, dass alle Änderungen vor der Implementierung in der Produktion in einer repräsentativen Testumgebung getestet und validiert werden. Alle Änderungen, die an den wöchentlichen Änderungsbeiratprozess übermittelt werden, müssen einen detaillierten Implementierungsplan (oder link zum Quellcode), risikobewertung, einen umfassenden Rollbackplan, Tests nach der Veröffentlichung und Überprüfung sowie klare Erfolgskriterien für eine Änderung enthalten, die überprüft oder genehmigt werden soll.

    Weitere Informationen finden Sie unter Empfehlungen für sichere Bereitstellungsmethoden.

  • monatliche Sicherheitspatches und vierteljährliche Basisplanupdates nur auf die lokale Azure-Produktionsinstanz angewendet werden, nachdem sie von der Vorproduktionsumgebung überprüft wurden. Update-Manager und das clusterfähige Aktualisierungsfeature automatisieren den Prozess der Verwendung VM-Livemigration, um Ausfallzeiten für geschäftskritische Workloads während der monatlichen Wartungsvorgänge zu minimieren. Standardbetriebsverfahren von Contoso Manufacturing erfordern, dass Sicherheits-, Zuverlässigkeits- oder Basisbuildupdates innerhalb von vier Wochen nach dem Veröffentlichungsdatum auf alle Produktionssysteme angewendet werden. Ohne diese Richtlinie können Produktionssysteme nicht mit monatlichen Betriebssystem- und Sicherheitsupdates auf dem neuesten Stand bleiben. Veraltete Systeme wirken sich negativ auf die Zuverlässigkeit und Sicherheit der Plattform aus.

    Weitere Informationen finden Sie unter Empfehlungen zum Einrichten einer Sicherheitsbasislinie.

  • Contoso Manufacturing implementiert täglich, wöchentliche und monatliche Sicherungen, um die letzten 6 x Tage täglicher Sicherungen (Montags bis Samstage), die letzten 3 x wöchentlichen (jeden Sonntag) und 3 x monatliche Sicherungen beizubehalten, wobei jede Sonntagswoche 4 aufbewahrt werden, um zu den Sicherungen monat 1, Monat 2 und Monat 3 zu werden, indem sie einen rollkalenderbasierten Zeitplan, der dokumentiert und auditierbar ist. Dieser Ansatz erfüllt contoso Manufacturing-Anforderungen für eine angemessene Balance zwischen der Anzahl der verfügbaren Datenwiederherstellungspunkte und der Reduzierung der Kosten für den Offsite- oder Cloud-Sicherungsspeicherdienst.

    Weitere Informationen finden Sie unter Empfehlungen zum Entwerfen einer Notfallwiederherstellungsstrategie.

  • Datensicherungs- und Wiederherstellungsprozesse werden alle sechs Monate für jedes Geschäftssystem getestet. Diese Strategie bietet Sicherheit, dass BCDR-Prozesse gültig sind und dass das Unternehmen geschützt ist, wenn ein Rechenzentrums-Notfall oder Cybervorfall auftritt.

    Weitere Informationen finden Sie unter Empfehlungen zum Entwerfen einer Zuverlässigkeitsteststrategie.

  • Die betrieblichen Prozesse und Verfahren, die zuvor im Artikel beschrieben wurden, und die Empfehlungen im Well-Architected Framework-Diensthandbuch für Azure Localermöglichen Es Contoso Manufacturing, ihre 99,8% SLO-Ziel zu erfüllen und Azure Local und Workload-Bereitstellungen auf mehreren Produktionsstandorten, die auf der ganzen Welt verteilt sind, effektiv zu skalieren und zu verwalten.

    Weitere Informationen finden Sie unter Empfehlungen zum Definieren von Zuverlässigkeitszielen.

Redundanz

Berücksichtigen Sie eine Workload, die Sie in einer einzelnen lokalen Azure-Instanz als lokal redundante Bereitstellungbereitstellen. Der Cluster bietet hohe Verfügbarkeit auf Plattformebene, sie müssen den Cluster jedoch in einem einzigen Rack bereitstellen. Für geschäftskritische oder unternehmenskritische Anwendungsfälle empfehlen wir, mehrere Instanzen einer Workload oder eines Diensts in zwei oder mehr separaten lokalen Azure-Instanzen bereitzustellen, idealerweise an separaten physischen Standorten.

Verwenden Sie Branchenstandardmuster für Hochverfügbarkeitsmuster für Workloads, die aktive/passive Replikation, synchrone Replikation oder asynchrone Replikation wie SQL Server Always Onbereitstellen. Sie können auch eine externe Netzwerklastenausgleichstechnologie (NLB) verwenden, die Benutzeranforderungen über die mehrere Workloadinstanzen weitergibt, die auf lokalen Azure-Instanzen ausgeführt werden, die Sie an separaten physischen Standorten bereitstellen. Erwägen Sie die Verwendung eines externen Partner-NLB-Geräts. Oder Sie können die Lastenausgleichsoptionen bewerten, die das Datenverkehrsrouting für Hybrid- und lokale Dienste unterstützen, z. B. eine Azure-Anwendungsgatewayinstanz, die Azure ExpressRoute oder einen VPN-Tunnel zum Herstellen einer Verbindung mit einem lokalen Dienst verwendet.

Weitere Informationen finden Sie unter Empfehlungen für das Entwerfen von Redundanz-.

Sicherheit

Die Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Sicherheitssäule.

Zu den Sicherheitsaspekten gehören:

  • Eine sichere Grundlage für die lokale Azure-Plattform: Azure Local ist ein standardmäßiges Produkt, das überprüfte Hardwarekomponenten mit einem TPM, UEFI und sicherem Start verwendet, um eine sichere Grundlage für die Lokale Azure-Plattform und Workloadsicherheit zu erstellen. Wenn Sie mit den Standardsicherheitseinstellungen bereitgestellt werden, verfügt Azure Local über Windows Defender-Anwendungssteuerung, Credential Guard und BitLocker. Um die Delegierung von Berechtigungen mithilfe von PoLP zu vereinfachen, verwenden Sie lokalen, rollenbasierten Zugriffssteuerungsrollen (RBAC) wie Azure Local Administrator für Plattformadministratoren und Azure Local VM Contributor oder Azure Local VM Reader für Workload-Operatoren.

  • Standardsicherheitseinstellungen: azure Local security default wendet Standardsicherheitseinstellungen für Ihre lokale Azure-Instanz während der Bereitstellung an und ermöglicht die Driftsteuerung, die Knoten in einem bekannten zustand zu halten. Sie können die Sicherheitsstandardeinstellungen verwenden, um Clustersicherheit, Driftsteuerung und gesicherte Kernservereinstellungen auf Ihrem Cluster zu verwalten.

  • Sicherheitsereignisprotokolle: Azure Local syslog forwarding integriert in Sicherheitsüberwachungslösungen, indem relevante Sicherheitsereignisprotokolle abgerufen werden, um Ereignisse für die Aufbewahrung in Ihrer eigenen SIEM-Plattform zu aggregieren und zu speichern.

  • Schutz vor Bedrohungen und Sicherheitsrisiken: Defender für Cloud schützt Ihre lokale Azure-Instanz vor verschiedenen Bedrohungen und Sicherheitsrisiken. Dieser Dienst trägt dazu bei, den Sicherheitsstatus Ihrer lokalen Azure-Umgebung zu verbessern und vor vorhandenen und sich entwickelnden Bedrohungen zu schützen.

  • Bedrohungserkennung und -behebung: Microsoft Advanced Threat Analytics Bedrohungen erkennt und korrigiert, z. B. für AD DS-Ziele, die Authentifizierungsdienste für Lokale Azure-Instanzknoten und ihre Windows Server-VM-Workloads bereitstellen.

  • Netzwerkisolation: Isolieren Von Netzwerken bei Bedarf. Sie können beispielsweise mehrere logische Netzwerke bereitstellen, die separate VLANs und Netzwerkadressbereiche verwenden. Wenn Sie diesen Ansatz verwenden, stellen Sie sicher, dass das Verwaltungsnetzwerk jedes logische Netzwerk und VLAN erreichen kann, damit Azure Local Instance Nodes über die ToR-Switches oder Gateways mit den VLAN-Netzwerken kommunizieren können. Diese Konfiguration ist für die Verwaltung der Workload erforderlich, z. B. das Zulassen, dass Infrastrukturverwaltungs-Agents mit dem Workload-Gastbetriebssystem kommunizieren können.

    Weitere Informationen finden Sie unter Empfehlungen zum Erstellen einer Segmentierungsstrategie.

Kostenoptimierung

Bei der Kostenoptimierung geht es um Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Kostenoptimierungssäule.

Zu den Überlegungen zur Kostenoptimierung gehören:

  • Abrechnungsmodell im Cloudstil für die Lizenzierung: Azure Local pricing follows the monthly subscription billing model with a flat rate per physical processor core in an Azure Local instance. Zusätzliche Nutzungsgebühren gelten, wenn Sie andere Azure-Dienste verwenden. Wenn Sie über lokale Kernlizenzen für windows Server Datacenter Edition mit aktiver Software Assurance verfügen, können Sie diese Lizenzen austauschen, um Azure Local Instance- und Windows Server VM-Abonnementgebühren zu aktivieren.

  • Automatische VM-Gastpatching für Virtuelle Azure Arc-VMs: Dieses Feature trägt dazu bei, den Aufwand für manuelles Patchen und die damit verbundenen Wartungskosten zu reduzieren. Diese Aktion trägt nicht nur dazu bei, das System sicherer zu machen, sondern optimiert auch die Ressourcenzuordnung und trägt zur Gesamtkosteneffizienz bei.

  • Kostenüberwachungskonsolidierung: Verwenden Sie Insights für azure Local und Patch mit Update Manager für Azure Local. Insights verwendet Monitor, um umfangreiche Metriken und Warnungsfunktionen bereitzustellen. Die Lebenszyklus-Manager-Komponente von Azure Localintegrates mit Update Manager, um die Aufgabe zu vereinfachen, Ihre Cluster auf dem neuesten Stand zu halten, indem Aktualisierungsworkflows für verschiedene Komponenten in einer einzigen Oberfläche konsolidiert werden. Verwenden Sie Monitor und Update Manager, um die Ressourcenzuordnung zu optimieren und zur Gesamtkosteneffizienz beizutragen.

    Weitere Informationen finden Sie unter Empfehlungen zur Optimierung der Personalzeit.

  • Anfängliche Workloadkapazität und Wachstum: Berücksichtigen Sie bei der Planung Ihrer lokalen Azure-Bereitstellung Ihre anfängliche Workloadkapazität, Resilienzanforderungen und zukünftige Wachstumsüberlegungen. Überlegen Sie sich, ob die Verwendung einer Zwei- oder Drei-Knoten-Speicherswitchless-Architektur Kosten reduzieren könnte, z. B. das Entfernen der Notwendigkeit, Netzwerkswitche der Speicherklasse zu beschaffen. Das Beschaffen zusätzlicher Speicherklassennetzwerkswitche kann eine teure Komponente neuer Bereitstellungen der lokalen Azure-Instanz sein. Stattdessen können Sie vorhandene Switches für Verwaltungs- und Computenetzwerke verwenden, die die Infrastruktur vereinfachen. Wenn Ihre Workloadkapazität und Resilienz nicht über eine Drei-Knoten-Konfiguration hinaus skaliert werden müssen, sollten Sie überlegen, ob Sie vorhandene Switches für die Verwaltung und Die Berechnung von Netzwerken verwenden können, und die drei Knoten speicherfreie Architektur verwenden, um Azure Local bereitzustellen.

    Weitere Informationen finden Sie unter Empfehlungen zur Optimierung der Komponentenkosten.

Trinkgeld

Sie können mit dem Azure-Hybridvorteil Kosten sparen, wenn Sie über Windows Server Datacenter-Lizenzen mit aktiver Software Assurance verfügen. Weitere Informationen finden Sie unter Azure Hybrid Benefit for Azure Local.

Operative Exzellenz

Operative Exzellenz deckt die Betriebsprozesse ab, die eine Anwendung bereitstellen und in der Produktion ausgeführt werden. Weitere Informationen finden Sie unter Übersicht über die operative Exzellenzsäule.

Zu den Überlegungen zur betrieblichen Exzellenz gehören:

Leistungseffizienz

Die Leistungseffizienz ist die Fähigkeit Ihrer Arbeitsauslastung, um die Anforderungen der Benutzer effizient zu erfüllen. Weitere Informationen finden Sie unter Übersicht über die Säule "Leistungseffizienz".

Zu den Überlegungen zur Leistungseffizienz gehören:

  • Workload-Speicherleistung: Erwägen Sie die Verwendung des tools DiskSpd, um die Speicherleistungsfunktionen einer lokalen Azure-Instanz zu testen. Sie können das VMFleet-Tool verwenden, um Last zu generieren und die Leistung eines Speichersubsystems zu messen. Bewerten Sie, ob Sie VMFleet- verwenden sollten, um die Leistung des Speichersubsystems zu messen.

    • Es wird empfohlen, einen Basisplan für die Leistung Ihrer lokalen Azure-Instanzen festzulegen, bevor Sie Produktionsworkloads bereitstellen. DiskSpd verwendet verschiedene Befehlszeilenparameter, mit denen Administratoren die Speicherleistung des Clusters testen können. Die Hauptfunktion von DiskSpd besteht darin, Lese- und Schreibvorgänge und Ausgabeleistungsmetriken wie Latenz, Durchsatz und IOPs auszugeben.

      Weitere Informationen finden Sie unter Empfehlungen für Leistungstests.

  • Workload-Speicherresilienz: Berücksichtigen Sie die Vorteile Speicherresilienz, Nutzungseffizienz (oder Kapazität) und Leistung. Die Planung für lokale Azure-Volumes umfasst die Identifizierung des optimalen Gleichgewichts zwischen Resilienz, Nutzungseffizienz und Leistung. Möglicherweise ist es schwierig, dieses Gleichgewicht zu optimieren, da die Maximierung eines dieser Merkmale in der Regel negative Auswirkungen auf eines oder mehrere der anderen Merkmale hat. Durch die Erhöhung der Resilienz wird die verwendbare Kapazität reduziert. Daher kann die Leistung je nach ausgewähltem Resilienztyp variieren. Wenn Resilienz und Leistung die Priorität haben und wenn Sie drei oder mehr Knoten verwenden, verwendet die Standardspeicherkonfiguration drei Wege-Spiegelung für Infrastruktur- und Benutzervolumes.

    Weitere Informationen finden Sie unter Empfehlungen für die Kapazitätsplanung.

  • Netzwerkleistungsoptimierung: Berücksichtigen Sie die Netzwerkleistungsoptimierung. Achten Sie im Rahmen Ihres Designs darauf, die projizierte Netzwerkdatenverkehr Bandbreitenzuteilung einzuschließen, wenn Sie ihre optimale Netzwerkhardwarekonfigurationbestimmen.

    • Um die Computeleistung in Azure Local zu optimieren, können Sie die GPU-Beschleunigung verwenden. Die GPU-Beschleunigung ist von Vorteil für hochleistungsstarkeN AI- oder Machine Learning-Workloads, die Datenerkenntnisse oder Ableitungen umfassen. Diese Workloads erfordern die Bereitstellung an Edgestandorten aufgrund von Überlegungen wie Datenschwere oder Sicherheitsanforderungen. Bei einer Hybridbereitstellung oder einer lokalen Bereitstellung ist es wichtig, Ihre Workload-Leistungsanforderungen, einschließlich GPUs, zu berücksichtigen. Mit diesem Ansatz können Sie die richtigen Dienste auswählen, wenn Sie Ihre lokalen Azure-Instanzen entwerfen und erwerben.

      Weitere Informationen finden Sie unter Empfehlungen für die Auswahl der richtigen Dienste.

Bereitstellen dieses Szenarios

Der folgende Abschnitt enthält eine Beispielliste der allgemeinen Aufgaben oder typischen Workflows, die zum Bereitstellen von Azure Local verwendet werden, einschließlich der erforderlichen Aufgaben und Überlegungen. Diese Workflowliste ist nur als Beispielleitfaden gedacht. Es handelt sich nicht um eine vollständige Liste aller erforderlichen Aktionen, die je nach organisatorischen, geografischen oder projektspezifischen Anforderungen variieren können.

Szenario: Es gibt eine Projekt- oder Anwendungsfallanforderung für die Bereitstellung einer Hybrid-Cloudlösung an einem lokalen oder Edgestandort, um lokale Computefunktionen für Die Datenverarbeitungsfunktionen bereitzustellen und azure-konsistente Verwaltungs- und Abrechnungsfunktionen zu verwenden. Weitere Details finden Sie im potenziellen Anwendungsfällen Abschnitt dieses Artikels. Bei den verbleibenden Schritten wird davon ausgegangen, dass Azure Local die ausgewählte Infrastrukturplattformlösung für das Projekt ist.

  1. Sammeln Sie Arbeitsauslastung und Anwendungsfallanforderungen von relevanten Projektbeteiligten. Mit dieser Strategie kann das Projekt bestätigen, dass die Features und Funktionen von Azure Local die Anforderungen an Workload, Leistung und Funktionalität erfüllen. Dieser Überprüfungsprozess sollte das Verständnis der Workloadskala oder der Größe und der erforderlichen Features wie Azure Arc VMs, AKS, Azure Virtual Desktop oder Azure Arc-fähigen Data Services oder Azure Arc-fähigen Machine Learning-Dienst umfassen. Die RTO- und RPO-Werte (Workload RTO) und andere nicht funktionsfähige Anforderungen (Leistungs-/Lastskalierbarkeit) sollten im Rahmen dieses Anforderungssammelschritts dokumentiert werden.

  2. Überprüfen Sie die Azure Local Sizer-Ausgabe für die empfohlene Hardwarepartnerlösung. Diese Ausgabe enthält Details der empfohlenen physischen Serverhardwareerstellung und -modell, die Anzahl der physischen Knoten und die Spezifikationen für die CPU-, Arbeitsspeicher- und Speicherkonfiguration der einzelnen physischen Knoten, die zum Bereitstellen und Ausführen Ihrer Workloads erforderlich sind.

  3. Verwenden Sie das Azure Local-Größenanpassungstool, um ein neues Projekt zu erstellen, das den Workloadtyp modelliert undskaliert. Dieses Projekt umfasst die Größe und Anzahl der virtuellen Computer und deren Speicheranforderungen. Diese Details werden zusammen mit Auswahlmöglichkeiten für den Systemtyp, die bevorzugte CPU-Familie und Ihre Resilienzanforderungen für hohe Verfügbarkeits- und Speicherfehlertoleranz eingegeben, wie im vorherigen Abschnitt "Clusterentwurfsoptionen" erläutert.

  4. Überprüfen Sie die Azure Local Sizer-Ausgabe für die empfohlene Hardwarepartnerlösung. Diese Lösung enthält Details der empfohlenen physischen Serverhardware (Make and Model), die Anzahl der physischen Knoten und die Spezifikationen für die CPU, den Arbeitsspeicher und die Speicherkonfiguration der einzelnen physischen Knoten, die zum Bereitstellen und Ausführen Ihrer Workloads erforderlich sind.

  5. Wenden Sie sich an den Hardware-OEM oder SI-Partner, um die Eignung der empfohlenen Hardwareversion im Vergleich zu Ihren Workloadanforderungenweiter zu qualifizieren. Wenn verfügbar, verwenden Sie OEM-spezifische Größenanpassungstools, um OEM-spezifische Hardwareanpassungsanforderungen für die vorgesehenen Workloads zu ermitteln. Dieser Schritt enthält in der Regel Diskussionen mit dem Hardware-OEM oder SI-Partner für die kommerziellen Aspekte der Lösung. Zu diesen Aspekten gehören Angebote, Verfügbarkeit der Hardware, Leadzeiten und alle professionellen oder Mehrwertdienste, die der Partner bereitstellt, um Ihre Projekt- oder Geschäftsergebnisse zu beschleunigen.

  6. Stellen Sie zwei ToR-Switches für die Netzwerkintegrationbereit. Für Lösungen mit hoher Verfügbarkeit müssen zwei ToR-Switches bereitgestellt werden. Jeder physische Knoten erfordert vier NICs, von denen zwei RDMA-fähig sein müssen, wodurch zwei Verbindungen von jedem Knoten zu den beiden ToR-Switches bereitgestellt werden. Zwei NICs, die mit jedem Switch verbunden sind, werden für ausgehende Nord-Süd-Konnektivität für die Compute- und Verwaltungsnetzwerke zusammengeführt. Die anderen beiden RDMA-fähigen NICs sind für den Ost-West-Speicherverkehr vorgesehen. Wenn Sie beabsichtigen, vorhandene Netzwerkswitche zu verwenden, stellen Sie sicher, dass sich die Herstellung und das Modell Ihrer Switches in der genehmigten Liste der Netzwerkswitche befinden, die von Azure Localunterstützt werden.

  7. Arbeiten Sie mit dem Hardware-OEM oder SI-Partner zusammen, um die Lieferung der Hardwarezu vereinbaren. Der SI-Partner oder Ihre Mitarbeiter sind dann erforderlich, um die Hardware in Ihr lokales Rechenzentrum oder Ihren Edgestandort zu integrieren, z. B. Racking und Stapeln der Hardware, des physischen Netzwerks und der Stromversorgung für die physischen Knoten.

  8. Ausführen der Bereitstellung der lokalen Azure-Instanz. Je nach ausgewählter Lösungsversion (Premier-Lösung, integriertes System oder validierte Knoten) können entweder der Hardwarepartner, DER SI-Partner oder Ihre Mitarbeiter die lokale Azure-Softwarebereitstellen. Dieser Schritt beginnt mit dem Onboarding der physischen Knoten Azure Stack HCI OS in Azure Arc-fähige Server und startet dann den Azure Local Cloud Deployment Process. Kunden und Partner können eine Supportanfrage direkt mit Microsoft im Azure-Portal auslösen, indem Sie je nach Art der Anfrage und der Hardwarelösungskategorie das Symbol Support + Problembehandlung + Problembehandlung auswählen oder sich an ihren Hardware-OEM- oder SI-Partner wenden.

    Trinkgeld

    GitHub-Logo Das Azure Stack HCI OS, Version 23H2 Systemreferenzimplementierung veranschaulicht, wie eine switched Multiserver-Bereitstellung von Azure Local mithilfe einer ARM-Vorlage und Parameterdatei bereitgestellt wird. Alternativ das Bicep-Beispiel veranschaulicht, wie eine Bicep-Vorlage zum Bereitstellen einer lokalen Azure-Instanz verwendet wird, einschließlich der erforderlichen Ressourcen.

  9. Bereitstellen von hochverwendigen Workloads auf Azure Local mithilfe von Azure-Portal-, CLI- oder ARM + Azure Arc-Vorlagen für Automatisierungs-. Verwenden Sie den benutzerdefinierten Speicherort Ressource des neuen HCI-Clusters als Zielregion, wenn Sie Workloadressourcen wie Azure Arc VMs, AKS, Azure Virtual Desktop-Sitzungshosts oder andere Azure Arc-fähige Dienste bereitstellen, die Sie über AKS-Erweiterungen und Containerisierung auf Azure Local aktivieren können.

  10. Monatliche Updates installieren, um die Sicherheit und Zuverlässigkeit der Plattformzu verbessern. Um Ihre lokalen Azure-Instanzen auf dem neuesten Stand zu halten, ist es wichtig, Microsoft-Softwareupdates und Hardware-OEM-Treiber und Firmwareupdates zu installieren. Diese Updates verbessern die Sicherheit und Zuverlässigkeit der Plattform. Update-Manager wendet die Updates an und bietet eine zentrale und skalierbare Lösung zum Installieren von Updates in einem einzelnen Cluster oder mehreren Clustern. Wenden Sie sich an Ihren Hardware-OEM-Partner, um den Prozess für die Installation von Hardwaretreiber- und Firmwareupdates zu ermitteln, da dieser Prozess je nach dem ausgewählten Hardwarelösungskategorietyp (Premier-Lösung, integriertes System oder validierte Knoten) variieren kann. Weitere Informationen finden Sie unter Infrastrukturupdates.

Nächste Schritte

Produktdokumentation:

Produktdokumentation für Details zu bestimmten Azure-Diensten:

Microsoft Learn-Module: