Redigera

Dela via

Störande antimönster för granne

Azure

Multitenantsystem delar resurser mellan två eller flera klienter. Eftersom klienter använder samma delade resurser kan aktiviteten för en klientorganisation ha en negativ inverkan på en annan klientorganisations användning av systemet.

Problembeskrivning

När du skapar en tjänst som ska delas av flera kunder eller klienter kan du skapa den för flera klienter. En fördel med system med flera klienter är att resurser kan poolas och delas mellan klientorganisationer. Detta resulterar ofta i lägre kostnader och förbättrad effektivitet. Men om en enskild klientorganisation använder en oproportionerlig mängd tillgängliga resurser i systemet kan systemets övergripande prestanda bli lidande. Det bullriga grannproblemet uppstår när en klientorganisations prestanda försämras på grund av en annan klientorganisations aktiviteter.

Överväg ett exempel på ett system med flera klienter med två klienter. Klientorganisation A:s användningsmönster och klient B:s användningsmönster sammanfaller. Vid tider med hög belastning använder klient A alla systemets resurser, vilket innebär att alla begäranden som klient B gör misslyckas. Med andra ord är den totala resursanvändningen högre än systemets kapacitet:

Bild som visar resursanvändningen för två klienter. Klientorganisation A förbrukar den fullständiga uppsättningen systemresurser, vilket innebär att klient B upplever fel.

Det är troligt att den klientorganisationsbegäran som kommer först har företräde. Sedan får den andra klientorganisationen ett problem med en bullrig granne. Båda klienterna kan också få problem med sina prestanda.

Det bullriga grannproblemet uppstår även när varje enskild klientorganisation förbrukar relativt små mängder av systemets kapacitet, men den kollektiva resursanvändningen för många klienter resulterar i en topp i den totala användningen:

Bild med 3 klienter, var och en förbrukar mindre maximalt dataflöde för lösningen. Totalt använder de tre klienterna de fullständiga systemresurserna.

Den här situationen kan inträffa när du har flera klienter som alla har liknande användningsmönster, eller där du inte har etablerat tillräckligt med kapacitet för den kollektiva belastningen på systemet.

Åtgärda problemet

Bullriga grannproblem är en inneboende risk när du delar en enskild resurs, och det går inte att helt eliminera risken för att påverkas av en bullrig granne. Det finns dock vissa steg som både klienter och tjänsteleverantörer kan vidta för att minska sannolikheten för störningar i grannens problem eller för att minska deras effekter när de observeras.

Åtgärder som klienter kan vidta

Åtgärder som tjänsteleverantörer kan vidta

  • Övervaka resursanvändningen för systemet. Övervaka både den totala resursanvändningen och de resurser som varje klientorganisation använder. Konfigurera aviseringar för att identifiera toppar i resursanvändningen och om möjligt konfigurera automatisering för att automatiskt åtgärda kända problem genom att skala upp eller ut.
  • Tillämpa resursstyrning. Överväg att tillämpa principer som undviker att en enda klientorganisation överbelastar systemet och minskar den tillgängliga kapaciteten för andra. Det här steget kan ha formen av kvottillämpning, via begränsningsmönstret eller mönstret Hastighetsbegränsning.
  • Etablera mer infrastruktur. Den här processen kan innebära att skala upp genom att uppgradera några av dina lösningskomponenter, eller så kan det innebära att skala ut genom att etablera ytterligare shards, om du följer fragmenteringsmönstret eller stämplar om du följer mönstret Distributionsstämplar.
  • Gör det möjligt för klientorganisationer att köpa företablerad eller reserverad kapacitet. Den här kapaciteten ger klientorganisationer mer säkerhet om att din lösning hanterar deras arbetsbelastning på ett tillfredsställande sätt.
  • Jämna ut klientorganisationens resursanvändning. Du kan till exempel prova någon av följande metoder:
    • Om du är värd för flera instanser av din lösning kan du överväga att ombalansera klienter mellan instanser eller stämplar. Överväg till exempel att placera klienter med förutsägbara och liknande användningsmönster över flera stämplar för att platta ut topparna i deras användning.
    • Fundera på om du har bakgrundsprocesser eller resursintensiva arbetsbelastningar som inte är tidskänsliga. Kör dessa arbetsbelastningar asynkront vid tider med låg belastning för att bevara din högsta resurskapacitet för tidskänsliga arbetsbelastningar.
  • Kontrollera om dina underordnade tjänster tillhandahåller kontroller för att undvika problem med bullriga grannar. När du till exempel använder Kubernetes bör du överväga att använda poddgränser, och när du använder Service Fabric bör du överväga att använda de inbyggda styrningsfunktionerna.
  • Begränsa de åtgärder som klienter kan utföra. Du kan till exempel begränsa klientorganisationer från att köra åtgärder som kör mycket stora databasfrågor, till exempel genom att ange ett maximalt antal returnerbara poster eller en tidsgräns för frågor. Den här åtgärden minskar risken för att klienter vidtar åtgärder som kan påverka andra klienter negativt.
  • Tillhandahålla ett QoS-system (Quality of Service). När du tillämpar QoS prioriterar du vissa processer eller arbetsbelastningar framför andra. Genom att räkna in QoS i din design och arkitektur kan du se till att åtgärder med hög prioritet prioriteras när det finns ett tryck på dina resurser.

Att tänka på

I de flesta fall har enskilda klienter inte för avsikt att orsaka problem med bullriga grannar. Enskilda klienter kanske inte ens är medvetna om att deras arbetsbelastningar orsakar problem med bullriga grannar för andra. Det är dock också möjligt att vissa klienter utnyttjar sårbarheter i delade komponenter för att attackera en tjänst, antingen individuellt eller genom att utföra en DDoS-attack (Distributed Denial-of-Service).

Oavsett orsak är det viktigt att behandla dessa problem som resursstyrningsproblem och tillämpa användningskvoter, begränsningar och styrningskontroller för att åtgärda problemet.

Kommentar

Se till att du berättar för dina klienter om eventuella begränsningar som du tillämpar eller eventuella användningskvoter för din tjänst. Det är viktigt att de hanterar misslyckade begäranden på ett tillförlitligt sätt och att de inte är förvånade över några begränsningar eller kvoter som du tillämpar.

Identifiera problemet

Från en klients perspektiv visas det bullriga granneproblemet vanligtvis som misslyckade begäranden till tjänsten, eller som begäranden som tar lång tid att slutföra. I synnerhet om samma begäran lyckas vid andra tillfällen och verkar misslyckas slumpmässigt, kan det finnas ett problem med en bullrig granne. Klientprogram bör registrera telemetri för att spåra lyckade och prestanda för begäranden till tjänster, och programmen bör också registrera baslinjeprestandamått för jämförelseändamål.

Ur en tjänsts perspektiv kan problemet med den bullriga grannen visas på flera sätt:

  • Toppar i resursanvändningen. Det är viktigt att ha en tydlig förståelse för din normala baslinjeresursanvändning och att konfigurera övervakning och aviseringar för att identifiera toppar i resursanvändningen. Se till att du överväger alla resurser som kan påverka tjänstens prestanda eller tillgänglighet. Dessa resurser omfattar mått som cpu- och minnesanvändning för servrar, disk-I/O, databasanvändning, nätverkstrafik och mått som exponeras av hanterade tjänster, till exempel antalet begäranden och de syntetiska och abstrakta prestandamåtten, till exempel Enheter för Azure Cosmos DB-begäranden.
  • Fel vid körning av en åtgärd för en klientorganisation. Leta särskilt efter fel som inträffar när en klientorganisation inte använder en stor del av systemets resurser. Ett sådant mönster kan tyda på att klienten är ett offer för det bullriga granneproblemet. Överväg att spåra resursförbrukningen per klientorganisation. När du till exempel använder Azure Cosmos DB bör du överväga att logga de enheter för begäran som används för varje begäran och lägga till klientorganisationens identifierare som en dimension i telemetrin, så att du kan aggregera förbrukningen för begärandeenheten för varje klientorganisation.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.