The IBM FlashSystem 900 is the perfect solution for a wide variety of use cases and business needs. The FlashSystem 900 can address I/O issues of applications that require high performance and low latency in relation to storage access.

Knowing how to apply the advantages that this latest technology can offer to IT market scenarios and solutions is important.

This chapter gives an overview of how to take advantage of the benefits of the IBM MicroLatency, macro efficiency, enterprise reliability, and extreme performance. This chapter explains where and how to use the FlashSystem as part of your business solution.

The use cases provide examples of real-world implementations, design solutions, and scenarios. The use cases highlight the benefits that each scenario can offer to clients.

The basics of three solution scenarios are described:

This chapter covers the following topics:

Certain applications have a natural affinity with the FlashSystem 900. These include applications that have a low tolerance to latency, are I/O per second (IOPS) intense, and need to scale in size and performance. These types of applications are key candidates for the FlashSystem because of their sometimes unique requirements for storage needs.

A set of applications exists that especially benefit from the FlashSystem solutions. The following applications are ideal candidates for the FlashSystem storage:

An entire book might be written about each one of these applications. The objective of this chapter is to briefly describe how the IBM FlashSystem 900 can provide value for the special challenges of these applications.

OLTP applications usually rely on a database that needs to be able to serve the application as fast as possible. In OTLP, parallelism allows the application to run as many transactions as possible at the same time. From a storage perspective, too many parallel I/O requests can be challenging because the parallelism limitation of traditional storage directly related to its number of disks.

Because the FlashSystem 900 is not limited by mechanical disk, there is no longer a limitation to allow the application to reach a new level of parallelism, and to be able to run up to 10x or 20x more transactions in up to one-third of the time, on average.

The FlashSystem 900 allows databases to run more operations, on average up to more than 10x because of the extreme performance. More transactions can occur in less time because of the MicroLatency benefits.

Data can be collected and analyzed to see the FlashSystem benefits. For DB2, performance can be measured by extracting a DB2 MONREPORT. Or, in an Oracle database, you can use an Automatic Workload Repository (AWR) report.

For more information about how to benefit from an IBM FlashSystem in a specific OLTP environment, contact your IBM representative. For more details about running the IBM FlashSystem in OLTP environments, see the IBM Redbooks Solution Guide, IBM FlashSystem in OLTP Database Environments, TIPS0973.

OLAP applications are important for the business environment because OLAP is a key player in a wide range of business intelligence (BI) tools. In many industries, OLAP is increasingly taking a more important role.

Because the business environment is more complex, decisions increasingly rely on results from BI tools. BI provides the decision maker the opportunity to have a broader vision of the market. Response time makes a big difference. In OLAP, it is even more evident. A decision made faster can help position you better in the market, but a delayed response might cause a significant negative impact to your business.

OLAP applications use a mathematics model to predict and to calculate behavior, but for that, accessing a large amount of data (big data) is necessary; this is where FlashSystem is a “game changer” for organizations. The FlashSystem allows clients to run their analyses and predictions at a new level of speed, helping companies to go to the market faster. It is not only a powerful processor, but the speed of access to big data plays a significant role in OLAP applications.

The FlashSystem 900 with its MicroLatency and extreme performance provides a new competitive advantage to clients.

For more details about running the IBM FlashSystem in OLAP environments, see the IBM Redbooks Solution Guide, IBM FlashSystem in OLAP Database Environments, TIPS0974.

A tiering approach, as used in IBM Easy Tier, is a solution that combines functionalities that can add value to other storage, in combination with the highly advanced key points that the FlashSystem 900 can offer, such as MicroLatency and maximum performance.

The great advantage of the tiering approach is the capability to automatically move the most frequently accessed data to the highest performing storage system. In this case, the FlashSystem 900 is the highest performing storage, and the less frequently accessed data can be moved to slower performing storage, which can be solid-state drive (SSD) based storage or disk-based storage. The next topic discusses the data movement that can be done at block level or at file level.

Easy Tier is the IBM implementation of block tiering. Other vendors have other names for the block movement between different tiers of storage. This topic does not discuss the details of how tiering works. The main objective is to explain how to take the advantage of this implementation by using the FlashSystem 900 and to describe which use case best fits this solution.

Some tiering solutions do not offer the possibility of external tiering. No external tiering means that the block movement can be done only inside the storage device. Because this is a limited approach and it does not work with the FlashSystem 900, only external tiering is discussed.

The IBM solution for external tier, known as IBM Easy Tier, is in IBM SAN Volume Controller and the IBM Storwize V7000 (V7000). SAN Volume Controller offers excellent synergy with the FlashSystem 900.

SAN Volume Controller and the FlashSystem address the combination of the lowest latency with the highest functionality. The V7000 and the FlashSystem address the best cost-benefit solution. Both provide the lowest latency for clients that use traditional disk array storage and need to increase the performance of their critical applications.

Use of the IBM Easy Tier solution is indicated when a need exists to accelerate general workloads. SAN Volume Controller will have a map of the hot data (more frequently accessed) and the cold data (less frequently accessed), and it will move the hot data to the FlashSystem and the cold data to the conventional storage. When data that was previously hot becomes cold, it moves from the FlashSystem to other storage. The inverse process occurs when cold data becomes hot (or more frequently accessed) and will be moved from a traditional storage to the FlashSystem (Figure 9-1).

This solution will focus on accelerating and consolidating the storage infrastructure. It might not reach the same lowest latency that a flash-only solution offers, but it can be used to improve the overall performance of the infrastructure, avoiding the acquisition of SSDs. The main requirement in this solution is to add more performance to an application or to multiple applications, especially existing applications whose performance is costly to improve by application tuning. The overall latency that SAN Volume Controller adds to the data path does not compromise the expected latency.

SAN Volume Controller adds other important features to the solution, such as replication at the storage layer, snapshots, and Real-time Compression.

Figure 9-1 illustrates how Easy Tier works with the FlashSystem 900. The more frequently accessed hot data is moved to the FlashSystem 900 and the less frequently accessed cold data is moved back to the slower disk array storage.

Easy Tier with the FlashSystem 900 offers the following benefits to the applications:

Another tiering approach treats the information at the file level. This type is referred to as Information Life Management (ILM). When using the FlashSystem 900 in an environment where the file is the crucial part of the solution, a preferred practice is to keep the most frequently accessed data in the FlashSystem storage. For more details about ILM, see the ILM fact sheet:

Some file systems can move the files between storage pools that contain different kinds of storage, for example, an SSD storage pool and a hard disk drive (HDD) storage pool. In IBM Spectrum Scale (formerly IBM General Parallel File System (GPFS)), you can create policies and move the files between the pools according to a designed policy. Ideally, keep the core files on a faster disk solution, such as the FlashSystem, which provides a significant performance improvement for the application. Also, file systems typically use the concept of metadata, which is where the file’s descriptive information is located. Considering that the most accessed information in a file system is the metadata, keeping the metadata in a FlashSystem 900 storage pool can significantly improve the overall performance of a file system. IBM Spectrum Scale (formerly GPFS) is considered highly advantageous for the FlashSystem because it can operate in a parallel fashion. For more information, see the IBM Spectrum Scale web page:

A well-known concept among data administrators is that most applications have an I/O profile that has more read events than write events. Traditionally, the majority of databases have an I/O profile of 70/30, which means that the database spends 70% of the time reading and only 30% of the time writing.

This section describes how a combination of the FlashSystem and another disk storage can add redundancy and allow the usage of software functionalities in other storage to provide outstanding performance for the applications with standard I/O behavior.

The following examples illustrate the possible combinations in a preferred read implementation and also can be expanded to other applications.

The preferred read solution approach allows the application to use the lowest latency for reads, or read at the speed of the FlashSystem, because the main goal of this solution is to send all read requests to the FlashSystem 900.

Preferred read presumes a write mirroring relationship, where the I/O is written to one or more types of storage, and all the read I/O requests are served from the FlashSystem 900.

Figure 9-2 gives a high-level example of how preferred read works.

The preferred read solution adds another level of protection, as Figure 9-3 shows. In a disaster situation, for example, if a power failure occurs on the FlashSystem 900 and it becomes unavailable, the application continues to access the data without interruption and without data loss because, in preferred read, all the data will be mirrored (in both storage products).

There is no mirroring between the FlashSystem and other storage. The writes are mirrored, or split, which means that every write request goes to both storage systems (the FlashSystem 900 and other storage) that are part of a preferred read relationship. The latency for write requests is always at the latency of the slower storage. You might think that this solution can seriously compromise the overall performance, but it is important to remember that, typically, in a traditional storage system, the writes are done in cache memory. So, the majority of the time, write latency is in microseconds because the cache memory has a low response time.

Therefore, the reads performed at the FlashSystem 900 speed (average 70% of the time) and the writes performed with little latency make this solution a good combination of performance and flexibility.

Preferred read can often be implemented on live systems easily and transparently and with no downtime. For more information about how to configure preferred read, see
5.5, “FlashSystem 900 preferred read and configuration examples” on page 140.

The preferred read solution allows the use of features of other storage systems. For example, if a mirroring relationship exists, such as Metro Mirror or Global Mirror, the preferred read does not affect this functionality because the replication will continue sending the write request to the secondary site. This scenario now has three copies of the data: one in the FlashSystem and two copies in the other storage systems.

Figure 9-4 shows how replication can work in a preferred read relationship.

Figure 9-5 shows a solution of using Logical Volume Manager (LVM) on site A in a preferred read design. A Metro Mirror relationship exists between the two other disk storage systems, going from site A to site B.

Further examples of preferred read implementation in some of the more frequently used scenarios are described in this section.

The three ways to implement a preferred read are as follows:

For more information about LVM, see 5.5, “FlashSystem 900 preferred read and configuration examples” on page 140.

IBM SAN Volume Controller and the IBM Storwize V7000 in combination with the FlashSystem 900 add functionality to the solution that is not included with only the FlashSystem 900.

SAN Volume Controller and the IBM Storwize V7000 can be used to implement a preferred read solution with the FlashSystem 900. Preferred read is implemented in SAN Volume Controller by using Volume Mirroring or virtual disk (VDisk) mirroring.

Figure 9-6 shows this scenario. For more information about implementing this feature, see IBM SAN Volume Controller and IBM FlashSystem 820: Best Practices and Performance Capabilities, REDP-5027.

For more information, see the following areas of this book:

A wide range of applications can implement mirroring of write I/Os and use a preferred read design to read at the FlashSystem speed. Because the applications can be designed and implemented according to the application developer, see the documentation for your application and search by preferred read implementation, split I/O, or I/O mirroring.

For instructions about how to implement Automatic Storage Management (ASM) preferred read on Oracle environments, see 5.5, “FlashSystem 900 preferred read and configuration examples” on page 140.

Many operating systems, such as Linux, IBM AIX, and Microsoft Windows, have built-in capability to split the I/O between more than one volume by performing a volume mirror at the operating system (OS) level. This kind of functionality usually allows the administrator to decide where the OS will read the data. Other operating systems perform the decision based on the speed of the volumes, using the faster path to storage, in this case, the FlashSystem.

Figure 9-7 shows LVM from AIX controlling the disk and performing a volume mirror at the OS level.

Linux LVM can also be used in this relationship. In the Solaris OS, Solaris Volume Manager (SVM) can be used. In Windows environments, you must use Veritas File System to handle the mirroring of the I/O.

This solution design is also known as manual placement. Work with the FlashSystem as a dedicated approach. Either place the entire application or the most important part of the application inside the FlashSystem 900. This way, the applications benefit the most from the extreme performance and MicroLatency.

Certain databases have components that when the speed of components increases, they accelerate the application without needing to accelerate the data.

Because the FlashSystem 900 has the potential to be configured with up to 48 TB (RAID 0) of capacity, usually a more efficient way is to place the entire application in the FlashSystem 900 and let the application accelerate at the maximum possible speed.

Figure 9-8 is an example of where the entire database is placed inside the FlashSystem 900.

Various solution scenarios were described. The advantages of each were highlighted to help you decide on the best solution approach to your specific application and business environment.

All applications have unique functionality, which you must consider when you design a solution to use the FlashSystem 900. When you compare solutions, consider these items:

The IBM FlashSystem 900 adds the following benefits to the solution:

In some situations, flexibility might be a priority over latency. In other situations, many IOPS and latency are critical and there is less need for flexibility.

Table 9-1 compares the benefits of each type of solution.

Figure 9-9 shows the advantages of each solution described in Table 9-1.

When performance is important, but you need flexibility, use an IBM Easy Tier solution, because all of SAN Volume Controller features can be used and the administrator does not need to worry about controlling which data is hot.

When every microsecond is important, a flash only solution is the best approach. Systems that need all the capacity of the extreme performance and the MicroLatency typically handles the application flexibility on another level, not on the storage level.

When a balance between the maximum possible performance and some level of flexibility is required, a preferred read solution is the best option. It helps you preserve your investment and offers good flexibility.

To further help you understand the suggestions and options when you are designing a solution, you can also engage the IBM client representative to help you to find the best solution for your application.