Author: javirodz

In this post, we are going to create a VLAN in the UCS Manager, but we are going to use the latest HTML5 version. So let’s get started bu logging into the UCS Manager URL. Once there browse to the LAN tab, in the case of the new GUI shown here, the third icon on the left (counting from the top).

 

Then browse to the VLANs section inside the LAN cloud. Remember to stay on the general LAN cloud instead that on inside the Fabric A or B.

Now click the Add button in the top-right pane. The Create VLANs pop-up windows appeared, then choose a name (VLAN_704 in this case) and set the VLAN ID (704 in this case). Click OK

That is all for this post, the VLANs are used within the vNIC templates to pass the network communication from outside the UCS environment. Next time I will show you how to create Policies.

This is a quick reference to the commands used to configure the zoning in NX-OS. This is an existing setup, the switches should be initialized and at the recommended NX-OS level. Connect to the FC Switch using PuTTY and configure it using the following examples. Here I am using fcalias, but devalias is an option too. There are a couple of differences, fcalias is VSAN specific while devalias are not.

show fcalias
show zone
show zoneset active

show flogi database
show fcns database

FCALIAS
conf t
fcalias name <alias name> vsan 1
member pwwn <wwpn>
end

ZONE
conf t
zone name <zonename> vsan 1
member fcalias <fcaliasname>
member fcalias <fcaliasname>
end

ZONESET
conf t
zoneset name <name> vsan 1
member <zonename>

end

ACTIVATE ZONESET
conf t
zoneset activate name <active zoneset name> vsan 1
end

SAVE
copy running-config startup-config

This is part of a series of posts on how to initially configure you UCS B-Series system using UCS manager. With the information in this post, you will be able to configure the vHBAs needed for FC connectivity. Check the other posts under the Cisco section in my blog. If you are using iSCSI you can skip this step of the UCS B-Series configuration.

To start login into your UCS Manager, select the SAN Tab and Navigate to the Pool section. Right click on WWNN and click Create WWNN Pool

Give it a name, select Sequential and clock Next.

Now add the value for the WWNN, first click add then fill the quantity (in this case 16) and cick Ok and Finish.

The WWPN pool creation process is analog to the one just described, but chage one of the its on the WWN window (see below)

That’s it for this post, I am trying to keep them short to keep them coming. On the next post, I will show how to create a VLAN.

 

Now that we have our system up to date with the latest software, we can start configuring the different templates, pools, and policies. The UCS is a stateless system, meaning that you will be able to abstract all the usual properties (UUID, MAC Address, etc…) into a Service Profile and apply those to any compatible hardware.

• Create a Sub-Organization:  this step is recommended for multitenant implementations, it doesn’t hurt to make it the standard installation procedure. Right-Click on Sub-Organization to open the Create Organization window.

• Create the UUID Pool: select the Server Tab, select Pools from the drop down menu, expand the Sub-Organizations and expand the new Sub-Organization (in this case Sub-Org-01). Select the UUID Suffix Pools and click Add.

• Type in a name and select Sequential, then click Next

• Click Add to define the value

• Change one digit to make it unique and add in a decent size to configure it once and forget about it. the click Finish and click OK in the resulting pop-up window.

• Create an IP address pool: this pool will be used to connect to the KVM for console access. First, navigate to the LAN tab and select Pools from the drop down menu, then under the Sub-Organization (Sub-Org-01 in this case) right click and select Create IP Pool.

• Give at name, select Sequential and click Next

• Click Add to define the IP address block.

• Setup the IP address block information, you can do as many as you want, you can always add later, I usually configure one for each blade at the very beginning ad forget about it.

• As a final step, click Next and then click Finish (assuming you won’t use IPv6).

• Create a Server Pool: from the Servers tab, navigate to the Sub-Organization and with a right-click select Create Server Pool. Once there type in a name for the pool and click Next.

• Select the blades and servers from the left pane and add them to the Pooled Servers pane, and click Finish.

• Create the MAC Address Pools: We could use the default pool, or we can get very creative with this, especially if you are using VMware or any other host with multiple vNICs. The trick here is to Identify the FI, chassis, site, etc.

The MAC address is going to be of the format 00:25:B5:00:00:00, the first part
(00:25:B5) is the Organizationally Unique Identifier (OUI) and the second part
(00:00:00) id the Device ID, and the second part is the one that we customize.

Is with the second part that we will get creative. Use it to identify the site and FI, and I go even further and if the deployment is small I also identify the vSwitch. For example 00:25:B5:1A:00:00 could be Site 1, FI A, vSwitch 0, and the last three places are for sequential values. Check the following image with a few MAC Pools.

 

In the previous image, you can see separate sets for management, vMotion, iSCSI, and VM traffic. You don’t have to do it exactly as I have it there, maybe you want to use the same vSwitch for management and vMotion, then you could designate one place as the vmk# for example. The next slideshow has the MAC Pool creation process.

 

I am going to submit this post the way I have it up to this point and then release the next steps including:

Create WWNN and WWPN pools (if you are using FC).

Create VLANs.

Create Policies.

Create vNIC and vHBA templates.

Create a Service Profile Template.

Deploy Service Profiles from the Service Profile Template.

Configure Especial Cases like Layer-2 Disjoint Networks

As part of the service portfolio at ABS Technology, we offer Data Center migrations. There are multiple technologies to achieve the data replication necessary in a migration. There are two main levels, host-level replication, and array level replication. With host replication, the granularity is a single operating system instance, it can be physical or virtual. You can use technologies like the vSphere Replication Appliance, Recoverpoint for VM’s, VEEAM, ZERTO, or Double-Take. All of these differ and the use of one vs the other will depend on a number of factors like RPO/RTO, budget, standardization policy, etc.

When it comes to array replication, you will have as many flavors as array vendors, but the two types are Asynchronous and Synchronous, again the selection of technology will depend on the requirements.

In this post, I will summarize what is needed for a migration from one Data Center to another of an environment using a UCS B-Series, a Nimble Storage Array, and vSphere.

In the Nimble storage array, the replication can be done over the Data subnet or the management subnet. If the array has a free NIC, you can configure it for data, but use it only for replication. this last case is the one I will be documenting here.

The first step is to configure the subnet in the Nimble Storage. I will user the network 10.10.10.0/24 as an example, with a discovery IP of 10.10.10.50 and an IP address of 10.10.10.51. The discovery IP will not be used because we will only use this subnet for replication purposes.

Figure 1. From the Administration main menu, select Network Configuration.

Figure 2. Click on Active Settings

Figure 3. Click the Subnets tab and then click the Edit button.

Figure 4. Then click the Add  button

Figure 5. Click Done to finish.

As a final step, you can save the new configuration in the active settings by clicking the Update button, or save it as a draft to be applied later by selecting the Save as Draft button.

The next step is to configure the replication partner. You will need the nimble Group Name of each storage array, the hostname or IP address and a password to use as a shared secret.

In the next four images, we will navigate through the process of setting the replication partner. First, log in the Nimble and from the menu select Manage->Protection->Replication Partners.

Figure 6. From the menu select Manage->Protection->Replication Partners.

Figure 7. Click on the New Replication Partner button.

Figure 8. Input the information, in our case select the newly created network from the drop down menu as a Replication Network (see Figure 5 above).

Figure 9. Create an optional QoS policy and click Finish.

In the following slideshow, I configure the Volume Collection. The Volume Collection contains all the volumes that will replicate at the same time. At the end, you can see the way I would monitor the replication.

This slideshow requires JavaScript.

Now that everything is replicating, wait for it to be synchronized and it’s time to migrate. There can be multiple ways to do this, you could clone a replica and chose the VM’s you want to migrate, or you could “Handover” the complete volume collection.

Option one: Create clone of the replica.

In this case, the pre-requisite is to stop I/O on the source VM, Datastore, or Volume collection. Do this to have a crash consistent copy of the source. After you stop the I/O, wait for the last replica to happen and now in the destination array, clone the volume replica snapshot and put it online. Then configure the cloned Volume for Host access. If you are satisfied with your VM, I would suggest a storage vMotion of that VM to another DS not involved in the replication and remove the clone. Just to keep things clean.

Option two: Handover the Volume Collection.

Before you click on that Handover button, make sure you shutdown your VMs and unmount the Datastores (don’t delete them!). In the case of a migration to a new set of hosts without replication back, remove the old hosts access to the volumes and rescan to remove dead paths.