Multitenant-systemen delen resources tussen twee of meer tenants. Omdat tenants dezelfde gedeelde resources gebruiken, kan de activiteit van de ene tenant een negatieve invloed hebben op het gebruik van het systeem van een andere tenant.
Beschrijving van het probleem
Wanneer u een service bouwt die door meerdere klanten of tenants moet worden gedeeld, kunt u deze bouwen om meerdere tenants te gebruiken. Een voordeel van multitenant-systemen is dat resources kunnen worden gegroepeerd en gedeeld tussen tenants. Dit leidt vaak tot lagere kosten en verbeterde efficiëntie. Als één tenant echter een onevenredige hoeveelheid resources gebruikt die beschikbaar zijn in het systeem, kan de algehele prestaties van het systeem lijden. Het probleem met lawaaierige buren treedt op wanneer de prestaties van een tenant worden verminderd vanwege de activiteiten van een andere tenant.
Bekijk een voorbeeld van een multitenantsysteem met twee tenants. De gebruikspatronen van tenant A en de gebruikspatronen van tenant B vallen samen. Op piekmomenten gebruikt tenant A alle resources van het systeem, wat betekent dat aanvragen die tenant B doet mislukken. Met andere woorden: het totale resourcegebruik is hoger dan de capaciteit van het systeem:
Het is waarschijnlijk dat de aanvraag van de tenant die het eerst binnenkomt voorrang krijgt. Vervolgens ondervindt de andere tenant een probleem met lawaaierige buren. Beide tenants kunnen ook hun prestatieproblemen ondervinden.
Het probleem met lawaaierige buren treedt ook op, zelfs wanneer elke afzonderlijke tenant relatief kleine hoeveelheden capaciteit van het systeem verbruikt, maar het collectieve resourcegebruik van veel tenants resulteert in een piek in het totale gebruik:
Deze situatie kan zich voordoen 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 lawaaierige buren vormen een inherent risico wanneer u één resource deelt en het is niet mogelijk om de mogelijkheid om te worden beïnvloed door een lawaaierige buur volledig te elimineren. Er zijn echter enkele stappen die zowel clients als serviceproviders kunnen uitvoeren om de kans op problemen met lawaaierige buren te verminderen of om hun effecten te beperken wanneer ze worden waargenomen.
Acties die clients kunnen uitvoeren
- Zorg ervoor dat uw toepassing servicebeperking afhandelt om het maken van onnodige aanvragen voor de service te verminderen. Zorg ervoor dat uw toepassing goede procedures volgt voor het opnieuw proberen van aanvragen die een tijdelijke foutreactie hebben ontvangen.
- Koop gereserveerde capaciteit, indien beschikbaar. Wanneer u bijvoorbeeld Azure Cosmos DB gebruikt, gereserveerde doorvoer aanschaft en wanneer u ExpressRoute gebruikt, richt u afzonderlijke circuits in voor omgevingen die gevoelig zijn voor prestaties.
- Migreer naar een exemplaar van één tenant van de service of naar een servicelaag met sterkere isolatiegaranties. Wanneer u bijvoorbeeld Service Bus gebruikt, migreert u naar de Premium-laag en richt u bij het gebruik van Azure Cache voor Redis een cache met standard- of Premium-lagen in.
Acties die serviceproviders kunnen uitvoeren
- Bewaak het resourcegebruik voor uw systeem. Bewaak zowel het algehele resourcegebruik als de resources die door elke tenant worden gebruikt. Configureer waarschuwingen om pieken in 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 die voorkomen dat één tenant het systeem overweldigt en de capaciteit voor anderen vermindert. Deze stap kan de vorm aannemen van het afdwingen van quota, via het beperkingspatroon of het patroon snelheidsbeperking.
- Meer infrastructuur inrichten. Dit proces kan betrekking hebben op omhoog schalen 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. U kunt bijvoorbeeld tenants met voorspelbare en vergelijkbare gebruikspatronen op meerdere stempels plaatsen om de pieken in hun gebruik af te vlakken.
- Overweeg of u achtergrondprocessen of resource-intensieve workloads hebt die niet tijdgevoelig zijn. Voer deze workloads asynchroon uit op externe piektijden om uw piekcapaciteit van resources voor tijdgevoelige workloads te behouden.
- Controleer of uw downstreamservices besturingselementen bieden om problemen met lawaaierige buren te beperken. Als u bijvoorbeeld Kubernetes gebruikt, kunt u overwegen om podlimieten te gebruiken en bij het gebruik van Service Fabric de ingebouwde governancemogelijkheden te gebruiken.
- Beperk de bewerkingen die tenants kunnen uitvoeren. Beperk bijvoorbeeld tenants van het uitvoeren van bewerkingen waarmee zeer grote databasequery's worden uitgevoerd, zoals door een maximum aantal records of tijdslimiet voor query's op te geven. Met deze actie wordt het risico beperkt 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 anderen. Door QoS in uw ontwerp en architectuur te factoreren, kunt u ervoor zorgen dat bewerkingen met hoge prioriteit voorrang krijgen wanneer uw resources onder druk staan.
Overwegingen
In de meeste gevallen zijn afzonderlijke tenants niet van plan om problemen met lawaaierige buren te veroorzaken. Afzonderlijke tenants zijn er mogelijk niet eens van op de hoogte dat hun workloads problemen veroorzaken met ruis voor andere tenants. Het is echter ook mogelijk dat sommige tenants misbruik kunnen maken van beveiligingsproblemen in gedeelde onderdelen om een service afzonderlijk aan te vallen 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 om gebruiksquota, beperking en beheeropties toe te passen om het probleem te verhelpen.
Notitie
Zorg ervoor dat u uw klanten vertelt over beperkingen die u toepast, of eventuele gebruiksquota voor uw service. Het is belangrijk dat ze op betrouwbare wijze mislukte aanvragen verwerken en dat ze niet verrast zijn door beperkingen of quota die u toepast.
Het probleem vaststellen
Vanuit het perspectief van een client wordt het probleem met lawaaierige buren meestal weergegeven als mislukte aanvragen voor de service of als aanvragen die lang duren. Met name als dezelfde aanvraag op andere momenten slaagt en willekeurig lijkt te mislukken, kan er sprake zijn van een probleem met ruis. Clienttoepassingen moeten telemetrie vastleggen om het slagingspercentage en de prestaties van de aanvragen voor services bij te houden, en de toepassingen moeten ook metrische gegevens over basislijnprestaties vastleggen voor vergelijkingsdoeleinden.
Vanuit het perspectief van een service kan het probleem met lawaaierige buren op verschillende manieren worden weergegeven:
- Pieken in resourcegebruik. Het is belangrijk om een duidelijk inzicht te hebben in het normale resourcegebruik van de basislijn en om bewaking en waarschuwingen te configureren om pieken in 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 server-CPU en geheugengebruik, schijf-IO, databasegebruik, netwerkverkeer en metrische gegevens die worden weergegeven door beheerde services, zoals het aantal aanvragen en de synthetische en abstracte metrische 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 resources van het systeem gebruikt. Een dergelijk patroon kan erop wijzen dat de tenant een slachtoffer is van het probleem met lawaaierige buren. Overweeg om 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 id van de tenant toe te voegen als dimensie aan de telemetrie, zodat u het verbruik van de aanvraageenheden voor elke tenant kunt aggregeren.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Hoofdauteur:
- John Downs | Principal Software Engineer
Andere Inzenders:
- Chad Kittel | Principal Software Engineer
- Paulo Salvatori | Principal Customer Engineer, FastTrack voor Azure
- Daniel Scott-Raynsford | PartnerTechnologie Strategist
- Arsen Vladimirskiy | Principal Customer Engineer, FastTrack voor Azure
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.