9.1. Remote Administration System The remote administration system mechanism (Figure 9.1) provides tools and user-interfaces for external cloud resource administrators to configure and administer cloud-based IT resources. Figure 9.1. The symbol used in this book for the remote administration system. The displayed user-interface will typically be labeled to indicate a specific type of portal. A remote administration system can establish a portal for access to administration and management features of various underlying systems, including the resource management, SLA management, and billing management systems described in this chapter (Figure 9.2). Figure 9.2. The remote administration system abstracts underlying management systems to expose and centralize administration controls to external cloud resource administrators. The system provides a customizable user console, while programmatically interfacing with underlying management systems via their APIs. The tools and APIs

9.0 Introduction To Cloud Management Mechanisms #Cloud-based IT resources need to be #setup, #configured, #maintained, and #monitored. The systems covered in this chapter are mechanisms that encompass and enable these types of management tasks. They form key parts of cloud technology architectures by facilitating the control and evolution of the IT resources that form cloud #platforms and #solutions. Mechanisms that enable the #hands-on #administration and management of cloud based IT resources are explained, including Remote Administration System, Resource Management System, SLA Management System, and Billing Management System. The following management-related mechanisms are described in this chapter: 1. #Remote Administration System 2. #Resource Management System 3. #SLA Management System 4. #Billing Management System Cloud computing concept Book Link CLOUDCOMPUTING THEORY PLAYLIST CLOUD COMPUTING PRACTICAL PLAYLIST Subscribe the Channel Link IF any #Query or

8.10. State Management Database A state management database is a storage device that is used to temporarily persist state data for software programs. As an alternative to caching state data in memory, software programs can off-load state data to the database in order to reduce the amount of runtime memory they consume (Figures 8.37 and 8.38). By doing so, the software programs and the surrounding infrastructure are more scalable. State management databases are commonly used by cloud services, especially those involved in long-running runtime activities. Figure 8.37. During the lifespan of a cloud service instance it may be required to remain stateful and keep state data cached in memory, even when idle. Figure 8.38. By deferring state data to a state repository, the cloud service is able to transition to a stateless condition (or a partially stateless condition), thereby temporarily freeing system resources. Cloud computing concept Book Link CLOUDCOMPUTING THEORY PLAYLI

8.9. Multi-Device Broker An individual cloud service may need to be accessed by a range of cloud service consumers differentiated by their hosting hardware devices and/or communication requirements. To overcome incompatibilities between a cloud service and a disparate cloud service consumer, mapping logic needs to be created to transform (or convert) information that is exchanged at runtime. The multi-device broker mechanism is used to facilitate runtime data transformation so as to make a cloud service accessible to a wider range of cloud service consumer programs and devices (Figure 8.35). Figure 8.35. A multi-device broker contains the mapping logic necessary to transform data exchanges between a cloud service and different types of cloud service consumer devices. This scenario depicts the multi-device broker as a cloud service with its own API. This mechanism can also be implemented as a service agent that intercepts messages at runtime to perform necessary transformations.

8.8. Resource Cluster Cloud-based IT resources that are geographically diverse can be logically combined into groups to improve their allocation and use. The resource cluster mechanism (Figure 8.30) is used to group multiple IT resource instances so that they can be operated as a single IT resource. This increases the combined computing capacity, load balancing, and availability of the clustered IT resources. Figure 8.30. The curved dashed lines are used to indicate that IT resources are clustered. Resource cluster architectures rely on high-speed dedicated network connections, or cluster nodes, between IT resource instances to communicate about workload distribution, task scheduling, data sharing, and system synchronization. A cluster management platform that is running as distributed middleware in all of the cluster nodes is usually responsible for these activities. This platform implements a coordination function that allows distributed IT resources to appear as one IT resource,

8.6. Failover System The failover system mechanism is used to increase the reliability and availability of IT resources by using established clustering technology to provide redundant implementations. A failover system is configured to automatically switch over to a redundant or standby IT resource instance whenever the currently active IT resource becomes unavailable. Failover systems are commonly used for mission-critical programs and reusable services that can introduce a single point of failure for multiple applications. A failover system can span more than one geographical region so that each location hosts one or more redundant implementations of the same IT resource. The resource replication mechanism is sometimes utilized by the failover system to provide redundant IT resource instances, which are actively monitored for the detection of errors and unavailability conditions. Failover systems come in two basic configurations: Active-Active In an active-active configur

8.7. Hypervisor The hypervisor mechanism is a fundamental part of virtualization infrastructure that is primarily used to generate virtual server instances of a physical server. A hypervisor is generally limited to one physical server and can therefore only create virtual images of that server (Figure 8.27). Similarly, a hypervisor can only assign virtual servers it generates to resource pools that reside on the same underlying physical server. A hypervisor has limited virtual server management features, such as increasing the virtual server’s capacity or shutting it down. The VIM provides a range of features for administering multiple hypervisors across physical servers. Figure 8.27. Virtual servers are created via individual hypervisor on individual physical servers. All three hypervisors are jointly controlled by the same VIM. Hypervisor software can be installed directly in bare-metal servers and provides features for controlling, sharing and scheduling the usage of hardware

8.5. Audit Monitor The audit monitor mechanism is used to collect audit tracking data for networks and IT resources in support of (or dictated by) regulatory and contractual obligations. Figure 8.15 depicts an audit monitor implemented as a monitoring agent that intercepts “login” requests and stores the requestor’s security credentials, as well as both failed and successful login attempts, in a log database for future audit reporting purposes. Figure 8.15. (1) A cloud service consumer requests access to a cloud service by sending a login request message with security credentials . (2)The audit monitor intercepts the message and (3)forwards it to the authentication service . (4)The authentication service processes the security credentials. A response message is generated for the cloud service consumer, in addition to the results from the login attempt . (5)The audit monitor intercepts the response message and stores the entire collected login event details in the log dat

8.4. Pay-Per-Use Monitor The pay-per-use monitor mechanism measures cloud-based IT resource usage in accordance with predefined pricing parameters and generates usage logs for fee calculations and billing purposes. Some typical monitoring variables are: • request/response message quantity • transmitted data volume • bandwidth consumption The data collected by the pay-per-use monitor is processed by a billing management system that calculates the payment fees. The billing management system mechanism is covered in Chapter 9. Figure 8.12 shows a pay-per-use monitor implemented as a resource agent used to determine the usage period of a virtual server Figure 8.12. (1) A cloud consumer requests the creation of a new instance of a cloud service . (2)The IT resource is instantiated and the pay-per-use monitor receives a “start” event notification from the resource software. (3)The pay-per-use monitor stores the value timestamp in the log database . (4)The cloud consumer la

8.3. SLA Monitor The SLA monitor mechanism is used to specifically observe the runtime performance of cloud services to ensure that they are fulfilling the contractual QoS requirements that are published in SLAs (Figure 8.7). The data collected by the SLA monitor is processed by an SLA management system to be aggregated into SLA reporting metrics. The system can proactively repair or failover cloud services when exception conditions occur, such as when the SLA monitor reports a cloud service as “down.” . Figure 8.7. The SLA monitor polls the cloud service by sending over polling request messages (MREQ1 to MREQN). (1a)The monitor receives polling response messages (MREP1 to MREPN) that report that the service was “up” at each polling cycle . (1b)The SLA monitor stores the “up” time—time period of all polling cycles 1 to N—in the log database . (2a)The SLA monitor polls the cloud service that sends polling request messages (MREQN+1 to MREQN+M). Polling response messages are not

8.2. Load Balancer A common approach to horizontal scaling is to balance a workload across two or more IT resources to increase performance and capacity beyond what a single IT resource can provide. The load balancer mechanism is a runtime agent with logic fundamentally based on this premise. Beyond simple division of labor algorithms (Figure 8.5), load balancers can perform a range of specialized runtime workload distribution functions that include: • Asymmetric Distribution – larger workloads are issued to IT resources with higher processing capacities • Workload Prioritization – workloads are scheduled, queued, discarded, and distributed workloads according to their priority levels • Content-Aware Distribution – requests are distributed to different IT resources as dictated by the request content Figure 8.5. A load balancer implemented as a service agent transparently distributes incoming workload request messages across two redundant cloud service implementatio