Single Server Actions

The most common way to initiate server actions is to navigate to the General tab of a specific server’s details page and then choose to initiate the action against the server from the Actions dropdown, as shown in Figure 4-1.

In the General tab of the server’s details page, basic inventory and health information are displayed on the left side and at the bottom of the page, and events affecting the server are shown on the right side. The events are further categorized as alarms, requests, and advisories. (See Chapter 3, “Infrastructure Operations,” for more detail on each of these.)

Different actions are available depending on the type of server. The actions shown in Figure 4-2 are for two different types of servers. Those on the left are for a UCS standalone rack server, and those on the right are for a UCS blade server.

Whenever an action is initiated, the Requests icon (discussed in Chapter 3) increments by one, indicating that the action is executing. The Requests icon is decremented by one (or is cleared if only one action was executing) upon completion of the action.

Not all actions shown in Figure 4-2 can be carried out against all servers. As noted previously, the possible actions depend on the type of server and also on the user’s permissions and the license tier of that server. For example, for a given server, a user with Server Administrator role credentials can perform all operations allowed by the server license level, including those related to power management, firmware upgrades, and operating system installation. The user with Server Administrator role credentials can also interface with existing element managers (such as UCS Manager or Cisco Integrated Management Controller) through the Actions menu. The user with Read-Only role credentials cannot perform Intersight-driven actions from this drop-down but can interface with element managers.

The actions shown in the drop-down menu in Figure 4-2 are all actions that can be performed within the context of the server currently displayed in Intersight.

Bulk Server Actions

Bulk server actions are used to perform specific functions against more than one server simultaneously. The simplest way to initiate bulk server actions for a selection of servers is to navigate to the servers table page by selecting Operate > Servers. This page lists all server targets. From this list, you can narrow down the list of servers by searching for servers based on attributes, as shown in Figure 4-3.

After narrowing down the list of servers, you can choose multiple servers by selecting the checkbox next to each desired server. After selecting the target servers, you can trigger the bulk action by clicking the bulk server action icon (the ellipsis), as shown in Figure 4-4.

The actions in the single server actions and bulk server actions lists have some overlap. In addition, not every action is available for every target type. For example, a firmware upgrade cannot be applied to a server that is a node in a HyperFlex cluster. Instead, HyperFlex clusters are upgraded as a cluster unit, as described in Chapter 6, “Storage Operations.”

Server Action Details

Server actions are presented in a nested menu format. For instance, power-related actions are visible as submenu actions under the Power menu, and system-related actions are visible as submenu actions under the System menu. Most of the actions are self-explanatory, but some of the actions have specific nuances, as highlighted the following sections.

vKVM Versus Tunneled vKVM

Operating a large-scale server environment requires the ability to remotely administer systems as if the operator were standing in front of the server. These remote presence capabilities are typically provided by an embedded management controller within the server itself. The most common—and perhaps the most important—remote presence capability is to virtually use the keyboard, video, and mouse functions. This is called vKVM (or virtual keyboard, video, mouse).

Intersight provides two distinctly different options for vKVM capabilities: vKVM and Tunneled vKVM. Both options provide the same functional benefit, but the Tunneled vKVM option takes full advantage of the Intersight architecture to allow the administrator to connect the vKVM from anywhere. Additional Tunneled vKVM behavior is noted below:

• Tunneled vKVM is disabled by default, and the administrator must opt in to enable this feature in Device Connector.

• Access to Tunneled vKVM functionality depends on the license tier of the target device.

• Tunneled vKVM requires authentication using an Integrated Management Controller (IMC) local user account. Other identity providers cannot be used with Tunneled vKVM.

For most vKVM solutions, the administrator must have access to the network on which the server management interface resides. This is typically achieved by using VPN software managed by an organization and placed on the operator’s client device (see Figure 4-5, left).

A VPN connection can introduce some significant security challenges. For instance, a VPN user may open access to the entire network of servers, workstations, and, in some cases, Operational Technology (OT) devices. VPN access can also open the door for impersonation because a VPN connection might be attempted by anyone on the Internet. Therefore, the VPN solution must take advantage of authentication technologies such as single sign-on (SSO) and multifactor authentication (MFA), using a trusted identity provider (IdP) to prevent identity spoofing. When using a VPN connection to access the remote console of a server, it is especially important to ensure that the VPN has been properly configured to limit the network segments that can be accessed and to ensure that the connectivity solution has been properly secured and hardened.

These challenges can be avoided with the Tunneled vKVM feature of Intersight. Intersight’s architecture can ensure proper connectivity, authentication, and network isolation from the client to the target console. Because Intersight already maintains a secure connection to its targets and its users, Intersight can take advantage of these connections to provide a secure end-to-end vKVM session for the Intersight administrator. The right side of Figure 4-5 shows an Intersight-authenticated user establishing a remote tunneled vKVM session through the existing Device Connector–maintained secure connection to Intersight. The KVM traffic is automatically tunneled from the remote user through Intersight to the target device, without needing to rely on a VPN.

Server Policies

Server policies in Intersight include items such as BIOS settings, disk group creation, Simple Mail Transfer Protocol (SMTP) settings, and Intelligent Platform Management Interface (IPMI) settings.

Once a policy is created, it can be assigned to any number of server profiles to standardize and ensure compliance across servers in all locations. The use of policies provides agility and minimizes the potential for mistakes when configuring many servers with similar settings. Policies promote consistency by allowing an administrator to make all necessary configuration changes in one place. For example, if the NTP server for a location were to change, the administrator would simply update the NTP policy used by all servers at that location rather than update each server individually.

Intersight has unique policy types for servers, blade chassis, UCS domains, and HyperFlex clusters. In some cases, policies can be shared between different target types. For example, an NTP policy can be used by both servers and UCS domains.

ID Pools

In Intersight, pools are used for consumable resources or identifiers such as management addresses, World Wide Names (WWNs), and MAC addresses that are unique for each server. Pools are preconfigured ranges of these addresses that are consumed when attached to a server profile. Figure 4-6 shows a small MAC address pool.

Server Profiles

An Intersight server profile is composed of a combination of policies and pools. Server profiles are used to define the desired configuration to a target server. The Assign Server Profile action triggers the automated configuration of the server to match the settings defined within the server profile.

Much as with policies, there are unique profile types for servers, chassis, UCS domains, and HyperFlex clusters. This chapter covers server profiles for both rack and blade servers. The other profile types are covered in other chapters.

Traditional UCS Domains

Intersight can be used to perform day-to-day operations on traditional UCS Manager (UCSM) domain infrastructure, such as powering on, powering off, accessing the vKVM, and updating firmware. This provides a consistent operational model for standalone rack servers, traditional UCS domains, and the newer architecture that is discussed below.

Intersight coordinates server operations with UCSM by using the embedded Device Connector (discussed in Chapters 1 and 2). Beginning with the 3.2 software release, Device Connector was integrated into UCS Manager. As with other Cisco targets, administrators simply claim a traditional UCS domain in Intersight by using the device ID and claim code obtained from UCSM Device Connector.

Upon successfully claiming a traditional UCS domain, Intersight conducts an inventory collection of the entire domain infrastructure. All components (servers, chassis, FIs, and so on) within the claimed domain are added to Intersight’s inventory of managed devices. Intersight can perform operational tasks within the domain by working in harmony with UCSM.

Examples of Intersight’s operational capabilities within a traditional domain include:

• Device inventory

• Graphical server views

• Health and monitoring

• Search and tagging

• vKVM or tunneled vKVM

• Firmware upgrades

• Advisories

• Hardware compatibility list (HCL) compliance

• TAC case creation

• Proactive RMA

• License operations

• UCS Manager launch

When the need arises to change or update traditional UCS servers’ configurations, Intersight provides a seamless and intuitive approach to access necessary configuration tools. Intersight is unable to directly configure or change policies on traditional UCSM domain infrastructure because UCSM acts as its own configuration manager. Intersight provides an option to directly interface with UCSM for blade and FI-attached servers or the IMC for standalone UCS servers.

Pass-through authentication is used with authorization via the operator’s current Intersight credentials and role-based access controls when these control planes are accessed from Intersight. While the Launch UCS Manager or Launch IMC action may load a web page closely resembling the actual UCSM or IMC interface, the resulting web pages are not actually presented by these interfaces. Instead, the resulting web pages are Intersight-constructed pages that use API calls to interact with the actual UCSM or IMC interfaces. To ensure that a security loophole is not introduced, the ability to configure Device Connector is disabled. Anyone enabling Intersight connectivity or changing Device Connector settings must have direct local access to the interface of the device being managed. (This concept of using Launch UCS Manager or Launch IMC is often referred to as using the “UCS Manager provider” or “IMC provider” to clarify the nomenclature and more accurately describe the connectivity to these interfaces.)

Intersight Managed Mode

Intersight Managed Mode (IMM) is an FI runtime mode that enables Cisco’s computing platform architecture, often referred to as Cisco’s “modernized compute architecture.” This modernized architecture has many similarities to traditional UCS domains, including FIs, server chassis, and servers. The two architectures are physically cabled the same way; a pair of FIs form the top-of-rack (ToR) switching fabric for the chassis and servers, ultimately coming together to form a UCS domain. While the terminology and physical attributes of the two architectures are identical, this is where the similarities end. The underlying software architectures and the governing control planes are fundamentally different.

A UCS domain can either be configured by an embedded UCSM instance for traditional UCS domains or by Intersight for modernized UCS domains. Traditional domains, running UCSM, are 100% dependent on UCSM to derive their configuration. Conversely, modern domains, configured by Intersight, have no embedded UCSM running in the Fabric Interconnects and are dependent on Intersight to derive their configuration. These modern domains are said to be running in Intersight mode. The domain mode is determined during the initial setup of a pair of Fabric Interconnects and cannot be changed or converted without reconfiguration of the domain.

Since Intersight mode is not dependent on an FI-embedded configuration control plane, it enables broader configuration scope. Intersight can configure the domain-based server infrastructure, and it can also use policy- and profile-based configuration methods to configure the domain switching fabric or Fabric Interconnects. All UCS infrastructure is defined by a policy managed by Intersight directly.

The following sections provide more details on this modern operational mode as well as how organizations can benefit from Intersight’s operational capabilities for both traditional UCSM and Intersight managed domains.

Benefits of Domains Running Intersight Mode

While Intersight can perform day-to-day operations for traditional UCS domains, the policy (or configuration) management is still handled at the individual domain level. In contrast, the policy for devices connected to a domain running in Intersight mode is managed and maintained by Intersight. This allows limitless scale for pools, policies, and profiles across an organization’s infrastructure, all within a single operational view.

For organizations with multiple Intersight managed compute domains, policies and pools become easier to consume and can be shared globally. The risk of identifiers, such as MAC addresses or Fibre Channel WWNs, overlapping across domains is removed, and existing policies can be reused in new domains located anywhere in the world.

An NTP policy, for example, can be shared among thousands of standalone rack servers, and that same policy can also be used by UCS domains in Intersight mode. Figure 4-7 shows an NTP policy used by both UCS server and UCS domain profile types.

Intersight’s ability to manage both standalone and domain-attached servers with a single policy model provides true administrative flexibility and configuration consistency, and it simplifies the operational burden whether the computer infrastructure is a handful of servers or a large, diverse, distributed server infrastructure.

Getting Started with Intersight Mode

There are minimum hardware and software requirements for running an FI with Intersight mode. The latest details for supported systems are available at https://intersight.com/help/supported_systems#supported_hardware_systems_and_software_versions.

The first step to getting started with IMM-compatible systems is to place the Fabric Interconnects in Intersight Managed Mode. A new FI presents the administrator with three questions (when connected to the FI serial port). An FI that was previously configured to run with UCS Manager must have its configuration erased before proceeding. Beginning with the primary FI, the questions and appropriate answers to enable Intersight Managed Mode are shown in Figure 4-8.

The FI then guides the administrator through a basic networking setup for the primary FI. Configuring the subordinate FI is even easier, as it can retrieve most of its settings from the primary FI. When connected to the subordinate FI serial port, the administrator answers the questions shown in Figure 4-9 and provides an IP address for the subordinate FI.

Once the initial configuration has been applied to the Fabric Interconnects, the FIs can be claimed into Intersight. This process is nearly identical to the process of claiming a standalone rack-mount server in Intersight. For the Fabric Interconnects, however, the administrator must connect via a web browser to the IP address of either FI to access the Device Console. The Device Console is a simple UI that presents a Device Connector screen for claiming the FI pair into Intersight.

Fabric Interconnects are Intersight targets that use Device Connector, which is discussed extensively in Chapters 1 and 2. Figure 4-10 will look familiar to anyone who has claimed other Cisco targets into Intersight. In Intersight mode, Device Connector in the Fabric Interconnects is responsible for maintaining connectivity to Intersight for all devices attached to the Fabric Interconnects, such as chassis, I/O modules, and blade servers.

Using the device ID and claim code from Device Connector, an administrator can initiate the claim process from Intersight by browsing to Admin > Targets and selecting Claim a New Target. For Intersight managed domains, the target type is Cisco UCS Domain (Intersight Managed), as shown in Figure 4-11.

Once a UCS domain has been claimed, it may take several minutes or longer (depending on the number of devices in the new domain) for Intersight to discover all the chassis, blades, and other devices connected.

Pools, policies, and profiles for the devices in the newly claimed domain can be created at any time—even before the domain is claimed.

Device Console

As previously mentioned, the Device Console is a UI that is accessed by browsing to the IP address of the primary or subordinate Fabric Interconnect operating in Intersight mode. The Device Console provides some basic system health information, and it has two primary purposes:

• The Device Connector is accessed through the Device Console and is required in the Intersight claiming process.

• The Device Console provides local KVM and API access to any attached servers for authenticated users. Administrators can access the KVM or API through Intersight as well, so the Device Console can function as a secondary access method in the unlikely event that Intersight becomes inaccessible from the data center. KVM access is shown in Figure 4-12.

Ideally, administrators should not need to access the Device Console after the initial device claiming is complete.

Chassis Profiles

Each chassis in an Intersight mode domain is configured using a chassis profile.

Chassis profiles are created much as other profiles are: You select Configure > Profiles and browse to the Chassis Profiles tab. From there, you can clone an existing chassis profile or create a new one.

A chassis profile consists of policies such as the following that can be defined in advance or created inline while creating a new profile:

• The IMC Access policy selects the IP address pool and VLAN to be used for assigning IP addresses to the IMC of each installed blade. The IP address pool can be previously defined or created inline.

• The SNMP policy defines the SNMP settings and trap destinations to be used for alerts.

Note that while both policies are technically optional, a blade cannot be managed without an IP address for the IMC. For this reason, the IMC Access policy with a valid IP address pool is effectively required.

Hybrid Domain Operations

For organizations with upcoming greenfield server deployments, it is recommended to deploy in Intersight mode. This enables Intersight as the configuration/policy manager for all the modernized infrastructure and provides unparalleled operational and scale benefits.

Organizations with existing traditional UCS domains typically have adapted their operational practices for efficient management of these platforms. These organizations have built procedures and invested in tools centered on the most efficient ways to meet their business objectives. Intersight adds enhanced operational capabilities for these brownfield environments without altering existing practices. Many of the Intersight benefits can be realized at no additional cost. If more advanced capabilities are desired, such as HCL compliance or advisories, a fee-based license can be applied. Each server can be licensed at a different tier, depending on its specific requirements.

A design principle with Intersight is to enable a no-impact transition for adoption. This refers to both the impact of Intersight on the infrastructure as well as the impact on operational processes maintaining the infrastructure. Cisco does not want to force an organization to adopt Intersight for configuration and policy-related tasks. This philosophy allows Intersight to embrace these traditional UCS domains and provide the benefits of Intersight for operational functions against traditional domain infrastructure while also providing a mechanism to make configuration changes against the traditional domain infrastructure using integration to legacy interface providers. From an organization’s perspective, this provides the best of both worlds; the organization can maximize the benefits of Intersight while not disrupting its current operational processes or incurring unnecessary risk in business continuity.

Standalone Server Updates

Updates for rack servers can be selected from either the Cisco repository or a local repository that an organization creates. When an update is initiated from Intersight, all the firmware components in the server—including the BIOS, Cisco IMC, PCI adapters, RAID controllers, and other firmware—are updated to compatible versions using a behind-the-scenes tool known as the Cisco Host Upgrade Utility (HUU). Intersight retrieves the firmware from either cisco.com or a local repository and initiates the HUU in a non-interactive mode to complete the update. By default, all server components are upgraded, as are drives; in addition, an advanced mode allows you to exclude individual hard drives from being upgraded during the automated process.

To download the firmware directly from Cisco, Intersight will utilize the Utility Storage option in the server. As shown in Figure 4-13, you must select Cisco Repository rather than Software Repository to see a complete list of firmware available from cisco.com. Once the correct version is selected and the update process is initiated, the firmware download to the Utility Storage begins. The installation starts on the first boot after the download is complete.

To use a local repository for updates, an organization needs to set up a network share (NFS, CIFS, or HTTP/S) that contains previously downloaded firmware images. Updates using the local software repository begin immediately.

UCSM Server Updates

Updates for UCS blade servers are downloaded directly from intersight.com. Much as with rack servers, all the server components (BIOS, Cisco IMC, PCI adapters, RAID controllers, and so on) are upgraded, as are storage drives. Advanced mode can be used to exclude particular storage drives or controllers from an upgrade.

A blade server may be upgraded in Intersight if it has a server profile from UCS Manager attached. However, if a server has a global server profile from UCS Central, it cannot (at this time) be updated from Intersight.

Once the update process is initiated from Intersight, the selected firmware image is downloaded to the Fabric Interconnect to which the server is attached, and a check is performed locally to determine whether the server requires a reboot.

UCS Domain Updates

FI switches are a powerful aspect of the UCS blade architecture but can be challenging to update due to their importance in the infrastructure. Because all data and management traffic for many servers can be dependent on a pair of switches, firmware upgrades must be handled with due diligence to ensure that there is no service disruption. Intersight brings an added layer of intelligence for this type of process, making the outcome much more reliable than if it is performed manually.

When the update process for FIs is initiated from Intersight, the selected firmware bundle is automatically downloaded from intersight.com, which eliminates the need for an operator to log in to cisco.com, manually select one or more firmware bundles, download the bundles to a local machine, and then individually upload those bundles to the appropriate FIs. This streamlined, intelligent process not only provides a quicker, more efficient upgrade approach for a single UCS blade server domain but also ensures that the process is consistently executed across multiple blade server domains.

As an example of this consistency, by default, the upgrade from Intersight initiates traffic evacuation. This ensures that traffic will fail over to the primary FI before an upgrade begins on the subordinate FI by disabling the host interface ports on the I/O module connected to the subordinate FI. Figure 4-14 shows that disabling host interface ports forces traffic through the primary FI.