Mpio on windows xp




















When a device such as a storage disk is first added in, each layer of the hierarchy is responsible for making the disk functional such as by adding partitions, volumes, and the file system. The stack layers below the broken line are collectively known as the device stack and deal directly with managing storage devices.

Device drivers manage specific hardware devices, such as a disks or tapes, on behalf of the operating system. In conjunction with the class driver, the port driver handles Plug and Play PnP and power functionality. Port drivers manage the connection between the device and the bus.

Windows Server introduced a new port driver, StorPort, which is better suited to high-performance, high-reliability environments, and is typically more commonly used today than SCSIport. Each storage adapter has an associated device driver, known as a miniport. This driver implements only those routines necessary to interface with the storage adapter's hardware. A miniport partners with a port driver to implement a complete layer in the storage stack, as shown in Figure 2.

Class drivers manage a specific device type. The class driver manages the functionality of the device. Class drivers like port and miniport drivers are not a part of the MPIO driver package per se; however, the PnP disk class driver, disk. For more information, see the MPIO drivers sections that follow.

The MPIO driver is implemented in the kernel mode of the operating system. It works in combination with the PnP Manager, the disk class driver, the port driver, the miniport driver, and a device-specific module DSM to provide full multipath functionality. Bus drivers are responsible for managing the connection between the device and the host computer. The multipath bus driver provides a "software bus also technically termed a "root bus" "—the conceptual analog to an actual bus slot into which a device plugs.

It acts as the parent bus for the multipath children disk PDOs. As a root bus, mpio. The MPIO bus driver also communicates with the rest of the operating system, and manages the PnP connection and power control between the hardware devices and the host computer, and uses WMI classes to allow storage array manufacturers to monitor and manage their storage and associated DSMs.

As explained previously in this document, a storage array manufacturer's device-specific module DSM incorporates knowledge of the manufacturer's hardware. These DSM actions are described further in the following sections. MPIO allows for devices from different storage vendors to coexist, and be connected to the same Windows Server based system.

The first DSM to claim ownership of the device is associated with that device and the remaining DSMs are not allowed a chance to press claims for that already claimed device.

If the DSM does support the device, it then indicates whether the device is a new installation, or is the same device previously installed but is now visible through a new path. In case of a failover, the DSM determines what new path should be used. The Microsoft device-specific module DSM provided as part of the complete solution in Windows Server includes support for the following policy settings:.

The control panel can be used to do the following:. You can list the VID and PID for storage that is already connected to the server by using the mpclaim tool at the command prompt.

Discover Multi-Paths Use this tab to run an algorithm for every device instance that is present on the system and determines if multiple instances actually represent the same Logical Unit Number LUN through different paths.

We recommend using vendor installation software to install the vendor's DSM. The report includes information on the device-specific module DSM that is being used, the number of paths, and the path state. You can also save this configuration at a command prompt by using the mpclaim command. EXE Usage examples. Before you can configure the load-balancing policy setting by using Disk Management, the device must first be claimed by MPIO.

If Path A fails, Path B is used. Select the Preferred check box, and then click OK. For a complete list of available PowerShell cmdlets in the Storage module, including usage and examples, please refer to the following TechNet site:. You can also obtain help for individual commands by specifying the cmdlet with Get-Help, such as shown below:. In Windows 8, PowerShell modules which ship with Windows do not include help content "inbox" instead this content is provided on the Internet, and may be updated via PowerShell from a computer which has Internet access.

Once a PowerShell module has been imported into the current PowerShell session, the help content may be downloaded and updated via the following command:. Note: the —Force parameter must be used if attempting to update more than once per 24 hour period. For example, in order to obtain script examples for the Get-Disk cmdlet, the following command is utilized:. Tip: If these steps are performed prior to connecting devices of the desired BusType, you can typically avoid the need for a restart.

In most cases, the default values may be adequate; however, it may be necessary to adjust these settings to obtain optimal performance for your environment.

Scenario 1 A two-node Windows Server failover cluster is configured with multiple connections to storage for each node by using MPIO, and employs multiple active paths to maximize throughput.

Due to application Service Level Agreement SLA requirements, in the event of path failures, short timeout values are required by the customer so that the resources will failover to the other cluster node more quickly. In this case, timer values such as the PDORemovePeriod are set to a low value and then tested to ensure compliance with customer requirements. Scenario 2 A single server that is not configured as a failover cluster is configured with MPIO and multiple connections to storage to provide both increased throughput and fault tolerance of path failures.

In this case, timers such as PDORemovePeriod are increased to allow additional time for path recovery to occur. For any customer scenario, determining the best timer values to use depends on a number of different variables, such as any of the following, which could all potentially impact whether the current settings would meet SLA or Operating Level Agreement OLA requirements:.

Settings 1 through 5 in the following table can be set through the user interface. The information provided on these settings is specific to the use of Microsoft DSMs. When using a vendor-provided DSM, refer to vendor documentation for information about the recommended timer values.

Although it is possible to set the following values to a very large number, we recommend that you use caution when doing so, and that you test the values for applicability prior to using them in a production environment. If this value were applied to a setting such as PDORemovePeriod where it represents seconds , the value would equate to approximately 49, days of delay before an error would be reported.

Type is Boolean and must be filled with either 0 disable or 1 enable. By default, it is disabled. This setting is used to indicate the time period in seconds with which MPIO has been requested to perform path verification.

This setting controls the amount of time in seconds that the multipath pseudo-LUN will continue to remain in system memory, even after losing all paths to the device.

The default setting is 3. Represents the period after which PathRecovery is attempted. The end result is that the system now has at least one path and one device online, but no pseudo-LUN to represent that device.

MPIO has a path recovery mechanism that can be used to avoid this issue. However, by default, the period at which path recovery is attempted is set to twice in the PDORemovePeriod. To mount a volume, perform the following steps. Repeat steps for a second network interface for example, DATA 1 on your device. Keep in mind that these interfaces should be enabled for iSCSI. For more information, see Modify network interfaces.

A Connect to Target dialog box appears. In the Connect to Target dialog box, select the Enable multi-path check box. Click Advanced. Click Properties. In the Properties dialog box, click Add Session. The volume created on the StorSimple device that are visible to this host appears under Disk Management as new disk s.

Initialize the disk and create a new volume. During the format process, select a block size of 64 KB. Under Disk Management , right-click the Disk and select Properties. In the DSM Name section, click Details and verify that the parameters are set to the default parameters. The default parameters are:. For multi-path based high availability and load balancing, multiple sessions must be manually added to declare the different paths available.

For example, if the host has two interfaces connected to iSCSI network and the device has two interfaces connected to iSCSI network, then you need four sessions configured with proper path permutations only two sessions will be required if each DATA interface and host interface is on a different IP subnet and is not routable.

We recommend that you have at least 8 active parallel sessions between the device and your application host. This can be achieved by enabling 4 network interfaces on your Windows Server system. Use physical network interfaces or virtual interfaces via network virtualization technologies on the hardware or operating system level on your Windows Server host. With the two network interfaces on the device, this configuration would result in 8 active sessions. This configuration helps optimize the device and cloud throughput.

Please refer to the Windows Server Catalog for version compatibility. The first two discussed in the Configuring Multipath-IO section are:. The next sections walkthrough each of these management tasks using the graphical user interface GUI or Windows PowerShell. See the Installing Multipath-IO section for more details.

These steps work for Windows Server , R2, , and The only differences between the graphical user interface is the changes in the dialogs visual appearances. The example provided in this section are taken from Windows Server No 3rd party DSMs are supported.

A Reboot Required dialog box will be displayed after completing this configuration. Choose Yes or No depending on what other management or application tasks you are performing, but keep in mind that a reboot is required for the new MPIO Devices settings to take effect. If iSCSI connectivity is being used, you may ignore this reboot requirement.

The reason for this is to reduce the number of reboot cycles for the Windows Server host since adding iSCSI support requires an additional reboot. Click OK. You will be prompted to perform a reboot at this time. The reason for preferring PowerShell is the requirements of ensuring the device that is added adheres to the string formatting of Vendor 8 characters and Product 16 characters.



0コメント

  • 1000 / 1000