NET1536BU Reference Design for SDDC with NSX and or ... · •This presentation may contain product...

Nimish Desai, Director NSBU VMware

NET1536BU

#VMworld #NET1536BU

Reference Design for SDDC with NSX and vSphere: Part 2

VMworld 2017 Content: Not fo

r publication or distri

bution

• This presentation may contain product features that are currently under development.

• This overview of new technology represents no commitment from VMware to deliver these features in any generally available product.

• Features are subject to change, and must not be included in contracts, purchase orders, or sales agreements of any kind.

• Technical feasibility and market demand will affect final delivery.

• Pricing and packaging for any new technologies or features discussed or presented have not been determined.

Disclaimer

#NET1536BU CONFIDENTIAL 2



bution

Goals of the Session & Customer Takeaway

• Establish reference architecture is validated and proven

• Include existing deployment experience and explain the changes in best practices if any

• Expand session to cover few design topics not covered before – security, routing details etc.

• Include new and upcoming features and changes in design guides




bution

1 DC Sizing & Topologies

2 NSX Security Services Design

3 NSX with SDDC Use Case

4 Summary and Q&A

Agenda




bution

Compute Cluster Connectivity

DC Design ConsiderationCompute Cluster

• Rack based vs. multi-rack (horizontal) stripping

– Availability vs. localized domain – CPU & mobility constraint & simplification of connectivity (IP, VTEP, Automation)

• Lifecycle of the workload drives the consideration for

– Growth, availability and changes in the application flows

– Multi-rack, zoning ( type of customer, tenancy etc.)

• Typically rack connectivity is streamlined and repeated

– Same four VLANs typically streamlines the configuration of ToR

– Connectivity to the fabric and requirement for additional capacity remains the same since its abstracted from infrastructure

• Workloads type, compliance and SLA can be met via

– Cluster separation

– Separate VXLAN network

– Per tenant separation routing domains

– DRS

Management

WAN

Internet

L3

L2

Compute

Cluster

Host 1

Host 3

Host 2

Host 6

Host 5

Host 4

Host 1

Host 3

Host 2

Host 6

Host 5

Host 4

Compute Clusters

L3

L2

DC Fabric

Edge Clusters




bution

NSX Sizing is Based on a Modular Footprint

• NSX footprint is sized based on customer requirements

• Once these requirements are defined, then map NSX components to infrastructure resources

• Similarly separate VCs for Management and Compute is not an NSX requirement

• Network Virtualization with NSX enables greater flexibility regardless of physical network design

• NSX capabilities are independent of network topology

• Flexibility with NSX components

– Controller are in management cluster with single VC

– Controller must register to VC where NSX manager resides

– Edge Resources are flexible in terms of vCPU and memory

– NSX stack is flexible – DFW only vs. full stack

– Three tier licensing allow flexibility that maps to cost and growth




bution

Small Design Considerations

• Understanding the workload that impact NSX component selection

– Edge workload is CPU centric with consistent memory – except in L7 load-balancer Edge services

– Edge resources requires external connectivity to VLANs thus restricting it location to avoid VLAN sprawl

• Single cluster for small design, expand to medium with separation of compute cluster

– Single cluster can start with DFW only design

• NSX Manager is the only component required

• VDS license comes with NSX

– Progress to full stack for other services such as FW, LB, VPN and VxLAN

• ESG in active-standby – Large form factor

• Quad-large if needed for firewall throughput

• Static routing for simplicity and reduced need of deploying control-VMSingle Cluster with NSX

WAN

Internet

L3

L2

Host 1

Host 3

Host 2

Host 32

Host y

Host x

NSX for Small Data Centers – Breaking

BoundariesNET1853




bution

Cluster Design with Medium DC

• Mixing compute and edge workload requires

– Balanced Compute workload can be mixed with Edge VM resources

– However the growth of compute can put additional burden on managing resource reservation to protect the Edge VM CPU

• Collapsing edge OR compute with management components (VC and NSX manager)

– Requires management component to be dependent on VXLAN since VXLAN enablement is per cluster bases

– Expansion or decoupling of management required for growth

• moving management cluster to remote location

• Having multiple VCs to manage separation

• Mixing Edge and Management is a better strategy

– Consistent static requirements of the resources – mgmt. is relatively time idle resources compared to compute workload

• For growth consider separation of edge and mgmt. cluster

Management

&

Edge Clusters

Separate Compute

Common Edge and Management Cluster

with NSX

WAN

Internet

L3

L2

Compute

Cluster

Host 1

Host 3

Host 2

Host 32

Host y

Host x




bution

Cluster Design with Medium DC – Continue

• Small to medium cluster can utilize the edge service gateway features where

– N-S BW is not more then 10 G

– Desire to reduce external FW usage with Edge FW functionality

– Using built in Load Balancer

– Use VPN or SSL functionality

• Edge Services Sizing

– Start with Large (2 vCPU) if the line rate BW is not required

– Can be upgraded to Quad-Large (4 vCPU) for growth in BW

• Consider LB in single arm mode to be near the application segments

• Decouple the need to Edge service mode choice if only LB service is required

Management

&

Edge Clusters

Separate Compute

Common Edge and Management Cluster

with NSX

WAN

Internet

L3

L2

Compute

Cluster

Host 1

Host 3

Host 2

Host 32

Host y

Host x




bution

Large DC Cluster Design

• Workload characteristics

– Variable

– On-demand

– Compliance requirements

• For cross-VC and SRM Deployment

– Separation of management cluster is inevitable

• Large scale Edge Cluster Design

– Dedicated minimum four hosts

– Minimum four ECMP Edge (Quad Large) 40 GB total BW

– Separate host with DRS protection between ECMP Edge VM and Active Control-VM

– Capacity for services VMs

• Edge VM CPU Guideline

– Ideally >= 2.6 GHz with 10 core to hold min two ECMP VMs for 20 GB (2x10 NIC) bandwidth

– Higher cores can be used to consolidate VMs but may need 4x10 GB network ports

– Keep the CPU/Socket consistent for Edge cluster to have flexibility

Edge Cluster

Separate Management Compute

& Edge and Cluster with NSX

Management

WAN

Internet

L3

L2

Compute

Host 1

Host 3

Host 2

Host 6

Host 5

Host 4

Host 1

Host 3

Host 2

Host 6

Host 5

Host 4

Compute

L3

L2

DC Fabric




bution

Edge Cluster Design

• Minimum four hosts Cluster

– Two host to hold two ECMP Edge VMs

– Other two for DLR Control-VM

– Not to mix ECMP and DLR-Control VM

• Avoiding race condition due to dual failures of components during host failure

– Anti-affinity is automatically enabled for DLR Control-VM

– Need anti-affinity and DRS protection group for ECMP VMs

• Host Uplink & VDS

– Use “SRC_ID with Failover” teaming for VXLAN traffic

– Route peering maps to unique link

• Performance & Sizing

– Intel, Broadcom or Emulex supporting VXLAN offload including RSS and TSO offload

• Oversubscription Dependent on

– Upstream connectivity from the ToR

– Application requirements

– Density of Edge VM per hosts

L3

L2

VLAN 10 VLAN 20

Host 1 Host 2

ESG-01 ESG-02 ESG-03 ESG-04

Host 3 Host 4

VM DRS Group 1

VM DRS Group 3

VM DRS Group 2

Bridge

Instance

L3

L2

Host 1

VLAN 10 VLAN 20

L3

L2

VLAN 10 VLAN 20

No over subscription 1:2 over subscription

Host 2

Host 1 Host 2




bution

Small, Medium and Large Virtualized DC – NSX Scales Consistently

Sizing VC Workload Edge Type N-S BW GB Cluster Choice RequirementResource

Reservation *

Small 1 ConsistentLarge - 2 vCPU

< 20 G Collapsed

Harder to

separate Mgmt.

later

Need for Edge

VMsESG or ECMP

Med 1

Consistence

Some on-

demand

Large to Quad

2 or 4 vCPU< 40G Mgmt./Edge

Growth not likely,

No other smaller

DC

Need for Edge

VMsESG or ECMP

Med (with

multiple DC

or compute

growth)

>1On-demand

With DR

Quad – 4 vCPU

<= 40G

Separate Mgmt.,

Edge and

Compute

Cluster

Growth or other

DC integration

must

If needed for

mix useECMP for N-S

ESG for local LB

Large >1

Variable, on-

demand, DR,

Inter-site and

dev-ops

Quad – 4 vCPU> 40G and

multi-tenant

Separate Mgmt.,

Edge and

Compute

Cluster

Scale &

AvailabilityNA

Multi-tier for

services

* Automatic resources reservation 6.2.3 onward#NET1536BU CONFIDENTIAL 16



bution

Enterprise Topology – Two Tier Design – with Edge Services with ECMP

• Typical Enterprise topology consist of app-tier logical segments

• Edge Services gateway needed to enable services such as firewall, NAT and VPN along with N-S routing

• Edge FW with ECMP – active/standby edge

• Only one Edge VM is possible per tenant

• Still need to enable ECMP mode

• Firewall and NAT is supported without asymmetric traffic issue

• Can have multiple peer to physical routers, reduced single point of failure

• Still needs OSPF and BGP protocol timer needs to be 40/120 for avoiding secondary failure of peer time out

VLAN 20

Edge Uplink

External Network

Physical Router

Web1 App1 DB1 Webn Appn DBn

NSX Edge HA

with two ECMP

Uplinks

VXLAN 5020

Transit Link

Distributed Routing

Routing Peering

Routing Peering




bution

VLAN 20

Edge Uplink

External Network

Physical Router


NSX Edge

VXLAN 5020

Transit Link

Distributed Routing

Routing Peering

Routing Peering

Web DB

DLR

E8E1

Physical Router

E2

…

App

Core

Routing Peering

Route Update

ECMPNon-Stateful

E3


Enterprise Topology – Two Tier Design – with ECMP

• ECMP Edge mode scalable BW and faster convergence

– 80 GB and higher

– Faster convergence up to 3 seconds and 1/8 of the traffic loss

– DLR to Edge timers tunable as well

– Disable firewall explicitly

• Edge Scaling

• Per tenant scaling – each workload/tenant gets its own Edge and DLR

• ECMP based scaling of incremental BW gain

– 10G BW upgrade per spin up of Edge up to maximum of 80 Gig(8 Edges)

– DLR Scaling can be up to 1000 LIF

– 998 logical network per DLR instance



bution

Flexible, Scalable, Secure & Multi-use

External

Networks

Dynamic Routing

(OSPF, BGP)

ECMP

Edges

Web Logical

Switch (Routed) App LS (Routed) DB LS (Routed)

In-line LBRouted

172.16.20.0/29 172.16.20.8/29 172.16.20.16/29

Web Logical

Switch (NAT) App LS (Private) DB LS (Private)

In-line LBNAT & Private

172.16.100.0/24 172.16.101.0/24 172.16.102.0/24

Web Logical

Switch (Routed)

DB Logical

Switch

(Routed)

App LS

(Routed)

172.16.10.0/29 172.16.10.8/29 172.16.10.16/29

Distributed Logical Router

• Flexibility – DLR, Stand-alone, Services & Isolation

• DLR for production workload• DevOps & QA isolation• Per app services

• Scalability• ECMP BW as needed• Edge-HA based on use case• In line routed LB segment• In line NAT & private segment

• Secure• DFW and Edge FW• Multi-vendor integration

• Automation – Blueprints and Security• Multi-use topology

• Automated DevOps segments• VDI Segments• Enterprise work load




bution

Automation Topology

ToR

Web Logical


In-line LBNAT

172.16.100.0/24 172.16.101.0/24 172.16.102.0/24

ToR

Web Logical


In-line NAT

172.16.100.0/24 172.16.101.0/24 172.16.102.0/24

Edge - HA

Web Logical

Switch

(Routed)

DB Logical

Switch

(Routed)

App LS

(Routed)

172.16.11.0/29 172.16.11.8/29 172.16.11.16/29

ECMP

Edges

Web Logical

Switch

(Routed)

DB Logical

Switch

(Routed)

App LS

(Routed)

172.16.10.0/29 172.16.10.8/29 172.16.10.16/29


• Pre-created Construct

• Provider ECMP for scale

• DLR e.g. production traffic

• All app segments can be dynamically created

and attached to DLR with security group

• QA/DevOps Topology

• Provider Edge HA

• Common transit VXLAN segment

• Allows provider Edge in Edge Cluster

• QA/DevOps Tenant Edge/Segments

• Resides in compute for growth and agility

• NAT with In line LB

• Create as many Edge with NAT

• No need to advertise subnets of each NATed QA

segments




bution

Multi Tenant (DLRs) Routing Topology

• Can be deployed by Enterprises, SPs and hosting companies

• No support for overlapping IP addresses between Tenants connected to the same NSX Edge

• If the true isolation of tenant routing and overlapping IP addressing is required –dedicated Edge HA mode is the right approach

External Network

Tenant 9

DLR Instance 9 DLR Instance 1

Web Logical

Switch App Logical Switch DB Logical SwitchWeb Logical

Switch App Logical Switch DB Logical Switch

Tenant 1

NSX Edge

VXLAN 5020

Transit Link

VXLAN 5029

Transit Link

…

VLAN

VXLAN




bution

High Scale Multi Tenant Topology

• High scale multi-tenancy is enabled with multiple tiers of Edge interconnected via VxLAN transit uplink

• Two tier Edges allow the scaling with administrative control

– Top tier Edge acting as a provider Edge manage by cloud(central) admin

– Second tier Edges are provisioned and managed by tenant

• Provider Edge can scale up to 8 ECMP Edges for scalable routing

• Based on tenant requirement tenant Edge can be ECMP or ESG Services mode

• Used to scale up the number of tenants (only option before VXLAN trunk introduction)

• Support for overlapping IP addresses between Tenants connected to different first tier NSX Edges

External Network

Tenant 1

Web Logical

Switch

App LS DB LS

…

Web Logical

Switch

Edge with HA

NAT/LB

features

ECMP Based

NSX Edge X-Large

(Route Aggregation

Layer)

ECMP Tenant

NSX Edge

VXLAN Uplinks

or VXLAN Trunk*

VXLAN

Uplinks or

VXLAN Trunk*

VXLAN 5100

Transit

App LS DB LS

*Supported from NSX Release 6.1 onward

… E8E1




bution

Mapping NSX Multi-Tenant to Physical Network Segmentation

• Each dedicated Tenant Edge can connect to a separate VRF in the upstream physical router

• The Department or Zone maintains

– VLAN and/or VRF level Isolation

• DLR and ECMP for Production

• Edge with services for QA/Dev

Tenant 1

Web Logical

Switch App Logical Switch DB Logical Switch

…

Physical Router

(PE or Multi-VRF CE)

C2

VLAN 10

Prod 1 VRF

T1 T2

Automated ESG

T1

T2

VLAN 20

VLAN

Web Logical

Switch App LS DB LS

In-line LBNAT

172.16.100.0/24 172.16.101.0/24 172.16.102.0/24

Web Logical

Switch App LS DB LS

In-line

NAT

172.16.100.0/24 172.16.101.0/24 172.16.102.0/24

Pre-created

Edge - HA

Automated ESG

Pre-created

Production

ECMP Edge

Dev 2 VRF

VXLAN




bution




4 Summary and Q&A

Agenda




bution

NSX Security Architecture Overview

• Design and Architectural Goals

– Built In and not bolt on

– On demand and dynamic security enforcement

– Follow life cycle of resources

– Run time redirection and insertion

– Topology independent, Not tied to physical

– DR and multi-site capable

– Build eco-systems

– Protect, detect, inoculate - Any application, any time, anywhere

Any App, Any VM,

Anywhere

DFW

Service Composer

Security Groups

Policy

Eco System




bution

Security Design Life Cycle

How do one take multi dimensional problem of securitization of assets and resources:

• Typically answer lies into developing framework and then policy model for each

• Lifecycle applies to specific to domain or use case

• Develop right level of control and risk with a flexibility of automation

– Per zone or tenant

– Regulated Environment

– Workload centric – VDI, Prod, QA

– Infrastructure traffic

– Physical FW and devices interaction

• Typically an inventory or grouping of application for a given zone or tenant or tiers is required

– What methodology is used to group?

– How to discover?

– How to automate?

Risk & Control

Zones

Access Pattern

Dependencies

Grouping

Policy Model




bution

Security Design Life Cycle

• Existing policy of isolation, segmentation and regulation is the base line

• Existing infrastructure services identification

– Shared services could be specific to zone or enterprise, either one requires discovery

• Develop dependencies model of security – level and inheritance based on app tier, zone, regulation

– Whitelist or blacklist

– Either requires known-knowns or known-unknown

• Use Log Insight, vRNI and SPLUNK to develop detail dependencies

– Default allow with log

– Default deny with log

• Degree of micro-segmentation determines the level of discovery and grouping criteria

• Repeat for each zone, tenant or workload

Identify Group/App

s/Zone

Decide Default Allow or

Deny & Log

Shared Services

Rules

Monitor Logs to R/Define

Rules

New App or Zone

Inventory

E-W Intra-App Rules




bution

Building a Sample Policy Model

• Starting point

– A cluster of applications

– Business units or tenants

– Regulated entities, security tiered segments

• Isolation between zones and tenants by various means

– DFW, Edge FW and DLR

• Each zone may have further isolation requirements

– DFW granularity drives degrees of isolation

• What type of transition flexibility is desired to replace/augment physical FW

– Is that transition comes in parallel or in a step?

– What is the first goal? Is that east-west isolation and/or automating security?

– Is this brownfield?

Zone - 2Zone -1



External NWInternal

Network

Zone-1 Physical Zone - 2 Physical

Shared Services#NET1536BU CONFIDENTIAL 31



bution

Follow zone principle, keep zone traffic security below

physical FW

Traffic Pattern & Access Drives the policy:

• Shared Services Policy

• For a zone virtual to that zone physical

• All east-west - Virtual zone to zone

• Physical FW manages physical zone isolation

• Each pattern becomes a bubble of security zone

• Further tightening of the connectivity inside bubble to

drive the micro-segmentation per app, per bubble

Policy Model

Zone - 2Zone -1



External NWInternal

Network

Zone-1 Physical Zone - 2 Physical

Shared Services#NET1536BU CONFIDENTIAL 33



bution

Policy with E-W Traffic

• No dependency on physical FW, co-exist with physical FW

• Applicable to either brown field or green field

• VLAN or VxLAN based

• FW rule table or service composer based enforcement

• Net new rules set discovery for east-west traffic

– Start will simple isolation

– Discover flows and tighten the rules

• Use vRA to enable “app isolation” method for automation based workload

Identify Group/App

s/Zone

Decide Default Allow or

Deny & Log

On-Board New Apps

Monitor Logs to R/Define

Rules

Shared Services

Rules

E-W Intra-App Rules




bution

Micro Segmentation Design Patterns

STOP

Stateful DFW

STOP

STOP

Stateful DFW

Stateful DFW

STOP

ControlledCommunication

STOP

Stateful DFW

Stateful DFW

STOP

STOP

Stateful DFW

Stateful DFW



STOP

STOP

Stateful DFW

Stateful DFW


PhysicalRouter

PhysicalRouter

Edge ServicesGateway



Policy

Policy Policy

PolicyPolicy

Traffic Steering Partner Advanced

Services

Traffic Steering Partner Advanced

Services

Distributed Segmentation Distributed Segmentation with Network IsolationDistributed Segmentation with Network Isolation And Service Insertion

Distributed Segmentation with Network Overlay Isolation Distributed Segmentation with Network Overlay Isolation and Service Insertion




bution

Components Of Security Platform

• DFW Objects and ”Apply to”

• Identity – AD Groups

• VC Container Objects – DC, Cluster, Port-Groups, Logical SW

• VM Characteristics– VM Names, Security Tags, Attributes, OS Names

• Protocols, Ports, Services

• TAGs

• Services Composer

– Security Groups

– Security Policy - application centric policy like DFW rules (l2-L4)

• Static and Dynamic Grouping

– Nested and inheritance

– Intelligent Grouping

• Automated Discovery

– Log Insight and vRNI (formally Arkin)

• Automation and API

– App Isolation

– Dynamic Management of security

Internet

Intranet/Extranet

Perimeter

Firewall

(Physical)

NSX Edge

Service

Gateway

SDDC (Software Defined DC)

D

F

W

D

F

W

D

F

W

Distributed FW - DFW

Virtual

Compute Clusters

Stateful Perimeter

Protection

Inter/Intra

VM

Protection#NET1536BU CONFIDENTIAL 37



bution

Service Composer

Decouples workloads from underlying network topology.

Automates deployment and enforcement of services.

Centralized Management for all distributed services.

Workflow Creation using multiple services.




bution

Security Groups & Policy Relation

• Security Groups provide a way of grouping workloads into containers.

• Security Policies allow a way to deploying services.

• NSX Security Groups (SGs) are pre created or On-Demand via vRA blueprint automation

• Pre-Existing NSX Security Policies are attached to the SGs

• Multiple existing Security Policies can be attached to the On-Demand SG’s

• Automatic removal of VM membership in security group

SECURITY GROUPSECURITY POLICY A

“Standard DB” Firewall – allow

inbound MySQL,

allow outbound DNS

AV – enable

Agentless AV and

Anti-Malware

“Standard Web” Firewall – allow

inbound HTTP/S,

allow outbound ANY

IPS – prevent DOS

attacks, enforce

acceptable use

SECURITY POLICY B




bution

Optimum Policy Model

Optimum Policy & Groups

Nesting of Groups

Policy Inheritance

Policy Weights




bution

vRealize Automation & NSX: Security Options

Existing Security Groups

On-Demand Security Groups

Existing Security Tags

App Isolation




bution

App Isolation

• App Isolation provides an optional first level of security:

– All inbound and outbound application access is blocked

– Intra application traffic is permitted

• Other policies are applied at a higher precedenceto permit/deny selected traffic

Web

App

DB

Web

App

DB

vRealize Automation & NSXNET1853




bution

Micro-Segmentation with vRA

• vRA is an excellent fit for automating Micro-Segmentation

• Provides application context to enable a policy based approach to security

• Granular security requires a mix of different vRA options:

– Existing or On-Demand SGs for Common Services access

– Existing SGs to control traffic within the deployment

– App Isolation to block traffic across deployments

• Rule ordering is defined by Security Policy’s Weight

• Service Composer configured to apply rules to Policy’s SGs:




bution

Security Scope per Use Case

Use Case Tools Progression Automation Analytics &

Discovery

EUC/VDI & Traditional

E-W

Tag for Simple

IsolationSecurity Group

Security Group and

Service Composer

vRNI & LI

ARM

Isolating between

ApplicationTAG per App PSG vRNI & ARM

Automated Isolation vRA & PSG Edge/Multi-tenancy vRNI, ARM &LI

Advance ServicesPSG & Third Party

Services InsertionAdvance Use Case

vRNI & Third Party

Tools

DMZ – E-W Zero Trust with TAG PSG Sandboxing with vRA

DMZ Ent-to-End E-W + Edge FWIDF/VxLAN/Service

Insertion

vRNI, ARM, End Point

Monitoring




bution

NSX Security Certifications and Compliance

Distributed

Firewall

Edge

Firewall

VPN

http://pubs.vmware.com/Release_Notes/en/nsx/6.3.0/releasenotes_nsx_vsphere_630.html

https://solutionexchange.vmware.com/store/products/vmware-pci-compliance-and-cyber-risk-solutions

http://ir.vmware.com/overview/press-releases/press-release-details/2016/Newly-Released-STIG-Validates-

VMware-NSX-Meets-the-Security-Hardening-Guidance-Required-for-Installment-on-Department-of-Defense-

DoD-Networks/default.aspx

https://www.vmware.com/content/dam/digitalmarketing/vmware/e

n/pdf/vmware-product-applicability-guide-hipaa-hitech.pdf

https://www.vmware.com/content/dam/digitalmarketing/vmware/e

n/pdf/vmware-product-applicability-guide-for-fedramp-v1-0.pdf




bution

http://pubs.vmware.com/Release_Notes/en/nsx/6.3.0/releasenotes_nsx_vsphere_630.html

https://solutionexchange.vmware.com/store/products/vmware-pci-compliance-and-cyber-risk-solutions#.VRLGzZPF9Fg

http://ir.vmware.com/overview/press-releases/press-release-details/2016/Newly-Released-STIG-Validates-VMware-NSX-Meets-the-Security-Hardening-Guidance-Required-for-Installment-on-Department-of-Defense-DoD-Networks/default.aspx

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/vmware-product-applicability-guide-hipaa-hitech.pdf

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/vmware-product-applicability-guide-for-fedramp-v1-0.pdf




4 Summary and Q&A

Agenda




bution

Security

Inherently secure infrastructure

Automation IT at the speed of business

Application continuityData center anywhere

NSX Customer Use Cases

Micro-segmentation

DMZ anywhere

Secure end user

IT automating IT

Multi-tenant infrastructure

Developer cloud

Disaster recovery

Cross cloud

Multi data center pooling




bution

VMware Cloud on AWS

• Pivotal Cloud Foundry is and opinionated PaaS(Platform As a Service)

• Enables










bution

PCF with NSX

• Pivotal Cloud Foundry is and opinionated PaaS(Platform As a Service)

• Enables










bution

PCF NSX Design Baseline Topology

• Centralized Edge provides

– Logical Routing and Switching

– LB, NAT and FW Services

• Centralized services

• VxLAN logical switches provide connectivity to any rack

– No need for changing IP and LB services

• Used for per instance or multi-tenancy or small scale




bution

PCF NSX Design Enterprise Topology

• Match to three availability zones

• DLR optimized traffic pattern

• Single arm LB

• Scale of BW with ECMP

• Combine centralized Edge with this to achive

– In line services such NAT, L

– Edge FW provides further isolation




bution

VxRack SDDC with NSX




bution

EHC with NSX




bution

vRealize Network InsightTransformative Operations for NSX based Software-Defined Data Center

Optimize Network

Performance with 3600 Visibility

& Analytics

Offers Best Practices, Health

and Availability of NSX

Deployment

Plan Micro-segmentation

Deployment and Audit Security

Compliance

Across Virtual, Physical and Cloud




bution

Reference Designs



bution

Driving value with our NSX partner ecosystem

Compute

Infrastructure

Network

Infrastructure

Networking &

Security

Services

Orchestration &

Management

PlatformsOperations &

Visibility

vRealize Automation

vCloud Director

vRealize OrchestratorVIO

vSANReady Node




bution

NSX

Reference

Designs

NSX

Platform

Hardening

NSX

Getting

Started

Guides

SDDC

Validated

Solutions

NSX

Partner

White

papers

Reference Designs & Technical Papers on VMware Communities:

https://communities.vmware.com/docs

Reference Designs and Technical Papers on the NSX Portal:

http://www.vmware.com/products/nsx/resources.html

NSX and

Fabric

Vendors

VMware NSX Collateral Landscape



bution

https://communities.vmware.com/docs

http://www.vmware.com/products/nsx/resources.html

VMware NSX Network Virtualization Design Guides:

https://communities.vmware.com/docs/DOC-27683

NSX Reference Design Guides – The Architecture

ESXi

Compute

Clusters

Compute ClustersInfrastructure/Edge Clusters (Edge, Storage,

vCenter and Cloud Management System)

Edge Clusters

WAN

Internet

Mgmt and

Cloud Mgmt Cluster

Storage Cluster




bution

https://communities.vmware.com/docs/DOC-27683

Join VMUG for exclusive access to NSX

vmug.com/VMUG-Join/VMUG-Advantage

Connect with your peers

communities.vmware.com

Find NSX Resources

vmware.com/products/nsx

Network Virtualization Blog

blogs.vmware.com/networkvirtualization

Where to Get Started

Dozens of Unique NSX Sessions

Spotlights, breakouts, quick talks & group discussions

Visit the VMware Booth

Product overview, use-case demos

Visit Technical Partner Booths

Integration demos – Infrastructure, security, operations,

visibility, and more

Meet the Experts

Join our Experts in an intimate roundtable discussion

Free Hands-on Labs

Test drive NSX yourself with expert-led or self-paces

hands-on labs

labs.hol.vmware.com

Training and Certification

Several paths to professional certifications. Learn

more at the Education & Certification Lounge.

vmware.com/go/nsxtraining

Engage and Learn Experience

Try Take




bution

https://www.vmug.com/VMUG-Join/VMUG-Advantage

https://communities.vmware.com/community/vmtn/nsx

http://vmware.com/products/nsx

http://blogs.vmware.com/networkvirtualization

http://labs.hol.vmware.com/

http://www.vmware.com/go/nsxtraining



bution

NET1536BU Reference Design for SDDC with NSX and or ... · •This presentation may contain product...

Documents

Transcript of NET1536BU Reference Design for SDDC with NSX and or ... · •This presentation may contain product...