이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 4. Recommendations
This chapter describes configuration that is not strictly required, but may improve the performance or stability of your environment.
4.1. General Recommendations
- Take a full backup as soon as the deployment is complete, and store it in a separate location. Take regular backups thereafter. See Backups and Migration in the Administration Guide.
- Avoid running any service that Red Hat Virtualization depends on as a virtual machine in the same environment. If this is done, it must be planned carefully to minimize downtime, if the virtual machine containing that service incurs downtime.
-
Ensure the bare-metal host or virtual machine that the Red Hat Virtualization Manager will be installed on has enough entropy. Values below 200 can cause the Manager setup to fail. To check the entropy value, run
cat /proc/sys/kernel/random/entropy_avail. To increase entropy, install therng-toolspackage and follow the steps in https://access.redhat.com/solutions/1395493. You can automate the deployment of hosts and virtual machines using PXE, Kickstart, Satellite, CloudForms, Ansible, or a combination thereof. However, installing a self-hosted engine using PXE is not supported. See:
- Automating Red Hat Virtualization Host Deployment in the Installation Guide, for the additional requirements for automated RHVH deployment using PXE and Kickstart.
- Preparing for a Network Installation in the Red Hat Enterprise Linux 7 Installation Guide.
- Kickstart Installations in the Red Hat Enterprise Linux 7 Installation Guide.
- Red Hat Satellite 6.2 Provisioning Guide
- Red Hat CloudForms 4.5 Provisioning Virtual Machines and Hosts
- Automating Configuration Tasks using Ansible in the Administration Guide.
- Set the system time zone for all machines in your deployment to UTC. This ensures that data collection and connectivity are not interrupted by variations in your local time zone, such as daylight savings time.
Use Network Time Protocol (NTP) on all hosts and virtual machines in the environment in order to synchronize time. Authentication and certificates are particularly sensitive to time skew. Using
chronydis recommended overntpd. See the following sections of the Red Hat Enterprise Linux 7 System Administrator’s Guide:- Document everything, so that anyone who works with the environment is aware of its current state and required procedures.
4.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
adminaccount, for proper activity tracking. -
Limit access to the hosts and create separate logins. Do not create a single
rootlogin 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.
- When deploying the Red Hat Enterprise Linux hosts, only install packages and services required to satisfy virtualization, performance, security, and monitoring requirements. Production hosts should not have additional packages such as analyzers, compilers, or other components that add unnecessary security risk.
4.3. Host Recommendations
- Standardize the make, model, hardware, and firmware/BIOS version of hosts in the same cluster. Mixing different makes of servers within the same cluster does not provide consistent performance from host to host.
- Although running both RHEL hosts and RHVH in the same cluster is supported, Red Hat recommends having, and documenting, a business or technical use case behind the mixed design.
- 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.
4.4. Networking Recommendations
- Bond network interfaces, especially on production hosts. Bonding improves the overall availability of service, as well as network bandwidth. See Bonds in the Administration Guide.
- For optimal performance and simplified troubleshooting, use VLANs to separate different traffic types and make the best use of 10GbE or 40GbE networks.
- 1GbE networks should only be used for management traffic. Use 10GbE or 40GbE for virtual machines and Ethernet-based storage.
- If additional physical interfaces are added to a host for storage use, uncheck VM traffic so that the VLAN is assigned directly to the physical interface.
- If Red Hat OpenStack Platform is already deployed, integrate Red Hat Virtualization with OpenStack Networking (neutron) to add Open vSwitch capabilities.
4.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.
- If you are anticipating heavy storage workloads, separate the migration, management, and storage networks to reduce the impact on the Manager virtual machine’s health.
- Although there is technically no hard limit on the number of hosts per cluster, Red Hat recommends limiting self-hosted engine nodes to 7 nodes per cluster. Distribute the servers in a way that allows better resilience (such as in different racks).
- 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.
