BigAdmin XPerts

1. I hear Sun talking about a new midrange architecture with this product...
2. What is the biggest advantage of the StorEdge 6920?
3. Will Sun be offering its new utility computing pricing on midrange storage products?
4. How does the virtualization inside the box...differ from Veritas Volume Manager?
5. How can we make a N1 Grid solution using these components? ...
6. How does the StorEdge 6920 differ from the StorEdge 6320?
7. How many logical volumes does this storage support, and when is Sun planning to incorporate iSCSI support in its storage?
8. When is Sun going to really start supporting Microsoft OS and its suite of applications in its storage software stack?
9. Recently we have acquired a SE6920...What can we hope for in terms of better performance?
10. Does DSP on SE6920 meet Sun Cluster 3.1 requirements without a host-based volume manager?

A: You are right. The StorEdge 6920 is indeed a ground breaking new storage architecture with which Sun is leading the midrange storage market. Through the last 3-4 years of talking with our customers, it has become clear that many companies now have not only large capacity requests but need a considerable amount of IO performance in order to keep up with corporate demands. Sun saw this emerging need and realized it would take a new modular networked storage architecture to get there. A cornerstone of the n-way scaling architecture is the ability to scale in not only performance and capacity but also in connectivity and data service. The Sun StorEdge 6920 is the first in a range of large capacity, high performance n-way scalable midrange systems that have been architected to provide capacities and performance that - until now - was only available in high-end monolithic architectures.

But back to your application: Oracle typically is configured for an IO size of 8K. Most OLTP applications are heavily random in nature. The effect on a storage system is that the architecture must be able to accommodate IO workloads that rely on fast disks access. This poses a problem for traditional dual RAID controllers. As you mentioned, your data base is moderate in size - 4 TB - which can be achieved using a standard dual RAID controller implementation using circa 112 36GB drives. The problem is not the capacity but the extra latency that is introduced with that many drives sharing a single pair of back-end FC-AL loops. As a rule of thumb, the loop sharing will negatively affect the performance of each drive by roughly minus 50% for a large loop. The Sun StorEdge 6920 overcomes this problem by spreading the disks across up to 16 backend loops and thereby not encountering a performance penalty. If we still assume 112 drives to reach the desired capacity, the StorEdge 6320 will only have 112/16 = 7 drives per backend loop thereby eliminating the large loop performance penalty. So, by moving your database to the Sun StorEdge 6920, you can see vastly improved performance over a traditional dual controller system. An additional benefit of the system is that you also get 16 GBytes of cache which further helps with performance. All this while keeping storage cost at a nice comfortable midrange level.

You will love it :-) . Happy computing.

Back to top

A: Yes, the StorEdge 6920 is a brand-new way of creating large, high performance storage capacities in a midrange storage system. Sun responded to an emerging storage need by combining intelligent networking technology with modular storage arrays and thereby creating a new category of midrange storage systems with unprecedented performance and capacity. Before Sun's StorEdge 6920 the way to deploy high capacity and performance in one system was to purchase costly high-end monolithic storage systems.

High-end monolithic systems have typically been the only viable platforms for large scale storage consolidation. Until now. The Sun StorEdge 6920 scales to 448 drives and 65 TBytes of capacity which makes it well suited to serve many concurrent applications. Its powerful N1 enabled DSP architecture also ensures ample performance for multiple concurrent applications. The StorEdge virtually eliminates the need for multiple discrete storage arrays for multiple applications. One system - all your applications.

Finally the system also comes with 14 pre-defined 'Storage Profiles' each of which is tailored and optimized for individual applications such as Oracle OLTP, Decision Support, e-mail and many more. These profiles makes it a snap to deploy the system, dial in the correct configuration and ensures predictable application performance every time. Both the architecture and the Storage Profiles make the StorEdge 6920 an ideal choice for cost effective storage consolidation.

Back to top

A: Yes. While we have not yet announced the program, Sun is committed to roll out more and more utility computing pricing for various products. Both the StorEdge 9900 and the StorEdge 6920 storage systems offer very large scalability and performance budget and are therefore good candidates to be deployed as a 'storage utility'. So stay tuned for an announcement from Sun in the near future.

Back to top

A: Veritas volume manager is host based. I.e. the mapping of multiple physical volumes to a concatenated /striped virtual volume is executed at the host level. Sun SE 6920 performs similar volume management at the system level, thereby freeing up the host from performing extra volume management. This especially benefits storage consolidation deployments where multiple hosts share a single SE 6920. Consolidated volume management is better for storage provisioning and capacity management.

Back to top

A: Yes, a high performance Grid is indeed best deployed on a SAN. Which means FibreChannel. You do have different options however. In case you want to use the StorEdge 3310, you need to deploy a NFS based Grid. Both SAN and an NFS based Grid use the same concept of central storage fanned out to the Grid server via a network.

Grid NFS style:
Here you would take advantage of one U high servers or Blades which comes with GigE on-board (free). Then connect the Grid nodes to a central GigE switch which in turn is connected to a larger NFS server. The NFS server has to be beefy enough to handle the cumulative load of the Grid nodes and should have a large amount of cache in it. The reason for the cache is that the StorEdge 3310 may not have enough spindles to perform all the IO in a timely fashion. Remember that one drive can only handle circa 300 512byte IOPS - and if the IO is bigger, then the IO number per drive falls. If the StorEdge 3310 has 12 drives and that you stripe across all of these, then the number for storage is 300 x 12 = 3600 IOPS. This might be enough - it all depends on your Grid application.

Grid SAN style:
A SAN is a little more costly for Grids but is also high performance. First, each Grid node needs an HBA. If you do not need true redundancy (and most Grids do not) then you can either go with a single ported HBA or a dual ported HBA - but not two single ported HBAs. This helps on cost. Then connect all the HBAs to a switch (Sun has a great 64-port cost-effective modular switch for Grids). Again you may not need redundancy - so one switch might do the trick. In the SAN Grid there is no NFS server so the switch is connected directly to storage. Here you should look at StorEdge 3510 or StorEdge 6120/6320. If you need to share information in your Grid at the SCSI level, you also need a SAN based file system like Sun QFS.

A final word on performance: Remember that many Grid applications (including a N1 grid) is dominated by random I/O. This means that cache on server/controllers only helps a little (because it is impossible to guess correctly as to what data is needed next and pre-fetch it). The result is that the performance of your RAID sets are setting the tone for total Grid performance. So use as many drives as possible in your RAID stripe.

Back to top

A: The StorEdge 6920 uses Sun StorEdge Data Services for N1 Software to create a unified storage pool of a large number of controllers and disks in one system. The N1 Data Services Platform runs a storage pool based volume manager so that storage can be 'carved out' from the pool and a LUN assigned to a host needing storage capacity.

In the StorEdge 6320, the aggregation of multiple controllers and subsequent LUN provisioning had to take place via the host based volume manager, since the 6320 uses regular SAN switches to tie multiple arrays into one system.

Back to top

A: The StorEdge 6920 systems supports 1024 LUNs. Sun sees iSCSI (Internet SCSI) as being a great way to facilitate native SCSI block replication. The StorEdge 6920 is scheduled to incorporate iSCSI for IP-based replication in the near future. We further continue to watch the market for iSCSI in target mode for all our storage offerings.

Back to top

A: Thanks for the question. We do indeed support the Windows OS on the StorEdge 6920. Both Windows NT/2K and Advanced Server 2003. You are right in thinking that the StorEdge 6920 is a great choice for SMB storage consolidation for mixed host environments -- and Windows servers and applications are certainly part of that mix. We therefore naturally support Windows server attachment to the system. It is important to remember that once a StorEdge 6920 LUN is associated with a given server, whether running Windows, Linux, or the Solaris OS, the application running on the OS really does not know that it is running on a Fibre Channel-based system. As is the case with any storage system running SCSI over FC, the OS, file system, and application above really only speak SCSI -- the FC transport is transparent. So any application running on a Windows server automatically is supported by StorEdge 6920. Including Microsoft Exchange. The StorEdge 6920 system simply does not care what the application is -- it is merely serving SCSI read and write requests.

The StorEdge 6920 is precisely designed to act as a consolidated 'storage utility' providing storage capacities, performance levels, and data services to a range of application servers at the same time. You can run Microsoft Exchange and Oracle on this system -- concurrently! Throw some Linux file servers in the mix while you are at it... The days where Sun only supported Solaris hosts on our storage systems are long gone. Today we support Windows, Linux (Red Hat and SUSE), Solaris, IBM-AIX, Irix, HP-UX, and even Novell NetWare. So have at it: mix it up! 8-) StorEdge is perfect for consolidating storage in mixed server environments. Happy computing.

Back to top

A: Thank you for purchasing the Sun StorEdge 6920 system. You are now ready to kick your database performance up several notches. But it all depends on two things: the nature of your workload and how many drives and controllers you are striping across.

The nature of the drives used also matters. The Sun StorEdge A5200 Array, as you know, was a JBOD implementation and used older drives rotating at 10,000 RPM. The performance of the older drives was circa 180 IOPS per drive. The StorEdge 6920 uses modern 15,000 RPM fibre channel drives that can perform around 250 IOPS per drive. So simply by using faster rotating drives you get better performance with the 6920. But there is more: The 6920 is a full RAID multi-controller implementation. Each controller pair in the 6920 is performance balanced with the number of drives it controls. The system then aggregates the performance of all the controllers into one large storage pool from which you provision your database server's LUNs.

To get optimal performance from your 6920, start by formatting all the disks and creating a storage pool striped across all the drives and controllers. Then provision 2 TB or so from the storage pool. This allows you to take advantage of all the drives in the system for maximum performance aggregation. Drives are inherently slow devices compared to your database server and its CPU(s), so ganging a lot of them together in one pool is a great way to increase system performance.

Without knowing the exact composition of your workload and the configuration of your 6920, it is a little tough to tell you exactly how much your performance will improve, but let me give you a quick idea of the general concepts involved in estimating the performance.

Given:

Workload is RANDOM database IO, and we will assume 20% cache hits when running on a cache-enabled system -- like the 6920. Cache in the A5200 is not available beyond the limited cache of the drives. We also will only look at read performance to compare the two systems. The number of drives in the 5200 was -- let's say -- 22 and your database was striped across all 22 (again, this is an assumption). The number of drives in your 6920 is 56 controlled by four controllers (another big assumption on my behalf -- generally more drives and more controllers are better for performance, but here I am assuming a smaller 6920). Because we have four 6920 controllers in this example, we have a total cache pool of 4 Gbyte.

Read estimates:

StorEdge 5200: 22 drives of 180 IOPS each => 22 * 180 = 3,960 IOPS. And since we have no controller cache in the system, this number is the final estimate for aggregated JBOD performance.

StorEdge 6920: 56 drives of 250 IOPS each => 56 * 250 = 14,000 raw disk performance. Four controllers of 25,000 cached IOPS => 4 * 25,000 = 100,000 IOPS. Combined system performance with 20% cache hit and 80% cache miss is: .2 * 100,000 + .8 * 14,000 = 31,200 IOPS.

As you can see, the 6920 system performance benefits from more and newer drives as well as system cache compared to an older JBOD. The performance in this simple sizing example is almost eight times faster for the 6920 (!!!).

Your performance experience will likely vary from this simple example. But you can clearly see how the name of the performance game is 'aggregation' and how the StorEdge 6920's industry-leading architecture can take performance to a whole new level. So again: stripe across as many controllers and drives as possible and you may enjoy database performance that you have only dreamed of until now. Happy computing.

Back to top

A: The Sun StorEdge 6920 system fully supports Sun Cluster 3.1 software. You do not need a host-based volume manager since the DSP serves up a single LUN. Oracle and SE6920 is a great combo, due to the performance aggregation of the SE6920's multiple controller architecture. Just remember to configure the SE6920 for as many controllers as your budget can accommodate. More controllers = better database performance.

As your question alludes to, the StorEdge 6920 is also a great platform for storage consolidation. Not only can you create different storage domains -- each with its own performance characteristics -- the SE 6920 also supports 256 host connections via SAN switches. Remember however, that you should consider connecting your hosts via dual paths for higher storage availability. And when doing so, each server will take up two host connections. So the SE6920 supports 256 dual-pathed hosts.

Your last question as to when to use StorEdge 6320 and StorEdge 6920 depends on your usage model. The SE6320 is an aggregated system where each controller pair is exposed directly to the hosts via dual FC switches. Such an architecture requires the host(s) to do performance striping across several controllers. This architecture is therefore best for HPTC and streaming applications. The StorEdge 6920 does not rely on host-based LUN striping. The SE6920 performs all the volume management via the N1 Data Platform. Creating a single large storage pool of up to 448 drives across 16 back-end loops and 16 controllers makes the SE6920 well suited for high-performance database work as well as storage consolidation.

Back to top