Mar 232012
 

Within Cisco UCS there are multiple pools which can be configured. Those pools will help you to create simplicity in your configuration as well as stateless computing. Those two are IMHO the biggest advantages of using such pools. But this is not all. You can also automatically deploy certain service profiles which are associated with a server pool. So let’s take a closer look which pools are available and there usage for it.

MAC pools

Within a MAC pool you can create your own list of MAC addresses. Each system will get, depending on your vNIC template configuration, a MAC address from a MAC pool. You can configure one global for the complete environment or multiple MAC pools. Although the choice is yours I would suggest to create at least one MAC pool on each Fabric Interconnect. One of the advantages of this is that when there are certain issues in the environment you can easily locate via which Fabric Interconnect the traffic comes from.

When creating a a MAC pool, use a convenient naming convention which fits with you. For example “Fabric-A”

image

When creating a MAC pool make sure you have enough addresses. Personally I like to think in blocks of 16 addresses. Also I suggest to use the default prefix if possible. The 00:25:B5 is reserved for Cisco UCS and it will usually give you plenty of MAC addresses for now and in the future. However if you really need to, you can change the prefix. So, when creating 2 MAC pools it would look like this.

image

In this case I created a MAC pool for Fabric A and a MAC pool for Fabric B. Also notice that I changed the 4th octet for the Fabric-B MAC pool. You can choose any you like, so just see this as an example. Both MAC pools have 256 MAC addresses available. If you are able to calculate in HEX you probably noticed it already.

WWNN Pools

Each system connected to the Fabric Interconnects (either Cisco B series or C series) can also make use of virtual HBAs or vBHA. A vHBA is used for Fibre Channel traffic. When using Fibre Channel each system will receive a WWNN or a World Wide Node Name. This is necessary to determine which ports belong to a common multiport device in the Fibre Channel network, however its not used for communication or zoning. An example of multiport devices are servers with several Fibre Channel host bus adapter cards. WWNNs could also be used to realize services such as striping over several redundant physical paths within the Fibre Channel protocol. Since a WWNN is necessary for each system you should create a block (or multiple blocks within a pool) big enough for each system.

An example of such WWNN pool:

image

WWPN Pools

Each vHBA needs also a WWPN or a World Wide Port Name as seen as below.

image

Each vHBA uses one WWPN which is being used for communications to the storage array. A WWPN should be unique on a Fibre channel network. Using this WWPN you can create zoning on a storage switch, like a Cisco MDS, and be able to configure LUN masking on a storage device. A nice article about zoning (either soft and hard zoning) can be found here.

UUID Pools

Let’s start what a UUID is. A UUID stands for Universally Unique IDentifier and it’s defined in the RFC 4122. A UUID are applied for identification purposes. For example, Linux Grub can use the UUID to identify the root partition of the operating system. UUID is truly a unique identification method.

So since Cisco UCS is in principle meant as stateless model it’s important that this is configurable within Cisco UCS. Therefore you are able to create a UUID pool.  Each Service profile extracts its UUID information from a UUID Pool. When creating the pool you get the option to set your own prefix or used a Derived prefix. A derived prefix will generate a prefix for the UUID pool uniquely for the UCS domain. However if you have a certain need for it you can choose other.

image

Server Pools

A server pool is as the names suggest, a pool of servers or a set of servers. These servers typically share the same characteristics. Those characteristics can be their location in the chassis, or an attribute such as server type, amount of memory,local storage, type of CPU, or local drive configuration.

One of those advantages is that you can assign a service profile template on a Server Pool. When deploying service profiles, servers in this pool will automatically receive a service profile.
For example you would like to create a pool of webservers and a pool database servers. The pool of database servers might have have more memory and / or more CPUs. If you assign the templates to server pool and you add the servers to the pool, the servers will automatically get the correct service profiles. This also make it easy when extending the environment when needed. For example you can pre-provision the service profiles while someone else place the blades in the datacenter.

An example of such a server pool:

image

There are 2 methods to populate the server pools, either manual populated or auto-populated.

  • Manual is where you select the blades and add them to a certain pool.
  • Auto-populated is where the server pool is populated due to Server Pool Qualifications and Server Pool Policies. Within the Server Pool Qualifications you define the certain hardware characteristics and the Server Pool Policy defines which Qualifications applies to which Server Pool.

However, keep in mind that a blade can be in multiple pools at the same time. Whichever profile "claims" a particular blade is its current "owner," regardless of the number of pools it is in.

I hope this will give you a basic understanding about the different pools and there usages within Cisco UCS. There is much more in UCS then this but I hoped you enjoyed this topic.

Mar 112012
 

In this post I will try to explain what a service profile template is within Cisco UCS. However to start with the basics let’s start with a service profile. I assume you are aware of the Cisco UCS Emulator. if not you can download it from here using your CCO account: http://developer.cisco.com/web/unifiedcomputing/home

So what is a service profile within Cisco UCS?
A service profile defines a single server and its storage and networking characteristics and are stored in the Cisco UCS Fabric Interconnects. Each server connected to the Fabric Interconnects are specified with a service profile. The advantage of service profiles are mainly automation of your physical hardware configuration like BIOS settings, firmware levels, network interface cards (NICs), host bus adapters (HBAs) etcetera.

So a service profile is a logical representation of a server; they include:

  • Identity – UUID, MAC addresses for each Virtual NIC (vNIC), WWN for each virtual HBA (vHBA), etc.
  • Configuration – server requirements, boot order, firmware, etc.
  • Connectivity – VLAN, VSAN, QoS, etc.

When you create a service profile, you can tell the profile to pull the MAC addresses from a pool as well as the UUID, WWN, etc. You can define where you want the profile to boot from (i.e. on the SAN or local disk) and you can define which firmware to load depending on the NIC, disk, etc. You can also set the VLAN and VSAN information to setup connectivity to the LAN and SAN networks. Each server has a service profile, one and only one profile, associated with it.

So what is a service profile template then?
A service profile template consists out of the same settings as a regular service profile however if you are somewhat familiar with virtualization you understand the template part. The template cannot be associated to any server yet it can be associated to a server pool. There are 2 template types; Initial and Updating. The difference between those two template types is that the initial template create standalone service profiles where as the updating template has a relationship with it’s service profiles. So when making changes to the updating template it will be propagated to all it’s service profiles. This will not be the case with initial templates.

Or explained from the Cisco Website:

The real power of the service profile becomes evident in templates. A service profile template parameterizes the UIDs that differentiate one instance of an otherwise identical server from another. Templates can be categorized into two types: initial and updating.

  • Initial Template: The initial template is used to create a new server from a service profile with UIDs, but after the server is deployed, there is no linkage between the server and the template, so changes to the template will not propagate to the server, and all changes to items defined by the template must be made individually to each server deployed with the initial template.
  • Updating Template: An updating template maintains a link between the template and the deployed servers, and changes to the template (most likely to be firmware revisions) cascade to the servers deployed with that template on a schedule determined by the administrator.

image

Personally I like the updating templates. The updating templates has the advantage that you can mass change the configuration settings or firmware levels for example which is then propagated to each service profile associated with the service profile template. However keep in mind that you do create an maintenance policy first and added to your service profile template. In case your system required a reboot it will be instantly being rebooted because of the defaults are set on immediate.

SNAGHTML7377505

Personally I prefer to create a maintenance policy with a User Ack configuration. In case of a change it will ask manual intervention to reboot the system as shown in the message below.

image

Further more, the advantage of templates is that you can create multiple service profiles with the except same settings as the template. This includes also the vNIC configuration as well as the vHBA etc. A nice step-by-step guide can be found here: http://www.petri.co.il/cisco-ucs-creating-service-profile-templates.htm

However to summarize the steps required to create a service profile I found this nice high level flow image on the Cisco Website which basically tells you what steps are required to create a service profile template.

So creating templates isn’t hard to do. However I do suggest to practice it within the simulator. Secondly I do recommend to use templates as much as possible which will makes it much easier to maintain your configuration and firmware levels. Also when adding or replacing blades you can easily deploy the new servers by just creating some new service profiles based on the template.

Mar 092012
 

The Cisco UCS third-generation fabric computing platform incorporates the new Intel Xeon processor E5-2600 product family and includes multiple server form factors delivering the industry’s highest server density and efficiency, with up to eight times the memory capacity and four times the I/O compared to previous UCS servers.
The Cisco UCS Manager now allows IT administrators to manage both blade and rack servers as a common entity, and extends the management domain to span thousands of servers across data centers around the world.

Cisco UCS integrated networking and virtualization:

image

  • The chassis I/O module 2204XP provides options for 80Gbps and 160Gbps down to each chassis to handle workload bursts. The module also offers port channeling, which allows load balancing across all ports to improve efficiency and resiliency through higher link utilization and bandwidth.

image

  • The Cisco UCS 6296UP Fabric Interconnect doubles the switching capacity of the UCS fabric (from 960Gbps to 1.92Tbps) and reduces end-to-end latency by 40 percent to deliver industry-leading application performance. The fabric interconnect provides infrastructure agility at scale with unified ports and greater energy efficiency, lowering watts per port by 36 percent.
  • The Cisco UCS 6200 Series combined with the Cisco Nexus Fabric Extender extends Cisco UCS Manager benefits to larger scale UCS deployments for both blade and rack form factors.

image

  • The VIC 1240, that is designed specifically for the M3 generation of UCS B-series servers. The card offers all the functionality of the Generation-1 Cisco VIC M81KR and augments application performance by quadrupling the bandwidth, up to 80 GB to the blade server when used with the Port Expander Card. It also increases flexibility by doubling the number of virtual interfaces available per card, up to 256 interfaces.

Large Photo

  • Cisco UCS B200 M3 Blade Server: The enterprise-class Cisco UCS B200 M3 server provides performance, versatility, and density in a half-blade form factor, delivering balanced, industry-leading density through its 24 DIMM slots and up to 80 gigabits of I/O bandwidth. Greater density, performance and bandwidth mean business applications can run faster, more cost-effectively, and more efficiently
    • Up to two Intel Xeon E5-2600 processor product family
    • Up to 384 GB of RAM with 24 DIMM slots
    • Up to two SAS/SATA/SSD
    • Cisco UCS VIC 1240 is a 4 x 10GE, FCoE-capable modular LAN on motherboard (LOM) and, when combined with an optional I/O expander, allows up to 8 x 10GE blade bandwidth
    • 1 Mezzanine, PCIe slot Gen 3.

Large Photo

  • UCS C220 M3 Rack Server: The Cisco UCS C220 M3 Rack Server is a one-rack-unit (1RU) server designed for performance and density for a wide range of business workloads, from Web services to distributed databases.
    • Up to two Intel Xeon E5-2600 processor product family
    • Up to 256 GB of RAM with 16 DIMM slots for memory-intensive applications
    • Four or eight SAS/SATA/SSD drives
    • 2 PCI Express Gen 3 slots and two 1GE LAN interfaces on the motherboard
    • Trusted Platform Module (TPM) for authentication and tool-less access

Large Photo

  • UCS C240 M3 Rack Server: The Cisco UCS C240 M3 Rack Server is a two-rack-unit (2RU) server designed for both performance and expandability over a wide range of storage-intensive infrastructure workloads, from big data to collaboration.
    • Up to two Intel Xeon E5-2600 processor product family
    • Up to 384 GB of RAM with 24 DIMM slots
    • Offers 12 or 24 SAS/SATA/SSDs for workloads demanding large internal storage
    • 5 PCI Express Gen 3 slots and four 1GE LAN interfaces on the motherboard
    • Trusted Platform Module (TPM) for authentication and tool-less access
Aug 092011
 

As a more and more Server-, Storage- and virtualization engineer I’m more then exited to see that Cisco is evolving there Cisco UCS platform with 3 more new products which I received in a marketing e-mail from Cisco.

New Fabric Interconnect (Cisco UCS 6248UP) that doubles the switching capacity of the data center fabric to improve workload density (from 520Gbps to 1Tbps), reduces end-to-end latency by 40 percent to improve application performance  and provides flexible unified ports to improve infrastructure agility and transition to a fully converged fabric.

New Chassis I/O Module (Cisco UCS 2208XP) that doubles the bandwidth to the chassis (from 40Gb to 80Gb) to improve application performance and handle workload bursts (from 80Gb to 320Gb to the blade).

New Virtual Interface Card (Cisco UCS VIC 1280) that quadruples the bandwidth to the server to improve application performance (from dual 10Gb to dual 40Gb) and doubles the number of virtual interfaces to improve Virtual Machine workload density (from 128 interfaces to 256 interfaces). It also offers a choice of Hypervisor to customers by expanding VM-FEX technology to Linux based hypervisors (KVM based on RHEL 6.1).

Besides all this new hardware, Cisco will also reveal Cisco UCS 2.0 which will contain some cool features including iSCSI Boot Support in UCS Service Profile

It was already being announced in July 12, 2011 at Cisco Live, Las Vegas. Sadly enough I couldn’t attend to this event since I don’t even live close. However M. Sean McGee apparently did.  Smile I can really recommend you read his blog since, IMHO it’s really cool.

Nov 062010
 

A few months ago I was certified for Cisco UCS Implementation. In our lab environment we are currently busy connecting and setting up our test UCS environment. However, just a few minutes ago I found a tool that is incredibly useful and I only wish I knew about it earlier.

I just found a Cisco UCS Emulator at the Cisco website. This could be really useful for development of course, however I’m more interested in the GUI to test things out. The download is about 224MB in size. The manual for this emulator can be found here.

After booting up the virtual machine, it is going to unpack and install the UCS Platform Emulator. Once it’s finished, the virtual machine is going to boot up the Cisco UCSPE (UCS Platform Emulator) & UCS Manager.

1 Booting Cisco UCS emulator

When done, you will see this screen:

2 UCS System booted

Above, you will find an URL containing an IP address configured for this virtual machine. When browsing to this URL using my web browser I’m presented the following window.

21 UCS manager webstart

When I hit the launch button, a JAVA client loads the UCS Manager. On my MacBook pro it took a little while before it was running, but hey I’m also running a Windows 7 VM 🙂

While loading you will see a screen that looks something like this:

3 Loading UCS manager

When it’s finished loading, you can login with the default UserID and Password.

3.1 Login Window UCS Manager

The default settings are:
UserID: config
Password: config

And, wow, I got a Cisco UCS Manager running on my system! Of course this is just an emulator but hey it’s less expensive then buying a UCS chassis!

4 UCS Manager

So if I want to try a new Service Profile, then it’s no problem at all.

5 Service Profile

So anyone who is currently studying for Cisco UCS, make sure you get this emulator. Also it’s very very useful while developing scripts or other applications to work with the Cisco UCS interface. It seems on the website it’s especially created for developers, but who’s going to stop you from using this for your studies?

I have to make a little note about the topic of development before I forget. For the developers amongst us, Cisco also created an UCS XML API Programmer’s Guide. I recommend that software engineers download this guide including the emulator if you are planning to use the UCS API’s.