Originally posted by: TonyPearson

Continuing my week in Chicago, for the IBM Storage Symposium 2008, I attended two presentations on XIV.

XIV Storage - Best Practices

Izhar Sharon, IBM Technical Sales Specialist for XIV, presented best practices using XIV in various environments.He started out explaining the innovative XIV architecture: a SATA-based disk system from IBM can outperform FC-based disk systems from other vendors using massive parallelism. He used a sports analogy:

"The men's world record for running 800 meters was set in 1997 by Wilson Kipketer of Denmark in a time of 1:41.11.

However, if you have eight men running, 100 meters each, they will all cross the finish line in about 10 seconds."

Since XIV is already self-tuning, what kind of best practices are left to present? Izhar presented best practices for software, hosts, switches and storage virtualization products that attach to the XIV. Here's some quick points:

Use as many paths as possible.

IBM does not require you to purchase and install multipathing software as other competitors might. Instead, the XIV relies on multipathing capabilities inherent to each operating system.For multipathing preference, choose Round-Robin, which is now available on AIX and VMware vSphere 4.0, for example. Otherwise, fixed-path is preferred over most-recently-used (MRU).

Encourage parallel I/O requests.

XIV architecture does not subscribe to the outdated notion of a "global cache". Instead, the cache is distributed across the modules, to reduce performance bottlenecks. Each HBA on the XIV can handle about 1400requests. If you have fewer than 1400 hosts attached to the XIV, you can further increase parallel I/O requests by specifying a large queue depth in the host bus adapter (HBA).An HBA queue depth of 64 is a good start. Additional settings might be required in the operating system or application for multiple threads and processes.

If you have long-running batch jobs, consider breaking them up into smaller steps and run in parallel.

Define fewer, larger LUNs

Generally, you no longer need to define many small LUNs, a practice that was often required on traditional disk systems. This means that you can now define just 1 or 2 LUNs per application, and greatly simplify management. If your application must have multiple LUNs in order to do multiple threads or concurrent I/O requests, then, by all means, define multiple LUNs.

Modern Data Base Management Systems (DBMS) like DB2 and Oracle already parallelize their I/O requests, so there is no need for host-based striping across many logical volumes. XIV already stripes the data for you.If you use Oracle Automated Storage Management (ASM), use 8MB to 16MB extent sizes for optimal performance.

For those virtualizing XIV with SAN Volume Controller (SVC), define manage disks as 1632GB LUNs, in multiple of six LUNs per managed disk group (MDG), to balance across the six interface modules. Define SVC extent size to 1GB.

XIV is ideal for VMware. Create big LUNs for your VMFS that you can access via FCP or iSCSI.

Organize data to simplify Snapshots.

You no longer need to separate logs from databases for performance reasons. However, for some backup products like IBM Tivoli Storage Manager (TSM) for Advanced Copy Services (ACS), you might want to keep them separate for snapshot reasons. Generally, putting all data for an application on one big LUN greatly simplifies administration and snapshot processing, without losing performance.If you define multiple LUNs for an application, simply put them into the same "consistency group" so that they are all snapshot together.

OS boot image disks can be snapshot before applying any patches, updates or application software, so that if there are any problems, you can reboot to the previous image.

Employ sizing tools to plan for capacity and performance.

The SAP Quicksizer tool can be used for new SAP deployments, employing either the user-based or throughput-based sizing model approach. The result is in mythical unit called "SAPS", which represents0.4 IOPS for ERP/OLTP workloads, and 0.6 IOPS for BI/BW and OLAP workloads.

If you already have SAP or other applications running, use actual I/O measurements. IBM Business Partners and field technical sales specialists have an updated version of Disk Magic that can help size XIV configurations fromPERFMON and iostat figures.

XIV Performance

Lee La Frese, IBM STSM for Enteprise Storage Performance Engineering, presented internal lab test results for the XIV under various workloads, based on the latest hardware/software levels [announced two weeks ago]. Three workloadswere tested:

• Web 2.0 (80/20/40) - 80 percent READ, 20 percent WRITE, 40 percent cache hits for READ.YouTube, FlickR, and the growing list at [GoWeb20] are applications with heavy read activity, but because of[long-tail effects], may not be as cache friendly.

• Social Networking (50/50/50) - 50 percent READ, 50 percent WRITE, 50 percent cache hits for READ.Lotus Connections, Microsoft Sharepoint, and many other [social networking] usage are more write intensive.

• Database (70/30/50) - 70 percent READ, 30 percent WRITE, 50 percent cache hits for READ.The traditional workload characteristics for most business applications, especially databases like DB2 and Oracle on Linux, UNIX and Windows servers.

The results were quite impressive. There was more than enough performance for tier 2 application workloads,and most tier 1 applications. The performance was nearly linear from the smallest 6-module to the largest 15-module configuration. Some key points:

• A full 15-module XIV overwhelms a single SVC 8F4 node-pair. For a full XIV, consider 4 to 8 nodes 8F4 models, or 2 to 4 nodes of an 8G4. For read-intensive cache-friendly workloads, an SVC in front of XIV was able to deliver over 300,000 IOPS.

• A single node TS7650G ProtecTIER can handle 6 to 9 XIV modules. Two nodes of TS7650G were needed to drive a full 15-module XIV. A single node TS7650 in front of XIV was able to ingest 680 MB/sec on the seventh day with17 percent per-day change rate test workload using 64 virtual drives. Reading the data back got over 950 MB/sec.

• For SAP environments where response time 20-30 msec are acceptable, the 15-module XIV delivered over 60,000 IOPS. Reducing this down to 25,000-30,000 cut the msec response time to a faster 10-15 msec.

These were all done as internal lab tests. Your mileage may vary.

Not surprisingly, XIV was quite the popular topic here this week at the Storage Symposium. There were many more sessions, but these were the only two that I attended.

technorati tags: IBM, XIV, SATA, best practices, performance, Wilson Kipketer, massive parallelism, HBA, DBMS, Oracle, ASM, DB2, SVC, VMware, VMFS, TSM, Tivoli, SAP, Quicksizer, SAPS, PERFMON, iostat, Disk+Magic, TS7650G, ProtecTIER