Announcing a Modern, Open-Source-Based, Private Cloud Solution

Last week, at Red Hat Summit 2019, we announced a new solution developed in conjunction with Red Hat: NetApp® HCI for Private Cloud with Red Hat. It’s a really exciting solution because it delivers a modern, open-source-based, true cloud on premises to enable modern agile software DevOps activities. Plus, because it’s based on NetApp HCI, it actually works at enterprise scale, with real performance, delivered predictably and consistently. This solution, nicely packaged as a NetApp Verified Architecture, is production-grade cloud for the enterprise. It takes advantage of the full TripleO-based deployment of the Red Hat OpenStack Platform with OpenShift running on top of that to facilitate cloud-native workloads.

There was much interest and excitement about this announcement at Red Hat Summit. I had many a conversation with people who had tried to implement a private cloud, with varying levels of success, on a full open-source stack with software-defined storage. From the people I spoke with, it seemed like one of the main stumbling blocks was getting block storage right. (No pun intended!) Sure, they could get it to “work,” but there’s a big difference between a lab setting and a production-grade cloud. With scale, a bunch of things tend to fall down. First of all, the ongoing work necessary to keep the software-defined storage going as things scale, adding nodes and so forth to support growth, can become onerous, depending on the architecture used. Even more painful, however, is what happens to performance at scale—not only the raw aggregated performance, but the predictability of performance per workload as more workloads get deployed on the cloud. This typically is a big problem in building a large-scale, production-capable private cloud.

The promise of our new solution, based on NetApp HCI, is that it solves just this problem. Judging from Red Hat Summit, people already seem to see it. You get easily scalable block storage and automated deployment for both compute and storage—but, unlike many HCI solutions, you have actual guaranteed performance at scale. I’m excited to see NetApp partnering so closely with Red Hat to bring a real end-to-end solution to market that can be readily deployed, solve for the cloud pieces we all need to bring to our organizations, and also perform at scale for production workloads.

Protect and Restore SQL Server Resources Across vCenter Server with SnapCenter

Many enterprises set up multiple vCenter Server to manage virtual machines (VMs). System administrators take this approach to isolate the ESXi host for production servers from the host for nonproduction servers or to manage different domains. They might even set up vCenter Server in different data centers.

Therefore, one overarching question that can come up for any IT generalist or backup administrator is whether a single backup product can manage backups across all vCenter Server.

Another question is whether database resources can be cloned or restored onto a different VM that resides in a different vCenter Server. If so, do administrators have to script a complex Windows PowerShell cmdlet, or do they have to use NetApp OnCommand® Workflow Automation to execute the task? And can SnapCenter support different domains or even different workgroups?

All these questions are valid. And I think that you will like the answers. Starting with version 4.1, SnapCenter now gives you support for multiple domains and workgroups. SnapCenter can also discover your database resources across different vCenter Server instance, even if your instances are in different domains. And with centralized management, you can easily clone and restore across locations.

SnapCenter in Action

To clone and restore, you use SnapCenter similar to the way that you clone and restore on any VM connected to a vCenter Server. And it works for physical logical unit numbers (LUNs) and virtual disks.

Let’s take an example with two separate ESXi hosts with the following setup:

• Each host is managed by a separate vCenter Server. ESXi Host A consists of production VMs, and ESXi Host B consists of nonproduction and noncritical VMs.
• Each ESXi server is connected to a separate storage controller to host Virtual Machine Disk (VMDK) files.
• Production servers are part of the domain controller, and nonproduction servers run in a workgroup environment.

In this example, you add vCenter Server host and push SnapCenter Plug-In for VMware vSphere to vCenter Server. You also add SQL Server hosts by pushing SnapCenter Plug-In for Microsoft SQL Server.

With those few steps, a single SnapCenter Server instance can manage data protection of your resources on VMs across different vCenter Server instances. It’s that easy.

Following are two use cases that we tested. In case 1, cloning and restore are performed by using the NetApp Snapshot™ copy that is available on the primary controller. In case 2, a NetApp SnapMirror® or SnapVault® Snapshot copy on the secondary controller is used.

Case 1: Clone and restore a database by using the Snapshot copy on the primary controller.

Case 2: Clone and restore a database by using a SnapMirror or SnapVault Snapshot copy on the secondary controller.

Both of our test scenarios succeeded and were supported. In our setup, the vCenter Server version varied. On Host A, we used vCenter Server 6.7, and on Host B, we used vCenter Server 6.5. The test was conducted with limited considerations, so it is a best practice to test the scenario before you implement it in a production instance.

Before you clone or restore with SnapCenter, you must follow these steps:

1. Create an initiator group for the ESXi host and for the guest VM. You can create the initiator group for the guest VM from SnapCenter.
2. Establish a connection between the ESXi host and the storage controller.
3. Establish a connection between the guest VM and the storage controller from SnapCenter.
4. Make sure that you can ping the storage virtual machine (SVM) short name from the guest host.