Upgrading vSphere from Nutanix Prism

Nutanix customers love the fact we give them their weekends back by having 1-click upgrades for the Acropolis operating system, BIOS, BMC, Firmware and the Hypervisor. When speaking to some customers still go through a multi-step process to include:

Download Updates in VUM
Create a new baseline
Attach Hosts to baseline and scan hosts to validate
Place DRS to manual and evacuate guests from the host
Issue shutdown command to CVM
Place host into maintenance mode
Proceed with remediation wizard
Complete upgrade
Reboot host
Power on CVM
Validate RF in Prism and move on

Yes, a couple of these steps are added compared to non-Nutanix environments, however there are still a number of steps that need to be completed.

With Prism, as long as the cluster is managed with vCenter, we are able to manage the entire process for you, by simply opening the upgrade tab, uploading the offline upgrade package with the json file from the Nutanix support portal and off you go! It’s as simple as that, and here’s another video to show the process.

Hyper-V Terminology in VMware speak

 

I’ve never had much to do with Hyper-V and my knowledge of it is nowhere near as strong as VMware, however since joining Nutanix I find the topic comes up more and more in conversations with clients. It’s great that Nutanix is hypervisor agnostic and supports multiple platforms, but this means I need to get up to speed with the Hyper-V lingo!

I’ve come up with the below table that I can use as my mini translator, so when in conversation I have a quick reference point.

VMware vSphere Microsoft Hyper-V
Service Console Parent Partition
VMDK VHD
VMware HA Failover Clustering
VMotion Live Migration
Primary Node Co-Ordinator Node
VMFS Clustered Shared Volume
VM Affinity VM Affinity
Raw Device Mapping (RDM) Pass Through Disks
Distributed Power Management (DPM) Core Parking
VI Client Hyper-V Manager
vCenter SCVMM
Thin Provisioning Dynamic Disk
VM SCSI VM IDE Boot
VMware Tools Integration Components
Standard/Distributed Switch Virtual Switch
DRS PRO/DO – Performance and Resource Optimsation/Dynamic Optimisation
Web Access Self Service Portal
Storage VMotion Quick Storage Migration
Full Clones Clones
Snapshot Checkpoint
Update Manager VMST – Virtual Machine Servicing Tool

VCAP-DCD | Objective 2.5 | Build Performance Requirements into the logical design

Understand what logical performance services are provided by VMware solutions

VMware have a number of performance enhancers in the vSphere, some of which are available in all licence versions, some however require a certain licence level to make the features available.

Memory
  • Transparent Page Sharing – Shares identical memory pages across multiple VMs. This is enabled by default. Consideration should be given to try and place similar workloads on the same hosts to gain maximum benefit.
  • Memory Ballooning – Controls a balloon driver which is running inside each VM. When the physical host runs out of memory it instructs the driver to inflate by allocating inactive physical pages. The ESXi host can uses these pages to fulfill the demand from other VMs.
  • Memory Compression – Prior to swapping, memory pages out to physical disks. The ESXi server starts to compress pages. Compared to swapping, compression can improve the overall performance in an memory over commitment scenario.
  • Swapping – As the last resort, ESXi will start to swap pages out to physical disk.
Disk
  • vStorage APIs for Array Integration (VAAI) –  is a feature introduced in ESXi/ESX 4.1 that provides hardware acceleration functionality. It enables your host to offload specific virtual machine and storage management operations to compliant storage hardware. With the storage hardware assistance, your host performs these operations faster and consumes less CPU, memory, and storage fabric bandwidth.
  • Storage I/O Control (SIOC) – was introduced in vSphere 4.1 and allows for cluster wide control of disk resources. The primary aim is to prevent a single VM on a single ESX host from hogging all the I/O bandwidth to a shared datastore. An example could be a low priority VM which runs a data mining type application impacting the performance of other more important business VMs sharing the same datastore.
  • vSphere Storage API’s – Storage Awareness (VASA) – VASA is a set of APIs that permits storage arrays to integrate with vCenter for management functionality.
Networking
  • Network IO Control (NIOC) – When network I/O control is enabled, distributed switch traffic is divided into the following predefined network resource pools: Fault Tolerance traffic, iSCSI traffic, vMotion traffic, management traffic, vSphere Replication (VR) traffic, NFS traffic, and virtual machine traffic.  You can control the bandwidth each network resource pool is given by setting the physical adapter shares and host limit for each network resource pool.

Identify and differentiate infrastructure qualities (Availability, Manageability, Performance, Recoverability, Security)

This has been covered in a previous Objective.

List the key performance indicators for resource utilisation

According to ITIL, a Key Performance Indicator (KPI) is used to assess if a defined service is running according to expectations. The exact definition of the KPIs differs depending on the area. This objective is about server performance which is typically assessed using the following KPIs: Processor, Memory, Disk, and Network.

VCAP-DCD | Objective 2.4 | Build manageability requirements into the logical design

Understand what management services are offered by VMware solutions

VMware provide us with whole host of management services within the stack, some of these are free, some come into play depending on the type of licence you have. In no particular order we have:

  • vCenter Server
  • vCenter Orchestrator
  • vSphere Management Assistant (vMA)
  • PowerCLI
  • vCLI
  • vSphere API’s
  • vSphere High Availability (HA)
  • vSphere Distributed Resource Scheduler (DRS)
  • Scheduled Tasks (within vCenter server)
  • Auto Deploy
  • Host Profiles

Identify and differentiate infrastructure qualities (Availability, Manageability, Performance, Recoverability and Security)

This was covered off in the previous Objective, however, as a reminder

Availability – The ability of a system or service to perform it’s required function when required. It is usually calculated as a percentage.

Manageability – The expense of running a system. If in a large enterprise the system is managed by a small team, the operation cost can therefore be low.

Performance – The measure of what is delivered by the system. This is usually measured against known standards. Recoverability – The ability to return a system to a working state after a failure or repair.

Security – The process of ensuring the service is used in the appropriate manner.

VCAP-DCD |Objective 2.3 | Build availability requirements into the logical design

Understand what logical availability services are provided by VMware solutions.

The two primary availability services in vSphere are High Availability (HA) and Fault Tolerance (FT). Studying for this exam, you should be understand the differences in these features, however at a very high level: HA – Can minimise downtime by restarting VMs in case of a hardware failure FT – Provides continues availability for a VM by making a secondary copy of the VM on another physical host. To gain a better understanding of VMware’s HA, (as well as DRS, Storage DRS and Stretched Clusters) the VMware vSphere 5.1 Clustering Deep Dive by Frank Denneman and Duncan Epping is a MUST! The VMware vSphere Availability Guide is also a MUST read. Fault Tolerance, whist no doubt is a great technology, it does have limitations, which are discussed in the Availability Guide. I rarely see a business case for FT, in most cases HA is good enough.

Identify and differentiate infrastructure qualities (Availability, Manageability, Performance, Recoverability, Security)

Availability – The ability of a system or service to perform it’s required function when required. It is usually calculated as a percentage.

Manageability – The expense of running a system. If in a large enterprise the system is managed by a small team, the operation cost can therefore be low.

Performance – The measure of what is delivered by the system. This is usually measured against known standards. Recoverability – The ability to return a system to a working state after a failure or repair.

Security – The process of ensuring the service is used in the appropriate manner.

Describe the concept of redundancy and the risks associated with single points of failure.

A single point of failure is a system component, that if it fails, will then cause the entire system to fail because of it. For example, in a vSphere world, if we have a virtual switch with a single physical NIC uplink and this uplink fails, the virtual switch will fail as a result. These components can be bolstered by adding redundancy, in the above example we could add redundancy to the virtual switch by adding a second physical uplink, therefore if one uplink fails traffic could continue to pass on the second uplink. This spreads out to multiple areas of a vSphere design, hosts in clusters, components in hosts and stretching out to the wider infrastructure, with multiple physical switches, load balancers etc etc.

Differentiate Business Continuity and Disaster Recovery concepts.

Business Continuity is focussing on avoiding or mitigating the impact of risk, therefore is a proactive approach.

Disaster Recovery is focussing on the recovery of a system/service after an outage, therefore is a reactive approach.

VMware offer a free DR/BC Fundamentals training course through MyLearn. Click the following link to register

DR/BC Fundamentals

 

 

VCAP-DCD | Objective 2.2 | Map Service Dependencies

Identify basic service dependencies for infrastructure and application services

Service dependencies come in many forms within a vSphere infrastructure design. Services rely on objects such as DNS, NTP, Active Directory etc. What devices are communicating together? What ports are they communicating on? Which processes make up these services?

VMware did have a product to assist in this, VMware vCenter Application Discovery manager, however this has now gone EOL, and unless you have already purchased it, you wont be able to get your hands on it. The current state analysis that should have already been completed at this point should help here, in particular in identifying the applications that will be migrated. It will then be a manual process to discover and document these dependencies.

I found a good WIKI  from ServiceNow which delves deeper into application dependency mapping. This article explains how relationships are defined using the following:

  • Runs on::Runs
  • Depends on::Used by
  • Hosted on ::Hosts
  • Virtualised by::Virtualises
  • Contains::Contained by
  • IP Connection::IP Connection

They also delve deeper into upstream and downstream relationships, I’d highly recommend giving this page some attention.

Document and reference your findings to ensure every relationship and dependency is covered and accounted for in the design.

VCAP-DCD | Objective 2.1 | Map business Requirements to the Logical Design

Explain the common components of logical design

We’ve already briefly touched on the logical design back in Objective 1.1. The logical design is a lower level design than the conceptual, yet still should not focus on physical detail such as host names, IP addresses, LUN sizes etc. The logical design will should consider the conceptual design along with any constraints, risks and assumptions. This enables you to understand if the design will meet the goals and requirements whilst taking into account all of the constraints.

To summarise, the logical design is based upon the documented information in the conceptual design. It will consider all the constraints and risks associated with the project, whilst communicating all risks with recommended actions aligned to enable the project to progress without delay.

List the detailed steps that go into the makeup of a common logical design

  1. Consider the conceptual design, ensure constraints risks and assumptions are documented
  2. Document recommended items to workaround risks
  3. Do NOT include physical details such as hardware, vendors, IP’s, port numbers etc
  4. Ensure capacity analysis is kept in mind, however don’t be tempted to delve into physical detail
  5. Ensure all relationships are covered between all components of the infrastructure
  6. Diagram how the infrastructure components will be arranged
  7. Document with diagrams, tables and text
  8. Ensure all requirements are met!

Differentiate functional and non functional requirements for the design

A functional requirement specifies what a system should do. A requirement specifies a function that a system or component must be able to perform. A function is described as a set of inputs, the behaviour and outputs that should be measurable. A functional requirement for a vSphere design could be “The platform must support creation of new workloads from a template” or “The platform should allow for 20% growth over the next 3 years”.

A non-functional requirement specifies how the system should be have. A non-functional requirement is a statement of how a system must behave, it is a constraint upon the system behaviour. A non-functional requirements specifies criteria that can be used to judge the operation of the system rather than specific behaviours. Non-Functional requirements can also be constraints. A non-functional requirement for a vSphere design could be “The platform will be built on VCE’s Vblock infrastructure” or “vSphere 5.1 will be used over vSphere 5.5 to ensure application support”.

 

VCAP-DCD | Objective 1.3 | Determine Risks, Constraints and Assumptions

Differentiate between the general concepts of a risk, a requirement, a constraint, and an assumption.

A project vision will generally consists of an idea or multiple ideas that make up a project. As well a the idea(s), the vision will layout a scope, requirements, constraints, assumptions and risks.

Scope

The scope is a statement that details what is included in, and what is not included in a project. This will aid the project team in setting a clear defined goal which all parties are able to understand and adhere to. This also helps eliminate any stray tasks to be consumed as part of the project. For example, you may be virtualising a Microsoft Exchange workload running Exchange Server 2003, however upgrading the Exchange Server to Exchange 2010 at time of migration is out of scope.

The scope will also set out different phases of the project. For example, you wouldn’t (or at least I hope you wouldn’t) expect to have a target of virtualising 100% of workloads in one go. The scope is likely to specify groups of workloads, simple candidates or workloads of high priority.

Requirements

A requirement is a need that the design must meet or a goal that the project must achieve. A requirement can be of business or technical focus. The requirements should be listed and referenced in the design documentation.

Examples of requirements include:

  • Must be SOX compliant
  • Must meet SLA of 99.9% uptime

A requirement will affect a design choice substantially.

Constraints

A constraint is something that plays the part of a restriction or limitation. It could well limit a design choice. Much like a requirement, a constraint can be of business or technical focus.

Examples of constraints include:

  • Existing vendor relationships will continue, therefore Cisco UCS will provide compute resource
  • Workloads cannot experience downtime outside of any agreed maintenance windows
  • All workloads must remain under full vendor support

The constraints should be listed and referenced in the design documentation.

Assumptions

An assumption is something that will be true to the project design, but is something that has not been fully tested nor verified.

Examples of assumptions include:

  • There will be sufficient bandwidth between primary DC and DR DC for replication to take place
  • There will be enough power and cooling in the primary DC to house the new kit
  • Business stakeholders will provide certain application before a given date

The assumptions should be listed and referenced in the design documentation.

Risks

A risk is something that could hinder or prevent completion of the project, or perhaps could adversely effect the design.  Risks are common place in every project and should be identified early to eliminate any aspect of surprise.

Examples of risks include:

  • The software and technology being used is cutting edge, has it been done before and to this scale
  • Existing hardware is unstable and unsupported
  • The project has a set completion date

The risks should be listed and referenced in the design documentation.

Given a statement, determine whether it is a risk, requirement, a constraint, or an assumption

I think I’ve covered off this deliverable in the above,refer back to ensure ability to understand the differences.

Analyse impact of VMware best practises to identified risks, constraints, and assumptions

I’m not a huge fan of the term ‘best practise’. I would always suggest referencing vendor documentation and guidelines however always use these as just that, guidelines. They should never be used as set rules.

Using vendor guides can help a design avoid known ‘constrains’ which will help eliminate ‘risk’.

VCAP-DCD | Objective 1.2 | Gather and analyse application requirements

Given a scenario, gather and analyse application requirements

To gather and analyse the application requirements we need to focus on the current state analysis, as the objective heading states with a close focus on applications to identify if they are candidates for virtualisation or not.

VMware Capacity Planner should be used to identify these candidates and potentially help identify any non-virtualisation candidates. Saying this, with the advances with each release of VMware vSphere, these should now be less common. It is vitally important to capture baselines of all candidates to include average and peak performance metrics. These metrics are vital to feed into the requirements documentation as well as helping to define consolidation ratios as well as comparisons post virtualisation.

All applications should be looked at individually to look at any dependencies that may be core to the application running successfully.

Application availability is key and must be determined from the off. This information will likely come from interviews with stakeholders and the business to determine the SLA of a certain application.

The information gathered from the current state analysis will help influence design decisions.

Given a set of applications within a physical environment, determine the requirements for virtualisation

So there are 5 key applications mentioned in the blueprint, yes, there will be others I am sure. Microsoft Exchange, Microsoft SQL, Oracle, SAP and Java are all mentioned in the blueprint, so I would have thought any exam questions would be related to these specific technology sets. I’d suggest the following reading:

Microsoft Exchange 2010 on VMware

Microsoft SQL on VMware

Oracle Databases on VMware

SAP Solutions on VMware

Enterprise Java Applications on VMware

Gather information needed in order to identify application dependencies

This again, comes back to the current state analysis. VMware Capacity Planner is a key tool here for discovery, however this doesn’t help with application dependencies and relationships. Products such as vCenter Operations Manager and VMware vCenter Infrastructure Navigator can be used here to help with this analysis. This task should not be rushed and should be run over a period of at least 30 days to ensure the infrastructure in question goes through a full monthly cycle to ensure all process are captured. Discussions should be held with SME’s and business stake holders to establish what business processes wouldn’t be run during the monitoring period and what discussions should take place to determine what impact this may have on the infrastructure and wether the process are different to those that have run throughout the monitoring period.

 

Given one ore  more application requirements, determine the impact of the requirements on the design

 

This, as most of this objective has been, is very application specific. Each applications requirements is likely to be different, however the processes outlined already in this post should have already presented the required information.

Again refer to the VMware documentation I’ve linked to above and ensure you understand any application specific requirements.

VCAP-DCD | Objective 1.1 | Gather and analyse business requirements

Associate a stakeholder with the information that needs to be collected:

This information ‘should’ always be passed on to you from the business you are working with. Most units/applications will have an aligned business owner. If for some reason they don’t or they are like some companies that simply don’t understand who the correct person is to speak to in the business then it’s a requirement to arrange stakeholder meetings to get bodies assigned as stakeholders in the project. People you need to speak to will include:

  • C-Level execs
  • Application Owners
  • Business Unites
  • Users (remember they are likely to use applications day in day out and can (sometimes) provide a better insight of how the application works than the aligned business owner
  • Server Team
  • Storage Team
  • Network Team
  • Security Team
  • Compliance Team

From personal experience I always try and get two vital pieces of information out of these meetings at a minimum. An aligned business stakeholder, and an SME (subject matter expert). Ensure these people are listed in the design along with their title or role and an email address.

Utilise customer inventory and assessment data from current environment to define a baseline state:

VMware have a 5 step design methodology which should be followed here (after all it is a VMware exam).

  1. Initial Design Meeting – scope, goals, requirements, constraints. Who should be invited.
  2. Current State Analysis – complete datacenter inventory, virtuaisation candidates, tools, constraints and assumptions.
  3. Stakeholder and SME training – educate SMEs who can help make informed design decisions
  4. Design Sessions – allow for design decisions with stakeholders/SMEs to be made so there are no surprises later on
  5. Design Deliverables – documentation to include: capacity analysis, hosts, vCenter servers, clusters, networks, storage, monitoring, patching, backup, restore, DR/BC, security, installation, operations, scalability, support, logical, physical.

(Thanks to the US vBrownBag team – I took this from their slide deck – I couldn’t find anything official).

Analyse customer interview data to explicitly define customer objectives for a conceptual design:

The conceptual design focuses on achieving the organisations business goals and requirements. It will be the first design that is created, and will be high level based on:

  • The information gathered from key stakeholder and SME interviews (scope, goals, requirements, assumptions, constraints)
  • The information gathered from the current state analysis

Identify the need for and apply requirements tracking:

A good design will document every single requirement. These requirements should be allocated a unique identifier (for example, R01. Ro2 etc) which should be proceeded with a description of the requirement, the source of the requirement, an approval date and a priority. The design should will need to reference these requirements and show they have been met.

Given results of a requirements gathering survey, identify requirements for a conceptual design:

The purpose of the conceptual design is to make certain that as many as possible of the business goals and objectives are met. You must be able to define the entities of the organisation. This entity could be a user, a service, an application a process, or an entire line of business. Entities can be anyone or anything affected by the design project and that have goals, requirements and constraints.

The conceptual design associates the goals and requirements to specific entities then defines which vSphere capability will be employed to reach the goal or satisfy the requirement. Generally the conceptual design is documented with a series of diagrams, tables and text.

Make use of VMware Capacity Planner to gather information for a current state analysis. Ensure the analysis includes:

  • Detail on current server, storage and network platforms
  • Detail on current applications and operating system levels
  • Detail on resource consumption
  • Detail on resource performance

Once the current state analysis is complete, envision the target state of the design. This is often easier to do with a diagram.

Categorise requirements by infrastructure qualities to prepare for logical design requirements:

The logical design will follow on from the conceptual design. The logical is lower level compared to the conceptual. The logical design will show how to arrange hosts, storage and network components enough to satisfy the relationships deciphered in the conceptual design. The logical design is useful for understanding and evaluating the design of the infrastructure without becoming lost in the connection and configuration details. The logical design includes the relationship between all major infrastructure components.

The logical design will be based on the information documented in the conceptual design and considers all the constrains and risks. Where risks to exist, they should be actively communicated to the business along with a recommended remediation to help enable a decision to be made going forward.

When creating the logical design be aware of the capacity analysis, although the logical design doesn’t normally include item specifics such as, LUN sizes, CPU count, memory required etc. Also, the logical design does not specify details of specific hardware, port details or FC zones. The logical design will illustrate how the design will meet the goals and requirements already set out. This design is generally documented with a series of diagrams, tables and text.