1. Associate the BCV Device for pairing: To perform standard/BCV pairing, the standard and BCV mirror devices of your production images must be members of the same device group (Note:- Already discussed in previous post about creating device group and pairing devices). symbcv –g DgName –sid SymmID associate dev 0ABC BCV001 Or to associate a range of devices to a device group, enter: symbcv –g DgName –sid SymmID associateall dev –RANGE 0ABC:0DEF Note:- -sid SymmID is optional if you have already defined device group in symcli environment varaiable. 2. Unmount the BCV device: Prior to using devices for BCV operations, the BCV device should be Windows formatted and assigned a drive letter. If using basic disks on the Windows platform, you must unmount the BCV devices. If using dynamic disks, you must deport the entire TimeFinder device group. For basic disks, use the syminq command to determine the SymDevName of the potential BCV device. For dynamic disks,use the TimeFinder symntctl command to determine the volume and disk group name as follows: symntctl list –volume [dg DgName] Note that the term device group and dynamic disk group are the same applied to this command. Unmount the selected BCV device as follows (with TimeFinder command): symntctl unmount –drive z Where z equals the designated drive letter. If an error occurs, check for an “openhandle” and clear this condition. For Veritas dynamic disks only, you must deport the disk group and rescan using the following commands: vxdg deport –g DgName symntctl rescan 3. Fully Establish BCV and STD: To obtain a copy of the data on a standard device, the BCV device of the pair must be established. To initiate a full establish on a specific standard/BCV device pair, target the standard device: symmir –g DgName –full establish DEV001 Fully Establish all pairs in a group. To initiate a full establish on all BCV pairs in a device group, enter: symmir –g DgName –full establish Verify the completed (synchronized) establish operation. To verify when the BCV pairs reach the full copied or Synchronized state, use the verify action as follows: symmir –g DgName –i 20 verify With this interval and count, the message is displayed every 20 seconds until the pair is established. Rescan the drive connections. For Dynamic disks only on a Windows host, you should rescan for drive connections visible to the host: symntctl rescan After any standard/BCV pair has been fully established and subsequently split, to save establish (resync) time, you can perform an establish operation omitting the -full option, which updates the BCV copy with only the changed tracks that occurred on the standard device during the elapsed BCV split time. To perform an incremental establish, omit the –full option, targeting the standard device symmir -g DgName establish DEV001 Optionally, you can also collectively target all devices in a device group, composite group, or defined devices in a device file: symmir –g DgName establish [-full] symmir –g CgName establish [-full] symmir –file FileName establish [-full] 4. Prepare (freeze) Production database for a TimeFinder Split: To prepare to split the synchronized BCV device from the production standard device, you must suspend I/O at the application layer or unmount the production standard prior to executing the split operation. symioctl freeze –type DbType [object] Ensure any residual cache on the Production host is fully flushed to disk. To insure all pending unwritten production file system entries are captured, enter TimeFinder command: symntctl flush –drive z Wait 30 to 60 seconds for the flush operation to complete. 5. Split the BCV devices: To split all the BCV devices from the standard devices in the production device group, enter: symmir –g DgName split To split a specific standard/BCV pair, target the logical device name in the group, enter: symmir –g DgName split DEV001 6. Verify the split operation completes: To verify when the BCV device is completely split from the standard, use the verify action as follows: symmir –g DgName –i 20 verify –split -bg With this interval and count, the message is displayed every 20 seconds until the pair is split. 7. Rescan for dynamic disks: For dynamic disks only, you should rescan for drive connections visible to the host: symntctl rescan 8. Mounting BCV device: After splitting the BCV device, you can mount the device with captured data on another host and reassign the drive letter. For basic disks, use the TimeFinder command: symntctl mount –drive z –dg DgName For Dynamic disks, use the TimeFinder command: symntctl mount –drive z –vol VolName –dg DgName | -guid VolGuid For VERITAS dynamic disk only, you must deport the disk group and rescan, as follows: vxdg deport –dg DgName symntctl rescan For Dynamic disk only (without Veritas), you can use the Microsoft diskpart command to select the disk and import the device using the online and import actions. Note:- symntctl command available in TimeFinder/IM ( Integration Module).
of the pair:
The EMC provided solution to this problem is called “Enginuity Consistency Assist”. When you create a set of sessions and invoke Enginuity Consistency Assist, the Symmetrix aligns the I/O of those devices and halts all I/O from the host systems very briefly—much faster than the applications can detect—while it creates the session. It then resumes normal operation without any application impact.
TimeFinder Consistent Split using (TimeFinder/Consistency Groups) allows the splitting off of a consistent, re-startable image of an Oracle database instance within seconds with no interruption to the online Oracle database instance.
Ÿ - Allows users to split off a dependent write consistent, re-startable image of application without interrupting online services
Ÿ - Using TimeFinder/Consistency Groups to defer write I/O at the Symmetrix before a split
Ÿ - Consistent split can be performed by any host running Solutions Enabler connected to the Symmetrix
Ÿ - Tested and available including HP-UX, Solaris, AIX, Linux, and Windows
Ÿ - No database shutdown or requirement to have database put into backup mode (Oracle).
Using TF/CG, consistent splits helps to avoid inconsistencies and restart problems that can occur with using Oracle hot-backup mode (not quiescing the database).
• No disruption to the online Oracle database to obtain a Point-in-Time image
• Provides a consistent, re-startable image of the Oracle database for testing new versions or database patch updates before deploying for use in production environments
• Can be used to obtain a business point of consistency for business restart requirements for which Oracle has been identified as one of multiple databases for such an environment.
The same benefits apply using TF/CG in a clustered environment as in a non-clustered environment:
- No disruption to the online Oracle database to obtain a Point-in-Time image in a Oracle single instance environment or when using Oracle Real Application Clusters
- Provides a consistent, re-startable image of the Oracle database for testing new versions or database patch updates before deploying for use in clustered production environments
- Can be used to obtain a business point of consistency for business restart requirements for which Oracle has been identified as one of multiple databases for such an environment.
Auto-provisioning requires Enginuity 5874 or later. It simplify Symmetrix provisioning by allowing you to create group of devices like storage group in CLARiiON, Front-End Port Group and Host Initiators Group and then associate these groups with each other in a masking view.
The following are the basic steps for provisioning Symmetrix using Auto-Provisioning:-
1) Create a Storage Group
2) Create a Port Group
3) Create an Initiator Group
4) Associate the groups in a Masking View.
Creating Storage Group:- It is component of Auto-Provisioning group and FAST ( Will discuss about FAST in later post), both require Enginiuity 5874. The maximum number of storage group allowed per array is 8192. A storage group can contain up to 4096 devices. A Symmetrix device can belong to more than one storage group.
Note:- By default Dynamic LUN addresses will assigned to each device. If can manually assign the host LUN addresses for the device you are adding to the group by clicking Set LUN Address- Storage group dialog box.
Creating Port Group:- A port can belong to more than one port group and port must have the ACLX bit enabled. For example if you want FA 5A and 12 A for windows operating system, you can create port group name called WIN_PortGrp or Win_FA5A_FA12A_PrtGrp etc.
Creating Initiator Group:- The maximum number of initiator groups allowed per Symmetrix array is 8000. An initiator group can contain up to 32 initiator of any type and contain other initiator groups (cascaded to only one level).
Initiator Group name must be unique from other initiator groups on the array and cannot exceed 64 characters. Initiator group names are case-insensitive.
Creating Masking view:- It just a co-relation between Storage Group, Port Group and Initiator Group and you are done! Device will be mapped automatically to selected port group and masked to selected initiator groups.
Return code handling for Windows and UNIX The following lists the possible status or error codes that can be returned by the various SYMCLI commands on a Windows or UNIX platform and useful for troubleshooting.
Code Code symbol Description
___________________________________________________
0 CLI_C_SUCCESS CLI -- call completed successfully.
1 CLI_C_FAIL CLI - call failed.
2 CLI_C_DB_FILE_IS_LOCKED- Another process has an exclusive
lock on the Host database file.
3 CLI_C_SYM_IS_LOCKED - Another process has an exclusive
lock on the Symmetrix.
4 CLI_C_NOT_ALL_SYNCHRONIZED NOT - all of the mirrored pairs are in the 'Synchronized' state.
5 CLI_C_NONE_SYNCHRONIZED - NONE of the mirrored pairs are in the 'Synchronized' state.
6 CLI_C_NOT_ALL_UPDATED - - NOT all of the mirrored pairs are in the 'Updated' state.
7 CLI_C_NONE_UPDATED --NONE of the mirrored pairs are in the 'Updated' state.
8 CLI_C_NOT_ALL_PINGED -- NOT all of the remote Symmetrix units can be pinged.
9 CLI_C_NONE_PINGED -- NONE of the remote Symmetrix units can be pinged.
10 CLI_C_NOT_ALL_SYNCHED -- NOT all of the mirrored pairs are in the 'Synchronized' state.
11 CLI_C_NONE_SYNCHED -- NONE of the mirrored pairs are in the 'Synchronized' state.
12 CLI_C_NOT_ALL_RESTORED -- NOT all of the pairs are in the 'Restored' state.
13 CLI_C_NONE_RESTORED -- NONE of the pairs are in the 'Restored' state.
14 CLI_C_NOT_ALL_VALID -- NOT all of the mirrored pairs are in a valid state.
15 CLI_C_NONE_VALID -- NONE of the mirrored pairs are in a valid state.
16 CLI_C_SYM_NOT_ALL_LOCKED -- NOT all of the specified Symmetrix units have an exclusive Symmetrix lock.
17 CLI_C_SYM_NONE_LOCKED --NONE of the specified Symmetrix units have an exclusive Symmetrix lock.
18 CLI_C_ALREADY_IN_STATE --The Device(s) is (are) already in the desired state or mode.
19 CLI_C_GK_IS_LOCKED -- All GateKeeper devices to the Symmetrix unit are currently locked.
20 CLI_C_WP_TRACKS_IN_CACHE -- Operation cannot proceed because the target device has Write Pending I/O in the cache.
21 CLI_C_NEED_MERGE_TO_RESUME --Operation cannot proceed without first performing a merge of the RDF Track Tables.
22 CLI_C_NEED_FORCE_TO_PROCEED --Operation cannot proceed in the current state except if you specify a force flag.
23 CLI_C_NEED_SYMFORCE_TO_PROCEED --Operation cannot proceed in the current state except if you specify a symforce flag.
24 CLI_C_NOT_IN_SYNC -- The Symmetrix configuration and the database file are NOT in sync.
25 CLI_C_NOT_ALL_SPLIT -- NOT all of the mirrored pairs are in the 'Split' state.
26 CLI_C_NONE_SPLIT -- NONE of the mirrored pairs are in the 'Split' state.
27 CLI_C_NOT_ALL_SYNCINPROG -- NOT all of the mirrored pairs are in the 'SyncInProg' state.
28 CLI_C_NONE_SYNCINPROG -- NONE of the mirrored pairs are in the 'SyncInProg' state.
29 CLI_C_NOT_ALL_RESTINPROG -- NOT all of the pairs are in the 'RestInProg' state.
30 CLI_C_NONE_RESTINPROG -- NONE of the pairs are in the 'RestInProg' state.
31 CLI_C_NOT_ALL_SUSPENDED -- NOT all of the mirrored pairs are in the 'Suspended' state.
32 CLI_C_NONE_SUSPENDED -- NONE of the mirrored pairs are in the 'Suspended' state.
33 CLI_C_NOT_ALL_FAILED_OVER -- NOT all of the mirrored pairs are in the 'Failed Over' state.
34 CLI_C_NONE_FAILED_OVER -- NONE of the mirrored pairs are in the 'Failed Over' state.
35 CLI_C_NOT_ALL_UPDATEINPROG -- NOT all of the mirrored pairs are in the 'R1 UpdInProg' state.
36 CLI_C_NONE_UPDATEINPROG -- NONE of the mirrored pairs are in the 'R1 UpdInProg' state.
37 CLI_C_NOT_ALL_PARTITIONED -- NOT all of the mirrored pairs are in the 'Partitioned' state.
38 CLI_C_NONE_PARTITIONED -- NONE of the mirrored pairs are in the 'Partitioned' state.
39 CLI_C_NOT_ALL_ENABLED -- NOT all of the mirrored pairs are in the 'Enabled' consistency state.
40 CLI_C_NONE_ENABLED -- NONE of the mirrored pairs are in the 'Enabled' consistency state.
41 CLI_C_NOT_ALL_SYNCHRONIZED_AND_ENABLED -- NOT all of the mirrored pairs are in the 'Synchronized' rdf state and the 'Enabled' consistency state.
42 CLI_C_NONE_SYNCHRONIZED_AND_ENABLED -- NONE of the mirrored pairs are in the 'Synchronized' rdf state and in the 'Enabled' consistency state.
43 CLI_C_NOT_ALL_SUSP_AND_ENABLED -- NOT all of the mirrored pairs are in the 'Suspended' rdf state and 'Enabled' consistency state.
44 CLI_C_NONE_SUSP_AND_ENABLED -- NONE of the mirrored pairs are in the 'Suspended' rdf state and the 'Enabled' consistency state.
45 CLI_C_NOT_ALL_SUSP_AND_OFFLINE -- NOT all of the mirrored pairs are in the 'Suspended' rdf state and 'Offline' link suspend state.
46 CLI_C_NONE_SUSP_AND_OFFLINE -- NONE of the mirrored pairs are in the 'Suspended' rdf state and the 'Offline' link suspend state.
47 CLI_C_WONT_REVERSE_SPLIT -- Performing this operation at this time will not allow you to perform the next BCV split as a reverse split.
48 CLI_C_CONFIG_LOCKED -- Access to the configuration server is locked.
49 CLI_C_DEVS_ARE_LOCKED -- One or more devices are locked.
50 CLI_C_MUST_SPLIT_PROTECT -- If a device was restored with the protect option, it must be split with the protect option.
51 CLI_C_PAIRED_WITH_A_DRV -- The function can not be performed since the STD device is already paired with a DRV device.
52 CLI_C_PAIRED_WITH_A_SPARE -- NOT all of the Snap pairs are in the 'Copy in progress' state.
53 CLI_C_NOT_ALL_COPYINPROG -- NOT all of the pairs are in the 'CopyInProgress' state.
54 CLI_C_NONE_COPYINPROG --NONE of the pairs are in the 'CopyInProgress' state.
55 CLI_C_NOT_ALL_COPIED -- NOT all of the pairs are in the 'Copied' state.
56 CLI_C_NONE_COPIED -- NONE of the pairs are in the 'Copied' state.
57 CLI_C_NOT_ALL_COPYONACCESS -- NOT all of the pairs are in the 'CopyonAccess' state.
58 CLI_C_NONE_COPYONACCESS -- NONE of the pairs are in the 'CopyonAccess' state.
59 CLI_C_CANT_RESTORE_PROTECT --The protected restore operation can not be completed because there are write pendings or the BCV mirrors are not synchronized.
60 CLI_C_NOT_ALL_CREATED -- NOT all of the pairs are in the 'Created' state.
61 CLI_C_NONE_CREATED -- NONE of the pairs are in the 'Created' state.
62 CLI_C_NOT_ALL_READY -- NOT all of the BCVs local mirrors are in the 'Ready' state.
63 CLI_C_NONE_READY -- NONE of the BCVs local mirrors are in the 'Ready' state.
64 CLI_C_STD_BKGRND_SPLIT_IN_PROG -- The operation cannot proceed because the STD Device is splitting in the Background.
65 CLI_C_SPLIT_IN_PROG -- The operation cannot proceed because the pair is splitting.
66 CLI_C_NOT_ALL_COPYONWRITE -- NOT all of the pairs are in the 'CopyOnWrite' state.
67 CLI_C_NONE_COPYONWRITE -- NONE of the pairs are in the 'CopyOnWrite' state.
68 CLI_C_NOT_ALL_RECREATED -- Not all devices are in the 'Recreated' state.
69 CLI_C_NONE_RECREATED -- No devices are in the 'Recreated' state.
70 CLI_C_NOT_ALL_CONSISTENT -- NOT all of the mirrored pairs are in the 'Consistent' state.
71 CLI_C_NONE_CONSISTENT-- NONE of the mirrored pairs are in the 'Consistent' state.
72 CLI_C_MAX_SESSIONS_EXCEEDED-- The maximum number of sessions has been exceeded for the specified device.
73 CLI_C_NOT_ALL_PRECOPY -- Not all source devices are in the 'Precopy' state.
74 CLI_C_NONE_PRECOPY -- No source devices are in the 'Precopy' state.
75 CLI_C_NOT_ALL_PRECOPY_CYCLED -- Not all source devices have completed one precopy cycle.
76 CLI_C_NONE_PRECOPY_CYCLED -- No source devices have completed one precopy cycle.
77 CLI_C_CONSISTENCY_TIMEOUT -- The operation failed because of a Consistency window timeout.
78 CLI_C_NOT_ALL_FAILED -- NOT all of the pairs are in the 'Failed' state.
79 CLI_C_NONE_FAILED -- NONE of the pairs are in the 'Failed' state.
80 CLI_C_CG_NOT_CONSISTENT -- CG is NOT RDF-consistent.
81 CLI_C_NOT_ALL_CREATEINPROG -- NOT all of the pairs are in the 'CreateInProg' state.
82 CLI_C_NONE_CREATEINPROG -- None of the pairs are in the 'CreateInProg' state.
83 CLI_C_NOT_ALL_RECREATEINPROG -- NOT all of the pairs are in the 'RecreateInProg' state.
84 CLI_C_NONE_RECREATEINPROG -- None of the pairs are in the 'RecreateInProg' state.
85 CLI_C_NOT_ALL_TERMINPROG -- NOT all of the pairs are in the 'TerminateInProg' state.
86 CLI_C_NONE_TERMINPROG -- None of the pairs are in the 'TerminateInProg' state.
87 CLI_C_NOT_ALL_VERIFYINPROG -- NOT all of the pairs are in the 'VerifyInProg' state.
88 CLI_C_NONE_VERIFYINPROG -- None of the pairs are in the 'VerifyInProg' state.
89 CLI_C_NOT_ALL_VERIFIED -- NOT all of the pairs are in the requested states.
90 CLI_C_NONE_VERIFIED -- NONE of the pairs are in the requested states Note: This message is returned when multiple states are verified at once.
91 CLI_C_RDFG_TRANSMIT_IDLE -- RDF group is operating in SRDF/A Transmit Idle.
92 CLI_C_NOT_ALL_MIGRATED -- Not all devices are in the ' Migrated' state.
93 CLI_C_NONE_MIGRATED -- None of devices are in the 'Migrated' state.
94 CLI_C_NOT_ALL_MIGRATEINPROG -- Not all devices are in the 'MigrateInProg' state.
95 CLI_C_NONE_MIGRATEINPROG -- None of devices are in the 'MigrateInProg' state.
96 CLI_C_NOT_ALL_INVALID-- Not all devices are in the 'Invalid' state.
97 CLI_C_NONE_INVALID-- None of devices are in the 'Invalid' state.
We have discussed about Virtual Provisioning of Symmetrix in previous post. Now, we will discuss about Virtual Provisioning Configuration. You have to understand your storage environment before you run the below mentioned command.
Configuring and viewing data devices and pools:
Data Devices are devices with datadev attribute. Only Data Devices can be part of Thin Pool. Devices with different protection scheme can be supported for use in Thin Pools. It is depending on specific Enginuity level. All devices with the datadev attribute are used for exclusively for populating Thin Pools.
Create command file (Thin.txt) with following syntax:
create dev count=10, config=2-Way-Mir, attribute=datadev, emulation=FBA, size=4602;
# symconfigure -sid 44 -file thin.txt commit –v –nop
A Configuration Change operation is in progress. Please wait...
Establishing a configuration change session...............Established.
Processing symmetrix 000190101244
{
create dev count=10, size=4602, emulation=FBA,
config=2-Way Mir, mvs_ssid=0000, attribute=datadev;
}
Performing Access checks..................................Allowed.
Checking Device Reservations..............................Allowed.
Submitting configuration changes..........................Submitted
…..
…..
…..
Step 125 of 173 steps.....................................Executing.
Step 130 of 173 steps.....................................Executing.
Local: COMMIT............................................Done.
Terminating the configuration change session..............Done.
The configuration change session has successfully completed.
# symdev list -sid 44 -datadev
Symmetrix ID: 000190101244
Device Name Directors Device
--------------------------- ------------- -------------------------------------
Sym Physical SA :P DA :IT Config Attribute Sts Cap(MB)
--------------------------- ------------- -------------------------------------
10C4 Not Visible ???:? 01A:C4 2-Way Mir N/A (DT) RW 4314
10C5 Not Visible ???:? 16C:D4 2-Way Mir N/A (DT) RW 4314
10C6 Not Visible ???:? 15B:D4 2-Way Mir N/A (DT) RW 4314
10C7 Not Visible ???:? 02D:C4 2-Way Mir N/A (DT) RW 4314
10C8 Not Visible ???:? 16A:D4 2-Way Mir N/A (DT) RW 4314
10C9 Not Visible ???:? 01C:C4 2-Way Mir N/A (DT) RW 4314
10CA Not Visible ???:? 16B:C4 2-Way Mir N/A (DT) RW 4314
Thin Pool can be created using symconfigure command and without adding data devices:
# symconfigure -sid 44 -cmd "create pool Storage type=thin;" commit –nop
Once pool is created, data devices can be added to the pool and enabled:
EMC announced Symmetrix V-Max recently which is based on virtual matrix. Symmetrix V-Max runs on latest Enginuity 5874. The 5874 plateform support Symmetricx V-Max Emulation level 121 and service processor level 102. The modular design of V-Max series Enginuity 5874 ensure flow and integrity between hardware component. Symmetrix Management Console 7.0 (SMC) integrated in service processor. SMC allows you to provision in 5 steps. Enginuity 5874 provides following enhanced feature:
Large Volume :-Support Enginuity 5874 increases the maximum volume size to approximately 240 GB for open systems environments and 223 GB for mainframe environments. DMX-4 allows max only 65 GB hyper.
512 Hyper Volumes per Physical Drive :- Enginuity 5874 supports up to 512 hyper volumes on a single drive, twice as much as Enginuity 5773(DMX-3/4). You can improve flexibility and capacity utilization by configuring more granular volumes that more closely meet their space requirements and leave less space unused.
Autoprovisioning Groups :- Auto provisioning Groups reduce the complexity of Symmetrix device masking by allowing the creation of groups of host initiators, front-end ports and storage volumes. This provides the ability to mask storage to multiple paths instead of one path at a time, reducing the time required and potential for error for consolidated and virtualized server environments. You can script and schedule batch operation using SMC 7.0.
Concurrent Provisioning and Scripts :- Concurrent configuration changes provide the ability to run scripts concurrently instead of serially, improving system management efficiency. Uses for concurrent configuration changes include parallel device mapping, unmapping, metavolume form and dissolve from different hosts.
Dynamic Provisioning Enhancements :- Dynamic configuration changes allow the dynamic setting of the BCV and dynamic SRDF device attributes and decrease the impact to hosts I/O during the corresponding configuration manager operations.
New Management Integration :- With Enginuity 5874, the Symmetrix Management Console (SMC) and SMI-S provider are available on the Symmetrix system's Service Processor. This frees host resources and simplifies Symmetrix system management; by attaching the Service Processor to your network, you can open SMC and manage the Symmetrix system from anywhere in their enterprise.
Enhanced Virtual LUN :- With Enginuity 5874, Virtual LUN technology provides the ability to non disruptively change the physical location on disk, and/or the protection type of Symmetrix logical volumes and allows the migration of open systems, Mainframe and System i volumes to unallocated storage or to existing volumes. Organizations can respond more easily to changing business requirements when using tiered storage in the array.
EMC is introducing a revolutionary new Virtual Matrix architecture within the Symmetrix system family which will redefine high-end storage capabilities. This new Symmetrix V-Max system architecture allows for unprecedented levels of scalability. Robust high availability is enabled by clustering, with fully redundant V-Max Engines and interconnects. The Symmetrix V-Max series is built on a revolutionary Virtual Matrix architecture. Symmetrix V-Max, along with Enginuity 5874, delivers unprecedented performance, availability, functionality, and economic advantages. The Symmetrix V-Max series, with the unique scale-out Virtual Matrix architecture, can be configured with 96 to 2,400 drives and usable capacity up to 2 PB. Systems provide up to 944 GB of mirrored global memory and up to 128 Fibre Channel ports, 64 FICON ports, 64 Gigabit Ethernet ports, or 64 iSCSI connections. The Symmetrix V-Max series is a distributed multi-node storage system that can scale from one to eight highly available V-Max Engines. Systems are configured around a central system bay and adjacent storage bays of up to 240 disks each. A full range of drive options is available scaling from ultra-fast enterprise Flash drives, to Fibre Channel drives; to the highest capacity 1 TB SATA II drives. Enhanced device configuration and replication operations result in simpler, faster and more efficient management of large virtual and physical environments. This allows organizations to save on administrative costs, reduce the risk of operational errors and respond rapidly to changing business requirements.Enginuity 5874 also introduces cost and performance optimized business continuity solutions. This includes the zero RPO 2-site long distance solution.RAID Virtual Architecture (RVA) - Enginuity 5874 introduces a new RAID implementation infrastructure. This enhancement increases configuration options in SRDF environments by reducing the number of mirror positions for RAID 1 and RAID 5 devices. This enhancement also provides additional configuration options, for example, allowing LUN migrations in a Concurrent or Cascaded SRDF environment. Large Volume Support Enginuity 5874 increases the maximum volume size to approximately 240 GB for open systems environments and 223 GB for mainframe environments.
512 Hyper Volumes per Physical Drive: - Enginuity 5874 supports up to 512 hyper volumes on a single drive, twice as much as Enginuity 5773. Customers can improve flexibility and capacity utilization by configuring more granular volumes that more closely meet their space requirements and leave less space unused. Autoprovisioning Groups Autoprovisioning Groups reduce the complexity of Symmetrix device masking by allowing the creation of groups of host initiators, front-end ports and storage volumes. This provides the ability to mask storage to multiple paths instead of one path at a time, reducing the time required and potential for error for consolidated and virtualized server environments. Concurrent Provisioning and Scripts Concurrent configuration changes provide the ability to run scripts concurrently instead of serially, improving system management efficiency. Uses for concurrent configuration changes include parallel device mapping, unmapping, metavolume form and dissolve from different hosts.
Dynamic Provisioning Enhancements: - Dynamic configuration changes allow the dynamic setting of the BCV and dynamic SRDF device attributes and decrease the impact to hosts I/O during the corresponding configuration manager operations.
New Management Integration: - With Enginuity 5874, the Symmetrix Management Console (SMC) and SMI-S provider are available on the Symmetrix system's Service Processor. This frees host resources and simplifies Symmetrix system management; by attaching the Service Processor to a customer network, the customer can open SMC and manage the Symmetrix system from anywhere in their enterprise.
Enhanced Virtual LUN :- With Enginuity 5874, Virtual LUN technology provides the ability to nondisruptively change the physical location on disk, and/or the protection type of Symmetrix logical volumes and allows the migration of open systems, Mainframe and System i volumes to unallocated storage or to existing volumes. Organizations can respond more easily to changing business requirements when using tiered storage in the array.
Enhanced Virtual Provisioning:- Draining With Enginuity 5874, Virtual Provisioning support for draining of data devices allows the nondisruptive removal of one or more data devices from a thin device pool, without losing the data that belongs to the thin devices. This feature allows for improved capacity utilization.Enhanced Virtual Provisioning: Support for all RAID Types with Enginuity 5874, Virtual Provisioning no longer restricts RAID 5 data devices. Virtual Provisioning now supports all data device RAID types.
Veritas Disk Group Configuration Guidelines:-
1) Use multiple Disk Groups—preferably a minimum of four; place the DATA, REDO, TEMP, UNDO, and FRA archive logs in different (separate) Veritas Disk Groups
2) Optimally, use RAID 1 for tier 1 storage
3) Configure Disk Groups so that each contains LUNs of the same size and performance characteristics
Distribute Veritas Disk Group members over as many spindles as is practical for the site’s configuration and operational needs
Data Striping and Load Balancing:-
1) Veritas software level striping: layout=stripe ncols=10 stripeunit=128k
2) Storage-level striping further parallelizes the individual I/O requests within storage
3) Using the storage RAID protection, the amount of I/O traffic (host to storage) is reduced
4) EMC PowerPath should be used for load balancing and path failover
5) Use of metavolumes is optional
a) There is an upper limit on the number of LUNs that a host can address—typically ranging from 256 to 1,024 per HBA.
Volume Configuration with Veritas (Hypervolumes):
1) Created 5 Veritas Disk Groups
2) Five Disk Groups are used because this number provides better granularity for performance planning
3) The use of five Disk Groups also provides increased flexibility when planning for the utilization of EMC replication technology within the context of an enterprise-scale workload
4) Having five Disk Groups permits the placement of data onto different storage tiers if desired
| Hypervolume | Purpose | Size |
| 1 | DATA | 32 GB |
| 2 | REDO | 400 MB |
| 3 | DATA | 32 GB |
| 4 | FRA | 30 GB |
| 5 | TEMP | 10 GB |
| 6 | FRA | 30 GB |
Average Disk Utilization for Raid 1 should be below 150 IOPS per disk and should not go above 200 IOPS per disk as per below configuration.
-- 80 physical disks (40 mirrored pairs)
-- 240 devices visible to Veritas
About Me
- Diwakar
- Sr. Solutions Architect; Expertise: - Cloud Design & Architect - Data Center Consolidation - DC/Storage Virtualization - Technology Refresh - Data Migration - SAN Refresh - Data Center Architecture More info:- diwakar@emcstorageinfo.com
Subscribe To
Posts
All Comments
