Local Replication – Business Copy

Local Replication – Business Copy
Managing HP Enterprise Virtual Array Local Replication – Business Copy Local Replication – Business Copy Module 15 U4879S L.01 HP Education Services U4879S L.01

Managing HP Enterprise Virtual Array
Objectives Managing HP Enterprise Virtual Array Local Replication – Business Copy Describe the EVA local replication concepts Describe the concepts of snapshots Describe the concepts of snapclones Describe the concepts of mirrorclones Describe the use of containers Learn to use Command View EVA to create local replicas U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Array-based data replication
Managing HP Enterprise Virtual Array Local Replication – Business Copy Replication solution rather than stand-alone application Controller-based Requires interface with several applications to enable and manage Business Copy (BC) functionality Typically used to facilitate backup operations Replica presented to alternate host to offload CPU/memory/I-O overhead associated with a backup Command View EVA performs basic replication tasks Creates, manages, and configures local replication Fully integrated into the Replication Solution Manager (RSM) GUI manages both local and remote replication Server software resides on a dedicated Windows-based management server, or general purpose server Host agent software resides on various host servers Instructor notes Explain relationship between BC EVA and RSM BC EVA a total solution, not an application GUI and Online Help are part of RSM BC no longer has “its own” server and host agent software – they are part of RSM BC = Business Copy RSM = Replication Solutions Manager GUI = Graphical User Interface CA = Continuous Access EVA = Enterprise Virtual Array SMA = Storage Management Appliance BC EVA is a replication solution that depends on several different applications to manage and execute local replication functionality. These applications include VCS/XCS firmware, Replication Solutions Manager (RSM) , Command View EVA, and others that will be identified later in this course. Business Copy is used for local data replication only. Continuous Access (CA) EVA is used for remote replication activities. Both applications are managed primarily, however, through the integrated RSM GUI. Business Copy EVA formerly had its own server and host agent software components. BC EVA 2.3 was originally released with both server and host agents of its own. When Replication Solutions Manager 1.0 was released, it supported CA EVA and most, though not all, of BC EVA 2.3 functions. With the release of BC EVA 3.0, full management capability for both CA EVA and BC EVA now resides in the HP StorageWorks Replication Solutions Manager 1.1 and later software. For users wanting only a local replication capability, only BC EVA 3.0 licensing is required. For users wanting to install both local and remote replication capabilities, licenses for BC EVA and CA EVA are required. For users wanting only remote replication capability, only CA EVA licenses are required. U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Local replication Managing HP Enterprise Virtual Array Local Replication – Business Copy Capabilities of the EVA4x00/6x00/8x00 (XCS 6.x and later): Traditional snapshots (fully allocated) Virtually capacity-free snapshots (demand allocated/vsnap) Virtually instantaneous snapclone Snapclone replica resync Mirrorclone Mirrorclone snapshot Containers Vdisk restore from snapshot or mirrorclone Instructor notes Snapshots and snapclones Container: pre-allocated space used as a receptor of snapclone data. The layered application called Fast Recovery Solution (FRS) required the new snapclone options called three-phase snapclone and replica resync. FRS is an HP-supplied solution to provide a non-disruptive backup of a MS Exchange database and a timely recovery in the case of a production database failure. FRS allows the following: Ability to create and verify a point in time backup copy of a database while production database is servicing the application Ability to recover, in a timely manner, from a database that has been logically corrupted (logical corruption refers to the fact that the database is corrupted, not hardware). Mechanisms to support FRS also provide the functionality to other user applications. Note: fully-allocated snapshots will use containers in a later XCS version. U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Licensing Considerations
Managing HP Enterprise Virtual Array Local Replication – Business Copy Business Copy EVA is a separately licensed feature: Business Copy license required in addition to basic Command View license Enables all local replica types U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Creating local replicas
Managing HP Enterprise Virtual Array Local Replication – Business Copy Available only when Vdisk is not presented U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Local Replication – Business Copy Snapshots U4879S L.01

Traditional snapshot features
Managing HP Enterprise Virtual Array Local Replication – Business Copy Point-in-time (PIT) copy of source Vdisk Allocation policy: fully allocated Reserved capacity equal to Vdisk May use containers as target (same size of Vdisk, redundancy limits) Vraid: equal or less redundancy than source Vdisk Vraid6 source: Vraid6, Vraid1, Vraid5, Vraid0 target Vraid1 source: Vraid1, Vraid5, Vraid0 target Vraid5 source: Vraid5, Vraid0 target Disk group: same disk group Up to 64 snapshots per Vdisk (maximum 80TB) Same allocation policy for all snapshots Same Vraid level for all snapshots Same preferred controller as source Vdisk Replication technique: “copy out before write” on changes (writes) to source Vdisk (copy on demand) U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Traditional snapshot operation
Managing HP Enterprise Virtual Array Local Replication – Business Copy Contents different Contents different Contents identical Vdisk Snap of A Vdisk Snap of A A (contents Vdisk A Snap of (contents as of T0) A A as of T0) Instructor notes Fully-allocated (traditional) snapshot - operations are similar to the HSG80 controller-based snapshot. They require that you reserve and set aside the capacity amount equal to that of the original volume for the snapshot. Data is not written into this reserved space until necessary. As data changes in the original virtual disk, the data in the snapshot volume is updated with the original data. If the disk group becomes full, the snapshot remains available. T3 update T1 update T1 update T3 Volume A receives more updates Vdisk A receives updates T1 Time T0 T2 T4 T5 Copy-out preserves PIT snapshot removed Create Snapshot A U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Traditional snapshot properties
Managing HP Enterprise Virtual Array Local Replication – Business Copy Name Create time WW LUN name Redundancy Allocation policy Capacity Cache policies Comments Host LUN address OS unit ID Write protection Reserved capacity vs. used U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

How snapshots work Managing HP Enterprise Virtual Array Local Replication – Business Copy OS Write Snapshot (reserved) block map Virtual disk block map Instructor notes This slide animated and hidden and included for the instructors option to help illustrate the previous slides concept. The numbers indicate actions that occur with mouse click. 1. Start with a disk group with a certain amount of available storage. 2. Create a virtual disk for applications and data. 3. Create a snapshot of that disk for backup. Note that the blocks that were only mapped to the virtual disk are now mapped to two places - the virtual disk and the snapshot. The mapping is now shared. 4. After the snapshot is created, changes are made to a file residing on the virtual disk. 5. Before those changes are made to the original disk, the data is moved to the snapshot—a copy-out. Note that the snapshots mapping has been updated accordingly so that it can find the data at its new home. Note also that this particular location is no longer part of a shared-map, but is exclusive to the snapshot. Then and only then, do we allow the original data to be overwritten at its original location. R Disk Group Unused blocks Shared data Snapshot mapped R Reserved blocks Virtual disk mapped Changed data (unshared) U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Virtual snapshot features (Vsnap)
Managing HP Enterprise Virtual Array Local Replication – Business Copy Point-in-time (PIT) copy of source Vdisk Allocation policy: demand allocated No initial reserved capacity Capacity allocated on demand with copy out (no container use) Vraid: equal or less redundancy than source Vdisk Vraid1 source: Vraid1, Vraid5, Vraid0 target Vraid5 source: Vraid5, Vraid0 target Disk Group: same disk group Up to 64 snapshots per Vdisk (maximum 80TB) Same allocation policy for all snapshots Same Vraid level for all snapshots Same preferred controller as source Vdisk Replication technique: “copy out before write” on changes (writes) to source Vdisk (allocate/copy on demand) U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Vsnap operation Managing HP Enterprise Virtual Array Local Replication – Business Copy Contents Contents Contents different identical different Vdisk Snap of A Vdisk Snap of Vdisk Snap of A A (contents A A A (contents as of T0) as of T0) Instructor notes Demand-allocated (Virtually Capacity-Free or Vsnap) Snapshots have minimal space reserved up front. Space is only used as the original virtual disk changes data. For example, you can create a snapshot of a virtual disk. This snapshot is actually a new virtual disk that initially shares the data block mapping with the original virtual disk. As the data changes (either on the original virtual disk or the snapshot), portions of the data block mapping can no longer be shared. Therefore, each host write command results in an unsharing operation. The segments of blocks, however, are shared storage between the snapshot and the original virtual disk. The demand-allocated snapshot can be created with any level of redundancy using the EVA. If the disk group becomes full, the snapshot is marked as overcommitted and put into an inoperative state. T3 update T1 update T1 update Volume A Volume A receives more receives updates updates Time T0 T1 T2 T3 T4 T4 T4 T5 snapshot removed copy-out preserves PIT Create Snapshot A U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Vsnap properties Managing HP Enterprise Virtual Array Local Replication – Business Copy Name Create time WW LUN name Redundancy Allocation policy Capacity Cache policies Comments Host LUN address OS unit ID Write protection Write-back when presented Reserved capacity vs. used U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Creating a snapshot (1 of 2)
Managing HP Enterprise Virtual Array Local Replication – Business Copy No existing replicas - all replica types available Select source Vdisk Choose replica U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Creating a snapshot (2 of 2)
Managing HP Enterprise Virtual Array Local Replication – Business Copy -1- Provide a snapshot name (32 char max) default date-time -2- Select the Allocation policy (first snap only) Instructor notes Virtual disk name The Vdisk name is assigned to a Vdisk or to a Vdisk family. The maximum length is 32 characters. Names can contain any characters, except for the following: ? (question mark) " (double quotes) / (slash) \ (backslash) < (less than sign) > (greater than sign) * (asterisk) | (vertical bar) : (colon) + (plus sign) , (comma) & (ampersand) % (percent sign) Use a meaningful name that can be easily remembered. Example: A disk that contains payroll data could be called Payroll or PayrollJanuary. -3- Select a container if Fully Allocated Resulting snapshot -6- Create the Snapshot -5- Optional host presentation -4- Vraid level (<= source) U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Snapshot instant restore (snapback)
Managing HP Enterprise Virtual Array Local Replication – Business Copy Allows you to restore a source virtual disk from a snapshot in normal mode Snapshots may be associated with a mirrorclone Limitations Snapshots higher in hierarchy remain intact, but there is double copy before write penalty Restored snapshot must be unpresented Instant access to data during restore Example shows restore from Snapshot 2 Source Vdisk Snapshot 7 Snapshot 2 Snapshot 1 Oldest Newest Instructor notes Describe normal and high performance modes. Written data that has not been copied from the snapshot must be copied prior to write. Snapshot instant restore (snapback) Normal mode maintains newer existing snapshots within the snapshot tree during the instant restore. High performance mode, not yet implemented, will allow a faster restore but existing snapshots within the tree will be invalidated. The instant access to data during restore is provided by two mechanisms: Data is read from the snapshot if not previously copied to source. U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Snapback operation Managing HP Enterprise Virtual Array Local Replication – Business Copy Vdisk with snap(s) Restore (un-presented snaps or mirrorclone) Snap selection Restore U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Local Replication – Business Copy Snapclones U4879S L.01

Virtually instantaneous snapclone
Managing HP Enterprise Virtual Array Local Replication – Business Copy Process to create a point-in-time full copy of a Vdisk Available immediately (like a traditional snapshot) Full background copy (normalization) Becomes an independent object (Vdisk) when normalized Options: Cross disk group clone operation (FC or FATA) Same or different Vraid level than source Cloning may be into an existing (empty) container Requires write-through cache mode May be set to different preferred controller May have snapshots (after normalized) Instructor notes Snapclone (Virtually Instantaneous snapclone) is an improved type of data cloning. It is similar to a fully-allocated snapshot in that duplicate space is reserved. However, a complete copy of the original virtual disk is created, instead of only copying changes. Two identical copies of the data are created with a snapclone. Unlike traditional clones performed by other controllers, the EVA snapclone data can be accessed immediately instead of waiting until the copy is complete. The EVA controller can access the original virtual disk for the data and keep track of what data has changed since the instant the snapclone was taken. U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Snapclone properties Managing HP Enterprise Virtual Array Local Replication – Business Copy Same as any other Vdisk after normalization Default name identifies the original Vdisk Write cache transitions to write-back requested after replication Write-back becomes actual upon presentation U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Local Replication – Business Copy Containers U4879S L.01

Containers (1 of 3) Managing HP Enterprise Virtual Array Local Replication – Business Copy Containers have two general purposes when used in conjunction with Business Copy: Pre-allocated space (container) can be used as a replica target for fully allocated snapshots, snapclones, or mirrorclones (required) Used with a snapclone to perform data roll-back/recovery using the “Convert to Container” feature – Snapclone Replica Resync U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Containers (2 of 3) Managing HP Enterprise Virtual Array Local Replication – Business Copy Object used as a target for replication May be created in any Virtual Disk folder Pre-allocated disk group capacity with Vraid level Vdisk may be converted into a container using the “Convert to Container” feature Pre-allocated container may be used as a replica target for: Three-phase fully allocated snapshot into a container Container must be within the same disk group and must be the same vraid level or less restrictive Three-phase snapclone into a container Container may be in any disk group and can be any vraid level Three-phase mirrorclone into a container Replica resync into an empty container (fast recovery) Vdisk may be converted into a container (emptied) and used as a replica target for a Vdisk (typically a snapcloned replica) U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Containers (3 of 3) Managing HP Enterprise Virtual Array Local Replication – Business Copy Enables fully-allocated snapshots/snapclones/mirrorclones to be created into a pre-allocated ‘container’ Avoids overhead of allocation before copy in a single action Vdisk must be transitioned (manual) to write-through before a snapclone operation (not required for snapshots/mirrorclones) Allows ‘flick-of-the-switch’ commit and association with container Vdisk transitions (automatic) to write-back after snapclone completes U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Container creation Managing HP Enterprise Virtual Array Local Replication – Business Copy Select any Vdisk folder Select container properties: name size (GB) disk group Vraid level Empty container created (in UNIX folder) U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Three-phase Snapclone
Managing HP Enterprise Virtual Array Local Replication – Business Copy Source Vdisk production Create empty recovery Vdisk 1. Create empty container to pre-allocate backend storage (recovery Vdisk) Source Vdisk application flush Empty recovery Vdisk 2. Transition Vdisk to write-through mode; Flush applications cache Instructor notes Three-phase snapclone Here is a description of the three phases in the picture. The first phase represents an active production database, and the pre-allocation of an empty container for later use as a snapclone. This could take place a day or a week before its actual use as a snapclone, but needs to occur far enough in advance for the creation of the empty container to complete and finish its background allocation work. The second phase represents transitioning the parent virtual disk to write through and applications flushing their caches, in preparation for a flick-of-the-switch commit. The third phase shows the flick-of-the-switch association of the pre-allocated empty container as a snapclone, and the transitioning of the source virtual disk back to write-back mode. This flick-of-the-switch commit could have happened atomically for multiple snapclones—one per parent virtual disk. Source Vdisk production Snapclone recovery Vdisk 3. “Flick of the switch commit”, snapclone association. Transition Vdisk to write-back. Copy U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Snapclone creation using a Container (1 of 2)
Managing HP Enterprise Virtual Array Local Replication – Business Copy source vdisk First, source vdisk write caching policy must be transitioned from Write-back to Write-through to snapclone into a container. U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Snapclone creation using a Container (2 of 2)
Managing HP Enterprise Virtual Array Local Replication – Business Copy U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Replica Resync (1 of 3) Managing HP Enterprise Virtual Array Local Replication – Business Copy snapclone source vdisk In the following example, vdisk003 was the original source, and a snapclone was created called Copy of vdisk003. If vdisk003 becomes corrupt, we can use the snapclone to roll the data back. To do this…… U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Replica Resync (2 of 3) Managing HP Enterprise Virtual Array Local Replication – Business Copy Unpresent the corrupt vdisk if presented, and select Convert to container. This flushes out corrupt data and sets up up the corrupt vdisk as a container to clone in the other direction. U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Replica Resync (3 of 3) Managing HP Enterprise Virtual Array Local Replication – Business Copy Snapclone (Copy of vdisk002) now becomes the source, and corrupted source (which is now a container) becomes the target for the new snapclone. U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Snapclone replica resync (1 of 3)
Managing HP Enterprise Virtual Array Local Replication – Business Copy Revert to a previous point-in-time copy (snapclone) if a virtual disk becomes corrupted Any virtual disk to be re-synced to any virtual disk: source/target must match in size the target is not presented Assumption: periodic backup performed as snapclones Process includes these steps Quiesce the application (un-mount the filesystem/volume) Un-present the source (corrupted) Vdisk Change the source Vdisk into a container SET VDISK CHANGE_INTO_CONTAINER (SSSU command) or “Convert to Container” option in Command View EVA Creates an empty container with the same settings as the original Vdisk Instructor notes Snapclone replica resync (1 of 3) The second part of FRS is recovery after source virtual disk (production database) failure. This second phase uses one of the commands resulting from the three-phase snapclone create work. This is the empty container command. This command is applied to the production database and empties the database in seconds. As soon as the production database is emptied, it is attached to the recovery database as a snapclone, and application I/Os are restarted to the production database. U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Snapclone replica resync (2 of 3)
Managing HP Enterprise Virtual Array Local Replication – Business Copy Process includes these steps (continued) Restore the virtual disk data: Create a snapclone of the previously taken backup snapclone Use the container (former Vdisk) as the destination Data is as current as your most recent snapclone (backup) When the new snapclone completes, it will become an independent virtual disk with the same settings as the previously corrupted virtual disk Restart application on the restored (snapclone) Vdisk Should only be a few minutes of impact U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Snapclone replica re-sync (3 of 3)
Managing HP Enterprise Virtual Array Local Replication – Business Copy 1. Application I/Os directed at source 2. After the snapclone finishes normalizing, it transitions to being a regular Vdisk. At this point a database validation could be run. Source Vdisk production disk group Snapclone recovery disk group before corruption after corruption 3. Production database gets corrupted. Must transition and use validated recovery database. Source Vdisk bad Recovery Vdisk Instructor notes This process is detailed in the student notes. A. Quiesce B. Empty C. Make the original source a snapclone of the recovery Vdisk D. Start the application at the source Source Vdisk snapclone Recovery Vdisk 4. When source is normalized, it is re-synced Snapclone/snapshot Source Vdisk U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Local Replication – Business Copy Mirrorclones U4879S L.01

Mirrorclones Managing HP Enterprise Virtual Array Local Replication – Business Copy Clone of a virtual disk that is completed, allocated, and normalized at the time of creation Mirrorclone stays up-to-date with changes in parent Vdisk Requires the use of containers and the three-phase process to create Several mirrorclone states Synchronized — Source and clone are synchronized so that the clone is automatically updated whenever the source virtual disk is updated Fracture (Suspend) — Gives point in time copy, sharing relationship still intact, allows snapshots to be taken Resynch — Takes mirrorclone out of fractured state and resumes replication. This is also called delta resynch. Restore — Contents of the source are being restored with point-in-time data from its mirrorclone (same operation as Snapback) Detach — Sharing relationship is broken and mirrorclone becomes standalone virtual disk (same as if a snapclone was created) Instructor notes This is the latest replication type. Describe in combination with the next slide. Mirrorclones (1 of 2) The mirrorclone offers the ability to resynchronize the clone to its source at a later time, or to restore the source directly from the clone. You may see any of the mirrorclone states in Command View EVA. U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Mirrorclone guidelines
Managing HP Enterprise Virtual Array Local Replication – Business Copy The array must have a local replication (Business Copy) license A mirrorclone may be in a different disk group than the source Based on chosen container For optimum protection from hardware failures, HP recommends creating a mirrorclone in a different disk group The redundancy level of a mirrorclone can be the same, lower, or higher than the source (according to container) You can present a mirrorclone only if the mirror link is suspended (fractured) Only one mirrorclone per Vdisk Fractured mirrorclone may have snapshots You cannot create a mirrorclone when the source is A snapshot A Vdisk that has a snapshot In the process of normalizing (cloning) or being deleted U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Mirrorclone operations (1 of 2)
Managing HP Enterprise Virtual Array Local Replication – Business Copy Synchronized mirrored Source Vdisk Mirrorclone synchronized Bitmap Fractured (PIT) (bitmap records changes to source) Source Vdisk Mirrorclone fractured (PIT) Fractured Bitmap Instructor notes Describe each of the mirrorclone states in combination with the previous slide. Resynching Source Vdisk Mirrorclone resynching Bitmap Source Vdisk Restore destination Restoring Mirrorclone or source Detached Source Vdisk Independent Vdisk Relationship broken U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Mirrorclone operations (2 of 2)
Managing HP Enterprise Virtual Array Local Replication – Business Copy Current State Operations Normalized Fractured Snapshots of Fractured mirrorclone Detached U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Mirrorclone properties
Managing HP Enterprise Virtual Array Local Replication – Business Copy during normalization after normalization U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Create a Vdisk mirrorclone page
Managing HP Enterprise Virtual Array Local Replication – Business Copy From Vdisk Properties page, select Create mirrorclone Container disk group and redundancy fix attributes for the mirrorclone Instructor notes You must create a container for the mirrorclone before creating the mirrorclone. To create a mirrorclone in the simplest way: Enter a name. Select a container. Click Create Mirrorclone. U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Replica comparison Managing HP Enterprise Virtual Array Local Replication – Business Copy Replica type Description Pros Cons Fully-allocated snapshot Pointer-based copy before writes Space allocated at creation No over-committing Space inefficient Demand-allocated snapshot Pointer-based copy before writes Space allocated on demand Space efficient Can over commit Snapclone Fully-allocated snapshot until background copy complete Independent separate Vdisk No over committing Some background process time consumed Mirrorclone Synchronized full replica of a Vdisk Instant clone for snapshot creation Instant restore Overhead to track updates U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

When to use each replica type
Managing HP Enterprise Virtual Array Local Replication – Business Copy Replica type When to choose this type Fully-allocated snapshot When you want a quick, low-overhead copy of a Vdisk, and you expect significant changes to the source Vdisk during the life of the snapshot Demand-allocated snapshot When you want a low-overhead copy, and you expect no more than % of the source Vdisk to change Snapclone When you need independent and durable copies; for example, for data mining, data warehousing, or preproduction testing Mirrorclone When you need a synchronized copy of a Vdisk that is updated as the source Vdisk changes; useful for getting an instant point-in-time snapshot of a Vdisk for backup U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Review Questions Managing HP Enterprise Virtual Array Local Replication – Business Copy Name the two types of snapshots and the pros and cons of each. What are the advantages of creating a snapclone vs. a snapshot? What is a container? What are the advantages of using a container? What are the pros and cons of creating a mirrorclone vs. a snapclone? To create a snapclone into a container, what must be done to the source vdisk first before creation of the snapclone? To access the data from a mirror, a mirrorclone has to be taken into which state? A. Synced D. Normalized B. Detached E. None of the Above C. Fractured Instructor notes This is the latest replication type. Describe in combination with the next slide. Mirrorclones (1 of 2) The mirrorclone offers the ability to resynchronize the clone to its source at a later time, or to restore the source directly from the clone. You may see any of the mirrorclone states in Command View EVA. U4879S L.01 – © 2011 Hewlett-Packard Development Company, L.P. U4879S L.01

Local Replication – Business Copy Lab activity U4879S L.01

Local Replication – Business Copy

Similar presentations

Presentation on theme: "Local Replication – Business Copy"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Local Replication – Business Copy

Similar presentations

Presentation on theme: "Local Replication – Business Copy"— Presentation transcript:

Similar presentations

About project

Feedback