The Symmetrix V-Max (TM) system, fully configured, can:
- export thousands of logical units of data (LUNs)
- serve hundreds of applications consuming these LUNs
These numbers will grow over time.
That is one large system. In fact, calling it 'large' is an understatement. The size and scale of the V-Max requires innovative solutions to the following questions:
- how in the world do I allocate that many LUNs?
- how do I connect the LUNs to the applications that consume them?
- how do I configure alternate paths to the LUNs in the case of a failure?
- how do virtualized applications start up on different servers and still see the same LUNs?
- how do I diagnose and repair applications with underperforming LUNs?
- how can I configure replication on this many LUNs?
- how large of a team will I need to take care of all the plumbing of application to storage?
- can the team work on parallel tasks at the same time?
A big part of the V-Max introduction (and quite possibly the most important part) is the new user interface that is purpose-built to manage at massive scale. Here's how it works.
1. Templates and Storage Groups: Automated "Find or Define"
Traditionally a storage administrator manually selects and configures the low-level disk segments that are dedicated to a given application. This is known as "define". This process is too manual for a V-Max scale system.
Alternatively, a storage administrator may have to "peruse" hundreds of pre-configured LUNs and reserve the ones that fit a given application. This is known as "find", and is also much too time-consuming at scale.
Traditional “find or define” can require a manual search through all the LUNs or a manual search through all of the free space.
For V-Max, the Symmetrix Management Console (SMC) has introduced the concept of "storage templates". An administrator creates templates for their particular application (e.g. My_DB_Disk_Template), specifies the capacities and characteristics (e.g. RAID level), and then specifies “Find”, “Define”, or “Best Effort”. The template can then be saved. The screen shot below highlights the process of creating a template.
Templates can be handed to a junior administrator having little to no knowledge of how to find or allocate storage on a Symmetrix system. These administrators can carve out physical storage from V-Max by creating a “storage group” (e.g. My_DB_Storage) based on the template. SMC creates the group by automating all of the low-level V-Max commands based on the template. There are no disks to select, and no device numbers to remember. The process of creating a storage group from a template is shown below.
2. Group Ports Together
Once the LUNs for a given application have been created, the next step is to select a set of storage ports to associate with these LUNs. Storage admins create port groups (e.g. My_DB_Ports) that will be associated with storage groups in a subsequent step.
3. Group Initiators and Automate the Connection
The final step of the end-to-end connection of V-Max storage occurs by creating an Initiator Group. This task simply creates a group of initiators (e.g. My_DB_Initiators) that will ultimately access storage groups through a given set of storage ports.
At the end of this process the administrator simply creates a “view”, which associates the three groups (My_DB_Storage, My_DB_Ports, and My_DB_Initiators). SMC automates the assignment of storage to port, and automates the mapping/masking of storage to initiators. This has traditionally been a very manual process that is now automated for V-Max.
What’s more, SMC automates the assignment of LUN numbers so that virtualized applications always consume the exact same LUN numbers (no matter what path they choose). A critical feature known as Volume Dynamic Addressing (VDA) is used to accomplish this task. No matter what server the application runs on, VDA ensures that the exact same LUN numbers are presented.
Think About It
A storage admin uses a template to form storage groups, creates port groups, creates initiator groups, and then tells V-Max: "make it happen". Sound easy?
It has to be. If it wasn't, then a V-Max at scale would be unmanageable.
Read 'Zilla's post about auto-provisioning in an ESX environment.
The Value of Templates
One can see how the introduction of application-based storage templates makes the initial setup of application storage much more automated. Dozens of low-level Symmetrix commands occur automatically from a high-level interface. The benefits of storage templates, however, go well beyond initial setup:
- Replication relationships can be specified within the template. Dozens of R1-R2 replication commands are automated using this streamlined approach.
· Application running poorly? LUNs in the storage group currently on SATA drives ? SMC's LUN Migration wizard can search for candidate FC drives, automatically create the required raid groups(if necessary) and perform the non-disruptive LUN migration. The application connections remain intact and the migration results in increased application performance.
· Application running out of capacity? Want to add 9 GB of SATA RAID-1 storage on the fly? Use a template to dynamically enlarge a storage group (see diagram):
The ease of expanding storage on V-Max highlights one of the more intangible benefits of SMC's template-based approach: the ability for a small team of people to manage huge amounts of application storage. Some of the benefits are listed below:
- While it's handy to know all of the underlying Symmetrix commands for connecting storage to applications (for all three steps), it's no longer strictly necessary.
- One administrator can manage storage needs for dozens of applications using a template-based approach. Once the number of applications reaches into the hundreds, more staff can be added (if desired), and storage can be managed per application(s).
- Traditional Symmetrix configuration changes required the reservation of a global lock. This lock often prevented other admins from making changes to a different part of the system. V-Max has increased the granularity of the lock. Dynamic changes (e.g. port assignments) no longer use a global lock but lock separate objects instead. This allows for parallelization by multiple storage admins.
- Static configuration changes (such as migrating application data to a different storage tier) still require a global lock but only at the beginning and at the end of the migration process.
No Guesswork
This is a long post (for me!), but it's been necessary in order to emphasize the scope of changes that have occurred to SMC in order to support a system of V-Max scale. The requirements for these changes came straight from Symmetrix customers that have been pushing the boundaries of massive scale for years. In fact, the V-Max architectural vision was shared with customers as early as 4-5 years ago, and customer's ease-of-use suggestions have been realized in the SMC V-Max interface.
Steve
Comments