Piszki Lab

Analiza przypadku w języku przodków…

Horizon Workspace: Wysokodostępny klaster bazodanowy oparty o vPostgres

| 0 comments

W związku z premierą Horizon Workspace 1.8 (konieczność wykonanie upgrade), oraz rozpoczynającymi się testami naszego nowego rozwiązania opartego w części na Workspace, postanowiłem przemodelować całkowicie środowisko w jakim on funkcjonuje. Na pierwszy rzut poszła baza danych. Już od jakiegoś czasu jesteśmy posiadaczami elementów VMware vFabric, w tym vPostgresa, z którego jesteśmy bardzo zadowoleni (bo kto by nie był zadowolony z posiadanego produkcyjnego wsparcia na bazę danych typu PostgreSQL). W przygotowanym rozwiązaniu wykorzystałem trzy instalacje vPostgres Appliance 9.3.2, dwie działające w trybie instancji głównej i repliki (jako backup ostateczny) oraz trzeciej działającej aktywnie. Nody działające w trybie aktywnym są replikowane poprzez PGpool-II (zainstalowany osobno na CentOS). W takim schemacie PGpool-II to SPOF, dlatego najlepiej jest przygotować dwie instalacje i użyć load balancera (w naszym przypadku na produkcji BIG-IP F5). Lub wykorzystać dwie instalacje PGpool-II z włączonym Watchdogiem i pływającym pomiędzy maszynami “wirtualnym” adresem IP (tak działa instalacja w labie). Opisywane przeze mnie rozwiązanie jest jak najbardziej uniwersalne, może być z powodzeniem użyte do uruchomienia klastra PostgreSQL dla vCloud Automation Center (i zapewne w przyszłości do vCSA 6.0 które ma wspierać zewnętrzną bazę danych PostgreSQL).

postgres_cluster

W pierwszej kolejności musimy przygotować wszystkie serwery vPostgres tak, aby poprawnie działały z Horizon Workspace.

W pliku /var/vmware/vpostgres/current/pgdata/postgresql.conf ustawiamy dwie zmienne (uwaga: poniżej linii include postgresql.conf.auto):

max_connections = 600

search_path = 'saas'

Następnie restartujemy (jako root) vPostgres poleceniem: service vpostgres_mon stop/start.

W kolejnym kroku konfigurujemy parę serwerów główny –> replika. Zakładamy bazę danych, może mieć dowolną nazwę, niekoniecznie saas (to samo dotyczy właściciela bazy danych). Ważne aby założony został schemat o nazwie saas oraz załadowane rozszerzenie citext wskazujące na schemat saas, tak jak na poniższym rysunku (bez tego Workspace będzie raportował błędy bazy danych):

postgres1

Mamy przygotowaną bazę danych, przechodzimy na drugi serwer, który będzie repliką, do katalogu: /opt/vmware/vpostgres/current/scripts i wykonujemy następujące polecenie (jako użytkownik postgres):

./run_as_replica -h IP_MASTER -b -W -U postgres

Skrypt zainicjuje zamianę wszystkich potrzebnych ustawień na obydwu serwerach vPostgres. Po zakończeniu jego wykonywania będziemy mieć działającą poprawnie parę Master—>Slave.

postgres2

Stan replikacji możemy sprawdzić skryptem show_replication_status:

postgres3

Po ewentualnej awarii wystarczy wykonać skrypt promote_replica_to_primary aby slave przeszedł w tryb zapisu. Jeśli poprzestaniemy na takiej konfiguracji, to po wypromowaniu nowego serwera typu master, musimy zmienić ścieżkę JDBC w Horizon Workspace Connector ręcznie:

horizon4

Wstępną konfigurację mamy zrobioną, teraz zainstalujemy i skonfigurujemy PG_POOL. Ja wybrałem jako podstawę instalacji dystrybucję linuksa CentOS, z wielu względów, jest darmowa i wspierana w bardzo wielu rozwiązaniach związanych z vSphere (np. Trend Micro Deep Security). Niestety w wersji 64-bitowej nie ma pakietu PGpool-II, należy go ściągnąć i zainstalować ręcznie. Można oczywiście zainstalować go też bezpośrednio w Appliance vPostgres, ale tutaj należy pamiętać, że nie jest to do końca “standardowa” dystrybucja i może sprawiać nam problemy przy kolejnym upgrade (jeśli w niej namieszamy). Poza tym, stosując loadbalancer, łatwiej jest wygenerować kolejne nody PGpool-II niż kolejne instancje vPostgres.

Konfiguracja PGpool-II nie jest trudna, wszystkie potrzebne pliki znajdują się w /etc/pgpool-II. W pliku pgpool.conf ustawiamy następujące opcje:

listen_adress = ‘*’         <—słuchamy na każdym interfejsie
port = 5432                 <—domyślnie jest 9999, ale to tylko w przypadku gdy pgpool jest instalowany razem z PostgreSQL
backend_hostname0 = ‘ugdbp1.pulab.local’  <—nazwa pierwszego noda
backend_port0 = 5432        <—port bazy danych
backend_weight0 = 1         <—priorytet
backend_hostname1 = ‘ugdbp2.pulab.local’ <—nazwa drugiego noda
backend_port1 = 5432
backend_weight1 = 1         <—czyli mają ten sam priorytet
enable_pool_hba = on        <—możliwość łączenia się do pg_pool z zewnątrz
pool_passwd = ‘pool_passwd’ <—plik z hasłami uprawnionych użytkowników
num_init_children = 300
max_pool = 2                <—limity połączeń, czyli 600=300x2 (patrz wyżej)
replication_mode = on       <—synchroniczny zapis na obydwa nody
load_balance_mode = on      <—asynchroniczny odczyt z różnych nodów

Konfiguracja Watchdog przedstawia się następująco:

use_watchdog = on
trusted_servers = '192.168.60.1'  <—Brama do testowania sieci
ping_path = '/bin'
 
wd_hostname = '192.168.60.134' <—Nazwa lokalnego noda
wd_port = 9000
wd_authkey = ''
 
delegate_IP = '192.168.60.136'    <-- Pływający adres
ifconfig_path = '/sbin'
if_up_cmd = 'ifconfig eth1:0 inet $_IP_$ netmask 255.255.255.0'
if_down_cmd = 'ifconfig eth1:0 down'
arping_path = '/usr/sbin'
arping_cmd = 'arping -U $_IP_$ -w 1'
 
clear_memqcache_on_escalation = on
wd_escalation_command = ''
wd_lifecheck_method = 'heartbeat'
wd_interval = 10
wd_heartbeat_port = 9694
wd_heartbeat_keepalive = 2
wd_heartbeat_deadtime = 30
 
heartbeat_destination0 = '192.168.60.135'    <—adres drugiego serwera Watchdog
heartbeat_destination_port0 = 9694
heartbeat_device0 = 'eth1'
 
wd_life_point = 3
wd_lifecheck_query = 'SELECT 1'
wd_lifecheck_dbname = 'template1'
wd_lifecheck_user = 'nobody'
wd_lifecheck_password = ''
 
other_pgpool_hostname0 = '192.168.60.135' <—adres drugiego serwera PGpool
other_pgpool_port0 = 5432
other_wd_port0 = 9000

Na drugim serwerze konfiguracja jest dokładnie odwrotna (adresy IP). Jeśli wszystko działa poprawnie, możemy swobodnie wyłączać poszczególne serwery PGpool-II i adres “wirtualny” będzie poprawnie przenoszony pomiędzy maszynami:

watchdog

W pliku pool_hba.conf ustawiamy dozwolone metody połączeń, obowiązuje dokładnie ta sama zasada co w PostgreSQL (możemy ustawić host all all 0.0.0.0/0 md5). W pliku pool_passwd musimy wpisać wszystkich użytkowników z baz danych którzy będą się łączyć do PostgreSQL poprzez PGpool-II w schemacie USER:MD5HASH. Ważna uwaga, w dokumentacji hash można wygenerować poleceniem pg_md5, błąd, to polecenie generuje błędny hash. Prawidłowy należy wyciągnąć bezpośrednio z bazy danych (jeśli używamy pgAdmina to wystarczy kliknąć na daną rolę). Natomiast jeśli chcemy wykorzystać pgpoolAdmin, to w pliku pcp.conf zapisane hasła muszą zostać wygenerowane za pomocą pg_md5. I to w zasadzie wszystko, PGpool-II jest całkowicie przeźroczysty, nie generuje obciążenia na maszynie, super rozwiązanie.

Na koniec kilka słów o awarii. W przypadku pary Master—>Slave schemat jest znany, pada master, promujemy drugiego noda do roli mastera i przełączamy aplikację na wypromowany serwer. Po usunięciu awarii, po prostu podpinamy odzyskany serwer jako slave. W przypadku gdy mamy dwa aktywne nody, awaria jednego nie wpływa na pracę aplikacji, PGpool-II po prostu przestaje się łączyć do drugiego noda i wszystkie zapytania przekazuje do pierwszego. Po usunięciu awarii, absolutnie nie możemy tak po prostu uruchomić odzyskanego serwera. Należy wyłączyć aplikację i uspójnić bazy danych (podłączyć się jako slave, wszystko się skopiuje samo, i wypromować serwer), i dopiero włączyć aplikację. Różnica jak widać sprowadza się do jednego, w wariancie pierwszym wyłączamy aplikację kiedy musimy, a w drugim kiedy chcemy Uśmiech

Można też wykorzystać mechanizmy failover dostarczone razem z PGpool-II, jeszcze ich nie testowałem, jak już uzupełnię wiedzę to postaram się zdać relację czy ten mechanizm działa poprawnie.

English

Oceń ten artykuł:
[Total: 1 Average: 5]

Dodaj komentarz

Required fields are marked *.