amon RyanPrasenjit SarkarSenior Solutions ArchitectStaff Solutions ArchitectIaaS with SDNThe Good, Bad and Confusing

#Purpose and AudiencePurpose Customer interest is increasing well beyond just what our standalone products offerIn fact customer dont care about the products, they care about the solutionIaaS with SDN as a solution extremely popularTherefore, focus on joint solution: vRA, vRO, NSX-v and 3rd party options

Intended AudienceAnyone dealing with this joint solution

#Customers only care about what they can *do* with the software, the products themselves and the borders between them are irrelevant.I want to do X, can you allow me to do that? Great, then do it2

Learning Outcomes

#The outcome here is for you to understand more about how the Lego blocks become the Lego house, how the products build a solution.Where the best/most useful pieces are and how not to step on that really sharp one barefoot.3

Life of a Network Engineer!!! ;-)Not everything in life is fair

#

Distributed Switch

A network path defines where exactly a VM would connect.You cannot use routed or NATed Profiles without vCNS or NSX. Only External Profiles would be used

Without NSX, DvPortgroup becomes Network pathMMBP1MMBP2

What is Network Path for vRealize Automation? Without NSX-V

#

To Core SwitchesDistributed-Router-01Perimeter-Gateway-01The External Network Profile has to be associated on the Logical Switch connected on the Uplink of the DLRAssociate External Network profile here

Distributed Router Model

#

To Core SwitchesDistributed-Router-01Perimeter-Gateway-01The External Network Profile has to be associated on the Logical Switch connected on the Uplink of the DLRAssociate External Network profile here

Advantage of this model:You can automatically redistribute Connected Routes on DLR into OSPFYou can make use of ECMPDistributed Router Model Difference in behavior for Routed Profile

#

To Core SwitchesPerimeter-Gateway-01The External Network Profile has to be associated on the Logical Switch connected on the Internal Interface of the Perimeter EdgeAssociate External Network profile here

Perimeter Edge Model

#

To Core SwitchesPerimeter-Gateway-01The External Network Profile has to be associated on the Logical Switch connected on the Uplink of the DLRAssociate External Network profile here

One Drawback in this Model:You cannot automatically advertise networks below the application edge to devices located upwards(Perimeter GW, Core Switches)Cannot make use of ECMP Perimeter Edge Model Difference in behavior for Routed Profile

#

Workload Distributed Switch

MMBP1

Transit Logical SwitchCore DvPortgroup

Distributed Router 01Perimeter GW 01Mgmt Distributed Switch

What is Network Path for vRealize Automation? With NSX-V

#

Transit-Logical-switchTransit-Logical-switch-01Network Path:Ext-DLR->Distributed GatewayNetwork Path:Ext-ESG->Perimeter-Gateway-01Test-Routed-ProfileTest-NAT-ProfileTo Core SwitchesDistributed-Router-01Perimeter-Gateway-01Perimeter-Gateway-02Perimeter-Gateway-03The Complete Story

#NSX with vRA On Demand Deployment Model

Provider LogicalRouter (HA)

ExternalNetworks2 Tiers of RoutingDistributed Logical Router or NSX Edge for Application RouterNSX Edge for Provider RouterDynamic Routing externallyDynamic Routing (DLR), Static Routing or NAT internally (Edge)Dynamic Routing(OSPF, BGP)Transit Uplink 192.168.10.0/24 (External Network Profile)Static Route addedautomaticallyOn Demand Model is typically used for more dynamic Test/Dev style workloads, particularly when there is a requirement for overlapping IP addresses

Dynamic Routing(OSPF, BGP)

Web Logical Switch (Routed)

DB Logical Switch(Routed)

MMS 1Routed

App LS (Routed)

172.16.10.0/29172.16.10.8/29172.16.10.16/29

Web Logical Switch (Routed)

App LS (Routed)

DB LS (Routed)

MMS 2Routed

172.16.20.0/29172.16.20.8/29172.16.20.16/29

Web Logical Switch (NAT)

App LS (Private)

DB LS (Private)

MMS 3NAT & Private

172.16.100.0/24172.16.101.0/24172.16.102.0/24

Web Logical Switch (NAT)

App LS (Private)

DB LS (Private)

MMS 4NAT & Private

172.16.100.0/24172.16.101.0/24172.16.102.0/24

DLR

#[Speaker Notes]Example slides that shows many network topologies in 1 diagram, just go through them again to be sure they know the difference.

First one is leveraging a DLR for routing, and dynamic routing (usually the recommended approach)Second one uses a ESG for routing, but doesnt leverage OSPF/BGP (why ? I dont know), and manages static routes automatically to the uplink ESG routerThen we have 2 different NAT/Private use case which look a like, deploying a ESG for the NAT / routing features within the MMB with multiple networks

[Learning Points]I would always recommend leveraging dynamic routing whenever possible (OSPF/BGP) leveraging a LDR and external networks (usually the most easy use case for customer to implement, and still leveraging ALL the benefits from NSX.)

[Detailed Notes]

12

NSX with vRA Pre Created Deployment ModelDynamic Routing(OSPF, BGP)

ExternalNetworks2 Tiers of RoutingDistributed Logical Router for Application RouterNSX Edge for Provider RouterDynamic RoutingUse existing LS as external network profilesOne Arm Load Balancing on demand (vCNS Edge in 6.0, NSX Edge in 6.1)Prod-01Logical Switch Dev-01Logical Switch

LB

LB

LB

Dynamic Routing(OSPF, BGP)

Transit Uplink 192.168.10.0/24 (External Network Profile)Scale Out Provider Logical Router (NSX 6.1)MMS 1 VMsMMS 2 VMsMMS 3 VMsPre-Created model is typically used with Production or more static workloads and the application topology is multi-tier on a single networkProd Web SG AProd App SG AProd DB SG ADev Web SG ADev App SG ADev DB SG ADev Web SG BDev App SG BDev DB SG B

Distributed Logical Router

Prod Web SG BProd App SG BProd DB SG BMMS 4 VMs LB

172.16.50.0/24 (External Network)172.16.60.0/24 (External Network)

Dynamic Routing(OSPF, BGP)with ECMPDynamic Routing(OSPF, BGP)with ECMP

Provider Logical Router (NSX 6.1)

#[Speaker Notes]This is a slide that highlights the Pre-Created deployment model but leveraging a more Flat Network approach (not a big Fan because its going to be very disruptive for customers today, based on security Groups/Micro Segmentation)One of the other common complains about customers/competitors was about the scalability of our North/South Traffic, especially as we are leveraging VMs (NSX Edge Service Gateways) to connect to the external world.

Since NSX 6.1, a new feature appeared, that is ECMP support for the NSX Edges, which allows to scale the bandwidth/performance of the North/South traffic.

[Learning Points]NSX can now scale very well for North South traffic and not only East/West.

[Detailed Notes]

13

NSX Security Groups & Security PoliciesEnd-Users and Cloud Admins are able to select pre-defined security policies already approved by the Security Admin in NSXSecurity policies are applied to one or more security groups where workloads are membersThese security groups are created on-demand by vRA at deployment timeWHAT you want to protectHOW you want to protect itSECURITY GROUPSECURITY POLICY

Members (VM, vNIC) and Context (user identity, security posture)Standard Web Firewall allow inbound HTTP/S, allow outbound ANY IPS prevent DOS attacks, enforce acceptable use

Services (Firewall, antivirus, IPS etc.) and Profiles (labels representing specific policies)

#[Speaker Notes]As we discussed earlier, Define a set of Security Policies for the MMB owners, and they will be able to leverage them in a standardized way.

vRealize Automation will then automatically create a Security Group at provision time with the impacted objects and Attach the security policies to the Security Group.

[Learning Points]Very simple and efficient way to have policies applied for every deployed blueprint from vRealize Automation.

[Detailed Notes]

14

NSX Security TagsNSX Security Tags can be used to define IF/THEN workflows for security services, e.g. IF user selects a Finance application, THEN place the VM in the Finance security groupINFRASTRUCTUREAPPS

Security AdminFinance PolicyIF Tag = Finance THEN add VM to Security Group Finance with Security Policy Finance

Step 1: Security Admin pre-defines a Security Group and a Security Policy with dynamic membership based on a Security Tag Finance AppSet Tag Finance

Cloud Admin

Multi-MachineBlueprintStep 2: Cloud Admin creates a Multi-Machine Blueprint which sets a Security Tag. Cloud Admin needs no knowledge of Security Groups or Security Policies.

#[Speaker Notes]Dynamic membership based on a NSX Security Tag is very powerful feature that accommodates different administrations Silos.Here a Security Admin can make sure that if any vRA Multi Machine Blueprint has a Security Tag assigned to it, it will automatically inherit the security group/security policies dynamically.

[Learning Points]This feature again, shows how efficient it can be to deploy workloads and secure them with minimal effort, and dynamically based on NSX Tags

[Detailed Notes]

15

NSX Security TagsNSX Security Tags can be used to define IF/THEN workflows for security services, e.g. IF user selects a Finance application, THEN place the VM in the Finance security groupINFRASTRUCTUREAPPSRequests Finance App

Service CatalogStep 3: End-User requests Application via the Service Catalog

Cloud Consumer

Step 4: VM is automatically deployed with its Security TagWHAT you want to protect

Step 5: VM is dynamically assigned to the relevant pre-defined Security GroupSG=Finance

#[Speaker Notes]This is the continuation from the previous Slide, I think it highlights very well the process from the Security Admin, to the Cloud Admin (MMB owner) and the deployment process by a Consumer (end user) and what is happening in the backend.

[Learning Points]If your customer has very strict corporate policies, this is a great feature to enforce them at deployment time.

[Detailed Notes]

16

vRA Feature Set Supporting NSXFeaturevRA 7.0FutureDay 1: Automated Routed, NAT, LB and security for single machines blueprintsRRDay 1: Automated Routed, NAT, LB and security for application stack (micro-segmentation)RRVisual topology in blueprint: Drag-and-drop of networks, LB and security objects in Canvas and map relationshipsRRDay 1 and 2: Enhance NSX NAT with features for SNAT, DNAT, port forwarding and PAT monitors in network profile and add Day 2 updatesQRDay 2: Update NSX security groups, tags and policies applied to VMsQRDay 1 and 2: Enhance NSX LB with features for port, algorithm, persistence, IP address pool, health check monitors in blueprint and add Day 2 updatesQRNSX Multi-vCenter Feature Support (IP and MAC set security groups)QRDay 1 and 2: Support for enabling HA on NSX EdgesQRDay 1 and 2: Define NSX firewall rules for the app in blueprint and Day 2 add/change/remove firewall rules on VMsQRDay 2: Change network adapters, IP address, DHCP, DNS, etc. on VMQRRequest time: Change Network, LB and Security settingsQRDirect support for IPAM solutionsQRSupport NSX functionality in vCloud AirQR

#

17

vRealize Automation 7.0Whats changing that helps here?

#

#

18

vRealize Automation 7.0 ChangesEasier setupGraphical canvasRelationship MappingNetworking components as first classManageable ItemsMore support for on-demand networking objectsSingle machines with advanced networkingOrchestratorEvent broker systemRelevant to IaaS with SDN

#

19

vRealize Automation 7.0 Easier Setup NSX Integration for Blueprint Authoring & DeploymentAutomated connectivity to existing or on-demand networksMicro-segmentation for application stackAutomated security policy enforcement thru NSX security policies, groups and tagsOn-demand dedicated NSX load balancer

#

20

vRealize Automation 7.0 Single Machine NetworkingvCAC 5.2 -> Custom propertiesvRA 6.x -> GUI based network options for MMBP onlyvRA 7.0 -> GUI based network options for all (but all are now one no single/MMBP difference)

#Talky part21

vRealize Automation 7.0 OrchestratorThe vRO 7.0 Control CenterEmbedded + ExternalNew modern UI for vRO setup, configuration, workflow monitoring, troubleshooting, and other useful information.Collect metrics for workflow executionAnalyze running workflowsGeneral troubleshootingManage, Import/Export central DBWAY more slick than previous legacy UI

#Talky part22

NSX vRealize Orchestrator PluginAbstracting with vROBenefitsAbility to support multiple product versions (vCNS, NSX) transparently to vRANetwork and security workflows are decoupled from policy engine, enabling more rapid release and update to workflowsAbility to deliver fixes and updates more rapidly Easier to extend/customize workflows by adding your own logic or leveraging other systemsProvide Self Service access to NSX vRO workflows through Advanced Service DesignerCan be used without vRAWarning: Supported for the vRA workflows ONLY

#[Speaker Notes]This is the VMware official vRO Plugin for vCNS/NSXThis allows custom integration points to be done in vRO directly without affecting vRA, as you can edit/fix workflows. (extend workflows)

The main problem with this plugin is that it is hard to extend the plugin as its a fully fledge java plugin. [Learning Points]This is a requirement for vRA/NSX to work, the NSX plugin is pre-installed in the embedded vRA appliance on the vRO server. If you use an external vRO Server you will be in charge of installing the plugin on it.

[Detailed Notes]Plugin is available for free, but make sure to check the compatibility Matrix between vRA/vRO/NSX, as you need very specific versions to have a supported configuration.

Warning: Manually run vCO workflow Enable Security policy support for overlapping networks to enable support for overlapping networks

23

NSX vCenter Dynamic Types PluginAbstracting with vROBenefitsHas been built by Christophe Decanini and offers additional workflows the official plugin doesnt cover.Its FREE !Designed to be used in XaaS contextSource code available at https://flowgrab.com or in the VMware communitieshttps://communities.vmware.com/docs/DOC-29032Can be extended easily, through the NSX REST API as its built leveraging the dynamic types plugin generator Great learning opportunity (vRO and NSX) !Warning: Not Supported by VMware

#[Speaker Notes]This plugin has been built by Christophe Decanini, and leverages his dynamic types plugin generator.

This allows you to create a vRO plugin with minimum, or no code, and is a great opportunity for any partner wanting to bring additional value with vRA/vRO/NSX to a customer enterprise infrastructure in the context of XaaS. (maybe expose the video of XaaS from the Demo kits with the Credit Cards scanner/reports to the students to show a specific customer use case)

As explained in the slide bullet points, the code is available and free for all, its very easy to extend to your own use case / feature coverage if required.

[Learning Points]You can drastically increase solution value for your customers leveraging this plugin, and also improve your vRO/NSX REST API skills in a short time.This scales very well if you have multiple NSX customers, as you can reuse the plugin for other engagements.

[Detailed Notes]Full details on the dynamic types plugin generator available on http://vcoteam.infoNSX plugin dynamic types tutorial: http://www.vcoteam.info/articles/learn-vco/298-create-a-plug-in-for-a-rest-web-service-in-minutes.html

24

NSX-vRO Plugin 1.1.0 or 2.0.0FeatureContinued support for interoperability between vRA, vRO and NSXExpanded support and bug fixes for use of the plugin with vRA ASD / XaaSEnhance NSX NAT with features for SNAT, DNAT, port forwarding and PAT monitors in network profile and add Day 2 updatesSupport full management (CRUD) of NSX security groups, tags and policies applied to VMsSupport for Enhanced NSX LB management with features such as LB port, algorithm, persistence, IP address pool, health check monitorsSupport for advanced NSX Edge features (HA, Logging, etc.)NSX firewall rule management (CRUD operations)Full documentation of the NSX-vRO plugin for general consumptionBetter scale and performance requirementsSupport for NSX Transformers (Crosshairs target)

#

25

vCAC 6.0.x and NSX IntegrationNSX vSphere (NSX-v)vCloud Automation CentervCenter ServervSphere Host (ESXi)vCNS ModelNSX API (REST)VIM API (SOAP)AMQP

#[Speaker Notes]This slide and the following is to show a change in how vCAC (vCloud Automation Center) in 6.0.x and vRA (vRealize Automation in 6.1) handles NSX Networking

[Learning Points]Previously in the 6.0.x releases vCAC was connecting directly to NSX Manager (leveraging the REST API)

[Detailed Notes]26

vRealize Automation and NSX IntegrationNSX vSphere (NSX-v)vRealize AutomationvCenter ServervSphere Host (ESXi)vCNS ModelNSX API (REST)VIM API (SOAP)AMQPvRealize OrchestratorvRO API (REST)NSX Plugin

#[Speaker Notes]Since vRealize Automation 6.1, VMware has moved the business logic for handling NSX into vRealize Orchestrator for multiple reasons

Avoid a hard dependency on vRA releases / NSXBring a more decoupled approach, where additional services can be provided through custom integration with vCO and the NSX plugin directly.Have the vRO Plugin updated more frequently to address bugs/add new features coverage (this topic will also be discussed in the vRO/plugins section)

[Learning Points]With this change, it is required to configure the vRealize Orchestrator endpoint in vRealize Automation to have the NSX Data Collection working correctly.

[Detailed Notes]This should be detailed in the [vRealize Automation Slide Deck]27

vRealize Automation 7.0 Event BrokerNew event broker systemAllows blocking task style implementationsDozens of notification possibilitiesAbility to wire any of these to vRealize OrchestratorTherefore ability to use vRO to influence NSX at any of these pointsStandard machine stub callouts will still exist

#Talky part28

DEMO: Cross site vMotion with vSphere, vRA and NSXOooh!

#

#29

Review of Learner ObjectivesYou should be able to meet the following objectives:Understand the benefits of the integration between NSX and vRealize AutomationBe able to articulate to customers the value of the joint solutionCreate NSX network and security components to be consumed by vRealize AutomationConfigure Network ProfilesConfigure a multi-machine blueprint with networking and securityDeploy a multi-tier application from the vRealize Automation catalog with networking and security components.

#

30

Key TakeawaysThe NSX and vRealize Automation integration allows for the automation of multi-tier applications with networking and security componentsThere are many different deployment options with the joint NSX and vRealize Automation solution. Understand your customer requirements and prescribe the appropriate deployment options.

#

31

Q&A

#

#32