[+] Czy dobrze rozumiem zasadę działania klastra HA?

Cześć!

Postawiłem sobie na vm’kach 3 Windows Servery 2008 R2 (wersja ewaluacyjna). Jedna z nich robi za kontrolera domen i udostępnia dysk za pomocą Microsoft ISCSI Target Software, pozostałe dwie to 2 węzły pracujące jako klaster failover. Wszystko działa poprawnie, postawiłem sobie prosty serwerek gry dla testów i jest ok. Ale! Mam kilka wątpliwości.

  1. Jeżeli jeden z węzłów pada, wówczas rolę przejmuje drugi. W tej sytuacji, jeśli chciałbym postawić serwer www, wówczas musiałbym poprawnie skonfigurować trasowanie sieci, ponieważ lokalnie węzły dostają różne IP. Czy dobrze to rozumiem?

  2. Do działania klastra potrzebny jest dysk dodany w menedżerze klastra z poziomu “sieciowego”. Do czego on służy, jeżeli nie jest widoczny do wykorzystania? Wydawało mi się, że służy jako jeden wspólny dysk.

  3. Każdy węzeł musi być klonem poprzedniego. Mimo to, zmiany wprowadzone w systemie węzła 1 nie są wprowadzane z automatu (przynajmniej domyślnie) w systemie węzła 2 takie jak np konfiguracja usługi mającej pracować w trybie failover (w sensie dodanie jej jako np usługi systemowej). Czy to poprawna reakcja systemów? Jak można w takiej sytuacji wprowadzać zmiany z automatu na kilu węzłach jednocześnie?

  1. W klastrach jest coś takiego jak floating IP, dodatkowe IP na karcie sieciowej lub masz jakiś frontend z IP, a hosty są backendem i to frontend trasuje ruch, np. HAProxy. Może to być domena jak np. w przypadku DFS.
  2. Storage może być współdzieleny (ta sam pula dyskowa podpięta pod kilka hostow z systemem plików wielodostepu, np. sieciowy system plików NFS lub rozproszony system plików DFS, GFS itp., a może być rozproszony (każdy ma swoj dysk, ktory synchronizuje się w tle) tu wymagany jest rozproszony system plików.
  3. Tu synchronizuje się tylko stan uslugi i pliki, zmiany w systemie trzeba ogarnąć innym mechnizmem automatyzacji, np. Ansible, puppet, ewentualnie GPO jeśli potrafi.
1 polubienie
  1. Czyli poza dyskiem dodanym z poziomu menedżera klastra musi być coś dodatkowego??

  2. Jakie dokładnie pliki się synchronizują?? Gdzie mogę szukać informacji na ten temat??

  1. Przeczytaj jeszcze raz.
  2. Pliki, bazy itp.
1 polubienie

Już wszystko rozumiem, dziękuję bardzo za wyjaśnienie.

PS. Postawiłem sobie serwer gry na klastrze. Wszystko działa poprawnie. Nie wiem tylko, co mogę wykorzystać do “pływających” IP, żeby współgrało z wbudowanym menedżerem failover’a w windows serverze 2008 R2. Czy ktoś mógłby rzucić mi hasło? Szukałem, nie mogłem znaleźć odpowiedniego rozwiązania.

Nie wiem czy w Windows jest taki mechanizm, ale jest jeszcze DNS. Podajesz 2 IP, a DNS rozwiązuje nazwę, jak nie piersze IP, to na drugie.

1 polubienie

Pod warunkiem oczywiście, że ktoś ma wystawioną usługę po nazwie domeny. Wtedy, rzeczywiście, DNS pomoże. Chyba że proxy, wówczas może ruszy z kopyta. Tyle, że skąd proxy / DNS ma wiedzieć, na którym węźle jest aktywna usługa? Będę jeszcze kombinował, ale dziękuję za pomoc.

Fajnie, jakby sama aplikacja też miała mechanizm HA. Jak nie ma, to stosuje się kolejne możliwości:

  • HA samej VM (w przypadku uszkodzenia np. jednego z hypervizorów w klastrze wirtualizacji czas potrzebny na uruchomienie VM na nowym nodzie; wady to właśnie ten czas potrzebny na uruchomienie aplikacji/samej VM )
  • FT (brak przerwy w działaniu, ale kosztowniejszy mechanizm i dość rzadko stosowany).
2 polubienia

DNS nie można mieć w LANie?

1 polubienie

@roobal
A można, zgadza się. Nie zaprzeczam.
@bachus
Dzięki! O FT nigdy nie słyszałem, muszę sprawdzić.


Problem z adresacją IP został rozwiązany. Jak się okazało, a czego ja jakimś cudem nie zauważyłem lub całkowicie przeinaczyłem, menedżer klastra ma możliwość przypisania adresu IP do każdej z usług podpiętych pod klaster. Przy awarii jednej nich poszczególne adresy dostają następne węzły w klastrze z automatu. Z początku i to nie rozwiązało problemu ponieważ, jak się później okazało, usługa w postaci serwera jakiejś tam prostej gierki miała problem z adresacją i przyjmowała (nasłuchiwała) na pierwszym z brzegu adresu (jaki dostawał węzeł). Dopiero po zastosowaniu odpowiedniego przełącznika z potrzebnym adresem IP serwerek zaczął nasłuchiwać tam, gdzie powinien. I od tego momentu wszystko zaczęło chodzić jak powinno, tak jak chciałem, na jednym adresie IP.