Showing posts with label VCE vBlock. Show all posts
Showing posts with label VCE vBlock. Show all posts

Calculating queue depth

You might need to tune your FC queue depth on the host to achieve the maximum values for hosts per controller and FC port fan-in. The maximum number of LUNs and the number of HBAs that can connect to an FC port are limited by the available queue depth on the FC target ports.

About this task
Queue depth is the number of I/O requests (SCSI commands) that can be queued at one time on a storage controller. Each I/O request from the host's initiator HBA to the storage controller's target adapter consumes a queue entry. Typically, a higher queue depth equates to better performance. However, if the storage controller's maximum queue depth is reached, that storage controller rejects incoming commands by returning a QFULL response to them. If a large number of hosts are accessing a storage controller, plan carefully to avoid QFULL conditions, which significantly degrade system performance and can lead to errors on some systems.
In a configuration with multiple initiators (hosts), all hosts should have similar queue depths. This prevents hosts with small queue depths from being starved by hosts with large queue depths.
The following general recommendations can be made about "tuning" queue depths.
  • For small to mid-size systems, use a HBA queue depth of 32.
  • For large systems, use a HBA queue depth of 128.
  • For exception cases or performance testing, use a queue depth of 256 to avoid possible queuing problems.
  • All hosts should have the queue depths set to similar values to give equal access to all hosts.
  • Ensure that the storage controller target FC port queue depth is not exceeded to avoid performance penalties or errors.
Steps
  1. Count the total number of FC initiators in all the hosts that connect to one FC target port.
  2. Multiply by 128.
    • If the result is less than 2,048, set the queue depth for all initiators to 128.
Example
You have 15 hosts with one initiator connected to each of two target ports on the storage controller. 15 x 128 = 1,920. 1,920 is less than the total queue depth limit of 2,048, so you can set the queue depth for all your initiators to 128.
    • If the result is greater than 2,048, go to step 3.
Example
You have 30 hosts with one initiator connected to each of two target ports on the storage controller. 30 x 128 = 3,840. 3,840 is greater than the total queue depth limit of 2,048, so you should choose one of the options under step 3 for remediation.
  1. Choose one of the following options.
    • Option 1:
      1. Add more FC target ports.
      2. Redistribute your FC initiators.
      3. Repeat steps 1 and 2.
Example
The desired queue depth of 3,840 exceeds the available queue depth per port. To remedy this, you can add a two-port FC target adapter to each controller, then rezone your FC switches so that 15 of your 30 hosts connect to one set of ports, and the remaining 15 hosts connect to a second set of ports. The queue depth per port is then reduced to 15 x 128 = 1,920.
    • Option 2:
      1. Designate each host as "large" or "small" based on its expected I/O need.
      2. Multiply the number of large initiators by 128.
      3. Multiply the number of small initiators by 32.
      4. Add the two results together.
      5. If the result is less than 2,048, set the queue depth for "large" host to 128 and the queue depth for "small" host to 32.
      6. If the result is still greater than 2,048 per port, reduce the queue depth per initiator until the total queue depth is less than or equal to 2,048.
Note: To estimate the queue depth needed to achieve a certain I/O per second throughput, use this formula.
Needed queue depth = (Number of I/O per second) x (Response time)
For example, if you need 40,000 I/O per second with a response time of 3 milliseconds, the needed queue depth = 40,000 x (.003) = 120.
Example
The desired queue depth of 3,840 exceeds the available queue depth per port. You have 10 "large" hosts that have high storage I/O needs, and 20 "small" hosts that have low I/O needs. Set the initiator queue depth on the "large" hosts to 128 and the initiator queue depth on the "small" hosts to 32.
Your resulting total queue depth is (10 x 128) + (20 x 32) = 1,920.
Example
You can spread the available queue depth equally across each initiator.

Your resulting queue depth per initiator is 2,048/30 = 68

Thanks to Link

An Overview of Cisco Nexus 1000v in vSphere Environment:

The idea behind the distributed switch is to have one place to do the configuration and management of the network connectivity for your entire ESXi cluster.  With Standard Switch, we have to manually create vSwitches and Port Groups on every ESX server.

With the distributed switch we configure the Port Groups in vCenter. When a new ESX server moves in to the cluster and is joined to the dvSwitch, it automatically gets the configuration.

Components of the Nexus 1000v:

The Cisco Nexus 1000V is a virtual access software switch that works with VMware vSphere and has the following components:

Virtual Supervisor Module (VSM)
Virtual Ethernet Module (VEM

Virtual Supervisor Module:

It is the control plane of the switch and a virtual machine that runs NX-OS.

The VSM is a virtual version of a hardware supervisor module.  Usually Cisco switches have a chassis switch with multiple blades wit one or more Supervisor Modules.  These hardware supervisor modules are the management cards for the entire chassis.  Some switches have redundant modules and the Nexus 1000v is no different. 

To provide fault tolerance you can run a second VSM in a standby role.  The secondary VSM will take over if the primary should fail.  Any configuration change on the primary is automatically replicated to the secondary as well

Virtual Ethernet Module:

VEM is a virtual line card embedded in each VMware vSphere (ESX) host. The VEM is partly inside the kernel of the hypervisor and partly in a user world process, called the VEM Agent.

So just like you log in to a Cisco chassis switch and do a “show modules” you’ll do the same here.  Each ESX server will be its own module.  And that’s why it’s called a Virtual Ethernet Module.

How the Modules Communicate?

Management, Control, and Packet VLANs

The Management VLAN is used for system login, configuration. and corresponds to the mgmt0 interface. The management interface appears as the mgmt0 port on a Cisco switch, and is assigned an IP address. Although the management interface is not used to exchange data between the VSM and VEM, it is used to establish and maintain the connection between the VSM and VMware vCenter Server.
The management interface is always the second interface on the VSM and is usually labeled Network Adapter 2 in the virtual machine network properties.
The Control VLAN and the Packet VLAN are used for communication between the VSM and the VEMs within a switch domain. The VLANs are used as follows:
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifThe Packet VLAN is used by protocols such as CDP, LACP, and IGMP.
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifThe Control VLAN is used for the following:
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifVSM configuration commands to each VEM, and their responses
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifVEM notifications to the VSM, for example a VEM notifies the VSM of the attachment or detachment of ports to the DVS
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifVEM NetFlow exports are sent to the VSM, where they are then forwarded to a NetFlow Collector.
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifVSM active to standby synchronization for high availability.
You can use the same VLAN for control, packet, and management, but if needed for flexibility, you can use separate VLANs. Make sure that the network segment has adequate bandwidth and latency.

Port Profiles:

A port profile is a set of interface configuration commands that can be dynamically applied to either the physical (uplink) or virtual interfaces. A port profile specifies a set of attributes that can include the following:
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifVLAN
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifport channels
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifprivate VLAN (PVLAN),
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifACL
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifport security
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifNetFlow
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifrate limiting
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifQoS marking
The network administrator defines port profiles in the VSM. When the VSM connects to vCenter Server, it creates a distributed virtual switch (DVS) and each port profile is published as a port group on the DVS. The server administrator can then apply those port groups to specific uplinks, VM vNICs, or management ports, such as virtual switch interfaces or VM kernel NICs.
A change to a VSM port profile is propagated to all ports associated with the port profile. The network administrator uses the Cisco NX-OS CLI to change a specific interface configuration from the port profile configuration applied to it. For example, a specific uplink can be shut down or a specific virtual port can have ERSPAN applied to it, without affecting other interfaces using the same port profile.

Administrator Roles  
Network Administrator 
Server Administrator 
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifCreates, configures, and manages vSwitches.
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifCreates, configures, and manages port profiles, including the following:
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifsecurity
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifport channels
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifQOS policies
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifAssigns the following to port groups:
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifvNICs
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifvmkernel interfaces
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifservice console interfaces
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifAssigns physical NICs (also called PNICs).

Contrasting the Cisco Nexus 1000V with a Physical Switch:

The following are the differences between the Cisco Nexus 1000V and a physical switch:
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifJoint management by network and server administrators
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifExternal fabric 
The supervisor(s) and line cards in a physical switch have a shared internal fabric over which they communicate. The Cisco Nexus 1000V uses the external fabric.
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifNo switch backplane
Line cards in a physical switch can forward traffic to each other on the switch's backplane. Since the Nexus 1000V lacks such a backplane, a VEM cannot directly forward packets to another VEM. Instead, it has to forward the packet via some uplink to the external fabric, which then switches it to the destination.
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifNo Spanning Tree Protocol
The Nexus 1000V does not run STP because it will deactivate all but one uplink to an upstream switch, preventing full utilization of uplink bandwidth. Instead, each VEM is designed to prevent loops in the network topology.
http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gifPort channels only for uplinks 
The uplinks in a host can be bundled in a port channel for load balancing and high availability. The virtual ports cannot be bundled into a port channel, since there is no reason to.


Thanks to Site1 and Site2

Provisioning ESXi hosts and Datastores using Standard Service on UIMP

Base infrastructure needs to be in place:
1.Base hardware installed, racked, and cabled
2.Infrastructure components must be configured for management
  e.g. Cisco UCS Management IP must be in place
3.Certain policies must be pre-configured on the infrastructure
  SAN Boot policy, no local disk policy, QoS policy, Chassis Discovery Policy, etc.
4.UIM OS Installation VLAN must be preconfigured
  Supports installation of OS (hypervisor) to a blade
5.VLANs, PIN Groups, and VSANs must be configured
  Adding ports to VLANs and VSANs
6.(Thin) Storage Pools, Storage Groups, or RAID Groups must be  preconfigured
7.FAST Policies should be preconfigured

Provisioning through UIMP is a five-step process:
  1. Discover Infrastructure and Create Address Pools
  1. Grading of resource pools and profiles
  1. Package pools and profiles into Service Offerings
  1. Publish Service Offerings in Service Catalog
  1. Create an Infrastructure Service from a Service Offering


1.       Log-in to UIMP with sysadmin credentials and navigate to “Asset Discovery” tab

a.       Rediscover the “Compute Systems, Storage systems, Switches (Network and MDS Switches), VMware vCenters ” and other required components for the respective vBlock

2.       Navigate to “Resource Planning” Tab and add “Grade Name” for the new blades

a.       Apply the Grade Name to the new Blades

3.       Create a “Standard Service Offering” from the “Service Planning” tab and enter the following information for the New Service Offering

a.       Give a Name and ESXi OS version
b.      Select the Grade name created for new Blades with required values for Minimum, Maximum and Default Blades and click “save”
c.       Select a Grade for Storage (for boot volume) with required values for Minimum and Combined Maximum in GB and click “Save”
d.      Select the vBlock Name, Switch A and all VLANS for the Network Profile and click “save”
e.      Select the vBlock Name, Switch B and all VLANS for the Network Profile and click “save”
f.        Edit the VMware Cluster and Provide HA, DRS and other settings

4.       Now create a new service (with all required information” from Service Offering created earlier
a.       Check all the settings in General tab
b.      Click on Servers Tab and assign IP, Hostname, BIOS Policy details, etc to all the Blades
c.       Set root password for all the hosts
d.      Click on Storage Tab and verify all the settings
e.      Add all the available ports for vhba-a
f.        Save all the settings
g.       Add all the available ports for vhba-b
h.      Save the settings

5.       Finally select the service created and click “provision” to start the provisioning
a.       Workflow can be seen in the Service History tab




CIMC Overview

Ø  Cisco Integrated Management Controller (CIMC) is used for management/monitoring of C-Series Rack servers and B-Series Blade Servers.

Ø  CIMC provides options like WebGUI, CLI and IPMI for management/monitoring tasks.

Ø  CIMC runs on a separate chip on the C-Series servers and thus is able to provide services in case of any major hardware failure or system crash.

Ø  CIMC also does user management tasks and supports user access levels of Admin (Full access), User/Operator (can change host features but not CIMC) and Read Only (can only see information).

Ø  CIMC uses IPMI to monitor thermal and voltage sensors in the servers.

Ø  CIMC is useful for initial configuration of the server and troubleshooting any problems in server operation; however CIMC cannot be used for tasks like deploying an OS, deploying software patches, install software applications and manage external storage on SAN or NAS.


Checking the queue depth of the storage adapter and the storage device

Purpose

This article provides the steps to identify the queue depths for the storage adapter and the storage device from the service console of the ESX host or the ESXi shell (Tech Support mode).

Resolution

To identify the storage adapter queue depth:

1. Run the esxtop command in the service console of the ESX host or the ESXi shell (Tech Support mode).
2. Press d.
3. Press f and select Queue Stats.
4. The value listed under AQLEN is the queue depth of the storage adapter. This is the maximum number of ESX VMKernel active commands that the adapter driver is configured to support.

To identify the storage device queue depth:
1. Run the esxtop command in the service console of the ESX host or the ESXi shell (Tech Support mode).
2. Press u.
3. Press f and select Queue Stats.
4. The value listed under DQLEN is the queue depth of the storage device. This is the maximum number of ESX VMKernel active commands that the device is configured to support.
Notes:
·    The value listed under LQLEN is the LUN queue depth. This is the maximum number of ESX/ESXi VMkernel active commands supported by the LUN.
·    The value listed under %USD is the percentage of queue depth (adapter, LUN, or world) used by ESX/ESXi VMkernel active commands.

Upgrading Cisco UCS Firmware

This steps helps us in upgrading Cisco UCS Firmware from 2.0(5a) to 2.1(3c) following VCE Matrix 4.0.11

1.     Download UCS Firmware:-

UCS firmware has to be downloaded in two bundles.

a.       Cisco Infrastructure software bundle: Includes firmware for all components like Fabric Interconnect, IO Modules & UCS manager.
b.      UCS B-Series Blade servers software bundle: Includes firmware for blade components CNA , CIMC, BIOS and baseboard.
c.       Uploading these bundles in to UCS domain either through TFTP or Local file system.

2.     Prerequisites :-

a.       Taking configuration backup.
b.       Verifying the cluster status of Fabric Interconnect under Equipment TAB à Fabric interconnect
c.        Verifying Eth data path (# show int br)
d.      Verifying FC data Path (#show flogi database , # show flogi-table)

3.     Updating the Server F/W using  Host Firmware Package

By using F/w package, we can upgrade server, adopter, CIMC and BIOS.  This policy enables to choose the set of f/w versions.

1.       Go to Server tabàPolicyàHost firmware
2.       Create the new policy in the name of 2.1(3c)
3.       Select the bios , adopter , CIMC along with blade model (B200 M2 , B230 M2 & B200 M3)
4.       Disassociate the service profile from the server that is going be updated first
5.       Map the host f/w package 2.1(3c) in that service profile and associate it again to the same server.
6.       Monitor the status of FSM and check the updated f/w once FSM is 100% complete
7.       Repeat the steps for other remaining servers.


4.     Updating the Infrastructure components

 Infrastructure components include IOM , UCS Manager and Fabric Interconnect. Below are the steps to followed post server upgrade.

1.       Go to f/w managementà Installed f/w .
2.       Select IOM and select 2.1(3c) in drop down for IOM 2
3.       Right click and select update f/w and select the version 2.1(3c)(check force box)
4.       Right click and select activate f/w and select 2.1(3c) and enable “Ignore Compatibility Check”
5.       Wait for IOM 2 to come online and follow the same steps for IOM 1 also.
6.       Right click the UCS Manager and select “Activate Firmware” and enable “Ignore Compatibility
7.       Once UCS manager comes online upgrade the Fabric Interconnect
8.       Right click the fabric Interconnect B (secondary) and activate Kernel first and System next
9.       FI will reboot
10.   Repeat the step 8 for Primary FI A and during reboot B will become Primary and A will become Secondary after reboot.
11.   Change the cluster Ownership back to A and verify all the components F/w wrt 2.1(3c).


Post to the Upgrade running version of f/w will be 2.1(3c) and backup version will be 2.0(5a)