Portworx, Inc.

Pure Storage, Inc.

Portwonx, Inc.

Dinesh Israni

Vinod Jayaraman

Goutham Rao

Harsh Desai

Saurabh Deoras

An illustrative computing system may include a master node that includes a prioritization module. The master node may be in communication with each of a plurality of containerized application nodes. The prioritization module may be configured to determine node prioritization information indicating a relative prioritization of the containerized application nodes for instantiating a designated containerized application, wherein the determining node prioritization information includes assigning a priority score to a candidate containerized application node, wherein higher priority is given based on a number of volumes stored on the candidate containerized application node that is designated for access by the designated containerized application.

Hyper-convergence with scheduler extensions for software-defined container storage solutions

An illustrative method includes determining whether a virtual storage volume is successfully mounted to a mount path associated with a compute node, the mount path being marked as read-only, marking, if the determining includes determining that the virtual storage volume is successfully mounted to the mount path, the mount path as writable, and maintaining, if the determining includes determining that the virtual storage volume is unsuccessfully mounted to the mount path, the mount path as read-only.

Mount path management for virtual storage volumes in a containerized storage environment

A clustered storage system may include potentially many different nodes. A node may mount a virtual storage volume for the use of a container application at the node. The node may receive a request from a different node and respond by indicating whether the virtual storage volume is in active use. In this way, the clustered storage system may safely but forcibly unmount a virtual storage volume having a failed or hanging mount point so that the volume may be mounted on a different node.

Resolving failed or hanging mount points in a clustered storage solution for containers

A clustered storage system may include potentially many different nodes, each including a storage driver and a scheduler agent. A node may mount a virtual storage volume for the use of a container application at the node. When a master node receives a request to instantiate a new containerized application, a scheduler at the master node may determine prioritization information for the new containerized application. The prioritization information may prioritize one or more nodes at which a virtualized storage volume employed by the application container instance is mounted.

Two servers implemented as containerized applications may manage the storage of data and the access of that data by compute jobs in a distributed system. A metadata server may distribute data on ingress and assign files to particular storage volumes. The metadata server may then provide a lookup function for files and be configured to distribute a file to other volumes when necessary. A job server may launch jobs as containerized applications and coordinate data access across jobs.

Distributed job manager for stateful microservices

Copy-on-Write (CoW) snapshots share data on disk for extents that have not been overwritten, which allows for efficient use of disk space. A chain of snapshots may be created, where each snapshot corresponds to a point in time. A sequence of snapshots may be copied by rebuilding each snapshot for the destination volume based on the source volume, resulting in memory usage at the destination volume substantially similar to the memory usage of the snapshot sequence at the source volume.

Efficient transfer of copy-on-write snapshots

A clustered storage system may include potentially many different nodes, each including a storage driver and a kernel module. A node may mount a virtual storage volume for the use of a container application at the node. The storage driver and kernel module may receive a request from a storage driver at a different node and respond by indicating whether the virtual storage volume is in active use. In this way, the clustered storage system may safely but forcibly unmount a virtual storage volume having a failed or hanging mount point so that the volume may be mounted on a different node.

A container orchestrator may communicate with a scheduler agent on a compute node to mount and/or unmount a virtual storage volume at the compute node. The scheduler agent may perform operations such as creating and/or deleting a mount path, mounting and/or unmounting the virtual storage volume, and/or marking the mount path as writable and/or read-only in order to eliminate cross-node race conditions.

Growing community of inventors

San Jose, CA, United States of America

Dinesh Israni