Glassfish Enterprise: 5 9's z HADB

Wprowadzenie. Kilka słów o GlassFish’u,

Serwer aplikacyjny dostępny od Sun Microsystems pierwotnie miał swe początki jako alians iPlanet (kooperacja inżynierów Sun Microsystems z NetScape). Po okresie wspólnej pracy z NetScape, Sun projekt iPlanet rozwijał pod swoimi skrzydłami już pod nazwą SunONE, Sun Open Net Environment. Nazwa ta została wprowadzona w 2002 roku i była przewidziana na grupę produktów, które powstały w wyniku aliansu. SunONE z kolei przekształcił się w linię produktów odpowiedzialnych za warstwę webową (serwer webowy, aplikacyjny, portal etc.) obecnych w ofercie pod nazwami Sun Java System. Debiut SJS nastąpił podczas konferencji SunNetwork we wrześniu 2003 roku. W ramach SJS powstał Sun Java System Application Server, który obecnie jest starą nazwą na wspierany serwer aplikacyjny oferowany od Sun Microsystems. Sun Java System Application Server v9.1 to ostatnia wersja z działu aplikacyjnych serwerów z nazwą SJSAS a jego odpowiednikiem (bit w bit identyczna implementacja, jedynie różny instalator i kilka graficznych plików) jest Sun GlassFish Enterprise Application Server v2.1.

Dziś GlassFish Enterprise jest aktualną nazwą dla tego serwera (wprowadzona w kwietniu 2008 roku). Glass w nazwie oznacza przejrzystość kodu, gdyż pierwotnie serwer aplikacyjny był OpenSource, ale z uwagi na jej popularność Sun postanowił oferować ten produkt w wersji Enterprise. W wersji 2.x (obecnie najnowsza 2.1.1) Sun GlassFish Enterprise Application Server jest serwerem aplikacyjnym, będącym implementacją specyfikacji JSR 244 rozwijanej w ramach JCP, szerzej znanej pod nazwą Java Enterprise Edition 5 lub w skrócie JEE5. Co oznacza, że tak jak RedHat JBoss, IBM WebSphere czy Oracle Weblogic, GlassFish jest jednym z kontenerów, służących jako środowisko do hostowania aplikacji/usług utworzonych przede wszystkim (choć nie tylko) w technologii JEE. Jest nie tylko jednym z serwerów, ale obecnie serwerem o najniższych kosztach wsparcia 7x24x365 (stałe, niezależne od ilości CPU, rdzeni, socket’ów), serwerze o dostępność na poziomie 5 9’s (realizowana przez HADB), serwerem o najwyższej wydajności (aktualne dane niezależnego konsorcjum SPEC), serwerem o największej ilości pobrań (ponad 4 mln) oraz przede wszystkim serwerem będącym od wielu lat platformą referencyjną (pierwszy certyfikowany, w pełni zgodny ze specyfikacją serwer aplikacyjny JEE5, oraz JEE6 w wersji v3).

Te i inne fakty sprawiają, że coraz częściej GlassFish używany jest w środowiskach produkcyjnych. Wraz z HADB, zapewnia bardzo wysoki poziom dostępności usług na poziomie 5 9’s. Oznacza to dostępność na poziomie 99.999%, a innymi słowy maksymalny dozwolony downtime naszych usług na poziomie 5 minut w ciągu roku. 5 9’s jest standardem dla usług telekomunikacyjnych i wszędzie tam, gdzie tolerancja utraty sesji jest bardzo niska. A oprócz samej sesji, HADB pozwala na stałość usługi JMS, usługi do asynchronicznego przesyłania wiadomości.

O artykule

Poniższy artykuł omawia w teorii technologię HADB jak również krok po kroku pokazuje budowę w oparciu o zwirtualizowane środowisko VMware. Wymagana jest jedynie podstawowa wiedza na temat środowisk Unix’owych, aby móc swobodnie się w nim poruszać. Wszystkie czynności przeprowadzane podczas tego artykuł są niezmiernie szczegółowe, aby każdy mógł bez problemu poradzić ze wszystkimi etapami.

Przygotowania do pracy

Aby móc przeprowadzić ćwiczenia wymagane jest pobranie ze stron Sun Microsystems obrazu Solaris'a 10 z utworzonymi zonami. Obraz ten posiada 12 skonfigurowanych zon – 12 zwirtualizowanych Solaris'ów z których 4 będą pełnić w naszym środowisku rolę instancji GlassFish'a będących w jednym klastrze. Link do obrazu poniżej (login: „root”, hasło: „cangetin”).

Po co, dlaczego ? Czym jest HADB ?

GlassFish w swojej ofercie posiada dwa mechanizmy do przetrzymywania sesji. In-memory replication jako szybkość i opensource, oraz HADB, stabilność na wysoką skalę, wsparcie oraz replikacja JMS. Oba mechanizmy dają podstawową funkcjonalność – replikację sesji. Do przetrzymywania samej sesji in-memory replication ma przewagę wydajności (RAM) i jest lepszym rozwiązaniem na małą skalę. Jeśli jednak ilość naszych sesji przekracza (zależne od środowiska, aplikacji, zasobów i innych współczynników) 100000 aktywnych sesji, mechanizm HADB staje się niezastąpiony w przypadku tak dużego obciążenia.

HADB, High Availiability Database jest to mechanizm rozproszonej bazy danych, której repozytoria są przechowywane w plikach na każdym z nodów. Baza HADB służy jako repozytorium sesji i wiadomości JMS, i przewidziana jest do dużych systemów, w których tolerancja utraty sesji oraz wysoka dostępność mają spełnić standardy 5 9’s.

GlassFish a GlassFish Enterprise oraz historia wersji.

Serwer GlassFish jest dostępny w dwóch wersjach – OpenSource (https://glassfish.dev.java.net/) oraz Enterprise (http://www.sun.com/software/products/appsrvr/index.jsp). Mowa tu o GlassFish Application Server oraz GlassFish Enterprise Application Server. Obydwie wersie posiadają podobną implementację z tą różnicą, że Enterprise posiada oficjalny suport od strony Sun Microsystems, moduły do HADB oraz zestaw trzech, dodatkowych, płatnych narzędzi dostępnych w pakiecie Enterprise Manager – Performance Advisor, Performance Monitor oraz SNMP Monitor. Z uwagi na HADB będziemy pracować z wersją Enteprise.

Rozwój każdej z edycji podzielony jest na 3 fazy:

• Concept Creation – zbieranie kluczowych wymogów, określanie ram czasowych, prototypowanie.
• Active Development – implementacja w kierunku Milestone aż do wersji finalnej.
• Maintenance – poprawki finalnej edycji, wydania produktu z poprawkami.

Pierwszy GlassFish v1 miał swoja premierę w maju 2006 roku i jego odpowiednikiem w ofercie Sun’a był Sun Java System Application Server 9.0 PE. Był on implementacją specyfikacji JEE5, jednak z kilkoma brakami jak możliwość klastrowania. GlassFish v2 miał premierę we wrześniu 2007 roku wraz z wersją wspieraną przez Sun’a o nazwie Sun Java System Application Server 9.1. Te wersje wspierały już klaster, load balancing, jak również replikację sesji przez pamieć. Wersia SJSAS 9.1 wspierała HADB, która od kwietna 2008 roku zmieniła nazwę na GlassFish Enterprise v2.1. W grudniu 2009 otrzymała update do wersji v2.1.1 prezentujący drobne poprawki w produkcie.

Wersja v3 GlassFish’a dostępna od grudnia 2009 roku jest pierwszą w pełni zgodną implementacją serwera aplikacyjnego z JEE6. GlassFish v3 jest serwerem modułowym (bazując na OSGI, implementacja Apache Felix) w którym moduły instaluje się łącząc się przez telnet do DAS’a na port 6666. GlassFish v3 jest dostępny w dwóch profilach: WEB – Servlets, JSP, JavaBeans, POJO, oraz Full – Servlets, JSP, JavaBeans, POJO, EJB.

Suszona rybka. Wpierw trochę teorii.

W architekturze serwera aplikacyjnego GlassFish występuje kilka pojęć, które warto przypomnieć zanim zaczniemy pracę, abyśmy zrozumieli podstawowe słownictwo występujące podczas instalacji oraz konfiguracji naszego środowiska.

Poniżej mamy graficzną prezentację przykładowego środowiska, na którym będziemy pracować. W celu wyjaśnienia wszystkich elementów wchodzących w jego skład, kolejno opiszemy każdy z nich.

Rysunek 1. Przykładowa architektura. 1 domena, 1 DAS, 1 klaster, 4 agenty, 4 instancje. Całość działa na systemie Solaris.

Domain Administration Server (DAS) - jest to centralny serwer w architekturze GlassFish’a. DAS to instancja administracyjna o nazwie server, odpowiadająca za centralny monitoring, logowanie, wdrażania aplikacji, konfiguracje zasobów dla klastrów i instancji, utworzonych w obrębie domeny. DAS jest miejscem, gdzie administrujemy domeną.

Uwaga: Zalecany rozmiar heap dla tego procesu to 512MB.

Domena - z kolei jest to zbiór instancji, klastrów wchodzących w jej skład mających wspólną konfigurację i udostępnione zasoby w jej obrębie. Każda domena ma swego DAS’a (na którym trzymane jest centralne repozytorium aplikacji) oraz profil domeny, który określa jej możliwości. Jest on ustalany podczas jej tworzenia. Dostępne są trzy przedefiniowane profile: Developer, Cluster, Enterprise. Ostatni jako jedyny dostępny jest w wersji komercyjnej (GlassFish Enterprise) i jako jedyny ma wsparcie do HADB. Konfiguracja domeny jest całościowo przeprowadzana na DAS’ie i przechowywana w pliku domain.xml również na DAS’ie.

Klaster - jest to nazwany zbiór homogenicznych instancji. Homogeniczność określana jest jedynie po wersji aplikacyjnego serwera. Każdy klaster istniejący w domenie (może być ich kilka) musi mieć unikatową nazwę. Jest tak ponieważ każdy klaster swą konfigurację przechowuje w katalogu, który ma nazwę określoną przez nazwę klastra. Każdy klaster należy zawsze i tylko do jednej domeny.

Instacja - klastrowa (clustered instance) bądź nie (stand-alone instance) jest to działający proces GlassFish’a. Proces JVM hostujący aplikacje (będące kopią aplikacji z centralnego repozytorium w DAS). Na jednej instalacji GlassFish’a może działać kilka jego instancji, każda nasłuchująca na innych portach HTTP, HTTPS, JMX, oraz IIOP.

Raz stworzona instancja stand-alone nie może być później dodana do klastra.

Uwaga: Zalecany rozmiar heap dla pojedynczego procesu instancji to 512MB.

Instancje podobnie jak klastry, muszą mieć unikatową nazwę w obrębie domeny i należą zawsze i tylko do jednej domeny. Jest tak z uwagi na ich konfigurację, przechowywaną w odrębnych katalogach. Jakakolwiek komunikacja z instancją następuje poprzez agenta.

Node Agent - jest to lekki proces uruchamiany ręcznie, lub skonfigurowany jako usługa w systemie operacyjnym (Windows 2000 - Service Contol, Windows XP i wyżej gotowy skrypt ma.cfg, Solaris do wersji 9 – init.d, Solaris 10 – usługa Service Management Facility), który odpowiada za komunikację oraz synchronizację instancji wchodzących w skład domeny z DAS’em (synchronizacje lokalnych repozytoriów z centralnym). Proces ten jest wymagany, aby móc zainstalować instancję. Jedyna instancja, która nie wymaga agenta to DAS.

Instalacja agenta jest jedyną czynnością jaką trzeba przeprowadzić na nowej maszynie w celu dodania jej do domeny GlassFish’a. Po jego instalacji dodawanie/instalacja instancji na nowej maszynie przeprowadzane jest zdalnie z DAS’a.

Proces agenta jest aktywny jedynie podczas cyklu życia instancji obsługiwanych przez niego (tworzenie, uruchamiania, usuwanie instancji, etc.).

Uwaga: Zalecany rozmiar heap dla procesu agenta to 256MB.

Tyle teorii czas przejść do praktyki.

Główno dowodzący ławicy. Instalacja DAS.

Budowę naszej architektury zaczniemy od instalacji DAS’a w tym celu pobierzemy instalatora. Aby móc korzystać z mechanizmu HADB musimy pobrać instalator GlassFish v2.x Enterprise (wersja OpenSource nie posiada wsparcia do HADB) w wersji z modułami do bazy wysokiej dostępności HADB (dopisek with HADB). Jest to oddzielna instalacja dostępna na stronach Sun Microsystems pod nazwą: Sun GlassFish Enterprise Server v2.1.1 with HADB. Jest do pobrania pod adresem podanym poniżej (stan na luty 2010):

http://www.sun.com/software/products/appsrvr/get_it.jsp

GlassFish v2.1.1 dostępny jest w wersjach językowych: English (sges_ee-2_1_1-solaris-i586.bin) oraz Multi Language (sges_ee-2_1_1-solaris-i586-ml.bin) z dopiskiem ml w nazwie. Obydwie wersje są odpowiednie do naszych ćwiczeń.

Po pobraniu instalatora przeprowadźmy instalacje naszej domeny, a mówiąc konkretnie instancję DAS’a. Wpierw uruchamiamy i logujemy się do zony, w której będziemy instalować DAS’a. W naszym przypadku to zona o nazwie zone01.

Uruchamiamy zonę zone01:

    global # zoneadm –z zone01 boot

Logujemy:

    global # zlogin zone01
    [Connected to zone 'zone01' pts/14]
    Last login: Thu Feb 11 07:36:54 on pts/4
    Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
    zone01 #

Po zalogowaniu do zony i po wgraniu naszego instalatora musimy dać na nim uprawniania. Do tego użyjemy narzędzia chmod dając stosowane uprawnienia na pliku. Po dodaniu uprawnień z uwagi, że pracujemy w zonach instalator graficzny nie zostałby wyświetlony (wymaga to ustawienie zmiennej DISPLAY) instalujemy z przełącznikiem -console.

    zone01 # cd glassfish/
    zone01 # cd sges_v2.1.1_with_hadb/
    zone01 # chmod 744 ./sges_ee-2_1_1-solaris-i586-ml.bin
    zone01 # ./sges_ee-2_1_1-solaris-i586-ml.bin - console

Po uruchomieni instalatora w trybie CLI....

    zone01 # ./sges_ee-2_1_1-solaris-i586-ml.bin -console
    Checking available disk space...
    Checking Java(TM) 2 Runtime Environment...
    Extracting Java(TM) 2 Runtime Environment files...

po krótkiej chwili uruchomi się instalator...

    Launching Java(TM) 2 Runtime Environment...
    Java Accessibility Bridge for GNOME loaded.

    You are running the installation program for Sun GlassFish Enterprise Server
    with HADB. This program asks you to supply configuration preference settings
    that it uses to install the server.

    The installation program consists of one or more selections that provide you
    with information and let you enter preferences that determine how Sun GlassFish
    Enterprise Server with HADB is installed and configured.

    When you are presented with the following question, the installation process
    pauses to allow you to read the information that has been presented. When you
    are ready, press Enter to continue.

     <Press ENTER to Continue>
    Some questions require more detailed information that you are required to type.
    The question may have a default value that is displayed inside of brackets [].
    For example, the following question has a default answer of yes:

    Are you sure? [yes]

    If you want to accept the default answer, press only the Enter key (which on
    some keyboards is labeled Return).

    If you want to provide a different answer, type it at the command prompt and
    then press Enter.

     <Press ENTER to Continue>

Enter.

    Welcome to the Sun GlassFish Enterprise Server with HADB Installation Program

    <Press ENTER to Continue>

Enter.

    Before you install this product, you must read and accept the entire
    Software License Agreement under which this product is licensed for your use.
    <Press ENTER to display the Software License Agreement>

Enter. Zostanie wyświetlona na licencja produktu.

    ...
    If you have read and accept all the terms of the entire Software License
    Agreement, answer 'yes', and the installation will continue.

    If you do not accept all the terms of the Software License Agreement, answer
    'no', and the installation program will end without installing the product.

    Have you read, and do you accept, all of the terms of the preceding Software
    License Agreement [no] {"<" goes back, "!" exits}?

Wpisujemy yes. Enter. Akceptujemy licencję. Po akceptacji licencji zaczyna się parametryzacja instalacji. Instalator poprosi o podanie miejsca instalacji.

    The Sun GlassFish Enterprise Server with HADB components will be installed in
    the following directory, which is referred to as the "Installation Directory".
    To use this directory, press only the Enter key. To use a different directory,
    type in the full path of the directory to use followed by pressing the Enter
    key.

    Installation Directory [/opt/SUNWappserver] {"<" goes back, "!" exits}:

Prośba o podanie katalogu instalacji. Wybierzmy domyślny klikając Enter, czyli w przypadku dystrybucji na Solaris’a /opt/SUNWappserver/. Instalując kilka Instalacji (nie instancji) robimy to podając inne katalogi, natomiast instancje są instalowane w obrębie konkretnej instalacji. Co za tym idzie na jednej fizycznie maszynie może być kilka instalacji, każda innej wersji GlassFish’a, pracująca na tej samej lub innej wersji JDK, a w ramach tych instalacji kilka instancji klastrowanych lub nie, podpiętych pod różne domeny.

Nasz domyślny katalog nie jest jeszcze stworzony w systemie więc instalator zapyta nas o to czy chcemy zmienić miejsce docelowe instalacji, czy utworzyć nieistniejący folder. Klikamy Enter co spowoduje stworzenie tego katalogu.

    The directory "/opt/SUNWappserver" does not exist.
    Do you want to create it now or choose another directory?

    1. Create Directory
    2. Choose New

    Enter the number corresponding to your choice  [1] {"<" goes back, "!"   exits}

Następnie kolejno będziemy pytani o instalację elementów GlassFisha.

    Please choose components.
    Do you want to install Node Agent [yes] {"<" goes back, "!" exits}?

Enter. Instalacja agenta w tym przypadku jest na przyszłość. Gdybyśmy chcieli, aby na maszynie, na której działa DAS również działały inne instancje (klastrowane lub nie) wtedy wymagany byłby agent.

Z uwagi, że nasze środowisko jest oparte o zony i każda instancja wchodząca w skład klastra działa w obrębie innej zony, a maszyna na której działa DAS nie posiada innych instancji, agent jest całkowicie opcjonalny.

Jednak zalecam jego instalację ponieważ po nazwie jaką on otrzyma od instalatora możemy sprawdzić, czy mamy poprawnie skonfigurowany plik /etc/hosts z wpisem FQDN. Instalator pobiera z pliku hosts FQDN dla nazwy agenta. Jeśli po instalacji serwera nazwa agenta odpowiada FQDN naszej maszyny oznacza to, że środowisko na którym pracuje GlassFish (Solaris) jest poprawnie skonfigurowane.

    Do you want to install High Availability Database Server
    [no] {"<" goes   back, "!" exits}?

Wpisujemy yes Enter.

    Do you want to install Load Balancing Plugin [no] {"<" goes back, "!" exits}?

Enter. Na tym etapie nie będziemy przeprowadzać Load Balancing.

    Do you want to install Domain Administration Server [yes]
    {"<" goes back, "!" exits}?

Tak chcemy zainstalować DAS. Enter.

    Do you want to install Sample Applications [yes] {"<" goes back, "!" exits}?

Opcjonalne. Enter. Po tej operacji instalator zapyta o JDK.

    The Sun GlassFish Enterprise Server requires a Java 2 SDK.
    Please provide the path to a Java 2 SDK 5.0 or greater.

    1. Install Java 2 SDK (6.0)
    2. Reuse existing Java 2 SDK
    3. Exit

    What would you like to do  [1] {"<" goes back, "!" exits}?

Wskażmy zainstalowane JDK z systemu. Wybieramy opcję 2. Enter.

    What would you like to do  [1] {"<" goes back, "!" exits}? 2

    Please enter the path to an existing, compatible Java 2 SDK Version 1.5.0 or
    above [/usr/jdk/instances/jdk1.5.0] {"<" goes back, "!" exits}

Instalator bazując na zmiennej JAVA_HOME pobierze ścieżkę do JDK z systemu.

    Supply the admin user's password and override any of the other initial
    configuration settings as necessary.

    Admin User [admin] {"<" goes back, "!" exits}:

Nazwa dla administratora GlassFish’a. Trzymajmy się prostoty, nazwijmy go admin. Klikając enter przyjmujemy domyślną nazwę.

    Admin User's Password (8 chars minimum):

Hasło dla administratora: adminadmin.

    Re-enter Password:

Powtórzenie Hasła dla administratora: adminadmin.

    Master Password will be used as SSL certificate database password.
    Master Password (8 chars minimum):

Master password. Hasło do bazy certyfikatów SSL GlashFisha. adminadmin.

    Re-enter Master Password:

Powtórzenie Hasła Master: adminadmin.

Następnie podajemy porty na których będzie pracować nasz DAS. Wszystkie wybieramy domyślnie.

    Admin Port [4848] {"<" goes back, "!" exits}:

Port, na którym będziemy łączyć się do konsoli administracyjnej, webowej o nazwie Admin Console. Dla domeny enterprises łączymy się przez HTTPS.

    HTTP Port [8080] {"<" goes back, "!" exits}:

Port HTTP. Enter.

    HTTPS Port [8181] {"<" goes back, "!" exits}:

Port HTTPS. Enter.

    Please choose installation options.
    Do you want to enable Updatecenter client [yes] {"<" goes back, "!" exits}?

Pytanie o instalacje UpdateCenter – aplikacji stand-alone (w wersji GlassFish’a v3 już zintegrowanej z Admin Console), służącej do aktualizacji zainstalowanych pluginów. Enter.

    Do you want to upgrade from previous Application Server version [no]
    {"<"goes back, "!" exits}?

Nie przeprowadzamy upgrade’u. Enter.

    Checking disk space...

    The following items for the product Sun GlassFish Enterprise Server with HADB
    will be installed:

    Product: Sun GlassFish Enterprise Server with HADB
    Location: /opt/SUNWappserver
    Space Required: 500.20 MB
    --------------------------------------------------
    Java 2 SDK, Standard Edition 6.0
    Uninstall
    Sun Java System Message Queue 4.4
    Application Server
    Sample Applications
    High Availability Database Server
    High Availability Database Administration Client
    Startup

    Ready to Install

    1. Install Now
    2. Start Over
    3. Exit Installation

    What would you like to do [1] {"<" goes back, "!" exits}?

Podsumowanie przed instalacją. Enter. Rozpoczynamy instalację.

    Installing Sun GlassFish Enterprise Server with HADB
    |-1%--------------25%-----------------50%-----------------75%--------------100%|
    Installation Successful.
    Next Steps:

        1. Access the About Application Server 2.1 welcome page at:
           file:///opt/SUNWappserver/docs/about.html

        2. Start the Application Server by executing:
           /opt/SUNWappserver/bin/asadmin start-domain --user admin domain1

        3. Start the Admin Console:
           https://localhost:4848

        4. Access sample applications:
           http://localhost:8080/samples/index.html

    Please press Enter/Return key to exit the installation program. {"!" exits}

Na koniec zostaniemy poinformowani podsumowaniem instalacji.

Uruchamianie Domain Administration Server.

W tej chwili mamy zainstalowanego DAS’a oraz domenę domain1 (instalowaną zawsze przy instalacji DAS’a) o profilu enteprise (z uwagi na wersję instalatora GlassFish Enterprise) wraz z modułami do HADB. Całość jest obecna w zonie zone01. Czas aby uruchomić DAS’a. W tym celu:

    zone01 # cd /opt/SUNWappserver/bin/
    zone01 # ./asadmin start-domain domain1

Narzędzie asadmin jest to narzędzie służące do administracji GlassFish’em. Narzędzie CLI, w którym przeprowadzamy całkowitą konfigurację naszej domeny. Parametr start-domain uruchamia domenę, DAS’a, czyli mówiąc konkretnie instancję administracyjną server.

Zostaniemy poproszeni o podanie hasła Maser. W naszym przypadku to adminadmin.

    Domain domain1 started.
    Domain [domain1] is running [Sun GlassFish Enterprise Server v2.1.1
    ((v2.1 Patch06)(9.1_02 Patch12)) (build b31g-fcs)] with its configuration
    and logs at: [/opt/SUNWappserver/domains].
    Admin Console is available at [https://localhost:4848].
    Use the same port [4848] for "asadmin" commands.
    User web applications are available at these URLs:
    [http://localhost:8080 https://localhost:8181 ].
    Following web-contexts are available:
    [/web1  /__wstx-services ].
    Standard JMX Clients (like JConsole) can connect to JMXServiceURL:
    [service:jmx:rmi:///jndi/rmi://learning:8686/jmxrmi] for domain management
    purposes.
    Domain listens on at least following ports for connections:
    [8080 8181 4848 3700 3820 3920 8686 ].
    Domain supports application server clusters and other standalone instances.

Po uruchomieniu instancji server (DAS), mamy powyższe podsumowanie. Zalogujmy się na Admin Console w celu praktycznego przetestowania DAS’a. W tym celu uruchamiamy przeglądarkę w zonie globlanej jako URL podając zonę zone01 na której działa nasz DAS. Z uwagi na komunikację z użyciem FQDN użyjemy https://zone01.example.com:4848/

Powyższy URL jest adresem pod którym logujemy się do Admin Console. Admin Console jest to webowe, graficzne narzędzie administracyjne, które podobnie jak asadmin służy do administracji domeną.

Rysunek 2. Ekran logowania do Admin Console.

Rysunek 3. Strona startowa Admin Console. Common Tasks. Po zalogowaniu do Admin Console.

Rysunek 4. Wizualizacja środowiska po instalacji DAS.

Budowa akwarium. Klaster GlassFish.

Po zainstalowaniu DAS czas stworzyć przykładowy klaster. Wpierw stworzymy konfigurację naszego klastra na DAS’ie, do której będziemy podczepiać nowe instancje. Nowo dodane instancje synchronizują się z centralnym repozytorium DAS’a kopiując do repozytorium lokalnego aplikację którą będą hostować - instancje w klastrze są homogeniczne. Do stworzenia klastra wystarczy jedna prosta komenda:

    zone01 # ./asadmin create-cluster clusterA

Po chwili otrzymamy odpowiedź.

    Command executed successfuly

Po wykonaniu tej komendy w katalogu /opt/SUNWappserver/domain/domain/config utworzył się katalog clusterA-config w wewnątrz którego w katalogu lib możemy dodać biblioteki tylko na potrzeby naszych instancji w klastrze. Utworzyliśmy klaster o nazwie clusterA. Oprócz utworzenia powyższych katalogów został zaktualizowany plik domain.xml opisujący naszą domenę domain1 o wpis na temat klastra. Po utworzeniu konfiguracji klastra czas dodać do niego instancje.

Rysunek 5. Wizualizacja środowiska po stworzeniu klastra.

Budowa akwarium ciąg dalszy. Instalacja agentów.

Naszą architekturę zbudujemy z czterech instancjach. Każda z nich będzie zainstalowana w oddzielnej zonie: zone02, zone03, zone04, zone05. Instalacja jest podobna jak w przypadku DAS. Z taką różnicą, że nie instalujemy komponentów:

• Domain Administration Server.
• Administration tools.

Z uwagi na fakt, że całe środowisko jest w zonach wpierw musimy uruchomić dane zony. W tym celu:

    global # zoneadm –z zone02 boot
    global # zoneadm –z zone03 boot
    global # zoneadm –z zone04 boot
    global # zoneadm –z zone05 boot

Powyższe komendy spowodują uruchomienie 4 następnych zon. Na każdej z nich przeprowadzimy identyczne instalacje GlassFish’a. Na każdej stworzymy po jednym agencie, do którego będziemy podczepiać instancje.

Kolejno dla każdej z zon:

Logujemy się:

    global # zlogin zone02
    [Connected to zone 'zone02' pts/14]
    Last login: Thu Feb 11 07:38:06 on pts/6
    Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
    zone02 #

Instalujemy GlassFish’a (pomijając instalacje Domain Administration Server oraz Administration Tools, ale nie zapominając o komponentach HADB. Inne parametry instalacji robimy identyczne jak w przypadku instalacji naszego DAS’a):

    zone02 # ./sges_ee-2_1_1-solaris-i586-ml.bin -console

Tworzymy agenta komendą create-node-agent w asadmin w zonie, podając jako host DAS’a w formacie FQDN (zone01.example.com), a jako port, port na którym działa DAS (4848):

    zone02 # cd /opt/SUNWappserver/bin/
    zone02 # ./asadmin create-node-agent --host zone01.example.com --port 4848 zone02-node-agent

Podczas tworzenia agenta zostaniemy poproszeni o podanie loginu (admin):

    Please enter the admin user name>

Oraz hasła (adminadmin):

    Please enter the admin password>

Po podaniu wymaganych danych po chwili otrzymamy odpowiedź o utworzeniu agenta.

    Command create-node-agent executed successfully.

W tym momencie DAS otrzymał wpis w domenie o istnieniu agenta na oddzielnej maszynie, jednak abyśmy mieli z nią komunikację przez JMX musimy wpierw uruchomić naszego agenta.

Uruchamiamy agenta komendą start-node-agent w asadmin:

    zone02 # ./asadmin start-node-agent zone02-node-agent

Zostaniemy poproszeni o podanie loginu (admin):

    Please enter the admin user name>

Hasła (adminadmin):

    Please enter the admin password>

Oraz hasła Master (adminadmin):

    Please enter the master password [Enter to accept the default]:>

Po uruchomieniu agenta otrzymujemy wpis z informacją do logów jak poniżej.

    Redirecting output to
    /opt/SUNWappserver/nodeagents/zone01-node-agent/agent/logs/server.log
    Redirecting application output to
    /opt/SUNWappserver/nodeagents/zone01-node-agent /agent/logs/server.log
    Command start-node-agent executed successfully.

Po dokonaniu tych czynności na każdej z zon, sprawdzimy czy DAS ma komunikację za wszystkimi agentami. Logując się na Admin Console (https://zone01.example.com:4848) w drzewie Node Agents zobaczymy listę naszych agentów w domeniw:

Rysunek 6. Podgląd stanu agentów z poziomu Admin Console.

Rysunek 7. Wizualizacja środowiska po utworzeniu agentów.

Budowa akwarium ciąg dalszy. Instancje w klastrze.

Obecnie utworzyliśmy nasz klaster clusterA dodając do niego cztery hosty. Czas utworzyć na hostach instancje GlassFish’a, które będą brać udział w mechanizmie HADB. W tym celu na każdej z zon: zone02, zone03, zone04, zone05 zainstalujemy instancje już bezpośrednio z DAS. Mamy taką możliwość ponieważ uruchomiliśmy już agentów.

Instancje utworzymy używając komendy create-instance w asadmin.

    zone01 # ./asadmin create-instance --cluster clusterA --nodeagent
        zone02-node-agent instance

Po utworzeniu instancji otrzymamy podsumowanie na jakich portach działa utworzona instancja.

Using 38,081 for HTTP_LISTENER_PORT.
Using 38,182 for HTTP_SSL_LISTENER_PORT.
Using 33,821 for IIOP_SSL_LISTENER_PORT. Using 37,677 for JMS_PROVIDER_PORT.
Using 33,701 for IIOP_LISTENER_PORT.
Using 38,687 for JMX_SYSTEM_CONNECTOR_PORT.
Using 33,921 for IIOP_SSL_MUTUALAUTH_PORT.
Command create-instance executed successfully.

Analogicznie tworzymy instancje dla każdej z zon. Po utworzeniu wszystkich instancji i zalogowaniu się Admin Console (https://zone01.example.com:4848) zobaczymy jak wygląda nasz klaster. Drzewo Clusters -> clusterA - zakładka Instances.

Rysunek 8. Stan klastra po utworzeniu instancji.

Aby uruchomić klaster wystarczy nam prosta komenda start-cluster w asadmin na DAS:

    zone01 # ./asadmin start-cluster clusterA
    Command start-cluster executed successfully.

Po uruchomieniu tej komendy w drzewie Clusters –> clusterA zobaczymy nasze 4 aktywne instancje wraz z ich stanem.

Rysunek 9. Stan klastra po jego uruchomieniu.

Na końcu mamy prezentacje graficzną naszego środowiska. Zakończyliśmy etap budowy klastra czas przygotować HADB.

Rysunek 10. Stan środowiska po uruchomieniu klastra.

Topologie HADB

Mechanizm rozproszonej bazy wysokiej dostępności pozwala na stworzenie dwóch topologii:

• Colocated (wraz z instancjami klastra)
• Separate tier (na oddzielnych nodach)

Pierwsza bazuje na użyciu tych nod’ów, na których pracują instancje w celu przechowywania replikacji sesji. Druga przewiduje użycie w tym celu odrębnych maszyn. Zwiększa to oczywiście wydajność instancji, ale nakłada wymogi na przepustowość sieci, oraz wymaga dodatkowego sprzętu.

Z uwagi na prostotę naszego środowiska będziemy trzymać się pierwszej topologii – colocated.

Obie topologie przedstawione są na poniższych ilustracjach.

Rysunek 11. Topologia coolocated w HADB.

Rysunek 12. Topologia separate tier w HADB.

Teoria w HADB.

Dwie przedstawione topologie charakteryzuje identyczna logiką działania HADB. Warto wpierw omówić kilka pojęć związanych z HADB, aby w pełni zrozumieć obie topologie.

Omówimy:

• Domena HADB
• DRU
• Management Agent
• Active node
• Spare node

Domena HADB - w obu topologiach mechanizm HADB tworzy odrębną domenę. Nie jest to domena w rozumieniu tradycyjnych domen GlassFish’a, ale domena skupiająca w sobie nod’y odpowiadające za repozytorium i replikacje sesji. Domena HADB skupia w sobie pary nod’ów, każda para replikuje sesje między sobą (A w B i B w A) w grupach zwanych DRU.

DRU (Data Redundancy Unit) – są zawsze dwie. Każda z nich zawiera 100% replikację sesji. Nod wchodzący w skład jednego DRU ma w drugim DRU swego mirror’a, drugiego nod’a z którym replikuje sesje. Oba nod’y tworzą poziom. Do każdej domeny nod’y dodaje się lub usuwa parami, co skutkuje usunięciem bądź dodaniem nod’ów z obydwu DRU. Każdy DRU zawiera w sobie aktywne (active) oraz wolne (spare) nod’y.

Management Agent – proces JVM, agenta HADB hostujący sesje na klasterze GlassFish. Może być active lub spare.

Active node – nod aktywny wchodzący w skład DRU. Jest to działający proces Management Agent (MA), który bierze aktywny udział w domenie (hostuje oraz replikuje sesje).

Spare node – jest to nod "zapasowy". Spare node jest podpięty pod dane DRU i pełni rolę backup’u. Jeśli z jakiś powodów proces MA przestaje działać w jego miejsce wchodzi Spare Node, który synchronizuje się pobierając replikacje sesji z mirror’a zakończonego procesu MA. W architekturze HADB Spare Nod’y są opcjonalne. Jeśli ich nie wykorzystamy to w przypadku awarii danego MA jego mirror hostuje swoje sesje plus replikacje sesji mirrora, co sprawia, że musi mieć zapasową moc obliczeniową.

Cała baza działa dopóki dopóty na każdym z poziomów działa przynajmniej jeden nod.

Poniżej przedstawiona jest przykładowa prezentacja architektury HADB z użyciem 4 nodów, 2 active, 2 spare.

Dodatkowo dołączony jest diagram struktur połączonych reprezentujący architekturę, którą będziemy budować.

Rysunek 13. Przykładowa architektura prostego HADB w topologii separate tier. W celu przejrzystości pominięto reprezentację klastra clusterA.

Rysunek 14. Diagram struktur połączonych zależności między domena a hadb.

Budowa HADB. Uruchamianie agentów HADB.

Aby móc skorzystać z mechanizmu HADB w środowisku Solaris wymogiem jest parametryzacja kernela. Są to cztery komendy które wykonujemy w terminalu w zonie globlanej:

    global # set shmsys:shminfo_shmmax=0x80000000
    global # set semsys:seminfo_semmni=16
    global # set semsys:seminfo_semmns=128
    global # set semsys:seminfo_semmnu=1000

Uwaga: Powyższe parametry różnią się oczywiście od środowiska na jakim będziemy stawiać nasze usługi. Jako referencje polecam Sun GlassFish Enterprise Server v2.1 High Avaliabiliy Administration Guide, gdzie znajdziemy wytyczne odnoście konfiguracji środowiska pod HADB.

Po ustawieniu parametrów robimy restart maszyny. Formalnie Solaris pozwala na konfigurowania parametrów bez restartowania maszyny, ale z uwagi na prostotę przeprowadzamy ponowne uruchomienie systemu. W tym celu użyjemy komendy init 6.

    global # init 6

Po ponownym uruchomianiu maszyny, zalogowaniu do Solarisa, musimy na nowo:

1. Uruchomić zone zone01 a w niej DAS’a
2. Uruchomić zony zone02, zone03, zone04, zone05 i w nich ich agentów
3. Uruchomić klastra z DAS

Wszystkie powyższy procedury były już omawiane, więc nie powinno być problemu z ich powtórzeniem.

Pierwszą czynnością, którą przeprowadzamy podczas tworzenia HADB jest instalacja modułów HADB do każdej z instancji. Tą czynność już przeprowadziliśmy instalując moduły wraz z instancjami na samym początku.

Drugim krokiem jest uruchomienie agentów HADB. Agent HADB nosi nazwę Management Agent i odpowiada za obsługę tej części bazy, za którą odpowiada dany nod z bazie HADB. Dla przypomnienia dodam, że baza jest rozproszona, co za tym idzie jej schema jest podzielona względem ilości nod’ów, a każdy z nod’ów pracuje jedynie na swojej części bazy.

W celu uruchomienia Management Agent’a w katalogu instalacji GlassFisha mamy podkatalog hadb. To właśnie w nim znajdują się moduły do HADB, które w tej dystrybucji są dostępne w dwóch wersjach 4 oraz 4.4.3-21 jak widać po nazwach katalogów w katalogu hadb. Do naszych ćwiczeń użyjemy modułów 4.4.3-21. Uruchamiamy więc agenta (na każdej z zon: zone02, zone03, zone04, zone05).

    zone02 # cd /opt/SUNWappserver/hadb/4.3.3-21/bin/
    zone02 # ./ma ma.cfg

Plik ma.cfg jest to plik konfiguracyjny agenta.

    Management Agent version 4.4.3.21 [V4-4-3-21 2009-04-25 03:09:43 pakker@hel04]
    ( SunOS_5.9_ix86) starting
    Logging to /opt/SUNWappserver/hadb/4.4.3-21/log/ma.log
    2010-02-14 18:04:26.964 INFO    Management Agent version 4.4.3.21
    [V4-4-3-21 200 9-04-25 03:09:43 pakker@hel04] (SunOS_5.9_ix86) starting
    2010-02-14 18:04:26.965 INFO    Using property: jgroups.fragsize=8096
    2010-02-14 18:04:26.966 INFO    Using property: ma.server.type=jmxmp
    2010-02-14 18:04:26.966 INFO    Using property: ma.server.mainternal.interfaces=
    2010-02-14 18:04:26.966 INFO    Using property: ma.server.dbhistorypath=
    /opt/SUN Wappserver/hadb/4.4.3-21/history
    2010-02-14 18:04:26.966 INFO    Using property: ma.server.dbconfigpath=
    /opt/SUNW appserver/config/hadb
    2010-02-14 18:04:26.967 INFO    Using property: jgroups.loglevel=OFF
    2010-02-14 18:04:26.967 INFO    Using property: console.loglevel=INFO
    2010-02-14 18:04:26.967 INFO    Using property: logfile.name=
    /opt/SUNWappserver/ hadb/4.4.3-21/log/ma.log
    2010-02-14 18:04:26.967 INFO    Using property: ma.server.jmxmp.port=1862
    2010-02-14 18:04:26.967 INFO    Using property: logfile.loglevel=INFO
    2010-02-14 18:04:26.968 INFO    Using property: ma.server.dbdevicepath=
    /opt/SUNW appserver/hadb/4.4.3-21/device
    2010-02-14 18:04:26.968 INFO    Using property: repository.dr.path=
    /opt/SUNWapps erver/hadb/4.4.3-21/rep
    2010-02-14 18:04:27.203 INFO    Listening for client connections on port 1862

Powyższy wydruk na konsole jest podsumowaniem po uruchomieniu agenta. Jak widać zgodnie z konfiguracją w pliku ma.cfg agent nasłuchuje na porcie JMX 1862, repozytorium przetrzymuje w podkatalogu /rep, logi agenta są zapisywane do pliku ma.log, a historia operacji na bazie jest przechowywana w podkatalogu /history.

Oprócz skryptu ma, który uruchamia nam agenta w katalog /bin znajdziemy:

    zone01 # ls
    clusql    hadbm     ma        ma-initd  ma.cfg

• clustersql – SQL Utility, narzędzie SQL do ręcznej pracy na bazie.
• hadbm – (High Avaliability Database Manager) narzędzie do zarządzania bazą HADB.
• ma – Management Agent, skrypt do uruchomienia agenta.
• ma-initd – skrypt do zarejestrowania agenta jako usługi w Solarisie do wersji 9 (od wersji 10 rejestrujemy do sami jako usługę w SMF).
• ma.cfg – plik konfiguracyjna agenta.

Po uruchomieniu agentów HADB, czas na budowę bazy.

Budowa HADB. Tworzenie bazy.

Do stworzenia bazy w przypadku topologii colocated wystarczy nam jedna prosta komenda (w przełączniku hosts nie ma spacji między kolejnymi maszynami oraz nazwy maszyn podajemy używając FQDN):

    zone01 # ./asadmin configure-ha-cluster --hosts
    zone02.example.com,zone03.example.com,zone04.example.com,zone05.example.com
    clusterA

Po dłuższej chwili (w zależności od sprzętu na jakim pracujemy 5 minut lub więcej) otrzymamy odpowiedź:

    Command configure-ha-cluster executed successfully.

I w ten oto prosty sposób utworzyliśmy krok po kroku architekturę HADB.

To co dzieje się przez tą komendę to uruchomienie w tle narzędzia hadbm i kolejno utworzenie domeny HADB, stworzenie schema dla bazy i dodanie nod’ów do DRU, wszystkich jako aktywne. Dzięki tej komendzie mamy najszybszy i najprostszy sposób to tworzenia HADB jednak tylko w topologii colocated. W przypadku topologii z użyciem oddzielnych maszyn musielibyśmy używać narzędzia hadbm i ręcznie krop po kroku tworzyli całą strukturę.

Uwaga: Dzięki narzędziu hadbm możemy zarządzać całą domeną HADB. Dodawać nod’y, zmieniać rozmiar używanej przestrzenie na dysku przez nod’y, czyścić bazę, refragmentować w przypadku dodania czy usunięcia nod’ów z DRU etc.

Aby korzystać z tego mechanizmu wystarczy wdrożyć aplikację, domyślnie DAS korzysta z HADB. Dzięki HADB będziemy mieli zapewnioną dostępność i replikację komponentów SFSB.

Konfigurację HADB przeprowadzamy z poziomu Admin Console.

Podsumowanie

Powyższy artykuł pokazał, jak w prosty sposób zbudować HADB. Więcej na temat wysokiej dostępność w oparciu o GlassFisha polecam dokument - Sun GlassFish Enterprise Server 2.1 High Availability Administration Guide, gdzie szczegółowo opisany jest Load Balancing, HADB oraz replikacja JMS.