此内容没有您所选择的语言版本。

Chapter 3. Recommendations


The configuration described in this section is not required, but may improve the stability or performance of your deployment.

3.1. General recommendations

  • Take a full backup as soon as deployment is complete, and store the backup in a separate location. Take regular backups thereafter. See Configuring backup and recovery options for details.
  • Avoid running any service that your deployment depends on as a virtual machine in the same RHHI for Virtualization environment. If you must run a required service in the same deployment, carefully plan your deployment to minimize the downtime of the virtual machine running the required service.
  • Ensure that hyperconverged hosts have sufficient entropy. Failures can occur when the value in /proc/sys/kernel/random/entropy_avail is less than 200. To increase entropy, install the rng-tools package and follow the steps in https://access.redhat.com/solutions/1395493.
  • Document your environment so that everyone who works with it is aware of its current state and required procedures.

3.2. Security recommendations

  • Do not disable any security features (such as HTTPS, SELinux, and the firewall) on the hosts or virtual machines.
  • Register all hosts and Red Hat Enterprise Linux virtual machines to either the Red Hat Content Delivery Network or Red Hat Satellite in order to receive the latest security updates and errata.
  • Create individual administrator accounts, instead of allowing many people to use the default admin account, for proper activity tracking.
  • Limit access to the hosts and create separate logins. Do not create a single root login for everyone to use. See Managing Users and Groups in the Red Hat Enterprise Linux 7 System Administrator’s Guide.
  • Do not create untrusted users on hosts.
  • Avoid installing additional packages such as analyzers, compilers, or other components that add unnecessary security risk.

3.3. Host recommendations

  • Standardize the hosts in the same cluster. This includes having consistent hardware models and firmware versions. Mixing different server hardware within the same cluster can result in inconsistent performance from host to host.
  • Configure fencing devices at deployment time. Fencing devices are required for high availability.
  • Use separate hardware switches for fencing traffic. If monitoring and fencing go over the same switch, that switch becomes a single point of failure for high availability.

3.4. Networking recommendations

  • Bond network interfaces, especially on production hosts. Bonding improves the overall availability of service, as well as network bandwidth. See Network Bonding in the Administration Guide.
  • For optimal performance and simplified troubleshooting, use VLANs to separate different traffic types and make the best use of 10 GbE or 40 GbE networks.
  • If the underlying switches support jumbo frames, set the MTU to the maximum size (for example, 9000) that the underlying switches support. This setting enables optimal throughput, with higher bandwidth and reduced CPU usage, for most applications. The default MTU is determined by the minimum size supported by the underlying switches. If you have LLDP enabled, you can see the MTU supported by the peer of each host in the NIC’s tool tip in the Setup Host Networks window.
  • 1 GbE networks should only be used for management traffic. Use 10 GbE or 40 GbE for virtual machines and Ethernet-based storage.
  • If additional physical interfaces are added to a host for storage use, uncheck VM network so that the VLAN is assigned directly to the physical interface.

3.5. Self-hosted engine recommendations

  • Create a separate data center and cluster for the Red Hat Virtualization Manager and other infrastructure-level services, if the environment is large enough to allow it. Although the Manager virtual machine can run on hosts in a regular cluster, separation from production virtual machines helps facilitate backup schedules, performance, availability, and security.
  • A storage domain dedicated to the Manager virtual machine is created during self-hosted engine deployment. Do not use this storage domain for any other virtual machines.
  • All self-hosted engine nodes should have an equal CPU family so that the Manager virtual machine can safely migrate between them. If you intend to have various families, begin the installation with the lowest one.
  • If the Manager virtual machine shuts down or needs to be migrated, there must be enough memory on a self-hosted engine node for the Manager virtual machine to restart on or migrate to it.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat