Installation Prerequisites on CentOS

To successfully install and deploy a Paragon Automation cluster, you must have a control host and installs the distribution software on a single or multiple cluster nodes. You can download the distribution software on the control host, and then create and configure the installation files to run the installation from the control host. You must have internet access to download the packages on the control host. You must also have internet access on the cluster nodes to download any additional software such as Docker, and OS patches.

The order of installation tasks is shown at a high level in Figure 1.

Figure 1: High-Level Process Flow for Installing Paragon Automation

Before you download and install the distribution software, you must preconfigure the control host and the cluster nodes as described in this topic.

Prepare the Control Host

The control host is a dedicated machine that is used to orchestrate the installation and upgrade of a Paragon Automation cluster. It carries out the Ansible operations that runs the software installer and installs the software on the cluster nodes as illustrated in Figure 2.

You must download the installer packages on the Ansible control host. As part of the Paragon Automation installation process, the control host installs any additional packages required on the cluster nodes. This includes optional OS packages, Docker, and Elasticsearch. Hence, the control node requires internet access to download software. All microservices, including third-party microservices, are downloaded onto the control host, and do not access any public registries during installation.

The control host can be on a different broadcast domain from the cluster nodes, though it is recommended that it is in the same domain. In either case, you must ensure that it can SSH into all the nodes.

Figure 2: Control Host Functions

Once installation is complete, the control host plays no role in the functioning of the cluster. However, you will need the control host to update the software or any component, make changes to the cluster, or re-install it if a node fails. You can also use the control host to archive configuration files. We recommend that you keep the control host available, and not use it for something else, after installation.

You need to prepare the control host for the installation process as follows:

Install Base OS—Install CentOS version 7.6 (or later). Paragon Automation Release 21.3 is qualified to work with CentOS 7.9 Minimal ISO.
Install Docker—Docker must be installed and configured on the control host to implement the Linux container environment. Paragon Automation supports Docker CE and Docker EE. The Docker version you choose to install in the control host is independent of the Docker version you plan to use in the cluster nodes.
If you want to install Docker EE, ensure that you have a trial or subscription before installation. For more information on Docker EE, supported systems, and installation instructions, see https://www.docker.com/blog/docker-enterprise-edition/.
To download and install Docker CE, perform the following steps:
To verify that Docker is installed and running, use the $ docker run hello-world command.
To verify the Docker version installed, use the $ docker version or $ docker --version commands.
For full instructions and more information, see https://docs.docker.com/engine/install/centos/.
Install SSH Client Authentication—The installer running on the control host connects to the cluster nodes using SSH. The user account used for SSH authentication must be root or a non-root account with superuser (sudo) privileges. We will refer to this account as the install user account in subsequent steps. You must ensure that the install user account is configured on all the nodes in the cluster. The installer will use the inventory file to determine which username to use, and whether authentication will use ssh-keys or a password. See Customize the Inventory File - Multinode Implementation or Customize the Inventory File - Single Node Implementation.
If you chose ssh-key authentication (recommended), generate the ssh-keys.
If you want to protect the SSH key with a passphrase, you can use ssh-agent. See https://www.ssh.com/academy/ssh/agent.

Note:
You will need to copy this key to the nodes as part of the cluster nodes preparation tasks, as described in the next section.
(Optional) Install wget—Install the wget tool to download the Paragon Automation distribution software.

$ yum install wget

Alternatively, you can use rsync or any other file download software to copy the distribution software.

Prepare Cluster Nodes

The primary and worker nodes are collectively called cluster nodes. Each cluster node must at least one static, and unique IP address as illustrated in Cluster Nodes Functions. When configuring the hostnames, use only lower case letters, and do not include any special characters other than “-” and “.”. If the implementation has a separate IP network to provide communication between the Paragon automation components, as described in the overview section, these IP addresses do not need to be reachable outside the cluster. However, in this case there should be a second set of IP addresses assigned to the worker nodes, which should be reachable from outside the cluster, to allow communication between Paragon Automation and the managed devices or between Paragon Automation and the network administrator.

We recommend that all the nodes be in the same broadcast domain. For cluster nodes in different broadcast domains, see Load balancing configuration for additional load balancing configuration.

Figure 3: Cluster Nodes Functions

As described in Paragon Automation System Requirements, you can install Paragon Automation as a single node or a multinode deployment. The node installation prerequisites are the same for both multinode and single-node deployments, except for storage requirements.

Configure Raw Disk Storage—The cluster nodes must have raw storage block devices with unpartitioned disks or unformatted disk partitions attached. The nodes can also be partitioned such that a portion of the disk space available is used for the root partition and other file systems. The remaining space must be unformatted with no file systems and reserved for Ceph to use. For more information, see Disk Requirements.

Note:
Nothing needs to be configured or installed to allow the unpartitioned disks or unformatted disk partitions to be used for Ceph storage. This will be assigned automatically during the installation process.

For multinode clusters, you must have a minimum of three cluster nodes with storage space attached.

For a single-node cluster, the single node must have storage space.

Installation will fail if unformatted disks are not available.

Ceph requires newer Kernel versions. If your Linux kernel is very old, consider upgrading or reinstalling a new one. For a list of minimum Linux kernel versions supported by Ceph for your OS, see https://docs.ceph.com/en/latest/start/os-recommendations. To upgrade your Linux kernel version, see Upgrade your CentOS Linux Kernel Version.
Install Base OS—Install CentOS version 7.6 (or later) that allows installation of Docker CE or Docker EE must be installed. Paragon Automation Release 21.3 is qualified to work with CentOS 7.9 Minimal ISO.
Create Install User Account—The install user is the user that the Ansible playbooks will use to log in to the primary and worker nodes and perform all the installation tasks. Ensure that either a root password or an account with superuser (sudo) privileges is configured. You will add this information to the inventory file during the installation process.
Set the root user password.
Configure SSH Authentication—Install open-ssh server on all nodes. The installer running on the control host connects to the cluster nodes through SSH using the install user account.
1. Log in to the cluster nodes. and install open-ssh server on all nodes.
2. After installation, edit the sshd_config file.
  $ vi /etc/ssh/sshd_config
3. If you are using "root" as the install user account, permit root login.
  
  PermitRootLogin yes
  
  If you chose to use plain text password for authentication, you must enable password authentication.
  
  PasswordAuthentication yes
  
  We do not recommend the use of password authentication.
4. If you changed /etc/ssh/sshd_config, restart the SSH daemon.
  $ systemctl restart sshd
5. Log in to the control host:
  1. To allow authentication using the SSH key, copy id_rsa.pub to the cluster nodes.
    Repeat this step for ALL the nodes in the cluster (primary and workers). cluster-node-IP is the unique address of the node as shown in Cluster Nodes Functions. If the hostname is used instead, the Ansible control host should be able to resolve the name to its IP address.
  2. SSH into the cluster node. You must not require a password to log in.
    
    To verify connectivity. Use the Install User Account to ssh.
    
    You should be able to SSH into all nodes in the cluster (primary and workers) from the control host using the Install User Account. If you are not able to, review the previous steps and make sure you did not miss anything.
Install Docker—Select one of the following Docker versions to install.
The Docker version you choose to install in the cluster nodes is independent of the Docker version installed in the control host.
- Docker CE—If you want to use Docker CE, you do not need to install it on the cluster nodes. The deploy script installs Docker CE on the nodes during Paragon Automation installation.
- Docker EE—If you want to use Docker EE, you must install Docker EE on all the cluster nodes. If you install Docker EE on the nodes, the deploy script uses the installed version and does not attempt to install Docker CE in its place. For more information on Docker EE, supported systems, download, and installation instructions, see https://www.docker.com/blog/docker-enterprise-edition/.
  
  The Docker version you choose to install in the cluster nodes is not dependent on the Docker version installed in the control host.
Disable Firewall—Disable the local firewall.

$ systemctl stop firewalld

$ systemctl disable firewalld

Consider protecting your cluster with an external firewall.
Install Python—Install Python 3, if not pre-installed with your OS, on the cluster nodes:
$ yum install -y python3
To verify the Python version installed, use $ python3 -V or $ python3 --version commands.
Check Installed Packages—Use the $ yum list installed command and ensure that the following packages are installed.

bash-completion, gdisk, iptables, lvm2, python-six, PyYAML, openssl
Install and Enable NTP—All nodes must run NTP or other time-synchronization at all times. By default, Paragon Automation installs the Chrony NTP client. If you do not want to use Chrony, you can manually install NTP on all nodes.
1. Install NTP.
  
  $ yum install ntp ntpdate -y
2. Run this command twice to reduce the offset with the NTP server.
  
  $ ntpdate ntp-server
3. Start the NTP daemon.
  
  $ systemctl start ntpd
4. Configure the NTP server pools.
  
  $ vi /etc/ntp.conf
5. Replace the default CentOS pools with your desired NTP server.
  
  server ntp-server prefer iburst
  
  Save and exit the file.
6. Restart the NTP service.
  
  $ systemctl restart ntpd
7. Confirm that the system is in sync with the NTP server.
  
  $ timedatectl
(Optional) Upgrade your CentOS Linux Kernel Version—To upgrade the kernel version of your CentOS server to the latest LTS version to meet the requirements for Paragon Automation installation.
To upgrade the kernel version of your CentOS server to the latest LTS version to meet the requirements for Paragon Automation installation.
1. Log in as root user.
2. Check the existing kernel version:
  
  root@server$ uname -msr
  
  If the Linux kernel version is earlier than 4.18, upgrade the kernel.
3. Update existing software packages to the latest versions
  
  root@server$ yum -y update
4. CentOS does not provide the latest available kernel versions in its software repository. Therefore, the ElRepo (elrepo) software repository is used. Additionally, CentOS requires all software to be signed; so you must install the elrepo GPG signature key before installing the elrepo repository.
  
  Installing the elrepo GPG signature key requires a single rpm command which returns no output if successful:
  1. Install GPG Key for ElRepo Software Repository.
    
    root@server$ rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
  2. Install ElRepo Software Repository.
    
    root@server$ rpm -Uvh https://www.elrepo.org/elrepo-release-7.0-4.el7.elrepo.noarch.rpm
  3. Confirm the latest kernel in the ElRepo Repository.
    
    root@server$ yum list available --disablerepo='*' --enablerepo=elrepo-kernel
5. Install the latest kernel.
  
  root@server$ yum --enablerepo=elrepo-kernel install kernel-lt
6. Reboot the server to load the new kernel.
  
  root@server$ reboot
7. Edit GRUB configuration. Use the text editor to edit /etc/default/grub file.
  
  root@server$ vi /etc/default/grub
8. Set GRUB_DEFAULT=0. Save and exit the file.
9. Install the GRUB configuration and reboot the server.
  
  root@server$ grub2-mkconfig -o /boot/grub2/grub.cfg
  
  root@server$ reboot
10. Verify the new kernel version.
  
  root@server$ uname -msr

The Kubernetes worker nodes host the pods that handle the applications workload.

A pod is the smallest deployable unit of computing created and managed in Kubernetes, and contains one or more containers, with shared storage and network resources, and with specific instructions on how to run the applications. Containers are the lowest level of processing and is where applications or microservices are executed.

The primary node in the cluster, determines which worker node will host a particular pod and containers.

All features of Paragon Automation are implemented using a combination of microservices. Some of these microservices need to be accessible from outside the cluster as they provide services to end users (managed devices), and administrators. For example, the pceserver service needs to be accessible to establish PCEP sessions between PE routers and Paragon Automation.

These services need to be exposed outside of the Kubernetes cluster with specific addresses that are reachable from the external devices. Because a service can be running on any of the worker nodes at a given time, the external addresses should be Virtual IP Addresses (VIPs), and not the address of any given worker node.

In this example:

Consider that WORKER1_IP = 10.1.x.3 and WORKER2_IP = 10.1.x.4.

SERVICE IP = PCEP VIP = 10.1.x.200

PCC_IP = 10.1.x.100

The services in Paragon Automation are configured to employ one of two methods of exposing services outside the cluster:

Load Balancer—Each load balancer is associated with a specific IP address and routes external traffic to a specific service in the cluster. This is the default method for many Kubernetes installations in the cloud. It supports multiple protocols and multiple ports per service. Each service has its own load balancer, and IP address.

Paragon Automation uses MetalLB.
Ingress—Ingress acts as a proxy to bring traffic into the cluster, then uses internal service routing to route the traffic to its destination. Under the hood, Ingress also uses a Load Balancer service to expose itself to the world so it can act as that proxy.

Paragon Automation uses:
- Ambassador
- Nginx
- HAProxy

The following services need to be accessible and thus require a VIP address.

Required VIP Address	Description	Load Balancer/Proxy
Ingress controller	Used for Web access of the Paragon Automation GUI. Paragon Automation provides a common Web server that provides access to the components and applications. Access to the server is managed through the Kubernetes Ingress Controller.	Ambassador MetalLB
Paragon Insights services	Used for Insights services such as syslog, DHCP relay, and JTI.	MetalLB
Paragon Pathfinder PCE server	Used to establish PCEP sessions with devices in the network.	MetalLB
SNMP trap receiver proxy (Optional)	User for the SNMP trap receiver proxy only if this functionality is required.	MetalLB
Virtual IP address for Infrastructure Nginx Ingress Controller	Used as a proxy for Paragon Pathfinder netflowd server, and optionally Paragon Pathfinder PCE server. The Nginx Ingress Controller needs a VIP within the MetalLB load balancer pool. This means that during the installation process you need to include this address as part of the LoadBalancer IP address ranges that you will be required to include while creating the configuration file.	Nginx MetalLB

Ports used by Ambassador:

http 80 (TCP) redirect to https

https 443 (TCP)

Paragon Planner 7000 (TCP)

DCS/NETCONF initiated 7804 (TCP)

Figure 4: Ambassador

Ports used by Insights Services, PCE server, and SNMP.

Insights Services

JTI — 4000 (UDP)

DHCP — (ZTP) 67 (UDP)

SYSLOG — 514 (UDP)

SNMP proxy — 162 (UDP)
PCE Server

PCEP — 4189 (TCP)
SNMP

SNMP Trap Receiver — 162 (UDP)

Ports used by Nginx Controller:

NetFlow 9000 (UDP)

PCEP 4189 (TCP)

Using Nginx for PCEP—During the installation process you will be asked whether you want to enable ingress proxy for PCEP.

If you select “None” or “HAProxy“ as the proxy for PCE server.
If you select "Nginx-Ingress" as a proxy for PCE server, you do not need to configure the VIP for PCE server described in the table. In this case, the Virtual IP address for Infrastructure Nginx Ingress Controller is used for both netflowd and PCE server.
Note:
The benefit of using Nginx is that a single IP address can be used for multiple services.

Figure 5: Nginx Controller

VIP for multi-primary node deployment
Load balancing configuration

VIP for multi-primary node deployment

If you are deploying a multi-primary node setup, you need an additional VIP, in the same broadcast domain as the cluster nodes. This address will be used for communication between the elected primary node and the worker nodes.

In a single primary setup, the worker communicates with the primary function using the address assigned to that node acting as primary (IP address configured on the interface of the node acting as primary).

In a multi-primary setup, the worker communicates with the primary function using the VIP, instead of the address assigned to any of the nodes acting as primary.

This IP address is referred to as the Kubernetes Master Virtual IP address in the installation wizard. This VIP must not be a part of the MetalLB load balancer pool of VIPs.

Note:

You must identify all the required VIPs, before you start the Paragon Automation installation process. You will be asked to enter these addresses as part of the installation process.

Load balancing configuration

VIPs are managed in Layer 2 by default. When all cluster nodes are in the same broadcast domain, each VIP is assigned to one cluster node at a time. Layer 2 mode provides fail-over of the VIP and does not provide actual load balancing. For true load balancing between the cluster nodes or if the nodes are in different broadcast domains, you must configure load balancing in Layer 3.

You must configure a BGP router to advertise the VIP to the network. The BGP router should be configured to use ECMP to balance TCP/IP sessions between different hosts. Connect the BGP router directly to the cluster nodes.

To configure load balancing on the cluster nodes, edit the config.yml file. For example:

In this example, The BGP router at 192.x.x.1 is responsible to advertise reachability for the VIPs with the 10.x.x.0/24 prefix to the rest of the network. The cluster allocates the VIP of this range and advertises the address for the cluster nodes that can handle the address.

DNS Server Configuration (Optional)

You can access the main Web gateway either through the ingress controller VIP or through a hostname that is configured in the DNS that resolves to the ingress controller VIP. You need to configure DNS only if you want to use a hostname to access the Web gateway.

Add the hostname to DNS as A, AAAA, or CNAME record. For lab and POC setups, you can add the hostname to the /etc/hosts file on the cluster nodes.

ON THIS PAGE