Patent ID: 12197306

DETAILED DESCRIPTION

Improved techniques for processing storage cluster performance metrics distribute the work of recording storage cluster performance across storage appliances of a storage cluster. Certain techniques utilize a migration status table that tracks the progress of storage object migrations across storage appliances of a storage cluster. Migration status information within the migration status table may dictate whether to disregard certain performance metrics from a particular storage appliance in order to avoid duplicate sets of performance metrics due to storage object migration. Moreover, such a technique may utilize a snapshot of the migration status table rather than the migration status table itself, e.g., to prevent contention events, to avoid data inaccuracies, etc. With duplicate sets of performance metrics avoided, a performance analysis may be competently based on the exported performance metrics and operation of the storage cluster may be reliably adjusted according to the performance analysis.

FIG.1shows a data storage environment120having a storage cluster which distributes storage cluster performance metrics recording work across storage appliances of the storage cluster in accordance with certain embodiments. As will be explained in further detail later, the data storage environment120may utilize a migration status table to avoid processing duplicate sets of performance metrics during storage object migration thus enabling reliable performance analysis.

As shown inFIG.1, the data storage environment120includes host computers122(1),122(2), . . . (collectively, host computers122), a storage cluster124, a communications medium126, and perhaps other devices128.

The host computers122are constructed and arranged to perform useful work. For example, one or more of the host computers122may operate as a file server, a web server, an email server, an enterprise server, a database server, a transaction server, combinations thereof, etc. which provides host input/output (I/O) requests130to the storage cluster124. In this context, the host computers122may provide a variety of different I/O requests130(e.g., block and/or file based write commands, block and/or file based read commands, combinations thereof, etc.) that direct the storage cluster124to store host data132within and retrieve host data132from storage (e.g., primary storage or main memory, secondary storage, tiered storage, combinations thereof, etc.).

The storage cluster124includes a set of storage appliances140which is constructed and arranged to perform data storage operations (e.g., to store and retrieve the host data132on behalf of the host computers122). For effective fault tolerance and/or load balancing, the set of storage appliances140includes at least two storage appliances140(e.g., two, three, four, etc.).

The storage appliances140include storage processing circuitry150and storage arrays152. Along these lines, the storage appliance140(A) includes storage processing circuitry150(A) and a storage array152(A). Similarly, the storage appliance140(B) includes storage processing circuitry150(B) and a storage array152(B). Likewise, the storage appliance140(C) includes storage processing circuitry150(C) and a storage array152(C), and so on. The storage cluster124is illustrated as having at least three storage appliances140by way of example only.

The storage processing circuitry150may include one or more storage processors (SPs) or engines, data movers, director boards, blades, I/O modules, storage device controllers, switches, other hardware, combinations thereof, and so on. With at least two hardware SPs, the storage processing circuitry150of a storage appliance140enjoys fault tolerance and is capable of load balancing.

The storage arrays152include storage devices (e.g., NVRAM devices, SSDs, hard disk drives, combinations thereof, etc.). When different types of storage devices are available, the storage arrays152are capable of providing different storage tiers having different storage characteristics (e.g., different access times, different storage capacities, different types of data protection schemes, combinations thereof, etc.). Additionally, the storage devices may be separated into different groups to provide different fault domains where the failure of a particular storage device only impacts data within a particular fault domain.

The communications medium126is constructed and arranged to connect the various components of the data storage environment120together to enable these components to exchange electronic signals160(e.g., see the double arrow160). At least a portion of the communications medium126is illustrated as a cloud to indicate that the communications medium126is capable of having a variety of different topologies including backbone, hub-and-spoke, loop, irregular, combinations thereof, and so on. Along these lines, the communications medium126may include copper-based data communications devices and cabling, fiber optic devices and cabling, wireless devices, combinations thereof, etc. Furthermore, the communications medium126is capable of supporting LAN-based communications, SAN-based communications, cellular communications, WAN-based communications, distributed infrastructure communications, other topologies, combinations thereof, etc.

The other devices128represent other possible componentry of the data storage environment120. Along these lines, the other devices128may include remote data storage equipment that provides data to and/or receives data from the storage cluster124(e.g., replication arrays, backup and/or archiving equipment, service processors and/or management/control devices, etc.).

During operation, the storage cluster124performs data storage operations in response to the I/O requests130from the host computers122. It should be appreciated that the storage cluster124may provide a variety of specialized services and features such as deduplication, compression, encryption, garbage collection, tiering, snapshotting, backup/archival services, replication and/or failover to other data storage equipment, data recovery, and so on. In some arrangements, the storage cluster124itself may run host-based applications thus providing a platform with integrated host services.

During such operation, the storage cluster124may handle (or treat) various storage-related constructs in an objectized manner, i.e., as storage objects. Examples of such storage object constructs, which are referred to hereinafter as storage objects170, include virtual machines (VMs), virtual volumes (VVOLs), logical units of storage (LUNs), and the like. Other constructs may be treated as storage objects as well such as file systems, files, sections of memory, complex data structures, combinations thereof, and so on.

In accordance with certain embodiments, the storage cluster124protects the host data132using one or more Redundant Array of Independent Disks (RAID) level protection schemes. Suitable RAID levels include, by way of example only, RAID 1, RAID 5, RAID 6, RAID 10, etc.

In accordance with certain embodiments, one or more storage appliances140of the storage cluster124utilizes a mapped-RAID architecture. For example; the storage appliance140(A) may implement RAID5(4+1) within a RAID resiliency set (RRS) (i.e., a first fault domain) having many storage devices (e.g., six, eight, 25, 64, etc.). The storage appliance140(A) may further provide other RRSs with the same or different RAID levels. Likewise, other storage appliances140may provide similar RRSs.

While the storage cluster124performs data storage operations on behalf of the host computers122, the storage cluster124records performance metrics. In particular, the metrics recording work is distributed across the storage appliances140such that one storage appliance140does not perform all of the recording work. Along these lines, the storage appliances140individually record appliance-specific performance metrics relating to locally owned (or managed) storage objects170into a local appliance database. There may also be a primary storage appliance140(i.e., a designated storage appliance140) that records cluster metrics relating to the overall cluster into a cluster database. Such distribution of metrics recording work among the multiple appliances140provides better load balancing and improves scalability. Further details of such metrics recording and processing will now be provided with reference toFIG.2.

FIG.2shows certain details of a storage cluster124in accordance with certain embodiments (also seeFIG.1). As shown, the storage processing circuitry150of each storage appliance140of the storage cluster124includes multiple SPs. Additionally, the storage array152of each storage appliance140stores regular data200(also see the host data132ofFIG.1) and local performance metrics210. Furthermore, one of the storage appliances of the storage cluster124is designated for storing cluster performance metrics220.

During operation, the SPs of the storage processing circuitry150of the storage appliances140process I/O requests130(i.e., write and read commands) from one or more host computers122(also seeFIG.1) in a fault tolerant and/or load balanced manner During such operation, the storage processing circuitry150records performance metrics which, when subsequently evaluated, provides insights to control further operation of the storage cluster124.

In accordance with certain embodiments, the storage cluster124refers to various storage-related constructs such as VMs, VVOLs, LUNs, etc. as storage objects170(FIG.1). As shown by way of example only inFIG.2, the regular data200(A) within the storage array152(A) of the storage appliance140(A) includes storage objects170(1) and170(2). Additionally, the regular data200(B) within the storage array152(B) of the storage appliance140(B) includes a storage object170(3). Furthermore, the regular data200(C) within the storage array152(C) of the storage appliance140(C) includes a storage object170(C).

It should be appreciated that the arrangement described above is provided by way of example only, and that other arrangements are possible. Along these lines, the storage cluster124may include a different number of storage appliances140(e.g., two, four, five, etc.). Additionally, the storage object situation within the storage cluster124may be different where each storage array152includes any number of storage objects170at a particular time of operation.

Moreover, it should be understood that the storage cluster124may migrate the storage objects170among the storage appliances140over time. Along these lines, suppose that a determination is made to migrate the storage object170(2) (e.g., a VVOL) from the storage array152(A) of the storage appliance140(A) to the storage array52(B) of the storage appliance40(B). Such a determination may be made based on an automatically triggered evaluation (e.g., periodic, scheduled, event driven, combinations thereof, etc.) of the performance metrics210,220recorded by the storage cluster124. Additionally, such a determination may be targeted at improving current storage cluster performance, improving future storage cluster performance, freeing resources for one or more additional modifications to the storage cluster124, freeing resources for a scheduled operation by the storage cluster124, combinations thereof, and so on.

When the storage cluster124migrates a storage object170from one storage appliance140to another storage appliance140, the storage cluster124maintains (e.g., stores and updates) a migration status table (MST)230to enable tracking of the migration operation over time. Access to the migration status table230by the storage appliances140is illustrated by the double arrow232inFIG.2.

Below is an example format for an entry of the migration status table230.

Object IDSource NodeDestination NodeState
The Object ID field of the entry stores an object identifier that uniquely identifies a particular storage object170within the storage cluster124. The Source Node field stores a storage appliance identifier that uniquely identifies a particular storage appliance140of the storage cluster124that serves as a source (or initial location) for the storage object170. The Destination Node field stores a storage appliance identifier that uniquely identifies another storage appliance140of the storage cluster124that serves as a destination (or subsequent location) for the storage object170. The State field stores a current migration state for the storage object170. It should be understood that other fields are suitable as will for the MST entry such as a timestamp, the type of storage object170(e.g., VM, VVOL, etc.), and so on.

In accordance with certain embodiments, for each storage object170within the storage cluster124, the storage processing circuitry150of the storage appliance140that currently manages (or owns) that storage object170is responsible for updating the migration state for that storage object170in the corresponding MST entry. Accordingly, the migration status table230reflects the current storage object migration situation within the storage cluster124. However, the recording work is distributed among multiple storage appliances140rather than a single storage appliance140thus improving scalability.

Moreover, it should be appreciated that the responsible manager (or owner) of the storage object170may change over time if the storage object170migrates across storage appliances140. Along these lines, when a storage object170migrates from one storage appliance140to another storage appliance140, the storage appliance140that currently manages the storage object updates the entry corresponding to the storage object170in the migration status table230to indicate that the migrate state of the storage object170is “PENDING” thus indicating that the migration operation is in progress. Additionally, the storage appliance140that currently manages the storage object170may further update the entry corresponding to the storage object170in the migration status table130to indicate that the migrate state of the storage object170with “SUCCESS” thus indicating that the migration operation has properly completed. Furthermore, the storage appliance40that currently manages the storage object170may further update the entry corresponding to the storage object170in the migration status table230after a period of time has passed since the migration operation completed with “REMOVE” thus indicating that the entry is no longer needed. Other states are suitable for use as well such as “HALTED, “FAILED”, etc. to identify other migration situations for the storage object170.

It should be understood that a variety of formats are suitable for use by the migration status table230. In some arrangements, the migration status table230has an entry that corresponds to each storage object170in the storage cluster124and the storage cluster124updates the state of an entry when the storage object170corresponding to that entry migrates. In other arrangements, the migration status table230takes the form of a historical log of entries. Other foiiiiats are suitable for use as well such as databases, linked lists, trees, and so on.

When the migration status table230takes the form of a historical log, a background service may routinely cleanup the migration status table230(e.g., consolidate entries, remove very old entries, etc.) to reduce the size of the migration status table130. For example, the specialized circuitry250may wake up periodically (e.g, once an hour, a day, a week, etc.) and remove any entries from the migration status table130having a “REMOVE” state.

Although storage object migration may begin automatically (e.g., due to an event, based on a schedule, etc.), it should be further understood that storage object migration may be initiated manually. For example, a human operator may provide a command to the storage cluster124to manually migrate the storage object170(2) from the storage array152(A) of the storage appliance140(A) to the storage array152(B) of the storage appliance140(B).

It should be further appreciated that storage object migrations may occur simultaneously. For example, while the storage object170(2) migrates from the storage array152(A) of the storage appliance140(A) to the storage array152(B) of the storage appliance140(B), one or more other storage objects170may migrate from one storage appliance140to another. Moreover, during such storage object movement within the storage cluster124, the storage cluster124continues to process I/O requests130on behalf of one or more host computers122.

During storage cluster operation, the performance metrics210,220are recorded within the storage arrays152. Such performance metrics210,220may vary over time and are thus recorded in a time-based manner (e.g., with timestamps).

As mentioned earlier, rather than impose the performance metric recording work on only one component of the storage cluster124(e.g., a single storage application) which does not scale well, the performance metric recording work is distributed across the storage appliances140. Such recording work distribution removes imposing the recording work on just one storage appliance140thus removing the threat of that storage appliance140becoming a bottleneck or overtasked.

Instead, each storage appliance140records performance metrics for the storage objects170managed (or owned) by that storage appliance140. Such an arrangements provides fairer distribution of the recording work load and improves scalability. Examples of suitable performance metrics include I/Os per second (or IOPs), storage consumption, and processor utilization, among others.

It should be appreciated that when a storage object170migrates from a first storage appliance140to a second storage appliance140, the performance metrics (which also may be treated as a storage object170) migrates from the first storage appliance140to the second storage appliance140. Accordingly, the performance metrics travel across storage appliances140with the storage objects170during migration.

The designated storage appliance140is constructed and arranged to record cluster performance metrics220pertaining to the storage cluster124as a whole. In accordance with certain embodiments, this task of recording the cluster performance metrics (e.g., aggregate IOPs for the storage cluster124, aggregate storage consumption, aggregate processor utilization, etc.) may be migrated from a first storage appliance140to a second storage appliance140. In such a situation, the cluster performance metrics220is moved from the first storage appliance140to the second storage appliance140.

As shown inFIG.2, specialized circuitry250is constructed and arranged to export the recorded performance metrics210from the storage arrays152to an archive260while the storage cluster124operates to process I/O requests130on behalf of one or more host computers122(FIG.1). In accordance with certain embodiments, the specialized circuitry250performs such exporting periodically (e.g., every two minutes, every five minutes, every 10 minutes, every 15 minutes, etc.).

In accordance with certain embodiments, the specialized circuitry250is further constructed and arranged to perform an analysis of the archived performed metrics to provide insights to improving the operation of the storage cluster124. Along these lines, suppose that a particular storage object170at a particular storage appliance140is not performing in accordance with certain requirements (e.g., low I/O latency at certain times due to high traffic, running out of capacity, combinations thereof, etc.) while other storage appliances140have excess resources. In such a situation, the specialized circuitry250may perform a migration operation (or may provide a migration recommendation that a human operator simply approves/initiates) which relocates the particular storage object170from the particular storage appliance140to a new storage appliance140. Once the particular storage object is relocated to the new storage appliance140, the particular storage object170may perform in accordance with the requirements. Accordingly, such an adjusting operation provides a modification to the storage cluster124in a manner that improves an operating characteristic such as performance of the particular storage object170.

It should be appreciated that, while the storage cluster124processes I/O requests130on behalf of one or more host computers122, the specialized circuitry250may perform performance metrics exporting, analysis, and/or adjusting operations in the background (e.g., in a manner that is transparent to the host computers122). In particular, the specialized circuitry250provides a bulk metrics service by periodically exporting recorded performance metrics from the local performance metrics210and the cluster perfoimance metrics220into the archive260. Along these lines, in a processing run, the specialized circuitry250may export the local performance metrics210from the storage appliances140to the archive260one at a time: retrieving the local performance metrics210(A) from the storage appliance140(A) (arrow270(A) inFIG.2), retrieving the local performance metrics210(B) from the storage appliance140(B) (arrow270(B), retrieving the local performance metrics210(C) from the storage appliance140(C) (arrow270(C), and so on. Additionally, in the processing run, the specialized circuitry250may export the cluster performance metrics220from the designated storage appliance140(arrow272).

Once the specialized circuitry150archives the performance metrics210,220(arrows270,272), the specialized circuitry250may evaluate the performance metrics210,220and/or adjust operation of the storage cluster124based on such an evaluation. In some embodiments the specialized circuitry250and/or the archive260resides within the storage cluster124(e.g., within a storage appliance140). In other embodiments, the specialized circuitry250and/or the archive260is external to the storage cluster124(e.g., in a host computer122, in another device128, etc.). Further details will now be provided with reference toFIG.3.

FIG.3shows certain details for using the migration status table230in accordance with certain embodiments. Suppose that the storage cluster124migrates the storage object170(2) from the storage appliance140(A) to the storage appliance140(B). That is, suppose that the storage object170(2) initially resides within the storage array152(A) of the storage appliance140(A) as shown inFIG.2. Then, as point time thereafter, the storage cluster124migrates (e.g., arrow300) the storage object170(2) from the storage array152(A) of the storage appliance140(A) to the storage array152(B) of the storage appliance140(B) as shown inFIG.3.

When the storage cluster124begins this migration operation, the storage cluster124updates the migration status table230so that an entry of the migration status table230indicates that the storage object170(2) is currently migrating. In particular, the storage cluster124provides the entry with a “PENDING” state. Below is an example entry in the migration status table230for the storage object170(2).

Object IDSource NodeDestination NodeStateef137ca3ABPENDING
Here, “ef137ca3” is an example object identifier that uniquely identifies the storage object170(2) within the storage cluster124. Additionally, “A” is an example storage appliance identifier that uniquely identifies the storage appliance140(A) within the storage cluster124as the initial location of the storage object170(2). Similarly, “B” is an example storage appliance identifier that uniquely identifies the storage appliance140(B) within the storage cluster124as the subsequent location of the storage object170(B). Furthermore, “PENDING” indicates that the storage object170(2) is in the state of migrating from the initial location to the subsequent location (i.e., that the migration operation has started but not finished).

When the storage cluster124properly completes the migration operation, the storage cluster124updates the migration status table230so that the entry of the migration status table230indicates that the storage object170(2) has successfully migrated. In particular, the storage cluster124provides the entry with a “SUCCESS” state. Below is the example entry for the storage object170(2) after the example entry is updated following proper completion of the migration operation.

Object IDSource NodeDestination NodeStateef137ca3ABSUCCESS
Here, “SUCCESS” indicates that the storage object170(2) has successfully migrated from the initial location to the subsequent location (i.e., the migration operation has properly finished).

As mentioned earlier, the storage cluster124may migrate multiple storage objects170concurrently. During such multiple migration situations, multiple entries within the migration status table230reflect current migration states for the storage objects170that are migrating.

It should be understood that the specialized circuitry250that is constructed and arranged to export, analyze, and adjust operation of the storage cluster124is further capable of accessing the MST entries of the migration status table230. Along these lines, the specialized circuitry250creates a migration status table (MST) snapshot320of the migration status table230. The specialized circuitry250then accesses the entries from the MST snapshot320.

It should be appreciated that, by accessing the MST snapshot320rather than the original migration status table230itself, there is no need to impose any locks, semaphores, and/or other access control mechanisms to preserve consistency of the entries. Accordingly, there are no MST contention issues that could otherwise cause operational delays/latency.

As explained above, the specialized circuitry250provides a bulk metrics service by periodically exporting the recorded performance metrics from the local performance metrics210and the cluster performance metrics220to the archive260. For example, the bulk metrics service may wake up every five minutes to access such metrics210,220in order to export newly recorded metrics to the archive260. As a result, the archived metrics may be analyzed with an aim of improving cluster operation and/or performance. Along these lines, a human administrator may run a script that accesses the archived metrics to graphically plot a history of cluster operation over a period time.

It should be appreciated that, without certain safeguards, particular bulk metrics service operations may cause the archived metrics to inaccurately describe cluster operation. For example, suppose that as the storage cluster124performs a storage object migration operation in which a particular storage object such as a VM or a VVOL migrates (or moves) from a source storage appliance140to a destination storage appliance140. During such operation, the recorded performance metrics associated with that particular object also migrate from the source storage appliance140to the destination storage appliance140.

Further suppose that, during the storage object migration operation, the bulk metrics service wakes up (e.g., see the specialized circuitry250inFIG.3) and accesses the performance metrics210,220in order to export newly recorded metrics to the archive260. In such a situation, if it were not for utilization of the migration status table230, it could be possible for the bulk metrics service to export the recorded metrics for the migrating storage object170from the local performance metrics210of the source storage appliance140as well as the local performance metrics210of the destination storage appliance140. That is, the recorded metrics for the associated with the particular storage object170could otherwise be stored in the archive260twice. If the archive260had duplicate metrics, an evaluation operation and/or a graphical plot of the history for the particular storage object170would show multiple data points for the time of storage object migration and such multiple data points could be detrimental to an evaluation of the metrics for insights to improve operation of the storage cluster124.

However, for a single storage object170that migrates from a first storage appliance140to a second storage appliance140, the specialized circuitry250ensures that duplicate sets of metrics are not archived. Rather, even if performance metrics for a migrating storage object170reside in both the local performance metrics210of the first storage appliance140and the local performance metrics210of the second storage appliance140, the specialized circuitry250stores the local performance metrics210from only one of the storage appliances140.

To this end, after the specialized circuitry250creates the snapshot320, the specialized circuitry250reads the entry for the storage object170from the snapshot320. If the state of the migration operation is “PENDING”, the specialized circuitry250exports the performance metrics for the storage object170from the local performance metrics210of the storage appliance140identified as the source node (or simply source). That is, the specialized circuitry250disregards the performance metrics for the storage object170from the local performance metrics210of the storage appliance140identified as the destination node (or simply destination). Accordingly, while the state of the migration operation is “PENDING” for the storage object170, the specialized circuitry250exports just one set of performance metrics for the storage object170, i.e., the performance metrics from the first storage appliance140.

However, if the state of the migration operation is “SUCCESS”, the specialized circuitry250exports the performance metrics for the storage object170from the local performance metrics210of the storage appliance140identified as the destination node (or simply destination). That is, the specialized circuitry250disregards the performance metrics for the storage object70from the local performance metrics110of the storage appliance40identified as the source. Accordingly, while the state of the migration operation is “SUCCESS” for the storage object170, the specialized circuitry250again exports just one set of performance metrics for the storage object170, i.e., the performance metrics from the second storage appliance140.

As a result of exporting just one set of performance metrics for the storage object170, any evaluation of the exported performance metrics will not be inadvertently based on multiple sets. Thus, evaluation will be reliable, and any adjustments to the operation of the storage cluster124based on the evaluation will be sound, i.e., based on accurate information. Further details will now be provided with reference toFIG.4.

FIG.4shows electronic circuitry400which is suitable for use as at least a portion of the specialized circuitry250(also seeFIGS.2and3) in accordance with certain embodiments. The electronic circuitry400includes a set of interfaces402, memory404, processing circuitry406, and other circuitry (or componentry)408.

The set of interfaces402is constructed and arranged to connect the electronic circuitry400to the communications medium126(also seeFIG.1) to enable communications with other devices of the data storage environment120(e.g., the host computers122, the storage cluster124, combinations thereof, etc.). Such communications may be IP-based, SAN-based, cellular-based, cable-based, fiber-optic based, wireless, cloud-based, combinations thereof, and so on. Accordingly, the set of interfaces402may include one or more host interfaces (e.g., a computer network interface, a fibre-channel interface, etc.), one or more storage device interfaces (e.g., a host adapter or HBA, etc.), and other interfaces. As a result, the set of interfaces402enables the electronic circuitry400to robustly and reliably communicate with other external apparatus.

The memory404is intended to represent both volatile storage (e.g., DRAM, SRAM, etc.) and non-volatile storage (e.g., flash memory, magnetic memory, etc.). The memory404stores a variety of software constructs420including an operating system422, specialized instructions and data424, and other code and data426. The operating system422refers to particular control code such as a kernel to manage computerized resources (e.g., processor cycles, memory space, etc.), drivers (e.g., an I/O stack), and so on. The specialized instructions and data424refers to particular instructions for exporting performance metrics from the storage cluster124to the archive260, evaluating the performance metrics from the archive260, and/or adjusting operation of the storage cluster124based on such evaluation. In some arrangements, the specialized instructions and data424is tightly integrated with or part of the operating system422itself. The other code and data426refers to applications and/or routines to provide additional operations and services (e.g., display tools, etc.), user-level applications, administrative tools, utilities, and so on.

The processing circuitry406is constructed and arranged to operate in accordance with the various software constructs420stored in the memory404. As is explained in further detail herein, the processing circuitry406executes the operating system422and the specialized code424to form the specialized circuitry250which performs improved operations. In some embodiments, the processing circuitry406and other software constructs further forms the storage processing circuitry150that robustly and reliably manages host data on behalf of a set of host computers122(also seeFIG.1). Such processing circuitry406may be implemented in a variety of ways including via one or more processors (or cores) running specialized software, application specific ICs (ASICs), field programmable gate arrays (FPGAs) and associated programs, discrete components, analog circuits, other hardware circuitry, combinations thereof, and so on.

In the context of one or more processors executing software, a computer program product440is capable of delivering all or portions of the software constructs420to the electronic circuitry300. In particular, the computer program product440has a non-transitory (or non-volatile) computer readable medium which stores a set of instructions that controls one or more operations of the electronic circuitry400. Examples of suitable computer readable storage media include tangible articles of manufacture and apparatus which store instructions in a non-volatile manner such as DVD, CD-ROM, flash memory, disk memory, tape memory, and the like.

The other componentry408refers to other hardware of the electronic circuitry400. Along these lines, the electronic circuitry400may include special user I/O equipment (e.g., a service processor, a device to graphically display renderings of the performance metrics, etc.), power supplies and battery backup units, auxiliary apparatuses, other specialized data storage componentry, etc.

It should be further understood that certain portions of the electronic circuitry400may reside together to form one or more storage controllers (or storage processors). In accordance with certain embodiments, the electronic circuitry400includes multiple storage controller devices for fault tolerance and/or load balancing purposes. Further details will now be provided with reference toFIG.5.

FIG.5shows a procedure500which is performed by specialized circuitry of the data storage environment120(FIG.1) in accordance with certain embodiments. The procedure500enables the specialized circuitry to process storage cluster performance metrics reliably in a manner that ensures multiple sets of the same performance metrics will not be processed for a migrating storage object. Performance of one or more activities within the procedure400may be triggered periodically (e.g., every five minutes or some other interval).

At502, the specialized circuitry obtains access to performance metrics from storage appliances of a storage cluster. Along these lines, the specialized circuitry is able to connect with the storage appliances in order to export local performance metrics to an archive. As mentioned earlier in connection withFIGS.2and3, the performance metrics identifies performance for storage objects managed by the storage appliances.

At504, the specialized circuitry, after access to the performance metrics is obtained, disregards a duplicate set of performance metrics for a storage object that migrates from a first storage appliance of the storage cluster to a second storage appliance of the storage cluster. Here, the specialized circuitry avoids accessing multiple sets of the performance metrics covering the same time interval for the storage object that migrates. Instead, based on an entry within a migration status table, the specialized circuitry ignores the duplicate set of performance metrics for the storage object.

At506, the specialized circuitry, after the duplicate set of performance metrics is disregarded, archives the performance metrics to an archive. Here, the specialized circuitry exports only one set of performance metrics for the storage object to the archive for a particular time interval based on an entry in the migration status table.

At508, in accordance with certain embodiments, the specialized circuitry provides a performance analysis based on the performance metrics from the archive. Additionally, in accordance with certain embodiments, the specialized circuitry adjusts operation of the storage cluster according to the performance analysis.

In some arrangements, the performance analysis includes a storage appliance loading assessment. Accordingly, the adjustment operation may involve rebalancing the storage objects across the storage appliances based on the storage appliance loading assessment.

In some arrangements, the performance analysis includes a storage appliance resource assessment. Accordingly, the adjustment operation may involve locating a new storage object among the storage appliances based on the storage appliance resource assessment.

Other activities are suitable for use in508or in combination with508. For example, performance aspects for one or more storage objects or even the storage cluster as a whole may be displayed graphically to a human user (e.g., an administrator or storage cluster operator). As another example, performance aspects for one or more storage objects or even the storage cluster as a whole may be used to identify issues, deficiencies, problems, etc. for rectification within the storage cluster, and so on. Further details will now be provided with reference toFIG.6.

FIG.6shows a diagram600having details for a general policy that avoids inadvertent processing of duplicate sets of information in accordance with certain embodiments. Within the diagram600, there are multiple devices A, B with databases of information. For example, each device A, B may have a respective object table database and objects within the respective object table databases may migrate from one object table database to the other.

To avoid processing duplicate sets of information at a particular time (i.e., an entry for the same object from both object tables) at a particular time, the state of the object migration may be evaluated. Along these lines, suppose that the object is migrating from device A to device B. Early in the process, the migration state of the object may be set to “PENDING” and thus the policy directs the information to be exported from the database of device A and not from the database of device B. However, later in the process if the migration state changes from “PENDING” to “SUCCESS”, the policy directs the information to be exported from the database of device B and not from the database of device A.

Accordingly, the processing circuitry receives only one set of information for further processing. As a result, such further processing is reliable and sound (i.e., not corrupted by a duplicate set of information).

As described above, improved techniques process storage cluster performance metrics. Certain techniques utilize a migration status table that tracks the progress of storage object migrations across storage appliances of a storage cluster. Migration status information within the migration status table may dictate whether to disregard certain performance metrics from a particular storage appliance in order to avoid duplicate sets of performance metrics due to storage object migration. Moreover, such a technique may utilize a snapshot of the migration status table rather than the migration status table itself, e.g., to prevent contention events, to avoid data inaccuracies, etc. With duplicate sets of performance metrics avoided, a performance analysis may be competently based on the performance metrics and operation of the storage cluster may be reliably adjusted according to the performance analysis.

While various embodiments of the present disclosure have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present disclosure as defined by the appended claims.

For example, it should be understood that various components of the data storage environment120such as one or more host computers122and/or one or more other devices128are capable of being implemented in or “moved to” the cloud, i.e., to remote computer resources distributed over a network. Here, the various computer resources may be distributed tightly (e.g., a server farm in a single facility) or over relatively large distances (e.g., over a campus, in different cities, coast to coast, etc.). In these situations, the network connecting the resources is capable of having a variety of different topologies including backbone, hub-and-spoke, loop, irregular, combinations thereof, and so on. Additionally, the network may include copper-based data communications devices and cabling, fiber optic devices and cabling, wireless devices, combinations thereof, etc. Furthermore, the network is capable of supporting LAN-based communications, SAN-based communications, combinations thereof, and so on.

It should be understood that, in former approaches, it is possible to get duplicate object entries. Such duplicate object entries could make subsequent evaluations, analyses, etc. inaccurate.

However, in accordance with certain embodiments, improved techniques involve eliminating object metrics duplicates during migration in a distributed data collection system. Along these lines, an efficient cluster-based system has distributed metrics collection across appliances for load balancing for system objects. Such load balancing may involve object migration between different system components. Additionally, collected metrics data must be migrated for the components.

To avoid getting duplicate object entries, improved techniques involve using a migration status table to track the progress and using a snapshot of the migration status table for duplicate in accordance with certain embodiments. It should be appreciated that using a stale cached table rather than the original table during ongoing data collection will ensure there is no migration status change during a collection run. Rather, it is easy to know what data and on which appliance the data was collected.

In accordance with certain embodiments, the local database collection requires a foreign table of the cached objects migration table. That is, the foreign table may be a copy (or snapshot) and thus the same as the original foreign migration table.

It should be understood that tests for existing systems show that metrics collection for a cluster is faster than any object migration. Accordingly, in accordance with certain embodiments, there are no cases of an object migration starting and finishing during collection. Also, FROM metrics data shall be removed from the original appliance only if PENDING-SUCCESS-REMOVE time is bigger than query execution time.

It should be further understood that in other situations, additional enhancements are provided such as:1. The data collection process is followed by a post-processing step to add missing data entries. The missing entries shall be found by comparing status differences (e.g., status change during collection) between the context table and the cached or copied context table.2. Data removal from a source appliance is delayed by a time that is longer than the data collection time. Without tests, the delay time shall not be bigger than 20-30 seconds.3. The cached or copied context table can be complemented by a repeatable read if the database supports certain advanced functionality such as PostgresSQL.

Moreover, it is possible that the bulk metrics service may miss archiving metrics for a migrating object. In such a situation, the possibility may occur on a system where bulk metrics collection time is greater than an object migration time.

The individual features of the various embodiments, examples, and implementations disclosed within this document can be combined in any desired manner that makes technological sense. Furthermore, the individual features are hereby combined in this manner to form all possible combinations, permutations and variants except to the extent that such combinations, permutations and/or variants have been explicitly excluded or are impractical. Support for such combinations, permutations and variants is considered to exist within this document. Such modifications and enhancements are intended to belong to various embodiments of the disclosure.