Zagadnienia dotyczące planowania pojemności
- 5 min
Podstawowe planowanie pojemności rozpoczyna się od pewnych prostych obliczeń, ale istnieją czynniki, które mogą komplikować proces. Oprócz prostych bieżących i przewidywanych liczb użycia należy również uwzględnić następujące kwestie:
- Limity i kwoty usługi
- Ograniczenia 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 kwoty usługi
Istnieje tendencja do postrzegania przetwarzania w chmurze jako nieograniczonego zasobu. W porównaniu z tradycyjnymi modelami serwerów/centrów danych pojemność chmury wydaje się być nieskończona. Chmura oferuje zupełnie nowy poziom skali. Jednak podobnie jak wszystko inne, 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 maszyn wirtualnych może wydawać się być 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 przechowywania 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źć pod poniższym linkiem.
Limity, limity przydziału i ograniczenia subskrypcji i usług platformy Azure
Te limity i limity przydziału są czymś, co należy znać i monitorować. Przyjrzyjmy się sposobom, aby to zrobić.
Azure Portal
Możesz zobaczyć przydziały usług i swoją pozycję względem tych limitów w sekcji Zużycie + kwoty pod Subskrypcje —> 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 znajdujesz się w odniesieniu 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 wynosi 124 względem limitu 1000. Zwiększenie limitu wymaga żądania pomocy technicznej, dlatego upewnij się, że wiesz wcześniej, kiedy zbliżasz się do progu.
Ograniczenia kosztów
Skalowanie nie polega tylko na rzucaniu większej ilości zasobów na problem. Ważne jest, aby organizacja zrozumiała koszt środowiska chmury i że dodanie większej liczby zasobów zwykle równa się większemu kosztowi. 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.
- Przejrzyj bieżące i przewidywane miesięczne wydatki 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 rozwiązaniem lub nie jest kompletnym rozwiązaniem. W niektórych przypadkach może się okazać, że konieczność skalowania jest w rzeczywistości problemem spowodowanym nieprawidłowym kodowaniem lub konfiguracją.
Możesz potencjalnie zaoszczędzić pieniądze i czas, wyszukując najpierw usterki przed skalowaniem zasobów. Oto kilka przykładów tego podejścia:
- Jeśli masz źle zaprojektowaną bazę danych z gorącymi partycjami, takimi jak korzystanie z tylko jednej partycji w ogromnej bazie danych noSQL, i tak działa wolno niezależnie od skali.
- Jeśli masz nieefektywne zapytania do bazy danych, popraw ich wydajność, zanim dodasz więcej zasobów do bazy 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ć przeciążone z powodu ponownych prób wynikających 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żesz napisać bardziej wydajny kod, aby rozwiązać ten 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ć znaczne oszczędności 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.