v2.7.0
Model9 WebsiteSupportGravityFAQ
Search
⌃K
Links

Installing the Model9 Management Server

Prerequisites

Prepare the environment for installation of the server by following these steps:
License key
Obtain a license key from Model9 by opening a “License Request" in the Model9 service portal: https://model9.atlassian.net/servicedesk/customer/portals​
The output of the z/OS command “D M=CPU” is required.
Firewall
Configure the local firewall to allow connections to ports needed by the Model9 containers. For a list of required ports, see the Model9 Before You Install page.
Modify the firewall settings to all the above-mentioned port connections, or make sure the local firewall is disabled, using the following commands:
#UBUNTU
sudo systemctl stop ufw
sudo systemctl disable ufw
#RHEL
sudo systemctl stop firewalld
sudo systemctl disable firewalld
#SUSE
sudo systemctl stop SuSEfirewall2
sudo systemctl disable SuSEfirewall2
If Docker is already installed, restart the Docker service using the following command:
sudo systemctl restart docker
Docker
  1. 1.
    Verify that the Docker is enabled using the following command:
    sudo systemctl status docker
  2. 2.
    Verify that the Docker is “enabled” and “active (running)” as shown in the following example:
    ​
    image5.png
    ​
    ​
  3. 3.
    If the Docker service is not enabled or active, use the following commands to enable and activate it:
    sudo systemctl enable docker
    sudo systemctl start docker
  4. 4.
    Make sure that the expected output of Docker is displayed, by issuing the following command:
    sudo docker ps
The following output is expected:
Note
The server installation is shipped as a Docker container, see the Docker Security documentation for additional information.
File system
The Model9 files should reside on a separate file system (other than the root file system) with enough free space to accommodate the Model9 management server and database. It is recommended to use the xfs filesystem type. Contact your Linux administrator to allocate adequate space and ensure it is mounted.
This procedure is intended for new and unmounted block devices only. It will overwrite any data that might already exist on the device.
Installation files
Upload the model9-server-home zip installation file to the designated server in binary mode. Select one of the two available files according to your environment:
Environment
Installation file
x86
model9-v2.7.0_build_caf1b68-server.zip
Linux on z
model9-v2.7.0_build_caf1b68-server-s390x.zip

Step 1: Unzip the installation file

Create the filesystem hierarchy using the following commands:
# Change user to root
sudo su -
# Define the path to model9 installation files you uploaded earlier
export M9INSTALL=/<path>
# If you haven’t done so already, set the model9 target installation path
export MODEL9_HOME=/data/model9
# Change the directory to $MODEL9_HOME
cd $MODEL9_HOME
​
# Create the diag directory
mkdir diag
​
# Unzip the server’s installation file
​
# On Linux issue:
unzip $M9INSTALL/model9-v2.7.0_build_caf1b68-server.zip
# On Linux on z issue:
unzip $M9INSTALL/model9-v2.7.0_build_caf1b68-server-s390x.zip
Verify the $MODEL9_HOME/diag directory exists

Step 2: Deploy the Model9 management server’s components

  1. 1.
    Deploy the application components using the following commands:
    # On Linux issue:
    docker load -i $MODEL9_HOME/model9-v2.7.0_build_caf1b68.docker
    docker load -i $MODEL9_HOME/postgres-14.5-x86.docker.gz
    ​
    # On Linux on z issue:
    docker load -i $MODEL9_HOME/model9-v2.7.0_build_caf1b68-s390x.docker
    docker load -i $MODEL9_HOME/postgres-14.5-s390x.docker.gz

Optional: Replace the default self-signed certificate

The base installation provides a self-signed certificate for encrypting access to the user interface. To replace the default certificate for the web UI, see Secure web browser communication. Communications between the Model9 Server and the Model9 Agent are encrypted by default and further action should only be taken if site certificates are preferred.

Optional: Obfuscate the object storage credentials

Model9 allows obfuscating the object storage secret key so it won't appear in clear text within the configuration files.
The obfuscation utility resides in the $MODEL9_HOME/Utilities directory. To run the utility issue the following command:
$MODEL9_HOME/Utilities/model9-obfuscator.sh <object storage secret key>
The outcome of the script is an obfuscated version of the object storage secret key. For example:
[[email protected] Utilities]# ./model9-obfuscator.sh objstoresecret
/model9/Utilities/model9-credential-encryptor model9-obfuscator.sh
15:24:59.677 INFO [i.m.c.Model9CredentialEncryptorEntryPoint-main] - *******************************************************************************
15:24:59.679 INFO [i.m.c.Model9CredentialEncryptorEntryPoint-main] - * Model9 Credential Encryptor *
15:24:59.679 INFO [i.m.c.Model9CredentialEncryptorEntryPoint-main] - * Website: https://www.model9.io *
15:24:59.679 INFO [i.m.c.Model9CredentialEncryptorEntryPoint-main] - * Contact: [email protected] *
15:24:59.679 INFO [i.m.c.Model9CredentialEncryptorEntryPoint-main] - * 2016-2021 (c) Model9 Software *
15:24:59.679 INFO [i.m.c.Model9CredentialEncryptorEntryPoint-main] - *******************************************************************************
15:24:59.702 INFO [i.m.c.Model9CredentialEncryptorEntryPoint-main] - Encrypting...
15:24:59.785 INFO [i.m.c.Model9CredentialEncryptorEntryPoint-main] - Encrypted: rNEiN6QZB+OrmDMZBSXYX4F0OlrtWBSbhEJAfU6LfwCPGrW7HsRMZw5599guVIs5
Use the obfuscated key when setting the object storage password for the server and the agent(s). If using the obfuscated secret add the following setting to the server's configuration file:
model9.objstore.endpoint.password_encrypted: true

Step 3: Update the Model9 management server parameters file

The model9-local.yml file residing in the $MODEL9_HOME/conf/ path contains some of the default parameters. You can update them if necessary. Some of the parameters are explained below:
model9.licenseKey: <license-key>
​
model9.home: '${MODEL9_HOME}'
​
model9.security.dataInFlight.skipAgentHostNameVerification: true
​
model9.security.dataInFlight.truststore.fileName: '${MODEL9_HOME}/keys/model9-backup-truststore.jks'
model9.security.dataInFlight.truststore.type: "JKS"
model9.security.dataInFlight.truststore.password: "model9"
model9.security.dataInFlight.keystore.fileName: '${MODEL9_HOME}/keys/model9-backup-server.p12'
model9.security.dataInFlight.keystore.type: "PKCS12"
model9.security.dataInFlight.keystore.password: "model9"
​
model9.session.timeout.minutes: 30
​
model9.master_agent.name: "<ip_address_or_DNS>"
model9.master_agent.port: <port>
​
# model9.objstore.resources.container.name: model9-data
# model9.objstore.endpoint.api.id: s3
model9.objstore.endpoint.url: https://<object store URL/IP>:8443
model9.objstore.endpoint.userid: <object store access key>
model9.objstore.endpoint.password: <object store secret>
model9.objstore.endpoint.password_encrypted: <false|true>
​
model9.runlogs.expirationScanIntervalMinutes: <min>
model9.runlogs.maxRetentionPeriodDays: <days>
​
model9.parallelism.tapeMounts.numberOfThreads: 3
​
dataSource.user: postgres
dataSource.password: model9
dataSource.url: jdbc:postgresql://model9db:5432/model9
  1. 1.
    License Key – A valid Model9 license key as obtained in the prerequisites section. When using multiple keys for multiple CPCs, specify one of the keys in the server’s yml file. The server-initiated actions are carried out by the agent using its own defined license. The license key specified for the server is used for displaying a message regarding the upcoming expiration of the license.
  2. 2.
    Session timeout minutes - Specify the number of minutes following which an inactive UI session will end. The default is 30 minutes.
  3. 3.
    Master Agent – The agent running on z/OS which verifies the UI login credentials, hostname, IP address, and port number.
Specifying a distributed virtual IP address (Distributed VIPA) can provide high availability by allowing the use of agent groups and multiple agents. See Managing Agents for more details.
4. Objstore endpoint – object storage information including:
Parameter
Description
Required
Value
model9.objstore.resources.container.name
Container/bucket name
no
default: model9-data
model9.objstore.endpoint.url
URL address of local or remote object storage, both HTTP and HTTPS** are supported
yes
default: none
Amazon AWS*: https://s3.amazonaws.com​
Google Cloud Storage: https://storage.googleapis.com​
model9.objstore.endpoint.userid
Access key to object storage
yes
default: none
model9.objstore.endpoint.password
Secret key to object storage
yes
default: none
model9.objstore.endpoint.password_encrypted
Determine if the object storage password is obfuscated or not
no
default: false
model9.objstore.endpoint.api.id
The object storage API name
no
default: s3
Amazon AWS*: aws-s3
Microsoft Azure: azureblob
model9.objstore.endpoint.api.s3.calculatemd5
Enable MD5 checksum calculation to be included in putObject requests *This is required for Object Lock enabled buckets
no
default: false Accepted values: true/false
model9.objstore.endpoint.api.s3.v4signatures
When using object storage that uses V4 signatures, set this parameter to ‘true’ in addition to api.id: s3
no
Default: false
Cohesity: true
HCP-CS: true
model9.objstore.endpoint.no.verify.ssl
When using the HTTPS protocol, whether to avoid SSL certificate verifications
no
default: true
* When using Amazon S3, see AWS S3 security considerations.
** Using HTTPS for the object storage URL parameter enables Data-in-Flight encryption.
5. Indirect datasets expiration​
​Parameter​
​Description​
​Required​
​Value​
​model9.parallelism.indirectsExpiration.numberOfThreads​
​This parameter allows configuring the size of the thread pool which handles the expiration of indirect datasets during Full Dump expiration.​
​no​
​1​
6. Run logs expiration - Setting these parameters will trigger an automatic deletion of run logs from the server. Please note that the deletion is non-recoverable. The automatic deletion will not be executed as long as one of the following parameters is set to (-1):
Parameter
Description
Required
Value
model9.runlogs.expirationScanIntervalMinutes
This parameter determines the frequency of running the deletion process of old run logs.
no
default: -1 (never)
model9.runlogs.maxRetentionPeriodDays
This parameter determines after how many days a run log will expire and can be deleted by the automatic deletion process.
no
default: -1 (never)
7. Cloud Data Set Import settings:
Parameter
Description
Required
Value
model9.parallelism.tapeMounts.numberOfThreads
This parameter determines the amount of parallel tape mounts per policy
no
default: 3
8. Datasource - DB connection information.

Step 4: Create a Model9 environmental variables file

Model9 management server loads its environmental variables from a file called model9.env that needs to be created in the $MODEL9_HOME/conf directory. This file can be used to set simple (non-array) environment variables and simplify the way that you start the server. It can also give you a point of reference to the variables that the management server was started with
  1. 1.
    Create the file model9.env in the $MODEL9_HOME/conf directory
  2. 2.
    Add the following parameters in model9.env
    TZ=America/New_York
    EXTRA_JVM_ARGS=-Xmx2048m
  3. 3.
    When running policies with over 100k objects, update the heap size to Xmx4096m in the model9.env file.
  4. 4.
    Edit the time zone (TZ) setting to ensure proper scheduling in the model9.env file.
  5. 5.
    Save the file
If you make a change to any of the parameters in the environment variables file, you will need to stop and remove the server docker container and issue the docker run command again.

Step 5: Start the Model9 Management Server

  1. 1.
    Create a Docker network bridge using the following command:
    docker network create -d bridge model9network
  2. 2.
    Start the Model9 PostgreSQL database container using the following command:
    # On Linux issue:
    docker run -p 127.0.0.1:5432:5432 \
    -v $MODEL9_HOME/db/data:/var/lib/postgresql/data:z \
    -v $MODEL9_HOME/conf/docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d:z \
    --name model9db --restart unless-stopped \
    --network model9network \
    -e POSTGRES_PASSWORD=model9 -e POSTGRES_DB=model9 -d postgres:14.5
    ​
    # On Linux on z issue:
    docker run -p 127.0.0.1:5432:5432 \
    -v $MODEL9_HOME/db/data:/var/lib/postgresql/data:z \
    -v $MODEL9_HOME/conf/docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d:z \
    --name model9db --restart unless-stopped \
    --network model9network \
    -e POSTGRES_PASSWORD=model9 -e POSTGRES_DB=model9 -d s390x/postgres:14.5
  3. 3.
    Verify the health status of the container and make sure it is ready to accept connections by issuing the following command and verifying its output as shown in the following example:
    docker logs model9db
3. Start the server
4. Once the object storage is available and the PostgreSQL container is running, start the server using the following command:
# On Linux issue:
docker run -d -p 0.0.0.0:443:443 -p 0.0.0.0:80:80 \
--sysctl net.ipv4.tcp_keepalive_time=600 \
--sysctl net.ipv4.tcp_keepalive_intvl=30 \
--sysctl net.ipv4.tcp_keepalive_probes=10 \
-v $MODEL9_HOME:/model9:z -h $(hostname) --restart unless-stopped \
--env-file $MODEL9_HOME/conf/model9.env \
--network model9network \
--name model9-v2.7.0 model9:v2.7.0.caf1b68
​
# On Linux on z issue:
docker run -d -p 0.0.0.0:443:443 -p 0.0.0.0:80:80 \
--sysctl net.ipv4.tcp_keepalive_time=600 \
--sysctl net.ipv4.tcp_keepalive_intvl=30 \
--sysctl net.ipv4.tcp_keepalive_probes=10 \
-v $MODEL9_HOME:/model9:z -h $(hostname) --restart unless-stopped \
--env-file $MODEL9_HOME/conf/model9.env \
--network model9network \
--name model9-v2.7.0 model9:v2.7.0.caf1b68
5. View the PostgreSQL and Model9 Server logs using the following commands:
# Dump logs to screen
cat /data/model9/logs/model9.*.log
docker logs model9db
# Dump logs to screen and keep displaying new log messages as they arrive
tail -f /data/model9/logs/model9.*.log
docker logs -f model9db
6. View the container’s logs by using the tail command to verify that the Model9 container has started up successfully. For example:
2020-09-29 01:56:44,719 [main] INFO zosbackupserver.ApdplicationLoader - The following profiles are active: production
2020-09-29 01:56:45,873 [main] INFO zosbackupserver.Application - Loading external configuration from /model9/conf/model9-local.yml
2020-09-29 01:57:08,860 [main] INFO z.l.AddProjectionsToAllLiveArchivesAndDeleteExpired - Using container: model9-ci
2020-09-29 01:57:09,929 [main] INFO z.l.AddProjectionsToAllLiveArchivesAndDeleteExpired - Migration complete. Created 0 expiration projections. Deleted 0 archive versions
2020-09-29 01:57:09,937 [main] INFO z.l.BlobRepositoryChangeDashMetadataKeysToUnderscore - Using container: model9-ci
2020-09-29 01:57:10,165 [main] INFO i.m.b.c.o.BucketValidator - Object store connectivity has been established successfully
2020-09-29 01:57:10,413 [main] INFO zosbackupserver.BootStrap - Model9 Version: v2.7.0 Build caf1b68 Started
2020-09-29 01:57:13,799 [main] INFO zosbackupserver.ApplicationLoader - Started ApplicationLoader in 30.488 seconds (JVM running for 39.514)[1]
7. The installation is complete. To stop, start or restart the server:
docker stop|start|restart model9-v2.7.0
docker stop|start|restart model9db
8. Display the server’s resource consumption using the following commands:
docker stats model9-v2.7.0
docker stats model9db
9. Display the containers’ health status with the following command, and check the relevant logs if necessary:
docker ps -a

Optional: Install the Stand-Alone Program for Stand-Alone Restore

Model9 full volume dumps can be used for stand-alone restore. To prepare a Bare-Metal recovery restorable volume, the stand-alone program must be installed on the server. The UI provides a special action to prepare a stand-alone copy from a regular full volume dump. The installation guide describes the required steps for enabling the creation of stand-alone copies. See the Model9 User and Administrator Guide for:
  1. 1.
    How to prepare a Stand-Alone copy.
  2. 2.
    How to perform a Stand-Alone restore.
Creating a Stand-Alone Copy - Requirements
Creating a stand-alone copy requires the following DFDSS files to be saved in the $MODEL9_HOME/SAbackup path:
  • DFSMSDSS.ins
  • DFSMSDSS.IMAGE
  • DFSMSDSS.PREFIX
These files can be obtained from the IBM Customized Offering Driver which can be downloaded from ShopZ free of charge.
Do not change the names or letter case of the DFSMSDSS files.
Stand-Alone Restore using FTP - Requirements
To perform a stand-alone restore from removable media accessed via FTP, install the VSFTPD default server using the following command:
#Ubuntu
sudo apt-get install vsftpd
​
#RHEL
sudo yum install vsftpd
A local user with sudopermissions can run the following systemctl commands to enable and start the service:
sudo systemctl enable vsftpd
sudo systemctl start vsftpd
Do not change the names or letter case of the DFSMSDSS files.
Stand-Alone Restore from a USB - Requirements
The USB device should be formatted using the FAT32 file system and can reside in any directory except for the root path.
Installing and Upgrading - Previous
Installing and Upgrading
Next
Installing the Model9 management server on zCX
Last modified 11d ago