LAB EVALUATION REPORT Virtualization with Compellent ... · IT-TrendWatch Evaluation Report...
Transcript of 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
IT-TrendWatch Evaluation Report
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).
IT-TrendWatch Evaluation Report
6
Copyright © 2009, IT-TrendWatch, All Rights Reserved
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.
IT-TrendWatch Evaluation Report
7
Copyright © 2009, IT-TrendWatch, All Rights Reserved
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.
IT-TrendWatch Evaluation Report
8
Copyright © 2009, IT-TrendWatch, All Rights Reserved
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.
IT-TrendWatch Evaluation Report
9
Copyright © 2009, IT-TrendWatch, All Rights Reserved
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.
IT-TrendWatch Evaluation Report
10
Copyright © 2009, IT-TrendWatch, All Rights Reserved
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
IT-TrendWatch Evaluation Report
11
Copyright © 2009, IT-TrendWatch, All Rights Reserved
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
IT-TrendWatch Evaluation Report
12
Copyright © 2009, IT-TrendWatch, All Rights Reserved
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
IT-TrendWatch Evaluation Report
13
Copyright © 2009, IT-TrendWatch, All Rights Reserved
Figure 4: Block level backup job results
Figure 5: Performance on server, shown with Windows Task Manager
IT-TrendWatch Evaluation Report
14
Copyright © 2009, IT-TrendWatch, All Rights Reserved
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
IT-TrendWatch Evaluation Report
15
Copyright © 2009, IT-TrendWatch, All Rights Reserved
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
IT-TrendWatch Evaluation Report
16
Copyright © 2009, IT-TrendWatch, All Rights Reserved
Figure 7: Choose Full or Instant Virtualization
Figure 8: Mapping iSCSI LUNs to a Virtual Machine
IT-TrendWatch Evaluation Report
17
Copyright © 2009, IT-TrendWatch, All Rights Reserved
Figure 9: Drivers injected into a Virtual Machine
Figure 10: VM is up and running
IT-TrendWatch Evaluation Report
18
Copyright © 2009, IT-TrendWatch, All Rights Reserved
Figure 11: Time to complete the Instant Virtualization job
IT-TrendWatch Evaluation Report
19
Copyright © 2009, IT-TrendWatch, All Rights Reserved
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.
IT-TrendWatch Evaluation Report
20
Copyright © 2009, IT-TrendWatch, All Rights Reserved
Figure 12: VM up and running after Full Virtualization
Figure 13: Time it took to complete the Full Virtualization Job
IT-TrendWatch Evaluation Report
21
Copyright © 2009, IT-TrendWatch, All Rights Reserved
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
IT-TrendWatch Evaluation Report
22
Copyright © 2009, IT-TrendWatch, All Rights Reserved
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).
IT-TrendWatch Evaluation Report
23
Copyright © 2009, IT-TrendWatch, All Rights Reserved
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
IT-TrendWatch Evaluation Report
24
Copyright © 2009, IT-TrendWatch, All Rights Reserved
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