Anda di halaman 1dari 8

PROVISIONING IN DMX

Hyper / meta creation (Tdev on vmax)


List of thin pools and individual devices
To check zoning (symmask list logins)
Map/mask for DMX
Complete allocation for vmax(procedure)
Flag settings
Clusters remember to set consistent_lun in vmax
DMX -4 1920 drives
1. To check the fabric logi (flogi)
Switchshow | grep wwpn or aliname

2. Providing logical connectivity (zoning)


3. Validating whether the zoning is done correctly or not through check plogi on storage
Symmask list logins sid xxx dir xxx p xxx
4. To display available free space (no need to tel)
Symconfigure sid xxx list freespace unit MB
5. To display the available devices
Symdev list sid xxx noport
6. To create hypers or devices
Open vi editor or text file
Create dev count=xxxx, size=xxxx, Config=RAID5,emulation=FBA
Save
Then RUN the text file using
Symconfigure -sid xxx f filename preview(conform the command syntax is correct)
Prepare(conform the command syntax is correct and
fisibilty
checking, and device locked)
Commit(commit the changes to the database)
7. To check available channel address for FA Ports
Symcfg list sid xxx dir xxx p xxx addr avail
8. Mapping the devices to the FS Ports
Open vi editor file
Map dev xxx to dir xxx p xxx target=0 lun=xxx;(; must & should)
Save
Then run the text file using
Symconfigure sid xxx f filename preview
Prepare
Commit

9. To update the configuration


Symcfg discover
10. Masking the hypers to the Host
Symmask sid xxx wwn wwpn dir xxx p xxx add dev xxx
11. To update the masking database
Symmask refresh sid xxx
12. To know how many hosts are accessing a hyper
Symmaskdb list sid xxx assignments dev xxx
13. To know how many devices are assigned to a host
Symmaskdb list sid xxx devs wwn wwpn
14. To display all disk groups in a symmetrix
Symdev list sid xxx bg disk_group
VMAX Provioning
1. Identifying the FA Ports to which HBAs are logged
Symaccess sid xxx list logins
2. Identifying the Devices which are not available in the Thin Pool
Symdev sid xxx list noport raid5 thinpool
3. Creating Thin devices
Symconfigure sid xxx cmd create dev count=xxxx size=xxxx emulation=FBA
Config=TDEV; preview,prepare,commit
4. Adding the devices to the thin pool
Symconfigure sid xxx cmd bind tdev xxx to pool poolname preallocate size=xxx;
preview,prepare, commit
5. Creating STORAGE group
Symaccess sid xxx create name SGNAME type storage dev xxx
Symaccess sid xxx name SGNAME type storage add dev xxx (If storage group is
exited then devs are added to existed group using this command)
Show storage group
Symaccess sid xxx show SGNAME type storage
6. Creating PORT group
Symaccess sid xxx create name PGNAME type port dir xxx p xxx
Symaccess sid xxx name PGNAME type port add dirport xx:xx (add existed port
group)

Show Port group


Symaccess sid xxx show PGNAME type port
7. Creating the Initiator group
Symaccess sid xxx create name IGNAME type initiator wwn wwpn
Symaccess sid xxx name IGNAME type initiator add wwn wwpn(add wwpns to
already existed initiator group)
Show initiator group
Symaccess sid xxx show IGNAME type initiator
8. Creating a masking VIEW
Symaccess sid xxx create view name mvname sg sgname pg pgname ig igname
9. Verify that the masking view is created or not
Symaccess sid xxx show MVNAME
Symaccess sid xxx list view
10. Verify that the devices are available to the Host or not
Syminq
11. To list the assignments for devices in particular range on particular symmetrix
Symaccess sid xxx list assignments dev xx:xx
12. To display list of devices with no assignments ,
Symaccess sid xxx list no_assignments

Differences between DMX-4 and Vmax:


Interconnect Technology
Max Useable Storage
Max Drives
Max Front-End Ports
Max Front-End Port
Speed
Max Cache
Drive Interfaces
Block Size (Open

DMX: Direct Matrix


Architecture
585 TB
2400
64
4 Gbit

V-Max: Virtual Matrix


Architecture
2 PB
2400
128
8 Gbit

512 Gbytes
2,4 Gbit
512 bytes

1024 Gbytes
4Gbit
520 bytes

Systems)
Microcode
Max Hyper Size
Max Hypers/Drive
Processor

5772/5773
64 Gbytes
128
PowerPC

Thin Pools
1. To show the list of thin pools in symm
Symcfg sid xxx list pools thin
2. To show the list of Tdevs in symm
Symdev sid xxx tdev
3. To check
Symcfg sid xxx show pool poolname details thin

5874
256 Gbytes
512
Intel Xeon

4. To see unbound Tdevs


Symcfg list tdev unbound
Or
Symcfg list tdev unbound
5. To see bound tdevs
Symcfg tdev bound
6. To bind the tdevs to thin pools
Symconfigure sid xxx cmdbind tdev xxx to pool poolname preallocate size=xxx;
preview
Prepare
Commit
Symmetrix Remote Data Facility

Run and connect Fibre cables from the EMC frame to the Cisco Switches
If there no RAs defined, have EMC perform a bin file change to convert some
of the D ports to RF ports (Dynamic SRDF) and enable the FF bit on both the
source and target box.
Zone the source and target RFs on the CISCO switches.
Run symconfigure and set both the R1 & R2 devices to dynamic rdf.
o example: set dev 81b, attribute=dyn_rdf;

1. Create and label the dynamic groups on both source & target
Symrdf addgrp sid xxx -remote_sid xxx dir xxx remote_dir xxx rdfg10
remote_rdfg10 label rdfg10
2. Show rdfg group
Symcfg sid xxx list rdfg all
3. Create pairing and establish R1 and R2 relationship
Symrdf createpair f filename sid xxx rdfg 10 type r1 establish
4. To display RA Ports
Symcfg list ra all sid xxx
5. Set the session priority
Set rdf group 10, session priority=30
6. Create a device group on the R1 side
Symdg type r1 create dg1
7. Add devices to r1

Symld sid xxx g dg1 add dev xxx rdfg10


8. Begin the replication process
Symrdf g dg1 setmode acp_disk
9. Once all devices are synchronized then set mode to async
Symrdf g dg1 setmode async
10. Enable consistency protection
Symrdf g dg1 enable
Conceptually, even operationally, SRDF is very similar to Timefinder. About the only
difference is that SRDF works across Symms; while Timefinder works internally to one
Symm.That difference, intersymm vs intrasym, means that SRDF operations can cover
quite a bit of ground geographically. With the advent of geographically separated symms,
the integrity of the data from one symm to the other becomes a concern. EMC has a
number of operational modes in which the SRDF operates. The choice between these
operational modes is a balancing act between how quickly the calling application gets an
acknowledgement back versus how sure you need to be that the data has been received on
the remote symm.
Difference between Synchronous and Asynchronous
Synchronous

Asynchronous

1. Data is same at source and target


2. distance is 100 km
3. default data is synchronized

1. Data is source symm ahead of target


symm I/O
2. Across the globe upto 1000km
3. Default data is consistent

Operations:
1. Host send I/O to source
2. Source send to the target
3. Target send ack to source
4. Source sends ack to the host
5. Then second I/O starts

Operations
1. Host sends I/O to source
2. Source sends ACK to Host then seoncd
I/O starts
3. Source sends I/O to target
4. Target sends ACK to Source

Adaptive write-pending:
This mode copies data over to the R2 volumes as quickly as it can; however, doesn't delay the
acknowledgement to the application. This mode is useful where some data loss is
permissable andlocal performance is paramount.
There's a configurable skew parameter that lists the maximum allowable dirty tracks. Once that
number of pending I/Os is reached, the system switches to the predetermined mode (probably
semi-synchronous) until the remote symm catches up. At that point, it switches back to adaptive
copy-write pending mode.
Adaptive disk pending:
It will check every thing is there any data send R1 to R2 correctly or not

Synchronous mode
Synchronous mode basically means that the remote symm must have the I/O
in cache before the calling application receives the acknowledgement.
Depending on distance between symms, this may have a significant impact
on performance which is the main reason that EMC suggests this set up in a
campus (damn near colocated) environment only.
If you're particularly paranoid about ensuring data on one symm is on the
other, you can enable theDomino effect (I think you're supposed to be
hearing suspense music in the background right about now...). Basically, the
domino effect ensures that the R1 devices will become "not ready" if the R2
devices can't be reached for any reason - effectively shutting down the
filesystem(s) untilthe problem can be resolved.

Semi-synchronous mode
In semi-synchronous mode, the R2 devices are one (or less) write I/O out of
sync with their R1 device counterparts. The application gets the
acknowledgement as soon as the first write I/O gets to the local cache. The

second I/O isn't acknowledged until the first is in the remote cache. This
should speed up the application over the synchronous mode. It does,
however, mean that your data might be a bit out of sync with the local
symm.

lun unallocation
Luns must be disabled before they can be removed.
symdev -sid xxxx write_disable 2A1
symdev -sid xxxx write_disable 2A5
symdev -sid xxxx write_disable 2A9
Mapfile example for creating meta
form meta from dev 009, config=striped stripe_size=1920;
add dev 00A to meta 009
add dev 00B to meta 009
Create a map file that contains luns to be removed from the FA path:
mapfile.txt (Don't forget the; at the end - a common mistake)
unmap dev 2A1 from dir 8a:0;
unmap dev 2A5 from dir 8a:0;
unmap dev 2A9 from dir 8a:0;
Mapfile example for changing hot spare...should be Temporary - can be done
nondisruptively
set symmetrix hot_swap_policy=TEMPORARY|PERMANENT
Meta Device Creation:
Expanding a lun is called as a meta lun
Open text file in vi editor
Form meta from (head meta name) Config = stripped stripe_size=1920;
Add dev (meta members) to meta (head meta name)
Save
Run the command
Symconfigure sid xxx f filename previw, prepare, commit