IBM IIC Magazine Q2 7/28/06 8:11 AM Page 1 IIC MAGAZINE. II kwartał 2006 nr 9

Transkrypt

1 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 1 IIC MAGAZINE II kwartał 2006 nr 9 Tivoli Storage Manager, TDP oraz LAN-free Bioinformatyka genom człowieka w bazie danych DB2 Nowinki technologiczne RFID Radio Frequency IDentification jako nośnik informacji w standardzie EPC (Elektroniczny Kod Produktu) Wysokodostępne DB2

2 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 2 OD REDAKCJI Drodzy Deweloperzy, po zimowym letargu wreszcie nadeszła pora na wiosenno-letnie przebudzenie. Drugi kwartał to wyjątkowo pracowity okres dla warszawskiego IBM Innovation Center. To czas intensywnych przygotowań do konferencji Developer Day oraz realizacji nowych przedsięwzięć. Takim przedsięwzięciem jest między innymi inicjatywa uruchomienia lokalnych Centrów Technologii IBM w siedzibach wybranych firm partnerskich, których zadaniem jest świadczenie szerokiego wachlarza bezpłatnych usług wsparcia technicznego dla lokalnych producentów oprogramowania, w tym zapewnienie dostępu do fizycznych i zdalnych zasobów sprzętowych IBM oraz specjalistycznych szkoleń. Z uwagi na zbieżne cele i założenia programowe IBM Innovation Center sprawuje patronat nad nowymi ośrodkami, które na przełomie maja i czerwca zostały otwarte w Żywcu (Infonet Projekt Sp. z o.o.), Wrocławiu (Jantar Sp. z o.o.) oraz Warszawie (K3Serwis Sp. z o.o.). Jestem przekonana, że zainteresuje Was oferta centrów. Dzięki niej macie szanse sprawniej, łatwiej i taniej realizować bieżące projekty dla klienta końcowego oraz poznawać nowe technologie. Mam również dobre wieści dla wszystkich tych, którzy z różnych przyczyn nie mogli wziąć udziału w naszej sztandarowej konferencji IBM Developer Day (uwaga kolejna już w listopadzie). Otóż najważniejsze tematy, które były przedmiotem sesji edukacyjnych, zawarliśmy w aktualnym numerze kwartalnika. Znacznik RFID SPIS TREŚCI O zagadnieniach związanych z konfiguracją IBM Tivoli Storage Manager oraz Tivoli Data Protection na przykładzie TDP dla DB2 przeczytacie w artykule Igora Zacharjasza i Pawła Krawczyka Tivoli Storage Manager, TDP oraz LANFree. Artur Górnik (IBM Software Group) występujący po raz pierwszy na naszych łamach wprowadzi Was w fascynujący świat bioinformatyki, nawiązując do The Genographic Project realizowanego pod auspicjami IBM, oraz wyjaśni, jak utworzyć bazę danych DB2 z kompletnym genomem człowieka. Wszystkich, którzy jeszcze nie wiedzą, że jest już dostępna nowa wersja IBM DB2 9, zwana groźnie Viper, w której zastosowano hierarchiczny silnik purexml do obsługi danych XML, odsyłam do lektury Nowinek technologicznych. Zachęcam również do odwiedzenia rubryki Z perspektywy Partnera Handlowego, w której o tajemnicach rewolucyjnej technologii RFID opowie Tomasz Pisarek szef działu oprogramowania firmy Jantar. Na zakończenie w artykule Wysokodostępne DB2 Maciej Przepiórka posłuży się przykładem implementacji DB2 HADR w środowisku AIX i przedstawi, w jaki sposób osiągnąć wysoką dostępność danych znajdujących się w bazie. 3 TIVOLI STORAGE MANAGER, TDP ORAZ LAN-free 10 BIOINFORMATYKA GENOM CZŁOWIEKA W BAZIE DANYCH DB2 13 NOWINKI TECHNOLOGICZNE 14 RFID RADIO FREQUENCY IDENTIFICATION JAKO NOŚNIK INFORMACJI W STANDARDZIE EPC (ELEKTRONICZNY KOD PRODUKTU) 16 WYSOKODOSTĘPNE DB2 Jak zawsze czekam również na Wasze artykuły i informacje do rubryki Nowinki Technologiczne. Najciekawsze z nich mają szansę ukazania się już w kolejnym numerze IIC Magazine. Jeżeli chcielibyście podzielić się z nami swoimi uwagami lub komentarzami na temat aktualnego wydania magazynu, piszcie do nas. Aneta Dąbrowska Redaktor prowadząca iic_warsaw@pl.ibm.com Okładka: Fot. Maciej Przepiórka

3 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 3 PAWEŁ KRAWCZYK, IGOR ZACHARJASZ Tivoli Storage Manager, TDP oraz LAN-free Poniższy artykuł przedstawia najważniejsze zagadnienia konfiguracyjne Tivoli Storage Managera oraz opisuje Tivoli Data Protection na przykładzie TDP dla DB2. W artykule tym opisaliśmy również konfigurację TSM-a w modelu LANFree. TSM wstępna konfiguracja W systemie operacyjnym AIX instalacja serwera TSM odbywa się poprzez zaznaczenie z poziomu SMIT-a odpowiednich pakietów. W spakowanym archiwum znajdują się dwie wersje serwera TSM (32 i 64 bit). Ważne jest, żeby przy instalacji nie wymieszać pakietów 32-bitowych z 64-bitowymi, ponieważ instalacja zakończy się w takim przypadku niepowodzeniem. Zarządzenie TSM-em może odbywać się za pomocą interfejsów zarówno graficznych, jak i tekstowych. Dostępne interfejsy to: Administration Center jest to graficzne narzędzie umożliwiające kompleksowe zarządzenie z jednego miejsca całą farmą serwerów TSM-a. IBM Tivoli Storage Management Console graficzna konsola serwera dostępna tylko w wersji serwera TSM dla platformy Windows. Klient Backup-Archive (GUI, z poziomu przeglądarki oraz tekstowy) są to programy instalowane na klientach servera TSM. Tekstowa konsola serwera TSM W poniższym artykule przy konfigurowaniu oraz użytkowaniu serwera TSM będziemy posługiwać się konsolą tekstową. W AIX-ie serwer TSM-a instaluje się domyślnie w katalogu /usr/tivoli/tsm/server/bin. Start servera TSM sprowadza się do uruchomienia pliku dsmserv: [root@partycja1 /]# cd /usr/tivoli/tsm/server/bin [root@partycja1 /]#./dsmserv Następnym krokiem będzie sprawdzenie informacji o zarejestrowanych licencjach TSM-a oraz w razie konieczności zarejestrowanie nowej licencji. TSM:P5TSM> query license ANR2017I Administrator SERVER_CONSOLE issued command: QUERY LICENSE Number of TDP for SAP R/3 in use: 0 Number of TDP for SAP R/3 in try buy mode: 0 Number of TDP for ESS in use: 0 Number of TDP for ESS in try buy mode: 0 Number of TDP for ESS R/3 in use: 0 Number of TDP for ESS R/3 in try buy mode: 0 Number of TDP for EMC Symmetrix in use: 0 Number of TDP for EMC Symmetrix in try buy mode: 0 Number of TDP for EMC Symmetrix R/3 in use: 0 Number of TDP for EMC Symmetrix R/3 in try buy mode: 0 Number of TDP for WAS in use: 0 Number of TDP for WAS in try buy mode: 0 Is IBM System Storage Archive Manager in use?: No Is IBM System Storage Archive Manager licensed?: No Is Tivoli Storage Manager Basic Edition in use: No Is Tivoli Storage Manager Basic Edition licensed: No Is Tivoli Storage Manager Extended Edition in use: No Is Tivoli Storage Manager Extended Edition licensed: No Server License Compliance: Not Valid TSM:P5TSM> register license file=tsmee.lic W tym miejscu możemy przystąpić do właściwej konfiguracji serwera TSM, czyli na początek do konfiguracji biblioteki taśmowej (hierarchia składowania), a potem do konfiguracji policy management. Aby TSM mógł współpracować z dowolnymi bibliotekami taśmowymi (niezależnie od producenta, modelu czy funkcjonalności), konieczne było wprowadzenie warstwy logicznej, przez którą TSM widzi i obsługuje bibliotekę taśmową. Wspomniana warstwa logiczna jest reprezentacją fizycznego urządzenia (biblioteki) w TSM-ie. Last License Audit: 06/07/06 00:13:28 Number of TDP for Oracle in use: 0 Number of TDP for Oracle in try buy mode: 0 Number of TDP for MS SQL Server in use: 0 Number of TDP for MS SQL Server in try buy mode: 0 Number of TDP for MS Exchange in use: 0 Number of TDP for MS Exchange in try buy mode: 0 Number of TDP for Lotus Notes in use: 0 Number of TDP for Lotus Notes in try buy mode: 0 Number of TDP for Lotus Domino in use: 0 Number of TDP for Lotus Domino in try buy mode: 0 Number of TDP for Informix in use: 0 Number of TDP for Informix in try buy mode: 0 Rys. 1 Mapowanie warstwy fizycznej na logiczną 3

4 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 4 IIC MAGAZINE II kwartał 2006 (9) Na rysunku 1 widzimy mapowanie dwóch klas logicznych urządzeń {o dostępie swobodnym (plik) i o dostępie sekwencyjnym (biblioteka taśmowa)} na urządzenia fizyczne. Dla celów poniższego artykułu pokażemy jak skonfigurować w TSM-ie bibliotekę taśmową LTO Taka biblioteka taśmowa posiada dwa napędy oraz zmieniarkę taśm. W systemie operacyjnym AIX zobaczymy następujące pliki, reprezentujące bibliotekę: /dev/rmt0 i /dev/rmt1 pliki reprezentujące napędy; /dev/smt0 i /dev/smt1 pliki reprezentujące zmieniarkę (changer). W tym miejscu warto zatrzymać się na chwilę, aby wyjaśnić podstawowe pojęcia, którymi będziemy posługiwać się, mówiąc o hierarchii składowania. Dane, które klient archiwizuje za pomocą serwera TSM, składowane są w Storage Pools. Storage Pool należy utożsamiać z kontenerem, do którego przypisujemy wolumeny (volumes). Rozmiar miejsca na archiwa i kopie danych, czyli rozmiar jednego storage pool jest sumą wszystkich wolumenów, które przypisane są do tego Storage Pool. Konfiguracja biblioteki z poziomu TSM wymaga stworzenia logicznego urządzenia reprezentującego bibliotekę (library) oraz zdefiniowanie od niego ścieżki (path) do urządzenia fizycznego. W dalszej części artykułu opiszemy model LANFree, który wymaga, aby biblioteka została zdefiniowana jako shared. TSM:P5TSM> define library mylib libtype=scsi shared=yes TSM:P5TSM> define path p5tsm mylib srctype=server desttype=library device=/dev/smc0 Następnie należy zdefiniować tyle napędów, ile ma nasza biblioteka, i do każdego z napędów podać ścieżkę do urządzenia fizycznego. W naszym przypadku wygląda to następująco: TSM:P5TSM> define drive mylib myfdrive TSM:P5TSM> define path p5tsm myfdrive srctype=server desttype=drive library=mylib device=/dev/rmt0 TSM:P5TSM> define drive mylib mysdrive TSM:P5TSM> define path p5tsm mysdrive srctype=server desttype=drive library=mylib device=/dev/rmt1 Kolejnym krokiem będzie wytworzenie w przestrzeni konfiguracyjnej TSM-a device class. Device Class reprezentuje grupę urządzeń o podobnej dostępności, wydajności oraz sposobie składowania danych (takie same media np. taśmy LTO2) TSM:P5TSM> define devclass ltoclass library=mylib devtype=lto Teraz możemy przystąpić już do załadowania taśm do naszej biblioteki oraz do rozpoznania ich (etykietowania) z poziomu TSM. TSM:P5TSM> label libvolume mylib search=yes labelsource=barcode checkin=scratch overwrite=yes Powyższa komenda spowoduje, że TSM rozpozna taśmy włożone do magazynków biblioteki, nazwie je zgodnie z naklejonymi kodami paskowymi oraz doda je do puli taśm pustych. W przypadku, gdy na taśmach znajdują się jakieś dane, opcja overwrite=yes spowoduje nadpisanie ich zawartości. Rozpoznane i zaetykietowane taśmy możemy wylistować komendą query libvol. Wynik takiego polecenia może wyglądać tak: TSM:P5TSM> q libvol ANR2017I Administrator SERVER_CONSOLE issued command: QUERY LIBVOL Library Name Volume Name Status Owner Last Use Home Device Element Type MYLIB 121AHS Scratch 4,098 LTO MYLIB 129AHS Scratch 4,099 LTO MYLIB 130AHS Scratch 4,097 LTO MYLIB 137AHS Scratch 4,101 LTO MYLIB 150AHS Scratch 4,096 LTO MYLIB 151AHS Scratch 4,100 LTO Zobrazujmy to na przykładzie: Storage Pool o nazwie backuppool i typie disk będzie miało w naszym przypadku rozmiar 208MB, ponieważ składa się z dwóch wolumenów (jeden o rozmiarze 200MB, a drugi o rozmiarze 8MB): TSM:P5TSM> q stgpool backuppool ANR2017I Administrator SERVER_CONSOLE issued command: QUERY STGPOOL backuppool Storage Device Estimated Pct Pct High Low Next Pool Name Class Name Capacity Util Migr Mig Mig Storage Pct Pct Pool BACKUPPOOL DISK M TSM:P5TSM> q vol stgpool=backuppool ANR2017I Administrator SERVER_CONSOLE issued command: QUERY VOLUME stgpool=backuppool Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status /usr/tivoli/tsm/server/ BACKUPPOOL DISK On-Line bin/backup.dsm /usr/tivoli/tsm/server/ BACKUPPOOL DISK On-Line bin/nowy.dsm W przypadku Storage Pools realizowanych na napędach taśmowych ich wielkość będzie równa ilości taśm przypisanych do tej Storage Pool x wielkość pojedynczej taśmy. Wynik polecenia q vol może wyglądać następująco: TSM:P5TSM> q vol stgpool=test ANR2017I Administrator SERVER_CONSOLE issued command: QUERY VOLUME stgpool=ltopool Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status FDS test klasatestowa 381, Filling Pomiędzy zdefiniowanymi Storage Pools można utworzyć hierarchię. Wraz z rosnącą ilością danych przechowywanych w TSM-ie, nasz Storage Pool będzie się powoli wypełniać. Możemy więc zdefiniować kolejny Storage Pool, na który będą migrowane dane po osiągnięciu określonego poziomu wypełnienia. I tak może powstać np. taka hierarchia: 4

5 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 5 TIVOLI STORAGE MANAGER, TDP ORAZ LAN-free Rys. 2 Hierarchia Storage Pools Storage Pool SP_A po osiągnięciu odpowiedniego poziomu wypełnienia będzie migrował dane na SP_B, a ta z kolei na SP_C. Z kolei SP_D (na który zrzucają dane inni klienci) będzie migrował od razu na SP_C. Wracając do naszej konfiguracji teraz należy wytworzyć Storage Pool, którym będziemy posługiwać się w dalszych rozważaniach. Do tego celu należy użyć komendy define stgpool: TSM:P5TSM> define stgpool ltopool ltoclass maxscr=3 W przypadku Storage Pool opartych o bibliotekę taśmową (dostęp sekwencyjny) nie trzeba jawnie dodawać wolumenów, ponieważ parametr max scratch (maxscr) definiuje, ile maksymalnie taśm może mieć Storage Pool. Taśmy zostaną automatycznie dodane do Storage Pool, jak tylko zajdzie taka potrzeba, czyli przy pierwszym bakcupie oraz w momencie gdy będzie się kończyło miejsce na kolejnych taśmach. Tylko taśmy ze statusem=scratch (puste lub ze starymi i niepotrzebnymi danymi), będą dodawane do Storage Pool. Teraz przejdziemy do konfiguracji policy management. Policy management, czyli zarządzanie politykami backupu to miejsce, w którym dokonamy w TSM-ie implementacji potrzeb biznesowych Domena zabezpieczenia danych. Innymi słowy, dzięki policy management Aktywny Policy Set możemy dla każdego typu naszych klientów utworzyć inny model Management Class przechowywania danych. Dzięki temu nasze serwery produkcyjne z Backup ważnymi aplikacjami mogą Copy Group przechowywać swoje dane w sposób inny niż dział księgowości czy klienci mobilni (np. sprzedawcy używający laptopów). Archive Copy Group Daje nam to sporą elastyczność konfiguracji serwerów TSM w naszej organizacji. Rys. 3 Policy Management Dla każdego z typów klientów możemy w przestrzeni konfiguracyjnej TSM-a wytworzyć oddzielną domenę. Domena jest zbiorem zarejestrowanych w niej klientów (nodów) oraz grupuje zbiór polityk backupów. W skład domeny wchodzi jeden lub wiele Policy Setów. Jeden z Policy Setów zawsze będzie aktywny. Policy Set z kolei grupuje Management Classy. Management Class może być również kilka, ale tylko jedna z nich będzie tzw. domyślną. Domyślna mgmt class to taka, do której klient będzie wysyłał swoje dane, jeżeli nie poda w sposób jawny innej mgmt classy. Mgmt classa jest zbiorem jednej lub maksymalnie dwóch copy group (jeżeli są dwie, to jedna zawsze będzie typu backup, a druga typu archive). Copy groupy są najmniejszym ziarnem management policy, a co za tym idzie definiują sposób przechowywania danych najbardziej szczegółowo i to właśnie najczęściej im poświęca się przy definiowaniu najwięcej czasu. Copy groupy zawierają, miedzy innymi parametry dotyczące tworzenia kopii zapasowych, ilości przechowywanych wersji pojedynczego pliku oraz terminy ważności poszczególnych wersji i reguły ich wygasania. Poniżej znajdują się przykładowe parametry copy group: DESTination=poolname nazwa Storage Pool, w której przechowywane będą dane; VERExists=verevalue ilość pamiętanych wersji pliku, które będą przechowywane; RETExtra=retevalue ilość dni, po których nieaktywna kopia pliku zostanie usunięta z systemu; VERDeleted=verdvalue maksymalna ilość zachowanych kopii dla plików, które zostały usunięte z systemu plików klienta; Type=Backup/Archive typ Copy groupy. W tym miejscu rozpoczniemy konfigurację policy management, która posłuży nam w dalszej części artykułu. Zaczniemy od zdefiniowania domeny: TSM:P5TSM> define domain pksandom descr= domena do tdp i lan free Następnie należy w obrębie utworzonej przed chwilą domeny stworzyć policy set: TSM:P5TSM> define policyset pksandom pksanpol Kolejnym krokiem będzie wytworzenie management classy: TSM:P5TSM> define mgmtclass pksandom pksanpol pksanmg Teraz w obrębie mgmt classy wytworzymy copy group typu backup i wskażemy miejsce (Storage Pool), na które będą zrzucane dane podczas procesu zachowywania danych. Na tym etapie następuje połączenie zdefiniowanego wcześniej miejsca do przetrzymywania danych (storage pool) z policy management: TSM:P5TSM> define copy pksandom pksanpol pksanmg type=backup dest=ltopool W tym momencie zakończyliśmy konfigurowanie policy management. Ostatnie trzy kroki, które należy jeszcze wykonać, to: Przypisanie zdefiniowanej wcześniej mgmt classy jako domyślnej: TSM:P5TSM> assign defmgmtclass pksandom pksanpol pksanmg ANR2017I Administrator SERVER_CONSOLE issued command: ASSIGN DEFMGMTCLASS pksandom pksanpol pksanmg ANR1538I Default management class set to PKSANMG for policy domain PKSANDOM, set PKSANPOL. Następnie sprawdzamy poprawność konfiguracji naszego policy setu: TSM:P5TSM> validate policyset pksandom pksanpol ANR2017I Administrator SERVER_CONSOLE issued command: VALIDATE POLICYSET pksandom pksanpol ANR1515I Policy set PKSANPOL validated in domain PKSANDOM (ready for activation). 5

6 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 6 IIC MAGAZINE II kwartał 2006 (9) Ostatnie rzecz to aktywacja przygotowanego policy setu: TSM:P5TSM> activate policyset pksandom pksanpol Teraz można już przejść do integracji TSM-a z bazą danych DB2 oraz do konfiguracji modelu LANFree. Integracja TSM z DB2 Produkty IBM w zakresie integracji TSM-a z bazami danych nazywamy Tivoli Storage Manager for Databases. W wypadku DB2 ta funkcjonalność jest wbudowana w bazę danych. W momencie tworzenia instancji bazy, polecenie db2icrt tworzy podkatalog adsm, w którym znajduje się biblioteka libtsm.a. To dzięki tej bibliotece DB2 komunikuje się z TSM-em a dokładnie z API klienta TSM. W systemie operacyjnym AIX 5.3 instalacja API TSM odbywa się poprzez rozpakowanie źródeł klienta TSM i zaznaczenie odpowiednich pakietów do instalacji. Poniżej mamy przykład zainstalowanych potrzebnych pakietów. W tym wypadku możemy wybrać tak 32-, jak i 64-bitowe wersje oprogramowania w odróżnieniu do instalacji serwera TSM, gdzie musimy się zdecydować, której wersji będziemy używać. tivoli.tsm.client.api.32bit TSM Client - Application Programming Interface 32bit tivoli.tsm.client.api.64bit TSM Client - 64bit Application Programming Interface Po zainstalowaniu pakietów musimy jeszcze ustawić zmienne środowiskowe, aby zapewnić komunikację pomiędzy instancją bazy danych a serwerem TSM. API TSM-a posługuje się następującymi wartościami: DSMI_DIR to zmienna środowiskowa wskazująca, gdzie leży dsmtca (TSM Trusted Client Agent); DSMI_CONFIG zmienna wskazująca na plik konfiguracyjny klienta TSM. W tym pliku będzie zawarta nazwa serwera TSM, do którego będą wysyłane kopie bezpieczeństwa; DSMI_LOG ścieżka do katalogu, w którym będzie utworzony plik dsierror.log zawierający ewentualne błędy. Nasze zmienne środowiskowe wpisujemy do pliku /home/db2inst1/.profile, aby przy następnych wywołaniach kontekstu właściciela instancji zmienne środowiskowe były automatycznie ustawiane. Oto przykład tych zmiennych z naszego pliku: export DSMI_DIR=/usr/tivoli/tsm/client/api/bin export DSMI_CONFIG=/home/db2inst1/tsm/dsm.opt export DSMI_LOG=/home/db2inst1/tsm W pliku /home/db2inst1/tsm/dsm.opt wskazaliśmy nazwę serwera, którego użyjemy podczas backupów, dlatego musi istnieć definicja tego serwera w pliku konfiguracyjnym klienta TSM na poziomie systemu. Taka definicja serwera znajduje się w pliku dsm.sys. Jego domyślną lokalizacją dla pakietu TSM API jest katalog /usr/tivoli/tsm/client/api/bin. Oto listing naszego pliku dsm.sys SErvername p5tsm COMMMethod TCPip TCPPort 1500 TCPServeraddress passwordaccess nodename generate db2 Serwer TSM jest pod adresem TCPServeraddress i słucha na porcie TCPPort. Komunikujemy się z nim za pomocą protokołu COMMMethod. Parametr passwordaccess ustawiliśmy na wartość generate, co spowodowało zachowanie hasła w pliku po stronie klienta. W ten sposób nie będzie ono już wysyłane przy każdej próbie komunikacji klienta z serwerem. Ostatnia czynność, jaka pozostała przed testami naszego środowiska, to ustanowienie hasła dostępu do serwera TSM. Po stronie serwera TSM zakładamy użytkownika o nazwie DB2 komendą register node. Po stronie klienta TSM, czyli po stronie serwera bazy danych logujemy się jako root i wywołujemy program dsmapipw z argumentem password. Program ten służy do zmiany hasła na serwerze TSM oraz zachowania tego samego hasła po stronie klienta TSM w pliku /etc/security/adsm/tsm.pwd. Zwracamy uwagę na sposób zalogowania się jako root. Ponieważ zmienne środowiskowe są ustawiane w profilu właściciela instancji DB2, to naszą zalecaną metodą jest: [root@partycja1 /]# su - db2inst1 $ set grep DSMI DSMI_CONFIG=/home/db2inst1/tsm/dsm.opt DSMI_DIR=/usr/tivoli/tsm/client/api/bin DSMI_LOG=/home/db2inst1/tsm _=DSMI_LOG=/home/db2inst1/tsm $ su root s Password: # whoami root # set grep DSMI DSMI_CONFIG=/home/db2inst1/tsm/dsm.opt DSMI_DIR=/usr/tivoli/tsm/client/api/bin DSMI_LOG=/home/db2inst1/tsm # cd sqllib/adsm #./dsmapipw password ************************************************************* * Tivoli Storage Manager * * API Version = * ************************************************************* Enter your current password: Enter your new password: Enter your new password again: Your new password has been accepted and updated. # Po stronie serwera obserwujmy połączenia w przypadku konsoli TSM będziemy widzieli połączenie pochodzące z serwera bazy danych. TSM:P5TSM> ANR0406I Session 6 started for node DB2 (AIX) (Tcp/Ip (34190)). ANR0403I Session 6 ended for node DB2 (AIX). Backup or Archive Serwer TSM składuje dane klienta jako backup lub archive. To klient TSM decyduje, w jakiego rodzaju będą to obiekty po stronie serwera. Produkty Tivoli Data Protection składują dane po stronie serwera w postaci zależnej od zabezpieczanego programu. W wypadku DB2 Tivoli Storage Manager składuje backupy bazy danych i przestrzeni tabel jako obiekty backupu, a logi transakcyjne jako archiwa. Wykonajmy backup naszej bazy danych o nazwie sample. Posłuży do tego komenda: [db2inst1@partycja1 ~]$ db2 backup db sample use tsm Po prawidłowym wykonaniu się backupu powinniśmy zobaczyć następujący komunikat po stronie serwera bazy danych: Backup successful. The timestamp for this backup image is :

7 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 7 TIVOLI STORAGE MANAGER, TDP ORAZ LAN-free Jak wyświetlić obiekty wysłane do serwera TSM z poziomu samego serwera? Ponieważ TSM udostępnia nam interfejs SQL do jego wewnętrznych struktur danych, to wykorzystamy tę metodę. tsm: P5TSM>select * from backups ANR2963W This SQL query may produce a very large result table, or may require a significant amount of time to compute. Do you wish to proceed? (Yes (Y)/No (N)) y NODE_NAME: DB2 FILESPACE_NAME: /SAMPLE FILESPACE_ID: 2 STATE: ACTIVE_VERSION TYPE: FILE HL_NAME: /NODE0000/ LL_NAME: FULL_BACKUP OBJECT_ID: 6145 BACKUP_DATE: :16: DEACTIVATE_DATE: OWNER: db2inst1 CLASS_NAME: DEFAULT tsm: P5TSM> Wynik tego zapytania jest właściwie oczywisty. Zwróćmy uwagę jedynie na pole LL_NAME to składowa nazwy obiektu składowanego w przestrzeni TSM i zawiera nazwę obrazu backupu bazy danych. Narzędzie administracyjne Podstawowym narzędziem administratora bazy danych odpowiedzialnego za backupy bazy jest program db2adutl. Możemy go zlokalizować w podkatalogu właściciela instancji bazy sqllib/adsm. Program ten umożliwia nam zarządzanie kopiami bezpieczeństwa znajdującymi się po stronie serwera TSM. Ponieważ nazwy obrazów bazy danych są zawsze unikalne, to TSM serwer nigdy nie będzie kasował tych obiektów te obiekty są aktywnym kopiami. Do administratora bazy danych należy obowiązek decydowania o kasowaniu niepotrzebnych kopii zapasowych. LAN-free Ponieważ backupy baz danych są zazwyczaj dużymi obiektami, to warto przyjrzeć się konfiguracji LAN-free naszego środowiska TSM. W tej konfiguracji klient TSM, jakim jest API, wysyła żądanie operacji do serwera TSM za pośrednictwem tak zwanego storage agenta. Jest to dodatkowy produkt TSM, instalowany zazwyczaj na tym samym systemie operacyjnym, na jakim klient. Zadaniem storage agenta jest zarządzanie mediami w sieci SAN dla potrzeb TSM klienta. Wysyłanie danych bezpośrednio do biblioteki taśmowej powoduje odciążenie serwera TSM, jak również redukuje poziom ruchu w sieci LAN. Nie zawsze backup LAN-free jest szybszy od backupu po ethernecie. Wynika to z tego, że agregowany czas backupu może być dłuższy, gdyż agent może czekać na wolny napęd. Typowy scenariusz backupu LAN-free wygląda następująco: 2. Storage agent odbiera dane od klienta i wysyła do managera biblioteki taśmowej żądanie montowania odpowiedniego wolumenu. W naszym wypadku managerem biblioteki taśmowej jest ten sam serwer TSM. 3. Manager biblioteki taśmowej wysyła rozkaz montowania wolumenu w odpowiednim napędzie. 4. Manager biblioteki taśmowej powiadamia storage agenta o miejscu, gdzie zamontował dla niego wolumen 5. Klient za pośrednictwem storage agenta zapisuje dane bezpośrednio do urządzenia przyłączonego do sieci SAN 6. Storage agent wysyła metadane do TSM serwera, a ten zapisuje je w swojej wewnętrznej bazie Co musimy zmodyfikować w dotychczasowej naszej konfiguracji? Po zainstalowaniu Storage Agent for AIX 5.3 modyfikujemy nasz plik dsm.sys, gdzie leży definicja serwera TSM dla API klient TSM. Dodajemy następujące wpisy: enablelanfree yes lanfreecommmethod tcpip lanfreetcpserveraddress lanfreetcpport 1500 Parametry zaczynające się od lan wskazują nam, jaka będzie komunikacja klienta ze Storage Agentem. Storage agent swoją konfigurację utrzymuje w pliku /usr/tivoli/tsm/storageagent/bin/dsmsta.opt. Tu zmodyfikowaliśmy parametr DEVCONFIG devconfig.txt. Od tej pory nasza konfiguracja urządzeń po stronie storage agenta będzie zapisywana w powyższym pliku. Poniższa komenda zapisuje taką właśnie konfigurację do pliku devconfig.txt [root@partycja1 /]# dsmsta setstorageserver myname=pksta mypassword=password myhladdress= servername=p5tsm serverpassword=password hladdress= lladdress=1500 Nadaliśmy w ten sposób nazwę agentowi, wskazaliśmy jego adres i port oraz podaliśmy informacje o serwerze docelowym TSM. Po stronie serwera TSM należy przejść następujące kroki: TSM:P5TSM> set servername p5tsm TSM:P5TSM> set serverpassword password TSM:P5TSM> set serverhladdress TSM:P5TSM> set serverlladdress 1500 To była konfiguracja parametrów serwera TSM, a poniżej przedstawiamy sposób na zdefiniowanie storage agenta w przestrzeni serwera TSM. TSM:P5TSM> define server pksta serverpassword=password hladdress= lladdress=1500 Teraz zweryfikujmy, czy w systemach operacyjnych, na których rezydują zarówno TSM serwer, jak i Storage Agent, widoczne są urządzenia podłączone do sieci SAN. 1. Klient rozpoczyna operację backupu. Serwer zwraca klientowi politykę backupu włącznie z informacją, czy docelowym miejscem backupu może być LAN-free storage pool. Po stronie serwera TSM muszą być zdefiniowane ścieżki od storage agenta do biblioteki taśmowej. Po stronie Storage Agenta: [root@partycja1 /]# lsdev -Cc tape rmt0 Available IBM 3580 Ultrium Tape Drive (FCP) rmt1 Available ,0 SCSI 4mm Tape Drive 7

8 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 8 IIC MAGAZINE II kwartał 2006 (9) rmt2 Available IBM 3580 Ultrium Tape Drive (FCP) smc0 Available IBM 3582 Library Medium Changer (FCP) smc1 Available IBM 3582 Library Medium Changer (FCP) [root@partycja1 /]# Po stronie TSM serwera: [root@p550tsm /]# lsdev -Cc tape rmt0 Available IBM 3580 Ultrium Tape Drive (FCP) rmt1 Available IBM 3580 Ultrium Tape Drive (FCP) smc0 Available IBM 3582 Library Medium Changer (FCP) smc1 Available IBM 3582 Library Medium Changer (FCP) [root@p550tsm /]# Ponieważ mamy inny zestaw urządzeń na każdym z tych systemów, to upewnijmy się, które nazwy urządzeń odnoszą się do których fizycznych napędów w bibliotece taśmowej. Oto sposób: [root@p550tsm /]# lscfg -vl rmt0 rmt0 U7311.D A-P1-C02-T1-W500308C13E L0 IBM 3580 Ultrium Tape Drive (FCP) Manufacturer IBM Machine Type and Model ULT3580-TD2 Serial Number Device Specific.(FW) 35N2 [root@partycja1 /]# lscfg -vl rmt2 rmt2 U7311.D AAA-P1-C02-T1-W500308C13E L0 IBM 3580 Ultrium Tape Drive (FCP) Manufacturer IBM Machine Type and Model ULT3580-TD2 Serial Number Device Specific.(FW) 35N2 [root@partycja1 /]# Mając te informacje, możemy teraz zdefiniować nasze ścieżki z poziomu serwera TSM. Po definicji uzyskujemy taką sytuację w konfiguracji serwera TSM: TSM:P5TSM> q path f=d ANR2017I Administrator SERVER_CONSOLE issued command: QUERY PATH f=d SourceName SourceType Destname DestType Library Node Name Device P5TSM SERVER MYLIB LIBRARY /dev/smc0 P5TSM SERVER MYFDRIVE DRIVE MYLIB /dev/rmt0 P5TSM SERVER MYSDRIVE DRIVE MYLIB /dev/rmt1 PKSTA SERVER MYFDRIVE DRIVE MYLIB /dev/rmt2 PKSTA SERVER MYSDRIVE DRIVE MYLIB /dev/rmt0 TSM:P5TSM> Wynik powyższej komendy zmodyfikowaliśmy na potrzeby poprawnego formatowania. Utworzyliśmy oddzielną policy domain dla węzłów, które będą uczestniczyły w back- /upach typu LAN-free. Dla copy group w tej domenie ustawiliśmy parametr destination na storage pool, którą obsługuje urządzenie SAN. Teraz uruchamiamy storage agenta. [root@partycja1 /usr/tivoli/tsm/storageagent/bin]#./dsmsta... ANR0916I TIVOLI STORAGE MANAGER distributed by Tivoli is now ready for use. Wynik wywołania backupu bazy danych spowoduje podobne do poniższego zachowanie serwera TSM: TSM:P5TSM> ANR0406I Session 35 started for node DB2 (DB2/6000) (Tcp/Ip (34230)). ANR0408I Session 36 started for server PKSTA (AIX-RS/6000) (Tcp/Ip) for storage agent. ANR0415I Session 36 proxied by PKSTA started for node DB2. ANR0408I Session 37 started for server PKSTA (AIX-RS/6000) (Tcp/Ip) for library sharing. ANR0408I Session 38 started for server PKSTA (AIX-RS/6000) (Tcp/Ip) for library sharing. ANR0409I Session 37 ended for server PKSTA (AIX-RS/6000). ANR8337I LTO volume 137AHS mounted in drive MYSDRIVE (/dev/rmt1). ANR0409I Session 38 ended for server PKSTA (AIX-RS/6000). ANR0511I Session 36 opened output volume 137AHS. ANR0408I Session 39 started for server PKSTA (AIX-RS/6000) (Tcp/Ip) for library sharing. ANR0514I Session 36 closed volume 137AHS. ANR0409I Session 39 ended for server PKSTA (AIX-RS/6000). ANR0403I Session 35 ended for node DB2 (DB2/6000). ANR0408I Session 40 started for server PKSTA (AIX-RS/6000) (Tcp/Ip) for library sharing. ANR0409I Session 40 ended for server PKSTA (AIX-RS/6000). ANR0403I Session 36 ended for node DB2 (DB2/6000). Zwróćcie uwagę na linię 3 komunikatów. Dla klienta o nazwie DB2, storage agent o nazwie PKSTA wykonał połączenie do serwera. To jeden z dowodów, że tym razem nasz backup odbył się bezpośrednio po sieci SAN. Igor Zacharjasz w IBM Polska pracuje od 6 lat. Od 3 lat pełni funkcję koordynatora zespołu technicznego IBM Innovation Center. Jest certyfikowanym specjalistą w zakresie serwerów pseries i systemu operacyjnego AIX. Współpracuje z firmami partnerskimi o profilu ISV. W Centrum zajmuje się rozwiązaniami klastrowymi, testami wydajnościowymi aplikacji oraz rozwiązaniami IBM TotalStorage. Kontakt: igor.zacharjasz@pl.ibm.com Paweł Krawczyk jest projektantem wysokodostępnych systemów informatycznych. W IBM Innovation Center zajmuje się tematyką dotyczącą rozwiązań klastrowych i wydajnością systemów. Wspiera firmy partnerskie typu ISV w przeprowadzaniu testów na bazie różnych systemów operacyjnych. W swojej karierze zawodowej zajmował się również projektowaniem systemów hostingowych w firmach ISP. Kontakt: pawel.krawczyk@pl.ibm.com 8

9 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 9 _DZIENNIK ADMINA _DZIEŃ 8: Poddaję się. Cała ta nasza infrastruktura jest do bani. Aplikacje, procesy nic do siebie nie pasuje! Nie jesteśmy w stanie szybko reagować na zmiany. Wszystko wymyka się spod kontroli! Marek wpadł na genialny pomysł. Taśma klejąca! Zużył już parę rolek i ręcznie posklejał wszystko i wszystkich. Pełna integracja _DZIEŃ 10: Ta taśmą klejącą to można integrować, ale kartkę ze ścianą. O sklejaniu nieelastycznych aplikacji i procesów zapomnij. _DZIEŃ 13: Mam! Znalazłem coś lepszego: IBM WebSphere middleware. Poprawia elastyczność naszej infrastruktury, bezproblemowo integrując aplikacje. Możemy ot tak zmieniać procesy i używać tego, co już mamy nawet SAP a lub Oracle a. A jak do tego wszystkiego doda się jeszcze doświadczenie IBM i ich znajomość branż, jesteśmy na dobrej drodze, by tworzyć prawdziwe SOA. _Hmmmm. WebSphere. Mocniejsze od taśmy klejącej. IBM, logo IBM oraz WebSphere są zarejestrowanymi znakami towarowymi firmy International Business Machines Corporation w Stanach Zjednoczonych i/lub w innych krajach. SAP jest zarejstrowanym znakiem towarowym firmy SAP AG w Niemczech i w kilku innych krajach. Oracle jest zarejestrowanym znakiem towarowym firmy Oracle Corporation i/lub jego filii IBM Corp. Wszystkie prawa zastrzeżone.

10 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 10 Artur Górnik Bioinformatyka genom człowieka w bazie danych DB2 Zastosowania informatyki w genetyce, biologii molekularnej, medycynie i odkrywaniu leków w dziedzinach nauki zwanych zbiorczo z ang. life sciences są coraz liczniejsze i coraz bardziej powszechnie znane. Przykładami bioinformatyki (ang. bioinformatics) i biologii obliczeniowej (ang. computational biology) są projekty: The World Community Grid i The Genographic Project, w których IBM aktywnie uczestniczy poprzez pracę zespołów IBM Research (The Computational Biology Center) oraz dostarczając swoją technologię: sprzęt i oprogramowanie. Niniejszy artykuł przedstawia w dalszej części sposób tworzenia krok po kroku bazy danych DB2 zawierającej kompletny genom człowieka efekt blisko dziesięciu lat prac zespołu The International Human Genome Project. Zawiera również opis praktycznego wyszukania w stworzonej bazie danych DB2 przykładowego genu, którego definicja zostanie pobrana z niezależnych banków genów: Ensembl i GeneCards. Wybranym genem będzie gen białka P53, którego uszkodzenie prowadzi do choroby nowotworowej. Stworzona na podstawie niniejszego artykułu baza DB2 z wzorcem genomu człowieka zawiera ten sam rodzaj informacji, która jest używana w wielu projektach genetycznych i bioinformatycznych, m.in. we wspomnianym już Projekcie Genograficznym. Projekt Genograficzny Projekt Genograficzny to pięcioletnie badania ludzkich genów prowadzone przez Towarzystwo National Geographic we współpracy z IBM. Projekt pozwoli ustalić mapę wędrówek człowieka do 60 tysięcy lat wstecz i uzyskać odpowiedź na wiele fundamentalnych pytań. Skąd pochodzimy? Jak dotarliśmy do wielu zakątków świata? Jakimi drogami wędrowali nasi przodkowie? Dlaczego wyglądamy tak różnie? Projekt Genograficzny to największy na świecie zbiór próbek DNA, którego komputerowe analizy w ramach metodologii biologii obliczeniowej wykorzystują zaawansowaną technologię IBM, łączącą oprogramowanie DB2 z platformą sprzętową IBM eserver. Stworzony dzięki projektowi bank danych będzie jednym z największych zbiorów informacji genetycznych o człowieku: zasobem pomocnym genetykom, historykom i antropologom. Informacje genetyczne otrzymane za pomocą najnowocześniejszych technik laboratoryjnych i komputerowych analiz DNA pozwolą odtworzyć mimo fizycznych i geograficznych różnic historyczne ścieżki łączące współczesnych ludzi. Każda osoba, która zakupi przez Internet odpowiedni zestaw, zostaje uczestnikiem projektu. Po anonimowym i bezbolesnym przekazaniu próbki swojego DNA każdy uczestnik otrzymuje własny raport z dostępem do wyników grupy osób o tym samym haplotypie (tj. mających ten sam wzorzec markerów genetycznych) i na ich podstawie może dowiedzieć się więcej o swoich najodleglejszych przodkach i mapie ich wędrówek. Vademecum Ludzkie ciało zbudowane jest z około 600 miliardów komórek. Każda z nich zawiera przeciętnie kilka tysięcy białek, w tym wiele enzymów. Wszystkim zarządza informacja ukryta w DNA (kwas dezoksyrybonukleinowy). Cząsteczkę DNA tworzą dwa łańcuchy owinięte wokół siebie tak, że zasady azotowe znajdują się wewnątrz. Te cztery zasady azotowe: adenina, cytozyna, guanina i tymina, łączą się zawsze według schematu: A-T, C-G, G-C, T-A. Wystarczy znać kolejność zasad jednej tylko nici, aby odtworzyć podwójną helisę DNA. Dlatego w naszej bazie danych, zgodnie z powszechnym podejściem, przechowujemy strukturę de facto tylko jednej nici. DNA zawarte w jądrze ludzkiej komórki (ludzki genom) ma 1,5 metra długości. Ludzki genom to około 30 tysięcy genów. Geny jednostki dziedziczenia decydujące o przekazywaniu poszczególnych dziedzicznych właściwości organizmu ułożone są liniowo w ściśle określonej kolejności: są to odcinki DNA, w których sekwencja ułożenia zasad azotowych wzdłuż łańcuchów DNA stanowi informację genetyczną o zdolności do syntezy białek. Geny mieszczą się na chromosomach (stałych składnikach jąder komórkowych). Najcieńsze chromosomy mają grubość od 100 do 200 nm (1 nm = 0, mm). Z sekwencji DNA kodowane są białka. Ekspresja genów to proces prowadzący od genu zapisanego w DNA do kompletnie ukształtowanego, funkcjonalnego białka. Niektóre wariacje DNA nie mają negatywnych skutków. Inne prowadzą do chorób lub do zwiększonej podatności na choroby (np. nowotwór złośliwy płuc). Wariacja sekwencji DNA w genie może zmienić białko produkowane przez kod genetyczny. Projekt Genomu Człowieka Projekt poznania genomu człowieka jest gigantycznym programem biologicznym, porównywalnym pod względem kosztów i technologicznego rozmachu jedynie z wysłaniem astronautów na Księżyc. Pierwszy jego etap zakładał zlokalizowanie wszystkich ludzkich genów, w drugim zaś bada się ich funkcje. Projekt obliczany pierwotnie na 15 lat i mający kosztować 3 miliardy dolarów rozpoczął się w 1990 roku. W grudniu 1999 roku ustalono zawartość pierwszego ludzkiego chromosomu. Wszystkie ludzkie geny zlokalizowano w kwietniu 2003 roku. Ze strony: można pobrać 49 plików tekstowych z najnowszą wersję genomu człowieka, oznaczoną jako: Human Genome Mar (hg18). Powyższe dane pochodzą z projektu prowadzonego przez: Center for Biomolecular Science & Engineering, UCSC Genome Bioinformatics Group, University of California, Santa Cruz, USA. 10

11 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 11 Bioinformatyka genom człowieka w bazie danych DB2 Gen TP53 CELLULAR TUMOR ANTIGEN P53 TUMOR SUPPRESSOR P53 PHOSPHOPROTEIN P53, ANTIGEN NY-CO-13 Odkryty w 1979 roku gen białka P53 (fosfoproteina w jądrze komórkowym), znajduje się na krótkim ramieniu chromosomu 17. Jest to gen supresorowy, odpowiedzialny m.in. za zachowanie stabilności genetycznej. Prawidłowa komórka wytwarza bardzo niewiele białka P53. Uszkodzenie DNA prowadzi do zwiększenia liczby P53 w jądrze komórkowym. Enzymy rozpoznające zniszczenie jądrowego DNA przyłączają grupy fosforanowe do białka P53, utrudniając jego rozkład. Nagromadzenie się cząsteczek białka P53 w komórce prowadzi do zatrzymania cyklu komórkowego oraz do uaktywnienia procesów naprawczych DNA, a jeśli naprawa materiału genetycznego okaże się niemożliwa do apoptozy. Apoptoza jest genetycznie zaprogramowanym samobójstwem i oznacza śmierć komórki. P53 jest czynnikiem transkrypcyjnym: uruchamia ekspresję wybranych grup genów. W przypadku, gdy zajdzie mutacja genu P53 lub utrata fragmentu chromosomu 17, białko P53 nie zapobiega replikacji uszkodzonego DNA. Nieprawidłowe komórki mogą się dzielić w nieskończoność, nie naprawiając błędów, co prowadzi do transformacji nowotworowej. Mutacje genów P53 można stwierdzić w ponad połowie wszystkich ludzkich nowotworów złośliwych. Genom człowieka w DB2 1. Pobranie 49 plików ze strony: 2. Rozpakowanie wszystkich pobranych plików: for i in `ls -1 *.gz`; do gunzip $i done 3. Ponieważ wszystkie pliki mają następującą strukturę: head -5 chr17.fa >chr17 AAGCTTCTCACCCTGTTCCTGCATAGATAATTGCATGACAATTGCCTTGT CCCTGCTGAATGTGCTCTGGGGTCTCTGGGGTCTCACCCACGACCAACTC CCTGGGCCTGGCACCAGGGAGCTTAACAAACATCTGTCCAGCGAATACCT GCATCCCTAGAAGTGAAGCCACCGCCCAAAGACACGCCCATGTCCAGCTT Z baz danych Ensembl i GeneCard możemy się dowiedzieć, iż gen TP53 znajduje się na chromosomie 17, w lokalizacji: 7,512,464 7,531,642. należy z każdego z nich usunąć pierwszą linię i wszystkie znaczniki końca linii. Do tego celu posłużyć może poniższy program napisany w języku Perl: Ze strony projektu Ensembl możemy pobrać zawartość genu TP53, wybierając odpowiednio z menu strony o genie TP53: > Export gene data > Output Format: FASTA format text file > Sequence type to export: Genomic; Output format: Text. >17 dna:chromosome chromosome:ncbi36:17: : :1 TGGCAGCAAAGTTTTATTGTAAAATAAGAGATCGATATAAAAATGGGATATAAAAAGGGA GAAGGAGGGGAAGGGTGGGGTGAAAATGCAGATGTGCTTGCAGAATGTAAAAGATGTTGA CCCTTCCAGCTGGACGTGGTGGCTCACAATTGTAATCCCAGCACTCTGGGAGGCTGAGAC AGGTGGATCGCCTGAGCCCAGGAGTTTGAGACCAGCCTGGGCAACACTGTGAGACCCCAT CTCTACAAAACATGCAAAAGTTGGCTGGCCATGGTGGCATGAACCTGTGGTCCCAGCTAC ( ) Pierwsze pięćdziesiąt zasad tego genu: TGGCAGCAAAGTTTTATTGTAAAATAAGAGATCGATATAAAAATGGGATA. genome.pl #!/usr/bin/perl -w use strict; my $first=1; while(<>) { if($first==1) { $first=0; } else { chomp; print; } } run TMP=".tmp_file" for i in `ls -1 *.fa`; do echo $i./genome.pl < $i > $TMP mv $i $i.hgp mv $TMP $i done 11

12 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 12 IIC MAGAZINE II kwartał 2006 (9) który uruchomić można poprzez wykonanie poniższych poleceń: chmod 700 genome.pl chmod 700 run sh run 4. Tworzenie bazy hgp w DB2 (przykładowe ścieżki dla systemu Linux): Number of rows rejected = 0 Number of rows committed = Poszukując genu TP53 w naszej bazie danych DB2, wykonajmy pierwsze zapytanie (wiemy, iż ma się on znajdować w chromosomie 17): select id, filename from genome where filename like '%17%' db2 ID FILENAME create database hgp automatic storage yes on '/home/db2inst1' \ using codeset iso territory us collate \ using system pagesize 8192 with 'The Human Genome Project' chr17.fa 40 chr17_random.fa 5. Tworzenie tabeli genome, do której przeprowadzimy ładowanie danych z plików tekstowych, używając m.in. typu danych CLOB: db2 connect to hgp create table genome (id int primary key not null, filename varchar(32), sequence clob (236M)) 6. Przygotowanie pliku spis.txt, w którym powinny się znaleźć wszystkie pliki, którymi będziemy zasilać tabelę genome : spis.txt 9. Znając ze strony projektu Ensembl zawartość tego genu, spróbujmy znaleźć w naszej bazie danych pierwsze pięćdziesiąt zasad tego genu: select locate('tggcagcaaagttttattgtaaaataagagatcgatataaaaatgggata',sequence) as TP53 from genome where id=17 TP Ciąg znaków został znaleziony! Zaczyna się on od pozycji pola CLOB w tabeli genome dla wiersza o id=17, co jest zgodne z danymi Ensembl i GeneCard, które umiejscawiają gen 17 w lokalizacji: 7,512,464 7,531,642 bp. 1,chr1.fa,chr1.fa 2,chr2.fa,chr2.fa 3,chr3.fa,chr3.fa 4,chr4.fa,chr4.fa 5,chr5.fa,chr5.fa ( ) i tak dla wszystkich 49 plików. 7. Proces zasilania tabeli z plików, zgodnie z opisem w pliku spis.txt : 10. Wyświetlmy z naszej bazy danych DB2 pierwsze pięćdziesiąt zasad od pozycji na chromosomie 17: select substr(sequence, , 50) as DNA from genome where id=17 DNA TGGCAGCAAAGTTTTATTGTAAAATAAGAGATCGATATAAAAATGGGATA db2 connect to hgp import from spis.txt of del modified by lobsinfile insert into genome Ciąg ten zgadza się z danymi o genie TP53 pobranymi ze strony projektu Ensembl. powinien zakończyć się następującym podsumowaniem: Number of rows read = 49 Number of rows skipped = 0 Number of rows inserted = 49 Number of rows updated = 0 Artur Górnik bazami danych zajmuje się zawodowo od 8 lat. W IBM Software Group odpowiada za DB2 i migracje baz danych. Posiada kilkuletnie doświadczenie w zakresie bazy danych Oracle. Współpracuje ze środowiskiem akademickim, wspierając rozwój zastosowań IT w bioinformatyce i zarządzanie sytuacjami kryzysowymi w systemach przetwarzania danych. Kontakt: artur.gornik@pl.ibm.com 12

13 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 13 NOWINKI TECHNOLOGICZNE Klient JMS dla IBM serwera aplikacyjnego WebSphere Technologia JMS (Java Messaging Services) służąca do przesyłania komunikatów pomiędzy systemami odgrywa istotną rolę podczas tworzenia nowych systemów, jak i podczas integracji istniejących systemów w firmach. IBM AlphaWorks udostępnił właśnie narzędzia typu klient w technologii J2SE służące do komunikowania się z serwerem aplikacyjnym WebSphere, wykorzystując technologię i mechanizmy JMS. Udostępnione narzędzia implementują wersję 1.1 standardu JMS, pozwalając na nawiązywanie połączeń TCP i SSL. Klient może być uruchamiany na dowolnej maszynie wirtualnej Java 2 SE w wersji Zastosowanie tej technologii jest wygodne i elastyczne oraz pozwala zmniejszyć rozmiary aplikacji łączącej się do serwera WebSphere. Więcej na stronie: Opracował: Tomasz Mielnik Service Integration Bus Explorer nowe narzędzie monitorujące szyny integracyjne Serwis IBM AlphaWorks opublikował nowe narzędzie o nazwie Service Integration Bus Explorer. Jest to narzędzie pozwalające w łatwy sposób monitorować i przeglądać komunikaty pojawiające się na szynie integracyjnej (ang. Service Integration Bus). SI Bus jest domyślnym mechanizmem obsługującym przesyłanie komunikatów w serwerze aplikacyjnym WebSphere, a także w WebSphere Enterprise Service Bus. SI Bus Explorer powstało w oparciu o bibliotekę SWT znaną ze środowiska Eclipse i dzięki bezpośredniemu połączeniu z serwerem WebSphere pozwala śledzić zasoby szyny komunikacyjnej takie, jak np. przesyłane komunikaty. Rozwiązanie będzie przydatne administratorom, programistom czy użytkownikom rozwiązań opartych o SI Bus. Więcej na stronie: Opracował: Tomasz Mielnik IBM FixTime e-servicepac Oferta FixTime e-servicepac daje pewność, że nowo zakupiony serwer System X (dawniej xseries) przez całe 3 lata świadczenia usługi nie będzie miał dłuższej przerwy w pracy spowodowanej awarią niż 8 godzin, od momentu zgłoszenia problemu do IBM. Dla wybranych serwerów System X IBM oferuje FixTime e-servicepac przez 7 dni w tygodniu i 24 godziny na dobę z GWARANTOWANYM CZASEM NAPRAWY od 8 do 24 godzin od zgłoszenia awarii do IBM. Usługa jest świadczona na całym terytorium Polski. Szczegóły oferty na stronie: Opracował: Igor Zacharjasz Hierarchiczno-relacyjny silnik danych DB2 9 IBM udostępnił nową wersję DB2 9, znaną pod nazwą kodową Viper. W wersji 9 zastosowano hierarchiczny silnik purexml do obsługi danych XML, co jest zupełnie innym podejściem niż w przypadku dotychczasowych rozwiązań stosowanych w bazach relacyjnych. Dokumenty XML obsługiwane są przez konkurencyjne bazy w postaci dużych obiektów binarnych LOB (large objects) albo są dekomponowane do tabel relacyjnych (shedding). W metodzie wykorzystującej obiekty LOB dokumenty wkładane są do pola binarnego w całości i dopiero w momencie realizacji zapytania przetwarzana jest jego struktura i zwracane są odpowiednie elementy dokumentu. Dynamiczne parsowanie dokumentu bardzo negatywnie wpływa na wydajność wyszukiwania. Z kolei metoda dekomponowania wymaga zdefiniowania struktury dokumentu XML, zanim zostanie on wstawiony do bazy, co bardzo ogranicza stosowanie tej metody to właśnie elastyczność jest największą zaletą formatu XML. DB2 9 przełamuje oba ograniczenia, ponieważ przechowuje dokumenty XML w formacie odpowiadającym hierarchicznej strukturze dokumentu XML. DB2 9 kładzie bardzo duży nacisk nie tylko na wydają pracę bazy XML-owej, ale także na integrację z relacyjnym silnikiem. Język zapytań do dokumentów XML XQuery/XPath jest obsługiwany na równi z językiem SQL, a kompilator zapytań bazy danych DB2 pozwala na łączenie danych relacyjnych z danymi XML. Zastosowanie natywnego języka zapytań do danych XML upraszcza tworzenie aplikacji przy zachowaniu odpowiedniej wydajności, jaką daje hierarchiczny silnik. DB2 9 pozwala także indeksować wybrane elementy dokumentu XML, które można określić odpowiednim wyrażeniem XPath. Wspierane są także indeksy pełnotekstowe na całym dokumencie XML. Więcej na stronie: Opracował: Artur Wroński DB2 Data Warehouse Edition 9 Narzędzia do budowy hurtowni danych DB2 Data Warehouse Edition 9 oparte są o platformę Eclipse. Z jednego interfejsu można modelować dane, budować kostki wielowymiarowe oraz definiować transformacje danych. Nowatorsko zostało rozwiązane podejście do eksploracji danych (data mining). Zaawansowane algorytmy eksploracji zostały zaszyte w bazę danych, tak by dane nie musiały opuszczać hurtowni, a modelowanie jest tak samo proste, jak tworzenie transformat SQL. Środowisko pozwala na pracę grupową oraz zawiera wbudowane mechanizmy śledzenia (debugging). Więcej na stronie: Opracował: Artur Wroński Projekt hurtowni danych Sterowanie przepływem danych Kod SQL wygenerowany na podstawie zaprojektowanych transformacji Przeglad obiektów w bazie danych Przepływ danych Interfejs do projektowania transformacji danych 13

14 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 14 Z PERSPEKTYWY PARTNERA HANDLOWEGO RFID Radio Frequency IDentification jako nośnik informacji w standardzie EPC (Elektroniczny Kod Produktu) Tomasz Pisarek Radio Frequency IDentification to technologia znana i z powodzeniem stosowana od kilku lat między innymi w systemach kontroli dostępu, ruchu osobowego oraz zabezpieczeniach pojazdów. Coraz częściej traktowana jest jako rewolucyjny krok w zarządzaniu przepływem towarów w całym łańcuchu dostaw. Zastosowanie systemów opartych o tę technologię jest związane z pasmem częstotliwości wykorzystywanych w rozwiązaniu. Niewielkich rozmiarów chipy i anteny umieszczone w TAG-ach występują w postaci kart plastikowych, breloków, przywieszek oraz etykiet samoprzylepnych. Rozwój technologii spowodował rozszerzenie zakresów częstotliwości oraz funkcjonalności elementów systemu. Od prostych TAG-ów, zawierających 80-bitowy kod identyfikacyjny wysyłany na żądanie do czytnika po TAG-i pracujące w paśmie UHF MHz Gen2, wykorzystywane w EPC, umożliwiające zapis i przechowywanie informacji. Wyróżniamy dwa główne typy TAG-ów: aktywne i pasywne. Tagi aktywne mają wbudowaną baterię i czerpią z niej energię potrzebną do transmisji danych. Ich zaletą jest duża odległość odczytu. Natomiast TAG-i pasywne czerpią energię z fali elektromagnetycznej wysyłanej bezpośrednio z czytnika działają na zasadzie fali odbitej, ich zasięg to ok. 10 m z jednej anteny, mają za to niewielkie rozmiary. Istnieje jeszcze rozwiązanie pośrednie są to TAG-i pasywne z zasilaniem baterią. Bateria w nich używana jest tylko do zasilania procesora, dane wysyłane są tak jak w TAG-ach pasywnych. Elektroniczne znaczniki zdobywają coraz większą popularność w sektorze logistycznym Centra logistyczne korzystające z technologii RFID otrzymują nowe możliwości w zarządzaniu zasobami dzięki zdalnej kontroli stanów magazynowych, a dodatkowo 14

15 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 15 RFID Radio Frequency IDentification jako nośnik informacji w standardzie EPC (Elektroniczny Kod Produktu) odczytane informacje przesyłane są do centralnego systemu informatycznego automatycznie, bez ingerencji człowieka. Cały proces przyjmowania i wydawania towaru można dowolnie zaprojektować i zautomatyzować, zakładając specjalne bramki z urządzeniami nadawczo-odbiorczymi. Rozwiązania oparte o technologię RFID automatyzują procesy biznesowe dane pozyskane z nośników RFID zasilają aplikacje ERP i WMS. Znaczniki RFID umieszczone na paletach i opakowaniach zbiorczych pozwalają zlokalizować zamówione towary, a system na bieżąco aktualizuje informacje o stanach magazynowych, przyjętych zamówieniach i ich realizacji. Podczas załadunku zamówionych towarów anteny zamontowane w bramkach wyjazdowych pozwalają na weryfikację zgodności wysyłki z oryginalnym zamówieniem. Technologią RFID zainteresowane są również największe sieci handlowe, które testują zastosowanie TAG-ów RFID w specjalnie przygotowanych placówkach handlowych. Towary oklejone zaprogramowaną etykietą z TAG-iem RFID umieszczone na półkach marketu wyposażonych w czytniki połączone z systemem informatycznym dają rzeczywisty obraz zapasów magazynowych i ruchu towarów. Sieć EPCGlobal łączy dwie technologie: zastosowanie technologii RFID UHF Gen2 do identyfikacji oraz Internetu, dzięki któremu produkt zaopatrzony w TAG jest widoczny w całym łańcuchu dostaw w czasie rzeczywistym. Dzięki sieci EPC wszystkie firmy biorące udział w projektach będą miały dostęp do otwartych globalnych standardów, a Internet zapewni im dostęp do informacji zapisanych na TAG-ach. EPC odzwierciedla oznaczenia stosowane w systemie EAN.UCC: SGTIN-96, SSCC-96, SGLN, GRAI, GIAI, GID. Obecnie takie firmy, jak METRO, WAL-MART i TESCO prowadzą już zaawansowane pilotowe wdrożenia technologii EPC i planują, że w 2006 roku całkowicie zaadaptują tę technologię w zakresie obsługi dostaw. Jantar Sp. z o.o. jako jedna z pierwszych polskich firm przystąpiła do tej organizacji, współuczestnicząc w budowie Laboratorium RFID-ECP w Instytucie Logistyki i Magazynowania w Poznaniu. Działalność ta ma za zadanie prowadzenie badań i rozpowszechnienie rozwiązań EPC w procesie logistycznym w oparciu o technologię RFID. KORZYŚCI Z ZASTOSOWANIA RFID: możliwość jednoczesnego odczytu i zapisu wielu etykiet zapis i odczyt nie wymaga bezpośredniej widoczności etykiety działanie w trudnych warunkach (zabrudzenia, wilgoć, wysokie i niskie temperatury) szybka transmisja danych pomiędzy etykietami a czytnikami zwiększone bezpieczeństwo przesyłania informacji dzięki możliwości szyfrowania danych Tomasz Pisarek zarządza działem oprogramowania w firmie Jantar Sp. z o.o. ( Od 12 lat zajmuje się rozwiązaniami dotyczącymi zakresu Automatycznej Identyfikacji Danych. Podczas swojej praktyki zawodowej uczestniczył w licznych projektach dotyczących opracowania oprogramowania w zakresie logistyki, bazując na urządzeniach takich firm, jak ZEBRA, SYMBOL, PSC itp. Obecnie prowadzi grupę badawczo-rozwojową technologii EPC/RFID firmy Jantar. Uczestnictwo w EPCGlobal umożliwia dostęp do banku informacji, opracowywanie najnowocześniejszych rozwiązań technologicznych, wymianę informacji pomiędzy uczestnikami programu testowego oraz ciągłe doskonalenie dotyczące wdrożenia i stosowania elementów sieci EPCGlobal. Wychodząc naprzeciw technologii EPC-RFID i jej zastosowaniu w logistyce i handlu, firma Jantar Sp. z o.o. prowadzi własne testy wdrożeniowe, wykorzystując posiadane w ofercie urządzenia AutoID. Najwięksi producenci systemów informatycznych również wprowadzili technologię RFID do swoich rozwiązań, zapewniając tym samym płynne zarządzanie łańcuchem dostaw. Dla przykładu: w ofercie biznesowych drukarek kodów kreskowych znajduje się IBM Infoprint 6700 model R40 (szczegóły: ibm.com/printers.thermal) mogący programować TAG-i RFID UHF Gen2. Jest to drukarka termiczna zapewniająca wieloprotokołową obsługę RFID i integrację z oprogramowaniem IBM ułatwiającym scentralizowaną komunikację. Urządzenie jest zgodne ze standardem EPC. Krótko mówiąc, technologia RFID umożliwia minimalizację błędów oraz nakładów pracy przy intensywnym zbieraniu danych. Tak szeroki zakres zastosowań technologii RFID możliwy jest za sprawą Elektronicznego Kodu Produktu EPC nowego standardu identyfikacji, opracowanego przez EPCGlobal. EPCGlobal jest organizacją, której celem jest rozwijanie zarówno całego systemu EPC, jak i jego poszczególnych elementów, korzeniami sięga do Auto-Id Center, które mieści się w Massachusetts Institute of Technology. Organizacja ta współpracuje z wieloma laboratoriami czołowych uniwersytetów, z ponad 100 firmami, które wspierają finansowo działalność Auto-Id, jak i również z innymi organizacjami logistycznymi. W Polsce EPCGlobal działa przy Instytucie Logistyki i Magazynowania w Poznaniu, której podstawowym zadaniem jest komercjalizacja i adaptacja w skali globalnej technologii opartej na Elektronicznym Kodzie Produktu. Jantar Sp. z o.o. ( jest Partnerem Handlowym IBM o statusie Premier (ang. IBM Premier Business Partner). Firma współpracuje również z Lenovo, ZEBRA Technologies, PSC, SYMBOL Technologies oraz SHARP. Dwukrotnie została uhonorowana Medalem Europejskim przyznawanym przez BCC i Urząd Komitetu Integracji Europejskiej dostawcom usług i wyrobów. Ponadto jest laureatem nagród Partner roku IBM, ZEBRA i SHARP. Jantar posiada Certyfikat ISO 9001:2000. Centrala firmy Jantar mieści się w Bielsku-Białej a najważniejsze z 8 oddziałów regionalnych są zlokalizowane we Wrocławiu, Warszawie, Krakowie i Rzeszowie. 15

16 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 16 MACIEJ PRZEPIÓRKA Wysokodostępne DB2 HADR jest technologią pozwalającą uzyskać wysoką dostępność bazy danych DB2. Wywodzi się z serwera Informix IDS. Tam technologia ta nazywana była Informix High Availability Data Replication (HDR) i była dostępna od połowy lat 90. W DB2 8.2, skrót HADR oznacza High Availability Disaster Recovery. Architektura HADR najprościej zrozumieć jako dwa zsynchronizowane serwery baz danych. Główny serwer (primary) obsługuje aplikacje lub użytkowników końcowych, podczas gdy serwer zapasowy (standby) jest utrzymywany przez cały czas pracy w stanie identycznym, jak serwer podstawowy to znaczy wykonuje dokładnie te same transakcje na tych samych danych. W razie awarii serwera podstawowego, serwer zapasowy przejmuje użytkowników i staje się serwerem podstawowym. Takie przełączenie w razie awarii zwykle trwa do 30 sekund. Przełączenie tego typu jest możliwe również w drugą stronę, dzięki czemu po naprawie uszkodzonego serwera sesje użytkowników mogą wrócić na poprzednią maszynę. Rys. 1 Architektura DB2 HADR Przełączanie ról serwerów może być przydatne nie tylko w razie awarii. Dzięki HADR administrator może wykonywać tzw. rolling upgrades, czyli uaktualniać wersję serwera bazy danych bądź systemu operacyjnego bez konieczności wymuszania dłuższych przestojów w dostępie do danych. W pierwszym kroku administrator zatrzymuje serwer zapasowy i na nim nakłada niezbędne poprawki, później następuje przełączenie ról i uaktualnienie serwera podstawowego. Na końcu następuje jeszcze jedno przełączenie i przywrócenie pierwotnych funkcji obu serwerów. Rys. 2 Odwrócenie ról serwerów po wykonaniu operacji takeover HADR udostępnia 3 tryby synchronizacji danych: tryb asynchroniczny (asynchronous), bliski synchronicznemu (near synchronous) i synchroniczny (synchronous). W trybie asynchronicznym, transakcje wykonane na węźle podstawowym są uznane za zatwierdzone już w momencie dostarczenia ich do warstwy TCP serwera podstawowego. Oznacza to, że w razie awarii tego serwera lub sieci, ostatnio wykonane transakcje mogą nie być dostarczone do serwera zapasowego, a co za tym idzie mogą być zgubione. Tryb asynchroniczny ma najmniejszy ze wszystkich trzech trybów synchronizacji narzut na wydajność, a czas odpowiedzi transakcji najkrótszy. Tryb nearsync zmniejsza ryzyko zagubienia transakcji, jednak minimalnie wydłuża czas wykonania transakcji. Za moment zatwierdzenia transakcji uznaje się chwilę, w której serwer podstawowy zapisał transakcję do plików dziennika (logów transakcyjnych), a serwer zapasowy potwierdził zapisanie otrzymanej transakcji do pamięci operacyjnej (ale jeszcze nie na dyski). Utrata transakcji może nastąpić jedynie, gdy oba serwery w tej samej chwili ulegną awarii i serwer zapasowy nie zdąży zapisać danych z pamięci RAM do logów. Prawdopodobieństwo utraty jakichkolwiek danych jest o wiele mniejsze niż w trybie asynchronicznym. Najlepsze zabezpieczenie przed awarią udostępnia tryb synchroniczny. Transakcja jest uznana za zatwierdzoną dopiero w chwili, gdy serwer podstawowy zapisze ją do logów oraz gdy serwer podstawowy otrzyma potwierdzenie od serwera zapasowego, że tamten zapisał dostarczoną transakcję do swoich logów znajdujących się na dyskach. W tym trybie, koszt wykonania transakcji jest najwyższy, ale zyskujemy 100% pewności, że żadna transakcja nie ucierpi w przypadku awarii. Instalacja i przygotowanie środowiska na przykładzie AIX-a Do celów przetestowania funkcjonalności HADR zainstalowałem bazę danych DB2 Enterprise Server Edition w wersji 8.1 FixPak 12. Platformą sprzętową były dwa serwery System p, a jako system operacyjny wybrałem AIX 5.3. Dalsza część artykułu to instrukcja, jak krok po kroku zainstalować i skonfigurować DB2 HADR. Pliki binarne DB2 muszą być zainstalowane na obu maszynach w identycznej wersji. root@aix1#./db2_install Specify one or more of the following keywords, separated by spaces, to install DB2 products. Keyword DB2.ESE DB2.ADMCL DB2.ADCL Product Description DB2 Enterprise Server Edition for AIX DB2 Administration Client for AIX DB2 Application Development Client for AIX Enter "help" to redisplay product names. Enter "quit" to exit. *********************************************************** DB2.ESE db2_08_01.msg.en_us.iso Pre-installation Verification Verifying selections...done Verifying requisites...done Results... The installation logfile can be found in /tmp/db2_install_log db2_install program completed successfully. 16

17 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 17 WYSOKODOSTĘPNE DB2 Kolejną niezbędną czynnością jest utworzenie grup oraz użytkowników w systemie operacyjnym (również na obu maszynach): root@aix1# mkgroup id='1001' db2iadm1 root@aix1# mkuser pgrp='db2iadm1' home='/home/db2inst1' db2inst1 root@aix1# mkgroup id='1002' db2fadm1 root@aix1# mkuser pgrp='db2fadm1' home='/home/db2fenc1' db2fenc1 root@aix1# mkgroup id='1003' dasadm1 root@aix1# mkuser pgrp='dasadm1' home='/home/dasusr1' dasusr1 Następnym krokiem jest zdefiniowanie serwera administracyjnego: root@aix1# /usr/opt/db2_08_01/instance/dascrt -u dasusr1 SQL4406W The DB2 Administration Server was started successfully. DBI1070I Program dascrt completed successfully. Należy też utworzyć instancję DB2 i skonfigurować ją tak, aby możliwa była komunikacja z zewnątrz przez protokół TCP/IP: root@aix1# /usr/opt/db2_08_01/instance/db2icrt -a server -u db2fenc1 db2inst1 DBI1070I Program db2icrt completed successfully. root@aix1# su db2inst1 db2inst1@aix1# db2set DB2COMM=TCPIP db2inst1@aix1# db2 update dbm cfg using svcename DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully. Ostatnia czynność to dopisanie do plików /etc/services następujących linii, określających numery portów TCP, przez które będzie się komunikować HADR: db2hadr_iic_pri 50000/tcp db2hadr_iic_std 50001/tcp Wszystkie powyższe czynności należy wykonać w ten sam sposób na obu maszynach. Kolejne czynności są inne dla serwera podstawowego i serwera zapasowego. Należy określić, który z serwerów będzie podstawowym (primary), a który zapasowym (standby). W tym przypadku będą to odpowiednio maszyny aix1 oraz aix2. Konfiguracja środowiska po stronie serwera podstawowego Na serwerze podstawowym uruchamiamy instancję i tworzymy bazę danych o nazwie IIC. W kolejnych krokach zostanie ona przeniesiona za pomocą poleceń backup i restore na serwer zapasowy. db2 => CREATE DATABASE IIC on /home/db2inst1/iic USING CODESET ISO TERRITORY US COLLATE USING SYSTEM USER TABLESPACE MANAGED BY DATABASE USING (FILE '/home/db2inst1/iic/00user' 5120) CATALOG TABLESPACE MANAGED BY DATABASE USING (FILE '/home/db2inst1/iic/00catalog' 25120) TEMPORARY TABLESPACE MANAGED BY DATABASE USING (FILE '/home/db2inst1/iic/00temp' 15120) DB20000I The CREATE DATABASE command completed successfully. HADR wymaga, aby baza danych działała w trybie logretain: db2 => update db cfg for iic using logretain on db2 => update db cfg for iic using logindexbuild on db2 => update db cfg for iic using indexrec restart db2 => update db cfg for iic using logarchmeth1 disk:/home/db2inst1/iic/arch logprimary 5 logsecond 5 logfilsiz 5000 W trybie logretain, pliki dziennika powtórzeń pozostają na dysku i w razie awarii mogą być użyte do powtórzenia wcześniej wykonanych transakcji (tzw. wykonania operacji roll-forward). Po przełączeniu bazy danych w tryb logretain wymagane jest wykonanie pełnej kopii zapasowej. Do tego momentu baza danych będzie się znajdować w stanie backup pending. Parametr logindexbuild określa, czy operacje tworzenia lub reorganizacji indeksów będą zapisywane do logów, a co za tym idzie wykonane również na serwerze zapasowym. Opcja indexrec ustawiona na wartość restart spowoduje, że przebudowa uszkodzonych indeksów będzie wykonywana w chwili restartu instancji bazy danych. Teraz pozostaje tylko wykonanie kopii zapasowej bazy danych: db2 => backup db iic to /home/db2inst1/backup Backup successful. The timestamp for this backup image is : Tak wykonany backup należy przenieść na serwer zapasowy, np. za pomocą FTP. Konfiguracja środowiska po stronie serwera zapasowego Odtworzenie bazy danych z backupu jest możliwe poprzez wykonanie następującego polecenia: db2 => restore db iic from /home/db2inst1/backup replace history file DB20000I The RESTORE DATABASE command completed successfully Parametry konfiguracyjne dla HADR Parametry HADR na serwerze podstawowym muszą odpowiadać parametrom HADR na serwerze zapasowym, tzn. muszą być ze sobą zgodne. Parametr HADR_LOCAL_HOST na serwerze podstawowym musi być identyczny, jak HADR_REMOTE_HOST na serwerze zapasowym. W podobny sposób muszą być ustawione HADR_LOCAL_SVC i HADR_REMOTE_SVC. Parametr HADR_REMOTE_INST określa nazwę instancji na zdalnym węźle klastra. HADR_TIMEOUT (wartość w sekundach) to limit czasu na komunikację z węzłem zdalnym. Sposób synchronizacji węzłów jest określany parametrem HADR_SYNCMODE. Domyślna wartość to nearsync. Parametry konfiguracyjne dla HADR na węźle podstawowym należy ustawić w taki sposób: db2 => update db cfg for iic using HADR_LOCAL_HOST db2 => update db cfg for iic using HADR_LOCAL_SVC db2hadr_iic_pri db2 => update db cfg for iic using HADR_REMOTE_HOST db2 => update db cfg for iic using HADR_REMOTE_SVC db2hadr_iic_std db2 => update db cfg for iic using HADR_REMOTE_INST db2inst1 db2 => update db cfg for iic using HADR_TIMEOUT 120 db2 => update db cfg for iic using HADR_SYNCMODE nearsync Na serwerze zapasowym muszą one odzwierciedlać konfigurację serwera podstawowego: db2 => update db cfg for iic using HADR_LOCAL_HOST db2 => update db cfg for iic using HADR_LOCAL_SVC db2hadr_iic_std db2 => update db cfg for iic using HADR_REMOTE_HOST db2 => update db cfg for iic using HADR_REMOTE_SVC db2hadr_iic_pri db2 => update db cfg for iic using HADR_REMOTE_INST db2inst1 db2 => update db cfg for iic using HADR_TIMEOUT

18 IBM IIC Magazine Q2 7/28/06 8:11 AM Page 18 IIC MAGAZINE II kwartał 2006 (9) db2 => update db cfg for iic using HADR_SYNCMODE nearsync Na obu maszynach należy dodatkowo określić serwer alternatywny (tzn. ten, na który będzie wykonywany failover). Dla maszyny aix1: db2 => update alternate server for database iic using hostname port DB20000I The UPDATE ALTERNATE SERVER FOR DATABASE command completed successfully. DB21056W Directory changes may not be effective until the directory cache is refreshed. db2 => terminate DB20000I The TERMINATE command completed successfully. Dla serwera aix2: db2 => update alternate server for database iic using hostname port DB20000I The UPDATE ALTERNATE SERVER FOR DATABASE command completed successfully. DB21056W Directory changes may not be effective until the directory cache is refreshed. db2 => terminate DB20000I The TERMINATE command completed successfully. Uruchomienie funkcjonalności HADR Operację uruchomienia środowiska HADR rozpoczyna się na serwerze zapasowym: db2 => start hadr on database iic as standby DB20000I The START HADR ON DATABASE command completed successfully. Później pozostaje tylko uruchomić HADR na serwerze podstawowym: db2 => start hadr on database iic as primary DB20000I The START HADR ON DATABASE command completed successfully. Od tej chwili środowisko HADR działa poprawnie i umożliwia łączenie się klientów ze zdalnych lokalizacji. Konfiguracja klienta Aby w pełni przetestować środowisko DB2 HADR, będzie potrzebna jeszcze jedna maszyna, na której zostanie skonfigurowany klient DB2. Zakładam, że jest to zwykła stacja robocza (system operacyjny Windows) z zainstalowanym klientem DB2. Operacja skatalogowania zdalnej bazy danych (w tej chwili działającej na węźle aix1) powinna być przeprowadzona w następujący sposób: db2 catalog tcpip node aix1 remote server remote_instance db2inst1 system ostype aix db2 catalog db iic as iic at node aix1 db2 terminate Może się okazać, że konieczne będzie ustawienie prawidłowej strony kodowej po stronie klienta: db2set DB2CODEPAGE=819 Wartość 819 oznacza stronę ISO (tak została utworzona baza danych). Wartość 912 ustawia się dla strony , a wartość 1250 dla Windows Test funkcjonalności HADR Po stronie klienta wykonujemy połączenie do bazy danych i tworzymy przykładową tabelę: db2 => create table test (id integer, name varchar(16)) DB20000I The SQL command completed successfully. db2 => insert into test values (1, 'Tim'),(2,'Mary') DB20000I The SQL command completed successfully. db2 => select * from test ID NAME Tim 2 Mary 2 record(s) selected. W dowolnym momencie na serwerze zapasowym można wykonać operację takeover. Spowoduje to zamianę ról serwerów i przeniesienie sesji na serwer określony wcześniej serwerem alternatywnym (polecenie update alternate server...). Serwer zapasowy stanie się serwerem podstawowym, a serwer podstawowy zapasowym. Takeover wykonuje się zawsze z poziomu serwera zapasowego: db2 => takeover hadr on database iic DB20000I The TAKEOVER HADR ON DATABASE command completed successfully. Z poziomu klienta DB2 ponownie wykonujemy zapytanie na tabeli testowej: db2 => select * from test SQL30108N A connection failed but has been re-established. The hostname or IP address is " " and the service name or port number is "60000". Special registers may or may not be re-attempted (Reason code = "1"). SQLSTATE=08506 db2 => select * from test ID NAME Tim 2 Mary 2 record(s) selected. Zapytanie zwróciło błąd informację o przełączeniu sesji na węzeł zapasowy, ale kolejna próba poprawnie zwróciła wynik. Oczywiście w razie awarii serwera podstawowego nie będzie możliwa zamiana ról. Serwer zapasowy stanie się serwerem podstawowym i jedynym serwerem w środowisku, aż do chwili usunięcia awarii. Przełączenie w takiej sytuacji będzie musiało być wykonane z parametrem by force: db2 => takeover hadr on database iic by force DB20000I The TAKEOVER HADR ON DATABASE command completed successfully. Więcej informacji na temat DB2 HADR oraz innych opcji konfiguracji można znaleźć w DB2 Information Center, dostępnym on-line pod adresem: Funkcjonalność HADR jest dostępna w DB2 Enterprise Server Edition bezpłatnie. W edycjach Workgroup oraz Express, HADR jest dodatkowo płatny. HADR nie jest w ogóle dostępny jedynie w darmowej wersji DB2 Express-C. Maciej Przepiórka od 5 lat specjalizuje się w zagadnieniach związanych z zarządzaniem informacją. W IBM Innovation Center odpowiada za testy, migrację i strojenie platform relacyjnych baz danych, jak również technologie Enterprise Search. Posiada doświadczenie we wdrażaniu systemów CRM i ERP oraz migracjach produkcyjnych baz danych na platformie AIX. W swojej karierze zawodowej zajmował się również administracją systemów UNIX i Linux oraz zaawansowanymi systemami multimedialnymi. Kontakt: maciej.przepiorka@pl.ibm.com 18

19 IBM IIC Magazine Q2 7/28/06 8:12 AM Page 19 _DZIENNIK ADMINA _DZIEŃ 49: Znów straciliśmy kontrolę. Nasz system nie jest bezpieczny, elastyczny i niezawodny. Witek kupił w sieci jakiś supersoft. Podobno zwęszy każdy problem. Ogary już poszły w las. _DZIEŃ 50: Tia Ogary nie okazały się tak dobre, jak zapewniały reklamy. Prędzej przegryzą kabel od Ethernetu, niż znajdą problem z siecią. _DZIEŃ 52: Mam to. IBM Tivoli Express. Niezłe. I działa. Tivoli to rozwiązania do zarządzania IT w średnich firmach, jak nasza. I w dobrej cenie. Serio. Rozwiązania Tivoli są superbezpieczne, zwiększają dostępność systemów i chronią dane poprzez automatyczny backup. Goście od Partnera Handlowego IBM nawet dostosowali je do naszych potrzeb i sprawnie wdrożyli. _Przypomnieć Witkowi: Trzymać psy z dala od komputerów. IBM, logo IBM, Tivoli oraz Express Middleware są zarejestrowanymi znakami towarowymi firmy International Business Machines Corporation w Stanach Zjednoczonych i/lub w innych krajach IBM Corporation. Wszelkie prawa zastrzeżone.

20 IBM IIC Magazine Q2 7/28/06 8:12 AM Page 20 Podstawowa oferta usług IBM Innovation Center obejmuje projekty migracyjne i portingowe, testy wydajnościowe, demonstracje i strojenie aplikacji, jak również szkolenia i seminaria techniczne. Więcej informacji na stronie: Jeśli jesteś zainteresowany skorzystaniem z naszego Centrum, już teraz skontaktuj się z opiekunem dedykowanym do Twojej firmy lub dzwoń pod numer: (+48 22) *. Wydarzenia, w których warto wziąć udział: 4-7 września IBM WebSphere Portal Technical Briefing, Stuttgart, Niemcy Szczegóły: 7 września DB2 Viper Technical Briefing, Warszawa, Hotel Westin Szczegóły: 21 września SOA Architect Summit, Warszawa Szczegóły: ibm.com/pl/events października IBM European System x and xseries Technical Conference, Londyn, Wielka Brytania Szczegóły: listopada IBM European System p, AIX 5L and Linux Technical Conference. Montpellier, Francja Szczegóły: listopada Transaction and Messaging Technical Conference, Saltzburg, Austria Szczegóły: listopada IBM European WebSphere Technical Conference, Saltzburg, Austria Szczegóły: Poszukujesz niezawodnego źródła informacji i zasobów dla dewelopera, wejdź na stronę: lub Więcej informacji o produktach, o których mowa w IIC Magazine, na stronach: IBM System Storage IBM System x IBM Infoprint IBM WebSphere Software IBM Tivoli Software IBM DB2 Software * Opłata wg jednostki taryfikacyjnej TP S.A.