Robin Systems, Inc.

Rakuten Symphony, Inc.

Ravi Kumar Alluboyina

Sree Nandan Atur

Tushar Doshi

Shravan Kumar Vallala

Manjunath Mageswaran

Dhanashankar Venkatesan

Jagadish Kumar Mukku

Giridharan Kesavan

Kapil Upadhayay

Ripulkumar Hemantbhai Patel

Partha Sarathi Seetala

Lakshay Badlani

Pragash Vijayaragavan

The present invention extends to methods, systems, and computer program products for optimizing resource allocation in view of predicted network traffic patterns and predicted power consumption. Network packets defining a network traffic flow can be received at a platform over time. Metrics can be derived from one or more applications executing on resources of the platform and processing data contained in the network data packets. Model training data can be formulated from the metrics. A resource adjustment model can be trained using the model training data. Executing the model can be automated to adjust resource allocation at the platform. Additional network packets defining an additional network traffic flow can be received at a platform over time. Data contained in the additional network packets can be processed using the adjusted resource allocation.

Optimizing resource scaling

Systems and methods for agentless GitOps and custom resources for application orchestration and management. A system includes a bare metal server running a cloud native application and a plurality of clusters running on the bare metal server, wherein at least a portion of the plurality of clusters executes an application. The system includes a data center automation platform responsible for service management and orchestration for the bare metal server, wherein the data center automation platform subscribes to a git repository to receive updates pertaining to the application, and wherein a read only token is established between the git repository and the data center automation platform.

Agentless GitOps and custom resources for application orchestration and management

A payload object, such as a JSON object, includes a plurality of elements is converted to an array file by individually serializing the elements. A header is written to the array file that includes the number of elements and an offset to the start of each element of the serialized elements. The serialized elements are written after the header. Thereafter, an individual serialized elements is read by first reading the offset corresponding to the individual serialized element from the header and reading data starting at the offset.

Storage and access of array objects

A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. Once pending write requests from the computing nodes are completed, storage nodes create a new snapshot for the storage volume by allocating a new segment to the new snapshot and finalizes and performs garbage collection with respect to segments allocated to the previous snapshot. Subsequent write requests to the storage volume are then performed on the segments allocated to the new snapshot. An orchestration layer implements a multi-role application that is provisioned with virtualized storage and computation resources. A snapshot of the application may be created and used to rollback or clone the application. Clone snapshots of storage volumes may be gradually populated with data from prior snapshots to reduce loading on a primary snapshot.

Multi-role application orchestration in a distributed storage system

Snapshots of storage volumes and containers of a bundled application may be created and used to rollback or clone the bundled application. Clone snapshots of storage volumes may be gradually populated with data from prior snapshots to reduce loading on a primary snapshot. Components of cloned applications may communicate with one another using addresses of these components in the parent application. Containers of the bundled application may communicate with an open virtual switch (OVS) that implements flows to implement translation between clone and parent addresses. Containers may be modified to execute operation-specific entrypoint functions prior to invoking an entrypoint of an application instance loaded in the containers.

Fenced clone applications

A bare metal server, or other computing device, may be represented as a JSON file (extending the concept to infrastructure as code) containing hardware, firmware and software versions with links to a kickstarter file depending on the needs of an application, SKU type or some other criteria. Rather than a management node in an L2 network which has a DHCP server to IP lease and facilitate OS installation, a workflow then generates a bootstrap kernel which initializes the bare metal server with an IP address, VLAN, and network gateway which is used to reach out to the network to download and install a kernel, upgrade firmware for various hardware components like BIOS, BMC, NIC, RAID, SSD, NVME, FPGA, etc. The bootstrap kernel may further configure RAID and JBOD, flash custom images on hardware components and may further instruct the server to incrementally download and install an operating system.

Automated initialization of bare metal servers

A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. A snapshot of the application may be created and used to rollback or clone the application. Clones snapshots of storage volumes may be gradually populated with data from prior snapshots to reduce loading on a primary snapshot. Components of cloned applications may communicate with one another using addresses of these components in the parent application. Jobs implementing a bundled application may be referenced with a simulated file system that generates reads to hosts only when the job log file is actually read. Job logs and a job hierarchy may be used to perform root cause analysis. Job logs may be for tasks such as creating the bundled application, cloning, rolling back, backing up, scaling out, scaling in, deleting, pruning unused application images, or the like.

Performing root cause analysis in a multi-role application

Implementing application entrypoints with containers of a bundled application

A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. An orchestration layer implements a multi-role application that is provisioned with virtualized storage and computation resources. A snapshot of the application may be created and used to rollback or clone the application. Clones snapshots of storage volumes may be thin clones. An application may use multiple orchestration approaches and objects of the multi-role application may be discovered and added to an application definition. The application definition may be used to create snapshots of the application and perform operations using the snapshots. Rolling back may include deleting objects other than PVCs, followed by rolling back storage volumes mounted to the PVCs, followed by recreating objects according to an application snapshot. PVCs created by a custom resource may be deleted along with the custom resource with the PVCs being recreated before recreating the custom resource.

Rolling back KUBERNETES applications including custom resources

An orchestrator generated pod specifications for role instances of a bundled application and submits these pod specifications to a KUBERNETES master. The pod specification specifies a node on which to implement a container executing the role instance, the node being selected according to an application manifest that may include affinity and anti-affinity constraints. The pod specification may be implemented by a KUBELET executing on the node, which may invoke interfaces to the orchestrator in order to obtain a network address for the container. A storage volume to be used by the container may have been mounted to the node previously by the orchestrator and be ready for use by the container. Upon failure of the node, the orchestrator generates a new pod specification according to the application manifest that instructs the master to create a new container having a same identity and state as the former container.

Implementing an application manifest in a node-specific manner using an intent-based orchestrator

Rolling back kubernetes applications

Deployment of a network service pipeline may be automated by defining workflows comprising functions of instances of elements. Workflows may be defined in a graphical user interface including menus for the selection of elements, functions, and predefined workflows. A workflow may be dynamic such that addition or modification of a function invokes a trigger that automatically populates or modifies parameters of the functions of the workflow. Elements may each have a same set of functions that may be invoked by an orchestrator to perform automated implementation of the workflow. Functions of a workflow may be implemented in batches and may retrieve executable. data from a distributed file store. A test platform with hardware and network simulation may be used to develop functions and workflows.

Health monitoring of automatically deployed and managed network pipelines

Implementing clone snapshots in a distributed storage system

A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. An orchestration layer implements a multi-role application that is provisioned with virtualized storage and computation resources. A snapshot of the application may be created and used to rollback or clone the application. Clones snapshots of storage volumes may be gradually populated with data from prior snapshots to reduce loading on a primary snapshot. A multi-role application may be orchestrated using multiple orchestration approaches and objects of the multi-role application may be discovered and added to an application definition. The application definition may be used to create snapshots of the application and the snapshot may be used to rollback, clone, backup, or migrate the application.

Orchestration of heterogeneous multi-role applications

A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. Once pending write requests from the computing nodes are completed, storage nodes create a new snapshot for the storage volume by allocating a new segment to the new snapshot and finalizes and performs garbage collection with respect to segments allocated to the previous snapshot. Subsequent write requests to the storage volume are then performed on the segments allocated to the new snapshot. An orchestration layer implements a multi-role application that is provisioned with virtualized storage and computation resources. A snapshot of the application may be created and used to rollback or clone the application. Containers may be loaded with data structures for encrypted and/or authenticated communication. Failed storage volumes maybe detected and repaired. Repopulating repaired volumes may be managed by an application or a storage manager implementing a virtualized storage system.

Growing community of inventors

Santa Clara, CA, United States of America

Ravi Kumar Alluboyina