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

Two separate networks are required so that client and management traffic in the cluster are separated.

Front-end network

This is used as a network bridge for ovirt management.

  • IP addresses assigned to the front-end network should be from the same subnet, and should be from a different subnet to back-end IP addresses.
Back-end network

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

  • Red Hat recommends a 10Gbps network for the back-end network.
  • Red Hat Gluster Storage requires a maximum latency of 5 milliseconds between peers.
  • IP addresses assigned to the back-end network should be from the same subnet, and should be from a different subnet to front-end IP addresses.

All host FQDNs and the Hosted Engine virtual machine’s FQDN should be forward and reverse resolvable by DNS.

A DHCP server is required when selecting DHCP network configuration for the Hosted Engine virtual machine.

3.5. Storage

3.5.1. Architecture

A single Red Hat Gluster Storage cluster can have 3–4 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 Gluster Storage cluster can contain at most 1 geo-replicated volume.

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

3.5.2. 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.

3.5.3. JBOD

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

3.5.4. 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.2 Administration Guide: https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.2/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.0/html/maintaining_red_hat_hyperconverged_infrastructure/configure_disaster_recovery_using_geo_replication.

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.