SSDs I 1-2-1
MK: Typically a small amount of DRAM is used by SSDs to provide a cache or buffer, in much the same way as HDDs do. To protect the data in the volatile DRAM, a battery backup or super capacitor is used to provide sufficient power to enable the data to be flushed from DRAM to NAND flash memory in the event of power loss to the SSD.
GW: All serious SSD offerings today have some kind of protection against sudden power loss. It is possible that commodity units might not but we don’t evaluate those so cannot comment. Supercaps have been shown to have serious problems at high temperatures and are being phased out by the vendors we deal with.
JC: When one uses as a small tactical component (such as a buffer), DRAM makes perfect sense. When utilized as a cache (by definition, meaning gigabyte upon gigabyte of data and not megabytes for example) it ups the percentage of data loss due to various reasons (almost everyone will have experienced the “Oh my God, the battery back-up wasn’t charged” kick-in the gut.)
Q And what are the main points to consider when deciding on in-server versus stand alone SSD solutions?
MK: When deciding on in-server SSD solutions versus standalone SSDs, the main things to consider are; a) what are the power and cooling requirements for the in-server SSDs e.g. where implementing the SSD in to an existing server, and b) is it more efficient from a cost and utilisation perspective to have a dedicated SSD solution per server, or to have the ability to share the resource across multiple servers.
GW: It’s a fundamental rule of computing that cache should always be as close to the CPU as possible, but no closer. By that I mean you should put cache inside your server if that works for your application, but this typically involves a sacrifice of RAS (reliability/availability/serviceability) and also it becomes difficult to share the cache data between servers and/or keep the cache coherent.
JC: This is an interesting fork in the road for many enterprises - the cost and inefficiences of going back to direct attached storage does not make a lot of sense. Certainly there are some individual applications or use cases where that can make sense,
but with options on the market today (such as our XLR8r) that offer 250,000 IO’s and .1 milisecond latency across a SAN-like infrastructure with all it’s inherent value for pennies per IO, it’s hard to believe that the world would go back to the way it was 15 years ago. Individual SSD drives in a server offer limited wear leveling, minimal WRITE IO optimizations and a never- ending burn-out direct-touch maintenance cycle that are equally un-appetizing.
Q Concerns over SSDs focus on performance degradation over time, the limited number of writes, and the cost. How are SSD manufacturers addressing these issues?
MK: SSD manufacturers are addressing performance degradation, write limits and cost by adding and improving firmware level functionality within the SSD controllers, such as wear levelling and over provisioning. As the manufacturing process evolves, cost will continue to be driven down.
GW: Every vendor will tell you they have magic technologies to deal with it. These boil down to wear levelling, over- provisioning, and parallelism. There are only a handful of flash chip makers, and all the SSD vendors have the same chips to choose from. There is, therefore, a limit to how good they can be but sadly no limit to how bad they can be. You need to choose a supplier that can tell the difference.
JC: WhipTail works closely with Intel (our SSD vendor of choice) to continue to maximize our software stack (RaceRunner Operating System.) Individual vendors are adding some limited wear management technology to the drives and increases in density. We value these upgrades as it validates and optimizes our software that focuses on long-term wear management and WRITE IO optimization across the drives when viewed as one large performance pool.
Q And is there a possible problem re data encryption and SSDs?
MK: There is no reason why encryption would be a problem with SSDs
GW: Maybe. The SSD vendors usually won’t provide a “black hole” policy for secure sites like the disk drive vendors will. So if the drive goes bad in these situations it would be nice if it
When deciding on in-server SSD solutions versus standalone SSDs, the main things to consider are; a) what are the power and cooling requirements for the in-server SSDs e.g. where implementing the SSD in to an existing server, and b) is it more efficient from a cost and utilisation perspective to have a dedicated SSD solution per server, or to have the ability to share the resource across multiple servers
WWW.SNSEUROPE.COM | SEPTEMBER 2011 25
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44