Servers
When you are finished with networks and storage, you can proceed to setting up the following servers:
Installation Requirements
There are some requirements to server installation that you need to follow. OnApp runs on CentOS but a CentOS version depends on a virtualization you are running.
- We recommend installing CentOS from a minimal CentOS ISO for Control Panel servers, static backup servers, and compute resources.
Full root access: please do not create the user 'onapp' since it is created as a part of the RPM installation.
When installing CentOS, do not use a partition scheme that allocates the majority of disk space to a dedicated
/homepartition, leaving therootpartition a small amount of space. Instead, allocate the majority of disk space to therootpartition or a dedicated/onapppartition.
For the list of all requirements, see Software Specifications.
Please do not create mixed compute zones. Do not add CloudBoot and static compute resources to one compute zone, as well as Xen and KVM compute resources to one compute zone.
Control Panel Server
The Control Panel server is absolutely critical to the stability and performance of the cloud. There are a few things to consider when selecting hardware for this server. When your production workloads grow, you need to add more compute resources and SANs, which puts more load on you Control Panel. Selecting the right hardware at the beginning is important and helps to avoid downtime during upgrades later down the line.
The Control Panel server may experience a high load on MySQL as you add more compute resources, so a fast disk array and lots of memory is recommended. For more details, see the Hardware Specifications document. If you have the Control Panel server specifications in mind, you can send them to your OnApp integrations specialist for a review.
Backup Server
The backup server stores virtual server backups and templates. It is also responsible for processing any disk transactions running in your cloud, such as provisioning virtual servers, taking backups or resizing disks.
The backup server must hold a backup storage volume. This can be a local disk array or can be mounted via NFS or iSCSI from a back end storage node. Note that the backup volume should not be presented from the same physical hardware that presents the primary storage volume to the compute resources.
Unlike primary storage, performance is not so essential here so there is less need for RAID10 or a high volume of spindles. You can consider a RAID level that provides more space as opposed to redundancy and performance: RAID5 or RAID6 is usually ideal for the backup volume. When configuring SAN, take into consideration that a larger block size is recommended owing to the nature of the data being stored on this array.
Backup storage is used to hold very large files so we recommend that it's at least 1.5 - 2x larger than the primary storage volume(s) available in the cloud. Additional backup servers can be added to your cloud as needed. In the traditional/centralized SAN configuration, you have to bind all your data stores to a backup server. The volume groups of each data store based on SAN must be shared with the backup server.
In a cloud where CloudBoot is enabled, you have to use CloudBoot backup servers instead of dedicated backup servers. To do so, you have to create a CloudBoot compute resource to be used as a backup server. You can set up CloudBoot backup servers and virtual dedicated backup servers to be used with the Integrated Storage. The backup scheme remains unchanged.
Compute Resource Servers
Compute resources are where virtual servers run in your cloud. A small amount of compute resource CPU, memory, and disk resource is reserved for the OnApp engine: the remainder is available as virtual resources to allocate to virtual servers.
If you use a centralized SAN, then the virtual server disks run on that SAN, and the compute resource own disk is used to boot the compute resource and run the OnApp engine. Performance here is not critical but we recommend introducing some redundancy: RAID1 SATA/SAS would be perfect. If you use OnApp Storage (our integrated SAN), you should factor more disks into your compute resource spec to enable the creation of a distributed SAN using those disks. If you choose not to run a centralized SAN or OnApp Storage, it is possible to have storage running locally on compute resources, though you lose the ability to failover from compute resource to compute resource: this is not recommended for an optimal cloud setup.
When you build your hardware, it's important to take into consideration the specifications of the primary components that will be virtualized: RAM and CPU. Note that you can oversell CPU cores in OnApp, but not RAM. RAM is a dedicated resource so the physical limitation to how many virtual servers you can fit on a single compute resource is limited by the amount of RAM installed on that compute resource. Another limitation to consider is that the compute resource CPU is a shared resource: the physical cores are shared among virtual servers running on a compute resource. Do not overload the compute resource with too many virtual servers as this can stretch the available CPU time and degrade the performance of all servers on that compute resource.
It's also important to note that too many virtual servers could potentially saturate the SAN NICs on the compute resource, which can introduce instability and performance loss to virtual servers (see the Host Components - Compute Resource Connectivity to Storage Network section for more details).
In the Networking document, you can see that OnApp requires at least 4 NICs on the compute resources. Note that this does not take into consideration any bonding or multipath configurations, which we recommend for any production setup on most if not all of our networks. You should consider bonding on the management network and multipath on the storage network(s) to improve stability and performance.
You must have Intel-VT or AMD-V enabled in the BIOS of all compute resources to enable you to provision Windows-based virtual servers on your OnApp cloud.
CloudBoot Compute Resource Servers
CloudBoot is a feature that enables fast provisioning of Xen and KVM compute resources without any pre-installation requirements. Using network/PXE boot methods, a new server can be plugged in and powered on. This server is automatically discovered by the OnApp Control Panel Server and installed over the network, so it is booted as a fully configured compute resource ready to host virtual servers.
The Control Panel Server manages IP address to hardware MAC assignment and the booting of a Xen or KVM image on demand. The compute resource images come preinstalled with all the SSH keys and any other settings specific to the node to enable compute resources to come online instantly. Images are booted as a standalone RAM disk. After images are bootstrapped, they operate independently from other servers but without any persistent installation dependency.
This enables booting of diskless blades, as well as booting compute resources with Integrated Storage enabled (OnApp Storage) where all local storage drives are presented to the integrated SAN.
Dependencies:
- Network/PXE boot must be supported and enabled on the primary management NIC for the compute resource servers.
- A secondary NIC is recommended for the Control Panel Server to provide a fully isolated network for the compute resource management subnet, including PXE boot and DHCP support for the compute resources.
For resilience, a secondary static TFTP server target can be configured to handle Control Panel server failure and ensure hardware boot consistency in the event of such a failure.