Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Multimandant-Systeme teilen Ressourcen zwischen zwei oder mehr Mandanten. Da Mandanten dieselben freigegebenen Ressourcen verwenden, kann sich die Aktivität eines Mandanten negativ auf die Verwendung des Systems eines anderen Mandanten auswirken.
Kontext und Problem
Wenn Sie einen Dienst erstellen, den mehrere Kunden oder Mandanten teilen, können Sie ihn so erstellen, dass er multitenantiert wird. Ein Vorteil von Multi-Tenant-Systemen besteht darin, dass Ressourcen in einem Pool zusammengefasst und von mehreren Mandanten gemeinsam genutzt werden können. Diese Ressourcenfreigabe führt häufig zu geringeren Kosten und einer verbesserten Effizienz. Wenn ein einzelner Mandant jedoch eine unverhältnismäßige Menge der im System verfügbaren Ressourcen verwendet, kann die Gesamtleistung des Systems beeinträchtigt werden. Das laute Nachbarproblem tritt auf, wenn die Leistung eines Mandanten aufgrund der Aktivitäten eines anderen Mandanten beeinträchtigt wird.
Betrachten Sie ein Beispiel-Mehrmandantensystem mit zwei Mandanten. Die Nutzungsmuster von Mandant A und Mandant B stimmen überein. Zu Spitzenzeiten verwendet Mandant A alle Ressourcen des Systems, was bedeutet, dass alle Anforderungen, die Mandant B vorgibt, fehlschlagen. Mit anderen Worten, die Gesamtressourcennachfrage ist höher als die Kapazität des Systems:
Wahrscheinlich hat der Mandant, dessen Anforderung zuerst eingeht, Vorrang. Dann kann der andere Mieter ein lautes Nachbarproblem haben. Alternativ kann die Leistung beider Mandanten verschlechtert werden.
Das laute Nachbarproblem tritt auch auf, wenn jeder einzelne Mandant nur einen kleinen Teil der Systemkapazität verbraucht. Die kombinierte Ressourcenauslastung vieler Mandanten kann jedoch zu einem Spitzenwert bei der Gesamtnutzung führen:
Dieses Szenario kann auftreten, wenn Sie über mehrere Mandanten verfügen, die alle über ähnliche Nutzungsmuster verfügen oder wenn Sie keine ausreichende Kapazität für die kollektive Auslastung des Systems bereitgestellt haben.
Solution
Die Gemeinsame Nutzung einer einzelnen Ressource birgt das Risiko von lauten Benachbarten Problemen, die Sie nicht vollständig vermeiden können. Es gibt jedoch einige Schritte, die sowohl Clients als auch Dienstanbieter ausführen können, um die Wahrscheinlichkeit von lauten Nachbarproblemen zu verringern oder ihre Auswirkungen zu mindern.
Aktionen, die Kunden durchführen können
Stellen Sie sicher, dass Ihre Anwendung die Dienstdrosselung verarbeitet, um unnötige Anforderungen an den Dienst zu reduzieren. Stellen Sie sicher, dass Ihre Anwendung bewährte Methoden zum Wiederholen von Anforderungen befolgt, die eine vorübergehende Fehlerantwort erhalten haben.
Erwerben Sie reservierte Kapazität, falls dies eine Option ist. Wenn Sie z. B. Azure Cosmos DB verwenden, kaufen Sie reservierten Durchsatz.
Migrieren Sie zu einer Dienstebene mit stärkeren Isolationsgarantien, falls verfügbar. Wenn Sie z. B. Azure Service Bus verwenden, wechseln Sie zur Premium-Stufe. Wenn Sie Azure Managed Redis mit dedizierter Infrastruktur und privaten Netzwerken verwenden, helfen Sie, laute Nachbareffekte zu beseitigen.
Migrieren Sie zu einer Single-Tenant-Instanz des Dienstes. Wenn Sie z. B. Azure ExpressRoute verwenden, trennen Sie separate Schaltkreise für Umgebungen, die für die Leistung sensibel sind.
Aktionen, die Dienstanbieter durchführen können
Überwachen Sie die Ressourcennutzung für Ihr System. Überwachen Sie sowohl die gesamte Ressourcennutzung als auch die Ressourcen, die jeder Mandant verwendet. Konfigurieren Sie Warnungen, um Spitzen bei der Ressourcennutzung zu erkennen. Konfigurieren Sie nach Möglichkeit die Automatisierung so, dass bekannte Probleme automatisch durch Hochskalieren oder Ausweiten behoben werden.
Wenden Sie die Ressourcenkontrolle an. Erwägen Sie das Anwenden von Richtlinien, die verhindern, dass ein einzelner Mandant das System überwältigt und die kapazität für andere Mandanten reduziert. Dieser Schritt kann die Form der Kontingenterzwingung über das Einschränkungsmuster oder das Rate Limiting-Muster annehmen.
Erweitern Sie Ihre Infrastruktur. Dieser Prozess kann die Skalierung umfassen, indem einige Ihrer Lösungskomponenten aktualisiert werden. Oder es kann auch eine Skalierung umfassen, indem zusätzliche Shards bereitgestellt werden, wenn Sie dem Sharding-Muster folgen, oder Stempel, wenn Sie dem Bereitstellungsstempelmuster folgen.
Ermöglichen Sie Mandanten den Erwerb von vorab bereitgestellter oder reservierter Kapazität. Dieser Ansatz bietet Mandanten mehr Vertrauen, dass Ihre Lösung ihre Workloads zuverlässig verarbeiten kann.
Ausbalancieren der Mandantenressourcennutzung. Sie können beispielsweise eine der folgenden Ansätze ausprobieren:
Wenn Sie mehrere Instanzen Ihrer Lösung hosten, sollten Sie die Mandanten neu auf die Instanzen oder Stamps verteilen. Ziehen Sie beispielsweise in Betracht, Mandanten mit vorhersehbaren und ergänzenden Nutzungsmustern über mehrere Bereiche hinweg zu platzieren, um die Spitzen in ihrer Nutzung zu glätten.
Überlegen Sie, ob Sie über Hintergrundprozesse oder ressourcenintensive Workloads verfügen, die nicht zeitempfindlich sind. Führen Sie diese Workloads asynchron zu Nebenzeiten aus, um Ihre Ressourcenkapazität für zeitkritische Workloads zu erhalten.
Überprüfen Sie, ob Ihre Downstream-Dienste über Kontrollelemente verfügen, mit denen Noisy Neighbor-Probleme vermieden werden können. Wenn Sie beispielsweise Kubernetes verwenden, erwägen Sie die Verwendung von Pod-Grenzwerten. Wenn Sie Azure Container Apps verwenden, sollten Sie Workloadprofile verwenden, um Workloads zu isolieren.
Schränken Sie die Vorgänge ein, die von Mandanten durchgeführt werden können. Beschränken Sie z. B. Mandanten auf die Ausführung ressourcenintensiver Datenbankabfragen, indem Sie eine maximale Anzahl von rückgabefähigen Datensätzen oder abfragezeitlimits festlegen. Oder ändern Sie diese Vorgänge so, dass sie asynchron sind, und planen Sie, dass sie außerhalb der Spitzenzeiten ausgeführt werden. Diese Aktion verringert das Risiko, dass Mandanten Aktionen ergreifen, die sich negativ auf andere Mandanten auswirken können.
Bereitstellen eines QoS-Systems (Quality of Service). Wenn Sie QoS anwenden, priorisieren Sie einige Prozesse oder Workloads vor anderen Prozessen oder Workloads. Indem Sie die Servicequalität in Ihren Entwurf und Ihre Architektur einbinden, können Sie sicherstellen, dass Vorgänge mit hoher Priorität Vorrang haben, wenn die Auslastung der Ressourcen sehr hoch ist.
Considerations
In den meisten Fällen beabsichtigen einzelne Mieter nicht, Lärmprobleme mit Nachbarn zu verursachen. Einzelne Mandanten wissen möglicherweise nicht, dass ihre Arbeitslasten zu lauten Nachbarn für andere Mandanten führen. Einige Mandanten können jedoch Sicherheitsrisiken in freigegebenen Komponenten nutzen, um einen Dienst entweder einzeln oder durch ausführen eines verteilten Denial-of-Service-Angriffs zu attackieren.
Unabhängig von der Ursache ist es wichtig, diese Probleme als Ressourcengovernanceprobleme zu behandeln und Nutzungskontingente, Einschränkungs- und Governancekontrollen anzuwenden, um das Problem zu beheben.
Note
Seien Sie transparent gegenüber Kunden über alle Drosselungsmechanismen oder Nutzungskontingente, die Sie erzwingen. Es ist wichtig, dass sie fehlgeschlagene Anforderungen ordnungsgemäß behandeln und nicht durch Einschränkungen überrascht werden.
Erkennen des Problems
Aus Sicht eines Clients manifestiert sich das laute Nachbarproblem in der Regel als fehlgeschlagene Anforderungen an den Dienst oder als Anforderungen, die lange Zeit dauern, bis der Vorgang abgeschlossen ist. Wenn die gleiche Anforderung zu anderen Zeiten erfolgreich ist und zufällig fehlschlägt, liegt möglicherweise ein lautes Nachbarproblem vor. Clientanwendungen sollten Telemetrie aufzeichnen, um die Erfolgsrate und Leistung der Anforderungen an Dienste nachzuverfolgen. Die Anwendungen sollten auch grundlegende Leistungsmetriken für Vergleichszwecke aufzeichnen.
Überprüfen Sie für Azure basierte Dienste die Azure-Abonnement- und Dienstgrenzwerte, Kontingente und Einschränkungen um Grenzwerte und Kontingente zu verstehen, die für jede Azure Komponente in Ihrer Lösung gelten.
Aus Sicht eines Diensts kann das laute Nachbarproblem auf folgende Weise auftreten.
Spitzen bei der Ressourcennutzung: Es ist wichtig, ihre normale geplante Ressourcenauslastung klar zu verstehen und Überwachung und Warnungen zu konfigurieren, um Spitzen zu erkennen. Berücksichtigen Sie alle Ressourcen, die sich auf die Leistung oder Verfügbarkeit Ihres Diensts auswirken können. Zu diesen Ressourcen gehören Metriken wie Server CPU und Arbeitsspeicherauslastung, Datenträgereingabe und -ausgabe, Datenbanknutzung und Netzwerkdatenverkehr. Sie sollten auch Metriken überwachen, die von verwalteten Diensten verfügbar gemacht werden, einschließlich Anforderungsvolumen und synthetische oder abstrakte Leistungsindikatoren wie Azure Cosmos DB Request Units.
Fehler beim Ausführen eines Vorgangs für einen Mandanten: Suchen Sie nach Fehlern, die auftreten, wenn ein Mandant keinen großen Teil der Systemressourcen verbraucht. Dieses Muster kann darauf hinweisen, dass der Mandant ein lautes Nachbarproblem aufweist. Nachverfolgung des Ressourcenverbrauchs pro Mandant. Wenn Sie z. B. Azure Cosmos DB verwenden, protokollieren Sie die Anforderungseinheiten für jede Anforderung, und fügen Sie den Bezeichner des Mandanten in die Telemetrie ein, damit Sie die Anforderungseinheitsnutzung für jeden Mandanten aggregieren können.
Contributors
Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.
Hauptautor:
John Downs | Principal Software Engineer, Azure Patterns & Practices
Andere Mitwirkende:
Chad Kittel | Principal Software Engineer, Azure Patterns & Praktiken- Paolo Salvatori | Principal Customer Engineer, FastTrack für Azure
- Daniel Scott-Raynsford | Partner Technology Strategist
- Arsen Vladimirskiy | Principal Customer Engineer, FastTrack für Azure
Um nicht-öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.