Zagadnienia dotyczące planowania pojemności

Ukończone

Podstawowe planowanie pojemności rozpoczyna się od pewnych prostych obliczeń, ale istnieją czynniki, które mogą skomplikować ten proces. Oprócz prostych bieżących i przewidywanych liczb użycia należy również uwzględnić następujące kwestie:

• Limity i przydziały usługi
• Ograniczenia w zakresie kosztów
• Nieefektywność kodu i konfiguracji
• Zależności

W tej lekcji dowiesz się, jak te zagadnienia mogą mieć wpływ na planowanie pojemności i jak rozwiązać każdy z nich.

Limity i przydziały usługi

Istnieje tendencja do postrzegania przetwarzania w chmurze jako nieograniczonego zasobu. W porównaniu do tradycyjnych modeli serwerowych/centrów danych, pojemność chmury wydaje się nieskończona. Chmura oferuje zupełnie nowy poziom skali. Jednak podobnie jak w przypadku wszystkich innych rozwiązań ma pewne ograniczenia. Planowanie pojemności obejmuje zrozumienie, kiedy osiągniesz te limity usług.

Podczas przeglądania systemu i jego architektury należy zrozumieć limity używanych usług w chmurze. Na przykład domyślnie na platformie Azure można mieć maksymalnie 200 maszyn wirtualnych na zestaw dostępności maszyn wirtualnych. Ten limit może wydawać się większy niż wystarczający, jeśli dopiero zaczynasz pracę. Jednak po osiągnięciu tego limitu nie można aprowizować więcej maszyn wirtualnych, co może spowodować awarię.

Podobnie domyślnie możesz mieć 250 kont magazynu na subskrypcję na region. Te limity są przykładami limitów miękkich, które można zwiększyć. Jednak niektóre usługi mają maksymalne limity, które można znaleźć za pomocą poniższego linku.

Limity subskrypcji i usług, limity przydziału oraz ograniczenia platformy Azure

Te limity i limity przydziału są czymś, co należy znać i monitorować. Przyjrzyjmy się sposobom na realizację tego celu.

Azure Portal

W sekcji Użycie i limity przydziału usługi w sekcji Subskrypcje i przydziały są widoczne w sekcji Limity przydziału i użycia —> Ustawienia w okienku nawigacji. Możesz filtrować według kategorii usług, takiej jak sieć/środowisko obliczeniowe i region świadczenia usługi Azure. Pokazuje, gdzie jesteś w stosunku do limitów.

Za pośrednictwem kodu

Możesz użyć Usage - List punktu końcowego dla dowolnej usługi platformy Azure, aby uzyskać bieżące informacje o użyciu zasobów oraz limity zasobów obliczeniowych w ramach subskrypcji, jak pokazano w tym obciętym przykładzie.

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{location}/usages?api-version=2023-03-01
{ 
    "currentValue": 124,
    "/subscriptions/{subscriptionId}/providers/Microsoft.Network/locations/westeurope/usages/VirtualNetworks",
    "limit": 1000, 
    "name": { 
        "localizedValue": "Virtual Networks",
        "value": "VirtualNetworks" 
    }, 
    "unit": "Count" 
}

Widać, że bieżąca liczba używanych sieci wirtualnych platformy Azure to 124, a limit wynosi 1000. Zwiększenie limitu wymaga żądania pomocy technicznej, dlatego upewnij się, że wiesz wcześniej, kiedy zbliżasz się do progu.

Ograniczenia w zakresie kosztów

Skalowanie nie polega tylko na rzucaniu większej ilości zasobów na problem. Ważne jest, aby Twoja organizacja mogła zrozumieć koszt środowiska opartego na chmurze oraz fakt, że dodanie większej ilości zasobów zwykle będzie wiązało się ze zwiększeniem kosztów. Pamiętaj o tym koszcie i współpracuj z zespołami finansowymi, aby upewnić się, że masz umowę na temat bieżących i przewidywanych wydatków na chmurę.

Należy prognozować koszty zarówno podczas początkowego projektowania systemów, jak i podczas regularnego przeprowadzania przeglądów już uruchomionych systemów. Platforma Azure oferuje narzędzia, które mogą ci pomóc:

• Planowanie kosztów środowiska przy użyciu kalkulatora platformy Azure.
• zapoznać się z bieżącymi i przewidywanymi miesięcznymi wydatkami w witrynie Azure Portal;
• Konfigurowanie budżetów w usłudze Microsoft Cost Management. To narzędzie umożliwia sprawdzenie kosztów w różnych zakresach, w tym grupy zarządzania, grupy zasobów i subskrypcji.

Nieefektywność kodu i konfiguracji

Czasami kierowanie większej ilości zasobów może rozwiązać problem, ale kosztuje to pieniądze. Czasami skalowanie nie jest odpowiednim rozwiązaniem lub nie jest kompletnym rozwiązaniem. W niektórych przypadkach może się okazać, że coś, co wygląda na potrzebę skalowania, w rzeczywistości jest problemem spowodowanym nieprawidłowym kodowaniem lub konfiguracją.

Przed skalowaniem zasobów możesz zaoszczędzić pieniądze i czas, wyszukując błędy. Oto kilka przykładów tego podejścia:

• Jeśli masz źle zaprojektowaną bazę danych z gorącą partycją, taką jak używanie tylko jednej partycji w ogromnej bazie danych noSQL, działa wolno niezależnie od skali.
• Jeśli masz niewydajne zapytania dotyczące baz danych, zwiększ ich wydajność przed użyciem większej ilości zasobów w bazie danych. Czasami dodanie odpowiedniego indeksu do bazy danych na podstawie typowych zapytań może obniżyć koszty 100x.
• Jeśli limity czasu są niepoprawnie ustawione, połączenia z bazą danych mogą być nasycone z powodu ponownych prób z niespójnych limitów czasu między serwerem a bazą danych. W takim przypadku należy naprawić ustawienia przed skalowaniem bazy danych.
• Jeśli kod dewelopera jest nieefektywny, czy można napisać bardziej wydajny kod, aby rozwiązać problem? Być może kod nie zwalnia pamięci, kiedy to możliwe, więc używasz większych maszyn wirtualnych pamięci, gdy nie jest to konieczne. Takie poprawki mogą zapewnić znaczną oszczędność kosztów.

Zależności

Zmiany, które są potrzebne do rozwiązania niektórych problemów opisanych w tym module, często mają zależności od deweloperów aplikacji. Niektóre rozwiązania i najlepsze rozwiązania zalecane w tym miejscu wymagają współpracy między Tobą i tymi deweloperami, aby to się stało.

Możesz nie być w stanie zaimplementować wszystkich tych zaleceń całkowicie samodzielnie. Jeśli jednak rozumiesz system w chmurze i jego możliwości i cechy, możesz stać się czynnikiem umożliwiającym zmianę w ulepszaniu systemów oraz ich skalowalności i niezawodności.