Zrzuć obowiązki na automat

Zrzuć obowiązki na automatZrzuć obowiązki na automatOlgierd CieślakOlgierd Cieślak

© 2009 IBM Polska

Agenda

Cel System Automation

Architektura

Relacje

Grupy

SA for Multiplatforms i AppMan

© 2009 IBM Polska

Cel stosowania automatyzacji

Zarządzanie automatyzowanymi zasobami (aplikacjami) - uproszczenie zarządzania, - ujednolicenie sposobu obsługi - automatyczne reagowanie na sytuacje awaryjne - monitorowanie zachowania aplikacji

Monitorowanie i zarządzanie zasobami sysplexu - zbiorów couple data sets - struktur CF, itp.

z/OS housekeeping (automatyzacja MVS) - kontrola zbiorów SMF - kontrola zbiorów dla dumpów, itp.

Automatyzacja UNIX System Services (USS) - start i stop aplikacji USS - monitorowanie aplikacji USS

© 2009 IBM Polska

Struktura System Automation

Polisaautomatyzacji

System Automation(Agent)

NetView

z/OS System: SYS1

Żąd

ania

Sta

ny

System Automation(Spare Manager)

System Automation(Agent)

NetView

z/OS System: SYS2

System Automation(Primary Manager)

Kopia

© 2009 IBM Polska

Rola managera automatyzacji

Manager jest komponentem SA który podejmuje decyzje o sposobie zachowania aplikacji w obrębie sysplexu

Posiada wiedzę o: - Wszystkich zasobach i ich lokalizacji,

- Relacji między zasobami, - Grupach zasobów - Zdarzeniach

Jest ukierunkowany na realizację celów,

Wysyła do agentów zlecenia - Startu aplikacji, - Zatrzymania aplikacji

Informuje operatora o istotnych zdarzeniach.

© 2009 IBM Polska

Manager automatyzacji - Podstawowe pojęcia

Cel (ang. goal) - Zadany stan do którego chcemy doprowadzić aplikację, - Cel wyznaczany jest przez operatora lub przez samo automation - SA podejmuje niezbędne kroki (zapisane w polisie automatyzacji) aby cel został zrealizowany - Prośba realizacji celu generuje głos.

Głos (ang. vote) - Manager automatyzacji otrzymuje żądania z różnych źródeł, - Żądania mogą mieć różną ważność i różny zasięg - Żądania mogą być niekiedy z sobą sprzeczne - Głos to żądanie realizacji celu z uwzględnieniem źródła, ważności, zasięgu i relacji w jakiej żądanie pozostaje w stosunku do innych żądań.

© 2009 IBM Polska

Rola agenta automatyzacji

Wykonuje czynności startu, stopu i monitorowania aplikacji w imieniu managera.

- Otrzymuje i wykonuje rozkazy startu i stopu aplikacji od managera, - Określa aktualny stan aplikacji na podstawie generowanych przez nią komunikatów, - Wysyła informacje o bieżących stanach do managera, - Stwierdza kiedy limity (tresholdy) dla recovery zostały przekroczone. - Utrzymuje timery

Co jest kontrolowane przez Agenta Automatyzacji: - Podsystem MVS, - Dowolna procedura MVS, - Aplikacja VTAM, - Transakcja CICS, - Itp.

© 2009 IBM Polska

Start aplikacji

• Start aplikacji składa się z trzech etapów:

- Pre-start – przygotowanie środowiska do startu,

- Startup – właściwy start aplikacji,

- Post-start – akcje podejmowane po zainicjowaniu aplikacji

• Różne tryby uruchamiania aplikacji:

- Definiowany przez użytkownika etykiety np. COLD, RECOVERY,

- Różne komendy w poszczególnych trybach.

© 2009 IBM Polska

Stop aplikacji

• Stop aplikacji składa się z trzech etapów:

- SHUTINIT – przygotowanie środowiska do zatrzymania aplikacji,

- Stop – właściwe zatrzymanie aplikacji,

- SHUTFINAL – akcje podejmowane po zakończeniu aplikacji

• Różne tryby zatrzymywania aplikacji:

- Domyślnie zdefiniowane trzy etykiety - NORM, IMMED, FORCE

- Różne komendy w poszczególnych trybach.

© 2009 IBM Polska

Stan aplikacji (Agent Status)

• Stan to informacja określająca bieżące zachowanie aplikacji,

• Stan określany jest przez agenta na podstawie zdefiniowanych

wcześniej zdarzeń oraz różnych informacji takich jak:

- Obecność podsystemu w MVS (czy jest aktywna przestrzeń adresowa),

- Czy podsystem działa zgodnie z założeniami,

- Jak wyglądał start lub stop,

- Jakie komunikaty generowała aplikacja,

- Czy a jeśli to ile razy aplikacja „padła”

• Stany aplikacji zapisywane są na bieżąco w tzw. Status File

• W zależności od stanu podejmowane są odpowiednie akcje

© 2009 IBM Polska

Relacja

• Połączenie między dwoma zasobami określające ich

zachowanie

• Jest kilka typów relacji i wiele warunków jej spełnienia.

A B

Zasób zależny

relacja / warunek

Zasób wspierający

Schemat relacji

Przykład:

TSO JES

Zasób zależny Zasób wspierający

MakeAvailable/WhenAvailable

© 2009 IBM Polska

Relacja MakeAvailable - przykład

VTAM musi być aktywny żeby można było uruchomić TSO

TSO VTAM

Zasób zależny Zasób wspierający


TSO VTAM



JES2

Ale żeby aktywować VTAM potrzeba aktywnego JES2

© 2009 IBM Polska

Relacja MakeUnavailable - przykład

Konieczna jest również relacja odwrotna zapewniająca, że TSO zostanie zamknięte zanim zamykany będzie VTAM

TSO VTAM

Zasób zależnyZasób wspierający

MakeUnavailable/WhenUnavailable

TSO VTAM



JES2

oraz, że VTAM zostanie zamknięty zanim rozpocznie się zamykanie JES2

© 2009 IBM Polska

Relacja MakeUnavailable - przykład

• Relacja HasParent jest złożeniem dwóch poprzednich relacji.

• Odzwierciedla dwustronną zależność między zasobami (dla startu i stopu)

• Jest najczęściej używaną relacją.

TSO

VTAM

MakeUnavailable/

WhenAssumedDownHasParent

TSO

VTAM

MakeAvailable/

WhenAvailable=

© 2009 IBM Polska

Grupowanie zasobów• Logiczne zgrupowanie zasobów w pewien sposób

powiązanych ze sobą.

- komponenty DB2 (MSTR, IRLM, DBM1…)

- obsługa sieci (TCPIP, FTP, SNMP…)

• Dwa typy grup:

- system

- sysplex

• Trzy rodzaje grup:

- basic

- move

- server

© 2009 IBM Polska

Grupowanie zasobów• Logiczne zgrupowanie zasobów w pewien sposób

powiązanych ze sobą.

- komponenty DB2 (MSTR, IRLM, DBM1…)

- obsługa sieci (TCPIP, FTP, SNMP…)

• Dwa typy grup:

- system

- sysplex

• Trzy rodzaje grup:

- basic

- move

- server

© 2009 IBM Polska

Inne platformy – SA for Multiplatforms

© 2009 IBM Polska

SA Application Manager

© 2009 IBM Polska

Koniec - pytania

Zrzuć obowiązki na automat

Documents