Hosten von ASP.NET Core in einer Webfarm

Von Chris Ross

Eine Webfarm ist eine Gruppe von mindestens zwei Webservern (oder Knoten), die mehrere Instanzen einer App hostet. Wenn eine Webfarm Benutzeranforderungen empfängt, verteilt ein Lastenausgleichsmodul die Anforderungen auf die Knoten der Webfarm. Webfarmen verbessern:

  • Zuverlässigkeit/Verfügbarkeit: Wenn bei mindestens einem Knoten ein Fehler auftritt, kann der Lastenausgleich Anforderungen zur weiteren Verarbeitung an andere funktionierende Knoten weiterleiten.
  • Kapazität/Leistung: Mehrere Knoten können mehr Anforderungen verarbeiten als ein einzelner Server. Das Lastenausgleichsmodul verteilt den Workload, indem Anforderungen auf die Knoten verteilt werden.
  • Skalierbarkeit: Wenn mehr oder weniger Kapazität benötigt wird, kann die Anzahl der aktiven Knoten entsprechend der Arbeitsauslastung erhöht oder verringert werden. Webfarmtechnologien wie Azure App Service können Knoten automatisch auf Systemadministratoranforderungen hin hinzufügen oder entfernen bzw. diese Vorgänge komplett ohne manuelles Eingreifen ausführen.
  • Wartbarkeit: Knoten einer Webfarm können auf einer Reihe von gemeinsamen Diensten basieren, wodurch die Systemverwaltung vereinfacht wird. Beispielsweise können die Knoten einer Webfarm auf einem einzigen Datenbankserver und einer gemeinsamen Netzwerkadresse für statische Ressourcen wie Images und herunterladbare Dateien basieren.

Dieses Thema beschreibt die Konfiguration und Abhängigkeiten für ASP.NET Core-Apps, die in einer Webfarm gehostet werden und auf freigegebenen Ressourcen basieren.

Allgemeine Konfiguration

Hosten und Bereitstellen von ASP.NET Core
Erfahren Sie, wie Sie Hostingumgebungen einrichten und ASP.NET Core-Apps bereitstellen. Konfigurieren Sie einen Prozess-Manager auf jedem Knoten der Webfarm, um App-Starts und -Neustarts zu automatisieren. Jeder Knoten benötigt die ASP.NET Core-Laufzeit. Weitere Informationen finden Sie in der Dokumentation Hosten und Bereitstellen von ASP.NET Core.

Konfigurieren von ASP.NET Core zur Verwendung mit Proxyservern und Lastenausgleich
Informationen zur Konfiguration von hinter Proxyservern und Lastenausgleichsmodulen gehosteten Apps, wobei wichtige Anforderungsinformationen häufig verdeckt werden

Bereitstellen von ASP.NET Core-Apps in Azure App Service
Azure App Service ist ein Microsoft Cloud Computing-Plattformdienst zum Hosten von Web-Apps. Dazu gehört auch ASP.NET Core. App Service ist eine vollständig verwaltete Plattform, die automatisches Skalieren, Lastenausgleich, Patchen und Continuous Deployment bietet.

App-Daten

Wenn eine App auf mehrere Instanzen skaliert wird, muss der App-Status möglicherweise über Knoten hinweg freigegeben werden. Im Falle eines Übergangsstatus sollten Sie IDistributedCache freigeben. Wenn der freigegebene Status Persistenz erfordert, speichern Sie ihn in einer Datenbank.

Erforderliche Konfiguration

Schutz von Daten und Zwischenspeichern benötigen eine in einer Webfarm bereitgestellte App-Konfiguration.

Schutz von Daten

Der ASP.NET Core-Datenschutz wird von Apps verwendet, um Daten zu schützen. Der Schutz von Daten basiert auf einem Satz kryptografischer Schlüssel in einer Schlüsselsammlung. Wenn das System zum Schutz von Daten initialisiert wird, werden Standardeinstellungen angewendet, die die Schlüsselsammlung lokal speichern. In der Standardkonfiguration wird eine eindeutige Schlüsselsammlung auf jedem Knoten der Webfarm gespeichert. Folglich kann kein Webfarmknoten Daten entschlüsseln, die von einer App auf einem anderen Knoten verschlüsselt werden. Die Standardkonfiguration eignet sich in der Regel nicht für das Hosten von Apps in einer Webfarm. Eine Alternative zur Implementierung einer freigegebenen Schlüsselsammlung besteht darin, Benutzeranforderungen immer an denselben Knoten weiterzuleiten. Weitere Informationen zur Systemkonfiguration zum Schutz von Daten für Webfarmbereitstellungen finden Sie unter Konfigurieren des Schutzes von Daten in ASP.NET Core.

Zwischenspeicherung

In einer Webfarmumgebung muss der Zwischenspeichermechanismus zwischengespeicherte Elemente über die Webfarmknoten hinweg freigeben. Das Zwischenspeichern muss auf einem Redis Cache, einer freigegebenen SQL Server-Datenbank oder einer benutzerdefinierten Zwischenspeicherimplementierung basieren, die zwischengespeicherte Elemente über die Webfarm hinweg freigibt. Weitere Informationen finden Sie unter Verteiltes Zwischenspeichern in ASP.NET Core.

Abhängige Komponenten

Die folgenden Szenarien erfordern keine zusätzliche Konfiguration, hängen jedoch von Technologien ab, die eine Webfarmkonfiguration benötigen.

Szenario Abhängig von…
Authentifizierung Datenschutz (siehe Konfigurieren des Schutzes von Daten in ASP.NET Core).

Weitere Informationen finden Sie unter Verwenden der cookie-Authentifizierung ohne ASP.NET Core Identity und Freigeben der Authentifizierungs-cookies für ASP.NET-Apps.
Identity Authentifizierung und Datenbankkonfiguration.

Weitere Informationen finden Sie unter Einführung in Identity in ASP.NET Core .
Sitzung Datenschutz, verschlüsselte cookies (siehe Konfigurieren des Schutzes von Daten in ASP.NET Core) und Zwischenspeicherung (siehe Verteiltes Zwischenspeichern in ASP.NET Core).

Weitere Informationen finden Sie unter Sitzungs- und Zustandsverwaltung: Sitzungszustand.
TempData Datenschutz, verschlüsselte cookies (siehe Konfigurieren des Schutzes von Daten in ASP.NET Core) oder Sitzung (siehe Sitzungs- und Statusverwaltung: Sitzungszustand).

Weitere Informationen finden Sie unter Sitzungs- und Zustandsverwaltung: TempData.
Fälschungssicherheit Datenschutz (siehe Konfigurieren des Schutzes von Daten in ASP.NET Core).

Weitere Informationen finden Sie unter Prevent Cross-Site Request Forgery (XSRF/CSRF) Attacks in ASP.NET Core (Verhindern von websiteübergreifenden Anforderungsfälschungen (XSRF/CSRF) in ASP.NET Core).

Problembehandlung

Schutz von Daten und Zwischenspeichern

Wenn der Schutz von Daten oder Zwischenspeichern für eine Webfarmumgebung nicht konfiguriert wurde, treten beim Verarbeiten von Anforderungen zeitweilig Fehler auf. Dies geschieht, weil Knoten nicht dieselben Ressourcen teilen und Benutzeranforderungen nicht immer an denselben Knoten zurückgeleitet werden.

Gehen Sie beispielsweise von einem Benutzer aus, der sich mithilfe der cookieauthentifizierung bei der App anmeldet. Der Benutzer meldet sich in der App auf einem Webfarmknoten an. Wenn seine nächste Anforderung auf demselben Knoten eintrifft, auf dem er sich angemeldet hat, kann die App das Authentifizierungscookie entschlüsseln und den Zugriff auf die App-Ressource gewähren. Wenn seine nächste Anforderung auf einem anderen Knoten eintrifft, kann die App das Authentifizierungscookie nicht auf dem Knoten entschlüsseln, auf dem der Benutzer angemeldet ist, und die Autorisierung für die angeforderte Ressource schlägt fehl.

Wenn eines der folgenden Symptome zeitweilig auftritt, ist das Problem in der Regel auf eine falsche Konfiguration zum Schutz von Daten oder zum Zwischenspeichern für eine Webfarmumgebung zurückgeführt:

  • Authentifizierungsfehler: Das Authentifizierungscookie ist falsch konfiguriert oder kann nicht entschlüsselt werden. OAuth (Facebook, Microsoft und Twitter) oder OpenIdConnect-Anmeldungen schlagen mit der Fehlermeldung „Korrelationsfehler“ fehl.
  • Authentifizierungsfehler: Identity geht verloren.
  • Im Sitzungszustand gehen Daten verloren.
  • Zwischengespeicherte Elemente werden nicht angezeigt.
  • Fehler bei TempData.
  • Fehler bei POSTs: Die Überprüfung zur Fälschungssicherheit schlägt fehl.

Weitere Informationen zur Datenschutzkonfiguration für Webfarmbereitstellungen finden Sie unter Konfigurieren des Schutzes von Daten in ASP.NET Core. Weitere Informationen zum Konfigurieren der Zwischenspeicherung für Webfarmbereitstellungen finden Sie unter Verteiltes Zwischenspeichern in ASP.NET Core.

Abrufen von Daten aus Apps

Wenn die Webfarm-Apps in der Lage sind, auf Anforderungen zu reagieren, erhalten Sie Anforderungen, Verbindungen und zusätzliche Daten von den Apps über die Inlinemiddleware des Terminals. Weitere Informationen und Beispielcode finden Sie unter Problembehandlung und Debuggen von ASP.NET Core-Projekten.

Zusätzliche Ressourcen