Klient IBM Spectrum Protect w piaskownicy

Dlaczego Docker

Od jakiegoś czasu uważnie przyglądam się technologii kontenerów w różnych systemach operacyjnych. Zaczęlo się prawie 20 lat temu z Workload Managerem w AIXie, który potem przeszedł w WPARy. Gdzie po drodze obiły mi się jeszcze o uszy subsystemy w OS/400, kilka podejść w Linuxie (pierwsze w 2002 robione w... Polsce). W końcu technologia dojrzała, a świat dojrzał do niej: powszechna, wręcz chorobliwa wirtualizacja i aplikacje oparte o mikroserwisy.
Ja do tematu dojrzałem dziś, bo mnie do tego zmusiła jednym, prostym ruchem Matka Korporacja: Wraz z wprowadzeniem klienta TSM/Spectrum Protect w wersji 8.1.2 (i 7.8) praktycznie zerwano z kompatybilnością w dół. A póki co, 100% systemów klikeckich z którymi pracuję to 7.1.7.XXX i niższe. A ficzury z 8.1.3 i 4 nęcą i potestować by się chciało.
Sęk jednak w tym, że serwer 8.1.4 nie gada z klientem niższym niż 7.8. Teoretycznie, klient 7.8 i 8.1.X, gdzie X >=2 gada z niższymi serwerami, ale jak raz zobaczy się z "wyższym" to już z niczym innym gadać nie będzie. Czyli muszę mieć dwóch klinetów BA w systemie - 8.1.1 do pracy i 8.1.4 do zabawy. A tego producent nie przewidział.
Zwykle w takiej sytuacji klonuję moją roboczą Fedorę, instaluję co trzeba i tyle. Tym razem postawiłem na Dockera.

Jak zacząć?

1. Mieć jakiegoś w miarę nowoczesnego linuxa na hoście. Ja mam Fedorkę 27.
2. Nie czytać https://docs.docker.com/get-started/. 
3. Przeczytać tę dokumentację, przynajmniej do ustępu o pomijaniu sudo.
4. Rozpocząć zabawę z kontenerami.

A może jednak coś warto wiedzieć?

Mi wystarczyło mieć śwadomość następujących faktów, choć niektóre z nich uświadomiłem sobie "w boju":

1. Kontener po zgaszeniu WRACA do oryginalnego stanu. Czyli nie ma tak, że odpalam sobie jakiś generyczny kontenerek z Fedorą (bardzo generyczny: bash, ls i dnf i kilka, w sumie 86MB innych programów), doinstalowuję co trzeba, gaszę i jak potrzebuję to odpalam.
2. Kontener buduje się... na bazie innego kontenera. Ja postanowiłem użyć docker.io/fedora, który jest oficjalnym buildem fedory na Dockera.
3. Kontener buduje się na podstawie Dockerfile. Tu jest dokumentacja z przykładowym plikiem.

Tworzenie kontenera

Sciągam podstawkę:

$ docker pull docker.io/fedora
Using default tag: latest
Trying to pull repository docker.io/library/fedora ...
sha256:25f7dac76b2c88d8b7e0b1d6213d3406e77c7f230bfa1e66bd1cbb81a944eaaf: Pulling from docker.io/library/fedora
a8ee583972c2: Pull complete
Digest: sha256:25f7dac76b2c88d8b7e0b1d6213d3406e77c7f230bfa1e66bd1cbb81a944eaaf
Status: Downloaded newer image for docker.io/fedora:latest

$ docker images
REPOSITORY              TAG                 IMAGE ID            CREATED             SIZE
docker.io/hello-world   latest              f2a91732366c        6 weeks ago         1.85 kB
docker.io/fedora        latest              422dc563ca32        7 weeks ago         252 MB

Zakładam pusty katalog na mój projekt:

$ mkdir -p /home/marcinek/containers/SPCliV8.1.4

$ cd  /home/marcinek/containers/SPCliV8.1.4

$  

Na początek trzeba przygotować pliki jakie będą używane do budowy  kontenera. Chcę zainstalować klienta Backup Archive (BA) w wersji 8.1.4. Mozna go sobie pobrać np stąd. Ja sobie stworzyłem katalog install gdzie wrzuciłem następujące pliki:

$ pwd
/home/marcinek/containers/SPCliV8.1.4

$ ls install/
8.1.4.0-TIV-TSMBAC-LinuxX86.tar        gskssl64-8.0.50.78.linux.x86_64.rpm  README.htm              TIVsm-APIcit.x86_64.rpm  TIVsm-BAhdw.x86_64.rpm  TIVsm-filepath-source.tar.gz
gskcrypt64-8.0.50.78.linux.x86_64.rpm  README_api.htm                       TIVsm-API64.x86_64.rpm  TIVsm-BAcit.x86_64.rpm   TIVsm-BA.x86_64.rpm     TIVsm-JBB.x86_64.rpm

No i tworzę plik Dockerfile: (na razie z błędem!)

FROM fedora
run mkdir -p /opt/tivoli/tsm/client/ba/bin
add install/ /install
add dsm.sys /opt/tivoli/tsm/client/ba/bin
add dsm.opt /opt/tivoli/tsm/client/ba/bin
#run echo "proxy=http://192.168.1.12:3128" >> /etc/dnf/dnf.conf
run echo "53.46.173.120 tsmservice" >> /etc/hosts
run dnf -y install iproute nfs-utils fuse-sshfs.x86_64 iputils
run dnf -y install /install/gsk* /install/TIVsm-API64.x86_64.rpm /install/TIVsm-BA.x86_64.rpm
run rm -rf /install
CMD /opt/tivoli/tsm/client/ba/bin/dsmadmc
 

A teraz budowanie:

$ docker build -t marcinek/ispcli_v814 .

No i odpalam:

$ docker run -it marcinek/ispcli_v814 /bin/bash
[root@ae505b4dd377 /]# cat /etc/hosts
127.0.0.1    localhost
::1    localhost ip6-localhost ip6-loopback
fe00::0    ip6-localnet
ff00::0    ip6-mcastprefix
ff02::1    ip6-allnodes
ff02::2    ip6-allrouters
172.17.0.2    ae505b4dd377

Czyli qpa. Nie opisała się zmiana pliku /etc/hosts. Docker najwyraźniej tak ma, rozwiązań jest kilka. Można np uruchamiać contener z opcją --add-host=[].
No to spróbujmy:

$ docker run --add-host tsmservice:53.46.173.120 -it marcinek/ispcli_v814 cat /etc/hosts
127.0.0.1    localhost
::1    localhost ip6-localhost ip6-loopback
fe00::0    ip6-localnet
ff00::0    ip6-mcastprefix
ff02::1    ip6-allnodes
ff02::2    ip6-allrouters
53.46.173.120    tsmservice
172.17.0.2    75fa3c6d2bce


Fantastik. To teraz jak zrobić, żeby się taka zmiana zapisała na poziomie budowania kontenera?

O tym napiszę poźniej, jak znajdę jakieś w miarę eleganckie rozwiązanie bo to co znajduje google nie jest ładne :-P
Brudne jest tu: http://jasonincode.com/customizing-hosts-file-in-docker/

I jeszcze poprawka

Kończyłem ten artykuł mając pod ręką serwer 7.1.7.300. Jak wróciłem do mojego 8.1.4 , okazało się... że nie działa:

dsmadmc -se=tasiemiec
IBM Spectrum Protect
Command Line Administrative Interface - Version 8, Release 1, Level 4.0
(c) Copyright by IBM Corporation and other(s) 1990, 2017. All Rights Reserved.

Enter your user id:  admin

Enter your password: 

ANS1592E Failed to initialize SSL protocol.
ANS8023E Unable to establish session with server.

ANS8002I Highest return code was -362.
Zła informacja jest taka, że w dsmerror.log'u znajdują się dokładnie te dwa wpisy z ekranu i nic więcej.  Pierwsza myśl. no to sobie włączę trace.  Konia z rzędem temu, kto znajdzie w internecie kompletną listę flag tracingu do klienta BA. Klasy i owszem, pojedynczych flag, nie. Ponieważ wybieram się pobiegać, to szybkie rozwiązanie, w stylu żeby pozbyć się gorączki należy wyrzucić termometr. Zmienić session security dla admina na którego chcę wejść moim kontenerem ze STRICT na TRANSACTIONAL:

 

I teraz można już wchodzić na admina z kontenera.

$ dsmadmc -se=tasiemiec
IBM Spectrum Protect
Command Line Administrative Interface - Version 8, Release 1, Level 4.0
(c) Copyright by IBM Corporation and other(s) 1990, 2017. All Rights Reserved.

Enter your user id:  admin

Enter your password: 

Session established with server TASIEMIEC: Linux/x86_64
  Server Version 8, Release 1, Level 4.000
  Server date/time: 01/13/18   10:28:38  Last access: 01/13/18   10:26:43


Protect: TASIEMIEC>q pr

Process      Process Description      Process Status                                  
  Number                             
--------     --------------------     -------------------------------------------------
       3     Local to Cloud           Cancelling Move Container of OVH. Elapsed time: 
              Transfer                 0 Days, 12 Hours, 54 Minutes.                  

Protect: TASIEMIEC>q stg

Storage         Device         Storage       Estimated       Pct       Pct      Hig-     Lo-     Next Stora-
Pool Name       Class Name     Type            Capacity      Util      Migr     h M-      w      ge Pool   
                                                                                 ig      Mi-    
                                                                                 Pct      g     
                                                                                         Pct    
-----------     ----------     ---------     ----------     -----     -----     ----     ---     -----------
BMIX                           CLOUD              400 G       0.0                                          
DIR_LOCAL                      DIRECTORY          400 G      20.1                                          
IBM_DEPLOY-     IBM_DEPLO-     DEVCLASS           0.0 M       0.0       0.0       90      70               
 _CLIENT_P-      Y_CLIENT-                                                                                 
 OOL             _IMPORT                                                                                   
OVH                            CLOUD            1,238 G       8.5       

A wracając do SSLa - spróbuję to rozkminić tak, żeby działało na domyślnym ustawieniu STRICT. Pewnie zacznę od tracingu serwera, bo tam jest bardzo obiecująca flaga SSLINFO...

TSM i pule typu DIRECTORYCONTAINER

Najprościej jest je zrobić z OC, ale ja wolę command line więc postanowiłem się nad tematem pochylić. Okazał się nieco prostszy niż sądziłem.

Na TSMie, którego konfiguruję będą się odbywać testy wydajnościowe, dlatego skonfigurowałem sobie aż 4 katalogi, które będą kontenerami:

/dev/mapper/tsmvg-tsmdirpool1lv     12T   34M   12T   1% /tsm/dircont1
/dev/mapper/tsmvg-tsmdirpool2lv     12T   34M   12T   1% /tsm/dircont2
/dev/mapper/tsmvg-tsmdirpool3lv     12T   34M   12T   1% /tsm/dircont3
/dev/mapper/tsmvg-tsmdirpool4lv     12T   34M   12T   1% /tsm/dircont4

Cała filozofia sprowadza się do napisania:

tsm: TSM>def stg dirpool1 stgtype=directory

Teraz trzeba dodać katalogi do tej puli:

tsm: TSM>define stgpooldir dirpool1 /tsm/dircont1,/tsm/dircont2,/tsm/dircont3,/tsm/dircont4

ANR3254I Storage pool directory /tsm/dircont1 was defined in storage pool DIRPOOL1.

ANR3254I Storage pool directory /tsm/dircont2 was defined in storage pool DIRPOOL1.

ANR3254I Storage pool directory /tsm/dircont3 was defined in storage pool DIRPOOL1.

ANR3254I Storage pool directory /tsm/dircont4 was defined in storage pool DIRPOOL1.

Taaadaaam:

tsm: TSM>q stg

Storage         Device         Storage       Estimated       Pct       Pct      Hig-     Lo-     Next Stora-

Pool Name       Class Name     Type            Capacity      Util      Migr     h M-      w      ge Pool    

                                                                                 ig      Mi-     

                                                                                 Pct      g      

                                                                                         Pct     

-----------     ----------     ---------     ----------     -----     -----     ----     ---     -----------

ARCHIVEPOOL     DISK           DEVCLASS           0,0 M       0,0       0,0       90      70                

BACKUPPOOL      DISK           DEVCLASS           0,0 M       0,0       0,0       90      70                

DIRPOOL1                       DIRECTORY       49,144 G       0,0                                           

SPACEMGPOOL     DISK           DEVCLASS           0,0 M       0,0       0,0       90      70     

Co dalej? Dalej, to co zwykle. to jest pula typu PRIMARY, więc można ją wskazać jako destination w copygrupie.

O paru rzeczach trzeba pamiętać:

1. Pule typu DIRECTORY nie łączą się w żaden sposób z pozostałymi pulami: nie da się i backupować do copy puli, nie mają active data puli, nie można ich włączyć w hierarchię ze zwykłymi pulami. NEXT może być tylko DIRECTORY albo cloud. Edit - 23.03.2018: Windows prawda. Next musi być na zwykłą pulę i działa tylko jak ISP "mysli" że obiekt mu się nie zmieści do dirpooli.
2. Nie da się kopiować danych pomiędzy tymi pulami a zwykłymi. MOVE DATA ani MOVE NODEDATA nie zadziałają. Chyba tylko replikacja pomiędzy TSMami mogłaby pomóc. Być może export import noda, ale nie próbowałem i trwałoby to 1000 lat. Edit - 23.03.2018: Nie tysiąc tylko 3 tygodnie na dwóch łączach po 500 Mbit/s. Dla 60 TiB netto (przed deduplikacją)
3. Ochrona takich pul odbywa się wyłącznie przez replikację. Jest nowy rodzaj - replikacja miedzy pulami. Nie potrzeba drugiego TSMa. Tyle, że ta druga pula też musi być typu DIRECTORY... no albo CLOUD, ale o tym w innym wpisie. Edit - 23.03.2018: PROTECT STGPOOL do zdalnego TSMa działa jak złoto... pod warunkiem, że do puli typu Directory Container. Jak docelowa pula jest typu Cloud to qpa. Przynajmniej do wersji 8.1.4.
4. Żeby skasować taką pulę trzeba najpierw skasować kontener, a ostatnio jak to robiłem, musiało poczekać conajmniej dobę od zapisu - dlaczego? pewnie jakiś feature :-P Edit - 23.03.2018: Nasz "stary znajomy": REUSEDALAY.

Po co zatem takie pule? Przede wszystkim deduplikacja "inline" - dużo lepsza niż w przypadku "starej" deduplikacji TSM, która mocno pompowała bazę - tak x10 w stosunku do tej bez deduplikacji. A w tym wypadku nie zaobserwowałem jakiegoś szczególnego wzrostu bazy.

Drugi argument to nowa replikacja pomiędzy pulami, w tym z pulami chmurowymi (IBM SoftLayer i OpenStack Swift). Edit - 23.03.2018:Pisałem wyżej: replikacja jest na poziomie "nodów", na szczęście uwzględnia deduplikację, i jest niezależna od typów pul. Tylko jest dość wolna. A PROTECT STGPOOL do zdalnego ISP, które jest szybkie działa tylko pomiędzy pulami typu Dircontainer :-\

Trzeci argumentem, choć jeszcze go nie potwierdziłem, jest wydajność - ponoć szybciej od "starej deduplikacji" a możliwe że i może być konkurencją dla pul typu DISK. Herezja? Nie wiem, ale możliwość określenia ilości wątków zapisu do pul DIRECTORY vs jeden, sztywny wątek do DISK sugeruje, że można spróbować wycisnąć więcej z naszego wielościeżkowego storage i wielokorkowych systemów.Edit - 23.03.2018:Przynajmniej tutaj moje wcześniejsze podejrzenia się spełniły: na jedym wątku Power8 wyciąga się około 100MB/s ruchu. W P8 ma wętków 8 na korek :-P. Co ciekawe to się przekłada na jakieś 20 MB/s ruchu z dyskami, z czego ponad połowa to odczyty! Oczywiście nie przy pierszym backupie, który musi szrpnąć wszystko, ale przy incrementalach. Na intelu (jakiś Xeon z 2016 roku) prędkość przetwarzania dedupliowanych backupów wyszła na poziomie 70 MB/s na korek (nie wątek, jak w Powerach!) Czyli Power, parafrazując Twaina: Plotki o śmierci Powera okazały się grubo przesadzone.
Jeszcze jedno ciekawe spostrzerzenie po ponad dwóch latach używania dirpool: ODTWARZANIE JEST SZYBKIE. Piszę to dużymi literami, żeby miłośnicy Data Domainów tego nie przegapili :-P

Konfigurowanie połączenia DB2 na Windows z TSM

Jestem, że tak powiem, windowsowo niepełnosprawny, więc pewne rzeczy, które odkryłem, mogą być dla większości oczywiste :-)

Dokumentacja, na którą skieruje nas życzliwy wujek "g" jest, jak się okazuje, równie szowinistyczna względem łindołsów jak i ja. Niby w tytule jest "Linux, Unix and Windows", ale jakoś wszystkie przykłady mają w ścieżkach "/" a nie "\".

W skrócie wszystko wygląda dobrze:
Żeby podłączyć DB2 do TSM wystarczy instancji ustawić 3 zmienne środowiskowe:

• DSMI_DIR - wskazującą na katalog gdzie jest agent dsmtca.
• DSMI_CONFIG - pokazującą na plik "dsm.opt" jakiego DB2 ma użyć do połązczeń.
• DSMI_LOG - katalog, do którego ma zostać zapisany log dsierror.log. 

Jasne? Tak, ale.
Ale nr 1 - na Windows nie ma dsmtca. Na Unixach to narządko jest odpowiedzialne za odpalanie części klienta na prawach roota (ma suid). Na wiodącym systemie jest to załatwiane inaczej, dlatego na Windzie ta zmienna powinna po prostu wskazywać na katalog "baclient", czyli przeważnie c:\Program Files\Tivoli\TSM\baclient.
Ale nr 2 - Na Windows można ustawiać zmienne środowiskowe na dwa sposoby: Po bożemu: w skrypcie, albo jakoś dziwnie, klikając prawym klawiszem gryzonia na "My Computer" itd.. Oba sposoby działają... połowicznie. To znaczy da się to wszystko ustawić, ale działa tylko częściowo: daje się bazie ustawić hasło z jakim ma się zgłaszać do TSMa, ale sam backup i restore nie działają. I tu dochodzimy do...
... Ale nr 3 - Zmienne środowiskowe dla instancji bazy DB2 należy ustawiać w jej własnym rejestrze zmiennych, którym manipuluje się poleceniem db2set. Ale (nr 4) nie bezpośrednio. Otóż przy pomocy zmiennej DB2_VENDOR_INI, ustawianej tymże narzędziem, wskazuje się plik, w którym ustawia się zmienne DSMI_*. To "Ale nr 4" to już moja złośliwość, bo to tak naprawdę fanaberia DB2 a nie systemu, bo na Unixach jest tak samo. To tyle komentarzy, poniżej zawarłem zatem nieco uściślony algorytm konfigurowania styku DB2 i TSM.

Ustawienia DB2

1. Stworzyć plik c:\db2tsm\db2tsm.env (nazwa i lokalizacja dowolna, liczy się treść) i umieścić w nim zmienne środowiskowe potrzebne do znalezienia TSMa przez DB2:

DSMI_DIR=c:\Program Files\Tivoli\TSM\baclient

DSMI_CONFIG=c:\db2tsm\db2-dsm.opt

DSMI_LOGS=c:\tsmlogs

Tak na prawdę to pliki db2-dsm.opt może leżeć gdzie się chce i nazywać się może dowolnie. Ważne, żeby istniał :-P i miał sensowną treść, o czym później.

Poleceniem db2set ustawić zmienną DB2_VENDOR_INI:

1. Uruchomić "Narzędzia wiersza poleceń" gdzieś z menu Start->DB2-> bla ->bla ->bla. Pewnie wybrać opcję "Jako administrator".
2. Sprawdzić ile mamy instancji, bo może być więcej.

db2ilist

3. Dla każdej instaencji, która ma mieć kontakt z TSM ustawić DB2_VENDOR_INI. UWAGA: Najprawdopodobniej, każdej instancji trzeba będzie ustawić inny plik  *.opt!

db2set -i INSTANCJA DB2_VENDOR_INI=c:\db2tsm\db2tsm.env

4. Zatrzymać i wystartować database managera (każda instancja ma własnego), dlatego jesli nie pracujesz z jedyną/domyślną/porządaną to najpier wybierz, ustawiając zmienną DB2INSTANCE:

set DB2INSTANCE=INSTANCJA   (to jest jedna z nazw zwróconych przez db2ilist)

a potem, restart instancji:

db2stop
db2start

A po stronie TSM...

TSM nie wymaga specjalnej gimnastyki. Należy tylko zarejestrować klienta dla każdej instancji DB2 jaką będziemy backupować, być może warto się tu zastanowić czy nie chcemy oddzielić klientów bazodanowych od plikowych, np inną domeną. Ja w przykładach posłuże się oddzielną domeną o odkrywczej i nieoczywistej nazwie DB2.

Drugą rzeczą do rozważenia, jest kwestia polityki backupu. TSM w tym wypadku jest zredukowany do roli worka na dane. Cała mądrość jest po stronie bazy, dlatego polityka bezpieczeństwa po stronie TSM może wyglądać na nieco ubogą.

1. Zarejestrować domenę na klientów DB2:

def dom DB2 descr="Bazy DB2"

2. Zdefiniować politykę backupową 

def pol db2 prod

def mgmt db2 prod db2_standard

def copyg db2 prod db2_stndard t=b dest=jakaś_pula vere=1 verd=0 rete=0 reto=0

assign defmgmt db2 prod db2_standard

3. Sprawdzić i zaktywoawać politykję:

val pol db2 prod (będzie marudzić na brak copy grupy archiwalnej, i pewnie na mig destination. te komunikaty można zignorować, ważne żeby powiedział że policy set prod jest ready for activation)

act pol db2 prod (znowu będzie marudzić. Olać).

4. Zarejestrować klienta naszej (naszych)  instancji:

reg node db2inst1 ibm123 dom=db2 backdel=y userid=none

Istotne jest tu, żeby pozwolić mu kasować swoje backupy. Każdy backup zrobiony przez DB2 będzie, z punktu widzenia TSMa, oddzielnym obiektem, dlatego nie ma wersjonowania, a co za tym idzie wygasania nadmiarowych wersji. To baza będzie odpowiedzialna za usuwanie nadmiarowych backupów. 

I jeszcze raz DB2

Teraz przyszedł czas na dokończenie konfigurowania DB2. 

1. Ustawić hasło API TSM:

dsmapipw   (zapyta o hasło, podać to z rejestracji noda, w przykładzie to ibm123)

Sprawdzić w activity logu TSMa, czy węzeł się podłączył. Jeśli nie to pewnie w %DSMI_LOG%\dsierror.log bedzie jakaś informacja o tym co się stało.

2. Zrobić jakiś prosty backup z DB2:

db2 backup db sample use tsm

db2 list history backup for db sample

Na koniec

To co napisałem, to wędka, a nie ryby. Pewnie powinienem o tym wspomnieć na początku :-P Zasadniczo to nic nie powinno się popsuć. Psucie zacznie się wtedy, gdy będziemy odtwarzać bazy, dlatego nie piszę o tym, tylko dosyłam do solidnego przeczytania ze zrozumieniem przynajmniej tego rozdziału dokumentacji.

Zanim uznamy rozwiązanie za kompletne, wypadałoby się także pochylić nad następującą tematyką:

•  Przestawienie bazy w tryb logowania archiwalnego (domyślnie, logi są cykliczne, więc jedyny możliwy backup, to pełny, offline - nic ciekawego)
• Włączenie śledzenia zmodyfikowanych stron - umożliwia backupy typu delta.
• Ustawienie długości historii backupów.
• Ustawienie automatycznego kasowania backupów.
• Ustawienie ilości przechowywanych backupów.
• Wymyślenie metody archiwizacji i retencji logów bazy.