US20150370486A1 - Dynamic storage management using virtual storage appliances - Google Patents
Dynamic storage management using virtual storage appliances Download PDFInfo
- Publication number
- US20150370486A1 US20150370486A1 US14/585,084 US201414585084A US2015370486A1 US 20150370486 A1 US20150370486 A1 US 20150370486A1 US 201414585084 A US201414585084 A US 201414585084A US 2015370486 A1 US2015370486 A1 US 2015370486A1
- Authority
- US
- United States
- Prior art keywords
- storage
- virtual storage
- storage appliance
- service level
- appliance
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/10—Address translation
- G06F12/109—Address translation for multiple virtual address spaces, e.g. segmentation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/061—Improving I/O performance
- G06F3/0611—Improving I/O performance in relation to response time
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0653—Monitoring storage devices or systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45583—Memory management, e.g. access or allocation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
Definitions
- At least one embodiment of the present invention pertains to management of a storage system in relation to performance of the storage system with respect to a service level objective, and more particularly, to dynamic management of a storage system, through the use of a virtual storage appliance, in response to changes in performance of the storage system with respect to a service level objective.
- a modern data center can include a large number of storage systems, including storage controllers and mass storage devices, and physical servers for hosting applications which access the storage systems.
- the physical servers that host the applications in such environments often include hypervisors, with the individual applications and their operating systems running as virtual machines (VMs) logically on top of the hypervisors.
- VMs virtual machines
- Conventional storage management systems are not capable of efficiently handling the dynamic nature of today's data centers.
- conventional storage management systems rely on the availability of pre-allocated resources, e.g., processors, memory, flash storage, disk drives, network, etc., often in the form of entire storage systems, to handle the storage needs of an application.
- pre-allocated resources e.g., processors, memory, flash storage, disk drives, network, etc.
- additional hardware resources are installed to meet the demand. Installing additional hardware resources can be time consuming, labor intensive, and expensive.
- entire storage systems are purchased and installed in the data center to compensate for a peak load that is slightly over the capacity of the previously allocated resources.
- conventional storage management techniques result in either an abundance of physical resources that are not efficiently being used (i.e., excess capacity) or, when demand exceeds capacity, cannot react quickly enough to reasonably satisfy the demand.
- the techniques introduced here provide for efficient management of storage resources, such as may be used in a modern, dynamic data center, through the use of virtual storage appliances.
- Virtual storage appliances perform storage system operations and can execute in or as a virtual machine on a hypervisor.
- the techniques according to one embodiment include a system and method for managing a dynamic data center by monitoring a storage system to determine whether the storage system is satisfying a service level objective for an application.
- the storage management system then instantiates, shuts down, or modifies a virtual storage appliance on a physical server if there is a determination that the service level objective is not being satisfied.
- the virtual storage appliance can then use resources of the physical server to meet the storage related needs of the application that the storage system cannot provide.
- This automatic and dynamic management of virtual storage appliances by the storage management system allows storage systems to react quickly and automatically to changing storage needs of applications without requiring significant expensive excess storage capacity to be provided.
- a storage management system such as introduced here, in one embodiment, includes a monitoring engine to gather data related to performance of the storage system.
- the storage management system further includes a detection engine to determine from the gathered data whether the storage system is satisfying a service level objective for an application that accesses the storage system.
- the storage management system in one embodiment, includes scenario data that defines actions to be taken in response to an alert from the detection engine.
- the storage management system further includes a decision engine to determine, based on information from the detection engine and the scenario data, an action to be taken in managing the storage system to meet the storage related needs of the application.
- FIG. 1 is a block diagram of an example data center with network storage including a client, a storage system, and a storage management system.
- FIG. 2 is a block diagram of a data center.
- FIG. 3 is a block diagram of a storage management system.
- FIG. 4 is a flow diagram of a process for managing a storage system automatically to meet service level objectives.
- FIG. 5 is a flow diagram of a process for instantiating a virtual storage appliance to perform storage related operations using resources of a physical server.
- FIG. 6 is a block diagram of a data center including a virtual storage appliance.
- FIG. 7 is a flow diagram of a process for reconfiguring a virtual storage appliance automatically to satisfy a service level objective.
- FIG. 8 is a flow diagram of a process for shutting down a virtual storage appliance automatically to satisfy a service level objective.
- FIG. 9 is a block diagram of a system that can be used to implement components of a network storage system.
- FIG. 1 shows an example of a data center with network storage, which includes a plurality of client systems 104 , a storage system 108 , a storage management system 110 and a network 106 connecting the client systems 104 , the storage system 108 , and the storage management system 110 .
- the data center is described in more detail below with reference to FIG. 2 .
- the client systems 104 are connected to the storage system 108 via an interconnect such as the network 106 , which can be, for example, a packet-switched network, such as a local area network (LAN) or a wide area network (WAN).
- LAN local area network
- WAN wide area network
- the storage management system 110 can be controlled by a user, e.g., a storage administrator, through a storage management system 110 coupled to the network 106 . Further, the storage management system 110 includes logic to monitor and configure storage resources in the storage system 108 to meet the needs of client applications 104 . As shown in FIG. 1 , the storage management system 110 is connected to the storage system 108 through the network 106 . However, in another embodiment the storage management system 110 can be part of the storage system 108 .
- FIG. 2 is a block diagram of a data center.
- the data center includes a storage system 202 and a physical server 210 .
- Physical server 210 is configured to host client application 220 that accesses the storage resources of the storage system 202 .
- the storage system 220 includes a storage controller 204 which is coupled to a mass storage subsystem 206 .
- the mass storage subsystem includes a number of mass storage devices 208 , such as disks, tapes, solid state drives, etc. Alternatively, some or all of the mass storage devices 208 can be other types of storage, such as flash memory, solid-state drives (SSDs), tape storage, etc. However, to simplify description, the storage devices 208 are assumed to be disks herein.
- the storage controller 204 can be, for example, one of the FAS-series of storage server products available from NetApp®, Inc. Further, the storage controller 204 can be connected to the disks 208 via a switching fabric (not shown), which can be a Fiber Distributed Data Interface (FDDI) network or Small Computer System Interface (SCSI) connection, for example. It is noted that, within the data center, any other suitable number of storage controllers and/or mass storage devices, and/or any other suitable network technologies, may be employed.
- a switching fabric not shown
- FDDI Fiber Distributed Data Interface
- SCSI Small Computer System Interface
- the storage controller 204 can make some or all of the storage space on the mass storage devices 208 available to the client systems 104 and applications 220 in a conventional manner.
- each of the mass storage devices can actually be an individual disk or other device, a group of disks or other devices (e.g., a RAID group), or any other suitable mass storage device(s).
- the storage controller 204 can communicate with the client systems 104 , the storage management system 110 , and the physical server 210 according to any one or more well-known protocols, such as Network File System (NFS), Common Internet File System (CIFS), Hypertext Transfer Protocol (HTTP), Internet Small Computer System Interface (iSCSI), or NetApp Remote Volume (NRV), to make data stored on the disks 208 available to clients 104 and/or applications 220 .
- the storage controller 204 can present or export data stored on the disks 208 as storage objects, for example, volumes, to each of the client systems 104 or applications 220 .
- the physical server 210 includes resources, e.g., one or more processors, memory, local storage, etc., (not shown) to host applications 220 that access the storage resources of the data center.
- the physical server 210 includes a hypervisor 214 with individual applications, such as application 220 , running in virtual machines logically on top of the hypervisor.
- the physical server 210 is coupled with the storage system 202 to allow applications 220 to access storage related resources of the storage system 202 .
- An example data access path 230 between an application and the storage system is shown in FIG. 2 .
- the data access path in the example of FIG. 2 , is through a physical interconnect, for example, network 250 .
- the data center further includes a storage management system 240 connected with the physical server 210 and storage system 202 through the interconnect 250 .
- the data center includes a data interconnect and a management interconnect.
- FIG. 3 is a block diagram of a storage management system according to the techniques introduced here, for example the storage management system 110 of FIG. 1 .
- the storage management system includes, among other things, a processor 302 , a memory 304 , a user interface 306 , a monitoring engine 308 , a detection engine 310 , a scenario table 312 , and a decision engine 314 .
- the elements of the storage management system can be implemented by programmable circuitry programmed or configured by software and/or firmware, or they can be implemented by entirely by special-purpose “hardwired” circuitry, or in a combination thereof. In the former case, elements 306 , 308 , 310 , and 314 can be implemented within processor 302 .
- the interface 306 allows a user to specify a service level objective for an application or set of applications.
- a service level objective is a specific measurable performance characteristic that specifies what service is to be provided to the application or set of applications. Common service level objectives are, for example, availability, throughput, response time, or quality.
- the user interface 306 can be any suitable type of user interface, e.g., a graphical user interface or a command line interface.
- the monitoring engine 308 gathers data relating to resource allocation of a storage system, and utilization of those resources, as well as performance data of the storage system relating to service level objectives. Examples of data gathered may include amount of memory used by the buffer cache, cache hit rate for I/O requests, workload on individual disk drives, time taken for disk access, how busy the processor is, etc.
- the monitoring engine 308 also monitors resource allocation on a physical server, such as server 210 , utilization of the physical server resources, the hypervisor 214 , and the virtual storage appliances, as described below.
- the detection engine 310 analyzes the data gathered by the monitoring engine 308 and triggers an alert if service level objectives are not being satisfied or if resources are not being efficiently utilized.
- the decision engine 314 in response to an alert from the detection engine 310 , utilizes the scenario data 312 to decide an action that the storage management system should take in response to the alert.
- the scenario data 312 is a data structure stored in memory 304 of the storage management system.
- the scenario data 312 can be stored as a table or any other known or convenient type of data structure.
- the scenario data 312 contains information outlining an action to take in response to a defined scenario.
- VSAs virtual storage appliances
- Endpoint VSAs can use direct-attached storage (e.g., disks or flash memory) on a physical server to store data in order to satisfy a service level objective, essentially dynamically adding storage resources to the storage system.
- Caching VSAs use storage on a physical server to cache data stored on the storage system or, in one embodiment, an endpoint VSA.
- Compression VSAs can remove redundant data being stored to a storage system, e.g., using deduplication techniques.
- Backup VSAs can initiate and manage backup of data from one storage system to another and restore the backed up data when needed.
- FIG. 4 is a flow diagram of a process 400 for managing a storage system automatically to meet service level objectives, according to the techniques introduced here. Note that at least some of the operations associated with this process can potentially be reordered, supplemented, or substituted for, while still performing the same overall technique.
- the process begins, at step 402 , with the monitoring engine 308 of the storage management system monitoring the storage system and gathering data relating to the performance and utilization of the storage system.
- the monitoring engine may obtain response time measurements for the I/O requests of a particular client.
- the detection engine 310 analyzes the data gathered by the monitoring engine 308 and at decision step 406 determines whether to trigger an alert.
- the detection engine 310 may compare. one or more performance values observed by the monitoring engine 308 to one or more corresponding threshold performance values that represent specific service level objectives. Based on each comparison of the observed performance value to the corresponding threshold performance value, the detection engine 310 either triggers an alert or continues to analyze data gathered by the monitoring engine 308 .
- An example of such a comparison is checking whether the measured response time of I/O requests is lower than the maximum response time specified in the service level objective. Another example is checking whether the measured throughput for I/O requests is higher than the minimum throughput specified in the service level objective.
- the decision engine 314 determines at step 408 , based on the alert and a scenario represented in the scenario data 312 , what action the storage management system should take.
- the decision engine 314 uses heuristic methods to determine an efficient action to perform in response to the alert. For example, the storage management system can instantiate, shut down, or reconfigure a VSA, or multiple VSAs, such that a service level objective for an application is satisfied.
- the storage management system then performs the action specified in the scenario data 312 at step 410 .
- the actions the storage management system may take are described in further detail in the example below. Importantly, this entire process can be performed without any human input during the process.
- FIGS. 5-8 illustrate how the storage management system can dynamically manage a storage system.
- the storage management system is monitoring a storage system that is providing storage related services for an application running on a physical server.
- FIG. 5 is a flow diagram of a process 500 for instantiating a virtual storage appliance to perform storage related operations using resources of a physical server. It should be understood that at least some of the operations associated with this process can potentially be reordered, supplemented, or substituted for, while still performing the same overall technique.
- the detection engine 310 of the storage management system determines that a service level objective for the application is not being met by the storage system. For example, the storage system may be receiving a large number of read requests and may not be able to perform at the required input/output rate for the application.
- the detection engine 310 triggers an alert that the storage system has reached its maximum read rate performance limits and therefore cannot satisfy a service level objective for the application.
- the decision engine 314 in response to receiving the alert, references scenario data 312 , such as example table below, to determine what action the storage management system should take.
- Option Scenario Action 1 A new application has Instantiate an Endpoint VSA on a been created with low physical server containing direct performance and low attached storage, and using the reliability needs, e.g., physical server storage to meet the to store temporary data. needs of the application.
- a new application has Allocate storage resources on a been created with high storage system. Optionally, create a performance and high Caching VSA and set up the reliability needs. application to use the cache which in turn accesses the storage system.
- 3 A new application has Instantiate an Endpoint VSA on a been created with low server and set up a replication/ performance and medium- backup relationship with a storage high reliability system. This VSA is now both an needs. Endpoint and a Backup VSA.
- the buffer cache hit rate in Increase the amount of memory the VSA (especially resources allocated to the VSA by Caching or Endpoint) is issuing commands to the hypervisor lower than needed. and the VSA. 8
- the buffer cache hit rate in Reduce the memory allocated to the the VSA (especially VSA by issuing commands to the Caching or Endpoint) is hypervisor and the VSA. higher than needed.
- the application is no Re-route the application to use the longer cacheable (e.g., the storage system directly and then physical server does not shutdown the Caching VSA. have sufficient storage for the amount of data cached by the application) for the Caching VSA.
- the storage system now Re-route the application to use the has sufficient performance storage system directly and then margin and one or more of shutdown the Caching VSA. its applications are using Caching VSAs.
- the decision engine 314 may choose, for example, option “6” in the scenario table above to improve the performance of the storage system.
- the storage management system instantiates a Caching VSA on the physical server to buffer (including proxying storage I/O operations) data for the application so that the application's minimum input/output (read/write) rate will be satisfied.
- the storage management system issues a command to re-route the application's data access path to use the Caching VSA.
- the details of instantiating a VSA are not germane to this description; a known or convenient process for instantiating a VM can be used.
- the VSA performs storage system operations, e.g., buffering data between the application and the storage system, to satisfy the service level objective for the application.
- FIG. 6 is a block diagram of an example data center including a virtual storage appliance.
- the data center depicted in FIG. 6 is similar to the data center depicted in FIG. 2 with the addition of the VSA 602 running on the physical server 210 . While FIG. 6 depicts a data center having a single physical server, a data center can have multiple physical servers, each running one or more VSAs. Further, the data access path 230 has been modified so that storage operations requested by the application 220 run through the VSA 602 instead of directly to the storage system 202 .
- the VSA 602 uses resources of the physical server 210 , e.g., processor, disk, and/or memory, to perform caching operations and/or other storage system operations, such that service level objectives for the application 220 are met.
- the VSA can run on any physical server connected with the storage system and the physical server hosting the application. Further, in one embodiment, the VSA can run in a storage system, such as in storage controller 204 , instead of in a separate physical server.
- the monitoring engine 308 of the storage management system monitors both the storage system 202 and the VSA 602 for conditions such as mentioned above (e.g., see example table).
- FIG. 7 a flow diagram of a process 700 for reconfiguring a virtual storage appliance automatically to satisfy a service level objective is shown.
- the detection engine 310 detects a change in resource usage. For example, the detection engine 310 may detect that the buffer cache hit rate in the VSA is too low, i.e., insufficient resources are allocated to the VSA and the application is accessing the storage system directly, resulting in performance loss. In response to detecting the low hit rate, the detection engine 310 triggers an alert at step 704 .
- the decision engine 314 references the scenario data 312 to determine what action the storage management system should take.
- the decision engine 314 can use heuristic methods to determine the most appropriate action. For example, the decision engine 314 may choose option “7” of the example scenario data 312 and decide to increase the physical server resources allocated to the VSA in order to increase the hit rate.
- the storage management system reconfigures resource allocation of the physical server to increase the resources allocated to the VSA to meet the needs of the application.
- the storage management system issues a command to the hypervisor to reconfigure the resource allocation. The hypervisor then performs the reconfiguration.
- the detection engine 310 determines, from data gathered by the monitoring engine 308 , that the VSA is no longer needed. This could occur, for example, when the application has been shut down or the storage system has become less busy, such that sufficient resources are available on the storage system to satisfy the service level objectives of the application without help from the VSA.
- the detection engine 310 triggers, at step 804 , an alert and the decision engine 314 references the scenario data 312 to determine the most appropriate action to take in response to the alert.
- the storage management system re-routes the data access path of the application, at step 808 , to directly access the storage system and shuts down the VSA at step 810 .
- the storage management system shuts down the VSA at step 810 .
- FIG. 9 is a block diagram of a system 900 that can be used to implement components of a network storage system.
- the system of FIG. 9 can be used to implement a client system, the storage management system, the storage controller, or the physical server.
- the system 900 includes a processor subsystem 910 that includes one or more processors.
- the system 900 further includes memory 920 , a network adapter 940 , and a storage adapter 950 , all interconnected by an interconnect 960 .
- the memory 920 illustratively comprises storage locations that are addressable by the processor(s) 910 and adapters 940 and 950 for storing software program code and data associated with the techniques introduced here.
- the processor 910 and adapters 940 and 950 may, in turn, comprise processing elements and/or logic circuitry configured to execute the software code and manipulate the data structures. It will be apparent to those skilled in the art that other processing and memory implementations, including various computer readable storage media, may be used for storing and executing program instructions pertaining to the techniques introduced here.
- the network adapter 940 includes a plurality of ports to couple the system 900 with one or more other systems over point-to-point links, wide area networks, virtual private networks implemented over a public network (Internet) or a shared local area network.
- the network adapter 940 thus can include the mechanical components and electrical circuitry needed to connect the system 900 to the network 106 .
- the network 106 can be embodied as an Ethernet network or a Fibre Channel (FC) network.
- One or more systems can communicate with other systems over the network 106 by exchanging packets or frames of data according to pre-defined protocols, such as TCP/IP.
- the storage adapter 950 cooperates with the operating system to access information on attached storage devices.
- the information may be stored on any type of attached array of writable storage media, such as magnetic disk or tape, optical disk (e.g., CD-ROM or DVD), flash memory, solid-state drive (SSD), electronic random access memory (RAM), micro-electro mechanical and/or any other similar media adapted to store information, including data and parity information.
- the storage adapter 950 includes a plurality of ports having input/output (I/O) interface circuitry that couples with the disks over an I/O interconnect arrangement, such as a conventional high-performance, Fibre Channel (FC) link topology.
- I/O input/output
- ASICs application-specific integrated circuits
- PLDs programmable logic devices
- FPGAs field-programmable gate arrays
- Machine-readable medium includes any mechanism that can store information in a form accessible by a machine (a machine may be, for example, a computer, network device, cellular phone, personal digital assistant (PDA), manufacturing tool, any device with one or more processors, etc.).
- a machine-accessible medium includes recordable/non-recordable media (e.g., read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.), etc.
- logic can include, for example, special-purpose hardwired circuitry, software and/or firmware in conjunction with programmable circuitry, or a combination thereof.
Abstract
The techniques introduced here provide for efficient management of storage resources in a modern, dynamic data center through the use of virtual storage appliances. Virtual storage appliances perform storage operations and execute in or as a virtual machine on a hypervisor. A storage management system monitors a storage system to determine whether the storage system is satisfying a service level objective for an application. The storage management system then manages (e.g., instantiates, shuts down, or reconfigures) a virtual storage appliance on a physical server. The virtual storage appliance uses resources of the physical server to meet the storage related needs of the application that the storage system cannot provide. This automatic and dynamic management of virtual storage appliances by the storage management system allows storage systems to quickly react to changing storage needs of applications without requiring expensive excess storage capacity.
Description
- At least one embodiment of the present invention pertains to management of a storage system in relation to performance of the storage system with respect to a service level objective, and more particularly, to dynamic management of a storage system, through the use of a virtual storage appliance, in response to changes in performance of the storage system with respect to a service level objective.
- A modern data center can include a large number of storage systems, including storage controllers and mass storage devices, and physical servers for hosting applications which access the storage systems. Today's data centers, especially in cloud computing environments, typically have large, multi-tenant systems, i.e., multiple organizations and/or applications share the same underlying processing and storage hardware. The physical servers that host the applications in such environments often include hypervisors, with the individual applications and their operating systems running as virtual machines (VMs) logically on top of the hypervisors.
- These data centers are often extremely dynamic in their makeup and usage. For example, the set of applications running on the physical servers in the data center often changes due to the multi-tenant nature of the data center. This dynamism typically results in a fluctuating storage workload for the data center. Further, the storage workload for the data center often changes over time regardless of whether the set of applications changes, e.g., the data center has a peak storage workload during a specific time of day. The difference between an average and peak load can be substantial. Further, in order to balance utilization of processing and storage resources (or for other management reasons), applications may be migrated between physical servers and sometimes between data centers, adding to the dynamic nature of the data center.
- Conventional storage management systems are not capable of efficiently handling the dynamic nature of today's data centers. Typically, conventional storage management systems rely on the availability of pre-allocated resources, e.g., processors, memory, flash storage, disk drives, network, etc., often in the form of entire storage systems, to handle the storage needs of an application. If the allocated resources do not meet the storage demand for the data center, typically additional hardware resources are installed to meet the demand. Installing additional hardware resources can be time consuming, labor intensive, and expensive. In some cases, entire storage systems are purchased and installed in the data center to compensate for a peak load that is slightly over the capacity of the previously allocated resources. As a result, conventional storage management techniques result in either an abundance of physical resources that are not efficiently being used (i.e., excess capacity) or, when demand exceeds capacity, cannot react quickly enough to reasonably satisfy the demand.
- The techniques introduced here provide for efficient management of storage resources, such as may be used in a modern, dynamic data center, through the use of virtual storage appliances. Virtual storage appliances perform storage system operations and can execute in or as a virtual machine on a hypervisor. The techniques according to one embodiment include a system and method for managing a dynamic data center by monitoring a storage system to determine whether the storage system is satisfying a service level objective for an application. The storage management system then instantiates, shuts down, or modifies a virtual storage appliance on a physical server if there is a determination that the service level objective is not being satisfied. The virtual storage appliance can then use resources of the physical server to meet the storage related needs of the application that the storage system cannot provide. This automatic and dynamic management of virtual storage appliances by the storage management system allows storage systems to react quickly and automatically to changing storage needs of applications without requiring significant expensive excess storage capacity to be provided.
- A storage management system such as introduced here, in one embodiment, includes a monitoring engine to gather data related to performance of the storage system. The storage management system further includes a detection engine to determine from the gathered data whether the storage system is satisfying a service level objective for an application that accesses the storage system. The storage management system, in one embodiment, includes scenario data that defines actions to be taken in response to an alert from the detection engine. The storage management system further includes a decision engine to determine, based on information from the detection engine and the scenario data, an action to be taken in managing the storage system to meet the storage related needs of the application.
- Other aspects of the techniques summarized above will be apparent from the accompanying figures and from the detailed description which follows.
- One or more embodiments of the present invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements.
-
FIG. 1 is a block diagram of an example data center with network storage including a client, a storage system, and a storage management system. -
FIG. 2 is a block diagram of a data center. -
FIG. 3 is a block diagram of a storage management system. -
FIG. 4 is a flow diagram of a process for managing a storage system automatically to meet service level objectives. -
FIG. 5 is a flow diagram of a process for instantiating a virtual storage appliance to perform storage related operations using resources of a physical server. -
FIG. 6 is a block diagram of a data center including a virtual storage appliance. -
FIG. 7 is a flow diagram of a process for reconfiguring a virtual storage appliance automatically to satisfy a service level objective. -
FIG. 8 is a flow diagram of a process for shutting down a virtual storage appliance automatically to satisfy a service level objective. -
FIG. 9 is a block diagram of a system that can be used to implement components of a network storage system. - References in this specification to “an embodiment”, “one embodiment”, or the like, mean that the particular feature, structure or characteristic being described is included in at least one embodiment of the present invention. Occurrences of such phrases in this specification do not necessarily all refer to the same embodiment.
-
FIG. 1 shows an example of a data center with network storage, which includes a plurality ofclient systems 104, astorage system 108, astorage management system 110 and anetwork 106 connecting theclient systems 104, thestorage system 108, and thestorage management system 110. The data center is described in more detail below with reference toFIG. 2 . Theclient systems 104 are connected to thestorage system 108 via an interconnect such as thenetwork 106, which can be, for example, a packet-switched network, such as a local area network (LAN) or a wide area network (WAN). - Various functions and configuration settings of the
storage system 108 can be controlled by a user, e.g., a storage administrator, through astorage management system 110 coupled to thenetwork 106. Further, thestorage management system 110 includes logic to monitor and configure storage resources in thestorage system 108 to meet the needs ofclient applications 104. As shown inFIG. 1 , thestorage management system 110 is connected to thestorage system 108 through thenetwork 106. However, in another embodiment thestorage management system 110 can be part of thestorage system 108. -
FIG. 2 is a block diagram of a data center. The data center includes astorage system 202 and aphysical server 210.Physical server 210 is configured to hostclient application 220 that accesses the storage resources of thestorage system 202. As shown inFIG. 2 , thestorage system 220 includes astorage controller 204 which is coupled to amass storage subsystem 206. The mass storage subsystem includes a number ofmass storage devices 208, such as disks, tapes, solid state drives, etc. Alternatively, some or all of themass storage devices 208 can be other types of storage, such as flash memory, solid-state drives (SSDs), tape storage, etc. However, to simplify description, thestorage devices 208 are assumed to be disks herein. - The
storage controller 204 can be, for example, one of the FAS-series of storage server products available from NetApp®, Inc. Further, thestorage controller 204 can be connected to thedisks 208 via a switching fabric (not shown), which can be a Fiber Distributed Data Interface (FDDI) network or Small Computer System Interface (SCSI) connection, for example. It is noted that, within the data center, any other suitable number of storage controllers and/or mass storage devices, and/or any other suitable network technologies, may be employed. - The
storage controller 204 can make some or all of the storage space on themass storage devices 208 available to theclient systems 104 andapplications 220 in a conventional manner. For example, each of the mass storage devices can actually be an individual disk or other device, a group of disks or other devices (e.g., a RAID group), or any other suitable mass storage device(s). Thestorage controller 204 can communicate with theclient systems 104, thestorage management system 110, and thephysical server 210 according to any one or more well-known protocols, such as Network File System (NFS), Common Internet File System (CIFS), Hypertext Transfer Protocol (HTTP), Internet Small Computer System Interface (iSCSI), or NetApp Remote Volume (NRV), to make data stored on thedisks 208 available toclients 104 and/orapplications 220. Thestorage controller 204 can present or export data stored on thedisks 208 as storage objects, for example, volumes, to each of theclient systems 104 orapplications 220. - The
physical server 210 includes resources, e.g., one or more processors, memory, local storage, etc., (not shown) tohost applications 220 that access the storage resources of the data center. Thephysical server 210 includes ahypervisor 214 with individual applications, such asapplication 220, running in virtual machines logically on top of the hypervisor. Thephysical server 210 is coupled with thestorage system 202 to allowapplications 220 to access storage related resources of thestorage system 202. An exampledata access path 230 between an application and the storage system is shown inFIG. 2 . The data access path, in the example ofFIG. 2 , is through a physical interconnect, for example,network 250. The data center further includes astorage management system 240 connected with thephysical server 210 andstorage system 202 through theinterconnect 250. In one embodiment, the data center includes a data interconnect and a management interconnect. -
FIG. 3 is a block diagram of a storage management system according to the techniques introduced here, for example thestorage management system 110 ofFIG. 1 . The storage management system includes, among other things, aprocessor 302, amemory 304, auser interface 306, amonitoring engine 308, adetection engine 310, a scenario table 312, and adecision engine 314. The elements of the storage management system can be implemented by programmable circuitry programmed or configured by software and/or firmware, or they can be implemented by entirely by special-purpose “hardwired” circuitry, or in a combination thereof. In the former case,elements processor 302. - The
interface 306 allows a user to specify a service level objective for an application or set of applications. A service level objective is a specific measurable performance characteristic that specifies what service is to be provided to the application or set of applications. Common service level objectives are, for example, availability, throughput, response time, or quality. Theuser interface 306 can be any suitable type of user interface, e.g., a graphical user interface or a command line interface. - The
monitoring engine 308 gathers data relating to resource allocation of a storage system, and utilization of those resources, as well as performance data of the storage system relating to service level objectives. Examples of data gathered may include amount of memory used by the buffer cache, cache hit rate for I/O requests, workload on individual disk drives, time taken for disk access, how busy the processor is, etc. Themonitoring engine 308 also monitors resource allocation on a physical server, such asserver 210, utilization of the physical server resources, thehypervisor 214, and the virtual storage appliances, as described below. - The
detection engine 310 analyzes the data gathered by themonitoring engine 308 and triggers an alert if service level objectives are not being satisfied or if resources are not being efficiently utilized. Thedecision engine 314, in response to an alert from thedetection engine 310, utilizes thescenario data 312 to decide an action that the storage management system should take in response to the alert. In one embodiment, thescenario data 312 is a data structure stored inmemory 304 of the storage management system. Thescenario data 312 can be stored as a table or any other known or convenient type of data structure. Thescenario data 312 contains information outlining an action to take in response to a defined scenario. - If a storage system is not able to meet the applicable service level objective with its current resource allocation, the storage management system manages one or more virtual storage appliances (VSAs), as described below, to dynamically supplement or replace the storage system to meet the service level objective for an application. VSAs are appliances that perform storage system operations and can execute in or as a virtual machine on a hypervisor. There can be many types of virtual storage appliances. Endpoint VSAs, for example, can use direct-attached storage (e.g., disks or flash memory) on a physical server to store data in order to satisfy a service level objective, essentially dynamically adding storage resources to the storage system. Caching VSAs use storage on a physical server to cache data stored on the storage system or, in one embodiment, an endpoint VSA. Compression VSAs can remove redundant data being stored to a storage system, e.g., using deduplication techniques. Backup VSAs can initiate and manage backup of data from one storage system to another and restore the backed up data when needed.
-
FIG. 4 is a flow diagram of aprocess 400 for managing a storage system automatically to meet service level objectives, according to the techniques introduced here. Note that at least some of the operations associated with this process can potentially be reordered, supplemented, or substituted for, while still performing the same overall technique. - The process begins, at
step 402, with themonitoring engine 308 of the storage management system monitoring the storage system and gathering data relating to the performance and utilization of the storage system. For example, the monitoring engine may obtain response time measurements for the I/O requests of a particular client. Atstep 404, thedetection engine 310 analyzes the data gathered by themonitoring engine 308 and atdecision step 406 determines whether to trigger an alert. For example, thedetection engine 310 may compare. one or more performance values observed by themonitoring engine 308 to one or more corresponding threshold performance values that represent specific service level objectives. Based on each comparison of the observed performance value to the corresponding threshold performance value, thedetection engine 310 either triggers an alert or continues to analyze data gathered by themonitoring engine 308. An example of such a comparison is checking whether the measured response time of I/O requests is lower than the maximum response time specified in the service level objective. Another example is checking whether the measured throughput for I/O requests is higher than the minimum throughput specified in the service level objective. - In response to an alert from the
detection engine 310, thedecision engine 314 determines atstep 408, based on the alert and a scenario represented in thescenario data 312, what action the storage management system should take. In one embodiment, thedecision engine 314 uses heuristic methods to determine an efficient action to perform in response to the alert. For example, the storage management system can instantiate, shut down, or reconfigure a VSA, or multiple VSAs, such that a service level objective for an application is satisfied. The storage management system then performs the action specified in thescenario data 312 atstep 410. The actions the storage management system may take are described in further detail in the example below. Importantly, this entire process can be performed without any human input during the process. -
FIGS. 5-8 illustrate how the storage management system can dynamically manage a storage system. Assume for this example that the storage management system is monitoring a storage system that is providing storage related services for an application running on a physical server.FIG. 5 is a flow diagram of aprocess 500 for instantiating a virtual storage appliance to perform storage related operations using resources of a physical server. It should be understood that at least some of the operations associated with this process can potentially be reordered, supplemented, or substituted for, while still performing the same overall technique. - At
step 502, thedetection engine 310 of the storage management system determines that a service level objective for the application is not being met by the storage system. For example, the storage system may be receiving a large number of read requests and may not be able to perform at the required input/output rate for the application. Atstep 504, thedetection engine 310 triggers an alert that the storage system has reached its maximum read rate performance limits and therefore cannot satisfy a service level objective for the application. Atstep 506, thedecision engine 314, in response to receiving the alert, referencesscenario data 312, such as example table below, to determine what action the storage management system should take. -
Option Scenario Action 1 A new application has Instantiate an Endpoint VSA on a been created with low physical server containing direct performance and low attached storage, and using the reliability needs, e.g., physical server storage to meet the to store temporary data. needs of the application. 2 A new application has Allocate storage resources on a been created with high storage system. Optionally, create a performance and high Caching VSA and set up the reliability needs. application to use the cache which in turn accesses the storage system. 3 A new application has Instantiate an Endpoint VSA on a been created with low server and set up a replication/ performance and medium- backup relationship with a storage high reliability system. This VSA is now both an needs. Endpoint and a Backup VSA. 4 The amount of space Identify the application on the available on the storage storage system which will benefit system has been reduced most from compression and significantly. dynamically instantiate a Compression VSA, and introduce the VSA in the data access path of the application so that the VSA can compress data that has been stored and is being stored. 5 New storage has been Initiate decompression of the entire added to the storage set of application data stored by the system, thereby allowing Compression VSA, re-route data to be stored without applications to directly use the compression. An storage system, and finally shut application's performance down the VSA. needs have also been affected by the introduction of compression. 6 The storage system has Identify an application on the storage reached its performance system for which a cache will reduce limits and the performance the workload as needed on the objectives of some storage system. Create a Caching applications are not being VSA for the application and re-route met. the application's data access path to use the cache. 7 The buffer cache hit rate in Increase the amount of memory the VSA (especially resources allocated to the VSA by Caching or Endpoint) is issuing commands to the hypervisor lower than needed. and the VSA. 8 The buffer cache hit rate in Reduce the memory allocated to the the VSA (especially VSA by issuing commands to the Caching or Endpoint) is hypervisor and the VSA. higher than needed. 9 The application is no Re-route the application to use the longer cacheable (e.g., the storage system directly and then physical server does not shutdown the Caching VSA. have sufficient storage for the amount of data cached by the application) for the Caching VSA. 10 The storage system now Re-route the application to use the has sufficient performance storage system directly and then margin and one or more of shutdown the Caching VSA. its applications are using Caching VSAs. - The
decision engine 314, based on heuristic methods for example, may choose, for example, option “6” in the scenario table above to improve the performance of the storage system. Accordingly atstep 508, the storage management system instantiates a Caching VSA on the physical server to buffer (including proxying storage I/O operations) data for the application so that the application's minimum input/output (read/write) rate will be satisfied. In one embodiment, the storage management system issues a command to re-route the application's data access path to use the Caching VSA. The details of instantiating a VSA are not germane to this description; a known or convenient process for instantiating a VM can be used. Finally, atstep 510, the VSA performs storage system operations, e.g., buffering data between the application and the storage system, to satisfy the service level objective for the application. -
FIG. 6 is a block diagram of an example data center including a virtual storage appliance. The data center depicted inFIG. 6 is similar to the data center depicted inFIG. 2 with the addition of theVSA 602 running on thephysical server 210. WhileFIG. 6 depicts a data center having a single physical server, a data center can have multiple physical servers, each running one or more VSAs. Further, thedata access path 230 has been modified so that storage operations requested by theapplication 220 run through theVSA 602 instead of directly to thestorage system 202. TheVSA 602 uses resources of thephysical server 210, e.g., processor, disk, and/or memory, to perform caching operations and/or other storage system operations, such that service level objectives for theapplication 220 are met. While it is shown inFIG. 6 that the VSA is running on the same physical server as the application, the VSA can run on any physical server connected with the storage system and the physical server hosting the application. Further, in one embodiment, the VSA can run in a storage system, such as instorage controller 204, instead of in a separate physical server. - After the VSA has been instantiated, the
monitoring engine 308 of the storage management system monitors both thestorage system 202 and theVSA 602 for conditions such as mentioned above (e.g., see example table). Referring now toFIG. 7 , a flow diagram of aprocess 700 for reconfiguring a virtual storage appliance automatically to satisfy a service level objective is shown. Atstep 702, thedetection engine 310 detects a change in resource usage. For example, thedetection engine 310 may detect that the buffer cache hit rate in the VSA is too low, i.e., insufficient resources are allocated to the VSA and the application is accessing the storage system directly, resulting in performance loss. In response to detecting the low hit rate, thedetection engine 310 triggers an alert atstep 704. - At
step 706, in response to the alert, thedecision engine 314 references thescenario data 312 to determine what action the storage management system should take. As noted above, thedecision engine 314 can use heuristic methods to determine the most appropriate action. For example, thedecision engine 314 may choose option “7” of theexample scenario data 312 and decide to increase the physical server resources allocated to the VSA in order to increase the hit rate. Accordingly, atstep 708, the storage management system reconfigures resource allocation of the physical server to increase the resources allocated to the VSA to meet the needs of the application. In one embodiment, the storage management system issues a command to the hypervisor to reconfigure the resource allocation. The hypervisor then performs the reconfiguration. - Referring now to
FIG. 8 , a flow diagram of aprocess 800 for shutting down a virtual storage appliance automatically to satisfy a service level objective is shown. Atstep 802, thedetection engine 310 determines, from data gathered by themonitoring engine 308, that the VSA is no longer needed. This could occur, for example, when the application has been shut down or the storage system has become less busy, such that sufficient resources are available on the storage system to satisfy the service level objectives of the application without help from the VSA. Thedetection engine 310 triggers, atstep 804, an alert and thedecision engine 314 references thescenario data 312 to determine the most appropriate action to take in response to the alert. Atdecision step 806, if the application is running (i.e., still requires storage system operations), the storage management system re-routes the data access path of the application, atstep 808, to directly access the storage system and shuts down the VSA atstep 810. Atdecision step 806, if the application is not running (i.e., no longer requires storage system operations), the storage management system shuts down the VSA atstep 810. -
FIG. 9 is a block diagram of a system 900 that can be used to implement components of a network storage system. For example, the system ofFIG. 9 can be used to implement a client system, the storage management system, the storage controller, or the physical server. - In an illustrative embodiment, the system 900 includes a
processor subsystem 910 that includes one or more processors. The system 900 further includesmemory 920, anetwork adapter 940, and astorage adapter 950, all interconnected by aninterconnect 960. - The
memory 920 illustratively comprises storage locations that are addressable by the processor(s) 910 andadapters processor 910 andadapters - The
network adapter 940 includes a plurality of ports to couple the system 900 with one or more other systems over point-to-point links, wide area networks, virtual private networks implemented over a public network (Internet) or a shared local area network. Thenetwork adapter 940 thus can include the mechanical components and electrical circuitry needed to connect the system 900 to thenetwork 106. Illustratively, thenetwork 106 can be embodied as an Ethernet network or a Fibre Channel (FC) network. One or more systems can communicate with other systems over thenetwork 106 by exchanging packets or frames of data according to pre-defined protocols, such as TCP/IP. - The
storage adapter 950 cooperates with the operating system to access information on attached storage devices. The information may be stored on any type of attached array of writable storage media, such as magnetic disk or tape, optical disk (e.g., CD-ROM or DVD), flash memory, solid-state drive (SSD), electronic random access memory (RAM), micro-electro mechanical and/or any other similar media adapted to store information, including data and parity information. Thestorage adapter 950 includes a plurality of ports having input/output (I/O) interface circuitry that couples with the disks over an I/O interconnect arrangement, such as a conventional high-performance, Fibre Channel (FC) link topology. - The techniques introduced above can be implemented by programmable circuitry programmed or configured by software and/or firmware, or they can be implemented by entirely by special-purpose “hardwired” circuitry, or in a combination of such forms. Such special-purpose circuitry (if any) can be in the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), etc.
- Software or firmware for use in implementing the techniques introduced here may be stored on a machine-readable storage medium and may be executed by one or more general-purpose or special-purpose programmable microprocessors. A “machine-readable medium”, as the term is used herein, includes any mechanism that can store information in a form accessible by a machine (a machine may be, for example, a computer, network device, cellular phone, personal digital assistant (PDA), manufacturing tool, any device with one or more processors, etc.). For example, a machine-accessible medium includes recordable/non-recordable media (e.g., read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.), etc.
- The term “logic”, as used herein, can include, for example, special-purpose hardwired circuitry, software and/or firmware in conjunction with programmable circuitry, or a combination thereof.
- Although the present invention has been described with reference to specific exemplary embodiments, it will be recognized that the invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense.
Claims (35)
1. A method comprising;
monitoring a storage system, by a storage management system, to determine whether the storage system is satisfying a service level objective for an application;
determining, by the storage management system, from said monitoring, that the storage system is not satisfying the service level objective for the application; and
in response to a determination that the storage system is not satisfying the service level objective, managing, by the storage management system, a virtual storage appliance, the virtual storage appliance configured to perform storage system operations to satisfy the service level objective for the application.
2. The method of claim 1 wherein managing the virtual storage appliance includes instantiating the virtual storage appliance on the physical server in response to an indication that the storage system is not satisfying the service level objective for the application.
3. The method of claim 1 wherein managing a virtual storage appliance includes shutting down the virtual storage appliance in response to a determination that the storage system is able to satisfy the service level objective without the virtual storage appliance.
4. The method of claim 1 wherein managing the virtual storage appliance includes reconfiguring the virtual storage appliance in response to a change in resource usage by the application.
5. The method of claim 4 wherein reconfiguring the virtual storage appliance includes increasing resources allocated to the virtual storage appliance.
6. The method of claim 4 wherein reconfiguring the virtual storage appliance includes decreasing resources allocated to the virtual storage appliance.
7. The method of claim 1 wherein the virtual storage appliance comprises an end-point virtual storage appliance, a caching virtual storage appliance, a compression virtual storage appliance, or a backup virtual storage appliance.
8. The method of claim 7 , further comprising, heuristically determining what type of virtual storage appliance will satisfy the service level objective.
9. The method of claim 7 , wherein an end-point virtual storage appliance satisfies an availability service level objective by using resources of a physical server to store data for the application in response to the storage system not having capacity to store the data.
10. The method of claim 7 , wherein a caching virtual storage appliance satisfies an input/output service level objective by using resources of a physical server to cache data along a data access path between the application and the storage system to increase an input/output rate in response to the storage system not meeting a defined input/output rate.
11. The method of claim 7 , wherein a compression virtual storage appliance satisfies an availability service level objective by using resources of a physical server to perform compression operations for the application in response to storage capacity of the storage system reaching a threshold.
12. The method of claim 7 , wherein a backup virtual storage appliance satisfies a reliability service level objective by using resources of a physical server to store backup data for the application in response to the storage system not providing backup.
13. A system comprising:
a storage system including a storage controller and a mass storage subsystem;
a physical server coupled to communicate with the storage system, wherein the physical server hosts an application that requires access to the storage system; and
a storage management system, coupled to communicate with the storage system and the physical server, the storage management system including:
a monitoring engine to monitor the storage system;
a detection engine to determine, based on monitoring of the monitoring engine, whether the storage system is satisfying a service level objective for the application; and
a decision engine configured to manage a virtual storage appliance on the physical server, wherein storage system operations are performed by the virtual storage appliance, using resources of the physical server, to cause the service level objective for the application to be satisfied.
14. The system of claim 13 wherein the storage management system further comprises scenario data for use by the decision engine to determine what action to take in managing the virtual storage appliance.
15. The system of claim 14 wherein the scenario data comprises a mapping of scenarios to actions.
16. The system of claim 14 wherein the decision engine is further configured to instantiate the virtual storage appliance on the physical server in response to an indication from the detection that the storage system is not satisfying a service level objective for the application.
17. The system of claim 14 wherein the decision engine is further configured to shut down the virtual storage appliance in response to a determination that the storage system is able to satisfy the service level objective without the virtual storage appliance.
18. The system of claim 14 wherein the decision engine is further configured to reconfigure the virtual storage appliance in response to a change in resource usage by the application.
19. The method of claim 18 wherein reconfiguring the virtual storage appliance includes increasing resources allocated to the virtual storage appliance.
20. The method of claim 18 wherein reconfiguring the virtual storage appliance includes decreasing resources allocated to the virtual storage appliance.
21. The system of claim 13 wherein the virtual storage appliance comprises an end-point virtual storage appliance, a caching virtual storage appliance, a compression virtual storage appliance, or a backup virtual storage appliance.
22. The system of claim 13 wherein the physical server includes a hypervisor configured to manage server resources for applications and virtual storage appliances.
23. The system of claim 21 , wherein the end-point virtual storage appliance, in response to the storage system not having capacity to store data for the application, uses resources of the physical server to store the data that an availability service level objective is satisfied.
24. The method of claim 21 , wherein the caching virtual storage appliance, in response to the storage system not meeting a defined input/output rate according to the service level objective, uses resources of the physical server to cache data along a data access path between the application and the storage system to increase an input/output rate such that the input/output rate satisfies the defined input/output rate and the service level objective is met.
25. The method of claim 21 , wherein a compression virtual storage appliance, in response to storage availability of the storage system reaching a threshold, uses resources of the physical server to perform compression operations for the application such that the storage availability is increased to meet a service level objective.
26. The method of claim 21 , wherein a backup virtual storage appliance, in response to the storage system not providing sufficient backup, uses resources of the physical server to store backup data for the application, such that the backup data is available to satisfy a reliability service level objective.
27. A method comprising;
monitoring a storage system, by a storage management system, to determine whether the storage system is satisfying a service level objective for an application;
determining, by the storage management system, that the storage system is not satisfying the service level objective;
instantiating, by the storage management system, a virtual storage appliance, the virtual storage appliance configured to perform storage system operations to satisfy the service level objective for the application; and
reconfiguring, by the storage management system, the virtual storage appliance, in response to a change in performance of the storage system or the virtual storage appliance, such that satisfaction of the service level objective is maintained.
28. The method of claim 27 wherein the storage management system instantiates the virtual storage appliance in response to determining that the storage system is not satisfying the service level objective for the application.
29. The method of claim 27 wherein modifying the virtual storage appliance includes shutting down the virtual storage appliance in response to the storage system being able to satisfy the service level objective without help from the virtual storage appliance.
30. The method of claim 27 wherein modifying the virtual storage appliance includes reconfiguring the virtual storage appliance in response to a determined event.
31. The method of claim 27 wherein the virtual storage appliance is one of an end-point virtual storage appliance, a caching virtual storage appliance, a compression virtual storage appliance, or a backup virtual storage appliance.
32. The method of claim 31 further comprising, heuristically determining what type of virtual storage appliance will satisfy the service level objective.
33. The method of claim 27 wherein reconfiguring the virtual storage appliance includes allocating or releasing physical server resources associated with the virtual storage appliance to maintain performance above the service level objective.
34. A storage management system comprising:
a user interface to allow a user to specify a service level objective for an application;
a monitoring engine to gather data relating to service level objective performance of the storage system;
a detection engine to detect, based on the data gathered by the monitoring engine, a defined event relating to the service level objective performance of the storage system and to trigger an alert in response to detecting the defined event;
scenario data that defines an action to be taken in response to the alert from the detection engine; and
a decision engine to implement the actions defined in the scenario data using a virtual storage appliance on a physical server connected to the storage system through a network, the virtual storage appliance configured to perform storage system operations to satisfy the service level objective for the application.
35. The storage management system of claim 34 , wherein the monitoring engine is further configured to gather data relating to resource allocation and utilization of the storage system and the virtual storage appliance.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/585,084 US20150370486A1 (en) | 2011-02-22 | 2014-12-29 | Dynamic storage management using virtual storage appliances |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/032,409 US8924658B1 (en) | 2011-02-22 | 2011-02-22 | Dynamic storage management using virtual storage appliances |
US14/585,084 US20150370486A1 (en) | 2011-02-22 | 2014-12-29 | Dynamic storage management using virtual storage appliances |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/032,409 Continuation US8924658B1 (en) | 2011-02-22 | 2011-02-22 | Dynamic storage management using virtual storage appliances |
Publications (1)
Publication Number | Publication Date |
---|---|
US20150370486A1 true US20150370486A1 (en) | 2015-12-24 |
Family
ID=52112643
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/032,409 Active 2031-12-01 US8924658B1 (en) | 2011-02-22 | 2011-02-22 | Dynamic storage management using virtual storage appliances |
US14/585,084 Abandoned US20150370486A1 (en) | 2011-02-22 | 2014-12-29 | Dynamic storage management using virtual storage appliances |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/032,409 Active 2031-12-01 US8924658B1 (en) | 2011-02-22 | 2011-02-22 | Dynamic storage management using virtual storage appliances |
Country Status (1)
Country | Link |
---|---|
US (2) | US8924658B1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2019217030A1 (en) * | 2018-05-07 | 2019-11-14 | Apple Inc. | Techniques for managing memory allocation within a storage device to improve operation of a camera application |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11582299B2 (en) * | 2016-01-26 | 2023-02-14 | Pure Storage, Inc. | Allocating cache memory in a dispersed storage network |
US11789631B2 (en) | 2010-11-29 | 2023-10-17 | Pure Storage, Inc. | Utilizing metadata storage trees in a vast storage network |
US9274838B2 (en) * | 2011-12-22 | 2016-03-01 | Netapp, Inc. | Dynamic instantiation and management of virtual caching appliances |
US20160147657A1 (en) * | 2014-11-21 | 2016-05-26 | Dell Products L.P. | System and method for optimized disk io ram caching for a vdi environment |
US9946465B1 (en) * | 2014-12-31 | 2018-04-17 | EMC IP Holding Company LLC | Adaptive learning techniques for determining expected service levels |
US10108455B2 (en) | 2015-08-26 | 2018-10-23 | Vmware, Inc. | Methods and apparatus to manage and execute actions in computing environments based on a type of virtual compute node |
US10122649B2 (en) | 2015-08-26 | 2018-11-06 | Vmware, Inc. | Methods and apparatus to manage and execute actions in computing environments based on a routing path |
US10110505B2 (en) * | 2015-08-26 | 2018-10-23 | Vmware, Inc. | Methods and apparatus to manage and execute actions in computing environments using a graphical user interface |
US10007577B2 (en) * | 2015-12-21 | 2018-06-26 | Intel Corporation | Methods and apparatus to facilitate distributed data backup |
US10613991B2 (en) * | 2016-08-01 | 2020-04-07 | Hewlett Packard Enterprise Development Lp | Transparent routers to provide services |
US10740130B1 (en) * | 2016-09-29 | 2020-08-11 | EMC IP Holding Company LLC | Administrative system for rendering a user interface within a virtual machine to allow a user to administer the virtual machine and group of underlying hardware of a hypervisor |
US10721304B2 (en) * | 2017-09-14 | 2020-07-21 | International Business Machines Corporation | Storage system using cloud storage as a rank |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090327618A1 (en) * | 2008-04-17 | 2009-12-31 | Kristal Pollack | Method for Self Optimizing Value Based Data Allocation Across A Multi-Tier Storage System |
US20110010445A1 (en) * | 2009-07-09 | 2011-01-13 | Hitachi Data Systems Corporation | Monitoring application service level objectives |
US20110078682A1 (en) * | 2008-05-28 | 2011-03-31 | Don Vinh Doan | Providing Object-Level Input/Output Requests Between Virtual Machines To Access A Storage Subsystem |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7613847B2 (en) * | 2006-05-16 | 2009-11-03 | Hewlett-Packard Development Company, L.P. | Partially virtualizing an I/O device for use by virtual machines |
US8655623B2 (en) * | 2007-02-13 | 2014-02-18 | International Business Machines Corporation | Diagnostic system and method |
US8326669B2 (en) * | 2007-04-19 | 2012-12-04 | International Business Machines Corporation | System and method for selecting and scheduling corrective actions for automated storage management |
US20120023209A1 (en) * | 2010-07-20 | 2012-01-26 | Robert Adam Fletcher | Method and apparatus for scalable automated cluster control based on service level objectives to support applications requiring continuous availability |
-
2011
- 2011-02-22 US US13/032,409 patent/US8924658B1/en active Active
-
2014
- 2014-12-29 US US14/585,084 patent/US20150370486A1/en not_active Abandoned
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090327618A1 (en) * | 2008-04-17 | 2009-12-31 | Kristal Pollack | Method for Self Optimizing Value Based Data Allocation Across A Multi-Tier Storage System |
US20110078682A1 (en) * | 2008-05-28 | 2011-03-31 | Don Vinh Doan | Providing Object-Level Input/Output Requests Between Virtual Machines To Access A Storage Subsystem |
US20110010445A1 (en) * | 2009-07-09 | 2011-01-13 | Hitachi Data Systems Corporation | Monitoring application service level objectives |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2019217030A1 (en) * | 2018-05-07 | 2019-11-14 | Apple Inc. | Techniques for managing memory allocation within a storage device to improve operation of a camera application |
US10852968B2 (en) | 2018-05-07 | 2020-12-01 | Apple Inc. | Techniques for managing memory allocation within a storage device to improve operation of a camera application |
Also Published As
Publication number | Publication date |
---|---|
US8924658B1 (en) | 2014-12-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8924658B1 (en) | Dynamic storage management using virtual storage appliances | |
US11263057B2 (en) | Dynamic instantiation and management of virtual caching appliances | |
US10254991B2 (en) | Storage area network based extended I/O metrics computation for deep insight into application performance | |
US8244868B2 (en) | Thin-provisioning adviser for storage devices | |
US8595364B2 (en) | System and method for automatic storage load balancing in virtual server environments | |
US9049204B2 (en) | Collaborative management of shared resources | |
US8782335B2 (en) | Latency reduction associated with a response to a request in a storage system | |
US10469582B2 (en) | Methods and systems for managing provisioning requests in a networked storage environment | |
US9542293B2 (en) | Method and system for collecting and pre-processing quality of service data in a storage system | |
US11856054B2 (en) | Quality of service (QOS) setting recommendations for volumes across a cluster | |
US9571356B2 (en) | Capturing data packets from external networks into high availability clusters while maintaining high availability of popular data packets | |
US20160004476A1 (en) | Thin provisioning of virtual storage system | |
US20220171663A1 (en) | Systems and Methods for Resource Lifecycle Management | |
US10725944B2 (en) | Managing storage system performance | |
US11122123B1 (en) | Method for a network of storage devices | |
US10761726B2 (en) | Resource fairness control in distributed storage systems using congestion data | |
US9778883B2 (en) | Methods and systems for resource management in a networked storage environment | |
CN116057507A (en) | Storage level load balancing | |
US9135191B1 (en) | Techniques for storage network bandwidth management | |
US10901654B2 (en) | Buffer credit management in a data storage system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: NETAPP, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BAIRAVASUNDARAM, LAKSHMI NARAYANAN;GOODSON, GARTH;MATHUR, VIPUL;AND OTHERS;SIGNING DATES FROM 20110208 TO 20110504;REEL/FRAME:037253/0317 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |