Improve App Performance with Micro-Segmentation for ... · The Software-Defined Data Center....

#vmworld

Improve App Performance with Micro-Segmentation

and Distributed RoutingBob Goldsand, VMware, Inc.

Todd Muirhead, VMware, Inc.

VAP1620BU

#VAP1620BU

VMworld 2018 Content: Not for publication or distribution

Disclaimer

2©2018 VMware, Inc.

This presentation may contain product features orfunctionality 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 features/functionality/technology discussed or presented, have not been determined.


Agenda


Accelerating Application Performance –Public, Private, and Hybrid Clouds

VMware NSX Network Kernel Service

NSX Distributed Routing and Distributed Firewall

vSphere 6.7 Persistent Memory Option

Persistent Memory Option – Database

NSX Plus Persistent Memory Performance results

Conclusion



Accelerating Application PerformancePublic, Private, and Hybrid Clouds


The Software-Defined Data Center

Transform storage by aligningit with app demands

Management tools give way to automation

Expand virtual computeto all applications

Virtualize the network for speed and efficiency

VMware vSphere®

VMware NSX™

VMware Virtual SAN™

Persistent Memory Option

VMware vRealize™

Compute

Network

Storage

Management

Software-Defined Data Center VMworld 2018 Content: Not for publication or distribution


Software Defined Architectures (SDA)Dynamic, Mobile, Performant, Multi-Cloud

Cloud Is Not A Destination Approach to IT = Cloud Computing So must change the way we architect apps

Any apps: traditional or cloud native Else why virtualize or move to cloud

SDDC & Cloud = SDA Rethink Current Architectures What Changes In SDDC vs. Native Collaboration Is Key; Get Out Of Silo’s Accelerate Application Performance

Hyper-ConvergedInfrastructure

NetworkVirtualization

InfrastructureAs-a-Service

Public Clouds

ContainerizedApps

DatacenterTrends



Software-Defined Architecture: Design GoalsPerformance Is Not Optional

Locality Of Reference Location and frequency of access

All contribute to latency – ultimately performance

Extend Locality Of Reference to SDDC All Resources - Compute, Network, Storage,

Management

Contain Resources In-Memory Ultimate locality of reference

SDA Allows Customers To run faster than physical Eliminate “Virtualization Penalty” Examples: NSX and Persistent Memory Option

vSphere 6.7

7

Unified Software-Defined Platform

SDA: Faster Than Physical



SDA: Tackling Common Mission/Business Critical Application Bottlene Most Prevalent Bottlenecks

Obvious Remediations: CPU – Hot Add vCPUs Memory – Hot Add Memory

Not So Obvious Remediations Network – Reduce or eliminate latency;

increase bandwidth vSphere NSX – routing and micro-segmentation In-memory computing

Storage – Reduce or eliminate latency vSphere 6.7 Persistent Memory Option

Application Itself All of the above plus workload management Co-location – Locality of reference Not possible in physical world

Converged IT Services

• Compute Virtualization

• Storage Virtualization

• Network Virtualization

• Intelligent Operations

Software-Defined Data Center



VMware NSXNetwork Kernel Services


Cloud Consumption • Self Service Portal• vCloud Automation Center, OpenStack,

Custom

Data Plane

NSX Edge

ESXi Hypervisor Kernel Modules

Distributed Services

• High – Performance Data Plane• Scale-out Distributed Forwarding Model

Management Plane

NSX Manager• Single configuration portal• REST API entry-point

Control Plane

NSX Controller• Manages Logical networks• Control-Plane Protocol• Separation of Control and Data Plane

FirewallDistributed Logical Router

LogicalSwitch

Logi

cal N

etw

ork

Phys

ical

Net

wor

k

…

…

NSX-V Overview, Architecture, and ComponentsKEY TAKE-AWAYS: Hardware Independence and Network Kernel Services



Host 2Host 1

vSphere Standard & Distributed Virtual SwitchTraffic Flow Without NSX

Standard Switch (VSS) & Virtual Distributed Switch (DVS) Basic network connectivity to ESXi hosts and

virtual machines. Centralized management and monitoring of

the network configuration across ESXi Hosts

For VSS and DVS VM’s on different hosts – traffic routed

through physical network VM’s on same host – traffic still routed

through physical network

Not Optimal For Latency Sensitive Workloads Doesn’t meet design goals of locality

Unnecessary Flow from Virtual/Physical Layers Network Hair-Pinning

APP-01 DB-01 APP-02 DB-02

Virtual Distributed Switch

FABRIC FABRIC

Virtual Switch VM Communications

Physical NetworkResources



NSX Eliminates Network Hair-PinningProvides Locality of Reference – Exploits In-Memory Computing

NSX Communications Never Leaves The Host Reduce Latency and Network Hops With NSXVMworld 2018 Content: Not for publication or distribution

Accelerating Application and Day 2 Operations

VIRTUAL LAYER

Without NSX, network services communicate between application tiers and VMs must traverse the physical network layer

Network hairpinning slows performanceWith NSX, co-locate VMs and eliminate network hairpinning to enable efficient app communication at memory speed inside the virtualized network

NSX eliminating hairpinning

vSphere HostvSphere Host

VIRTUAL LAYER

PHYSICAL NETWORK LAYER

vSphere Host

PHYSICAL NETWORK LAYER

NSX

vSphere Host vSphere HostvSphere Host



NSX Network Services ResultsDistributed Routing and Distributed Firewall



Testing Methodology – Performance GoalAchieving Locality Of Reference

• Single VM Performance– No external operations; No latency– Intra VM loads on Flash Array

• Remote Data Loads – Network Latency– Load from client VM to database VM– Same/Different ESXi Hosts

• Using Distributed Virtual Switch• Using NSX

• Remote Data Loads – Storage Latency– Loads from client VM to database VM– Same/Different ESXi Hosts

• Using Persistent Memory Option (PMEM)

• Remote Data Loads – NSX Plus PMEM– Repeat tests

• Setting The Bar– How Close To Single VM Performance– Exploiting NSX and PMEM– Contain operations to in-memory

vSphere

Host

vSphere NSX

Host

vSphere NSX

Host

vSphere NSX

Host

vSphere NSX

Host

Single VM Performance

VM

VMVM VM

VMVMVM

DVD Store Testing

VMware NSX

Persistent Memory Option



Oracle 12c BI & NSX: Measuring Elimination Of Hair-PinningTest Environment – Simulating Remote Data Loads (Enterprise Data Warehouse Use Case)

Dell Blade

vSpherevDS

vSphereNSX

vSpherevDS

vSpherevDS

vSphereNSX

vSphereNSX

VM VMOracle 12cDatabase

OracleClient

VM VMOracle 12cDatabase

OracleClient

VMOracle 12cDatabase

VMOracleClient

VM VM

Oracle 12cDatabase

OracleClient

PHYSICAL

VIRTUAL

– Oracle 12c Database (SLES 12) - Record Results Using Same/Separate vSphere Host– Oracle 12c Client (SQL Loader WIN2K) - NetApp All Flash Array 8060



NSX Dramatically Increases App Performance –Data Load Times

17

Based on testing done using an Oracle Database and Client and comparing vSphere with NSX to vSphere with vDS (Distributed vSwitches). Horizontal axis tracks how many rows were loaded and size of file.

1.3 1.41.6 1.5

1.7

1.4

1.9

2.7

1.6

2.0

0.0

1.0

2.0

3.0

“X”

MU

LTIP

LES

OF

IMP

RO

VE

ME

NT

FILE SIZE

Different Hosts Same Host

*Depending on how many rows being loaded and file size

1.3-2.7x

increased app performance*

1010

1010

1011

010

100

110

1010

1010

00

1010

1011

011

010

010

100

1010

00

1010

10

110

1111

00

1010

1011

110

011

1111

00

1010

110

110

1010

1011

010

1010

1010

1010

1011

1010

011

010

1010

011

100

1010

100

1010

1010

1010

1010

1010

1010

1010

1010

101

011

010

1011

010

1010

1010

1111

010

1010

10

1010

1010

1011

00

1010

1010

110

1010

00

110

1011

1010

010

1010

100

00

1011

010

1010

010

1010

0

Up to 2.7ximprovement on the

same host

Up to 1.7ximprovement across

different hosts

2x improvement on full data load



NSX Dramatically Increases App Performance –Multi-tier apps

18

4-8x improvement on the same host

2-5x improvement across different

hosts

More tierslarger improvement

1.94 2.06

2.793.03

4.81

4.14

4.95

6.336.71

7.64

0

1

2

3

4

5

6

7

8

9

2 3 4 5 6

“X”

MU

LTIP

LES

OF

IMP

RO

VE

ME

NT

APPLICATION TIERS

Different Hosts Same Host

1010

1010

1011

010

100

110

1010

1010

00

1010

1011

011

010

010

100

1010

00

1010

10

110

1111

00

1010

1011

110

011

1111

00

1010

110

110

1010

1011

010

1010

1010

1010

1011

1010

011

010

1010

011

100

1010

100

1010

1010

1010

1010

1010

1010

1010

1010

101

011

010

1011

010

1010

1010

1111

010

1010

10

1010

1010

1011

00

1010

1010

110

1010

00

110

1011

1010

010

1010

100

00

1011

010

1010

010

1010

0

Study was done using Apache Bench, a HTTP load testing tool. Comparison is between NSX with VXLAN and Non-NSX with VLAN. Results confirmed that with the increased number of application tiers, the better NSX performs relative to the alternative..

*Performance improvement depends on load size, host location and number of tiers. Trends indicate that the more tiers or the larger the load, greater the improvement

1.9-7.6x

increased app performance*



NSX Performance Acceleration: Moving the Bottleneck

Degree Of Performance Gains• Dependent On Logging and Data

Ingestion Methods

Relaxed Or Minimal Logging• Log minimal amount of information

for certain operations

Bulk Loading• Bypasses database cache; loaded directly into

tables

Eventual Consistency• Data changes are not instantaneous; inconsistent

reads/writes

NSX Performance Acceleration• Leveraged at enterprise of internet scale• Private, Hybrid, or Public Cloud deployment

MySQL-MyISAM, CouchDB, MongoDB, Amazon SimpleDB,

Oracle

Oracle, SAP ASE, SAP HANA, DB2

SQL Server, MySQL –innodb,

PostgresSQL

>60%

40 to 60%

15 to 25%

Examples Of The Database “Network Funnel”



MySQL Has Different Storage Engines available• Innodb

– Supports full database transactions– All database changes are logged – cannot be disabled

• MyISAM – Lightweight providing fast performance– Logging can be disabled during loading

Loaded both with the same set of test data• Reviews data from DVDStore 3

MySQL Data Import with Different Storage Engines



MySQL Data Import Performance Influenced by Bottleneck

Data Import Time MyISAM InnodbvDS NSX %NSX Better vDS NSX %NSX Better

Different Hosts 136.0535 100.5388 35.32% 412.4498 373.71025 10.37%Same Host 131.715 77.776 69.35% 407.6 374.38275 8.87%

0

50

100

150

200

250

300

350

400

450

vDS MyISAM NSX MyISAM vDS Innodb NSX Innodb

Tim

e to

Lo

ad (

s)

MySQL Load Time with vDS and NSX (smaller is better)

Same Host Different Hosts



Performance Gains Associated With Network Architecture3 Tier Architectures or Leaf Spine Architecture

Advantages & Disadvantages For Both Architectures

Traditional 3-Tier Architectures Adv: availability, simplicity, scalability Dis: increased latency; bandwidth

Leaf-Spine Adv: consistent latencies, bandwidth Dis: cabling/network gear, greater number of

ports required

Key Take-Aways Important To Know Gains will vary; greater on 3-tier About 80% to 85% of networks are 3-tier

architectures Like compute virtualization; NSX also not

dependent on underlying physical infrastructure

Tiered Architecture

Leaf-Spine Architecture



Increased Network Complexity Introduces Additional Network Latencies

Compare Physical Firewall vs NSX Firewalling• Talked with customers, network admins

internal/external• Data center best practices, smart device placement• Too many permutations to be easily modeled in lab

performance testing• Add load balancers, other network services, and

complexity grows

Key Take-Aways/Important To Know• Understand difference between physical and kernel

based network services• Also Firewall walls are attached to VM not device• Walk away with the concepts extremely important• vRealize Network Insight• Customer References

Physical Network Services Model

Kernel Based Network Services Model

vSphere Host

Host 1

vSphere Host

Host 2

vSphere Host

Host 3

Web1 App1 DB1 DB2

NSX Distributed Logical Router



vSphere 6.7 Persistent Memory OptionAddressing Storage Bottleneck



vSphere 6.7 Persistent Memory OptionDesign Goals: Locality and Low Latency

• Persistent memory • Has the characteristics of memory

– DRAM-like latency and bandwidth– CPU can use regular load/store byte-addressable

instructions • Fully ACID Compliant - maintains data during

power cycles

Persistent Memory Support on NVDIMM-N Contains both DRAM and NAND Flash

Modules Battery backed Available from DELL/EMC

Persistent Memory



PMEM Access ModelsExposing PMEM To Virtual Machines

External Block Storage Model (vPMEMDISK) PMEM backed Datastore No modifications to application or database Existing applications or migrations to PMEM

Byte-Addressable Model (vPMEM) VM direct access to NVDIMMs OS requirements:

Windows Server 2016, RHEL 7.5, CentOS 7.4 Most performant model

Our SQL Server & Oracle Testing vPMEM Byte Addressable Model SQL Server 2016 PMEM aware

Oracle Not - Evident in results

vDISK vPMEM-DISK

DataStore (VMDK) PMEM DataStore(PMEMDSK)

vSCSI

NVDIMM

Memory Bus

PMEM DataStore (NVDIMM)

NVDIMM

Memory Bus

vPMEM

External Device Block Storage Model

Byte-Addressable PMEM Model



vSphere 6.7Persistent Memory Option – Database



Persistent Memory Option Results: SQL Server Database

Backup and Recovery Tests From PMEM to PMEM 60GB SQL Server Database SQL Server 2017; Window Server 2016

SQL Server Results Backup 7 Times Faster Recovery 7 Times Faster

VMware Fault Tolerance SQL Server FT – 3,867 orders per minute SQL Server FT PMEM – 4,584 orders per

minute Approximately 15% gain

Day 2 Operations: Backup & Recovery

Data FilesLog Files

OS Files



Persistent Memory Results Oracle Database Day 2 Operations: Data Load Speeds

Local Loads: Load DVDStore data files from NetApp all

flash array xfs file system into Oracle 45% faster

Load DVDStore data files from PMEM xfsfile system into Oracle 55% faster

Mounting with DAX option about 5% gain for both load tests

Tests done with Oracle 12cR2 RedHat Linux 7.5 OS Includes Support for NVMe devices

Data FilesLog Files

OS Files



Available Physical RAMAvailable Physical RAM

Compare and Contrast In-Memory Databases and Traditional w/PMEMMemory Footprints

In-memory Database Operates entirely in-memory Optimized for in-memory

computing

Traditional Database Data cache fraction of size of

database Flexible use of physical RAM

Key Takeaways In-memory still faster than PMEM Traditional still architected for disk

layer Minimize storage interactions with

NVDIMMs Consider price/performance and

workload Always comes down to

requirements, requirements, requirements…

Data

Data

Other Objects

Logs, Temporary Tables, Indices,

Materialized Views, etc.

Other Objects

In-Memory Database Traditional Database

200GB

100GB

256GB

10GB

256GB

Sizing 100GB Database

PMEM

Data or

Partitions

PMEM

Logs

Flash Array

or

Could Be PMEM

Persistence Layer

In-Memory

Footprint

7GB



NSX Plus Persistent Memory Option



NSX Plus Persistent Memory Option Performance Results

Loading of Data Into Oracle DB

Single VM – Shows Design Goal

Different VMs is realistic• What can be done to still get

design goal performance?• Some performance advantage

is achieved with PMEM • NSX provides performance

advantages• Co-Location of VMs through

vMotion further accelerates performance

• Combination of NSX and co-location brings us within ~5% of performance design goal

Combination of NSX and PMEM create best performance

270

785

531

390

282

203

642

446

309

217

0

100

200

300

400

500

600

700

800

900

Local VM - PerformanceDesign Goal

Different Hosts VDS Different Hosts NSX Same Host VDS Same Host NSX

Load

Tim

e (s

)

Performance of Oracle Database Loading with PMEM and NSX

Flash PMEM



vRealize Network Insight


SDDC: Intelligent Day 2 Operations with vRealize Network Insight VMware Distributed Resource Scheduler

• Balances virtual machine workload across the vSphere Host Cluster

• Initial placement of VM based on load balancing and host constraints

• DRS is not sufficient to eliminate hair-pinning– Due to temporal and transient nature of workload optimization– Which VMs are communicating with each other?– When are VMs communicating which each other?– Predictive DRS vSphere 6.5 and DRS Rules

VMware Network Insight (Exploring)• Model Application and Database Behavior

– Understand when and which VMs are communicating in landscape– Migrate VMs to optimize workload and eliminate hair-pinning

• Leverage Time Machine Feature• Predict degree of application acceleration with NSX

vRealize Operations

Compute StorageHybridCloud

Network & Security

vRealizeNetworkInsight

vRealize Log Insight

Application

vRealize Business for Cloud

Intelligent Operations for The SDDC


Use Case: Financial EOQ/EOY Close

High traffic generating applications are run over co-located VMs and at memory speed, creating an optimal communication path

Solution:

Reconcile financial transactions at the end of quarter/end of year

Scenario:

• Increasing transactions to be completed with tight timelines

• More users require access to mission critical applications• Large datasets being uploaded and processed

Challenges:

• Streamline business processes, with optimized efficient access to actionable data

• Reconcile financial records in a fraction of the time previously required

Benefits:

AnalyticsCRM

Custom Apps



Need To Leverage Software-Defined Data Center – Cloud Computing Rethink what is possible with Software-Defined Architectures

Top Bottlenecks – CPU, Memory, Network, Storage, Application All can be remediated with SDDC & SDA techniques

Design Goals Of Locality and In-Memory Achievable High bar of single VM performance compared to application stack Near-Zero latency with NSX and Persistent Memory

Customer References & Collaboration Anyone interested in working with VMware on customer references – let us know Customer collaboration – new ways of creating SDA

ConclusionsObservations


PLEASE FILL OUTYOUR SURVEY.Take a survey and enter a drawingfor a VMware company store gift card.

#vmworld #VAP1620BU


THANK YOU!

#vmworld #VAP1620BU


Improve App Performance with Micro-Segmentation for ... · The Software-Defined Data Center....

Documents

Transcript of Improve App Performance with Micro-Segmentation for ... · The Software-Defined Data Center....