NSXTD3 M02 Basic Design 0720

Module 2: NSX-T Data
Center Basic Design

Concepts
© 2020 VMware, Inc.

Importance
You must understand the principles for a well-developed NSX-T Data Center design and the benefits
of using the VMware Validated Design approach.
© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2-2

Module Lessons
1. Design Principles
2. Design Process
3. VMware Validated Design

Lesson 1: Design Principles
© 2019 VMware Inc. All rights reserved.

Learner Objectives
• Identify design terms
• Describe framework and project methodology

About Framework
A framework has the following features:
• A toolkit that can be used for delivery and assessment of a broad range of architectures
• A structure for content or process that can be used as a tool to represent thoughts and ensure
consistency and completeness
A framework typically consists of methodology, standards, and supporting tools.

Design Methodology
A design methodology describes an iterative, high-level process that is used to create a design.
The design methodology can include several phases. General phases are run in every engagement.

Design Tools
Design tools can include the following components:
• Supporting artifacts used to execute the methodology
• Defined vocabulary of terms unique to the framework

Guiding Principles
Guiding principles are best practices and recommendations for the correct assembly of the
architecture according to the framework:
• Standards are developed in the field. They provide guidelines, not rigid rules:
– Standards include configuration and processes.
• Standards are sometimes common practices.
• Standards are used to avoid problems and get results.
• You must always balance best practices with an organization’s objectives.
• Best practices are often used in the absence of other requirements
• Best practices are not static. They evolve as technology evolves.
• No single, online location for best-practice information is available.

Design Sessions
Design decisions are made during design sessions, such as interviews and whiteboard sessions.
A design considers the organization’s goals, requirements, constraints, and the guiding principles.
To provide a solution that works, involve key stakeholders and SMEs early and often in design
sessions:
• Do not surprise the key stakeholders and SMEs.
• Explain design risks caused by constraints and requirements.
© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 10

Design Tradeoffs
Designing is a balancing act between the following factors:
• Technical best practices
• Organization goals, requirements, and constraints
Designing often involves tradeoffs. Every design choice has design
implications that must be weighed.
Communicate risks to all stakeholders.
Perform a final gap analysis between your design and the
organization’s goals and requirements.

End Goals
A good design:
• Involves the organization’s key stakeholders and SMEs
• Balances business goals and requirements with technical considerations and best practices
• Has documented rationale and considerations
• Includes sufficient detail to be unambiguous
• Is not complex
• Considers target states
• Is repeatable
• Is constantly evolving

Review of Learner Objectives
• Identify design terms
• Describe framework and project methodology

Lesson 2: Design Process

Learner Objectives
• Identify customers requirements, assumptions, constraints, and risks
• Explain the physical design
• Explain the conceptual design
• Explain the logical design

Using Frameworks (1)
Use a framework that:
• Identifies the correct stakeholders
• Extracts the most relevant customer business drivers
• Drives business objectives throughout all layers of the engagement
• Provides top-to-bottom transparency and traceability for all decisions
• Is less limited by specific technologies and engagements:
– Flexible enough to deliver products that have not been considered
– Can be used beyond design engagements
– Deliverable to VMware technology stacks

Using Frameworks (2)
A good framework has:
• Clear and repeatable methodology
• Accessible and scalable tools
• Reasonable and justifiable standards

About Design Frameworks
The use of a standard framework communicates
an organized and professional approach to
customers.
Design qualifiers ensure that all levels of the
engagement are met. Each qualifier affects the
other qualifiers.
Design qualifiers include:
• Availability
• Manageability
• Performance
• Recoverability
• Security
• Cost

Steps in the Life Cycle (1)
The life cycle includes the following steps:
1. Discover:
• Define the scope and educate the customer.

• Document customer objectives.
• Test customer objectives against actual needs.
• Solicit and document customer requirements, assumptions, and constraints.

Steps in the Life Cycle (2)
2. Develop:
• Create and document the solution.

• Ratify design validation procedures.
3. Execute:
• Build, deploy, implement, operationalize, test, and verify.

4. Review:
• Measure the performance against customer objectives.

• Identify the next customer opportunities.

Customer Constraints, Requirements, and Assumptions (1)
Interview stakeholders and SMEs to determine how the
organization’s constraints, requirements, and assumptions might
affect the design or limit design choices.
For example, because of an existing vendor relationship, host
hardware was already selected.
Identity constraints:
• Political factors that might affect the design
• Business objectives and requirements
• Regulatory compliance issues
• Project schedule
• Training and skills that are required
• Budget constraints that affect the design
• Involvement of remote offices
• Organizational policies that affect the design
• Security requirements
Customer Constraints, Requirements, and Assumptions (2)
Identify and list the project’s key business and technical requirements:
• For example, the organization must comply with Sarbanes-Oxley regulations.
• For example, the underlying infrastructure for any service defined as strategic must support a
minimum of four 9s of uptime (99.99 percent).
Identify and list the design assumptions:
• Assumptions are design components that are assumed to be valid without proof.
• For example, the data center uses shared (core) networking hardware across production and
nonproduction infrastructures.
• For example, the organization has sufficient network bandwidth between sites to facilitate
replication.
• For example, security policies dictate server hardware separation between DMZ servers and
internal servers.

Design Risks
Risks might prevent you from achieving project goals.
Identify and list design risks. For example, the organization's main data center contains only a single
core router, which is a single point of failure.

Stakeholder and SME Training
Educate the key stakeholders and SMEs, who assist with creating the architectural design, about
vSphere and virtualization.
These key stakeholders and SMEs can provide valuable input during the design process.
Education choices include:
• Scheduled customer classes delivered by VMware Education.
• Dedicated classes delivered by VMware Education.
• Jumpstarts (onsite mentoring), delivered by VMware or partners, require a training or test
environment.
• Minimum training should include vSphere and NSX-T Data Center.

Working with Stakeholders
Stakeholders must include representatives for all groups that are
affected by the design, including:
• A project sponsor, such as the CIO, VP Infrastructure, or IT
Director
• Virtualization architects
• Business decision makers
• Core technical teams, such as product development, server,
storage, networking, security, and backup and recovery
You interview stakeholders and conduct workshops to gather
requirements and build consensus:
• Asking the correct questions is vital.
• Gathering requirements is an iterative process, which might
require multiple rounds of interviews.
• Gather both functional and nonfunctional requirements.

Gathering Application Requirements
Application requirements determine how to optimize the design.
Gather application requirements from the following sources:
• Interviews with application owners
• Application SLAs
• Vendor documentation and industry averages
• VMware best practice guides
The following examples show the type of information to gather:
• Workload characteristics (business-critical, VDI, ITaaS, and so on)
• Hardware and software requirements
• Service dependencies
• Communication requirements between applications and with the
outside world
• Security zoning requirements
• Specifications for performance, availability, and so on
Identifying Business Objectives
You start the design process with a set of clear business objectives that
help define the scope of the project and keep the design on track.
Examples of common business objectives:
• Extend the vSphere platform to other areas of the business.
• Build a strong foundation for future projects, including cloud
infrastructures.
• Optimize the existing implementation to change and expand over
time.
• Consolidate servers across multiple data centers.
• Virtualize the environment for business-critical applications.

Identifying Business Factors That Affect Design
When conducting interviews, you ask questions to learn about business
conditions and practices that affect the design.
The following common factors might affect the design:
• Organizational boundaries: physical, political, and cultural
• Prior experience with virtualization and VMware products
• Service-level agreements (SLAs)
• Security and compliance requirements
• Time and project urgency
• Policies and procedures
• Training requirements
• Budget constraints
• Future scaling

Output Classification

Conceptual Design
Gather the following information to create the conceptual design:
• From key stakeholder and SME interviews: Scope, goals, requirements, assumptions, and
constraints
• From the current state analysis
The conceptual design focuses on achieving the organization’s business goals and requirements:
• Determine the entities that are affected by the project (lines of business, users, applications,
processes, management methods, physical machines, and so on).
• Determine how the goals, requirements, and constraints map to each entity.
• Design infrastructure that will be necessary to achieve each entity’s goals and requirements, while
staying within constraints. For example, consider where you will need availability, scalability,
performance, security, manageability, and so on, while staying within cost and other constraints.
• Document the conceptual design with diagrams, tables, and text.

Creating a Conceptual Design (1)
The conceptual design captures the assessment findings to ensure that the solution meets goals and
requirements, while staying within constraints.

Creating a Conceptual Design (2)
The conceptual design categorizes assessment findings into requirements, constraints, assumptions,
and risks:
• Business requirements must be provided, and a solution must achieve these requirements.
• Constraints are conditions that provide boundaries to the design.
• Assumptions list the conditions that are believed to be true but are not confirmed. By the time of
the deployment, all assumptions should be validated.
• Risks are factors that might have a negative effect on the design.

Logical Design
The logical design includes the relationships between all major infrastructure components, with the
following considerations:
• Conceptual design
• Technical requirements
• Constraints and risks
The logical design is useful for understanding and evaluating the design of the infrastructure:
• The logical design ensures that the design meets the goals and requirements while staying within
the constraints.
• The logical design does not include physical details such as vendor models, host names, IP
addresses, and port connections.

Creating the Logical Design
The logical design includes design decisions on
how to arrange all major infrastructure
components to satisfy service dependencies and
requirements that are specified in the conceptual
design.
For example, design decisions include the
following components:
• Management
• Clusters
• Storage
• Networking
• VMs
• Security
The Design phase is an iterative process.

Design Decision Justifications
Designs are a series of compromises. When a design decision does not directly relate to a
requirement, you use nonfunctional requirements to evaluate and justify the decision.
Principle Description
Scalability How easily can the solution expand for future growth?
Availability How well does the solution ensure that services are available to meet business
goals and requirements?
Manageability How flexible is the solution? Will the solution make operations simpler or more
complex?
Performance How does this solution affect infrastructure performance?
Security Does this solution make the infrastructure more or less secure?
Recoverability How well does this solution meet RTO and RPO requirements?
Cost Are one-time and ongoing costs worth the gains of the solution? When will ROI
be reached?

Example of a Logical Design
The logical design includes design decisions, justifications, and implications for the major
infrastructure components. Design decisions must support the requirements, constraints,
assumptions, and risks that are outlined in the conceptual design.
Assign an identification number to each design decision. The identification number allows the
architect and stakeholders to easily reference decisions.
ID Design Decision Design Justification Design Implication

DD01 Two vCenter Server Because the client has a policy to The client must buy a
instances will be used. separate the dev/test environment license for each site.
from the production environment, each However, manageability
environment will have its own vCenter will be improved.
Server instance.
DD02 The vCenter Server The client wants to manage both sites Multiple linked vCenter
instances will be from the same interface. The sites will Server instances require
configured in use roles and permissions to limit an external Platform
enhanced linked access. Services Controller
mode. appliance.

Physical Design
Use the logical design to create the physical design.
A physical design includes specific vendor and implementation details:
• Vendor models
• Host names
• IP addresses
• Port connections
• LUN sizes
• Number of CPUs
• Other specific physical details

Creating the Physical Design
The physical design provides the detailed specifications for purchasing hardware and ultimately
deploying the solution.

Physical Design: Example of an Implementation Guide
An implementation guide is
intended to define the steps and
the variable required to deploy
the solution. In this case, it is
focused on the physical design.
The physical design moves into
implementation details, based
on the logical design.
More than one physical design
can be built, based on a quality
logical design.

Comparing Logical and Physical Views

Design Deliverables
The final step in the design process is the creation of the design documents:
• The number and type of design documents vary by project.
• The following factors affect the number and type of documents delivered:
– Project cost
– Project length
– Design type:
• Solution-oriented designs typically require more custom documentation.
• Product-oriented designs might include a larger proportion of references to instructions in
online documentation.
– Level of detail requested by the organization

Required Document Deliverables
The ability to produce the correct documentation is a critical step in conveying the solution’s impact
to the business:
• Capacity-analysis report:
– This report might contain the financial total cost of ownership and ROI information.
• Design document:
– Is a blueprint for the actual design
– Includes conceptual, logical, and physical design information
– Discusses all design aspects

Design and Deploy Process

Examples of Deliverables by Phase
Each phase of a project includes the following deliverables:
Phase Documentation
Assessment • Current state analysis report
• Conceptual design
Design Design blueprints, which include the following information:
• Logical design
• Physical design
Deployment Installation and configuration documentation
Validation Validation plan with test results

• Identify customers requirements, assumptions, constraints, and risks
• Explain the physical design
• Explain the conceptual design
• Explain the logical design

Lesson 3: VMware Validated Design

Learner Objectives
• Describe VMware Validated Design
• Describe the benefits of using VMware Validated Design
• Identify the composition of VMware Validated Design
• Describe the methodology of VMware Validated Design
• Create the VMware Validated Design bill of materials (BOM)
• Explain VMware Cloud Builder

Introducing VMware Validated Design
VMware Validated Design provides prescriptive blueprints with comprehensive deployment and
operational practices.
Complete Data Center-Level Designs
Standardized and Consistent
Proven and Robust
Applicable to Broad Use Cases

Ensuring Interoperability and Resiliency
VMware Validated Design is extensively tested to ensure interoperability and resiliency.

Benefits of VMware Validated Design
VMware Validated Design enables the deployment of a software-defined data center (SDDC).

VMware Approach to SDDC

VMware Validated Design for SDDC 6.0 Software BOM
VMware Validated Design is now aligned with the latest release of VMware Cloud Foundation.

About VMware Cloud Builder (1)
VMware Cloud Builder has the following characteristics:
• Automated SDDC deployment:
– Streamlined VMware Validated Design deployment experience
– Fully automated
– Reduces time and effort to deploy SDDC
• Supports:
– Single region
– Dual region
– Consolidated
• VMware Cloud Builder prerequisites:
– To automate the deployment, the Cloud Foundation Builder VM must be on the same
management network as the hosts to be used.
– The Cloud Foundation Builder VM must also be able to access all required external services,
such as DNS and NTP.

About VMware Cloud Builder (2)
Customer-specific information is captured in the
Deployment Parameters XLS file:
• This file is used to capture SDDC configuration
parameters:
– VM names
– License keys
– Users and groups
– Passwords
– Hosts and networks
– vRealize Suite parameters
– Deployment parameters
• This file is imported to VMware Cloud Builder
and used to automate the deployment of the
SDDC.

Additional Resources
Resource Location
Main Site http://vmware.com/go/vvd
Documentation http://vmware.com/go/vvd-sddc
Community http://vmware.com/go/vvd-community
Videos and Demos http://vmware.com/go/vvd-videos
Certified Partner Architectures http://vmware.com/go/vvd-cpa
vExpert Slack http://vexpert.slack.com > #vvd

Lab 1: Gathering Requirements
Review and document the customer requirements:
1. Read the Customer Background
2. Read the Customer Requirements
3. Document the Constraints, Risks, and Assumptions

• Describe VMware Validated Design
• Describe the benefits of using VMware Validated Design
• Identify the composition of VMware Validated Design
• Describe the methodology of VMware Validated Design
• Create the VMware Validated Design bill of materials (BOM)
• Explain VMware Cloud Builder

Key Points
• A solid design is based on guiding principles which define best practices, recommendations, and
standards.
• A sound design approach includes a design methodology, staff training, and discussions with
stakeholders.
• Requirements, constraints, assumptions, and risks must be identified and listed.
• Decisions must be made to balance technical best practices, business goals, and constraints.
• A good design is repeatable, documented with decision rationale, and detailed for clarity.
• A physical design provides the technical details to implement the physical infrastructure.
• A conceptual design focuses on achieving the business goals and requirements.
• A logical design does not include physical details but it indicates the balance between the
business goals versus constraints and risks.
Questions?

NSXTD3 M02 Basic Design 0720

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NSXTD3 M02 Basic Design 0720

Uploaded by

Copyright:

Available Formats

Module 2: NSX-T Data

Center Basic Design

© 2020 VMware, Inc.

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2-2

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2-3

© 2019 VMware Inc. All rights reserved.

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2-5

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2-6

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2-7

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2-8

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2-9

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 10

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 11

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 12

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 13

© 2019 VMware Inc. All rights reserved.

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 15

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 16

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 17

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 18

• Define the scope and educate the customer.

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 19

• Create and document the solution.

• Build, deploy, implement, operationalize, test, and verify.

• Measure the performance against customer objectives.

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 20

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 22

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 23

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 24

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 25

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 27

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 28

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 29

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 30

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 31

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 32

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 33

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 34

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 35

ID Design Decision Design Justification Design Implication

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 36

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 37

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 38

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 39

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 40

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 41

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 42

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 43

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 44

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 45

© 2019 VMware Inc. All rights reserved.

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 47

Complete Data Center-Level Designs

Standardized and Consistent

Proven and Robust

Applicable to Broad Use Cases

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 48

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 49

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 50

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 51

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 52

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 53

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 2 - 54