CERTIFICATION STUDY GUIDE
VCE CERTIFIED PROFESSIONAL
VCE VBLOCK
®
SYSTEMS DEPLOYMENT
AND IMPLEMENTATION: COMPUTE EXAM
210-020
Document revision 1.2
Revision History
Date Document Revision Author Description of Changes
May 2014 1.0 VCE Initial Draft
July 2014 1.1 VCE Final
Table of Contents
Obtaining the VCE-CIIEc Certification Credential ... 4
VCE Vblock® Systems Deployment and Implementation: Compute Exam ... 4
Recommended Prerequisites ... 4
VCE Exam Prep Resources ... 4
VCE Certification Website ... 4
Accessing Related VCE Documentation ... 5
About This Study Guide ... 6
Vblock
®Systems Overview ... 7
Vblock Systems Architecture ... 7
System Management ... 8
Advanced Management Pod (AMP) ... 8
VCE Vision™ Intelligent Operations ... 8
Vblock Systems Compute Layer ... 10
Compute Components ... 10
Production Servers ... 10
Fabric Interconnects ... 11
Vblock Systems Compute Architecture ... 12
Server Management ... 12
Initial UCS Configuration ... 13
Advanced Configuration And Provisioning ... 14
Service Profiles ... 14
Service Profile Templates ... 15
Resource Pools ... 15
Obtaining the VCE-CIIEc Certification Credential
The VCE™ Certified Professional program validates qualified IT professional to design, manage, configure, and implement Vblock® Systems. The VCE™ Certified Converged Infrastructure Implementation Engineer (VCE-CIIE) credential verifies proficiency with respect to the deployment methodology and management concepts of the VCE Converged Infrastructure. VCE-CIIE credentials assure customers that a qualified implementer with a thorough understanding of Vblock Systems is deploying their systems.
The VCE-CIIE track includes a core qualification and four specialty qualifications: Virtualization, Network, Compute, and Storage. Each track requires a passing score for the VCE Vblock® Systems Deployment and
Implementation: Core Exam and one specialty exam.
To obtain the Certified Converged Infrastructure Implementation Engineer Compute (CIIEc) certification, you must pass both the VCE Vblock Systems Deployment and Implementation: Core Exam, and the
VCE Vblock Systems Deployment and Implementation: Compute Exam.
VCE Vblock Systems Deployment and Implementation: Compute Exam
The VCE Vblock Systems Deployment and Implementation: Compute Exam confirms that candidates have met all entrance, integration, and interoperability criteria, and that they are technically qualified to install, configure, and secure the server infrastructure on Vblock Systems.
The exam covers compute technology available at the time the exam was developed.
Recommended Prerequisites
There are no required prerequisites for taking the VCE Vblock Systems Deployment and Implementation:
Compute Exam; however, exam candidates should have working knowledge of Cisco UCS server technology in a
production data center. The knowledge and experience should be obtained through formal ILT training and a minimum of one-year experience. It is also highly recommended that exam candidates have training, knowledge, and/or working experience with industry-standard x86 servers and operating systems.
VCE Exam Prep Resources
VCE strongly recommends exam candidates carefully review this study guide; however, it’s not the only
recommended prep resource for the VCE VblockSystems Deployment and Implementation: Compute Exam and
reviewing this study guide alone does not guarantee passing the exam. VCE certification credentials require a high level of expertise, and it’s expected that you review the related EMC, Cisco, or VMware resources listed in the References document (available from the VCE Certification website). It’s also expected that you draw from real-world experiences to answer the questions on the VCE certification exams. The certification exam also tests deployment and implementation concepts covered in the Instructor-Led training (ILT) course VCE Vblock Systems
Accessing Related VCE Documentation
The descriptions of the various hardware and software configurations in this study guide apply generically to Vblock Systems. Vblock Systems 200, Vblock Systems 300, and Vblock Systems 700 family Physical Build, Logical Build, Architecture, and Administration Guides contain more specific configuration details.
The VCE related documentation is available via the links listed below. Use the link relative to your role.
Role Web Link
Customer http://support.vce.com
VCE™ Partner www.vcepartnerportal.com
VCE employee www.vceview.com/solutions/products/
Cisco , EMC, or VMware employee https://portal.vce.com/solutions
About This Study Guide
The content in this study guide is relevant to the VCE Vblock Systems Deployment and Implementation: Compute
Exam. It provides information about Cisco Unified Computing System (UCS) servers and how they integrate into
the VCE Vblock Systems. Specifically, it addresses installation, implementation, and administration of compute resources within the Vblock Systems environment.
This study guide focuses on deploying Cisco compute solutions in a VCE Vblock Systems converged infrastructure. Vblock Systems come preconfigured with specific customer-defined server, storage, and networking hardware. Since Vblock Systems are shipped with VCE qualified components, the bulk of this guide concentrates on how to configure and manage the compute infrastructure on Vblock Systems.
The following topics are covered in this study guide:
System Overview. An overview of the Vblock Systems and the compute environment including an architectural review of Cisco Unified Computing System (UCS) as well as an introduction to the specific Cisco compute components in the Vblock Systems.
Management. How to manage the Vblock Systems using the two most significant Vblock Systems management solutions: VCE Advanced Management Pod (AMP) and VCE Vision™ software. Configuration. UCS configuration and implementation procedures accomplished through the service
profiles, templates, pools, and policies of the Cisco Unified Computing System (UCS) Manager for UCS B-Series servers, and the Cisco Integrated Management Controller (CIMC) that is used to manage the standalone C-Series servers.
High-Availability. Configuring the compute infrastructure for high availability. The Configuration and Administration sections discuss various options for maximizing redundancy.
Administration. The UCS Manager is the main UCS administration tool, but it also functions as an auxiliary administration tool for other Vblock Systems environments, notably the Vblock Systems compute layer. This section also covers the role of the AMP and VCE Vision software in administering the UCS.
Vblock Systems Overview
VCE Vblock Systems combine industry-leading hardware components to create a robust, extensible platform to host VMware vSphere in an optimized scalable environment. Vblock Systems use pairs of hardware and power connections which, when combined with clustering and replication technologies, create a highly available virtual infrastructure.
This study guide concentrates on the converged infrastructure of the Vblock 200 family, Vblock System 300 family, and Vblock System 700 family. These systems are made up of several preconfigured components.
Vblock Systems Architecture
Vblock Systems are complete, enterprise-class data center infrastructure platforms. They have a scaled-out architecture built for consolidation and efficiency. System resources are scalable through common and fully redundant components. The architecture allows for deployments involving large numbers of virtual machines and users.
The specific hardware varies depending on the Vblock Systems model and specific configuration. The compute, storage, and network components include
Cisco UCS-environment components
o UCS rack-mount blades (Vblock 200) and blade servers (Vblock System 300 family and Vblock System 700 family)
o UCS chassis
o UCS Fabric Interconnects o UCS I/O modules
Redundant Cisco Nexus and or Catalyst LAN switches Redundant Cisco MDS SAN switches, installed in pairs EMC VNX or VMAX enterprise storage arrays
Base preinstalled configuration software includes VMware vSphere on UCS production servers as well on the C-Series servers that comprise the AMP for the Vblock System 300 and Vblock System 700.
System Management
As noted, Vblock Systems have two primary sources for system management: the Advanced Management Pod (AMP) and VCE Vision software.
Advanced Management Pod (AMP)
The AMP is the main management point for the Vblock Systems environment. Essentially, an AMP server acts as a central repository for all the core management applications and tools from the various Vblock Systems
components, including the Cisco Integrated Management Controller (CIMC) for Cisco rack servers. AMP software monitors and manages system health, performance, and capacity. It resides on a dedicated server (or virtual server) separate from the production system, and as such, it supplies fault isolation for management without a drain on system resources, while providing a clear point of demarcation for administration operations.
Originally, the AMP was implemented as either a single-server mini-AMP or a dual-server HA-AMP. The second generation AMP-2 has multiple configurations. It comes as a virtual environment (AMP-2V) or as a dedicated physical environment with a default server (AMP-2P) or with two physical servers (AMP-2RP) for redundancy. In rare cases where the Vblock Systems have no vSphere environment, an AMP-2LP is used. Only Vblock 200 platforms implement a virtual AMP-2V or an AMP-2LP.
Architecturally, the AMP is a vCenter cluster made up of core management VMs and virtual applications (vApps), including vCenter Server and several element managers. Physically, the AMP is typically implemented as a specific set of hardware in the Vblock Systems—usually in a high-availability AMP-2RP configuration. It is contained in top-of-the-rack C220 server(s), except, of course, for AMP-2V implementations, which use separate virtual machines for core-management workload services.
VCE Vision Intelligent Operations
The VCE Vision software application resides on its own Virtual Machine in the AMP. VCE Vision software
provides a single source for Vblock Systems resource monitoring and management. The industry’s first converged architecture manager, VCE Vision software has been designed with a single, consistent interface that interacts with all Vblock Systems components. VCE Vision software integrates tightly with vCenter Operations Manager, the management platform for the vSphere environment.
The diagram below provides a sample view of the Vblock Systems architecture. The Vblock System 340 is shown in this example.
Vblock Systems Compute Layer
Compute Components
Cisco’s Unified Computing System (UCS) is an enterprise-class Intel platform server offering. It integrates network, compute, and management into a high-performance server platform. It combines network switches and blade servers into a single integrated architecture built to meet the demands of enterprise data centers. The Vblock Systems UCS architecture is discussed in the next section. First, however, it makes sense to introduce the Vblock Systems UCS components.
Production Servers
For compute services, Vblock Systems rely on either UCS rack servers or blade servers. It depends on which Vblock Systems are used. The Vblock System 200 uses UCS C-Series rack-mount servers, and the Vblock 300 and Vblock 700 use B-Series blades. (Note that the Vblock System 300 family and Vblock System 700 family also use the C-Series rack servers as dedicated AMP servers.) All UCS servers are based on standard x86
components, with Intel Xeon processors and DIMM slots.
The Vblock 340 and Vblock System 720 support multiple M2 and M3 UCS B-Series models. In terms of their physical attributes, these blade servers come in full slot (M3 B420 and M2 B440) and half slot (M3 B22, M3 B200, M2 B230) form factors. Total memory for the B-Series blade servers ranges from 384 GB to 1 TB, with DIMM slots ranging from 12—48, depending on the model. At the high end, the M3 B420 has three-adapter slots, with one dedicated for a virtual interface card (VIC). Both the M3 B420 and M3 B440 feature SAS drives. For flexibility, B-Series models can be mixed within the chassis.
The Vblock 200 platforms can have four to 12 UCS C220 M3 servers, each with one or two CPUs (4-core, 6-core, and 10-core). The servers have 64 GB—256 GB of memory and 8 DIMM slots per processor, and they use a virtual interface card (VIC) for converged networking.
Vblock Systems servers provide all the compute services for the virtual environment. They are installed with VMware ESXi and the Cisco Nexus 1000V virtual switch, and they feature converged network adapters and port virtualization through the VIC, a 10-GB Ethernet PCIe adapter for virtual interfaces.
Fabric Interconnects
The Cisco UCS 6200-Series Fabric Interconnects (FIs) provide the management and communication backbone for Cisco’s B-Series blade servers and the UCS 5100-Series chassis. Installed in pairs, the FIs provide
connectivity through the servers and chassis and outward to the network and storage components in Vblock 300 and Vblock 700 platforms. Cisco UCS 6200-Series FI switches offer line-rate, low-latency, lossless 10 Gigabit Ethernet, Fibre Channel over Ethernet (FCoE), and Fibre Channel functions.
All the chassis and blade servers attach to the FIs to become part of a single, highly available management domain. In addition, by supporting unified fabric, the Cisco UCS 6200 Series provides both the LAN and SAN connectivity for all blades within its domain.
From a networking perspective, the Cisco UCS 6200 Series FIs use a cut-through architecture, with a switching capacity of 2 terabits (TB) and 320-Gbps bandwidth per chassis, independent of packet size and enabled services. The product family supports Cisco low latency, lossless 10 Gigabit Ethernet unified network fabric capabilities, which increase the reliability, efficiency, and scalability of Ethernet networks. Multiple traffic classes occur over a lossless Ethernet fabric from the blade through the FI. Significant TCP savings come from an FCoE-optimized server design in which network interface cards (NICs), host bus adapters (HBAs), cables, and switches can be consolidated.
The Cisco UCS 6248UP 48-Port Interconnect is a one-rack unit (1RU) 10 Gigabit Ethernet, FCoE, and Fibre Channel switch offering up to 960-Gbps throughput and up to 48 ports. The switch has 32 1/10 Gbps fixed Ethernet, FCoE, and FC ports and one expansion slot.
The UCS 6296UP 96-Port Fabric Interconnect is a 2RU 10 Gigabit Ethernet, FCoE, and native Fibre Channel switch offering up to 1920 Gbps throughput and up to 96 ports. The switch has 48 1/10 Gbps fixed Ethernet, FCoE, and Fibre Channel ports and three expansion slots.
Vblock Systems Compute Architecture
This study guide is not meant to examine the complexities of the Vblock Systems compute architecture. Still, the architecture is significant. By looking at the components, we have already touched on the basic tenets of the Vblock Systems server architecture that depends on the UCS server model.
The UCS Series-C 220 servers used in Vblock 200 platforms are rack servers, and architecturally their connectivity functionality and management is self-contained. Each UCS C220 server uses the Cisco Integrated Management Controller (CIMC) for administration, configuration, monitoring, and server upgrades. CIMC resides independently on each server. Physically, the UCS C220 is a 1RU server. Vblock 200 platforms support four to twelve UCS C220 servers, typically installed at the bottom of the rack, below the network switches.
The B-Series blades used in the Vblock 300 and Vblock 700 platforms have a different design altogether. They are contained in a UCS chassis, along with a separate I/O module, or Fabric Extender (FEX), for converged-network access. The FEX modules connect to the Fabric Interfaces. The FIs, in turn, provide management and connectivity—both between servers and IP networks for LAN and Network Attached Storage (NAS)
communication and between servers and Fibre Channel networks for SAN communication. Meanwhile, both Vblock 300 and Vblock 700 models use dedicated C220 servers for the AMP.
In both cases, UCS servers can be configured to boot from SAN or from local storage; however, the local storage in Vblock Systems is reserved only in C-Series servers. In other words, local storage for Vblock 300 and Vblock 700 platforms only exists in the AMP for management. Vblock 200 platforms can include local storage in their stand-alone, rack-mounted servers for ESXi and bare-metal deployments.
Initial UCS Configuration
Although basic configuration is completed at manufacturing, the compute environment will require continual adjustment to accommodate applications and other environment considerations. Therefore, administrators should become familiar with the initial configuration process, outlined below. Keep in mind that the information presented here is a summary. More complete base configuration instruction is available in the Vblock Physical and Logical Build Guides as well as other VCE and Cisco documentation.
Setting up compute resources for Vblock 200 platforms is largely a physical-build process. Compute resources, memory, and I/O bandwidth are determined by the number of servers deployed, the selected CPU types, and the network connections.
For Vblock 300 and Vblock 700 platforms, the process begins with configuring the Fabric Interconnects by running the appropriate Cisco scripts. Remember, FIs are installed in redundant pairs. Configuration needs to be finished on the first FI before starting the second. After FI configuration, the UCSM completes the process of setting up the fabric communication between the server chassis, the FI ports, and the I/O modules.
Determine setup policies. UCSM sets the policies for adding new chassis, determines the number of links between the chassis and the FIs, and specifies the redundant power supplies.
Configure ports. FI ports can be Ethernet or Fibre Channel. The first steps involve verifying and installing the FI port licenses and setting the port mode. Then physically connect the FIs to the I/O modules before configuring Uplink Ethernet (and disjoint Layer 2), Uplink FC ports, and necessary port channels. Create named VLAN and VSAN. A named VLAN creates a connection and isolates traffic to a specific
external LAN. It can apply to both common and global configuration parameters. Likewise, a named VSAN creates a connection and isolates traffic to a specific external SAN, and it also applies to all available (common/global) fabrics. To allow all VSANs in a UCS domain access to all the FC Uplink ports on the FI, make sure that FC Uplink trunking is enabled.
By default, all Ethernet ports initially belong to VLAN 1 and all FC ports initially belong to VSAN 1. (Refer to Vblock® System Deployment and Implementation: Network for additional information regarding VLANs and VSANs.)
Install firmware. Download the correct host firmware package.
Configure Communication Management settings. These are customer-specific settings that include communication services, DNS servers, and management interface monitoring.
Complete Additional Configuration. These include setting syslog options, adding an NTP server, and determining base configuration policies (e.g., network-control policies, local disk configuration policies, BIOS policies).
Advanced Configuration and Provisioning
The Cisco UCS Manager is policy based, relying on policies that define the role of the server. Policies simplify the system configuration and provisioning; determining, for instance, where a server boots from or what its I/O properties are. Policies ultimately address every layer of the Vblock Systems hardware infrastructure, including RAID levels, I/O properties, host firmware and BIOS settings, adapter IDs and settings, disk configuration, network identity (MAC address, VLAN, World Wide Name, etc.), VLAN and VSAN attributes, network control settings (QoS), and data center connectivity.
Each server in the Vblock Systems has a Service Profile, which encapsulates the server’s assigned policies and data points. Furthermore, dynamic pooling automatically groups servers to coordinate compute resources more efficiently. The UCS Manager uses policies, service profiles, and resource pools to identify, control, and administer UCS servers. This policy-based approach lends itself to large-scale cloud environments, where maintaining server resources consistently among thousands of virtual machines can be challenging.
This section looks more closely at the concepts and methodology of using the UCS Manager for Vblock Systems server configuration.
Service Profiles
The service profile is a key feature of Vblock Systems deployment, imposing compute, network, and storage attributes to UCS servers. A server is essentially an anonymous entity; it is the service profile that gives the server its role in the system. The service profile is stored in the UCS Fabric Interconnects. Once the profile is assigned to a server, the UCS Manager automatically configures the server, adapters, I/O modules, and FIs. A server can have only one service profile.
A service profile contains four types of information: server resources, identity information (UUID and MAC addresses for vNICs and WWNs for host bus adapters), firmware specifications, and configuration connectivity. The chart below identifies the attributes found in the service profile.
Service Profile Templates
Service profiles are generated from templates. The templates themselves are completely independent of the server. The service profile is applied to the server, not the template. Service profile templates (SP templates) provide a pattern for new profile creation, making server provisioning and redeployment more consistent. For instance, existing service profile templates (SP templates) might determine network interfaces: vNIC, vHBA, and iSCSI templates. These existing templates can be reused for new server deployment, or they become elements of a new service profile. In other words, a basic template for, say, web-server deployment may serve as the basis for two new separate profiles: one for Production web servers (production VLANs, SAN configuration, etc.) and one for Test web servers (QA VLANs, local disk boot, etc.). Both new server profiles inherit attributes from the original web-server template.
As an example, consider the process of deploying eight identically configured blade servers. Each blade should have two vNICs and two vHBAs. In addition, the internal disks of the blades should be mirrored, they should boot from SAN, and the local disks should be scrubbed if the blade is not associated with a service profile. Lastly, the blades should all communicate over the same VLAN and VSAN. All eight blades could—and should—share the same service profile, ensuring that the policies, VLAN IDs, VSAN IDs are all set identically. Otherwise, it is a time-consuming process. Service profile templates simplify the task significantly for rapid server deployment. In the case of these eight blades, the server requirements are now captured in template, which can then generate eight identical service profiles.
The concept of inheritance is an important feature for service profile templates and their proliferation. Templates are classified into two types: initial and updating. The type determines the way modifications are handled. A service profile generated from an initial SP template inherits all the properties of that template. But the profile is not inherently connected to that template. The template does not adjust to profile changes; it stays intact. Any
changes are manual, applied one service profile at a time. Service profiles generated from updating SP template do affect the template. Any modifications are automatically applied to the template. This automatic updating can certainly be useful, especially for server farms, but be aware that modifications to updating SP templates can have far-reaching—and sometimes unintended—consequences.
Resource Pools
As indicated in the previous example with the eight identical blade servers, service profiles can be applied to a collection of UCS resources or pools. Vblock Systems support a number of pooling options: Server pools, Management IP pools, and Address pools.
Server pools define a class of servers based on various characteristics (i.e. all 96 GB dual-socket servers, or all 1U servers with eight local disks, or all servers that have been manually added to the pool). Server pools typically contain similarly configured blades. The entire pool can then be associated with a service profile, so that when a matching server is discovered in the UCS environment, it gets assigned to the appropriate template, and can be automatically provisioned on power-up.
Address pools include UUIDs, World Wide Names (WWNs), and MAC addresses.
Using UUID suffix pools offers some flexibility in terms of deploying service profiles. By assigning a service profile to a UUID pool, the service profile can be moved among servers without being tied to specific hardware. This is known as “stateless” computing.
WWN pools allow service profiles to be assigned to blocks of virtualized WWNs. Service profiles specify the number of virtual host bus adapters (vHBAs) in the system. In most cases, the number will be equal to the number of blades multiplied by two, because each blade has two virtual HBAs present. Multiple WWN pools can be created on a per-application basis to minimize SAN zoning requirements.
A unique MAC address is assigned to every node on the LAN, and MAC address pools can be associated with specific vNICs.
Policies
After designating resource pools, the policies need to be defined—after which they can be automatically propagated to their applied service profiles. As mentioned, policies determine the server role. Many UCS policies are predefined using default values, but others are user defined. There are two types: configuration policies and operational policies. The Firmware Policy, for example, determines the blade server BIOS and adapter firmware, and it would be considered a configuration policy. So would the Auto-Configuration Policy that defines the configuration applied to any new server at initial startup. The Scrub Policy is operational; it allows local disks to be wiped on association. The chart below lists both the configuration and operational UCS policies.
Access Roles
The user roles are both systems and proprietary roles created on the UCS environment. Standard roles (server, network, storage, etc.) are built into the UCS Manager. Role-Based Access Control (RBAC) within UCS Manager is a hierarchical structure beginning at the top level with “root” and moving down to sub organizations when they are created. Each role has a corresponding set of privileges that control write access to server configuration, internal and border LAN configuration, internal and border SAN configuration, and configuration of other Cisco Unified Computing System components—including RBAC configuration itself.
Creating Pools, Policies, and Service Profiles
Typically, Vblock Systems administrators use the UCS Manager and optionally the Unisphere UIM provisioning tool to perform UCS provisioning and to determine server resources prior to actually creating service profiles or templates. The UCS Manager captures the server topology information for the Vblock Systems compute
resources, starting with the chassis and blade servers and following through with the I/O modules, the FI ports and Uplink status, and the defined VSANs and VLANs. The UCS Manager also collects the UCS
resource-configuration data, including the host ID, the cluster state, the network adapter inventory, and existing policies associated with the server.
Pools
The next step involves setting up pools. It is important to understand the UCS topology before designating resource pools. Populating pools can be either a manual or automatic process. The UCS Manager interface handles manual population.
New server pools require a name and a description, and then servers can be added to it. From the UCS Manager, select Server Pools from the Pools filter in the Servers tab. The same server can appear in different pools. Server pools can be auto populated as well, depending on the server pool policy.
Address pools also require a name and a description before adding the unique IDs. As with server pools, use the Pools filter from the Servers tab in the UCS Manager, and select the appropriate address ID pool: UUID Suffix, MAC, or WWNN/WWPN. Each type of address ID is characterized by a specific format.
A UUID consist of a prefix and a suffix, combining for a 128-bit, 16-octet ID that uniquely identifies a compute node or resource (e.g., file server, web server, etc.). In Vblock Systems, the UCS Manager assigns prefixes in a specific form—eight-digit section, followed by two digit sections: FFFFFFFF-FFFF-FFFF. Suffixes are a four-digit section followed by twelve-four-digit section: XXXX-XXXXXXXXXXXX. So an entry in the UUID pool might look like this: 1000025b-2FFF-3FFF-2000-010203040506.
WWNs are made up of two-digit octets, and they represent either the address of the SAN server (World Wide Node Name or WWNN) or a vHBA port name (World Wide Port Name or WWPN). Vblock Systems WWNs also follow a strict structure, and the company identifier (organizationally unique identifier or OUI) is encoded in the third section. So, for instance, in the WWN address 20:00:XX:XX:XX:NN:NN:NN, “XX:XX:XX” is the OUI. The
Policies
Generally speaking, each UCS policy has its own individual prerequisite and configuration tasks—some of them brief and some quite lengthy. For instance, the Server Pool Policy is simply a matter of naming and describing the policy, and then selecting the server pools and pool qualification from drop-down lists. Meanwhile, some of the boot policies have several prerequisites followed by drawn-out operations for configuring the boot device, creating a qualified name pool, establishing an address pools, building authentication profiles, et cetera—all before actually creating the policy.
Commonly, policies require previous set up of things like VLANs and VSANs, pools, vNIC and vHBA addresses, and MAC addresses. In addition, some policies rely on previously implemented policies. Keep in mind that many UCS policies have already been established during the initial logical-configuration phase at manufacturing. Suffice it to say that Cisco provides provisioning and configuration tools for creating policies that work in
conjunction with the UCS Manager. The most notable of these is the UCS Director, which automates some of the steps necessary in configuring a UCS domain. As a whole, the UCS management environment has a
straightforward GUI with drop-down lists and dialog boxes for creating policies.
The items below discuss some important individual Vblock Systems policies, but the material covered here should be considered overview material. For platform- and site-specific details regarding UCS policies, consult the appropriate Vblock Physical Build and Logical Build Guide, the Logical Configuration Survey as well as any relevant Cisco documentation.
Autoconfiguration Policy defines a default configuration (service profile) for new blades.
Boot Policy determines the configuration of the boot device, the server boot location, and the boot order. Since ESXi is installed on the servers, Vblock Systems typically boot from SAN. In terms of boot order, the first boot target is CD-ROM target for OS installation, followed by SAN boot, and then LAN. Chassis Discovery Policy determines how the system behaves when a new chassis is added.
Specifically, it determines thresholds for the number of links between the chassis and the FIs, which ultimately affect the traffic path and oversubscription rate.
Firmware Policy configures server BIOS and adapter firmware.
Ethernet and FC Policies specifies queue sizes, interrupt handling behavior, and failover configuration within the hosts of the network adapters.
Local Disk Policy sets the mode for local SAS drives via the drive RAID controller. Local disk modes include: No Local Storage, RAID 0 Striped, RAID 1 Mirrored, Any Configuration, RAID 5 Striped Parity, RAID 6 Striped Dual Parity, and RAID 10 Mirrored and Striped.
Power Policy establishes the redundancy of the power supplies in the UCS domain. Settings are: Non Redundant, where the power load is evenly balanced among the installed power supplies; n+1, where an extra power supply is installed for redundancy; and Grid, which provides actual failover.
Virtual Adapter Policies define the UCS connections for vNICs and vHBAs. The UCS Manager uses vNIC and vHBA templates for this purpose. (Note that these are not SP templates.) vNIC template fields include the FI ID, the maximum packet size (MTU), MAC pool, the QoS policy, LAN pin group, and a Statistics Threshold Policy. The vHBA template fields include the FI ID, VSAN, maximum data field size, WWPN pool, QoS policy, SAN pin group, and a Statistics Threshold Policy.
Service Profiles
Once the provisioning information is obtained, the pools created, and the policies defined, all the information needs to be applied to the server via the service profile. Again, new service profiles can be created from existing templates and they can be cloned from existing service profiles. And modified templates and service profiles can be created from existing templates. The UCS Manager also creates new service profiles from scratch. As with creating policies, the UCS Manager uses drop-down lists and dialog boxes for creating service profiles and SP templates.
The process begins in the UCS Manager Servers tab. Use the Create Service Profile tab from the Service Profile Templates menu. The new template initially requires a name and classification as either an updating or initial template. After that, the UCS Manager requests the following information:
UUID pools. The UUID block pools should already be created, and are available from a pull-down list. Network Configuration. Again, network configuration policies may already be available. But the network
configuration can be created on the fly, by establishing the connectivity type, creating the vNIC, including VLAN information, and selecting the MAC pool (for each FI). Repeat the process for all of the vNICs on the server.
Storage Configuration. First select the WWN pool assignment. At this point, the process is not unlike the vNIC process outlined above: create the vHBA, and assign it to each FI.
Boot Order Select the appropriate boot policy from the drop-down menu.
These configurations are considered core policies. The blades cannot work without them. Of course, a Vblock Systems template usually contains additional information and policies as well.
When the template is complete, a service profile can be generated from it or from any template in the drop-down list. The service profile requires a name (a “Naming Prefix” and “Suffix Starting Number”), the number of instances (i.e., the number of blades that require the profile), and the associated template. To assign the profile to a server, use the Equipment tab to associate the blade and its appropriate profile. If the blade is removed or migrated, its service profile needs to be disassociated.
Administration
Cisco and VCE provide a number of administrative tools for managing the UCS platform, performing configuration tasks, and resolving underlying problems. UCS administration can be performed locally or remotely, and
administrative solutions may involve a mix of production and non-production systems.
UCS Manager
The UCS Manager is Cisco’s most significant management solution for UCS domains. The previous section on Configuration highlights the merits of the UCS Manager. Its policy- and profile-based approach to server configuration simplifies what would otherwise be a demanding deployment project. We should point out that the policies, pools, service profiles, and SP templates all serve to make the compute infrastructure an easily-calibrated and adjustable environment. Unworkable or unstable configurations can be swapped out for better alternatives. Such flexibility is invaluable when it comes to troubleshooting. In addition, the UCS Manager monitors faults, alarms, and the status of the server-component equipment.
Due to their converged architecture, managing Vblock Systems are a sophisticated process. Administrators rely largely on the element managers for each Vblock Systems component: Unisphere for the storage system, vCenter Server for the virtual environment, Data Center Network Manager and NX-OS for networking, and the UCS Manager for the server environment. A lot of overlap exists among them, and the UCS Manager is no exception. Given that so many server-based administrative operations extend to other Vblock Systems components, the UCS Manager performs a number of general Vblock Systems management tasks. For example, creating VLANs and VSANs is considered a networking operation, and indeed, administrators generally create VLANs and VSANs from within NX-OS. Yet, VLANs and VSANs also play an important role in cloud computing in general and in server deployment in particular, when configuring the Fabric Interconnects, the vNICs and the vHBAs. That being the case, they can also be created from within the UCS Manager. For LAN and SAN configurations in a UCS domain, the UCS Manager performs the following tasks:
Create VLANs and VSANs
Configure uplink ports, port channels, and LAN/SAN PIN groups Configure the QoS classes, definitions, and bandwidth allocations
Create the pools and policies related to network configuration, such as MAC address pools and Ethernet adapter profiles
The Fabric Interconnects may be the most crucial UCS component in the Vblock Systems converged
infrastructure. The fabric communication requires precise configuration. It starts out with communication between the FIs themselves. In Vblock Systems, the FIs have a direct connection to each other through their L1 and L2 Ethernet ports. Both FIs actively forward traffic at the data plane; and at the management plane, the FIs are
AMP Management
As pointed out earlier, the UCS Manager resides on the Fabric Interface itself, not on the AMP server. However, the AMP contains core management software that is useful for Vblock Systems server administration and management, including UIM/P, CIMP, and VCE VisionTM software.
Vblock Systems administrators commonly use UIM/P for Vblock Systems hardware provisioning because it automates so many operations. For UCS provisioning, UIM/P performs many advanced configuration procedures. In the Vblock 340 alone, using UIM/P reduces UCS provisioning by 15 steps. It works in conjunction with the UCS Manager, using UCS policies to generate service profiles and configure vHBAs and vNICs.
While CIMC resides on the AMP server, its focus is really only on C220 servers, not the blade servers that make up the server platform of the Vblock 300 and Vblock 700. Still, CIMC is tightly integrated with the UCS Manager for service profiles, server provisioning, and change management. Furthermore, CIMC communicates vital information about each individual server to the UCS Manager for diagnostic and health monitoring services. All three tools—the UCS Manager, UIM/P, and CIMC—coordinate seamlessly with VCE Vision software. The VCE Vision software management system provides a single interface into the Vblock Systems. It collects UCS data generated from the UCS Manager, UIM/P, and CIMC and coordinates it with data from the other Vblock Systems element managers, resulting in a cohesive view of any specific Vblock System as a whole. Components are seen as one entity, one product. The dashboard interface lets users drill down for specific details on the UCS platform—the individual servers, the Fabric Interconnects and I/O modules, and the communication links. VCE Vision software is chiefly a component discovery and monitoring tool. The system is particularly effective for running diagnostics. Dashboards indicate the status of the server environment: performance health, resource availability, compliance, as well as system alerts.
Server Upgrades
Keep in mind that the material provided in this section is not a detailed procedure. Administrators should
familiarize themselves with UCS environment upgrade and installation documentation before attempting an actual upgrade.
The procedure begins with a formal assessment of the existing server environment: all the UCS components, their operability, and compliance. VCE Vision software can be a convenient tool here. It includes a compliance checker that uses predefined profiles as benchmarks for compliance scans, in addition to component inventory and the diagnostics discussed previously. VCE Vision software generates reports that reveal precisely the status of each Vblock Systems element, including each UCS component.
UCS upgrades for UCS C220 production servers and AMP servers is the same. BIOS and CIMC firmware must be upgraded to the same version, or the server cannot boot. The Cisco Host Upgrade Utility simultaneously upgrades CIMC, BIOS, LOM, storage controller, and VIC firmware to compatible levels.
B-Series environments are more elaborate, and so is their upgrade process. Production hosts need to go into maintenance mode before uploading the new firmware package and applying it. Be sure that each component is being upgraded to the most recent available version. First the firmware needs to be activated on each blade, on the adapters, on the UCS Manager, and on I/O modules. Then the new firmware is applied to each host service profile. At that point, the firmware can be activated on the fabric—one Fabric Interconnect at a time. Once the firmware has been installed on all the necessary UCS components, the hosts are rebooted (also one at a time). Upgrading Vblock Systems servers tends not to be an isolated event. As a converged environment, the server infrastructure is interconnected with the entire system—the adapters on the network switches, for example, or the FC connections between the Fabric Interconnects and the ports on the storage arrays. Any change can upset the balance of the system, especially changes and updates in the virtual environment. vSphere dominates in the Vblock Systems infrastructure.
Given the complexity involved in upgrading a converged infrastructure, VCE has implemented a full-scale upgrade service, VCE Software Upgrade Service, providing everything from upgrade project planning through
implementation and verification.
Still, many customers prefer to perform upgrades in-house. Regardless, upgrades are based on the VCE Release Certification Matrix (RCM), which lists the hardware and software component versions that have been fully tested and verified for particular release versions of Vblock Systems.
Conclusion
This study guide represents a subset of all of the tasks, configuration parameters, and features that are part of a Vblock Systems deployment and implementation. This study guide focused on deploying Cisco compute solutions in a VCE Vblock Systems converged infrastructure including how to configure and manage the compute
infrastructure on Vblock Systems.
Exam candidates with the related recommended prerequisite working knowledge, experience, and training should thoroughly review this study guide and the resources in the References document (available on the VCE Certification website) to help them successfully complete the VCE VblockSystems Deployment and Implementation: Compute Exam.
ABOUT VCE
