After installation of the iSCSI Initiator and rebooting the Windows server, you are now to connect the initiator...
to iSCSI target LUNs. In this example, I have created two volumes on the iSCSI SAN that are part of a volume group named SF-VG01; the volumes are SFEX01-MB01 and SFEX01-LOGS01 (see Figure 3.7).
On the Open Filer virtual SAN, I need to edit each iSCSI volume that I have created and allow access from a particular IP subnet. In this case, I'm going to allow access to the iSCSI volume from computers on the same subnet (see Figure 3.8).
The ability to configure and allow access to a LUN based on IP address will vary from one iSCSI SAN to another, so refer to your iSCSI SAN vendor or documentation to determine whether this step is necessary and how to perform it. Alternatively, I could also configure CHAP authentication to the iSCSI volumes, but that is not necessary in this configuration.
Next, we need to configure the iSCSI initiator. To do so, locate the iSCSI Initiator in Control Panel (or on the Desktop), and run it. Figure 3.9 shows the General property page of the iSCSI Initiator; notice the Initiator Node Name.
Figure 3.9 General property page of the iSCSI Initiator.
The Initiator Node Name is automatically generated and is intended to be unique on your network. The node name in Figure 3.9 is iqn.1991-05.com.microsoft:sfoex01.colonialfleet.local. This includes the DNS domain name of the Windows server as well as additional information placed there by the iSCSI initiator. iSCSI initiator and target names that start with iqn are called iSCSI qualified names. The format for the first part of an iqn name is iqn.year.month.reversedomain followed by a colon, followed by the DNS domain name of the host or initiator. If the name is part of a target volume, it will include the volume group and the volume name.
NOTE: Though you can change the Initiator Node Name, I recommend keeping it at the default to keep things as simple as possible in your configuration.
The first thing we need to do is to locate the iSCSI targets we are going to be using for this Windows server. Figure 3.10 shows the Discovery property page of the iSCSI Initiator Control Panel application. From the Discovery property page, I specify either the iSNS servers I will use to locate targets and initiators or I can specify the IP addresses of the iSCSI SAN.
Figure 3.10 Locating the iSCSI targets.
As Figure 3.10 shows, I manually specify the IP address of the iSCSI target I am using for this example. Under the Target Portals section, click Add to see the interface that allows you to add iSCSI SANs. Figure 3.11 shows the Add Target Portal dialog box. All that is actually required is the IP address or DNS name of the iSCSI SAN and the remote TCP port number (3260 is the default).
Figure 3.11 The Add Target Portal dialog box.
If you click Advanced, you will see the Advanced Settings property page (see Figure 3.12). For a small environment or a lab setup, you can keep all the default settings found on the Advanced Settings. One time you might need the Advanced Settings property page is when the target system requires CHAP authentication or mutual authentication. CHAP authentication provides very basic security while mutual authentication not only requires the initiator to authenticate with the target but also the target to authenticate with the initiator.
Figure 3.12 Advanced settings when configuring a target portal.
You are reading tip #4 from "iSCSI SAN storage for Microsoft Exchange -- 5 tips in 5 minutes," excerpted from Chapter 3 of the book "The Shortcut Guide to Exchange Server 2007 Storage Systems," by Jim McBee, copyright 2007, published by Realtimepublishers.
If you are configuring CHAP authentication, the default user name is the local Initiator Node Name. You must also specify a shared secret that must also be configured on the target volume. If the remote iSCSI system must also authenticate the connection, you can specify mutual authentication.
If you are concerned about network-level security (encryption or authentication), enable IPSec between the initiator and the target systems. The Windows iSCSI Initiator supports IPSec, but not all iSCSI SANs do, so check with your vendor.
NOTE: Always follow the iSCSI Initiator procedures provided by your iSCSI SAN vendor. Vendor-provided procedures will always be more accurate than the generic advice I am giving you here or that you will find in Microsoft's documentation.
Once you have finished configuring the target portal information, you can move on to the Targets property page (see Figure 3.13). From here, you can see all the targets that were discovered when you specified target portals on the Discovery page. If the targets for your remote iSCSI SAN do not show up, click Refresh. If they still do not show up, you might have an authentication issue or the IP address of the initiator is not allowed to connect to the target volume.
Figure 3.13 Configuring remote iSCSI targets.
By default, the Status of these targets will be Inactive. For each of the targets you want to use, you will need to select each one and click Log On. Notice the target name of this volume is iqn.2006-01.com.openfiler:sf-vg01.sfex01-logs01; this name includes the volume group name (sf-vg01) and the volume name (sfex01-logs01).
Figure 3.14 The Log On to Target dialog box.
If you are setting up iSCSI volumes for use with applications that require the volume be available when the application starts, such as Exchange or SQL Server, make sure that you select the Automatically restore this connection when the system boots check box. Doing so ensures that the target is connected on reboot; this is also called a persistent connection.
NOTE: From the iSCSI Initiator Control Panel application, you can remove target volumes. You can also remove the volumes completely by stopping the Microsoft iSCSI Initiator Service. Under no circumstances should you do so while Exchange or SQL databases are active and using iSCSI targets. This will corrupt the data residing on these LUNs just as if you had pulled the plug on a physical disk drive.
After you have connected the targets to this system, it is almost time to partition and format the new volumes that are available to this Windows server. However, before you do so, it is a good idea to get the information necessary to uniquely identify each of the iSCSI volumes. This is not necessary if you are only using one or two target volumes or if they are different sizes, but trust me, this will become valuable on a larger server.
First, take note of the target name, specifically the part that shows the volume name that was created on the iSCSI SAN. In this example, the volume name is SFEX01-MB01. On the Targets property page of the iSCSI Initiator, select each target and click Details. Then select the Devices property page and click Advanced; this shows the Device Details properties. On the Device Details General property page (see Figure 3.15), take note of the SCSI Address information; in this case, Port 2, Bus 0, Target Id 1, LUN 0.
Figure 3.15 Viewing the device details including the SCSI Address.
In the case of this example, I would create a table for this server that documents the SCSI Address and the volume name. Table 3.1 shows an example table for server SFOEX01.
Table 3.1: SAN volumes and SCSI addresses.
|iSCSI SAN Volume Name||Volume Size||Local SCSI Address||Device Id|
|SFEX01-LOGS01||500MB||Port 2, Bus 0, Target Id 0, LUN 0||1|
|SFEX01-MB01||1.2GB||Port 2, Bus 0, Target Id 1, LUN 0||2|
Once you have documented the SCSI Addresses of all your targets, it is time to move on to the Windows Disk Management console (found in Computer Management). From here, we'll partition and format the disks. When you first launch the Disk Management console, Disk Management will recognize there are new disks that do not have a disk type associated.
NOTE: iSCSI-based volumes should always be configured as basic disks. Do not initialize them as dynamic disks.
The Initialize and Convert Disk Wizard will automatically run; you should select Next to continue with the wizard. On the Select Disks To Initialize screen (see Figure 3.16), make sure that all unrecognized disks are selected, then click Next.
Figure 3.16 Selecting disks to initialize.
Figure 3.17 shows the next screen of the wizard—the Select Disks to Convert screen. By default, the disks will be initialized as basic disks; however, this screen gives you the option of configuring these disks as dynamic disks. Ensure that the new iSCSI disks are not selected to be converted, and click Next. SAN disks should always be basic disks; this is true also for any volume that will be part of a Windows cluster.
Figure 3.17 Ensure that iSCSI SAN volumes are not converted.
Once you have ensured that none of the new disks will be converted to dynamic disks, click Next. On the Completing the Initialize and Convert Disk Wizard screen, click Finish.
Figure 3.18 shows the Computer Management console, the Disk Management container, and the new iSCSI volumes. Disk 1 and 2 are the new iSCSI volumes that have been assigned to this Windows server. It is pretty easy to determine which disk is for which purpose because Disk 1 is 510MB and Disk 2 is 1.18GB.
NOTE: The disk sizes are quite small and just for illustrating this example.
Figure 3.18 Viewing the new iSCSI disks.
We can match up each of the disks with the actual SCSI ID by selecting the disk drive (such as Disk 2), then right-clicking, and choosing Properties. This will show us the properties of the disk drive from the perspective of Windows. Notice that the location of the disk is Port(2) Bus 0, Target ID 1, LUN 0. This matches up with SAN volume SFEX01-MB01, which I had intended to be used for a mailbox database.
Figure 3.19 Properties of a disk using the Windows Disk Management console.
I now need to create a partition on each of these disks, assign the disks to a drive letter or mount point, and format the disks. On Exchange Server systems that require more than 20 volumes, you would assign the disks to mount points rather than drive letters; if you do not use mount points, you will run out of drive letters to assign to the volumes. To set up the disks, follow these instructions:
- Right-click the unallocated space on each disk and choose New Partition.
- On the Welcome to the New Partition Wizard page, click Next.
- On the Select Partition Type page, select Primary Partition, and click Next.
- On the Specify Partition Size page, ensure that the maximum size of the disk is being used for the partition. When finished, click Next.
- On the Assign Drive Letter or Path page, specify the drive letter or configure a mount point. When finished, click Next.
- On the Format Partition page, ensure that the NTFS file system is selected, that the allocation unit size is set to the Microsoft recommended value of 64K, and specify a useful volume label. When finished, click Next.
- On the Completing the New Partition Wizard screen, click Finish. The partition will be created and formatted.
Figure 3.20 Specifying the file system type and allocation unit size.
These steps offer one procedure for partitioning and formatting a disk. Although this method is by far the simplest, you can also use the Windows 2003 SP1 utility diskpart.exe. The advantage of using diskpart.exe is that it allows you to create the partition so that it is evenly aligned with the 65th sector of the disk. I'll go into this in a little more detail in Chapter 4, but essentially the first 63 sectors of a disk are reserved for the boot sector (even if the disk is not bootable). This means that the first sector of the disk that is usable by partition will start on the 64th sector, but this means that the first logical sector spans multiple disk I/O boundaries.
For this reason, it is better to start the disk partition on the 65th sector rather than the first one available (usually the 64th); check with your SAN vendor to confirm that this is true for your storage system. In general, it is a good practice to create your partitions this way. Thus, we want the first partition to start on the 65th sector; because each sector is 512 bytes in size, the first sector should start at 32768 bytes.
To create a partition using this approach, open a command prompt and run diskpart.exe. This will offer the following output:
Microsoft DiskPart version 5.2.3790.1830
Copyright (C) 1999-2001 Microsoft Corporation.
On computer: SFOEX01
Next, we want to list information about all the disks; I use the list disk command to do so:
DISKPART> list disk
|Disk 0||Online||16 GB||8033 KB|
|Disk 1||Online||510 GB||0 B|
|Disk 2||Online||1208 GB||1208 GB|
Notice the output from the list disk command shows that for Disk 2, there is still 1208MB of free disk space. This is the disk that has not yet been partitioned or formatted. The Disk 2 referred to at the command line is the same Disk 2 we see in the Disk Management console, but you can confirm that it is the same physical disk using the detail disk command. Note that I must select the disk using the select disk 2 command before I can use the detail disk command.
DISKPART> select disk 2
Disk 2 is now the selected disk.
DISKPART> detail disk
Openfile Virtual disk Multi-Path Disk Device
Disk ID: 7739E0FB
Type : iSCSI
Bus : 0
Target : 1
LUN ID : 0
There are no volumes.
Notice that Disk 2 is Target 1, LUN ID 0. Now that the disk is selected, I can use the create partition command to create the partition. The align value is in KB, so I want to specify 32KB so that the first sector starts at 32,768 bytes (32 * 1024):
DISKPART> create partition primary align=32
DiskPart succeeded in creating the specified partition.
Once the partition is created, I can assign the partition a drive letter or a mount point and then format it. This can be done via the GUI.
NOTE: The allocation unit size for the disks should be 64KB when formatting the disks.
Finally, for each disk that I have created, I am going to create a text file that I call a marker file. The file name will have some information about the server to which the disk belongs, the local drive letter to which it should be assigned, and the SAN volume from which it came. For example, for the G drive that holds the transaction logs on server SFOEX01, the SAN from which the volume originated, and whose iSCSI SAN volume is SFEX01-LOGS01, I will name the file as follows:
Let's break down the file name so that you can see the different parts:
Server name SFOEX01
Disk drive Drive-G
SAN name SF-SAN01
SAN volume SFEX01-LOG01
If the volume is a mount point instead of drive letter, you could substitute information about the mount point and where it is supposed to be found.
If you work with clusters or if you ever have to reconfigure your LUNs to reconnect to your Exchange Server, this will prove to be one of the most valuable 60 seconds you ever spent. The file does not have to contain any data, though you can certainly put some text in the file so that it is not 0KB. I also recommend that you mark the file as read-only so that an overanxious administrator does not delete it by accident.
Congratulations—your iSCSI SAN is now ready to use. However, this is by no means all that you would need to do for a successful deployment of iSCSI in your environment. The following list highlights additional steps that you might need to consider:
- Document your iSCSI configuration, including volumes and the initiators to which they are assigned.
- Configure and schedule snapshot software for backing up data on the LUNs and configure the software to verify the integrity of Exchange databases, if applicable.
- Configure redundancy, fault tolerance, and/or multi-path I/O.
- Increase data security by enabling IPSec for authentication and/or data encryption.
For procedures on creating snapshots of Exchange data, configuring multi-path I/O, or IPSec, refer to your iSCSI SAN vendor's documentation or best practices for detailed information. These procedures will usually differ from one vendor to another.
ISCSI SAN STORAGE FOR MICROSOFT EXCHANGE
Tip 1: A basic primer on iSCSI storage architecture
Tip 2: iSCSI SAN storage design options for Microsoft Exchange Server
Tip 3: Setting up Windows iSCSI initiator support for a Microsoft Exchange SAN
Tip 4: Connecting Windows Server and Exchange to iSCSI SAN LUNs
Tip 5: Moving Exchange Server databases and logs to iSCSI SAN LUNs
This chapter excerpt from The Shortcut Guide to Exchange Server 2007 Storage Systems , by Jim McBee, is printed with permission from Realtimepublishers, Copyright 2007.
Dig Deeper on Microsoft Exchange Server Storage Management