OnApp Cloud handles cloud deployment, VS deployment, VS management & resource allocation, Compute resource and SAN management, failover, user management, billing, self-provisioning, CDN and DNS, and other associated functions. Here's a brief description of the main components and features of the OnApp installation:
There are two required server types in an OnApp configuration – Compute resource servers and the Control Panel server. OnApp also requires storage devices for templates, virtual servers and backups.
Control Panel server
The Control Panel server (sometimes known as the Base server) hosts the OnApp user interface and manages all the processes controlled by OnApp.
The Control Panel server:
- Provides a web-based user interface
- Assigns a virtual server to a Compute resource
- Creates/starts/stops/deletes virtual servers
- Resizes CPU and storage
- Manages virtual servers through a console session
- Creates backups of virtual servers
- Allows virtual servers to be restored from a backup
- Allows the creation of custom templates from virtual server backups, for future deployment of new virtual servers
- Displays your CPU usage and network utilization
Compute resources are Xen, KVM, or VMware ESXi/vSphere 5.0 -powered servers running on bare metal, with CentOS Linux as the management operating system.This ensures highly efficient use of available hardware, and complete isolation of virtual server processes. The management OS controls virtual servers as well as handling network/disk connectivity, monitoring, IP address anti-spoofing and more.
- Provide system resources such as CPU, memory, and network
- Control the virtual differentiation of entities such as virtual servers and application data being delivered to cloud-hosted applications
- Take care of secure virtualization and channeling of storage, data communications and server processing
- Can be located at different geographical zones
- Can have different CPU and RAM
OnApp Cloud supports three Compute resource virtualization platforms:
- Xen - OnApp supports Xen 3 and Xen 4
VMware Compute resources operate in a slightly different way. With Xen/KVM OnApp controls Compute resources directly. With VMware, OnApp controls the VMware vCenter. This allows vCenter to control the VSs with the full range of VMware functionality including DRS and vMotion to ensure that the operation is optimal.
CloudBoot Compute resources
CloudBoot functionality is a method of Compute resource installation without the presence of a local disk or other local storage, utilizing the PXE and DHCP servers. To start using CloudBoot, you must have Integraded Storage configured and the CloudBoot enabled in the system configuration first. See CloudBoot Compute Resources section for details. CloudBoot Compute resources are used for smart and baremetal server provisioning.
OnApp gives you complete control of your virtual servers (VSs), and all files and processes running on those servers. You can start, stop, reboot and delete virtual servers. You can move VSs between Compute resources with no downtime. OnApp also lets you perform automatic and manual backups, and restore VSs in case of failure.
When creating a virtual server, you can choose a Compute resource server with data store attached if you wish. If not, the system will search for Compute resources available that have sufficient RAM and storage for that virtual server, and choose the one with the lowest (but sufficient) amount of RAM available.
You can monitor the CPU usage of each virtual server, and the network utilization of each network interface. This helps you decide if and when to change the resources available to each VS. OnApp also provides detailed logs of all tasks which are running, pending, have failed or have been completed.
Smart servers are dedicated entities based on CloudBoot Compute resources with passthrough enabled. Smart servers are created and managed exactly the same as virtual servers, except only one smart server can be deployed per Compute resource. Smart servers can be organized into zones to create different tiers of service - for example, by setting up different zones for smart appliances, with limits and prices specified per zone. Smart appliance zones can also be used to create private clouds for specific users.
Baremetal servers are physical servers that reside directly on the hardware without the virtualization layer. Namely, baremetal server is a Compute resource that runs on the OS installed. Baremetal Compute resources can not have more than one baremetal server located on it.
For VS template and backup storage we recommend that you set up a separate server with SSH (preferred) or NFS (for high end NAS). However, in a CloudBoot environment or for a small scale installation you can use the Control Panel server to host the templates and backups.
You will also need a storage platform for virtual server disk storage. OnApp provides an integrated storage platform that enables you to expose local storage drives across Compute resources as a distributed block SAN with full redundancy and failover properties. Additionally, you can use any block based storage platform, such as local disks in Compute resources, an Ethernet SAN such as iSCSI or AoE, or hardware (fiber) SAN. Storage Area Networks are core segments of the cloud system, and OnApp can control their physical and virtual routing. This control enables seamless SAN failover management, including SAN testing, emergency migration and data backup.
With OnApp you can create complex networks between virtual servers residing on a single host, or across multiple installations of OnApp. You can configure each virtual server with one or more virtual NICs, each with its own IP and MAC address, to make them act like physical servers.
OnApp ensures that each customer has their own dedicated virtual network, isolated and secure. They can only see their traffic, even if they share the same physical server as another customer. OnApp enables you to modify network configurations without changing actual cabling and switch setups.
An OnApp template is a pre-configured OS image that is used to build virtual servers. There are two types of templates for virtual server deployment in OnApp: downloadable templates provided by OnApp, and custom templates you create from existing virtual servers. The OnApp template library includes a wide range of VS templates for various distributions of Windows and Linux, both 32- and 64-bit.
At present OnApp does not support VSs/templates with Active Directory Domain Controllers.
OnApp is a highly scalable cloud deployment and management tool that allows you to add and remove Compute resources, data stores and resources at any time to meet your changing needs. You can add more CPUs and memory to a specific virtual server to increase its capacity, and increase the total available RAM and CPU by adding new Compute resources.
OnApp provides high reliability and availability in a number of ways:
- Compute resource failover management system — If a Compute resource fails, OnApp's self-healing architecture automatically moves virtual servers to another box. Compute resources regularly update the control panel with their status. If they do not return valid data for a period of time, they are marked as offline, and an appropriate new Compute resource is selected for a virtual server to boot there. This process is fully automatic but may take several minutes. When the crashed Compute resource comes online, it will be again available, but virtual servers previously migrated from it will not be migrated back.
- Virtual servers — OnApp keeps virtual servers running even if the Control Panel server goes offline. In such an event, you won't be able to perform any actions to virtual servers until access to the Control Panel server has been restored.
- Backup mechanisms — There is storage security provided by the backup mechanisms on both virtual and physical storage. Both automatic and manual backups provide the ability to capture the current state of a virtual server. You can always restore the virtual server from a backup if needed. There are also emergency mySQL backups as part of the disaster recovery system.
- Database replication (planned feature) — OnApp will feature database replication which includes the creation and maintenance of multiple copies of the same database. Database replication improves availability: when your main database becomes unavailable, the slave copy will take over.
- High Availability Control Panel — OnApp High Availability feature brings new opportunity to deploy more than one Control Panel within one cloud. This allows to improve cloud load balancing, minimize server downtime in case of CP issues and enhance scalability of the whole infrastructure.
OnApp provides multiple layers of security:
- Compute resource — OnApp is a multi-Compute resource cloud system that currently supports Xen, KVM and VMware (Hyper-V and other Compute resources will be added in future releases). The first layer of security is provided by the Compute resource itself. For example, Xen provides full isolation between virtual servers and allows each virtual server to access its own disk only. When a virtual server makes a request for data, it gets redirected to its correct disk. Xen dictates which virtual servers and resources are allowed to run or be accessed at any given time.
- Firewall — In addition to the Compute resource security mechanism, there is also an anti-spoof firewall which resides on the server where you store virtual servers. The firewall enables the management operating system of the Compute resource to examine packets entering and leaving the virtual server. It blocks packets that do not belong to the virtual server and accepts those meeting the rules. The firewall prevents IP spoofing and packet sniffing.
- Control Panel — Virtual servers in OnApp are completely controlled by the administrator. Administrators have full root (Linux) or Administrator (Windows) access to accounts and servers. The Control Panel also lets you assign different levels of user access to virtual servers, Compute resources, consoles and disks.
- Network Security is provided by completely isolating virtual servers from each other using VLANs. Each customer can be assigned their own VLAN, so using their private IP they can only access addresses within that VLAN. Using a public IP, they can only access those boxes which are manually specified, using the Integrated Console.