WO2016151584A2

WO2016151584A2 - Distributed large scale storage system

Info

Publication number: WO2016151584A2
Application number: PCT/IL2016/050312
Authority: WO
Inventors: Raz Gordon
Original assignee: Storone Ltd.
Priority date: 2015-03-26
Filing date: 2016-03-24
Publication date: 2016-09-29
Also published as: WO2016151584A3

Abstract

There is provided a distributed storage system (DSS) and method of operating thereof. DSS comprises Objective Based Configuration Module (OBCM) operatively coupled to a plurality of interconnected computer nodes. Computer nodes comprise processing resources to calculate data indicative of conformity between 1) parameters relating to storage-related resources connected to respective interconnected computer nodes and at least partially allocated to a logical storage entity and 2) a Service Level Specification (SLS) indicative of user-defined storage requirements referring to the logical storage entity, and to inform the OBCM accordingly. OBCM is configured to: use the conformity indicative data to assess conformity status (over-utilized, normal or under- utilized) for a storage location with respect to storage-related resources placed thereon; calculate a reconfiguration for the DSS so that to re-allocate storage-related resources from storage location with under-utilized status to a storage location with over-utilized status; and perform measures for re-allocating according to the calculated reconfiguration.

Description

DISTRIBUTED LARGE SCALE STORAGE SYSTEM

FIELD OF PRESENTLY DISCLOSED SUBJECT MATTER

The invention relates to distributed large scale storage systems and in particular to an apparatus and a method for implementing such systems.

BACKGROUND

Distributed storage systems have rapidly developed over the last decade as networks grow in capacity and speed. With networks expanding from local area networks (LAN) to global wide area networks (WAN), storage systems customers (such as businesses) are becoming more globally distributed, resulting in a demand for distributed storage systems to provide data storage and access over a plurality of locations (hereinafter: "Storage Locations"), that are optionally distinct and/or geographically remote from one another. In addition, in some cases, the resources allocated to a first customer in one or more of the Storage Locations can be over utilized, whereas the resources allocated to a second customer in one or more other Storage Locations (or in the same Storage Location, that can be shared by more than one customer), can be underutilized. There is thus a need in the art for a new method and system for reallocation of data storage resources.

SUMMARY

According to a first aspect of the presently disclosed subject matter, there is provided a distributed storage system comprising: an Objective Based Configuration Module (OBCM) operatively coupled to an infrastructure layer comprising two or more interconnected computer nodes operatively connected to a plurality of storage-related resources, the computer nodes and the storage-related resources distributed over a plurality of storage locations, wherein: at least one of the interconnected computer nodes comprises at least one processing resource configured to calculate conformity indicative data indicative of conformity between (1) storage-related resources parameters data relating to one or more storage-related resources connected to respective interconnected computer nodes and at least partially allocated to a logical storage entity, and (2) at least one Service Level Specification (SLS) indicative of user-defined storage requirements referring to the logical storage entity, and to inform the OBCM accordingly; and wherein the OBCM is configured to: assess conformity status for at least one storage location of the plurality of storage locations using the conformity indicative data received with respect to storage- related resources placed at the at least one storage location, the conformity status indicative of over-utilized, normal or under-utilized status of one or more storage-related resources placed at the at least one storage location; calculate a reconfiguration for the distributed storage system based, at least, on the assessment results, so that to re-allocate one or more storage-related resources from storage location with under-utilized status to a storage location with over-utilized status; and perform one or more measures for re- allocating at least part of at least one of the storage-related resources according to the calculated reconfiguration.

In some cases the measures include issuing a command to physically move at least part of at least one of the storage-related resources from a first storage location with under-utilized status to a second storage location with over-utilized status.

In some cases the reconfiguration is calculated also based on at least one of the costs of the reallocation or the required time for completion of the reallocation.

In some cases the reconfiguration is calculated such that the costs of the reallocation are minimal.

In some cases at least a first storage location of the plurality of storage locations is associated with a first customer and at least a second location of the locations is associated with a second customer.

In some cases the first storage location is associated with a first customer and the second location of the locations is associated with a second customer.

In some cases at least two storage locations of the plurality of storage locations are associated with the same customer.

In some cases the one or more storage-related resources include at least one storage-related resource of the following storage-related resource categories: cache resources, data storage resources and network resources.

In some cases the one or more storage-related resources include at least one storage-related resource of each of the following storage-related resource categories: cache resources, data storage resources and network resources.

In some cases the measures include migrating data from at least one data storage resource to be reallocated. In some cases the reconfiguration is calculated by an optimization engine.

In some cases the optimization engine uses one or more of the following optimization techniques: linear programming; simulated annealing; genetic algorithms.

In some cases the one or more optimization techniques uses heuristics or approximates.

In some cases the at least one user-defined storage-related requirement includes at least one of: location; local protection level; backup retention policy; remote protection level; performance levels; encryption level; de-duplication; compression; storage method.

In some cases the informing of the OBCM is performed by the processing resource directly.

In some cases informing of the OBCM is performed by the processing resource via a second interconnected computer node. According to a second aspect of the presently disclosed subject matter, there is provided a method of reconfiguring a distributed storage system utilizing an Objective Based Configuration Module (OBCM) operatively coupled to an infrastructure layer comprising two or more interconnected computer nodes operatively connected to a plurality of storage-related resources, the computer nodes and the storage-related resources distributed over a plurality of storage locations, the method comprising: calculating conformity indicative data indicative of conformity between (1) storage-related resources parameters data relating to one or more storage-related resources connected to respective interconnected computer nodes and at least partially allocated to a logical storage entity, and (2) at least one Service Level Specification (SLS) indicative of user- defined storage requirements referring to the logical storage entity, and informing the OBCM accordingly; and assessing, utilizing the OBCM, conformity status for at least one storage location of the plurality of storage locations using the conformity indicative data received with respect to storage-related resources placed at the at least one storage location, the conformity status indicative of over-utilized, normal or under-utilized status of one or more storage-related resources placed at the at least one storage location; calculating, utilizing the OBCM, a reconfiguration for the distributed storage system based, at least, on the assessment results, so that to re-allocate one or more storage-related resources from storage location with under-utilized status to a storage location with over- utilized status; and performing one or more measures for re-allocating at least part of at least one of the storage-related resources according to the calculated reconfiguration.

In some cases the measures include migrating data from at least one data storage resource to be reallocated.

In some cases the reconfiguration is calculated by an optimization engine.

In some cases the at least one user-defined storage-related requirement includes at least one of: location; local protection level; backup retention policy; remote protection level; performance levels; encryption level; de-duplication; compression; storage method. BRIEF DESCRIPTION OF FIGURES

In order to understand the presently disclosed subject matter and to see how it may be carried out in practice, the subject matter will now be described, by way of non-limiting examples only, with reference to the accompanying drawings, in which:

Figure 1 schematically illustrates a top-level architecture of a Distributed Storage

System including an Infrastructure Layer, according to an exemplary embodiment of the invention;

Figure 2 schematically illustrates a simplified, exemplary system for configuring a Distributed Storage System, according to the presently disclosed subject matter;

Figure 3 schematically illustrates a simplified and exemplary flow diagram of an optimization process performed by the objective-based management system, according to the presently disclosed subject matter;

Figure 4 schematically illustrates a simplified flow diagram of an exemplary operational algorithm of a configuration process performed by the objective-based management system, according to the presently disclosed subject matter;

Figure 5 is a block diagram schematically illustrating an exemplary computer node connected to the Distributed Storage System, according to certain examples of the presently disclosed subject matter;

Figure 6 is a flowchart illustrating a sequence of operations carried out for calculating conformity indicative data, according to certain examples of the presently disclosed subject matter; and

Figure 7 is a flowchart illustrating a sequence of operations carried out for reconfiguring the Distributed Storage System, according to certain examples of the presently disclosed subject matter.

DETAILED DESCRIPTION

In the drawings and descriptions set forth, identical reference numerals indicate those components that are common to different embodiments or configurations.

Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "reconfiguring", "calculating", "informing", "assessing", "performing", "migrating" or the like, include action and/or processes of a computer that manipulate and/or transform data into other data, said data represented as physical quantities, e.g. such as electronic quantities, and/or said data representing the physical objects. The term "computer" should be expansively construed to cover any kind of electronic device with data processing capabilities, including, by way of non-limiting example, a personal computer, a server, a computing system, a communication device, a processor (e.g. digital signal processor (DSP), a microcontroller, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), any other electronic computing device, and or any combination thereof.

The operations in accordance with the teachings herein may be performed by a computer specially constructed for the desired purposes or by a general purpose computer specially configured for the desired purpose by a computer program stored in a computer readable storage medium.

As used herein, the phrase "for example," "such as", "for instance" and variants thereof describe non-limiting embodiments of the presently disclosed subject matter. Reference in the specification to "one case", "some cases", "other cases" or variants thereof means that a particular feature, structure or characteristic described in connection with the embodiment(s) is included in at least one embodiment of the presently disclosed subject matter. Thus the appearance of the phrase "one case", "some cases", "other cases" or variants thereof does not necessarily refer to the same embodiments).

It is appreciated that certain features of the presently disclosed subject matter, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the presently disclosed subject matter, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination.

In embodiments of the presently disclosed subject matter, fewer, more and/or different stages than those shown in Figs. 3-4 and 6-7 may be executed. In embodiments of the presently disclosed subject matter one or more stages illustrated in Figs. 3-4 and 6-7 may be executed in a different order and/or one or more groups of stages may be executed simultaneously. Figs. 1, 2 and S illustrate a general schematic of the system architecture in accordance with an embodiment of the presently disclosed subject matter. Each module in Figs. 1, 2 and 5 can be made up of any combination of software, hardware and/or firmware that performs the functions as defined and explained herein. The modules in Figs. 1, 2 and S may be centralized in one location or dispersed over more than one location. In other embodiments of the presently disclosed subject matter, the system may comprise fewer, more, and/or different modules than those shown in Figs. 1 , 2 and 5. Bearing this in mind, attention is drawn to Figure 1, which schematically illustrates a top-level architecture of a Distributed Storage System including an Infrastructure Layer, according to the presently disclosed subject matter. According to examples of the presently disclosed subject matter, Distributed Storage System (DSS) 200 can comprise one or more of the following layers: an Infrastructure Layer 201, a Unified Distributed Storage Platform (UDSP) layer 202, and an API/framework layer 203.

According to some examples of the presently disclosed subject matter, infrastructure layer 201 can include one or more interconnected computer nodes 205 (e.g. any type of computer including, inter alia, one or more processing resources such as one or more processing units, one or more memory resources such as a memory, and one or more network interfaces), and in some cases two or more interconnected computer nodes 205, on which a more detailed description is provided herein, inter alia with reference to Figure 5. The interconnected computer nodes 205 (including their processing resources and/or their memory and/or their network interfaces) of the infrastructure layer 201 are storage-related resources used by DSS 200. Infrastructure layer 201 can further include one or more of the following additional storage-related resources: (a) data storage resources (e.g. data storage device 204, RAID (redundant array of independent disks) 206, DAS (direct attached storage) 208, JBOD (just a bunch of drives) 210, network storage appliance 207 (e.g. SAN, NAS, etc.), SSD 213, etc.); (b) cache resources 212 such as memory resources (e.g. RAM, DRAM, etc.), volatile and/or non-volatile, and/or a data storage resources (e.g. SSD 213) that in some cases can be used additionally or alternatively as a cache resource), etc.; (c) network resources 214; and (d) additional resources providing further functionality to the DSS 200 and/or enhance its performance (such as compression accelerator, encryption accelerator 209, Host Bus adapter (HBA) enabling communication with SAN resources, etc.).

In some cases, the resources can include more than one of a same type of device, and/or more than one of a different type of device. A more detailed description of some of the resources will follow herein.

According to some examples of the presently disclosed subject matter, the computer nodes 205 can be interconnected by a network (e.g. a general-purpose network).

In some cases, one or more of the resources of the infrastructure layer 201 can be connected to one or more computer nodes 205 directly. In some cases, one or more of the resources of the infrastructure layer 201 can be comprised within a computer node 205 and form a part thereof. In some cases, one or more of the resources of the infrastructure layer 201 can be connected (e.g. by a logical connection such as iSCSI 222, etc.) to one or more of the computer nodes 205 by a network (e.g. a general-purpose network).

Optionally, the network can be a general-purpose network. Optionally, the network can include a WAN. Optionally, the WAN can be a global WAN such as, for example, the Internet. Optionally, the network resources can interconnect using an IP network infrastructure. Optionally, the network can be a Storage Area Network (SAN). Optionally, the network can include storage virtualization. Optionally, the network can include a LAN. Optionally, the network infrastructure can include Ethernet, Infiniband, FC (Fibre Channel) 217, FCoE (Fibre Channel over Ethernet), etc., or any combination of two or more network infrastructures. Optionally, the network can be any type of network known in the art, including a general purpose network and/or a storage network. Optionally, the network can be any network suitable for applying an objective-based management system for allocating and managing resources within the network, as further detailed herein. Optionally, the network can be a combination of any two or more network types (including, inter alia, the network types disclosed herein).

According to some examples of the presently disclosed subject matter, at least one resource of the infrastructure layer 201 (including, inter alia, the computer nodes 205, the data storage resources, the cache resources, the network resources, additional resources connected to a computer node 205, or any other resources) can be an off-the-shelf, commodity, not purposely-built resource connected to the network and/or to one or more computer nodes 205. It is to be noted that such a resource can be interconnected as detailed herein, irrespective of the resource characteristics such as, for example, manufacturer, size, computing power, capacity, etc. Thus, any resource (including, inter alia, the computer nodes 205), irrespective of its manufacturer, which can communicate with a computer node 205, can be connected to the infrastructure layer 201 and utilized by the DSS 200 as further detailed herein. In some cases any number of resources (including, inter alia, the computer nodes 205) can be connected to the network and/or to one or more computer nodes 205 and utilized by the DSS 200, thus enabling scalability of the DSS 200. In some cases, any number of computer nodes 205 can be connected to the network and any number of resources can be connected to one or more computer nodes 205 and utilized by the DSS 200, thus enabling scalability of the DSS 200. It is to be noted that a more detailed explanation about the process of connecting new resources (including, inter alia, the computer nodes 205) to the DSS 200 is further detailed herein, inter alia with respect to Fig. 5. In some cases, the infrastructure layer 201 or part thereof can be distributed over a plurality of geographically distinct Storage Locations. In addition, in some cases, the resources allocated to a first customer in one or more of the Storage Locations can be over utilized, whereas the resources allocated to a second customer in one or more other Storage Locations (or in the same Storage Location, that can be shared by more than one customer), can be underutilized. As further detailed herein, e.g. with respect to Figs. 6-7, in such cases, the DSS 200 (e.g. using an objective based configuration module 340 operatively coupled to the infrastructure layer 201, as detailed herein) can be reconfigured so that at least one resource of the infrastructure layer 201 is reallocated, optionally physically moved, from a first Storage Location to a second Storage Location, or from a first portion (e.g. a first rack) of a given Storage Location to a second portion (e.g. a second rack) of the same Storage Location. It is to be noted that in some cases, the determination whether a Storage Location is under or over utilized is made with respect to Service Level Specifications provided by the corresponding customers, as detailed herein with respect to Fig. 6.

In some cases, each Storage Location is associated with, and controlled by, a single corresponding customer. It is to be noted that control can include any type of ownership (the customer owns or rents the Storage Location), or any other right to control access to the Storage Location. In some cases, a single customer can control a plurality of Storage Locations.

It is to be noted that in some cases, at least a first Storage Location is associated with, and controlled by, a first customer and at least a second Storage Location is associated with, and controlled by, a second customer, different than the first customer.

It is to be further noted that in some cases at least two storage locations of the plurality of storage locations are associated with the same customer.

Turning to the UDSP layer 202, according to some examples of the presently disclosed subject matter, it can include one or more UDSP agents 220 that can be installed on (or otherwise associated with or comprised within) one or more of the computer nodes 205. In some cases, a UDSP agent 220 can be installed on (or otherwise associated with) each of the computer nodes 205. In some cases, a UDSP agent 220 can be additionally installed on (or otherwise associated with) one or more of gateway resources 216 (that can act, inter alia, as protocol converters as further detailed herein), and in some cases, on each of the gateway resources 216. In some cases, a UDSP agent 220 can be additionally installed on (or otherwise associated with) one or more of the client servers 218 (e.g. servers and/or other devices connected to the DSS 200 as clients), and in some cases, on each of the client servers 218. It is to be noted that in some cases, client servers 218 can interact with DSS 200 directly without a need for any gateway resources 216 that are optional. It is to be further noted that in some cases there can be a difference in the UDSP agent 220 (e.g. a difference in its functionality and/or its capability, etc.) according to its installation location or its association (e.g. there can be a difference between a UDSP agent 220 installed on, or otherwise associated with, a computer node 205, a UDSP agent 220 installed on, or otherwise associated with, a gateway resources 216, a UDSP agent 220 installed on, or otherwise associated with, a client server 218, etc.).

It is to be noted that a detailed description of the UDSP agents 220 is provided herein, inter alia with respect to Fig. S. Having said that, it is to be noted that according to some examples of the presently disclosed subject matter, UDSP agents 220 can be configured to control and manage various operations of DSS 200 (including, inter alia, automatically allocating and managing the resources of the Infrastructure Layer 201, handling data-path operations, etc.). In some cases, UDSP layer 202 can include UDSP 225 which includes the management system for DSS 200. Optionally, management system processing can be implemented through one or more UDSP agents 220 installed on the computer nodes 205 in Infrastructure Layer 201, or through one or more UDSP agents 220 installed on a gateway resource 216 or on a client server 218 with access to DSS 200 (e.g. directly and/or through gateway resources 216), or any combination thereof.

Management system can enable a user to perform various management tasks (including, inter alia monitoring and reporting tasks) relating to DSS 200, such as, creating new logical storage entities (such as Logical Units, Object Stores, file system instances, etc.) that can be associated with Service Level Specifications (SLSs) (in some cases, each logical storage entity is associated with a single SLS), updating logical storage entities, granting access permissions of logical storage entities to gateway resources 216 and/or to client servers 218, creating snapshots, creating backups, failover to remote site, fallback to primary site, monitoring dynamic behavior of DSS 200, monitoring SLSs compliance, generation of various (e.g. pre-defined and/or user-defined, etc.) reports (e.g. performance reports, resource availability reports, inventory reports, relationship reports indicative of relationships between computer nodes 205 and other resources, trend reports and forecast reports of various parameters including Key Performance Indicators, etc.) referring to different scopes of the DSS 200 (e.g. in the resolution of the entire DSS 200, certain sites, certain types of use such as for a certain SLS, certain resources, etc.), managing various alerts provided by DSS 200 (e.g. alerts of failed hardware, etc.), etc. It is to be noted that the above management tasks are provided as non-limiting examples only. It is to be noted that in some cases, the logical storage entities can be created automatically by DSS 200 according to the SLS, as further detailed herein. It is to be noted that each of the logical storage entities can be associated with one or more data storage resources.

It is to be noted that throughout the specification, when reference is made to a user, this can refer to a human operator such as a system administrator, or to any type of auxiliary entity. An auxiliary entity can refer for example to an external application such as an external management system, including an auxiliary entity mat does not require any human intervention, etc.

In some cases, management system can enable a user to provide DSS 200 with user-defined storage requirements defining a service level specification (SLS) specifying various requirements that the user requires the DSS 200 to meet. In some cases, the SLS can be associated with a logical storage entity. Optionally, the SLS can include information such as, for example, specifications of one or more geographical locations where the data is to be stored and/or handled; a local protection level defining availability, retention, recovery parameters (e.g. RPO - Recovery Point Objective, RTO - Recovery Time Objective); a backup retention policy defining for how long information should be retained; a remote protection level for disaster recovery (DR) defining one or more remote geographical locations in order to achieve specified availability, retention and recovery goals under various disaster scenarios; local and/or remote replication policy; performance levels (optionally committed) defined using metrics such as IOPS (input/output operations per second), response time, and throughput; encryption requirements; de-duplication requirements; compression requirements; a storage method (physical capacity, thin capacity/provisioning), etc.

In some cases, management system can enable management (including creation, update and deletion) of various Service Level Groups (SLGs). An SLG is a template SLS that can be shared among multiple logical storage entities. An SLG can be a partial SLS (that requires augmentation) and/or contain settings that can be overridden. Thus, for example, an SLG can define various recovery parameters only that can be inherited by various SLSs, each of which can add and/or override SLS parameters.

According to some examples of the presently disclosed subject matter, UDSP 225 can include an automatic management system for allocating resources and managing the resources in the DSS 200. Optionally, the automatic management system is an Objective- Based Management System (OBMS) 100 that can be configured to allocate and manage the resources in the network, inter alia based on any one of, or any combination of, user- defined requirements defined by one or more service level specifications (SLSs), data of various parameters relating to computer nodes 205 and/or to resources connected thereto, data of various parameters that refer to the DSS 200 or parts thereof (e.g. maximal allowed site-level over-commit, maximal allowed overall over-commit, various security parameters, etc.) and data of various parameters that refer to the dynamic behavior of the DSS 200 and the environment (e.g. the client servers 218, gateway resources 216, etc.), as further detailed herein, inter alia with respect to Fig. 2 and Fig. 5. Optionally, OBMS 100 processing can be implemented through one or more UDSP agents 220 installed on one or more of the computer nodes 205 in Infrastructure Layer 201, or through one or more UDSP agents 220 installed on a gateway resource 216 or on a client server 218 with access to DSS 200 (e.g. directly or through gateway resources 216), or any combination thereof.

According to some examples of the presently disclosed subject matter, API/framework layer 203 includes a plug-in layer which facilitates addition of software extensions (plug-ins) to DSS 200. Such plug-ins can be utilized for example for applying processes to the data, introducing new functionality and features to DSS 200, interfacing DSS 200 with specific applications and implementing application-specific tasks (e.g. storage related tasks, etc.), implementing various resource specific drivers, introducing new SLS parameters and/or parameter group/s (e.g. in relation to a plug-in functionality and/or goals), implementing management functionality, etc. In some cases, the plug-in layer can also include drivers associated with various hardware components (e.g. encryption cards, etc.).

In some cases the plug-ins can be deployed on one or more UDSP agents 220. In some cases, the plug-ins can be deployed on one or more UDSP agents 220 for example, according to the plug-in specifications (e.g. a software encryption plug-in can be installed on any UDSP agent 220), according to various resources connected to a computer node 205 and/or to a gateway resource 216 and/or to a client server 218 on which a UDSP agent 220 is installed (e.g. a hardware accelerator plug-in can be automatically deployed on each UDSP agent 220 associated with a computer node 205 that is associated with such a hardware accelerator), according to a decision of the automatic management system (e.g. OBMS 100), or according to a selection of a system administrator, etc. In some cases the plug-ins can be deployed automatically, e.g. by the automatic management system (e.g. OBMS 100) and/or by the computer nodes 205. Optionally, the software extensions can include data processing plug-ins 226 such as, for example, a data deduplication plug-in enabling for example deduplication of data stored on DSS 200, a data encryption plug-in enabling for example encryption/decryption of data stored on DSS 200, a data compression plug-in enabling for example compression/decompression of data stored on DSS 200, etc. Optionally, the software extensions can include storage feature plug-ins 228 such as, for example, a content indexing plug-in enabling for example indexing of data stored on DSS 200, a snapshot management plug-in enabling management of snapshots of data stored on DSS 200, a tiering management plug-in enabling for example tiering of data stored on DSS 200, a disaster recovery plug-in enabling for example management of process, policies and procedures related to disaster recovery, a continuous data protection plug-in enabling for example management of continuous or real time backup of data stored on DSS 200, etc. Optionally, the software extensions can include application plug-ins 230 such as, for example a database plug-in enabling for example accelerating query processing, a management plug-in 233 enabling for example performance of various DSS 200 management tasks and other interactions with users, client servers 218, and other entities connected to DSS 200, and other suitable application plug-ins.

As indicated herein, in some cases, a plug-in can introduce new SLS parameters and/or parameter group(s) (e.g. in relation to a plug-in functionality and/or goals). In such cases, according to the plug-in functionality, respective SLS parameters and/or parameter group(s) can be introduced to DSS 200. Such introduced SLS parameters can be used in order to set plug-in related requirements, e.g. by a user and/or automatically by the automatic management system (e.g. OBMS 100), etc.

In some cases, the software extensions can be stored on one of the computer nodes 205 or distributed on more than one computer node 205. In some cases, the software extensions can be stored on one or more data storage resources connected to one or more computer nodes 205. In some cases, the software extensions can be stored in a virtual software extensions library that can be shared by the UDSP agents 220.

In some cases, the software extensions can be managed, automatically and/or manually (e.g. by a system administrator). Such management can sometimes be performed by utilizing the management plug-in 233. In such cases, management plug-in 233 can enable addition/removal of software extension to/from DSS 200, addition/removal of various software extensions to/from one or more UDSP agents 220, etc.

Following the description of the top-level architecture of DSS 200, a detailed description of a DSS 200 configuration process that can be performed by Objective Based Management System (OBMS) 100 is hereby provided. For this purpose, attention is now drawn to Figure 2, illustrating a simplified, exemplary system for configuring a Distributed Storage System 200, according to the presently disclosed subject matter. For this purpose, OBMS 100 can be configured, inter alia, to automatically allocate and manage resources in the Infrastructure Layer 201. OBMS 100 can include an Input Module 102, one or more Processors 104, and an Output Module 106.

In some cases, input Module 102 can be configured to receive input data. Such input data can include, inter alia, any one of, or any combination of, user-defined storage requirements defined by one or more service level specifications (SLSs), definitions of one or more logical storage entities, data of various parameters relating to computer nodes 205 and/or to resources connected thereto (including storage-related resources, also referred to as storage-related resources data), data of various parameters that refer to the DSS 200 or parts thereof (e.g. maximal allowed site-level over-commit, maximal allowed overall over-commit, various security parameters, etc.), data of various parameters relating to dynamic behavior (dynamic behavior parameter data) of the DSS 200 and the environment (e.g. the client servers 218, gateway resources 216, etc.), etc.

In some cases, user-defined requirements can define one or more service level specifications (SLSs) specifying various requirements that one or more users require the DSS 200 and/or one or more logical storage entities to meet.

In some cases, the data of various parameters relating to dynamic behavior of the DSS 200 and the environment (dynamic behavior parameter data) can include various parameters data indicative of the current state of one or more of the DSS 200 components (including the computer nodes 205 and the resources connected thereto). Such data can include data of presence and/or loads and/or availability and/or faults and/or capabilities and/or response time(s) and/or connectivity and/or cost(s) (e.g. costs of network links, different types of data storage resources) and/or any other data relating to one or more of the resources, including data relating to one or more computer nodes 205, one or more gateway resources 216, one or more client servers 218, etc. In some cases, such data can include, inter alia, various statistical data. In some cases, the data of various parameters relating to computer nodes 205 and/or to resources connected thereto (including storage-related resources, also referred to as storage-related resources data) can include data of various parameters indicative of the resources of the DSS 200, including hardware resources, including storage-related resources, such as, for example:

a. parameters relating to a data storage resource, (e.g. for each of the its hard drives):

1. Hard drive category parameters (e.g. hard drive size, interface (e.g. SAS, SATA, FC, Ultra-SCSI, etc.), cache size, special features (e.g. on-drive encryption, etc.), etc.);

2. Hard drive performance parameters (e.g. response time, average latency, random seek time, data transfer rate, etc.);

3. Hard drive power consumption;

4. Hard drive reliability parameters (e.g. Mean Time Between Failure (MTBF), Annual Failure Rate (AFR), etc.).

b. computer node 205 parameters:

1. Number of CPUs and cores per CPU.

2. Performance parameters of each CPU and/or core, such as frequency, L2 and L3 cache sizes.

3. Architecture (e.g. does the CPU and/or core support 64-bit computing, is it little- endian or big-endian)

4. Support for certain instruction sets (e.g. AES-NI, a new instruction set for speeding up AES encryption).

5. Number of hard drive slots available;

6. Available storage interfaces (SATA, SAS, etc.);

7. Maximal amount of memory;

8. Supported memory configurations;

c. Cache resource parameters:

1. Cache resource type (e.g. DRAM, SSD), size and performance.

2. Is the cached storage space local or remote.

3. NUMA parameters.

d. Gateway resource parameters:

1. Number of CPUs and cores per CPU.

2. Performance parameters of each CPU and/or core, such as frequency, L2 and L3 cache sizes. 3. Aichitectuie (e.g. does the CPU and/or core support 64-bit computing, is it little- endian or big-endian)

S. Number of hard drive slots available in the enclosure;

6. Available storage interfaces (SAT A, SAS, etc.);

7. Maximal amount of memory;

8. Supported memory configurations;

9. Networking parameters relating to gateway (number of ports, speed and type of each port, etc.)

e. Network resource parameters:

1. Switching and routing capacities;

2. Network types;

3. Security parameters.

It is to be noted that these are mere examples and additional and/or alternative various parameters can be used.

In some cases, data relating to dynamic behavior of the DSS 200 and the environment (dynamic behavior parameter data) can include various parameters indicative of the resources of the DSS 200, including hardware resources such as, for example: a. Parameters relating to a data storage resource (e.g. for each of its hard drives):

1. Hard drive free space.

2. S.M.A.R.T. parameters of the hard drive.

3. The power state of the hard drive (turned off, in spin-up phase, ready, etc.)

4. Recent and current load on hard drive.

S. Existing allocations and reservations.

b. Computer node 205 parameters:

1. Recent and current load statistics for each core.

2. Existing allocations and reservations.

3. Current amount of memory.

c. Cache resource parameters:

1. Available size.

2. Occupancy level of the cache.

3. Recent and current swapping/page fault statistics.

4. Existing allocations and reservations. d. Gateway resource parameters:

1. Recent and current network connections statistics.

2. Recent and current node load statistics.

3. Recent and current latency statistics.

4. Recent and current routing cost statistics (for commands routed by a gateway into a DSS).

S. Existing allocations and reservations.

e. Network resource parameters:

1. Recent and current load of network segments.

2. Recent and current reliability and quality parameters of network segments.

3. Existing allocations and reservations.

In some cases, input Module 102 can be configured to transfer the input data to one or more Processors 104. As indicated, OBMS 100 processing can be implemented through one or more UDSP agents 220 (e.g. while utilizing Objective based configuration module 340 as further detailed herein, inter alia with reference to Fig. 5), e.g. through UDSP agents 220 installed on one or more of the computer nodes 205 in Infrastructure Layer 201, or through UDSP agents 220 installed on one or more gateway resources 216, or through UDSP agents 220 installed on one or more client servers 218 with access to DSS 200 (e.g. directly or through gateway resources 216), or any combination thereof. In such cases, the one or more processors 104 can be one or more processing resources (e.g. processing units) associated with such UDSP agents 220 (e.g. if the processing is implemented through a UDSP agent 220 installed on a computer node 205, then processor can be the processing unit of that computer node 205, etc.). It is to be noted that more than one processing resource (e.g. processing unit) can be used for example in case of parallel and/or distributed processing.

The one or more Processors 104 can be configured to receive the input data from Input Module 102 and to perform an optimization process based on the input data for determining configuration requirements that meet all of the user-defined storage requirements (e.g. SLSs) provided by the one or more users of DSS 200, inter alia with respect to entities that they affect (such as logical storage entities associated with such SLSs). A more detailed description of the optimization process and of the determined configuration requirements is provided herein, inter alia with respect to Fig. 3. The configuration requirements can be transferred to Output Module 106 which, in some cases, can determine if the current DSS 200 resources are sufficient to meet the determined configuration requirements. Accordingly, Output Module 106 can be configured to perform solution-driven actions, which include allocation, reservation, commit or over-commit (e.g. virtually allocating more resources than the actual resources available in the infrastructure layer 201) of the resources if the configuration requirements can be met by the system, or issuing improvement recommendations to be acted upon by the user which may include adding resources and/or adding plug-ins and/or any other recommendations for enabling the system to meet the configuration requirements. Such improvement recommendations can include, for example, recommendation to add one or more resources, to add or upgrade one or more plug-ins, to span the infrastructure across additional and/or different locations (local and/or remote), etc.

It is to be noted that in some cases the configuration process, or parts thereof, can be initiated when deploying the DSS 200 and/or one or more logical storage entities for the first time, and/or following one or more changes (e.g. pre-defined changes) applied to DSS 200 and/or to one or more logical storage entities (e.g. addition/removal of a resource such as computer nodes 205, cache resources, data storage resources, network resources, plug-ins or any other resource to DSS 200; a change in one or more user-defined storage requirements; etc.), and/or according to the dynamic behavior of DSS 200 (as further detailed below, inter alia with respect to Fig. S), etc. Additionally or alternatively, the configuration process, or parts thereof, can be initiated in a semi-continuous manner (e.g. at pre-determined time intervals, etc.). Additionally or alternatively, the configuration process, or parts thereof, can be performed continuously.

It is to be further noted that, with reference to Fig. 2, some of the blocks can be integrated into a consolidated block or can be broken down to a few blocks and/or other blocks may be added. Furthermore, in some cases, the blocks can be performed in a different order than described herein. It should be also be noted that whilst the flow diagrams are described also with reference to system elements that realizes mem, this is by no means binding, and the blocks can be performed by elements other than those described herein.

Attention is now drawn to Figure 3, which schematically illustrates a simplified and exemplary flow diagram of an optimization process performed by the objective-based storage management system, according to the presently disclosed subject matter. In some cases, one or more Processors 104 can be configured to receive input data (e.g. from input module 102) and, in some cases, convert the received input data into a format suitable for processing by an optimization engine (e.g. into an optimization problem representation) (block 112).

An optimization engine associated with one or more Processors 104 can be configured to perform an optimization process, based on the original and/or converted input data to arrive at a required configuration which satisfies the requirements as defined by the input data (as further detailed herein, inter alia with respect to Fig. 2) (block 114). It is to be noted that in some cases, the optimization process can be instructed to return the first valid solution that it finds, whereas in other cases, the optimization process can be instructed to search for the optimal solution out of a set of calculated valid solutions. Optionally, the optimization techniques used in the optimization process can include any one of, or any combination of, linear programming, simulated annealing, genetic algorithms, or any other suitable optimization technique known in the art. Optionally, the optimization technique can utilize heuristics and/or approximations. Optionally, optimization decisions can be taken based on partial and/or not up-to-date information.

In some cases, the output of the optimization engine can be converted by the one or more Processors 104 from an optimization solution representation to a configuration requirements representation (block 116).

In some cases, the configuration requirements are output by the one or more Processors 104 for example as any one of, or any combination of, the following: location requirements (e.g. availability of at least one additional site, availability of a certain amount of storage space in the additional site/s, maximal latency between sites, minimal geographical distance between sites for example for disaster recovery purposes, etc.), cache resources requirements (e.g. required cache size, required cache type, required cache locations, required cache performance parameters, etc.), gateway resources requirements (e.g. required Fibre Channel bandwidth, required processing performance parameters, etc.), network resources requirements (e.g. required network bandwidth, required network type, etc.), computing resources requirements (e.g. computer nodes processing performance parameters, computer nodes number of CPU cores, etc.), data storage resources requirements (e.g. required storage space, required storage type, etc.), additional resource requirements (e.g. required compression performance, required encryption performance, etc.), plug-in requirements (e.g. required database plug-in, etc.), environment requirements (e.g. required physical security level, etc.), etc. (block 117). It is to be noted that, with reference to Fig. 3, some of the blocks can be integrated into a consolidated block or can be broken down to a few blocks and/or other blocks may be added. Furthermore, in some cases, the blocks can be performed in a different order than described herein. It should be also be noted that whilst the flow diagrams are described also with reference to the system elements that realizes them, this is by no means binding, and the blocks can be performed by elements other than those described herein.

Turning to Figure 4, there is shown a schematic illustration of a simplified flow diagram of an exemplary operational algorithm of a configuration process performed by the objective-based management system, according to the presently disclosed subject matter. In some cases, as indicated above, Input Module 102 can receive the input data and transfer the data to the one or more Processors 104 (block 110). As further indicated above, the one or more Processors 104 can, in some cases, convert the input data into a format suitable for processing by an optimization engine (e.g. into an optimization problem representation) (block 112).

An optimization engine associated with one or more Processors 104 can be configured to perform an optimization process, based on the original and/or converted input data to arrive at a required configuration which satisfies the requirements as defined by the input data (as further detailed herein, inter alia with respect to Fig. 2) (block 114). In some cases, the output of the optimization engine can be converted by the one or more Processors 104 from an optimization solution representation to a configuration requirements representation (block 116).

In some cases, output module can compare the required configuration with the actual data of the DSS 200 resources (e.g. the computer nodes 205, the storage-related resources, etc.) and/or environment for determination if the DSS 200 can meet the required configuration (block 118). It is to be noted that in some cases the actual DSS 200 resources can refer to those parts of the DSS 200 resources that are currently available. If the actual DSS 200 resources and/or environment can meet the required configuration, OBMS 100 can be configured to reserve and/or allocate the resources according to the required configuration (block 126). In some cases, OBMS 100 can be configured to set up the DSS 200 configuration and/or perform any induced deployment actions (block 128). In some cases, the set-up and/or deployment action can include, inter alia, automatically creating new logical storage entities (such as Logical Units, Object Stores, file system instances, etc.) associated with SLSs. In some cases, each logical storage entity is associated with a single SLS.

As part of setting-up the storage configuration and/or performing any induced deployment actions, relevant set-up and/or deployment action requests can be sent to the UDSP agents 205; in some cases such requests are sent to the UDSP agents 205 associated with the storage-related resources relevant for the requested set-up and/or deployment action. In some cases, the UDSP agents 205 that receive such requests can be configured to update a data repository associated therewith about the set-up and/or deployment requested to be used by DSS 200 as further detailed below, inter alia with respect to Fig.

5. In some cases, following the deployment, the process of deploying the DSS 200 ends successfully (block 130).

If the actual DSS 200 resources and/or environment cannot meet the required configuration, OBMS 100 can be configured to send a message to the user (e.g. a system administrator) providing the user with a failure notification and/or recommendations as to corrective actions to be taken by the user for allowing implementation of the required infrastructure configuration (block 120). Optionally, the action can include adding infrastructure resources which will allow successful calculation of a configuration. Optionally, the action can include adding relevant plug-ins. Optionally, the action can involve spanning infrastructure resources across additional and/or alternative locations. It is to be noted that the recommendations disclosed herein are mere examples, and other recommendations can be additionally or alternatively issued to the user. In some cases, OBMS 100 can be configured to make a decision as to whether the required infrastructure configuration should be re-evaluated, optionally after some interval/delay, or not (block 122). If yes, OBMS 100 can be configured to return to block 112. Optionally, the Output Module 106 automatically goes to 112, optionally after some interval/delay, if set to a continuous mode. Optionally, the decision to retry or not is based on user input of a retry instruction. If no, the process of deploying the DSS 200 failed. In some cases, OBMS 100 can be configured to report failures.

It is to be noted that, with reference to Fig. 4, some of the blocks can be integrated into a consolidated block or can be broken down to a few blocks and/or other blocks may be added. Furthermore, in some cases, the blocks can be performed in a different order than described herein. It should be also be noted that whilst the flow diagrams are described also with reference to the system elements that realizes them, this is by no means binding, and the blocks can be performed by elements other than those described herein. Attention is now drawn to Figure 5, in which a block diagram schematically illustrating an exemplary computer node connected to the Distributed Storage System, according to certain examples of the presently disclosed subject matter, is shown.

According to some examples of the presently disclosed subject matter, Computer node 205 can comprise one or more processing resources 310. The one or more processing resources 310 can be a processing unit, a microprocessor, a microcontroller or any other computing device or module, including multiple and/or parallel and/or distributed processing units, which are adapted to independently or cooperatively process data for controlling relevant computer node 205 resources and/or storage-related resources connected to computer node 205 and for enabling operations related to computer node 205 resources and/or to storage-related resources connected to computer node 205.

Computer node 205 can further comprise one or more network interfaces 320 (e.g. a network interface card, or any other suitable device) for enabling computer node 205 to communicate, inter alia with other computer nodes and/or other resources connected to DSS 200.

According to some examples of the presently disclosed subject matter, computer node 205 can be associated with a UDSP data repository 330, configured to store data, including inter alia data of various user-defined storage requirements defining SLSs, and/or data of a logical storage entities associated with each SLS, and/or data of various parameters relating to computer nodes 205 and/or to storage-related resources connected thereto and/or data relating to various parameters that refer to the DSS 200 or parts thereof and/or data relating to dynamic behavior of the DSS 200 and the environment (e.g. the client servers 218, gateway resources 216, etc.), and/or data relating to the DSS 200 set-up and/or deployment and/or any other data. In some cases, UDSP data repository 330 can be further configured to enable retrieval, update and deletion of the stored data. It is to be noted that in some cases, UDSP data repository 330 can be located locally on computer node 205, on a storage-related resource connected to computer node 205 (e.g. a data storage resource, a cache resource, or any other suitable resource), on a client server 218, on a gateway resource 216, or any other suitable location. In some cases, UDSP data repository 330 can be distributed between two or more locations. In some cases, UDSP data repository 330 can be additionally or alternatively stored on one or more logical storage entities within the DSS 200. In some cases, additionally or alternatively, UDSP data repository 330 can be shared between multiple computer nodes. According to some examples of the presently disclosed subject matter, computer node 205 can further comprise a UDSP agent 220 that can be executed, for example, by the one or more processing resources 310. As indicated above, UDSP agents 220 can be configured, inter alia, to control and manage various operations of computer node 205 and/or DSS 200. UDSP agent 220 can comprise one or more of the following modules: an objective based configuration module 340 and a conformity determination module 350.

According to some examples of the presently disclosed subject matter, Objective based configuration (OBMC) module 340 can be configured to configure and/or reconfigure DSS 200 as detailed inter alia with respect to Figs. 2-4 and 7.

Conformity determination module 350 can be configured to calculate conformity indicative data indicative of conformity between (1) storage-related resources parameters data relating to one or more (and in some cases relating to each) storage-related resources connected to respective interconnected computer nodes and at least partially allocated to a given logical storage entity and (2) at least one Service Level Specification (SLS) indicative of user-defined storage requirements referring to the given logical storage entity, and to inform the OBCM 340 accordingly, as further detailed herein, inter alia with respect to Fig. 6. As a result of the calculation, for each storage-related resource for which the calculation has been performed, conformity indicative data, indicative of conformity between its parameters data and one or more SLSs associated with a logical storage entity to which the storage-related resource has been at least partially allocated to, is calculated.

It is to be noted that the one or more processing resources 310 can be configured to execute the UDSP agent 220 and any of the modules comprised therein.

It is to be noted that according to some examples of the presently disclosed subject matter, some or all of the UDSP agent 220 modules can be combined and provided as a single module, or, by way of example, at least one of them can be realized in a form of two or more modules. It is to be further noted that in some cases UDSP agents 220 can be additionally or alternatively installed on one or more gateway resources 216 and/or client servers 218, etc. In such cases, partial or modified versions of UDSP agents 220 can be installed on and/or used by the one or more gateway resource 216 and/or client server 218, etc.

Turning to Fig. 6, there is shown a flowchart illustrating a sequence of operations carried out for calculating conformity indicative data, according to certain examples of the presently disclosed subject matter. According to some examples of the presently disclosed subject matter, conformity determination module 350 can perform a conformity indicative data calculation process 600. In some cases, UDSP agents 220 associated with one or more computer nodes 205 (e.g. dedicated computer nodes) can be responsible for performing the conformity indicative data calculation process 600, e.g. while utilizing conformity determination module 350. For this purpose, in some cases, conformity determination module 350 can receive (1) storage-related resources parameters data relating to one or more (and in some cases relating to each) storage-related resources connected to respective interconnected computer nodes and at least partially allocated to a given logical storage entity and (2) at least one Service Level Specification (SLS) indicative of user-defined storage requirements referring to the given logical storage entity (block 610).

Using the received data, conformity determination module 350 can calculate conformity indicative data, indicative of conformity between the received storage-related resources parameters data and the received one or more SLSs (block 620).

Such calculation can be performed, for example, by comparing the received parameters data with the received SLS requirements and in case there is a breach of a requirement, or optionally nearing such a breach (e.g. in accordance with pre-defined thresholds), the conformity indicative data calculated for the corresponding storage-related resource can be indicative of non-conformance with the SLS requirement, whereas, if the SLS requirement is met, and optionally no breach is nearing, the conformity indicative data can be indicative of conformance with the SLS requirement. In some cases a level of conformity can be determined, e.g. as a ratio between the actual utilization of the resources and an allowed utilization in accordance with the SLS requirement.

As a result of the calculation, for each storage-related resource for which the calculation has been performed, conformity indicative data, indicative of conformity (or lack thereof) between its parameters data and one or more SLSs associated with a logical storage entity to which the storage-related resource has been at least partially allocated to, is calculated. The conformity indicative data can be, for example, a Boolean value, a numeric value, a percentage value, or any other type of value, e.g. depending on the type of parameter and/or the type of a corresponding user-defined storage requirement indicated by the corresponding SLS.

In some cases, conformity determination module 350 can be further configured to inform OBCM 340 of the calculated conformity indicative data (block 630). It is to be noted that, with reference to Fig. 6, some of the blocks can be integrated into a consolidated block or can be broken down to a few blocks and/or other blocks may be added. It should be also noted that whilst the flow diagram is described also with reference to the system elements that realizes them, this is by no means binding, and the blocks (or any subset thereof) can be performed by elements other than those described herein.

Attention is now drawn to Fig. 7, showing a flowchart illustrating a sequence of operations carried out for reconfiguring the distributed storage system, according to certain examples of the presently disclosed subject matter.

According to some examples of the presently disclosed subject matter, objective based configuration module 340 can perform a reconfiguration process 700. In some cases, UDSP agents 220 associated with one or more computer nodes 205 (e.g. dedicated computer nodes) can be responsible for performing the reconfiguration process 700, e.g. while utilizing objective based configuration module 340. For this purpose, in some cases, Objective based configuration module 340 can utilize at least the conformity indicative data received with respect to storage-related resources placed at the at least one Storage Location for assessing conformity status for at least one Storage Location of the plurality of Storage Locations, the conformity status indicative of over-utilized, normal or under- utilized status of one or more (and in some cases - all) storage-related resources placed at the at least one Storage Location (block 710). As a result, for each Storage Location for which the assessment has been performed, a conformity status is calculated indicating whether the storage-related resources located at such Storage Location are over-utilized, under-utilized, or normal (i.e. not over-utilized and not under-utilized).

In some cases, for example when at least one Storage Location is over-utilized, objective based configuration module 340 can be further configured to activate the Objective Based Management System (OBMS) 100 for performing a DSS 200 configuration process, as detailed above, inter alia with respect to Figs. 2-4, while utilizing also said assessment results, so that to re-allocate one or more storage-related resources from one or more Storage Locations with under-utilized status to a Storage Location with over-utilized status (block 720).

It is to be noted that in some cases the DSS 200 configuration process can include a requirement that the costs (e.g. in terms of money, such as shipping costs, technician time costs, configuration costs, data migration costs, etc.) of the reallocation are minimal or below a certain threshold, and/or a requirement that the time for completion of the reallocation is minimal or below a certain threshold. In some cases, the time-related requirement is given a larger weight than the cost-related requirement. In some cases the time-related requirement is a requirement that must be met, and subject to this requirement, the cheapest alternative is sought so that the reconfiguration will result in the cheapest solution that meets the time-related requirement.

It is to be noted that in some cases, the objective based configuration module 340 can be configured to check if an alternative cost, of ordering a new storage-related resource (addition of which will solve the over-utilization situation) from an external source (e.g. any storage-related resources supplier), is lower than the cost of performing the reallocation, and if so - provide a suitable recommendation to the user (not shown in the drawing). If the user chooses to accept the recommendation - the process ends. It is to be noted that also in this scenario, the time-related requirements can be taken into account, and optionally be given a higher weight than the cost-related requirement.

In some cases, objective based configuration module 340 can be further configured to perform one or more measures for re-allocating at least part of at least one of said storage-related resources according to the calculated reconfiguration (block 730). In some cases, the measures can include issuing a command to physically move at least part of at least one of said storage-related resources from a first storage location with under-utilized status to a second storage location with over-utilized status (or from a first portion (e.g. a first rack) of a given Storage Location to a second portion (e.g. a second rack) of the same Storage Location). It is to be noted that in some cases, the measures can include preparatory actions to be made before performing the reallocation, such as migrating data from data storage resources that are to be reallocated, etc.

It is to be noted that, with reference to Fig. 7, some of the blocks can be integrated into a consolidated block or can be broken down to a few blocks and/or other blocks may be added. It should be also noted that whilst the flow diagram is described also with reference to the system elements that realizes them, this is by no means binding, and the blocks (or any subset thereof) can be performed by elements other than those described herein.

Claims

What is claimed is:

1. A distributed storage system comprising: an Objective Based Configuration Module (OBCM) operatively coupled to an infrastructure layer comprising two or more interconnected computer nodes operatively connected to a plurality of storage-related resources, the computer nodes and the storage-related resources distributed over a plurality of storage locations, wherein:

at least one of said interconnected computer nodes comprises at least one processing resource configured to calculate conformity indicative data indicative of conformity between (1) storage-related resources parameters data relating to one or more storage-related resources connected to respective interconnected computer nodes and at least partially allocated to a logical storage entity, and (2) at least one Service Level Specification (SLS) indicative of user-defined storage requirements referring to the logical storage entity, and to inform the OBCM accordingly; and wherein the OBCM is configured to:

assess conformity status for at least one storage location of the plurality of storage locations using the conformity indicative data received with respect to storage-related resources placed at the at least one storage location, the conformity status indicative of over-utilized, normal or underutilized status of one or more storage-related resources placed at the at least one storage location;

calculate a reconfiguration for the distributed storage system based, at least, on said assessment results, so that to re-allocate one or more storage- related resources from storage location with under-utilized status to a storage location with over-utilized status; and

perform one or more measures for re-allocating at least part of at least one of said storage-related resources according to the calculated reconfiguration.

2. The distributed storage system of claim 1 wherein the measures include issuing a command to physically move at least part of at least one of said storage-related resources from a first storage location with under-utilized status to a second storage location with over-utilized status.

5

3. The distributed storage system of claim 2 wherein the reconfiguration is calculated also based on at least one of the costs of the reallocation or the required time for completion of the reallocation. 4. The distributed storage system of claim 3 wherein the reconfiguration is calculated such mat the costs of the reallocation are minimal.

The distributed storage system of claim 1 wherein at least a first storage location of the plurality of storage locations is associated with a first customer and at least a second location of the locations is associated with a second customer.

The distributed storage system of claim 2 wherein the first storage location is associated with a first customer and the second location of the locations is associated with a second customer.

The distributed storage system of claim 1 wherein at least two storage locations of the plurality of storage locations are associated with the same customer.

The distributed storage system of claim 1 wherein said one or more storage-related resources include at least one storage-related resource of the following storage- related resource categories: cache resources, data storage resources and network resources.

The distributed storage system of claim 1 wherein said one or more storage-related resources include at least one storage-related resource of each of the following storage-related resource categories: cache resources, data storage resources and network resources. 10. The distributed storage system of claim 9 wherein the measures include migrating data from at least one data storage resource to be reallocated.

11. The distributed storage system of claim 1 wherein said reconfiguration is calculated by an optimization engine. 12. The distributed storage system of claim 11 wherein said optimization engine uses one or more of the following optimization techniques:

a. Linear programming;

b. Simulated annealing;

c. Genetic algorithms. 13. The distributed storage system of claim 12 wherein the one or more optimization techniques uses heuristics or approximates. 14. The distributed storage system of claim 1 wherein said at least one user-defined storage-related requirement includes at least one of :

a. location;

b. local protection level;

c. backup retention policy;

d. remote protection level;

e. performance levels

f. encryption level;

g. de-duplication;

h. compression;

i. storage method 15. The distributed storage system of claim 1 wherein the informing of the OBCM is performed by the processing resource directly. 16. The distributed storage system of claim 1 wherein the informing of the OBCM is performed by the processing resource via a second interconnected computer node. 17. A method of reconfiguring a distributed storage system utilizing an Objective Based Configuration Module (OBCM) operatively coupled to an infrastructure layer comprising two or more interconnected computer nodes operatively connected to a plurality of storage-related resources, the computer nodes and the storage-related resources distributed over a plurality of storage locations, the method comprising: calculating conformity indicative data indicative of conformity between (1) storage-related resources parameters data relating to one or more storage-related resources connected to respective interconnected computer nodes and at least partially allocated to a logical storage entity, and (2) at least one Service Level Specification (SLS) indicative of user-defined storage requirements referring to the logical storage entity, and informing the OBCM accordingly; and

assessing, utilizing the OBCM, conformity status for at least one storage location of the plurality of storage locations using the conformity indicative data received with respect to storage-related resources placed at the at least one storage location, the conformity status indicative of over-utilized, normal or under-utilized status of one or more storage-related resources placed at the at least one storage location;

calculating, utilizing the OBCM, a reconfiguration for the distributed storage system based, at least, on said assessment results, so that to re-allocate one or more storage-related resources from storage location with under-utilized status to a storage location with over-utilized status; and

performing one or more measures for re-allocating at least part of at least one of said storage-related resources according to the calculated reconfiguration. 18. The method of claim 17 wherein the measures include issuing a command to physically move at least part of at least one of said storage-related resources from a first storage location with under-utilized status to a second storage location with over-utilized status. 19. The method of claim 18 wherein the reconfiguration is calculated also based on at least one of the costs of the reallocation or the required time for completion of the reallocation.

20. The method of claim 19 wherein the reconfiguration is calculated such that the costs of the reallocation are minimal.

21. The method of claim 17 wherein at least a first storage location of the plurality of storage locations is associated with a first customer and at least a second location of the locations is associated with a second customer.

5

22. The method of claim 18 wherein the first storage location is associated with a first customer and the second location of the locations is associated with a second customer. 23. The method of claim 17 wherein at least two storage locations of the plurality of storage locations are associated with the same customer.

24. The method of claim 17 wherein said one or more storage-related resources include at least one storage-related resource of the following storage-related resource categories: cache resources, data storage resources and network resources.

25. The method of claim 17 wherein said one or more storage-related resources include at least one storage-related resource of each of the following storage- related resource categories: cache resources, data storage resources and network resources.

26. The method of claim 25 wherein the measures include migrating data from at least one data storage resource to be reallocated. 27. The method of claim 18 wherein said reconfiguration is calculated by an optimization engine.

28. The method of claim 27 wherein said optimization engine uses one or more of the following optimization techniques: