Robin Systems, Inc.

Symantec Corporation

Veritas Technologies LLC

Tushar Doshi

Ravi Kumar Alluboyina

Anish A Vaidya

Shravan Kumar Vallala

Manjunath Mageswaran

Pooja Sarda

Hariharan Sethuraman

Manjiri R Patwardhan

Ripulkumar Hemantbhai Patel

Jagadish Kumar Mukku

Sree Nandan Atur

Partha Sarathi Seetala

Lakshay Badlani

Kushal B Shah

Jagadamba Rangaiah

Giridharan Kesavan

Rohan Parulekar

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

A KUBERNETES installation processes a script and invokes a scheduling agent in response to encountering an instruction to create a pod. The scheduling agent is an agent of an orchestrator and performs tasks such as identifying a selected node, creating multiple interface objects with multiple IP addresses, and creating storage volumes in coordination with the orchestrator. Upon creation, the pod may call a CNI that is an agent of the orchestrator in order to configure the pod to use the multiple interface objects. The pod may call a CSI that is an agent of the orchestrator in order to bind a storage volume to the pod. The scheduling agent may coordinate with the orchestrator to implement affinity and anti-affinity rules for placement of pods and storage volumes. The script may also be transformed by the orchestrator in order to insert instructions implementing affinity and anti-affinity rules.

Implementing affinity and anti-affinity with KUBERNETES

A KUBERNETES installation processes a script and invokes a scheduling agent in response to encountering an instruction to create a pod. The scheduling agent is an agent of an orchestrator and performs tasks such as identifying a selected node, creating multiple interface objects with multiple IP addresses, and creating storage volumes in coordination with the orchestrator. Upon creation, the pod may call a CNI that is an agent of the orchestrator in order to configure the pod to use the multiple interface objects. The pod may call a CSI that is an agent of the orchestrator in order to bind a storage volume to the pod. The scheduling agent may coordinate with the orchestrator to implement affinity and anti-affinity rules for placement of pods and storage volumes. The script may also be transformed by the orchestrator in order to insert instructions implementing affinity and ant-affinity rules.

Implementing advanced networking capabilities using helm charts

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

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.

Implementing secure communication in a distributed computing system

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. Changes to application state may be written to a remove storage volume that may be mounted to a new instance or clone of the application to recreate its state. Jobs to create and execute 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. A job manager creates jobs according to the manifests and executes phases of these jobs with respect to target nodes of the distributed computing system.

Job manager for deploying a bundled application

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. Clones snapshots of storage volumes may be gradually populated with data from prior snapshots to reduce loading on a primary snapshot. Upgrades for bundled applications may be defined and executed for containers and roles of the bundled application.

Upgrading bundled applications in a distributed computing system

Disclosed herein are methods, systems, and processes to adjust replication operations in a distributed environment. A set of replicated data is received from a first appliance as a result of a replication operation. The replication operation is initiated by the first appliance and the set of replicated data includes a first timestamp. A write operation is performed to store the set of replicated data and a second timestamp is recorded. Recovery point information is generated based on the first timestamp and the second timestamp. The recovery point information is configured to be utilized in adjusting replication parameters of a subsequent replication operation.

Adjusting replication operations in a distributed environment

Various systems and methods for performing clustering operations in distributed systems are disclosed. For example, one method involves performing a clustering operation that uses a virtual machine (VM). This VM is hosted by a first node. The method involves receiving an indication that indicates a migration of the virtual machine from the first node to a second node. The method also involves, in response to a receipt of this indication, suspending performance of the clustering operation using the virtual machine. The method can also involve resuming performance of the clustering operation using the virtual machine in response to receiving an indication of a successful migration of this virtual machine.

Handling of virtual machine migration while performing clustering operations

A computer-implemented method for proactively evaluating failover nodes prior to the occurrence of failover events may include (1) identifying at least one primary node that services at least one application, (2) identifying at least one failover node designated to service the application if the primary node were to fail, (3) prior to detecting failure of the primary node, proactively evaluating the failover node's ability to service the application if the primary node were to fail, and then (4) in response to determining that the failover node would be unable to adequately service the application if the primary node were to fail, proactively performing at least one corrective action that would cause the application to be adequately serviced if the primary node were to fail. Various other methods, systems, and computer-readable media are also disclosed.

Growing community of inventors

Santa Clara, CA, United States of America

Tushar Doshi