3rd generation SSDs arrive

July 10th, 2010

At Citrusleaf our mission is to bring down the cost of internet scale data.

If your load is both transactional, and you have analytics needs over that data, you are best suited by SSD (Solid State Device) technology.

The first generation was the Intel X25 series. The ‘M’ (Mainstream) model is still compeditive, from a price and performance view. The fact that Apple used them in laptops for years shows the solid performance and longevity. However, few data centers are willing to install consumer-grade devices. We get that.

The second generation is best captured by two products: the FusionIO PCI-E devices, and the Samsung SS805. The FusionIO devices are tuned to make Oracle and MySQL run faster without any maintance, while the Samsung drives are those sourced directly on Del’s price list for Enterprise customers. Both show high speed while being acceptable to most corprorate customers. The price of the FusionIO solution is roughly $12k for a 640G card, and the Samsung devices are about $1200 for a 100G part. In both cases the density can be troublesome, as the FusionIO requires specialized outboard cards and risers, and the most attractive high density Dell servers only allow a few direct-attached SATA drives.

Enter the third generation.

FusionIO has been promising, and has started delivering, a density double the density of the previous generation. Finally, we’ll be able to recommend 640G cards without special enclosures.

However, the density (and price) of the new OCZ SSD drives are another matter entirely. This new generation has been promised since January, but I’ve repeatedly called OCZ and been told I could buy one “soon”. Only in the last few weeks have drives become available in the US “prosumer” market (eg, newegg).

This generation promises the new “enterprise MLC” approach. OCZ is shipping a device based on the SandVine chip which uses MLC flash (ie, consumer grade) to support enterprise grade reliability. The new drives come in at 400G for a single SATA drive for $2200. Price per bit is half of the Samsung drives, and density is 4x higher.

For Citrusleaf, this means creating server configurations with greater headroom. Adding two 400G drives per server (800G per server), and 4 servers, but allowing the flexibility of adding drives to empty slots later.

We love a 2x cost per bit decrease and a 4x density increase! Got to love you, Moore.

OCZ is not a common name in today’s data center, and neither is Sand Vine. but we expect the technology from these chipsets to be picked up by a “name brand” vendor and available shortly. Or, perhaps, the OCZ drives will be rebranded. Toshiba, maybe?

We can’t recommend these drives with Citrusleaf deployments until we get one in house, but one’s on its way and we’ll put it through our test suite.

More information on the OCZ enterprise product line

Posted in big data | No Comments »

Cloud Computing Show podcast

December 29th, 2009

Citrusleaf represented for Gary Orienstien’s Cloud Computing Show podcast. We had a great discussion.

I’m not a huge podcast listener, but I thought we covered good ground about the innovations in Cloud over the last year. James Watters (now of Vmware) and Adrian Cole (JClouds) provided great insights as well.

James was particularly catty at a few points (in a good way), and Gary drove the discussion well.

In the area of cloud data storage, I think MySQL has become the de-facto standard in cloud deployments, but the static nature of MySQL is problematic.

“NoSQL” had a huge hype bubble at mid-year, and in the last month has moved to implementation. Solid products will be arriving in the next 6 months from the variety of funded projects like Riak, 10Gen, VoltDB, and from efforts like Citrusleaf.

I am continually impressed by the amount of quick traction of Amazon’s EC2 with Spot Pricing. Spot pricing is the most subversive of features, as it requires an elastic architecture that will adjust to instances being removed – thus driving architects to implement queuing services and other features. Spot Pricing will drive more truely elastic and cloud oriented architectures.

At the end of the podcast, I mention a first-teir website moving major functionality to EC2, so listen until the end!

Posted in Uncategorized | No Comments »

Cloud is about elasticity, databases must become more elastic

November 20th, 2009

Geir Magnusson’s talk at NoSQL East has stuck with me these several months.

Geir presented the need for scaling databases in the cloud effectively, and with a personal touch.

Imagine:

You build a clean architecture with an elastic application server layer, a solid load balancer in the front. You’re on a flexible infrastructure platform (aka, a cloud infrastructure provider), you’re ready for success, but you’re keeping costs down and runway long by buying servers only as needed.

You’ve pushed all the state in the system to your database, and databases are fairly efficient. An inexpensive MySQL instance can easily handle hundreds of requests a second, and you’ve only got thousands of users per day. The second that sees two users is a rare second. The lag is noticable, so you run back through your application code and make your ActiveState objects cleverer, make sure you’re only causing two or three database requests per page load.

When the load finally comes, when, in Geir’s case, the buyers at Gilt.com finally found a pair of shoes no one else had, the load starts climbing.

You don’t realize it’s happening at first. You’re in a meeting, you’re fooling with a new bit of code or reading about a new language. Someone shouts over a cubicle, or IM messages come in furious. Load’s on its way up: hold on.

Then comes the sinking feeling: you watch as pages per second plateau. An unnatural plateau, a flatline. The system’s hit a bottleneck; users must be experiencing lags and connection failures.

Scramble time. Check the load balancer metrics. Check the app servers: CPU load, swapping, context switches, connections. Check the database.

Oh, dear.

We built a scaling web service with only one database.

Most application developers, and most applications, solve load spikes with caching. Maybe they use a content manager like Akamai, maybe they use an internal cache layer like Memcache, maybe they use in-process caching inside their application. They just have to protect the database enough, not be perfect. A diligent designer will test with simulated load from unit tests, or replay log files through a load generation tool.

Caching has its limits. In a drive to make your site stickier, you try to track behavior. Find trends. Integrate with other site elements. Suggest and recommend.

Sometimes those suggestions require upgrading your database. If you’ve been through a database upgrade before, you know what it’s like.

Like most developers, you probably don’t have 6 months to wait for hardware to arrive. And write the killer slide deck to open the purse strings of the CFO. You claimed this architecture saves money, and you’re asking for a doubling of your database hardware every six months? Throwing away the old hardware? That won’t go over well.

But imagine a linear-scale database. Imagine the peace of mind when load starts climbing. Hours in advance, you can spool up an extra instance. A week in advance, you can move a spare blade into service, and ask about ordering another chassis (plan calls for linear spend on linear growth, CFO!)

Elasticity is what your company bought when you moved to the cloud, shouldn’t you demand elasticity at every layer in your architecture?

Posted in cloud | No Comments »