Scale Computing – HC3 Product Launch

Scale Computing… the company with a name that never really made sense… until today. You see, Scale Computing began in 2007 as a storage company. Their most recent product lines, the M Series and S Series products, utilized HGFS (licensed through IBM) to provide a clustered filesystem for data consumption. Need more space… just add a new node and let the cluster work its magic. Combine the simplicity of the cluster filesystem with the creation of a highly usable web-based management utility, and you get a simple and powerful storage system.

But… isn’t that storage? Not really compute? Perhaps the “Computing” was foreshadowing for the most recent Scale Computing product release: HC3 Hyperconvergence system.

HC3 represents a significant change to the direction and focus of the company. Scale is utilizing IP and existing products in the storage realm and enhancing the storage experience with server virtualization functionality.

Let’s dig into some of the nitty gritty technical details we all want to see:

Technical low-down

The virtualization functionality is provided via the highly powerful and versatile KVM hypervisor. The use of KVM in a system like this always raises an eyebrow, or two. More often than not, KVM is relegated to the “Linux/UNIX geek” realm. The hypervisor is highly functional, feature rich, and has a very solid following in the Open Source community. New functionality, enhancements, and maintenance is constantly ongoing. Plus, with KVM in the OpenStack development line, KVM is just the beginning of where the Scale Computing layer could go in the future. Additionally, as a consumer of Open Source software in its solution, Scale contributes back to the community. Scale has slightly modified KVM to allow for better caching and has released that code back to the community for consumption elsewhere.

As mentioned above, Scale is building the HC3 on their existing HGFS filesystem. KVM is a natural hypervisor selection based on the fact that it operates at the same level in the OS as the filesystem… just another service installed in the OS.

Many of the expected virtual machine management functionality is present in the HC3 product:

  • Live Migration
  • Resource Balancing
  • Thin Provisioning
  • VM Failover/Restart On Node Failure
  • Storage Replication
  • etc…

As far as hardware is concerned, the HC3 product is built on the same hardware as the M Series storage line. You can see more details here: Heck, existing Scale Computing customers can install a firmware upgrade on the M Series hardware to get HC3 functionality… gratis too.

Management of the environment, like the storage, is handled in a clustered fashion. Connection to any of the node management IP addresses results in the ability to control the entire cluster. No need for a centralized controller for management services. The connection for management is handled by any HTML5 compliant browser. I guess this means an iPhone browser could be used (although, I question the usefulness of such a form factor… but, it should work nonetheless).

Once logged into the management interface, a number of components can easily be managed: Virtualization, Storage, General, etc… If you have used the interface before, the only major difference between the pre-HC3 and post-HC3 interfaces is the addition of the Virtualization option. The interface is very simplistic with very few options available. Navigation is logical and easy to use.

Target Market

Scale computing has made a very conscious decision to focus on the SMB/SME markets. These markets tend to employ a small number of IT personnel with limited knowledge and high expectations placed upon them. For the business, selecting a product that performs a role, is easy to use, and provides high levels of availability is extremely desired.

Scale has identified the market and designed HC3 to reflect what their customers want:

  • Easy administration
  • Few configuration options
  • Expandability
  • Small form factor (1U servers)
  • Support for common operating systems
  • Resiliency
  • Performance
A solution like HC3 fits really well for the SMB/SME markets. If the business does not have a need for a highly customizable environment, HC3 may be exactly what they are looking for. Leveraging HC3 may result in IT administrators having extra time on their hands to work on other projects.

What makes Scale Computing HC3 different?

One of the most significant differentiators for the HC3 product is their starting point. While it makes sense for THIS company, starting with a solid storage foundation, followed by a virtualization plan is really a different path to get to a converged infrastructure product. Scale has developed a solid storage product and decided to make a hypervisor decision that compliments existing efforts while providing the functionality customers are looking for.

The ability to scale compute and storage resources is becoming an expectation and the norm in virtual environments. HC3 allows for two major ways to scale:

  1. Addition of a new HC3 node – This adds additional footprint for executing virtual machine workloads… plus additional storage.
  2. Addition of a new M Series node – This adds additional storage without the compute functionality.

Scaling by adding an M Series node, while possible, just does not make sense at this time. The possibility to add additional compute resources to the HC3 cluster holds so much more potential benefit to a consumer that I find it hard to believe this would be used. But, for what it is worth, that is an option.

Simple is better. For the target market, removal of complexity results in a predictable and, hopefully, low-touch compute environment. There is less of a need to have deep knowledge just to keep the compute environment functional. Scale has made a number of configuration decisions behind the scenes to reduce the load on customers.

What is missing?

With all the hotness that HC3 provides, a number of notable features are missing from this release:

  • Solid reporting – Aside from some “sparkline”-esque performance graphs (on a per VM basis), the ability to look back on a number of statistics for any number of reasons (Ex: troubleshooting performance issues) just is not there. For the target market, this may be an acceptable risk. I do not necessarily agree, though.
  • VM Snapshotting – At this time, the snapshotting functionality is achieved by snapshotting the entire filesystem.
  • Crash Consistent Snapshots – The snapshots of the volumes are crash consistent — in the event a VM is restored from a snapshot, it is in a state that mimics a sudden loss of power… the server has crashed. So, reliance on OS and application recovery is necessary. Probably a good idea to have backups. Pausing the VM, if possible in your environment, prior to taking a snapshot would help in stability… but, that is a stretch.

Virtual Bill’s Take

I absolutely love the focus on the SMB/SME markets. They need some TLC, for sure. By focusing on creation of a utility virtualization device, the IT resources in the business can focus on moving the business forward rather than messing with complicated details. Howard Marks made a comment during a briefing from Scale: “Do you care if your car has rack and pinion steering? I just want to get in and drive”. This solution addresses the need to get in and drive. I can see this as being very appealing to quite a number of companies out there.

Scale Computing is an up and comer in the converged infrastructure game going on now. Converged infrastructure is making a play in the corporate IT ecosystem that challenges traditional thinking… and that is always a good thing. Selection of KVM as the hypervisor is logical, but it is going to be a hurdle to overcome. KVM just does not have the household recognition as other vendors. So, getting support from many directions is going to be challenging. But, after speaking with Scale Computing, they’re up for the challenge.

If they play their cards right, HC3 could help usher in a flood of new customers to Scale and a change in how SMB/SMEs operate server environments.


Growing Pains–Network Scaling And Maturation

When I signed up with my current employer around 8 years ago, the world was a different place. We did not have much of a budget, so we relied on some creative thinking and duct tape to get the job done. The network was a much simpler place too. Every office had their own local servers and WAN traffic definitely fit a simpler profile. Planning for the future was more targeted at which products provided the most functionality at the lowest (or no) cost.

However, that was then and this is now. Suddenly, we have budgets and business sees value in investing in a cost-center, like IT. The business is growing. More and more traffic is passing over the WAN and the profile has changed drastically. Voice traffic, ICA/RDP, backup needs, and just plain more data is increasing the load on the network. Plus, we have new offices opening in places where getting a static IP address is extremely expensive and not realistic.

The network was designed a decade ago and it is becoming time to remodel so we can continue to grow. The issue becomes how. Which change is going to provide the biggest bang for our buck?

We have the backing and we believe we have made some core infrastructure purchases that allows us to operate right now and grow into the future.

So… where do we go from here?

– Dynamic Routing Protocol: Static routes have been great as we use a hub-and-spoke model for the time being. However, as we expand into China and Europe, the networking design will need to change and routing will become more and more important. Something like EIGRP will probably be the best fit for us.

– Inter-office communications: Some offices have MPLS connections. Others do not… so, their communications travel all over the world to reach other offices. Being able to bring up VPN tunnels on demand to facilitate more point-to-point connectivity is going to be important. Hello DMVPN. Sure, I can create VPN configurations on each office router for other office routers, but that becomes increasingly difficult and monotonous as a new office comes onboard and the branch offices can only handle so many connections.

– Geographic routing blocks: Conceptually, just having geographic regions in the same IP addressing area makes for simpler routing. That means re-IPing a handful of offices to meet the needs.

– Regional hubs: Does it make sense to aggregate core services in a single location or create regional hubs and focus on higher performing hub-to-hub communications. I believe the answer is ‘Yes’!

All of this is really showing me a brief glimpse into the pains and considerations that really need to take place to create a more mature networking environment. Concepts like:

– Router hardware limitation (CPU availability, encryption offloading, etc…)

– Router limitations impact on network throughput

– Resiliency design

– Limitations and Advantages of various routing protocols

– Packets Per Second (versus they typical Mbps style measurement)

– plus much more!

Based on my research, this is the next logical step for us to move. I am sure there are 1 million other ways to go (always open to comments). But, as long as I try to be forward looking and pay more attention to the little details, we should be good to go!

Implementing the options from above sounds like a lot of fun. My inner geek is squee’ing with excitement. Hopefully, these projects will turn into reality and we can begin using a smarter, larger, and more robust network in the near future.