Modern applications span multiple clouds to reduce costs, avoid vendor lock-in, and leverage low-availability resources in another cloud. However, standard object stores operate within a single cloud, forcing users to manually manage data placement across clouds, i.e., navigate their diverse APIs and handle heterogeneous costs for network and storage. This is often a complex choice: users must either pay to store objects in a remote cloud, or pay to transfer them over the network based on application access patterns and cloud provider cost offerings. To address this, we present SkyStore, a unified object store that addresses cost-optimal data management across regions and clouds. SkyStore introduces a virtual object and bucket API to hide the complexity of interacting with multiple clouds. At its core, SkyStore has a novel TTL-based data placement policy that dynamically replicates and evicts objects according to application access patterns while optimizing for lower cost. Our evaluation shows that across various workloads, SkyStore reduces the overall cost by up to 6X over academic baselines and commercial alternatives like AWS multi-region buckets. SkyStore also has comparable latency, and its availability and fault tolerance are on par with standard cloud offerings.

Regulated enterprises often seek to extend their workloads into the cloud, but are impeded by integration concerns relating to security, governance and compliance. Further, enterprises running mission-critical applications, face throughput and latency challenges due to cloud integration overheads. We present Hybrid Cloud Connector to accelerate on-prem to cloud integration by handling non-functional aspects in lieu of the application, reducing complexity, and centralizing administration via a policy-driven control point.

This work tackles an inherent conflict between two important trends. The first is the integration of data compression capabilities into many storage systems supporting random I/O on the compressed data. The second is encrypting data at the host, before data is written to the storage, in order to address regulatory and enterprise requirements. This provides end-to-end protection for the data, but since the data arrives encrypted, it prevents the storage from compressing the data. Can compression savings be achieved together with host side encryption without changing the storage protocols or storage backend? In this paper we show that they can.

Distributed storage systems often triplicate data to reduce the risk of permanent data loss, thereby tolerating at least two simultaneous disk failures at the price of 2/3 of the capacity. To reduce this price, some systems utilize erasure coding. But this optimization is usually only applied to cold data, because erasure coding might hinder performance for warm data.

Until now object storage has not been a first-class citizen of the Apache Hadoop ecosystem including Apache Spark. Hadoop connectors to object storage have been based on file semantics, an impedance mismatch, which leads to low performance and the need for an additional consistent storage system to achieve fault tolerance. In particular, Hadoop depends on its underlying storage system and its associated connector for fault tolerance and allowing speculative execution. However, these characteristics are obtained through file operations that are not native for object storage, and are both costly and not atomic. As a result these connectors are not efficient and more importantly they cannot help with fault tolerance for object storage. We introduce Stocator, whose novel algorithm achieves both high performance and fault tolerance by taking advantage of object storage semantics. This greatly decreases the number of operations on object storage as well as enabling a much simpler approach to dealing with the eventually consistent semantics typical of object storage. We have implemented Stocator and shared it in open source. Performance testing with Apache Spark shows that it can be 18 times faster for write intensive workloads and can perform 30 times fewer operations on object storage than the legacy Hadoop connectors, reducing costs both for the client and the object storage service provider.

No abstract available.

Data is the natural resource of the 21st century. It is being produced at dizzying rates, e.g., for genomics, for media and entertainment, and for Internet of Things. Object storage systems such as Amazon S3, Azure Blob storage, and IBM Cloud Object Storage, are highly scalable distributed storage systems that offer high capacity, cost effective storage. But it is not enough just to store data; we also need to derive value from it. Apache Spark is the leading big data analytics processing engine combining MapReduce, SQL, streaming, and complex analytics. We present Stocator, a high performance storage connector, enabling Spark to work directly on data stored in object storage systems, while providing the same correctness guarantees as Hadoop's original storage system, HDFS.

Data is the natural resource of the 21st century. It is being produced at dizzying rates, e.g., for genomics by sequencers, for Media and Entertainment with very high resolution formats, and for Internet of Things (IoT) by multitudes of sensors. Object Stores such as AWS S3, Azure Blob storage, and IBM Cloud Object Storage, are highly scalable distributed storage systems that offer high capacity, cost effective storage for this data. But it is not enough just to store data; we also need to derive value from it. Apache Spark is the leading big data analytics processing engine. It runs up to one hundred times faster than Hadoop MapReduce and combines SQL, streaming and complex analytics. In this poster we present Stocator, a high performance storage connector, that enables Spark to work directly on data stored in object storage systems.

Storage class memory (SCM) is an emerging class of memory devices that are both byte addressable, and persistent. There are many different technologies that can be considered SCM, at different stages of maturity. Examples of such technologies include NVDIMM-N, PCM, SttRAM, Racetrack, FeRAM, and others.

Storage cloud systems achieve economies of scale by serving multiple tenants from a shared pool of servers and disks. This leads to the commingling of data from different tenants on the same devices. Typically, a request is processed by an application running with sufficient privileges to access any tenant's data; this application authenticates the user and authorizes the request prior to carrying it out. Since the only protection is at the application level, a single vulnerability threatens the data of all tenants, and could lead to cross-tenant data leakage, making the cloud much less secure than dedicated physical resources. To provide security close to physical isolation while allowing complete resource pooling, we propose Secure Logical Isolation for Multi-tenancy (SLIM). SLIM incorporates the first complete security model and set of principles for the safe logical isolation between tenant resources in a cloud storage system, as well as a set of mechanisms for implementing the model. We show how to implement SLIM for OpenStack Swift and present initial performance results.

Large scale consolidation of distributed systems introduces data sharing between consumers which are not centrally managed, but may be physically adjacent. For example, shared global data sets can be jointly used by different services of the same organization, possibly running on different virtual machines in the same data center. Similarly, neighboring CDNs provide fast access to the same content from the Internet. Cooperative caching, in which data are fetched from a neighboring cache instead of from the disk or from the Internet, can significantly improve resource utilization and performance in such scenarios. However, existing cooperative caching approaches fail to address the selfish nature of cache owners and their conflicting objectives. This calls for a new storage model that explicitly considers the cost of cooperation, and provides a framework for calculating the utility each owner derives from its cache and from cooperating with others. We define such a model, and construct four representative cooperation approaches to demonstrate how (and when) cooperative caching can be successfully employed in such large scale systems. We present principal guidelines for cooperative caching derived from our experimental analysis. We show that choosing the best cooperative approach can decrease the system's I/O delay by as much as 87%, while imposing cooperation when unwarranted might increase it by as much as 92%.

Multilevel caching, common in many storage configurations, introduces new challenges to traditional cache management: data must be kept in the appropriate cache and replication avoided across the various cache levels. Additional challenges are introduced when the lower levels of the hierarchy are shared by multiple clients. Sharing can have both positive and negative effects. While data fetched by one client can be used by another client without incurring additional delays, clients competing for cache buffers can evict each other’s blocks and interfere with exclusive caching schemes. We present a global noncentralized, dynamic and informed management policy for multiple levels of cache, accessed by multiple clients. Our algorithm, MC 2 , combines local, per client management with a global, system-wide scheme, to emphasize the positive effects of sharing and reduce the negative ones. Our local management scheme, Karma , uses readily available information about the client’s future access profile to save the most valuable blocks, and to choose the best replacement policy for them. The global scheme uses the same information to divide the shared cache space between clients, and to manage this space. Exclusive caching is maintained for nonshared data and is disabled when sharing is identified. Previous studies have partially addressed these challenges through minor changes to the storage interface. We show that all these challenges can in fact be addressed by combining minor interface changes with smart allocation and replacement policies. We show the superiority of our approach through comparison to existing solutions, including LRU, ARC, MultiQ, LRU-SP, and Demote, as well as a lower bound on optimal I/O response times. Our simulation results demonstrate better cache performance than all other solutions and up to 87% better performance than LRU on representative workloads.

Power consumption is a major issue in today's datacenters. Storage typically comprises a significant percentage of datacenter power. Thus, understanding, managing, and reducing storage power consumption is an essential aspect of any efforts that address the total power consumption of datacenters. We developed a scalable power modeling method that estimates the power consumption of storage workloads. The modeling concept is based on identifying the major workload contributors to the power consumed by the disk arrays.

Transactional memory and speculative locking are optimistic concurrency control mechanisms, whose goal is to enable highly concurrent execution while reducing the programming effort. The same basic idea lies in the heart of both methods: optimistically execute a critical code segment, determine whether there have been data conflicts and roll back in case validation fails. Transactional memory is widely considered to have advantages over lock-based synchronization on shared memory multiprocessors. Several recent works suggest employment of transactional memory in a distributed environment. However, being derived from traditional shared-memory design space, these schemes seem to be not "optimistic" enough for this setting. Each thread must validate the current transaction before proceeding to the next. Hence, blocking remote requests whose purpose is to detect/avoid data conflicts are placed on the critical path and thus delay execution.

In today's networked storage environment, it is common to have a hierarchy of caches where the lower levels of the hierarchy are accessed by multiple clients. This sharing can have both positive or negative effects. While data fetched by one client can be used by another client without incurring additional delays, clients competing for cache buffers can evict each other's blocks and interfere with exclusive caching schemes. Our algorithm, MC2, combines local, per client management with a global, system-wide, scheme, to emphasize the positive effects of sharing and reduce the negative ones. The local scheme uses readily available information about the client's future access profile to save the most valuable blocks, and to choose the best replacement policy for them. The global scheme uses the same information to divide the shared cache space between clients, and to manage this space. Exclusive caching is maintained for non-shared data and is disabled when sharing is identified. Our simulation results show that the combined algorithm significantly reduces the overall I/O response times of the system.

Summary form only given. Since the introduction of the Java language less then a decade ago, there have been several attempts to create a runtime system for distributed execution of multithreaded Java applications. The goal of these attempts was to gain increased computational power while preserving Java's convenient parallel programming paradigm. This paper gives a detailed overview of the existing distributed runtime systems for Java and presents a new approach, implemented in a system called JavaSplit. Unlike previous works, which either forfeit Java's portability or introduce unconventional programming constructs, Java-Split is able to execute standard multithreaded Java while preserving portability. JavaSplit works by rewriting the bytecodes of a given parallel application, transforming it into a distributed application that incorporates all the runtime logic. Each runtime node carries out its part of the resulting distributed computation using nothing but its local standard (unmodified) Java virtual machine (JVM).

Code instrumentation is widely used for a range of purposes that include profiling, debugging, visualization, logging, and distributed computing. Due to their special status within the language infrastructure, the standard class libraries, also known as system classes provided by most contemporary object-oriented languages are difficult and sometimes impossible to instrument. If instrumented, the use of their rewritten versions within the instrumentation code is usually unavoidable. However, this is equivalent to `instrumenting the instrumentation', and thus may lead to erroneous results. Consequently, most systems avoid rewriting system classes. We present a novel instrumentation strategy that alleviates the above problems by renaming the instrumented classes. The proposed approach does not require any modifications to the language, compiler or runtime. It allows system classes to be instrumented both statically and dynamically. In fact, this is the first technique that enables dynamic instrumentation of Java system classes without modification of any runtime components. We demonstrate our approach by implementing two instrumentation-based systems: a memory profiler and a distributed runtime for Java.

This paper presents JavaSplit, a portable runtime for distributed execution of multithreaded Java programs. Java-Split transparently distributes threads and objects of an application among the participating nodes. Thus, it gains augmented computational power and increased memory capacity without modifying the Java multithreaded programming conventions. Java-Split works by rewriting the bytecodes of a given parallel application, transforming it into a distributed application that incorporates all the runtime logic. Each runtime node carries out its part of the resulting distributed computation using nothing but its local standard (unmodified) Java virtual machine (JVM). This is unlike previous Java-based distributed runtime systems, which use a specialized JVM or utilize unconventional programming constructs. Since Java-Split is orthogonal to the implementation of a local JVM, it achieves portability across any existing platform and allows each node to locally optimize the performance of its JVM, e.g., via a just-in-time compiler (JIT).

Abstract The advances in storage and communications enable users to store massive amounts of data, and to share it seamlessly with their peers. With the advent of XML, we expect a significant portion of this data to be in XML format. We describe here the architecture and implementation of an XML repository that promotes a novel navigation paradigm for XML documents based on content and context. Support for these capabilities is achieved by bringing to bear the organizational power of information retrieval to the domain of semistructured documents. File systems remain the preferred storage infrastructure for the home and business desktop environments. We have built a system, XMLFS, based on the ideas stated above. XMLFS presents a storage abstraction that manifests itself to the client as a familiar file system. However, it breaks the tight coupling between the directory hierarchical structure and the file system. XMLFS creates automatically a directory organization of any XML document collection based on content and context. Each user can navigate through the file system according to her/his domain of interest at that point in time. Our result is a first step towards a solution to the discovery and navigation problems presented by the collective repositories of XML documents in peer‐to‐peer environments.

Lempel-Ziv (1977) based compression algorithms are universal, not assuming any prior knowledge of the file to be compressed or its statistics. Accordingly, the reference dictionary of these textual substitution compression algorithms includes only segments of the already-processed portion of the file. It is often the case, though, that both, compressor and decompressor, even when they reside on different sites, share knowledge of files (e.g., devices managed by a server, or software customers holding older releases of products). For such cases, we suggest the addition of shared files to the reference dictionary. Preferably, files to be included are those which resemble the file to be compressed. Such an extension of the reference dictionary lengthens the matches found while compressing the file, and thus lessens the number of matches needed to cover the file. We found that with a careful selection (which can be automated) of the shared files to be included, the advantage of the decrease in the number of matches overwhelms the disadvantage of the increase in the number of bits needed to express the index of each match in the extended dictionary. Altogether, compression attainable by our proposed scheme can be significantly better than with the original Lempel-Ziv dictionary. Maintaining and searching a dictionary that is much larger than the original Lempel-Ziv dictionary demand strong computational resources and suits off-line more than on-line compression. We thus conclude that in the client/server environment, where shared files commonly exist, and the server enjoys extensive computational resources, the scheme suggested is advantageous for transferring files from the server to its clients.

Abstract The cluster virtual machine (VM) for Java provides a single system image of a traditional Java Virtual Machine (JVM) while executing in a distributed fashion on the nodes of a cluster. The cluster VM for Java virtualizes the cluster, supporting any pure Java application without requiring that application be tailored specifically for it. The aim of our cluster VM is to obtain improved scalability for a class of Java Server Applications by distributing the application's work among the cluster's computing resources. The implementation of the cluster VM for Java is based on a novel object model which distinguishes between an application's view of an object (e.g. every object is a unique data structure) and its implementation (e.g. objects may have consistent replications on different nodes). This enables us to exploit knowledge on the use of individual objects to improve performance (e.g. using object replications to increase locality of access to objects). We have already completed a prototype that runs pure Java applications on a cluster of NT workstations connected by a Myrinet fast switch. The prototype provides a single system image to applications, distributing the application's threads and objects over the cluster. We used the cluster VM to run, without change, arealJava Server Application containing over 10 Kloc Kloc means Kilo lines of code—used to describe the size of applications in terms of source lines count. for the source code and achieved high scalability for it on a cluster. We also achieved linear speedup for another application with a large number of independent threads. This paper discusses the architecture and implementation of the cluster VM. It focuses on achieving a single system image for a traditional JVM on a cluster while describing, in short, how we aim to obtain scalability. Copyright © 2001 John Wiley & Sons, Ltd.

cJVM is a Java Virtual Machine (JVM) that provides a single system image of a traditional JVM while executing on a cluster. cJVM virtualizes the cluster, supporting any pure Java application without requiring any code modifications. By distributing the application's work among the cluster's nodes, cJVM aims to obtain improved scalability for Java Server Applications. cJVM uses a novel object model which distinguishes between an application's view of an object and its implementation (e.g., different objects of the same class may have different implementations). This allows us to exploit knowledge on the usage of individual objects to improve performance. cJVM is work-in-progress. Our prototype runs on a cluster of IBM IntelliStations running Win/NT and are connected via a Myrinet switch. It provides a single system image to applications, distributing the application's threads and objects over the cluster. We have used cJVM to run without change a real Java application containing over 10Kloc and have achieved linear speedup for another application with a large number of independent threads. This paper discusses cJVM's architecture and implementation, showing how to provide a single system image of a traditional JVM on a cluster.

The process trellis is a parallel software architecture for building heuristic real-time monitors. These programs, for example Intelligent Cardiovascular Monitors, must process massive quantities of data in real time. It is natural to turn to parallelism to meet these computational requirements. The process trellis software architecture is intended to simplify the creation and maintenance of heuristic real-time monitors. To do this it must be 1) modular, 2) efficient and 3) predictable.