Access Logix is a storage system-based licensed software. This feature lets you enable data access and create storage groups on shared storage systems. This software runs on each storage processor.
Access Logix functionality
- LUN masking – it is an process that makes a LUN available to some hosts and unavailable to other hosts. I describe it a little bit more below.
- Presents a ‘virtual storage system’ – by LUN masking, LUNs are presented only to server(s) which are authorized to see them. In effect, it presents a ‘virtual storage system’ to each host.
- Maps VNX LUNs to host LUNs – mapping VNX LUNs, often called Array Logical Units (ALUs) to host LUNs or Host Logical Units (HLUs). It determines which physical addresses each attached host will use for its LUNs. This feature is configurable by the storage admin.
- Manages Access Control List – access to LUNs is controlled by information stored in Access Logix database, which is resident in a reserved area of VNX disk – the PSM LUN (Persistent Storage Manager).
Access Logix limits
- host may be in 1 storage group per storage system. If you add the same host in another storage group it will be removed from the previous one.
- maximum of 4 storage systems per host
- number of host per storage system – depends on the VNX model
- a storage group is local to 1 storage system
- maximum number of LUNs in a storage group, depenends on a VNX model, eg. VNX5500 – 512
Storage group is a collection of one or more LUNs (or metaLUNs) to which you connect one or more servers. In other words think of a Storage group as a container, when you define:
- list of servers that belongs to that container
- list of LUNs that belongs to that container
All servers within one storage group can access all LUNs that are in the same storage group. This is called LUN masking.
LUN masking vs LUN Mapping
Below is a diagram of a storage system attached to two hosts. Each host has a storage group associated with it – storage group A for Server A, and storage group B for Server B. The LUNs used on the storage system are sequential, from 0 through 7, but it’s not always like that, and actually you can set it up differently if you wish. ALU is Array Logical Unit, and HLU is Host Logical Unit. Each LUN on the storage system (ALU) has been mapped to a LUN number as seen by the host (HLU).
LUN masking vs LUN mapping
The mappings are stored in a translation table, which is part of the Access Logix database. Each server sees the LUNs prezented to it as though they are the only LUNs on the ‘virtual storage system’, represented by the storage group.
Access Control List
When you use Fibre Channel, access to the LUNs is controlled by an Access Control List (ACL) which contains the 128-bit Globally Unique ID (UID) of the LUN, and 128-bit Unique IDs of the HBAs in the host. The HBA UID consists of the 64-bit WWNN followed by the 64-bit WWPN.
Each request for LUN access references the ACL, in order to determine whether or not a host should be allowed access.
Registration is a process of making a host known to the storage system. Connectivity depends on the protocol being used, Fabric logins tell the VNX which ports and HBAs are connected, iSCSI logins tell the VNX which ports and initiators are connected. Registration can be perfomed in a number of ways:
- Automatically, by the Unisphere Agent when it starts
- Manually, through Unisphere or Navisphere CLI
- By using the Unisphere Server Utility
You can compare FAST Cache as a “DRAM cache” but built from FLASH drives, with higher capacity available. Let’s start at the beginning:
DRAM cache – is a storage-system component that improves performance by transparently storing data in very fast storage media (DRAM). It’s capacity is limited and very expensive.
FAST cache technology supplements the available storage-system cache (DRAM cache), adding up to 2 TB read/write FAST Cache. The nice trick is that FAST Cache addresses a hot spot anywhere in the array, both RAID group LUNs and storage pool LUNs. Hot Spot is simply a busy area on a LUN.
How does FAST cache work?
Data on LUNs that becomes busy is promoted to FAST cache. The promotions depends on the number of accesses (read and/or write) within a 64KB chunk of storage, and is not dependent on whether the data already exists in the DRAM cache. If you have FAST VP I/Os from extreme performance tier are not promoted to FAST Cache.
Let’s assume we have a scenario when FAST Cache memory is empty:
- When the first I/O is sent by the application, the FAST Cache policy engine looks for an entry in the FAST Cache memory map for the I/O’s data chunk. At this stage memory map is empty, the data is accessed from the HDD LUN. This is called FAST Cache miss. EMC claims there is minimal performance overhead when checking the memory map for every access to a FAST cache enabled LUN
- If the application frequently access data in a 64KB chunk of storage, the policy engine copies that cunk from the HDD LUN to FAST Cache. This operation is called promotion, and this period is called the warm-up period for FAST Cache.
- When the application accesses this data again, the policy engine sees that it is in the FAST Cache (based on memory map). This is called a FAST Cache hit. Because the data is accessed from the Flash drives, the application gets very low response times and high IOPS.
Incoming I/O from the host application is checked against the FAST Cache memory map to determine whether the I/O is for a chunk t hat is already in FAST Cache. If the chunk is not in a FAST Cache, the I/O request follows the same path it would follow if the storage system does not have FAST Cache. However, if the data chunk is in the FAST Cache, the policy engine redirects the I/O request to the FAST Cache.
FAST Cache read operation
If the host I/O request is a write operation for a data chunk in FAST Cache, and the write cache is not disabled for the LUN, the DRAM cache is updated with the new “write”, and an acknowledgment is sent back to the host. The host data is not written directly to the FAST Cache. When data needs to be moved out of the DRAM Cache, it is written to FAST Cache.
FAST Cache write operation
Write-back operation is the situation when data is copied from FAST Cache to the back-end HDD. This happens when FAST Cache promotion is scheduled but there are no free or clean pages available in the FAST Cache.
FAST VP stands for Fully Automated Storage Tiering for Virtual Pools. It’s a very smart solution for dynamically matching storage requirements with changes in the frequency of data access. FAST VP segregates disk drives into three categories (already explained in EMC VNX – RAID groups vs Storage Pools) called tiers:
- Extreme Performance Tier – Flash drives
- Performance Tier – 15k and 10k SAS drives
- Capacity Tier – Near-line SAS drives (that can be up to 4TB in size)
The main feature of FAST VP is reduce Total Cost of Ownership, by maintaining high performance, using mix of expensive and cheaper disks. The main idea is based on the fact, that only part (usually not more than 5%) of the data is accessed frequently. Based on that sentence we can put those “more-active data” located on Heterogenous pools on higher Tier to lower the read response time. Look at the picture below showing before/after.
FAST VP before/after effect
FAST VP is automated feature which implements a set of user-defined tiering policies to ensure the best performance for various environments. FAST VP uses an algorithm to make data relocation decisions based on the activity level of each slice. It ranks the order of data relocation across all LUNs within each separate pool. Available LUN level policies are:
- Highest Available Tier – this policy is used when quick response times are a priority. The Highest Available Tier policy starts with the hottest (fastest) slices first and places them in the highest available tier until the tier’s capacity or performance capability limit is hit.
- Auto-Tier – a small portion of a large st of data may be responsible for most of the I/O activity in a system. This policy allows for moving a small percentage of the ‘hot’ data to higher tiers while maintaining the rest of the data in the lower tiers. The Auto-Tier automatically relocates data to the most appropriate tier based on the activity level of each data slice. LUNs set with Highest available Tier take precedence in case of limited capacity of high tier.
- Start High then Auto-Tier – This policy is default for each newly created pool LUN (on heterogenous pools obviously). It takes advantage of the Highest Available Tier and Auto-Tier policies. Start High then Auto-Tier sets the preferred tier for initial data allocation to the highest performing disk drives wich available space. After some time it relocates the LUN’s data based on the performance statistics and the auto-tiering algorithm.
- Lowest Available Tier – this policy is used when cost effectiveness is the highest priority. Data is initially places on the lowest available tier with capacity. It’s perfect for LUNs that are not performance or response-time sensitive. All slices of these LUNs will remain on the lowest storage tier available in the pool, regardless of their activity level.
- No Data Movement – this policy can be chosen only after a LUN is created. Data remains in its current position, so the performance and response-time is predictable. The data can still be relocated within the tier, and the system still collects statistics on these slices, so if you change the policy (for example to Auto-Tier) the Storage Array has all necessary information to move portion of data to appropriate tiers.
Data relocation is a process that moves the data between the available tiers within the storage pool, accordingly to the chosen tiering policy and collected statistics of LUN’s slices. You can set the Relocation Schedule or manually start the process. The Data Relocation Status can have three values:
- Ready – no active data relocations
- Relocating – data relocations are in progress
- Paused – all data relocations for system are paused.
Manage Auto-Tiering window
As I mentioned before FAST VP feature allows for automatic data relocation based on a user-defined relocation schedule. The schedule defines when and how frequently the array starts data relocation on the participating storage pools. The Data Relocation Schedule section enables you to define the operational rate for the data relocation operation. Values are low, medium, high. Low has the least impact on system performance, high has the most impact. The default value is medium.
Using FAST VP for file
To create filesystems you have to begin by provisioning LUNs from a block storage pool with mixed tiers. Provisioned LUNs are added to the ~filestorage Storage group. After performing a rescan of the storage system a diskmark operation is started that presents the newly created storage to a new file storage pool. If the Block pool LUNS used for creating File Storage Pool were created with FAST VP enabled, the File Systems will use this technology as well. Take a look at the picture below:
FAST VP for file workflow