sci lab test validation report: netapp storage efficiency

Silverton Consulting, Inc. StorInt™ Briefing

SCI Lab Test Validation Report: NetApp Storage Efficiency

Written by: Ray Lucchesi Published: July 2012

SCI Lab Validation Report: NetApp Storage Efficiency

© 2012 Silverton Consulting, Inc. Page 1 All Rights Reserved twitter.com/RayLucchesi|RayOnStorage.com

+1-720-221-7270|SilvertonConsulting.com

Executive Summary Silverton Consulting tested a number of NetApp’s widely used software storage efficiency features on a FAS3240 storage system using a mix of data types. The testing was designed to measure the cumulative impact of multiple efficiency technologies when used together, and as a result, several test phases were required. The first phase tested three NetApp storage efficiency features. Specifically, the storage system was thick provisioned to create a baseline and then cumulatively thin provisioned, deduplicated and compressed, all using the same data. Storage capacity requirements were assessed after each step to measure any savings that occurred. At the end of this phase, the thinly provisioned, deduplicated and compressed storage saved an impressive 79% when compared with the baseline capacity requirements. The second phase examined two NetApp copy services: Snapshot™ and FlexClone™. During this phase, the storage at the end of the prior phase was first Snapshot copied and then FlexClone copied. Capacity requirements were again evaluated after each NetApp copy had completed to compare against the baseline. Once again, storage capacity requirements for both copies were substantially less than baseline. The final phase ran a mixed workload against the FlexClone copies of the previous phase to determine how capacity efficiency and copy services impacted performance for the storage system under test. In the first phase above, after creating the storage baseline, a set of database, email and file system workloads were run. For this phase those workloads were run once more, only this time against the deduplicated, compressed, and FlexClone copied data. This final step showed little to no performance degradation when using deduplicated, compressed and cloned data as compared against baseline performance.

Table of Contents

Executive Summary Introduction Test Step 1: Baseline

Cumulative storage efficiency Test Step 2: Thin provisioning Test Step 3: Data deduplication Test Step 4: Data compression

Copy services Test Step 5: Snapshot copy Test Step 6: FlexClone copy

Performance Test Step 7: Performance

Summary Appendices




SUMMARY: Cumulative Effect of NetApp Storage Efficiency Features

SUMMARY: Savings from NetApp Space Efficient Copy Features




Introduction NetApp recently contracted with Silverton Consulting Inc. (SCI) to independently validate the substantial storage capacity savings attainable with NetApp systems. The three storage efficiency features rigorously tested included thin provisioning, data deduplication and data compression. NetApp further engaged SCI to verify the storage copy efficiency capabilities of NetApp’s Snapshot and FlexClone features.1 In a final corollary phase of testing, SCI was asked to independently authenticate the I/O performance of the storage system with data already subjected to the efficiency features under trial.

NetApp storage system test environment One NetApp FAS3240 storage system running Data ONTAP 8.1 operating in 7-‐Mode, with ~20TB of SAS disk and 10GbE interfaces was installed at SCI’s lab. The storage was arranged as a RAID-‐DP configuration (19-‐data and 2-‐parity, using 450 GB SAS disk drives) with two (2TB) aggregates and five user volumes:

• One volume with 629GB of storage for a file system, • Two volumes configured as a 629GB iSCSI LUN for SQL Server database

tables and the second as a SQL log volume of ~105GB iSCSI LUN, • Two more volumes to hold iSCSI LUNs, one configured with 629GB for a

Microsoft Exchange database and the other LUN with ~42GB for an Exchange log file.

The storage system was equipped with 8GB of system RAM/cache and was connected to lab servers using three separate 10GbE interfaces, one for the file workload and two for the SQL database and email. No FlashCache or Fibre Channel interfaces were used during the testing. The specific NetApp system options employed to store this data were as follows:

• Volume Space Guarantee = volume • LUN Set Reservation = enable • Fractional Reserve = 100% • Snapshot Reserve (Aggregate and Volume) = 5%.

These system storage parameters were selected to establish a thickly provisioned baseline and insure that any space savings or consumption afforded by the storage efficiency features under further evaluation would be more accurately assessed. That is, the performance and capacity results experienced would be due solely to the storage efficiency feature under test.

1 For a customer case study on NetApp storage efficiency features see our report on Achieving Exceptional Storage Efficiency with NetApp Storage available at http://media.netapp.com/documents/ar-‐exceptional-‐data-‐density.pdf




Actual test process The actual test was a multi-‐step task where data was loaded to the storage then capacity measurements using NetApp/Windows facilities were taken initially to establish baseline. The same measurements were then taken again after thin provisioning, data deduplication and data compression were progressively enabled and the resulting transformation process was complete. Additionally, capacity measurements were taken after the workload was run to isolate and identify the data growth due solely to the workload process. The actual workload mixture used in the testing process was specifically designed to more closely emulate and approximate realistic operating conditions for a storage system. In addition, the three types of workloads were run simultaneously to better mirror real shared storage use operations; running any one of these workloads in isolation would have generated significantly different throughput. For performance, measurements were taken only after the baseline data was loaded and then again after all storage efficiency features were enabled. The measurements were reported on minutely over the concurrently working simulated file, SQL database and email workload runs. These measurements were derived by using Window’s Perfmon, running on each of the three VMs, executing the different workloads. Using this approach, individual performance measurements for each of the three workloads was determined. Because of the realistic workload design, high variability of performance measurements was expected and in fact, experienced during evaluation. As such, average performance was used to compare throughput operations between the baseline and final all features test step.

Test Step 1: Baseline To measure subsequent capacity savings and performance, the measurement tools were used to establish both baseline numbers after the data had been loaded onto the storage as well as after a simulated workload run. That is, the data was initially loaded and a workload processed with no storage efficiency features enabled; the resulting measurements were the baseline numbers for subsequent comparisons. Figure 1 Baseline capacity requirements summary chart




Baseline capacity parameters After the initial data was loaded but before any storage efficiency features were enabled, the capacity measurements reported by the Windows host validated the NetApp storage system measurements. In fact, the reported measurements were identical and as follows:

• File system storage -‐ 629.1GB • SQL DB storage – 629.1GB • SQL Log storage – 104.9GB • Email DB storage – 629.1GB • Email log storage – 41.9GB • Total baseline storage capacity – 2.0TB.

Baseline performance

Figure 2 Baseline performance run

Figure 2 graphs the performance achieved by the NetApp storage without enabling any capacity efficiency features. As can be seen, each type of workload, experienced wide variability as follows:




• The file workload varied between a high of ~70 MB/sec. to a low of ~3 MB/sec.,

• The SQL Server workload varied between ~134 and ~54 MB/sec., and • The email workload varied between ~37 and ~28 MB/sec.

However, average baseline performance, also depicted in Figure 2, showed mean throughput as follows:

• File services average performance was ~25 MB/sec. • SQL Server DB average performance was ~97 MB/sec. • Email average performance was ~33MB/sec.

Cumulative storage efficiency tests During this phase of the testing, we enabled NetApp thin provisioning, data deduplication and data compression features against the test data created during the baseline test step above. The intent of this phase of the testing was to determine what if any storage capacity requirements could be saved by an aggressive use of these features.

Test Step 2: Thin provisioning Although not required to apply thin provisioning, the data was reloaded in order to start from the same conditions, then thin provisioning was enabled in the next trial iteration by setting “Vol options guarantee=none” and “LUN set reservation=disable” for each volume and LUN. The thin provisioning feature saved capacity by freeing up unused space in partially used volumes and LUNs. Thin provisioning also allowed the creation of many more file systems and LUNs on the storage system (‘oversubscription’). Substantial savings were anticipated but were

dependent on how much empty, yet reserved space had been allocated to each volume as a result of using thick provisioning.

Thin provisioning capacity requirement savings

Figure 3 clearly shows the dramatic reduction in storage capacity requirements that enabling thin provisioning afforded. However, this savings was entirely dependent on the amount of allocated and never written space available. Comparing the baseline capacity to

Figure 3 Thin provisioning capacity requirements




the pre-‐workload capacity requirements using thin provisioning, the following available storage capacity requirements savings percentages were derived on this pass of the test:

• File system storage: 211.7GB, a substantial 66% savings over baseline capacity. With thin provisioning, the file system reserved only as much space as data written, releasing significant storage capacity for other use.

• SQL DB storage: 473.6GB, a moderate savings of 25% over baseline capacity. Thin provisioning freed up all of the SQL DB LUN’s reserved space that had yet to be written.

• SQL log storage: 1.2GB, an outstanding savings of 99% over baseline capacity. Much if not all of the log space had never been written.

• Email database storage: 414.0GB, a significant savings of 34% over baseline capacity. Similarly, thin provisioning freed up all email database reserved space.

• Email log storage: 0.1GB, another outstanding savings of over 99% from baseline capacity. Again, the same as that described above.

Overall, thin provisioning saved a remarkable 45+ percent of the capacity used in the baseline step. It should be noted that actual storage efficiency measurements for this and all remaining steps was calculated solely from internal NetApp storage commands. The Windows command that normally displays storage capacity does not recognize thin provisioning, deduplication or compression and thus, does not report on capacity savings or any measurement to derive capacity savings. In this step, the NetApp CLI “df -‐k” command was used.

Test Step 3: Data deduplication The next storage efficiency feature enabled in the trial was data deduplication on top of the already thinly provisioned storage. This feature was enabled and then run by issuing “sis on” and “sis start –s” commands at the volume level. NetApp’s deduplication feature was expected to reduce storage used by eliminating duplicate 4KB data blocks within a volume. However, the anticipated savings were expected to vary significantly depending on the amount of duplicate blocks present from volume-‐to-‐volume. Storage efficiency was calculated using the NetApp CLI “df –S” command.2

Data deduplication capacity requirement savings

As shown in Figure 4 below, data deduplication resulted in additional storage capacity savings. The significant reduction in used storage space was realized

2 NetApp has written a guide to implementing deduplication that can be found at http://media.netapp.com/documents/tr-‐3958.pdf




almost entirely due to the email and file system data being responsive to the dedupe process. Actual capacity savings after data deduplication were as follows:

• File system storage: 118.3GB of data stored, a 44% incremental savings over thin provisioning capacity requirements.

• SQL DB storage: 452.4GB of data stored, a slight, 4% incremental savings over thin provisioning capacity.

• SQL log storage: 18MB of data stored, a 99% incremental savings over thin provisioning capacity.

• Email database storage: 87.0GB of data stored, an impressive 79% incremental savings over thin provisioning capacity.

• Email log storage: 2MB of data stored, a 97% incremental savings over thin provisioning capacity.

Overall, data deduplication saved an additional 40+ percent of the capacity used in the thin provisioning step.

Test Step 4: Data compression Data compression, a compute intensive efficiency feature, was enabled for the thinly provisioned and deduplicated storage for the fourth pass by issuing a “sis config –C TRUE” command followed by initiating compression using the “sis start –S –C” command at the volume level. This command scanned all current volume and LUN data and automatically compressed it. This compression activity of the original data was completed prior to any further testing steps. However, by not using the “-‐I” option in the command above, offline compression was activated. NetApp does offer inline compression but offline was used to more closely emulate a customer that wanted the space savings of compression but executed off hours to minimize the impact on daily IO activity. The data compression feature was expected to increase free capacity by reducing repeating patterns of data within the volume. Storage efficiency was calculated using the NetApp CLI “df –S” command.

Data compression capacity requirement savings

As shown below in Figure 5, storage savings were moderate using the data compression feature against previously deduplicated and thinly provisioned data. However, these realized savings were only modest due to the inherent compressibility of the data. That is, image and zipped or archive (already compressed) files did not further compress well whereas Microsoft Office files were

Figure 4 Data deduplication capacity requirements




compressed by 50 percent or more. Database and email compressibility rates also varied considerably.

In this step, actual capacity savings after data compression were as follows:

• File system storage: 106.1GB of data stored, a 10% incremental savings over capacity present for the data deduplication step. This only modest savings was primarily due to the nature of

the test file data, which consisted of email and incompressible, image data. • SQL DB storage:229.2GB of data stored, a 49% incremental savings over

data deduplication capacity, primarily due to the amount of text and web log data present in the tables.

• SQL log storage: 17.8MB of data stored, a slight 2% incremental savings over data deduplication capacity.

• Email database storage: 87.0GB of data stored, a minimal <1% incremental savings over data deduplication capacity due to the nature of the test data used for email data.

• Email log storage: 1.8MB of data stored, a 13% incremental savings over data deduplication capacity.

Overall, compression saved an additional 36 percent of the capacity used in the deduplication step.

Copy services tests After storage capacity measurements for thin provisioning, data deduplication and data compression were established, a single set of Snapshot and FlexClone copies were taken of the test data. This was done to ascertain capacity requirement savings provided by NetApp’s point-‐in-‐time volume and LUN storage copies, i.e. read-‐only Snapshot copies and read-‐write FlexClone copies. Then the workload was run against the FlexClone copies. Both Snapshot and FlexClone copy capacity requirements were expected to be significantly smaller than source data capacity requirements. However, this presented a significant dilemma as to when to measure Snapshot and FlexClone

Figure 5 Data compression capacity requirements




capacity requirements. There are at least two very different alternatives: 1) Measure copy capacity requirements before a performance workload was run against the source data and 2) Measure copy capacity requirements after a performance workload was run against the source data. Pre-‐workload Snapshot and FlexClone copies only store meta-‐data to describe the data being copied and points to the original source data. In contrast, a post-‐workload Snapshot and FlexClone copies must store this meta-‐data plus any original data that was modified, thus consuming more storage capacity. As a result, post-‐workload copy capacity requirements were measured and compared with the post-‐workload baseline capacity measured in Test Step 1 (see p. 4).

Test Step 5: Snapshot copy In this step, Snapshot copies were taken of the data by using the “snap create” NetApp command. In Figure 6 below, post-‐workload Snapshot copies capacity requirements were measured and compared against the baseline capacity after the workload was run. The Snapshot copies were expected to be significantly smaller than source data as any storage capacity consumed should only represent data modified from the original.

Snapshot copy capacity requirement savings

Figure 6 clearly shows that the capacity requirements for the post-‐workload set of Snapshot copies were significantly smaller than the post-‐workload baseline source data. The capacity consumed by Snapshot copies only slightly registered on the chart as it represented the incremental space required to store any changes to the source data. Actual post-‐workload capacity measurements for the Snapshot copies were as follows:

• File system Snapshot storage: 6.8GB of data stored, an outstanding 99% savings over the capacity present for the baseline data file system.

• SQL DB Snapshot storage: 90.1GB of data stored, an 86% savings over the capacity present in the baseline SQL data.

• SQL log Snapshot storage: 7MB of data stored, a 100% savings over the capacity present in the baseline email log data.

• Email database Snapshot storage: 7.5GB of data stored, a 99% savings over

Figure 6 Snapshot copy capacity requirements




the capacity present in the baseline email database. • Email log Snapshot storage: <1MB of data stored, a 100% savings over the

capacity present in the baseline email log data. Of note, NetApp Snapshot capacity is entirely contingent upon the amount of data modified since the original Snapshot copies were taken. Thus, heavily modified data will consume more Snapshot space and may grow over time as the source data is updated.

Test Step 6: FlexClone copy As the next step in the rigorous testing of NetApp’s storage features, measurements were derived after taking NetApp FlexClone copies, another type of space efficient, point-‐in-‐time copy of source data. These copies differed from NetApp Snapshot copies because they could be written as well as read. Once again post-‐workload FlexClone capacity requirement measurements were measured and compared to post-‐workload baseline numbers to determine the capacity requirement savings. Once more, significant storage capacity requirement savings were anticipated for these copies of the source data.

FlexClone copy capacity requirement savings

As expected, the numbers generated in the trial and depicted in Figure 7, shows the significant storage capacity requirement savings available by taking a FlexClone copy of the source data. In this step, actual post-‐workload FlexClone capacities were as follows:

• File system FlexClone storage: 66.6GB, an 89% savings over the capacity present in the baseline data.

• SQL DB FlexClone storage: 200.9GB, a 68% savings over the capacity present in baseline SQL data.

• SQL log FlexClone storage: 65.2GB, a 34% savings over the capacity present in the baseline SQL log data.

• Email database FlexClone storage: 115.8GB, an 82% savings over the capacity present in the baseline email data.

• Email log FlexClone storage: 349MB, an 89% savings over the capacity present in the baseline email log data.

Figure 7 FlexClone copy capacity requirements




Similar to Snapshot copies, space savings from FlexClone copies depended on the amount of data modified from the original source storage. However, calculating the space used by FlexClone copies was more complex. In this case, the NetApp “vol clone split estimate” command was relied on to provide the amount of space shared between the source data and its clone. The space consumed by the clones was then calculated as the difference between the capacity used by the FlexClone data and the estimate of shared storage.

Performance testing

Test step 7: Thin provisioning, deduplication, compression, Snapshot and FlexClone performance results After all capacity efficiency features and copy services discussed above were enabled, baseline workloads were rerun to determine their impact on storage system performance. As discussed above, all the workloads were run against FlexClone copies with thin provisioning, deduplication, compression and Snapshot copy enabled and compared against a similar workload run against the original baseline data to test how these features and copy services would impact storage performance. System capacity requirements did not change from previous steps and have thus, not been reported on again (see pp. 9, 10 & 11).

Performance results after capacity efficiency and copy services were enabled

In Figure 8 below both the baseline and the capacity efficiency and copy services run results were shown side-‐by-‐side to facilitate easy comparison. Some impact from all the storage features was expected, but system performance significantly exceeded predictions.




Figure 8 Baseline vs. all features performance comparison chart

In fact, enabling NetApp’s space saving features of thin provisioning, data deduplication, compression along with Snapshot and FlexClone copy actually had a positive effect on storage performance during some of our testing. Specifically, no negative performance was seen. Performance of the all features enabled workloads were as follows:

• Average SQL DB performance: 118 MB/sec., an improvement of 22% versus the baseline performance.

• Average email performance: 40 MB/sec., an improvement of 24% over baseline performance.

• Average file system performance: only a slight negative performance impact, 24 MB/sec., for only a minor, <1% degradation over baseline performance, which could arguably be considered noise in the performance run.

Overall, total median performance also improved incrementally when all of the storage efficiency features were enabled. Also evident in Figure 8 is the increased variability of the all features run, i.e., the peak minus the minimum performance for each workload increased. However, most of this range difference was attributable to the higher performance of each workload.




Summary

In conclusion, the storage capacity savings gained from NetApp’s thin provisioning, data deduplication and data compression were truly remarkable. As shown in Figure 9, thin provisioning alone provided a sizable 46 percent capacity savings.

But enabling data deduplication provided even more overall, a 68 percent savings as compared to baseline capacity used. Data compression added still more, such that when all tested features were activated, the size of the original storage was reduced by an impressive 79 percent.

… when all tested features were activated, the size of the original storage was reduced by an

impressive 79 percent

Figure 9 Overall capacity requirements




In comparison, NetApp Snapshot and FlexClone copies did not have any impact on capacity requirements for source data. As both are only point-‐in-‐time copies, their post-‐workload capacity was compared simply with the baseline capacity in the above chart. Thus, as seen in Figure 10, both facilities provided impressive point-‐in-‐time copies greater than 95 and 78 percent smaller for Snapshot and FlexClone copies respectively than baseline data.

Figure 10 Capacity savings for data copy facilities chart




Figure 11 Baseline vs. all tested features performance comparison chart

Besides the tremendous capacity savings achieved using thin provisioning, deduplication and compression, enabling these storage efficiencies had no negative impact on the overall performance of the NetApp storage system. Moreover, when comparing overall median performance, NetApp’s operational throughput also exhibited no negative impact. The ultimate decision to use any or all of vendor’s storage capacity saving features or their point-‐in-‐time copy capabilities can be a complex decision and often involves a tradeoff with performance. However, NetApp thin provisioning, data deduplication and compression can potentially provide overwhelming storage capacity savings with little, if any, overall performance degradation and thus, deserve strong consideration for any data center environment. Silverton Consulting, Inc. is a Storage, Strategy & Systems consulting services company, based in the USA offering products and services to the data storage community.




Appendix 1 SCI Lab resources and workload details SCI’s lab uses enterprise-‐class server and networking resources to support hardware and software validation activities including:

• One Westmere class, dual processor, six-‐core server with 144GB of memory and an SSD for internal storage

• One Nehalem class, dual processor, quad-‐core server, with 48GB of memory and an SSD for internal storage

• One SandyBridge class, single processor, quad-‐core server, with 32GB DRAM and an SSD for internal storage

• Six Xeon class, dual processor, quad core servers with five having 48GB of DRAM, using internal SAS drives for local storage

• Three FC SAN switched fabrics supporting 2GFC, 4GFC, and 8GFC, and • Two Ethernet fabrics supporting both 1GigE as well as 10GbE, providing

FCoE, iSCSI and normal LAN traffic. Although all the above were available for testing, the Nehalem class server running VMware with 3 virtual machines (VMs) each having 16GB of DRAM was utilized for this test. All the data was accessed over 10Gb/sec Ethernet (10GbE) interfaces. The server had two standard Intel 10GbE XF SR NICs teamed together used for iSCSI and a single Emulex 11101 NIC used for CIFS traffic. No attempts were made to optimize system or storage performance but rather to establish a baseline level of performance for comparison purposes.

Workloads used to measure performance To measure system performance, a typical workload was generated against the previously acquired data using the SCI lab server. One VM was dedicated to each workload as follows:

• File system workload: A CIFS file share was created and accessed by one VM. Then, a simulated file workload was constructed which wrote and read data concurrently using an automated copy script.

• SQL DB workload: A SQL Server was configured and a simulated workload was created consisting of changing and modifying column values in the relational tables.

• Email workload: Microsoft’s Exchange 2010 Jetstress tool was run for 1150 mailboxes producing ~0.18 I/O per mailbox per second, i.e. a normal email workload.

Data used in test Test data was taken from a number of sources including publicly available email data, internal file data from SCI’s lab and office environment and text/image/PDF data obtained from the web. Specifically,




• File system: ~211GB consisting of 48% email data (.pst files/email data), 21% Perfmon data, 15% text, 7% image data, 5% Office/PDF data, and 4% DB/SQL data.

• SQL database (DB) data: ~474GB of data spread across 18 tables containing text and web server log data.

• Email data: ~414GB of email with 88MB of log data created by the Microsoft Jetstress tool.

The testing used a variety of data types to simulate the diversity of data found in many customer environments and to reduce the potential for non-‐standard results based on “artificial” data. However, the testing is not intended to represent best practice guidelines for any specific application or environment. Readers are encouraged to consult NetApp documentation and personnel directly for the best practice recommendations for their specific application requirements. Additionally, the performance testing was designed to measure before and after results to assess any potential impact of implementing multiple storage efficiency and copy technologies. These results are not intended to be used for performance sizing and do not reflect possible throughput results outside of the specific test environment. Readers are encouraged to consult NetApp documentation and personnel directly for performance recommendations for their specific requirements.




Appendix 2 NetApp CLI commands used and results summary Feature Commands to enable Commands to measure

savings Savings

Baseline df –k Thin provisioning

lun set reservation path disable; vol options volname guarantee=none

df –k; df -A

Moderate

Data deduplication

sis on path; sis start –S path;

df –k; df –S

Moderate

Data compression

sis config –C TRUE path; sis start –S -C path;

df –k; df –S

Moderate

Snapshot snap create volname snapvolname

df –k; snap list

Outstanding3

FlexClone Vol clone create clonename –s volume volname

df –k; vol clone split estimate clonename; snap list;

Significant4

All features (As indicated above) (As indicated above) Substantial Table 1 Command and results summary table

3 For original source data there were no savings but for snapshot copies there were outstanding savings 4 For original source data there were no savings but for FlexClones there were significant savings




Appendix 3 Summary of Capacity Test Results Cumulative Storage Efficiency Test Results (GB) Test Step 1 Test Step 2 Test Step 3 Test Step 4

Post-‐workload Baseline

Net After Thin Provisioning

Net After Thin Provisioning & Deduplication

Net After Thin Provisioning,

Deduplication & Compression

File System Storage 629.15 211.72 118.27 106.12 SQL DB Storage 629.15 473.60 452.42 229.20 SQL Log Storage 104.86 1.20 0.02 0.02 Email DB Storage 629.15 414.03 87.04 87.03 Email Log Storage 41.94 0.09 0.00 0.00 Total Capacity 2,034.24 1,100.64 657.76 422.37 Table 2 Cumulative storage efficiency test results Copy Services Test Results (GB) Test Step 1 Test Step 5 Test Step 6

Post-‐workload

Baseline Net After

Snapshot Copy Net After

FlexClone Copy File System Storage 629.15 6.81 66.63 SQL DB Storage 629.15 90.07 200.87 SQL Log Storage 104.86 0.01 65.15 Email DB Storage 629.15 7.48 115.80 Email Log Storage 41.94 0.00 0.35 Total Capacity 2,034.24 104.37 448.80 Table 3 Copy services test results

sci lab test validation report: netapp storage efficiency

Technology

storage baseline

storage test step

storage system

compressed storage

storage capacity requirements

capacity efficiency

netapp copy services

cumulative test step