Tag Archives: HC3

Behind the Scenes: Architecting HC3

Like any other solution vendor, at Scale Computing we are often asked what makes our solution unique. In answer to that query, let’s talk about some of the technical foundation and internal architecture of HC3 and our approach to hyperconvergence.

The Whole Enchilada

With HC3, we own the entire software stack which includes storage, virtualization, backup/DR, and management. Owning the stack is important because it means we have no technology barriers based on access to other vendor technologies to develop the solution. This allows us to build the storage system, hypervisor, backup/DR tools, and management tools that work together in the best way possible.

Storage

At the heart of HC3 is our SCRIBE storage management system. This is a complete storage system developed and built in house specifically for use in HC3. Using a storage striping model similar to RAID 10, SCRIBE stripes storage across every disk of every node in a cluster. All storage in the cluster is always part of a single cluster-wide storage pool, requiring no manual configuration. New storage added to the cluster is automatically added to the storage pool. The only aspect of storage that the administrator manages is creation of virtual disks for VMs.

The ease of use of HC3 storage is not even the best part. What is really worth talking about is how the virtual disks for VMs on HC3 are accessing storage blocks from SCRIBE as if it were direct attached storage to be consumed on a physical server–with no layered storage protocols. There is no iSCSI, no NFS, no SMB or CIFS, no VMFS, or any other protocol or file system. There is also no need in SCRIBE for any virtual storage appliance (VSA) VMs that are notorious resource hogs. The file system laid down by the guest OS in the VM is the only file system in the stack because SCRIBE is not a file system; SCRIBE is a block engine. The absence of these storage protocols that would exist between VMs and virtual disks in other virtualization systems means the I/O paths in HC3 are greatly simplified and thus more efficient.

Without our ownership of both the storage and hypervisor by creating our own SCRIBE storage management system there is no storage layer that would have allowed us to achieve this level of efficient integration with the hypervisor.

Hypervisor

Luckily we did not need to completely reinvent virtualization, but were able to base our own HyperCore hypervisor on industry-trusted, open-source KVM. Having complete control over our KVM-based hypervisor not only allowed us to tightly embed the storage with the hypervisor, but also allowed us to implement our own set of hypervisor features to complete the solution.

One of the ways we were able to improve upon existing standard virtualization features was through our thin cloning capability. We were able to take the advantages of linked cloning which was a common feature of virtualization in other hypervisors, but eliminate the disadvantages of the parent/child dependency. Our thin clones are just as efficient as linked clones but are not vulnerable to issues of dependency with parent VMs.

Ownership of the hypervisor allows us to continue to develop new, more advanced virtualization features as well as giving us complete control over management and security of the solution. One of the most beneficial ways hypervisor ownership has benefited our HC3 customers is in our ability to build in backup and disaster recovery features.

Backup/DR

Even more important than our storage efficiency and development ease, our ownership of the hypervisor and storage allows us to implement a variety of backup and replication capabilities to provide a comprehensive disaster recovery solution built into HC3. Efficient, snapshot-based backup and replication is native to all HC3 VMs and allows us to provide our own hosted DRaaS solution for HC3 customers without requiring any additional software.

Our snapshot-based backup/replication comes with a simple, yet very flexible, scheduling mechanism for intervals as small as every 5 minutes. This provides a very low RPO for DR. We were also able to leverage our thin cloning technology to provide quick and easy failover with an equally efficient change-only restore and failback. We are finding more and more of our customers looking to HC3 to replace their legacy third-party backup and DR solutions.

Management

By owning the storage, hypervisor, and backup/DR software, HC3 is able to have a single, unified, web-based management interface for the entire stack. All day-to-day management tasks can be performed from this single interface. The only other interface ever needed is a command line accessed directly on each node for initial cluster configuration during deployment.

The ownership and integration of the entire stack allows for a simple view of both physical and virtual objects within an HC3 system and at-a-glance monitoring. Real-time statistics for disk utilization, CPU utilization, RAM utilization, and IOPS allow administrators to quickly identify resource related issues as they are occurring. Setting up backups and replication and performing failover and failback is also built right into the interface.

Summary

Ownership of the entire software stack from the storage to the hypervisor to the features and management allows Scale Computing to fully focus on efficiency and ease of use. We would not be able to have the same levels of streamlined efficiency, automation, and simplicity by trying to integrate third party solutions.

The simplicity, scalability, and availability of HC3 happen because our talented development team has the freedom to reimagine how infrastructure should be done, avoiding inefficiencies found in other vendor solutions that have been dragged along from pre-virtualization technology.

Scale with Increased Capacity

2016 has been a remarkable year for Scale Computing and one of our biggest achievements was the release of the HC1150 appliance. The HC1150 significantly boosted the power and capacity of our HC1000 series and featured hybrid flash storage at a very affordable price. As a result, the HC1150 is our most popular HC3 model but, of course, we couldn’t stop there.

First, we have begun offering 8TB drives in our HC1000 series appliances to increase the maximum storage capacity by almost double (or actually double it on the HC1100). Data sets are ever increasing in size and this increase in storage capacity means you can grow capacity even faster and more affordably, one node at a time. The unique ability of HC3 to mix and match nodes of varying capacity (and across hardware generations!) means your storage can grow as needed each time you expand your cluster.

Secondly, we have introduced a new HC1150D appliance for pre-sale which doubles the CPU capacity with a second physical processor. CPU can often be a performance bottleneck in scaling out the number of VMs supported. With this increase in CPU capacity, the HC1150D scales out an HC3 cluster to support more compute power across a greater number of VMs. The HC1150D also doubles available RAM configuration up to 512GB per appliance.

Below is a preview of the new configuration ranges and starting pricing for the HC1000 series, including the HC1150D.

Screenshot 2016-12-15 09.07.43

Scale Computing is committed to giving our customers the best virtualization infrastructure on the market and we will keep integrating greater capacity and computing power into our HC3 appliances. Our focus of simplicity, scalability, and availability will continue to drive our innovation to make IT infrastructure more affordable for you. Look for more announcements to come.

Screenshot 2016-07-13 09.34.07

HyperCore v6 – A Closer Look at HC3’s New User Interface

They said it couldn’t be done! Scale has taken the easiest HyperConverged user interface and somehow made it simpler in HyperCore v6. HC3 offers a “set it and forget it” style to IT infrastructure. If we intend for our customers to forget about our product, the user interface has to be extremely intuitive when there is an event that requires an administrator to log in to the system (new VM/workload request, verifying an already “self-healed” hardware failure, etc.).

HyperCore v6 User Interface – Key Features

  • Streamlined workflows for administrators – 60% reduction in clicks during the VM creation workflow. Quicker access to VM consoles directly from Heads up Display (HUD).
  • New Intuitive Design – With the intelligence of HyperCore handling the heavy lifting of VM failover and data redundancy, administrators often employ a “set it and forget it” mentality where it is only required that they log in periodically to make changes to the system. This requires an intuitive interface with almost no learning curve.
  • Improved Responsiveness – The new HyperCore User Interface is extremely responsive with state changes and VM updates immediately accessible in the UI.
  • Tagging / Grouping – Users can now combine VMs into logical groups via tagging. Set multiple tags for easy filtering.
  • Filtering – Spotlight search functionality that filters VMs based on matching names, descriptions, tags for quick and easy access to VMs in larger environments.
  • Cluster Log – A single source for all of the historical activity on the cluster. Filter alerts by type or search for specific key words using the spotlight search to track historical data on the cluster.
  • UI Notification System – Pop up notifications that display in process user actions, alerts and processes present users with relevant information about active events on the system.
  • Unified Snapshot/Cloning/Replication Functionality – Snapshot, cloning and replication functionality are now integrated into the card view of each VM for easy administration.

 

User Interface Demonstrations

Anyone can say that they have a simple user interface, but it doesn’t count unless you can see that simplicity in action. Check out the demonstrations below:

Creating a VM on HC3 – HyperCore v6

Cloning a VM on HC3 – HyperCore v6

Snapshot a VM on HC3 – HyperCore v6

HyperCore v6 – A Closer Look at Built-in Remote Disaster Recovery

As you saw in last week’s press release, Scale Computing’s HC3 now includes VM-level replication as a key new feature in HyperCore v6. Administrators can now setup replication on a per VM basis for integrated remote Disaster Recovery, which builds on the already unique snapshot and cloning functionality built into HyperCore v5. Since the introduction of HyperCore v5, users could manually take near-instant, VM-level snapshots that are easily cloned in an extremely space efficient manner (“thin clones”).

Now in version 6, HyperCore allows users to set up continuous replication to a secondary HC3 cluster, which will automatically take a snapshot on the selected VMs, moving only the unique blocks to the remote site.

Then, to restore on the secondary cluster, simply clone the VM from the latest (or previous) automated or manual snapshot. It makes disaster recovery testing a breeze to be able to spin up these VMs quickly and on their own private network. Of course, if this isn’t a test and your VM at the secondary site is now production, HC3 continues to track the unique blocks that are created and ONLY sends those blocks back to the primary site when its time to fail back.

Replication Highlights:

  • Continuous VM-level Replication – HyperCore makes use of its space efficient snapshot technology to replicate to a secondary site, tracking only the blocks unique to each snapshot and sending the change blocks.
  • Low RPO/RTO – Simply “clone” a snapshot on the target cluster for the manual failover of a VM that is immediately bootable.
  • Simple Disaster Recovery Testing – Testing a DR infrastructure plan is now as simple as cloning a snapshot on the target cluster and starting a VM. No disruption to ongoing replication.
  • Easy Failback after Disaster Recovery – After running a VM at the DR site, simply replicate the changed data back to the primary site for simple failback.

Bring on the Demo!

There is nothing quite like a demonstration of this new technology. In this video you’ll see a number of things….

  1. Remote Connection Setup (0:08) – You’ll see me create a connection from my primary cluster (left) to a secondary cluster (right). Once the clusters are securely connected, I can then enable replication on any VMs between those two clusters.
  2. Replication Setup (0:40) and Initial Replication (1:05) – After cloning a VM, you’ll see me set up replication on that VM to the secondary cluster. The initial replication is time-lapsed, but you’ll see the progress on the snapshot view in on the Primary cluster (left) and after it completes, the clone-able snapshot on the secondary cluster.
  3. Failover Test 1 (1:38) Automated Snasphot – I clone the VM from the snapshot, which is immediately bootable. That’s about as easy as it gets for DR testing!
  4. Failover Test 2 (1:58) Manual Snapshot – After making some changes to the VM (“replication” file on the desktop), I create a manual snapshot. Notice that the blocks unique to that snapshot are tracked separately from the initial replication snapshot (3:32). When I clone from the manual snapshot, you’ll see the “replication” text file appear on the desktop. DR plan tested again!
  5. Failback (4:30) – After making changes to the cloned VM on the secondary site (“Replication – Rollback”), I simply set up replication on the cloned VM back to the primary cluster. Since the majority of the data already exists at the primary site, it takes almost no time for my minor changes to replicate back. Once there, I simply clone the snapshot and I’m back in action on the primary cluster. (Note: Here (5:23) I also disconnect the NIC to spin this VM up without conflicting with my actual production VM…a nice trick for that DR testing!).

HyperCore v5 –A Closer Look at One Click Rolling Upgrades

As noted in a previous post, HyperCore v5 is now Generally Available and shipping on all HC3 node types. In this “A Closer Look…” series of blog posts we’ll be going through the majority of these new features in more detail. Today’s topic…One Click Rolling Upgrades:

  • Non-Disruptive / Rolling Updates ‒ HC3 clusters can be upgraded with no downtime or maintenance window. Workloads are automatically live-migrated across the HC3 appliance to allow for node upgrades, even if such an upgrade requires a node-reboot. Workloads are then returned to the node after the upgrade is complete.

 

Included in HyperCore v5 is our one click rolling upgrade feature…and our customers love it! Customers covered under ScaleCare – our 24×7 support offering that covers both hardware and software – are alerted of HyperCore updates as they become generally available via the user interface. There is nothing more to license when new updates become available, which means that as new features are developed for HyperCore, our current users can take full advantage of them.

When a user kicks off an upgrade, this sets into motion a series of events that updates the nodes in the cluster while keeping the VMs up and running throughout the process. The upgrade starts with a single node by live migrating the VMs from that node to the other nodes in the cluster. Keep in mind that the best practice is to keep enough available resources available to tolerate a node failure in your environment. This same concept holds true for rolling upgrades and users are alerted if they do not meet this condition (and prevented from upgrading if true).

Insufficient Free Memory

After the VMs are live migrated off of the first node, the full OS stack is updated, rebooting the node if required. Once that node is brought back online and has rejoined the cluster, the VMs are then returned to their original position and the upgrade process moves on to node 2 repeating the process. This continues through each node in the cluster until the system in its entirety is running the latest code. No VM downtime, no maintenance window required.

 

HyperConvergence for the SMB

Scott D. Lowe authored a fantastic article on HyperConverged.org last week that focused on where HyperConvergence is NOT a fit.  It is not an angle you hear often from a proponent of HyperConvergence and I have to admit…I like it.

At Scale, we have a laser-like focus on serving the IT infrastructure needs of small-to-medium sized businesses.  Similar to Scott Lowe’s approach in his article, it is as important to define our target customer as it is to define who is NOT our target customer.  When it comes down to it, a large company who has IT employees that specialize in every component in the infrastructure (think SAN or network admin, etc.) may never fully appreciate the simplicity of HC3 or may even be somewhat threatened by it. Continue reading

The King is Dead. Long Live the King!

With a title like Death by 1,000 cuts: Mainstream storage array supplies are bleeding, I couldn’t help but read Chris Mellor’s article on the decline of traditional storage arrays.  It starts off just as strong with:

Great beasts can be killed by a 1,000 cuts, bleeding to death from the myriad slashes in their bodies – none of which, on their own, is a killer. And this, it seems, is the way things are going for big-brand storage arrays, as upstarts slice away at the market…

And his reasons as to why are spot on from what we have seen in our target customer segment for HC3.

the classic storage array was under attack because it was becoming too limiting, complex and expensive for more and more use-cases.

Looking at our own use-case for HC3, storage array adoption for our target segment (the SMB) rose with the demand for virtualization, providing shared storage for things like live migration and failover of VMs.  It was a necessary evil to know that critical workloads weren’t going to go down for days or even weeks in the event of a hardware failure. Continue reading

Video: How to Add Resources to HC3

With an infrastructure refresh on the horizon, a common question asked in IT used to be:

“What should I buy today that will meet my storage demand over the next X years?”

Historically, that is because IT groups needed to purchase today what they would need 3-5 years from now in order to push out a painful forklift upgrade that would inevitably come with reaching max capacity in a monolithic storage array.  After the introduction of “scale-out” storage (where you were no longer locked into the capacity limitations of a single physical storage array), the question then became:

“What should I buy today that will meet grow alongside my storage demand over the next X years?”

This meant that customers could buy what they needed for storage today knowing that they could add to their environment to scale-out the storage capacity and performance down the road.  There were no forklift upgrades or data migrations to deal with.  Instead, it offered the seamless scaling of storage resources to match the needs of the business.

Now with hyperconverged solutions like HC3 where the scale-out architecture allows users to easily add nodes to infrastructure to scale out both the compute and storage, the question has changed yet again.  Hyperconverged customers now ask themselves:

“What should I buy today that will meet grow alongside my storage infrastructure demand over the next X years?”

Adding nodes to HC3 is simple.  After racking and plugging in power/networking, users simply assign an IP address and initialize the node.  HyperCore (HC3’s ultra-easy software) then takes over from there seamlessly aggregating the resources of that node in with the rest of the HC3 cluster.  There is no disruption to the running VMs.  In fact, the newly added spindles are immediately available to the running VMs giving an immediate performance boost with each node added to the cluster.  Check out the demo below to see HC3’s scalability in action!

 

 

SMB IT Challenges

There was a recent article that focused on the benefits that city, state and local governments have gained from implementing HyperConvergence (Side Note: for anyone interested in joining, it was brought to my attention on a new HyperConvergence group on LinkedIn where such articles are being posted and discussed).  The benefits cited in the article were:

  • Ease of management,
  • Fault tolerance,
  • Redundancy, and late in the article…
  • Scalability.

I’m sure it isn’t surprising given our core messaging around Scale’s HC3 (Simplicity, High Availability and Scalability), but I agree wholeheartedly with the assessment.

It occurred to me that the writer literally could have picked any industry and the same story could have been told.  When the IT Director from Cochise County, AZ says:

“I’ve seen an uptick in hardware failures that are directly related to our aging servers”,

It could just as easily have been the Director of IT at the manufacturing company down the street.  Or when the City of Brighton, Colorado’s Assistant Director of IT is quoted as saying,

“The demand (for storage and compute resources) kept growing and IT had to grow along with it”,

That could have come out of the mouth of just about any of the customers I talk to each week. Continue reading

Hypervisor Converged – Definitions Diverged

I read a recent blog post from VMware’s Chuck Hollis that attempted to define and compare the terms Converged Infrastructure vs. Hyper-Converged and Hypervisor-Converged Infrastructure.

As is usually the case, I thought Chuck did a great job cutting through vendor marketing to the key points and differences, beginning with his quote that “Simple is the new killer app in enterprise IT infrastructure.”  And we would echo that is even more true in the mid-sized and smaller IT shops that we focus on.

But eventually vendor biases do surface. Especially in an organization like VMware with many kinds of partners and a parent company with a hardware centric legacy. That’s not a bad thing, and I’m sure I will show my vendor bias as well.  At Scale Computing we focus exclusively on mid-size to small IT shops and are therefore biased to view the world of technology through their eyes.

As background, we would consider our HC3 products to be “hypervisor converged infrastructure” as our storage functionality is built in to the hypervisor which are both run in a single software OS kernel. I would consider hypervisor-converged to be a specific case or sub-set of hyper-converged, which simply means you have removed an external storage device and moved the physical disks into your compute hosts which also run the hypervisor code. (how the hypervisor gets to those disks is the difference in manageability, performance, complexity – see Craig Theriac’s blog series – The Infrastructure Convergence Continuum ) Continue reading