deon/spdocker
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Minor updates and start of upgrading

Browse Source
This commit is contained in:
Deon George 2018-03-08 16:37:49 +11:00
parent ab61ea9435
commit 3b1e19f352
No known key found for this signature in database
GPG Key ID: 7670E8DC27415254
4 changed files with 110 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
source/server/firstrun.md
View File

@ -6,6 +6,8 @@ description: Spectrum Protect Server in a Docker Container - First run
related:
- { page: "index", title: "Containerising SP" }
- { page: "normalrun", title: "Normal Run of Container" }
- { page: "upgrade", title: "Upgrading SP" }
- { page: "recover", title: "Recoverying the SP Database" }
---
# First deployment of a Spectrum Protect Server (in a container)
> **NOTES**:
@ -33,7 +35,7 @@ TSM_DATA=/srv/sp/data
The first init run will be to create the database layout, and to copy the initialise database (as performed when containering SP) onto our persistent storage.
`docker run --detach=false --hostname=tsm --interactive=false -v $TSM_USER:/tsm.init -v $TSM_DB:/database.init --privileged=true --rm=true --restart=no --tty=false --name=spectrumprotect leenooks/spectrumprotect:8.1.4 init1`
`docker run --detach=false --hostname=tsm --interactive=false -v $TSM_USER:/tsm.init -v $TSM_DB:/database.init --privileged=true --rm=true --restart=no --tty=false --name=spectrumprotect ibm/spectrumprotect:8.1.4 init1`
You wont see any output, but if you look in your $TSM_USER path, you should see the familiar TSM instance owner files (like sqllib). The $TSM_DB directory should have sub directories created for the DB2 database, active and archive logs.
@ -55,7 +57,7 @@ drwxr-xr-x 2 201 201 4096 Mar 8 14:30 tsmdb
The second init run will now run the post-install setup for a new environment (`dsmserv formatdb` and then create the ADMIN user).
`docker run --detach=false --hostname=tsm --interactive=false -v $TSM_USER:/tsm -v $TSM_DB:/database --privileged=true --rm=true --restart=no --tty=false --name=spectrumprotect leenooks/spectrumprotect:8.1.4 init2`
`docker run --detach=false --hostname=tsm --interactive=false -v $TSM_USER:/tsm -v $TSM_DB:/database --privileged=true --rm=true --restart=no --tty=false --name=spectrumprotect ibm/spectrumprotect:8.1.4 init2`
```tsm Expected Output
ANR7800I DSMSERV generated at 16:03:41 on Nov 17 2017.

4
source/server/index.md
View File

@ -6,6 +6,8 @@ description: Spectrum Protect Server in a Docker Container
related:
- { page: "firstrun", title: "Initial Container Setup" }
- { page: "normalrun", title: "Normal Run of Container" }
- { page: "upgrade", title: "Upgrading SP" }
- { page: "recover", title: "Recoverying the SP Database" }
---
# Putting Spectrum Protect into a Container
(These instructions as based on Spectrum Protect 8.1.1. References to *SP* means Spectrum Protect.)
@ -51,7 +53,7 @@ COPY install.xml install-fp.xml /tmp/
Next, is performing a silent installation of SP.
```Dockerfile
RUN SOURCE_URL=http://yum.leenooks.net/docker/tsm && \
RUN SOURCE_URL=http://YOUR_SITE_URL_HERE && \
mkdir -p /tmp/build/8.1.0 && cd /tmp/build/8.1.0 && \
curl -SL ${SOURCE_URL}/8.1.0 > tsm && \
chmod +x tsm && ./tsm && rm -f tsm && \

4
source/server/normalrun.md
View File

@ -6,6 +6,8 @@ description: Spectrum Protect Server in a Docker Container - Normal Run
related:
- { page: "index", title: "Containerising SP" }
- { page: "firstrun", title: "Initial Container Setup" }
- { page: "upgrade", title: "Upgrading SP" }
- { page: "recover", title: "Recoverying the SP Database" }
---
# Normal Run of a Spectrum Protect Server (in a container)
> **NOTES**:
@ -30,7 +32,7 @@ TSM_DATA=/srv/sp/data
Starting SP for normal operations.
`docker run --detach=true --hostname=tsm --interactive=false -v $TSM_USER:/tsm -v $TSM_DB:/database -v $TSM_DATA:/data --memory=16g -p 1500:1500 -p 1543:1543 --privileged=true --rm=false --restart=no --tty=false --name=spectrumprotect leenooks/spectrumprotect:8.1.4`
`docker run --detach=true --hostname=tsm --interactive=false -v $TSM_USER:/tsm -v $TSM_DB:/database -v $TSM_DATA:/data --memory=16g -p 1500:1500 -p 1543:1543 --privileged=true --rm=false --restart=no --tty=false --name=spectrumprotect ibm/spectrumprotect:8.1.4`
```tsm Expected Startup, viewable by doing docker log -f spectrumprotect
ANR7800I DSMSERV generated at 16:03:41 on Nov 17 2017.

100
source/server/upgrade.md Normal file
View File

@ -0,0 +1,100 @@
---
subtitle: Upgrades
header-img: img/header_img/server.jpg
date: 2018-03-07 09:50:12
description: Upgrading Spectrum Protect Server in a Docker Container
related:
- { page: "index", title: "Containerising SP" }
- { page: "firstrun", title: "Initial Container Setup" }
- { page: "normalrun", title: "Normal Run of Container" }
- { page: "recover", title: "Recoverying the SP Database" }
---
# Upgrading Spectrum Protect Server (in a container)
**NOT YET COMPLETE**
> **NOTES**:
> * The storage used in the example below is from the host filesystems, passed to the container with Docker's `-v` option.
> * Upgrading needs special thought.
I have found that upgrading within a major release, eg: 7.1.0 to 7.1.1, 7.1.2 to 7.1.3, etc works transparently. Upgrading from 6 to 7 (I havent tried) and 7 to 8 (failed for me). Spectrum Protect is smart enough to realise that it has been upgraded and will do a one time schema update. However, DB2 needs thought, especially if there has been a major change in DB2 between SP releases.
> * As always, make sure you have a backout plan, in case things go pair shaped. I exploit Docker it provides a great backout option, especially if you use it with persistenet Docker Container storage that can exploit snapshots and reverting (or directly accessing) a snapshot. In the example below, I'm using Linux LVM snapshots to provide my backup option. Specturm Scale would also be a good choice.
## Configuration
Our configuration will use these defaults
```bash Container Variables
TSM_DB=/srv/sp/database
TSM_USER=/srv/sp/user
TSM_DATA=/srv/sp/data
```
* **TSM_DB** is where the TSM Database will be stored on the Docker Host, and will be passed to the container with `-v $TSM_DB:/database`
* **TSM_USER** is where the TSM Instance user's home directory is on the Docker Host, and will be passed to the container with `-v $TSM_USER:/tsm`
* **TSM_DATA** is where the TSM Disk based storage pools are stored on the Docker Host, and will be passed to the container with `-v $TSM_DATA:/data`
If data is stored in a cloud pool, then this would be where the acceleration pool is holding data before it gets sent to the cloud.
# Upgrade Steps
## Backup SP
`backup db type=FULL devclass=<YOUR BACKUP DEVCLASS> protectk=y pass=<PASSWORD> wait=yes`
```plain Expected Output
Protect: SERVER1>backup db t=f devclass=dbb protectk=y pass=password wait=y
ANR0984I Process 8 for Database Backup started in the FOREGROUND at 15:59:21.
ANR4559I Backup DB is in progress.
ANR2280I Full database backup started as process 8.
ANR4626I Database backup will use 1 streams for processing with the number originally requested 1.
ANR4550I Full database backup (process 8) completed. Total bytes backed up: 2,232,418,304.
ANR0985I Process 8 for Database Backup running in the FOREGROUND completed with completion state SUCCESS at 16:02:16.
ANR2394I BACKUP DB: Server device configuration information was written to all device configuration files.
Protect: LEENOOKS>q volh type=dbb
...
Date/Time: 08-03-2018 15:59:22
Volume Type: BACKUPFULL
Backup Series: 246
Backup Operation: 0
Volume Seq: 100,001
Device Class: DBB
Volume Name: /data/dbb/20485162.DBV
```
Make sure your backup is successful and make a note of where it is, in case you need it.
```bash On the Host
[root@host]# ls -aln $TSM_DATA/dbb/|grep 20485162
-rw------- 1 201 201 2232419730 Mar 8 16:01 20485162.dbv
```
## Stop SP
Stop your SP server.
`halt`
<small>**NOTE**: Dont use `docker stop` to stop your SP server.
By default docker sends a SIGTERM signal to the containers process 1 and then waits 10 seconds for it to die. If it hasnt died, it will then send it a SIGKILL.
While you can control the timeout between the SIGTERM and SIGKILL signal and you can even control which kill signal is sent, I havent explored what signals SP will act on. So as a recommendation, always use SP `halt` command to stop an SP server.</small>
## If you can, snapshot your persistent storage.
If you can snapshot your persistent storage that you provide to the SP Docker Container, that will save you doing a "restoredb" if something goes pair shaped.
## Delete your container
`docker rm -v spectrumprotect`
## Start the container with the new version of SP
### You need to do a one-time start of the container with the option `upgrade`.
`docker run --detach=true --hostname=tsm --interactive=false -v $TSM_USER:/tsm -v $TSM_DB:/database --privileged=true --rm=true --tty=false --name=spectrumprotect ibm/spectrumprotect:8.1.4 upgrade`
### Normal Run
`docker run --detach=true --hostname=tsm --interactive=false -v $TSM_USER:/tsm -v $TSM_DB:/database -v $TSM_DATA:/data --memory=16g -p 1500:1500 -p 1543:1543 --privileged=true --rm=false --restart=no --tty=false --name=spectrumprotect ibm/spectrumprotect:8.1.4`
```plain Expected Output
show the upgrade
```
Happy days :)
> If something did go pear shapped, then revert your snapshot (or if it is read only, copy the files back to the original path) and then start your container with the original image (the old version) of SP. It should start up as normal as if it was only shut down temporarily.
> If you really have problems, you have that backup to recover from! Start the container with the `restore <PASSWORD>` option - you'll need a DBDIRS.TXT file as well in the instance home directory. More info on recovering [here](#recover).