Featuring guest bloggerRahul Talekar, Solutions Architect for Cisco UCS solutions. Rahul's blog describes the best case scenerio for adding a node to an existing Azure Stack configuration- best case when deployed with Cisco UCS.

Since inception Cisco Unified Computing System was developed with policy based infrastructure automation in mind. Using built-in Infrastructure automation policies, Cisco rack servers can move from loading dock in to production in "plug-and-play" fashion. Servers can be configured automatically using predefined policies by simply connecting the servers to UCS top-of-rack Fabric Extenders and Fabric Interconnects. Because policies make configuration automated and repeatable, configuring 100 new servers is as straightforward as configuring one server, delivering agile, cost-effective scaling.

In this blog I will talk about the UCS infrastructure policies used for the Cisco Integrated System for Azure Stack, and specifically how it simplifies the Azure Stack add node capability, announced by Microsoft last month. The following UCS manager screenshot shows just some of the built in UCS infrastructure policies that Cisco UCS customers can use.  This policies can be set from the UCS manager user interface or using UCS API.

During the installation of every Cisco Azure Stack system, Cisco automation tools define the policies required for Azure Stack infrastructure on the UCS. And every homogenous server added to the existing Azure Stack installation is automatically configured according to the pre-defined UCS Azure Stack policies. This is a core value and benefit of UCS.

To add a new server into an existing azure stack cluster, an Azure Stack administrator simply connects the new server/servers into the UCS fabric interconnects, the Cisco Nexus fabric extenders and power and then lets UCS associate the appropriate service profile. Once the newly added server has the service profile associated, all the Azure Stack administrator has to do is to note the BMC IP on the service profile and provide it in the Azure Stack add node wizard and start the add node operation from the Azure Stack admin portal.

Now the interesting part.

The following section describes how different conditions allows the pre-defined policies to trigger the different operations that automatically prepares the new server for Azure Stack consumption:

• When a new server is connected to the UCS Fabric Interconnects and Fabric Extender, theUCS Rack Server Discovery Policyis triggered which starts the server discovery operation.
• Once the Server is fully discovered and if it has the matching hardware to the other servers in the rack, then theUCS Server Pool Qualification policyis triggered. This policy adds the newly discovered server into theUCS server poolcreated for the Azure Stack

• When an unassociated server is available in the UCS server pool, theUCS Server Autoconfig Policyis triggered. This policy automatically creates aUCS Service Profilefrom the Azure Stack specificUCS Service Profile Templateand associate it to the server.

Note: Cisco automation tools creates theAzure Stack specific UCS service profile template on the UCS servers during the initial installation of Azure Stack.

• During the service profile association along with the assignment of the uniqueBMC IP address different Azure Stack related UCS policies are automatically applied to the server. I would like to highlight two succinct policies that manages the  BIOS configuration and firmware upgrade required for the Azure Stack add node operation:
  1. Host firmware policy: This policy makes sure that all the servers in the Azure Stack cluster have the same firmware for every server component. If this policy detects different firmware on the newly added server, then it updates the server firmware to ensure that it has firmware similar to the other servers in the cluster.
  2. BIOS policy: This policy ensures that the BIOS of every server in the Azure Stack cluster has the same Microsoft recommended BIOS settings. This policy configures the Microsoft recommended BIOS settings for the newly added server.

Remember, this policy based automatic server configuration isunique to Cisco UCS and no other server vendor has similar capability. Only Cisco provides these outlined polices. None of these policies were specifically developed for Azure Stack; they are standard operation for Cisco UCS and are available out-of-the box with Cisco UCS. For Azure Stack, we only need to set and configure specific policies applicable to Azure Stack requirements.

With policy based automation, Cisco Azure Stack server addition operation is a "plug-and-play" approach and customers can perform it themselves without the need for a service engagement with Cisco. This is the reason why Cisco supports node addition one node at a time. Most of the other server vendors require service engagement to perform server addition operation and they will sell servers in the pack of 4 servers to keep the cost of service engagement low.

For more information, please visit https://www.cisco.com/go/microsoft-azure-stack

.