NAUKOWA I AKADEMICKA SIEĆ KOMPUTEROWA Środowisko klastrowe w portalu Polska.pl Agnieszka Kukałowicz-Kolaszyńska (qqlka), Starszy Specjalista IT.

Prezentacja na temat: "NAUKOWA I AKADEMICKA SIEĆ KOMPUTEROWA Środowisko klastrowe w portalu Polska.pl Agnieszka Kukałowicz-Kolaszyńska (qqlka), Starszy Specjalista IT."— Zapis prezentacji:

1

2 NAUKOWA I AKADEMICKA SIEĆ KOMPUTEROWA Środowisko klastrowe w portalu Polska.pl Agnieszka Kukałowicz-Kolaszyńska (qqlka), Starszy Specjalista IT

3 Kto to jest Qqlka? Źródło: Wikipedia.org

4 Kto to jest Qqlka? Politechnika Gdańska, Wydział ETI, Sieci Komputerowe 2000 - 2002:  Administrator portalu Panorama Firm: www.pf.plwww.pf.pl  Linux, serwery www, serwery plików, poczta, DNS, bazy danych, itp.. 2002 – obecnie:  Administrator portali Polska.pl i Poland.pl: www.polska.pl, www.poland.plwww.polska.plwww.poland.pl  Projekt „Rozbudowa infrastruktury portalu Polska.pl zapewniająca wysoką wydajność, dostępność i skalowalność”. Red Hat Certified Engineer (RHCE)

5 Portale Polska.pl i Poland.pl Charakter niekomercyjny Najważniejsze serwisy:  Dziedzictwo Narodowe – http://dziedzictwo.polska.plhttp://dziedzictwo.polska.pl  Zdjęcia – http://zdjecia.polska.plhttp://zdjecia.polska.pl  Wideo – http://wideo.polska.plhttp://wideo.polska.pl  Przyroda – http://przyroda.polska.plhttp://przyroda.polska.pl Specyfika portalu:  Zasoby polskich archiwów, bibliotek i muzeów  Skany dokumentów archiwalnych, starodruków, książek, itp.. (w oryginalnym rozmiarze - 600 DPI) Oglądalność portalu Polska.pl - maj 2009:  420 tysięcy unikalnych użytkowników  4,4 mln odsłon  2,52 % zasięgu

6  zwiększenie wydajności portalu Polska.pl  umożliwienie skalowania portalu Polska.pl  zapewnienie wysokiej dostępności (High Availability) portalu Polska.pl  zapewnienie dostępu do dużej ilości danych przechowywanych w sieci SAN  ułatwienie zarządzania środowiskiem portalu Polska.pl  zwiększenie bezpieczeństwa portalu Polska.pl Dlaczego portal Polska.pl potrzebował środowiska klastrowego?

7 Zwiększenie wydajności i skalowalności 1  Było:  jeden serwer aktywny  jeden serwer pasywny (w razie awarii przejmujący rolę serwera aktywnego)  Powinno być:

8 Zwiększenie wydajności i skalowalności 2 Problemy starej infrastruktury portalu Polska.pl:  Duże obciążenie maszyny fizycznej, na którym uruchomione są portale Polska.pl i Poland.pl  duże zużycie pamięci operacyjnej przez aplikacje  coraz większe zapotrzebowanie na przestrzeń dyskową  coraz większa złożoność bazy danych  aplikacje konkurują między sobą o przestrzeń dyskową, pamięć operacyjną, zasoby CPU  nie można „pozwolić” na nieoptymalne fragmenty kodu aplikacji, gdyż mogą powodować problemy ze stabilnością i wydajnością portalu Polska.pl  sprzęt jest kilkuletni, słaba moc procesora, niewielkie dyski, brak możliwości dodania pamięci RAM, karty sieciowe z interfejsami 100Mb/s  Brak możliwości rozbudowy serwerów  sprzęt, system oraz aplikacje mogły nie wytrzymać nagłego wzrostu oglądalności portali Polska.pl i Poland.pl (spowodowanego udostępnieniem mechanizmów Web 2.0)  Brak możliwości dodawania nowych usług

9 Zwiększenie wydajności i skalowalności 3 Zastosowanie prostych rozwiązań nie rozwiązałoby problemu skalowalności i wydajności infrastruktury:  odzielne nowe, wydajne maszyny fizyczne dla serwerów www, bazy danych, … wygenerują kolejne problemy:  co zrobić w razie awarii jednego z nich  jak sobie poradzić z nagłym wzrostem oglądalności, itp..  co zrobić, gdy trzeba uruchomić nową usługę, aplikację …?  Konieczne było systemowe rozwiązanie problemu wydajności i skalowania portalu Polska.pl, które pozwoliłoby na:  przydzielanie zasobów sprzętowych w zależności od potrzeb usługi  szybką reakcję w przypadku nagłych wzrostów oglądalności (zwiększanie zasobów, dodawanie nowych serwerów, itp.)  łatwe dodawanie nowych usług  łatwe „dostawianie” nowych maszyn fizycznych  łatwą konfigurację nowych maszyn (w zasadzie zautomatyzowaną)

10 Zapewnienie wysokiej dostępności Ograniczenia starej infrastruktury portalu Polska.pl:  w przypadku awarii maszyny podstawowej konieczność ręcznego uruchomienia środowiska portalu na maszynie zapasowej  Utrudnione prace administracyjne wymagające restartu maszyny fizycznej (aktualizacja kernela)  Utrudnione prace „konserwatorskie” – rozbudow Konieczne było systemowe rozwiązanie powyższych problemów, tak aby:  w awaria jednej maszyny nie powodowała widocznej przerwy w działaniu portalu Polska.pl  prace administracyjne/konserwatorskie nie wpływały na działanie portalu  awarie aplikacji (niektóre typy) były automatycznie naprawiane (bez ingerencji administratora)  brak było pojedynczego punku awarii SPOF  Maszyny fizyczne miały jak najwięcej elementów redundatnych (zasilacze, dyski, porty Ethernet, itp.)

11 Ułatwienie zarządzania środowiskiem Konieczne jest stworzenie środowiska, w którym:  w łatwy sposób będzie można aktualizować oprogramowanie  w prosty sposób będzie można mieć dostęp do najnowszych wersji oprogramowania  poważne zmiany w oprogramowaniu nie będą powodować niedostępności portalu Polska.pl  będzie można łatwo i w niewidoczny sposób dodać nowy sprzęt i oprogramowanie  będzie można w łatwy sposób dodawać nowe serwery (fizyczne, wirtualne)  proces instalacji i konfiguracji serwerów będzie w jak największym stopniu zautomatyzowany  zarządzanie infrastrukturą środowiska będzie możliwe za pomocą narzędzi www  będzie można szybko zwiększyć przestrzeń dyskową na potrzeby portalu

12 Zapewnienie bezpieczeństwa środowiska Ograniczenia starej infrastruktury portalu Polska.pl:  wszystkie aplikacje działają na jednym serwerze, konkurują między sobą o zasoby  problemy z jedną aplikacją mogą wpływać niepożądanie na działanie drugiej aplikacji  błąd „bezpieczeństwa” w jednej aplikacji może spowodować, że cały serwer będzie zagrożony Konieczne jest stworzenie środowiska, w którym:  w łatwy sposób będzie można aktualizować oprogramowanie pod kątem bezpieczeństwa  każda aplikacja będzie działać we własnym środowisku odseparowana od innych aplikacji  wykorzystanie zasobów (pamięci, czasu procesora) przez jedną aplikację nie wpłynie na pracę innej aplikacji  zmniejszenie ryzyka włamania do całej infrastruktury portalu (aplikacje www działają we własnych środowiskach)

13  Wirtualizacja systemów  Klastry wysokiej dostępności  Klastrowe systemy plików  Load Balancing  Pamięć masowa  Rozbudowa sprzętowa i programowa W jaki sposób zrealizowano cele budowy środowiska klastrowego

14 Oprogramowanie  Red Hat Enterprise Linux 5 Advanced Platform:  Wirtualizacja  Red Hat Cluster Suite  GFS  Red Hat Enterprise Linux 5 Server  Wirtualizacja (do 4 hostów)  Maksymalnie 2 CPU  Red Hat Cluster Suite

15 Red Hat Enterprise Linux Advanced Platform vs Red Hat Enterprise Linux Server: Oprogramowanie

16 W jaki sposób zrealizowano cele budowy środowiska klastrowego Sprzęt 2 serwery Fujitsu-Siemens Primergy RX 2 procesory 2GB RAM 2 porty Ethernet 1Gbit/s 5 serwery Dell PowerEdge II 2 procesory 4-rdzeniowe 16 GB RAM 4 porty Ethernet 1Gbit/s Karta HBA FC Qlogic 2 zasilacze 4 zarządzalne listwy zasilające PDU firmy APC 2 urządzenia „KVM over Net” firmy ATEN Infrastruktura sieci SAN macierz 3PAR

17 Dlaczego Red Hat ? Za:  wszystko w jednym:  system operacyjny,  oprogramowanie do wirtualizacji,  oprogramowanie klastrowe (HA, Load Balancing),  klastrowy system plików  Red Hat Network (narzędzie do zarządzania oprogramowaniem, powiadomienia o aktualizacjach, błędach, poprawkach)  Support  niewygórowana cena (??):  Red Hat Enterprise Linux 5 Advanced Platform Standard 3-Year Subscription – ok. 3057 EUR netto  Red Hat Enterprise Linux 5 Server Standard 3-Year Subscription – ok. 1629 EUR netto Przeciw: oprogramowanie komercyjne istnieją rozwiązania darmowe: Linux-HA LVS Xen, KVM OCFS2 (Oracle Clustered File System, Ver 2) duży koszt (ok. 15 000 brutto za licencję RHELAP) przyzwyczajenia admnistratorów („ nie lubimy oprogramowania komercyjnego” ) oprogramowanie komercyjne: nie pozwala na ingerencję w źródła kodu (kernela, aplikacji) nie można instalować ze źródeł (np. aktualizacja kernela ze źródeł)

18 Czy wiesz, że … „Kukułka z wyglądu przypomina nieco ptaka drapieżnego (krogulca). Wskutek tego małe ptaki na jej widok wypłaszają się z gniazd. Kukułka dostrzega to i może dzięki temu podrzucić do gniazda ofiary swoje jajko”. Źródło: http://mpancz.webpark.pl/ciekawbio8.php

19 Projektowanie 1 Rok 2005:  seminarium „Technologie klastrowe na platformie Linux” (Altkom) Rok 2006:  pierwsze „formalne” kroki w celu budowy nowej infrastruktury portalu Polska.pl (przedstawienie koncepcji Dyrekcji NASK)  sposób finansowania (szukanie dofinansowania w programach unijnych – Polska.pl projekt niekomercyjny)  w jaki sposób przetestować rozwiązania Red Hat?  stworzyć środowisko testowe (zakup 6 używanych, starych i tanich serwerów IBM)  pierwsze problemy:  jak przetestować konfigurację z macierzą dyskową ? Skąd wziąć macierz FC? (NASK w tym czasie pracował nad wdrożeniem sieci SAN w oparciu o protokół Fibre Channel). Nikt nie chce wypożyczyć takiej macierzy do testów.  Środowisko testowe w Gdańsku (cała infrastruktura NASK w Warszawie)  wdrożenie sieci SAN w NASK Rok 2007:  podłączenie środowiska testowego do sieci SAN w NASK  przetestowanie rozwiązań Red Hat (Red Hat Enterprise Linux Server 4)  opracowanie budżetu projektu i zatwierdzenie go przez dyrekcję NASK

20 Projektowanie 2 Rok 2008:  Zakup sprzętu i oprogramowania (problem – ustawa o zamówieniach publicznych)  Przejście na Red Hat Enterprise Linux 5  Modyfikacja projektu (wprowadzenie serwerów wirtualnych)  Wrzesień – listopad 2008: montaż sprzętu w serwerowni, instalacja, konfiguracja i podłączenie do infrastuktury NASK Rok 2009: dostosowanie aplikacji webowych do środowiska rozproszonego testy Uruchomienie portalu Polska.pl w nowej architekturze (07.04.2009)

21 Architektura – projekt logiczny

22 Architektura – projekt fizyczny Sprzęt rozmieszczony w dwóch szafach:  Każda szafa zawiera wszystkie niezbędne elementy do poprawnego działania klastra  Awaria wszystkich urządzeń w jednej szafie nie powinna powodować przerwy w funkcjonowaniu portalu Polska.pl Zasilanie serwerów:  Każdy serwer Dell podpięty do dwóch niezależnych źródeł zasilania  Zarządzanie zasilaniem odbywa się przez listwę APC PDU (niezbędną do działania klastra HA) Sieć Ethernet:  Każda szafa „podpięta” jest do innego przełącznika Ethernet  Wydzielona sieć do komunikacji Workerów w klastrze (każdy Worker połaczony z dwoma przęłącznikami Ethernet – Ethernet Channel Bonding)  3 sieci Ethernet – 1 publiczna, 2 prywatne (do komunikacji w klastrze, do komunikacji LB z Workerami) Sieć SAN:  Każdy Worker ma kartę HBA FC (dwuportową)  Multipathing - dwa niezależne światłowody łączące każdy Worker z dwoma przełącznikami, dwie ścieżki do tego samego zasobu macierzy

23 Architektura – podsumowanie Brak SPOF !!! (przynajmniej teoretycznie)

24 Konfiguracja środowiska – wirtualizacja, klaster maszyn wirtualnych 1 Wirtualizacja:  Wykorzystano Xen i parawirtualizację  Wszystkie VM znajdują się na wolumenach wyeksportowanych z sieci SAN  Wszystkie VM znajdują się na klastrowym systemie plików GFS (dzięki czemu możliwa jest migracja „na żywo” VM z jednej maszyny na drugą  Wszystkie Workery (Worker1, …, Worker5) „widzą” wszystkie obrazy VM  Każda aplikacja ma swój własny VM Klaster maszyn fizycznych (Worker1, …, Worker5):  Wszystkie VM są zarządzane za pomocą oprogramowania klastrowego (oznacza to, że operacje uruchamiania, wyłączania lub migracji na inny serwer rzeczywisty VM wykonywane są z poziomu oprogramowania klastrowego. VMs traktowane są jak normalne usługi w środowisku klastrowym)  Odgradzanie od zasobów realizowane za pomocą mechanizmu Power Fencing (do tego niezbędna jest listwa zarządzalna APC PDU)  Skonfigurowany mechanizm Quorum, po to, aby klaster mógł prawidłowo działać nawet wtedy, gdy tylko 1 węzeł jest dostępny  Bez Quorum klaster potrzebuje (n/2 + 1) węzłów do prawidłowego działania (w przypadku Polska.pl 3 węzły)

25 Konfiguracja środowiska – wirtualizacja, klaster maszyn wirtualnych 2 Power fencing Qourum

26 Konfiguracja środowiska – klastry usług Na maszynach wirtualnych uruchomione 2 oddzielne klastry:  klaster usług aktywny/aktywny (usługi www)  klaster usług aktywny/pasywny Klaster usług aktywny/aktywny  wszyskie usługi www na maszynach wirtualnych mają dostęp do danych aplikacji przechowywanych w zewnętrznej pamięci masowej (wyeksportowanych do VMs jako VBD)  dane przechowywane są w systemie plików GFS (GFS1) i widoczne przez wszystkie VMs  klaster skonfigurowany po to, aby móc korzystać z GFS  nietypowa konfiguracja klastra:  każda usługa www ma swoją własną domenę „failover”  W przypadku awarii usługi www nie jest ona uruchamiana w innym miejscu (jest wystarczająca liczba usług www tego samego typu), jest jedynie restartowana  możliwe zrezygnowanie z tego typu klastra (pewna nadmiarowość i skomplikowanie rozwiązania, „ale skoro został wykorzystany GFS to dlaczego nie skonfigurować reszty”)  Skonfigurowany mechanizm Quorum  Skonfigurowany mechanizm Virtual Fencing

27 Konfiguracja środowiska – klastry usług 2 Virtual Fencing Klaster uruchomiony w środowisku maszyn wirtualnych (VMs) także musi mieć skonfigurowany mechanizm odgradzania od zasobów w przypadku awarii węzła wirtualnego Nie może korzystać z mechanizmu Power Fencing (gdyż odcinałby od zasilania całą maszynę fizyczną, a nie tylko maszynę wirtualną) Rozwiązanie: Na maszynie fizycznej uruchomiony jest demon „fence_xvmd”, który czeka na żądanie fencingu od maszyny wirtualnej Na maszynie wirtualnej uruchomiony jest agent „fence_xvm”, który wysyła żądanie fencingu (multicast) do wszystkich maszyn fizycznych, razem z nazwą domeny, która ma być odcięta od zasobu Maszyna fizyczna za pomocą interfejsu „libvirt” niszczy i restartuje maszynę wirtualną  Maszyna fizyczna:

28 Konfiguracja środowiska – klastry usług 3 Virtual Fencing  Maszyna wirtualna:

29 Konfiguracja środowiska – klaster usług 4............

30 Konfiguracja środowiska – klastry usług 5 Klaster usług aktywny/pasywny  Niektórych usług/aplikacji nie można uruchomić w trybie aktywny/aktywny, muszą zostać uruchomione w trybie aktywny/pasywny  Typową usługą uruchamianą w modelu aktywny/pasywny jest baza danych, która MUSI być w ten sposób uruchamiana, chyba że ma własne mechanizmy klastrowania  Aplikacje mogą być uruchamiane w modelu aktywny/pasywny ze względu na licencję, ale mogą być z tym problemy:  Niektóre aplikacje nawet w modelu aktywny/pasywny potrzebują 2 licencji  Rezygnujemy z modelu aktywny/aktywny, gdy koszt licencji oprogramowania (przynajmniej 2) jest za duży dla budżetu projektu  Typowe usługi www można także uruchamiać w modelu aktywny/pasywny, kiedy wiemy, że system nie musi być „super” skalowalny  Działanie:  Każda usługa jest skonfigurowana na dwóch wirtualnych maszynach ( na jednej jako usługa aktywna, na drugiej jako usługa pasywna)  W przypadku awarii usługi jest ona restartowana na drugiej wirtualnej maszynie  W przypadku awarii wirtualnej maszyny na której uruchomiona jest aktywna usługa, jest ona restartowana na drugiej wirtualnej maszynie  Każda usługa ma swój własny adres IP (tzw. Floating IP), który jest uruchamiany (konfigurowany na VM) w trakcie startu usługi

31 Konfiguracja środowiska – klastry usług 6........

32 Czy wiesz, że … „ Jajo kukułki jest zbliżone wielkością do jaj gospodarzy. Ma rozmaite ubarwienie, tak że często (choć nie zawsze) są podobne do jaj gospodarza. Oczywiście samica kukułki nie może dowolnie zmieniać ubarwienia swych jaj, aby dostosować je do jaj gospodarza, lecz znosi je zawsze takie same, wyszukując gniazdo z odpowiednio ubarwionymi jajami. W ten sposób tworzą się jak gdyby odmiany kukułek, pasożytujące u różnych gatunków gospodarzy”. http://ptaki.ovh.org/kukulka.html

33 Problemy 1 Konfiguracja parametrów: multipath failover, qdisk failover, cman failover  Od października 2008 roku opisana w Red Hat Knowledgebase: http://kbase.redhat.com/faq/docs/DOC-2882 http://kbase.redhat.com/faq/docs/DOC-2882  Wcześniej brak „podpowiedzi”, konfiguracja metodą prób i błędów Problemy z konfiguracją kilku interfejsów sieciowych w środowisku ze skonfigurowaną wirtualizacją i klastrem VM:  Obecnie opisane w dokumentacji RH: http://www.redhat.com/docs/en- US/Red_Hat_Enterprise_Linux/5.4/html/Virtualization_Guide/chap-Virtualization- Pre_Red_Hat_Enterprise_Linux_5.4_Xen_networking.htmlhttp://www.redhat.com/docs/en- US/Red_Hat_Enterprise_Linux/5.4/html/Virtualization_Guide/chap-Virtualization- Pre_Red_Hat_Enterprise_Linux_5.4_Xen_networking.html  W wersji <= RH 5.2 błąd z konfiguracją bridge’ów przy uruchamianiu usługi cman.  Konieczna była zmiana skryptu startowego /etc/init.d/cman  https://bugzilla.redhat.com/show_bug.cgi?id=459145 https://bugzilla.redhat.com/show_bug.cgi?id=459145  Errata: http://rhn.redhat.com/errata/RHBA-2009-0189.html

34 Problemy 2 Problem z komunikacją w klastrze, gdy węzły podłączone są do przełączników Cisco Catalyst:  Problem opisany obecnie w RHKB: http://kbase.redhat.com/faq/docs/DOC-5933, niestety rozwiązanie nie mógło być wykorzystane w środowisku Polska.plhttp://kbase.redhat.com/faq/docs/DOC-5933  Rozwiązanie polega na włączeniu multicast routing dla danego vlana, tak aby przełącznik mógł pracować jako ruter IGMP (administratorzy sieciowi nie wyrazili zgody)  Pomógł Support, który zaproponował inne rozwiązanie (podanie parametru NETWORKDELAY) Qdisk timeout w klastrze uruchomionym w środowisku maszyn wirtualnych: Brak rozwiązania, nie znana przyczyna Można zastosować „workaround” Czy ktoś zna rozwiązanie ??

35 Problemy 3 Dużo błędów: W zasadzie ciągle trzeba sprawdzać RH Bugzilla Na szczęście wiele błędów jest opisanych i rozwiązanych w RH Bugzilla (nawet jeśli nie są włączone do aktualizacji) Niektóre błędy ciężkie do debugowania (pomimo opji włączenia debugowania w pliku konfiguracyjnych klastra) Kolejne wersje oprogramowania RH Cluster Suite, GFS, Xen poprawiają znane błędy, ale … zawierają nowe Aktualizowanie oprogramowania: Nigdy od razu po udostępnieniu nowej wersji (5.2->5.3) Warto poczekać i sprawdzić czy nowa wersja ma jakieś błędy !!! (monitorować RH Bugzilla) Najlepiej mieć środowisko testowe, gdzie można przetestować sobie taki upgrade oprogramowania (najlepiej przygotować sobie procedurę takiego upgrade’u) Update’y pojedynczych pakietów (zwłaszcza tych kluczowych) wykonywać jedynie po dokładnym zapoznaniu się z Erratą Dokumentacja (2006-2007 bardzo mało, obecnie coraz więcej)

36 Dokumentacja 1 Dokumentacja:  Coraz lepsza i coraz dokładniejsza  2009 - „Using Device-Mapper Multipath” http://www.redhat.com/docs/en- US/Red_Hat_Enterprise_Linux/5.4/html/DM_Multipath/index.htmlhttp://www.redhat.com/docs/en- US/Red_Hat_Enterprise_Linux/5.4/html/DM_Multipath/index.html  2009 - „Configuring Fence Devices in Red Hat Cluster” http://www.redhat.com/docs/en- US/Red_Hat_Enterprise_Linux/5/html/Configuration_Example_- _Fence_Devices/index.html http://www.redhat.com/docs/en- US/Red_Hat_Enterprise_Linux/5/html/Configuration_Example_- _Fence_Devices/index.html  Poprawiony i uszczegółowiony „Virtualization Guide” http://www.redhat.com/docs/en- US/Red_Hat_Enterprise_Linux/5.4/html/Virtualization_Guide/index.html http://www.redhat.com/docs/en- US/Red_Hat_Enterprise_Linux/5.4/html/Virtualization_Guide/index.html  Wcześniej – bardzo ogólnie (zwłaszcza lata 2006-2007) Przykłady konfiguracji, Case Studies (też coraz więcej):  „NFS over GFS” - http://www.redhat.com/docs/en- US/Red_Hat_Enterprise_Linux/5/html/Configuration_Example_- _NFS_Over_GFS/index.htmlhttp://www.redhat.com/docs/en- US/Red_Hat_Enterprise_Linux/5/html/Configuration_Example_- _NFS_Over_GFS/index.html  Red Hat Reference Architecture Series: http://www.redhat.com/rhel/resource_center/reference_architecture.htm l http://www.redhat.com/rhel/resource_center/reference_architecture.htm l

37 Dokumentacja 2 Webinars:  http://www.redhat.com/webinars/ http://www.redhat.com/webinars/ Videos: http://www.redhat.com/videos/  http://www.redhat.com/videos/solutions/all.html http://www.redhat.com/videos/solutions/all.html  http://www.redhat.com/videos/demos/all.html http://www.redhat.com/videos/demos/all.html  Red Hat Bugzilla:  https://bugzilla.redhat.com/ https://bugzilla.redhat.com/  Red Hat Knowledgebase:  http://kbase.redhat.com/faq/en http://kbase.redhat.com/faq/en  Red Hat Cluster Wiki :  http://sources.redhat.com/cluster/wiki http://sources.redhat.com/cluster/wiki

38 Plany Co dalej ???  Aktualizacja do RH 5.4  Migracja z GFS1 do GFS2  Rekonfiguracja klastra  przeanalizowanie co można zrobić lepiej, inaczej…  zmiana sposobu montowania wolumenów GFS w przypadku klastrów działających w środowisku wirtualnym (montowanie przy starcie systemu, zamiast montowanie przy uruchamianiu usługi za pomocą Rgmanager)  dopracowanie konfiguracji Quorum (wykorzystanie tzw. quorum heuristics)  Migracja Xen ->KVM ??  Klaster rozproszony geograficznie  infrastruktura NASK umożliwia budowę klastra w dwóch różnych lokalizacjach  redundancja sprzętu (każda szafa może pracować samodzielnie)

39 Gdybyśmy jeszcze raz wdrażali klastry, to …. „Niewiedza otwiera nam ścieżki do poszukiwań.... wiedza i pewność je zamyka w pewnym sensie....” Susan Jeffers

40 Gdybyśmy jeszcze raz wdrażali klastry, to …. … nie podjęłabym się tego zadania. … spróbowałabym przetestować inne rozwiązania komercyjne. ale …. najprawdopodobniej ponownie wybrałabym Red Hat (skoro oprogramowanie komercyjne jest wyzwaniem, to Open Source także) ale …. zrobiłabym to w innej kolejności: szkolenie (RH436 Red Hat Enterprise Clustering and Storage Management) ewentualne wsparcie firmy zewnętrznej zajmującej się wdrożeniami RH Cluster Suite, GFS projekt, wdrożenie, uruchomienie

41 Kontakt Jak się ze mną skontaktować ? e-mail firmowy: agnieszka.kukalowicz@nask.plagnieszka.kukalowicz@nask.pl e-mail prywatny: agnieszka.kukalowicz@gmail.comagnieszka.kukalowicz@gmail.com Blog: http://klastryredhat.wordpress.com/http://klastryredhat.wordpress.com/

42 Pytania Pytania ?

43 I na koniec … Pisklę kukułki karmione przez dorosłego rudzika Rys. Tomasz Cofta (materiały programu „Ptaki”)

44