Bewerken

Antipatroon voor luidruchtige buren

Azure

Multitenant-systemen delen resources tussen tenants. Omdat tenants dezelfde gedeelde resources gebruiken, kan de activiteit van de ene tenant een negatieve invloed hebben op het gebruik van het systeem door een andere tenant.

Beschrijving van het probleem

Wanneer u een service bouwt die moet worden gedeeld door meerdere klanten of tenants, kunt u deze bouwen voor multitenant. Een voordeel van systemen met meerdere tenants is dat resources kunnen worden gegroepeerd en gedeeld tussen tenants. Dit resulteert vaak in lagere kosten en verbeterde efficiëntie. Als één tenant echter een onevenredige hoeveelheid resources gebruikt die beschikbaar zijn in het systeem, kunnen de algehele prestaties van het systeem eronder lijden. Het probleem met luidruchtige buren treedt op wanneer de prestaties van een tenant verslechteren vanwege de activiteiten van een andere tenant.

Bekijk een voorbeeld van een multitenant-systeem met twee tenants. De gebruikspatronen van tenant A en de gebruikspatronen van tenant B vallen samen, wat betekent dat tijdens piekmomenten het totale resourcegebruik hoger is dan de capaciteit van het systeem:

Afbeelding met het resourcegebruik van twee tenants. Tenant A verbruikt de volledige set systeembronnen, wat betekent dat tenant B fouten ondervindt.

Het is waarschijnlijk dat de aanvraag van de tenant die het eerst is aangekomen, voorrang heeft. Dan ondervindt de andere tenant een probleem met een luidruchtige buren. Het is ook mogelijk dat beide tenants last hebben van hun prestaties.

Het probleem met lawaaierige buren treedt ook op wanneer elke afzonderlijke tenant relatief kleine hoeveelheden van de capaciteit van het systeem verbruikt, maar het collectieve resourcegebruik van veel tenants resulteert in een piek in het totale gebruik:

Afbeelding met drie tenants, die elk minder verbruiken dan de maximale doorvoer van de oplossing. In totaal verbruiken de drie tenants de volledige systeemresources.

Dit kan gebeuren wanneer u meerdere tenants hebt die allemaal vergelijkbare gebruikspatronen hebben of wanneer u onvoldoende capaciteit hebt ingericht voor de collectieve belasting van het systeem.

Het probleem oplossen

Problemen met luidruchtige buren vormen een inherent risico in systemen met meerdere tenants en het is niet mogelijk om de mogelijkheid om te worden beïnvloed door een luidruchtige buur volledig te elimineren. Er zijn echter enkele stappen die zowel clients als serviceproviders kunnen uitvoeren om de kans op lawaaierige buren te verminderen of om de gevolgen ervan te beperken wanneer ze worden waargenomen.

Acties die clients kunnen uitvoeren

Acties die serviceproviders kunnen uitvoeren

  • Bewaak het resourcegebruik voor uw systeem. Bewaak zowel het algemene resourcegebruik als de resources die elke tenant gebruikt. Configureer waarschuwingen om pieken in het resourcegebruik te detecteren en configureer indien mogelijk automatisering om bekende problemen automatisch te verhelpen door omhoog of uit te schalen.
  • Resourcebeheer toepassen. Overweeg beleidsregels toe te passen waarmee wordt voorkomen dat één tenant het systeem overweldigt en de capaciteit die beschikbaar is voor anderen vermindert. Deze stap kan de vorm hebben van het afdwingen van quota, via het beperkingspatroon of het patroon Snelheidsbeperking.
  • Meer infrastructuur inrichten. Voor dit proces kan omhoog worden geschaald door een aantal van uw oplossingsonderdelen te upgraden, of het kan nodig zijn om uit te schalen door extra shards in te richten, als u het Sharding-patroon of -stempels volgt, als u het patroon Implementatiestempels volgt.
  • Tenants in staat stellen vooraf ingerichte of gereserveerde capaciteit aan te schaffen. Deze capaciteit biedt tenants meer zekerheid dat uw oplossing hun workload adequaat afhandelt.
  • Maak het resourcegebruik van tenants soepeler. U kunt bijvoorbeeld een van de volgende methoden proberen:
    • Als u meerdere exemplaren van uw oplossing host, kunt u overwegen om tenants opnieuw te verdelen over de exemplaren of stempels. Overweeg bijvoorbeeld tenants te plaatsen met voorspelbare en vergelijkbare gebruikspatronen op meerdere stempels om de pieken in hun gebruik af te vlakken.
    • Overweeg of u achtergrondprocessen of resource-intensieve workloads hebt die niet tijdgevoelig zijn. Voer deze werkbelastingen asynchroon uit op daluren om uw piekresourcecapaciteit te behouden voor tijdgevoelige werkbelastingen.
  • Controleer of uw downstreamservices besturingselementen bieden om ruisproblemen te verhelpen. Als u bijvoorbeeld Kubernetes gebruikt, kunt u overwegen om podlimieten te gebruiken. Wanneer u Service Fabric gebruikt, kunt u overwegen de ingebouwde governancemogelijkheden te gebruiken.
  • Beperk de bewerkingen die tenants kunnen uitvoeren. Voorkom bijvoorbeeld dat tenants bewerkingen uitvoeren waarmee zeer grote databasequery's worden uitgevoerd, zoals door een maximumaantal retournerende records of een tijdslimiet voor query's op te geven. Deze actie vermindert het risico dat tenants acties ondernemen die een negatieve invloed kunnen hebben op andere tenants.
  • Een QoS-systeem (Quality of Service) bieden. Wanneer u QoS toepast, geeft u prioriteit aan bepaalde processen of workloads voor op andere. Door QoS mee te nemen in uw ontwerp en architectuur, kunt u ervoor zorgen dat bewerkingen met hoge prioriteit voorrang krijgen wanneer er druk is op uw resources.

Overwegingen

In de meeste gevallen zijn afzonderlijke tenants niet van plan om lawaaierige burenproblemen te veroorzaken. Afzonderlijke tenants zijn zich er mogelijk niet eens van bewust dat hun werkbelastingen voor anderen problemen met ruis veroorzaken. Het is echter ook mogelijk dat sommige tenants misbruik maken van beveiligingsproblemen in gedeelde onderdelen om een service aan te vallen, afzonderlijk of door een DDoS-aanval (Distributed Denial of Service) uit te voeren.

Ongeacht de oorzaak is het belangrijk om deze problemen te behandelen als problemen met resourcebeheer en gebruiksquota, beperking en beheeropties toe te passen om het probleem te verhelpen.

Notitie

Zorg ervoor dat u uw klanten informeert over eventuele beperkingen die u toepast of eventuele gebruiksquota voor uw service. Het is belangrijk dat ze mislukte aanvragen op een betrouwbare manier verwerken en dat ze niet verrast worden door beperkingen of quota die u toepast.

Het probleem vaststellen

Vanuit het perspectief van een client wordt het probleem met de ruis meestal gemanifesteerd als mislukte serveraanvragen of aanvragen die lang duren om te voltooien. Met name als dezelfde aanvraag op andere momenten slaagt en willekeurig lijkt te mislukken, is er mogelijk een probleem met de ruis van de buren. Clienttoepassingen moeten telemetriegegevens vastleggen om het slagingspercentage en de prestaties van de aanvragen voor services bij te houden, en de toepassingen moeten ook metrische gegevens over de basislijnprestaties vastleggen voor vergelijkingsdoeleinden.

Vanuit het perspectief van een service kan het probleem met lawaaiige buren op verschillende manieren worden weergegeven:

  • Pieken in resourcegebruik. Het is belangrijk om een duidelijk inzicht te hebben in uw normale resourcegebruik volgens de basislijn en om bewaking en waarschuwingen te configureren om pieken in het resourcegebruik te detecteren. Zorg ervoor dat u rekening houdt met alle resources die van invloed kunnen zijn op de prestaties of beschikbaarheid van uw service. Deze resources omvatten metrische gegevens zoals cpu- en geheugengebruik van de server, schijf-IO, databasegebruik, netwerkverkeer en metrische gegevens die beschikbaar worden gesteld door beheerde services, zoals het aantal aanvragen en de synthetische en abstracte prestatiegegevens, zoals de Azure Cosmos DB-aanvraageenheden.
  • Fouten bij het uitvoeren van een bewerking voor een tenant. Zoek met name naar fouten die optreden wanneer een tenant geen groot deel van de systeemresources gebruikt. Een dergelijk patroon kan erop wijzen dat de tenant het slachtoffer is van het probleem met de luidruchtige buren. Overweeg het resourceverbruik per tenant bij te houden. Wanneer u bijvoorbeeld Azure Cosmos DB gebruikt, kunt u overwegen om de aanvraageenheden die voor elke aanvraag worden gebruikt, te registreren en de tenant-id als dimensie toe te voegen aan de telemetrie, zodat u het verbruik van de aanvraageenheden voor elke tenant kunt aggregeren.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.

Hoofdauteur:

Andere inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.