Patent Application
20160203145
The present invention, in some embodiments thereof, relates to service oriented distributed data management with associated architecture and, more particularly, but not exclusively, to such a system that uses content and metadata to manage the data. Today the amount of storage keeps on growing exponentially, with major growth in new storage fronts such as cloud and BigData, and future growth trends with the emergence of the internet of things (IoT). In the new age data is dynamic, can move or replicate between different physical locations, can move between faster solid state storage or slower mechanical hard drives (HDD) based on usage patterns, and needs to be shared by many clients or applications, whether they are sensors, mobile phones, tablets, PCs, or application servers.
To date, most storage of data is block storage. Data is blindly arranged in blocks with no reference to the content. Multiple level storage can follow usage patterns as mentioned above to place more frequently used pieces of data in faster storage while keeping all of the data in main storage. Firewalls and other network control devices can inspect packets and direct data transfer according to the results, which may occasionally relate to the content, but there is no equivalent in data storage and management once beyond the bounds of networking.
The present trends suggest a different approach to storage, no longer silos of single vendor block storage mapped to a single client or application, but rather an adoption of highly scalable file or object based globally networked storage, which can serve many clients or applications, and connect to multiple local, remote, or cloud based storage resource islands/pools from a variety of vendors and be managed as a service.
Today there are some file sharing solutions in the form of NAS (Network Attached Storage) or even clustered/scale-out NAS solutions which have internal storage and support file access protocols, those however are limited in scale, provide only basic file management data services, and focus on local deployments.
Some new object storage solutions exist as local clusters or in the form of cloud storage, and examples include Amazon S3, Google Drive, and Dropbox, all of which are quite scalable, but are still limited in performance and in the data services that they provide, have limited consistency, and do not allow mixing various storage resources. The main use of those services is for backup and archiving and not as a form of enterprise storage or a way to unify different storage resources or protocols under the same governance.
Given the huge variety of potential clients and applications, each requiring different storage services, or different priorities, and the enormous scale and variety of the underlying storage resources, the management paradigm may be expected to change from the present day black box type of management which is agnostic to the data content.
The present embodiments may provide a service oriented distributed data resource management layer, which may in turn provide security, appropriate service levels, data lifecycle management, and features/functionality required by individual clients or applications or a group of such. Data is managed as data objects or groups of objects, based on content and metadata and the different protocols through which the data arrives, or management may be based on metadata which the system stores about those objects, and the protocols are mapped to a common data semantic in which features can be selected for highly granular data management policies. The features can be from the content, from the metadata, from the session history, information to do with the data source or the source history and the like and can be arranged into policies in advance, or dynamically as required. The data management and processing can be done in a distributed fashion, multiple data control and processing elements can be scattered locally and globally, those divide the data name space among them so each control element would only process a relevant portion of the data objects, thereby gaining scalability, higher level controller entities can distribute and synchronize the data management policies across all data processing elements. The data management and processing can be distributed and implemented in a cascading or topology driven fashion in which the same traffic or objects are processed by multiple stages and each stage may implement a portion of the data classification or processing tasks.
According to an aspect of some embodiments of the present invention there is provided a method of managing data, comprising:
identifying data objects, the data objects having attributes;
unpackaging said objects, said unpackaging comprising mapping said attributes to a common central semantic;
using said common central semantic, obtaining features of said data objects;
defining at least one data management policy for data objects using said features and said common central semantic, said data management policy defining a feature-based sequence of data management actions defining data management that varies for different objects depending on respective features; and
applying said at least one policy to objects of said application or protocol according to said features as appearing in individual objects, thereby to carry out said data management for each object individually.
According to an aspect of some embodiments of the present invention there is provided a method of managing data, comprising:
identifying data objects having respective features, and an associated policy, said associated policy being a data management policy for data objects using said features, said data management policy defining a feature-dependent sequence of data management actions providing data management that varies for different objects depending on said respective features;
obtaining said respective features of given data objects;
applying at least one data management action to one of said data objects based on said at least one policy and according to features of said one data object; and
managing said individual objects according to said policy and said respective features.
Data streams and objects can be scattered across a plurality of data processing elements which may reside in one or more locations, and each data processing element may manage and process all the data objects or a subset of the data objects or a subset of the data streams to gain scalability. One or more higher level data controllers may distribute the data management policies to the individual data processing elements.
Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the invention, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.
Implementation of the method and/or system of embodiments of the invention can involve performing or completing selected tasks manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment of embodiments of the method and/or system of the invention, several selected tasks could be implemented by hardware, by software or by firmware or by a combination thereof using an operating system.
For example, hardware for performing selected tasks according to embodiments of the invention could be implemented as a chip or a circuit. As software, selected tasks according to embodiments of the invention could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In an exemplary embodiment of the invention, one or more tasks according to exemplary embodiments of method and/or system as described herein are performed by a data processor, such as a computing platform for executing a plurality of instructions. Optionally, the data processor includes a volatile memory for storing instructions and/or data and/or a non-volatile storage, for example, a magnetic hard-disk and/or removable media, for storing instructions and/or data. Optionally, a network connection is provided as well. A display and/or a user input device such as a keyboard or mouse are optionally provided as well.
Some embodiments of the invention are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the invention. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the invention may be practiced.
In the drawings:
The present invention, in some embodiments thereof, relates to a data management method and system and more particularly, but not exclusively, to a data management method and system that uses features within or associated with data objects to manage the data objects with high granularity in a distributed environment.
Data arrives in a session to be managed in various ways. Data management may involve different ways of storage, of making the data available to users, of backing up, replicating or keeping the data up to date, of taking snapshots, of providing redundancy and otherwise securing the data and of disposing of old and unwanted data. Data management may involve hierarchical arrangement of the data in layered storage, and data belonging to different users or data of different kinds may be managed in different ways. In one embodiment, rules belonging to different groups may be arranged in a hierarchy, for example rules handling data belonging to different users may form one group and rules for handling different kinds of data may be placed in another group, and then a hierarchical relationship between the two groups may be defined in order to solve conflicts between contradictory rules.
The position of the data in a hierarchy may be considered to be part of associated metadata.
A session in the present context is any framework in which data objects arrive, and the session has session attributes which define what the data is or where it comes from or where it is going or what to do with it and the like. The data can be tagged and the tags can be used to decide what to do with the data in the management system, that is to say to determine what policies apply. The policies may assign one or more present or future actions to the data.
To address the need for faster storage access, new mesh or edge/core data management topologies are being designed, similar to the way very large server networks are built, and the present embodiments allow the data management layer to try and manage or filter or cache the data in-flight in a more application aware manner, reducing the overhead and scalability challenges of current applications and reducing the dependency on network bandwidth or latency. When doing so there is even a greater need for scalable data management approaches which can guarantee a consistent view of the data, and provide consistent policy and data processing regardless of where the data may have come from or where it is being stored.
Today there is a wide variety of data access protocols which range from file oriented access, for example NFS, CIFS, WebDAV, FTP, . . . to object protocols such as Rest, Amazon S3, OpenStack Swift, and then there are other application specific protocols such as Hadoop HDFS and HBASE, and in many cases different clients may try and access the same file or object through different protocols. There is thus provided in accordance with some of the present embodiments the ability to map the attributes, including protocol attributes, of the incoming data to a common data transaction semantic, process the data requests according to the appropriate policy, and then read or store the data in the relevant storage resource which can also use different interfaces ranging from block protocols such as SCSI, SATA, iSCSI, FC, or file protocols, or object protocols, or memory semantics. In any service oriented data management layer there may be segregation between the access or storage media protocol and the data security, tiering, and retention etc policies.
Unpackaging and mapping may involve stripping away the specific structure or packaging of incoming data, and separating the content itself from the associated metadata. The metadata is stored in a uniform manner and associated with the content so that the content can be managed on a high granularity basis.
A preferred part of managing a service is the ability to constantly monitor the service usage and behavior, as part of a service oriented data management layer in which analytical data on the data access patterns, faults, capacities, usage, etc. may be collected.
Such data can be used by the system users or administrators or can be used by the system itself to adapt its behavior in a proactive manner, an example would be to migrate a storage resource closer to the actual user, or slow down or disconnect an abuser accessing shared data.
The present embodiments may thus provide a distributed, software defined, service oriented data management layer allowing many different clients and applications in different places using different access protocols to access large amounts of data stored in a variety of storage resources in different locations, while abstracting, securing, optimizing, monitoring, modifying, and managing the lifecycle of the data in a consistent way, and potentially embedding higher level data services in a scalable and fully programmable fashion.
In the present embodiments there may be multiple data controller elements, which distribute or replicate the storage namespace among them, and may provide flexible front-end connectivity to support any protocol or access pattern. The controller elements may be themselves controlled through a set of match/action based rules (similar to network packet routers) focused on data objects and services, and can store the data in variety of local or remote storage resources with difference performance or cost characteristics. Controller elements or portions of them may be arranged in a cascade with multiple stages, each such controller stage may implement parts of the data classification or data management action enabling greater scalability of the system.
In addition, there may be provided a control layer which processes and distributes the desired data services and access policies to the different data controller nodes. The processing can be distributed based on the origin of the data transactions or based on the data objects name space, or based on any other combinations.
By using flexible match/action rules the control layer may apply any type of data management behavior/function to any data object or object category or user or protocol or combination. This allows a software defined data management path, with enormous flexibility and granular control compared to the common practice today which is rigid and allows a limited set of actions per object or file directory. The policy may consist of a set of match/action rules which can be ordered according to the priority of each rule. This way if there are conflicts between rules or a partial match the rules with the higher priority wins. Multiple policy rules can be grouped together by application or through a usage scenario, and may be added or updated or removed in an atomic fashion to guarantee consistent policy behavior and simpler management. Having a flexible and software defined policy may provide for managing of shared data especially when addressing distributed, dynamic and large scale environments, with a variety of workloads each requiring different services.
Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the Examples. The invention is capable of other embodiments or of being practiced or carried out in various ways.
Referring now to the drawings,
The common semantic may then be used to obtain features or metadata or content of data objects and identify a nearby data processing element to process that object policy. As will be explained below, the features or metadata or content may be found in the objects themselves or may relate to the network source, network source attributes, or users, including a user identity, or sessions or applications or protocols relating to the objects. Depending on the protocol or application, the data objects may be files, databases, database entries, data records, media streams, log or event streams, time series data, messages, OOP objects, data packets, or any other organizational unit of data. The features may be used to define 16 a data management policy or policies for object or type of object. When an individual object requires data management services, then features relating to the object are extracted 18, and then used to apply the policy so as to manage or service the object.
The features may be taken from the object content, from metadata either contained within the object or otherwise relating to the object, session history, information to do with the data source; information to do with the history of the data source, information to do with the protocol or application itself or any other information source that is available and relevant to management of the data.
In one embodiment the policy is ready in advance of receipt of a data object requiring data management or data services. In an alternative a policy may be provided dynamically with initial presentation of the objects.
Data management relates to a data management system say at enterprise level or data management at the cloud level, and may involve defining availability of particular data objects so that the policy defines availability of the objects in terms of the object features.
Data management may relate to storage of the data objects in a flexible storage hierarchy, so that the policy relates hierarchy levels to object features.
The policies may be applied to parts of objects, again based on features. Thus for example if the object is an article having a headnote and detailed text, then the availability of the headnote may be set higher than that of the detailed text. In this way, flexibility of the data management allows advantage to be taken of the levels of the data storage hierarchy.
Likewise, data management may relate to synchronization of the data objects with other objects elsewhere, and the policy may relate synchronization actions to features of the data objects.
Likewise, data management may relate to obtaining snapshots or a backup or archiving so that the snapshot or backup or archiving is governed by features relating to the objects.
The data management may include defined actions, and the data management method may involve attaching one or more of the defined actions to a data object according to the features of the object and the associated policy. The actions may be carried out by the backend logic but some, say the simpler actions, may be carried out at the front end to offload logic from the backend. Actions carried out at the front end may be carried out immediately upon data arrival and may use preset rules which do not depend on the central mapping.
The same object may have more than one policy applied thereto, each defining actions. The policies may be arranged in a hierarchy so that in the event of conflict between two actions, the action whose policy is higher in the hierarchy succeeds.
Reference is now made to
As discussed with respect to
The action may be applied according to rules of the policy.
Examples of actions include any of the following: a routing action, a block action, a redirect action, a mirror action, a mapping action, a data caching action, a data pre-fetching action, a data tiering action, a snapshot action, a copy on write action, a data compression action, a data encryption action, a data deduplication action, a content filtering action, a pattern matching action, a remote notification action, a remote replication action, a QOS action, a QOS action defining bandwidth limits, a QOS action defining bandwidth guarantees, a QOS action defining priority, a QOS action defining limits or guarantees on the number of data or IO transactions per second, a QOS action defining a data size, a QOS action defining a data growth rate, a QOS action defining warning events, a tag set action, a tag increment action, a tag decrement action, a set attribute tag action, a data content processing action, generation of custom logs or reports action, and a function call action and a default action.
There may also be a set of actions that do not happen in the context of the incoming transaction, and these include examples such as: periodic backups or archiving of the data, which may operate according to a given schedule, periodic snapshots, periodic data synchronization between repositories, periodic report generation, periodic or schedule based data movement, automated data deletion, e.g. based on file aging from its creation data or last usage, periodic incremental replication, say in which after every n minutes the delta or changes are sent, tiering which may involve moving data between different storage classes based on the historical usage pattern combined with user policies, processing of the data content and transforming the content into a new form as a batch operation.
The different actions may be associated with elements in a control layer and the actions may operate their corresponding elements to manage the object.
The embodiments are now considered in greater detail, with respect to
A low latency fabric with distributed consistency 56 connects to scaled out data services 58 which are designed to provide scalability and performance which are potentially unlimited. A data pipe service (DPS) 60 provides parallel processing and smart read/write caching of storage transactions and services. There may be numerous individual pipelines 62.1 . . . 62.n. Object store service (OSS) 64 comprises a variety of pluggable storage options mapped into a primitive k/V object API or file abstraction. Three OSS logic instances 66 are shown. The architecture further provides flexible storage and resource options which are decoupled from processing, and which are used for tiering, capacity scaling and migration. The three options provided are direct, networked and cloud. Direct provides the lowest cost and highest density solution. Networking provides for greater reliability and is compatible with legacy applications. Cloud provides backup, archiving, synchronization and sharing options. The architecture can be scaled to include new storage options as they are introduced.
Data transport is bidirectional, and the outward direction from object storage 94 may avoid the data placement service 98.
The containers may be of different types and may have policies/ACLs, and distributed group objects to handle hierarchical relations, file directories, tables, indexes, and distributed transactions.
Each tenant may have multiple containers and multiple users. The container data may be sliced into groups and hierarchies 152 including nested groups such as a directory structure.
In 3 the slaves acknowledge the synchronization or replication.
In 4 an acknowledgement is sent to the user.
In 5 the DPS's from other zones accept the copy of the data.
In 6 non-parked data is confirmed, and in 7, when shared access OSS stores the data, all other DPSs are notified about the new copy, as in the local example above.
Reference is now made to
The system 200 contains an identifying unit 206 whose task is to identify data objects having particular features that it already knows about and an associated policy. The associated policy is a data management policy that the system has already assigned for data objects using having the given features identified. The data management policy may define a feature-dependent sequence of data management actions varying for different objects depending on the respective features.
A feature obtaining unit 208 obtains the features from the given data objects, which the identification object may then understand and use to associate the object with the corresponding policy. To be clear, the feature obtaining unit identifies features on a given data object and the identification unit uses those features to decide what the object is and what it belongs to.
A data management assignment unit 212 assigns data management tasks to the object based on the associated policy. The management unit 214 then manages the individual objects according to the policy the features and the assigned management tasks. Common semantic 210 stores the various features, that may come from numerous protocols, in a single unified arrangement, allowing the system 200 to provide application aware data management overall.
Feedback between different stages may be implemented. A data management action may set a common semantic attribute associated with said object, that may be used in subsequent operations. A policy may drive the system to update an object attribute, and that attribute can be classified by the following stages in the processing phases to further drive new actions, or the new attribute may serve as an input to the classification and be taken into account when later following messages arrive.
Features of the present embodiments are now discussed in greater detail and include the following:
Policy is stored per container, container belongs to an account/tenant.
The match Key can consist of some or all of the following fields, which make up the session attributes:
Policies have states to disable/enable.
The system can mark the user creating the policy, and/or restrict creation of certain rules to a subset of users. Policy can be organized by layers, layers can be restricted to view/modify by individual users, layers can be inherited from other containers and/or general user or tenant policy.
Actions can be grouped to policy or IO/app types/behaviors (to simplify for users).
A date and/or time range and expiration time may be associated with a policy rule (indicating a rule will only be active during that time).
Monitor (Source Host/Net/User/Group+Protocol, Object path/type, Current Tags)
As previously described, policy can be enforced by multiple data processing services (DPS) in a global scale. Such enforcement may require replicating the policy and state of the data objects in all the relevant processing elements in a consistent way.
To enable better scaling and performance the data object processing may be scattered across multiple data processing services (DPS) where each such service may only process a portion of the data namespace, that is individual objects or containers or some portion of those, so that each service needs to only hold and manage a portion of the data management policy which is relevant to those objects. In such a case the front-end services (FES) need to know where to direct the traffic to, so only data management services that are synchronized on the policy and state of data objects process those data objects and the system maintains a consistent policy and data view.
Multiple data processing services in the same or different locations may manage the same data objects to enable greater performance or locality or availability or scalability. In such a case the object state and/or policy and/or content may need to be replicated across all the services which may manage the same data.
A higher level controller entity can take the global policy and break and/or replicate the policy into multiple data processing services in different locations in a consistent way.
It is expected that during the life of a patent maturing from this application many relevant data management services and transactions will be developed and the scopes of the corresponding term are intended to include all such new technologies a priori.
The terms “comprises”, “comprising”, “includes”, “including”, “having” and their conjugates mean “including but not limited to”.
The term “consisting of” means “including and limited to”.
As used herein, the singular form “a”, “an” and “the” include plural references unless the context clearly dictates otherwise.
It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment, and the above description is to be construed as if this combination were explicitly written. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the invention, and the above description is to be construed as if these separate embodiments were explicitly written. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.
Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.
All publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention. To the extent that section headings are used, they should not be construed as necessarily limiting.
This application claims the benefit of priority under 35 USC 119(e) of U.S. Provisional Patent Application No. 62/099,673 filed on Jan. 5, 2015, the contents of which are incorporated herein by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62099673 | Jan 2015 | US |
