Platform install on a VM

Overview

This topic describes the steps for a fresh install, using the latest installation files.

The steps for creating a VM and running the wizard should be completed for each node in your topology. Therefore, these tasks will need to be performed either once or multiple times during installation, depending on the topology you’re installing.

The install tasks (creating the VM and running the install wizard) describe the steps for a common setup of a single node from the install file for each of the following fresh install scenarios:

• Standalone installation

• A node install during multi-node installation

  Note

  For the node install during multi-node installation option, refer to Role of each VM installation for multi-node installation.

• Failover recovery

Step 1: Download the installation files and create the VM

Select your VM platform from the list below and follow the download and VM creation instructions in the relevant topic:

• VMWare Esxi 8
• Hyper-V
• Nutanix Community Edition

Next steps: Step 2: Run the installation wizard on the VM.

Step 2: Run the installation wizard on the VM

Prerequisites:

• Step 1: Download the installation files and create the VM

To run the install wizard on the VM:

1. Power on the VM.

2. Configure the options in the installation wizard:

   Step	Description
   network device	The network device name.
   IP	The IP address of the server. The required format is with Classless Inter-Domain Routing (CIDR): ip/netmask. [1]
   gateway	The IP address of the network gateway. [1]
   DNS	The DNS server is optional. Ensure that the DNS server is capable of looking up all hostnames referred to, including NTP server and remote backup locations. [1]
   NTP	The NTP server is mandatory to ensure that time keeping is accurate and synchronized among nodes in the same cluster. [1]
   boot password	Enable boot loader configuration password. See the example below.
   hostname	The hostname, not the fully qualified domain name (FQDN). The maximum character length for the hostname is 56.
   role	Choose a role for the node you’re installing on. Note: only WebProxy, Application and Database nodes are used for a modular architecture installation. A WebProxy role installs only the front-end web server together with ability to distribute load among multiple middleware nodes. An Application node is the main transaction processing engine and includes a web server which can operate by itself, or route transactions from a web node. A Database node provides persistent storage of data. A Standalone node consists of the Web, Application, and Database roles on one node. For Single-node cluster (cluster-of-one). A Unified node consists of the Web, Application, and Database roles on one node. On installation, the system needs to be clustered with other nodes and the cluster provisioned. A General node used for M2UC, NBI.
   data center	The system’s geographic location (data center name, city, country that a customer can use to identify the system location). You cannot change this setting once set.
   platform password	Platform password must be at least eight characters long and must contain both uppercase and lowercase letters and at least one numeric or special character.

[1] (1,2,3,4)

VOSS Automate supports IPv4 or IPv6

IPv6 allows the following input formats to be used:

• IPv6 Compressed, e.g.: ::ffff:c0a8:6403/64

• IPv6 Expanded (Shortened), e.g.: 0:0:0:0:0:ffff:c0a8:6403/64

• IPV6 Expanded, e.g.: 0000:0000:0000:0000:0000:ffff:c0a8:6403/64

From Automate release 24.1 onwards, network addresses are in CIDR (Classless Inter-Domain Routing) format, for example: 192.168.100.3/27 or e00d::fafe:23/112. The use of a netmask in the 255.255.255.0 format is no longer supported.

On a fresh install, if you run the install on a network with a DHCP server and encounter the following error, you can enter a valid DNS server address to continue the installation:

“Error: DNS server <DNS server> is either invalid or cannot be reached on the network”

3. Once all details are entered, installation proceeds. Monitor install progress.

   When the installation completes, the system reboots. Since all services will be stopped, this takes some time.

Related topics

• Boot password and security

Step 3: Finalize the installation

1. Once the installation completes, a sign-in prompt for the platform user displays. This confirms that the system is ready for use.

2. Connect to newly deployed server CLI as the platform user.

   A login message such as the following displays:

   Last login: Wed Nov  2 11:12:45 UTC 2016 from thwh on pts/6
   Last failed login: Wed Nov  2 11:19:53 UTC 2016 from iza on ssh:notty
   There were 2 failed login attempts since the last successful login.
   
   host: dev-test, role: webproxy,application,database, load: 0.21, USERS: 3
   date: 2016-11-02 11:19:57 +00:00, up: 14:19
   network: 172.29.253.14, ntp: 172.29.1.15
   HEALTH: NOT MONITORED
   database: 31Gb
   Failed logins: 2 since Wed Nov 02 11:19:53 2016 from iza
   
       mail - local mail management          keys - ssh/sftp credentials
    network - network management           backup - manage backups
       voss - voss management tools           log - manage system logs
   database - database management          notify - notifications control
   schedule - scheduling commands        selfservice - selfservice management
       diag - system diagnostic tools      system - system administration
       snmp - snmp configuration             user - manage users
    cluster - cluster management           drives - manage disk drives
        web - web server management           app - manage applications
   

   If the user failed to log in prior to a successful login, the count, date, and origin of the attempts are shown as Failed logins. A successful login resets this login count.

3. Run app status on all application nodes and ensure the services are all running and reporting the correct version before continuing.

4. Return to Multi-node Installation, Standalone Installation or Failover step to complete the overall installation or failover recovery procedure.

Boot password and security

The default security protocol for the web server is TLSv1.2.

Password protection can be enabled on the VOSS Automate boot loader configuration from the install wizard upon first install and also from the CLI - see the topic on System Boot Passwords in the Platform Guide for commands to enable, disable or reset the boot password.

Important

The boot password is non-recoverable.

The console example below shows the boot password configuration output:

(1)              ip    (199.29.21.89)
(2)         netmask    (255.255.255.0)
(3)         gateway    (199.29.21.1)
(4)             dns    (199.29.88.56)
(5)             ntp    (199.29.88.56)
(6)   boot password    (disabled)
(7)        hostname    (atlantic)
(8)            role    (UNDEFINED)
(9)     data centre    (earth)
(10) platform password (UNDEFINED)
Select option ? 6
Valid passwords must contain:
   at least one lower- and one upper-case letter,
   at least one numeric digit
   and a special character eg. !#@$%&^*
Password: Please enter platform user password:
 Please re-enter password
Password:
NOTE: The system boot password is now set for user platform.

When the boot password is set, the wizard will show:

(6)   boot password    (*****)

Role of each VM installation for multi-node installation

For install details on supported virtualization platforms:

See: Supported virtualization and hypervisor platforms.

According to the multi-node deployment topology and specification, the role of each VM installation is as indicated below.

• For each web proxy instance:

  • Create a new VM using the platform install file.

  • For role, select (3) WebProxy.

  • Specify the appropriate data center (Primary/DR site) for each web proxy instance.

• For each unified instance (Standard Topology only):

  • Create a new VM using the platform install file.

  • For role, select (2) Unified.

  • Specify the appropriate data center (Primary/DR Site) for each unified instance.

  The following unified nodes are required in the cluster:

  • One unified node as the Primary node at the Primary site

  • One unified node as the Secondary node at the Primary site

  • Two unified nodes as the Secondary nodes at the Disaster Recovery (DR) site

  Note

  For a six node multi cluster deployment there are:

  • Two unified nodes (one Primary and one Secondary)

  • One web proxy node at the Primary site

  • Two unified nodes (both Secondary)

  • One web proxy node at the DR site

  For an eight node multi cluster deployment, there are:

  • Four unified nodes (one Primary and three Secondary)

  • One web proxy node at the Primary site

  • Two unified nodes (both Secondary)

  • One web proxy node at the DR site

• Modular Architecture Topology

  The following nodes are required in a typical Modular Architecture cluster:

  • One Application node as the Primary node at the Primary site

  • One additional Application node at the Primary site

  • One Database node as the Primary Database node at the Primary site

  • One additional Database node at the Primary site

  • One Application node at the Disaster Recovery (DR) site

  • One Database node at the Disaster Recovery (DR) site

  Note

  For a typical Modular Architecture cluster there is one web proxy at the Primary site and one WebProxy node at the DR site.

  For each Database instance:

  • Create a new VM using the platform install file.

  • For role, select (2) Database.

  • Specify the appropriate data center (Primary/DR Site) for each database instance.

  For each Application instance:

  • Create a new VM using the platform install file.

  • For role, select (2) Application.

  • Specify the appropriate data center (Primary/DR Site) for each Application instance.

  Also refer to Multi-node Installation section in the Install Guide.

Detailed configuration can be applied from the Command Line Interface (CLI). Use the following commands for details: network help or network

For example, domain can be configured using network domain add <domain-name>.

For a geo-redundant deployment, the data center information entered in the wizard is equivalent to the location information.