The document outlines the architecture and benefits of a Software-Defined Data Center (SDDC), emphasizing its approach to IT infrastructure through virtualization, automation, and resource pooling. Key advantages include significant cost reductions, enhanced organizational efficiency, and improved agility and operational efficiency. It also discusses the importance of design patterns, technical requirements, and the phased implementation necessary for successful SDDC deployment.

1. Architecting the Software-Defined Data Center
Aidan Dalgleish, VMware
David Hill, VMware
Kamau Wanguhu, VMware
VSVC7371
#VSVC7371

2. 22
Introduction
 David Hill
• Senior Solutions Architect, Global Technology Solutions
• VCAP
• Blog: Virtual-Blog.com
• Twitter @davehill99
 Aidan Dalgleish
• Staff Solutions Architect – Global CoE
• VCDX #010
• Blog: vCloudscape.com
• Twitter: @aidersd
 Kamau Wanguhu
• Staff Solutions Architect – Global CoE
• VCDX #003
• Blog: borgcube.com
• Twitter: @borgcube_

3. 33
Agenda
Method Q/AOverview Design Patterns

4. 44
Definition
Software-defined data center is an
architectural approach to IT infrastructure
that extends virtualization concepts such as
abstraction, pooling and automation to all of
the data center’s resources to achieve IT as
a service.

5. 55
Definition
Software-defined data center is an
architectural approach to IT infrastructure
that extends virtualization concepts such as
abstraction, pooling and automation to all of
the data center’s resources to achieve IT as
a service.

6. 66
Three Core Tiers

7. 77
Top 5 Value Drivers – Why Is SDDC Attractive Now?
 Dramatic Sustainable Cost Reduction
• Realize 40-75% cost reduction at full SDDC
(~75% CapEx / ~56% OpEx reductions.)
 Organizational Efficiencies
• “New” Skillsets and headcount optimizations are required and allow much
more to be done by much fewer, more cross-functional staff
 Datacenter Agility and Efficiency
• High levels of automation and self-service drive a much more agile datacenter
environment and greatly reduce time to market of services and applications
 Operational Efficiencies
• Simplified, consolidated, and heterogeneous management and orchestration
toolsets allow for a fully-realized service-oriented organization

8. 88
SDDC Quandary
 Must introduce complexity to provide simplicity
 A SDDC is an architecture for your infrastructure. This adds a
layer of complexity in the form of technology and automation that
simplifies the provisioning process for end-users
 By incurring upfront costs, you reduce long term operating costs
Apps
Compute
Network
Storage

9. 99
Software-Defined Data Center
Standardized ResourcesAvailabilityManagement
Pooled ResourcesAutomation
Security Policy Self-Service

10. 1010
Software-Defined Data Center
Standardized ResourcesAvailabilityManagement
Pooled ResourcesAutomation
Security Policy Self-Service
vSphere (vCenter/ESX)Site Recovery
Manager
vCenter Operations
Management Suite
vCenter Orchestrator AMQP (RabbitMQ) vCloud Director and
vCloud API
vCloud
Connector
Nicira
vCloud Automation Center
vFabric Application DirectorvCloud Networking and Security

11. 1111
Software-Defined Data Center
Standardized ResourcesAvailabilityManagement
Pooled ResourcesAutomation
Security Policy Self-Service
Site Recovery
Manager
vCenter Operations
Management Suite
vCenter Orchestrator AMQP (RabbitMQ) vCloud Director and
vCloud API
vCloud
Connector
NSX
vCloud Automation Center
vFabric Application DirectorvCloud Networking and Security
• Virtualized Compute
• VDS
• Storage Profiles
• VMware HA
• VADP
(backup/restore)
• vCenter Operations
• Configuration Manager
• Infrastructure Navigator
• Hyperic
• Chargeback Manager
• Edge, Load Balancing, VPN
• App Firewall
• VXLAN
• Service Insertion Framework
• Virtual Datacenters
• vApp and Metadata
• Catalog
• IaaS• PaaS
• Workload Mobility
• Extended Network
• Catalog Sync
Monitoring, Compliance, Remediation, Reporting
vSphere (vCenter/ESX)

12. 1313
Agenda
Method Q/AOverview Design Patterns

13. 1414
Vision
Architecture
PlanTransition
Manage
Governance
Requirements
Management
Change Mgmt
Method
Articulated vision
Business and Technical Goals
Requirements, Assumptions,
Constraints, Scope, Risks,
Use Case Definition
Gap Analysis
Architecture
Definition (Business,
Information
Systems,
Technology)
Roadmap definition
Implementation
planning
Iteration planning
Implement solution
Validation
Continuous
monitoring
Optimization

14. 1515
Phased Approach
Virtualize
Servers Virtualize
Storage Virtualize
Network
Fully Automated
Phase 1
Phase 2
Phase 3
Target State
Phases can be completed in any order.
Server Virtualization is typically the low hanging fruit

15. 1616
REQUIREMENTS

16. 1717
Identify Design Inputs
There are a number of application use
cases. First and foremost are production
applications which must be ported from a
legacy environment. Migration of these
applications are critical to the success of
the project.
The development teams are interested in
being able to quickly spin up self-
contained application pods to allow for
continuous testing without impacting other
resources on the network.
Currently no provisions have been made
for additional hardware for the pilot. The
available hardware consists of a number
of blade server systems and a few legacy
storage array systems. Application I/O
profiles are not known and they would like
a flexible way to control or ensure storage
performance. They would like to minimize
the capacity required and in turn the costs
of the storage.
The existing networking infrastructure is
limited to a range of VLANs.
The company’s current operating model
consists of separate IT teams for each
major business unit. As part of ongoing
research into the cloud computing model,
the project sponsor has secured funding to
pilot an implementation. The main project
initiative is to standardize operations
centrally and provide an IaaS offering to
supplement existing IT processes.
After discussing with the current BU
stakeholders, they have identified a need
for access to separate, dedicated
environments to host their primary
production applications. In addition, they
would like sandbox execution
environments that scale as their
computing needs grow.
Metering of the environment is desired in
order to provide usage reports back to the
end consumers. A later stage will involve
integration of the metering system with the
system that handles invoice processing for
a complete chargeback model.
The provisioning process in most business
units takes anywhere from 3 days to 2
weeks due to the number of approvals
needed, application dependencies, and
integration with additional systems.
Complete automation of the provisioning
process is a key driver for the new
centralized model.
While this is a pilot, architecture of the
system should follow recommended
proven practices within the industry.

17. 1818
Identify Design Inputs
There are a number of application use
cases. First and foremost are production
applications which must be ported from a
legacy environment. Migration of these
applications are critical to the success of
the project.
The development teams are interested in
being able to quickly spin up
self-contained application
pods to allow for continuous testing
without impacting other resources on the
network.
Currently no provisions have been made
for additional hardware for the pilot. The
available hardware consists of a number
of blade server systems and a few legacy
storage array systems. Application I/O
profiles are not known and they would like
a flexible way to control or ensure storage
performance. They would like to minimize
the capacity required and in turn the costs
of the storage.
The existing networking
infrastructure is limited to
a range of VLANs.
The company’s current operating model
consists of separate IT teams for each
major business unit. As part of ongoing
research into the cloud computing model,
the project sponsor has secured funding to
pilot an implementation. The
MAIN PROJECT
INITIATIVE IS TO
STANDARDIZE
OPERATIONS
CENTRALLY
and provide an IaaS offering to
supplement existing IT processes.
After discussing with the current BU
stakeholders, they have identified a need
for access to separate,
dedicated environments to
host their primary production applications.
In addition, they would like sandbox
execution environments that scale as their
computing needs grow.
Metering of the environment is desired in
order to provide usage reports back to the
end consumers. A later stage will involve
integration of the metering system with the
system that handles invoice processing for
a complete chargeback model.
The provisioning process in most business
units takes anywhere from 3 days to 2
weeks due to the number of approvals
needed, application dependencies, and
integration with additional systems.
Complete
AUTOMATION OF THE
PROVISIONING
PROCESS IS A KEY
driver for the new centralized model.
While this is a pilot, architecture of the
system should follow recommended
proven practices within the industry.

18. 2121
Business Requirements
B101
B102
B103
B104
B105
B106
B107
B108
B109
B110
System provides separate dedicated environments.
Complete automation of the provisioning process.
System provides metering capabilities for cost reporting.
System leverages shared infrastructure and resource pooling.
System supports a catalog of standardized templates.
System provides differentiated offerings based on cost.

19. 2222
Technical Requirements
T101
T102
T103
T104
T105
T106
T107
T108
T109
T110
Must integrate with existing ticketing system
Leverage thin provisioning for storage efficiency
Centralized LDAP directory to be used
System supports a catalog of standardized vApp templates.
System provides differentiated offerings based on cost.

20. 2323
Constraints
C101
C102
C103
C104
C105
C106
C107
C108
C109
C110
Dell and AMD have been preselected as the platform of choice
Eight 1GbE ports will be used per server
NetApp’s NAS storage will be used
All Tier 2 NAS volumes are de-duplicated
Physical switches will not be configured for QoS
Existing Cisco TOR environment to be used
Limited VLANs available

21. 2424
Assumptions
A101
A102
A103
A104
A105
A106
A107
A108
A109
A110
Virtualization environment configured
Shared storage configured
VLANs and IP address reserved

22. 2929
Agenda
Method Q/AOverview Design Patterns

23. 3030
Design Patterns
Server Architecture
Storage
Architecture
Network
Architecture
Automation
Design

24. 3131
Design Patterns
Server Architecture
Storage
Architecture
Network
Architecture
Automation
Design

25. 3232
Design Considerations
 What does the environment look like today?
• How many sites?
• How many potential virtualization candidates?
• Multiple waves?
 How will this impact your Design / Project?
• Different Cluster / Datacenter structure
• Within the limits?
• Sizing based on X waves / years?
 What are the use cases?
• Server consolidation?
• IaaS?
• Service Level Agreements (SLA)?

26. 3333
Compute Considerations
 How many eggs in one basket?
• Two sockets vs four sockets
• Optimal Memory configurations
• 8GB DIMMs are cheaper than 2 x 4GB
• Triple channel configurations
• Number of DIMM slots might be different per vendor / model
 AMD vs Intel
• AMD supports more cores, while Intel generally is faster
• VMmark can be used to make perf comparisons!
 TPS vs no TPS
• Using 64-bit Guest OS’es?
• Performance gain
 Sweetspot?
• Still seems to be dual socket – 96GB of memory

27. 3434
Design Considerations
 Vendor
 AMD vs Intel
 Blade vs Rack
• Density increases
• Hot spots
• Costs
• Management
 Additional considerations
• Is embedded ESXi available?
• How much local SSD (capacity and IOPS) can it handle?
• Does it have built-in 2x 10 GE ports?
• Does the built-in NIC card have hardware iSCSI capability?
• Management integration

28. 3535
Where Do We Start?
 How many physical Datacenters will there be?
 Will each physical DC need a vCenter Server?
 For each vCenter, do we need multiple virtual Datacenters?
 For each DC, do we need multiple Clusters?
 For each Cluster, how many hosts?
Physical DC
vCenter
Datacenter Datacenter
Cluster Cluster
ESXi ESXi ESXi
vCenter
Datacenter
Physical DC vCenter Datacenter Cluster ESXi

29. 3636
Compute Recap
 Think about Performance
 Think about Sizing
 Considerations on how to scale in the future
 SLA’s
 BC/DR

30. 3737
Design Patterns
Server Architecture
Network
Architecture
Automation
Design
Storage
Architecture

31. 3838
Design Considerations
 Protocol Wars!
 Multiple Tiers?
• Or even Auto-Tiering, what is the impact?
 vSphere Storage APIs – Array Integration (VAAI)
• Does it impact sizing?
 vSphere Storage APIs – Storage Awareness (VASA)
• Will it impact operations?
 Thin provisioning?
• Thin, Thick and Eager Zeroed Thick
• vSphere vs Storage Array!
 Virtual SAN

32. 3939
Design Considerations
 Can we use Storage DRS?
• Impact on storage array features?
• Impact on sizing?
• Impact on other VMware products like vCloud Director?
 Policy-Driven Storage?
• How does it utilize VASA?
 Business Continuity Requirements?
• Or possibly in the future?
 No more worrying about block sizes with VMFS-5
• When upgrading VMFS-3 to VMFS-5 block size does not change!
 Did you know VAAI is T-10 compliant?
• Makes leveraging it easier for lower-end devices

33. 4141
Software Defined Storage
 Software “Defined” Storage – the one remaining piece of the
SDDC story
 Much like vCNS and NSX have eliminated manual networking
processes, vSAN eliminates the manual storage processes
 Policy driven; defined instead of interpreted
 Single data store per cluster
 Manage at the VM layer
41

34. 4242
The “Classic” Way
 In 5.1, previously used storage profiles to “interpret” different
storage capabilities
• No standards
• Manually created
• No service guarantees
• Storage DRS/SIOC could limit some guests to help
• Multiple platforms – outside the VMware interface scope
• Limited integration
 Result: Limited portability, significant differences between
platforms, and a lot of continuing manual work on the side of the
storage admin

35. 4343
The “Modern” Way
 Define storage policies
 Storage platform adapts your workload to match the policy
 Adjust policy on the fly as needed
 Guaranteed service levels
 Portability
 Once again, we are abstracting storage to be a VM property, much
like CPU allocations, RAM capacities, or networking segments

36. 4444
Designing “Good” Policies
 vSAN will allow you to set almost any combination of possible
attributes for a storage policy
 What makes a good policy?
• Redundancy
• Failure zones
• Disk striping (RAID)
• Read Cache
 What makes a bad policy?
• No redundancy
• Avoid waste!
• Cache reservation on namespace (it’s text!)
• Thickness of namespace (still just text!)
• Stripe width of namespace (getting the hint?)
• Same policy for everything
• A small web server with static content probably doesn’t need a cache reservation,
or much stripe width

37. 4545
Storage Recap
 Size isn’t everything, it’s the performance counts
 Understand the nature of your workloads
 Consider implications of what technology allows you to do
 Don’t overlook business continuity requirements
 Design for failure – assume anything can and will fail

38. 4646
Design Patterns
Server Architecture
Automation
Design
Storage
Architecture
Network
Architecture

39. 4747
Design Considerations
 Physical Consideration
• Number of Sites
• Active/Active Sites
• Latency between sites
• Transport Fabric (L2 or Leaf and Spine)
• Server Cluster locations
 Security Considerations
• Isolated zones (Internal, DMZ, External)
• Virtual machine groups
• Isolation between virtual machines
• VPN requirements

40. 4848
Design Considerations
 Connectivity Requirements
• Site spanning of L2 networks
• IP addressing preservation
• Multiple N-S egress locations
• E-W traffic optimizations
• Routing requirements
 Access Requirements
• Access to physical hosts on same L2
• Virtual machine IP addressing
• IPv4
• IPv6
• Virtual machine reachability
• Direct
• NAT

41. 4949
Overlapping IP Addressing/Existing IP Addressing
Design Constraint
Preserve existing network IP
addressing scheme and application
addressing scheme
Re-use IP subnets across tenants or
Zones of Control
What NSX Enables
• No changes to physical infrastructure
• No changes in the configuration of the
application
• Reduced deployment time
• Progressive migration to new
infrastructure without disruption to
application users
• Normalized segmentation and network
configuration
• Troubleshooting benefits/Operational
benefits
Design Solution
• Network overlays provisioned across
hypervisors on separate network domains
• Options for unicast, multicast of hybrid
physical network configurations
• Requires only L3 connectivity (no need for
trunking or VLAN extensions across
network domains)
• Network overlays provisioned across
hypervisors on separate network domains
• NAT implemented as edge service

42. 5050
Workload Mobility
Design Constraint
Application mobility limited by physical
network topology
• Disjoint L2 domains
• Datacenter Interconnect (DCI)
• VLAN extensions
What NSX Enables
• Removes need for trunking across
disjoint L2 domains
• Removes need of presenting two
network stacks to the hypervisor
• Removes need for extending VLANs
across L3 boundaries using data
plane implementations such as VPLS,
OTV, etc.
• No need for a multicast-capable WAN
• Allows preservation of current network
topology and addressing scheme
• Single management point/integration
point (NSX Controller API), as opposed
to having to orchestrate tasks across
individual network nodes
Design Solution
• Network overlays provisioned across
hypervisors on separate network domains
• L2-bridge gateway services to provide
connectivity for bare-metal applications or
VLAN-backed applications

43. 5151
Use Case – Providing Security Services to Applications
What NSX Enables
• East-West Firewall services
• North-South perimeter firewall
• High performance, highly scalable in-
kernel firewall service
• Security policies that follows the entire
VM lifecycle
• Centralized management of security
policies with distributed enforcement of
such policies
• Policy definition can be based on
vCenter objects
• Activity Monitoring allows for policy
enforcement based on user identity
Design Constraint
Application mobility imposes security
challenges. Lack of native security
capabilities in the application.
Design Solution
• NSX Manager deployment and
administration of security services

44. 5252
IP
Transport Network
NSX
Controller Cluster
NorthboundRESTAPI 11.1.1.10
Gateway Service
Appliance/VM
Virtual
NetworkVM1
VM2
VM1
VM2
NSX – How It Works
10.2.2.10
Data Plane Control Plane
VM1VM1
VM2
Cloud
Management
Platform
1 2
Hypervisor
10.1.1.10
VM3
192.168.1.0/24
Corpnet
20.1.1.2
VM3
Corpnet
20.1.1.2
10.97.110.10
VM2
VLAN 9
VM4 VM5
VLAN 9
VM4 VM5
1 2
Existing
DC
Network(s)
5252

45. 5353
Network Recap
• Enhanced virtual machine mobility
• Security policy decoupled from location
• Location independent IP addressing
• Virtual infrastructure design flexibility

46. 5454
Design Patterns
Server Architecture
Design
Storage
Architecture
Network
Architecture
Automation

47. 5656
Opportunities for Automation
Full automation Partial automation
Plan and
request
Self-service
portal
Billing and
charge back
Application
configuration
management
User access
provisioning
Service
catalog
Operate and
monitor
Performance
dashboards/
visualization
Incident
management
Automated
scaling
Monitoring
General
infrastructure
Business
continuity
Analytics
and capacity
management
Discovery
and asset
management
Virtualization
platform
management
Physical
resource
management
Application
lifecycle
management
Multi-cloud
management
Provision and
deploy
Application
provisioning
Service
provisioning
Application
orchestration
Security and
compliance
Processes in the operating cycle that can be automated

48. 5757
Component Integration and Interoperability
Network
Services
External
Systems
vSphere
(vCenter/ESX)
vCenter
Orchestrator
vCenter Operations
Manager
vCenter
Configuration
Manager
vCenter
Infrastructure
Navigator
vCenter Chargeback
Manager
AMQP (RabbitMQ)
vFabric Application
Director
vCloud Automation
Center
vCloud Connector
Site Recovery
Manager
Backups
vCloud Director
Public Cloud
Add more vCenters for
scale
VMware API for Data Protection
(VADP)
Some vendors back
up vCD vApp
No integration with
SRM and vCD
vCNS
Manager
vApp must be off
Network Extension
uses Layer 2 VPN
Topology
Adapter
v0.9.1 Compliant
Service
Insertion
Framework
Collects from vSphere, vCD,
and vCNS Edge
Edge integrated
w/vCD; App not
Customization w/
API/Adapter
Integrated
SQL
vCloud
API
REST
API
vCloudAPI
vCloudAPI
vCloud API
REST
API
VIM API
VIM API
vCloud
API
vCloud API

49. 5858
Key Takeaways
3
2
1
Understanding of the key design considerations
for SDDC
Understanding of the key components
of an SDDC
Understanding of the key integration points
of SDDC

50. 5959
Where Do I Go for More Information?
 SDDC
• VAPP4679 – Software Defined Datacenter Design Panel for Monster VM’s
• VCM5048 – Automating the Software Defined Data Center: How do I get started
• VSVC7498 – Deploying the Software Defined Data Center today, Customer perspectives
and tips on optimizing VMware environments with SDDC
 Software Defined Storage
• STO5638 – Best practices for Software Defined Storage
• STO5027 – VMware Virtual SAN Technical Best Practices
• STO4798 – Software Defined Storage: The VCDX way
 Software Defined Networking
• NET5716 – Advanced NSX Architecture
• NET5184 – Designing your next generation data center for Network Virtualization
 Cloud
• PHC4750 – How to build a hybrid cloud in less than a day
• PHC5640 – The story behind designing and building a distributed automation framework
for vCloud Hybrid Service

51. 6060
VMware Architect Community Launch
Join us as we launch the VMware Architect
community for the SDDC
Enjoy drinks, snacks, and conversation with other
champions of SDDC
Intercontinental Hotel
The Pacific terrace
Wednesday 28th August
5PM – 7PM

52. 6161
Questions

53. THANK YOU

55. Architecting the Software-Defined Data Center
Aidan Dalgleish, VMware
David Hill, VMware
Kamau Wanguhu, VMware
VSVC7371
#VSVC7371