Upload
ibm-software-polska
View
306
Download
3
Embed Size (px)
Citation preview
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
MakeAvailable/WhenAvailable
TSO VTAM
MakeAvailable/WhenAvailable
MakeAvailable/WhenAvailable
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
MakeUnavailable/WhenUnavailable
MakeUnavailable/WhenUnavailable
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