By Greg Schulz, Server and StorageIO @storageio
Part 1 of this series laid out the basics of nand flash Solid State Devices (SSD) with part II discussing endurance and performance. Part III looked at SSD options for virtual servers, VDI or virtual desktop as well as storage for physical server environments, usage and configuration criteria. Let us build off those and continue to look at what SSD to use for different environments.
For write, endurance today that means single level cell (SLC) combined with a robust flash translation layer (FTL) implementation combing software firmware and hardware for write intensive scenarios requiring a long duty cycle. Granted SLC is more expense per GByte and that multilevel cell (MLC) provides more capacity in a given density, look at the total value. For example, if SLC has a higher price per GB and your requirement is to use that technology for as long as possible, you will get more program/erase (P/E) cycles with SLC than with MLC. That means then if endurance is a priority, compare on a cost per P/E basis. That is what is the cost of P/Es, which might mean using an SLC device longer, or, using a lower cost MLC and then plan on replacing it sooner. However as noted in previous posts, look beyond the chips or MLC and SLC dies also considering how they are combined with FTL, software and firmware as part of a solution.
In the future, if not already today there are robust MLC based solutions in or entering the market that have improved FTLs, hardware, software and firmware to improve on P/E wear and tear on the media improving endurance and overall reliability. Some solutions will also be, or are already being labeled eMLC or Enterprise MLC as a hybrid approach. IMHO, these are similar to the role of enterprise high capacity SATA not to be confused with eSATA (external SATA) and desktop SATA HDDs. Both enterprise and desktop SATA HDDs have high capacity, however their duty cycles and characteristics differ as do cost.
While the focus on media has been mainly around nand flash for SSD, let us not forget the role of DDR DRAM. DRAM can be found on PCIe flash SSD cards as a read/write buffer or cache to help with wear leveling and other management tasks. DRAM is used in physical servers and controllers for device drivers and their buffers or data structures. DRAM is also found in SSD appliances used for software, buffers, data structures and other tasks, as is also the case in storage systems. Even in the Hybrid Hard Disk Drives (HHDD) like the Seagate Momentus XTs, which I have in my laptops and some servers that include SLC flash SSD, there is also DRAM working in a compliment manner.
Moving on from the mediums, what type of SSD to use when and where will vary on several factors however, they can be simplified down to the following:
- Are you looking for an extension of physical server DRAM?
- Are you looking for a cache (read or read/write) to compliment or enhance underlying internal dedicated, or external shared storage?
- Are you looking for a dedicated internal storage and IO medium to replace HDDs?
- What IO, performance, storage, server, application, database or other problem are you looking to address?
- Do you need high availability with ability to failover or move VMs from one PM to another?
- How large is the data footprint of the application that needs more performance?
- What are your growth plans or requirements?
- Do you need to support more IOPs and transactions, or more bandwidth throughput?
- What is the size of the IO or transactions being performed for comparison purposes?
- What are the read/write characteristics of your applications?
- How many PMs or physical servers need to get some benefit from having SSD?
- How will you move data or applications around to derive benefit of the SSD?
The above are just a few questions that should drive the conversation of what type of SSD solution you need for a given scenario.
In some cases, it will be a PCIe card with SLC flash configured as a read or read/write cache to complement and enhance your underlying iSCSI, SAS, FC or FCoE shared block storage such an EMC VFCache or those from LSI and Mircon among others.
In other cases it will be a PCIe card configured as a internal dedicated flash SSD target in a server using application or server based replication to another server equipped with SSD card for HA (for example FusionIO, LSI, Micron, TMS and others).
Other scenarios will involve PCIe cards, like those among others mentioned above, installed in ether a traditional Cisco, Dell, HP, IBM, SuperMicro or Oracle server configured as an appliance for hosting VMs or other applications, or simply deployed as a traditional physical machine. Besides using PCIe cards, those same servers or appliances can also be configured with SAS or SATA 2.5” or 3.5” SSDs installed into drive slots as individual drives using software based RAID, or attached to a PCIe RAID card.
Yet another option is to place SAS and SATA 2.5” or 3.5” SSDs (MLC or SLC) into the drive slots of storage systems and enclosures for use as a target, or as EMC has done, as an optional cache on the CLARiiON and VNX product lines. Some storage systems and appliances combine different SSD technologies including a mix of drive form factor SSD as targets managed with tiering tools and software along with PCIe cache cards or special form factor SSD DIMMs. For example, Oracle uses various SSD packing approaches in their 7000 series, as do others including NetApp. NetApp as an example supports a PCIe flash card as a performance accelerator module (PAM) along with drive form factor SSDs. The above and those solutions from other storage systems and appliance vendors can also be complimented by host or server side caching.
Which type of approach, what specific product will come down to the problem being solved or opportunity being presented, preference to packaging approaches or vendors, physical server PCIe expansion slot space, budget and comfort level among other factors.
If you are not sure which SSD approach, packaging, or product is best for your environment, drop a note or comment here and will provide perspective and suggestions in addition to those I am guessing vendors and vars will offer.
Here are some related SSD links to learn more in addition to the previous posts in this series.