System równoważenia obciążenia bazy danych lub odwrotny serwer proxy bazy danych rozdziela przychodzące obciążenie bazy danych na wiele serwerów baz danych działających za nim. Celem równoważenia obciążenia bazy danych jest zapewnienie pojedynczego punktu końcowego bazy danych dla aplikacji, z którym mogą się łączyć, zwiększenie przepustowości zapytań, zminimalizowanie opóźnień i maksymalizację wykorzystania zasobów serwerów baz danych.
Istnieją dwa sposoby topologii równoważenia obciążenia bazy danych:
- Scentralizowana topologia
- Rozproszona topologia
W tym poście na blogu omówimy obie topologie i zrozumiemy niektóre wady i zalety każdej konfiguracji. Ponadto, czy byłoby możliwe łączenie obu topologii razem?
Scentralizowana topologia
W konfiguracji scentralizowanej zwrotny serwer proxy znajduje się pomiędzy warstwą danych i prezentacji, co przedstawia poniższy diagram:
Aby wyeliminować pojedynczy punkt awarii, należy ustawić maksymalnie dwa węzły równoważenia obciążenia w celu zapewnienia nadmiarowości. Jeśli aplikacja może obsługiwać wiele punktów końcowych bazy danych, na przykład aplikacja lub sterownik bazy danych może przeprowadzać kontrole kondycji, jeśli moduł równoważenia obciążenia jest w dobrej kondycji pod kątem przetwarzania zapytań, prawdopodobnie możesz pominąć część dotyczący wirtualnego adresu IP. W przeciwnym razie oba węzły modułu równoważenia obciążenia powinny być powiązane ze wspólną nazwą hosta lub wirtualnym adresem IP, aby zapewnić przejrzystość klientom bazy danych, w których wystarczy użyć jednego punktu końcowego bazy danych, aby uzyskać dostęp do warstwy danych. Korzystanie z mapowania DNS lub hosta jest również możliwe, jeśli chcesz pominąć korzystanie z wirtualnych adresów IP.
To podejście oparte na warstwach jest znacznie prostsze w zarządzaniu ze względu na niezależne, statyczne rozmieszczenie hosta. Jest bardzo mało prawdopodobne, aby warstwa modułu równoważenia obciążenia była skalowana (dodając więcej węzłów) ze względu na jej solidne podstawy w zakresie odporności, nadmiarowości i przejrzystości w warstwie aplikacji. Prawdopodobnie musisz skalować hosta w górę (dodając więcej zasobów do hosta), co zwykle nastąpi w przyszłości, gdy obciążenia związane z systemem równoważenia obciążenia staną się bardziej wymagające wraz z rozwojem firmy.
Ta topologia wymaga dodatkowej warstwy i hostów, co może być kosztowne w przypadku infrastruktury typu bare metal z serwerami fizycznymi. Ta konfiguracja jest łatwiejsza do zarządzania w chmurze lub środowisku wirtualnym, gdzie można elastycznie dodawać dodatkową warstwę między warstwą aplikacji a bazą danych, bez ponoszenia zbyt dużych kosztów infrastruktury fizycznej, takich jak koszty energii elektrycznej, miejsca w szafie i sieci.
Rozproszona topologia
W konfiguracji topologii rozproszonej systemy równoważenia obciążenia są rozmieszczone w warstwie prezentacji (serwery aplikacji lub sieci), co upraszcza poniższy diagram:
Aplikacje traktują system równoważenia obciążenia bazy danych podobnie jak lokalny serwer bazy danych, load balancer staje się reprezentacją zdalnych baz danych z perspektywy aplikacji. Zwykle system równoważenia obciążenia będzie nasłuchiwał lokalnego interfejsu sieciowego, takiego jak 127.0.0.1 lub „localhost”, co usprawni działanie hosta bazy danych punktu końcowego dla aplikacji.
Jedną z zalet pracy w tej topologii jest to, że nie potrzebujesz dodatkowych hostów do celów równoważenia obciążenia. Łącząc warstwę równoważenia obciążenia w warstwie prezentacji, moglibyśmy zaoszczędzić co najmniej dwa hosty. W środowisku gołego metalu ta topologia może potencjalnie zaoszczędzić wiele pieniędzy na przestrzeni lat. Ogólnie rzecz biorąc, obciążenie pracą systemu równoważenia obciążenia jest znacznie mniej wymagające w porównaniu z obciążeniem bazy danych lub aplikacji, co sprawia, że uzasadnione jest współdzielenie tych samych zasobów sprzętowych z aplikacjami.
Gdy znajdujesz się w tym samym miejscu co serwer aplikacji, zbliżasz zwrotny serwer proxy do aplikacji i eliminujesz pojedynczy punkt awarii. Może to znacznie poprawić wydajność aplikacji, gdy istnieje geograficzna separacja między aplikacją a warstwą danych, szczególnie w przypadku systemów równoważenia obciążenia bazy danych, które obsługują buforowanie zestawu wyników, takie jak ProxySQL i MaxScale. Z drugiej strony liczba systemów równoważenia obciążenia bazy danych jest zwykle równa liczbie węzłów aplikacji, co oznacza, że jeśli warstwa aplikacji jest skalowana w górę, liczba systemów równoważenia obciążenia bazy danych będzie wzrastać, co może potencjalnie obniżyć wydajność dla kondycji bazy danych sprawdź usługę. Zwróć uwagę, że kontrole kondycji modułu równoważenia obciążenia są nieco bardziej pogawędkowe ze względu na jego odpowiedzialność za nadążanie za prawidłowym stanem węzłów bazy danych.
Przy pomocy narzędzi do automatyzacji infrastruktury IT, takich jak Chef, Puppet i Ansible, wraz z narzędziami do orkiestracji kontenerów, automatyzacja wdrażania i zarządzania wieloma instancjami load balancera dla tej topologii nie jest już niemożliwym zadaniem. Jednak będzie następna krzywa uczenia się dla zespołu operacyjnego, aby wymyślić sprawdzone w boju, zasady wdrażania i zarządzania na poziomie produkcyjnym, aby zmniejszyć nadmierną pracę podczas obsługi wielu węzłów równoważenia obciążenia. Nie przegap wszystkich ważnych aspektów zarządzania systemem równoważenia obciążenia bazy danych, takich jak tworzenie kopii zapasowych/przywracanie, aktualizacja/obniżanie wersji, zarządzanie konfiguracją, kontrola usług, zarządzanie błędami i tak dalej.
Rozproszona topologia może być mieszana z topologią scentralizowaną dla niektórych obsługiwanych systemów równoważenia obciążenia baz danych, takich jak ProxySQL, jak pokazano na poniższym diagramie:
Serwery backendu instancji ProxySQL mogą być innym zestawem ProxySQL zamiast węzłów. W tej konfiguracji wirtualny adres IP nie jest konieczny do uzyskania dostępu do pojedynczego punktu końcowego do węzłów bazy danych, ponieważ lokalna instancja ProxySQL hostowana lokalnie na serwerze aplikacji będzie pojedynczym dostępem do punktu końcowego z punktu widzenia aplikacji.
Wymaga to jednak dwóch wersji konfiguracji modułu równoważenia obciążenia — jednej, która znajduje się w warstwie aplikacji, a druga znajduje się w warstwach modułu równoważenia obciążenia. Wymaga również większej liczby hostów, z wyjątkiem konieczności poznania technologii wirtualnego adresu IP, przełączania awaryjnego IP i tak dalej. W tej topologii łączą się zalety i wady zarówno konfiguracji rozproszonej, jak i scentralizowanej.
Wnioski
Każda topologia ma swoje zalety i wady i musi być dobrze zaplanowana od samego początku. Ta wczesna decyzja ma kluczowe znaczenie i może mieć ogromny wpływ na wydajność aplikacji, skalowalność, niezawodność i dostępność w dłuższej perspektywie.
