Minimal Technical Requirements and Architecture

Scalability Guide

This guide is for users who are utilizing virtual machines in their Hubble deployment, whether it is an on-premise or cloud deployment. The purpose of this guide is to provide guidelines for hardware and virtual machine configurations, and to illustrate how many users an organization could accommodate per server, based on the types of users, data, and frequency of change in their environment. The data below is sourced from a combination of application recommendations from our independent software vendors (ISVs), along with customer data from actual deployments. This is not an application scalability guide.

This guide is therefore best used as a starting point for your planning - as with any deployment, your usage will depend on the variables of your own environment.

Hubble Application Server Configuration

Table 1: Application Server Guidelines

¹ Each of the mentioned storage needs will require their own separate drive/partition (i.e. you will not be able to combine the OS and Application parts in a single 70 GB partition).

²The Data drive will need to be formatted with the ext4 filesystem and be auto-mounted to the /mnt/ data/ folder. We also HIGHLY RECOMMEND configuring an NFS mount upon /mnt/data/backups to prevent losing data in an event of a disaster with App Server. For more details, please see Prerequisites in the Hubble Application Server Installation section of this guide.

³ We recommend using one of the following Linux distributions:

• Ubuntu: Versions 16.04.4 LTS to 22.04.2 LTS
• CentOS: Version 8
• RHEL: Versions 7.5 to 9.2

⁴ You will need to install the exact version of Docker Compose mentioned here - higher versions are not supported. See https://docs.docker.com/compose/install/. for instructions. You can install newer versions of Docker through:

• Ubuntu - Docker CE installation documentation can be found at https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/.
• CentOS - Docker CE installation documentation can be found https://docs.docker.com/engine/installation/linux/docker-ce/centos/. See below for a troubleshooting tip.
• RHEL - RedHat supports the version of Docker provided in their repository. See https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html-single/getting_started_with_containers/#getting_docker_in_rhel_7.
• Oracle Linux - we recommend following Docker's instructions for installing on CentOS, as the modified Docker version 17.06.2.ol in the repository provided by Oracle does not work with docker-thinpool (at time of writing).

Installing Docker on Systems with RHEL 8 Servers

Steps to install docker on systems with RHEL 8 servers:

Troubleshooting Docker CE Installation on CentOS

If you see the following error during Docker CE installation on CentOS:

To resolve this, you should uninstall docker-engine-selinux:

Then install the newer container-selinux package (version 2.42 was appropriate at time of writing but you may need to update this):

And then try using yum to install docker-ce again.

Hubble Web Server

A load balancer is included in the Application Server, which can distribute user requests across multiple web servers. Depending on usage profile, we recommend a maximum loading of about 50 users per web server.

Table 2: Web Server (IIS) Guidelines

¹ The Hubble software will only install on the C: drive, not another drive.

Networking Requirements

• Internet access during deployment, installation and configuration on all nodes.
• See Network Diagram.

Storage Requirements (Accelerator)

• Specific storage requirements will vary depending upon source ERP data, desired replication and analytics functions.
• For guidance, the compression ratio between source ERP and Vector is 4:3.
• Future disk expansion will require assistance from the Hubble Infrastructure Team.

Clock Synchronization

Hubble's servers communicate with each other and require that their clocks are sufficiently synchronized. If there is more than 5 minutes difference between their clocks, a timeout error will be logged and users will not be able to login.

Please ensure that each machine used for Hubble is maintained with the correct time by using the corresponding VMWare option or operating system settings/services.

Performance Testing

Below is a list of important things to remember during your own testing:

1. Define “acceptable” user experience: Defining user experience (UX) requires careful examination of user and application interaction. This can be obvious, like the rendering time for a workspace to appear. It can also be less obvious, like the ability to smoothly scroll down a page or the “snappy” reaction for a menu to appear after a right click. Ask users to report metrics, and to judge specific activities or functions using finite scales (e.g. 1-5, 5 being best), to avoid feedback that is too generic.
2. Compare real world workloads: In virtual environments, time-slicing of resources allows users to get the same level of performance even when sharing resources. This is due to user “think time” which includes any time the user is not actually interacting with the application, or when not using the application or even sitting at their workstation. Add up all the time away from the application (meetings, lunch, out of office, etc.) and one could expect to get even more benefits from shared resources. These benefits equate to more resources for the user’s session and typically a more responsive application, thus a better perceived experience by the end user, as opposed to peak workload benchmarks with inhuman-like uninterrupted work.
3. Test with real users: It is important to actually look at the application running be sure that the experience is enjoyable for users. That being said, it’s also important to maintain perspective, especially if you are not a regular user of the applications. While a data center administrator deploying Hubble in a virtual environment might view a testing desktop and think the experience is slow or sluggish, while a user who works with it daily might find it normal. The feedback from an actual end user using the application in a virtual desktop is the ultimate test of success. Add in the point above about real world workloads and you see why real users are the most accurate means of testing.

Architecture Diagram

Note: External Access

We require external (Internet) access, during deployment only:

• In the Hubble Application Server, we need internet access for downloading containers from Docker Hub. You can test this by running the “docker run hello-world” command from a shell with root privileges.

• In the Hubble Web Server, we need internet access for downloading updates from Microsoft.

This access can be provided through a proxy if your organization requires one for internet connectivity.

The following diagram illustrates the network architecture of an On-premise deployment:

Port Explanations

The ports that are used to access the Hubble Application Server:

• TCP 22: SSH
• TCP 443: HAProxy (if using HTTPS)
• TCP 592: HAProxy (if using HTTPS)
• TCP 3000: Configuration UI
• TCP 5000: Repository Backup Service
• TCP 5432: PostgreSQL
• TCP 5433: Repository Backup Service
• TCP 5580: Wkhtmltopdf (PDF generation)
• TCP 5672: RabbitMQ
• TCP 6379: Redis
• TCP 15672: RabbitMQ Admin

The ports that are used to access the Hubble Web Server:

• TCP 80: IIS
• TCP 3389: RDP

Note: You can also configure SSO on HTTPS using Port 443 instead of 7001 through Load Balancer. Similarly, configuring Reporting on HTTPS using Port 443 instead of 592 through Load Balancer with redirect rules is also possible.

Hubble Tools

As part of Hubble installation, some third party tools are installed. Below is a list of the services Hubble uses, with the corresponding vendors:

Configuration

Default Configurations

• Administrator password: password

Hubble Configuration Page

There are a number of configuration details that are required when deploying Hubble.

These are entered into the configuration web page, and should be known before deployment.