Abstract: Approaches presented herein relate to the distribution and processing of stream data in a networked computing environment. A set of streaming data sources can be identified for a given cluster of nodes and the data from those data sources can be tracked, managed, and/or routed to a number of different microservices. Stream distribution and routing (SDR) agents may be used to manage a routing table that includes an identifier for each of the data sources. The individual agents may distribute information about the sensors to individual microservices, which may determine which data streams are relevant and then initiate individual processes and functions using the relevant data streams. Output results from the individual microservices may also be assigned an identifier, which may further be used by the individual agents to route outputs toward their particular microservices, which may then use the outputs from other microservices within their own workstreams.

Abstract: A cloud managed storage system (200) includes a cluster of the nodes (220) that are already in communication with a cloud management plane (280) that has visibility of all the storage nodes (220) in the cluster. When a cluster is created, the number of nodes (220) is determined and based on the number of nodes (220), the storage system (200) can determine whether an external quorum witness (284) is required and automatically enable a quorum witness (284) as a cloud service. Storage nodes (220) can contact the quorum witness (284) when necessary for failover processes.

Abstract: A cloud managed storage system (200) includes a cluster of the nodes (220) that are already in communication with a cloud management plane (280) that has visibility of all the storage nodes (220) in the cluster. When a cluster is created, the number of nodes (220) is determined and based on the number of nodes (220), the storage system (200) can determine whether an external quorum witness (284) is required and automatically enable a quorum witness (284) as a cloud service. Storage nodes (220) can contact the quorum witness (284) when necessary for failover processes.

Abstract: An initiating node (C) in a storage platform (100) receives a modification request (312, 314) for changing an object (0). The initiating node (C), using system configuration information (127), identifies an owner node (A) and a backup node (B) for the object (0) and sends change data (324, 334) to the owner node (A) and the backup node (B). The owner node (A) modifies the object (0) with the data (324) from the initiating node (C) and sends an update request (352) that does not include the data (324) to the backup node (B). The backup node (B) modifies a backup object (0?) with data (334) from the initiating node (C).

Abstract: An initiating node (C) in a storage platform (100) receives a modification request (312, 314) for changing an object (O). The initiating node (C), using system configuration information (127), identifies an owner node (A) and a backup node (B) for the object (O) and sends change data (324, 334) to the owner node (A) and the backup node (B). The owner node (A) modifies the object (O) with the data (324) from the initiating node (C) and sends an update request (352) that does not include the data (324) to the backup node (B). The backup node (B) modifies a backup object (O?) with data (334) from the initiating node (C).

Abstract: An initiating node (C) in a storage platform (100) receives a modification request (312, 314) for changing an object (O). The initiating node (C), using system configuration information (127), identifies an owner node (A) and a backup node (B) for the object (O) and sends change data (324, 334) to the owner node (A) and the backup node (B). The owner node (A) modifies the object (O) with the data (324) from the initiating node (C) and sends an update request (352) that does not include the data (324) to the backup node (B). The backup node (B) modifies a backup object (O?) with data (334) from the initiating node (C).