Expand storage provision by HSG80

Information Technology, Storage, Windows No Comments »

This entry presents my experience on expanding the logical disks of a Microsoft Exchange server.

Our Exchange server is a Microsoft Windows 2000 advanced box. The Exchange database files reside on 4 logical disks, let say I,K,M,N, coming from LUNs Compaq-HP HSG80 with fabric for redundancy via Fibre channel connections.

LUNs all are configured with RAID10 for redundancy and performance.

In this entry, I demonstrate the update of one logical disk I (I:), tasks of upgrading storage on other logical disks are the same.

I: is configured as a logical disk coming from a LUN with RAID10 on HSG80.

I: is name disk on Windows, under HSG80 its name is D10, and comes from stripe S10, that composes of M10, M11, M12, where M10, M11, M12 are there mirrors. M10, M11,M12 each composes of two SCSI Ultra320 10K 72GB. So size of S10 (D10) is 72×3GB, that is approximately 200GB under Windows.

Here are the configuration of the mirrors M10, M11, M12:

M10 <– (DISK10000, DISK20000)

M11 <– (DISK30000, DISK40000)

M12 <– (DISK50000, DISK60000)

The reason for this storage upgrade is by the time, the exchange server databases grow up and soon we run out of space on I, K, M, N. So we need to upgrade the size of I,K,M,N from 200GB to 400GB. The storage had been proceeded by following steps (tasks on Windows Exchange server will be mentioned short, not in details)

  • Back up all Exchange database files: this can be done by cold-backup,ie, copy all Exchange data files to other location either inside the Exchange server or on the external storage.
  • Stop Exchange services on Windows 2000 server.
  • Shut down the HSG80 fabric with commands:
SHUTDOWN OTHER_CONTROLLER
SHUTDOWN THIS_CONTROLLER
  • Replace 6 SCSI 72 disks of I by 12 SCSI 146GB disks.
  • Turn on SAN HSG80
  • Reconfigure D10, by deleting it, then recontruct D10 with new disks, all command are following
DELETE D10
DELETE S10
DELETE M10
DELETE M11
DELETE M12
INIT DISK10000
INIT DISK20000
INIT DISK30000
INIT DISK40000

INIT DISK60000
ADD MIRROR M10 DISK10000 DISK20000
INIT M10
ADD MIRROR M11 DISK20000 DISK40000
INIT M11
ADD MIRROR M12 DISK50000 DISK60000
INIT M12
ADD STRIPE S10 M10 M11 M12
INIT S10
ADD UNIT D10 S12

Now we have new D10 (new LUN ID) with size is 400GB.

We can do LUN masking from the SAN by using SET, like the follwing

SET D10 DISABLE_ACCESS_PATH=ALL ENABLE_ACCESS_PATH=(MSG1_1A1, MSG1_1A2, MSG1_2A1,MSG1_2A2)

where MSG1_1A1, …, MSG1_2A2 are access paths to the Exchange server.

We are done on SAN HSG80. The next steps are on Excahnge server:

Delete old logical disks because the new disks coming from new LUN IDs. Use Disk Management in Computer Management to rescan new logical disks. Set up, format them then copy back the exchange databases to the new disks. Restart Exchange services. That’s it.

Learn all about LUNs

Information Technology, Storage No Comments »
Source: 09 Jan 2008 | Greg Schulz
LUNs transform raw storage into usable space, accessible from any attached operating system. However, creating and implementing LUNs can be a challenge. In this handbook you’ll learn what LUNs are, how they’re used, how to implement LUNs, how to manage LUNs, how to partition LUNs and the concepts involved in LUN migration.

LUN basics

For open systems environments, including Windows, fixed-block architectures or fixed-block addressing is the most common basis for performing I/O operations to and from a disk drive. The most common I/O command protocol for open systems is the SCSI command set, not to be confused with parallel SCSI cabling, as there is a difference. The SCSI command set is implemented on different network and storage I/O interfaces or transports, such as Fibre Channel, iSCSI, SAS, InfiniBand and others. Part of the SCSI command set protocol is an initiator (source) that requests an I/O operation (read, write or status inquiry) and a target (destination) device with a subaddress known as a LUN. The target can be a single disk in a JBOD array with each HDD having a different SCSI target and possibly a unique or selectable LUN of the device supports it. A common use of LUNs is in storage systems or arrays that incorporate some type of controller, usually with RAID where multiple HDDs are configured and aggregated into a RAID or volume group and then assigned a unique LUN and accessed via a SCSI target ID. For example, assume you have a storage system with 32 300 GB HDDs configured into two separate RAID groups, each with 16 HDDs. One RAID group is a RAID 5 14+1 and a hot spare, the other being a RAID 10 (8+8). The RAID 5 group would have about 4.2 TB of usable capacity, while the RAID 10 group would be about 2.4 TB. The storage system could present a single LUN or volume to a server or servers for each of the RAID groups or, the RAID groups could be subdivided into multiple smaller LUNs for more granular access of the storage depending on specific application needs or preferences. To learn more, check out chapters 3 (Networking with your Storage) and 4 (Storage and I/O Networks) in my book “Resilient Storage Networks” (Elsevier) along with other SearchStorage.com and Storage magazine tips and FAQs, including Tracking down those missing bytes.

Implementing LUNs

LUNs can be created and implemented in various configurations, such as capacity, address, or boot device, along with what host servers can see or access the LUN or volume. Creation of a LUN can be done using vendor supplied management tools or third-party tools. LUNs can be created on storage systems and virtualization appliances along with other storage devices, including virtual tape libraries (VTL). Some third-party storage management tools enable you to create LUNs on different vendor’s storage systems, while other tools simply provide tracking and storage resource management (SRM) information for LUNs. There are a few generic steps for creating a LUN. First, it is necessary to create a RAID group or volume group on the storage system or virtualization appliance mapping some number of unused HDDs or devices together. The next step is assigning a RAID level and then subdividing or “carving” out LUNs from the RAID group assigning manually or automatically address numbers. The number of LUNs supported by a storage system will vary by vendor implementation and storage I/O interface, such as Fibre Channel, SAS, Parallel SCSI, iSCSI, etc., being used. Likewise, various operating systems and virtual servers, including VMware, will have different limits on how many LUNs can be accessed in total and per adapter port on the physical server. Some operating systems also have a default or preference that certain storage, including boot devices, is on certain targets and LUNs. For example, older versions of Windows NT would not recognize nonzero LUNs until upgraded to newer versions and registry entry adjustments. Some storage systems support the notion of partitions where a group of LUNs or volume groups can be mapped into a partition that appears to the host servers as a unique storage system with indicial LUNs. For example, 20 servers could be attached to an LSI/Engenio-based storage system that has four Fibre Channel ports. Assuming that the storage system has 40 total LUNs (or more), 20 partitions could be created with each partition containing two LUNs with one of the LUNs being LUN 0 as a boot device and mapped to a particular server adapter address. Each server would think that it has its own unique LUN 0 for a boot device yet in reality, there are 20 LUN 0s, each isolated from the other in a shared storage environment.

LUN management

Some storage systems support partitions to help allocate unique LUNs to different servers. Depending on implementation, some vendors support partitions that incorporate LUNs from different volume or RAID groups for flexibility, or if a LUN can span multiple storage enclosures and I/O busses inside the storage system to avoid performance contention. Another feature that will vary by vendor implementation is how LUN expansion takes place if supported. For example, vendors will often support on-line growth of RAID or volume groups to facilitate creation of additional LUNs, while others support dynamic expansion of existing LUNs. However, do not assume that all implementations are the same and that dynamic expansion means while data is being read or written to a LUN. Check the details and ask vendor-specific questions as to what it does or does not support and if there are any extra fees for enhanced LUN functionality. In addition to the number of LUNs supported, the size of LUNs supported will also vary by storage system and operating systems. Most storage devices and operating systems today should be able to support at least a 2 TB LUN. Some operating systems can support addressing and accessing of LUNs larger than 2 TB either natively or via upgrade patch kits. For storage systems, look at the total number of LUNs supported by a particular solution or if that vendor has guidelines or restrictions on the number of LUNs that can be accessed on a given physical or adapter port. Also, check to see what limitations on addressing or flexibility exists with volume mapping and masking software features in storage systems to enable specific LUNs to be seen or hidden from different servers. For LUNs being accessed by nonclustered or failover server nodes, typically you would hide those LUNs from other servers so that they are not seen and accessed. Similarly on the server, path management software from vendors, such as Microsoft’s MPIO, IBM’s SDD, Symantec Corp.’s DMP and EMC Corp.’s Powerpath, should be configured to access and support path failover to LUNs accordingly.

Advanced LUN topics

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.
  • To learn more, check out chapters 3 (Networking with your Storage) and 4 (Storage and I/O Networks) in my book Resilient Storage Networks (Elsevier) along with other SearchStorage and Storage Magazine tips and FAQs including Tracking down those missing bytes., or send me a note with your questions.
    WP Theme & Icons by N.Design Studio
    Entries RSS Comments RSS Login