Having gained momentum from its promise of centralized control over distributed network architectures at bargain costs, software-defined Networking (SDN) is an ever-increasing topic of research. SDN offers a simplified means to dynamically control multiple simple switches via a single controller program, which contrasts with current network infrastructures where individual network operators manage network devices individually. Already, SDN has realized some extraordinary use cases outside of academia with companies, such as Google, AT&T, Microsoft, and many others. However, SDN still presents many research and operational challenges for government, industry, and campus networks. Because of these challenges, many SDN solutions have developed in an ad hoc manner that are not easily adopted by other organizations. Hence, this paper seeks to identify some of the many challenges where new and current researchers can still contribute to the advancement of SDN and further hasten its broadening adoption by network operators.

Advancing Software-Defined Networks: A Survey

Methods and apparatuses for performing deduplication in a hybrid storage aggregate are provided. In one example, a method includes operating a hybrid storage aggregate that includes a plurality of tiers of different types of physical storage media. The method includes identifying a first storage block and a second storage block of the hybrid storage aggregate that contain identical data and identifying caching statuses of the first storage block and the second storage block. The method also includes deduplicating the first storage block and the second storage block based on the caching statuses of the first storage block and the second storage block.

Deduplicating hybrid storage aggregate

There are provided a system and a computer program product for operating multi-node data stores. The system stores a data table in a first computing node and stores an index table in a second computing node. The index table provides keys used for accessing data in the first computing node and other multi-node data stores. The system performs operations that update or read the data table accessed from the first computing node and the index table accessed from the second computing node. The operations optimize between latency in updating or reading the data table and the index table and data consistency maintained between data entries in the data table and data entries pointed by indices in the index table.

Differentiated secondary index maintenance in log structured nosql data stores

A technique for load balancing uses heuristic-based algorithms with respect to input/output (I/O) latency of workloads destined to storage devices, e.g., solid state drives (SSDs), of a storage array attached to a storage system. Illustratively, “front-end” requests received from a host result in a back-end workload as those requests are processed by a storage I/O stack of the storage system and stored on the storage array. Accordingly, the technique maintains a consistent latency for the host requests (front-end) to control latency for the back-end workload. The load balancing technique illustratively load balances fixed (back-end) workloads having similar I/O sizes and I/O patterns. Illustratively, the technique balances the workloads across a plurality of storage ports over one or more I/O paths to the SSDs. Access to the SSDs may then be distributed among the storage ports.

Load balancing technique for a storage array

A method, in one embodiment, can include receiving a key and associated data via a computing device. Furthermore, the method can include searching a B+ tree data structure using the key to find a leaf node. The B+ tree data structure is stored by a persistent storage coupled to the computing device. The B+ tree data structure can include a first plurality of nodes that each contains a key-value entry that is not maintained in a sorted order based on its key. In addition, the key and associated data are appended to the leaf node. A sector that includes the leaf node and the key and associated data can be flushed to the persistent storage.

Insert optimization for b+ tree data structure scalability

A method for maintaining an index in multi-tier data structure includes providing a plurality of a storage devices forming the multi-tier data structure, caching an index of key-value pairs across the multi-tier data structure, wherein each of the key-value pairs includes a key, and one of a data value and a data pointer, the key-value pairs stored in the multi-tier data structure, providing a journal for interfacing with the multi-tier data structure, providing a plurality of zone allocators recording which zones of the multi-tier data structure are in used, and providing a plurality of zone managers for controlling access to cache lines of the multi-tier data structure through the journal and zone allocators, wherein each zone manager maintains a header object pointing to data to be stored in an allocated zone.

Multi-tier caching

Examples disclosed herein relate to propagating changes made on a file system volume of a primary cluster of nodes to the same file system volume also being managed by a secondary cluster of nodes An application is executed on both clusters, and data changes on the primary cluster are mirrored to the secondary cluster using an exo-clone file The exo-clone file includes the differences between two or more snapshots of the volume on the primary cluster, along with identifiers of the change blocks and (optionally) state information thereof Just these changes, identifiers, and state information are packaged in the exo-clone file and then exported to the secondary cluster, which in turn makes the changes to its version of the volume Exporting just the changes to the data blocks and the corresponding block identifiers drastically reduces the information needed to be exchanged and processed to keep the two volumes consistent

Container runtime image management across the cloud

Modern NVMe solid state drives offer significantly higher bandwidth and lower latency than prior storage devices. Current key-value stores struggle to fully utilize the bandwidth of such devices. This paper presents SplinterDB, a new keyvalue store explicitly designed for NVMe solid-state-drives. SplinterDB is designed around a novel data structure (the STBε-tree) that exposes I/O and CPU concurrency and reduces write amplification without sacrificing query performance. STBε-tree combines ideas from log-structured merge trees and Bε-trees to reduce write amplification and CPU costs of compaction. The SplinterDB memtable and cache are designed to be highly concurrent and to reduce cache misses. We evaluate SplinterDB on a number of microand macro-benchmarks, and show that SplinterDB outperforms RocksDB, a state-of-the-art key-value store, by a factor of 6–10× on insertions and 2–2.6× on point queries, while matching RocksDB on small range queries. Furthermore, SplinterDB reduces write amplification by 2× compared to RocksDB.

/pdf/splinterdb-closing-the-bandwidth-gap-for-nvme-key-value-44wz1hde67.pdf

SplinterDB: Closing the bandwidth gap for NVMe key-value stores

Embodiments described herein are related to cloning a volume in a file system. In some embodiments, a directory hard link is used to generate a clone of the root node of the volume. In certain embodiments, upon determining that a file or directory of the clone which comprises a hard link to an index node has been modified, a new object directory is generated beneath a root node of the volume. The index node may be added to the new object directory and one or more files and directories in the volume which link to the index node may be updated to contain symbolic links to the index node in the new object directory. In certain embodiments, a copy-on-write operation is performed in order to copy the file or directory and the new object directory to the clone.

Supporting file system clones in any ordered key-value store

Our key innovation is to allow volume snapshots in VDFS (our native hyper-converged distributed file system) to be exported to a stand-alone regular file that can be imported to another VDFS cluster efficiently (zerocopy when possible) called exo-clones. Our exo-clones carry provenance, policy, and similar to git commits, the fingerprints of the parent clones from which they were derived. They are analogous to commits in a distributed source control system, and can be stored outside of VDFS, rebased, and signed. Although they can be unpacked to any directory, when used with VDFS they can be mounted directly with zero-copying and are instantly available to all nodes mounting VDFS. VDFS with exoclones provides the format and the tools necessary to both transfer, and run encapsulated applications in both public and private clouds, and in both test/dev and production environments.

/pdf/exo-clones-better-container-runtime-image-management-across-5gokvs9ne9.pdf

Spillane Richard P

Papers

Multi-tier caching

Container runtime image management across the cloud

SplinterDB: Closing the bandwidth gap for NVMe key-value stores

Supporting file system clones in any ordered key-value store

Exo-clones: better container runtime image management across the clouds