diff --git a/source/img/header_img/oc.jpg b/source/img/header_img/oc.jpg new file mode 100644 index 0000000..a949bab Binary files /dev/null and b/source/img/header_img/oc.jpg differ diff --git a/source/index.md b/source/index.md index 548cf2c..8fb7166 100644 --- a/source/index.md +++ b/source/index.md @@ -16,7 +16,7 @@ Docker is tool that will make the lives of system admins easier. It really helps So upgrades are really easy - you can consider an upgrade as: 1. Stop application - 1. Backup the application data (and a super quick way to do that is a filesystem or disk snapshot) + 1. Backup the application data (and a super quick way to do that is a file system or disk snapshot) 1. Deploy new version of application 1. New version of application should read data, and if appropriately "update it" to enable it to work with that new version @@ -30,30 +30,30 @@ Docker is tool that will make the lives of system admins easier. It really helps 3. It separates files relating to any application into 3 specific categories: 1. Application related files - in Docker, they are the put inside the Docker image, when the image is built. 2. Application data files - this is the data that personalises the application, and often is linked to the specific application version that created the data. In general terms, this has business value, it could be your Email database data, your RDBMS database data, etc - 3. Temporary data files - these are the files that your application may create as a result of running, (eg: temp files, etc) - they have no value, but are needed by the application to run. If they are lost, there is no concern. + 3. Temporary data files - these are the files that your application may create as a result of running, (EG: temp files, etc) - they have no value, but are needed by the application to run. If they are lost, there is no concern. So, for any application, you just need to keep the Application related files (1) and the Application data files (2). -By design containers should be considered ephemeral, ie: they can be destroyed and created many times. As long as the Application data files are connected to the same version of an Application related files when a Container is started, the application will live on until it is retired. +By design containers should be considered ephemeral, IE: they can be destroyed and created many times. As long as the Application data files are connected to the same version of an Application related files when a Container is started, the application will live on until it is retired. In Docker, your Application related files are in a Docker Image, your Application data files are on "Persistent Storage" and the Temporary data files are often created inside the container, and discarded when the container is destroyed. # Docker and Spectrum Protect ## Spectrum Protect Server -So from a Spectrum Protect point of view, if we are to run a Spectrum Protect server, containerizing it enables you to leverage points all three points above: +So from a Spectrum Protect point of view, if we are to run a Spectrum Protect server, containerising it enables you to leverage points all three points above: 1. Regardless of whether you'll have 1 SP server or 100, you install it "once" and store it in your Docker Image library (aka a Docker Registry) and you can deploy it many times almost instantly. 2. When you upgrade your Spectrum Protect server, you have easy upgrade and back-out plan, and in fact you can even "test" the upgrade before you do it live. -3. When you deploy it, your "Application data files" will be your Spectrum Protect configuration (ie: the database), and the Spectrum Protect configuration data (ie: your disk storage pools). +3. When you deploy it, your "Application data files" will be your Spectrum Protect configuration (IE: the database), and the Spectrum Protect configuration data (IE: your disk storage pools). You can place those anywhere you like following your organisations data deployment policies, but when referenced inside the container, they are always referenced at the same point that SP has been prepared for when you have "installed it". If you are interested in Dockerising Spectrum Protect, this might help you get [started](server). ## Spectrum Protect Client -From a client point of view, ie: protecting your business application and enabling you to recover it, by Dockerising your application, you have many your Spectrum Protect management even easier. IE: From the same three points above: -1. Application related files - ie: these are Docker Images and dont really need to be protected (daily at least). You'll have a copy of your Docker Image on your host(s) where your application is deployed and a copy in your Docker registry. +From a client point of view, IE: protecting your business application and enabling you to recover it, by Dockerising your application, you have many your Spectrum Protect management even easier. IE: From the same three points above: +1. Application related files - IE: these are Docker Images and don't really need to be protected (daily at least). You'll have a copy of your Docker Image on your host(s) where your application is deployed and a copy in your Docker registry. If your host ever dies, you'll setup a new host, ```docker pull``` the application, recover your data and start your application. (If anything, you could protect your "built" application by protecting the Docker Registry that it is stored in.) 2. Application data files, which represent your applications configuration and data, you do want to protect this, and in many cases you can protect this from "outside" the container. - There is no silver bullet on how to protect this data, so it will depend on the application and whether it provides an API or a "dump" capability on your approach to protecting it. In very, very simple terms, you could "pause" a Docker container, snapshot the devices (disk or filesystem) where the persistent storage is held and you have the equivalent of a hardware based snapshot backup. + There is no silver bullet on how to protect this data, so it will depend on the application and whether it provides an API or a "dump" capability on your approach to protecting it. In very, very simple terms, you could "pause" a Docker container, snapshot the devices (disk or file system) where the persistent storage is held and you have the equivalent of a hardware based snapshot backup. 3. Temporary data files - this can be ignored. Generally this data is "inside" the container and discarded if the container is ever "destroyed and recreated". If you are interested in Dockerising Spectrum Protect Clients, this might help you get [started](client). diff --git a/source/server/firstrun.md b/source/server/firstrun.md index 7eaedd6..0ed3623 100644 --- a/source/server/firstrun.md +++ b/source/server/firstrun.md @@ -7,20 +7,20 @@ 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" } +- { page: "recover", title: "Recovering the SP Database" } --- # First deployment of a Spectrum Protect Server (in a container) > **NOTES**: > * The following instructions are for a Spectrum Protect 8.1.4 instance. I used the same procedure described [here](/server) to build the Docker Image. The only difference is that I performed a new install using the installation media that would be available from Passport Advantage. (Thus it was just an install, not an 8.1.0 install and followed by a 8.1.4 upgrade). > * Make sure you follow the guidelines for space required as presented in the [Knowledge Center](https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.4/srv.install/t_srv_plan_capacity-linux.html). - Our Docker Image will have the SP database in `/database`, the instance user in `/tsm` and storage pools in `/data`. Ultimately these will be volumes provisioned from the host and using host storage, or your prefered Docker persistent volume storage technology. -> * The storage used in the example below is from the host filesystems, passed to the container with Docker's `-v` option. -> * This implementation is using DISK or CLOUD storage pool storage. While accessing tape should be possible, I havent explored what is required for that to work. + Our Docker Image will have the SP database in `/database`, the instance user in `/tsm` and storage pools in `/data`. Ultimately these will be volumes provisioned from the host and using host storage, or your preferred Docker persistent volume storage technology. +> * The storage used in the example below is from the host file systems, passed to the container with Docker's `-v` option. +> * This implementation is using DISK or CLOUD storage pool storage. While accessing tape should be possible, I haven't explored what is required for that to work. ## Configuration Our configuration will use these defaults -```bash Container Variables +```bash Helpful Variables TSM_DB=/srv/sp/database TSM_USER=/srv/sp/user TSM_DATA=/srv/sp/data @@ -33,7 +33,7 @@ TSM_DATA=/srv/sp/data ## First Run Init #1 -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. +The first init run will be to create the database layout, and to copy the initialise database (as performed when containerising 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 ibm/spectrumprotect:8.1.4 init1` @@ -75,6 +75,6 @@ ANR1912I Stopping the activity log because of a server shutdown. ANR0369I Stopping the database manager because of a server shutdown. ``` -**NOTE**: With 8.1.4 I noticed a lot of `DBI1306N` messages floating up the screen. That doesnt appear to be an actual problem. +**NOTE**: With 8.1.4 I noticed a lot of `DBI1306N` messages floating up the screen. That doesn't appear to be an actual problem. The "Init" steps will only need to be run the once for any "new" instance of SP. Thereafter, you'll start SP using the Normal steps documented [here](normalrun.html). diff --git a/source/server/index.md b/source/server/index.md index f675d92..027773f 100644 --- a/source/server/index.md +++ b/source/server/index.md @@ -7,7 +7,7 @@ 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" } +- { page: "recover", title: "Recovering the SP Database" } - { page: "runoc", title: "Running OC in a container" } --- # Putting Spectrum Protect into a Container @@ -18,19 +18,19 @@ related: For example if your storage driver is `devicemapper` then the default volume size `Base Device Size` may be 10GB, which wont be enough for a SP installation. You will need to increase it to at least 15GB - details on how to do that are outside of the scope of this document. > * Also make sure your host has sufficient memory to perform the build - SP requires at least 12GB of RAM to pass the installation logic. I actually perform the build on an iMac with 16GB of memory allocated to Docker. It is also using the `overlay` storage driver, which means the size of the volume the build container gets is the available free capacity of my /Users mount point. -> * The accompaning files for this build are available in my [gitlab](http://dev.leenooks.net/deon/spdocker/tree/master) -> * And lastly, most importantly, running SP in a container is **not officially supported by IBM** - so you cannot make a helpdesk call about having problems. +> * The accompanying files for this build are available in my [gitlab](http://dev.leenooks.net/deon/spdocker/tree/master) +> * And lastly, most importantly, running SP in a container is **not officially supported by IBM** - so you cannot make a help-desk call about having problems. Technically it should work without problems, but if you are experiencing a problem, be prepared to recreate your environment on a physical host and validate that your problem still exists (and thus not a result of Docker or the implementation on Docker). ## Create your Dockerfile -As at the time of writing these instructions, Red Hat linux is not available in the Docker hub - but CentOS is a good clone. We'll use it +As at the time of writing these instructions, Red Hat Linux is not available in the Docker hub - but CentOS is a good clone. We'll use it ### Image preparation ```Dockerfile FROM centos:7 ``` -Next we need to install some dependancies - these are documented in the [Knowledge Center](https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.4/srv.install/r_srv_lnx_sysreq_inst_x-linux.html) as a requirement for running SP on Linux. You might like to check to make sure these are still all that is required for newer releases of SP. +Next we need to install some dependencies - these are documented in the [Knowledge Center](https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.4/srv.install/r_srv_lnx_sysreq_inst_x-linux.html) as a requirement for running SP on Linux. You might like to check to make sure these are still all that is required for newer releases of SP. ```Dockerfile RUN yum -y install http://yum.leenooks.net/CentOS/7/base/redhat-release-7-6.el7.centos.12.2.x86_64.rpm \ @@ -41,11 +41,11 @@ RUN yum -y install http://yum.leenooks.net/CentOS/7/base/redhat-release-7-6.el7. yum clean all && rm -rf /var/tmp/* ``` -**NOTE**: During the installation of SP, it tests to make sure it is running on RedHat linux by testing the existence of an RPM package `redhat-release`. The redhat-release installed on line 1 is a fake RPM package - it installs no files, but just emulates the existance of that required RPM package. +**NOTE**: During the installation of SP, it tests to make sure it is running on RedHat Linux by testing the existence of an RPM package `redhat-release`. The redhat-release installed on line 1 is a fake RPM package - it installs no files, but just emulates the existence of that required RPM package. ### Spectrum Protect Installation -Now copy in our silent install configuration files. These files are based on the silent install xml files that come on the installation media. Some details on these files are also in the [Knowledge Center](https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.4/srv.install/t_srv_inst_silently-linux.html) +Now copy in our silent install configuration files. These files are based on the silent install XML files that come on the installation media. Some details on these files are also in the [Knowledge Center](https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.4/srv.install/t_srv_inst_silently-linux.html) ```Dockerfile COPY install.xml install-fp.xml /tmp/ ``` @@ -67,7 +67,7 @@ RUN SOURCE_URL=http://YOUR_SITE_URL_HERE && \ rm -rf /tmp/build /tmp/install*xml ``` -**NOTE**: Some information on what is occuring here. +**NOTE**: Some information on what is occurring here. * This is an "new install" (lines 1-6) then followed by an "upgrade" (lines 7-11). The reason for the new install first, is that the Spectrum Protect license files and license libraries are not available in upgrades (from Fix Central). So you'll need to install from your downloaded media from Passport Advantage, and then upgrade it to the latest release from Fix Central. If you sourced your installation media from Passport Advantage, then the license files and libraries are probably in that installation media, so you only need to run lines 1-6. * To avoid the resulting Docker Image being too large, we download the installation media from a web server (Line 3) and then delete it after it has been expanded (line 4). We also do the same for up upgrade package (lines 8 & 9). @@ -76,11 +76,11 @@ RUN SOURCE_URL=http://YOUR_SITE_URL_HERE && \ ### Spectrum Protect Post-Installation -Now we set our user environment that will utlimately run SP +Now we set our user environment that will ultimately run SP ```Dockerfile ENV USER=tsm USERDIR=/tsm USERID=201 GROUPID=201 ``` -**NOTE**: You can set these according to your enterprise policy. `USERDIR` will ultimately need to be persistant storage using your favourite storage provisioning methodology. I generally host mount when starting the container using `-v /host/path/user:/tsm` and it works well. I have used some 3rd party persistent storage offerings, however, they often have not worked. While I havent explored in detail why not, I suspect it is because of Direct IO calls being made by DB2 and those 3rd party offerings not supporting those sytem calls. +**NOTE**: You can set these according to your enterprise policy. `USERDIR` will ultimately need to be persistent storage using your favourite storage provisioning methodology. I generally host mount when starting the container using `-v /host/path/user:/tsm` and it works well. I have used some 3rd party persistent storage offerings, however, they often have not worked. While I haven't explored in detail why not, I suspect it is because of Direct IO calls being made by DB2 and those 3rd party offerings not supporting those system calls. Now we create our user @@ -141,6 +141,6 @@ REPOSITORY TAG IMAGE ID CREATED SIZE ibm/spectrumprotect 8.1.1 14aba816e231 2 minutes ago 2.96GB ``` **NOTES** -* Make sure you have enough space in your `/var/lib/docker` directory - the build will use about 9 GBs. +* Make sure you have enough space in your `/var/lib/docker` directory - the build will use about 9 GB's. Now that your container is built, you'll want to start it a specific way, depending on whether you are starting a clean new instance of SP, or an existing instance. Those details are [here](firstrun.html). diff --git a/source/server/normalrun.md b/source/server/normalrun.md index 669b6a0..83e0eb8 100644 --- a/source/server/normalrun.md +++ b/source/server/normalrun.md @@ -7,17 +7,17 @@ related: - { page: "index", title: "Containerising SP" } - { page: "firstrun", title: "Initial Container Setup" } - { page: "upgrade", title: "Upgrading SP" } -- { page: "recover", title: "Recoverying the SP Database" } +- { page: "recover", title: "Recovering the SP Database" } --- # Normal Run of a Spectrum Protect Server (in a container) > **NOTES**: -> * The storage used in the example below is from the host filesystems, passed to the container with Docker's `-v` option. -> * This implementation is using DISK or CLOUD storage pool storage. While accessing tape should be possible, I havent explored what is required for that to work. +> * The storage used in the example below is from the host file systems, passed to the container with Docker's `-v` option. +> * This implementation is using DISK or CLOUD storage pool storage. While accessing tape should be possible, I haven't explored what is required for that to work. ## Configuration Our configuration will use these defaults -```bash Container Variables +```bash Helpful Variables TSM_DB=/srv/sp/database TSM_USER=/srv/sp/user TSM_DATA=/srv/sp/data @@ -56,9 +56,9 @@ You should now be able to connect with the Admin Client. **NOTES**: * For Spectrum Protect you need to use `--privileged=true`. From what I have worked out, DB2 needs this. I did find some notes on DB2 in docker [here](https://www.ibm.com/developerworks/data/library/techarticle/dm-1602-db2-docker-trs/index.html), and tried these options without using `--privileged=true` but DB2 still reported some errors. - I dont think it is an issue running SP in privileged mode, but if you do find a solution to have it run without full privileges, I would be interested ;) + I don't think it is an issue running SP in privileged mode, but if you do find a solution to have it run without full privileges, I would be interested ;) The link above has some important tips regarding DB2 memory and the `--memory=` setting. * When defining your DISK based storage pools (or STGPOOLDIR for your cloud pools), remember the path to your "data" is `/data` inside the container. If you use another path, you will loose that data when the container is destroyed. -* You should be able to run many SP instances on the same host (or swarm) even at different version levels. In container, they can all respond to port 1500, and outside the container, they'll need to have unique ports eg: `-p 1501:1500`, `-p 1502:1500`, etc. (Just remember to think about resource requirements and potential resource contention.) +* You should be able to run many SP instances on the same host (or swarm) even at different version levels. In container, they can all respond to port 1500, and outside the container, they'll need to have unique ports EG: `-p 1501:1500`, `-p 1502:1500`, etc. (Just remember to think about resource requirements and potential resource contention.) * Use the same `--hostname=` setting that you used when running the *init* steps above. DB2 is sensitive to hostname changes. -* Spectrum Scale makes a great persistent storage filesytem for Docker containers, and gives you great optoins for Specturm Protect. For example, you could move SP to different hosts very easily (stop on hosta, start on hostb - if both hosts see the same Spectrum Scale file system and your database/data are on it). +* Spectrum Scale makes a great persistent storage file system for Docker containers, and gives you great options for Spectrum Protect. For example, you could move SP to different hosts very easily (stop on hosta, start on hostb - if both hosts see the same Spectrum Scale file system and your database/data are on it). diff --git a/source/server/runoc.md b/source/server/runoc.md index af4fbf3..dfb28df 100644 --- a/source/server/runoc.md +++ b/source/server/runoc.md @@ -1,30 +1,30 @@ --- title: Operations Center -header-img: img/header_img/server.jpg +header-img: img/header_img/oc.jpg date: 2018-03-07 09:50:12 -description: Operations Center in a Docker Container +description: Operations Centre in a Docker Container related: - { page: "index", title: "Containerising SP" } - { page: "runoc", title: "Running OC in a container" } --- > **NOTES** -> * Operations Center is a good fit for a container - especially in a cluster (eg: Swarm), it requires no persistent storage (other than the initial config). +> * Operations Centre is a good fit for a container - especially in a cluster (EG: Swarm), it requires no persistent storage (other than the initial config). > * Make sure your host has sufficient memory to perform the build - OC requires at least 4GB of RAM to pass the installation logic. -> * The accompaning files for this build are available in my [gitlab](http://dev.leenooks.net/deon/spdocker/tree/oc) -> * And lastly, most importantly, running SP in a container is **not officially supported by IBM** - so you cannot make a helpdesk call about having problems. +> * The accompanying files for this build are available in my [gitlab](http://dev.leenooks.net/deon/spdocker/tree/oc) +> * And lastly, most importantly, running SP in a container is **not officially supported by IBM** - so you cannot make a help-desk call about having problems. Technically it should work without problems, but if you are experiencing a problem, be prepared to recreate your environment on a physical host and validate that your problem still exists (and thus not a result of Docker or the implementation on Docker). -The process for Containerising OC is very similiar to [Containerising Spectrum Portect](index.html). +The process for Containerising OC is very similar to [Containerising Spectrum Protect](index.html). ## Create your Dockerfile -As at the time of writing these instructions, Red Hat linux is not available in the Docker hub - but CentOS is a good clone. We'll use it +As at the time of writing these instructions, Red Hat Linux is not available in the Docker hub - but CentOS is a good clone. We'll use it ### Image preparation ```Dockerfile FROM centos:7 ``` -Operations Center doesnt really need any dependancies - you can check the [Knowledge Center](https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.4/srv.install/c_oc_inst_reqs_os.html) for any updates. However, to pass the installation logic, we do need to have a redhat-release RPM installed. For CentOS it doesnt exist (CentOS calls it centos-release), so I created one. +Operations Centre doesn't really need any dependencies - you can check the [Knowledge Center](https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.4/srv.install/c_oc_inst_reqs_os.html) for any updates. However, to pass the installation logic, we do need to have a redhat-release RPM installed. For CentOS it doesn't exist (CentOS calls it centos-release), so I created one. ```Dockerfile RUN yum -y install http://yum.leenooks.net/CentOS/7/base/redhat-release-7-6.el7.centos.12.2.x86_64.rpm \ @@ -35,11 +35,11 @@ RUN yum -y install http://yum.leenooks.net/CentOS/7/base/redhat-release-7-6.el7. yum clean all && rm -rf /var/tmp/* ``` -**NOTE**: During the installation of SP, it tests to make sure it is running on RedHat linux by testing the existence of an RPM package `redhat-release`. The redhat-release installed on line 1 is a fake RPM package - it installs no files, but just emulates the existance of that required RPM package. +**NOTE**: During the installation of SP, it tests to make sure it is running on RedHat Linux by testing the existence of an RPM package `redhat-release`. The redhat-release installed on line 1 is a fake RPM package - it installs no files, but just emulates the existence of that required RPM package. ### Operations Centre Installation -Now copy in our silent install configuration files. These files are based on the silent install xml files that come on the installation media. Some details on these files are also in the [Knowledge Center](https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.4/srv.install/t_srv_inst_silently-linux.html) +Now copy in our silent install configuration files. These files are based on the silent install XML files that come on the installation media. Some details on these files are also in the [Knowledge Center](https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.4/srv.install/t_srv_inst_silently-linux.html) ```Dockerfile COPY install.xml install-fp.xml /tmp/ @@ -57,7 +57,7 @@ RUN SOURCE_URL=http://YOUR_SITE_URL_HERE && \ rm -rf /tmp/build /tmp/install*xml ``` -**NOTE**: Some information on what is occuring here. +**NOTE**: Some information on what is occurring here. * To avoid the resulting Docker Image being too large, we download the installation media from a web server (Line 3) and then delete it after it has been expanded (line 4). * Line 5 is the silent installation method for installing SP components. * Line 6 deletes any installation files to reduce the size of the resulting Docker Image. @@ -87,5 +87,5 @@ Now that your container is built, starting OC is simple `docker run --detach=true --interactive=false --link=spectrumprotect -v /serverConnection.properties:/opt/tivoli/tsm/ui/Liberty/usr/servers/guiServer/serverConnection.properties --memory=1g -p 11443:11443 --privileged=false --rm=false --restart=no --tty=false --name=spectrumprotectoc ibm/spectrumprotect-oc:8.1.1` ***NOTES***: -* The OC container needs to connect to your SP server(s). If your SP server is running in a container, you can use the `--link=` to link to the container name of your server (not necessarily required). If you are running your container in a cluster (eg: Docker Swarm), then you'll need to use the appropriate configuration for your cluster to do container-to-container networking. +* The OC container needs to connect to your SP server(s). If your SP server is running in a container, you can use the `--link=` to link to the container name of your server (not necessarily required). If you are running your container in a cluster (EG: Docker Swarm), then you'll need to use the appropriate configuration for your cluster to do container-to-container networking. * The `-v /serverConnection.properties:../serverConnection.properties` will saving you having to do a "setup" of OC if the container is ever stopped and destroy (this will happen in cluster environments). Make sure the file reference in the `-v` option is available on your cluster persistent storage. diff --git a/source/server/upgrade.md b/source/server/upgrade.md index 3a11201..77d49a1 100644 --- a/source/server/upgrade.md +++ b/source/server/upgrade.md @@ -7,20 +7,21 @@ 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" } +- { page: "recover", title: "Recovering 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. +> * The storage used in the example below is from the host file systems, 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. + 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. If upgrading that results in a version of DB2 changing (like v7 to v8) additional consideration needs to be made that has not yet been captured in my `upgrade` option below. (Upgrading from v7 to v8 failed for me because of DB2 issues that I wasn't able to resolve - DB2 changed versions between 7 and 8.) + After the upgrade Spectrum Protect is smart enough to realise that it has been upgraded and will do a one time schema update. +> * As always, make sure you have a back-out plan, in case things go pair shaped. Docker itself provides a great back-out option, especially if you use it with persistent 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. Spectrum Scale would also be a good choice. ## Configuration Our configuration will use these defaults -```bash Container Variables +```bash Helpful Variables TSM_DB=/srv/sp/database TSM_USER=/srv/sp/user TSM_DATA=/srv/sp/data @@ -33,50 +34,70 @@ TSM_DATA=/srv/sp/data # Upgrade Steps -## Backup SP +## Backup Spectrum Protect's Database `backup db type=FULL devclass= protectk=y pass= 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. +ANR0984I Process 143 for Database Backup started in the FOREGROUND at 14:48:02. ANR4559I Backup DB is in progress. -ANR2280I Full database backup started as process 8. +ANR2280I Full database backup started as process 143. 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. +ANR4550I Full database backup (process 143) completed. Total bytes backed up: 2,215,641,088. +ANR0985I Process 143 for Database Backup running in the FOREGROUND completed with completion state SUCCESS at 14:52:45. ANR2394I BACKUP DB: Server device configuration information was written to all device configuration files. -Protect: LEENOOKS>q volh type=dbb +Protect: SERVER1>q volh type=dbb ... - Date/Time: 08-03-2018 15:59:22 + Date/Time: 14-03-2018 14:48:04 Volume Type: BACKUPFULL - Backup Series: 246 + Backup Series: 253 Backup Operation: 0 Volume Seq: 100,001 Device Class: DBB - Volume Name: /data/dbb/20485162.DBV - + Volume Name: /data/dbb/20999284.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 +[root@host]# ls -aln $TSM_DATA/dbb/|grep 20999284 +-rw------- 1 201 201 2215642514 Mar 14 14:51 20999284.dbv ``` -## Stop SP +## Stop Spectrum Protect Stop your SP server. -`halt` +```plain Stop the SP Server +Protect: SERVER1>halt +ANR2234W This command will halt the server; if the command is issued from a remote client, it may not be possible to restart the server from the remote location. -**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. +Do you wish to proceed? (Yes (Y)/No (N)) y + +ANS8002I Highest return code was 0. + +[root@host]# +``` + +**NOTE**: Don't 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 hasn't 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 haven't explored what signals SP will act on. So as a recommendation, always use SP `halt` command to stop an SP server. ## 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. +```bash Using LVM Snapshot +[root@host]# df /srv/sp +Filesystem 1K-blocks Used Available Use% Mounted on +/dev/mapper/vgroot-lvprotect 20511356 10031500 9431280 52% /srv/sp + +[root@host]# lvcreate -s -L5G -n lvspsnapshot vgroot/lvprotect + Using default stripesize 64.00 KiB. + Logical volume "lvspsnapshot" created. +``` + +**NOTE**: If you are using IBM Spectrum Scale, you can use `mmcrsnapshot` + ## Delete your container `docker rm -v spectrumprotect` @@ -85,16 +106,67 @@ If you can snapshot your persistent storage that you provide to the SP Docker Co ### 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` +`docker run --detach=true --hostname=tsm --interactive=false -v $TSM_USER:/tsm -v $TSM_DB:/database --privileged=true --rm=false --tty=false --name=spectrumprotect ibm/spectrumprotect:8.1.4 upgrade` + +**NOTE**: You can see the console by running `docker logs -f spectrumprotect` to make sure the upgrade works as expected. Once you see success, you can delete the container with `docker rm -v spectrumprotect`. + +```bash Expected Output +[root@host]# docker logs -f spectrumprotect +DB2 installation is being initialized. + + Total number of tasks to be performed: 4 +Total estimated time for all tasks to be performed: 309 second(s) + +Task #1 start +Description: Setting default global profile registry variables +Estimated time 1 second(s) +Task #1 end +... +The execution completed successfully. + +For more information see the DB2 installation log at "/tmp/db2iupdt.log.5". +DBI1446I The db2iupdt command is running. + + +DBI1070I Program db2iupdt completed successfully. +``` ### Normal Run +Spectrum Protect is ready to run on the new version as normal. The first time it runs at a later release, you should see some `ANR0276I` messages. + `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 +ANR7800I DSMSERV generated at 16:03:41 on Nov 17 2017. + +IBM Spectrum Protect for Linux/x86_64 +Version 8, Release 1, Level 4.000 + +Licensed Materials - Property of IBML + +(C) Copyright IBM Corporation 1990, 2017. +All rights reserved. +U.S. Government Users Restricted Rights - Use, duplication or disclosure +restricted by GSA ADP Schedule Contract with IBM Corporation. + +ANR7801I Subsystem process ID is 7. +... +ANR0275I Detected schema change for table SD.Pool.Clusters, attempting to +reconcile. +ANR0276I Schema reconciliation for table SD.Pool.Clusters succeeded. +ANR0275I Detected schema change for table SD.Containers, attempting to +reconcile. +ANR0276I Schema reconciliation for table SD.Containers succeeded. +ANR0275I Detected schema change for table SD.Replicated.Stgpools, attempting to +reconcile. +ANR0276I Schema reconciliation for table SD.Replicated.Stgpools succeeded. +... +IBM Spectrum Protect:SERVER1> ``` +I did this on the lab server, and while admittedly it doesn't have much data - the whole "upgrade" process took 12 minutes after the DB backup was complete - and that was with me documenting it for this wiki. So it could have been quicker! + 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 something did go pear shaped, 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 ` option - you'll need a DBDIRS.TXT file as well in the instance home directory. More info on recovering [here](recover).