Architecture Deep Dive for VPLEX

What is it?

  • Storage federation platform that extends storage beyond the boundaries of the data center
  • Distributed, peer-to-peer, fault-tolerant storage system

What problem does it solve?

  • Simultaneous access to storage devices from two distinct locations
  • Planned data mobility within, across and between data centers

What’s unique?

  • Clusters can scale out and scale up
  • Distributed coherent cache enabling distributed storage access
  • Designed for asynchronous distances and multiple clusters

VPLEX Director

  • 8x 8Gb/s FC front-end
  • 8x 8Gb/s backend
  • Dual quad-core processors (2.33Ghz)
  • 32GB memory, about 25GB for cache
  • 4x 8Gb/s FC com ports (intra- and inter-cluster)
  • 4x 1Gb/s Ethernet com ports (inter-cluster)
  • Standard EMC hardware
  • GeoSynchrony is the operating system
  • Looks like a VMAX engine

VPLEX Cluster

  • Rack containing 1, 2, or 4 engines
  • Plus a management server (and standby)
  • Intra-director fibre channel switches
  • Power and battery backup for each engine
  • Cabling for management and intra-cluster com
  • VPLEX Local is one cluster
  • VPLEX Metro is two clusters

Major Subsystems

  • Front-end – storage view
  • Cache – distributed coherent cache
  • Device Virtualization – virtual volumes
  • Back-end – storage volumes

Lease Rollover

  • Can be used to migrate data from one array to a new array
  • Import new storage array/volumes
  • Production volumes are mirrored
  • Original array can be pulled out while the virtual devices now point to the new array

Application Migration

  • Enable application at the remote site
  • Cache activity now functions at source and remote site
  • Disable application at source site
  • Cache activity migrates to the remote site

Cluster failure and cluster partition

  • Cluster failure and partition is hard
    • What does A know and when does it notice it can talk to B any more?
    • Easy if B’s really dead (then it can’t mess us up), but what if it’s still alive?
    • How do A and B decide what to do?
  • Cluster Bias
    • Each distributed volume has a bias that favors one site over another
  • What happens to all the writes to the other side?

A Closer Look at Distributed Mirrors

  • Each disributed mirror has two dirty region logs
    • One records writes that couldn’t be committed locally
    • One records writes that couldn’t be committed to the remote site
  • Each distributed mirror also has a bias and timeout for applying that bias

Failure of cluster without bias

  1. IO goes to cluster A and B
  2. Something bad happens to A. A can’t talk to B and thus starts a timer. IO pauses briefly
  3. The timer expires, IO resumes for hosts at A. Writes are logged to the DRL.
  4. Eventually B is repaired and brought back online. A and B reconnect.
  5. A begins to resynchronze B based on DRL. Distributed mirror and cache coherency present A’s version of the data
  6. Resynchronization finishes, DRLs are now empty

Failure of cluster with bias

  1. IO goes to cluster A and B
  2. B can’t talk to A. IO pauses indefinitely.
  3. Admin instructs B to resume IO, and starts passive application at B. Writes are logged in B’s DRL
  4. A is repaired and brough back online. And B reconnect. A notices B continued in spite of bias settings.
  5. B begins to resynchronze A based on DRL. Distributed mirror and cache coherency present B’s version of the data
  6. Resynchronization finishes, DRLs are now empty
Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s