ApplyIT

FAST VP Customer Example

Customers prefer to spend as little as they need to on infrastructure. One of the tricks is to understand what you really need and where you may be able to cut. With the price of disk capacity dropping each year, customers would love to buy the largest/cheapest drives that they can to support their workload. This results in near-term savings when the gear is purchased, and longer term savings from reduced power, cooling, and maintenance bills. But how large can the drives be before they cannot sustain the business workload?

The Problem

Storage tiering is not a new idea. Back in 2003, EMC started a big campaign to help customers save money by tiering their data. It was called ILM - Information Lifecycle Management. The idea was to help customers put the right data on the right storage at the right time, saving them money. There were only two problems: the tiering placements were manual (like this process example), and to place it correctly you needed to understand what the profile for the data was currently and what it would be in the future.

Many customers decided that the manpower was more expensive than just buying additional hardware 'to be safe.' Sure, you could buy a mix of drive types, but buying all the same drives and spreading the workload across all of them is much easier to plan for. And if you did it right, the workload would push the drives hard (to about 70% busy) about the same time you 'ran out' of space (at 75-90% full). Of course, if the workload turns out to have much different needs, you either waste space (the drives get too busy) or waste money (you bought more performance than you need).

Simplified Storage Expansion

Many customers thinking of a new storage array focus on the work required to set up a new server with storage. This is an important item to research.  And some storage vendors can make it a bit simpler than others to connect the host HBA WWNs to the capacity in the array. However, I submit that that there is a much more common storage management challenge, and one that can be made a lot simpler.

The Problem

Customers are constantly adding more capacity to their systems. Application retain more data. New applications are added to servers. Upgrades need more space. It seems that every few months each server is getting some additional storage capacity. So how hard should it be? After all, the servers and storage are already connected.

So let's make this a little more complicated. Many customers are now rolling out VMware ESX clusters of 8 or more servers. Some of these servers have more than 2 HBA ports. So when adding a device to the cluster, there may be 30 or more HBAs that all need to get their access updated.

What did I just buy?

When a company looks to build a major new IT system, they have a set of business goals in mind.  Mapping those goals to specific pieces of technology to acquire is not always the easiest thing to do.  This is a discussion of how EMC worked with one customer to take some of the questions out of what they were getting and increase the customer confidence in the final solution at the same time.

The Problem

This customer deals with continuous data feeds, both coming in and going out.  They need to have the data integrated into their overall information framework within very specific time windows.  They know how much data they need to be able to move - after all, they are in the information business.  But how does that translate into a storage solution?

They mapped their performance needs to a set of hardware requirements.  They took these requirements to multiple vendors, and they got very different solutions from each.  They have enough relationship with their vendors to know that all of the solutions would eventually meet the need.  However, it was possible that some were not going to support the full (planned) production workload with only the gear being proposed.  Price was the major factor in the purchase decision between workable solutions, and the vendors were well aware of this.  Might some be planning to fix things later with upgrades, or hoping that the planned workload would never appear?  (Customers have to consider this possibility, even if only causes them to do enough checking to 'trust but verify' - thus the pictured fake news clipping)

Sharing Information

I am a geek.  As such, I have a tendency to over-engineer solutions, especially when it comes to solving personal challenges.  And while I may be able to make my ‘solutions’ work, my family sometimes finds them difficult/frustrating/impossible to live with.  This is the story of how I made data sharing work in my home.

The Problem

I have a corporate laptop.  I also have a home desktop system.  I need to be able to easily move files between them – mostly personal documents and media.  Some of the files are rather large.  Thumb drives are inconvenient.  And since I have a home network, using anything other than the network to move these files just feels wrong.

I also need to share things with my family.  My wife has a home desktop system and a laptop as well.  The kids each have a desktop system (hand-me-downs).  And when someone creates a document they want the others to have access to, we need a way to do it easily.

Then there are the friends and family that come by.  Many use the WiFi network.  Then we want to share pictures (without cutting them down to nibs or posting them to a public area like Facebook).  And again, we want it to be easy.

Of course, I also have tax records and other documents that, while I would like to store them centrally for easy access, I have a real need to secure.  Sorry, I don’t trust the WiFi security for much.

Better Oracle Performance in a Flash

Enterprise Flash Drives (EFDs) have made a big splash in the storage world over the past 2 years.  Many customers are interested in how they might apply this new technology to speed up applications.  And given a cost of roughly 20 times that of the same size 15K Fibre Channel (FC) drive, they want to be sure they can get a good return on their investment.  Finding the right targets to make that happen can be fairly simple.

The Problem

A retail customer purchased a set of 8 EFDs with a new array.  They had a few systems that were critical to their overall operations that they were hoping to improve.  The business would get the most value from an improvement in the PeopleSoft HR batch runs, ensuring that payroll computations were completed on time.  They had upgraded to new HP-UX servers, and found that they were now usually waiting for disk I/O.

The systems had been running on a CLARiiON CX3 array with dedicated groups of 15K FC drives.  They were to be moved to a new Symmetrix DMX-4 which had the EFDs.  The natural discussion was what data to place on this valuable EFD space.

Big Warehouse, Small Backup

This customer has a data warehouse that drives internal research and is sold to external customers.  The data needs to be accurate and available at all times.  Their goal was a new storage architecture to maximize availability and data protection while optimizing operational complexity and cost.  We were able to help them meet those goals.

The Problem

The starting size of the data warehouse was 25 TB, which would increase by about 10% per year.  This was for 2 years of retained data.  Some data was available to load throughout the day, while other sources would provide bulk feeds during the night.  With 2 years of retention, the change rate for the database was under 2% per week.  In general, backups every few days were OK, since there was a separate record of all data imported into the system and the ‘current’ image could be recreated from even a few day old copy within a matter of hours.

The business required that the data be available, and that backups be able to restore the system to a point in time up to 1 year old (there had been times of some small feeds of errant data that were corrected weeks later, so prudence dictated that extended recovery be possible).  Given the value of the operational system, there needed to be space to perform a full restore while continuing production operations.  This would also provide for space to conduct quarterly testing of the restore processes.

Given the value of the data, the business was interested in the option of having two full images of the data.  This would allow for quick resumption of production operations should there be an environmental or other event at the primary location.  This was, however, a desire with limited funding, and would only be included if it could be accomplished without greatly increasing the cost of the solution.

Looking to the future, there would be business value in being able to extend the data retention period from 2 years to 5 or even 7 years.  The more the solution is able to scale at reasonable cost and without driving up complexity, the sooner it would be cost effective to keep the data active in the warehouse for a longer period of time.

Enterprise Business Restart

Recovering a single system after a disaster can be difficult.  Recovering hundreds is a mess.  Recovering them in a consistent fashion, so that their data dependencies are all correct, is a huge task.  And what if they run different operating systems?  There is an effective answer.

The Problem

This customer has over 1,000 separate systems that are critical to ongoing operations and are located in a core data center.  The systems are a combination of Mainframe, UNIX variations (AIX, HP-UX, LINUX, etc.), and Windows.  They use SAN and NAS storage (the Mainframe CKD over FICON I include in the SAN), with over half a Petabyte of unique data and various additional copies.  They have SAP and other systems that have data flowing between different them, often with different operating systems, with no easy way to perform data isolation (picture an interaction of web services, shipping, billing, and warehouse data and you get the general idea).  The customer wanted to implement business restart, with clear business requirements.

Recovery Point Objective (RPO)

There is value in having the data during any site recovery be as current as possible.  These are not public finance systems, so the value of a minute of data was not measured in millions of dollars, but it has real corporate value.  The goal was set to lose less than 5 minutes of data.

The Fastest I/O

The fastest I/O is the one you never do. By applying optimization, customers can dramatically cut the number of disk I/Os needed to run a database query. This is the story of one customer’s results from a 4-day EMC Oracle Assessment, and how they were able to avoid over 1 billion I/Os per day on a single database.

The Problem

The customer is a transportation company. They perform large nightly database updates. These updates have critical timelines for completion, so that the results are ready for use when other processes kick off in the morning. The updated data relates directly to the profitability of ongoing operations. 

The application had been running OK, though it used a lot of hardware (Sun E10K servers and a pair of DMX-4 arrays, duplicated for DR and linked with SRDF). Since the application was purchased from an outside vendor, the tuning options were limited. The customer had worked with the vendor on several occasions to optimize the nightly batch processing. Benchmarks were conducted. Extensive examination was done of the data model. It appeared that the database and application were about as tuned as they could be, and more hardware was going to be the only path to keep up with growth.