Archives for posts with tag: storage

Storage performance is core to application performance and data access.  When we talk about storage performance, we typically talk about IOPS and throughput, but there is a third variable, latency.  Latency measures the time it takes for storage to respond to a request or instruction issued by the CPU.    The lowest latency is achieved by delivering data from memory at the speed of memory.  The typical latency is at 1us.  If data could be delivered at such latency, we would have a highly efficient server architecture, but  there are a number of factors that prevent out ability to see latency at that level.

  • Application latency – the inherent architecture of the application may make it impossible to achieve microsecond latency.  Typical operations add to the overall latency.
  • Local file system – since DRAM is volatile, data that requires persistence must be committed to persistent media before an acknowledgement is returned.  The local file system is responsible for taking blocks off DRAM and copying them to other media on the I/O bus.  A common Linux file sytsem such as XFS or EXT4 add as much at 250us.  Even with the replacement of DRAM with NVDIMM (persistent memory), the latencies remain at minimum at 250us.  Though 250us may seem like nothing, in a typical database environment the reduction of 250us alone would increase IOPS and throughput per core by 350% and 410% respectively.
  • Network – When data travels over the network, whether it is FC or IP, there are added latencies.   Most all SSD/Flash arrays deliver performance at 1ms or more latency.  If SSD/Flash is sitting on the PCIe bus, that latency may be reduced to  a range between 500 and 800 microseconds.  Recently, a new protocol has been developed to allow shared storage (SAN) to deliver the same latency as storage on the PCIe.   This is the NVMe standard.
  • Drive media – Flash has a lower latency profile than HDD; it is not surprising since HDD is a mechanical device where the speed with which the platters spin correlates to the time it takes for the data to be pulled off the drive.  Flash is not a mechanical media and doesn’t have the same delays built in.

Of course we can’t leave out IOPS and throughput.  IOPS measures how many operations can be performed per second while throughput is how much data can be transferred through a given pipe.  Depending on the application, one of the other of these metrics will be more relevant.

For applications that stream data sequentially require more bandwidth and are therefore more concerned with throughput.  Thoughput may be calculated by the total bandwidth of the drives in a given system, the controllers, and the network.  Even if you have a system capable of delivering gigabytes of data, it still needs the network to carry the data.  There is often an imbalance between the network and system capabilities.  Recently a client expressed concern exemplifying this issue.  As a research institution there is a lot of data created by the labs and then processed by the investigators.  The challenge they are facing is that the amount of data being created and moved to a centralized location is much greater than what the network can handle.  As a result, they are unable to transfer data over the wire; some use tape or don’t move data at all.

IOPS  measures the number of operations a drive or a system can perform.  We have seen huge gains with the adoption of SSD/Flash.  Where a 15K RPM drive has the ability to deliver around 180 IOPS, a flash drive has the ability to deliver thousands of IOPS.  About 10-15 years ago storage administrators would be forced to over-provision capacity in order to get enough drives in a RAID set to deliver required number of IOPS.  As an example:  if your application needed 1 TB of data and 1,500 IOPS, using 15K drives at 300GB of capacity each an administrator would have to provision 4 drives to reach required capacity and 9 drives to reach the required IOPS.  Today,  capacity and IOPS can be balanced.

Not all applications require microsecond latency, thousands of IOPS and gigabytes of throughput, but with higher performance, when properly designed, the system can perform at a much higher level of efficiency, both operational and financial.  Next time we talk about performance, let’s make sure we are clear what performance we need.

 

I haven’t written a blog in some time, I have been working on many interesting projects.  More on that later.

This week I saw that HPE has signed a definitive agreement to acquire Nimble Storage for $1B.  Nimble is a solid system and the company has done a great job bringing it to market.  Nimble did all the right things from a sales and marketing perspective.  I can understand why it is an attractive target for HPE or any other potential acquirer.  That said, here are some reasons why I question the value of this merger:

  • HPE has a hybrid SSD/HDD system (3PAR); they have spent a lot of time porting it to a smaller entry point.  There is a significant overlap between 3PAR and Nimble from a target market perspective.  BTW, 3PAR seems to be one area in storage at HPE that is growing so why cannibalize or compete with self?
  • HPE has areas of the portfolio that are really lacking in offerings.  This includes NAS/file system storage, Object storage, tier 3 bulk storage, and others.  There is growth in storage in unstructured data and virtualization.  If you want growth, go where there is growth in the market.
  • Part of Nimble’s success is its go to market strategy and execution.  HPE takes a different approach to channel than Nimble.  One consideration is whether the challenge is gaining more growth in storage is more associated with how HPE sells and markets than what products they care, at least in some areas.  If you want to compete with younger more agile firms, then try being more agile.  Agility in sales process is something other large companies lack.

Moving forward, I hope HPE  doesn’t take too long to integrate Nimble and adopt some of Nimble’s strategies.

My job requires me to be at the intersection of customer buying products and services and the industry creating and bringing to market technology.  I have found that there is a great disconnect between what the industry is hyping and what is really possible.

For a number of years now we have been touting the cloud as the answer to all our infrastructure aches and pains.  “If you go cloud, you will have more flexible, just what you need, less expensive services” the trade magazines and pundits claim.  The reality though is, “it depends”.

The concept of utility computing has been around for some time. Back in the dot.com boom there were a number of companies attempting to provide storage as a service, shared infrastructure, etc.  I actually worked for one of these companies, Genuity.  What really defines utility based services is the delivery of a service just in time and the payment for such service based on consumption.  That is how the electrical services work.  And if we all needed the same exact service varying only in the quantity of it, then we would be set, but application infrastructure doesn’t run that way. If you poll organizations that have standardized on VMware as an example.  They all may have and even run application such as MSSQL Server or MySQL or another common applications, but the demands of these applications on the infrastructure will be different in every situation.

When customers ask me about cloud or how to get there, usually because someone higher up has decided that cloud is the way to go, I first ask them what it means to them.  I then try to understand the drivers behind wanting to go to the cloud.  Here are some reasons that make sense:  spikes in demand, seasonal applications or projects, don’t want to manage my application, don’t have a secondary site for my backups or DR.  The most common way to embrace the cloud actually aligns with some of the traditional business concepts such as ‘focus on your core competency and outsource secondary services’.  This means if an application or service is not core to your organizations business objectives, then consider outsourcing it.  Best examples of this include email outsourcing (Office365, gmail, other email services), email archiving, CRM, telephony and conferencing, backups, and file sharing.  It also makes sense that if you need some resources for a short period of time, it is more likely to be cost effective to go to the cloud than to procure it in house.

Of course we should keep in mind that not all clouds are the same and that not all applications are the same.  The traditional enterprise applications are highly dependent on the underlying infrastructure to perform while newer cloud-centric applications have build much of those dependencies into the application it self.  This means that your Oracle db may not work well in EC2 but your MongoDB will have no issues.

Finally, if we are talking about utility we are talking about operational costs.  If the goal is to achieve OPex rather than CAPex, cloud is not the only answer.  There are traditional outsourcing offerings in the market that allow you to consume as an OPex, even if the infrastructure is dedicated to you.  There are specialty service providers that offer services for specific applications where the infrastructure is shared but the application is yours and yours alone.  At the bottom of all these options is operational leasing.

I am not saying that cloud is not great and that it is not reality.  What I am saying is that we have to be careful when we refer to cloud.  We need to qualify what we mean, what, expect.  The technology continues to evolve; there is a lot of innovation in the industry today and we are making great progress to making cloud more ubiquitous.  Part of it designing and building applications that run better on commodity infrastructure; part is enabling quality of service and custom service delivery in a multu-tenant environment.  If you think you want cloud, just make sure you have a clear idea of what that means to you.

I have been meeting with a variety of organizations and what is a reality marketers and product managers often forget is that everyone buys something different even if on surface it seems like they are buying the same thing.  For example, an organization announced that it is looking for 75TB of storage to support their db environment.  It seems pretty straight forward, they need storage.  Then, when you get a little closer, you discover that what they are really buying has little to do with storage at its foundation.

So what was this organization buying?

– the database application required some level of performance and so the storage system had to deliver the best possible performance per GB at the lowest possible  price.  At some point, if all available options were offering the same performance at a similar price point, then the conversation became more based on perception of performance and how much is good enough.

– the last system deployed ran without any issues so we are buying reliability of the brand we have had rather than the unknown of the brand we don’t have any exposure to.

– Operational efficiency and effectiveness – we have been using system A for the past two years and even though the application we will be deploying is very different, there is a perceived notion that we can easily architect the known platform for this use case better than something else

– Support is critical – even though I supposedly have had no issues with the system I have, I want to make sure that I have best support in my neighborhood just in case.

– My friend in company B just deployed a new environment and it includes product A, which means it is good and I too should buy it

– Company X is taking my hardware back and giving me credit, making the purchase less expensive.  I am not sure that it will deliver what I need or want or will be less expensive over time, but it looks good right now.

– I like the new product but I don’t have the resources to evaluate it and it is too much work to do other background checks, I will just buy a product from company I know even if it is doesn’t offer what I really need or want.

– I don’t know what I need but Vendor C just told me something interesting and I want it so I will buy it.

– I don’t like the sales rep from company B so I will buy from company X because their rep is nice.

There are many reasons why purchase decisions don’t seem rational or logical.  Anyone selling in this industry must be aware of who is buying, what they are buying, and why.  The best technology doesn’t always win, but a good enough product with a strong sales and marketing force can become a billion dollar enterprise.