Container Deployment Foundation

Software Version: 2019.05

Planning Guide [DRAFT]

July 5, 2019
Planning Guide [DRAFT]

Legal Notices
Warranty
The only warranties for Micro Focus products and services are set forth in the express warranty statements accompanying
such products and services. Nothing herein should be construed as constituting an additional warranty. Micro Focus shall
not be liable for technical or editorial errors or omissions contained herein.
The information contained herein is subject to change without notice.
The network information used in the examples in this document (including IP addresses and hostnames) is for illustration
purposes only.
ArcSight products are highly flexible and function as you configure them. The accessibility, integrity, and confidentiality of
your data is your responsibility. Implement a comprehensive security strategy and follow good security practices.
This document is confidential.

Restricted Rights Legend

Confidential computer software. Valid license from Micro Focus required for possession, use or copying. Consistent with FAR
12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial
Items are licensed to the U.S. Government under vendor's standard commercial license.

Copyright Notice
© Copyright 2019 Micro Focus or one of its affiliates
Confidential computer software. Valid license from Micro Focus required for possession, use or copying. The
information contained herein is subject to change without notice.
The only warranties for Micro Focus products and services are set forth in the express warranty statements
accompanying such products and services. Nothing herein should be construed as constituting an additional
warranty. Micro Focus shall not be liable for technical or editorial errors or omissions contained herein.
No portion of this product's documentation may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording, or information storage and retrieval systems, for any
purpose other than the purchaser's internal use, without the express written permission of Micro Focus.
Notwithstanding anything to the contrary in your license agreement for Micro Focus ArcSight software, you may
reverse engineer and modify certain open source components of the software in accordance with the license terms
for those particular components. See below for the applicable terms.
U.S. Governmental Rights. For purposes of your license to Micro Focus ArcSight software, “commercial computer
software” is defined at FAR 2.101. If acquired by or on behalf of a civilian agency, the U.S. Government acquires this
commercial computer software and/or commercial computer software documentation and other technical data
subject to the terms of the Agreement as specified in 48 C.F.R. 12.212 (Computer Software) and 12.211 (Technical
Data) of the Federal Acquisition Regulation (“FAR”) and its successors. If acquired by or on behalf of any agency
within the Department of Defense (“DOD”), the U.S. Government acquires this commercial computer software
and/or commercial computer software documentation subject to the terms of the Agreement as specified in 48
C.F.R. 227.7202-3 of the DOD FAR Supplement (“DFARS”) and its successors. This U.S. Government Rights Section
18.11 is in lieu of, and supersedes, any other FAR, DFARS, or other clause or provision that addresses government
rights in computer software or technical data.

Micro Focus Container Deployment Foundation 2019.05 Page 2 of 45

Planning Guide [DRAFT]

Support
Contact Information
Phone A list of phone numbers is available on the Technical Support
Page: https://softwaresupport.softwaregrp.com/support-contact-information

Support Web Site https://softwaresupport.softwaregrp.com/

Micro Focus Product Documentation https://community.softwaregrp.com/t5/ArcSight-Product-Documentation/ct-

p/productdocs

Micro Focus Container Deployment Foundation 2019.05 Page 3 of 45

Planning Guide [DRAFT]

Contents
Overview 6
Chapter 1: Choosing a Deployment Infrastructure 7
About Master Nodes 7
About Worker Nodes 8
Use of Kubernetes and Docker 8
Use of Kafka 8
Deployment Architectures 8
Multiple Master and Multiple Worker Deployment 9
Single Master and Multiple Worker Node Deployment 10
Shared Master and Worker Node 11
Chapter 2: Prepare Infrastructure for Deployment 12
Implementation Roles and Responsibilities 13
Deployment Considerations and Best Practices 13
Provision and Prepare the Master and Worker Nodes 15
Network Identification 16
Secure Communication Between Micro Focus Components 17
Network File System (NFS) Requirements 18
Supported Browsers 19
Supported Screen Resolutions 19
Supported Languages 19
File System Requirements 20
Set System Parameters (Network Bridging) 21
Check MAC and Cipher Algorithms 22
Check Password Authentication Settings 22
Ensure Required OS Packages Are Installed 23
Remove Libraries 24
System Clock 24
Systems Clock Examples 24
Open Port Requirements 24
Firewall Settings 25
Proxy Settings 26
Proxy Settings Examples 26
DNS Configuration 27
Test Forward and Reverse DNS Lookup 27
Kubernetes Network Subnet Settings 28

Micro Focus Container Deployment Foundation 2019.05 Page 4 of 45

Planning Guide [DRAFT]

Configure the NFS Server Environment 29

NFS Prerequisites 29
NFS Directory Structure 30
Export the NFS Configuration 31
Testing NFS 32
NFS Setup Using a Script 32
Disable Swap Space 32
Create Docker Thinpools (optional) 33
Next Steps 35
Appendix A: CDF Planning Checklist 36
Appendix B: Enabling Installation Permissions for a sudo User 38
Edit the sudoers File on the Initial Master Node (only) 38
Installing Components Using the sudo User 39
Edit the sudoers File on the Remaining Master and Worker Nodes 39
Glossary 41

Send Documentation Feedback 45

Micro Focus Container Deployment Foundation 2019.05 Page 5 of 45

Planning Guide [DRAFT]

Overview
This CDF Planning Guide will provide instructions on preparing your infrastructure environment for
security products installed using Micro Focus’ Container Deployment Foundation (CDF).
CDF enables customers to install pre-integrated application capabilities. The distribution unit for
software delivery is the container, leveraging the speed and format of the containerized environment.
By bundling an orchestration layer to bootstrap and manage the life-cycle of many suite-related
containers, CDF supports standardized deployment, built-in upgrades and patching, seamless scaling,
and rollbacks.
Several Micro Focus security products run on the CDF platform as a suite of applications. These
applications include:
l Transformation Hub
l ArcSight Investigate
l Identity Intelligence
l Analytics (a prerequisite for ArcSight Investigate and Identity Intelligence)
For more information about a product's compatibilty with this version of the CDF installer (version
2019.05) , consult the product's Release Notes, available on the Micro Focus support community.

Micro Focus Container Deployment Foundation (2019.05) Page 6 of 45

Planning Guide [DRAFT]

Chapter 1: Choosing a Deployment Infrastructure

All container-based products and capabilities run within the Container Deployment Foundation (CDF)
infrastructure, which comprises Kubernetes and Docker container foundational management. After
successfully preparing host system prerequisites as described in this guide, you will be ready to launch
the CDF Installer. The CDF Installer deploys and manages upgrades and configurations of container-
based security products.
The CDF Installer will validate minimum infrastructure requirements and then configure, install and start
the services associated with the security products chosen during the installation process. You can install
the security products as a root user, or optionally as a sudo user. (For more information on granting
permissions for installing as a sudo user, see Appendix B.)
There are 2 primary deployment configurations, each of which depends on whether the deployment
requires high availability or not. While it is recommended that all deployments be highly available, you
may decide that development or testing environments don’t necessarily require redundancy and
failover.
The number of host systems required will depend on the architecture chosen, types of which are
described below.

Note: Appendix A includes a checklist for your use to track your progress implementing your
preparation.

About Master Nodes

The Kubernetes Master Nodes control the cluster, manage its workload and directs communication
across the system.
In order to ensure high availability of cluster services, a minimum of 3 Master Nodes must be
deployed. Deployment of multiple Master Nodes is strongly recommended for all environments,
especially highly available environments. When deployed in this manner, a failure of one Master Node
will fail over to one of the other Master Nodes.
Should a single Master Node be deployed instead of the recommended 3 Master Nodes, any failure of
the single Master Node will cause the entire cluster to fail, including all Worker Nodes. In such cases, the
entire cluster may become unrecoverable, requiring a complete reinstall and reconfiguration of the
entire cluster.
While it is possible to run a cluster with only 2 Master Nodes, it is not recommended. If the primary
Master Node is taken offline for maintenance or upgrade, there will only be a single Master Node
available during this time and any failure to the running Master Node will result in the entire cluster
failing.

Micro Focus Container Deployment Foundation (2019.05) Page 7 of 45

Planning Guide [DRAFT]

Adding Master Nodes after the cluster has been initially deployed is not supported. You must
decide before deploying the cluster whether multiple Master Nodes will be initially deployed.

About Worker Nodes

The Worker Nodes run the application components and perform the work in the cluster. A minimum of 3
dedicated Worker Nodes are recommended for all highly available deployment configurations.
Worker Nodes can be added or removed from the cluster as needed. Scaling the cluster to perform more
work requires additional Worker Nodes, all of which are managed by the Master Nodes.

Use of Kubernetes and Docker

Kubernetes automates deployment, scaling, maintenance and management of containerized
applications across a cluster of host systems.
Applications running in Kubernetes are defined as “pods”, which groups containerized components.
Clusters use Docker Containers as these components. A pod consists of one or more containers that are
guaranteed to be co-located on the host server and can share resources. Each pod in Kubernetes is
assigned a unique IP address within the cluster, allowing applications to use ports without the risk of
conflict. Persistent services for a pod can be defined as a volume, such as a local disk directory or a
network disk, and exposed by Kubernetes to the containers in the pod to use. A cluster relies upon an
exernal Network File System (NFS) as its persistent storage.

Use of Kafka
Kafka is a messaging system that publishes messages for subscribers to consume on its scalable
platform built to run on servers. It is commonly referred to as a message broker.
This middleware is used to decouple data streams from processing, translate and enrich event data, and
to buffer unsent messages. Kafka improves on traditional message brokers through advances in
throughput, built-in partitioning, replication, latency and reliability.

Deployment Architectures
CDF installation supports the following deployment architectures, which are detailed in the following
sections:
l Multiple Master and Multiple Worker Nodes
l Single Master with Multiple Worker Nodes
l Shared Master and Worker Node

Micro Focus Container Deployment Foundation (2019.05) Page 8 of 45

Planning Guide [DRAFT]

Multiple Master and Multiple Worker Deployment

In this deployment, Master and Worker Nodes are dedicated to a specific OS instance. This
configuration can be run in development and testing, and it is the recommended configuration for
highly available environments. Events are processed by the Worker Nodes, with failover to another
Worker Node in the event of a Worker failure. There are no single points of failure.
A minimum of 6 physical or VM environments are needed (3 dedicated Master Nodes and 3 or more
dedicated Worker Nodes), plus a customer-provisioned NFS server, referred to in this documentation as
External NFS.

Micro Focus Container Deployment Foundation (2019.05) Page 9 of 45

Planning Guide [DRAFT]

Single Master and Multiple Worker Node Deployment

In this deployment, a single Master Node connects to 3 or more Worker Nodes. The Master and the
Worker Nodes are dedicated to a specific OS instance. Events are processed by the Worker Nodes, with
failover to another Worker Node in the event of a Worker failure.

Note: The single Master Node is a single point of failure, and as a result, this configuration is not
recommended for highly available environments (see "About Master Nodes" on page 7).

Micro Focus Container Deployment Foundation (2019.05) Page 10 of 45

Planning Guide [DRAFT]

Shared Master and Worker Node

This configuration shares an OS instance between one or more the Master and Worker Nodes, while
supporting additional Worker Nodes on different OS instances.

Note: The single Master Node is a single point of failure, and as a result, this configuration is not
recommended for highly available environments.

Micro Focus Container Deployment Foundation (2019.05) Page 11 of 45

Planning Guide [DRAFT]

Chapter 2: Prepare Infrastructure for Deployment

The actual installation of container-based applications on properly configured infrastructure, as
described later in the product Deployment Guides, will be quick and straightforward. The most complex
part of the installation process is the preparation of the hosts, storage, and networking infrastructure,
which is described in this chapter.
The installation process includes several milestones, and each milestone comprises several
interdependent steps. The installation process will validate the infrastructure environment before
performing application installation, as well as after the installation has completed.

Note: Appendix A includes a checklist for your use to track your progress implementing your
preparation.

This chapter contains the following sections:

• Implementation Roles and Responsibilities 13

• Deployment Considerations and Best Practices 13
• Provision and Prepare the Master and Worker Nodes 15
• Secure Communication Between Micro Focus Components 17
• Network File System (NFS) Requirements 18
• Supported Browsers 19
• Supported Screen Resolutions 19
• Supported Languages 19
• File System Requirements 20
• Set System Parameters (Network Bridging) 21
• Check MAC and Cipher Algorithms 22
• Check Password Authentication Settings 22
• Ensure Required OS Packages Are Installed 23
• Remove Libraries 24
• System Clock 24
• Open Port Requirements 24
• Firewall Settings 25
• Proxy Settings 26
• DNS Configuration 27
• Configure the NFS Server Environment 29
• Disable Swap Space 32
• Create Docker Thinpools (optional) 33
• Next Steps 35

Micro Focus Container Deployment Foundation (2019.05) Page 12 of 45

Planning Guide [DRAFT]

Implementation Roles and Responsibilities

Your installation will require specific administration skills, and coordination with corporate IT
departments, including the following:
l Linux operating system administration (including applying OS updates, and configuring networks,
firewalls, ports, user access, and other tasks)
l Familiarity with editing configuration files
l Running commands and scripts on one or more operating systems
l Familiarity with Micro Focus components
l Familiarity with Kafka processing and configuration
The following roles and responsibilities will be needed to properly configure the infrastructure
environment.

Role Responsibility
Application The person in this role must ensure successful execution of the entire installation including verification
admin and post-installation tasks. This person must have a good understanding of the entire installation
process, request support from other appropriate roles as needed, and complete the installation once the
environment is ready for installation.

IT admin The person in this role prepares physical or virtual machines as requested by the application
administrator.

Network The person in this role manages network-related configuration for your organization. This person needs
admin to perform network configuration tasks as requested by the Application administrator.

Storage The person in this role plans and deploys all types of storage for your organization. This person needs to
admin set up one or more NFS servers required by CDF installation.

Deployment Considerations and Best Practices

Before starting the installation process, there are several decisions to be made to plan and prepare your
infrastructure. Listed below are the considerations you will need to decide upon and an outline of steps
you will follow during this planning and preparation process. Details are explained in later sections of
this guide.

Micro Focus Container Deployment Foundation (2019.05) Page 13 of 45

Planning Guide [DRAFT]

Consideration Best Practices

Host Systems l Provision cluster Master and Worker Node host systems and operating environments (OS, storage,
network, VIP, and so on). You will need the IP addresses and FQDNs for these systems during product
deployment.
l The cluster may be installed using the root USERID. Alternatively, it may be installed using a sudo
USER with sufficient privileges.

For more information on granting permissions for installing as a sudo user, see Appendix B.

l Systems must not only meet minimum requirements for CPU cores, memory and disk storage capacity,
but must meet anticipated end-to-end EPS processing throughput requirements.
l Master and Worker Nodes can be deployed on virtual machines.
l Since most of the processing occurs on Worker Nodes, if possible, deploy Worker Nodes on physical
servers.
l For Master and Worker Nodes, don't mix hardware configurations, or physical servers with virtual
machines. Keep host system form factors identical across your implementation.
l When using virtual environments, please ensure:
o Resources are reserved and not shared.

o The UUID and MAC addresses are static and do not change after a reboot or a VM move.
Dynamic addresses will cause the Kubernetes cluster to fail.
l All Master and Worker Nodes must be installed in the same subnet.
l Adding more Worker Nodes is typically more effective than installing bigger and faster hardware.
Using more Worker Nodes also enables you to perform maintenance on your cluster nodes with
minimal impact to uptime. Adding more nodes also helps with predicting costs due to new hardware.
l For high availability of Master Nodes, create a Virtual IP (VIP) that is shared by all Master Nodes.
Prior to installation, a VIP must not respond when pinged.
l If a Master and Worker are sharing a node, then follow the higher-capacity Worker Node sizing
guidelines.

Storage l Available on the FTP download site, the Deployment Size Calculator spreadsheet will enable you to
determine your recommended disk storage requirements and other configuration settings based on
throughput requirements.
l Create or use a preexisting external NFS storage environment with sufficient capacity for the
throughput needed. Guidelines are provided below.
l Determine the size and total throughput requirements of your environment using total EPS. For
example, if there are 50K EPS inbound, and 100K EPS consumed, then size for 150K EPS. (Note: This
does not apply to the Identity Intelligence (IDI) product, because IDI measures the number of
identities and transactions per day.)
l Data compression is performed using GZIP on the producer (for example, the Smart Connector).
Transformation Hub does not compress data.

Network l Although event data containing IPv6 content is supported, the cluster infrastructure is not supported
on IPv6-only systems.

Micro Focus Container Deployment Foundation (2019.05) Page 14 of 45

Planning Guide [DRAFT]

Consideration Best Practices

Security l Determine a security mode (FIPS, TLS, or Client Authentication) for communication between
components.

Performance l Kafka processing settings for Leader Acknowledgement (ACK) and TLS settings have a significant
effect on throughput through the system. Should ACK and TLS be enabled, throughput performance
may be degraded by a factor of 10 or more, requiring more Worker Nodes to account for the
processing overhead.
l If events are being stored to Vertica, consider the potential performance effects of the CEF-to- Avro
data transformation, and allow a 20% increase in CPU utilization. This will generally only have a
large impact with very high EPS (250K+) rates.

Downloads l Ensure you have access to the Micro Focus software download location. You will download installation
and Licensing packages to the Initial Master Node in the cluster.
l Ensure you have a valid Micro Focusl license key for the software being installed.

Provision and Prepare the Master and Worker Nodes

Provision and then configure the Master and Worker Node operating systems, and ensure that the
images meet your enterprise’s operating standards.
l Plan for and request RedHat or CentOS operating systems for your expected Dev, Test and
Production environment implementations. Master and Worker Nodes must meet minimum disk, CPU,
memory, network and redundant node requirements based on the expected Events per Second
(EPS).
l Deploy Master and Worker Nodes on a minimal Linux OS instance plus the additional packages that
are listed below.

Supported Operating Systems

The Master Node and Worker Node hosts must use the same operating system. The following
operating systems are supported.

Operating System Architecture Type Versions

Red Hat Enterprise Linux x64 7.5 or later

CentOS x64 7.5 or later

Supported File Systems

l EXT3/EXT4 file systems
l XFS file system
l Logical Volume Manager (LVM)
Either an EXT4 or an XFS file system is recommended.

Micro Focus Container Deployment Foundation (2019.05) Page 15 of 45

Planning Guide [DRAFT]

Network Identification
• IPv4 (hostnames must also resolve to IPv4 addresses).
• Direct layer 2 connectivity between nodes is required.
• Static IP addresses: each node must have a static IP address.

CDF Databases
• PostgreSQL from 9.4.x to 10.6.x

Minimum Master Node Sizing Requirements

Master Node disk storage is used for storing images and persistent data shared between nodes.

Disk Storage
Expected Total EPS 10K+ RPM SAS or
(Production + SSD RAM
Consumption) (RAID 10) CPUs/Cores Per CPU (GB) Network
All EPS rates Recommended 256 GB. 2/2 (4 cores in total), 2.3 GHz 16 1 GbE
minimum

Disk storage excludes NFS disk requirements. A minimum of 200 GB for NFS is required.

Minimum Worker Node Requirements

Worker Node disk storage is used for:
l Product related data located under installation directory’s k8s-hostpath directory
l Thinpool used by Docker to run Container file systems
l Any activities requiring local storage by Containers runtime processing

Note: The values in the table below assume Leader ACKs and TLS enabled in Kafka.

The following table shows the recommended size requirements for Worker Nodes based on the
expected EPS throughput of the cluster.
Refer to the Deployment Sizing Calculator for total disk requirements across Worker Nodes.

Micro Focus Container Deployment Foundation (2019.05) Page 16 of 45

Planning Guide [DRAFT]

CPUs/Cores Per
Expected Total EPS Disk Type CPU
(Production + 10K+ RPM SAS or SSD 2.3GHz RAM Required Worker
Consumption) (RAID 10) minimum (GB) Network Nodes
Up to 10k Dependent on EPS and 2/2 (4 cores in 16 10GbE 3 or more
retention needs total)

10k - 50k Dependent on EPS and 2/4 (8 cores in 32 10GbE 3 or more

retention needs total)

50k-100k Dependent on EPS and 2/12 (24 cores in 64 10GbE 3 or more

retention needs total)

100-250k Dependent on EPS and 2/12 (24 cores in 128 10GbE 5 or more
retention needs total)

250k – 500k Dependent on EPS and 2/12 (24 cores in 256 10GbE 5 or more
retention needs total)

500k or more Dependent on EPS and 2/12 (24 cores in 256 10GbE 7 or more
retention needs total)

Note: Disk sizes exclude NFS disk requirements. A minimum of 200 GB for NFS is required.

Secure Communication Between Micro Focus Components

Determine which security mode you want for communication between infrastructure components. The
security mode of Producers and Consumers connected must be the same across all components. Set up
the other Micro Focus components with the security mode you intend to use before connecting them.
Changing the security mode after the deployment will require system downtime. If you do need to
change the security mode after deployment, refer to the appropriate Administrator's Guide for the
affected components.
The following table lists Micro Focus products, preparations need for secure communication with
components, ports and security modes, and where to find more information on the product.

Micro Focus Container Deployment Foundation (2019.05) Page 17 of 45

Planning Guide [DRAFT]

Supported security More

Product Preparations needed... Port modes information
Management Install ArcMC before Transformation Hub 38080 l TLS ArcMC
Center (ArcMC) installation. Administrator's
l FIPS
Guide
l Client
Authentication

SmartConnectors SmartConnectors and ArcMC onboard connectors 9093 l TLS SmartConnector

and Collectors can be installed and running prior to installing User Guide,
l FIPS (SC 7.6+ only)
Transformation Hub, or installed after the ArcMC
Client Administrator's
Transformation Hub has been deployed.
l

Authentication Guide
l FIPS mode setup is not supported between
SmartConnector v7.5 and Transformation Hub.
Only TLS and Client Authentication are
supported.
l FIPS mode is supported between Connectors
v7.6 and above and Transformation Hub.

ESM ESM can be installed and running prior to 9093 l TLS ESM Installation
installing Transformation Hub. Guide,
l FIPS
ESM Installation,
Note that changing ESM from FIPS to TLS mode l Client Guide,
requires a redeployment of ESM. Refer to the Authentication ESM
ESM documentation for more information. Administrator's
Guide

Logger Logger can be installed and run prior to 9093 l TLS Logger
installing Transformation Hub. Administrator's
l FIPS
Guide
l Client
Authentication

Leader Acknowledgement and TLS Enablement: In general, enabling Leader ACKs and TLS
results in significantly slower throughput rates, but greater fidelity in ensuring events are received
by Subscribers. Micro Focus has seen results over 800% slower when both Leader ACK and TLS
are enabled versus when both were not active. For more information on Leader Acknowledgements
and TLS enablement and their effects on processing throughput, refer to the Kafka documentation
which explains these features.

Network File System (NFS) Requirements

To operate properly, the CDF Installer platform and some components require a customer-provisioned
NFS server, referred to in this documentation as an External NFS server. External NFS server
configuration guidelines can be found here.

Micro Focus Container Deployment Foundation (2019.05) Page 18 of 45

Planning Guide [DRAFT]

Supported NFS Server Versions

• NFSv3
• NFSv4
Run the command nfsstat –s to view the version of NFS you are running.

Supported NFS types

• Linux-based NFS
• NetApp
• HPE 3PAR File Persona
• Amazon EFS

Supported Browsers
l Google Chrome
l Mozilla Firefox

Note: Browsers should not use a proxy to access CDF ports 5443 or 3000 applications, because
this may result in inaccessible web pages.

Supported Screen Resolutions

l 1600x900
l 1280x1024
l 1920x1200
l Higher resolutions are also supported.

Supported Languages
The CDF Management Portal UI will inherit the local language from your browser. The following
languages are supported.
l English (US + UK)
l French
l German

Micro Focus Container Deployment Foundation (2019.05) Page 19 of 45

Planning Guide [DRAFT]

l Japanese
l Spanish

Note: Products installed using CDF may or may not support these same languages. Consult the
product's release notes for details on its supported languages.

File System Requirements

The following table provides a reference of the directories that are required on each of the servers, and
the space that is needed. Ensure you use the absolute path for the equivalent directory.

Master Worker
Node Master Node Node
File system/device Minimum* Recommended* Minimum Description
$K8S_HOME 8 GB 8 GB This directory is for the CDF installation.
To specify a customized directory, change the
K8S_HOME parameter in install.properties or
during installation, run the following command:
./ install.sh --k8s-home

$K8S_HOME 30 GB 200 GB; Make This directory is for the Kubernetes server, CDF
Installer, and containers. The$K8S_HOME and
sure the used
$RUNTIME_CDFDATA_HOME are the same
(same as disk size plus directory.
$RUNTIME_CDFDATA_ 200 GB is no To specify a customized file system, change the
HOME) K8S_HOME and RUNTIME_CDFDATA_HOME
more than
parameters in the install.properties file or run
80% of the the following commands:
whole system ./ install.sh --k8s-home
disk space. ./ install.sh --runtime-home

/var 5 GB 20 GB 20 GB This directory is for the CDF build.

Micro Focus Container Deployment Foundation (2019.05) Page 20 of 45

Planning Guide [DRAFT]

Master Worker
Node Master Node Node
File system/device Minimum* Recommended* Minimum Description
/tmp 5 GB N/A 5 GB This directory is for the CDF build. To specify a
customized file system, during installation, run
the following command:
./ install.sh --tmp-folder

/var/opt/kubernetes 2 GB+ N/A This directory includes the CDF images and all
suite images. The /offline/suite_images
suite
subdirectory can be removed after uploading
image suite images.
size

Main Docker thinpool 20 GB N/A This device is for main Docker thinpool. It is
directory defined in configured through THINPOOL_DEVICE.
parameter THINPOOL_ To specify the device, configure the
DEVICE THINPOOL_DEVICE parameter in
install.properties or during installation, run the
following command:
./ install.sh --thinpool-device
For more information on Docker thinpool
configuration, see here.

Note: An asterisk (*) in the column header indicates that this value does not include NFS server
space.

Set System Parameters (Network Bridging)

You must make sure the br_netfilter module is installed on all Master and Worker Nodes before
changing system settings. Perform the following steps on all the Master and Worker Nodes:
1. Log in to the node.
2. Run the following command to check whether the br_netfilter module is enabled:
lsmod |grep br_netfilter
3. If there is no return value, the br_netfilter module is not installed, and you must run the
following commands to install it:
modprobe br_netfilter
echo "br_netfilter" > /etc/modules-load.d/br_netfilter.conf

4. Open the /etc/sysctl.conf file in a supported text editor.

5. Make sure the following system parameters are set:

Micro Focus Container Deployment Foundation (2019.05) Page 21 of 45

Planning Guide [DRAFT]

net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1
net.ipv4.ip_forward = 1
net.ipv4.tcp_tw_recycle = 0
kernel.sem=50100 128256000 50100 2560

6. Save the /etc/sysctl.conf file.

7. Run the following command to apply the updates to the node:
/sbin/sysctl -p

Check MAC and Cipher Algorithms

Ensure the /etc/ssh/sshd_config files on each and every Master and Worker Nodes are configured
with at least one of the following values, which lists all supported algorithms. Add only the algorithms
that meet the security policy of your organization.
l For MAC algorithms: hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-96
l For Cipher algorithms: 3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-
ctr,arcfour128,arcfour256,blowfish-cbc
For example, you could add the following lines to the /etc/ssh/sshd_config files on all Master and
Worker Nodes:
MACs hmac-sha2-256,hmac-sha2-512
Ciphers aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr

Check Password Authentication Settings

If you will use a user name and password authentication for adding cluster nodes during the installation,
make sure the PasswordAuthentication parameter in the /etc/ssh/sshd_config file is set to "yes".
There is no need to check the password authentication setting when you add the cluster nodes using a
user name and key authentication.
To ensure the password authentication is enabled, perform the following steps on every Master and
Worker Node:
1. Log on to the cluster node.
2. Open the /etc/ssh/sshd_config file.
3. Check if the parameter PasswordAuthentication is set to yes. If not, set the parameter to yes as
below.
PasswordAuthentication yes

4. Run the following command to restart the sshd service:

Micro Focus Container Deployment Foundation (2019.05) Page 22 of 45

Planning Guide [DRAFT]

systemctl restart sshd.service

Ensure Required OS Packages Are Installed

The packages listed in the following table must be installed on the hosts listed in the Host Systems
Affected column. These packages are available in the standard yum repositories.

Package Name Host systems affected

device-mapper-libs Master, Workers

java-1.8.0-openjdk Master only

libgcrypt Master, Workers

libseccomp Master, Workers

libtool-ltdl Master, Workers

net-tools Master, Workers

nfs-utils Master, Workers

rpcbind Master, Workers, NFS Servers

systemd-libs (version >= 219) Master, Workers

unzip Master, Workers

httpd-tools Master, Workers

conntrack-tools Master, Workers

lvm2 Master, Workers

curl Master, Workers

libtool-libs Master, Workers

To check for one of these packages, setup the yum repository on your server and run this command:
yum list installed <package name>

This command returns an exit status code where:

l 0 indicates the package is installed
l 1 indicates the package is not installed (does not check whether the package is valid)
To install a required package, run the following command:
yum -y install <package name>

Micro Focus Container Deployment Foundation (2019.05) Page 23 of 45

Planning Guide [DRAFT]

Remove Libraries
Remove libraries that will prevent Ingress from starting using the following command, and confirm the
removal when prompted:
yum remove rsh rsh-server vsftpd

System Clock
Implement a Network Time Protocol (NTP) to ensure the system clock of each cluster node remain in
sync. A network time server must be available.
chrony implements this protocol and is installed by default on some versions of RHEL/CentOS. If
installed, verify that chrony is running.

Systems Clock Examples

A network time server must be available. chrony implements this protocol and is installed by default
on some versions of RHEL and CentOS. chrony must be installed on every node. Verify chrony
configuration by using the command:
chronyc tracking

To install chrony, then start the chrony daemon and verify operation:
1. yum install chrony
2. systemctl start chronyd
3. systemctl enable chronyd
4. chronyc tracking

Open Port Requirements

The following firewall ports will be opened during the installation process and must be available.
The default policy of INPUT chain must be set to "ACCEPT" to open the firewall or to add required
iptables rules. If it is not set to "ACCEPT", contact your IT system administrator to change the policy.
To check the default policy of the INPUT chain, run the following command:
iptables -S | grep -- '-P INPUT'

To check whether a port is in use, run the following command:

netstat -antp | grep :<port_number_to_check>

Micro Focus Container Deployment Foundation (2019.05) Page 24 of 45

Planning Guide [DRAFT]

Used by Port Notes

CDF 3000, 5443, 5444
Management
Portal

Kubernetes 2379, 2380, 3000, 4001, 4194,

5000, 8080, 8088, 8200, 8201,
8285, 8443, 8472, 10250, 10251,
10252, 10256

NFS 111, 2049, 20048

Transformation 2181, 9092, 9093, 38080, 39000, l Port 9093 is used by Kafka and is TLS-enabled. All customer data
Hub 39093, 32181 is secured by TLS.
l If you are using the Vertica database, such as with ArcSight
Investigate, you must make port 9092 reachable by all
Transformation Hub nodes, consumers, producers, and Vertica
nodes. Port 9092 is not TLS-enabled.

Transformation 9999, 10000 The Transformation Hub Kafka Manager uses port 9999 and 10000
Hub Kafka to monitor Kafka. These ports must be mutually reachable between
Manager all Transformation Hub nodes.

Transformation 39001-39010 ArcSight Management Center communicates with CTH on ports

Hub CTH 39001-39050.

CAdvisor 4194

By default, ZooKeepers do not use TLS or FIPS to communicate with each other. This communication is
internal-only, and does not include customer data.

Firewall Settings
Make sure that the firewalld.service is enabled and running on all nodes.

Enable masquerade setting in firewall

You must enable the masquerade settings only when the firewall is enabled. Run the following
command on all Master and Workers Nodes to check whether the masquerade setting is enabled:
firewall-cmd --query-masquerade

If the returned value is "yes", then the masquerade is enabled.

If the returned value is "no", run the following commands to enable masquerade in firewall.
firewall-cmd --add-masquerade --permanent

firewall-cmd --reload

Micro Focus Container Deployment Foundation (2019.05) Page 25 of 45

Planning Guide [DRAFT]

Proxy Settings
It is recommended that the cluster have no access to the Internet and proxy settings (http_proxy,
https_proxy and no_proxy) are not set. However, if a connection with the Internet is needed and
you already specified a proxy server for http and https connection, then you must correctly configure
no_proxy.

If the firewall is turned off, the install process will generate a warning. To prevent getting this warning,
the CDF Install parameter --auto-configure-firewall should be set to true.
If you have the http_proxy or https_proxy set, then no_proxy definitions must contain at least the
following values:
no_proxy=localhost, 127.0.0.1, <all Master and Worker cluster node IP
addresses>,<all all Master and Worker cluster node FQDNs>,<HA virtual IP
Address>,<FQDN for the HA Virtual IP address>

Note: Incorrect configuration of proxy settings has proven to be a frequent installation

troubleshooting problem. To verify that proxy settings are configured properly, on all Master and
Worker Nodes run the following command and ensure the output corresponds to the
recommendations.

echo $http_proxy, $https_proxy, $no_proxy

Proxy Settings Examples

Example 1:
export http_proxy="http://web-proxy.example.net:8080"

export https_proxy="http://web-proxy.example.net:8080"

export no_
proxy="localhost,127.0.0.1,node1.swinfra.net,10.94.235.231,node2.swinfra.net,
10.94.235.232,node3.swinfra.net,10.94.235.233,node3.swinfra.net,10.94.235.233
,node4.swinfra.net,10.94.235.234,node5.swinfra.net,10.94.235.235,node6.swinfr
a.net,10.94.235.236,ha.swinfra.net 10.94.235.200"

Example 2:
export http_proxy="http://web-proxy.eu.example.net:8080"

Micro Focus Container Deployment Foundation (2019.05) Page 26 of 45

Planning Guide [DRAFT]

export https_proxy=
"localhost,127.0.0.1,swinfra.net,10.94.235.231,10.94.235.232,10.94.235.233,10
.94.235.233,10.94.235.234,10.94.235.235,10.94.235.236,10.94.235.200"

DNS Configuration
Ensure host name resolution through Domain Name Services (DNS) is working across all nodes in the
cluster, including correct forward and reverse DNS lookups. Host name resolution must not be
performed through /etc/hosts file settings.
All Master and Worker Nodes must be configured with a Fully Qualified Domain Name (FQDN), and
must bebe in the same subnet. Transformation Hub uses the host system FQDN as its Kafka
advertised.host.name. If the FQDN resolves successfully in the Network Address Translation
(NAT) environment, then Producers and Consumers will function correctly. If there are network-specific
issues resolving FQDN through NAT, then DNS will need to be updated to resolve these issues.
Configuration Notes:
l Transformation Hub supports ingestion of event data that contains both IPv4 and IPv6 addresses.
However, its infrastructure cannot be installed into an IPv6-only network.
l localhost must not resolve to an IPv6 address, for example, “::1” – this is the default state. The
install process expects only IPv4 resolution to IP address 127.0.0.1. Any ::1 reference must be
commented out in the etc/hosts file.
l The Initial Master Node host name must not resolve to multiple IPv4 addresses, and this includes
lookup in /etc/hosts.

Test Forward and Reverse DNS Lookup

Test that the forward and reverse lookup records for all servers were properly configured.
To test the forward lookup, run the commands on every Master and Worker Node in the cluster and on
every producer and consumer host system, including:
l All Master Nodes: master1.yourcompany.com, …, mastern.yourcompany.com
l All Worker Nodes: worker1.yourcompany.com, …, workern.yourcompany.com
l Your ArcMC nodes: arcmc.yourcompany.com
l Your Logger node: logger.yourcompany.com
l Your ESM nodes: esm.yourcompany.com
Use the nslookup or host commands to verify your DNS configuration. (Note: Do not use the ping
command.) You must run the nslookup commands on every server specified in your
/etc/resolv.conf file. Every server must be able to forward and reverse lookup properly and return
the exact same results.

Micro Focus Container Deployment Foundation (2019.05) Page 27 of 45

Planning Guide [DRAFT]

If you have a public DNS server specified in your /etc/resolv.conf file (such as the Google public
DNS servers 8.8.8.8 or 8.8.4.4), you must remove this from your DNS configuration.
Run the commands as follows. Expected sample output is shown below each command.
hostname

master1

hostname -s

master1

hostname -f

master1.yourcompany.com

hostname -d

yourcompany.com

nslookup master1.yourcompany.com

Server: 192.168.0.53
Address: 192.168.0.53#53
Address: 192.168.0.1
Name: master1.example.com

nslookup master1

Server: 192.168.0.53
Address: 192.168.0.53#53
Name: master1.example.com
Address: 192.168.0.1

nslookup 192.168.0.1

Server: 192.168.0.53
Address: 192.168.0.53#53
1.0.168.192.in-addr.arpa name = master1.example.com.

Kubernetes Network Subnet Settings

The Kubernetes network subnet is controlled by the --POD_CIDR and –SERVICE_CIDR parameters to
the CDF Installer.

Micro Focus Container Deployment Foundation (2019.05) Page 28 of 45

Planning Guide [DRAFT]

The --POD_CIDR parameter specifies the network address range for Kubernetes pods. The address
range specified in the --POD_CIDR parameter must not overlap with the IP range assigned for
Kubernetes services (which is specified in the –SERVICE_CIDR parameter). The expected value is a
Classless Inter-Domain Routing (CIDR) format IP address. CIDR notation comprises an IP address, a
slash ('/') character, and a network prefix (a decimal number). The minimum useful network prefix is /24
and the maximum useful network prefix is /8. The default value is 172.16.0.0/16. For example:
POD_CIDR=172.16.0.0/16

The CIDR_SUBNETLEN parameter specifies the size of the subnet allocated to each host for Kubernetes
pod network addresses. The default value is dependent on the value of the POD_CIDR parameter, as
described in the following table.

POD_CIDR Prefix POD_CIDR_SUBNETLEN defaults POD_CIDR_SUBNETLEN allowed values

/8 to /21 /24 /(POD_CIDR prefix + 3) to /27

/22 to /24 /(POD_CIDR prefix + 3) /(POD_CIDR prefix + 3) to /27

Smaller prefix values indicate a larger number of available addresses. The minimum useful network
prefix is /27 and the maximum useful network prefix is /12. The default value is 172.17.17.0/24.
Change the default POD_CIDR or CIDR_SUBNETLEN values only when your network configuration
requires you to do so. You must also ensure that you have sufficient understanding of the flannel
network fabric configuration requirements before you make any changes.

Configure the NFS Server Environment

NFS storage is used by all nodes in the cluster to maintain state information about the infrastructure
and to store other pertinent data. In the case of a Dedicated Master deployment having a minimum of 3
Master Nodes, NFS must run on a highly-available external server.

NFS Prerequisites
1. Make certain that the following ports are open on your external NFS server: 111, 2049, and 20048
2. Enable the required packages (rpcbind and nfs-server) by running the following commands
on your NFS server
systemctl enable rpcbind

systemctl start rpcbind

systemctl enable nfs-server

systemctl start nfs-server

3. The following table lists the minimum required sizes for each of the NFS installation directories.

Micro Focus Container Deployment Foundation (2019.05) Page 29 of 45

Planning Guide [DRAFT]

Minimum
Directory Size Description
{NFS_ROOT_ 130GB This is the CDF NFS root folder, which contains the CDF database and files.
DIRECTORY}/itom/itom_ The disk usage will grow gradually.
vol

{NFS_ROOT_ Depends, This volume is only available when you did not choose PostgreSQL High
DIRECTORY}/itom/db but start Availability (HA) for CDF database setting. It is for CDF database.
with 10GB
During the install you will not choose the Postgres database HA option.

{NFS_ROOT_ Depends, This volume is used for backup and restore of the CDF Postgres database.
DIRECTORY}/itom/db_ but start Its sizing is dependent on the implementation’s processing requirements
backup with 10GB and data volumes.

{NFS_ROOT_ Depends, This volume stores the log output files of CDF components. The required
DIRECTORY}/itom/logging but start size depends on how long the log will be kept.
with 40GB

{NFS_ROOT_ 10GB This volume stores the component installation packages.

DIRECTORY}/arcsight

Note: 1GB = 1024 * 1024 * 1024 bytes

NFS Directory Structure

To create the NFS directory structure:
1. Login to your NFS server and create the following:
l A GROUP named arcsight, with a GID of 1999

l A USER named arcsight with a UID of 1999

l An NFS Root directory = /opt/arcsight/nfs/volumes

Note: If you have previously installed any version of CDF, you must remove all NFS shared
directories before you proceed. To do this, run the following command for each directory:
rm -rf <path to shared directory>

2. For each directory listed in the table below, run the following command to create each NFS shared
directory:
mkdir -p <path to shared directory>

For example: mkdir -p /opt/arcsight/nfs/volumes/itom/itom_vol

Directory Mount Point Example

{NFS_ROOT_DIRECTORY}/itom/itom_vol /opt/arcsight/nfs/volumes/itom/itom_vol

{NFS_ROOT_DIRECTORY}/itom/db /opt/arcsight/nfs/volumes/itom/db

Micro Focus Container Deployment Foundation (2019.05) Page 30 of 45

Planning Guide [DRAFT]

Directory Mount Point Example

{NFS_ROOT_DIRECTORY}/itom/db_backup /opt/arcsight/nfs/volumes/itom/db_backup

{NFS_ROOT_DIRECTORY}/itom/logging /opt/arcsight/nfs/volumes/itom/logging

{NFS_ROOT_DIRECTORY}/arcsight /opt/arcsight/nfs/volumes/arcsight

3. The permission setting of each directory must be recursively set to 755. If it is not, run the following
command to update the permissions:
chmod -R 755 <path to shared directory>

For example: chmod -R 755 /opt/arcsight/nfs/volumes/itom/itom_vol

4. Set the ownership in this structure to UID 1999 and GID 1999. Change the directory to /opt, and
then run the following command:
chown –R 1999:1999 {NFS_ROOT_DIRECTORY}/arcsight

Note: if you use a UID/GID different than 1999/1999 provide it during the CDF installation in the
install script arguments--system-group-id and --system-user-id.

Export the NFS Configuration

For every NFS volume, run the following set of commands on the External NFS server based on the IP
address. You will need to export the NFS configuration with appropriate IPs in order for the NFS mount
to work properly. For every node in the cluster, you must update the configuration to grant the node
access to the NFS volume shares.
Here is a sample exportfs output for IP address 192.168.1.0 for all of the volumes:
/opt/arcsight/nfs/volumes/arcsight 192.168.1.0/24
(rw,sync,anonuid=1999,anongid=1999,all_squash)

/opt/arcsight/nfs/volumes/itom/itom_vol 192.168.1.0/24
(rw,sync,anonuid=1999,anongid=1999,all_squash)

/opt/arcsight/nfs/volumes/itom/db 192.168.1.0/24
(rw,sync,anonuid=1999,anongid=1999,all_squash)

/opt/arcsight/nfs/volumes/itom/logging 192.168.1.0/24
(rw,sync,anonuid=1999,anongid=1999,all_squash)
/opt/arcsight/nfs/volumes/itom/db_backup 192.168.1.0/24
(rw,sync,anonuid=1999,anongid=1999,all_squash)

Save the /etc/exports file, and then run the following command:
exports -ra

Synchronize the time on the NFS server and the time on the other servers in the cluster.

Micro Focus Container Deployment Foundation (2019.05) Page 31 of 45

Planning Guide [DRAFT]

If you later add more NFS shared directories, you must restart the NFS service.

Testing NFS
1. Create the NFS directory under /mnt.
2. From the command prompt attempt to mount the nfs directory on your local system, to
/mnt/nfs, using the sample commands below (for NFS v3 and v4).
l NFS v3 Test: mount -t nfs 192.168.1.25:/opt/arcsight/nfs/volumes/arcsight
/mnt/nfs
l NFS v4 Test: mount -t nfs4 192.168.1.25:/opt/arcsight/nfs/volumes/arcsight
/mnt/nfs
After creating all 5 volumes, run the following commands on the NFS server:
exportfs -ra
systemctl restart rpcbind
systemctl enable rpcbind
systemctl restart nfs-server
systemctl enable nfs-server

NFS Setup Using a Script

For non-HA, single-node shared Master and Worker Node environments only, NFS may be
configured with the script setupNFS.sh, which is located on the Initial Master Node in /
{ArcsightRootFolder}/kubernetes/scripts folder.

To run the script:

1. Copy setupNFS.sh to the NFS server.
2. Do one of the following:
l If using the default UID/GID run : sh setupNFS.sh /path_to_
volumes/volumes/itom/volume_name
l If using a non-default UID/GID run: sh setupNFS.sh /path_to_
volumes/volumes/itom/volume_name true <uid> <gid>
3. Run the following command to restart the NFS service:
systemctl restart nfs

Disable Swap Space

Complete this task on all Master and Worker nodes.
To disable swap space:

Micro Focus Container Deployment Foundation (2019.05) Page 32 of 45

Planning Guide [DRAFT]

1. Log on to the node.

2. Run the following command to disable the swap process:
swapoff -a

3. Open the /etc/fstab file in a supported editor, and then comment out the lines that display
"swap" as the disk type. Then save the file.
For example: #/dev/mapper/centos_shcentos72x64-swap swap

Create Docker Thinpools (optional)

Optionally, to improve performance of Docker processing, set up a thinpool on each Master and Worker
Node. Before setting up a thinpool on each node, create a single disk partition on the node, as explained
below.
For the thinpool device for Docker (for example, sdb1): the minimum physical volume size is 30GB.

To create a new partition on a node:

1. fdisk <name of the new disk device that was added]

For example: # fdisk /dev/sdb1

2. Enter n to create a new partition.

3. When prompted, enter partition number, sector, type (Linux LVM), and size for the first partition.
To select Linux LVM partition type:
l Enter t to change the default partition type to Linux LVM

l Type L to list the supported partition types

l Type 8e to select Linux LVM type
4. When prompted, enter partition number, sector, type (Linux LVM), and size for the second
partition.
5. Type p to view the partition table.
6. Type w to save the partition table to disk.
7. Type partprobe.

To set up a thinpool for Docker on a node:

1. Create a physical volume with the following command:
# pvcreate [physical device name]

For example:
# pvcreate /dev/sdb1

Micro Focus Container Deployment Foundation (2019.05) Page 33 of 45

Planning Guide [DRAFT]

2. Create a volume group with the following command:

# vgcreate [volume group name] [logical volume name]

For example:
# vgcreate docker /dev/sdb1

3. Create a logical volume (LV) for the thinpool and bootstrap with the following command:
# lvcreate [logical volume name] [volume group name]

For example: the data LV is 95% of the 'Docker' volume group size (leaving free space allows for
automatic expanding of either the data or metadata if space is running low, as a temporary
stopgap):
# lvcreate --wipesignatures y -n thinpool docker -l 95%VG
# lvcreate --wipesignatures y -n thinpoolmeta docker -l 1%VG

4. Convert the pool to a thinpool with the following command:

# lvconvert -y --zero n -c 512K --thinpool docker/thinpool --poolmetadata
docker/thinpoolmeta

Optionally, you can configure the auto-extension of thinpools using an lvm profile.
1. Open the lvm profile with a text editor.
2. Specify a value for the parameters thin_pool_autoextend_threshold, and thin_pool_
autoextend_percent, each of which represents a percentage of the space used.
For example:
activation {
thin_pool_autoextend_threshold=80
thin_pool_autoextend_percent=20
}

3. Apply the lvm profile with the following command:

# lvchange --metadataprofile docker-thinpool docker/thinpool

4. Verify that the lvm profile is monitored with the following command:
# lvs -o+seg_monitor

5. Clear the graph driver directory with the following command, if Docker was previously started:
# rm -rf /var/lib/docker/*

6. Monitor the thinpool and volume group free space with the following commands:
# lvs
# lvs -a
# vgs

Micro Focus Container Deployment Foundation (2019.05) Page 34 of 45

Planning Guide [DRAFT]

7. Check logs to see the auto-extension of the thinpool when it hits the threshold:
# journalctl -fu dm-event.service

Next Steps
With your preparation complete, you are now ready to install the CDF Installer and then use it to deploy
container-based applications. Such applications may include one or more of the following:
l Transformation Hub
l ArcSight Investigate
l Identity Intelligence
For deployment information, see the Micro Focus Deployment Guide corresponding to your product of
choice.

Micro Focus Container Deployment Foundation (2019.05) Page 35 of 45

Planning Guide [DRAFT]

Appendix A: CDF Planning Checklist

Refer to the checklist below to set up your hosts, network, storage, and other prerequisites for
installation of CDF. Check off each task as it is verified and completed.

Prerequisite Description Completed

Meet system Memory, CPU, disk space and network connectivity for the expected EPS
requirements throughput rates.

Network l Ensure connectivity between cluster nodes (Master and Worker Nodes). Any
connectivity latency will result in lower EPS throughput rates.
between nodes l Expected performance level is < 1 millisecond.

Validate cluster l Ensure that security protocols are enabled and configured properly for
security communication between all cluster nodes.
configuration l The security mode of Producers and Consumers must be the same across the
infrastructure.
l Changing the security mode after the infrastructure has been deployed will
require system down time.
l Other options are TLS, FIPS and Client Authentication

Create a sudo user l (Optional) Create a sudo user if the install will use a non-root USER.

Meet file system Ensure file systems have sufficient disk space.
requirements

Set system Ensure that network bridging is installed.

parameters

Check MAC and Ensure that MAC and cipher minimum requirements are met.
cipher algorithms

Check password If using a USER and password authentication, ensure the PasswordAuthentication
authentication parameter is enabled.

Ensure OS l Ensure that all required packages are installed on Master and Worker Nodes and
packages are the NFS server.
installed l Remove libraries that will cause conflicts.

Ensure system Ensure that the system clock of each cluster Master and Worker node remains
clocks are in sync continuously in sync. A network time server must be available (for example, chrony).

Disable swap space Optional. For the best performance, disable disk swap space.

Create a CDF (Optional) In highly available environments, we recommend that you create a CDF
installation installation directory, and then mount a logical volume to the installation directory.
directory

Set up Docker Optional. For the best performance, set up Docker thinpools.
thinpools

Micro Focus Container Deployment Foundation (2019.05) Page 36 of 45

Planning Guide [DRAFT]

Prerequisite Description Completed

Configure network l Ensure host name resolution through DNS across all nodes in the cluster.
settings l Infrastructure does not support being installed on IPv6-only networks.

Configure Configure the network subnet for the Kubernetes cluster.

Kubernetes
network subnet

Configure firewall Ensure that the firewalld.service is enabled on all Master and Worker Nodes in the
settings cluster.

Configure proxy Should you require internet access, ensure that your proxy and no-proxy settings
settings are properly configured and tested.

Configure NFS Ensure that the external NFS server is properly configured and available. NFS
server settings utilities must be installed.

Validate Virtual IP l Verify that the VIP address and FQDN shared by all Master Nodes in the cluster
address and FQDN are accessible. The VIP provides high availability for Master Nodes.
l The Installation process will test and ping the VIP and try to resolve the FQDN.
Configured as the –ha-virtual-ip parameter in the CDF Installer.
l Should a Master Node fail, another Master Node takes over the VIP and responds
to requests sent to the VIP.

Micro Focus Container Deployment Foundation (2019.05) Page 37 of 45

Planning Guide [DRAFT]

Appendix B: Enabling Installation Permissions for a

sudo User
If you choose to install the Installer as a sudo user, the root user must grant non-root (sudo) users
installation permission before they can perform the installation. Please make sure the provided user has
permission to execute scripts under temporary directory /tmp on all Master and Worker Nodes.
There are two distinct file edits that need to be performed: first on the Initial Master Node only, and
then on all remaining Master and Worker Nodes. These file edits are detailed below.

Edit the sudoers File on the Initial Master Node (only)

Note: Make the following modifications on the Initial Master Node only.

First, log on to the Initial Master Node as the root user. Then, using visudo, edit the /etc/sudoers
file and add or modify the following lines.

Warning: In the following commands you must ensure there is, at most, a single space character
after each comma that delimits parameters. Otherwise, you may get an error similar to this when
you attempt to save the file.
>>> /etc/sudoers: syntax error near line nn <<<

1. Add the following Cmnd_Alias line to the command aliases group in the sudoers file.
Cmnd_Alias CDFINSTALL = <CDF_installation_package_directory>/scripts/pre-
check.sh, <CDF_installation_package_directory>/install, <K8S_
HOME>/uninstall.sh, /usr/bin/kubectl, /usr/bin/docker, /usr/bin/mkdir,
/bin/rm, /bin/su, /bin/chmod, /bin/tar, <K8S_HOME>/scripts/uploadimages.sh,
/bin/chown

l Replace <CDF_installation_package_directory> with the directory where you unzipped the

installation package. For example, /tmp/cdf-2019.05.0xxx.
l Replace <K8S_HOME> with the value defined from a command line. By default, <K8S_HOME> is
/opt/arcsight/kubernetes.
2. Add the following lines to the wheel users group, replacing <username> ALL=NOPASSWD:
CDFINSTALL with :

Defaults: <username> !requiretty

Defaults: root !requiretty

l Replace <username> with your actual sudo user name

3. Locate the secure_path line in the sudoers file and ensure the following paths are present:

Micro Focus Container Deployment Foundation (2019.05) Page 38 of 45

Planning Guide [DRAFT]

Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin

By doing this, the sudo user can execute the showmount, curl, ifconfig and unzip commands
when installing the CDF Installer.
4. Save the file.

Installing Components Using the sudo User

After completing the modifications to the sudoers files as described above, perform the following
steps.
1. Log in to the Initial Master Node as the non-root sudo user to perform the installation
2. Download the installer files to a directory where the non-root sudo user has write permissions
3. Run the CDF installer using the sudo command (for more details, refer to the your product's
Deployment Guide)

Edit the sudoers File on the Remaining Master and Worker

Nodes
Note: Make the following modifications only on the remaining Master and Worker Nodes.

Log in to each Master and Worker Node. Then, using visudo, edit the /etc/sudoers file and add or
modify the following lines.

Warning: In the following commands you must ensure there is, at most, a single space character
after each comma that delimits parameters. Otherwise, you may get an error similar to this when
you attempt to save the file.
>>> /etc/sudoers: syntax error near line nn <<<

1. Add the following Cmnd_Alias line to the command aliases group in the sudoers file.
Cmnd_Alias CDFINSTALL = /tmp/scripts/pre-check.sh, <ITOM_Suite_Foundation_
Node>/install, <K8S_HOME>/uninstall.sh, /usr/bin/kubectl, /usr/bin/docker,
/usr/bin/mkdir, /bin/rm, /bin/su, /bin/chmod, /bin/tar, <K8S_
HOME>/scripts/uploadimages.sh, /bin/chown

l Replace <ITOM_Suite_Foundation_Node> with the directory where you unzipped the installation
package. For example, /tmp/ITOM_Suite_Foundation_2019.05.0xxx.
l Replace <K8S_HOME> with the value defined from a command line. By default, <K8S_HOME> is
/opt/arcsight/kubernetes.
2. Add the following lines to the wheel users group, replacing <username> ALL=NOPASSWD:
CDFINSTALL with :

Micro Focus Container Deployment Foundation (2019.05) Page 39 of 45

Planning Guide [DRAFT]

Defaults: <username> !requiretty

Defaults: root !requiretty

l Replace <username> with your actual sudo user name

3. Locate the secure_path line in the sudoers file and ensure the following paths are present:
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin

By doing this, the sudo user can execute the showmount, curl, ifconfig and unzip commands
when installing the CDF Installer.
4. Save the file.
Repeat the process for each remaining Master and Worker Node.

Micro Focus Container Deployment Foundation (2019.05) Page 40 of 45

Planning Guide [DRAFT]

Glossary

C
cluster
A group of nodes, pods, or hosts.

Common Event Format (CEF)

CEF is a unified format that transforms log file data into normalized, enriched, and categorized log data. It is an IT
security industry standard log format.

Connectors in Transformation Hub (CTH)

CTH features enable enriching, normalizing and sending syslog data and routing it to Kafka topics.

consumer
A consumer of Transformation Hub event data. Consumers may be Micro Focus products such as Logger or ESM,
third-party products like Hadoop, or can be made by customers for their own use.

Container Deployment Foundation (CDF)

CDF is the container-based delivery and management model built on Kubernetes and Docker containers, which
standardizes distribution, installation, upgrade, and operation of Micro Focus products and product suites.

CTH
Collector in Transformation Hub (CTH). A feature where SmartConnector technology operates directly in
Transformation Hub to collect data.

D
Dedicated Master Node
A node dedicated to running the Kubernetes control plane functionality only.

destination
In Micro Focus products, a forwarding location for event data. A Transformation Hub topic is one example of a
destination.

Docker container
A Docker container is portable application package running on the Docker software development platform.
Containers are portable among any system running the Linux operating system.

Micro Focus Container Deployment Foundation (2019.05) Page 41 of 45

Planning Guide [DRAFT]

F
flannel
flannel (spelled with a lower-case f) is a virtual network that gives a subnet to each host for use with container
runtimes. Platforms like Google's Kubernetes assume that each container (pod) has a unique, routable IP inside the
cluster. The advantage of this model is that it reduces the complexity of doing port mapping.

Fully Qualified Domain Name (FQDN)

A fully qualified domain name (FQDN) is the complete domain name for a specific computer, or host, on the
internet. The FQDN consists of two parts: the hostname and the domain name. For example, an FQDN for a
hypothetical mail server might be mymail.example.com. The hostname is mymail, and the host is located within
the domain example.com.

I
Initial Master Node
The Master Node that has been designated as the primary Master Node in the cluster. It is from this node that you
will install the cluster infrastructure.

K
Kafka
An open-source messaging system that publishes messages for subscribers to consume on its scalable platform
built to run on servers. It is commonly referred to as a message broker.

Kubernetes
Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized
applications. It groups containers that make up an application into logical units for easy management and
discovery.

L
Labeling
Adding a Kubernetes label to a Master or Worker Node creates an affinity for the workload to the Master or Worker
Node, enabling the node to run the specified workload on the labeled server.

Local Docker Registry

The Docker Registry location on the Master and Worker Nodes in the cluster. Application software is launched and
managed from the Local Docker Registry.

Micro Focus Container Deployment Foundation (2019.05) Page 42 of 45

Planning Guide [DRAFT]

M
Master Nodes
Master Nodes run the CDF Installer and process web services calls made to the cluster. A minimum of 1 Master Node
is required for each cluster.

N
Network File System (NFS)
This is the location where the CDF Installer, Transformation Hub, and other components may store persistent data.
A customer-provisioned NFS is required. This environment is referred to in this documentation as an "external"
NFS. Although the CDF platform can host a CDF-provisioned NFS (Internal NFS), for high availability an External
NFS service should implemented.

Node
A processing location. In CDF containerized applications, nodes come in two types: master and worker.

P
Pod
Applications running in Kubernetes are defined as “pods”, which group containerized components. CDF uses
Docker Containers as these components. A pod consists of one or more containers that are guaranteed to be co-
located on the host server and can share resources. Each pod in Kubernetes is assigned a unique IP address within
the cluster, allowing applications to use ports without the risk of conflict.

producer
A gatherer of event data, such as a SmartConnector or CTH. Typically data from a producer is forwarded to a
destination such as a Transformation Hub topic.

R
root installation folder
The root installation folder is the top level directory that the Transformation Hub, CDF Installer, and all supporting
product files will be installed into. The default setting is /opt/arcsight. It is referred to as RootFolder in this
document, supporting scripts, and installation materials.

S
Shared Master and Worker Nodes
A configuration where both Master and Worker Nodes reside on the same hosts. This is not a recommended
architecture for high availabillty.

Micro Focus Container Deployment Foundation (2019.05) Page 43 of 45

Planning Guide [DRAFT]

SmartConnector
SmartConnectors automate the process of collecting and managing logs from any device and in any format.

T
thinpool
Using thin provisioning in Docker, you can manage a storage pool of free space, known as a thinpool, which can be
allocated to an arbitrary number of devices when needed by applications.

Transformation Hub
A Kafka-based messaging service that enriches and transforms security data from producers and routes this data
to consumers.

Transformation Hub cluster

The Transformation Hub cluster consists of all Master and Worker Nodes in the TH environment.

V
Virtual IP (VIP)
To support high availability, a VIP is used as the single IP address or FQDN to connect to a dedicated Master
infrastructure that contains 3 or more master Nodes. The Master Nodes manage Worker Nodes. The FQDN of the
VIP can also be used to connect to the cluster’s Master Nodes.

W
Worker nodes
Worker nodes ingest, enrich and route events from event producers to event consumers. Worker nodes are
automatically load-balanced by the TH infrastructure.

Z
Zookeeper
In Kafka, a centralized service used to maintain naming and configuration data and to provide flexible and robust
synchronization within distributed systems.

Micro Focus Container Deployment Foundation (2019.05) Page 44 of 45

Send Documentation Feedback
If you have comments about this document, you can contact the documentation team by email. If an
email client is configured on this system, click the link above and an email window opens with the
following information in the subject line:
Feedback on Planning Guide [DRAFT] (Container Deployment Foundation 2019.05)
Just add your feedback to the email and click send.
If no email client is available, copy the information above to a new message in a web mail client, and send
your feedback to [email protected].
We appreciate your feedback!

Micro Focus Container Deployment Foundation (2019.05) Page 45 of 45