Udostępnij za pośrednictwem

Hałaśliwy antywzorzec sąsiada

Azure

Systemy wielodostępne współdzielą zasoby między co najmniej dwiema dzierżawami. Ponieważ dzierżawy korzystają z tych samych zasobów udostępnionych, aktywność jednej dzierżawy może negatywnie wpłynąć na użycie systemu przez inną dzierżawę.

Kontekst i problem

When you build a service that multiple customers or tenants share, you can build it to be multitenanted. Zaletą systemów wielodostępnych jest to, że zasoby mogą być w puli i współużytkowane przez dzierżawców. Udostępnianie zasobów często skutkuje niższymi kosztami i lepszą wydajnością. Jeśli jednak jedna dzierżawa korzysta z nieproporcjonalnej ilości zasobów dostępnych w systemie, ogólna wydajność systemu może mieć duże znaczenie. The noisy neighbor problem occurs when one tenant's performance is degraded because of the activities of another tenant.

Rozważmy przykładowy system wielodostępny, który ma dwie dzierżawy. Wzorce użycia dzierżawy A i wzorce użycia dzierżawy B pokrywają się. W godzinach szczytu dzierżawa A używa wszystkich zasobów systemu, co oznacza, że wszystkie żądania dzierżawy B kończą się niepowodzeniem. Innymi słowy, całkowite zapotrzebowanie na zasoby jest wyższe niż pojemność systemu:

Diagram przedstawiający użycie zasobów dwóch dzierżaw.

Prawdopodobnie dzierżawa, której żądanie dotarło najpierw, ma pierwszeństwo. Następnie inna dzierżawa może napotkać hałaśliwy problem z sąsiadem. Alternatywnie wydajność może obniżyć wydajność obu dzierżaw.

Problem z hałaśliwym sąsiadem występuje również wtedy, gdy każda dzierżawa zużywa tylko niewielką część pojemności systemu. Jednak łączne użycie zasobów wielu dzierżaw może spowodować szczyt ogólnego użycia:

Diagram przedstawiający trzy dzierżawy, z których każda korzysta z mniejszej niż maksymalna przepływność. Razem w pełni wykorzystują całkowite zasoby systemowe.

Ten scenariusz może wystąpić, gdy masz wiele dzierżaw, które mają podobne wzorce użycia lub gdy nie aprowizowana wystarczająca pojemność dla zbiorczego obciążenia systemu.

Solution

Udostępnianie jednego zasobu wiąże się z ryzykiem hałaśliwych problemów sąsiadów, których nie można całkowicie uniknąć. Istnieją jednak pewne kroki, które mogą podjąć zarówno klienci, jak i dostawcy usług, aby zmniejszyć prawdopodobieństwo hałaśliwych problemów sąsiadów lub zminimalizować ich skutki.

Akcje, które mogą wykonywać klienci

Akcje, które mogą wykonywać dostawcy usług

  • Monitoruj użycie zasobów dla systemu. Monitoruj zarówno ogólne użycie zasobów, jak i zasoby używane przez każdą dzierżawę. Konfigurowanie alertów w celu wykrywania skoków użycia zasobów. Jeśli to możliwe, skonfiguruj automatyzację, aby automatycznie ograniczyć znane problemy przez skalowanie w górę lub w górę.

  • Stosowanie ładu zasobów. Rozważ zastosowanie zasad, które uniemożliwiają pojedynczej dzierżawie przeciążenie systemu i zmniejszenie pojemności dostępnej dla innych dzierżaw. This step might take the form of quota enforcement through the Throttling pattern or the Rate Limiting pattern.

  • Aprowizuj więcej infrastruktury. Ten proces może obejmować skalowanie w górę przez uaktualnienie niektórych składników rozwiązania. Or it might include scaling out by provisioning extra shards if you follow the Sharding pattern, or stamps if you follow the Deployment Stamps pattern.

  • Umożliwia dzierżawcom zakup wstępnie aprowizowanej lub zarezerwowanej pojemności. Takie podejście zapewnia dzierżawcom większą pewność, że rozwiązanie może niezawodnie obsługiwać obciążenia.

  • Równoważenie użycia zasobów dzierżawy. Możesz na przykład wypróbować jedną z następujących metod:

    • Jeśli hostujesz wiele wystąpień rozwiązania, rozważ ponowne równoważenie dzierżaw między wystąpieniami lub sygnaturami. Rozważ na przykład umieszczenie dzierżaw z przewidywalnymi i uzupełniającymi wzorcami użycia w wielu sygnaturach w celu spłaszczenia szczytów ich użycia.

    • Zastanów się, czy masz procesy w tle, czy obciążenia intensywnie korzystające z zasobów, które nie są wrażliwe na czas. Uruchom te obciążenia asynchronicznie poza godzinami szczytu, aby zachować pojemność zasobów dla obciążeń z uwzględnieniem czasu.

  • Sprawdź, czy usługi podrzędne zapewniają mechanizmy kontroli, aby rozwiązać problemy z hałaśliwymi sąsiadami. For example, when you use Kubernetes, consider using pod limits. W przypadku korzystania z usługi Azure Service Fabric rozważ użycie wbudowanych funkcji zapewniania ładu.

  • Ogranicz operacje, które mogą wykonywać dzierżawcy. Na przykład ogranicz dzierżawcom wykonywanie operacji, które uruchamiają bardzo duże zapytania bazy danych, na przykład przez określenie maksymalnej liczby zwracanych rekordów lub limitu czasu zapytań. Możesz też zmienić te operacje tak, aby były asynchroniczne i zaplanować ich uruchamianie poza godzinami szczytu. Ta akcja ogranicza ryzyko podejmowania działań przez dzierżawców, które mogą negatywnie wpłynąć na inne dzierżawy.

  • Zapewnienie jakości systemu usług (QoS). W przypadku stosowania QoS należy określić priorytety niektórych procesów lub obciążeń przed innymi procesami lub obciążeniami. Uwzględniając funkcje QoS w projekcie i architekturze, możesz mieć pewność, że operacje o wysokim priorytcie mają pierwszeństwo, gdy występuje presja na zasoby.

Considerations

W większości przypadków poszczególne dzierżawy nie zamierzają powodować hałaśliwych problemów z sąsiadami. Poszczególne dzierżawy mogą nie wiedzieć, że ich obciążenia powodują problemy z hałaśliwymi sąsiadami w przypadku innych dzierżaw. Jednak niektóre dzierżawy mogą wykorzystywać luki w zabezpieczeniach w udostępnionych składnikach w celu ataku na usługę pojedynczo lub przez przeprowadzenie rozproszonego ataku typu "odmowa usługi".

Niezależnie od przyczyny ważne jest, aby traktować te problemy jako problemy z zarządzaniem zasobami i stosować limity przydziału użycia, ograniczanie przepustowości i mechanizmy kontroli ładu, aby rozwiązać ten problem.

Note

Bądź niewidoczny dla klientów dotyczących wszelkich mechanizmów ograniczania przepustowości lub limitów przydziałów użycia, które są wymuszane. Ważne jest, aby obsłużyć żądania, które zakończyły się niepowodzeniem, i nie są przechwytywane przez ograniczenia.

Jak wykryć problem

Z perspektywy klienta problem z hałaśliwym sąsiadem zwykle manifestuje się jako żądania zakończone niepowodzeniem do usługi lub jako żądania, które wymagają długiego czasu. W szczególności, jeśli to samo żądanie powiedzie się w innym czasie i wydaje się kończyć się losowym niepowodzeniem, może wystąpić problem z hałaśliwym sąsiadem. Aplikacje klienckie powinny rejestrować dane telemetryczne w celu śledzenia współczynnika powodzenia i wydajności żądań do usług. Aplikacje powinny również rejestrować podstawowe metryki wydajności na potrzeby porównania.

W przypadku usług opartych na platformie Azure zapoznaj się z limitami, limitami przydziałów i ograniczeniami subskrypcji i usług platformy Azure, aby zrozumieć limity i przydziały, które mają zastosowanie do każdego składnika platformy Azure w rozwiązaniu.

Z perspektywy usługi problem z hałaśliwym sąsiadem może pojawić się w następujący sposób.

  • Skoki użycia zasobów: Ważne jest, aby jasno zrozumieć normalne użycie zasobów punktu odniesienia oraz skonfigurować monitorowanie i alerty w celu wykrywania skoków. Rozważ wszystkie zasoby, które mogą mieć wpływ na wydajność lub dostępność usługi. Te zasoby obejmują metryki, takie jak użycie procesora i pamięci serwera, dane wejściowe i wyjściowe dysku, użycie bazy danych i ruch sieciowy. Należy również monitorować metryki uwidocznione przez usługi zarządzane, w tym wolumin żądania i syntetyczne lub abstrakcyjne wskaźniki wydajności, takie jak jednostki żądań usługi Azure Cosmos DB.

  • Błędy podczas wykonywania operacji dla dzierżawy: Poszukaj błędów, które występują, gdy dzierżawa nie korzysta z dużego udziału zasobów systemu. Ten wzorzec może wskazywać, że dzierżawa ma problem z hałaśliwym sąsiadem. Śledzenie użycia zasobów według dzierżawy. Na przykład w przypadku korzystania z usługi Azure Cosmos DB należy rejestrować jednostki żądań dla każdego żądania i uwzględniać identyfikator dzierżawy w telemetrii, aby można było agregować użycie jednostek żądania dla każdej dzierżawy.

Contributors

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Principal author:

  • John Downs | Principal Software Engineer, Azure Patterns & Practices

Other contributors:

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.