Notes
Capacity is pool driven not device driven
Data's physical placement is on a TDAT
TDEV is mapping to that data
cache is most critical resource
most important thing in cache is track id tables
thin device presented to host
host is irrevelevant to the storage - just sees storage
host generates IO issues read or write off erasure
pre fetcher - sequential data, detects sequential read - move the next seq read to cache assuming that it will be the next read
write is ack'd as soon as it gets to cache
mirrored cache slots are for writes, unprotected cache slots are used for reads (data is safe on disk)
writes that occur get marked as write pending
during vault scenario - data in write pending status gets written down to the vault drives
data in write pending is in the mirrored cache and not written to disk
CACHE Config - check pic in OneNote
Common Area - Ingenuity purposes
Device Table Area - track all data, who owns what - customer data - prod workload - track ids map to this
track id is cache view of the data - copy is on disk and in cache - can be recovered from one or the other
Cache Slots
DMX 32k cache slots for Open Systems and 56K for Mainframe
VMAX standardized to 64K
VMAX3 and Powermax 128k - only open systems - mainframe stays at 64k
Old model is multiple storage resource pools
vmax3 or powermax is one storage pool
**check images for Powermax work flow and caching
Device tables tell us how to map data - device table tells us that a certain cache slot maps back to a particular device block or range on physical disk
Device table is used to find the data through mapping, either in cache or on the disks
Device tables track the data
cache slots hold the data
TRD recovery scans - scans in cache
scans will fix data on disk if disk tables are corrupt
Most important structure for the cache is the track id table (TID)
cache recovery, disks recovery - physical consistency inconsistency
TDATs - physical disks that make up the pool
physical consistency table tracks data
In a pinch you could spin up a "failed" flash drive to be used as a spare if it will be multiple days before you're able to replace it. This way there is at least a spare available. A "failed" flash drive is likely not physically failed.
DMX - No flash
VMAX1 & 2 - FC and SATA
DMX and VMAX1 does the copy to spare and copy back - newer models use a global spare policy
flex RAID - parity isn't from specific drives, but flexible throughout the entire pool
A7, C,, - Inline?
Symmetrix OS
Task Based operating system
As resources are being taxed, priority's can be modified
80% of CACHE slots are available for writes
100% of cache slots are available for reads
When 50% of cache slots are write pending, system goes to an aggressive destaging mode, where data in cache is writing down to the disk backend
Code upgrade - symmwin will run through code process (not modifying a bin) - fast iml of the directors - rolling upgrades - loads all code then does fast iml of the directors - every component is running it's part of the code - 0 downtime - About 45 minutes from getting the code to complete
SNAPVX - pointer based snap shot
Guest OS (VMAX3) - Container - VM with containers - Tools 0 and Tools 1 - STP - Symmetrix Trends and Performance (performance collections and performance reporting) / Unisphere (embedded) - Event Logs and Alert conditions / eNAS (virtual data mover) / eManagement (local Unisphere and Solutions Enabler) /
HBA from host is the initiator > Zone > FE Director (PG (port groups)) >
masking group - HBA WWPN / Zone / SG (storage group)
From Chris on McCormick - A target volume that is larger than the source volume can be linked to the snapshot in either copy or nocopy mode. This functionality is enabled by default. There is an environmental variable SYMCLI_SNAPVX_LARGER_TGT that can be set to prevent larger targets from being used.
symcfg -lockbox verify -ssv
Each MMCS has to connections
MMCS1 - 172.16.255.252
MMCS2 - 172.16.255.253
MMCS1 - 172.17.255.252
MMCS2 - 172.17.255.253