Shareable Private Space on a Public Cloud

Transcription

1 Shareable Private Space on a Public Cloud 1.0 Introduction: Sharable private space on public cloud (a distributed computing platform) is nontrivial task. With immerse of Free & Open Source Software (FOSS), this task now become some what trivial with use of modified versions of cloud-computing. OpenStack is the best example of use of FOSS in cloud computing. A scalable, reliable, high-performing cloud environment includes much more than just servers. Right thing comes with right documentation, yet its another non-trivial task. A detailed architecture of the cloud-computing with simple, and secured access is foremost priority. For this free and open architectural assistance is required. 1.1 Architecture of the cloud computing: The majority of cloud workloads currently run on instances using hypervisor technologies such as KVM, Xen, or ESXi. The challenge is that each of these hypervisors use an image format that is mostly, or not at all, compatible with one another. In a private or hybrid cloud solution, this can be mitigated by standardizing on the same hypervisor and instance image format but this is not always feasible. This is particularly evident if one of the clouds in the architecture is a public cloud that is outside of the control of the designers. Many clouds offer complementary services over and above the basic compute, network, and storage components. These additional services are often used to simplify the deployment and management of applications on a cloud platform. Fig. 1.0 OpenStack cloud platform

2 1.2 Mounting public cloud space for private use: An online classified advertising company wants to run web applications consisting of Tomcat, Nginx and MariaDB in a private cloud. In order to meet policy requirements, the cloud infrastructure will run in their own data center. They have predictable load requirements but require an element of scaling to cope with nightly increases in demand. Their current environment is not flexible enough to align with their goal of running an open source API driven environment. Their current environment consists of the following: Between 120 and 140 installations of Nginx and Tomcat, each with 2 vcpus and 4 GB of RAM A three-node MariaDB and Galera cluster, each with 4 vcpus and 8 GB RAM The company runs hardware load balancers and multiple web applications serving the sites. The company orchestrates their environment using a combination of scripts and Puppet. The websites generate a large amount of log data each day that needs to be archived. The solution would consist of the following OpenStack components: A firewall, switches and load balancers on the public facing network connections. OpenStack Controller services running Image, Identity, Networking and supporting services such as MariaDB and RabbitMQ. The controllers will run in a highly available configuration on at least three controller nodes. OpenStack Compute nodes running the KVM hypervisor. OpenStack Block Storage for use by compute instances that require persistent storage such as databases for dynamic sites. OpenStack Object Storage for serving static objects such as images. Fig. 1.2 Mounting Public Cloud space for private use

3 Fig. 1.3 Private Cloud Storage Schema 1.3 Operating system for cloud storage: The selection of operating system (OS) and hypervisor has a significant impact on the end point design. Selecting a particular operating system and hypervisor could affect server hardware selection. For example, a selected combination needs to be supported on the selected hardware. Ensuring the storage hardware selection and topology supports the selected operating system and hypervisor combination should also be considered. Additionally, make sure that the networking hardware selection and topology will work with the chosen operating system and hypervisor combination. For example, if the design uses Link Aggregation Control Protocol (LACP), the hypervisor needs to support it.

4 Some areas that could be impacted by the selection of OS and hypervisor include: Cost Selecting a commercially supported hypervisor such as Microsoft Hyper-V will result in a different cost model rather than chosen a community-supported open source hypervisor like Kinstance or Xen. Even within the ranks of open source solutions, choosing Ubuntu over Red Hat (or vice versa) will have an impact on cost due to support contracts. On the other hand, business or application requirements might dictate a specific or commercially supported hypervisor. Supportability Depending on the selected hypervisor, the staff should have the appropriate training and knowledge to support the selected OS and hypervisor combination. If they do not, training will need to be provided which could have a cost impact on the design. Management tools The management tools used for Ubuntu and Kinstance differ from the management tools for VMware vsphere. Although both OS and hypervisor combinations are supported by OpenStack, there will be very different impacts to the rest of the design as a result of the selection of one combination versus the other. Scale and performance Security Ensure that selected OS and hypervisor combinations meet the appropriate scale and performance requirements. The chosen architecture will need to meet the targeted instancehost ratios with the selected OS-hypervisor combination. Ensure that the design can accommodate the regular periodic installation of application security patches while maintaining the required workloads. The frequency of security patches for the proposed OS-hypervisor combination will have an impact on performance and the patch installation process could affect maintenance windows. Supported features Determine what features of OpenStack are required. This will often determine the selection of the OS-hypervisor combination. Certain features are only available with specific OSs or hypervisors. For example, if certain features are not available, the design might need to be modified to meet the user requirements. Interoperability Consideration should be given to the ability of the selected OS-hypervisor combination to interoperate or co-exist with other OS-hypervisors, or other software solutions in the overall design (if required). Operational and troubleshooting tools for one OS-hypervisor combination may differ from the tools used for another OS-hypervisor combination and, as a result, the design will need to address if the two sets of tools need to interoperate.

5 1.4 Management software: The selected supplemental software solution impacts and affects the overall cloud design. This includes software for providing clustering, logging, monitoring and alerting. Inclusion of clustering Software, such as Corosync or Pacemaker, is determined primarily by the availability design requirements. Therefore, the impact of including (or not including) these software packages is primarily determined by the availability of the cloud infrastructure and the complexity of supporting the configuration after it is deployed. The OpenStack High Availability Guide provides more details on the installation and configuration of Corosync and Pacemaker, should these packages need to be included in the design. Requirements for logging, monitoring, and alerting are determined by operational considerations. Each of these sub-categories includes a number of various options. For example, in the logging subcategory one might consider Logstash, Splunk, Log Insight, or some other log aggregationconsolidation tool. Logs should be stored in a centralized location to make it easier to perform analytics against the data. Log data analytics engines can also provide automation and issue notification by providing a mechanism to both alert and automatically attempt to remediate some of the more commonly known issues. If any of these software packages are needed, then the design must account for the additional resource consumption (CPU, RAM, storage, and network bandwidth for a log aggregation solution, for example). Some other potential design impacts include: OS-hypervisor combination: Ensure that the selected logging, monitoring, or alerting tools support the proposed OS-hypervisor combination. Network hardware: The network hardware selection needs to be supported by the logging, monitoring, and alerting software.