0% found this document useful (0 votes)
1 views

V Switch With Ms SQL App 007 02

This application note provides guidance for IT professionals on using SANRAD V-Switch with Microsoft SQL 2000, focusing on centralized database storage solutions. It outlines four recommended storage designs based on varying levels of performance, availability, and cost, along with a performance study comparing SANRAD V-Switch to FC-SAN. The results indicate that SANRAD V-Switch offers a cost-effective alternative for IO resource-intensive applications like Microsoft SQL.

Uploaded by

ccs.itsystems
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
1 views

V Switch With Ms SQL App 007 02

This application note provides guidance for IT professionals on using SANRAD V-Switch with Microsoft SQL 2000, focusing on centralized database storage solutions. It outlines four recommended storage designs based on varying levels of performance, availability, and cost, along with a performance study comparing SANRAD V-Switch to FC-SAN. The results indicate that SANRAD V-Switch offers a cost-effective alternative for IO resource-intensive applications like Microsoft SQL.

Uploaded by

ccs.itsystems
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

SANRAD Application Note:

Using SANRAD V-Switch with Microsoft SQL 2000


APP-007-02

SANRAD Copyright SANRAD 2004


US Tel: 866-301-8155 All rights reserved. The copyright and all intellectual property rights
International Tel: 972-3-767-4800 in this application note belong to SANRAD. It is strictly forbidden to
copy, duplicate or otherwise use this application note or any part
[email protected] thereof in any way shape or form without the prior written consent
of SANRAD.
Table of Contents
SANRAD SQL Storage System Solutions 3
General Recommendations:................................................................ 3
Design Options 4
MS SQL Storage Design 1 .................................................................. 5
MS SQL Storage Design 2 .................................................................. 6
MS SQL Storage Design 3 .................................................................. 7
MS SQL Storage Design 4 .................................................................. 8
Summary of Storage Designs.............................................................. 9
MS SQL and SANRAD V-Switch Performance Study 9
Test Method:........................................................................................ 9
Test Environment: ............................................................................. 10
Test Results: 11
Summary 13

Important Notice
The configurations described or tested in this application note are not the only available solution. The
application note is not intended nor may it be construed as an endorsement of any product(s) tested.
This application note provides not warranty of any kind. SANRAD limited warranties for SANRAD
products are stated in separate documentation accompanying each product. No damages or remedy
of any kind shall be recoverable by any party for any claim or loss in any way arising or alleged to
arise from or as a result of this application note, whether considered alone or in addition to any other
claim.

APP-007-02Copyright SANRAD 2005 2


SANRAD SQL Storage System Solutions
This application note is intended for IT professionals who are considering iSCSI and
SANRAD V-Switch as a means for centralizing database storage for one to many MS
SQL database servers. There are several benefits to moving to a shared storage
model, but with these benefits there are questions about what type of solution best
fits the needs of the organization. Performance, guaranteed data availability and
future scalability costs are concerns that need to be addressed when placing MS SQL
Database on a centralized network storage solution. This application note presents
recommendations to designing an MS SQL storage system using SANRAD V-Switch
and a performance study based on the one of the proposed design.
This application note assumes knowledge and experience with MS SQL
administration. It is also recommended to familiarize yourself with V-Switch basic
configuration and operation.
When planning the storage strategy for MS SQL, companies should design the MS
SQL storage based on a combination of capacity, availability, RAID performance and
cost to best suite their needs and budget. In this note we present four recommended
MS SQL storage configurations, each one with a different emphasis on capacity,
availability, performance and cost.

General Recommendations:
In an iSCSI environment each component can contribute to improved capacity,
availability and performance.

T H E S T O R A G E S I D E (D I S K A R R A Y ):

The user should consider:


• Type of disk array: SCSI controller or FC controller as well as if disk
array will have one controller or two. FC perform better than SCSI.
• Type of disks: SCSI or SATA, SCSI perform better but cost more, one
SATA disk can go up to 400 GB with 7200 RPM at the same price of one
SCSI disk with 120 GB and 15000 RPM
• Number of spindles: The number of disks in a LUN. The more the better
for performance even more important then the disk size.
• Disk array cache size: 256 MB, 512 MB or 1024 MB. We recommend at
least 512 MB
For example, an FC disk array with SATA disks and at least 512 MB cache controller
is a good combination of performance and cost for up to 500 users.

APP-007-02Copyright SANRAD 2005 3


THE SERVER(S) SIDE:

The user needs to decide between an iSCSI Microsoft software initiator and iSCSI
HBA hardware. The advantage of the iSCSI HBA is the TCP/IP offload engine within
the HBA for TCP checksum calculations takes the load off the server CPU. If CPU
utilization is above 40% without the use of iSCSI, it is recommended to use an HBA
to avoid server CPU saturation when iSCSI is used. However, the Microsoft initiator
is a free download whereas an iSCSI HBA is hardware that must be purchased.
It is highly recommended to configure one volume for the database file and a
separate volume for the transaction log. In some cases it is also recommended to put
the tempdb on its own volume. For more details please consult the MS SQL
administration guide available online.
Note: While the IO subsystems will impact the MS SQL performance it is equally
important to emphasize the important of an efficient and well design database which
can improve MS SQL performance dramatically.

THE NETWORK SIDE:

It is highly recommended to use a Gigabit network and, if possible, dedicated


Ethernet subnet.

T H E V-S W I T C H S I D E :
For better performance it is recommended to dedicate port ETH2 or ETH3 (V-Switch
3000 only) on the V-Switch for the database and transaction log volumes. Refer to
the V-Switch User Manual for more details.

Design Options
SANRAD MS SQL solution allows for flexibility with the MS SQL system design. The
designs depend on many factors but the most influential are capacity, availability,
RAID performance and cost. This paper focuses on four design options:
• Design 1 – Better RAID performance, medium availability, less capacity
and low to medium costs
• Design 2 – Medium RAID performance, medium availability, more
capacity and low costs
• Design 3 – Better RAID performance, high availability, more capacity
and medium costs
• Design 4 – medium RAID performance, very high availability, a less
capacity and medium to high costs

APP-007-02Copyright SANRAD 2005 4


MS SQL Storage Design 1
By using RAID 0+1 on the disk array, this design ensures a combination of high
performance (striping) with availability (mirroring) on the disk array at the expense of
lower data capacity as a result of the combination of the mirroring and striping. Using
only one controller and one disk array keeps the initial cost down but using RAID 0+1
raises the cost per MB data. Further, using only one controller is a risk for availability.
It is recommended to add another controller on the disk array for redundancy.

MS SQL Server

2 Simple Volumes: V-Switch 3000


1 for database &
1 for log

RAID 0+1
3U

Disk Array with


RAID
Capabilities
Figure 1. MS SQL Storage Design 1

Storage components and configuration:


• 1 Disk array with one controller and all disks configured as one disk
array group with RAID 0+1
• 1 V-Switch with volumes configured as simple volumes, a volume for the
log and a volume for the database

APP-007-02Copyright SANRAD 2005 5


MS SQL Storage Design 2
By using RAID 5 on the disk array this design ensures availability on the disk array
with more data capacity however at the expense of medium performance (due to the
RAID 5 parity). Using only one controller, one disk array and RAID 5 keeps the cost
down and the costs per MB data down but using only one controller is a risk for
availability. It is recommended to add another controller on the disk array for
redundancy.

MS SQL Server

2 Simple volumes: V-Switch 3000


1 for database &
1 for log

RAID 5
3U

Disk Array with


RAID
Capabilities
Figure 2. MS SQL Storage Design 2

Storage components and configuration:


• 1 Disk array with one controller and all disks configured as one disk
array group with RAID 5
• 1 V-Switch with volumes configured as simple volumes, a volume for the
log and a volume for the database

APP-007-02Copyright SANRAD 2005 6


MS SQL Storage Design 3
By using the combination of two disks arrays that are mirrored on the V-Switch level,
this design ensures high availability with more data capacity and better performance
due to the striping on the disk array level. However having two disk arrays raises the
initial costs.

MS SQL Server

2 Mirrored volumes:
1 for database & V-Switch 3000
1 for log

RAID 0
3U

Disk Arrays with


RAID
Capabilities
Figure 3. MS SQL Storage Design 3

Storage components and configuration:


• 2 Disk arrays with one controller each, all disks configured into four disk
array groups with RAID 0 each disk array group.
• 1 V-Switch with volumes configured as mirror volumes (one volume=2
disks arrays groups, one from each disk array), a volume for the log and
a volume for the database

APP-007-02Copyright SANRAD 2005 7


MS SQL Storage Design 4
By using the combination of two disks arrays that are mirrored on the V-Switch level
and RAID 5 on the disk arrays this design ensures very high (double) availability with
a bit less data capacity and medium performance due to the RAID 5 parity on the disk
array level. However having two disks arrays raises the initial costs as well as the
costs per MB data

MS SQL Server

2 Mirrored volumes:
1 for database &
V-Switch 3000
1 for log

RAID 5
3U

Disk Arrays with


RAID
Capabilities
Figure 4. MS SQL Storage Design 4

Storage components and configuration:


• 2 Disk arrays with one controller each, all disks configured into four disk
array groups with RAID 5 each disk array group.
• 1 V-Switch with volumes configured as mirror volumes (one volume=2
disks arrays groups, one from each disk array ), a volume for the log and
a volume for the database

APP-007-02Copyright SANRAD 2005 8


Summary of Storage Designs
The following table summarizes the characteristics of each MS SQL storage design
recommendation:

Table 1: Summary of Designs


Design Availability Performance Cost Capacity
MS SQL Medium High Low to Medium Low
Design 1
MS SQL Medium Medium Low Medium
Design 2

MS SQL Medium High Medium High


Design 3

MS SQL High Medium High Medium to High


Design 4

MS SQL and SANRAD V-Switch Performance


Study
Test Method:
To test the performance of MS SQL using SANRAD V-Switch 3000, we created a test
environment that included a Windows 2003 server running SQL 2000 with a SANRAD
V-Switch 3000 connected to a Raidsys (Infotrend) FC disk array. The disk array was
configured with two LUNs, each configured with RAID 0+1. On the V-Switch we
configured two volumes from the LUN’s: one for the database and one for the
transaction log. We also created a small FC-SAN environment by connecting the
server using FC HBAs directly to the disk array so we could compare the
performance between the SANRAD iSCSI V-Switch and FC-SAN. Performance was
tested using the Microsoft utility Database Hammer from the SQL 2000 resource kit.
This utility created a database with 10 million rows and simulated SQL 2000 activities
with different numbers of connections.

APP-007-02Copyright SANRAD 2005 9


Test Environment:
SQL 2000 Server -

Table 2:
Model IBM eServer X225
Processor 2 X 2.8 GHz Intel Pentium 4
Memory 2.5 GB
Network Card Broadcom NetXtreme Gigabit Ethernet
FC HBA Qlogic 2200
Internal SCSI Controller LSI Logic Ultra 320
Operation System Windows 2003 Enterprise + hotfixes (up to 1/10/04)
Microsoft Initiator V1.06
iSCSI Initiator
Application Microsoft SQL 2000 with SP 3a

V-Switch Setup –

Table 3:
Model V-Switch 3000
Firmware Version 2.2.7
StoragePro Version 2.2.7
Storage Connection Type Fiber Channel (FC)

Storage Subsystem Setup –

Table 4:
Make RaidSys (Infotrend)
Model 9300 A16F (FC)
Controller Cache Memory 1 GB
Disks 250 GB SATA
Raid Capability 0, 0+1, 1, 5, 50, JBOD
Firmware 3.41B.02

APP-007-02Copyright SANRAD 2005 10


Test Results
The following table and graph describe the performance test results of the two
environments.

Table 1: Test Results

IOPs Average Disk Latency SQL Server Avg Latch


(Database Volume) (ms) (ms)

Number of FC-SAN SANRAD FC-SAN Sanrad FC-SAN SANRAD


Connections
V-Switch V-Switch V-Switch

100 934 879 21 27 47 51

200 1009 976 29 35 51 55

300 1134 1118 39 43 62 69

400 1401 1355 48 55 78 81

500 1603 1546 59 66 96 103

2400

1600
IO Per Sec

IOPs FC-SAN

IOPs Sanrad V-
800 Switch

0
100 200 300 400 500
Number of connections

Figure 5. IO Per Sec

APP-007-02Copyright SANRAD 2005 11


70

Average Disk Latency(ms)


60

50 Average Disk Latency


(Database volume) in
40 ms FC-SAN
30 Average Disk Latency
(Database volume) in
20 ms Sanrad V-Switch
10

0
100 200 300 400 500
Number of connections

Figure 6. Average Disk Latency (ms) for the database volume

Disk latency close to 100 ms indicates an IO bottleneck.

120
SQL Server Avg Latch (ms)

100
SQL Server Avg Latch
80 in ms FC-SAN

60
SQL Server Avg Latch
40 in ms Sanrad V-
Switch
20

0
100 200 300 400 500
Number of connections

Figure 7. SQL Server Avg Latch (ms)

A very high average latch may indicate an IO bottleneck.

APP-007-02Copyright SANRAD 2005 12


Summary
The test results show that SANRAD V-Switch iSCSI solution offers a cost-effective
alternative to FC-SAN. The difference in the numbers between the iSCSI solution and
the FC solution is negligible. Therefore, the SANRAD V-Switch can be used for IO
resource intensive applications like Microsoft SQL as well as others such as
Exchange.

APP-007-02Copyright SANRAD 2005 13

You might also like