v2.8.2
Model9 WebsiteSupportGravityFAQ
Search
⌃K
Links

Installing the Model9 management server on zCX

Prepare the environment for installation of the server on zCX by following these steps

Prerequisites

License key

Obtain a license key from Model9 by opening a “new 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.
Required Container version:
docker ==> (version 18 or above) or
podman ==> (version 4.4.1 or above)

zCX Configuration

  1. 1.
    Verify that the zCX instance has at least 8GB of memory.
  2. 2.
    Verify zCX container disk space
    1. 1.
      Verify that the zCX ROOT filesystem has at least 8GB of storage space.
    2. 2.
      Verify that the zCX DATA filesystem has at least 40GB of storage space (Extra data volumes can be added dynamically after instance creation).
    The following operator command can be used to display the allocated disk space MODIFY container_name,DISPLAY,DISK
Docker
  1. 1.
    Create docker volumes for the Model9 management server and database:
    docker volume create model9
    docker volume create model9db
    docker volume create model9db_initdb
  2. 2.
    Create a docker instance of alpine Linux to unzip and edit the installation files. Note: If your zCX container does not have internet access you will have to download and load the alpine image manually
    # Running an alpine container and mounting the model9 docker volume
    docker run -d --rm --name dummy \
    -v model9:/root \
    -v model9db_initdb:/docker-entrypoint-initdb.d \
    s390x/alpine tail -f /dev/null
  3. 3.
    Upload the s390x installation zip to the zCX instance using scp or any other tool in binary mode.
  4. 4.
    Copy the s390x installation zip from the zCX instance to the alpine container (one line):
    docker cp model9-v2.8.2_build_ebcddfb-server-s390x.zip dummy:/root/model9-v2.8.2_build_ebcddfb-server-s390x.zip

Step 1: Unzip the installation file

Create the filesystem hierarchy using the following commands:
docker exec -it dummy sh
cd /root
unzip /root/model9-v2.8.2_build_ebcddfb-server-s390x.zip
​
# Create the diag directory
mkdir diag
​
# Update the docker-entrypoint-initdb.d directory
cp conf/docker-entrypoint-initdb.d/* /docker-entrypoint-initdb.d
​
# Logout of Alpine container (CTRL+D)

Step 2: Copy the containers to the zCX instance

Copy the docker containers from the alpine docker container:
docker cp dummy:/root/model9-v2.8.2_build_ebcddfb-s390x.docker ./
docker cp dummy:/root/postgres-14.5-s390x.docker.gz ./

Step 3: Load the docker container to the zCX instance

Create the filesystem hierarchy using the following commands:
docker load -i model9-v2.8.2_build_ebcddfb-s390x.docker
docker load -i postgres-14.5-s390x.docker.gz

Step 4: Start the Model9 database container

  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:
    docker run --shm-size=256m -p 127.0.0.1:5432:5432 \
    -v model9db:/var/lib/postgresql/data:z \
    -v model9db_initdb:/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

Step 5: Update the Model9 management server parameters file

Login to the alpine container and edit the model9-local-yml file:
docker exec -it dummy sh
cd /root
vi conf/model9-local.yml
#Logout of Alpine container (CTRL+D)
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>"
model9.master_agent.port: <port>
​
# model9.objstore.resources.container.name: model9-data
# model9.objstore.endpoint.api.id: s3
model9.objstore.endpoint.url: http://minio:9000
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>
​
dataSource.user: postgres
dataSource.password: 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.
    Note
    Specifying a distributed virtual IP address (Distributed VIPA) can provide high availability by allowing the use of agent groups and multiple agents. See the Administrator and User Guide for more details.
  4. 4.
    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.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. 5.
    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)
    ​
  6. 6.
    DataSource - DB connection information.

Step 6: Starting the Model9 server

Once the object storage is available and the PostgreSQL container is running, start the server:
docker run -d -p <zCX-VIPA>:443:443 -p <zCX-VIPA>: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:/model9:z -h $(hostname) --restart unless-stopped \
-e "TZ=America/New_York" \
-e "CATALINA_OPTS=-Xmx2048m" \
--network model9network \
--name model9-v2.8.2 model9:v2.8.2.ebcddfb
Replace <zCX-VIPA> with the zCX instance VIPA
When running policies with over 100k objects, update the heap size to Xmx4096m in the docker run command using the CATALINA_OPTS parameter
By default, Model9 uses ports 80 and 443 for the management server. If these ports are not available for use or you wish to use different ports update the -p parameters to use different ports. For example, in order to use port 8080 and port 8443 update the parameters as follows:
-p <zCX-VIPA>:8443:443 -p <zCX-VIPA>:8080:80
Previous
Installing the Model9 Management Server
Next
Installing the Model9 agent
Last modified 1mo ago