Nexsan E-Series and Quantum StorNext Automate SAN Volume Sharing

Transcription

1 openbench Labs Executive Briefing: Nexsan E-Series and Quantum StorNext Automate SAN Volume Sharing Simplifying Collaboration through Automated SAN Volume Sharing March 20, 2012

2 Executive Briefing: Jack Fegreus March 20, 2012 Nexsan E-Series and Quantum StorNext Automate SAN Volume Sharing Simplifying Collaboration through Automated SAN Volume Sharing UNLIMITED LEVERAGE At small- to medium-size enterprise (SME) sites, file serving remains a dominant application. Frequently, smaller SME sites standardize on Windows Server 2008 R2 as their Corona-Norco case study initial file-serving solution of choice. Larger sites, however, E-Series data and specification sheets are fast replacing network file servers with Microsoft Storage Switzerland white paper SharePoint, which utilizes a SQL Server database to manage SUBMIT access to documents for information sharing and workplace collaboration. Helping drive this change, numerous corporations are pursuing highly transformative marketing objectives based on leveraging new IT technologies. Under TesT: san VolUme sharing Nexsan E18 Enterprise Storage Array & Quantum StorNext 1) Leverage strict storage standards compliance to integrate tightly with multiple APIs to leverage productivity features developed by third-party vendors: Through strict compliance with Windows and vstorage APIs, Nexsan allows IT to utilize a wealth of storage management tools on client systems to provide end-to-end visibility for all storage resources utilized in delivering a shared-file system to heterogeneous clients over a SAN. 2) Create a highly scalable storage cloud that can be managed as a single virtual entity: The Nexsan management software integrates with the Windows Virtual Disk Service (VDS) to provide a complete single-pane-of-glass storage management interface for Nexsan and Microsoft storage management tools, including Server Manager and Storage Manager for SANs, to provide full access to all Nexsan configuration data and directly manage any Nexsan device. 3) Automate I/O Performance: Through strict compliance with advanced storage standards, Nexsan storage arrays offer sophisticated dynamic MPIO options including Asymmetric LUN Access (ALUA) load balancing, SCSI storage reservations that persist over bus resets and biased FC/iSCSI path utilization. 4) Maximize Density and Reliability with Hierarchical Storage: Nexsan devices support a mix of SSD, SAS, and SATA drives to support a full range of SLA storage requirements with respect to capacity, throughput, access, and reliability. NEXSAN Information Kit Line of Business (LOB) executives at these corporations are pressuring CIOs to focus on fast scalable delivery of services that support internal collaboration and external client interaction. For LOB executives, such initiatives exhibit a high potential to transform business processes. For IT administrators, however, these initiatives present many of the same data management issues associated with scale out and availability that plague network file servers along with new content-management complexities. IT can simplify many of the storage resource management tasks associated with mandates to transform business processes using Nexsan arrays. Thanks to the Nexsan Flexible Storage Platform strategy, IT administrators can harness a wide range of thirdparty storage application software via Nexsan s extensive API integration and 02

3 strict implementation of SCSI 3 standards in addition to using Nexsan s storage system software for traditional array-managed storage operations. Nexsan's Flexible Storage Platform enables IT to implement a stack-managed approach to storage management that incorporates many technologies from multiple vendors with any Nexsan array to create an agile infrastructure that can scale and operate economically in a cloud environment. More importantly, the stack of third-party storage applications that IT can leverage with Nexsan arrays extends to a host of critical complementary and alternative software options for any strategic IT initiative, including robust options for the delivery of either collaboration or client interaction services. In particular, IT can leverage the capability of the Nexsan E-Series array to simultaneously support industry-leading SSD, SAS, and SATA storage in a highly scalable, highly available, SAN-based array. What s more, Nexsan arrays can be used in conjunction with Quantum s StorNext software to create a sophisticated file sharing scheme that many dub a clustered file system. N exsan's Flexible Storage Platform enables IT to implement a stackmanaged approach to storage management that incorporates many technologies from multiple vendors with any Nexsan array to create an agile infrastructure that can scale and operate economically in a cloud environment. StorNext virtualizes the block pools associated with independent groups of storage volumes. Each independent block pool is conceptually similar to the global virtual file-space model that Dell s Compellent line dubs Dynamic Block Architecture. Under the StorNext scheme, each virtual block pool is dubbed a file system and presented as a single mount point to multiple clients simultaneously. What s more, IT administrators can extend the StorNext scheme beyond the reach of an FC SAN using a Distributed LAN with a proprietary TCP protocol. Unlike conventional NFS- or CIFS-based NAS file sharing, StorNext s Distributed LAN protocol supports clients with multiple NICs for greater throughput, fault tolerance, load balancing, and higher scalability. More importantly, the level of performance and the degree of scalability measured for StorNext is directly attributable to the underlying Nexsan array and the I/O subsystem power of the client systems. StorNext overhead is focused at Meta Data Controllers (MDCs), which are at the heart of StorNext configurations, and occurs principally at setup, when the block pool for a StorNext file system is virtualized, and during off hours, when scheduled sweeps of the file system move unused files to near-line storage. BUILDING BLOCKS FOR SANS AND BEYOND Our examination of StorNext running on Nexsan E60, SASBeast, and SATABeast arrays, is a strong metaphor for the rapid expansion of resource virtualization that is pushing the long standing IT distributed architecture paradigm towards a critical tipping point. At issue is the generalization of distributed computing into cloud architecture. The pivotal resource for this tipping point is a SAN-based storage. In a cloud environment, storage resources must be capable of scaling out in both capacity and performance as virtual infrastructure (VI) initiatives intensify the demands 03

4 on storage servers. In a traditional SAN environment, I/O fan-out is patterned on a few storage resources attached to many lightly-loaded physical servers. In a VI environment, however, multiple Virtual Machines (VMs) generating distinct predictable I/O streams are consolidated on a small number of physical hosts running hypervisor software. By concentrating the I/O streams of local VMs, VI hosts present storage resources with far more intense and far less predictable I/O streams that stress both I/O latency and throughput. As a result, storage arrays are inextricably linked to the capital and operational expenses that IT must restructure in order to maximize the return on investment (ROI) of a VI initiative. To meet the broadest possible range of storage needs, the Nexsan E-Series can be populated with drives three times more densely than competitive arrays: A 4U E60 can hold 60 drives and a 2U E18 can hold 18 drives. To ensure reliability in such densely packed environments, all E-Series arrays extend the design features that remove heat and vibration from the chassis of the company s highly successful SAS and SATABeast lines. G iven the hardware configuration of a Nexsan E-Series array, its I/O throughput potential reaches upwards of 8GB per second. Among the new technologies in E- Series arrays, Nexsan introduced Active Drawer Technology, which allows an IT administrator to pull out a single drawer of drives typically to replace a known failed drive while keeping the system online. To accelerate read and write IOPS in workloads that utilize small random I/O requests, E-Series arrays support solid-state drives (SSDs), which come in a 2.5-inch form factor, have a 6Gb/s SAS interface, feature capacities up to 400GB, and utilize enterprise-grade SLC NAND Flash memory. The E-Series also introduces a fourth level of power reduction in AutoMAID to extend power savings. To further enhance performance, Nexsan E-Series array can be populated with SSD, SAS, and SATA drives in the same chassis and each E-Series I/O controller, whether 8Gb Fibre Channel (FC) or 10Gb iscsi, features dual RAID engines. For maximum throughput and configuration flexibility, each E-Series array can be provisioned with two dual-fc and two dual-iscsi controllers, all of which interoperate simultaneously. Given the hardware configuration of a Nexsan E-Series array, its I/O throughput potential reaches upwards of 8GB per second. Not surprisingly, leveraging the full performance capability of a E-Series array requires deploying the latest advances in server I/O architecture. New high-end Intel servers, such as the Dell R610 that we used in testing, implement the Intel QuickPath Interconnect (QPI), which is a point-to-point processor interconnect patterned on the crossbar architecture used in large mainframes and supercomputers. QPI replaces the older Front Side Bus (FSB) of Xeon-based systems with a switch that provides separate parallel lanes for the CPU to transmit and receive I/O data at the same time. With QPI, server I/O throughput and IOPS performance scales dramatically higher. This boost in performance is especially important in a VI environment. Individual server applications seldom challenge the throughput or IOPS, performance an E60 can deliver. The 04

5 key to maximizing E60 value is the presence of multiple users and multiple applications. STREAMING BEYOND APPLICATIONS Before examining StorNext, we first established I/O performance parameters for our Nexsan E60 and SATABeast with QPI-based servers running Windows Server 2008 R2. We began our testing of the Nexsan E18 array by running synthetic benchmarks that stressed sequential data throughput using large block (128KB) I/O requests. We used Iometer to generate sequential large block reads and writes, which are characteristic of backup, data mining, and online analytical processing (OLAP) applications. SSD Growing STREAMING HD VIDEO EDITING BENCHMARK use of customer facing video data has introduced a new class of video content creation applications dubbed Non Linear Editing (NLE) which stream large I/O blocks sequentially. What s more, NLE software depends entirely on strick minimum storage As a real world test of I/O streaming, we ran an NLE content creation scenario, in which we simultaneously performance to read and wrote 36,000 frames of HD video using the Panasonic 1080i60 HD video format. Using the Panasonic prevent frame format, our video file consumed 16GB, required 100Mbps throughput for playback, and imposed a minimum drop. As a 450Mbps throughput heuristic on professional NLE systems. Using a hybrid storage strategy, NLE functions were performed on volumes provisioned on a single SSD-based array in an E18, while video distribution utilized result, NLE volumes from a SATA array. We launched multiple NLE processes to generate simultaneous streams of reads storage and writes and sustained a read throughput of 242MB per second and a write at 212MB per second on each of configurations two user processes performing reads and writes in opposing order. typically feature both SSD and HDD arrays to ensure that multiple editing streams will scale within a user pool while continuing to meet strict performance and space requirements. To assess performance capabilities with respect to data throughput and data access, we set up four E18 arrays: Two arrays were configured with external FC connections and two arrays were configured for a 10GbE iscsi SAN. To maximize I/O performance 05

6 during our tests, we used two Dell R610 and two Dell R710 PowerEdge servers running Windows Server 2008 R2. For FC connections, we installed QLogic QLE 2562 HBAs and for 10GbE iscsi traffic, we installed Intel X520 HBAs. Servers capable of sustaining a high IOPS rate are essential for leveraging Nexsan E- Series arrays provisioned with solid-state drives (SSDs), which utilize enterprise-grade SLC NAND Flash memory. With QPI architecture, both the I/O throughput and IOPS performance of a server scale dramatically higher. While the performance capabilities of QPI-based servers in combination with Nexsan E-Series arrays is especially important in a VI environment, a single user process is simply incapable of reaching the throughput or IOPS potential of an E18. array. A single instance of any application cannot generate enough I/O to maximize command queue or cache performance. When working with HDD-based arrays, a full command queue, which can be freely reordered is essential for minimizing rotational latency. Even when working with SSD-based logical volumes, such as in our NLE content creation scenario, the key to maximizing the value of an E-Series array is the presence of multiple independent user processes. SAN Fabric, Disk Type FC SAN SSD* iscsi SAN SSD* FC SAN SAS iscsi SAN SAS FC SAN SATA iscsi SAN SATA Nexsan E18 Sequential I/O Performance Iometer 128KB Read and Write Requests Sequential Reads 1 LUN, 1 Controller Sequential Reads 2 LUNs, 2 Controllers Sequential Writes 1 LUN, 1 Controller 1,036 MB/sec 1,932 MB/sec 580 MB/sec 922 MB/sec 1,719 MB/sec 516 MB/sec 1,525 MB/sec 2,176 MB/sec 980 MB/sec 1,355 MB/sec 1,935 MB/sec 872 MB/sec 1,405 MB/sec 2,164 MB/sec 1,004 MB/sec 1,219 MB/sec 1,849 MB/sec 854 MB/sec *Using current production firmware. Pending beta firmware eliminates double cache flushes. **E60 Array We began our examination of E18 performance with an assessment of sequential read and write throughput. For these tests we used Iometer, to create synthetic I/O workloads that artificially generated enough asynchronous large-block read and write requests to keep all command queues full throughout the test of a logical disk. We started using logical disks provisioned on a single array within an E18.On each E-Series system, we used all of the standard default settings for a general purpose I/O in APAL mode. We set no specialized cache performance setting to favor streaming or random I/O and did not disable any fault tolerance mechanisms, such as cache mirroring, to minimize overhead. Using a standard production configuration, each logical disk had two optimal paths that 06

7 connected the two ports on its master controller with each HBA SAN port on the test server. This scenario created six baseline tests: One created for each disk type (SSD, SAS. and SATA) and one created for each SAN type (8Gbps FC and 10GbE iscsi). Using logical drives provisioned from one array and one controller on an FC SAN fabric, we consistently measured read throughput levels of around 1,500MB per second with SAS-based logical volumes and 1,400MB per second with SATA-based volumes. Running the same tests on an iscsi fabric, which was set for standard size rather than jumbo IP packets, produced similar results that were typically within 90% of the throughput level measured on an FC SAN fabric. While SDD drives are typically associated with dramatic acceleration of random access I/O transactions, we observed important differences in sequential throughput scalability using SSD-based volumes in our NLE application scenario. The characteristics of sequential throughput with SSD-based volumes have important ramifications for application scaling. For a command queue depth of 4 or less, logical volumes backed by an SSD-based array provided a distinct advantage in sequential throughput. We also measured less throughput variability with respect to the command queue length for SSD-based logical volumes. Less performance variability makes it easier for IT to plan, scale, and support applications that require specific levels of service, such as video creation. On the other hand, as the command queue filled to 8 or more outstanding requests, streaming I/O throughput for both SAS- and SATA-based logical volumes surpassed that of SSD-based volumes with the current E-Series firmware. A new beta version of the E- Series controller firmware, however, eliminates duplicate issueing of SSD cache flush commands that are now done by firmware in all qualified SSD drives. In I/O access tests, this change in overhead doubled our measurements for sustained IOPS rates. Using multiple logical volumes associated with arrays on each controller in the E18, sequential throughput scaled across all drive types over both FC and iscsi SANs. We regularly measured total sequential throughput for all scenarios within a tight range from 1,800MB per second to 2,200 per second with no specialized tuning for SAN fabrics or data stream characteristics. The only exception within our sequential throughput tests centered around our direct attached SAS connection with its significantly higher bandwidth than either 8Gbps FC or 10GbE iscsi. Using multiple SATA-based arrays, we were able to stream sequential reads at 3,015MB per second. This level of performance is four to five times greater than applications that rely on data streaming will typically generate. This head room on the E18 is essential for scaling multiple processes. For backup in particular, when performing 128KB writes, a SATA RAID-5 volume sustained an average streaming throughput of 1,005MB per second. Given the low cost and high capacity advantages provided by 2TB SATA drives, exceptional write throughput makes the E18 a real asset for Disk-to-Disk (D2D) backup. Moreover, Backup Exec 2012 and Veeam Backup & Replication v6 both utilize pools of 07

8 backup proxy servers to run multiple VM data protection processes in parallel, which is completely dependent of the sequential throughput head room that an E18 provides. In addition to streaming data in large blocks, there is also a need to satisfy small discrete I/O requests. Server applications built on databases, such as Oracle and SQL Server, generate large numbers of discrete I/O operations that transfer a small amount of data at a time. Commercial applications that rely on transaction processing (TP) include such staples as SAP and Microsoft Exchange. TP applications seldom exhibit steady-state characteristics. In a typical mid-market environment, TP loads for applications, such as SAP, average only several hundred IOPS. Nonetheless, these applications often experience heavy processing spikes, such as at the end of a financial period. The TP load during an intense processing period can reach several thousand IOPS. That variability makes TP applications among the most ideal to target for virtualization, since a well-managed VI can be configured to automatically marshal resources and position VMs on hosts to support peak processing demands. NEXSAN TRANSACTION PROCESSING To analyze IOPS performance of a E18 array, we ran our oblload benchmark, while observing the E18 with the Nexsan management console. Key metrics for this benchmark include the initial performance of a single worker process, which is indicative of the best performance that a single user can expect. The next key metric is the total throughput for multiple processes constrained by a fixed average access time (5ms in our tests). A single oblload process on a single logical SATA-based volume typically sustained about 400 IOPS, while an SSD-based volume sustained over 4,000 IOPS using current firmware. With multiple processes, the SATA-based volume sustained a maximum of 9,000 IOPS, while the SSD-based volume was able to sustain over 33,000 IOPS with an average access time that was under 2ms. To simulate real world database performance, 8KB reads. We also constrained our results with a global requirement that the average I/O response time be less than 10ms. A high IOPS load without a restriction on average response time creates highly unrealistic 08

9 results. More importantly, to stress the Nexsan array, we had to make sure that we were timing only I/O requests and responses on the server. This necessitated generating thousands of block addresses outside of the timing loop using our oblload benchmark. SAN Fabric, Disk Type FC SAN, SSD Nexsan E18 IOPS oblload 8KB Random Read Requests Single User Sustained IOPS 1 LUN, 1 Controller, 10ms max average access time 4,400 IOPS* 9,000 IOPS* IOPS Maximum Sustained IOPS 1 LUN, 1 Controller, 10ms max average access time 33,000 IOPS* 67,500 IOPS FC SAN SAS 590 IOPS 14,775 IOPS FC SAN SATA 395 IOPS 9,000 IOPS *Using current production firmware. Pending beta firmware eliminates double cache flushes. IOPS benchmarking of the Nexsan E18 was characterized by the greatest variations in I/O performance that we measured. We conducted all of our IOPS tests on an FC SAN using a single 1TB logical volume to minimize cache effects from both the server and the large controller caches on the Nexsan E18. Not surprising, we measured the lowest sustained IOPS rate with a SATA-based logical volume at 9,000 IOPS A SAS-based array with 15,000 RPM disks sustained 14,775 IOPS, which was about 64% greater than the transaction load sustained by a SATA-based array. Testing an SSD-based volume demonstrated how a small amount of overhead can make a dramatic effect on IOPS performance. With the current production software, we were able to sustain 33,IOPS with an SSD-based volume. With new firmware that no longer issues cache flush commands to qualified SSD drives, all of which manage cache flushes with their own embedded firmware, we able to sustain 67,500 IOPS. NEXSAN STORNEXT SYNERGIES Quantum s shared SAN StorNext File System provides an ideal storage application to leverage all of the features of the Nexsan E60. Conceptually, the Quantum StorNext File System provides clients with direct shared access to logical disk volumes, which are distributed by a collection of MDCs, which act as file system name servers. To implement StorNext, we began by creating and exporting LUNS from the Nexsan E60 and SATABeast systems using SAS, SATA, and SSD arrays. For each StorNext file system, we initially striped four Nexsan LUNs, which were backed by SAS or SATA RAID- 5 arrays to store user data. Next, the physical disk block addresses underpinning the new StorNext logical drive were virtualized and placed in a small pool of address meta data. The meta data pool was then located on an additional stripe set created with two additional LUNs. SSD drives on the E60 provide a perfect solution for storing the meta data pool. To provide high availability, each file system is maintained as a totally self-contained entity with respect to data and meta data. As a result, each MDC shares access to all of the logical volumes that are exported by the Nexsan arrays to configure the StorNext logical file systems. In addition, every client needs to access all of the logical disks that 09

10 represent any StorNext file system that will be mounted on the client. That means client systems will also need access to the Nexsan arrays, which will be mounted as raw disks. STORNEXT FILE SYSTEM For StorNext, the disk configuration choices provided by the Nexsan E60 array are critical to successful implementation. From the user perspective, the critical storage components are the LUNs imported from the E60 that are striped for user data. Here, SAS disks provide a key advantage. In addition, there is also a hidden stripe set that holds journal and meta data about the file system blocks associated with user data, which is an ideal target for a RAID-0 SSD array. In addition, there are also storage disks, which are created as standard linux logical volumes and used as near-line storage for file versions and infrequently used data. When needed, this data must be stream quickly back to the front-end file system. Striped SATA RAID-5 LUNs are perfect for this feature. Access to a StorNext logical drive requires the installation of StorNext client software to handle data address queries with an MDC. As a result, client systems are not required to run the same operating system (OS) to access shared logical volumes. All of the MDC servers supporting a StorNext file system, however, must run the same OS in order to avoid data corruption running file system maintenance tasks, such as indexing. COLLABORATION PARADIGMS BEYON SHARING StorNext is commonly used in environments where large files must be shared by users without network delays. This includes real-time analysis of satellite image data and where 10

11 a file must be available for access by multiple readers starting at different times. Nonetheless, file sharing is just the common starting point for a StorNext installation. NEXSAN STORNEXT DATA DELIVERY When a client accessed data on a StorNext file system, the client first requested a virtual block address from the MDC. The MDC server then made a very small-block I/O requests directed at the meta data store. This I/O pattern is ideal for SSD drives since IOPS are virtually the sole consideration. Depending on the applications accessing user data, either SAS or SATA arrays should be used to underpin user data. In data streaming applications, such as writing and reading video frame data with a Mac, FSB-based clients consistently accessed data on SATAbased arrays at around 500MB per second. By careful provisioning the base arrays, I/O was perfectly spread over both Nexsan controllers. In our tests, we used either Red Hat Linux 5.7 or Windows-Server 2008 R2 on MDC servers. All StorNext clients ran either Windows 7 or Windows Server 2008 R2, Mac OS X Lion with X-San, or Red Hat Linux 5.7. All of these clients directly accessed shared data over our SAN. In these scenarios, FSB-based clients consistently streamed shared data at throughput rates around 500MB per second. More importantly, a shared SAN file system makes all user data local, which eliminates the need for local copies of documents. As a 11

12 result, the need for high-overhead block deduplication is dramatically lower. A client accesses data by requesting data addresses from the MDC server over a LAN. The client then uses the returned addresses for direct SAN data. As a result, client systems directly accessed only the four Nexsan arrays that were striped and provisioned with user data, while MDC servers primarily accessed only the two disks provisioned with virtualized block meta data. By accelerating MDC access to the block meta data and giving clients direct access to data on E60 arrays, the StorNext scheme proved to be extraordinarily responsive. In particular IOPS performance for a user data was 35% greater with Nexsan and StorNext when compared to Compellent. The operational performance of Nexsan arrays with StorNext is all the more important given Gartner s research showing nearly half of new SharePoint installations are used simply for file sharing and not content management. On the other hand, when StorNext is managed on MDCs running Linux, a number of automated storage management features become available to both IT administrators and end users. Among the added storage management features are a sophisticated additional tier of near-line storage pool for infrequently used files and time-based file versions. The nearline pool can be either tape- or disk-based, in which case it is dubbed an SDISK and given a local mount point on the Linux file system. We created an SDISK using striped logical volumes in the Red Hat Logical Volume Manager from SATA-based arrays connected to both Nexsan controllers for automatic load balancing with respect to the Nexsan array. Storage polices created by IT and assigned to file systems, fill the role of Compellent s Data Progression function by automatically replacing files on the primary storage tier with stubs pointing to a new location on the SDISK. As a result, the shared file system can be optimized around a SAS tier for active files that need TP supported and a SATA tier where high throughput is more important than a high IOPS rate. While StorNext only adds its sophisticated storage management module when running on a Linux-based MDC, the StorNext file system runs perfectly well on a collection of 64-bit Windows Servers. From the StorNext client perspective, there is no difference between a Linux based MDC and a Windows-based MDC. The end-user experience is exactly the same in both cases. In contrast, IT no longer has access to the specialized tape library-centric backup software that is part of the StorNext storage management module. As a result, IT must be able to implement an external data protection service that can handle a non NTFS file system. This problem is easily resolved with Symantec Backup Exec, which inherits the storng integration of Nexsan with Symantec s Storage Foundation. Thanks to this integration, Nexsan arrays can be completely provisioned directly from the Backup Exec GUI. This creates a very fast storage repository for Backup Exec. In test by openbench Labs, we measured total peak throughput of 400MB per second while simultaneously reading and writing data during a backup job. 12

13 MAKING COMPLEX SHARING MANAGABLE SAN MANAGEMENT FOR STORNEXT Too often, SAN fabric management devolves to a point where IT views storage resources as isolated pools of logical disks that require proprietary management processes. Such SAN resource isolation leaves IT organizations without a clear set of links needed to tie storage resources with critical applications to evaluate business value in key business initiatives. Nexsan s extensive API integration with Windows and VMware greatly simplifies IT management tasks, In a Windows when advanced StorNext functions are invoked on Linux-based MDC servers. Using servers running Linux Server to manage StorNext enables more features to manage, while simultaneously making management more environment, which complicated. Once our Nexsan arrays were encapsuloated by the Red Hat OS or the StorNext application, is pegged as all storage resource information was lost. On clients running Windows Server 2008 R2, however, we were able to access a wealth of Nexsan resource details for each LUN used to support a StorNext file system. representing nearly 75 percent of the server market in 2010, integration of Nexsan s device firmware with Windows Server APIs, including the Virtual Disk Service (VDS), significantly raises the visibility of Nexsan internal devices and lowers the complexity of storage management tasks for IT administrators, who gain immediate access to essential information needed to simplify SAN management tasks and reduce OpEx costs associated with resolving SAN performance issues with StorNext. At a base level, logical disks created on Nexsan devices have extended property sheets that include the name of the specific Nexsan device on which the logical disk was created, the array used within that device, and the internal name of the array partition that was mapped as a LUN. Through integration with VDS, Nexsan is able to leverage the Microsoft management stack, including Storage Manager for SANs and System Center for Virtual Machine Management to provide IT administrators with higher levels of functionality to improve IT productivity. 13

14 AUTOMATING PERFORMANCE OPTIMIZATION While IT overhead is the primary factor in operating cost B y complimenting high performance with sophisticated management software and tight integration with third-party applications, Nexsan empowers IT to use any advanced automation features to provision storage, enhance application performance and ensure process availability. reduction, CIOs also have to worry about meeting Service Level Agreements (SLAs) made with Line of Business executives in association with initiatives such as enhanced internal and external collaboration. These executives think in terms of business process parameters. So SLA objectives focus around two distinct notions: process availability and process performance. The robust Nexsan hardware architecture combined with Nexsan's Flexible Storage Platform strategy provides IT with a storage platform that satisfies a wide range of performance metrics with respect to access (IOPS), throughput (MB per second), and capacity (price per GB), while simultaneously supporting multiple levels of availability. The bottom line for IT sites struggling with implementing critical business-driven initiatives from collaboration to cloud computing is Nexsan s ability to provide a highly manageable multi-fabric SAN infrastructure. By complimenting high performance with sophisticated management software and tight integration with third-party applications, Nexsan empowers IT to use any advanced automation features to provision storage, enhance application performance and ensure process availability. 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. 14