Chapter 3. Support Requirements

Review this section to ensure that your planned deployment meets the requirements for support by Red Hat.

3.1. Operating System

Red Hat Hyperconverged Infrastructure (RHHI) is supported only on Red Hat Virtualization Host 4.1. Use Red Hat Virtualization Host 4.1 as a base for all other configuration.

See the Red Hat Virtualization Planning and Prerequisites Guide for details on requirements of Red Hat Virtualization: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/planning_and_prerequisites_guide/requirements

3.2. Physical Machines

Red Hat Hyperconverged Infrastructure (RHHI) requires at least 3 physical machines. Scaling to 6 physical machines or 9 physical machines is also supported.

Each physical machine must have the following capabilities.

  • at least 2 NICs per physical machine, for separation of data and management traffic (see Section 3.4, “Networking” for details)

  • for small deployments:

    • at least 12 cores
    • at least 64GB RAM
    • at most 48TB storage

  • for medium deployments:

    • at least 12 cores
    • at least 128GB RAM
    • at most 64TB storage

  • for large deployments:

    • at least 16 cores
    • at least 256GB RAM
    • at most 80TB storage

3.3. Virtual Machines

Each virtual machine can have at most 4 virtual CPUs and 2TB virtual disk space.

The supported number of virtual machines depends on their size and resource usage.

3.4. Networking

Each node requires 3 x 1 Gigabit Ethernet ports. To enable high availability, these must be split across two network switches. Ensuring that switches have separate power supplies further improves fault tolerance.

Fully-qualified domain names that are forward and reverse resolvable by DNS are required for all hosts and for the Hosted Engine virtual machine.

Client and management traffic in the cluster must be separated. This means that Red Hat Hyperconverged Infrastructure requires two separate networks:

A front-end management network

This network is used by Red Hat Virtualization and virtual machines.

  • This network should be capable of transmitting at Gigabit Ethernet speeds.
  • IP addresses assigned to this network can be selected by the administrator, but must be on the same subnet as each other.
  • IP addresses assigned to this network must not be in the same subnet as the back-end storage and migration network.
A back-end storage network

This network is used for storage and migration traffic between storage peers.

  • Red Hat recommends a 10Gbps network for the back-end storage network.
  • Red Hat Gluster Storage requires a maximum latency of 5 milliseconds between peers.

A separate network is required for network fencing devices using IPMI.

If you want to use DHCP network configuration for the Hosted Engine virtual machine, then you must have a DHCP server configured prior to configuring Red Hat Hyperconverged Infrastructure.

If you want to use geo-replication to store copies of data for disaster recovery purposes, a reliable time source is required.

3.5. Storage

3.5.1. Disks

Red Hat recommends SSDs for best performance. If you use Hard Drive Disks (HDDs), you should also configure a smaller, faster Solid State Disk (SSD) as an lvmcache.

3.5.1.1. RAID

RAID configuration limits depend on the technology in use.

  • SAS/SATA 7k disks are supported with RAID6 (at most 10+2)

  • SAS 10k and 15k disks are supported with the following:

    • RAID5 (at most 7+1)
    • RAID6 (at most 10+2)

RAID cards must use flash backed write cache.

Red Hat further recommends providing at least one hot spare drive local to each server.

3.5.2. JBOD

JBOD configurations require architecture review. Contact your Red Hat representative for details.

3.5.3. Logical Volumes

The logical volumes that comprise the engine gluster volume must be thick provisioned. This protects the Hosted Engine from out of space conditions, disruptive volume configuration changes, I/O overhead, and migration activity.

The logical volumes that comprise the vmstore and optional data gluster volumes must be thin provisioned. This allows greater flexibility in underlying volume configuration. If your thin provisioned volumes are on Hard Drive Disks (HDDs), configure a smaller, faster Solid State Disk (SSD) as an lvmcache.

3.5.4. Red Hat Gluster Storage Volumes

Red Hat Hyperconverged Infrastructure is expected to have 3–4 Red Hat Gluster Storage volumes.

  • 1 engine volume for the Hosted Engine
  • 1 vmstore volume for virtual machine boot disk images
  • 1 optional data volume for other virtual machine disk images
  • 1 shared_storage volume for geo-replication metadata

A Red Hat Hyperconverged Infrastructure deployment can contain at most 1 geo-replicated volume.

3.5.5. Volume Types

Red Hat Hyperconverged Infrastructure (RHHI) supports only replicated or arbitrated replicated volume types.

The arbitrated replicated volume type carries the following additional limitations:

  • Arbitrated replicated volumes are supported on the first three nodes only.
  • Arbitrated replicated volumes must use replica 3 arbiter 1 configuration.

  • Arbiter bricks do not store file data; they only store file names, structure, and metadata.

    This means that a three-way arbitrated replicated volume requires about 75% of the storage space that a three-way replicated volume would require to achieve the same level of consistency.

    However, because the arbiter brick stores only metadata, a three-way arbitrated replicated volume only provides the availability of a two-way replicated volume.

For further details, see the Red Hat Gluster Storage 3.3 Administration Guide: https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.3/html-single/administration_guide/#Creating_Arbitrated_Replicated_Volumes

3.6. Support limitations

  • One arbitrated replicated volume is supported as part of the initial deployment of Red Hat Hyperconverged Infrastructure (RHHI). Expanding this arbitrated replicated volume is not supported. Adding additional arbitrated replicated volumes is not supported.
  • Arbitrated replicated volumes are currently supported only in a replica 3 arbiter 1 configuration.

For further details about these volume types, see the Red Hat Gluster Storage Administration Guide:

3.7. Disaster Recovery

Red Hat strongly recommends configuring a disaster recovery solution. For details on configuring geo-replication as a disaster recovery solution, see Maintaining Red Hat Hyperconverged Infrastructure: https://access.redhat.com/documentation/en-us/red_hat_hyperconverged_infrastructure/1.1/html/maintaining_red_hat_hyperconverged_infrastructure/disaster-recovery-geo-rep.

Be aware of the following support limitations when configuring geo-replication:

  • Red Hat Hyperconverged Infrastructure (RHHI) supports only one geo-replicated volume; Red Hat recommends backing up the volume that stores the data of your virtual machines.
  • The source and destination volumes for geo-replication must be managed by different instances of Red Hat Virtualization Manager.