Archive

Posts Tagged ‘Flash’

How to Save Money by Buying Dumber Flash

October 19, 2016 Leave a comment

Quick and simple new way to look at storage. Stop buying flash arrays that offer a bunch of bells and whistles. Two main reasons, 1. It increases your $/TB and 2. It locks you into their platform. Lets dive deeper.

1. If you go out and buy an All Flash Array (AFA) from one of the 50 vendors selling them today you will likely see there is a wide spectrum not just from the media (eMLC, MLC, cMLC) but also in the features and functionality. These vendors are all scrambling to put in as many features as possible in order to reach a broader customer base. That said, you the customer will be looking to see which AFA has this or is missing that and it can become an Excel Pivot Table from hell to manage. The vendor will start raising the price per TB on those solutions because now you can have more features to do things therefore you now have more storage available or data protection is better. But the reality is you are paying the bills for those developers who are coding the new shiny feature in some basement. That added cost is passed down to the customer and does increase your purchase price.

2. The more features you use on a particular AFA, the harder it is to move to another platform if you want a different system. This is what we call ‘stickiness’. Vendors want you to use their features more and more so that when they raise prices or want you to upgrade it is harder for you to look elsewhere. If you have an outage or something happens where your boss comes in and say “I want these <insert vendor name> out of here”, are you going to say well the whole company runs on that and its going to take about 12-18 months to do that?

I bet your thinking well I need those functions because I have to protect my data or i get more storage out of them because I use this function, but what you can do is take those functions away from the media and bring it up into a layer above them in a virtual storage layer. This way you can move dumb storage hardware in and out as needed and more based on price and performance than feature and functionality. By moving the higher functionality into the virtual layer the AFA can be swapped out easily and allow you to always look at the lowest price system based solely on performance.

Now your thinking about the cost of licenses for this function and that feature in the virtualization layer and how that is just moving the numbers around right? wrong! For IBM Spectrum Virtualize you buy a license for so many TBs and that license is perpetual. You can move storage in and out of the virtualization layer and you do not have to increase the amount of licenses. For example. You purchase 100TB of licenses and your virtualize a 75TB Pure system. You boss comes in and says, I need another 15TB for this new project that is coming online next week. You can go out to your vendors and choose a dumb storage AFA array and insert it into the virtual storage layer and you still get all of the features and functions you had before. Then a few years go by and you want to replace the Pure system with a nice IBM flash system. No problem, with ZERO downtime you can insert the Flash 900 under the virtual layer, migrate the data to the new flash and the hosts do not have to be touched.

The cool thing that I see with this kind of virtualization layer is the simplicity of not having to know how to program APIs, or have a bunch of consultants come in for some long drawn out study and then tell you to go to ‘cloud’. In one way this technology is creating a private cloud of storage for your data center. But the point here is by not having to buy licenses for features every time you buy a box allows you to lower that $/TB and it gives you the true freedom to shop the vendors.

Advertisements

IBM Storage Announcement Summary – April 16, 2013

April 18, 2013 Leave a comment

As usual, IBM has pushed out a bunch of things all at once. Other than the FlashSystem, the DCS 3700 has the T10 Protection Information (PI), and the DS series got some new disks.  For more information on T10 go to one of my favorite blogs “Storage CH Blog”

Content of this summary is subject to change after the date of publication
 

Announcements by Letter Number

113-046 New IBM FlashSystem portfolio of high-performance flash storage systems

113-047 New IBM FlashSystem portfolio of high-performance flash storage systems

113-056 Enhancements to IBM DCS3700 systems include new hard disk drive features and host connection capabilities

113-057 IBM System Storage DS5000 hard drive refreshes

113-058 IBM System Storage hard drive refresh for DS3500 and DS3950 systems

113-059 New hard drive refreshes for DS5020 Systems

213-105 New VMware vCenter Operations Management Suite editions and VMware vSphere with Operations Management offerings improve virtual and cloud environment administration

213-146 IBM AIX adds support for new IBM Power Systems hardware

213-152 IBM System Networking Switch Center v7.1

213-153 IBM System Networking Switch Center v7.1

613-002 IBM SmartCloud Unified Communications Dedicated

913-060 Hardware withdrawal: Select IBM System Storage DCS3700, DS5000, and DS5020 features – Some replacements available

913-061 Hardware withdrawal: Select IBM System Storage DS3950 and DS3500 features – Replacements available

913-094 Software withdrawal: IBM System Networking Element Manager v6.1

DRAM vs Flash who wins?

October 6, 2012 Leave a comment

I have spent most of the day looking over the products from TMS (Texas Memory Systems) that IBM just acquired. One of the questions I have always wondered is how to map performance back to a certain technology.  When dealing with DRAM and Flash devices there seems to trade offs on each. The first that comes to mind is DRAM requires some sort of battery backup as it will loose the data contents when power is lost. Most DRAM cards and appliances have this under control with some sort of destaging to SSD or they have some sort of battery attached to the IO card that allows the DRAM time to hold information until power is restored.
DRAM is typically faster than its flash cousin as well as reliable and more durable. Typically there is less controller latency due to the lack of complexity of wear leveling and garbage collection. DRAM is still more expensive that Flash and has the problem of needing power all the time.
When looking at systems to find out how to decide which solution fits your environment it comes down to price and IO. The DRAM solutions are usually smaller in size but can push more IO. For Example the TMS 420 is 256GB of storage in a 4U frame that can push 600,000 IOPs. Not bad if you need 256GB of really fast space. This could be used for very high transaction volumes.  This can be deployed with traditional storage and used for the frequently used database tables and indexes while lower IO tables can be thrown over to the spinning hard disk side.
In comparison the TMS 820 Flash array delivers a whopping 24TB in a 1U space and can push a meek 450,000 IOPS. This is somewhat incredible as the footprint is small and dense but still gives you the punch needed to beef up parts of your infrastructure. I stared running the numbers to compare this with say a V7000 with all SSD drives and we can’t come close.  You could virtualize  the system under the SVC code (included in the V7000) and use the Easy Tier function to move hot data to and from the TMS array which gives you the performance needed. I see why IBM decided to acquire TMS now.
So who wins in a DRAM and Flash discussion? The vendors of course, they are the ones who are going after this market aggressively. I think most consumers are trying to figure out if its needed to spend money on moving a database from 1500 disks at sub 20 ms response to using 200 larger disk and adding the DRAM or Flash device to keep the same latency. As an architect I want to keep in mind how much space and environmentals all of those disk eat up and having an alternative even if it costs more up front, is appealing.