CompTIA Cloud+ Study Guide. Ben Piper
Читать онлайн книгу.
System Requirements
After you have completed your assessments and needs analysis, you'll have then defined your requirements and which cloud service and deployment models best meet them. The next step is to select a pilot application to migrate to the cloud from your existing data center.
Prior to performing the migration, the engineering team should sit down and review the complete design, from the application, configuration, hardware, and networking to the storage and security. As part of this verification, it is helpful to stage the system in the cloud as a proof-of-concept design. This allows everyone to test the systems and configuration in a cloud environment prior to going live.
Correct Scaling for Your Requirements
The ability of the cloud to scale resources up or down rapidly to match demand is called elasticity. For IaaS services, this can be done automatically as needed using autoscaling. This allows cloud consumers to scale up automatically as their workload increases and then have the cloud remove the services after the workload subsides. For SaaS and PaaS services, dynamic allocation of resources occurs automatically and is handled by the cloud provider. (Later in the chapter, we'll discuss the division of responsibilities between you and the provider.) With elastic computing, there is no longer any need to deploy servers and storage systems designed to handle peak loads—servers and systems that may otherwise sit idle during normal operations. Now you can scale the cloud infrastructure to the normal load and automatically expand as needed when the occasion arises.
On-demand cloud services allow the cloud customer to create instantly additional servers, storage, processing power, or any other services as required. On-demand allows customers to consume cloud services only as needed and scale back when they are no longer required. For example, if a developer needs to provision a database and application server for testing, they can quickly provision these servers and deprovision them once they're no longer needed. This is also referred to as a just-in-time service because it allows cloud services to be added and removed as needed.
Pay as you grow (PAYG) is like a basic utility, such as power or water, where you pay for only what you use. This is very cost effective because there are minimal up-front costs, and the ongoing costs track your actual consumption of the service. The elasticity of the cloud lets you add resources on-demand, so there's no need to overprovision for future growth. With a normal data center operation, the computing must be overprovisioned to take into account peak usage or future requirements that may never be needed.
Making Sure the Cloud Is Always Available
In this section, you'll become familiar with common deployment architectures used by many of the leading cloud providers to address availability, survivability, and resilience in their services offerings.
Regions
Major cloud providers partition their operations into regions for fault tolerance and to offer localized performance advantages. A region is not a monolithic data center but rather a geographical area of presence that usually falls within a defined political boundary, such as a state or country. For example, a cloud company may offer regions throughout the world, as shown in Figure 1.20. They may have regions in Sydney and Tokyo in the Asia Pacific region, and in Europe there may be regions called London and Oslo. In North America there could be regions in Boston, Ottawa, Austin, and San Jose.
FIGURE 1.20 Cloud regions
All of the regions are interconnected to each other and the Internet with high-speed optical networks but are isolated from each other, so if there is an outage in one region, it should not affect the operations of other regions.
Generally, data and resources in one region aren't replicated to any other regions unless you specifically configure such replication to occur. One of the reasons for this is to address regulatory and compliance issues that require data to remain in its country of origin.
When you deploy your cloud operations, you'll be given a choice of what region you want to use. Also, for a global presence and to reduce network delays, the cloud customer can choose to replicate operations in multiple regions around the world.
Availability Zones
Regions are divided into one or more availability zones (AZs). Each region will usually have two or more availability zones for fault tolerance. AZs almost always correspond to individual data centers. Each AZ has its own redundant power and network connections. Within a region, AZs may be located a greater distance apart, especially if the region is in an area prone to natural disasters such as hurricanes or earthquakes. When running redundant VMs in the cloud, it's a best practice to spread them across AZs to take advantage of the resiliency that they provide. Figure 1.21 illustrates the concept of availability zones.
FIGURE 1.21 Availability zones
Cluster Placement
As I alluded to earlier, you can choose to run VMs on different virtualization hosts for redundancy in case one host fails. However, there are times when you want VMs to run on the same host, such as when the VMs need extremely low-latency network connectivity to one another. To achieve this, you would group these VMs into the same cluster and implement a cluster placement rule to ensure that the VMs always run on the same host. If this sounds familiar, it's because this is the same principle you read about in the discussion of hypervisor affinity rules.
This approach obviously isn't resilient if that host fails, so what you may also do is to create multiple clusters of redundant VMs that run on different hosts, and perhaps even in different AZs.
Remote Management of VMs
In this section, you'll learn about remote access techniques and look at what tools are available to manage and monitor your VMs. Remember that you don't have physical access to the cloud provider's data centers, so remote access is your only option for managing your servers. Furthermore, the cloud provider will not give you direct access to the hypervisor, which is typically going to be proprietary. This is unlike a traditional data center environment in which you can install a hypervisor management application on a workstation and fully configure and manage the hypervisor, as Figure 1.22 and Figure 1.23 illustrate.
FIGURE 1.22 Local computer running the hypervisor management application
FIGURE 1.23 Remote hypervisor management application
As we've discussed, your options for managing your VMs and other cloud resources are limited to the web management interface, command-line