Nexenta Blog

10+ Lessons from my Software-Defined (SDx) Life

18 Apr 2014  by Nexenta

After an exciting week in Amsterdam, Paris and London, where we had Nexenta’s quarterly sales meeting, the first of our global OpenSDx Summits, our French launch in Paris, and my first TV interview for Nexenta in London (@cloudchantv) a number of key themes are bubbling up.  Multiple industries, organizations, people and technologies are energized by the promise of Open, SoftwareDefined “everything” – from storage, servers, and networks, to data centers, infrastructure and ultimately enterprises.  Few vendors are delivering on this promise, and few organizations understand that Software Defined Storage (#softwaredefinedstorage) (SDS) is the first critical step on this journey.  Here’s what’s top of mind from a week with the movers, shakers and influencers of OpenSDx:

1. Hip or Hype? the Future of OpenSDx
2. Software-Based and Software-Defined are different
3. “Open” is also for Organizations
4. CIOs have new imperatives – and new opportunities 
5. Evolution is the name of the game
6. Scale changes everything
7. Agility + Simplicity = Happy
8. Macroeconomics affect storage economics
9. CIOs need a better technology cost basis
10. Think twice about the cost of Cloud
11. Civil rights mean data rights
12. UK, France & Spain lead SDS pack

1. Hip or Hype? the Future of OpenSDx

There’s a lot of buzz in the industry right now around Software Defined “everything”– even traditional hardware vendors suddenly have “software-defined”, yet inexplicably hardware-based, solutions.   The resulting market fog means end users can’t get a clear view of OpenSDx.  What to do?  Get the facts straight.  Look to industry leaders like VMware who invite you to master the new reality of the Software Defined Enterprise.  Look to analysts like IDC pointing to the starring role that software increasingly plays in IT infrastructures, and survey data that show over 50% of companies in leading countries considering software defined solutions.  There’s a lot of hype, but at the end of the day, your enterprise will be software defined, and SDS is the first platform on which to achieve competitive advantage.

2. Software-Based and Software-Defined are different

To improve the view of SDx, we need standards and definitions that we can all agree on.  Analysts differentiate between Software Based and Software Defined solutions.  Why shouldn’t you?  If you want to tell the difference, ask, “How many hardware platforms does your Software Defined Solution run on?”  One is not the right answer … Software Based means you should expect hardware dependency, Software Defined means hardware, application, and protocol agnostic, enabling a Software Defined Infrastructure, for your Software Defined Enterprise.

3.  “Open” is also for Organizations

Open Source started a fundamental shift in how people think about technology – collaborative, flexible, cross-functional, team oriented.  OpenSDx is the next generation of Open Source for enterprise technology, be it compute, storage, or networking  –  like Nexenta – 100% Software.  Total Freedom.  All love. :)  Development of such solutions means breaking down barriers to create integration opportunities, increasing communication between both people and technologies.  As the gravitational pull of OpenSDx gets stronger, organizational movements are beginning to reflect this desire for open, collaborative environments, from the creation and empowerment of cross-functional Dev Ops teams, to industry collaborations like the Open Compute framework.

4. CIOs have new imperatives – and new opportunities 

The best CIOs have never been just about technology – they have a holistic view of the business and IT, and now they’ll be rewarded as they use this special insight to qualify OpenSDx solutions and understand where and why it best fits in their organization.  OpenSDx holds incredible power for CIOs – it helps transform them from IT service providers to strategic partners, capable of improving the speed of business and delivering not just technology but innovation.   OpenSDx = Efficiency = Innovation = Competitive Advantage.

5.  Evolution is the name of the game

Revolution is a scary thought for most IT leaders – few organizations want to be on the bleeding edge of technology innovation for their mission critical systems – but rapid, low risk evolution is oh so attractive, especially when your initial steps build a foundation giving a competitive advantage.  Organizations taking steps now to implement Software Defined solutions will find not only near term business benefits, but also longer term competitive ones.  This is why so many analysts and industry leaders are highlighting SDS as one of today’s big trends.  Storage is the bedrock of the data center; if you can evolve this expensive, growing component of your data center, all the change layered on top will be easier.

6.  Scale changes everything

The scale of IT has exponentially increased – environments are built with hundreds and thousands of devices and systems, proof of concepts on 100 units no longer suffices.  The complexity associated with such environments is immense, and resources and knowledge must scale more efficiently.  Architectures, people and processes will all need to evolve, and simple, manageable tools are needed to do so effectively.  At Nexenta, our typical installation used to be on the order of tens of terabytes; now, our largest customer will grow to half an Exabyte in the next eighteen months.  We expect to see more customers and organizations moving that direction.

  7.  Agility + Simplicity = Happy

Much like taking part in a revolution, end users cheer for flexibility and choice – but with boundaries.  While Software Defined (SDx) solutions mean you can make more choices, the potential permutations can be overwhelming – analysis stops, paralysis ensues, innovation stalls.  It’s incumbent upon OpenSDx solution providers to develop simple, manageable solutions, so that agility is delivered with simplicity.  Choice is wonderful, but introduces complexity, and at the end of the day, IT managers need to be sure they can still run their own house. (#agilesimplehappy).  When we engaged customers in release planning for NexentaStor 4, the loudest chants were for simplicity and improved manageability, and delivery of those characteristics is critical to customer satisfaction.

8.  Macroeconomics affect storage economics

According to the IDC surveys shared by Donna Taylor (@Donna_IDC), macroeconomic trends have a trickle down effect on storage buying behaviors.  Storage is the fastest growing, and often largest, line item in an organization’s IT budget.  How do you stave off additional CAPEX and OPEX costs?   Keep your storage longer, keep it off warranty, do more with less.  Customers are also willing to pay a little extra for flexibility and choice, so that longer-term options exist that extend the life of their storage assets.   You can also just buy NexentaConnect to get simple, better performance and density for your VDI environment. (Yes, shameless plug!)

9.  CIOs need a better cost baseline

Organizations have two related problems when trying to address their return on investment.  First, many IT organizations spend over 70% of their budget to keep the lights on – this inhibits innovation, because resources focus on maintenance instead of value add.  Second, most IT organizations lack true IT cost transparency.  Budgets are based on past behaviors and high-level estimates vs. on fact-based usage of IT services.  The highest benefit of the Software Defined Enterprise is that it balances Business and Technology, empowering Technology to deliver, price and project IT services against a business strategy – and make recommendations on the right course of action.  How to solve for these challenges and achieve SDE benefits?  Deliver simple, flexible, manageable solutions that free up time, and enable a better IT operating model with intelligence from cost data.  CIOs looking to improve their infrastructure economics via SDDC / SDI will quickly need to examine their costs.

10.  Think twice about the cost of Cloud

Like the Hotel California, when it comes to your data and the cloud, “you can check-out any time you like, but you can never leave.”  (#ThomasCornely).  Many organizations choose public cloud services as an easy way to quickly add capacity, or ramp up new products; however cost needs to be examined carefully and holistically.  Remember that you’re not only paying for storage, but also for use and access.  It’s not a one-time cost, but a year over year, growing, expenditure.   Nexenta’s CIO-validated cost analysis, based on list prices, reveals that our solutions are 70% cheaper than legacy system solutions over a 3 year time horizon, and 15% less than cloud providers.  Do you know the true cost of your storage?

And a few bonus items for our friends in Europe!

11.  Civil rights mean data rights

With Edward Snowden on the television screen, frequent discussion of the US Patriot Act and concerns about European data being on American soil, it was clear that data security and privacy are top of mind for our EMEA friends.  European organizations must enable end user preferences on how their is data used, understand what constitutes consent, how long it lasts, and also permit the “right to be forgotten”.  While data security itself is generally handled in the application layer, storage solutions like Nexenta’s with self-healing properties like those of ZFS help reduce data corruption and ensure data integrity, thus making sure the right data is available to the right people at the right time.

12.  UK, France & Spain lead SDS pack

The localization of SDS solution adoption is evident in Europe not only by industry but also by geography; as I am finding, it’s incredibly important to understand not only the culture and expectations of the countries where we work, but also where they are in their SDS journey, and what’s needed to help them take the next step.  According to survey data presented by Donna Taylor, IDC’s EMEA storage analyst, there is a continuum of adoption in Europe, with the UK, France and Spain leading the pack in terms of interest and adoption around SDS solutions, and the Nordics at the other end, exhibiting some interest.

So, what’s the upshot?  OpenSDx is real.  It’s here.  Everyone’s talking about it.  In my interview with CloudTV (@CloudTV), I was asked what makes me passionate about Nexenta and Software Defined Storage.  My answer?  We are at the forefront of a fundamental shift in how business and technology operate today – one that’s going to make all industries more efficient, more innovative, more competitive, and better.  What better place to be than leading that revolution?

Join the conversation. Let us know what you think via @Nexenta and stay tuned for videos of Nexenta’s OpenSDx Summit EMEA sessions on our YouTube channel.

by

Jill Orhun
Marketing & Chief of Staff
Nexenta Systems

CCOW-Negotiating Rendezvous Groups

23 Dec 2013  by Nexenta

CCOW^TM Replicast is a storage protocol that uses multicast communications to determine which storage servers will store content and then retrieve it for a consumer. It also allows content to be accepted/delivered/replicated using multicast communications. Content can be placed once and received concurrently on multiple storage servers. Replicast can also scale to very large clusters and can support multiple sites, and each site can be as large as the networking elements will allow.

In order to understand how Replicast works, you must first understand how it uses Multicast addressing. Specifically, how the role of the Negotiating Group and Rendezvous Group differs from Consistent Hashing algorithms which are the normal solution for distributed storage systems.

How Conventional Object Storage Systems use Consistent Hashing

The Object name, sometimes referred to as the payload of a chunk, is used to calculate a Hash ID. This ID is then mapped to an aggregate container for multiple objects/chunks (for OpenStack Swift these are called “Swift Partitions” and for CEPH they are called “Placement Groups”). Although the quality of the hashing algorithm can vary, the content of a chunk has to map to a set of storage servers that is based on an Object Name in order to achieve a consistent hash algorithm. If you start with the same set of storage servers, the same content will always map to the same storage servers.

Promoters of Consistent Hashing make the point that Consistent Hashing limits the amount of content that must be moved when a set of storage servers change. If there is a 1% change in the cluster membership then 1% of the content must be relocated. In the long run, you actually want 1% of the content to move to the new servers. Should 1% of the content be lost, you will want to create new replicas of the lost 1% on other servers anyway.

Where CCOW Replicast differs is that it can be far more flexible about when that replication occurs and more selective as to which data is replicated. Replicast has a different method of assigning locations. These more efficiently deal with evolving cluster membership to achieve far higher utilization of cluster resources when the membership isn’t changing.

Negotiating Group

CCOW Replicast uses a “Negotiating Group” to effectively support the chunks “location”. An object name still yields a Name Hash ID (using the Name of the Named Manifest) but that Hash ID maps to a Negotiating Group. When a Manifest references a Chunk, it is found by mapping its Chunk ID (which is the Content Hash ID of the Chunk) to a Negotiating Group.

The Negotiating Group will be larger than the set of servers that would have been assigned by Consistent Hashing. Typically ten to twenty members of the Negotiating Group is preferred. The key is that the client, or more typically the Putget Broker on the client’s behalf, uses multicast messaging to communicate with the entire Negotiating Group at the same time. Effectively the Putget Broker asks “Hey you guys in Group X, I need three of you to store this Chunk”. A Negotiation then occurs amongst the members of the Negotiating Group to determine which three (or more) of members will accept the Chunk, when and at what bandwidth.

“Negotiating” sounds complex but the required number of message exchanges is actually the same as any TCP/IP connection setup. So the Negotiating Group can determine where the Chunk will be stored and with the same number of network interactions as Swift requires for the first TCP/IP connection. For the default replication count of three, Swift requires three connections to be setup.

More importantly, a consistent hashing algorithm (such as Swift uses) will always pick the same storage servers. This is independent of the workload of these servers. Many consider this as the price of eliminating the need for a central metadata server.

With Consistent Hashing, the 3 servers with the lightest workload are selected out of 3 storage servers (assuming the replication count is 3). Of course that also means you are also selecting the 3 busiest servers. With CCOW Replicast you select the 3 servers with the least workload from all the available servers.

Implications of Dynamically Selection

With dynamic load-sensitive selection, CCOW Replicast enables you to a) run your cluster at higher performance levels than Consistent Hashing would allow, and b) still have lower latency.

A well balanced storage cluster will at peak usage want individual storage servers to be loaded only 50% of the time. If they are heavily loaded less than 50%  of the time then the cluster could accommodate heavier peak traffic and you have overspent on your cluster. If they are loaded more than 50% of the time then some requests will be much delayed and your users could start complaining. Should the chance of a randomly selected storage server being busy is 50%, what are the chances that all 3 randomly selected storage servers will not already be working on at least one request.

When it is time to retrieve a Chunk, the client/putget broker does not need to know what servers were selected. It merely sends a request to the Negotiating Group. The negotiating group picks one of its members with the desired chunk and the rendezvous is scheduled to transfer the data.

Rendezvous Group

While the Negotiating Group plans a transfer, it is executed by the Rendezvous Group. The Rendezvous Group implements Replicast’s most obvious feature: Send Once, Receive Many times. Transfers sent via the Rendezvous Group are efficient not only because they only need to be sent once, but also because all Rendezvous Transfers are using reserved bandwidth which they can start at full speed. There is no need for a TCP/IP ramp up.

An important aspect of Rendezvous Groups is that they are easily understood and verified with a known relationship to the membership in the Negotiating Group:

• Put transactions – every member of a Rendezvous Group is a member of the Negotiating Group with a planned Rendezvous Transfer or a slave-drive under active control of a member
• Get transactions – the principle member of the Rendezvous Group is the client or Putget Broker that initiated the get transaction. Additional storage servers could have also been part of a put transaction. These additional targets are piggy-backing creation of extra replicas on the delivery that the client required anyway.