Równoważenie obciążenia zwiększa wydajność systemu, zwłaszcza z punktu widzenia aplikacji, umożliwiając kilku komputerom obsługę tych samych danych. Działa w taki sposób, że obciążenie jest rozprowadzane między zapytaniami klientów do węzłów replikacji poza węzłem głównym lub głównym, podczas gdy modyfikacje bazy danych są kierowane wyłącznie do samego węzła głównego. Wszelkie modyfikacje węzła głównego są następnie propagowane do każdej repliki za pomocą replikacji strumieniowej PostgreSQL.
Jak równoważniki obciążenia mogą wpływać na PostgreSQL?
Wykorzystanie równoważenia obciążenia powinno kierować aplikacje klienckie do łączenia się z serwerem równoważenia obciążenia i dystrybuować zainicjowane połączenia do dostępnych węzłów PostgreSQL w zależności od typu żądań zapytania. Pomaga to podkreślić wybitne obciążenie na konkretnym serwerze PostgreSQL i promuje równoległą równowagę obciążenia między dostępnymi węzłami w klastrze.
Korzystając z PostgreSQL, istnieje już kilka istniejących rozwiązań, aby to zadziałało. Rozwiązania te mogą działać bezproblemowo lub równoważenie obciążenia może działać z obecną topologią — z węzłami podstawowymi i rezerwowymi — jednak równoważenie obciążenia jest zaimplementowane w samej warstwie aplikacji. Równoważenie obciążenia stawia czoła wyzwaniom związanym z problemami z synchronizacją, co jest podstawową trudnością dla współpracujących serwerów. Ponieważ nie ma jednego rozwiązania, które eliminuje wpływ problemu z synchronizacją we wszystkich przypadkach użycia, istnieje wiele rozwiązań. Każde rozwiązanie rozwiązuje ten problem w inny sposób i minimalizuje jego wpływ na określone obciążenie.
W tym blogu przyjrzymy się tym równoważnikom obciążenia, porównując je i pokazując, jak korzystne jest to dla obciążenia PostgreSQL.
Równoważenie obciążenia HAProxy dla PostgreSQL
HAProxy to oparty na zdarzeniach, nieblokujący silnik łączący serwer proxy z bardzo szybką warstwą we/wy i wielowątkowym harmonogramem opartym na priorytetach. Ponieważ został zaprojektowany z myślą o przekazywaniu danych, jego architektura jest zaprojektowana do działania w lekkim procesie, który jest zoptymalizowany pod kątem jak najszybszego przenoszenia danych przy jak najmniejszej liczbie operacji. Koncentruje się na optymalizacji wydajności pamięci podręcznej procesora poprzez utrzymywanie połączeń z tym samym procesorem tak długo, jak to możliwe. W związku z tym implementuje model warstwowy oferujący mechanizmy omijania na każdym poziomie, zapewniając, że dane nie osiągają wyższych poziomów, chyba że jest to konieczne. Większość przetwarzania odbywa się w jądrze. HAProxy robi wszystko, co w jego mocy, aby pomóc jądru wykonać pracę tak szybko, jak to możliwe, dając kilka wskazówek lub unikając pewnych operacji, gdy zgaduje, że mogą być później zgrupowane. W rezultacie typowe liczby pokazują 15% czasu przetwarzania spędzonego w HAProxy w porównaniu do 85% w jądrze w trybie zamknięcia TCP lub HTTP i około 30% w przypadku HAProxy w porównaniu do 70% w przypadku jądra w trybie utrzymywania aktywności HTTP.
HAProxy posiada również dodatkowe funkcje równoważenia obciążenia. Na przykład funkcja proxy TCP pozwala nam używać go do połączeń z bazą danych, szczególnie dla PostgreSQL, korzystając z wbudowanej obsługi usługi sprawdzania. Mimo że istnieje obsługa usługi bazy danych, nie wystarczy ona do pożądanej kontroli kondycji, szczególnie w przypadku klastra typu replikacji. Standardowym podejściem podczas wdrażania go w środowisku produkcyjnym jest użycie sprawdzania TCP, a następnie poleganie na xinetd z HAProxy.
Zalety używania HAProxy dla PostgreSQL
Najlepszą rzeczą w HAProxy jest jego lekkość, łatwość konfiguracji i obsługi, a także spełnia oczekiwania. Korzystanie z HAProxy na szczycie klastra PostgreSQL zostało wdrożone i wdrożone wielokrotnie od dużych organizacji do różnych MŚP/SMB do ich użytku produkcyjnego. Od dawna sprawdza się w produkcji i dużej obciążalności nie tylko dla baz danych, ale nawet z innymi usługami sieciowymi, takimi jak aplikacje internetowe lub do równoważenia obciążenia geograficznego (dystrybucja ruchu w wielu centrach danych). Mając HAProxy nad PostgreSQL, umożliwia użytkownikom dławienie lub ograniczanie odpowiedzi w celu zrównoleglenia i prawidłowego rozłożenia obciążenia na wszystkie dostępne węzły w klastrze. Wbudowany mechanizm z HAProxy pozwala również użytkownikowi bezproblemowo skonfigurować wysoką dostępność i łatwiej ją skalować, jeśli potrzebne jest obciążenie i uniknąć pojedynczego punktu awarii (SPOF).
Wady używania HAProxy dla PostgreSQL
HAProxy nie zapewnia filtrowania zapytań ani analizy zapytań w celu zidentyfikowania typu żądanej instrukcji. Brakuje możliwości wykonywania podziału odczytu/zapisu na jednym porcie. Ustawienie load balancera na HAProxy wymaga przynajmniej skonfigurowania różnych portów dla zapisów i innych dla odczytów. Wymaga to zmian aplikacji zgodnie z Twoimi potrzebami.
HAProxy obsługuje również bardzo prostą obsługę funkcji PostgreSQL do sprawdzania stanu, ale to tylko określa, czy węzeł działa, czy nie, tak jakby po prostu pingował węzeł i czekał na odpowiedź zwrotną. Nie identyfikuje roli węzła, który próbuje przekazać żądane połączenia od klienta do żądanego węzła. Dlatego nie rozumie lub nie ma funkcji w HAProxy, aby zrozumieć topologię replikacji. Chociaż użytkownik może tworzyć oddzielne odbiorniki w oparciu o różne porty, ale nadal dodaje zmiany w aplikacji, aby zaspokoić potrzeby równoważenia obciążenia. Oznacza to, że użycie zewnętrznego skryptu z xinetd może stanowić obejście w celu spełnienia wymagań. Mimo to nie jest on zintegrowany z HAProxy i może być podatny na błędy ludzkie.
Jeśli jeden węzeł lub grupa węzłów musi zostać umieszczona w trybie konserwacji, konieczne będzie również zastosowanie zmian w HAProxy, w przeciwnym razie może to być katastrofalne.
Pgpool-II do równoważenia obciążenia w PostgreSQL
Pgpool-II to oprogramowanie o otwartym kodzie źródłowym, które jest wykorzystywane przez ogromną społeczność PostgreSQL do wdrażania równoważenia obciążenia i używania go do działania jako oprogramowanie pośredniczące od aplikacji do warstwy proxy, a następnie rozkłada obciążenie po pełnej analizie typu żądania na zapytanie lub połączenie z bazą danych. Pgpool-II istnieje od 2003 roku i początkowo nosił nazwę Pgpool, aż w 2006 roku stał się Pgpool-II, który służy jako świadectwo bardzo stabilnego narzędzia proxy nie tylko do równoważenia obciążenia, ale także mnóstwa fajnych funkcji .
Pgpool-II jest znany jako szwajcarski scyzoryk dla PostgreSQL i jest oprogramowaniem proxy, które znajduje się pomiędzy serwerami PostgreSQL a klientem bazy danych PostgreSQL. Podstawową ideą PgPool-II jest to, że znajduje się on na kliencie, a następnie zapytania odczytu muszą być dostarczane do węzłów rezerwowych, podczas gdy zapis lub modyfikacje trafiają bezpośrednio do podstawowego. Jest to bardzo inteligentne rozwiązanie równoważenia obciążenia, które nie tylko równoważy obciążenie, ale także obsługuje wysoką dostępność i zapewnia łączenie połączeń. Inteligentny mechanizm pozwala zrównoważyć obciążenie pomiędzy urządzeniami nadrzędnymi i podrzędnymi. Tak więc zapisy są ładowane do urządzenia głównego, podczas gdy odczyty przetwarzania są kierowane do dostępnych serwerów tylko do odczytu, które są rzekomo aktywnymi węzłami gotowości. Pgpool-II zapewnia również replikację logiczną. Chociaż jego użycie i znaczenie spadły, ponieważ wbudowane opcje replikacji poprawiły się po stronie serwera PostgreSQL, nadal pozostaje cenną opcją dla starszych wersji PostgreSQL. Oprócz tego zapewnia również łączenie połączeń.
Pgpool-II ma bardziej zaangażowaną architekturę niż PgBouncer, aby obsługiwać wszystkie funkcje, które robi. Ponieważ oba obsługują łączenie połączeń, to drugie nie ma funkcji równoważenia obciążenia.
Pgpool-II może zarządzać wieloma serwerami PostgreSQL. Korzystanie z funkcji replikacji umożliwia tworzenie kopii zapasowej w czasie rzeczywistym na 2 lub więcej dyskach fizycznych, dzięki czemu usługa może być kontynuowana bez zatrzymywania serwerów w przypadku awarii dysku. Ponieważ Pgpool-II jest również zdolny do pulowania połączeń, może zapewnić ograniczenie przekraczania połączeń. Istnieje limit maksymalnej liczby jednoczesnych połączeń z PostgreSQL, a połączenia są odrzucane po takiej liczbie połączeń. Jednak ustawienie maksymalnej liczby połączeń zwiększa zużycie zasobów i wpływa na wydajność systemu. pgpool-II ma również limit maksymalnej liczby połączeń, ale dodatkowe połączenia będą umieszczane w kolejce zamiast natychmiastowego zwracania błędu.
W przypadku równoważenia obciążenia: Jeśli baza danych jest replikowana, wykonanie zapytania SELECT na dowolnym serwerze zwróci ten sam wynik. pgpool-II korzysta z funkcji replikacji, aby zmniejszyć obciążenie każdego serwera PostgreSQL poprzez dystrybucję zapytań SELECT na wiele serwerów, poprawiając ogólną przepustowość systemu. W najlepszym przypadku wydajność poprawia się proporcjonalnie do liczby serwerów PostgreSQL. Równoważenie obciążenia działa najlepiej w sytuacji, gdy wielu użytkowników wykonuje wiele zapytań jednocześnie.
Dzięki funkcji zapytania równoległego dane mogą być dzielone między wiele serwerów, dzięki czemu zapytanie może być wykonywane na wszystkich serwerach jednocześnie, aby skrócić całkowity czas wykonania. Zapytania równoległe działają najlepiej podczas wyszukiwania danych na dużą skalę.
Zalety używania Pgpool dla PostgreSQL
Jest to bogaty w funkcje rodzaj oprogramowania nie tylko do równoważenia obciążenia. Podstawowe funkcje i wsparcie tego narzędzia są wysoce na żądanie, co zapewnia pulę połączeń, alternatywę go PgBouncer, natywną replikację, odzyskiwanie online, buforowanie zapytań w pamięci, automatyczne przełączanie awaryjne i wysoką dostępność z jego podprocesem za pomocą watchdoga. To narzędzie jest tak stare i jest stale wspierane przez społeczność PostgreSQL, więc radzenie sobie z problemami nie może być trudne do szukania pomocy. Dokumentacja jest tutaj twoim przyjacielem, gdy szukasz pytań, ale szukanie pomocy w społeczności nie jest trudne, a fakt, że to narzędzie jest open-source, możesz z niego swobodnie korzystać, o ile przestrzegasz licencji BSD.
Pgpool-II ma również parser SQL. Oznacza to, że jest w stanie dokładnie przeanalizować kody SQL i przepisać zapytanie. Pozwala to Pgpool-II na zwiększenie równoległości w zależności od żądania zapytania.
Wady używania Pgpool dla PostgreSQL
Pgpool-II nie oferuje STONITH (strzelania drugiego węzła w głowę), który zapewnia mechanizm odgradzania węzłów. Jeśli serwer PostgreSQL ulegnie awarii, utrzymuje dostępność usługi. Pgpool-II może być również pojedynczym punktem awarii (SPOF). Gdy węzeł ulegnie awarii, łączność z bazą danych i dostępność zostaną zatrzymane od tego momentu. Chociaż można to naprawić, stosując nadmiarowość w Pgpool-II i używając watchdoga do koordynowania wielu węzłów Pgpool-II, to dodaje dodatkową pracę.
W przypadku puli połączeń, niestety dla tych, którzy skupiają się tylko na pule połączeń, Pgpool-II nie radzi sobie zbyt dobrze, to pule połączeń, szczególnie dla niewielkiej liczby klientów. Ponieważ każdy proces potomny ma własną pulę i nie ma możliwości kontrolowania, który klient łączy się z którym procesem potomnym, zbyt wiele szczęścia pozostawia się, jeśli chodzi o ponowne wykorzystanie połączeń.
Korzystanie ze sterownika JDBC do równoważenia obciążenia w PostgreSQL
Java Database Connectivity (JDBC) to interfejs programowania aplikacji (API) dla języka programowania Java, który definiuje sposób, w jaki klient może uzyskać dostęp do bazy danych. Jest częścią platformy Java Standard Edition i zapewnia metody zapytań i aktualizacji danych w bazie danych i jest zorientowany na relacyjne bazy danych.
Sterownik PostgreSQL JDBC (w skrócie PgJDBC) umożliwia programom Java łączenie się z bazą danych PostgreSQL przy użyciu standardowego, niezależnego od bazy danych kodu Java. Jest sterownikiem JDBC typu open source napisanym w czystej Javie (typ 4) i komunikuje się w natywnym protokole sieciowym PostgreSQL. Z tego powodu sterownik jest niezależny od platformy; raz skompilowany sterownik może być używany w dowolnym systemie.
Nie jest to porównywalne z rozwiązaniami równoważenia obciążenia, które wskazaliśmy wcześniej. Dlatego to narzędzie jest interfejsem API interfejsu programowania aplikacji, który umożliwia łączenie się z aplikacji dla dowolnego typu języka programowania, który jest napisany, który obsługuje JDBC lub przynajmniej ma adapter do połączenia z JDBC. Z drugiej strony jest to korzystniejsze w przypadku aplikacji Java.
Równoważenie obciążenia za pomocą JDBC jest dość naiwne, ale może wykonać swoje zadanie. Wyposażony w parametry połączenia, które mogą uruchomić mechanizm równoważenia obciążenia, który oferuje to narzędzie,
- targetServerType - umożliwia otwieranie połączeń tylko z serwerami o wymaganym stanie/roli zgodnie z czynnikiem definiującym dla serwerów PostgreSQL. Dozwolone wartości to dowolna, podstawowa, główna (przestarzała), podrzędna (przestarzała), drugorzędna, preferSlave i preferSecondary. Stan lub rola jest określana przez obserwację, czy serwer zezwala na zapisy, czy nie.
- hostRecheckSeconds - kontroluje jak długo w sekundach wiedza o stanie hosta jest buforowana w globalnej pamięci podręcznej JVM. Domyślna wartość to 10 sekund.
- loadBalanceHosts – pozwala skonfigurować, czy pierwszy host jest zawsze próbowany (gdy jest ustawiony na false), czy połączenia są wybierane losowo (gdy ustawione na true)
Czyli używanie loadBalanceHosts, które akceptuje wartość logiczną. loadBalanceHosts jest wyłączone w trybie domyślnym, a hosty są połączone w podanej kolejności. Jeśli ta opcja jest włączona, hosty są wybierane losowo z zestawu odpowiednich kandydatów. Podstawowa składnia podczas łączenia się z bazą danych za pomocą jdbc jest następująca:
- jdbc:postgresql:baza danych
- jdbc:postgresql:/
- jdbc:postgresql://host/baza danych
- jdbc:postgresql://host/
- jdbc:postgresql://host:port/baza danych
- jdbc:postgresql://host:port/
Biorąc pod uwagę, że loadBalanceHosts i połączenie otrzymują wiele hostów skonfigurowanych tak jak poniżej,
jdbc:postgresql://host1:port1,host2:port2,host3:port3/databaseDzięki temu JDBC może losowo wybierać z zestawu odpowiednich kandydatów.
Zalety używania PgJDBC dla PostgreSQL
Nie ma potrzeby wymagać oprogramowania pośredniczącego lub proxy jako systemów równoważenia obciążenia. Ten proces zapewnia większy wzrost wydajności z interfejsu aplikacji, ponieważ nie ma dodatkowej warstwy, przez którą przechodzi każde żądanie. Jeśli masz gotowe aplikacje i napisane są one do obsługi interfejsu z JDBC, może to być korzystne i jeśli nie potrzebujesz więcej oprogramowania pośredniczącego, zwłaszcza jeśli masz napięty budżet i chcesz ograniczyć tylko procesy przeznaczone do jego wyłącznego celu i funkcji. W przeciwieństwie do aplikacji o dużym natężeniu ruchu i dużym zapotrzebowaniu, może wymagać serwerów proxy działających jako systemy równoważenia obciążenia i może wymagać dodatkowych zasobów, aby prawidłowo obsługiwać wysokie żądania połączeń, co również wymaga przetwarzania procesora i pamięci.
Wady używania PgJDBC dla PostgreSQL
Musisz ustawić swój kod dla każdego połączenia, o które chcesz poprosić. Jest to interfejs programowania aplikacji, co oznacza, że trzeba sobie z tym poradzić, zwłaszcza jeśli Twoja aplikacja jest bardzo wymagająca, aby każde żądanie zostało wysłane do odpowiednich serwerów. Nie ma wysokiej dostępności, automatycznej skalowalności i ma pojedynczy punkt awarii.
Co powiesz na wrappery lub narzędzia zaimplementowane za pomocą libpq do równoważenia obciążenia w PostgreSQL?
libpq to interfejs programisty aplikacji C do PostgreSQL. libpq to zestaw funkcji bibliotecznych, które umożliwiają programom klienckim przekazywanie zapytań do serwera zaplecza PostgreSQL i otrzymywanie wyników tych zapytań.
libpq jest również podstawowym silnikiem dla kilku innych interfejsów aplikacji PostgreSQL, w tym tych napisanych dla C++, PHP, Perl, Python, Tcl, Swift i ECPG. Więc niektóre aspekty zachowania libpq będą dla ciebie ważne, jeśli użyjesz jednego z tych pakietów.
libpq nie automatyzuje równoważenia obciążenia i nie należy go traktować jako narzędzia do rozwiązań równoważenia obciążenia. Jednak jest w stanie połączyć się z następnymi dostępnymi serwerami, jeśli poprzednie serwery wymienione dla połączenia nie powiedzie się. Na przykład, jeśli masz dwa dostępne węzły gorącej rezerwy, jeśli pierwszy węzeł jest zbyt zajęty i nie odpowiada na odpowiednią wartość limitu czasu, łączy się z następnym dostępnym węzłem w danym połączeniu. Opiera się na typie określonych atrybutów sesji. Opiera się to na parametrze target_session_attrs.
Parametr target_session_attrs akceptuje wartości do odczytu-zapisu oraz wszelkie wartości domyślne, jeśli nie zostały określone. Parametr target_session_attrs oznacza, że jeśli jest ustawiony na odczyt-zapis, tylko połączenie, w którym transakcje odczytu i zapisu są akceptowane podczas połączenia. Zapytanie SHOW transaction_read_only zostanie wysłane po każdym udanym połączeniu. Jeśli wynik jest włączony, połączenie zostanie zamknięte, co oznacza, że węzeł jest identyfikowany jako replika lub nie przetwarza zapisów. Jeśli w ciągu połączenia określono wiele hostów, wszystkie pozostałe serwery zostaną wypróbowane tak, jakby próba połączenia się nie powiodła. Domyślna wartość tego parametru, any, co oznacza, że wszystkie połączenia są dopuszczalne. Chociaż poleganie na target_session_attrs nie wystarcza do równoważenia obciążenia, możesz być w stanie zasymulować sposób okrężny. Zobacz mój przykładowy kod C poniżej przy użyciu libpq,
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <unistd.h>
#include <libpq-fe.h>
const char* _getRoundRobinConn() {
char* h[2];
h[0] = "dbname=node40 host=192.168.30.40,192.168.30.50";
h[1] = "dbname=node50 host=192.168.30.50,192.168.30.40";
time_t t;
//srand((unsigned)time(&t));
sleep(1.85);
srand((unsigned)time(NULL));
return h[rand() % 2];
}
void
_connect()
{
PGconn *conn;
PGresult *res;
char strConn[120];
snprintf(strConn, 1000, "user=dbapgadmin password=dbapgadmin %s target_session_attrs=any", _getRoundRobinConn());
//printf("\nstrConn value is: %s\n", strConn);
conn = PQconnectdb(strConn);
res = PQexec(conn, "SELECT current_database(), inet_client_addr();");
if ( PQresultStatus(res)==PGRES_TUPLES_OK )
{
printf("current_database = %s on %s\n", PQgetvalue(res, 0, 0),
PQhost(conn));
} else {
printf("\nFailed... Message Code is: %d\n", PQresultStatus(res));
}
PQclear(res);
PQfinish(conn);
}
int main(void)
{
int i;
for (i=0 ; i<5 ; i++)
_connect();
return 0;
}Wynik ujawnia,
[email protected]:/home/vagrant# gcc -I/usr/include/postgresql -L/usr/lib/postgresql/12/lib libpq_conn.c -lpq -o libpq_conn; ./libpq_conn
current_database = node40 on 192.168.30.40
current_database = node40 on 192.168.30.40
current_database = node50 on 192.168.30.50
current_database = node40 on 192.168.30.40
current_database = node50 on 192.168.30.50Pamiętaj, że jeśli węzeł .40 (główny węzeł) ulegnie awarii, zawsze przekieruje połączenie na .50, o ile wartość target_session_attrs jest dowolna.
W takim przypadku możesz po prostu swobodnie tworzyć własne za pomocą libpq. Chociaż proces polegania na libpq i/lub jego opakowaniach jest zbyt surowy, aby powiedzieć, że może to zapewnić pożądany mechanizm równoważenia obciążenia z równomierną dystrybucją do posiadanych węzłów. Zdecydowanie to podejście i kodowanie można ulepszyć, ale myśl jest taka, że jest to bezpłatne i otwarte oprogramowanie, i można kodować bez polegania na oprogramowaniu pośredniczącym i swobodnie projektować sposób, w jaki ma działać równoważenie obciążenia.
Zalety używania libpq dla PostgresQL
Biblioteka libpq to interfejs aplikacji programisty zbudowany w języku programowania C. Jednak biblioteka została zaimplementowana w różnych językach jako wrappery, dzięki czemu programiści mogą komunikować się z bazą danych PostgreSQL w swoich ulubionych językach. Możesz bezpośrednio stworzyć własną aplikację, używając swoich ulubionych języków, a następnie wylistować serwery, na które chcesz wysyłać zapytania, ale tylko po drugim, jeśli awaria lub przekroczenie limitu czasu spowoduje wysłanie obciążenia do dostępnych węzłów, na które zamierzasz rozłożyć obciążenie. Jest dostępny w językach takich jak Python, Perl, PHP, Ruby, Tcl lub Rust.
Wady używania libpq dla PostgresQL
Implementacja pod kątem równoległości obciążenia nie jest idealna i musisz napisać własny mechanizm równoważenia obciążenia za pomocą kodu. Nie ma konfiguracji, której można użyć lub dostosować, ponieważ jest to sam interfejs programistyczny do bazy danych PostgreSQL za pomocą parametru target_session_attrs. Oznacza to, że podczas tworzenia połączenia z bazą danych musisz mieć serię połączeń odczytu idących do węzłów repliki/wstrzymania, a następnie pisać zapytania, które trafiają do węzła zapisującego lub węzła podstawowego w kodzie, niezależnie od tego, czy jest to Twoja aplikacja, czy też musisz utworzyć własny interfejs API do zarządzania rozwiązaniem równoważenia obciążenia.
Korzystanie z tego podejścia zdecydowanie nie wymaga ani nie polega na oprogramowaniu pośredniczącym z perspektywy aplikacji typu front-end do bazy danych jako zaplecza. Oczywiście jest to lekkie, ale wysyłając listę serwerów po połączeniu, nie oznacza to, że obciążenie jest rozumiane i wysyłane równomiernie, chyba że musisz dodać swój kod dla tego podejścia. To tylko dodaje kłopotów, ale istnieją już rozwiązania, więc po co wymyślać koło na nowo?
Wnioski
Implementacja load balancerów za pomocą PostgreSQL może być wymagająca, ale zależy od typu aplikacji i kosztów, z którymi masz do czynienia. Czasami, w przypadku dużego obciążenia, wymaga to zastosowania oprogramowania pośredniczącego działającego jako proxy w celu prawidłowego rozłożenia obciążenia, a także nadzoru jego stanu lub kondycji węzła. Z drugiej strony może wymagać zasobów serwera albo musi być uruchomiony na serwerze dedykowanym, albo wymagać dodatkowego procesora i pamięci w celu zaspokojenia potrzeb, co zwiększa koszty. Dlatego istnieje również prosty, ale czasochłonny sposób, ale oferujący rozłożenie obciążenia na dostępne serwery, które już masz. Wymaga to jednak umiejętności programistycznych i zrozumienia funkcjonalności interfejsu API.
