openbench Labs Data Center Converged SAN Infrastructure Measuring Nexsan Performance and Compatibility in Virtualized Environments Analysis:

Transcription

1 Data Center Converged SAN Infrastructure openbench Labs Analysis: Measuring Nexsan Performance and Compatibility in Virtualized Environments

2 Analysis: Measuring Nexsan Performance and Compatibility in Virtualized Environments Author: Jack Fegreus, Ph.D. Managing Director openbench Labs September 15, 2010 Jack Fegreus is Managing Director of openbench Labs and consults through Ridgetop Research. He also contributes to InfoStor, Virtual Strategy Magazine, and Open Magazine, and serves as CTO of Strategic Communications. Previously he was Editor in Chief of Open Magazine, Data Storage, BackOffice CTO, Client/Server Today, and Digital Review. Jack also served as a consultant to Demax Software and was IT Director at Riley Stoker Corp. Jack holds a Ph.D. in Mathematics and worked on the application of computers to symbolic logic.

3 Table of Contents Table of Contents Executive Summary 04 VOE Test Scenario 06 SASBeast Performance Spectrum 13 Customer Value 19 03

4 Executive Summary Executive Summary F or an SME site to successfully implement a VOE, Nexsan provides a storage infrastructure that is capable of efficiently supporting the characteristic I/O patterns that distinguish a VOE host server to deliver optimal performance. The mission of IT is to get the right information to the right people in time in order to create value or mitigate risk. With this in mind, the growing use of digital archiving, rich media in corporate applications, and a Virtual Operating Environment (VOE), such as VMware vsphere, is driving double-digit growth in the volume of data stored. That has made data storage the cornerstone of IT strategic plans for reducing capital expense (CapEx) and operating expense (OpEx) resource costs. openbench Labs Test Briefing: Nexsan SASBeast Enterprise Storage Array 1) Enhance Administrator Productivity: An embedded WEB-based utility enables the management of multiple storage arrays from one interface, which can be integrated with the Microsoft Management Console and the Virtual Disk Service to provide a complete single-pane-of-glass storage management interface. 2) Maximize Density and Reliability with Hierarchical Storage: 4U chassis supports any mix of 42 SSD, SAS, and SATA drives mounted vertically front-to-front and back-to-back to cancel rotational vibrations, reduce head positioning errors, optimize thermal operations, and extend drive life. 3) Maximize Energy Savings: AutoMAID (Massive Array of Idle Disks) technology automates the placing of drives in a hierarchy of idle states to conserve energy, while maintaining near-instantaneous access to data. 4) Maximize I/O Performance: Dual active-active RAID controllers support 42 simultaneously active drives: Iometer Streaming I/O Benchmark: Total full-duplex throughput reached 1GB per second, while simultaneously streaming 128KB reads and 128KB writes using three SAS- and one SATA-based RAID-5 volumes. To meet the needs of IT at small to medium enterprise (SME) sites, Nexsan has evolved its line of SASBeast storage arrays around highly flexible software architecture that can be integrated to the point of transparency in a Windows Server 2008 R2 environment. These Nexsan arrays can support a full hierarchy of SSD, SAS, and SATA drives in complex SAN fabrics that utilize both Fibre Channel and iscsi paths. For SME sites, a SASBeast can provide multiple storage targets that support a wide range of application-specific requirements stemming from Service Level Agreements (SLAs). The robust architecture of the Nexsan SASBeast provides IT with a single platform that can satisfy a wide range of storage metrics with respect to access (IOPS), throughput (MB per second), or capacity (price per GB). Nonetheless, helping IT contain traditional CapEx provisioning costs through the deployment of hierarchical storage resources is only the starting point for the business value proposition of the SASBeast. Through tight integration of the Nexsan Management Console with the Iometer I/O Operations Benchmark: 4KB reads and writes (80/20 percent mix), averaged 2,330 IOPS on a SAS RAID-5 volume and scaled to 4,380 IOPS with a second volume. 04

5 Executive Summary Microsoft Management Console (MMC) and Virtual Disk Services (VDS), a Nexsan SASBeast presents IT administrators with a unified SAN management suite to costeffectively manage the reliability, availability and scalability (RAS) of multiple petabytes of data. This is particularly important for OpEx costs, which typically are 30 to 40 times greater than CapEx costs over the life of a storage array. Nexsan s simplified storage management and task automation is particularly important when implementing a VOE, which introduces a complete virtualization scheme involving servers, storage, and networks. VOE virtualization with multiple levels of abstraction can complicate important IT administration functions. Reflecting these problems, IDG, in a recent survey of CIOs implementing server virtualization, reported that the percent of CIOs citing an increase in the complexity of datacenter management jumped from 47 percent at the end of 2008 to 67 percent at the end of Virtualization difficulties are often exacerbated by multiple incompatible advanced point solutions, which often come as extra-cost options of storage products. These powerful proprietary features are particularly problematic for IT at SME sites. Features designed to resolve complex issues encountered in large datacenters frequently only introduce incompatibilities among interdependent resources and limit the benefits that SME sites can garner from a VOE, which independently provides IT with sufficiently robust and easy-to-use solutions to deal with the intricacies of hypervisor architecture. For an SME site to successfully implement a VOE, Nexsan provides a storage infrastructure that is capable of efficiently supporting the characteristic I/O patterns that distinguish a VOE host server. With such a foundation in place, IT is free to use the comprehensive virtualization features of their VOE to provision resources for VMs, commission and decommission VM applications, and migrate VMs among multiple hosts in real time to meet changing resource demands. What s more, advanced third party applications designed for a VOE are far more likely to recognize VOE solutions for such issues as thin provisioning than hardware-specific solutions. To meet the exacting demands of multiple IT environments, including that of a VOE, a Nexsan SASBeast provides IT with a storage resource fully optimized for reliability and performance. Each physical unit features design innovations to extend the lifespan of installed disk drives. The design of the SASBeast also promotes infrastructure scale-out, as each additional unit also adds controllers and ports to maintain performance. More importantly, the scaling-out of a storage infrastructure with SASBeast units has a minimal impact on IT overhead, which is the key driver of OpEx costs. Each SASBeast comes with an embedded WEB-enabled Graphical User Interface (GUI), dubbed NexScan, which allows IT to provision a single subsystem with a hierarchy of drive types. Furthermore, NexScan simplifies administrator tasks in a Windows Server environment through tight integration of its management software with MMC and VDS for end-to-end storage management. With NexScan, an administrator can provision a logical disk on any SASBeast, export it to a Windows Server, and provision the server with that logical disk from a single interface. 05

6 VOE Test Scenario VOE Test Scenario W hile working with a range of Windows tools for administrators, such as Server Manager and Storage Manager for SANs, we were able to directly configure and manage storage LUNs for both the FC and the iscsi fabrics without having to open up a separate Nexsan GUI. I/O RANDOMIZATION IN A VOE With server virtualization rated as one of the best ways to optimize resource utilization and minimize the costs of IT operations, many sites run eight or more server VMs on each host in a production VOE. As a result, VOE host servers must be able to deliver higher I/O throughput loads via fewer physical connections. In stark contrast to a VOE, traditional core-driven SAN fabrics are characterized by a few storage devices with connections that fan out over multiple physical servers. Each server generates a modest I/O stream and multiple servers seldom access the same data simultaneously. From a business software perspective, the I/O requirements for a VM are the same as those for a physical server. From an IT administrator s perspective, however, I/O requirements for VOE hosts are dramatically different. In a VOE, a small number of hosts share a small number of large datastores, while the hosts aggregate and randomize all of the I/O from multiple VMs. Elevated I/O stress also impacts the I/O requirements of VOE support servers. In particular, servers used for backup should be capable of handling the logical disks associated with multiple hosted VMs in parallel. 06

7 VOE Test Scenario NEXSAN ISCSI & FC CONVERGEENCE Among the ways that Nexsan simplifies SAN management is through the convergence of iscsi and Fibre Channel devices. Nexsan treats these connections as two simple transport options. Within the Nexsan GUI, we readily shared volumes that were used as VOE datastores by ESXi hosts and a Windows server that was used to run backup software. More importantly, the SASBeast facilitated our ability to switch between a local Disaster Recovery (DR) scenario, in which both the VOE host and the Windows server connected to the datastore volume over the FC fabric, and a remote DR scenario, in which the Windows server connected to the datastore via our iscsi fabric. generation of 8Gbps FC ports. At the heart of our vsphere 4.1 VOE test environment, we ran a mix of twelve server and workstation VMs. To provide a typical SME infrastructure, we utilized a Nexsan SASBeast, along with a hybrid SAN topology that featured a 4Gbps FC fabric and a 1GbE iscsi fabric. With the price convergence of 8Gbps and 4Gbps FC HBAs, SASBeast systems are now shipping with a new While working with a range of Windows tools for administrators, such as Server Manager and Storage Manager for SANs, we were able to directly configure and manage storage LUNs for both the FC and the iscsi fabrics without having to open up a separate Nexsan GUI. What s more, the Nexsan software, which treats the virtualization of storage over FC and iscsi fabrics as simple transport options, made it very easy to switch back and forth between fabric connections. While physically setting up the SASBeast, a number of design elements that enhance reliability stood out. Storage reliability is especially important in a VOE as impaired array processing for a rebuild, or worse the loss of an array, cascades from one host server 07

8 VOE Test Scenario down to multiple VMs. To extend the service life of disk drives, the SASBeast positions disks vertically in opposing order alternating between front-to-front and then back-to-back. This layout dampens the natural rotational vibrations generated by each drive. Mounting all of the drives in parallel tends to amplify these vibrations and induce head positioning errors on reads and writes. Head positioning errors are particularly problematic in a VOE, which is characterized by random small-block I/O requests. In such an environment, data access time plays a greater role with respect to transfer time for I/O services. That vertical disk layout also helps create a positive-pressure air flow inside the unit. High efficiency waste heat transfer in a storage chassis is dependent on molecular contact as air flows over external drive surfaces. As a result, air pressure is just as important as air flow for proper cooling. To facilitate testing, our Nexsan SASBeast was provisioned with twenty eight 15K rpm SAS drives and fourteen 2TB SATA drives. To configure internal arrays and provide external access to target volumes, our SASBeast was set up with two controllers, which could be used to create both SAS and SATA arrays and which featured a pair of FC and a pair of iscsi ports per controller. Also embedded in the unit was version of the Nexsan management software, which we tightly integrated with MMC on all of our Windows-based servers. Using this storage infrastructure, we were able to provide our VOE and physical server environments with storage hierarchies designed to meet robust sets of application-specific SLA metrics. In particular, we configured three RAID arrays on the SASBeast: Two arrays utilized SAS drives and one array utilized SATA drives. For optimal IOPS performance, we created a 7.2TB RAID-5 SAS array on controller 0. Then on controller 1, we created a 6.6TB RAID-6 SAS array for higher availability. VOE CONSOLIDATION We implemented our vsphere 4.1 VOE, on a quad-processor HP ProLiant DL580 server running the VMware ESXi 4.1 hypervisor. This server hosted 12 VMs running a mix of operating systems, which included Windows Server 2008, Windows Server 2003, SUSE Linux Enterprise Server 11, and Windows 7. Within our VOE, we set up a storage hierarchy that was undergirded by three central datastores that were created on each of the three arrays set up on the Nexsan SASBeast. To manage VM backups, we installed Veeam Backup & Replication v4.1 on a quadcore Dell PowerEdge 1900 server, which ran Windows Server 2008 R2 and shared access to each datastore mapped to the VOE host. We tested datastore access over both our FC fabric, which represented a local DR scenario, and over our iscsi fabric, which represented a remote DR scenario. In addition, we mapped another RAID-5 SATA volume to the Dell PowerEdge server to store backup images of VMs. The number of VMs that typically run on a VOE host along with the automated 08

9 VOE Test Scenario movement of those VMs among hosts as a means to balance processing loads puts a premium on storage resources with low I/O latency. What s more, increasing the VM density on a host also serves to further randomize I/O requests as the host consolidates multiple data streams from multiple VMs. NEXSAN VOE OPTIMIZATION To handle the randomized I/O patterns of a VOE host with multiple VMs, the Nexsan SASBeast provides a highly flexible storage infrastructure. In addition to being able to provision a SASBeast with a wide range of disk drive types, administrators have an equally broad choice of options from which to configure access policies for internal arrays and external volumes. To maximize performance in our VOE, we biased I/O caching on the SASBeast for random access. As the host consolidates the I/O streams of multiple VMs, sequential I/Os for multiple VMs are consolidated by the host with the result that random access I/O becomes a key characteristic for a VOE host. We also set up an I/O multipathing scheme on the Nexsan SASBeast that allowed us to map any array volume to one or all Fibre Channel and all iscsi ports. Using a Nexsan SASBeast with dual controllers, IT administrators are free to assign any RAID array that is created to either controller. Independent of array ownership, administrators set up how logical volumes created on those arrays are accessed over Fibre Channel and iscsi SAN fabrics. In particular, a SASBeast with two controllers and two FC ports on each controller can present four distinct paths to each volume exposed. Without any external constraints, four distinct paths to a storage device will create what appear to be four independent devices on the client system. That presents an intolerable situation to most operating systems, which assume exclusive ownership of a device. To resolve this problem, the simple solution is to use an active-passive scheme for ports and controllers that enables only one path at a time. That solution, however, precludes load balancing and link aggregation. Nexsan provides IT administrators with a number of options for sophisticated load balancing via multipath I/O (MPIO). The range of options for each unit is set within the 09

10 VOE Test Scenario Nexsan GUI. Volume access can be restricted to a simple non-redundant controller setup or can be allowed to utilize all ports and all LUNs (APAL): The later configuration provides the greatest flexibility and protection and is the only configuration to support iscsi failover. ASYMMETRIC MPIO To provide a high performance scale-out storage architecture, each SASBeast supports two internal controllers that are each capable of supporting two external FC ports and two external iscsi ports. When a RAID array is created, it is assigned a master controller to service the array. If the SASBeast is placed in APAL mode, IT administrators can map any volume to all of the FC and iscsi ports as a load balancing and failover scheme. In this situation I/O requests directed to the other controller incurs added overhead needed to switch control of the array. To garner the best I/O performance in a high-throughput low-latency environment, a host must be able to implement a sophisticated load balancing scheme that distinguishes between the two ports that are on the controller servicing the volume from the two ports on the other controller. The key is to avoid the overhead of switching controllers. VSPHERE 4.1 ASYMMETRIC MPIO DISCOVERY When either an ESX or an ESXi 4.1 hypervisor discovers a volume exposed by the Nexsan SASBeast, it defaults to making only one path active for I/O. We changed this default to round robin access. When this change is made, the new drivers in ESXI 4.1 did a SCSI inquiry on the FC volume and discovered that the Nexsan was an ALUA device. As a result, the hypervisor set up the four paths to the servicing controller as active optimized and the four paths to the other controller as non-optimized. Using ESX or ESXi 4.0, all eight paths would set as equally active for I/O. To meet this challenge, Nexsan implements Asymmetric Logical Unit Access (ALUA) when exporting target volumes. The Nexsan device identifies the paths that are active and optimized (i.e. paths that connect to a port on the controller servicing the device) and paths that are active but are not optimized. Nonetheless, for this sophisticated MPIO mechanism to work, it must be recognized by the host operating system that is using the SASBeast as a target. Both Windows Server 2008, which uses a sophisticated MPIO driver module from Nexsan, and the vsphere 4.1 hypervisors, ESXi 4.1 and ESX 4.1, recognize the Nexsan SASBeast as an ALUA target. As a result, IT administrators can set 10

11 VOE Test Scenario an MPIO policy on any host running one of these operating systems that takes advantage of knowing which SAN paths connect to the controller servicing a logical drive. VSPHERE ALUA PERFORMANCE On Windows Server 2008, the base asymmetric access policy is dubbed Round Robin with Subset. This policy transmits I/O requests only to ports on the servicing controller. Should the servicing controller fail, Nexsan passes array servicing to the other controller in the SASBeast and the host computer automatically starts sending I/O requests to the active ports on the new servicing controller. Upgrading to vsphere 4.1 from vsphere 4.0 boosted I/O throughput by 20% for VMs resident on a datastore imported from the SASBeast. More importantly for IT OpEx costs, gains in I/O throughput required a simple change in the MPIO policy for each datastore imported from the SASBeast. To understand how the driver changes in the new VMware hypervisors impact host I/O throughput, we monitored FC data traffic at the switch ports connected to the Nexsan SASBeast and the VOE host. We tested I/O throughput by migrating a server VM from a datastore created on the SAS RAID-6 array, which was serviced by controller 1, to a datastore created on the SAS RAID-5 array, which was serviced by controller 0. We repeated this test twice: once with the VOE host running ESXI 4.1 and once with the host running ESXi 4.0 Update 2. Running either ESXi 4.0 or ESXi 4.1, the host server balanced all read and write requests over all of its FC ports; however, the I/O response patterns on the SASBeast were dramatically different for the two hypervisors: ESXi 4.1 transmitted I/O requests exclusively to the FC ports on the controller servicing a target volume. In particular, when a VOE host was running ESXi 4.1, the host only directed reads to controller 1, which serviced the SAS RAID-6 volume, and writes to controller 0, which serviced the SAS RAID-5 volume. In contrast read and write data requests were transmitted 11

12 VOE Test Scenario to all of the FC ports on both of the SASBeast controllers equally, when the host was running ESXi 4.0. With all I/O requests directed equally across all FC ports under ESXi 4.0, throughput at each undistinguished port was highly variable as I/O requests arrived for both disks serviced by the controller and disks serviced by the other controller. As a result, I/O throughput averaged about 200MB per second. On the other hand, with our VOE host running ESXi 4.1, I/O requests for a logical disk from the SASBeast were only directed to and balanced over the FC ports on the controller servicing that disk. In this situation, full duplex reads and writes averaged 240MB per second as we migrated our VM from one datastore to another. For IT operations, I/O throughput under ESXi 4.1 for a VM accessing a SASBeast disk volume reached comparable levels of performance particularly with respect to IOPS to that of a physical server. 12

13 SASBeast Performance Spectrum SASBeast Performance Spectrum U sing four Iometer worker processes two reading and one writing on three RAID-5 SAS volumes and one writing on a RAID-5 SATA volume we measured total full-duplex throughput from the SASBeast at 1GB per second. SCALE-UP AND SCALE-OUT I/O THROUGHPUT We began our I/O tests by assessing the performance of logical disks from the Nexsan SASBeast on a physical server, which was running Windows Server 2008 R2. For these tests we created and imported a set of volumes from each of the three arrays that we had initially created. We used Iometer to generate all I/O test workloads on our disk volumes. To assess streaming sequential throughput, we used large block reads and writes, which are typically used by backup, data mining, and online analytical processing (OLAP) applications. All of these datacenter-class applications need to stream large amounts of server-based data rapidly to be effective. As a result, we initially focused our attention of using the SASBeast in a 4Gbps Fibre Channel SAN. Fibre Channel Sequential Access I/O Throughput Windows Server 2008 R2 Round Robin with Subset MPIO on a 4Gbps FC SAN RAID & Disk Type Read Throughput Iometer benchmark 128KB blocks Write Throughput Iometer benchmark 128KB blocks RAID-5 SAS 554 MB/sec 400 MB/sec RAID-6 SAS 505 MB/sec 372 MB/sec RAID-5 SATA 522 MB/sec 430 MB/sec Application Throughput Veeam Backup & Replication 4.1 Parallel backup of four VMs 245 MB/sec reading VM data 245 MB/sec writing backup image We began our benchmark testing by reading data using large block I/O requests over two FC connections. Maximum I/O throughput varied among our three logical volumes by only 10 percent. During these tests, the fastest reads were measured at 554MB per second using volumes created on our RAID-5 SAS array. What s more, the aggregate read throughput for all targets using two active 4Gbps ports exceeded the wire speed capability of a single 4Gbps FC port. While we consistently measured the lowest I/O throughput on reads and writes using SAS RAID-6 volumes, the difference on writes between a SAS RAID-5 volume and a SAS RAID-6 volume was only about 7 percent 400MB per second versus 372MB per second. Using the Nexsan SASBeast, the cost for the added security provided by an extra parity bit, which allows two drives to fail in an array and continue processing I/O requests, is very minimal. This is particularly important for IT sites supporting mission-critical 13

14 SASBeast Performance Spectrum applications that require maximum availability and high-throughput performance. A RAID-6 array provides an important safety net when rebuilding after a drive fails. Since a RAID-6 array can withstand the loss of two drives, the array can be automatically rebuilt with a hot-spare drive without risking total data loss should an unrecoverable bit error occur during the rebuild process. On the other hand, a backup of a degraded RAID-5 array should be run before attempting a rebuild. If an unrecoverable bit error occurs while rebuilding a degraded RAID-5 array, the rebuild will fail and data stored on the array will be lost. When performing writes, the variation in throughput between the disk volumes reached 15 percent. Interestingly, it was SATA RAID-5 volumes that consistently provided the best streaming performance for large-block writes. In particular, using 128KB writes to a SATA RAID-5 volume, throughput averaged 430MB per second. Given the low cost and high capacity advantages provided by 2TB SATA drives, the addition of exceptional write throughput makes the SASBeast an exceptional asset for Disk-to-Disk (D2D) backup operations and other disaster recovery functions. To assess the upper I/O throughput limits of our Nexsan SASBeast for D2D and other I/O intense applications, we used Iometer with multiple streaming read and write processes in order to scale total throughput. Using four Iometer worker processes two reading and one writing on three RAID-5 SAS volumes and one writing on a RAID-5 SATA volume we measured total full-duplex throughput from the SASBeast at 1GB per second. ISCSI NICHE iscsi Sequential Access I/O Throughput Windows Server 2008 R2 Jumbo frames, iscsi HBAs, and Round Robin MPIO on a 1GbE iscsi SAN RAID & Disk Type Read Throughput Iometer benchmark 128KB blocks Write Throughput Iometer benchmark 128KB blocks Application Throughput Veeam Backup & Replication VM backups in parallel RAID-5 SAS 82 MB/sec (1 HBA) 146 MB/sec (2 HBAs) 83 MB/sec (1 HBA) 146 MB/sec (2 HBAs) RAID-5 SATA 80 MB/sec (1 HBA 145 MB/sec (2 HBAs) 85 MB/sec (1 HBA) 150 MB/sec (2 HBAs) 136 MB/sec writing backup image On the other hand, streaming throughput on a 1GbE iscsi fabric has a hard limit of 120MB per second on each connection. What s more, to approach the upper end of that comparatively limited of performance, IT must pay close attention to the selection of equipment. Most low-end switches and even some Ethernet NICs that are typically found at SMB sites do not support jumbo Ethernet frames or port trunking, which are important functions for maximizing iscsi throughput. What s more, it s also important to isolate iscsi data traffic from normal LAN traffic. For iscsi testing, we utilized jumbo Ethernet frames 9,000 bytes rather than 1,500 14

15 SASBeast Performance Spectrum bytes with QLogic iscsi HBAs, which offload iscsi protocol processing and optimize throughput of large data packets. Our throughput results paralleled our FC fabric results: Streaming throughput differed by about 2 to 5 percent among logical volumes created on SAS and SATA arrays. Once again, the highest read throughput was measured on SASbased volumes and the highest write throughput was measured on SATA-based volumes. PUSHING IOPS In addition to streaming throughput, there is also a need to satisfy small random I/O requests. On the server side, applications built on Oracle or SQL Server must be able to handle large numbers of I/O operations that transfer small amounts of data using small block sizes from a multitude of dispersed locations on a disk. Commercial applications that rely on transaction processing (TP) include such staples as SAP and Microsoft Exchange. More importantly, TP applications seldom exhibit steady-state characteristics. Typical TP loads for database-driven applications in an SMB environment average several hundred IOPS. These applications often experience occasional heavy processing spikes, such as at the end of a financial reporting period that can rise by an order of magnitude to several thousand IOPS. That variability makes systems running TP applications among the most difficult for IT to consolidate and among the most ideal to target for virtualization. A well-managed VOE is capable of automatically marshaling the resources needed to support peak processing demands. Random Access Throughput Windows Server 2008 Iometer (80% Reads and 20% Writes) RAID & Disk Type 4Gbps FC Fabric 1 logical disk 30ms average access time 4Gbps FC Fabric 2 logical disks 30ms average access time 1GbE iscsi Fabric 1 logical disk 30ms average access time MS Exchange Heavy use (75% reads) 4KB I/O 2,000 mail boxes RAID-5 SAS 2,330 IOPS (4KB I/O) 2,280 IOPS (8KB I/O) 4,318 IOPS (4KB I/O) 4,190 IOPS (8KB I/O) 1,910 IOPS (4KB I/O) 1,825 IOPS (8KB I/O) 1,500 IOPS RAID-6 SAS 1,970 IOPS (4KB I/O) 1,915 IOPS (8KB I/O) 1,350 IOPS (4KB I/O) 1,275 IOPS (8KB I/O) RAID-5 SATA 1,165 IOPS (4KB I/O) 1,120 IOPS (8KB I/O) 795 IOPS (4KB I/O) 755 IOPS (8KB I/O) We fully expected to sustain our highest IOPS loads on SAS RAID-5 volumes and were not disappointed. In these tests, we used a mix of 80 percent reads and 20 percent writes. In addition we limited the I/O request load with the restriction that the average I/O request response time had to be less than 30ms. Using 4KB I/O requests the size used by MS Exchange, we sustained 2,330 IOPS on a SAS RAID-5 volume, 1,970 IOPS on a SAS RAID-6 volume, and 1,160 IOPS on a SATA RAID-5 volume. Next, we switched our top performing RAID-5 SAS volume from the FC to the iscsi fabric and repeated the test. While performance dropped to

16 SASBeast Performance Spectrum VM Datastore RAID & Disk Type IOPS, it was still at a par with the FC results of our RAID-6 SAS volume and above the level that Microsoft suggests for supporting 2,000 mail boxes with MS Exchange. Next we ran our database-centric Iometer tests with 8KB I/O requests. In these tests, we doubled the amount of data being transferred; however, this only marginally affected the number of IOPS processed. With 8KB transactions, which typify I/O access with Oracle and SQL Server, we sustained 2,280 IOPS on a SAS RAID-5 volume, 1,915 IOPS on a SAS RAID-6 volume, and 1,120 IOPS on a SATA RAID-5 volume. Once again when we connected our SAS RAID-5 volume over our iscsi fabric, we measured a 20% drop in performance to 1,825 IOPS, which is more than sufficient to handle peak loads on most database-driven SME applications. To test transaction-processing scalability in a datacenter environment we added another RAID-5 SAS volume to our second SASBeast controller. By using two volumes on our FC fabric, we increased IOPS performance by 85% for both 4KB and 8KB I/O requests. In our two-volume tests with SAS RAID-5 volumes, we sustained levels of 4,320 IOPS and 4150 IOPS with an average response time of less than 30ms with a mix of 80 percent reads and 20 percent writes. STRETCHING I/O IN A VOE VM I/O Throughput Metrics VM: Windows Server 2008 VM Host: ESXi 4.1 Hypervisor on a 4Gbps FC SAN Sequential Throughput Streaming 128KB blocks Random Access 1 Logical disk, 80% Reads 30ms average access time MS Exchange Heavy use (75% reads) 4KB I/O 2,000 mail boxes RAID-5 SAS 436 MB/sec (Reads) 377 MB/sec (Writes) 2,380 IOPS (4KB I/O) 2,011 IOPS (8KB I/O) 1,500 IOPS RAID-6 SAS 427 MB/sec (Reads) 342 MB/sec (Writes) 2,325 IOPS (4KB I/O) 1,948 IOPS (8KB I/O) RAID-5 SATA 420 MB/sec (Reads) 380 MB/sec (Writes) Within our VOE, we employed a test scenario using volumes created on the same Nexsan RAID arrays that we tested with the physical Windows server. To test I/O throughput, we used Iometer on a VM running Windows Server Given the I/O randomization that takes place as a VOE host consolidates the I/O requests from multiple VMs, we were not surprised to measure sequential I/O throughput at a level that was 20% lower than the level measured on a similarly configured physical server. Nonetheless, at 420MB to 436MB per second for reads and 342MB to 380MB per second for writes, the levels of streaming throughput that we measured were 60 to 70 percent greater than the streaming I/O throughput levels observed when using high-end 16

17 SASBeast Performance Spectrum applications, such as backup, data mining, and video editing, on physical servers and dedicated workstations. As a result, IT should have no problems supporting streaming applications on server VMs or using packaged VM appliances with storage resources underpinned by a SASBeast. On the other hand, we sustained IOPS levels for random access I/O on RAID-5 and RAID-6 SAS volumes that differed by only 2 to 3 percent from the levels sustained on a physical server. These results are important for VM deployment of mission-critical database-driven applications, such as SAP. What s more, the ability to sustain 2,380 IOPS using 4KB I/O requests affirms the viability of deploying MS Exchange on a VM. APPLICATIONS & THE BEAST The real value of these synthetic benchmark tests with Iometer rests in the ability to use the results as a means of predicting the performance of applications. To put our synthetic benchmark results into perspective, we next examined full-duplex streaming throughput for a high end IT administrative application: VOE backup. What makes a VOE backup process a bellwether application for streaming I/O throughput is the representation of VM logical disk volumes as single disk files on the host computer, This encapsulation of VM data files into a single container file makes image-level backups faster than traditional file-level backups and enhances VM restoration. Virtual disks can be restored as whole images or individual files can be restored from within the backup image. More importantly, VMFS treats files representing VM virtual disks dubbed a.vmdk files analogously to a CD images. Host datastores typically contain only a small number of these files, which can be accessed by only one VM process at a time. It is up to the OS of the VM to handle file sharing for the data files encapsulated within the.vmdk file. This file locking scheme allows vsphere hosts to readily share datastore volumes on a SAN. The ability to share datastores among hosts greatly simplifies the implementation of vmotion, which moves VMs from one host to another for load balancing. With shared datastores, there is no need to transfer data, which makes moving a VM much easier. Before shutting down a VM, its state must be saved. The VM can then be restarted and brought to the saved state on a new host. Sharing datastores over a SAN is also very important for optimizing VM backups. For our VOE backup scenario, we utilized Veeam Backup & Replication 4.1 on a Windows server that shared access to all datastores belonging to hosts in our vsphere VOE. Every VM backup process starts with the backup application sending a VMsnap command to the host server to initiate a VM snapshot. In the snapshot process, the VM host server creates a point-in-time copy of the VM s virtual disk. The host server then freezes the vmdk file associated with that virtual disk and returns a list of disk blocks for that vmdk file to the backup application. The backup application then uses that block list to read the VM snapshot data residing in the VMFS datastore. 17

18 SASBeast Performance Spectrum SIMPLIFIED VOE DATASTORE SHARING To implement the fastest and most efficient backup process, IT must ensure that all VM data will be retrieved directly from the VMFS datastores using the vstorage API. That means the windows server running Veeam Backup & Replication must be directly connected to the VOE datastore. In other words, the Windows server must share each of the datastores used by VOE hosts. Through integration with VDS, the Nexsan SASBeast makes the configuration and management of shared logical volumes an easy task for IT administrators. In addition to the proprietary Nexsan software, IT administrators can use Storage Manager for SANs to create new LUNs and manage existing ones on the SASBeast. While Storage Manager for SANs provided less fine-grain control when configuring LUNs, wizards automated end-to-end storage provisioning from the creation of a logical volume on the SASBeast, to connecting that volume over either the FC or iscsi fabric, and then formatting that volume for use on our Windows server. As a result, the Nexsan hardware and software provided an infrastructure that enabled the rapid set up of an optimized environment for Veeam Backup & Recovery. Reflecting the interoperability of the Nexsan SASBeast, we were able to use Storage Manager for SANs within the Server Manager tool, to create and manage volumes, such as the voperations datastore used by our ESXi host. In particular we were able to drill down on the voperations volume and map it to our Windows Server 2008 R2 system via either our FC fabric or, our iscsi fabric. Application Throughput: VOE Full-Backup RAID-5 SAS Datastore RAID-5 SATA Backup Repository ESXi 4.1 Host, Windows Server 2008 R2, Veeam Backup & Recovery 4.1 Datastore Access 4VMs Processed Sequentially Optimal compression, Deduplication 4VMs Processed in Parallel Optimal compression FC SAN Fabric 164 MB/sec 245 MB/sec iscsi SAN Fabric 97 MB/sec 136 MB/sec To minimize backup windows in a vsphere VOE, Veeam Backup & Replication uses vstorage APIs to directly back up files belonging to a VM without first making a local copy. What s more, Veeam Backup and Replication recognizes disks with VMFS thin provisioning to avoid 18

19 SASBeast Performance Spectrum backing up what is in effect empty space. In addition, the Veeam software accelerates processing incremental and differential backups by leveraging Changed-Block Tracking within VMFS, As a result, we were able to leverage the VOE awareness for advanced options within our software solution to backup 4VMs at 245MB per second over our FC fabric and 136MB per second over our iscsi fabric. GREEN CONSOLIDATION IN A VOE Equally important for IT, the Nexsan SASBeast was automatically making significant savings in power and cooling costs all throughout our testing. A key feature provided within the Nexsan management suite provides for the optimization of up to three powersaving modes. These settings modes are applied array-wide; however, the modes available to an array depend upon the disk drives used in the array. For example, the rotational speed of SAS drives cannot be slowed. Once the AUTOMAID SAVINGS disks enter into a power saving mode, they can be automatically restored to full speed with only the first I/O delayed when the array is accessed. More importantly, over the period that we ran extensive tests of sequential and random data access, the power savings for each of our Over our testing period, we kept the AutoMAID feature aggressively seeking to enact power savings. Over three disk arrays the test period, AutoMAID provided fairly uniform power savings across all arrays, amounting to just over 50% was remarkable of the expected power consumption. uniform. The bottom line over our testing regime was an average power savings of 52 percent. Even more importantly, this savings was garnered over a period that saw each of the 42 disks in our SASBeast average 1,500,000 reads and 750,000 writes. Also of note for the mechanical design of the SASBeast, over our entire test there was not one I/O transfer or media retry. 19

20 Customer Value Customer Value W hile Nexsan s storage management software provides a number of important features to enhance IT productivity, the most important feature for lowering OpEx costs in a complex SAN topology is tight integration with VDS on Windows. MEETING SLA METRICS As companies struggle to achieve maximum efficiency, the top-of-mind issue for all corporate decision makers is how to reduce the cost of IT operations. Universally, the leading solutions center on resource utilization, consolidation, and virtualization. These strategies, however, can exacerbate the impact of a plethora of IT storage costs, from failed disk drives to excessive administrator overhead costs. As resources are consolidated and virtualized, the risk of catastrophic disaster increases as the number of virtual systems grows and the number of physical devices underpinning those systems dwindle. NEXSAN SASBEAST FEATURE BENEFITS 1) Application-centric Storage: Storage volumes can be created from a hierarchy of drives to meet multiple application-specific metrics. 2) I/O Retries Minimized: During our testing we executed a total of 95 million read and write I/Os without a single retry. 3) Automatic Power Savings: AutoMAID technology can be set to place drives in a hierarchy of idle states to conserve energy, while only delaying the first I/O request returning to a normal state. 4) High Streaming Throughput: Running with SAS- and SATA-based volumes, application performance mirrored benchmark performance as backups of multiple VMs streamed total full-duplex data at upwards of 500MB per second. 5) Linear Scaling of IOPS in a VOE: Using random 4KB and 8KB I/O requests typical of Exchange Server and SQL Server VMs sustained IOPS rates for both I/O sizes that differed by less than 2.5 percent on a SAS RAID-5 volume and scaled by over 80% with the addition of a second target volume. While reducing OpEx and CapEx costs are the critical divers in justifying the acquisition of storage resources, those resources must first and foremost meet the performance metrics needed by end-user organizations and frequently codified in SLAs set up between IT and Line of Business (LoB) divisions. These metrics address all of the end user s needs for successfully completing LoB tasks. Typically these requirements translate into data throughput (MB per second) and data response (average access time) metrics. In terms of common SLA metrics, our benchmarks for a single SASBeast reached levels of performance that should easily meet the requirements of most applications. What s more, the scale-outoriented architecture of the SASBeast presents an extensible infrastructure that can meet even the requirements of many High Performance Computing (HPC) applications. With a single logical disk from a RAID-5 base array, we were able to drive read throughput well over 500MB per second and write throughput well over 400MB per second. This is double the throughput rates needed for HDTV editing. With a single SASBeast and four logical drives, we scaled total full-duplex throughput to 1GB per second. 20

21 Customer Value We measured equally impressive IOPS rates for random access small-block 4KB and 8KB I/O requests. With one logical disk, we sustained more than 2,000 IOPS for both 4KB and 8KB I/O requests which scaled to over 4,000 IOPS with two logical disks. To put this into perspective, Microsoft recommends a storage infrastructure that can sustain 1,500 IOPS for an MS Exchange installation supporting 2,000 active mail boxes. BUILDING IN RELIABILITY In addition to performance specifications, storage reliability expressed in guaranteed uptime is another important component of SAL requirements. Starting with the mechanical design of the chassis and moving through to the embedded management software, Nexsan s SASBeast provides a storage platform that promotes robust reliability and performance while presenting IT administrators with an easy to configure and manage storage resource. In particular, the design of the SASBeast chassis proactively seeks to maximize the life span of disks by minimizing vibrations and maximizing cooling. For IT operations especially with respect to SLAs that design helps ensure storage performance guaranties concerning I/O throughput and data access will not be negatively impacted by data access errors induced by the physical environment. By extending disk drive life cycles, there will be fewer drive failures for IT to resolve and fewer periods of degraded performance as an array is rebuilt with a new drive. During our testing of a SASBeast, openbench Labs generated a total of 95 million read and write requests without the occurrence of a single read or write retry. SIMPLIFIED MANAGEMENT DRIVES SAVINGS While Nexsan s storage management software provides a number of important features to enhance IT productivity, the most important feature for lowering OpEx costs in a complex SAN topology is tight integration with VDS on Windows. For IT administrators, VDS integration makes the Nexsan storage management GUI available from a number of the standard tools on a Windows server. In particular, IT administrators are able to use Storage Manager for SANs to implement full end-to-end storage provisioning. By invoking just one tool, an administrator can configure a Nexsan array, create and map a logical volume to a host server, and then format that volume on the host. Nexsan also leverages very sophisticated SAN constructs to simplify administrative tasks. All storage systems with multiple controllers need to handle the dual issues of array ownership active service processors and SAN load balancing active ports. Through Nexsan s implementation of Asymmetric Logical Unit Access (ALUA), host systems with advanced MPIO software can access a SASBeast and discern the subtle difference between an active port and active service processor. As a result, an IT administrator is able to map a LUN to each FC port on each controller and allow the server s MPIO software to optimize FC port aggregation and controller failover. Using this scheme openbench Labs was able to scale streaming reads and writes to four drives at upwards of 1GB per second. 21

22 Customer Value REVOLUTIONARY GREEN SAVINGS In addition to providing an innovative solution for reliability and performance, Nexsan s AutoMAID power management scheme automatically reduces SASBeast power consumption, which is a significant OpEx cost at large sites. Using three levels of automated power-saving algorithms, the SASBeast, eliminates any need for administrator intervention when it comes to the green IT issues of power savings and cooling. Nexsan automatically reduces the power consumed by idle disk drives via a feature dubbed AutoMAID. AutoMAID works on a per-disk basis, but within the context of a RAID set, to provide multiple levels of power savings from parking heads to slowing rotational speed to further contain OpEX costs. While testing the SASBeast, openbench Labs garnered a 52% power savings on our arrays. 22