Blogs

   
Michael Petrov
Co-Founder, CEO
9/23/2011
Enterprise Storage Selection Methodology

IT space is always overcrowded by all types of vendors. When a company has a need to purchase a new gadget, there will be hundreds of vendors around IT groups preaching products calling the shamelessly not less as the BEST on the market. No matter what they sell. It is hard for CIOs/CTOs/IT directors to make a conquest choice as we all know that vendor offers are sliced differently and you always compare apples to oranges.

                    The biggest goal of IT groups is to figure out how to compare offerings on a flat place, how to make them equal – make them all apples or oranges.

This is how we did it selecting a SAN solution for an entry-level enterprise implementation.

1.      Narrowing the selection

It is hard to come up with an algorithm of how you would narrow the vendor selection. We can easily contact 20 vendors but it would be too much to compare. As an initial selection, we decided to review 3PAR, EMC, NetApp and Compellent. We, as a service provider, didn’t even go into this selection as it was no difference for us if the client will want to review NEC, HP or many other manufacturers. At this point we just got a list from the client who said they want to compare those guys…

After communication between our client and the vendors, the client narrowed the selection between EMC and Compellent. This is where our work as trusted consultants started.

 

2.      Creating a “flat place”

Here is what, in our opinion, counts when you select storage: capacity, power, features.

Capacity:

Capacity analysis should be broken down by:

Raw offered capacity

Raw capacity is easy to calculate number of disks and their sizes. Naturally, it has to be broken down by the class of disks as faster storage costs more and has smaller sizes. IT should never get tricked by marketing talking points like: “our storage software logic makes it so fast that you don’t need many fast disks”. Do they think we are stupid?

Derived usage capacity

In the past it was very easy to calculate usable capacity. Today storage vendors offer different types of RAIDs, pool algorithms and configurations that have certain limitations. Those limitations create lower physical disk utilization, require more hardware and sometimes result in usable space loss or underutilization. Down the road you may easily hit a wall where the array would not allow you to use RAID 5 with 3 disks and would force you to use only RAID 6 with a predefined number of disks. So we would strongly recommend creating a disk usage map, RAID groups and pools at the time of storage selection.

Maximum capacity

Maximum capacity is the number of disks that offered controller configuration can spin before controllers have to be upgraded. 

 

 

Power:

It is very hard to analyze power. There are many different methodologies to do that. What makes it difficult is that the same application can work differently on different setups. For example, there could be a big debate on what is going to be better to throw? 10 SSD disks in a disk pool or use them as a fast cache. Maybe it is better to use 5 SSDs as a fast cache and 5 SSDs to add to the disk pool? And if you do that, maybe it will be impossible to use 5 SSD disks in the mix with SAS and SATA disks in the disk pool and we need 6 of them.

Here are the parameters that we wanted to use in order to analyze raw power of the storage:

Total Controller RAM

How much RAM controllers have. (ßI’m not sure what he means here.) SAN controllers are computers. Some of them run chopped off a version of Linux, some of them run proprietary OS but they all use RAM. The more RAM controllers have, the faster they work. There is one huge subject – OS version. If SAN OS is 32 bit – the RAM limitation would always be 4G. 64 bit SAN OS would not have this limitation.

Fast Cache

Fast cache plays a role of shocks absorbing I/O spikes and we feel it is a very important part of a SAN implementation. Some vendors don’t have fast cache at all claiming that the algorithm is optimal as it is. So if you select a car, would you get absolutely the same engine without TURBO or with it if the price is the same? The same goes for fast cache. The more of the fast cache is proposed, the faster the system can be.

Total Ports and their aggregate speed

For sure port availability should match. If one SAN offers FC and iSCSI and another one only one of the options, you would probably select the storage that offers both types of ports.

iSCSI could have 2 speeds: 1Gbps and 10Gbps

Fiber could have 4Gbps and 8Gbps.

In a lot of cases you would hear that if you have a high performance application you should go with Fiber. You would ask if you have 1OGbps iSCSI, isn’t it “faster” than fiber? Not necessarily. The problem is in the frame size and the way data is encapsulated. The detailed analysis of the iSCSI vs FC is outside of the scope of this document and should be performed using application specific data. However, the cumulative speed of all ports could give you a good idea about the power of the system.

Maximum throughput on the front end

Technically it is the total port aggregate speed. So if the array has 4x1Gbps of iSCSI ports and 2x4Gbps of FC, the total would be 12Gbps. No matter what you do, you cannot pull more out of the array without changing or expending the controller.

Maximum throughput on the back end

This is the throughput from controllers to the disk enclosures and disks themselves. The speed depends on the architecture of the array and cannot be easily expended.

Number of IOPS (Input output operation)

It is a very important parameter. This is how many input output operations the array can perform in a second. In contrast with throughput, the IOP can be very short but there might be a lot of them. In a lot of cases OLTP database would be an example of when the throughput is not so important but number of IOPS is something that would affect the performance of the system. Number of IOPS depends on number of physical disks (“spindles”) in array (certainly SSDs are not spindles but have their own number of IOPS characteristics).

As an example – 4x600GBx1500RPM SAS disks would give 1.2T of storage. At the same time 8x300GBx1500RPM SAS disks would be the same size BUT WOULD PRODUCE TWICE MORE IOPS. So database systems would perform better on the second configuration.

 

 

Important features

All SAN arrays offer different features and comprising is out of the scope of this document. We wanted to point out features that can affect total cost of ownership.

 

Power consumption:

As power is expensive today, total power consumption is a very critical parameter. It is linearly dependent on the number of physical disks in the array as one single disk can pull up to 0.5Amp power consumption. So overall it is better to have fewer disks which contradict with the IOPS recommendations.

 

Maximum number of disks

Some SAN vendors would say that they can spin unlimited amount of disks. There is no theoretical limit; however, there are  CPU/memory resources needed to control/spin disks. When the number of disks is going up the controllers will slow down. So it is very important to know when there will be a need for an upgrade.

 

 

 

This table shows the comprising of 2 different SAN arrays based on our methodology.

 

 

Compellent

EMC

SSD 100G

0

10

SSD Storage

0

1T

SAS – 15K RPM 600G

 

41

SAS – 15K RPM 450G

48

 

SAS – 15K RPM 300G

 

 

SAS – 10K RPM 300G

 

 

SAS Storage

21.6T on 48 spindles

24.6T on 41 spindles

SATA – 7.2K RPM 2T

12

7

SATA Storage

24T on 12 spindles

14T on 7 spindles

 

 

 

Fast Cache

8G

200G

Max Fast Cache

64G

1T

 

 

 

Disk trays

4

4

 

 

 

Ports FC

8

8

Ports iSCSI

4

4

 

 

 

Max Throughput on front end

64Gbps in FC + 4Gbps on iSCSI

64Gbps in FC + 4Gbps on iSCSI

Max Throughput to back end

96Gpbs

92Gbps

IOPS Based on Drives in array

Could not get

38,640.00

 

 

 

Max number of disks

150 (estimated)

250 (limited)

 

 

 

Power consumption

2.8KW

1.47KW

 

 

 

OS

32-bit

64-bit

 

 

 

 

 

3.      Comparing technical details

Based on the comprising table we can see that:

EMC provided better disk configuration.

The max throughput is the same from both vendors.

IOPS could not be obtained from Compellent

EMC provided Fast Cache while Compellent claimed that the algorithm of the software would compensate.

EMC is natively 64 bit. Compellent was offered in 32 bit configuration with an ability to upgrade to 64 bit in a few months when it will become available.

 

4.      Cost

 

At first, Compellent offered a price close to EMC but was around 3% more expensive. When Dell found out that EMC is winning the deal, at the last moment dropped prices almost 100K down. Our client felt it was not ethical for Dell to do that and still wanted to go with EMC, however showed the prices to EMC for comments. EMC provided additional discount but could not come close to the lowballed price of Dell. The client still selected EMC as they felt that Dell may try to recover the loss of revenue through further charges.

   

Replies

Leave a reply

Name (required)
Email (will not be published) (required)

Number from the image above
  
Latest blog posts
VNX Versions
11/10/2014
Subscribe to the blog by e-mail

Sign up to receive
Digital Edge blog by e-mail


Subscribe    Unsubscribe