Create a New VM Using the Platform-Install OVA#

Note

If an OVA file is not available for your current release, you need to obtain the most recent release OVA for which there is an upgrade path to your release.

The steps below show the common setup of a single node from the OVA file - either for the purposes of:

  • a standalone installation

    If an OVA file is not available for your current release:

    1. Obtain and install the most recent release OVA for which there is an upgrade path to your release.

    2. Apply the Delta Bundle Upgrade steps for the current release to the OVA to upgrade it.

  • a node installation during multinode installation - see Notes on Multi-Node Installation

    If an OVA file is not available for your current release:

    1. Obtain and install the most recent release OVA for which there is an upgrade path to your release.

    2. Apply the Delta Bundle Upgrade steps for the current release to the cluster to upgrade it. Refer to the Upgrade Guide with Delta Bundle.

  • or during a failover recovery

    If an OVA file is not available for your current release:

    1. Obtain and install the most recent release OVA for which there is an upgrade path to your release.

    2. Add it to your cluster. Use the same configure options in the table below as were applied to the lost node.

      Note that the node version mismatch in the cluster can be ignored, since the next upgrade step aligns the versions.

    3. Apply the Delta Bundle Upgrade steps for the current release to the cluster to upgrade it.

      For details, refer to the Upgrade Guide with Delta Bundle and to the specific scenario Disaster Recovery steps in the Platform Guide.

The steps will therefore be followed either once or multiple times during installation - in accordance with the required topology.

The downloaded OVA file is imported into VMware vCenter Server. Only one OVA file is used to deploy all the functional roles. You choose the specific node role when the installation wizard is run.

  1. Log in to vSphere to access the ESXi Host.

  2. Choose File > Deploy OVF Template.

  3. Choose Source, browse to the location of the .ova file, and click Next.

  4. On the Name and Location page, enter a Name for this server.

  5. On the Deployment Configuration page, select the appropriate node type. (Refer to the list at the role option below.)

  6. Choose the resource pool in which to locate the VM.

  7. Choose the data store you want to use to deploy the new VM.

  8. Choose the disk format to use when deploying the new VM.

    • For non-SSD-based drives in production environments, “thick provisioning” is mandatory. Thick Provision Eager Zeroed is recommended.

    • For SSD-based drives, “thin provisioning” is supported.

  9. On the Network Mapping, choose your network on which this VM will reside.

  10. Do not select Power on after deployment.

  11. On the Ready to Complete page, click Finish to start the deployment.

  12. After the VM is created, select the CD ROM configuration and verify the Connect at Power On check box is enabled. Also, verify the memory, CPU, and disk settings against the requirements shown in either the Single-node cluster (cluster-of-one) System Hardware Specification or Multinode Cluster Hardware Specification section in the Install Guide.

  13. Power on the VM.

  14. Configure the options in the installation wizard:

Option

Option name

Description

1

IP

The IP address of the server.

2

netmask

The network mask for the server.

3

gateway

The IP address of the network gateway.

4

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.

5

NTP

The NTP server is mandatory to ensure that time keeping is accurate and synchronized among nodes in the same cluster.

6

boot password

Enable boot loader configuration password. See the example below.

7

hostname

The hostname, not the fully qualified domain name (FQDN).

The maximum character length for the hostname is 56.

8

role

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.

9

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.

10

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.

Note

On a fresh installation, if you run the install on a network with a DHCP server and encounter an error:

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

you can enter a valid DNS server address to continue the installation.

Once all details are entered, installation will commence. When installation is complete, the system will reboot. Since all services will be stopped, this takes some time.

Notes on Passwords 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    (*****)

Notes on Multi-Node Installation#

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

  • For each WebProxy instance, create a new VM using the platform-install OVA. For role, select (3) WebProxy. Specify the appropriate data center (Primary/DR site) for each WebProxy instance.

  • Standard Topology only: For each Unified instance, create a new VM using the platform-install OVA. 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) and one WebProxy node at the Primary site, and two Unified nodes (both Secondary) and one WebProxy node at the DR site.

    • For an eight Node Multi Cluster deployment, there are four Unified nodes (one Primary and three Secondary) and one WebProxy node at the Primary site. Two Unified nodes (both Secondary) and one WebProxy node are 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 WebProxy node at the Primary site and one WebProxy node at the DR site.

    For each Database instance, create a new VM using the platform-install OVA. 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 OVA. For role, select (2) Application. Specify the appropriate data center (Primary/DR Site) for each Application instance.

    Also refer to Multinode Installation section in the Install Guide.

Detailed configuration can be applied from the Command Line Interface (CLI). Use network help or network for details. 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.

Finalize the Installation#

When the installation of the OVA is complete, a sign-in prompt for the platform user is displayed. The system is ready for use.

Connect to newly deployed server CLI as the platform user.

The login message would for example looks the same as below:

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
security - security update tools

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.

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

Note

Return to Multinode Installation, Standalone Installation or Failover step to complete the overall installation or failover recovery procedure.