Zarządzanie obciążeniem |
Noty techniczne do przykładu BeenThere |
Znajdowanie kodu źródłowego |
Przeglądanie uwag dotyczących kodu |
Kod źródłowy aplikacji BeenThere znajduje się w katalogu
Użytkownicy systemu z/OS: Drzewo kodu źródłowego przykładów nie jest udostępniane na platformie z/OS, ponieważ przykładowe aplikacje nie są budowane na platformie z/OS.
Aplikacja BeenThere demonstruje możliwości funkcji zarządzania obciążeniem (workload management - WLM) produktu IBM WebSphere Application Server w wersji Network Deployment. Aplikacja BeenThere zawiera serwlet BeenThere oraz bezstanowy komponent EJB sesji BeenThere. Serwlet BeenThere reprezentuje serwer aplikacji w klastrze, do którego rozsyłane jest żądanie HTTP. Komponent EJB BeenThere reprezentuje serwer aplikacji w klastrze, do którego wysłane zostało żądanie komponentu EJB. Komponent EJB BeenThere jest wywoływany przez serwlet BeenThere.
Serwlet BeenThere wyświetla następujące informacje:
Dodatkowo serwlet BeenThere może wykonywać następujące akcje:
Środowisko przykładu, używane do demonstrowania funkcji zarządzania obciążeniem kontenera WWW oraz kontenera EJB, zostało przedstawione na następującej ilustracji:
Rysunek 1 Środowisko przykładu
Komputery w tym środowisku obejmują:
Konfiguracja zawiera dwa klastry serwerów, MyWebCluster oraz MyEJBCluster. Klaster serwerów składa się z grupy serwerów aplikacji. Jeśli jeden z serwerów w klastrze ulegnie awarii, żądania kierowane będą do pozostałych elementów klastra. Każdy z klastrów przykładu składa się z dwóch elementów klastra. Klaster MyWebCluster składa się z elementów klastra WebServer1 i WebServer2, a klaster MyEJBCluster składa się z elementów klastra EJBServer1 i EJBServer2.
Tak skonfigurowane środowisko stanowi przykład, który jest używany tylko w celu zademonstrowania sposobu uruchamiania aplikacji BeenThere. W środowisku produkcyjnym konieczne jest przeprowadzenie dokładnego planowania mocy obliczeniowej zasobów, aby określić liczbę elementów serwerów aplikacji, które mają zostać utworzone na konkretnej liczbie komputerów w oparciu o spodziewane obciążenie żądaniami klientów.
Serwer WebSphere Application Server w wersji Network Deployment udostępnia funkcję zarządzania obciążeniem (workload management - WLM) dla żądań HTTP i EJB.
Zarządzanie obciążeniem dla żądań HTTP jest obsługiwane przez wtyczkę serwera WWW.
Warto bliżej przyjrzeć się konfiguracji przedstawionej na rysunku 1. Na komputerze web działa serwer IBM HTTP Server, który rozsyła żądania HTTP do każdego z serwerów aplikacji WebServer1 i WebServer2 stanowiących elementy klastra MyWebCluster, na których działa serwlet BeenThere. Wymienione serwery aplikacji zostały skonfigurowane odpowiednio na komputerach app1 i app2. Ponadto wtyczka serwera IBM HTTP Server została tak skonfigurowana, że serwer WebServer1 ma wagę zarządzania obciążeniem wynoszącą 2, a serwer WebServer2 ma wagę zarządzania obciążeniem wynoszącą 3. Wagi mogą być postrzegane jako liczniki, które uruchamiają się przy skonfigurowanej wartości i zmniejszają się o 1 po obsłużeniu każdego żądania. Żądania są rozsyłane przy użyciu procesu cyklicznego do każdego serwera aplikacji, którego bieżąca wartość licznika wagowego jest większa niż 0. Jeśli wartość licznika wynosi 0, to serwer aplikacji jest pomijany. Po zmniejszeniu wartości wszystkich liczników wagowych do 0 następuje zresetowanie wszystkich liczników wagowych serwerów aplikacji do ich skonfigurowanych wartości, a proces rozsyłania rozpoczyna się od początku.
Zarządzanie obciążeniem dla żądań EJB jest obsługiwane wewnętrznie przez kontroler zarządzania obciążeniem serwera WebSphere Application Server.
Warto bliżej przyjrzeć się konfiguracji przedstawionej na rysunku 1. Zdefiniowany został klaster MyEJBCluster składający się z elementów serwera aplikacji EJBServer1 i EJBServer2, które są odpowiedzialne za działanie bezstanowego komponentu EJB sesji BeenThere. Serwlet BeenThere wywołuje komponent EJB, aby uzyskać informacje dotyczące wykonywania na serwerze aplikacji, na którym działa komponent EJB. Ponadto serwery te zostały skonfigurowane z wartościami wagowymi wynoszącymi odpowiednio 1 i 3.
Na platformie z/OS wartości wagowe używane są do równoważenia żądań HTTP, ale nie są używane do równoważenia żądań internetowych protokołu IIOP (Inter-ORB Protocol).
Aplikacja BeenThere korzysta z interfejsów programistycznych aplikacji administracyjnych serwera WebSphere Application Server. Dzięki tym interfejsom aplikacje mają dostęp do informacji konfiguracyjnych środowiska wykonawczego i środowiska serwera:
Udostępnia interfejsy po stronie serwera, które służą do uzyskiwania informacji o atrybutach serwera aplikacji, oraz pozwala wykonywać standardowe funkcje zarządzania komponentami JMX MBean.
Udostępnia interfejsy ze strony klienta dla zdalnego obiektu AdminService. Klasa AdminClient oferuje funkcje serwera proxy dla zdalnego obiektu AdminService za pośrednictwem jednego z obsługiwanych konektorów Java Management Extensions (JMX).
Udostępnia interfejsy do odpytywania i modyfikowania danych konfiguracyjnych (lokalnie lub zdalnie) oraz pozwala zarządzać położeniem i treścią dokumentów konfiguracyjnych serwera aplikacji.
Aby zademonstrować pełnię możliwości i elastyczność, jaką aplikacje zyskują dzięki interfejsom administracyjnym serwera WebSphere Application Server, aplikacja BeenThere korzysta z wszystkich wymienionych interfejsów w następujący sposób:
Interfejs AdminService jest używany przez serwlet BeenThere i komponent EJB do uzyskiwania nazwy węzła, nazwy serwera aplikacji oraz identyfikatora procesu dla serwera aplikacji, w obrębie którego działają. Następujący segment kodu demonstruje sposób uzyskiwania informacji o atrybucie serwera:
// Pobierz obiekt AdminService produktu Websphere. AdminService adminService = AdminServiceFactory.getAdminService(); // Pobierz instancję komponentu MBean lokalnego serwera administracyjnego produktu Websphere. ObjectName localServer = adminService.getLocalServer(); // Pobierz nazwę węzła. nodeName = (String) adminService.getAttribute(localServer, "nodeName"); // Pobierz nazwę serwera aplikacji. serverName = (String) adminService.getAttribute(localServer, "name"); // Pobierz identyfikator procesu serwera aplikacji. serverPid = (String) adminService.getAttribute(localServer, "pid");
Interfejs AdminClient jest używany do łączenia z procesem menedżera wdrażania w celu pobrania wartości wagowych elementów klastra dla wszystkich elementów serwera aplikacji w klastrze, w obrębie którego działa komponent EJB BeenThere. Następujący segment kodu demonstruje sposób uzyskiwania instancji interfejsu AdminClient:
// Pobierz obiekt AdminService produktu Websphere. AdminService adminService = AdminServiceFactory.getAdminService(); // Pobierz instancję AdminClient dla menedżera wdrażania. adminClient = adminService.getDeploymentManagerAdminClient();
Interfejs ConfigService jest używany do odczytywania dokumentu konfiguracyjnego serwera WebSphere Application Server o nazwie cell.xml w celu określenia, czy aplikacja BeenThere działa na serwerze WebSphere Application Server Base Edition, czy w środowisku Network Deployment Edition. Następujący segment kodu demonstruje sposób określania środowiska, w którym działa aplikacja:
// Utwórz nową sesję zarządzania produktu WebSphere. Session session = new Session(); // Pobierz instancję obiektu ConfigService produktu WebSphere // dla serwera aplikacji wykonującego ten serwlet. ConfigService configService = ConfigServiceFactory.getConfigService(); if (configService != null) { // Odczytaj dokument cell.xml. ObjectName cellObj = ConfigServiceHelper.createObjectName(null, "Cell"); ObjectName[] cellObjs = configService.queryConfigObjects(session, null, cellObj, null); if (cellObjs.length != 0) { cellObj = cellObjs[0]; String cellName = (String) configService.getAttribute(session, cellObj, "name"); String cellType = (String) configService.getAttribute(session, cellObj, "cellType"); if (cellType.equals("DISTRIBUTED")) { websphereND = true; } } // Zwolnij sesję. configService.discard(session);Jeśli wykryte zostanie środowisko Network Deployment, opcja Wyświetl wagi elementów klastra komponentów bean zostanie włączona i będzie wyświetlana, ponieważ jest ona poprawna tylko w tym typie środowiska. W przeciwnym razie nie jest ona wyświetlana jako opcja możliwa do wybrania.