This action might not be possible to undo. Are you sure you want to continue?
The host systems connect via the Front End. This forwards read/writes to the Global Memory Cache which may then forward read/writes to the Back End, as required. Read process: Check the Global Memory Cache. If the data is found, return it. Otherwise, forward the read request to the Back End, retrieve the data, place a copy in the cache. If there is a Cache hit, respond immediately, responding at memory speeds. Write process: Write to the Cache, the data is placed in the cache as “Write pending” and the user is informed of a successful write. The data is then written to the Back End asynchronously. If applicable, multiple writes can also be combined into a single transaction, thereby improving performance and minimizing disk accesses. VMax emulates physical disks, hence the detailed information about tracks, sectors, cylinders, etc. This is to be changed later to block level storage. Symmetrix presents the abstraction of a disk drive, i.e. a set of block addresses − Each device is assigned a unique identifier − Each device has a maximum size of 240GB − Meta devices can be created to break the device limit − A meta device is a concatenation of many separate devices which are presented to the host as a single device. Some caching rules − Each device only gets 4% of total cache − Each device gets only 5% of write-pending cache These rules ensure that not only one device hogs all cache. − If Cache usage < 50% − Front End has priority − If Cache usage ≥ 50 and Cache usage < 80% − Front End and Back End have equal priority
x > General Reference . each engine has 2 directors. FibreChannel. meaning that we have between 2 and 16 directors. using SCSI commands The Symmetrix needs one SYMAPI server which is directly connected to the Symmertix More information is on Powerline: Home > Support > Technical Documentation and Advisories > Software ~ S ~ Documentation > Solutions Enabler > v7. containing information about − Directors − Memory − Physical devices − Software The bin file is created on the service processor by SYMWIN Changes to this file can be made online The bin file is also located on each director The Symmetrix Stack SMC runs on a tomcat server It interfaces to the Symmetrix via SCSI. Director board The directors share most of their memory via the System Interface Solution Enable (API & CLI) The bin file describes the configuration.− If Cache usage is ≥ 80% − This means that the host write faster than the Back End can write − This in turn means that we have a high write pending rate − Back End has priority − In this case. create Meta devices with more spindles to spread the write over many physical devices Maximum Meta device size: 255 * 240GB = 59TB Symmetrix has at least 1 and at most 8 engines.
This is a flat file containing − Operational data − Physical/logical configuration information − User defined information − Resides on host sstem in Root\EMC\symapi\db\symapi_db. The gatekeeper is like any other volume. The license keys are located in SYMAPI/config in a flat file . the host creates a general information section in memory. Per management server.General architecture Relationship between SYMAPI and CLI − Both do the same thing − both use the same dlls − API more granular − CLI invokes multiple API calls Upon opening a connection. Event log: Who was doing what and at what time. The event log is a 40MB circular file which can be consolidated into a long file. It should be small (<10MB) and shouldn't be used for anything else.blocks. It has a channel addresses.bin First step: populate DB to ensure DB is up to date All communication is done via the gatekeeper . used for command and control. use 5 gateways The Solution Enabler documentation documents error codes. containing configuration information.
When a drive fails. There are at most 512 hypervolumes for each disk. or there are soft errors (re-reads. A disk with RPM 0 means that the device is a flash drive. Disk status codes: Ready: read/write not ready: no reads nor writes write disabled: no writes Service states: Normal . The idea is that the data is spread over as many physical spindles as possible. When Symmetrix volumes are created. etc). we can always calculate between VMAX cylinder usage and MB: 1 Cyl = 15 * 8 * 16 * 512 = 983040 Bytes This is a standard for the VMAX. Tiers are based on Disk Groups New volumes are spread evenly across all disks in a Disk Group Maximum number of DGs: 255 DG 0 is reserved for hot spares! For this reason. Disks are grouped into physical disk groups.2K. Each device has an internal unique hex identifier. This means that only a reconfigure and not a copy is needed.Some Information about Disks The part of a physical disk to which a Symmetrix device maps is called a hypervolume. For flash drives. 7. space is allocated from a Disk Group (DG). the spare becomes a mirror and the broken drive becomes a non-functional spare. the SymDefName Each device is looking as follows: 1 Cylinder = 15 Tracks 1 Track = 8 Sectors 1 Sector = 16 Blocks 1 Block = 512 Bytes Therefore. 1 spare for 32 drives. etc). RPM speed (15K. the capacity is zero. Spares: If a drive fails. this will trigger a sparing policy Spare policy: At least 8 spares or 2 for each 100 drives of each kind. for example) at an increasing rate. but is different for other Symmetrix devices! Metavolumes The maximum device size is about 240GB This can be circumvented by using Metadevices: This means that several devices are grouped into one metadevice which is seen by the host as a single device. or Flash). normally according to the device types (sorted according to type (SATA.
SMC Notes Double click on the sid ID: same as symcfg list command Click on a device: Same as symdev list and symdev show Creating a new device: Right-click on the sid ID → device config → create device: same as symconfigure The command history is shown on the SMC but not the actual commands Symmetrix Performance Analyzer is a tool which gives the heat map of a Symmetrix The next version should support full features Actual capacity = capacity Cache is shown as actually usable cache. same as for a concatenated. striping data across all data devices. we can see the different number of steps. Striped devices can be converted to to concatenated but this is difficult. the host must be able to handle the geometry change. Furthermore. each of these steps can have sub steps. so only half of the actual capacity is usable. Dissolving a meta device . Striped is better for random reads Extending striped is difficult to see for host.Failed Degraded: Data still okay but the copy is gone. This is tedious and slow! Removing devices from a striped array is difficult. It can be done online but you have to copy all data to a mirror which must be identical to the original devices. if we run the CLI. Concatenation Sequential reads: Read device 1 from start to finish. Cache is mirrored. In the latter case. then read device 2 from start to finish Striped read: Read from device 1 sectors 1 and 2. Configurations The configuration session goes through the following steps Preview Prepare Commit Checks the syntax and the command structure Run preview checks and check whether the Symmetrix will support the changes Run preview and prepare steps and then perform the actual changes (commit) The commit must not be interrupted! Hence. then go to device 2 and read sectors 1 and 2.
Migration During a migration task. . Subscription rates can go from 0% to 65534% − Then bind TDEVs to pool.This breaks apart the meta device but the actual devices and the data stored there is save Rule: Never abort commits! After a change. there is a lock on the Symmetrix To perform a migration. Migrations can be done automatically based on policies (for example. once added thez become res/write enabled First tracks will be written immediately Symaccess is better to get the active logins. If a thin device does not belong to a pool. Always enable lots to increase striping performance. make sure that target and source have the same size and that the target is not a thin device. These will be added to the pool. Protection is provided by the pool they belong to. its state will be “not ready”! Building pools for thin devices − Bigger pools are better − Check the I/O consumption and the base pool size − Create Data devices. The pool size can be increased by adding more data devices. add data devices to pool and enable them. usage policies) Virtual provisioning Thin devices (TDEV): Collection of pointers to locations where the data is stored. Data devices not added to a pool have the status “Disabled”! − Increasing the size of thin devices can be done by creating multiple thin devices and adding them to a meta volume − Create a thin pool. do a discover to update the database file Groups Storage Group: All devices available to server/application/cluster Port Group: Subset of all devices visible Initiator Group: All HBAs of server/cluster One device can be in multiple storage groups. symmask is deprecated.
32. Thin devices stripe data over the data devices. This means that a meta device snap can still have 128 sessions but that each device within the meta also is used 128. The thin pool can be over provisioned. Snapping Meta Devices Meta devices are snapped by first snapping their subdevices. For VDEVs. Device Groups and Composite Groups Device Groups are limited to one Symmetrix array. If a composite group is a target then set the -tgt option when creating the group → this ensures that everyone knows which . all changes to the to the TDEVs are stored and striped over the save devices. 48. 60GB The number of devices in the pools can be adjusted dynamically. It is recommended to use Composite Groups.Snapping DD: Data Devices SD: Save Devices The size of DD and SD should be somewhere between 16. The problem with composite groups is that all drives in all arrays have to reflect the same point in time. Composite Groups can span multiple Symmetrix arrays. Once this step is complete. The grouping information is stored locally. as these are more flexible. the new devices are also combined into a meta device. GNS is used in the case of the CG covering multiple arrays.
Cloning and Snapping restrictions Cloning of a clone of a thin device is not possible. mission critical data A: RPO in seconds.unlimited distance. write ordering not maintained. some data loss DM: Data transfer between Symmetrixes. no performance impact. data at the target could be old and inconsistent Writing with SRDF/S: host writes to Symmetrix. . A snap of a thin device can be created. A snap of a cloned thin device does not work. production copy) R2: target (secondary. A snap of a snap of a thin device is not possible. only complete data sets are accepted. external array writes.group is the source and which is the target. SRDF/DM: Data Mobility between Symmetrixes. the Symmetrix confirms the write and sends the data to the external array. A thin device can be cloned. nothing else can be done with the resulting copy. no data loss SRDF/A: Asynchronous data backup for extended distances. Symmetrix writers to external array. the DRX flag must be set SRDF/S: Synchronous data protection. A composite group cannot contain another composite group. limited distance. Symmetrix Remote Data Facilities (SRDF) For a device to use SRDF. confirms the write. minimal performance impact. BC/DR ops) Configurations can be − Bidirectional − Souirce/Target Swap (personality change) − Concurrent and Dynamic − One to n − n to one − n to n S: Some performance impact. This means that once a thin device is cloned or snapped. nearly unlimited distance. data transfer in the form of data sets (data set: A collection of writes). the local Symmetrix writes and confirms the write to the host Writing with SRDF/A: The host writes to the Symmetrix. unless the clone is finished and the cloning session is terminated. unless the clone of the thin device is done and the session is closed. used for content distribution R1: source (primary copy.
even for remote ones . the database is up to date Show all running daemons Gives commands that were executed and individual messages for each command All environmental variables that can be set All environmental variables that are currently set Gets the log file which is stored on the Symmetrix The free space on the system Displays version number Gets environment information Query all devices it sees (within the Symmetrix and the external ones) Information obtained from standard SCSI Health of the Symmetrix Lists all directors A-D: Front End E-H: Back End Show all Back End directors and status -SA: SCSI adapter (Front End) Gives details as to which ports are online.Free = Free capacity .Interesting Commands Command symcfg discover symcfg list symcfg verify -sid symcfg -services list symcli_debug= symcli_debug=[32 | 64 | 128 | 256] symcli -env symcli -def symaudit symconfigure -sid -freespace symcli symcli -env syminq symcfg list -env_data symcfg list -dir ALL list -sid symcfg -DA all list -sid symcfg -FA all -ports list -sid symcfg -memory Description .This command may be slow List of Symmetrix devices that can be accessed (remote and local) Gets a checksum from the Symmetrix and checks with the checksum from the database. i.Total = Total space available .Actual = same as Total Details about physical disks Shows disk groups Lists devices that are using hot spares Gives information about failed hot spares symdisk list symdisk list -sid -v|more symdisk list -by_diskgroups symdisk list -hotspares symdisk list -spare_info -v . If they are the same.Populates db for every Symmetrix it can see.Hypers: Hypervolumes that use the disk . which have cables connected Displays global memory: Slot number = director board Information about the physical disks .e.
syminq symcfg -fa all list -port -sid symaccess list logins -dir [director] -p [port number] symdev list -noport symcfg list -FA -address -available symaccess -sid create type [storage | port | initiator] -name -dir [director:port] symaccess -sid create view -name -storgrp -portgrp -initgroup symmigrate For striped. back end information and capacity but not the used capacity All devices on the Symmetrix with more details on the ones the host can see (m) grouped (M) Metahead = seen by host. bcv_meta_head=[name]. front end. etc All devices that are in state notnormal Only one change session at a time is allowed Determine if a lock is currently held Check if the Symmetrix supports host-initiated configuration changes Shows all unconfigured space How to run the command that is normally stored in a file symdev show [dev number] -sid symdev list -service_state notnormal symconfigure symdev list lock symconfigure verify symdev list -da all -space symconfigure commit -cmd “[some command here]” form meta from dev[device name] Forms a meta device from an existsing device. port or initiator group. protection level. connected) Gives port and connection status. The initiator group does not require the -dir Creates a masking view of the listed groups. gives port. you have to specify the stripe size Note the protect_data parameter. if it is set to false. show which addresses are still available Creates a storage. protect_data=true. port status (is it online. data will be lost Status of each HBA. x means a port is connected to a cable Shows connectivity between SAN and HBAs Devices not mapped to a front port For a Front End director. WWN. config=[concatenated | striped] count= [nunber] Also works with multiple devcies form meta from dev[device name] config=striped strip_size 1 cyl add dev [name] to meta [name].Command sympd list symdev list Description Outputs the Sym device number. such as where it resides. Symmask is deprecated for the Symmetrix Migration command . total capacity of the group is shown Lots of data about a device.
This action might not be possible to undo. Are you sure you want to continue?