53
Tips for Data Center Preservation Hashtag #SOSPG5
Tips for Data Center
Preservation
Hashtag #SOSPG5
Data Center in the
Cloud Matthew E. Donehoo
Director of Information Systems
Segal McCambridge Singer & Mahoney, Ltd.
Storage Infrastructure as a Service
3
Storage Controller
Storage Infrastructure
as a Service
SAN/NAS/DAS
WAN Accelerator
D2D
Tape
Backup
Application
Tape Storage
Replicated SAN
Replicated D2D
Do-it-yourself Storage Infrastructure
A New Logical Volume
Why Cloud Storage?
4
• Unlimited/Elastic
• Protected
• Available from Anywhere
Someone else’s job to run it
Storage Controller
What are the benefits?
5
• Complete centralized control
of all storage infrastructure
• Single, simplified solution
• Unlimited scale without
provisioning
• No more backups – ever
• Infrastructure delivered on-
demand as a service
• Integrated data access – in
every location
• Mobile & browser client
support
• Reduced access delays &
greater productivity
Better
Storage
Simpler
Synchronization
6
Addressing our needs
Security &
Access
Growth &
Infrastructure
Support unpredictable
data spikes
Distribute data across
multiple offices
Provide convenient
access
Protect data for
defensibility
Instant scalability
Single global namespace
Access in every location
Local access everywhere
including mobile
Customer managed
access & encryption
Data growth and capacity scaling
7
5TB 50TB 500TB • Scale capacity instantly
• Support unpredictable data spikes
• Meet capacity demands
for litigation support
Mobile access and sharing
8
• Access the corporate file
share from anywhere
• Deliver presentations
right from the device
• Share documents with
others on the fly
• Eliminate the use of
Dropbox
Cloud Mirroring™
for more data protection
9
Thank you!
Matthew E. Donehoo
Director of Information Systems
Segal McCambridge Singer & Mahoney, Ltd.
VMware Site Recovery
Manager Colby Corso
IT Infrastructure Manager
Irell & Manella LLP
VMware Site Recovery Manager
(SRM)
SRM Topology Options
Recovery Plans
Array-based Replication
vSphere Replication
vSphere Replication
Planned Migrations
Failback
Testing Recovery Plans
Testing Recovery Plans
Thank you!
Colby Corso
IT Infrastructure Manager
Irell & Manella LLP
310-203-7121
OTV & LISP Brian Farnham
Technical Marketing Engineer
Cisco Systems, Inc.
What is OTV?
OTV is an innovative Layer 2 interconnect from Cisco
Replacement for MPLS, VPLS, & STP based technologies
Much easier to provision and maintain
Supported on the Nexus 7000, ASR1000 & CSR1000v
Data Center Interconnect
VSS & vPC or FabricPath Applies easily for dual site interconnection
Over dark fiber or protected D-WDM
Easy crypto using end-to-end 802.1AE
OTV – Overlay Transport Virtualization MAC in IP
EoMPLS & VPLS & A-VPLS & H-VPLS PE style
Multi-tenants
Most deployed today
Traditional Layer 2 Extensions
33
Challenges in Traditional
Layer 2 VPNs
34
Flooding Behavior Pseudo-wire Maintenance Multi-Homing
- Unknown Unicast for MAC propagation - Unicast Flooding reaches all sites
- Full mesh of Pseudo-wire is complex - Head-End replication is a common problem
- Requires additional Protocols & extends STP - Malfunctions impacts multiple sites
No Pseudo-Wire
State Maintenance
Optimal Multicast
Replication
Multipoint Connectivity
Point-to-Cloud Model
Preserve Failure Boundary
Built-in Loop Prevention
Automated Multi-Homing
Site Independence
Terminology
Edge Device Performs all OTV functionality
Internal Interface Carry VLANs extended through OTV
Regular Layer 2 interfaces
No OTV configuration required
Join Interface One of the uplink of the Edge Device
Used to physically “join” the Overlay
network
No OTV specific configuration required
Overlay Interface Virtual interface with most of the OTV
configuration
Encapsulates Layer 2 frames in IP unicast or
multicast
OTV Devices and Interfaces
37
Core Device
OTV Edge Device
OTV Internal Interface
OTV Join Interface
Aggregation Device
OTV Overlay Interface
West
OTV
South
East
OTV
OTV
OTV Control Plane
OTV Control Plane OTV Control Plane
IP A IP B
IP C
Encap Decap
Decap
OTV Hello
OTV Hello
OTV Hello
IGMP Join G
IGMP Join G
IGMP Join G
Multicast state for group G
established throughout transport
Transport natively replicates
multicast to all OIFs
All edge devices join OTV
control-group G
1
2
3
4
5
6
6
7
7
IP A G OTV Hello
IP A G OTV Hello
IP A G OTV Hello
OTV Hello IP A G OTV Hello
OTV Hello IP A G OTV Hello
Neighbor IP Addr
West IP A
Neighbor IP Addr
West IP A
Neighbor IP Addr
Multicast-enabled
Transport
3
8
OTV Control Plane
3
9
South
East West
OTV
OTV
OTV
OTV Control Plane
OTV Control Plane OTV Control Plane
IP A IP B
IP C
Decap Decap
Encap
OTV Hello
IP C G OTV Hello
IP C G OTV Hello IP C G OTV Hello
OTV Hello OTV Hello
OTV Hello IP C G OTV Hello OTV Hello IP C G OTV Hello
Neighbor IP Addr
West IP A
Neighbor IP Addr
West IP A
South IP C
Neighbor IP Addr
South IP C
1
2
3
4 4
5 5
Bidirectional
adjacency formed
The South Site creates its
hello with West’s address
in the TLV
Multicast-enabled
Transport
OTV Control Plane
South
East West
OTV
OTV
OTV
VLAN MAC IF
100 MAC A IP A
100 MAC B IP A
100 MAC C IP A
VLAN MAC IF
100 MAC A IP A
100 MAC B IP A
100 MAC C IP A
VLAN MAC IF
100 MAC A e1/1
100 MAC B e1/1
100 MAC C e1/1
VLAN MAC IF
100 MAC A e1/1
101 MAC B e1/1
102 MAC C e1/1
Update A
VLAN MAC IF
100 MAC A IP A
101 MAC B IP A
102 MAC C IP A
VLAN MAC IF
100 MAC A IP A
100 MAC B IP A
100 MAC C IP A
New MACs learned
in VLANs that are
OTV extended
Craft OTV
update with
new MACs
IP A G Update A
Update A
Update A
IP A G Update A
IP A G Update A
Update A IP A G Update A
Update A IP A G Update A
Encap Decap
Decap 1
2
3
4
5
5
6
6
VLAN MAC IF
100 MAC A IP A
101 MAC B IP A
102 MAC C IP A
7
7
Add MACs
learned
through OTV
Add MACs
learned
through OTV
MAC Table
MAC Table
MAC Table
Multicast-enabled
Transport
OTV MAC Learning
4
0
Spanning-Tree and OTV
Site transparency: no changes to the
STP topology
Total isolation of the STP domain
Default behavior: no configuration is
required
BPDUs sent and received ONLY on
Internal Interfaces
Site Independence
41
L
2
L
3
OT
V OT
V
The BPDUs
stop here
The BPDUs
stop here
L
2
L
3
OTV
OTV
Unknown Unicast and OTV No Longer Unknown Unicast Storms Across the DCI
42
No requirements to forward
unknown unicast frames
Assumption: end-host are not silent
or uni-directional
Default behavior: no configuration
is required
MAC TABLE
VLAN MAC IF
100 MAC 1 Eth1
100 MAC 2 IP B
- - -
MAC 1 MAC 3
No MAC 3 in the
MAC Table
OTV Multi-homing
• No additional protocols
required (i.e. BGP)
• OTV site-vlan used to discover
OTV neighbor in the same site
• Authoritative Edge Device
(AED) Election takes place
• Extended VLANs are split across
the AEDs
• The AED is responsible for:
‒ MAC address advertisement for its VLANs
‒ Forwarding its VLANs’ traffic inside and outside
the site
Fully Automated Multi-homing
43
L
2
L
3
OTV OTV AED AED
Site Adjacency used for AED election
Site Adjacency
Path Optimization
• Extended VLANs typically have associated HSRP groups
• By default, only one HSRP router elected active, with all servers pointing
to HSRP VIP as default gateway
Egress Routing with LAN Extension
44
HSRP
Active
HSRP
Standby
HSRP
Listen
HSRP
Listen
HSRP Hellos
VLAN
20
VLAN
10
ARP for
HSRP VIP
ARP reply
Packet from
Vlan 10 to Vlan 20
DMAC = Host Vlan 20
Packet from
Vlan 10 to Vlan 20
DMAC = DGW
Routing
Egress Routing Localization
• Filter FHRP with combination of VACL and MAC route filter
• Result: Still have one HSRP group with one VIP, but now have active
router at each site for optimal first-hop routing
FHRP Filtering Solution
45
HSRP
Active
HSRP
Standby
HSRP
Listen
HSRP
Listen
HSRP Hellos
VLAN
20
VLAN
10
HSRP Hellos ✗ ✗ ✗ ✗
HSRP Filter
HSRP
Active HSRP
Standby
ARP for
HSRP VIP
ARP reply
Path Optimization
• Layer 2 extensions represent a challenge for optimal routing
• Challenging placement of gateway and advertisement of routing
prefix/subnet
Optimal Routing Challenges
46
HSRP
Active
HSRP
Standby
HSRP Filter
HSRP
Active HSRP
Standby
East-West /
Server-Server
Egress:
South-North /
Server-Client
Egress:
South-North /
Server-Client
Ingress:
North-South /
Client-Server
Ingress:
North-South /
Client-Server
Ingress Routing Localization Possible Solutions
47
Challenge
•Subnets are spread across locations
•Subnet information in the routing
tables is not specific enough
•Routing doesn’t know if a server has
moved between locations
•Traffic may be sent to the location
where the application is not available
Options
•DNS Based
•Route Injection
•LISP – Locator/ID Separation Protocol
Introduction to
Location Identity
Separation Protocol
(LISP)
Internet
Device IPv4 or IPv6
address represents
identity and location
Today’s Internet Behavior Loc/ID “overloaded” semantic
x.y.z.1 When the device moves, it gets
a new IPv4 or IPv6 address for
its new identity and location
w.z.y.9
Device IPv4 or IPv6
address represents
identity only.
When the device moves, keeps
its IPv4 or IPv6 address.
It has the same identity
LISP Behavior Loc/ID “split”
Internet
a.b.c.1
e.f.g.7
Only the location changes
x.y.z.1
x.y.z.1
Location Identity Separation Protocol What do we mean by “location” and “identity”?
Its location is here!
A LISP Packet Walk How Does LISP Operate?
Non-LISP site
East-DC
LISP site
IP Network
ETR
EID-to-RLOC mapping
172.16.1.1 172.16.2.1
1.1.1.1
3.3.3.3
172.16.10.1
2.2.2.2
10.2.0.0/24
172.16.3.1 172.16.4.1
10.1.0.0/24
West-DC
PiTR
4.4.4.4
10.3.0.0/24
Non-LISP site
ITR S
D
DNS entry: D.abc.com A 10.1.0.1
1
10.3.0.1 -> 10.1.0.1
2
EID-prefix: 10.1.0.0/24
Locator-set:
172.16.1.1, priority: 1, weight: 50 (D1)
172.16.2.1, priority: 1, weight: 50 (D2)
Mapping
Entry
3
This policy controlled
by destination site
10.3.0.1 -> 10.1.0.1
172.16.10.1 -> 172.16.1.1
4
10.3.0.1 -> 10.1.0.1
5
Access
Agg
VM= 10.10.10.1 Default GW = 10.10.10.100
ISP A ISP B
Access
Agg
Data Center A
LAN Extension
Prefix
(EID)
Route Locator
(RLOC)
10.10.10.1 A, B
10.10.10.2 A, B
… …
10.10.10.5 C, D
10.10.10.6 C, D
Ingress Tunnel
Router (ITR)
Moved to C, D
Decap
3
IP_DA = 10.10.10.1
1
ETR
Routing Based Ingress Optimization
A B C D
IP_DA = 10.10.10.1
IP_DA = 10.10.10.1
4
5
Decap
7
IP_DA = 10.10.10.1
6 Encap
2
Data Center B
ETR
VM= 10.10.10.1 Default GW = 10.10.10.100
IP_DA = 10.10.10.1
VM IP Address
10.10.10.1
Thank you!
Brian Farnham
Technical Marketing Engineer
Cisco Systems, Inc.
Questions?
