Emc IP Holding Company LLC

Emc Corporation

Dell Products Inc.

Other

Ems Ep Holding Company LLC

Arieh Don

Vinay G Rao

Sanjib Mallick

Ian Wigmore

Alexandr Veprinsky

Philip Derbeko

Stephen Smaldone

Michael J Scharland

Patrick Brian Riordan

Assaf Natanzon

Gabriel Benhanokh

Owen Martin

Subin George

Marik Marshak

Krishna Deepak Nuthakki

Felix Shvaiger

Alex Veprinsky

Anat Eyal

Scott Rowlands

Yaron Dar

Erik P Smith

Zvi Gabriel Benhanokh

Adnan Sahin

Jaeyoo Jung

Jehuda Shemer

Michael E Specht

Kenneth A Halligan

David Meiri

Anton Kucherov

Helen S Raizen

Tomer Shachar

Anestis Panidis

Natan Vishlitzky

Xiali He

David Joshua Brown

Elie Antoun Jreij

Saar Cohen

Sunil Kumar

Ramesh Doddaiah

Yevgeni Gehtman

Amit Pundalik Anchi

Philip E Tamer

Andrew Chanler

Maxim Balin

Ajith Balakrishnan

Roy E Clark

Michael E Bappe

John T Fitzgerald

Dan Aharoni

Hana Moreshet

Amnon Naamad

Deepak Vokaliga

Michael Ferrari

Mathieu Gagne

Gopinath Marappan

Owen Crowley

Ishay Kedem

Benjamin W Yoder

Dan Arnon

Malak Alshawabkeh

Erez Ofer

Peniel Charles

Randall Shain

Stephen Richard Ives

Harold Martin Sandstrom

Alesia Tringale

Ofer Michael

Prakash Venkatanarayanan

John Krasner

Philippe Armangau

Douglas Eric LeCrone

Ching-Yun Chao

Mark J Halstead

Haim Kopylovitz

Peng Wu

Rong Yu

Xiaoye Jiang

Eitan Bachmat

Hui Wang

Jonathan I Krasner

Thomas L Watson

Ron Arnan

Amihai Savir

Xiaomei Liu

Yechiel Yochai

Valerie Lotosh

Ning Wu

Kurumurthy Gokam

Jeremy O'Hare

Stav Sapir

Kundan Kumar

Bhaskar Bora

Rimpesh Patel

Donald Mace

John Creed

Hongliang Tang

Naor Radami

John W Bates

Igor Achkinazi

Michael D Barber

In a software-defined data storage system with a production node and local and remote storage nodes that replicate data generated by an application running on the production node, all filesystem metadata associated with remotely replicated devices is copied from the remote storage node to memory of the production node in response to establishment of a communication link between the production node and remote storage node. That metadata is maintained in the memory for as long as the link is active and used to generate multiple remote replication IOs. Local replication is implemented by reading only necessary metadata from the local storage node on a per-IO basis. The cached metadata is flushed from memory in response to loss of the communication link.

Efficient storage device handling in remote replication

An apparatus in an illustrative embodiment comprises at least one processing device that includes a processor coupled to a memory. The at least one processing device is configured to implement a centralized discovery controller for coupling to a host and to a storage system accessed by the host, with the centralized discovery controller being configured to receive from the host a congestion alert, and responsive to the received congestion alert, to send to the host and to one or more targets of the storage system corresponding congestion control messages. The congestion alert is illustratively received in the centralized discovery controller from a multi-path input-output (MPIO) driver of the host, where the MPIO driver controls delivery of IO operations from the host to the storage system over selected paths. The congestion control messages may comprise respective Asynchronous Event Notifications (AENs) associated with respective Asynchronous Event Requests (AERs).

Host multi-path layer with congestion mitigation through interaction with centralized discovery controller

Methods and systems for managing storage services provided by storage arrays are disclosed. The storage services may be managed by proactively identifying and remediating malicious activity that may impact the storage services. The malicious activity may be identified by monitoring activity of adapters used by host devices to communicate with the storage arrays. The activity may be monitored to identify patterns of reset commands that are likely to negatively impact storage services provided by the storage arrays.

Protecting storage arrays from load attacks

Methods and systems for offloading signature computations are disclosed. The signature computations may be offloaded from a storage array to a host. The host may use data processing units or graphical processing units to process the signature computations. In processing the signature computations by the host, the storage array may further process deduplication of the signatures, once they are received from the host. The host may require that the storage array support the distributed system and the deduplication procedure and meet a deduplication ratio specified by a criteria.

Data storage through offloading signature computations

A storage array is configured with an allowed process configuration. An allowed process may correspond to an application or process executed by a host computing system that may seek to access a volume of the storage array via a command descriptor block message or a corresponding block command message, which may comprise a data field and a metadata field. The host may embed a process identifier corresponding to a process seeking to access the storage array in the metadata field. The storage array may receive the block command message and determine whether the metadata field comprises a process identifier that is included in the allowed process configuration. If so, the storage array may perform the access command corresponding to the block command message. If not, the storage array may reject performing the access command. The storage array may report access commands that were performed or rejected.

Protecting data from unprivileged processes

In an active-active replication environment in which sequential read IOs are distributed across storage array ports and replicas, a first read data size controls selection of a different path to a currently targeted replica to distribute sequential reads across storage system ports and a second read data size controls when a different replica is selected to distribute the sequential reads across storage systems. The storage arrays that maintain the replicas are phase-coordinated to pre-fetch only sequential data that will be accessed in the near future from their local replica. For example, a first storage array prefetches sequential data from a first replica in chunks corresponding to the first data size until sequential data corresponding to the second data size has been prefetched, skips sequential addresses corresponding to the second data size, and prefetches sequential data corresponding to the first data size that is next in sequence relative to the skipped sequential addresses.

Enhancing array prefetch for sequential IOs in active-active remote replication

A storage array is configured to detect single points of failure (SPoFs) that could cause a host application to fail. Zoning information obtained from network switches is used with initiator-target login information to determine whether all host server HBA port initiators logged in to a storage object maintained by the storage array are from the same zone. If so, a path-based SPOF alert is generated. If all host server HBA port initiators logged in to the storage object are from the same HBA, then a NIC-based SPOF alert is generated. A masking view is used with the zoning information and initiator-target login information to determine whether all host server HBA port initiators logged in to the storage object are from the same host server. If so, a clustering-based, nodal SPOF alert is generated.

SAN single path point of failure detection

A migration management application may facilitate generating an image of a source cloud block drive formatted according to a first format. The management application may facilitate copying of the image to a target cloud block drive formatted according to a second format. Changes directed to the source drive during copying of the image may be stored to a first journal, which may be copied to the target drive. During copying of the first journal, changes directed to the source drive may be stored to one or more subsequent journals. Upon determining that a subsequent journal is smaller than a configured cutover criterion, the management application may pause, during a cutover period, directing of changes to the source drive. The management application may copy changes, directed to the source drive during the cutover period, to the target drive and may redirect user/data applications to operate with respect to the target drive.

Migrating data between heterogeneous cloud block devices

One or more aspects of the present disclosure relate to read-skew-based data theft mitigation. In embodiments, an input/output (IO) workload is received at a storage array. Further, access to a logical device can be controlled based on at least one read capacity skew forecast corresponding to the logical device.

Read skew based data theft mitigation

A disaster recovery site storage array causes an instance of a host application or selected executables running on a host server to validate changes to an asynchronously updated replica of a storage object. Snapshots of the replica are generated before and after each set of changes to the replica are received from a remote storage array. Validation is performed by mounting snapshots to the instance of the associated host application and causing the host application instance to validate the data. If a snapshot is determined to be invalid, then the replica to recovered with the most recent known-valid snapshot. Alternatively, if each set of changes is validated prior to being applied to the replica, invalid changes are not applied to the replica. Unvalidated snapshots may be accumulated and validated independently from application of sets of changes to the replica, thereby decoupling validation from replication.

Zero-trust remote replication

Methods and systems for securing data are disclosed. To secure data, signed tokens may be used to authenticate operations to be performed by storage arrays. The operations may modify data stored in the storage array and/or provide copies of stored data. The signed token may specify limits on the authority of various entities to invoke various functions of storage arrays, and include cryptographic data usable by the storage arrays to authenticate the tokens. By requiring that tokens be included with operations to be performed by storage arrays, the storage arrays may be less likely to perform undesired operations.

Storage array protection using signed token

Techniques for obfuscating and/or de-obfuscating data using bit-level shard masks are disclosed. Shard masks are generated. The shard masks are designed to shard a block of data into a number of shards for distribution and storage among a number of storage arrays. The shard masks shard the block of data at a bit-level granularity. The shard masks are applied to the block of data to generate the shards. The shards are then distributed among the storage arrays for storage on the storage arrays.

Bit level sharding of sensitive data for increased security

An apparatus in one embodiment comprises at least one processing device configured to detect a plurality of asynchronous events in a storage system, wherein the storage system is configured to provide respective individual asynchronous event notifications for the detected asynchronous events to a host device in response to receipt of corresponding asynchronous event requests from the host device. The at least one processing device is further configured to determine that multiple ones of the asynchronous events have been detected in the storage system without receipt of respective ones of the corresponding asynchronous event requests from the host device, and to provide to the host device in response to a particular one of the asynchronous event requests received from the host device a summary notification comprising information indicative of the multiple detected asynchronous events. The at least one processing device illustratively comprises at least one storage controller of the storage system.

Concurrent handling of multiple asynchronous events in a storage system

An apparatus comprises at least one processing device configured to implement a multi-path layer in a host device, wherein the multi-path layer controls delivery of input-output (IO) operations from the host device to a storage system over selected ones of a plurality of paths through a network. The multi-path layer is configured, for each of at least a subset of the IO operations, to store at least a process identifier, a user identifier and an access type for the IO operation. The multi-path layer is further configured to perform analytics on the stored process identifiers, user identifiers and access types to detect an access pattern, and responsive to the detected access pattern having one or more designated characteristics associated with malware, to generate an alert. The alert may be generated by inserting security alert indicators into respective ones of the IO operations, for extraction therefrom by the storage system.

Host multi-path layer with IO analytics for malware defense

Local power storage automation (e.g., using a computerized tool), is enabled. For example, a system can comprise: a processor and a memory that stores executable instructions that, when executed by the processor, facilitate performance of operations, comprising: based on historical power consumption data applicable to a data center rack, determining a predicted future power consumption by the data center rack, determining energy resource data of an energy resource available for consumption by the data center rack, wherein the energy resource data comprises energy unit cost, energy transfer rate, and usage limit applicable to the energy resource, and based on the predicted future power consumption by the data center rack and the energy resource data, and based on a defined power criterion being determined to be satisfied, powering the data center rack via the energy resource.

Local power storage automation

Growing community of inventors

Newton, MA, United States of America

Arieh Don