- Base Implementation UCS. 3
- Initial configuration (on site). 3
- GUI (remote) connectivity. 5
- Setting Up KVM Management IPs for Blades. 6
- Port configuration. 7
- Chassis discovery. 10
- Installing Servers. 12
- Creating VLANs. 12
- Create Organizations. 13
- Create policies and pools in organization. 13
This document will give a short overview of the UCS implemtation at Telkom SA Bellville. It is not a runbook but rather a reference to which parameters have been used for the quickstart implementation. In conjunction with the official UCS documentation it is possible to reinact the installation, which will be helpful when the UCS goes production.
For physical cabling please reference the Logical Site Prep that will be distributed with this document.
When the UCS is powered on for the first time it needs to be configured directly via serial to provide the first parameters. This is done via the Cisco typical console port (found on the fabric interconnects (FI)), which requires a special cable (supllied with the UCS). Use any serial terminal program to connect using the following parameters:
UCS configuration can be done on any of the fabric interconnects first, which will then automatically become fabric interconnect A (FI A). The following configuration gives an overview of the parameters needed for the first interconnect:
|IP for FI 1||10.145.3.8/25|
|IP for FI 2||10.145.3.9/25|
Connect to the other Node as with the first. The second Fabric Interconnect (FI B) requires less information as it will connect to FI A and sync most information.
Now that the base configuration has been done, it is possible to connect to the management network. This is done via a browser (Internet Explorer or FireFox) Please ensure that the newest version of Java is installed and that security settings in the browser are set to allow the application to run.
Type in the Virtual IP configured in the previous step into the browser:
Click on the Launch button to start the UCS Manager Java application. The first time this is done for a specific firmware level, the application will we downloaded onto the local management machine which can take up to 2 minutes. There will be a login request. For the purposes of this document, the admin user will be used for full rights, please note that in a production environment you should designate user with specific rights.
The UCS requires a management address for each blade to allow KVM sessions and virtual media connectivity. This is done by assigning a pool of IP addresses that the UCS assigns to each blade.
|ChassisNr||Start IP/Subnet||End IP(8 per Chassis)||Gateway|
|1 and 2||10.145.3.11/25||10.145.3.26||10.145.3.1|
The pool of admin addresses is set up in the UCS manager GUI:
A freshly installed UCS will not find it chassis automatically. It is necessary to define which ports on the FIs are connected to the chassis and which are used to connect to the network.
This is a simple process that requires the following steps:
The UCS comes with fixed ports on the FI and expansion ports for the GEM slot. Only the fixed ports can be used to connect Server Ports.
Initially all ports will be “Unconfigured Ports” simply drag and drop the correct ports into “Server Ports”
From the Logical site prep guide, it can be seen that the following ports are connected to the chassis:
Note: Keep in mind that all configuration done on FI A must also be done on FI B. Tho not mandatory, it is highly recommended that identical configurations are used for both FIs
In a similar fashion drag and drop the ports connected to the upstream network by dragging them from “Unconfigured ports” to “Uplink Ethernet Ports”.
|Portchannel Name||Fabricinterconnect/UCS Ports||Northbound Switchname/Port|
|Portchannel 39||FI A/1/1||Switch1/??|
|Portchannel 39||FI A/1/2||Switch2/??|
|Portchannel 40||FI B/1/1||Switch1/??|
|Portchannel 40||FI B/1/2||Switch2/??|
In this case, ports 3 and 4 on each FI have already been configured for future expansion, even though no physical cabling exists.
For this implementation the UCS is connected via VPC to two Nexus 7K in the following fashion:
From the UCS perspective, the ports must be configured in a simple port channel as seen in the table above:
Keep in mind that this must be done for both sides with a different port channel (In this case 39 for FI A and 40 for FI B)
In case any configuration changes are done to the port channel, it may be necessary to re enable the portchannel from the UCS manager:
The SAN is configured equally easily. FC ports can be found on the expansion ports. If VSAN technology is used it is necessary to first create a VSAN that can be assigned to each FC port. Though it is possible to create different VSANs for different ports it is best practice to configure the same VSAN for all ports on one specific UCS (different ports should only be used if “FC pinning” is used thereby splitting FC traffic for very high secure environments)
Click on each FC port and select the correct VSAN:
Dont forget to repeat the same steps for all FC ports. When new ports are connected to the SAN switch, it may be necessary to re enable the FC Ports that have been added.
The moment the Server Ports were configured, the UCS will automatically discover connected chassis, it will however only configure the first Server link per IOM( there are two IO Modules situated in the chassis) therefore limiting the bandwidth to the minimum configuration of 20 GBit per chassis. To make use of the additional connections (in this case there are two connections per IOM which means there are 4 connections in total for 40 Gbit per chassis) it is necessary to “acknowledge” each chassis separately.
NOTE: Please keep in mind that “achnowledging a chassis can be a disruptive process for all blade that are in that specific chassis.
Repeat the process for every chassis separately . Check if all connections have been acknowledged by navigating to the IOM modules of each chassis:
All VLANs that pass through the FIs must be explicitly allowed for each interface. To do this, VLANs must be defined in the LAN tab and given a name. Note that when assigning VLANs to interfaces, only the given name will appear in the selection, so it may be a good idea to add the VLAN number to the name. Once a VLAN is defined it is NOT possible to rename it, and it must be deleted and recreated.
The UCS has the ability to split up resources into different tenancies. For this to work efficiently, it is necessary to create sub organizations. As a default, the base level is always the root level, on which there is full administrative access. Though it is possible to work on this level only ,it is best practice to create sub organizations in order to restrict access on organizational level.
For each organization it is possible to create separate policies that can only be used within that organization or sub organizations within. In this document we will look at the most important ones used in this implementation. It may however be well worth looking at the other ones, as these generally can save quite a bit of repetitive configuration.
Boot policies can be used to determine in which way a service profile should access its boot devices. This is particularly important in a SAN boot environment, where it is necessary to specify SAN boot targets. Tho this configuration could be done for each Service profile individually, it is highly recommended that this put in a profile with the correct settings.
The boot policy requires a unique name and description. Add local bootdevices if needed (CD-ROM). After that add the SAN boot HBAs. In this configuration each blade has 2 HBAs, and it is possible to specify primary and secondary boot HBA.
Each HBA can have two boot targets, which must be zoned accordingly to the correct LUN.
Repeat the process above for secondary boot target and do the same for the second HBA (vhba1). If everything is set up correctly the result should look like this:
Each object in a virtualized environment makes use of an unique identifier called the UUID. As the name states this value must be unique within the domain of servers. The UCS Manager can draw suck UUIDs from predefined pools, and will ensure uniqueness within the UCS domain.
It is possible to create such a pool globally for the whole UCS domain, or specifically for each suborganization.
UUIDs are split up into a prefix and a suffix. While the prefix remains the same, it is possible to create multiple suffix blocks within one pool.
With the service profile technology, the physical blade used to run a specific profile, can be selected manually, or grouped together in a pool. The latter allows the service profile to select available resources as needed, irrespective of the physical slots currently populated in the chassis. This allows for greater flexibility and transparency. Since a service profile will select the next available blade in a pool automatically, it is best practice to pool blades with similar hardware configurations. As with UUID pools, server pools can be created globally for the whole UCS or specific for a suborganization.
For this implementation a server pool with 24 GB ram and Qlogic CNAs is formed across all blades in the chassis.
Simply add all blades to the pool that may be used by the service profiles assigned to this specific pool.
There are other pools and policies that can be used to setup default parameters.
A Service Profile is a collection of data used to set the unique identifiers of a server and the operational parameters used to run it. For the UCS, a service profile is synonymous for a traditional server, making use of the resources, pools and policies defined earlier in this document. The UCS has two different wizards to create a service profile, the expert wizard offering more options and allowing for advanced features like multiple VLANs etc. In this example only the expert wizard will be utilized.
Each Service Profile needs a unique identifier, which is also the title of the actual profile. Using the hostname of the actual server makes it easier to administer Service profiles later.
Additionally a UUID needs to be set for this specific profile. Selecting a pool will automate this process, tho it is possible to assign a UUID manually.
Even if booting from SAN, if physical local disks are present, it is necessary to configure the local storage. This can be done with a policy or simply for each Service Profile.
Additionally if HBAs are used a WWNN must be set for the adapter.
The Menlo CNA has the ability to create up to two HBAs. Click on the “Add” button to add a HBA to the list. Each of these HBAs needs a WWPN and a few specific settings. The following table specifies the settings for both HBAs.
Similary up to two network adapters are supported for the Menlo CNA. In order to use multiple VLANs via a trunk, it is necessary to use the “expert” LAN configuration.
Click the Add button to add a vnic.
Each vnic needs specific settings and a MAC address. As with the HBAs it is possible to assign these MACs via a pool or manually for each adapter.
|VNIC||FABRIC||Failover||VLAN Trunking||Adapter Policy|
Additionally all VLANs that will be used on this interface (even via virtual machines) must be allowed specifically for each adapter. Below is a configuration of vnic0:
For this dialog just leave the default setting “Let System Perform Placement.
Each Service Profile needs a boot order. This was already configured in the Boot policy section of this document, and therefore only needs to be selected.
This dialog allows to manually specify which physical blade is associated to this Service Profile, or allows to utilize a Pool.
Click on the “Finish Button after this dialog. Once the Service profile has been created, click on it and navigate to the general tab as shown below.
Initially the Overall status will be in “config”, meaning that the Service Profile is being applied to the physical blade. If everything was configured correctly the Overall Status should be “OK”. If the Overall Status is “config-error”, something was done wrongly in the configuration, or a resource is being assigned that does not physically exist (example assigning 3 network cards to a Menlo CNA).
Once the Service Profile is up and running it is necessary to connect to it via the KVM applet found on the General Tab of the Service Profile.
The KVM applet allows to connect to local drives of the management station and even ISO files located locally. Select Tools and Launch Virtual Media.
For mounting an ISO file, select Add Image and browse for the correct file locally
Finally enable the drive by enabling the mapped checkbox next to the correct image.
Once mounted boot and install server like any other depending on the boot order that was specified in the Boot Policy.
Note: Do NOT close this window as the virtual media session will close and the connection will break off.
To install the Virtual Ethernet Module of Nexus 1000V onto the ESX host, copy the newest file to any location on the ESX host and execute the following command in the directory the VEM file has been copied. Though a reboot is not necessary it is highly recommended.
The future holds great promise when it comes to the cloud. It’s no secret cloud computing has taken off in recent years with new innovations and business applications. But figuring out where cloud computing will be by the end of the decade can be difficult for those who don’t know what cloud computing is.
Organizations finding cloud computing to be more cost-effective in the long-term are waiting to discover how cloud computing will evolve and what it’ll mean for their future. Here are a few predictions for companies and where cloud computing will be in 2020.
More application availability on the cloud
It’s predicted that by 2020, more than a quarter of all applications will be available via cloud. About 56 percent of enterprises consider cloud to be a strategic differentiator while about 58 percent of enterprises spend more than 10 percent of their annual budgets on cloud services. Researchers predict there will be more than 8.2 billion active mobile devices by 2020 with the trend of more and more applications on the cloud to follow. Software will be on tap via cloud since the cloud makes it possible to rapidly build and deploy applications leading to better technology and faster response times. It’ll make it possible for organizations to get what they want on-demand.
More hybrid cloud adoption and increased cloud development
Some industry leaders say that 50 percent of companies will have hybrid cloudsas early as 2017. CIOs will be pushing for more strategies implementing the cloud although they won’t always be pure cloud implementations since it can be very difficult to do so. The hybrid cloud provides a combination of strengths like management convenience and on-premise solutions. CIOs can expect to see more resources going towards cloud development since 85 percent of new software is being built with the cloud in mind. Enterprises can expect to see an increase in third-party, enterprise and commercial developers and contributors to cloud application ecosystems, marketplaces, and API exchanges
Say goodbye to the traditional infrastructure
It’s expected by 2020 that CIO will not be able to draw a map of their infrastructure if asked due to the evolving characteristics of the cloud. Software can be expected to almost completely float away from hardware since companies are already starting to find many valuable applications available online while eliminating the need to keep purchasing new servers. Companies can also expect individual software applications to get larger and more complex for scalability. Since applications will only get larger, the emphasis will be on modular software. Modular software are large applications with components that can be modified without shutting down the entire program. This will require a new approach to technology by CIOs and their department.
A study released by Rackspace and conducted by Vanson Bourne argues improving resilience and security remain in the top three motivations for businesses moving to the cloud in 2016.
The survey, which polled 500 UK IT and business decision makers, found reducing IT costs (61% of respondents) as the most popular reason for migration, ahead of resilience and disaster recovery (50%) and security (38%). While these reasons have long since been considered when companies move data to the cloud, according to Rackspace chief security officer Brian Kelly 2016 may represent a tipping point.
“Cloud has long been associated with a loss of control over information, but more and more businesses are now realising this is a misconception,” he said. “Organisations are increasingly seeing the cloud as a means to keeping their systems and information safe and in the year ahead security will be an accelerator, not an inhibitor, of cloud adoption.”
Part of this change is that security hurdles are becoming easier to clear. Only one in five (20%) respondents said they encountered problems meeting security and privacy requirements, while consulting expert advice reduced the chances of issues (17% compared to 26%). Yet overall security concerns pervade; in particular, businesses are worried about meeting security requirements (48%), losing control of data to a third party provider (39%), and cost of migration (39%) above others.
Interestingly, more than half of those polled (58%) said they moved business critical data over to the cloud first, either alone or at the same time as non-critical data. Meanwhile, companies using a third party supplier had fewer security concerns than those who went it alone.
“Many businesses do not have the expertise or budgets to combat a growing number of sophisticated cyber-attacks in house, but using the cloud – with the support of a team which is able to dedicate a large number of resources to security – will help to keep data safe at the fraction of the cost,” added Kelly.
Over the course of 2015, we’ve seen many of the trends we predicted last year come to fruition. As cloud adoption in the UK soared past 84% in May, it was evident that we had been right that the technology would become even more mainstream. With enterprises aiming to become more mobile, 2015 has also seen the normalisation of “anytime, anywhere working” and the increased dependency on IT to help drive business transformation.
With over two-thirds of IT departments set to increase their operational IT budgets in 2016, it does not look like the importance of IT in driving business goals will diminish anytime soon – the question really lies in how. Although we don’t have a crystal ball that we can look into to predict anything with certainty, there are some trends emerging that we see shaping the enterprise IT in the year ahead:
Businesses will have to use IT to evolve
It is no longer sufficient “just” to be the best in your industry. Businesses across all industries will need to examine their untapped data assets to drive the next wave of innovation and competition. Disruptive technologies have changed the potential of businesses of all sizes, and within each industry there will be those that will effectively leverage data assets to drive unprecedented levels of competition in 2016.
The nature of security will continue to change rapidly
As we’ve seen over the past 18 months, the nature of the threat has changed in fundamental ways. No longer is perimeter based security sufficient – if it ever was in the first place. More than ever, a deep, granular, distributed security model will be needed. Advances in software defined networking combined with other non-traditional approaches (think beyond IP and port ACLs!) will be what enables IT to keep pace with the evolving threat.
Understanding for how to map application portfolios to many cloud models will grow
Insomuch as mainframes still exist (indeed are a growth area for some), so will on premise IT, private cloud, boutique cloud, and hyper scale cloud. All will continue to remain relevant. Much of the new development, so called “born in cloud” applications, is likely to align with the hyper scale cloud, while the vast majority of existing enterprise applications may not.
The value proposition of hyper scale cloud will be stemmed by shortage of truly able developers
There is already a shortage of developers that can truly capitalise on the value of hyper scale cloud. Indeed, many “born in cloud” applications are really just traditional designs deployed to the cloud. Applications, even newly developed ones, often rely on the infrastructure layer to provide resilience. The next generation of applications engineered to provide resilience at the application layer – i.e. those that can tolerate infrastructure failure – will suffer until this developer shortage is addressed. Unlikely to end in 2016, this is long term problem that will require one or more higher education cycles to fully resolve.
There will be a resurgence of the private cloud…but not for long
Early adopters of public cloud will re-evaluate the commercial fit of private cloud – and late adopters may move directly to private cloud due to regulations and compliance needs. Cloud economics are compelling for a wide variety of use cases, but a CAPEX investment supporting a stable, long term application base often makes sense. In addition, many regulatory bodies regularly lag behind in innovation, and private cloud often addresses compliance obligations while still providing many of the benefits of public cloud. However, this resurgence is likely to be short lived as regulatory bodies catch up, applications evolve, and more flexible pricing models for public cloud prevail.
As we move into 2016, it’s clear that organisations will continue to look to their IT teams to remain competitive – both for developing new business solutions and meeting existing challenges. As such, it’s important that they are prepared to tackle the biggest hurdles and continue to take advantage of the opportunities that IT presents to the enterprise.
I hope this time most of the VMware administrators will be busy with upgrading their infrastructure to vSphere 6. There are some rare situations in which your ESXi upgrade to 6.0 may fail due to some old firmware or drivers or may be whatever reasons. Most of the administrators will be aware about rolling back vCenter or VM upgrade by reverting it to previous snapshot. Most of them may be unaware about the rolling back your ESXi upgrade. This post explains you the procedure to roll back your ESXi 6.0 upgrade to previous version i.e ESXi 5.5.
Procedure to Downgrade or Rollback your ESXi 6.0 Upgrade:
After the ESXi upgrade is failed or Hung, reboot your ESXi host. Durig ESXi host boot up, hit Shift+R
Recovery mode will display the ESXi build version which you were upgrading from. If you want to roll back to the previous version, hit Y to go back to the previous version of ESXi. In my case , I was upgrading my ESXi host from ESXI 5.5 to ESXi 6.0. So I am hitting Y to rollback to previous version ie. ESXi 5.5
Thats it. Your ESXi server will boot with the previous version of the ESXi i.e ESXi 5.5. This is a permanent and you will not able to boot to ESXi 6.0 until your next successful upgrade. I hope this is informative for you. Thanks for Reading!!!. Be Social and share it in social media, if you feel worth sharing it.
RVTools is a windows .NET 2.0 application which uses the VI SDK to display information about your virtual machines and ESX hosts. Interacting with VirtualCenter 2.5, ESX Server 3.5, ESX Server 3i, VirtualCenter 4.x, ESX Server 4.x, VirtualCenter 5.0, VirtualCenter Appliance, ESX Server 5.0, VirtualCenter 5.1, ESX Server 5.1, VirtualCenter 5.5, ESX Server 5.5. RVTools is able to list information about VMs, CPU, Memory, Disks, Partitions, Network, Floppy drives, CD drives, Snapshots, VMware tools, Resource pools, Clusters, ESX hosts, HBAs, Nics, Switches, Ports, Distributed Switches, Distributed Ports, Service consoles, VM Kernels, Datastores, Multipath info and health checks. With RVTools you can disconnect the cd-rom or floppy drives from the virtual machines and RVTools is able to update the VMware Tools installed inside each virtual machine to the latest version.
Free VM Health Monitor
- Monitor the performance of VMware ESX & ESXi servers
- Get key virtual machine statistics like CPU, memory & disk utilization
- Keep a tab on both host and guest OS resources
- Get to know the network bandwidth usage
- Utilize the threshold settings and keep performance degradation at bay
- Refresh the VMware performance statistics in real time
After the major vSphere release on september, vmware again released the latest vcenter this month. Even though it is a minor release, lot of bugs fixed in this release. Issues resolved with this release are as follows
- Attempts to upgrade vCenter Single Sign-On (SSO) 5.1 Update 1 to version 5.5 might fail with error code 1603
- Attempts to log in to the vCenter Server might be unsuccessful after you upgrade from vCenter Server 5.1 to 5.5
- Unable to change the vCenter SSO administrator password on Windows in the vSphere Web Client after you upgrade to vCenter Server 5.5 or VCSA 5.5
- VPXD service might fail due to MS SQL database deadlock for the issues with VPXD queries that run on VPX_EVENT and VPX_EVENT_ARG tables
- Attempts to search the inventory in vCenter Server using vSphere Web Client with proper permissions might fail to return any results
- vCenter Server 5.5 might fail to start after a vCenter Single Sign-On Server reboot
- Unable to log in to vCenter Server Appliance 5.5 using domain credentials in vSphere Web Client with proper permission when the authenticated user is associated with a group name containing parentheses
- Active Directory group users unable to log in to the vCenter Inventory Service 5.5 with vCenter Single Sign-On
- Attempts to log in to vCenter Single Sign-On and vCenter Server might fail when there are multiple users with the same common name in the OpenLDAP directory service
- Attempts to log in to vCenter Single Sign-On and vCenter Server might fail for OpenLDAP 2.4 directory service users who have attributes with multiple values attached to their account
- Attempts to Log in to vCenter Server might fail for an OpenLDAP user whose account is not configured with a universally unique identifier (UUID)
- Unable to add an Open LDAP provider as an identity source if the Base DN does not contain an “dc=” attribute
- Active Directory authentication fails when vCenter Single Sign-On 5.5 runs on Windows Server 2012 and the AD Domain Controller is also on Windows Server 2012