Measuring Nexsan Performance and Compatibility in Virtualized Environments


Published on

Measuring Nexsan Performance and Compatibility in Virtualized Environments, Medición de desempeño y compatibilidad de de Nexsan en ambietes virtualizados.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Measuring Nexsan Performance and Compatibility in Virtualized Environments

  1. 1. openBench LabsData Center Converged SAN Infrastructure Measuring Nexsan Performance and Analysis: Compatibility in Virtualized Environments
  2. 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. 3. Table of ContentsTable of Contents Executive Summary 04 VOE Test Scenario 06 SASBeast Performance Spectrum 13 Customer Value 19 03
  4. 4. Executive SummaryExecutive Summary “For an SME site to successfullycapable of VOEVOE, Nexsantoprovides a storage infrastructure that is implement a characteristic I/O patterns that distinguish a efficiently supporting the host server 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. To meet the needs of IT at openBench Labs Test Briefing: small to medium enterprise (SME) sites, Nexsan has evolved Nexsan SASBeast® Enterprise Storage Array its line of SASBeast™ storage1) Enhance Administrator Productivity: An embedded WEB-based utility arrays around highly flexible enables the management of multiple storage arrays from one interface, software architecture that can be which can be integrated with the Microsoft Management Console and the integrated to the point of Virtual Disk Service to provide a complete single-pane-of-glass storage transparency in a Windows Server management interface. 2008 R2 environment. These2) Maximize Density and Reliability with Hierarchical Storage: 4U chassis Nexsan arrays can support a full supports any mix of 42 SSD, SAS, and SATA drives mounted vertically— hierarchy of SSD, SAS, and SATA front-to-front and back-to-back—to cancel rotational vibrations, reduce head positioning errors, optimize thermal operations, and extend drive life. drives in complex SAN fabrics that utilize both Fibre Channel3) Maximize Energy Savings: AutoMAID® (Massive Array of Idle Disks) technology automates the placing of drives in a hierarchy of idle states to and iSCSI paths. For SME sites, a conserve energy, while maintaining near-instantaneous access to data. SASBeast can provide multiple storage targets that support a wide4) Maximize I/O Performance: Dual active-active RAID controllers support 42 range of application-specific simultaneously active drives: requirements stemming from Iometer Streaming I/O Benchmark: Total full-duplex throughput reached Service Level Agreements (SLAs). 1GB per second, while simultaneously streaming 128KB reads and 128KB writes using three SAS- and one SATA-based RAID-5 volumes. The robust architecture of 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 Nexsan SASBeast provides IT to 4,380 IOPS with a second volume. 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 04
  5. 5. Executive SummaryMicrosoft Management Console (MMC) and Virtual Disk Services (VDS), a NexsanSASBeast presents IT administrators with a unified SAN management suite to cost-effectively manage the reliability, availability and scalability (RAS) of multiple petabytesof data. This is particularly important for OpEx costs, which typically are 30 to 40 timesgreater than CapEx costs over the life of a storage array. Nexsan’s simplified storage management and task automation is particularly importantwhen implementing a VOE, which introduces a complete virtualization scheme involvingservers, storage, and networks. VOE virtualization with multiple levels of abstraction cancomplicate important IT administration functions. Reflecting these problems, IDG, in arecent survey of CIOs implementing server virtualization, reported that the percent ofCIOs citing an increase in the complexity of datacenter management jumped from 47percent at the end of 2008 to 67 percent at the end of 2009. Virtualization difficulties are often exacerbated by multiple incompatible advancedpoint solutions, which often come as extra-cost options of storage products. Thesepowerful proprietary features are particularly problematic for IT at SME sites. Featuresdesigned to resolve complex issues encountered in large datacenters frequently onlyintroduce incompatibilities among interdependent resources and limit the benefits thatSME sites can garner from a VOE, which independently provides IT with sufficientlyrobust 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 storageinfrastructure that is capable of efficiently supporting the characteristic I/O patterns thatdistinguish a VOE host server. With such a foundation in place, IT is free to use thecomprehensive virtualization features of their VOE to provision resources for VMs,commission and decommission VM applications, and migrate VMs among multiple hostsin real time to meet changing resource demands. What’s more, advanced third partyapplications designed for a VOE are far more likely to recognize VOE solutions for suchissues 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 andperformance. Each physical unit features design innovations to extend the lifespan ofinstalled 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 hasa minimal impact on IT overhead, which is the key driver of OpEx costs. Each SASBeastcomes with an embedded WEB-enabled Graphical User Interface (GUI), dubbedNexScan®, which allows IT to provision a single subsystem with a hierarchy of drivetypes. Furthermore, NexScan simplifies administrator tasks in a Windows Serverenvironment through tight integration of its management software with MMC and VDSfor end-to-end storage management. With NexScan, an administrator can provision alogical disk on any SASBeast, export it to a Windows Server, and provision the serverwith that logical disk from a single interface. 05
  6. 6. VOE Test ScenarioVOE Test Scenario hile working with a range of Windows tools for administrators, “W 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. 7. VOE Test Scenario At theNEXSAN ISCSI & FC CONVERGEENCE 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 Among the ways that Nexsan simplifies SAN management is through the convergence of iSCSI and Fibre of 8Gbps andChannel devices. Nexsan treats these connections as two simple transport options. Within the Nexsan GUI, we 4Gbps FCreadily shared volumes that were used as VOE datastores by ESXi hosts and a Windows server that was used to HBAs,run backup software. More importantly, the SASBeast facilitated our ability to switch between a local Disaster SASBeastRecovery (DR) scenario, in which both the VOE host and the Windows server connected to the datastore volumeover the FC fabric, and a remote DR scenario, in which the Windows server connected to the datastore via our systems areiSCSI fabric. now shipping with a new generation of 8Gbps FC ports. 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. 8. VOE Test Scenariodown to multiple VMs. To extend the service life of disk drives, the SASBeast positions disks vertically inopposing order—alternating between front-to-front and then back-to-back. This layoutdampens the natural rotational vibrations generated by each drive. Mounting all of thedrives in parallel tends to amplify these vibrations and induce head positioning errors onreads and writes. Head positioning errors are particularly problematic in a VOE, which ischaracterized by random small-block I/O requests. In such an environment, data accesstime 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 molecularcontact as air flows over external drive surfaces. As a result, air pressure is just asimportant as air flow for proper cooling. To facilitate testing, our Nexsan SASBeast was provisioned with twenty eight 15K rpmSAS drives and fourteen 2TB SATA drives. To configure internal arrays and provideexternal access to target volumes, our SASBeast was set up with two controllers, whichcould be used to create both SAS and SATA arrays and which featured a pair of FC and apair of iSCSI ports per controller. Also embedded in the unit was version 1.5.4 of theNexsan management software, which we tightly integrated with MMC on all of ourWindows-based servers. Using this storage infrastructure, we were able to provide ourVOE and physical server environments with storage hierarchies designed to meet robustsets of application-specific SLA metrics. In particular, we configured three RAID arrays on the SASBeast: Two arrays utilizedSAS drives and one array utilized SATA drives. For optimal IOPS performance, wecreated a 7.2TB RAID-5 SAS array on controller 0. Then on controller 1, we created a6.6TB RAID-6 SAS array for higher availability.VOE CONSOLIDATION We implemented our vSphere™ 4.1 VOE, on a quad-processor HP ProLiant® DL580server running the VMware ESXi™ 4.1 hypervisor. This server hosted 12 VMs running amix 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 storagehierarchy that was undergirded by three central datastores that were created on each ofthe three arrays set up on the Nexsan SASBeast. To manage VM backups, we installed Veeam Backup & Replication v4.1 on a quad-core Dell® PowerEdge® 1900 server, which ran Windows Server 2008 R2 and sharedaccess to each datastore mapped to the VOE host. We tested datastore access over bothour FC fabric, which represented a local DR scenario, and over our iSCSI fabric, whichrepresented a remote DR scenario. In addition, we mapped another RAID-5 SATAvolume 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. 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. 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 To maximize performance in our VOE, we biased I/O caching on the SASBeast for controllers and two FC portsrandom access. As the host consolidates the I/O streams of multiple VMs, sequential I/Os on each controller can presentfor multiple VMs are consolidated by the host with the result that random access I/O four distinct paths to eachbecomes a key characteristic for a VOE host. We also set up an I/O multipathing scheme volume exposed.on the Nexsan SASBeast that allowed us to map any array volume to one or all FibreChannel and all iSCSI ports. 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. 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 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 When either an ESX or an ESXi 4.1 hypervisor discovers a volume exposed by the Nexsan system that is using theSASBeast, it defaults to making only one path active for I/O. We changed this default to round robin SASBeast as a target.access. When this change is made, the new drivers in ESXI 4.1 did a SCSI inquiry on the FCvolume and discovered that the Nexsan was an ALUA device. As a result, the hypervisor set up the Both Windows Serverfour paths to the servicing controller as active optimized and the four paths to the other controller 2008, which uses aas non-optimized. Using ESX or ESXi 4.0, all eight paths would set as equally active for I/O. 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. 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. 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 Upgrading to vSphere 4.1 from vSphere 4.0 boosted I/O throughput by 20% writes to controller 0, which serviced thefor VMs resident on a datastore imported from the SASBeast. More SAS RAID-5 volume. In contrast readimportantly for IT OpEx costs, gains in I/O throughput required a simple and write data requests were transmittedchange in the MPIO policy for each datastore imported from the SASBeast. 11
  12. 12. VOE Test Scenarioto all of the FC ports on both of the SASBeast controllers equally, when the host wasrunning ESXi 4.0. With all I/O requests directed equally across all FC ports under ESXi 4.0, throughputat each undistinguished port was highly variable as I/O requests arrived for both disksserviced by the controller and disks serviced by the other controller. As a result, I/Othroughput averaged about 200MB per second. On the other hand, with our VOE host running ESXi 4.1, I/O requests for a logicaldisk from the SASBeast were only directed to and balanced over the FC ports on thecontroller servicing that disk. In this situation, full duplex reads and writes averaged240MB per second as we migrated our VM from one datastore to another. For IToperations, I/O throughput under ESXi 4.1 for a VM accessing a SASBeast disk volumereached comparable levels of performance—particularly with respect to IOPS—to that ofa physical server. 12
  13. 13. SASBeast Performance SpectrumSASBeast Performance Spectrum sing four Iometer worker processes—two reading and one “U 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. We began our Fibre Channel Sequential Access I/O Throughput benchmark testing Windows Server 2008 R2 — Round Robin with Subset MPIO on a 4Gbps FC SAN by reading data Read Throughput Write Throughput Application Throughput using large blockRAID & Disk Type Iometer benchmark Iometer benchmark Veeam Backup & Replication 4.1 I/O requests over 128KB blocks 128KB blocks Parallel backup of four VMs two FC 245 MB/sec connections. RAID-5 SAS 554 MB/sec 400 MB/sec Maximum I/O reading VM data throughput varied RAID-6 SAS 505 MB/sec 372 MB/sec among our three 245 MB/sec logical volumes by RAID-5 SATA 522 MB/sec 430 MB/sec writing backup image 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. 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 Read Throughput Write Throughput Application ThroughputRAID & Disk Type Iometer benchmark Iometer benchmark Veeam Backup & Replication 4.1 128KB blocks 128KB blocks 4 VM backups in parallel 82 MB/sec (1 HBA) 83 MB/sec (1 HBA) RAID-5 SAS 146 MB/sec (2 HBAs) 146 MB/sec (2 HBAs) 80 MB/sec (1 HBA 85 MB/sec (1 HBA) 136 MB/sec RAID-5 SATA 145 MB/sec (2 HBAs) 150 MB/sec (2 HBAs) 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. 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 SAS- based 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) 4Gbps FC Fabric 4Gbps FC Fabric 1GbE iSCSI Fabric MS ExchangeRAID & Disk Type 1 logical disk 2 logical disks 1 logical disk Heavy use (75% reads) 30ms average access time 30ms average access time 30ms average access time 4KB I/O 2,000 mail boxes 2,330 IOPS (4KB I/O) 4,318 IOPS (4KB I/O) 1,910 IOPS (4KB I/O) RAID-5 SAS 1,500 IOPS 2,280 IOPS (8KB I/O) 4,190 IOPS (8KB I/O) 1,825 IOPS (8KB I/O) 1,970 IOPS (4KB I/O) 1,350 IOPS (4KB I/O) RAID-6 SAS 1,915 IOPS (8KB I/O) 1,275 IOPS (8KB I/O) 1,165 IOPS (4KB I/O) 795 IOPS (4KB I/O) RAID-5 SATA 1,120 IOPS (8KB 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 1910 15
  16. 16. SASBeast Performance Spectrum 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 MS Exchange VM Datastore Random Access Sequential Throughput Heavy use (75% reads) 1 Logical disk, 80% ReadsRAID & Disk Type Streaming 128KB blocks 4KB I/O 30ms average access time 2,000 mail boxes 436 MB/sec (Reads) 2,380 IOPS (4KB I/O) RAID-5 SAS 1,500 IOPS 377 MB/sec (Writes) 2,011 IOPS (8KB I/O) 427 MB/sec (Reads) 2,325 IOPS (4KB I/O) RAID-6 SAS 342 MB/sec (Writes) 1,948 IOPS (8KB I/O) 420 MB/sec (Reads) RAID-5 SATA 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 2008. 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. 17. SASBeast Performance Spectrumapplications, such as backup, data mining, and video editing, on physical servers anddedicated workstations. As a result, IT should have no problems supporting streamingapplications on server VMs or using packaged VM appliances with storage resourcesunderpinned by a SASBeast. On the other hand, we sustained IOPS levels for random access I/O on RAID-5 andRAID-6 SAS volumes that differed by only 2 to 3 percent from the levels sustained on aphysical server. These results are important for VM deployment of mission-criticaldatabase-driven applications, such as SAP. What’s more, the ability to sustain 2,380 IOPSusing 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 touse the results as a means of predicting the performance of applications. To put oursynthetic benchmark results into perspective, we next examined full-duplex streamingthroughput for a high end IT administrative application: VOE backup. What makes a VOE backup process a bellwether application for streaming I/Othroughput is the representation of VM logical disk volumes as single disk files on thehost computer, This encapsulation of VM data files into a single container file makesimage-level backups faster than traditional file-level backups and enhances VMrestoration. Virtual disks can be restored as whole images or individual files can berestored from within the backup image. More importantly, VMFS treats files representing VM virtual disks—dubbed a .vmdkfiles—analogously to a CD images. Host datastores typically contain only a small numberof these files, which can be accessed by only one VM process at a time. It is up to the OSof 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 aSAN. The ability to share datastores among hosts greatly simplifies the implementationof vMotion, which moves VMs from one host to another for load balancing. With shareddatastores, 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 andbrought to the saved state on a new host. Sharing datastores over a SAN is also very important for optimizing VM backups. Forour VOE backup scenario, we utilized Veeam Backup & Replication 4.1 on a Windowsserver that shared access to all datastores belonging to hosts in our vSphere VOE. Every VM backup process starts with the backup application sending a VMsnapcommand to the host server to initiate a VM snapshot. In the snapshot process, the VMhost server creates a point-in-time copy of the VM’s virtual disk. The host server thenfreezes the vmdk file associated with that virtual disk and returns a list of disk blocks forthat vmdk file to the backup application. The backup application then uses that block listto read the VM snapshot data residing in the VMFS datastore. 17
  18. 18. SASBeast Performance Spectrum To implement the fastestSIMPLIFIED VOE DATASTORE SHARING 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 Reflecting the interoperability of the Nexsan SASBeast, we were able to use Storage can use Storage Manager for Manager for SANs within the Server Manager tool, to create and manage volumes, such as SANs to create new LUNs the vOperations datastore used by our ESXi host. In particular we were able to drill down on and manage existing ones on the vOperations volume and map it to our Windows Server 2008 R2 system via either our FC fabric or, our iSCSI fabric. 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. To minimize backup Application Throughput: VOE Full-Backup windows in a vSphere VOE, RAID-5 SAS Datastore — RAID-5 SATA Backup Repository Veeam Backup & Replication ESXi 4.1 Host, Windows Server 2008 R2, Veeam Backup & Recovery 4.1 uses vStorage APIs to 4VMs Processed Sequentially 4VMs Processed in Parallel directly back up filesDatastore Access belonging to a VM without Optimal compression, Deduplication Optimal compression first making a local copy. FC SAN Fabric 164 MB/sec 245 MB/sec What’s more, Veeam Backup and Replication recognizesiSCSI SAN Fabric 97 MB/sec 136 MB/sec disks with VMFS thin provisioning to avoid 18
  19. 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 power- saving 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 theAUTOMAID 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 arraysthe test period, AutoMAID provided fairly uniform power savings across all arrays, amounting to just over 50% was remarkableof 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. 20. Customer ValueCustomer Value hile Nexsan’s storage management software provides a number of “W 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. While reducing OpEx and CapEx costs NEXSAN SASBEAST FEATURE BENEFITS are the critical divers in justifying the1) Application-centric Storage: Storage volumes can be created from acquisition of storage resources, those a hierarchy of drives to meet multiple application-specific metrics. resources must first and foremost meet the2) I/O Retries Minimized: During our testing we executed a total of 95 performance metrics needed by end-user million read and write I/Os without a single retry. organizations and frequently codified in3) Automatic Power Savings: AutoMAID technology can be set to SLAs set up between IT and Line of place drives in a hierarchy of idle states to conserve energy, while Business (LoB) divisions. These metrics only delaying the first I/O request returning to a normal state. address all of the end user’s needs for4) High Streaming Throughput: Running with SAS- and SATA-based successfully completing LoB tasks. volumes, application performance mirrored benchmark performance Typically these requirements translate into as backups of multiple VMs streamed total full-duplex data at data throughput (MB per second) and data upwards of 500MB per second. response (average access time) metrics.5) Linear Scaling of IOPS in a VOE: Using random 4KB and 8KB I/O requests—typical of Exchange Server and SQL Server—VMs In terms of common SLA metrics, our sustained IOPS rates for both I/O sizes that differed by less than 2.5 benchmarks for a single SASBeast reached percent on a SAS RAID-5 volume and scaled by over 80% with the levels of performance that should easily addition of a second target volume. meet the requirements of most applications. What’s more, the scale-out- oriented 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. 21. Customer Value We measured equally impressive IOPS rates for random access small-block—4KB and8KB—I/O requests. With one logical disk, we sustained more than 2,000 IOPS for both4KB and 8KB I/O requests which scaled to over 4,000 IOPS with two logical disks. Toput this into perspective, Microsoft recommends a storage infrastructure that can sustain1,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 guaranteeduptime is another important component of SAL requirements. Starting with themechanical design of the chassis and moving through to the embedded managementsoftware, Nexsan’s SASBeast provides a storage platform that promotes robust reliabilityand performance while presenting IT administrators with an easy to configure andmanage storage resource. In particular, the design of the SASBeast chassis proactively seeks to maximize the lifespan of disks by minimizing vibrations and maximizing cooling. For IT operations—especially with respect to SLAs—that design helps ensure storage performance guarantiesconcerning I/O throughput and data access will not be negatively impacted by dataaccess 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 degradedperformance 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 theoccurrence of a single read or write retry.SIMPLIFIED MANAGEMENT DRIVES SAVINGS While Nexsan’s storage management software provides a number of important featuresto enhance IT productivity, the most important feature for lowering OpEx costs in acomplex SAN topology is tight integration with VDS on Windows. For IT administrators,VDS integration makes the Nexsan storage management GUI available from a number ofthe standard tools on a Windows server. In particular, IT administrators are able to useStorage Manager for SANs to implement full end-to-end storage provisioning. By invokingjust one tool, an administrator can configure a Nexsan array, create and map a logicalvolume to a host server, and then format that volume on the host. Nexsan also leverages very sophisticated SAN constructs to simplify administrativetasks. All storage systems with multiple controllers need to handle the dual issues of arrayownership—active service processors—and SAN load balancing—active ports. ThroughNexsan’s implementation of Asymmetric Logical Unit Access (ALUA), host systems withadvanced MPIO software can access a SASBeast and discern the subtle difference betweenan active port and active service processor. As a result, an IT administrator is able to map aLUN to each FC port on each controller and allow the server’s MPIO software to optimizeFC port aggregation and controller failover. Using this scheme openBench Labs was able toscale streaming reads and writes to four drives at upwards of 1GB per second. 21
  22. 22. Customer ValueREVOLUTIONARY GREEN SAVINGS In addition to providing an innovative solution for reliability and performance,Nexsan’s AutoMAID power management scheme automatically reduces SASBeast powerconsumption, which is a significant OpEx cost at large sites. Using three levels ofautomated power-saving algorithms, the SASBeast, eliminates any need for administratorintervention 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 featuredubbed AutoMAID™. AutoMAID works on a per-disk basis, but within the context of aRAID set, to provide multiple levels of power savings—from parking heads to slowingrotational speed—to further contain OpEX costs. While testing the SASBeast,openBench Labs garnered a 52% power savings on our arrays. 22