 |
|
Home > iSCSI SAN storage design options for Microsoft Exchange Server |
|
|
|
iSCSI SAN storage design options for Microsoft Exchange Server |
|
| 05 Dec 2007 | Jim McBee |
|
|
Although deploying iSCSI is reasonably simple to do, there are a number of ways that it can be deployed. Let's look at a couple of possible design considerations. The first of these is by far the simplest and is shown in Figure 3.2. In this solution, the iSCSI SAN is connected to the same network switch as the rest of the network components. This switch could be a 10MB, 100MB, or 1GB Ethernet switch.
Figure 3.2 Simple iSCSI SAN solution.
This design provides an example of how simple an iSCSI deployment could be, but it is certainly not a best practice. One reason is that storage-related iSCSI traffic will need to share the same network infrastructure as the rest of the computers on the network. Further, this design does not provide multiple paths between the initiators and the iSCSI SAN. This solution might work fine in a small environment or for a lab. However, sharing a network with other traffic will introduce latency into your environment and negatively impact iSCSI performance. Many data networks are also only 10/100Mbps networks; 10/100Mbps networks will work for iSCSI but performance will be quite poor.
Figure 3.3 shows a more practical approach to planning a network for iSCSI. In this example, a dedicated 1GB Ethernet switch is provided. Each node on the network that requires iSCSI LUNs is connected to this dedicated network as well as to the production LAN.
Figure 3.3 Providing a dedicated network for iSCSI storage.
This design can be scaled to allow multi-path I/O by adding dedicated Ethernet switches for the storage network or by allowing the production LAN to be used as a backup path in case the dedicated Ethernet network is not available.
In most cases, each iSCSI client system has a local disk that is used by the OS for booting and for the page file as well as locally installed applications. In some situations, though, it is possible to boot from a SAN LUN. Although this is not very common, sometimes companies want to know if this is possible. Implementing SAN boot introduces additional complexity into your environment, such as having to configure the LUNs and the adapters for SAN boot, but it can allow for faster recovery from hardware failures. If this is a requirement, the iSCSI client must have a bootable iSCSI network interface card or use a PXE client such as emBoot. Bootable network interface cards for iSCSI are available from vendors such as Broadcom and Intel.
In environments in which the iSCSI client will be running applications that are I/O intensive (such as Exchange Server systems with more than 500 mailboxes), iSCSI performance can be improved by using adapters that offload the overhead of the iSCSI protocol or TCP on to a host bus adapter (HBA) card for iSCSI. Vendors such as QLogic, Adaptec, and Alacritec make iSCSI HBAs. Prior to making a design decision to use iSCSI HBAs, consult your iSCSI SAN vendor to review your expected and projected I/O loads to determine whether iSCSI HBAs are necessary. Even with moderately heavy iSCSI loads, the performance on the software-based iSCSI initiator is very good.
ISCSI SAN STORAGE FOR MICROSOFT EXCHANGE
 Home: Introduction
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 Microsoft Exchange to iSCSI SAN LUNs
Tip 5: Moving Exchange Server databases and logs to iSCSI SAN LUNs
|
|
|
|
|
|
| TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of . |
|
| |
All Rights Reserved, , TechTarget |
|
|
|
|
|
