YESTERDAY: Implementing LUNs
Many storage systems support data migration or LUN migration, however, the devil is in the details. Some vendors support movement of data while a LUN is being read and written, while others can automatically move data based on policies when there is no write activity. Ask your vendor if it supports movement of the data in an entire LUN while applications are actively reading and writing to the LUN and what its caveats are.
Investigate how a vendor supports LUN affinity and cache coherency. Even though a LUN may be accessible via two or more controllers, nodes or processors, find out if one controller owns or acts as a primary to maintain data integrity and if so, how are the I/Os moved or "shipped" between the controllers to maintain cache coherency without negatively impacting performance.
Besides using host-based third-party or operating system supplied volume managers, LUNs can be created from standalone storage devices that support selectable subaddressing, in addition to specifying SCSI target addresses. LUNs can also be created and run on standard servers as appliances or on special purpose services blades in SAN switches.
Below are some important things to remember:
-
Avoid performance contention between LUNs by avoiding allocating LUNs from the same RAID group to active and competing workloads if possible
-
Exercise caution creating RAID groups factoring in where HDDs exist in enclosures and on what internal busses to avoid contention
-
Exercise caution intermixing various types of HDDs of different capacity, speeds and interfaces adhering to vendor recommendations and guidelines
-
Understand what performance impacts to LUNs when re-sizing, migrating or performing other operations including snapshot copies or replication
-
Follow vendor guidelines pertaining to creating large RAID groups of many HDDs vs. multiple smaller ones factoring that vendor's specific architecture capabilities or limitations.
