VCF on Dell EMC VxRail – Creating a VxRail VI Workload Domain

By Victor Wu on 2019 年 05 月 11 日 • ( Leave a comment )

In this demo, we are going to walk through creating a VxRail Virtual Infrastructure (VxRail VI) Workload Domain. Click on the Workload Domains menu to the left.

Click the View Details link to continue.

Let’s add a VxRail VI Workload Domain. Click the + Workload Domain button at the top right of the screen to continue.

Click on the VI-VxRail Virtual Infrastructure Setup menu item to continue.

We are now launched into the VxRail VI Configuration wizard. The first step is to provide the Workload Domain and Organization Name. Click the VI Workload Domain Name text line to enter in a Domain and Organization name.

In the first phase of VxRail VI Workload Domain creation, SDDC Manager will create a Workload Domain construct and deploy a vCenter that will be used to manage it.

VxRail has the ability to be deployed as a self managed standalone cluster or into an existing vCenter managed VMware environment. The latter is exactly the way we will deploy VxRail for our Workload Domain. At this step, we need to complete the information for the vCenter. Click the Next button to continue.

Here we see a summary of the information that has been entered. It all looks correct. Click the Finish button to begin the Workload Domain creation and vCenter deployment workflow.

We can view the list of tasks SDDC Manager is performing and their associated completion status in the Tasks pane. SDDC Manager has successfully completed all tasks. Click on the X icon at the top right corner to continue.

You can now see the new Workload Domain (WLD1) has been created. It is currently in an Activating state. This is because we don’t have any VxRail clusters in it yet. Let’s take a look in the Management Domain vCenter to see the WLD1 vCenter that SDDC Manager deployed.

Looks like the vCenter was deployed successfully onto the Management Domain cluster. Click on the rack1-vc-2 VM to view its details.

Now that our Workload Domain construct has been created and the vCenter that is used to manage it deployed successfully, it is time to run through the native VxRail cluster deployment process so that we can add it to the Workload Domain.

Click on the browser address bar to access the VxRail Manager Deployment Wizard console.

Another advantage of the Cloud Foundation on VxRail integration between SDDC Manager and VxRail Manager, is the fact that we can leverage the same native VxRail administrative processes for a Cloud Foundation use case, that could be used for any other VxRail standalone use case.

Let’s walk through the native VxRail deployment process here. Click on the Get Started button to begin.

Click the Accept button to accept the EULA and continue.

We will be deploying a VxRail cluster configuration here. Leave the radio button selected and click on the Next button to continue.

VxRail Manager has discovered 3 appliances that we can use to create our cluster. Check the box confirming that all three appliances should be configured. Click the Next button to continue.

To speed up deployment, we will select to upload a configuration file to pre-populate all of the required parameter fields needed for deployment. Click the Configuration File radio button to continue. Click the Next button to select the configuration file.

We now see all the fields populated. We will now walk through the remaining steps. Here we are choosing to deploy VxRail using 2 of the 4 NIC ports that should be physically installed on every node.

Cloud Foundation on VxRail supports using 10GbE or 25GbE host networking connections. Click the Next button to continue.

Here we see all of the pre-populated host and domain information. Click on the scroll bar to view more pre-populated configuration information.

We are attaching the vCenter that SDDC Manager has already deployed as part of the Create VxRail VI Workload Domain workflow. See how the Cloud Foundation process flow compliments the native VxRail experience? This is by design as part of the co-engineering built into Cloud Foundation on VxRail. Click the Next button to continue.

With Cloud Foundation on VxRail, the network pools are managed by VxRail Manager that reside on each cluster. IP addresses for the various required networks will be entered and managed as part of VxRail Manager cluster administration.

Here is what we have entered for the vSphere vMotion network for the cluster. Click the Next button to continue.

Here is the IP address and VLAN configuration for the vSAN network. Click the Next button to continue.

VxRail Manager can configure one or more VM networks for the cluster at cluster deployment.

Here we see only one configured. Click the Next button to continue.

As part of a VxRail deployment, VxRail Manager has the ability to deploy a vRealize Log Insight instance that is used for standalone cluster use cases.

Since SDDC Manager already has deployed this and we will be using VxRail as part of a Cloud Foundation environment, we will be selecting the None option here. Click the Next button to continue.

In this step we see all of the necessary account credentials for the cluster. Click the Next button to continue.

Click the Validate button to Validate all of our information was entered correctly. This will take a few moments.

The validation successfully completed. Now it’s time to build the VxRail cluster.

Click the Build VxRail button to continue to the build console.

Click on the Start Configuration button to begin the deployment workflow.

Hooray! The VxRail build has successfully completed. Click on the Manage VxRail button to launch the vCenter HTML5 console where all VxRail Manager management activities are performed using the new vCenter Plugin.

You can now see a new vCenter listed with a new DataCenter object contained underneath it. Click on the VxRail-Datacenter hash to expose the new VxRail cluster.

Here we see the 3 node VxRail cluster that was just built. Notice that a dedicated VxRail Manager VM is up and running. Each VxRail cluster deployed will have its own VxRail Manager VM that is responsible for its cluster management.

All VxRail clusters are configured with vSAN as its primary storage for running workloads.

Now that we have seen what VxRail Manager has configured for a native VxRail cluster deployment. It’s time to add the cluster to the VxRail VI Workload Domain.

Click on the browser address bar to launch the SDDC Manager console. Select the WLD1 link to bring up this Workload Domain’s dashboard screen.

The WLD1 Workload Domain dashboard screen does not have any information in it yet since the Workload Domain is still empty. Click on the Actions menu to launch the Add VxRail cluster menu.

Click on the Add VxRail Cluster menu option to continue.

The first step is to associate the VxRail Manager running on the VxRail cluster that will be added with SDDC Manager so it can discover the cluster and perform the cluster operations needed to add it to the Workload Domain.

Click the Next Button to continue.

Once SDDC Manager discovers the hosts, you need to enter in the SSH password for each host in order so SDDC Manager can use it for communicating to the hosts.

Click on the SSH Password text line for the first host to enter in the password. Click the Next button to continue.

To compliment what is already included and configured in VxRail, SDDC Manager will automatically deploy and configure the remaining portions of the Cloud Foundation software stack, including the NSX components.

This is the first cluster being added to the Workload Domain, therefore, no NSX Manager has been deployed yet. SDDC Manager will deploy it as part of the “Add Cluster” process, along with installing the NSX VIBs on each host.

Any subsequent clusters that are added to the Workload Domain will not require another NSX Manager instance. Only the NSX VIBs will be installed on each host in that cluster.

Complete the necessary NSX information here. Click the text line to enter the required VXLAN ID details.

Click on the 1st NSX Controller IP Address text line to enter in the remaining NSX details. Click the Next button to continue.

We will enter the required NSX and vSAN license keys. The keys were included in our original Cloud Builder configuration file so these fields have been pre-populated. Click the Next button to continue.

Review the information entered here. Everything looks correct.

Click the Finish button to begin the SDDC Manager Add VxRail Cluster to Workload Domain workflow.

You can view and monitor the status of the tasks SDDC Manager is performing for the workflow in the Tasks Pane.

The Add VxRail Primary Cluster workflow task is now in the running state.

All tasks have successfully completed. Click the X to close the Tasks Pane window.

You can now see that the WLD1 status is Active; it contains 1 cluster and 3 hosts.

Here on the Hosts menu, we see details about the hosts currently in the Workload Domain.

Let’s take a look at the Workload Domain Cluster Details following the completion of the workflow from the vCenter level to see what additional items were configured by SDDC Manager.

Click the browser address bar to launch the vCenter console.

Each vCenter deployed in Cloud Foundation will be deployed in Enhanced Linked Mode. This allows for a Cloud Foundation administrator to have global visibility into all Workload Domain infrastructure. By having each Workload Domain be managed by its own vCenter and NSX Manager, this also gives the administrator flexibility to establish different security and configuration policies for each Workload Domain based on business or workload needs that are independent of one another.

Click on the Linked vCenter Server Systems menu to continue.

Here we see that the WLD1 vCenter has been linked to the Management Domain vCenter. This is also why we are able to see all vCenters and their respective clusters in one vCenter view. Click on the Extensions menu to continue.

Here we see the datastores that have been configured on the cluster. The primary storage for all VxRail VI Workload Domains is vSAN.

Let’s now take a look at the NSX configuration that SDDC Manager automatically performed during the Add VxRail Cluster operation. Click on the Menu toolbar menu to continue.

On this dashboard screen, you will notice the default NSX Manager is 192.1.0.38. This is the NSX Manager for the Management Domain. Select the 192.1.0.38 Standalone link to bring up a menu for all NSX Managers deployed.

We can now see that a new NSX Manager with an IP address of 192.1.0.39 has been successfully deployed and configured.

The dashboard contents shown are for the NSX Manager instance deployed for our WLD1 VxRail VI Workload Domain.

The last item to highlight is the ability to effortlessly enable centralized logging for the VxRail cluster that was just added to the new Workload Domain.

Optionally, vRealize Log Insight can be licensed to collect and analyze logs from VxRail VI Workload Domain components and workloads running in them.

We can enable SDDC Manager to automatically configure the hosts on all VxRail VI Workload Domains and have their logs collected from within the SDDC Manager’s UI.

Click the Administration menu to expand it.

Click the vRealize Suite menu to continue.

The vRealize Suite menu provides the option to manage the deployment, and access the vRealize components used for cloud management and operations.

This is where we access the vRealize Log Insight configuration screen and have the option enable log collection for VxRail VI Workload Domains.

Click the Enable button to have SDDC Manager run a workflow to enable log collection on the hosts in our new WLD1 Workload domain.

Let’s take a look at the results of the SDDC Manager configuration. Log into the Log Insight instance by clicking on the vRealize Log Insight link at the top of the screen.

Click the menu icon in the top right corner to bring up the settings menu options. Select Administration to continue.

Click the Hosts menu to view a list of hosts and components currently enabled for log collection.

You can now see, along with all of the Management Domain hosts and components, that the hosts and components for WLD1 are now having their logs collected by Log Insight.

This concludes this demonstration.