SRDF & Timefinder Resume

15,423 views

Published on

Resume of architecture and usage of SRDF & Timefinder tools, within its options, such as Snap, Clone, Mirror and Sync / Async, etc

3 Comments
25 Likes
Statistics
Notes
No Downloads
Views
Total views
15,423
On SlideShare
0
From Embeds
0
Number of Embeds
85
Actions
Shares
0
Downloads
702
Comments
3
Likes
25
Embeds 0
No embeds

No notes for slide

SRDF & Timefinder Resume

  1. 1. EMC – Local Replication Solutions All the local replication solutions that were discussed in this module are available on EMC Symmetrix and CLARiiON arrays. Ÿ EMC TimeFinder/Mirror and EMC TimeFinder/Clone are full volume replication solutions on the Symmetrix arrays, while EMC TimeFinder/Snap is a pointer based replication solution on the Symmetrix. EMC SnapView on the CLA RiiON arrays allows full volume replication via SnapView Clone and pointer based replication via SnapView Snapshot. Ÿ EMC TimeFinder/Mirror: Highly available, ultra-performance mirror images of Symmetrix volumes that can be non-disruptively split off and used as point-in-time copies for backups, restores, decision support, or contingency uses. Ÿ EMC TimeFinder/Clone: Highly functional, high-performance, full volume copies of Symmetrix volumes that can be used as point-in-time copies for data warehouse refreshes, backups, online restores, and volume migrations. Ÿ EMC SnapView Clone: Highly functional, high-performance, full volume copies of CLARiiON volumes that can be used as point-in-time copies for data warehouse refreshes, backups, online restores, and volume migrations. Ÿ EMC TimeFinder/Snap: High function, space-saving, pointer-based copies (logical images) of Symmetrix volumes that can be used for fast and efficient disk-based restores. Ÿ EMC SnapView Snapshot: High function, space-saving, pointer-based copies (logical images) of CLARiiON volumes that can be used for fast and efficient disk-based restores. We will discuss EMC TimeFinder/Mirror and EMC SnapView Snapshot in more detail in the next few slides. Ÿ Array based local replication technology for Full Volume Mirroring on EMC Symmetrix Storage Arrays – Create Full Volume Mirrors of an EMC Symmetrix device within an Array Ÿ TimeFinder/Mirror uses special Symmetrix devices called Business Continuance Volumes (BCV). BCVs: – Are devices dedicated for Local Replication – Can be dynamically, non-disruptively established with a Standard device. They can be subsequently split instantly to create a PIT copy of data. Ÿ The PIT copy of data can be used in a number of ways: – Instant restore – Use BCVs as standby data for recovery – Decision Support operations – Backup – Reduce application downtime to a minimum (offline backup) – Testing Ÿ TimeFinder/Mirror is available in both Open Systems and Mainframe environments Ÿ Establish – Synchronize the Standard volume to the BCV volume – BCV is set to a Not Ready state when established Ø BCV cannot be independently addressed – Re-synchronization is incremental – BCVs cannot be established to other BCVs – Establish operation is non-disruptive to the Standard device – Operations to the Standard can proceed as normal during the establish Ÿ Split – Time of Split is the Point-in-Time – BCV is made accessible for BC Operations – Consistency Ø Consistent Split – Changes tracked The TimeFinder/Mirror Consistent Split option ensures that the data on the BCVs is consistent with the data on the Standard devices. Consistent Split holds I/O across a group of devices using a single Consistent Split command, thus all the BCVs in the group are consistent point-in-time copies. Used to create a consistent point-in-time copy of an entire system, an entire database, or any associated set of volumes. The holding of I/Os can be either done by the EMC PowerPath multi-pathing software or by the Symmetrix Microcode (Enginuity Consistency Assist). PowerPath-based consistent split executed by the host doing the I/O, I/O is held at the host before the split. Enginuity Consistency Assist (ECA) based consistent split can be executed, by the host doing the I/O or by a control host in an environment where there are distributed and/or related databases. I/O held at the Symmetrix until the split operation is completed. Since I/O is held at the Symmetrix, ECA can be used to perform consistent splits on BCV pairs across multiple, heterogeneous hosts.
  2. 2. Ÿ Restore – Synchronize contents of BCV volume to the Standard volume – Restore can be full or incremental – BCV is set to a Not Ready state – I/Os to the Standard and BCVs should be stopped before the restore is initiated Ÿ Query – Provide current status of BCV/Standard volume pairs TimeFinder/Mirror allows a given Standard device to maintain incremental relationships with multiple BCVs. This means that different BCVs can be established and then split incrementally from a standard volume at different times of the day. For example a BCV that was split at 4:00 a.m. can be re-established incrementally even though another BCV was established and split at 5:00 a.m. In this way, a user can split and incrementally re-establish volumes throughout the day or night and still keep re-establish times to a minimum. Incremental information can be retained between a STD device and multiple BCV devices, provided the BCV devices have not been paired with different STD devices. The incremental relationship is maintained between each STD/BCV pairing by the Symmetrix Microcode. Ÿ Two BCVs can be established concurrently with the same Standard device Ÿ Establish BCVs simultaneously or one after the other Ÿ BCVs can be split individually or simultaneously. Ÿ Simultaneous. “Concurrent Restores”, are not allowed Ÿ SnapView is software that runs on the CLA RiiON Storage Processors, and is part of the CLARiiON Replication Software suite of products, which includes SnapView, MirrorView and SAN Copy. SnapView can be used to make point in time (PIT) copies in 2 different ways – Clones, also called BCVs or Business Continuity Volumes, are full copies, whereas Snapshots use a pointer-based mechanism. Full copies are covered later, when we look at Symmetrix TimeFinder; SnapView Snapshots will be covered here. The generic pointer-based mechanism has been discussed in a previous section, so we’ll concentrate on SnapView here. Snapshots require a save area, called the Reserved LUN Pool. The ‘Reserved’ part of the name implies that the LUNs are reserved for use by CLARiiON software, and can therefore not be assigned to a host. LUNs which cannot be assigned to a host are known as private LUNs in the CLA RiiON environment.
  3. 3. To keep the number of pointers, and therefore the pointer map, at a reasonable size, SnapView divides the LUN to be snapped, called a Source LUN, into areas of 64 kB in size. Each of these areas is known as a chunk. Any change to data inside a chunk will cause that chunk to be written to the Reserved LUN Pool, if it is being modified for the first time. The 64 kB copied from the Source LUN must fit into a 64 kB area in the Reserved LUN, so Reserved LUNs are also divided into chunks for tracking purposes. The next 2 slides show more detail on the Reserved LUN Pool, and allocation of Reserved LUNs to a Source LUN. The CLARiiON storage system must be configured with a Reserved LUN Pool in order to use SnapView Snapshot features. The Reserved LUN Pool consists of 2 parts: LUNs for use by SPA and LUNs for use by SPB. Each of those parts is made up of one or more Reserved LUNs. The LUNs used are bound in the normal manner. However, they are not placed in storage groups and allocated to hosts, they are used internally by the storage system software. These are known as private LUNs because they cannot be used, or seen, by attached hosts. Like any LUN, a Reserved LUN will be owned by only one SP at any time and they may be trespassed if the need should arise (i.e., if an SP should fail). Just as each storage system model has a maximum number of LUNs it will support, each also has a maximum number of LUNs which may be added to the Reserved LUN Pool. The first step in SnapView configuration will usually be the assignment of LUNs to the Reserved LUN Pool. Only then will SnapView Sessions be allowed to start. Remember that as snapable What is Business Continuity? * Business Continuity is the preparation for, response to, and recovery from an application outage that adversely affects business operations. * Business Continuity Solutions addresses systems unavailability, degraded application performance, or unacceptable recovery strategies.
  4. 4. Failures happen; hardware, software, natural disasters, etc. and downtime has a significant impact. the cost is more then just a financial loss. What can we do to avoid downtime or minimize the length of time we are down? EMC offers Business Continuity Solutions that help address common failures or outages: PowerPath: Host to Storage failures and performance bottleneck of a Host Bus Adapter (HBA) TimeFinder: Family of Products: Local Storage Protection (TimeFinder Mirror, Clone or Snap) SRDF: Family of Products: Remote Protection. (SRDF/S, SRDF/A..) Timefinder is a local replication solution that allows you to make copies of data locally. It is an array based local replication solution, runs on EMC Symmetrix Arrays, and it allows make PIT copies of data, so application can run on symm devices, and in the meantime have replicas for multiple purposes, such as backup, testing, reporting, etc. TimeFinder/Mirror (formerly called TimeFinder), has been the industry-leading local replication product since it was first announced in 1997. It is the only local replication product available that creates true mirror images of its source. Because TimeFinder/Mirror business continuance volumes (BCVs) are full physical copies and appear as a mirror of the standard device, they can be used to increase availability by servicing I/O if the source volume and the source volume’s protection are destroyed. It uses this BCVs vols allowing the user to create complete replicas of its original volumes. TimeFinder/Clone is the newest addition to the TimeFinder product family. Originally released as a feature of TimeFinder in Enginuity™ 5x68, TimeFinder/Clone provides significant configuration flexibility because clone copies do not use Symmetrix mirror positions. This option uses any symmetrix device of like size, (it must be of the same size). TimeFinder/Snap TimeFinder/Snap is different from TimeFinder/Clone and TimeFinder/Mirror as it does not actually create a full copy of the source data. The benefit to customers is that they only need to allocate a small percentage of additional capacity to support changes to the source volume. Since it is not a full copy of the data, TimeFinder/Snap creates pointers back to the original source data. It only uses 30% of the space needed for the other Timefinder options, as it uses save devices. When managing Timefinder, the normal option is Solutions Enabler, but it can also be managed from Control Center for example. * Solutions Enabler Management tools: * EMC Control Center – Easy, point-and-click access – Excellent for ad hoc TimeFinder operations * SMC: Symmetrix Management Console – Web-based application for managing the Symmetrix – Works the same as the CLI/A PI – the same rules apply – Makes it easier to perform complex CLI tasks * EMC Replication Manager – Discovers replication environments – Automates replication process – Integrates replication technologies at the application level
  5. 5. * TimeFinder Clone/Base Product – New standard for full -copy – Formerly part of TimeFinder/Mirror – MF SNAP Facility included * TimeFinder/Mirror becomes add-on option – TimeFinder/Mirror recommended for ultra high performance and availability requirements * Existing TimeFinder/Mirror customers “grandfathered” – If on maintenance, will continue to receive TimeFinder/Mirror and TimeFinder/Clone (including MF SNAP) TimeFinder/Mirror allows companies to make more effective use of their most valuable resources by enabling parallel information access, as opposed to traditional sequential information access, thus eliminating the need to do things like quiesce an application for backups. BCV and standard devices should be configured on opposing Front End and Back End Directors for redundant paths. TimeFinder/Mirror Business Continuance is possible due to Business Continuance Volume (BCV) devices. These BCV devices are standard Symmetrix devices that are specially configured to be dynamic mirrors. Each BCV device has its own host address and is configured as a stand-alone device. If you want to use Timefinder mirror, you will need devices with BCV Attribute given. This can be done using ECC, SymCli or SMC. Once we have BCV, usgin TF Controls, we can do an Establish Process. This process will synchronize all data and can be done online. Completed the Establish process, you can do a Split Operation (PIT), this will the point at when the data is completely replicated. Then the replicated data can be used for any purpose. To check the TF mirror status of the replciation, you can do Query operations, that will provide you the percentage of the process running. If you suffer logical corruption or any problem in your original copy of the data, you can do a Restore, of your PIT replica made in the last Split operation. When issuing the split command with ‘- instant’ option, as soon as given back the prompt, you will be able to utilize the replicated copy of the data, but in the meantime, background operations will continue to run.
  6. 6. When a split is initiated for each specified BCV pair in a device group, the following occurs: command validity is checked. For example, the Symmetrix array makes sure that the standard device has an active BCV mirror and that the standard and BCV devices comprise a BCV pair. − Any pending write transactions to the standard device and the BCV device are destaged. − The BCV device is split from the BCV pair. − If the device is a meta device, all meta members are implicitly split as well. − The BCV device state is changed to Ready, enabling host access through its separate address (BCV001). − Operation with the standard device is resumed and any tracks changed from write operations to the standard device are marked. (This is necessary for updating the BCV device if it is reestablished with the same standard device at a later time.) − If the BCV device has any of its own mirrors, the mirrors are synchronized. The instant (-instant) option improves the performance of a typical split operation by performing a quick foreground BCV split. This option can be made the continual default split mode by setting the following: SYMAPI_DEFAULT_BCV_SPLIT_TYPE = INSTANT in file: /var/symapi/config/option or: C:Program FilesEMCsymapiconfigoptions. To remove the instant default option, remove the line entry or comment the line out by using a pound sign (#) at the beginning of the line. This performs an Instant Split across a group of devices using a single Consistent Split command, thus all BCVs in the group are consistent point-in-time copies. It is used to create a consistent point-in-time copy of an entire system, entire database, or any associated set of volumes. It can create consistent splits on remote BCVs through SRDF.
  7. 7. PowerPath-based consistent split executed by the host doing the I/O: * -rdb option * -ppath option I/O is held at the host before the split. ECA-based consistent split can be executed: * By host doing the I/O, as long as there is a dedicated path for a gatekeeper to perform the control * By a control host (no database), in an environment where there are distributed and/or related databases * -cons option I/O held at the Symmetrix until the instant split operation is completed: * Approximately 3 seconds. Available on Solaris, HP-UX, AIX, Tru64, and W2K platforms Since I/O is held at the Symmetrix, ECA can be used to perform consistent splits on BCV pairs across multiple, heterogeneous hosts. There are three types of consistent activation available; each offers a restartable copy on the BCV devices: 1. PowerPath 2. ECA 3. Veritas File System or -vxfs Consistent split using PowerPath Consistent splits using PowerPath can be implemented with an instant (-instant) split where you must also specify either a database or PowerPath device(s) and any pre-action and post-action scripts: To target a database, use the following syntax: symmir -g DgName split –instant -rdb -dbtype DbType [-db DbName] [-preaction Script][-postaction Script] To target the PowerPath standard devices of the group, or just specific PowerPath device name(s) as a target, use the following syntax: symmir -g DgName split –instant -ppath STDDEVS|<PowerPathPdevName...> [-preaction Script][-postaction Script] PowerPath consistent split operations require Version 2.0.1 or higher PowerPath-connected devices on Symmetrix arrays. Through the assistance of PowerPath, a symmir consistent split (supplied with database or PowerPath parameters) initially suspends I/O to the devices that hold the database. This prevents the database application from proceeding. The consistency split command also lets you specify the name of scripts using the -preaction and -postaction script options. The script commands are executed prior to the freeze and after the thaw operation, respectively. TimeFinder/Mirror Restore * During a symmir restore operation, data on the standard is replaced with data from the BCV Volume. * Primary host still has full read/write access to the standard volume * If an application is using the standard volume during a restore, the results would be unpredictable y Applications must be stopped, file systems unmounted, and volume groups deactivated when a restore is initiated Remember that restore is a recovery operation. A pplications should be stopped, files systems unmounted, and VG deactivated before you issue the restore command. You will be able tu utilize your STD Volumes (Original source of data) but you won’t like to do that.
  8. 8. TimeFinder/Mirror Extended Operations The extended BCV operations include protect establish, reverse split, and protected restore. These operations add flexibility to TimeFinder configurations and allow for added protection of gold BCV copies. Protected Restore: A protected restore feature allows the contents of a BCV to remain unchanged during and after a restore operation, even while the BCV and standard are joined. Reverse Split: In a reverse split operation, the direction of data flow between the BCV mirrors is reversed. During a reverse split, the fixed BCV mirror (M2) will refresh the moving mirror (M1) after the split operation. This behavior may be desirable when you need to revert to an older copy of the data that was on the BCV before it was established. Protected BCV Establish: In a 2-way BCV mirror configuration for a normal establish, M2 is fixed and can only be updated from M1 after a split. For a 2-way BCV mirror device for a protected establish, both M1 and M2 move to the standard device mirror set and become instantly synchronized and available for updates from I/O activity on the standard device. By default, TimeFinder can “remember” up to eight BCVs. This means that different BCVs can be established and then split from a standard volume at different times of the day. With the Multi-BCV function, up to eight BCVs will be remembered by the Symmetrix. In other words, a BCV that was split at 4:00 a.m. can be re-established, even though another BCV was established and split at 5:00 a.m. In this way, a user can split and incrementally re-establish volumes throughout the day or night and still keep re-establish times to a minimum. Incremental information can be retained between a STD device and multiple BCV devices, provided the BCV devices have not been paired with different STD devices. Using the environment variable SYMCLI_MAX_BCV_PAIRS, the maximum number of pairs (established or restored) can be adjusted between 1 to 16 BCV devices. TimeFinder/Mirror Concurrent BCVs * Each BCV occupies a mirror position; locally protected R1 Volumes cannot have two BCVs established with them concurrently. * Establish two BCVs with the same standard simultaneously or one after the other * BCVs can be split individually or simultaneously * Simultaneous “Concurrent Restores” are not allowed Concurrent BCVs is a TimeFinder/Mirror feature that allows two BCVs to be simultaneously attached to a standard volume. The BCV pair can be split, providing customers with two copies of the customer’s data. Each BCV can be mounted online and made available for processing. When you establish a BCV device as a mirror of a standard device, that relationship is known as a BCV pair. When you sequentially establish/split/establish a number of BCV devices over time with a specified standard, that is known as a multi-BCV relationship. You can establish two BCV devices (eight when using emulation mode) as concurrent mirrors of a single standard device all within the same symmir command line. This relationship is known as a concurrent BCV Pair. This feature allows you or an application script to instantly generate two synchronized copies of the standard data.
  9. 9. When the two BCVs are split from the standard, the BCV’s hosts can access the data on either BCV. When establishing concurrent BCV pairs, you can either specify the BCVs, or use the -concurrent option to allow the Symmetrix array to select suitable BCV(s) from the available BCV list. To have this concurrent BCV’s option, you must have at least 3 copies, and remember that you can only restore from one of the BCVs at the time. And if SRDF involved, the 3rd BCV will be on the remote Symmetrix Array. Querying Concurrent BCV Status * When concurrent BCVs are part of a device group, use the –multi option as part of the query command * Invalid track tables are maintained - future concurrent incremental establish operations are possible: symmir –g <testdg1> query –multi * To evaluate the background progress after initiating a split operation: symmir –g <testdg1> query –multi –bg * To verify the status of concurrent BCV pairs: symmir –g <testdg1> verify –concurrent To query the state of a split action on multi-BCVs or concurrent BCVs in a group prod, enter the following command. Note the use of the –multi flag. symmir -g <testdg1> query –multi TimeFinder/Mirror Host Considerations * While established, BCV is a mirror to the STD device and is not accessible by the host * All access to a BCV must be stopped before it is established – Stop application, un-mount filesystem, and deactivate volume group * Any attempt to access the BCV device while it is established results in an I/O error – inq command will hang and timeout – Activating a volume group or mounting a filesystem that resides on a BCV while the BCV is established results in an I/O error * If the host is re-booted or reconfigured while the BCV is established, the BCV is not detected and may cause it to be removed from the host device configuration TimeFinder/Mirror provides host-transparent, "splittable" mirrors that can be used in a variety of ways to enhance application availability and reliability. On the BCV host side, TimeFinder/Mirror operations are not transparent. When the BCV is established with the standard volume, it becomes unavailable to the BCV host system. A ny attempt to access the BCV will fail. If the host is re-booted or reconfigured while the BCV is established, the BCV may not be detected and may cause it to be removed from the host device configuration. IBM addresses established BCV issues by automatically configuring the BCV as a Defined device in the AIX ODM. When a reboot occurs, the BCV is not automatically configured. BCV devices that are not established can be configured during reboot with the EMC command mkbcv. BCV devices that are established can be made available with mkbcv after they have been split. * When a BCV is split, it can be used by the same host or by a different host * There are LVM issues when both BCV and Standard device are accessed from same host • UNIX Systems: Duplicate Physical Volume Ids and Volume Group Ids • Windows 2003: Duplication of disk signatures Note: Dynamic disk requires a second host and Volume configuration information. A split BCV is an identical copy of the volume it was dynamically mirrored to. When accessing the BCV on the same host as it’s mirror duplicate, volume information must be changed.
  10. 10. Multiple Host Environment * When a Standard volume and BCV are split, a different host can easily access the volume group by “importing” the volume group – Unix - export/importing – Windows - C:diskmgmt.msc * There is no conflict with PVIDs and VGDA information because each host only accesses one copy of the data * There is also a performance benefit when BC applications use a copy of the data on a non- production host. Note – PVID = Physical Vol ID –VGDA = Volume Group Descriptor Area When accessing a BCV on a second host, there are no duplicate IDs to consider. The device can simply be brought online using standard host controls. 1. symmir establish # symmir –g <dgname> establis # symmir –g <dgname> query 2. symmir split # symmir –g <dgname> split # symmir –g <dgname> query 3. Mount the file system on Host B From Host B 4. Start your application on Host B This slide shows the basic steps to access a BCV on a secondary host in a TimeFinder environment. It performs a “clean” split operation which requires no form of recovery from the application when restarted at the secondary host. It does not take into account the use of consistent split that would perform a freeze/thaw on the application to allow for a consistent point-in-time copy of data at the secondary host, but could require a level of recovery. Host Considerations: Same Host * When the BCV and standard volumes are accessed by the same host, there is a conflict – The Standard and BCV volumes have identical PVIDs and VGDA information – Host expects the PVID and VGDA to be unique * Additional steps must be taken before the host can use the BCV and standard device. Accessing a BCV on the same host as the original production data requires addressing duplicate disk identifiers in order to access the device. Each operating system has unique methods for addressing duplicate identifiers. The SYMCLI TimeFinder/Mirror component extends the basic SYMCLI command set to include TimeFinder/Mirror or “Business Continuance Commands” that allow you to perform control operations on BCV device pairs within a TimeFinder/Mirror environment. The symmir command allows you to perform a wide spectrum of monitor and control operations on standard/BCV device pairs within a TimeFinder/Mirror environment. The symbcv command allows you to perform support operations on Symmetrix BCV devices.
  11. 11. The Device Group represented in the diagram is currently in a “Split” state. The BCV devices are now accessible via a target host. The data on the BCV devices represents a point in time copy. When the BCV’s are split, the source or production host will continue to read and write to its source devices. This will cause an out of sync state between the standards and all the BCV pairs within the device group. The changes made on the standard devices will be tracked for incremental synchronization at a later time. Identify Accessible Standard / BCV Volumes • Syminq: Displays volume type and can be used to identify accessible BCV volumes. The syminq command can be used to obtain SCSI disk device information for one or all locally attached physical devices. Options can be specified to control what data is returned and its presentation as specified in the syminq manpage, which can be found in the EMC Solutions Enabler Symmetrix CLI Command Reference guide. It should be noted here that data returned from issuing any syminq command is not stored in the configuration database or file. Identify BCV Volumes * C:symbcv list pd displays summary information about all BCV volumes accessible to your host * C:symbcv list dev displays summary information about all BCV volumes in the attached Symmetrix. * A host “does not need” access to a BCV in order to perform TimeFinder operations.
  12. 12. Configuration and status information is stored in the Symmetrix configuration database file for each device on every Symmetrix array, including BCV devices. You can find all BCV devices on a Symmetrix array and view their physical and Symmetrix device names. You can also display details about the BCV devices, including the BCV device name, Symmetrix device name of the paired standard device, number of invalid tracks for both the BCV device and standard device, and the BCV pair state. To list all BCV devices that are visible to your host, enter: symbcv list pd To list all BCV devices, regardless of whether they are visible to your host, enter: symbcv list dev Device Group Operations * Related devices are grouped into Device Groups * BCV devices are associated with Device Groups * All devices in a Device Group must be in the same Symmetrix * All devices in a group must be the same type (RDF1, RDF2, Regular) * By default, relationships of one STD device with up to eight BCV devices can be maintained. (increased up to sixteen - SYMCLI_MAX_BCV_PAIRS) * A device can belong to multiple Device Groups as of SE 6.3 - (Provided the SYMAPI_ALLOW_DEV_IN_MULT_GRPS parameter is enabled) A device group is a logical grouping of Symmetrix volumes. There are three types of device groups: regular, rdf1, and rdf2. A device group with type regular cannot contain RDF volumes. The device group definition will be stored in a file referred to as “SYMAPI database” on the host where the symdg create command was executed. Users can add regular devices and associate BCV devices with a device group by using either the physical device name, or the Symmetrix device name. The above diagram is a review of what we just created. The TimeFinder Device Group contains two standard devices and two BCV devices. The device group name is “Testdg1”. Using the syminq and symbcv commands, the user has selected symm standard devices 0021 and 0022 and BCV devices 0061 and 0062 when creating this Device Group. When creating device groups for any production application, it is recommended that one documents the environment. With dozens of Device Groups, each containing many devices, the environment can become confusing. Also, careful consideration should be given to any production Device Group name. A Device Group name should represent what data is being mirrored.
  13. 13. Display SYMCLI Device Groups * symdg show displays detailed information about a device group * Group membership * Associated BCV devices The symdg show <Device Group> command is a quick way to show what devices belong to which Device Group. Outputting the results of this command to a file can be used to help create and maintain documentation for any production environment. symmir establish: All Devices * Establishes a BCV mirror to each volume in a device group * Default is to perform incremental establish * -full must be specified the first time a BCV is established to a volume * -exact assigns BCVs in order associated with DG After configuration and initialization of a Symmetrix array, BCV devices contain no data. The BCV devices, like standard devices, have unique host addresses and are online and ready to the hosts to which they are connected. The full establish must be used the first time the standard devices are paired with BCV devices. Optionally, you can target devices in a device group, composite group, or device file: • symmir -g DgName -full establish • symmir -g CgName -full establish • symmir -f FileName -full establish To initiate a full establish on all the BCV pairs in the testdg1 device group, enter: symmir -g testdg1 -full establish To initiate a full establish on more than one BCV pair (list) in the testdg1 device group with one command, enter: symmir -g testdg1 -full establish DEV001 BCV ld BCV001 DEV002 BCV ld BCV002 • to show full “Synchronization” has been achieved. You can perform a query (symmir query) to determine the state of a BCV pair, or all BCV pairs, in the device group. The query is sent via the gatekeeper device to the Symmetrix array, returning with information about the state of the BCV pair(s). Because the Device Group is in an “Established” state, any “Write” activity to the standards will mirror to its BCV pair. During this “Establish” state, the BCV devices are “Not Ready” to any target host.
  14. 14. The verify option used with the –synched flag will enable script to confirm “synchronization”. The following command verifies whether the BCV device pair(s) are only in the Synchronized state. example C:symmir -g testdg1 -synched verify symmir establish: selected devices * Allows you to override existing device pairing * Default is to perform incremental establish * -full must be specified the first time a BCV is established to a volume. When a full establish is initiated for each specified BCV pair in a device group: * Command validity is checked. For example, the Symmetrix array makes sure both the standard device and BCV device are the same size; the device specified as BCV has the BCV attribute; and the standard device does not already have a BCV device assigned to it. * If the standard device is a meta head device, then the BCV must also share the same meta device properties. All meta members will be implicitly established along with the meta head device. * The BCV device is set as Not Ready to the host. * The BCV device is assigned as the next available mirror of the standard device. * The contents of the standard device are copied to the BCV. To initiate a full establish on one BCV pair, (DEV001 to Sym DEV 0062) in the testdg1 device group, enter: symmir -g testdf -full establish DEV001 BCV dev 0062 The previous slide shows that within a Device Group, a user can select specific device pairs to mirror. In the above example, the storage administrator has selected a full mirror copy of device 0021 to device 0062. Careful consideration needs to be applied when performing this TimeFinder/Mirror functionality. Understanding the application that is being mirrored is a must. In the event that both BCV devices contain a database application, replicating one device at a different time would cause the mirrored environment to be out of sync from each other. If one device contains database system files and the second device contains redo logs, mirroring the two devices independently will result in out of sync database. Storage and A pplication administrators must fully understanding the application being replicated. To be safe, always create a TimeFinder Mirror replication environment on a “Test” platform before migrating to production.
  15. 15. symmir query * Setting the SYMCLI_DG variable eliminates having to specify the Device Group using the -g flag * The –i (Interval = 5) , -c (Count = 10) options will query the state of the Device Group (Testdg1) ten times every five seconds. Setting the SymCLI device group system variable (SYMCLI_DG) eliminates having to use the device group name. Example c:Set Symcli_dg=testdg1 c:Symmir –full establish –nop c:symmir -synched verify The above symmir query command will display the status of the full establish between Standard Device 0021 and BCV Device 0062. With the –i (interval) and –c (count) flags invoked, the query command will be displayed ten times, every five seconds. Also notice that the –g <device group name> was not included in the above query/verify commands. symmir split * All devices or specific devices within a device group can be split with a single operation. The result of a split, changes the BCV device from “Not Ready” to “Ready” to the target host. After an establish operation, the standard device and BCV mirrors are synchronized and the BCV device becomes a mirror copy of the standard device. You can split the paired devices to where each holds separate valid copies of the data, but will no longer remain synchronized to changes when they occur. The target host can now use the BCV device. When a split is initiated for each specified BCV pair in a device group, the following occurs: * Command validity is checked. For example, the Symmetrix array makes sure the standard device has an active BCV mirror and the standard and BCV devices comprise a BCV pair. * I/O is suspended to the standard device until the split operation completes. * Any pending write transactions to the standard device and BCV device are destaged. * The BCV device is split from the BCV pair. * The BCV device state is changed to Ready, enabling host access through its separate address.
  16. 16. * Operation with the standard device is resumed and any tracks changed from write operations to the standard device are marked. (This is necessary for updating the BCV device if it is re- established with the same standard device at a later time.) * If the BCV device has any of its own mirrors, the mirrors are synchronized. symmir –g testdg1 split Results in a split condition between all standard devices and all BCV devices within a Device Group symmir –g testdg1 split -consistent Results in a consistent split condition between all standard devices and all BCV devices within a Device Group Once the establish operation synchronizes the standard devices to its BCV pairs, one can issue a symmir split. The split will result in the BCV maintaining a point in time copy of its standard pair. Splitting the paired devices results into each holding separate valid copies of the data, but will no longer remain synchronized to changes when they occur. The BCV Devices can now be mounted to the Target Host. symmir restore * Data is restored from BCV to Standard Volume * Default is incremental restore. Specify -full if required The incremental restore process accomplishes the same thing as the restore, but with a major time- saving exception. The BCV device copies only new data that was updated on the BCV device while the BCV pair was split. Any changed tracks on the standard device are also overwritten by the data on corresponding tracks on the BCV device. This maximizes the efficiency of the synchronization process. This process is useful if the results from running a new application on the BCV device were desirable, and the user wants to port the data and new application to the standard device. To initiate an incremental restore on all the BCV pairs in the testdg1 device group, enter: symmir -g testdg1 restore symmir –g testdg1 –full restore Results in a full track for track copy from the BCV to it’s Standard pair – within Device Group - (Testdg1) Like the full establish operation, a full restore operation copies the entire contents of the BCV devices to the standard device.
  17. 17. Multi-BCV’s Example * Identify two Regular Volumes and four BCVs * Create two SYMCLI Device Groups of type Regular - AMdg and PMdg * Add two Regular Volumes to AMdg. Associate first two BCVs in Amdg * Associate the next two BCVs with PMdg (as yet does not have any Regular Volumes added) * Full establish AMdg, verify synchronization, then split AMdg * Move Regular Volumes to PMdg, full establish, verify synchronization Let’s discuss a specific business example where Multi-BCV’s can be used. The above “Multi-BCV” example has been set up to enable application replication from the same standard devices to two BCV sets. Both AM and PM device groups will enable the creation of “test” and or “development” environments for the target host. The symld “moveall” command enables a set of production standard devices to be moved from one device group to another, giving the user production copies at specific points in time. Another way of accomplishing this would be to enable BCV’s to become members of multiple device groups. Associating a BCV device with multiple device groups - By default, a BCV device cannot be associated with more than one device group at the same time when you are using one SYMCLI configuration database file. However, you can change this default behavior by enabling the SYMAPI_ALLOW_DEV_IN_MULT_GRPS parameter in the options file. The following page identifies the symcli command set for the above business example. 1. Identify two regular volume and four BCV’s 2. C:symdg -type regular create AMdg 3. C:symdg -type regular create PMdg 4. C:symld -g AMdg addall dev -range 092:093 5. C:symbcv -g AMdg associateall dev -range 056:057 6. C:symbcv -g PMdg associateall dev -range 058:059 7. c:symmir -g AMdg establish -full -exact 8. c:symmir -g AMdg query All devices in group 'AMdg' are in the 'Synchronized' state 9. c:symmir -g AMdg split -instant –noprompt Move the standard devices to PMdg, - perform a full establish, and verify synchronization. 10. c:symld -g AMdg moveall PMdg 11. c:symmir -g PMdg est -full –exact 12. c:symmir -g PMdg split -instant –noprompt 13. c:symld -g PMdg moveall Amdg 14. c:symmir -g AMdg restore 15. c:symmir -g AMdg split –noprompt TimeFinder/Clones * A TimeFinder Clone is an instant point-in-time copy of a Symmetrix Device – Copying can be immediate or deferred (copy on access) – Copying can be controlled by copy sessions – Copy sessions are maintained on the Symmetrix unit – Copy sessions can be: Created, Recreated, Restored, Activated, Queried, Listed, and Terminated using the symclone command. – Data can be copied from a single source device to as many as sixteen target devices, with automatic background copying for up to eight target devices simultaneously – Does not take-up a “Mirror” position – Remote clone is supported with –rdf When creating a clone image, it is not necessary to first perform a full establish operation as you would with traditional TimeFinder BCVs. Upon activation of the cloned image, it is fully read/write enabled; data is copied in the background as it is accessed. The Symmetrix array is currently limited to sixteen sessions per source device, which can be used for TimeFinder Mirror, Clone or Snap operations. This limits the number of available clone copies that can be created. A total of sixteen concurrent CopyOnAccess copy sessions can be created from a standard device.
  18. 18. TimeFinder/Clone Operations * Create – Create relationship between standard and Clone * Activate – Clone is now active and available immediately for read/write access – Production I/O is processed against standard * Re-Create – Clone is re-attached to Standard for new point-in-time copy (incremental/differential) * Establish – Re-create and activate * Restore – Re-attached to Standard and incremental or full restore is performed * Split – You can use the symclone split command to split a clone device pair that is in the Restored state. This command requires Enginuity Version 5671 or later * Terminate The create action defines the copy session requirements and sets the track protection bitmap on the source device to detect which tracks are being accessed by the target host or written to by the source host. The target device is made Not Ready to its host and placed on hold status for copy session activity. This prevents other control operations from using the device. The activate action makes the clone ready to the host. It also starts one of the background copying processes. The process, Copy-On-Access or Full Copy, depends on the argument used when the clone session was created. The recreate command allows you to incrementally copy all subsequent changes made to the source device. In other words, it allows you to refresh the contents of the clone with new contents of the source since the clone session has been activated. The restore action restores contents of the clone volume to a restore target. The establish operation creates and then immediately activates a clone session with a single command. The terminate action terminates a source clone relationship. TimeFinder/Clone - Options with Creation * CopyOnAccess – Default (Prior to 72 code) – Only modified tracks are copied to clone volume after activation * Full Device Copy – Full copy in the background starts after activation * Precopy – Full copy in the background starts after creation * Differential – Used with Full Copy or Precopy (implied Full Copy by default) – Required if recreate clone session is planned – Required if incremental restore is planned * Symclone Recreate Before Copied – No need to wait for a clone copy to complete, before activating a new point-in-time with recreate – Symclone recreate or establish is now permitted while the session is in CopyInProg mode – Recreate is a differential copy (modified tracks copied /unmodified not) * CopyOnWrite – Default behavior change utilizes CopyOnWrite instead of CopyOnAccess CopyOnAccess: By default, when a copy session is finally activated, the device pair state will be CopyOnAccess. This means that after activating the copy session, only those tracks that have been written to the source or written/read from the target, will be copied to the target device. A full data copy to the target device will not occur unless all of device tracks are accessed or written to while participating in the active session. CopyOnWrite: Before SE 6.4, the data is copied to the target device when there is change of data on the source or target. But it also copies the data even when the data is read from the target which is unnecessary since the data is not changed and there is no need to copy the data . This impacts the performance since even read operation to the target device destages the data. The symclone status was CopyOnAccess. One can modify this default device pair state to CopyOnWrite by setting the following parameter in the options file to ENABLE.SYMAPI_CLONE_COPY_ON_WRITE = ENABLE | DISABLE Once CopyOnWrite as been enabled and activated, all reads will be handled from the source device and writes to the source device or target device during the active copy session will result in the data being copied to a target device. Full Device Copy Option: When the copy session is eventually activated, data begins background copying so that a full copy of the data will become available on the target device. Precopy Option: The -precopy option can be used with the create argument to start copying tracks in the background, before the clone session is activated.
  19. 19. Differential Option: This option creates an SDDF (Symmetrix Data Differential Facility) session for maintaining changed track information. Creating a differential clone session automatically implies a Full Device Copy. Recreate Before Copied: This feature allows users to recreate the symclone session before the copy finishes. In prior releases the customer had a problem if there was change in the SRC after the initial clone session. The customer had to wait until the previous copy finished in order to make differential changes. Aborting the original session with terminate would destroy the differential information and require a full copy. TimeFinder/Clone - Actions and States of a Session • A restore operation is permitted only when a clone is in a “copied” state The diagram depicts flow of actions and states of a clone session. The Split action when in a Restored state is new, as of Solutions Enabler 6.3. TimeFinder/Clone - Create a Copy Session * To create a CopyOnAccess session: symclone … create – To create a “CopyOnAccess” Clone session: when activated tracks that have been written to the source or written/read from the target will be copied to the target device * To create a Full “Background Copy” session: symclone … create … –copy – To create a full “copy” – when activated will invoke a background track for track copy of the source to the target clone device. * To create a Precopy session: symclone … create … –precopy – To create a –precopy which enable track for track copy from the source to the clone device before the clone session is activated * To create a Differential clone session: symclone … create … -differential – Creating a differential clone session automatically implies a Full Device Copy The symclone create command: * Makes the target not ready (NR) to its host * Creates a copy session * Sets up the track protection bitmap to provide user access to data on the target as soon as the clone pair is activated * Puts a hold on the target to prevent other control operations (for example, TimeFinder operations), or a copy over previously copied data * The -copy option makes an immediate copy of the entire source to the target. Copying begins upon issuing the symclone activate command * -precopy starts the copy immediately after the session has been created * -differential allows a clone session to be recreated and an incremental restore to be performed
  20. 20. TimeFinder/Clone - Multiple Clone Copies Up to 16 clone copies of a standard source device can be created. The Symmetrix array is currently limited to 16 sessions per source device, which can be used for TimeFinder Mirror, Clone, Snap, or SDDF (Symmetrix Differential Data Facility) operations. This limits the number of available Clone copies that can be created. A total of 16 concurrent CopyOnAccess copy sessions can be created from a standard device (sessions created without using the -copy option). However, this number is decremented for each current TimeFinder Mirror, Clone, Snap, and SDDF session. For example, if you have a standard device with two paired BCV devices, you can only create up to 14 copy sessions for that standard device. Copy sessions created using the -copy option to create full data copies are limited to eight concurrent sessions, with up to an additional eight CopyOnAccess sessions, for a total of sixteen sessions. Note: The use of -differential uses up an additional SDDF session for a maximum of eight (8) copies. Major Activation Options * Not Ready – The clone volume is placed in NR state: symclone –g testdg2 activate DEV001 sym dev 0063 –not_ready * Consistent – Create a consistent image of a heterogeneous database environment: symclone –g testdg2 activate –consistent Three methods to execute Consistent Activation: * By specifying -ppath and PowerPath STD devices that hold the database * By specifying –consistent * By specifying –vxfs for VxFS filesystem (Solaris and HP only) Not Ready Option: The -not_ready option can be used with the activate action to cause the target device to remain not ready to its host. The copy session will be activated and the target device will be placed in the Not Ready state. The Clone copy can later be read/write enabled to the host using the symld ready command. Consistent Option: The symclone activate command can be used with the -consistent option to invoke the Enginuity Consistency Assist (ECA) feature. This feature can be used to create Clone copies that are consistent with the database up to the point in time that the activation occurs. The feature suspends writes to the source devices during the activation. When the activation has completed, writes are resumed and the target device contains a consistent production database copy of the source device at the time of activation. A dditional details for ECA technology are discussed in the Consistency Technology “SRDF Solutions” module. Refer to EMC Solutions Enabler Symmetrix CLI Version 6.5 COMMAND REFERENCE, P/N 300- 002-181, REV A05 for the complete option list.
  21. 21. Multiple Clone Copies of a BCV Clone sessions can use BCV as a source volume. This helps isolate production volumes from clone I/O during the copy sessions. The BCV background split must be completed before a clone session creation. Establish a Copy Session * The establish command combines create/recreate and activate into a single command – Makes behavior more similar to TimeFinder/Mirror * Execute recreate followed by activate . symclone establish * Execute create followed by activate . symclone –full establish * Activate options (-consistent, -preaction, etc.), are performed at activate (not create) time . symclone –full establish –consistent The symclone establish command sets the target device to Not Ready for a short time. Therefore, you may want to unmount the target volume before issuing the command. An establish operation creates and then activates a new clone session. The clone session created by the establish operation is by default equivalent to a session created with –copy and –differential options. The establish operation can also be performed on an existing differential clone session. In which case, the operation performs recreate and activate operations on the clone session. Terminate a Copy Session * The symclone terminate command: – Stops a copy session – Removes any hold on the target – Deletes copy session information from the Symmetrix unit * Normal termination is possible whenever a copy pair is in the Created, Copied, CopyOnAccess, Split or Restore state * The syntax is: . symclone –g testdg2 terminate DEV001 sym dev 0063 Terminating a copy session deletes the pairing information in the Symmetrix array and removes any hold on the target device. Terminating a session while the device pairs are in the CopyOnAccess or CopyInProg state causes the session to end. If the application has not finished accessing all of the data, the target copy is not a full copy. The symclone terminate command is allowed for all TimeFinder pair states. A created / activated copy session may be terminated, but the data on the target device becomes invalid (whether or not data was actually copied to the target). If the state is CopyInProg, then the -symforce option must be applied to terminate the session. This also leaves the target copy as an incomplete copy.
  22. 22. Restore from a TimeFinder/Clone symclone –g testdg2 restore DEV001 sym dev 0063 * Restore can be done to other standards or the source volume * Session must be created with –copy or –precopy * Session must be activated * Wait until the clone is in a “Copied” state * Issue a symclone restore command You can use the symclone restore command to copy target data to another device (full restore), or back to the original source device (incremental restore). In the case of a full restore (-full), the original session terminates and a copy session to the target of the restore starts. In the case of an incremental restore, the original session terminates and an incremental copy session back to the original source device starts. To support this operation, the session must have been created with the -differential option and the device must be in a fully copied state. TimeFinder/Clone Operations Using the “symclone list” command will show all the clone session in the Symmetrix. The above shows a clone session between device 0023 and 0063 has been created but is currently in a non-active state (Created). Also, a clone session between device 0023 and 0064 has been created and activated (CopyOnAccess). The symclone list command: The symclone query command:
  23. 23. Above is the symclone query on device group testdg1 showing the clone relationship between BCV001, BCV002 to DEV001. One clone pair is in a “CopyOnAccess” state where the other is in a “Created” state. The following command will active the DEV001 to BCV001 pair: C: symclone –g testdg2 activate DEV001 sym dev 0063 -nop The above diagram represents the SYMCLI command set which first creates the device group (testdg2). Next the devices are added t the device group. Next a clone session is created than activated. The last command is querying the state of the device group which shows that an active clone session between devices 0023 and 0064 is in a “CopyOnAccess” state. Create the symclone Session The symclone create action defines the clone copy session requirements and sets the track protection bitmap on the source device to detect which tracks are being accessed by the target host or written to by the source host. The target device is made Not Ready to its host and placed on hold status for clone copy session activity. This prevents other control operations from using the device. The device pair state transitions from CreateInProgress to Created when complete. The clone copy does not become accessible to its host until the copy session is activated. Check the symclone create Session When performing a symclone query on testdg2, notice that the background copy is active for this pair. This is known as a “PreCopy” state.
  24. 24. With Enginuity Version 5671 and later, you can use the -PreCopy option with the create argument to start copying tracks in the background, before activating the copy session. This allows the early movement of data before the point-in-time clone copy is established. Activate the symclone Session This activates the copy operation from the source device to the target device. Activating the copy session places the target device in the Read/Write state and initiates the -precopy option. (Refer to the previous slide where the copy session was created with the –precopy flag). The target host can access the cloned data and has access to data on the source host until the copy session is terminated. Note: Cloned data is made available as a point-in-time copy at the time of activation and not at the time that the session was created. Performing the symclone –g testdg2 query command currently shows that “The background copy setting is active for this pair”, “The Target device is currently associated with this group”, “This Clone session is currently a “PreCopy” state ” and “The pre-copy operation has not completed one cycle”.
  25. 25. Query Clone Session State Terminating the symclone Session Terminating a copy session deletes the pairing information in the Symmetrix array and removes any hold on the target device. Terminating a session while the device pairs are in the CopyOnAccess or CopyInProg state causes the session to end. If the application has not finished accessing all of the data, the target copy is not a full copy. The symclone terminate command is allowed for all TimeFinder/Clone pair states. Note: A created and activated copy session may be terminated, but the data on the target device is not valid unless the state had previously been COPIED.
  26. 26. The symclone create –differential Flag Subsequent cloning to the same target can be performed as differential copying. One can use the –differential option the first time you clone a full copy from the source to the target. All subsequent copying during that copy session automatically becomes incremental (that is, copying only new writes to the source device). A differential or incremental clone operation copies only those device tracks that have changed since the initial full clone was performed. To do this, however, the copy session that existed for the full clone must still exist. You must also set up the differential clone during a full clone operation. The –differential option, therefore, must be used here with the –copy (or –precopy) option. For example: C:symclone –g testdg2 create DEV001 sym dev 0063 –copy –differential The –differential option creates an SDDF session for the source and target. Using the -differential option, utilizes two SDDF sessions. Query after Creation (-differential) Notice this clone session is a “differential” copy. With Enginuity Version 5671 and later, subsequent cloning to the same target can be performed as differential copying. You can use the –differential option the first time you create a clone copy session. All subsequent copying during that copy session automatically becomes incremental.
  27. 27. The symclone activate –consistent The symclone activate command can be used with the -consistent option to invoke the Enginuity Consistency Assist (ECA) feature. This feature can be used to create clone copies that are consistent with the database up to the point in time that the activation occurs. The feature suspends writes to the source devices during the activation. When the activation has completed, writes are resumed and the target device contains a consistent production database copy of the source device at the time of activation. The symclone Recreate Once a clone device is fully copied, the symclone recreate command allows you to incrementally copy all subsequent changes made to the source device (made after the point-in-time copy initiated) to the target device. To use this feature, the copy session must have been created with either the -copy or -precopy option, and the - differential option. In addition, the session must have been activated to establish the new point-in-time copy and to initiate the copy of the changed data. While in the Recreated state, the target device remains Not Ready to the host.
  28. 28. Query after Recreating Notice the state of the clone session currently in a “Recreated” state. At this point, the target device is not available to the target host. With Enginuity Version 5671 and later, once a clone device is fully copied, you can use the symclone recreate command to incrementally copy all subsequent changes made to the source device (made after the point-in-time copy initiated) to the target device. The symclone Establish To create and then immediately activate a copy session with a single command, you can use the symclone establish command. Note: The symclone establish command sets the target device to Not Ready for a short time. Therefore, you may want to unmount the target host before issuing the command.
  29. 29. Query of Multi Clone Note – The “–multi” flag is required to see all the clone sessions. When using the query argument you can display the state of all devices involved in the clone operation by including the - multi option or you can use the verify argument to verify that the data has been fully copied to the target: c:symclone -g testdg2 query –multi symclone Restore You can use the symclone restore command to copy target data to another device (full restore), or back to the original source device (incremental restore). In the case of a full restore (-full), the original session terminates and a copy session to the target of the restore starts. In the case of an incremental restore, the original session terminates and an incremental copy session back to the original source device starts. To support this operation, the session must have been created with the -differential option and the device must be in a fully copied state.
  30. 30. Query after Restore For example, to fully restore data from the original target device (BCV001) created in the example above: symclone -g testdg2 restore -full DEV001 sym ld BCV001 Note: When constructing a symclone restore command, the device receiving the data always appears first in the command, followed by the device from which the data is being copied. TimeFinder/Clone Emulation Mode * Emulation mode allows customers to leverage existing TimeFinder Mirror scripts – symmir commands are converted to symclone commands * Enables – Faster introduction of TimeFinder Clone into existing TimeFinder Mirror environments – Simplified conversion to RAID 5 protected BCVs * Support for all current TimeFinder Clone capabilities – Symmetrix mirror position not required – Immediately read and write accessible – NOCOPY option – TimeFinder Consistency Group support Starting with Enginuity™ Version 5671, TimeFinder supports the ability to map TimeFinder commands to Clone operations. With this feature, TimeFinder commands execute Clone operations. This feature is enabled by setting the environment variable: SYMCLI_CLONE_EMULATION to ENABLED, or if a RAID 5 BCV is encountered. * SE 6.0 added capabilities to match the missing TimeFinder/Mirror functionality: − Recreate and -differential (Ref Note – Page 10 - The use of -differential uses up an additional SRDF session for a maximum of 8 copies) to match the incremental capabilities. − Establish to remove the separation of activate and create − Copy mode -precopy to with the -cycled verify state to simulate the TimeFinder synchronization before split. − Restore to explicitly match restore support including incremental restore − Remote RDF operations for DGs, CGs and the Device File * Only Clones: − Can be protected using any type of supported protection scheme including RAID5 − Can be put into a NOCOPY mode fully suspending "synchronization" I/Os.
  31. 31. Operations Mappings: TimeFinder/Mirror to TimeFinder/Clone The following limitations apply to this feature: * The TimeFinder reverse split feature is not allowed * Restores are always protected restores * Incremental Restore is only accepted if all tracks were originally copied from the source prior to the restore taking place * The SYMAPI_DEFAULT_BCV_SPLIT_TYPE, SYMAPI_DEFAULT_BCV_RESTORE_TYPE, SYMAPI_DEFAULT_BCV_ESTABLISH_TYPE option file settings are ignored. * Any Snap or Clone operations to an emulated device are rejected * The maximum number of BCVs that can be incrementally established with a Standard device is 8, instead of the 16 allowed by TimeFinder. SYMCLI_MAX_BCV_PAIRS can, at most, be eight * The BCV states Split-Before-Restore and Split-Before-Sync are not valid states for an emulation device. In both cases, a forced Split completes the operation. Clone Emulation in Action Setting the “SYMCLI_CLONE_EMULATION” variable The device 0063 is a BCV, which automatically triggers a TF/clone emulation. The device is paired with a standard as follows: symmir -g testdg1 establish DEV001 sym dev 0063 –full -nop 'Full Establish' operation execution is in progress for device ‘DEV001‘ paired with BCV device ‘0063' in device group ‘testdg1'. Please wait... 'Full Establish' operation successfully initiated for device ‘DEV001‘ in group ‘testdg1' paired with BCV device ‘0063'. The translation of TimeFinder / Mirror to TimeFinder / Clone command is done by the Symmetrix. The only way that users know the emulation is in effect is to perform a symdev show on the device, as displayed on this slide.
  32. 32. TimeFinder/Clone or TimeFinder/Mirror? Clone advantages include: * Relieving the four-mirror limit on the STD device (since clones do not require mirror positions). Since no positions are taken up by BCVs, more are free for SRDF configurations, including SRDF/Star and Concurrent SRDF. * Using more than two Clone Copies Concurrently. Today we are limited by the mirror positions available and number of dynamic mirrors a device can have. Using clone emulation mode, we allow up to eight concurrent BCV devices to be established to the STD. * Using more than one protected BCV establish. Today, a protected BCV establish (for BCV devices that are mirrored) moves both mirrors of the BCV device to the STD. This uses up the mirror positions in a way that only a single BCV device can be "protected established" to the STD. Using clone emulation mode, the mirror restrictions are removed and you can perform a protected. BCV establish with more BCV devices. * For the sole purpose of using RAID-5 BCVs. * TimeFinder/Mirrors strengths are higher performance and availability needs. TimeFinder Command Line Interface:
  33. 33. TimeFinder/Snap for Symmetrix DMX * Snapshots create “logical” point-in-time images of a source volume * Requires only a fraction of the source volume’s capacity * Up to 15 snapshots can be created from a source volume and are available immediately * Setting the SymCli_Multi_Virtual_snap variable to enabled will provide capability of up to 128 snaps session * Complements TimeFinder and provides unmatched replication flexibility TimeFinder Snap creates space-saving, logical point-in-time images or “snapshots.” The snapshots are not a full copies of data; they are logical images of the original information, based on the time the snapshot was created. It’s simply a view into the data. A set of pointers to the source volume data tracks is instantly created upon activation of the snapshot. This set of pointers is addressed as a logical volume and is made accessible to a secondary host that uses the point-in-time image of the underlying data. Some documents may indicate that the maximum copy session is sixteen. The fact is that users can create up to fifteen copy sessions and the Symmetrix reserves one session for restoring purpose. Solutions Enabler supports up to 128 snaps from a source device. This support requires that you enable the following SYMCLI environment variable: SYMCLI_MULTI_VIRTUAL_SNAP = ENABLED Snap Operations Overview This slide illustrates a virtual copy session where the controlling host creates a set of pointers to reference where the original data resides. The pointers reside on the Virtual Device. TimeFinder/Snap functionality is managed via copy sessions, which pair the source and target devices. Sessions are maintained on the Symmetrix array and can be queried to verify the current state of devices. A copy session must first be Created that defines the Snap devices in the copy operation. Once the session is subsequently activated, the target virtual devices then become accessible to its host. When the information is no longer needed, the session can be terminated. Snap operations are controlled from the host by using the symsnap command to create, activate, terminate, and restore the Snap copy sessions.
  34. 34. TimeFinder/Snap * TimeFinder Snap captures a point-in-time view of a source volume by duplicating only the changed data: – The target is a “slim” virtual device that contains pointers to original source data – The target can be mounted like any other volume – Copying only occurs when there are writes to the source or target – The pre-image of data that has changed is copied to a save device, consuming a fraction of the space required to copy the entire source – Copying is controlled by copy sessions, which are created, activated, queried, listed, and terminated using the “symsnap” command. TimeFinder Snap allows you to make copies of data simultaneously on multiple target devices from a single source device. The data is available to a target host instantly. However, you can copy data from a single source device to as many as fifteen(15) target devices. This source device can be a Standard or a BCV device. (BCV in a Split State). A target device is a virtual device that consumes negligible physical storage through the use of pointers to track data. TimeFinder/Snap - Copying Data Once the TimeFinder Snap session is activated: – The first time a track on the source is written to, the original data on the source is copied to the save device, the VDEV pointer is changed to point to the save device; “then” the source is changed. – “Copy on First Write” applies to writes to the VDEV as well. TimeFinder Snap uses a process called “Copy on First Write” when handling writes to the production data at the same time a snapshot is running. When a host attempts to write to data on the production volume, the original track is first copied to the Save Area, then the write is processed against the production volume. This process of pointers maintains the consistent, point-in-time copy of data for the ongoing snapshot. Striping the Save Device * The copy-on-write is repeated every time a different track on the source is first written to. * Tracks are striped in a round-robin manner to the Save Devices to improve performance. The save pool device is not host accessible, but accessed only through the virtual devices that point to it. Save devices provide a pool of physical space to store snap-copy data to which virtual devices point. Tracks are striped by the microcode in a round-robin manner to save devices to improve performance. When savedevs are configured across the backend, they are separated first by director, then channel, and then by disk. Terminating a Copy Session * When a Copy Session is Terminated: – The virtual device is made not ready. – Tracks on the save device(s) are reclaimed if they are not referenced by any other copy session. – The copy session structures are freed-up. As sessions are terminated, the space in the Save Area is released and available for re-use by other snap sessions.
  35. 35. Multiple Save Device Pools Symmetrix SAVE devices are specially configured devices (not mapped to the host) that provide pooled physical storage space used to store pre-update images or changed tracks during a virtual copy session. Devices within a SAVE device pool act as a group to store data in striped form. Symmetrix supports the creation of multiple named SAVE device pools, allowing symsnap commands to use a particular pool. Save Area capacity can also be allocated based on application requirements, for example: * Allocate more space for Write-intensive applications. * Allocate more space for long duration snapshots. The -svp option can be used with the create action to specify which SAVE device pool to use for an operation. For example, to instruct the copy session to use the SAVE device pool Accounting, use the following symsnap command: symsnap -g BackupDB create DEV002 vdev ld VDEV005 –svp Accounting Operations and States When a virtual device is in a “Not Ready” state, it can participate in a new snap session. The symsnap create argument creates a copy session, and sets the track protection bitmap on the source device to protect all tracks and detect which tracks are being accessed by the target host or written to by the source host. The target virtual device remains Not Ready to its host and placed on hold status for copy session usage. This prevents other control operations from using the device. The device pair state will transition from “Create In Progress” to “Created” when complete. When the copy session is activated, a point-in-time copy of the data becomes available to a target host. The state of the device pair is “CopyOnWrite”. This means that any first write to the source or target device during an active snap session will result in data being copied to an additional save device for storage. The target host accesses the copy through the use of device pointers stored on the virtual device. The pointers keep track of where the data is located in physical storage for accessing the point-in-time copy from the time of activation.
  36. 36. Symsnap restore command is used to restore changed tracks to the desired restore target, which can be either a Symmetrix standard or BCV device. After users issue the command, the status of a virtual device will change from Restore in Progress to Restored. The snap session in the Restored state must be terminated before the snap session of the source can be terminated. Terminating a session with the symsnap terminate command while the device pairs are in the CopyOnfirstWrite or Restored state, will cause the session to end. Once the virtual copy session is terminated, the information is no longer available on the virtual device. Consistent Activation * Four methods to execute “Consistent Activation” * Specify -ppath and PowerPath STD devices that hold the database – Specific devices; supply the device name – All devices using keyword SRCDEVS – Use –rdb for automatic mapping of DB devices * Specify –consistent * Specify –vxfs for VxFS filesystem (Solaris and HP only) * Consistent activate command -both_sides – For devices with an RDF State of Synchronized – Ability to generate a consistent activate for both the local and remote VDEVS at the same time. There are four types of consistent activation available; each offers a restartable copy on BCV devices: – PowerPath – Veritas File System – ECA – -both_sides symsnap Operations * Common Snap operations: – Create – Activate – Restore – Terminate C:symsnap –g testdg3 create DEV001 sym DEV 00A1 –svp training C:symsnap –g testdg3 activate DEV001 sym DEV 00A1 C:symsnap –g testdg3 restore DEV001 sym DEV 00A1 C:symsnap –g testdg3 terminate DEV001 sym DEV 00A1 –restored C:symsnap –g testdg3 terminate DEV001 sym DEV 00A1 The SYMCLI symsnap – Create, Activate, Restore, and Terminate command set are displayed. Configuration Considerations * Cache – There is some additional cache required for TimeFinder Snap snapshots – Total number of VDEVs (snapshots) must be accounted for in cache calculations * VDEV (snapshots) – Are persistent, – On 56XX small physical devices must be allocated (1/600th the size of a source device) – Consume SYM device ID and count as a DA target – Are not convertible to / from other device types (Standard / BCV) Additional Cache is required for Snap snapshots. The number of VDEVs must be included in cache calculations. VDEVs are not customer configurable. Symmetrix volume limits must be respected, VDEVs consume device IDs and count as DA targets; VDEVs count towards hypervolume limits for physical devices. * SaveDev (Save Area) – Physical device(s) store original data copied from source on Copy on First Write – Recommendation of one SaveDev for every five snapshots that will be active at the same time (@20% change rate) – SaveDev should be spread over as many physical volumes as possible – SaveDev consumes SYM device IDs and count as DA targets – Data is striped across entire Save Pool * SaveDev (Save Area) Monitoring – SaveDev thresholds can be set and notifications can be sent – SaveDev can be added dynamically – When Save Area fills, all snapshots are terminated one by one
  37. 37. Symmetrix volume limits must be respected. It cannot exceed total Symmetrix budgets for either device ID limits or DA target limits. SaveDev’s consume device IDs and count as DA targets and cannot exceed hypervolume limits on physical devices since SaveDevs count towards hypervolume limits for physical devices. Use symsnap monitor to track the amount of available space of the save area. The symsnap monitor command can also be used to automatically run an action if a predetermined threshold for space has been crossed. Use -percent nn –action script_pathname to specify the percentage full threshold and script associated with it. Save Device Space Considerations * Virtual Devices do not pre-allocate space for all potential copy-on-write tracks * It is possible to run out of free space on save devices * If Writes can not complete due to no free space: – The target VDEV goes Not Ready (NR), applications beware! – Copy-on-write is disabled and the source track is changed * Draining Save Devices . Permits a disable command to work on an active save device . All active tracks copied (drained) to other devices in the save pool . Protections against disabling the last device or causing the pool to overflow and terminate snap session . Symconfigure syntax remains unchanged: . disable dev SymDevName[:SymDevName] in pool <poolname>, type = snap Monitoring Save Device Space * Use symsnap monitor to automatically run an action: C:symsnap monitor -sid 24 -percent 1 –action one_percent_script.sh –svp DEFAULT_POOL -i 10 –c 5 * The above command will monitor the default save pool (“DEFAULT_POOL”) every 10 seconds for 5 iterations. If the save pool usage reaches 1 percent, then the command will execute the one_percent_script.sh script. You can monitor SAVE devices by using the symsnap monitor command to check the percentage full. When devices reach the specified percentage, an optional action script can be executed by the application to preserve the data or terminate sessions. The following is an example of the monitor command: symsnap monitor -percent 80 -action SaveScript -norepeat -i 60 –svp Accounting In the above example, the SAVE device pool “Accounting” will be monitored every minute for percentage full. When the percentage of the SAVE devices are 80 percent full, the associated action script SaveScript will be executed each time the threshold of 80 percent is met. The first command above will list all the Save Pools. The second command will list all the devices within a save pool The above example will list all the devices within the “training” save pool. C:symsnap list –pools C:symsnap list –svp training -savedevs Using the symconfigure command set the storage administrator can create save pools to be used against a specific application. * First use the Symconfigure to create a save pool * Next, disable save devices from the default save pool * Next, add the disables save devices to the new save pool * Than enable the devices within the new save pool For additional information on creating save pools for snap sessions, reference Symmetrix Array Controls CLI, version 6.5, Product Guide P/N 300-002-940, REV A05. List all the Save Pools and Devices within a Pool c:symsnap list –pools c:symsnap list –svp training –savedevs
  38. 38. View Save Pool’s Details c:symsnap –sid 97 show pool training symsnap –sid <id> show pool <poolname> <- Shows detailed information about the specified “save device” pool. c:symsnap list –svp training –savedevs The above command shows detailed information about specified “save devices within a specific save pool. The symsnap list command with the –savedevs option displays any “save” devices that have been configured on this Symmetrix array to hold data for virtual devices. The display indicates there has not yet been any virtual device activity that caused tracks of data to be copied to these SAVE devices. Add VDEV to Device Group C:symdg create –type regular testdg3 C:symld –g testdg3 add dev 0025 C:symld –g testdg3 add dev 00A1 C:symdg list Reference the above set of commands. The first command creates a testdg3 device group. The second command adds device “0025” as the source from symm ID 97 to the testdg3 device group. The third command adds device “00A1” to the device group and names it “VDEV001”. The last command displays a list of all the device groups which now contain testdg3. symsnap create c:symsnap –g testdg3 create DEV001 sym DEV 00A1 –svp training The symsnap create action defines the copy session requirements and sets the track protection bitmap on the source device to protect all tracks and detect which tracks are being accessed by the target host or written to by the source host. The target virtual device remains Not Ready to its host and placed on hold status for copy session usage. This prevents other control operations from using the device. The device pair state transitions from CreateInProg to Created when complete. The virtual data becomes accessible to its host when the copy session is activated. symsnap activate The symsnap activate command places the snap pair in the CopyOnWrite (copy-on-first-write) state and the target virtual device in a Read/Write (RW) state. The actual copying of data is deferred until you modify tracks on either the source or the target devices. c:symsnap –g testdg3 activate DEV001 sym DEV 00A1
  39. 39. symsnap query / list c:symsnap –g testdg3 query c:symsnap list At this point, using the symsnap “query” or “list” commands will report the state of the device pair for the snap session as “CopyOnWrite”. symsnap restore * Three types of restore operations can be performed for virtual device copy sessions: – Incremental restore back to the original source device – Incremental restore to a split BCV – Full restore to any standard or split BCV device Three types of restore operations can be performed for virtual device copy sessions: 1. Incremental restore back to the original source device. 2. Incremental restore to a BCV, which has been split from its original standard source device but maintains the incremental relationship with the source. 3. Full restore to any standard or split BCV device outside of the existing copy session. The target device of the restore must the same size and emulation type as the source device. Since Enginuity Version 5670, all original Snap copy sessions are maintained when performing a restore operation. A new restore copy session between the source device and restore target device is created. A restore operation can only be performed if an additional copy session is available for use. C:symsnap -g testdg3 create DEV001 sym DEV 00A1 -svp training C:symsnap -g testdg3 activate DEV001 sym DEV 00A1 C:symsnap -g testdg3 restore DEV001 sym DEV 00A1 C:symsnap -g testdg3 query
  40. 40. The above command initiates, by default, an incremental restore from the target device “00A1” to the source device “DEV001”. Note: Prior to performing a restore operation, the user should stop all activity on the file system. This can be accomplished by un- mounting the file system. The symsnap restore command initiates an incremental restore operation that restores from the target VDEV device to the source DEV001. Symsnap query with the –multi flag c:symsnap –g testdg3 query –multi The symsnap query command with the –multi option flag displays all the current copy sessions associated to the testdg3 device group. c:symsnap -g testdg3 terminate DEV001 sym DEV 00A1 -restored C:symsnap -g testdg3 terminate DEV001 sym DEV 00A1 The restored copy session must be terminated first, before the original copy session can be terminated. To terminate the restored copy session, enter: symsnap –g <testdg3> terminate <DEV001> vdev DEV <00A1> -restored After the restore session has been terminated the original copy session can be now be terminated. symsnap –g <testdg3> terminate <DEV001> vdev DEV <00A1> When to Use TimeFinder/Snap The following table represents when TimeFinder Snap vs. TimeFinder Clones / Mirrors should be used, and is a general guideline that should be used to generate discussion regarding the appropriate TimeFinder solution. Snap Summary TimeFinder/Snap functionality is managed via copy sessions, which pair the source and target devices. Sessions are maintained on the Symmetrix array and can be queried to verify the current state of the devices. A copy session must first be created that defines the Snap devices in the copy operation. Once the session is subsequently activated, the target virtual devices then become accessible to its host. When the information is no longer needed, the session can be terminated. Snap operations are controlled from the host by using the symsnap command to create, activate, terminate, and restore the Snap copy sessions. The Snap operations described in this chapter explain how to manage the devices participating in a copy session through using the SYMCLI.
  41. 41. Symmetrix Management Console (SMC) * Independent, light-weight, web-based application – Simple and easy to use browser interface – Hosted on small Windows/Linux/Solaris server – Enables remote access and management from nearly any client * Enables access, configuration, and basic operation of Symmetrix arrays – Supports all configuration capabilities of Solutions Enabler/CLI * Supports multiple generations of Symmetrix – Enginuity version 5x68 and newer * Provides day-one support of new Symmetrix features when released * Adding full-feature ControlCenter does not require management data to be migrated EMC completes the device management offering with the addition of Symmetrix Management Console (SMC for short), enabling you to deploy a light-weight, web-based Graphical User Interface, or GUI, for performing device management in Symmetrix environments. You can now choose the right management product or products to meet your specific requirements. Almost anything you can do using the Solutions Enabler CLI can now be done using the SMC GUI. SMC will manage all Symmetrix systems running Enginuity version 5568 and newer, and will support new hardware and software features and functionality at the time of product release. Addressing customer demands for enhanced platform interoperability, SMC is an independent application which runs using its own lightweight Windows/Linux/Solaris server. The client runs in a browser window, therefore supporting nearly any client with remote access to the server. The SMC GUI features closely match Solutions Enabler CLI features to include all basic monitoring, configuration, and control of Symmetrix arrays. SMC has no Symmetrix-related database other than the Solutions Enabler database, so all data automatically transfers to the full-feature ControlCenter when discovered by the Symmetrix agent. Due to the combination of being light-weight yet feature rich, early response to SMC shows it to be a leader in this type of product. SMC Functionality * Access Management – Manage users, permissions/roles – Symmetrix Access Controls * Configuration Management – Create devices, map and mask devices, create device groups, set Symmetrix attributes * Replication Management – TF/Clone, TF/Mirror, TF/Snap, SRDF/S, SRDF/A, SRDF/DM, Open Replicator, Optimizer * Alerts and Monitoring – Monitor Device status, device attributes, operations status – Monitor array alerts The major components of the SMC Interface are highlighted here. To monitor and control operations, select a single object or folder of multiple objects in the Navigation Tree. The View Bar is used to switch between five different views: Properties, Config Session, Alerts, Command History, and Replication Monitor. The view currently selected displays in the view area. The View button and corresponding view display are color coded to match. The Alert counter in the top right, which also selects the Alert View, Tree Selection, View selection, and object selection within the View area, determines the current display. The View may be split horizontally into two or three areas, depending on the detail associated with the selection. Device Groups and Composite Groups * SRDF and TimeFinder operations in SMC require Device Groups or Composite Groups (DG/CG) * All DG/CGs in the default symapi_db.bin or GNS (if active) are available in SMC * DG/CGs can be created, deleted, renamed and devices can be added and removed as needed * SRDF and TimeFinder operations are invoked by selecting a DG or CG and using the Replication option * Device Masking operation can also be invoked by selecting a DG * Devices can belong to multiple DGs SRDF and TimeFinder operation in SMC requires the use of either Device Groups or Composite Groups. SMC has visibility to all the DG/CGs that exist in the symapi_db of the SMC Server host and to all device groups, if GNS is in use. The DG/CG Wizard allows the creation of new DGs and CGs. Groups can be deleted and renamed and devices can be added or removed as necessary. The Mapping and Masking dialogs can be launched directly from a Device group, making it convenient to quickly change the allocation configuration of a whole data set. The same device can be added to more than one device group or consistency group at the same time, making it easier to manage complex synchronization environments. For backwards compatibility, the SYMAPI_ALLOW_DEV_IN_MULT_GRPS option must be enabled in the SYMAPI configuration file (<install>/symapi/config/options) after install or upgrade.
  42. 42. Device Types in DG/CG The Devices types supported in SMC are shown on the slide. The STD Devices can be Regular (non SRDF Devices), SRDF R1s, or SRDF R2. Devices can be added as Clone Target devices on the local or the remote array, and remote Virtual devices can be added. The device group dialog displays only valid devices when choosing a device type. For instance, when adding remote Clone Target devices, only eligible devices configured on the remote array display in the dialog. Creating Device Groups * Device Group Management à Create Device Group SMC Device Group creation is a multi-step process, similar to creating SYMCLI device groups using symdg, symld, and symbcv. The wizard is launched by right clicking the Device Group Folder and choosing the Device Group Management Æ Create Device Group option. In this example, we create a Device Group of Type Regular and associate local VDEVSs, local BCVs and local clone targets. The first step is to choose a name for the Device Group (SMCDG in this example), then the Device Group Type (Regular in this example because we want to add STD devices). Click on STD in the Device Type Column and add the required STD devices from the Available box to the Group Members box. The bottom of the wizard gives a summary of the selections that have been made. In the next slide, the local BCVs, VDEVs and the local Clone target selections are made.
  43. 43. The local BCVs, VDEVs and the local clone targets (TGT) are added to the device group. Click OK to complete the creation of the device group. Device Group Created Successfully A completion message is displayed. The completion message reports types of devices added, in this case STD, BCV, VDEV, and TGT. The new group device group, SMCDG, is displayed in the tree view with folders for the STD, BCV, VDEV, and TGT devices. Replication Operations Supported by SMC Almost all replication technologies available on the Symmetrix Arrays can be monitored and managed via SMC. At the present time, SRDF/Star cannot be managed via SMC. Management of TimeFinder operations is shown in this module.

×