Thanks for choosing VMware vSphere Design Essentials, your companion in learning the fundamentals of designing VMware vSphere. We understand your mission to learn, apply, and reap the benefits of virtualization and to design VMware vSphere to its fullest extent using this book. Let's get started learning about VMware vSphere and its essentials.
VMware vSphere is a product developed by VMware, Inc. The company is located at Palo Alto, California, USA, and was started in 1998. It offers virtualization, cloud software, and services. VMware vSphere is a product that aims to provide x86 virtualization to renovate datacenters into streamlined cloud computing infrastructures, which in turn enables IT organizations to deliver consistent and elastic IT services.
vSphere virtualizes physical hardware and converts one single physical system into multiple VMs; thereby VMware vSphere reduces the space, cost, and complexity of managing systems in a datacenter. This book is not only for VMware architects but also for people who use vSphere on a daily basis. This book will help you understand how vSphere is designed and will help you to design your virtual infrastructure using VMware vSphere to its best potential. Also this book will help you to improve your skills; you will become well versed in designing best practices.
Designing VMware vSphere infrastructure will be a multipart subject. In this chapter, we'll provide an introduction to the VMware vSphere landscape, the design of vSphere itself, challenges and obstacles that were caused by virtual infrastructure due to poor design, and the way to overcome those challenges with structured principles and processes.
In this chapter, you will learn the following topics:
Introduction to the VMware vSphere landscape
Designing VMware vSphere
Challenges and obstacles faced with the virtual infrastructure
Designs that will accelerate solutions to resolve real-world obstacles
Values and procedures that need to be followed while designing VMware vSphere
Virtualizing x86 systems
Built-in security and High Availability
The VMware vSphere landscape is formed by the following mandatory components. If the infrastructure is designed without any one of these components, it will result in issues such as poor performance, poor user experience, and applications not working. Let's take a look at the components of vSphere in the following table:
Designing these components is highly critical for virtualization success. The following diagram illustrates the associations within each component:
You need to have understood component associations within VMware vSphere. As the next step, start designing essentials before we jump into designing each component. Let's get started with understanding the essentials of designing VMware vSphere. Designing is nothing but assembling and integrating VMware vSphere infrastructure components together to form the baseline for a virtualized datacenter. It has the following benefits:
From my experience, I would always urge you to have frequent meetings to observe functional requirements as much as possible. This will create a win-win situation for you and the requestor and show you how to get things done. Please follow your own approach, if it works.
Architecture design principles should be developed by the overall IT principles specific to the customer's demands, if they exist. If not, they should be selected to ensure positioning of IT strategies in line with business approaches. In nutshell, architect should aim to form an effective architecture principles that fulfills the infrastructure demands, following are high level principles that should be followed across any design:
Design mission and plans
Design strategic initiatives
External influencing factors
When you release a design to the customer, keep in mind that the design must have the following principles:
Understandable and robust
Complete and consistent
Stable and capable of accepting continuous requirement-based changes
Rational and controlled technical diversity
Without the preceding principles, I wouldn't recommend you to release your design to anyone even for peer review.
For every design, irrespective of the product that you are about to design, try the following approach; it should work well but if required I would recommend you make changes to the approach.
The following approach is called PPP, which will focus on people's requirements, the product's capacity, and the process that helps to bridge the gap between the product capacity and people requirements:
The preceding diagram illustrates three entities that should be considered while designing VMware vSphere infrastructure.
Please keep in mind that your design is just a product designed by a process that is based on people's needs.
Functional requirements should be meaningful; while designing, please make sure there is a meaning to your design. Selecting VMware vSphere from other competitors should not be a random pick, you should always list the benefits of VMware vSphere. Some of them are as follows:
Server consolidation and easy hardware changes
Dynamic provisioning of resources to your compute node
Templates, snapshots, vMotion, DRS, DPM, High Availability, fault tolerance, auto monitoring, and solutions for warnings and alerts
Let's explore the components that integrate to form the PPP framework. Always keep in mind that the design should consist of people, processes, and products that meet the unified functional requirements and performance benchmark. Always expect the unexpected. Without these metrics, your design is incomplete; PPP always retains its own decision metrics. What does it do, who does it, and how is it done? We will see the answers in the following diagrams:
The PPP Framework helps you to get started with requirements gathering, design vision, business architecture, infrastructure architecture, opportunities and solutions, migration planning, fixing the tone for implementing and design governance. The following table illustrates the essentials of the three-dimensional approach and the basic questions that are required to be answered before you start designing or documenting about designing, which will in turn help to understand the real requirements for a specific design:
Results of what?
What kind of CPU is required?
What is the quantity of CPU, RAM, storage per host/VM?
What kind of storage is required?
What kind of network is required?
What kind of power and cooling are required?
How much rack and floor space is demanded?
Results of who?
Who is responsible for infrastructure provisioning?
Who is responsible for implementation of the hardware and software patches?
Who is responsible for storage and back up?
Who is responsible for security and hardware support?
Results of how?
How should we manage the virtual infrastructure?
How should we manage hosted VMs?
How should we provision VM on demand?
How should a DR site be active during a primary site failure?
How should we provision storage and backup?
How should we monitor and perform periodic health checks?
Before we start to apply the PPP framework on VMware vSphere, we will discuss the list of challenges and encounters faced on the virtual infrastructure.
In this section, we will see a list of challenges and encounters faced with virtual infrastructure due to the simple reason that we fail to capture the functional and non-functional demands of business users, or do not understand the fit-for-purpose concept:
Resource Estimate Misfire: If you underestimate the amount of memory required up-front, you could change the number of VMs you attempt to run on the VMware ESXi host hardware.
Resource unavailability: Without capacity management and configuration management, you cannot create dozens or hundreds of VMs on a single host. Some of the VMs could consume all resources, leaving other VMs unknown.
High utilization: An army of VMs can also throw workflows off-balance due to the complexities they can bring to provisioning and operational tasks.
Business continuity: Unlike a PC environment, VMs cannot be backed up to an actual hard drive. This is why 80 percent of IT professionals believe that virtualization backup is a great technological challenge.
Security: More than six out of ten IT professionals believe that data protection is a top technological challenge.
Backward compatibility: This is especially challenging for certain apps and systems that are dependent on legacy systems.
Restriction of licensing: Before you install software on virtual machines, read the license agreements; they might not support this; hence, by hosting on VMs, you might violate the agreement.
Sizing the database and mailbox: Proper sizing of databases and mailboxes is really critical to the organization's communication systems and for applications.
Poor design of storage and network: A poor storage design or a networking design resulting from a failure to properly involve the required teams within an organization is a sure-fire way to ensure that this design isn't successful.
Planning, designing, and positioning a virtualization-based infrastructure are really difficult tasks. There are sizable technical hurdles for administrators to jump, but often it's the challenge of getting everyone to pull in the same direction that ultimately slows a virtualization rollout. Let's explore the top 10 considerations that should be considered before starting to design a VMware virtualization and the best time to start. According to VMware experts, the right stage to start considering, is the beginning, which leads on to the following questions:
Why is the customer seeking to implement VMware vSphere?
What applications does the customer plan to deploy?
What objective does the customer hope to reach with the help of a VMware vSphere deployment?
What are the existing problems, business or technical, that the customer is trying to resolve?
Requirement gathering and documenting are the driving factors for virtualization; the objectives, problems and needs of the customer should be the first task to undertake before we can start designing. This is the beginning and translates into what we have called the design factors—requirements, constraints, risks, and assumptions. They are crucial to the success of any vSphere design. In the next section, you will learn the ways in which we can overcome the challenges and enforcements.
This section provides a step by step sequence and activity that is required to be followed in order to design a virtualization; this is a completely elastic method that best fulfills your infrastructure demands. The steps are obtainable in an ordered sequence as per the following diagram:
It's really difficult to build a virtual infrastructure if you don't know the target or requirements. Elicitation is the step where the requirements are first gathered from the customer. Many practices are available for gathering requirements. Each has a certain value in certain situations; you need manifold techniques to gain a complete picture from various sets of clients and stakeholders. Here's a look at some of the approaches you can take:
One-on-one meeting with IT leaders and top management sponsors for the project
Team meetings with the current team responsible for managing technical operations
Facilitated sessions, prototyping, initial engagement surveys, use cases, following people around, Request for Proposals (RFPs), brainstorming
Finally, at the end of requirement gathering, conduct workshops with all these reviews, lastly look for room for improvement. If all stakeholders in a session try to appraise the value and cost for each demands, at last artifacts becomes much more effective and cost-valuable. Hence, schedule periodic meetings to review and agree requirements:
Research and collect data facts as far as possible before you start planning for design; since the analysis or research must be lightweight, it must also be less scrupulous. Best results come from considering user insights from the very start as input and giving the result to the design process.
In the early stages of the process, the discovery stage will help you identify new breaks and will describe the design in brief. VMware vExperts advise re-iterative ESXi and VM configuration testing before it is rolled out to the Proof of Concept (POC). In turn, this will help to inform decisions from the design phase to the final implementation. A usability problem can be corrected more swiftly and with less cost if it is identified at the design stage itself rather than at the support stage.
We will use the 4D-stage analysis process to display how we can fit in all the stages:
The preceding 4D stage analysis, as explained in the following table, aligns to the method that is required to be adopted in each stage:
Task and gap analysis
Quantitative and qualitative
With this approach, we will be able to gain an insight into requirements and the output of this phase is an input to the planning phase. As the next step, let's learn about planning and its implications to the design phase.
The design considerations we made in final steps may make us to change the decisions which we made in the earlier steps, due to various thought clashes. Every alert challenges the potential requirement gathering, planning, and design, which will be a great challenge throughout the project planning.
We will come to design phase which meets best of our requirements, only after iterating through the stages as many times as required to include all of the thoughts within the manuscript. The following diagram illustrates the key technical metrics that are required to be a part of your planning technical artifacts:
Each phase of planning and its mission is listed in the following table:
Phases of planning
Mission 1: Determine the workload resource requirements
Mission 2: Define the workload characterizations
Plan for VM configuration
Mission 1: Define the compute configuration
Mission 2: Define the network configuration
Mission 3: Define the storage configuration
Mission 4: Define the VM availability strategy
Mission 5: Define the VM types
Plan for cluster
Mission 1: Define the physical locations
Mission 2: Define the ESXi host cluster
Mission 3: Determine the cluster ESXi host members
Mission 1: Define the compute configuration
Mission 2: Define the network configuration
Mission 3: Define the storage configuration
Mission 4: Define the server virtualization host scale
Mission 5: Define the server virtualization host availability strategy
Plan for DRS and DPM
Mission 1: Define the priority configuration
Mission 2: Define the algorithm and calculate it
Mission 3: Define the threshold configuration
Mission 4: Define the balanced average CPU loads or reservations
Mission 5: Define the balanced average memory loads or reservations
Mission 6: Define resource pool reservations
Mission 7: Define an affinity rule
Plan for HA and FT
Mission 1: Define monitoring mechanisms for physical servers and VMs
Mission 2: Define server failure detection
Mission 3: Define migration and restart of VM Priority from failed ESXi host
Mission 4: Define the vLockstep technology for FT
Mission 5: Define the transparent failover
Mission 6: Define the component failures
Plan for VMware architecture
Mission 1: Define the maintenance domains
Mission 2: Define the physical fault domains Mission 3: Define the reserve capacity
Mission 1: Define the original SLA factors for storage and VMs
Mission 2: Define the original costs for storage and VMs
VMware Capacity Planner is a capacity planning product that gathers comprehensive resource consumption data in assorted IT environments and associates it to industry standard position data to provide analysis and decision support modeling. The following are the key benefits of the product:
Increased efficiency with server union and volume optimization
Reduced complication through IT calibration and hardware restraint
Improved expectations with capacity consumption trends and virtualization targets
The output of data gathering from the requirements, analysis, and planning phases is a design phase input. This is really a key factor for your success. In the next section, let's explore the key requirements for designing in general and then we will map that to the streamlined process and principles.
Design essentials are what this book is all about. Let's get started by looking at the fundamentals. Any design, irrespective of the platform, should be enabled with factors such as balance, proximity, alignment, repetition, contrast, and space. These factors, in turn, should focus on the following:
Identifying design thoughts and encounters
Describing where to start with customers
Describing procedures for dealing with decision architects
Identifying if you've achieved design acceptance
Identifying what your framework should include
Identifying the phases of design
Identifying the risks associated with the discovery phase
Identifying the best practices that can fit the customer's needs.
Identifying the method that is capable of either scale-out or horizontal scaling
The preceding components will help you to attain the following deliverables that will help you to build the right solution document for small, medium, and enterprise businesses:
Designing VMware vSphere is really challenging; to avoid any bottleneck, we need to learn and understand how it is really done by experienced architects and VMware itself. In the following section, we will discuss the values and procedures that need to be followed while designing VMware vSphere.
As you are aware, inputs for each design have to come from the PPP framework in order to achieve the desired success, including decision-influencing factors. This helps us to satisfy the functional requirements and performance benchmarks.
Start your design by focusing on the business drivers, and not the product features. The products could be the best in the world, but no good for your use case irrespective of any conditions. For example, if you have been asked to design your VMware vSphere-based Hadoop clusters, the driving factors for your design decision would not include fault tolerance. However, for a business-critical application, fault tolerance will be vital and, if that business-critical application needs more than one CPU, then we would not be able to use VMware vSphere Fault Tolerance to continue its uptime. On the design document, the feature looks good, but it doesn't work in the real infrastructure. The following diagram illustrates values of virtualization and its subcomponents:
Readiness is all about integrating different components together: uptime and system reliability, downtime, redundancy, and resiliency. In a nutshell, a mechanism that avoids crashes and maintains performance.
Values should have a close relationship with each other. With regard to the PPP framework of design, the value of readiness typically has the greatest effect on product decisions.
In some cases, the functional requirements explicitly call for readiness; for example, a functional and performance requirement may demand that the vSphere design must provide 99 percent readiness to meet any demand. In this case, readiness is explicitly noted by the requirement gathering and therefore must be incorporated into the design.
In some other cases, the functional requirements may not explicitly state readiness demands at 99 percent. In these cases, the designer should include an appropriate level of availability as per the projected target state.
To accommodate both cases in the design document, always come up with an assumption section. An assumption section can offer justification for the vSphere designer's decisions within the broader business framework of functional performance requirements, design consideration, and constraints. When readiness isn't explicitly stated, the designer can provide an assumption that the infrastructure will be made as ready as possible within the cost limitations of the statement of work.
Performance is often called for in the performance requirements, and it can affect decisions in the product and people phases. For the product phase, it can affect all manner of design decisions, starting from the type of the server's hardware to the kind of network storage devices planned. With regard to the performance demand, it's mostly seen as a Service Level Agreement (SLA) that expresses performance metrics, such as response times per request, transactions per second in the network, and the capacity to handle the maximum number of users.
If there is no performance requirement explicitly defined, the designer of a vSphere infrastructure should consider performance as a key component for its design decisions.
The KA key stage is to review and agree the performance metrics and make sure they have been documented on a low-level design, as well as ensuring that the specified components are validated against the gathered requirements. The key components that need to be considered and validated are as follows:
For hardware or CPU, the designer should consider options such as Hardware Assisted Computing Virtualization, Hardware Assisted I/O Memory Managed units Virtualization and Hardware Assisted Memory Managed units Virtualization.
For Network adapters, the designer should consider the following; such as Checksum Offload, TCP Segmentation Offload (TSO), the ability to handle high-memory DMA (that is, 64-bit DMA addresses), the ability to handle multiple Scatter Gather elements per Tx frame, Jumbo frames (JF), and Large Receive Offload (LRO). When using VXLAN, the NICs should support offload of encapsulated packets.
For storage, the designer should consider options such as vSphere Flash Read Cache (vFRC), VMware vStorage APIs for Array Integration (VAAI), LUN Access Methods, virtual disk modes, linked clones, and virtual disk types.
For network, the designer should consider the following such as Network I/O Control (NetIOC), DirectPath I/O, Single Root I/O Virtualization (SR-IOV), SplitRx Mode, and Virtual Network Interrupt Coalescing.
The designer should consider that the management pane has a key component that should be documented in a design document. Manageability is a key factor that works on support and operations. As a part of the support, managing infrastructure is most essential; hence, manageability is integrated from various factors:
Reachability from one infrastructure environment to another environment, from one location to another location
Usability, scalability, and interoperability
Access, manipulation, scripting, and automating common administrative tasks
Obtaining statistics from guest operating systems
Extending the vSphere Client GUI to vCLI
Monitoring mechanisms to manage server hardware and storage
Performance monitoring mechanisms and obtaining historical data
Recovery after a disaster is a key design principle that should be considered. With traditional disaster recovery procedures, the IT team have to identify a way for budgets to support the solution and make decisions about exactly which systems will not be sheltered. This process made ease via virtualization and along with a arrival of disaster recovery offerings via private and public clouds. Resiliency services and business continuity services are now ease for administer to manage, in turn makes huge disaster recovery protection for all applications.
To protect critical data and systems, only a few tools are available in the market today, especially to query real-time data replication and failover. It is critical for vSphere designers to understand that these tools are required for the appropriate infrastructure, and it is very important for designers to know exactly which systems and data need to be protected along with the type of protection that they are demanded, defining the metrics become one of the main design essentials for vSphere.
To start with, the first key metric is the Recovery Point Objective (RPO). For any data protection tool, RPO defines how much data could be lost in the recovery procedure. In case a single disk drive in the RAID 5 array undergoes failure, then there is no associated data loss. This is called as RPO of zero. At worst case scenario is that the entire disk in an array undergoes failure. In this situation, if a business demands data restoration from the last good known tape backup, the RPO time for this would be 12 to 24 hours. Essential of defining RPO of VMs is highly demanding, along with an integrating of tools in the design document.
The next serious metric is Recovery Time Objective (RTO). Used along with RPO, RTO measures the time taken for the entire recovery process up until the time where the end user can reconnect to their applications.
For example, if a production server fails and reaches a state where the server should be reimaged using the same tape backup solution, the RTO could be hours or days. This is will depend on time taken to repair the existing hardware or build the new hardware, followed by installing the host, guest OS and followed by applications deployment time . Hence, integrating this information on your design document is essential.
Once recovery objectives such as RPO and RTO have been finalized, most organization discovers that a traditional tape backup alone is not enough to meet their objective of high availability for many critical applications, Therefore, many organization will implement integration of different solutions such as data replication and application high availability attached with guest OS virtualization.
Security is yet another key principle that has to be incorporated into virtualization design. VMware has its own product for security—VMware vShield Endpoint (VSE). VSE offers endpoint protection by command of magnitude and divests anti-threat agent processing inside VMs that reside on ESXi and safe virtual appliance brought by VMware partners. VSE improves amalgamation ratios, performance, rationalizes antivirus deployment, monitoring for threats, and make sure compliance by logging antivirus and anti-malware activities which are accomplished in the virtual infrastructure.
Virtualization security is a key component of design. While the IT team needs to implements its own security practices and security governance in the phase of virtualization, the clear impact is that security can be really advantageous. Virtualization improves security by assembly it more fluid and context-aware solution. Which means security is more precise to manage, and cost effective to deploy than traditional security software.
Virtualization security empowers datacenter admins with the authority of automation on provision VMs. These VMs are fully wrapped with security policies that follow desktops when users move across from one system to another system.
With the accurate processes and products, virtualization has the authority to make datacenters even more secure; hence they identify the right tools to protect VMware vSphere-based virtualizations.
Assumptions should be an important section in the design document; without the assumption section, the planning phase cannot be driven forward. Factors that need to be considered by designers are the following:
The existing infrastructure that can be used for the virtualization project
Application virtualization consolidation and compatibility assessment
List of firewall rules in place
Trained VMware-Certified resources to deploy the solution and support it further
Equipment that will be presented at a certain date
The organization has satisfactory network bandwidth
Server hardware that has to be separated between DMZ and internal servers
Identify suitable best practices associated with a proposed design
Subordinate a role to the material that needs to be composed
Stakeholders that will make a decision in the next meeting
In scope and out of scope that has to be reviewed and agreed on between the project sponsor and project supplier
If you design your capacity in such a way that your business is going to grow by 20 percent yearly, this growth will apply linearly to the ingesting of the available capacity in the datacenter. This can be categorized under assumptions.
Constraints are a key principle that should be considered on design essentials. This section will impose obstacles and limit your design decision; it can be a technical limitation, the actual cost of the project, or the choice of vendors. Here are some examples of factors that limit the design:
The project has to be finished in a very limited period
The project requires infrastructure to meet the timeline
The project budget is very limited
Skilled resources to execute the design are very limited
Any vendor support needs for apps, servers, storage, and networks are limited
Any other factors that are affecting the design decision
If you purchased a SAN 3 years ago for a file server consolidation project, you plan to use it for a virtualization project, and you do not find any information about those devices, this can be categorized under the constraints section and it is really a critical component for the project execution phase.
Risk management is a key principle that is required to be considered while designing VMware vSphere infrastructure. Identifying the risk factor very early will help you to identify and highlight problems hiding inside your virtualization design effort:
The major risk listed in the virtualization project is whether the project will be delivered on time and on budget
Availability of technically skilled resources to complete the project on time
Not enough network bandwidth to handle the initial load
Isolating the infrastructure form development, pre-production to production
For example, you might be in a situation where the IT Management does not provide the required approval for changing the network core to increase iSCSI traffic. This can be characterized under risks on your design principles.
There are eight values of design as an outcome of design decisions. There are multiple ways to fulfill the functional and performance requirements, but a vSphere designer must evaluate each of the following against these eight values:
Does the choice positively or negatively impact the readiness of the design?
What about the design's manageability or performance?
What about recoverability and security?
What about risks, constraints, and assumption associated with it?
These principles provide generic guidance and direction on the best way to meet the functional and performance requirements for a particular design.
Before we wrap up this chapter, we will look at a final section on the process of designing VMware vSphere with its essentials.
Now that we've discussed the PPP framework of design and the value of design, it's time to discuss the procedure of design. In this section, we'll start with how we go about creating a VMware vSphere design. The following procedure illustrates the various processes that are required to be followed while creating a VMware vSphere design:
What are the needs of business users?
Which of the services currently meet those needs?
How are users performing?
What industrial or policy-linked restraints might there be?
Before you start building a design you need to build up a blueprint of what the context for that design is. This means lots of end user research, and a close assessment of current infrastructure and policies, ethics, and business needs.
Let's get started with requirement gathering, which is an important part of any IT virtualization project. Understanding what those requirements will bring, is success to virtualization project. Shockingly it's an part that is frequently given far too little courtesy.
Numerous designs start with the greenest list of demands, where some of via verse, for those we need focus and avoid these bottleneck ,by producing a document of requirements. This requirement document will acts as bible for design phase. It will, in turn, provide the following benefits as well:
A brief functional requirement for design purposes.
A statement of key objectives—a prime points condition
A description of the infrastructure in which the virtualization will work
Information on major design constraints to meet the requirements
The context on the statement of requirements should be stable. Architect should not allow state of changes, which will relatively slow down the phase of design and so forth.
Upon finalization of statement of requirements, make sure the business and respective stakeholders sign up and agrees to it. Technical artifacts expectation should inline to statement of requirements. No deviation should be entrained.
Here are well-known rules that will you help you successfully complete your requirement gathering:
Never assume what we have is what our client wants for
Involve the appropriate stakeholder right from beginning
Review, define and agree the scope of work for the virtualization
Make sure that the functional, nonfunctional and operational requirements are specific, measurable and realistic
Create a crystal-clear, detailed requirement document and share it with all the stakeholders to gain their confidence on the virtualization project
Demonstrate your understanding of the business requirements with all stakeholders (again and again)
Today, many organizations invest time and effort in building their requirements prior to engaging suppliers and consultants. Organizations implementing VMware vSphere have fully documented their functional requirements. This documentation often has outlines stating the organization objective.
For example, perhaps the enterprise is implementing virtualization as part of a VDI/Shared Desktop virtualization initiative. In that case, some of the functional and performances requirement of the VMware vSphere environment can be a show-stopper. In your VDI project, an initial requirement may be that the vSphere infrastructure should automatically restart VMs in the event of an ESXi host failure. The moment you read the statement, you may want to use vSphere High Availability on your design document in order to meet the given performance requirement. Since you have planned to use VMware vSphere High Availability, implementation of clusters is required. This, in turn means you have to set up redundant management connections that distress the networking and storage design and so forth.
Another case. Let's say an enterprise is migrating to a new datacenter and a team that has compiled the number of applications that have to be migrated. From that documentation, we can better understand the application requirements and identify the functional and performance requirements required to be supported by the virtual infrastructure that is intended to be designed. Possibly, the application dashboard documentation indicates that the IOPS profile is mainly writes instead of reads. This is a key element for designing the storage.
Though reviewing the existing documentation will be helpful, it's unlikely that you'll find all the information required for your design. But it is really worthwhile to spend time in identifying what is already available; it will save your time bridging the gap.
Technical assessment is a critical step between the planning and design of a virtualization project. It has three important modules—infrastructure assessment, business assessment, and operational assessment. The goal of the technical assessment is to inventory current infrastructure and identify virtualization candidates.
The key deliverables of this assessment will be as follows:
Baseline the list of servers, that are ideal candidates for virtualization
Baseline performance and utilization, which is very much essential for capacity planning
Data collection does not have the arrangement required for the virtual server farm design. Inventory data may encompass fault values and performance reports may have wrong data, because the monitored server was shut down or not reachable via the network. Moreover, performance reports extracted from servers having disparate configurations cannot be equated unless data is standardized. Indeed, we cannot compare processor utilization reports for servers with different types of processor.
This phase is predominantly interesting when the server landscape whose data is being analyzed contains a number of servers. For each server, many data facts are available, requirements will streamline the metrics that are required to be considered; however, for the designer it is worth considering the following tools for capacity planning and utilization measurements:
After you've gathered the information required to determine the design's functional requirements, it's then required to assess the current infrastructure. Assessing the infrastructure fixes a couple of gaps and, to do that, use the gap analysis as per the customer's demand.
Design integration is essential for the successful design of VMware vSphere. Integration of design can happen only if factors such as data architecture, business architecture, application architecture, and technology architecture are put together, as illustrated in the following diagram:
To be specific, with regard to technology architecture, always remember VMware vSphere should have a component model with components such as management layer architecture, network layer architecture, and storage layer architecture. Furthermore, it should integrate further with the cloud and SOA on demand.
In this chapter, we discussed the VMware vSphere landscape, designing VMware vSphere, and a list of challenges and encounters faced on the virtual infrastructure. Designing accelerates the solutions that resolve real-world obstacles, values, and procedures that need to be followed while designing VMware vSphere.
In the next chapter, you will learn about designing essentials for the management layer, which is, designing the VMware ESXi host, cluster, and vCenter.