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