lab evaluation report virtualization with compellent ... · it-trendwatch evaluation report...

LAB EVALUATION REPORT

Virtualization with Compellent Storage Center and Syncsort Backup Express

By Bram Dons

IT-TrendWatch

August, 2009

IT-TrendWatch Evaluation Report

Virtualization with Compellent Storage Center and Syncsort Backup Express

Executive Summary Syncsort, Inc. and Compellent commissioned IT-TrendWatch, a research and test company, to perform a series of usability and performance tests with the Syncsort Backup Express (BEX) data protection software package. These tests were made in combination with a Compellent Storage Center Storage Area Network (SAN) which acted as the main storage and backup medium. The tests as described in this whitepaper focus on storage virtualization with the Compellent SAN and Syncsort’s unique use of VMware virtualization technology to back up and recover a Windows Server system. This unique solution made it possible for backup and recovery to be achieved more quickly and painlessly in comparison with standard existing industry backup applications.

Key Findings The tests demonstrate that the Syncsort/Compellent joint solution leverages virtual environments to provide extremely fast server recovery plus optimal storage usage. Findings show: Recovery of a 100 GB server in

only 4 minutes, enabling business to continue

Easy full server restore of 100 GB server in only 50 minutes vs. hours for competing solutions

Ability to maximize storage capacity through thin provisioning and tiered storage structure

Affordable storage that provides throughput comparable to enterprise-level storage array

Significance of Report Studies have shown that IT departments that operate in virtualized environments often experience the following data protection pain points: Their backup jobs are taking too

long or failing, due to reduced availability of CPU, memory or I/O resources

Their recovery times are elongated and recoveries are not application consistent

They need more storage because virtualization easiness has lead to server and data sprawl

They cannot move data quickly between virtual machines

This report provides proof of an affordable and reliable joint solution that expressly alleviates these pain points.

Process Overview In order to demonstrate this, we performed a series of backup and restore tasks using Syncsort BEX and Compellent Storage Center. During these tasks we measured the time it took to execute the backup, the ‘Instant Virtualization’ (IV) and ‘Full Virtualization’ (FV) capabilities of Syncsort’s data protection solution and we demonstrated the recovery methodologies. We also monitored the impact that the jobs have on CPU and network utilization and measured the storage performance. We tested Syncsort’s backup procedure with the Instant and Full Virtualization restore methods where a physical server was migrated to a VMware Virtual Machine. The main advantage of this restore method is that a complete server can be restored in a couple of minutes. Compare this with the traditional backup methods where a restore of a server can take hours or even a day or more. The whole backup/restore process, in which the physical server is transformed to a VM, is completely transparent for the user. Compared with traditional backups, there is no need to format the disks or install the operating system, drivers and applications. Restoring a crashed Client with more than 100GB of local storage via the Instant Virtualization method took only 4 minutes. The crashed server was restored on a VM with a minimum of down time so users could quickly continue with their work. The Full Virtualization method, in which the content of the complete backup disks where transferred to the ESX Server, took only 50 minutes. The test was executed in combination with a Compellent Storage Center disk array. It showed Compellent’s Thin Provisioning value when doing a backup in which only a small part of the provisioned storage capacity was used. During the block level base backup we noticed a total measured throughput of almost 118MBps, which is a level of performance a customer can expect from an enterprise type storage array.

Table of Contents

Introduction ................................................................................................................... 5

Co mpe lle nt Sto rage Cent er and Virt ua lizat io n ............................................................. 5 BEX Ad va nced Reco ver y Tec hno lo g ies ...................................................................... 5

S yncso rt BEX Archit ect ure.......................................................................................... 6 Creat ing V irt ua l Ma c hines w it h BEX .......................................................................... 7

Le verag ing a V irt ual St orage Enviro nme nt .................................................................. 8 Test Configu ration ...................................................................................................... 9

Using Co mpe lle nt Sto rage Cent er .............................................................................. 9 Test of Block Leve l Based Backup .............................................................................. 11

Test o f Inst ant Virt ua lizat io n ..................................................................................... 14 Creat ing t he Inst ant V irt ualiz at io n jo b ....................................................................... 14

Test of Fu ll Vi rtuali zation ........................................................................................... 19 Summa ry of Te st Results ............................................................................................ 21

Appendix A .................................................................................................................. 23 Profi le IT-TrendWatch ............................................................................................... 24


5

Copyright © 2009, IT-TrendWatch, All Rights Reserved

Introduction

Compellent Storage Center and Virtualization

The Compellent® Storage Center™ Storage Area Network (SAN) is an ideal

complement to the VMware environment because virtualized storage offers significant

and complementary benefits to virtualized applications. By creating a pool of virtual

storage volumes, the Compellent SAN provides the flexibility to change or move storage

attributes without affecting how storage is presented to the server. The Compellent

SAN reduces the overall storage capacity needed to support a VMware environment,

speeds up storage provisioning, simplifies storage management, enhances disaster

recovery and reduces the cost of acquisition, operation and management.

Like the VMware environment, the Compellent SAN abstracts storage attributes from

physical hardware. Storage is presented to virtual servers as disk capacity, regardless of

the mix of disk types, disk capacities and server connectivity selected by administrators.

As a result, administrators have the same sort of flexibility in making changes to virtual

storage volumes as they do with Virtual Machines (VMs). They can change RAID levels,

sto rage t iers a nd server co nnect ivit y w it ho ut chang ing ho w sto rage is prese nt ed to

servers.

By using VMware, the Compellent SAN and Syncsort‟s Backup Express together,

enterprises can compound the benefits of virtualization. The following features are ways

in which the Compellent SAN optimizes VMware server virtualization:

Thin Provisioning to conserve storage capacity

Automated Tiered Storage maximizes VM storage performance and efficiency

Server Instant Replay minimizes the capacity needed for VM clones

Automatic LUN Masking accelerates VM storage provisioning

Intuitive interface simplifies VM disaster recovery

Cost-Effective replication for VMware Site Recovery Manager

Persistent hardware architecture to protect technology investments

BEX Advanced Recovery Technologies

The BEX solution suite is a resource storage model that enables very frequent backups,

minimizes downtime and seamlessly integrates with routine, enterprise-wide backup and

recovery practices. A fundamental aim of BEX is reliable, economical, easy-to-

administer data protection that optimizes Recovery Point Objectives (RPO) and Recovery

Time Objectives (RTO).


6


The BEX Advanced Recovery technologies exploit image-based, block level protection

backup technology. This white paper will focus only on the BEX Advanced Recovery

solution in combination with VMware Virtual Machine Backup on the Compellent SAN.

It provides high-performance block level based backups to disk-based storage controlled

by Windows 2003 (r2) x64 servers (BEX Advanced Servers) and provides fast, reliable

block- and file- level recovery. A BEX Advanced Server supports direct, SAN (FC),

SCSI, or iSCSI attached storage.

BEX Advanced Recovery includes the following main features:

Zero-Impact Backup with Data Reduction and Multi-Purpose Snapshots

Server, File and Object Level Restore

Application Recovery

BEX Instant Availability

BEX Full Virtualization

BEX Instant Virtualization™

Bare Metal Recovery

VMware Virtual Machine Backup and Recovery

Syncsort BEX Architecture

The BEX architecture is based on three software-based components: Master Server,

Advanced Client and Advanced Server. The Master Server software is installed on one

machine. That machine holds and manages the BEX catalog and can be based on a

Windows 2000/2003 32-bit or Windows 2003/2008 64-bit operating system, UNIX,

Linux, or Novell OES. The BEX Advanced Client software, the BEX Management

console, user documentation and a web server are also automatically installed.

The BEX Advanced Client software is installed on all the servers from which a backup

has to be made.

The Advanced Server software is installed only on Windows 2003/2008 x64 systems that

will act as a BEX Advanced Server. This server will function as the destination server for

a BEX Advanced Recovery Open Storage backup. This system supports Zero-Impact

Backup with Data Reduction for Windows, Linux and Solaris clients, and it is the

backbone for BEX Virtualization, BEX Archive, BEX Bare Metal Recovery, BEX

Instant Availability features. On any BEX Advanced Server, Advanced Client and ESX

host, an iSCSI initiator is required for Instant Availability related Restore operations.


7


Creating Virtual Machines with BEX

The BEX virtualization feature allows a user to fully create a Virtual Machine (VM) from

a backed up physical Windows Server instance through a special type of BEX Advanced

Recovery restore job called a „virtualization job‟. This newly created VM can then

function as a replacement for a crashed physical server. For any volume backed up in a

BEX Advanced Recovery job, the initial backup is a base backup, and all subsequent

backups are incremental during which only changed blocks are transferred. A BEX

Advanced Recovery backup (base or incremental) on a BEX Advanced Server volume is

a virtual image of the entire source volume (application and OS) at a particular point in

time. That means that all recovery points in time are presented as full backups.

To exploit this feature two steps must be followed. First, execute a BEX Advanced

Recovery (Open Storage) backup of the client server node, inclusive of the BEX BMR

virtual volume. This is routine for BEX users.

Second, use the backup to create a Virtual Machine on the virtual controller by either

mapping the backed up instance (Instant Virtualization) or transferring data of the backed

up instance to the virtual controller (Full Virtualization). This is easily done through the

BEX user interface.

Full Virtualization jobs create a new Virtual Machine which contains a duplicate of the

“functional volume.” Each partition of the job‟s source instance is physically transferred

to its own disk volume on the new VM during virtualization. In other words, the full

method of virtualization creates a virtual disk with the same layout as the corresponding

disk of the backed up source machine and populates it with the backed up data.

The Instant Virtualization job maps the data stored on the Advanced Server through raw

device mapping(s) via iSCSI to the ESX host (2 disks means 2 mappings). Unlike Full

virtualization jobs, Instant Virtualization jobs do not physically transfer data to the

Virtual Machine and therefore do not require any space on the virtual controller‟s data

store. Changes made to the mapped drive do not affect the backed up data which is read-

only; these changes are stored in a temporary data space of the advanced server.


8


Leveraging a Virtual Storage Environment

Using Compellent and VMware in unison enables customers to improve utilization and

lower overall costs with flexible server connectivity, fully automated boot from SAN,

thin provisioning and cost-effective SRM implementation. Compellent Storage Center

SAN adheres to the VMware Hardware Compatibility List (HCL) to ensure

supportability.

Compellent‟s persistent hardware architecture enables the continuous integration of new

technologies and eliminates forklift upgrades. Virtualizing servers and storage into a

single pool reduces upfront purchases and on-the-fly provisioning eliminates need to

dedicate resources upfront and makes unused resources available to any application or

OS. The system makes it easy to add capacity, connectivity and bandwidth incrementally

for flexible growth.


9


Test Configuration

The test configuration (figure 3) consists of a physical BEX Advanced Server, BEX

Client and VMware ESX 3.5 server. The BEX Master Server is a VMware Virtual

Machine (VM) which is running on the physical ESX 3.5 Server (ESXi can be used). All

systems are connected through a 1GbE network. The Compellent Storage Center

functions as a backup medium and is connected through a 4Gb Fibre Channel direct

connection to the BEX Advanced Server (no FC-switch in between). Both Advanced

Server and Client are running Windows 2008 64-bit Enterprise operating system, the

Master Server Windows 2003 64-bit Standard. (For a detailed description of the hardware

see Appendix A).

The test performed was an „Instant Virtualization‟ and „Full Virtualization‟ recovery of a

BEX Advanced Recovery backup taken from the Advanced Client. We measured the

time it took to do both recovery jobs and showed the impact they have on the 1GbE

network and the CPUs on both Client and Advanced Server. Also the performance of the

disks for both scenarios was measured, and the time of the backup job, which applies for

both recovery scenarios.

Using Compellent Storage Center

In this setup we used Compellent Storage Center SAN. This SAN has some unique

features in comparison with most other enterprise storage offerings: it delivers an

industry-leading block level storage virtualization solution. Compellent allows the

combination of all disks in a single storage pool with which the user can then create thin

provisioned LUNs and present them to the servers. Another unique feature is Automated

Tiered Storage which reduces overall storage costs and improves performance by placing

blocks of data on the ideal storage tier based on actual use. Frequently accessed data

remains on faster Tier 1 storage, and if it is less used it can later on be automatically

migrated to a more economical storage, for example SATA disks (figure 1). This unique

tiered storage model and the thin provisioning capabilities can be leveraged in a Syncsort

backup architecture.

For example, after the data from a base backup has been placed on Fibre Channel disk

based storage on Tier 1 it can later on be migrated to the lower Tier 3 which is equipped

with the larger capacity and less expensive SATA II disks. In this way the total cost of

ownership (TCO) of the storage infrastructure can be significantly lowered without

performance loss as writes will always occur on Tier1 (RAID 10). Based on the historical

disk access data, blocks will then be moved up and down the different tiers automatically.


10


Supported disk devices are Fibre Channel, SAS and SATA II which can all be combined

in RAID 5 and RAID 10 LUNs. Just recently Compellent has announced support of 73

and 146GB Solid State Drives (SSDs) for the Tier 1 storage. These „drives‟ (they are not

disks) have an R/W access time of less than 1.0ms. The Compellent disk array supports

both iSCSI and Fibre Channel connectivity. In our test we will use a 1TB FC LUN, based

on RAID 10 on Tier 1 storage layer (see figure 2) which will function as a backup media

for both Instant and Full Virtualization tests. Figure 2 shows the 1TB thin provisioned

LUN in which the half of it is actually being used and the other half reserved for future

expansion.

Figure 1: Compellent tiered storage architecture

Figure 2: Thin provisioning with backup volume on Compellent


11


Test of Block Level Based Backup

Before an Instant or Full Virtualization from a server can be done the volumes on the

Client server have to be backed up by using a BEX Advanced Recovery backup job. The

first backup is the initial base backup from the disk(s) on the Advanced Client. After the

initial backup is done, all the subsequent backups are incremental where only the changed

blocks are transferred across the network. The backup process uses the NDMP-compliant

protocol to transfer block level data from the Client to the Advanced Server. In our test

we make a block level base backup from both the Boot disk „C‟ and SQLDATA disk „E‟

on the Advanced Client (figure 3). The „E‟ disk functions as storage for the data and log

files for the SQL 2008 Server. The database and tables were populated to a size of 62GB

with the help of the TPC-C‟s Benchmark Factory from Quest Software. Although the size

of the disk volume was 250GB, only 64GB (with the SQL data and log files) was filled

with real data. Only this data will really be backed up and not the complete disk. We have

monitored only the disk speed and network utilization from the backup of the E disk,

because disk C would most likely give the same results.

Figure 3: Configuration for block level backup


12


The process of backing up the „E‟ disk is as follows. First we created the 1TB backup

disk „E‟ on the Compellent disk array. After creating and starting the backup job we

monitored the performance from the disk and network on both the Advanced Server and

Client. As we can see on the Monitor Jobs tab, the backup job took only 13.13 minutes to

complete the task (data disk) and just over 15 min to complete the job (figure 4) and the

total measured throughput was almost 111 MBps (All disks). The „Windows Task

Manager‟ on the Advanced Server reflected the corresponding throughput of 118 MBps

on the local disk. The CPU was occupied 16% of the time doing the backup job (figure

5).

Looking on the Client side we saw an even a higher peak of 172 MBps on the disk and

941 Mbps network activity. The Client software consumed 1% of the CPU cycles, which

are basically the result of the Syncsort nibbler.exe job running on the Windows 2008

server; no other major tasks where running on the Client during the backup. The nibbler

job is responsible for handling the block-based data streams with the backup server

through means of the NDMP protocol. After the base block level backup procedure has

finished, the administrator defines a procedure to do incremental block level backups at

chosen regular intervals.

backup job took only 13.13 minutes to complete the task

throughput was almost 111 MBps

peak data rate of 172 MBps

941 Mbps network activity

client software consumed only 1% of the CPU cycles


13


Figure 4: Block level backup job results

Figure 5: Performance on server, shown with Windows Task Manager


14


Test of Instant Virtualization

The purpose of this test was to show how much time it takes to recover a client which

crashed due to a software or hardware failure. We assumed that the Advanced Client has

crashed and we needed to do an Instant Virtualization restore to restore the Windows

Server as quickly as possible on a different server, in this case as a VM on the ESX 3.5

server (figure 6). (An ESX 3.5i/ESXi can be used.) Instant Virtualization makes it

possible to restore the complete physical server with all the data and applications in

minutes (independent from disk/data size), instead of hours in comparison with most

other standard backup applications which exist today in the market. Instant Virtualization

is based on Syncsort‟s own Physical-To-Virtual (P2V) technology in combination with

VMware‟s virtual ESX infrastructure.

In our test the physical BEX 3.1 Advanced Client is being transferred to a VM on the

ESX 3.5 server. The migration process uses the backup from the client C: Boot disk and

E:SQLDATA disk on the Advanced Server and an iso-file on the Master Server. This file

represents a disk image of an ISO 9660 file and contains everything which normally is

put on an optical disk and can be easily mounted to the VM.

Creating the Instant Virtualization job

Before Instant Virtualization (IV) can be used, it must be activated on the Advanced

Server. After selecting the backup volume via the BEX management console, you choose

between Instant and Full Virtualization and provide the name of the VM and the size of

the memory you‟ll need (figure 7). The first thing the job does is scan the iSCSI network

for existing volumes (iSCSI-targets) through means of the iSCSI-initiator on the ESX

Server (see figure 8). Both „C‟ and „E‟ volumes are being recognized and the ESX Server

is instructed to mount both volumes (in VMware terms this is called „creating a data

store‟). In this mounting process the ESX Server acts as an iSCSI initiator and the

Advanced Server as an iSCSI target. After this has been done, a VM is created,

automatically started and loads/boots a BEX process from the iso-file located on the

Master Server. Making use of this iso-file is similar to a boot process from a CD-ROM.

During this process the device drivers are injected into the boot disk C (figure 9). The

VM is then reset and booted up with the right drivers installed. In the end the formerly

physical Client is now running as a VM on the ESX 3.5 Server. The Client is restored, up

and running, and again fully available for users (figure 10).

The whole conversion process from beginning to end took only 4.31 minutes, in which no

data was transferred between the Backup Server and the ESX 3.5 Server (figure 11). The

main purpose of doing an Instant Virtualization is to get the crashed server up and


15


running as soon as possible. Compare this with a normal restore operation with

traditional backup applications which can take hours or even days depending on the size

of the volumes to be restored. For Instant Virtualization restore size does not matter at all

as no data is transferred. However, the Instant Virtualization method is just a temporary

disaster recovery solution; it secures a quick re-continuation of your business processes

within the organization after a disaster and it enables you to go from an uncontrolled and

unplanned situation to a controlled and planned situation.

If the Advanced Server crashes, both boot disk and sqldata are not available anymore to

the VM. As of a result of that the Client crashes. To protect against this critical event

there are a few things a customer can do. First, they can make a backup of the IV based

VM client by performing a BEX Full Virtualization. This can be done when time is

available (during the weekend or in a planned maintenance window, for example).

Second, the customer can make a clone/copy the Instant Virtualization based VM to a full

VM.

Instant Virtualization is created as a quick DR solution which enables the continuation of

critical business processes in an organization within a very short time-frame (minutes). If

you have more time and want a more permanent solution, then Full Virtualization or a

conventional (P2P/V2P) BEX Bare Metal Recovery (BMR) is another option.

Figure 6: Configuration for Backup and Virtualization


16


Figure 7: Choose Full or Instant Virtualization

Figure 8: Mapping iSCSI LUNs to a Virtual Machine


17


Figure 9: Drivers injected into a Virtual Machine

Figure 10: VM is up and running


18


Figure 11: Time to complete the Instant Virtualization job


19


Test of Full Virtualization

At the moment the Client server crashes, the administrator can choose to either do a Full

Virtualization right away or do an Instant Virtualization and later a Full Virtualization or

full BMR restore of the original or other physical server. In our case we are continuing

from our last scenario: the recovered server is up and running via Instant Virtualization.

With this Instant Virtualization method all the data from the client‟s „C‟ and „E‟ disk still

remain on the Advanced Server.

Because there is only one copy of the original data on the Advanced Server it introduces

a single point of failure (spof). This means that if the Advanced Server crashes, an Instant

Virtualization restore from a crashed client is not possible anymore. Syncsort offers a

solution for this spof problem by implementing a secondary Advanced Server. BEX

Replication offers additional disk-based protection in which data is replicated to the

secondary server. The secondary server will take over in case of a crash of the primary

advanced server. We mentioned the spof situation which exists after completion of the

Instant Virtualization job. However, that‟s not the main priority in a disaster recovery

scenario. In general when we talk about spof we refer to the storage architecture where a

spof situation can be solved by, for example, implementing a synchronous or

asynchronous mirror storage solution (as offered by the Compellent Storage Center

Array).

If we want to go back to the original situation where both backed up Client disks need to

become local disks on the Client server again, we have to transfer the contents of both

volumes to the ESX 3.5 Server. Because we want to do a Full Virtualization restore based

on the latest data available, the first thing to do is to run a normal block level backup job

of our existing data which in this case is on the VM created with Instant Virtualization,

otherwise we would do a restore from the data which most likely are outdated. After

that‟s done, the Full Virtualization procedure is almost the same as the Instant

Virtualization procedure. Instead of choosing „Instant‟, the „Full‟ method is chosen from

the menu (figure 7). After running the Full Virtualization job we can see from the

message job that the whole restore procedure took just 50 minutes to complete (figure 13)

and the VM is up and running (figure 12). If we compare this with the Instant

Virtualization job, it takes ten times more time to do the job; of course the time it takes to

transfer all the data depends on the size of the volumes. After restoring the client as a full

VM the IT manager can still decide to leave the Client running on the ESX 3.5 server as

it is or rebuild a physical server and restore the data to the physical server via a Virtual-

To-Physical (V2P) transformation with BEX BMR.


20


Figure 12: VM up and running after Full Virtualization

Figure 13: Time it took to complete the Full Virtualization Job


21


Summary of Test Results

We have tested Syncsort‟s backup procedure with the Instant and Full Virtualization

method where a physical server was migrated to a VMware Virtual Machine. The main

advantage of this restore method is that a complete server can be restored in a couple of

minutes. Compare this with the traditional backup methods where a restore from a server

can take hours or even a day or more. The whole backup process, in which the physical

server is transformed to a VM, is completely transparent for the user. Compared with

traditional backups, there is no need to format the disks or install the operating system,

drivers and applications. In our tests we restored the complete crashed server, including

all the applications, in our case the SQL Server, in just one operation. The user-friendly

BEX GUI, equipped with lots of menus, makes it easy for the administrator to step

through all the backup procedures. (In contrast to the documentation which could be

improved).

Analyzing the test results from the block level backup and full and instant virtualization

backup methods we come to the following conclusions:

The block level backup performed well; speeds of more than 110MBps were seen.

Because of the low impact on the Client CPU and the online „hot‟ backup capability,

there is probably no need to take a „backup window‟ into account. This of course depends

on the number and load of other applications. The High network utilization is observed

only during the brief period that a backup is being done. The base backup only needs to

be done once-ever. Thereafter incremental backups are performed which are exceedingly

quick and have a low-impact on the system.

Restoring a Client via the Instant Virtualization method took only 4 minutes. The crashed

server was restored on a VM with a minimum of down time so users could quickly

continue with their work. The Full Virtualization method, in which the content of the

complete backup disks where transferred to the ESX Server, took a longer time, as one

would expect. But even then, within 50 minutes the complete transfer was done.

Afterwards the customer can still decide to leave the server running as a VM or migrate it

back to a physical server.

The Compellent Storage Center has an excellent GUI from which all RAID settings and

tiers can be configured. It gives excellent overviews of how the disks are being used in

the different tiers. The Thin Provisioning showed its value when doing a backup in which

only a small part of the provisioned storage capacity was used. After working extensively

with the array and performing numerous booting up procedures it never failed and/or

showed missing LUNs (which can‟t be said from other iSCSI/FC array‟s we have tested

in the past). During the block level based backup we noticed a total measured throughput

of almost 118MBps, which is a level of performance a customer can expect from an


22


enterprise type storage array. And last, the documentation is easy to read and gives a

quick overview of all the features of the Storage Center array (an example for how to

write good user readable manuals).


23


Appendix A

BEX Master

VMware ESX 3.5i VM running on 2950 Intel host

1 VMware processor

Internal RAM 1024MB

Drives:

C: 8GB “boot disk” Virtual Disk

D: 8GB “BEXdata” Virtual Disk

BEX Advanced Client

Dell 2950

2x 2.0GHz quad core Intel processor Intel Xeon

Internal RAM16GB

Fibre Channel HBA Qlogic QLE2460 FC4

Drives:

C: 2x73GB local drives in RAID1 “boot disk”,

E: SQL Compellent LUN 250GB “SQLDATA”

BEX Advanced Server

Dell 2950

2x 1.6GHz dual core Intel Xeon

Internal RAM 16GB

QLE2460 FC4

Drives:

C: 2x73GB in RAID1 “boot disk”

E: 1TB Compellent LUN “APS1”

VMware ESX 3.5i

Dell 2950

2x 1.6GHz dual core Intel Xeon

Internal RAM 16GB

QLA2360 FC2

Drives:

1TB local RAID 5

Compellent Storage Center Disk Array

11 x Fibre Channel Disk 15K 450GB (3.5-4 ms R/W access)

Total “effective” capacity 3TB

4 GB Dual Port Fibre Channel HBAs


24


Profile IT-TrendWatch IT-TrendWatch is an independent technology research and analysis firm. Our company is specialized in evaluating software and hardware products related to the distributed processing, clustering, virtualization, storage and storage-centric server market. We make use of our own test laboratory which consists of a SAN, NAS and iSCSI storage equipment. Test platforms are Windows NT, Linux and Solaris. We have a broad background of more than thirty years in the computing industry in software design, hardware engineering and technical management.

We advise companies on future IT-technology investments and bring them in contact with new storage related companies. We also do benchmark testing for new storage platforms, high performance and cluster architectures.

As a spin-off activity we write articles and books about storage technology.

We publish articles and evaluation reports for various Dutch IT-magazines and write storage handbooks and management handbooks for Windows NT systems. We are also the principal advisor for Storage Magazine in the Netherlands. On request we give seminars and presentations about new storage technology.

For More information email us at [email protected] or phone us +31 (0) 36 5328569

lab evaluation report virtualization with compellent ... · it-trendwatch evaluation report...

Documents