EGO components

The components of the resource management middleware layer (for the supply side) fall into several groupings. Those that play a more central and exposed role include the cluster kernel, system services, APIs, and application orchestrators. Each group performs a set of functions essential to orchestrating the access of applications to the underlying resources.


Name

Description

EGO cluster kernel

The enterprise cluster kernel is a process automatically started on one of the hosts within the cluster. It provides a core set of centralized functions that leverage the capabilities of host-level agents. The kernel integrates the resources of all hosts and performs many-to-one virtualization so that mixed physical resources appear to clients as a single virtual computer.

It is in the EGO cluster kernel where the requirements for support for services and for plan-based ownership are primarily met.

There are three parts that makeup the EGO cluster kernel: Information, Allocation, and Execution.

Execution

Once resources are allocated, the EGO cluster kernel provides the mechanism that allows them to execute activities using those resources. Actions include starting, stopping, or controlling execution activities. The EGO cluster kernel uses process execution managers (PEMs) on the hosts to perform remote operations using operating system-level processes. Changes of status on the host are reported asynchronously to the client so that the client can determine how to handle failures and restarts.

Allocation

The EGO cluster kernel also manages allocation requests from clients. Like a virtual memory manager in a host operating system, which converts a physical resource into a virtual resource and allocates it to applications, the EGO cluster kernel virtualizes distributed resources. For example, it can take physical hosts and carve them up into virtual CPU slots. Clients could then request and release CPU slots through allocate and release interfaces, identifying the number and type of resources they need based on host attributes of allocating consumers.

Taking into consideration the available resources and consumer entitlements, the EGO cluster kernel applies plans to determine what to allocate. The client is notified asynchronously as resources become available, the resources are identified, and host information is passed back to the client.

The allocation engine balances the demand for resources with the available supply. It tracks the amount of each type of resource and adjusts priorities, reclaiming resources from clients that exceed their share of the resources. The allocation engine supports immediate allocation requests.

Information

The EGO cluster kernel aggregates information from the hosts, providing a single point from which clients can request information such as the state of individual resources, the status of allocation requests, the consumer hierarchy, including resources assigned to each consumer, and services that have been started. By giving central access to static and near-real-time information, the kernel makes it possible to effectively monitor and manage resources and enables clients to discover what resources are available.

System services

System services provide common functionality required to support multiple workload-specific application managers. Higher-level services leverage these common services to ensure consistent management of distributed application workloads.

There are a number of system services, including the service controller, WebServiceGateway, service director (ServiceDirector), and Platform Management Console (WEBGUI) services. These are described below.

Service controller

The service controller is always started on the EGO cluster kernel host. It is responsible for starting other system services. Acting as a client to the EGO cluster kernel, it requests resource allocations for running services. It ensures that services are running by detecting failures and restarting service instances based on availability plans.

ServiceDirector

Services are dynamically started and can therefore run on any host. This means that clients have to dynamically locate services to access them. Clients can locate services explicitly via API calls to the service controller that starts and tracks those services; alternatively, the service director provides a mechanism, based on standard DNS, for redirecting client requests to the physical instance of that service.

WEBGUI

The WEBGUI service (Platform Management Console) is a web-based graphical user interface for administrators and operations staff. The Console is extensible to enable higher-order services to add functionality for managing workload- or application-specific interfaces.

WebServiceGateway

The web service gateway (WebServiceGateway) service is a runtime component of EGO. The gateway provides a standards-based web services interface for web service clients to access EGO functionality. The web service client sends its request to the gateway via SOAP protocol. The gateway calls the EGO C APIs to perform the required operations on behalf of the web service client and returns the results.

RS

The repository service manages package deployment, and allows deployment of a service without reliance on a shared file system. When a service package is updated, the new service package overwrites the existing service package. The repository service is started as a EGO system service. If the process or host fails, the service is relocated and restarted on another host.

purger

The purger service is used by the reporting feature, and manages the relational database size by deleting old data at regular intervals.

plc

The plc service is used by the reporting feature, and manages the data loader plug-ins.

derbydb

This Apache Derby service runs as a system service when first installed. It is used primarily for demo clusters. The derbydb service is only enabled if an environment variable is set prior to installation (Linux) or during the Windows installation.

EGO cluster interfaces

Standards-based EGO cluster interfaces help meet the requirement of being application agnostic and facilitate integration with heterogeneous applications, enabling third-party vendors and customers to easily integrate applications and resources across the cluster.

EGO application orchestrators and applications

Another key factor in meeting the requirement to support services is EGO Application Orchestrators and Applications-higher-order services that provide workload or application-specific integration with the cluster. A EGO Application Orchestrator understands the nature of an application workload, measures its performance against service levels, and pinpoints bottlenecks. If the orchestrator determines that additional resources can alleviate a performance problem, it leverages other components to request resources and then release them when they are no longer needed. EGO Application Orchestrators can also process workloads and act as application middleware, providing EGO interfaces for users to develop applications.