Red Hat, Inc.

Jay Vyas

Huamin Chen

Daniel J Walsh

Ian Scott McLeod

Christoph Goern

Daniel W Riek

Vaclav Pavlin

Ronald Nowling

Langdon White

Suneel Marthi

Aaron Weitekamp

Michael Virgil

A system and method for a tiered cloud storage for different availability and performance requirements includes a gateway, a block store configured to cache data, and an object store configured to persistently store data. The gateway, the block store, and the object store are in a compute zone. The gateway may receive from a user application a file access call and process the file access call. The gateway may also send the file access call to the block store. Then, the gateway may determine to store data in the object store and flush the data from the block store to the object store.

Tiered cloud storage for different availability and performance requirements

A system includes a memory, a processor in communication with the memory, a hypervisor executing on the processor, a pool of hypervisor resources, and a cloud-sharing module (CSM). The CSM runs in a kernel to assign an anonymous identity to a hypervisor resource from the pool of hypervisor resources. The CSM broadcasts a transaction for the hypervisor resource and determines which provider owns the hypervisor resource. A first provider is associated with a second anonymous identity and a second provider is associated with a third anonymous identity. Additionally, the CSM receives mining information that includes a block associated with the transaction, where the block is part of a blockchain. The CSM completes the transaction for the first anonymous identity associated with the hypervisor resource between the second anonymous identity and the third anonymous identity.

Cooperative cloud infrastructure using blockchains for hardware ownership and access

A system for scheduling remediation includes a memory, a processor in communication with the memory, a container scheduled on a first node, a scheduler executing on the processor, and a node-local-unscheduler ('NLU'). The scheduler has a watch module. The NLU executes on the processor to determine a status of the container as failing validation. The NLU has access to scheduling policies corresponding to the container and the first node. Responsive to determining the status of the container as failing validation, the NLU annotates the container and stops execution of the container. The watch module executes on the processor to detect the annotation associated with the container. Responsive to detecting the annotation, the container is rescheduled to a second node.

Node-local-unscheduler for scheduling remediation

A power consumption optimization system includes a virtual machine (VM) provisioned on a host, a memory, a server, and a processor in communication with the memory. The processor causes the server to store a power consumption profile of the VM. The VM runs at a processor frequency state. Additionally, the processor causes the server to receive a request to lower a processor frequency for the VM from an original processor frequency state to a reduced processor frequency state. The request has request criteria indicating a time duration associated with the request. The server validates the request criteria and a requirement of another tenant on the host. Responsive to validating the request criteria and the requirement the other tenant on the host, the server confirms the request to lower the processor frequency. Additionally, the server lowers the processor frequency to the reduced processor frequency state during the time duration.

Power consumption optimization on the cloud

A system for reducing overlay network overhead includes a memory, a processor in communication with the memory, a first container and a second container running on a first host, and a container scheduler executing on the processor. Each of the first container and second container expose a network service port(s). The container scheduler executes on the processor to assign a network complexity weight to the first host. The network complexity weight is based on a quantity of network service ports that the first container and the second container expose. The container scheduler also filters hosts based on resource availability corresponding to each host and ranks the hosts based on a respective network complexity weight corresponding to each host. Additionally, the container scheduler dispatches a third container to a second host based on the resource availability and network complexity weight corresponding to the second host.

Reducing overlay network overhead across container hosts

An example method of providing a configuration for a multitier microservice architecture includes receiving a configuration request from a user for a configuration that satisfies a set of conditions in a cloud environment. The method also includes searching a configuration data store for the configuration that matches the set of conditions. The configuration specifies a first container and a second container, the first container sends a first communication to the second container, and the second container sends a second communication responsive to the first communication to the first container. The method further includes in response to finding the configuration that matches the set of conditions: sending an allocation request to a cloud provider for allocation of the configuration in the cloud environment and providing a first identifier (ID) that identifies the first container and a second ID that identifies the second container to the user.

Configuration recommendation for a microservice architecture

A system for container migration includes containers running instances of an application running on a cluster, an orchestrator with a controller, a memory, and a processor in communication with the memory. The processor executes to monitor a vitality metric of the application. The vitality metric indicates that the application is in either a live state or a dead state. Additionally, horizontal scaling for the application is disabled and the application is scaled-down until the vitality metric indicates that the application is in the dead state. Responsive to the vitality metric indicating that the application is in the dead state, the application is scaled-up until the vitality metric indicates that the application is in the live state. Also, responsive to the vitality metric indication transitioning from the dead state to the live state, the application is migrated to a different cluster while the horizontal scaling of the application is disabled.

Merging scaled-down container clusters using vitality metrics

Cascading job scheduling in guests is disclosed. For example, first, second, third, and fourth nodes, each execute respective first, second, third, and fourth pluralities of guests each of which executes respective first, second, third, and fourth pluralities of jobs. A scheduler executes on a processor to receive a current capacity update of the first node. A respective quantity of jobs executing on each of the first, second, third, and fourth nodes is tracked. A first, second, third, and fourth estimated capacity of the respective first, second, third, and fourth nodes is calculated. The first, second, third, and fourth nodes are ranked in a list based on the respective estimated capacities. A request to execute a job is received. The first, second, and third nodes are selected as a schedulable set based on the list. A schedulable set notice and the job are sent to the first node to be executed.

Cascading job scheduling in guests

A system and method for providing high availability for a thin-provisioned container cluster includes a memory, one or more processors in communication with the memory, a scheduler executing on the one or more processors, and a spot instance market monitor. The spot instance market monitor receives market information about spot instances in a cloud system at a first time. The spot instances are available to a client at the first time. The spot instance market monitor determines, based on the market information, a respective reliability value for each of the spot instances at the first time. Then, the scheduler selects one spot instance among the spot instances based on the reliability value of the spot instance. In response to the selection of the spot instance, the scheduler schedules a container on the spot instance and executes the container on the spot instance.

Providing high availability for a thin-provisioned container cluster

A container intrusion detection and prevention system includes a memory, a physical processor in communication with the memory, and an image scanner executing on the physical processor. The image scanner scans an image of a container in a container image registry. The container includes an application. The image scanner creates an image tag of the container and a set of generic rules for the container. The image scanner packages the image tag of the container with the set of generic rules to form a tuple and stores the tuple in an application rule registry.

Container intrusion detection and prevention system

A method of adjusting a set of resources allocated for a job includes analyzing, by a job tuning module, an intermediate result of a job. Processing the job includes processing a first iteration of a task and a second iteration of the same task. Additionally, the intermediate result is a result of the first iteration of the task, and the job is allocated a first set of resources during processing of the first iteration of the task. The method also includes sending a notification to a scheduler that causes the scheduler to adjust the first set of resources allocated to the job to a second set of resources for processing the second iteration of the task. The job may be allocated the second set of resources during processing of the second iteration of the task.

Self-programmable and self-tunable resource scheduler for jobs in cloud computing

An example system includes a memory, one or more processors in communication with the memory, and a container image generator. The container image generator receives a first set of information. The container image generator receives a second set of information, including secure information that requires validation to be accessed. The container image generator generates a first container layer, including a first URL associated with the first set of information. The container image generator generates a second container layer, including a second URL associated with the second set of information. The container image generator stores the first container layer and the second container layer at a storage location.

Growing community of inventors

Concord, MA, United States of America

Jay Vyas