W. Curtis Preston recently posted several entries in his Backup Central blog about post-processing dedupe speeds. The first entry asked why post-processing vendors, specifically FalconStor, Sepaton, Exagrid, and Quantum, do not publish their dedupe speeds and the second entry included agreement from each of the aforementioned vendors to publish their dedupe speeds. This, of course, is all good news and extremely helpful for end-users who are saturated with marketing hype about this or that dedupe solution.
As someone who has designed and sold VTL solutions from FalconStor, I want to call attention to a couple of points that are often overlooked by end-users when they evaluate a post-processing dedupe solution:
1) The dedupe performance capabilities of any node or set of nodes is a function of the amount of RAM in each node. The reason for this is that the seed data that will be deduped and the hash table which is used for the dedupe process is held in memory and when there is not enough available RAM, the solution will at best bottleneck and at worst stop the dedupe process. This is contrary to the ingest process, which is not RAM intensive but CPU and HBA throughput intensive.
For this reason, it is extremely important to size your nodes properly for dedupe, separately form the sizing for data ingest.; essentially the more RAM in the nodes, the better. However, one must also decide if the solution should be scaled up or scaled out. In other words, given financial and data center constrains, is it better to scale up to a few nodes with a large amount of RAM or scale out to a greater number of nodes with fewer RAM? That recommendation is best made by the individual vendor for their solution; but the point is that end-user needs to understand the reasons behind specific designs and choose the one that fits best in their environment.
2) One of the potential areas of bottleneck that is often overlooked is the storage controllers that provides the back-end capacity for the dedupe solution. Using the numbers that Curtis cites in his blog, let's assume an data ingest rate of 1 TB (1,000 Mb)/second and a dedupe rate of 500 MB/sec. if you are doing concurrent processing (which means starting the dedupe process when a virtual tape is written and "ejected" or a backup job is complete, instead of traditional post-processing where dedupe begins when all backups jobs are finished writing to disk), then you are looking at sizing for 1.5 TB/sec of throughput. If you then assume that a typical storage controller with quad-core CPUs can perform at ~400 MB/sec, with the typical I/O profile for a VTL/dedupe workload, you are looking at having four storage controllers in your solution. Depending on the storage system you are using for the back-end, that could be a single system with 4 controllers or 2 systems, each with 2 controllers; in either case, there is CapEx and OpEx costs to be considered. The number of storage controllers, of course, can be scaled back if your are doing post-processing dedupe where the dedupe process does not begin until all data ingest is completed.
There is also the issue of what will be prioritized if there is a throughput bottleneck during concurrent processing. Will the dedupe process be throttled down in favor of data ingest or will dedupe be prioritized? Personally, I would consider data ingest to be a higher priority since what is most important is finishing the backups. End-users should ask each vendor they are considering to explain how bottlenecks are handled. I should add that for this reason, I had several FalconStor personnel recommend post-processing be used whenever possible.
What I've detailed above is based on my own experience, specifically with FalconStor. I would invite any of the post-processing dedupe vendors to elaborate or correct what I have said. The main thing is to get the correct information to the end-user community so that they can make the right choice for their environment.
Friday, June 4, 2010
Thursday, June 3, 2010
Product Marketing Gone Wrong or When Roadmaps Lead to Dead Ends
One of the most frequent questions I hear from both end-users and vendor sales teams is, "what is the latest product roadmap?" Working for a small emerging storage vendor, the answer to that question is often used as a decision criteria by enterprise companies as they evaluate our storage system. For our sales teams, the roadmap becomes a barometer for the future health of the company and impacts our ability to push on despite rejections and disappointments. I am not saying these are correct viewpoints to hold, but are perhaps inevitable given the instabilities of our time and the inherent difficulties in starting a new storage company.
So given the importance of "The Roadmap," how is it actually formulated? For me, it should ideally be a synthesis of input from end-users, Marketing, software and hardware engineers, field techs, and sales teams. No doubt pulling all these ideas together and synthesizing them into a coherent roadmap is no easy matter. However, all too often vendor roadmaps are created by Marketing, executives, and engineering managers, with little or no input from end-users and from the field teams. So then, many times, the decisions about what features should go into the roadmap and what should be dropped or deferred, are made by smart folks, who nevertheless, have little or no recent experience with managing storage in the "real world." Add to that the inevitable development delays, it is no wonder that I find myself often scratching my head as I try to decide how to present a roadmap that was at least 6 months out of date when it was first conceived at HQ and is now more than a year or more behind where we need to be when it is finally presented to the field and to our customers.
When I was at EMC, that wasn't as much of an issue because of our inherent credibility as a major IT vendor and because we were in a position to guide and sometimes even dictate what features end-user should be looking for in the future. And even if some upstart, such as 3PAR, Compellent, or Pillar Data Systems, introduced a new capability that grabs mind share, EMC can simply pronounce that the new technology is immature, produce their own version of the technology, rename it, and then introduce it to the world as a more mature and better engineered product.
That's a luxury that a small company like mine does not have. So companies like mine and others of the same ilk need to make even greater effort to speak with those who are closest to how the technology will be used in the "real world." And it can't be just a marketing stunt; that type of input has to be taken seriously and there has to be mechanisms for evaluating that input and factoring it in when roadmap decisions are made.
For end-user, I have some advice regarding influencing roadmap decisions... Interject yourself into the system, especially if you are already a consumer of a particular vendor's solution; demand input into the roadmap before it is finalized since you are looking into becoming or already are an investor into, not only the vendor's technology, but the company itself. Recognize, especially if the vendor is small, that development resources are limited; this is especially the case when the product is new and the vendor has to allocate already overstretched development resources into fixing bugs. Therefore, make judicious choices about what features to request; choose features that will make the solution better and not just "nice-to-haves" such as a better GUI color scheme. Finally, recognize that how much value is placed by a vendor on end-user roadmap input is directly proportionate to the value of your company's name as a customer "logo"/reference and/or how much future revenue you are likely to generate for the vendor; therefore, if you are not with a "big name" company, you need to frame your feature requests in terms of their impact to future purchases.
In the end, making sure that future solutions are aligned with what will solve real customer problems is the job of both the vendor and the end-user community. I urge everyone to take up the challenge before decisions are made that lead to dead ends.
So given the importance of "The Roadmap," how is it actually formulated? For me, it should ideally be a synthesis of input from end-users, Marketing, software and hardware engineers, field techs, and sales teams. No doubt pulling all these ideas together and synthesizing them into a coherent roadmap is no easy matter. However, all too often vendor roadmaps are created by Marketing, executives, and engineering managers, with little or no input from end-users and from the field teams. So then, many times, the decisions about what features should go into the roadmap and what should be dropped or deferred, are made by smart folks, who nevertheless, have little or no recent experience with managing storage in the "real world." Add to that the inevitable development delays, it is no wonder that I find myself often scratching my head as I try to decide how to present a roadmap that was at least 6 months out of date when it was first conceived at HQ and is now more than a year or more behind where we need to be when it is finally presented to the field and to our customers.
When I was at EMC, that wasn't as much of an issue because of our inherent credibility as a major IT vendor and because we were in a position to guide and sometimes even dictate what features end-user should be looking for in the future. And even if some upstart, such as 3PAR, Compellent, or Pillar Data Systems, introduced a new capability that grabs mind share, EMC can simply pronounce that the new technology is immature, produce their own version of the technology, rename it, and then introduce it to the world as a more mature and better engineered product.
That's a luxury that a small company like mine does not have. So companies like mine and others of the same ilk need to make even greater effort to speak with those who are closest to how the technology will be used in the "real world." And it can't be just a marketing stunt; that type of input has to be taken seriously and there has to be mechanisms for evaluating that input and factoring it in when roadmap decisions are made.
For end-user, I have some advice regarding influencing roadmap decisions... Interject yourself into the system, especially if you are already a consumer of a particular vendor's solution; demand input into the roadmap before it is finalized since you are looking into becoming or already are an investor into, not only the vendor's technology, but the company itself. Recognize, especially if the vendor is small, that development resources are limited; this is especially the case when the product is new and the vendor has to allocate already overstretched development resources into fixing bugs. Therefore, make judicious choices about what features to request; choose features that will make the solution better and not just "nice-to-haves" such as a better GUI color scheme. Finally, recognize that how much value is placed by a vendor on end-user roadmap input is directly proportionate to the value of your company's name as a customer "logo"/reference and/or how much future revenue you are likely to generate for the vendor; therefore, if you are not with a "big name" company, you need to frame your feature requests in terms of their impact to future purchases.
In the end, making sure that future solutions are aligned with what will solve real customer problems is the job of both the vendor and the end-user community. I urge everyone to take up the challenge before decisions are made that lead to dead ends.
Wednesday, June 2, 2010
How Do We Make Sense of It All?
EMC, NetApp, 3PAR, Isilon, Compellent, Pillar Data Systems, Xiotech, Hitachi, Brocade, and Cisco. SAN, NAS, Fibre Channel, iSCSI, FCoE, CIFS, and NFS. Fibre Channel, SATA, SAS, and SSD. Sometimes there seems to be precious little that the storage industry spends more time on than creating new TLAs and industry terms. Some may argue that about the only thing the companies in this industry is better at doing is propagating FUD about their competitors
Often, we spend more time spreading FUD about the competition and defending ourselves from their FUD than we do educating users and helping to solve real problems. In fact, one of the benefits I brought to my employer when I switched over from the 800 pound storage gorilla, was a certain level of immunity from the FUD being spread by EMC competitors. I loved having various vendor sales teams spread some false information about the CLARiiON or the DMX and then watch their faces drop when I systematically dismantled their arguments. Of course, it also meant that the EMC sales and customer service teams knew they couldn't get away with exaggerated claims about certain capabilities of a product or denial of known issues and bugs.
However, what about those end-users who have never sat on the vendor side of the table? My colleagues were often confused and frustrated by the charges and counter charges coming from one vendor or another. Often their response was to fall back to what they knew, not because it was the best choice, but because it was the easier choice when trying to make sense of it all. The outcome is that often the only winner is the incumbent vendor and end-users are the real losers because they are discouraged from taking risks that may prove to be better solutions.
Now that I've been back on the vendor side, this time with one of those new "emerging" storage vendors, I am seeing, from a different perspective, how the incumbent storage vendors so often use FUD to paralyze end-users and to prevent them from taking worthwhile "risks." My hope with this blog, is to look a the storage industry from both sides of the vendor/end-user table and to provide some analysis that may be enlightening to all parties, even if it means sometimes hitting both over the head with my words.
Besides this blog, I am also hoping to make my presence felt on Twitter @nyc_se. Please feel free to comment and let me know how I am doing.
Often, we spend more time spreading FUD about the competition and defending ourselves from their FUD than we do educating users and helping to solve real problems. In fact, one of the benefits I brought to my employer when I switched over from the 800 pound storage gorilla, was a certain level of immunity from the FUD being spread by EMC competitors. I loved having various vendor sales teams spread some false information about the CLARiiON or the DMX and then watch their faces drop when I systematically dismantled their arguments. Of course, it also meant that the EMC sales and customer service teams knew they couldn't get away with exaggerated claims about certain capabilities of a product or denial of known issues and bugs.
However, what about those end-users who have never sat on the vendor side of the table? My colleagues were often confused and frustrated by the charges and counter charges coming from one vendor or another. Often their response was to fall back to what they knew, not because it was the best choice, but because it was the easier choice when trying to make sense of it all. The outcome is that often the only winner is the incumbent vendor and end-users are the real losers because they are discouraged from taking risks that may prove to be better solutions.
Now that I've been back on the vendor side, this time with one of those new "emerging" storage vendors, I am seeing, from a different perspective, how the incumbent storage vendors so often use FUD to paralyze end-users and to prevent them from taking worthwhile "risks." My hope with this blog, is to look a the storage industry from both sides of the vendor/end-user table and to provide some analysis that may be enlightening to all parties, even if it means sometimes hitting both over the head with my words.
Besides this blog, I am also hoping to make my presence felt on Twitter @nyc_se. Please feel free to comment and let me know how I am doing.
Subscribe to:
Posts (Atom)
Posts
