Inspiracja , wiedza , realizacja
Jsystems

W przebudowie

Login



Java

Oracle

Linux

Android

PostgreSQL

Microsoft SQL Server

Narzędzia systemu Linux

Data dodania: Jun 16, 2016
Data aktualizacji: Jun 16, 2016

Vmstat




VmStat to narzędzie pozwalające podglądać co się w danym momencie dzieje w systemie. Zrzuca co wskazany w sekundach czas migawki zawierające informacje o aktualnym obciążeniu systemu. Narzędzie wywołujemy z parametrem określającym w sekundach co jaki czas ma być wykonywany zrzut statystyk.

Wyjaśnienie kolumn w wyniku:

r: liczba procesów w kolejce oczekujących na uruchomienie.

b: liczba procesów w stanie uśpienia

swpd: użyta pamięć wirtualna

free: wolna pamięć

buff: zużycie pamięci na potrzeby buforów

cache: pamięć użyta o buforowania

si: ilość bloków (1kB) pamięci odczytana z pamięci wirtualnej

so: ilość bloków (1kB) pamięci zapisana w pamięci wirtualnej

bi: ilość bloków (1kB) odczytanych z dysku

bo: ilość bloków (1kB) zapisanych na dysku

in: liczba przerwań procesora

cs: ilość przełączeń kontekstu

us: czas procka wykorzystany na programy inne niż elementy systemu operacyjnego.

sy: czas procka wykorzystany na działalność związaną z systemem operacyjnym

id: Czas bezczynności procesora

wa: tak zwane „waits” czyli oczekiwanie na urządzenia typu dysk twardy


Iostat


Program umożliwia sprawdzenie statystyk użycia poszczególnych dysków. Wyniki które zobaczymy to dane od ostatniego restartu. Dzięki iostat możemy sprawdzić ile danych zostało odczytanych i zapisanych na poszczególnych dyskach, od uruchomienia systemu, a także jaka była średnia prędkość zapisu i odczytu na nich w tym czasie. Parametr 5 podany na końcu sprawia że wyniki będą się pojawiały co 5 sekund.




TOP


Top to narzędzie służące do sprawdzenia najbardziej obciążających system procesów. Możemy dzięki niemu podejrzeć co najbardziej zużywa nam pamięć operacyjną czy procesor.




Zasadniczo aby go uruchomić wystarczy w konsoli wywołać „top”, ale jeśli interesują nas konkretnie procesy PostgreSQL możemy wywołać „ top | grep postgres ”:




IOTOP


Narzędzie zbliżone do TOP, z tą różnicą że prezentowane obciążenia dotyczą procesów generujących I/O.



Tutaj również możemy użyć grep aby odfiltrować zdarzenia związane z PostgreSQL:



HTOP


Nieco przyjemniejsze dla oka niż TOP narzędzie do badania aktualnego obciążenia. Taka „lepsza” wersja TOPa. – uwzględnia np. zużycie poszczególnych procesorów.



GNOME SYSTEM MONITOR


Bardzo wygodne narzędzie przedstawiające graficznie aktualne wykorzystanie procesorów, przestrzeni wymiany i sieci.


SAR


To jest narzędzie-nakładka dla sysstat. Należy więc zainstalować obydwa. Sysstat zbiera dane o aktualnym obciążeniu systemu, a sar je prezentuje. Jak widać na poniższej ilustracji, SAR prezentuje zrzuty obciążenia systemu co 10 minut. Dzięki niemu możemy podejrzeć kiedy w ciągu dnia system ma najmniej pracy, gdybyśmy zechcieli zaplanować jakieś obciążające operacje związane z utrzymaniem.



Replikacja

Skalowanie z użyciem replikacji

Czy baza danych np. Google mogłaby być oparta na jednej bazie danych – jednym serwerze? Wątpliwe :) Jeśli zbiór danych musi być jeden a potrzebujemy mocy obliczeniowej wielu serwerów możemy do skalowania tego typu wykorzystać dostępną w PostgreSQL replikację. System który za chwilę skonfigurujemy będzie działał w taki sposób, że będzie jeden serwer Master z którego baza będzie replikowana na kilka innych serwerów. W zależności od sposobu konfiguracji replikacji (a może być synchroniczna lub asynchroniczna) możemy mieć dokładne kopie bazy na kilku serwerach. Serwer master będzie działał w trybie zapis-odczyt, a serwery slave w trybie tylko do odczytu. Aplikacja korzystająca z takie systemu wszelkie zmiany danych będzie przeprowadzać na serwerze master, ale odczyt danych będzie rozłożony na kilka serwerów (w końcu będą miały te same dane). Dzięki czemu rozłożone zostanie również obciążenie wynikające z odpytywania baz. Z takiej konfiguracji wynika jeszcze jedna dodatkowa korzyść. Mianowicie jeśli serwer Master ulegnie awarii, któryś z serwerów Slave może go zastąpić. Tryb Hot Standby a więc taki rodzaj konfiguracji jaki za chwilę przeprowadzimy jest dostępny od wersji 8.2. Możliwość działania bazy replikującej w trybie tylko do odczytu wprowadzono w wersji 9.0.



Konfiguracja serwera MASTER


Zaczniemy od konfiguracji serwera MASTER – a więc tego który ma być replikowany.


Z informacji wstępnych dla wyjaśnienia – serwer MASTER ma u mnie adres IP = 192.168.0.101, serwer SLAVE – 192.168.0.100. Replikacja została wykonana na serwerach z CentOS 6.7 i PostgreSQL w wersji 9.4.


Opisany tutaj sposób replikacji to replikacja strumieniowa asynchroniczna. Oznacza to, że powtórzenie zmiany na serwerze SLAVE nie następuje od razu (choć zazwyczaj dość szybko, zależy to od aktualnego obciążenia serwerów i sieci).


Przejdź do systemowego użytkownika „postgres” i z poziomu psql utwórz użytkownika z poziomu którego przeprowadzana będzie replikacja:



create user rep replication;



Następnie przejdź do edycji pliku postgresql.conf:



nano /var/lib/pgsql/9.4/data/postgresql.conf



Musimy zmienić kilka parametrów. Zacznijmy od listen_address – aby serwer SLAVE mógł dokonywać replikacji będziemy potrzebować możliwości dobicia się do niego przez sieć, tak więc ustaw adresy które mają być akceptowane, bądź * . Pamiętaj by odremowywać wszystkie parametry!




Kolejna rzecz to parametr wal_level którą ustawiamy na wartość hot_standby. Umożliwi to replikację wpisów z dzienników WAL:




Kolejne dwa bardzo ważne parametry to max_wal_senders i wal_keep_segments. max_wal_senders określa ile może być maksymalnie serwerów SLAVE – czyli w zasadzie na ilu serwerach może być prowadzona replikacja naszego serwera. Ja daję na potrzeby tego przykładu 1, ale oczywiście możesz dać też wyższą wartość. Parametr wal_keep_segments określa liczbę plików WAL która ma być przetrzymywana na wypadek gdyby przykładowo serwer SLAVE uległ awarii i nie można było na bieżąco kopiować wpisów. Pamiętaj że każdy plik WAL to 16MB, musisz więc dysponować przestrzenią wystarczającą do ewentualnego przechowania takiego zbioru plików.




Nieco niżej znajduje się parametr synchronous_standby_names. Wprowadzamy tam listę serwerów które mogą prowadzić replikację – na ten moment daję * czyli wszystkie, później w razie potrzeby to zmienię.




Poniżej lista parametrów i ich wartości jakie powinny być ustawione:


listen_address='*'

wal_level = hot_standby

max_wal_senders = 1

wal_keep_segments = 10

synchronous_standby_names = '*'


Przechodzimy teraz do pliku pg_hba.conf i przeprowadzamy drobną edycję aby umożliwić serwerowi SLAVE podpięcie się do serwera MASTER w celu replikacji:


nano /var/lib/pgsql/9.4/data/pg_hba.conf


Na końcu dodajemy wpis podobny do poniższego. Pierwszy parametr oznacza połączenia sieciowe, drugi rodzaj połączenia (tutaj replikacja). Trzeci użytkownika któremu na to pozwalamy, czwarty to adres IP serwera SLAVE lub ewentualnie sieć w której będą serwery kopiujące. Ostatni to rodzaj autoryzacji - „trust” oznacza dostęp bez hasła – ostatecznie użytkownikowi REP nie ustawialiśmy żadnego. Nie przejmuj się za bardzo bezpieczeństwem w tym przypadku, ponieważ dostęp do serwera MASTER w celu replikacji będzie możliwy tylko ze wskazanych hostów.


host replication rep 192.168.0.100/32 trust



Aby przeładować konfigurację zrestartuj teraz serwer:


service postgresql-9.4 restart



Konfiguracja serwera SLAVE


Ponieważ będziemy usuwać zawartość katalogu z plikami danych, zatrzymaj wcześniej serwer PostgreSQL:


service postgresql-9.4 stop



 Usuń zawartość katalogu z plikami danych. Za chwilę zostaną tutaj skopiowane pliki z serwera MASTER.


rm -rf /var/lib/pgsql/9.4/data/*


Upewnij się jeszcze czy faktycznie katalog jest pusty:


ls /var/lib/pgsql/9.4/data/



 Ponieważ replikacja polega na powtarzaniu na serwerze SLAVE operacji które zostały wykonane na serwerze MASTER, musimy mieć jakiś punkt wyjścia. Tym punktem wyjścia będzie kopia zapasowa. Tutaj wykorzystujemy program pg_basebackup (powinien być w katalogu z binariami – tam gdzie m.in. psql). Jako parametr pierwszy wskazujemy katalog w którym mają znaleźć się pliki danych i pliki konfiguracyjne, drugi parametr to adres IP serwera MASTER, trzeci to użytkownik z poziomu którego chcemy tę kopię wykonać. W tym przypadku jest to przed momentem stworzony użytkownik REP.


pg_basebackup -D /var/lib/pgsql/9.4/data/ -h 192.168.0.101 -U rep



 Operacja ta może potrwać, uzbrój się więc w cierpliwość. Kopiowana jest przecież cała baza, a jeśli Twoja jest duża to zajmie to chwilę. Gdy operacja się zakończy zweryfikuj czy pliki powstały:


ls /var/lib/pgsql/9.4/data/



 Tworzymy teraz plik recovery.conf w katalogu /var/lib/pgsql/9.4/data/ . Taki plik zazwyczaj służy po prostu do odtwarzania bazy, w tym jednak przypadku wskazuje serwer z którego ma być przeprowadzana replikacja (parametr primary_conninfo), oraz plik którego pojawienie się spowoduje uruchomienie serwera SLAVE w normalnym trybie działania zapis/odczyt (np. w sytuacji gdy będzie on musiał awaryjnie zastąpić serwer MASTER). Takie rozwiązanie może być skuteczne w przypadku gdybyśmy musieli szybko przywrócić system oparty o tę bazę do działania, jednak powoduje przerwanie replikacji! Serwer SLAVE przechodzi w takim wypadku z trybu tylko odczyt do trybu zapis-odczyt.


cd /var/lib/pgsql/9.4/data/


nano recovery.conf


Do tego pliku wprowadzać informacje wg poniższego wzorca:


standby_mode=on

trigger_file='/tmp/odpalacz'

primary_conninfo='host=192.168.0.101 port=5432 user=rep application_name=mapetyzmy'


Przejdźmy teraz na moment do pliku postgresql.conf. Dokonamy zmiany która umożliwi dostęp do serwera SLAVE w trybie tylko do odczytu. Znajduje to zastosowanie jako swoisty „load balancing”. Serwer master służy w takiej konfiguracji do przeprowadzania zmian na danych, a kilka serwerów SLAVE do uruchamiania kwerend.


nano postgresql.conf


zmieniamy parametr hot_standby:


hot_standby = on



I restartujemy Postgresa:


service postgresql-9.4 restart



Testy działania


Oba serwery pierwotnie były kompletnie puste, dopiero po instalacji. Na obu serwerach sprawdzam tabele jakie są. Następnie na serwerze MASTER tworzę tabelę OMG, która po chwili bez żadnej ingerencji z mojej strony pojawia się również na serwerze SLAVE: