当前位置：文档库 › Multipath Routing and Multiple Description Coding in Ad hoc Networks A Simulation Study 1

Multipath Routing and Multiple Description Coding in Ad hoc Networks A Simulation Study 1

Multipath Routing and Multiple Description Coding in Ad hoc

Networks: A Simulation Study 1

Irene Fernández Díaz, Jan de Jongh and Dick Epema*

TNO Telecom, The Hague, The Netherlands

*Delft University of Technology, Delft, The Netherlands

E-mail: i.fernandezdiaz@telecom.tno.nl

This research was supported by the Towards Freeband Communication Impulse of the technology programme of the Dutch Ministry of Economic Affairs.

Abstract

The nature of ad hoc networks makes it a challenge to offer connections with an assured quality. In order to improve the performance of the network, multipath routing in combination with multiple description coding (MDC) is proposed. By

splitting up streams of multimedia traffic into several substreams (called descriptions ), by sending these substreams along

different paths from source to destination, and by reassembling them again at the destination, we hope to improve the quality of the received stream as compared to the single-description, single-path case.

We have done a simulation study from a network perspective: with a realistic medium access control protocol (IEEE 802.11), routing protocol (based on Dynamic Source Routing) and other kind of topologies than the ones studied so far.

Counter to experience in wired networks and to other studies, simulation showed that for the many cases considered, multipath routing in combination with MDC does not perform better than single-path routing and a single description in IEEE 802.11-based networks.

Introduction

The nature of ad hoc networks: the lack of a central authority, a shared medium, the potentially low bandwidth, the mobility of the nodes, etc, makes it a challenge to offer connections with sufficient quality for real-time applications (voice or video).

A promising approach is to establish multiple paths between the source and the destination and to use coding schemes that take advantage of the existence of several paths in order to improve the performance of ad hoc networks to give support to real-time applications.

Recent studies have focused on two aspects: developing

multipath routing protocols for ad hoc networks either totally new [1, 2] or based upon existing single-path routing protocols [3] or testing/developing coding schemes in multipath topologies [4, 5]. While the first studies mainly focus on the efficiency of the protocol proposed, the second focus on the coding itself and not on the characteristics of the network that has to support it. As a result, little attention is paid to the influence of the Medium Access Control (MAC) protocol, the routing protocol or even the network topology.

The aim of our simulation study is to study whether the

combination of multipath routing and a special type of coding called Multiple Description Coding can improve the network performance in terms of delay and packet loss, taking into

account other kind of topologies than the ones studied so far and realistic protocols as a modified version of Dynamic Source Routing (DSR) as routing protocol and IEEE 802.11 as MAC protocol. In other words, this is a study done from a network perspective instead of a coding perspective. We do not intend to propose a new multipath routing protocol. In fact, other research activities have already taken care of that.

This paper is organized as follows. First, we give a description of the model and of the simulation implementation in OPNET. Then, we present the results of the simulation of several

scenarios. At the end of the paper, we draw conclusions and we point out directions for future research.

Model description

In this section, we describe the system, mobility, connectivity, workload and routing models as well as the performance metric. We also describe how we implemented these models in OPNET.

System and Mobility Model

We consider a group of N (>1) nodes, each of which moves randomly on a rectangular grid, called the playfield, of width W and height H . Nodes move independently, and according to the Random Waypoint Mobility Model [6]. With random waypoint, nodes move along a path of randomly chosen waypoints in the playfield. Between two waypoints, a node moves in a straight line with constant speed drawn (for each “leg”) from a uniform distribution [v min , v max ], 0 < v min < v max . Once a node arrives at a waypoint, it pauses for a random amount of time, drawn (at each waypoint) from an uniform distributed time on [t min , t max ], 0 <= t min <= t max . All pause times are independent. Also, pause times are independent of node waypoints and speeds. The boundary values for the speed (viz., v min and v max ) and for the pause times (viz., t min and t max ) are the same for each node. At t =0, the nodes are distributed randomly (and independently) across the playfield, and each node starts with a pause time.

We use the OPNET implementation of the Random Waypoint Mobility Model from NIST with only minor modifications [7].

Connectivity Model

The connectivity model is as follows: two nodes are able to communicate if the distance between them is smaller than or equal to some predefined, constant, communications range R. In the simulations, R=250 m.

The MAC protocol used is that of IEEE 802.11b: Carrier Sense Multiple Access with Collision Avoidance with RTS/CTS (Request To Send/Clear To Send). An OPNET implementation of the protocol is readily available at [8].

Workload Model

The workload model is as follows. Starting at t=0, selected nodes inject traffic destined for a single other node. The traffic is in the form of a fixed number F of packetized flows, each corresponding to a different description code of the underlying multimedia stream. If F=1, no multiple description coding is applied; then, the packets of the only flow are the packets of the original multimedia stream. If F=2, twice as many packets as when F=1 are injected into the system. Ideally, the use of multiple description coding does not increase the amount of traffic. In other words, in case F=2, the encoder generates twice as many packets, but theses packets are half the size of the packets that it generates when F=1. Therefore, traffic is injected at the same rate into the system independently of the number of description codes used. Each flow consists of packets of fixed size P with fixed interarrival time A. The flows are synchronized in the sense that, within interval A, a single packet of each of the F flows is generated sequentially. The ensemble of F packets sent within a time interval FA is called a batch. Each packet contains a stream and a flow identifier field. Time stamping and sequence numbering of the packets are also implemented in the model.

Once a packet of flow F originates at the sending node, the flow number is used as an index into the DSR route cache to find the route of the flow. So, packets of flow one are always sent via the first route in the route cache, packets of flow two via the second route and so forth.

Multipath Routing Model

The multipath routing protocol is a modified version of the existing OPNET implementation of DSR version 5 [9]. DSR together with AODV (Ad hoc On-Demand Distance Vector Routing) are the most popular and most studied reactive routing protocols. Our choice is a practical one: despite of the fact that recently several multipath routing protocols have been proposed, simulation implementations of them are not available. Although at the time of writing the latest internet draft of DSR was version 9 [10], the only available implementation was based on version 5 [9].

The OPNET implementation of DSR of NIST (later reviewed by AFIT) was modified to give support to multipath routing. The modifications are summarized below:

1. In DSR, although the route cache may contain several routes

to the same destination, only the first route is used. In the

modified version, packets are routed according to their flow identifier field. Packets with flow id equal to one use the

first route in the cache. Packets with flow id equal to two,

use the second route in the cache and so forth. If no route to

the destination is found in the route cache, the packet is

inserted in the send queue and the source node initiates a

Route Discovery (if this has not been initiated yet).

2. As long as there is no route for the packets in the send

queue, packets remain in the queue. In response to a route

reply, packets are extracted from this queue. If the queuing delay of the packet is higher than a maximum predefined

acceptable end-to-end delay, the extracted packet is

dropped. Otherwise, if there is a route available in the cache, the packet is sent. If there is no route available in the cache, the packet is queued again.

3. Intermediate nodes that receive a route request, handle this

request if they are not already in the route contained in the

request packet (to avoid loops). The target of a route request packet may handle the same route request a predefined

number of times: for example, the maximum number of

description codes used by any source. This ensures that

more than one route reply can be sent by the target node in response to the same route request packet (to ensure that

alternative routes are found).

4. Intermediate nodes do not send promiscuous replies to

request packets of which they are not the target.

5. Intermediate nodes are not allowed to shorten source routes

contained in the packets they forward, even though they

know a shorter route.

6. Intermediate nodes are not allowed to salvage packets. A

node that salvages a packet sets its address as source address of the packet. This modification was done to avoid wrong

packet counts when obtaining the performance metric (a

salvaged packet is otherwise interpreted as a single packet

of a new stream and therefore the stream success of that

stream is low). The term stream success will be introduced later.

As the goal of our study was not to develop a new multipath routing protocol, these modifications are justified. However, we admit that the resulting protocol is inefficient, as many of the enhancements of DSR had to be modified or removed in order to support multipath routing.

Performance Metric

We are interested in the following performance metric. First, for each batch i, i=0,1,2,… we define the quality Q i of batch i. The quality of a batch is a real number between zero and unity and depends on the number of packets of the batch that were received correctly (i.e., without transmission errors) and timely (within a fixed interval of length T v after the packet is sent by the source node) at the destination node. In the simulations, T v is 300 ms, which corresponds to the maximum allowable delay in interactive two-way voice communications.

The dependence of the quality of a batch on the fraction of packets received of that batch is shown in Table 1, for F=3.

For an arbitrary F, the relationship is as follows, with q i being the number of packets of batch i received, q i=0,1,…,F:

Q i = 1 – 1 / { 2qi}, q i= 0,1,…, F-1,

Q i = 1, q i = F.

The main idea behind our definition of the batch quality is that with multiple description coding, receiving a single code already

yields an acceptable quality (i.e. 50%). Receiving additional codes improves the quality, but the marginal gain decreases. The performance metric in which we are interested is the expected stationary batch quality E[Q], which we call the stream success.

Number of packets of batch received* Quality of batch

0 0.0

1 0.50

2 0.75

3 1.00

Table 1-Dependence of the quality of a batch on the fraction

of received packets.

Results

The scenarios in which we presume that multiple description coding can give a performance improvement are those in which congestion occurs at certain points of the route being used. In those cases, the use of two description codes and a second route help reduce the network congestion and in this way, improve the network performance for the traffic that uses multiple description codes and multipath routing. Nevertheless, this kind of scenario is not the only focus of the simulations.

For the simulation study, we chose a step-by-step approach, with scenarios of increasing complexity. We present here a selection of scenarios: first, we consider a multihop topology (without multipath and with one description code (DC)), then we study the influence of mobility in multipath scenarios and finally, we study the influence of MDC in different multihop scenarios with background traffic (other sources of traffic than the source under study, which will cause network congestion).

The simulation parameters common to all simulations are summarized in Table 2.

WLAN data rate 1 Mbit/s

WLAN range

250 m

Communication pairs Source: mobile_node_0

Destination: mobile_node_4 Packet size 512 bytes (256 bytes for 2 DC)

Maximum end-to-end

delay

300 ms

Table 2-Common simulation parameters.

In all simulations, the communication pair under study is mobile_node_0 (source) and mobile_node_4 (destination). In the different scenarios, we use the term transmission rate to refer to the transmission rate of mobile_node_0 and the term stream success is used to refer the quality of the stream received at mobile_node_4. Received packets with a maximum end-to-end delay higher than 300 ms are considered lost. As explained before, when two description codes are used, the source produces twice as many packets, but the packets are half the size (256 bytes instead of 512 bytes). Scenario 1: goodput in a multihop topology

The objective of the simulation is to obtain the maximum transmission data rate between a pair of nodes (mobile_node_0 and mobile_node_4) to guarantee 100% stream success, when a topology as illustrated in Figure 1 is used. The number of nodes is varied between 2 and 6. The distance between two adjacent nodes is 180 m.

Figure 1-Multihop scenario with 4 nodes.

The parameters used in the simulations are summarized in Table 3.

Number of nodes Variable: 2 to 6

Mobility NO

Simulated time 10 minutes

Number description codes 1

Packets per stream 1876

Packet interarrival time Variable

Stream interarrival time 120 s

Peak transmission rate Variable

Table 3-Simulation parameters.

The results are shown in Table 4.

Number of nodes 2 3 4 5 6

Transmission data

rate (kbit/s)

650 328 215 210 204

Table 4-Goodput to ensure 100% stream success.

As shown in Table 4, the higher the number of nodes, the lower the maximum transmission rate. This result will be used later to create congestion situations in certain parts of the network. Scenario 2: effect of mobility with six nodes

The scenario used in these simulations is shown in Figure 2.

The objective of these simulations is to test the effect of mobility on the stream success when the source uses first 2 description codes and second 1 description code. The nodes move on a playfield of 400 x 400 m. The simulation parameters are listed in Table 5.

Figure 2-Six nodes.

Mobility: Max. speed Min. speed Step Pause time YES

Variable: see results Variable: see results

2 s (position calculated every 2s) 10 s

Simulated time 1 hour

Number description codes 2* (1)

Packets per stream 3752* (1876)

Packet interarrival time 0.016 s* (0.032)

Stream interarrival time 120 s

*Equivalent to 128 kbit/s during 1 minute (64 kbit/s per description code)

Table 5-Simulation parameters.

The speed of the nodes is varied between 0.1 and 4 m/s to simulate slow walking and cycling respectively. The average stream success and the 90% confidence interval (CI) of the stream success for the 2 DC case are shown in Table 6.

Min. speed (m/s) Max.

speed

(m/s)

Average

stream

success (%)

Stream success

90% CI

0.1 0.5 63.21 (50.26,76.16)

0.5 1 73 (58.95, 87.04)

1 4 71.25 (57.23, 85.27)

Table 6-Stream success when 2 DC are used.

From the results in Table 6, we conclude that when 2 description codes are used, on average, at any given point in time, at least one packet of either of the flows is received (and in time). Note that with speeds between 0.1 and 0.5 m/s, the availability of routes does not change much during the transmission time of one stream (1 minute). With higher speeds, the availability of routes changes during the transmission time of one stream. It should be remarked that to obtain significant results for the lower speeds, simulations longer than 1 hour would be more adequate. Otherwise, the results of the simulation are very much influenced by the random initial position of the nodes on the playfield. It can be concluded, that in this scenario (the network is relatively dense and the network load is relatively low) mobility does not influence much the performance in terms of stream success.

The results of the simulations when the source uses 1 DC are summarized in Table 7.

Min.

speed

(m/s)

Max.

speed

(m/s)

Average

stream success

(%)

Stream success

90% CI

0.1 0.5 100 (100,100)

0.5 1 91.95 (82.47, 101.43)

1 4 87.29 (76.09, 98.49)

Table 7-Stream success when 1 DC is used.

Table 7 shows that the use of 1 DC instead of 2 DC gives a better performance in terms of stream success. With speeds between 0.1 and 0.5 m/s, every time the stream is transmitted, there is one route from the source to the destination which allows all packets to be received in time. As mentioned before, we admit that to obtain significant results for the lower speeds, simulations longer than 1 hour would be more adequate. However, it can be concluded that in this scenario, the performance is better when one description code is used than when two description codes are used by the source.

Scenario 3: two node disjoint paths

The scenario considered in this series of simulations is shown in Figure 3.

Figure 3-Eight nodes and two node disjoint paths

In this scenario, together with the communication pair under study (mobile_node_0 to mobile_node_4), the communication between mobile_node_3 and mobile_node_1 is added as background traffic. The scenario is chosen because two node disjoint routes exist between the source (mobile_node_0) and the destination (mobile_node_4). Besides, the distance between

mobile_node_2 and mobile_node_1 is larger than 250 m and so is the distance between mobile_node_7 and mobile_node_3. In other words, mobile_node_2 is not in the range of

mobile_node_1, what makes this scenario attractive from the interference point of view. It should be noted that in other types of scenarios, where more possible routes exist, the routing protocol (modified version of DSR) cannot select routes that fulfil this criterion. Therefore, the path choices in that case could be less advantageous in terms of interference.

The objective of the simulation is to determine whether or not increasing the number of description codes can give a

performance improvement when not all the traffic is received at mobile_node_4 due to congestion caused by the background traffic from mobile_node_3 to mobile_node_1.

Note that in this simulation, traffic from mobile_node_3 to mobile_node_1 (background traffic) is sent once the route

discovery process initiated by mobile_node_0 is completed. The parameters used in the simulations are listed in Table 8.

Mobility: NO Simulated time 10 minutes Number description codes 2 (1) Packets per stream 3752 (1876) Packet interarrival time 0.016 s (0.032) Stream interarrival time 120 s

Table 8-Simulation parameters.

The values in Table 8, correspond to 128 kbit/s sent from

mobile_node_0 to mobile_node_4. The stream duration is 1 minute and between 2 streams there are 2 minutes of no traffic. Mobile_node_3 transmits to mobile_node_1 (this is the background traffic) with a continuous transmission rate that varies between simulations: 128, 256, 384 and 512 kbit/s.

A series of simulations is run. When mobile_node_0 transmits with 1 DC, all traffic follows the route 0-1-3-4. When it

transmits with 2 DC, packets of the first description code follow the route 0-1-3-4 and packets of the second description code follow the route 0-2-5-6-7-4. The results of the simulations are shown in Figure 4.

Figure 4-Stream success versus background traffic. It cannot be concluded that in terms of stream success using 2 DC is better than using 1 DC. The use of 2 DC is only better

when the background traffic is 512 kbit/s. In that case, the route 0-1-3-4 cannot support 128 + 512 kbit/s (which is above the throughput limit as shown in Table 4), whereas using an

alternative route allows some packets to be received. However the number of timely received packets is very low and so is the stream success (13%).

Taking 256 kbit/s as background traffic, while all packets are received and in time when mobile_node_0 uses 1 DC, when this source node uses 2 DC, the stream success is much lower (65%). This has to do with the enormous delays experienced by some of the packets at MAC layer due to retransmissions. For some packets, many retransmissions attempts are made before the packet is successfully received. This occurs mainly at mobile_node_7, mobile_node_0, mobile_node_1 and

mobile_node_3. For example, looking at mobile_node_4, with 1 DC, 4 “hears” the transmissions of 3 destined to 1 and hears the transmission of 3 destined to 4. With 2 DC, 4 hears the transmissions of 3 destined to 1, hears the transmission of 3 destined to 4 and the transmissions of 7 destined to 4. The use of the second route does not improve the results because this route is also influenced by the background traffic between 3 and 1. Consider, for example, that 4 cannot acknowledge packets coming from 7 if 3 is sending to 1.

In case of 128 kbit/s as background traffic, when 2 DC are used, the number of packets that have to be retransmitted many times is low (only a few packets experience long delays). This is why the stream success is 96%. When 1 DC is used, almost no packet has to be retransmitted several times. All packets are received in time and therefore, the stream success is 100%.

Scenario 4: twelve nodes, two disjoint routes and background traffic

The scenario used in the simulations is illustrated in Figure 5.

Figure 5-Twelve nodes and two node disjoint routes. In this scenario, together with the communication pair under study (mobile_node_0 to mobile_node_4), the communication between mobile_node_3 and mobile_node_1 is added as background traffic. This scenario is chosen because two node disjoint routes exist between the source (mobile_node_0) and the destination (mobile_node_4). Besides, the distance between mobile_node_2 and mobile_node_10 is longer than 250 m and so is the distance between mobile_node_7 and mobile_node_8. Furthermore, the distance between mobile_node_4 and

mobile_node_3 is longer than 250 m. Therefore, the background traffic (from 3 to 1) does not directly affect the transmissions of mobile_node_4. It should be noted that, in general, the routing protocol (modified version of DSR) can by no means find routes which meet this criterion (two node disjoint routes in which all

but the common nodes of the two routes are not in each others range and in which the common nodes are not in the range of other traffic sources) when other possible routes exist.

The objective of the simulation is again to determine whether or not increasing the number of description codes can give a performance improvement when not all the traffic is received at mobile_node_4 due to congestion caused by the background traffic from mobile_node_3 to mobile_node_1. Note that in this simulation, traffic from mobile_node_3 to mobile_node_1 (background traffic) is sent once the route discovery process initiated by mobile_node_0 is completed.

The parameters used in these simulations are the same as those shown in Table 8. Again, while the source under study,

mobile_node_0, always transmits 128 kbit/s to mobile_node_4, the background traffic (from 3 to 1) varies between simulations: 128, 256, 384 and 512 kbit/s.

A series of simulations is run varying the number of description codes used by mobile_node_0. When mobile_node_0 transmits with 1 DC, all traffic follows the route 0-10-1-3-8-4. When it transmits with 2 DC, packets of the first description code follow the route 0-10-1-3-8-4 and packets of the second description code follow the route 0-2-11-5-6-9-7-4. The results are shown in Figure 6.

As shown in Figure 6, the performance in terms of stream success is in all cases better when the source sends with 2 DC than when the source sends with 1DC. The performance difference is more significant when the background traffic increases. For example, for a background traffic of 256 kbit/s, whereas with 1 DC the stream success is 46% (this can be interpreted as just one packet received for every two sent packets), with 2 DC the stream success is 77% (for every two sent packets, half of the time both are received and have of the time, one is received). Therefore, by carefully choosing the second route it can be guaranteed that using 2 DC gives a performance improvement above using 1 path and 1 DC. However, as mentioned before, no existing routing protocol can deliberately make such route choices (routes with characteristics similar to those in Figure 5) when other possible routes exist.

Figure 6-Stream success versus background traffic. Conclusions

In this paper, we have compared the performance of multipath routing combined with multiple description coding with single-path routing and one description code in ad hoc networks. In scenarios with mobility, the results show that, in general, the performance of multipath routing is worse than the performance of single-path routing. In scenarios where the use of multiple description codes is aimed at relieving certain parts of the network where congestion occurs, multiple description coding gives a better performance only in very specific scenarios, where the routes chosen satisfy very specific requirements (node disjoint routes in which the alternative route is not affected by the congestion). Current routing protocols are just not able to choose routes with such characteristics.

The main result is that multipath routing is probably not the best way to improve the performance of current and near future ad hoc networks, as long as these networks are based on IEEE 802.11 as we know it today and the routing protocols are the ones we know today. We admit that more extensive research would be needed to lead to definitive conclusions.

Future research could be oriented to obtain experimental results to contrast our simulation results or to study solutions at physical layer that help to reduce the interference problems that we have pointed out in this work.

References

[1] S-J. Lee and M. Gerla, “Split Multipath Routing with Maximally Disjoint Paths in Ad hoc Networks”, Proceedings of IEEE ICC, pp. 3210-3205, Helsinki, June 2001.

[2] S. Mao, D. Bushmitch, S. Narayanan and S. S. Panwar, “MRTP: A Multi-Flow Realtime Transport Protocol for Ad Hoc Networks”, Proc. IEEE VTC, Orlando, October 2003.

[3]A. Nasipuri, R. Castaneda and S.R. Das, “Performance of Multipath Routing for On-Demand Protocols in Mobile Ad Hoc Networks,” ACM/Kluwer Mobile Networks and Applications (MONET), 2001. [4] N. Gogate, D-M Chung, S.S. Panwar and Y Wang, “ Supporting

Image and Video Applications in a Multihop Radio Environment Using Path Diversity and Multiple Description Coding”, IEEE Trans. On Circuits for Video Technology, vol.12, No 9, September 2002.

[5] S. Mao, S. Lin, S.S.Panwar and Y. Wang, “Video Transport over Ad Hoc Networks: Multistream Coding with Multipath Transport”, IEEE JSAC Special Issue on Recent Advances in Wireless Multimedia, 2003.

[6] J. Broch, D.A. Maltz, D.B. johnson, Y.-C. Hu, and J. Jetcheva, “A Performance Comparison of Multi-hop Wireless Ad Hoc Network Routing Protocols”, Proc. Mobile Computing and Networking (MobiCom), pp. 85-97, 1998.

[7] DSR OPNET contributed model of NIST can be found at:

https://www.wendangku.net/doc/3b12030388.html,/wctg/prd_dsrfiles.html; March 2004. [8] https://www.wendangku.net/doc/3b12030388.html,.

[9] D. B. Jonhson, D. A. Maltz, Y-C Hu and J.G. Jetcheva; The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks; https://www.wendangku.net/doc/3b12030388.html,/~griswold/Drafts-RFCs/draft-ietf-manet-dsr-05.txt; March 2001.

[10] D. B. Jonhson, D. A. Maltz, Y-C Hu; The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR);

https://www.wendangku.net/doc/3b12030388.html,/internet-drafts/draft-ietf-manet-dsr-09.txt; April 2003.

多路径的配置与管理V2.0

多路径配置与管理

目录 1. 多路径概述 (1) 1.1 什么是多路径 (1) 1.2 业界的MPIO (1) 2. Windows Server 2008/2012 MPIO配置与管理 (1) 2.1 MPIO安装 (1) 3.2 MPIO配置 (5) 3.3 MPIO切换策略介绍 (13) 4. RedHat Linux MPIO配置与管理 (15) 4.1 多路径软件的安装 (15) 4.2 Multipath.conf配置文件解析 (16) 4.3 配置multipath.conf (19) 4.3.1 快速配置 (19) 4.3.2 高级配置 (19) 4.4 多路径管理 (24) 4.5 多路径磁盘的使用 (25) 5 各产品multipath.conf参数配置 (26) 5.1 INSPUR AS500G/E、AS520G/E (26) 5.1.1 Windows客户端 (26) 5.1.2 Linux客户端 (27) 6 Multipath Issues Troubleshooting (27) 6.1在群集中保持多路径设备名称一致 (27)

1. 多路径概述 1.1 什么是多路径普通的电脑主机都是一个硬盘挂接到一个总线上，这里是一对一的关系。而到了有光纤组成的SAN环境，或者由iSCSI组成的IPSAN环境，由于主机和存储通过了光纤交换机或者多块网卡及IP来连接，这样的话，就构成了多对多的关系。也就是说，主机到存储之间的IO由多条路径可以选择。每个主机到所对应的存储可以经过几条不同的路径，如果是同时使用的话，I/O流量如何分配？其中一条路径坏掉了，如何处理？还有在操作系统的角度来看，每条路径，操作系统会认为是一个实际存在的物理盘，但实际上只是通向同一个物理盘的不同路径而已，这样在使用的时候，就给用户带来了困惑。多路径软件就是为了解决上面的问题应运而生的。多路径管理MPIO（Multi-Path），对支持MPIO的存储设备，MPIO自动发现、配置和管理多个存储路径，提供IO高可靠性和负载均衡。MPIO方案的实现有三个部分组成，分别为存储系统部分、存储软件部分和操作系统部分。多路径的主要功能就是和存储设备一起配合实现如下功能： 1.故障的切换和恢复 2.IO流量的负载均衡 3.磁盘的虚拟化在RedHat和Suse的2.6内核中都自带了免费的多路径软件包，并且可以免费使用，同时也是一个比较通用的包，可以支持大多数存储厂商的设备，即使是一些不是出名的厂商，通过对配置文件进行稍作修改，也是可以支持并运行的很好的。 1.2 业界的MPIO 由于多路径软件是需要和存储在一起配合使用的，不同的厂商基于不同的操作系统，都提供了不同的版本。并且有的厂商，软件和硬件也不是一起卖的，如果要使用多路径软件的话，可能还需要向厂商购买license才行。，业界比较常见的MPIO功能软件有EMC 的PowerPath，IBM的SDD，日立的Hitachi Dynamic Link Manager和广泛使用的linux开源软件device-mapper。 2. Windows Server 2008/2012 MPIO配置与管理 2.1 MPIO安装 Windows Server 2008系统包含MPIO软件，不需要使用其它的MPIO软件。具体安装步

SUSE-多路径Device-Mapper+Multipath

Device-Mapper Multipath 一DM-Multipath概述 DM-Multipath 能够使服务器与存储控制器间multiple I/O路径变成一个单一的设备。I/O 路径是由线缆、交换机、控制器组成的物理SAN。DM-Multipath能够创建一个由I/O路径聚集组成的新设备。在不配置DM-Multipath的情况下，盘阵的一个LUN从控制器主机端口映射到服务器，在操作系统里被识别成一个独立的设备，这样就会造成同一个LUN通过盘阵不同的主机端口映射到服务器被识别成不同的设备。作为一种解决方案，DM-Multipath通过在物理设备上创建一个单独的多路径设备，提供了一种在逻辑上管理I/O路径的机制，这样盘阵的LUN 从控制器主机端口映射到服务器，在操作系统里被识别成一个多路径设备。每个多路径设备拥有一个唯一标识的World Wide Identifier（全球识别号，WWID），默认情况下，多路径设备的名称被设置成它的WWID。通过修改multipath.conf文件中的user_friendly_names选项参数，可以设置多路径设备的别名为mpathn。例如如下的配置环境：一个拥有两个HBA的服务器通过一个未配置zone的FC交换机连接到有两个主机端口的盘阵控制器（盘阵仅有一个LUN）上，在操作系统里能够看到四个设备：/dev/sda, /dev/sdb, dev/sdc, 和/dev/sdd。通过配置multipath.conf文件，DM-Multipath就会创建一个拥有WWID 的多路径设备，多路径设备受控于DM-Multipath，我们可以在三个不同目录查看多路径设备：/dev/目录；/dev/mapper/mpathn,/dev/mpath/mpathn；/dev/dm-n.。使用/dev/mapper目录中的设备名对多路径设备进行管理，如创建逻辑卷，创建文件系统等。/dev/mpath将所有的多路径设备放到该目录下，只是便于查看，不要使用该目录下的设备进行创建逻辑卷，创建文件系统等操作。/dev/dm-n只是用于系统内部的使用，不要使用这里面的设备。二DM-Multipath功能 DM-Multipath能够提供：冗余在active/passive模式中，DM-Multipath提供失效转移功能。active/passive环境中，在任何时间内只有一半的I/O路径被使用。如果一个I/O路径内的元素例如线缆、交换机、控制器失效，DM-Multipath切换到轮换的路径。提高性能 DM-Multipath能够被配置在active/ active模式下，在这种模式下，I/O路径处于round-robin方式。DM-Multipath能够动态的平衡I/O负荷。三DM-Multipath应用环境示例 ①Active/ Passive Multipath Configuration with One RAID Device 该配置里服务器有两个HBA，两个SAN交换机和两个控制器。从服务器到一个RAID存在两个I/O路径。如下图：

DeviceMapperMultipath配置指导书全解

Device Mapper Multipath配置指导书文档密级：内部公开修订记录

目录目录 (1) 前言 (3) 1检查系统DM-Multipath (4) 1.1检查DM-Multipath是否正确安装 (4) 1.2查看DM-Multipath版本 (5) 1.3检查DM-Multipath配置文件 (5) 1.4检查DM-Multipath服务multipathd是否开机启动 (5) 2修改DM-Multipath配置 (6) 2.1修改multipath.conf文件 (6) 2.1.1 CentOS 6.3 对接阵列S5800T 配置 (7) 2.1.2 NeoKylin Advance Linux Server V5.6 对接阵列18500配置 (8) 2.2 FAQ (9) 2.2.1如何获取阵列vendor及product (9) 2.2.2 DM-Multipath可用的磁盘在哪里 (9) 3注意事项 (11) 3.1集群应用 (11) 3.2 DM-Multipath与UltraPath共存 (11) 3.3设备屏蔽 (11) 3.4驱动超时参数 (11) 3.4.1 FC驱动 (11) 3.4.2 ISCSI驱动 (12) 附录A DM-Multipath盘符绑定 (13) 附录B DM-Multipath磁盘屏蔽 (14) 附录C 常用命令 (16)

关键词： Device Mapper Multipath、配置摘要：本指导书是针对Linux系统自带多路径Device Mapper Multipath对接我司阵列，配置操作过程中需要的步骤、注意事项等提供的指导，本指导书描述了Multipath配置过程及注意事项。缩略语清单： DM-Multipath(Device Mapper Multipath )：Linux系统自带多路径 LUN(Logical Unit Number): 逻辑单元号 ALUA（Asymmetric Logical Unit Access）：非对称逻辑单元 IALUA（Implicit Asymmetric Logical Unit Access）：隐式ALUA EALUA（Explicit Asymmetric Logical Unit Access）：显式ALUA 参考资料清单：无。

NetAppMultipath最佳实践配置

NetApp Multipath最佳实践配置 1.Red Hat Enterprise Linux 6 with ALUA enabled sample configuration file The following file provides an example of the values you need to supply when your host is running Red Hat Enterprise Linux 6 with ALUA enabled: defaults { user_friendly_names no max_fds max flush_on_last_del yes queue_without_daemon no } blacklist { devnode "^hd[a-z]" devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" devnode "^cciss.*" } devices { device { vendor "NETAPP" product "LUN" path_grouping_policy group_by_prio features "3 queue_if_no_path pg_init_retries 50" prio "alua" path_checker tur failback immediate path_selector "round-robin 0" hardware_handler "1 alua" rr_weight uniform rr_min_io 128 getuid_callout "/lib/udev/scsi_id -g -u -d /dev/%n" } } 2.Red Hat Enterprise Linux 6 without ALUA enabled sample configuration file The following file provides an example of the values you need to supply when your host is running Red Hat Enterprise Linux 6 and does not have ALUA enabled. Note: Unless you are running the iSCSI protocol and Data ONTAP operating in 7-Mode, you should have ALUA enabled. defaults {

V7000 Linux 多链路配置方式

V7000 Linux多链路配置方式 1. 查看V7000支持的硬件列表，设备驱动，微码和推荐的多链路软件 https://https://www.wendangku.net/doc/3b12030388.html,/support/docview.wss?rs=591&uid=ssg1S1003703#_RH50 根据环境进行设备微码升级，驱动安装。 2. 确认multipath是否已经安装 3. 配置/etc/multipath.conf文件 blacklist { devnode "^sda" } defaults { polling_interval 30 failback immediate no_path_retry 5 rr_min_io 100 path_checker tur user_friendly_names yes } multipaths { multipath wwid 3600508b30090f5d0d2a9d6459049 (通过multipath –ll看) alias xxx（要赋予的别名） {path_grouping_policy failover path_checker tur path_selector "round-robin 0"} multipath

wwid alias } # SVC device { vendor "IBM" product "2145" path_grouping_policy group_by_prio prio_callout "/sbin/mpath_prio_alua /dev/%n" } 4. 设置开机启动 #chkconfig multipathd on #chkconfig --level 345 multipathd on 5. 执行/etc/init.d/multipathd start 启动DMMP进程，执行 multipath –F(删除路径) multipath -v2 查找设备，执行multipath -ll 检查是否找到设备，如果出现一下内容，说明配置成功： mpath1 (36005076801860022900000000000019a) IBM,2145 [size=2.0G][features=0][hwhandler=0] \_ round-robin 0 [prio=200][ enabled] \_ 4:0:0:1 sdd 8:48 [active][ready] \_ 5:0:0:1 sdt 65:48 [active][ready] \_ round-robin 0 [prio=40][ active] \_ 4:0:2:1 sdak 66:64 [active][ready] \_ 5:0:2:1 sdal 66:80 [active][ready] 6. 查看/dev/mapper下的设备选取/dev/mapper/xxxx（刚刚写的别名）作为设备。

RHEL_ENTERPRISE_6.4_多路径软件multi-path配置操作手册

RHEL ENTERPRISE 6.4 多路径软件multi-path 配置操作手册

目录一、什么是多路径 (1) 1.1 多路径的主要功能 (1) 1.2 UUID的作用及意义 (2) 二、Linux下multipath介绍 (2) 2.1 查看multipath是否安装 (2) 2.2 Linux下multipath需要以下工具包介绍 (2) 三、multipath在Redhat中的基本配置过程 (3) 3.1 安装和加载多路径软件包 (3) 3.2 设置开机启动 (4) 3.3 生成multipath配置文件 (4) 四、multipath 高级配置 (4) 4.1 获取存储设备的UUID/wwid和路径 (5) 4.2 配置/etc/multipath.conf 文件例子 (5) 4.3 关于：scsi_id (8) 五、multipath 基本命令 (8) 六、multipath.conf配置文件说明 (9) 七、对multipath磁盘的基本操作 (10) 八、使用multipath的一个例子 (12) 九、PV/VG/LV常用操作命令 (12) 十、使用udev配置固定iSCSI磁盘设备名称 (16)

Linux下多路径multipath配置文档和相关概念

一、什么是multipath 普通的电脑主机都是一个硬盘挂接到一个总线上，这里是一对一的关系。而到了有光纤组成的SAN环境，由于主机和存储通过了光纤交换机连接，这样的话，就构成了多对多的关系。也就是说，主机到存储可以有多条路径可以选择。主机到存储之间的IO由多条路径可以选择。既然，每个主机到所对应的存储可以经过几条不同的路径，如果是同时使用的话，I/O流量如何分配？其中一条路径坏掉了，如何处理？还有在操作系统的角度来看，每条路径，操作系统会认为是一个实际存在的物理盘，但实际上只是通向同一个物理盘的不同路径而已，这样是在使用的时候，就给用户带来了困惑。多路径软件就是为了解决上面的问题应运而生的。多路径的主要功能就是和存储设备一起配合实现如下功能： 1. 故障的切换和恢复 2. IO流量的负载均衡 3. 磁盘的虚拟化二、为什么使用multipath 由于多路径软件是需要和存储在一起配合使用的，不同的厂商基于不同的操作系统，都提供了不同的版本。并且有的厂商，软件和硬件也不是一起卖的，如果要使用多路径软件的话，可能还需要向厂商购买license才行。比如EMC公司基于linux下的多路径软件，就需要单独的购买license。其中，EMC提供的就是PowerPath，HDS提供的就是HDLM，更多的存储厂商提供的软件，可参考这里。当然，使用系统自带的免费多路径软件包，同时也是一个比较通用的包，可以支持大多数存储厂商的设备，即使是一些不是出名的厂商，通过对配置文件进行稍作修改，也是可以支持并运行的很好的。 ※请与IBM的RDAC、Qlogic的failover驱动区分开，它们都仅提供了Failover的功能，不支持Load Balance负载均衡方式。但multipath根据选择的策略不同，可支持多种方式，如：Failover、Multipath等。 Failover的功能解释：通俗地说，即当A无法为客户服务时，系统能够自动地切换，使B能够及时地顶上继续为客户提供服务，且客户感觉不到这个为他提供服务的对象已经更换。这里的

Linux多路径multipath安装配置

目录一、测试环境摘要 (4) 二、检查安装multipath (4) 2.1检查是否已安装 (4) 2.2若未安装则安装 (4) 2.2.1搭建yum源 (4) 2.2.2通过yum源安装并自启动 (4) 2.3核查安装是否成功 (5) 2.4设为开机自动启动 (5) 三、配置multipath (5) 3.1创建配置脚本 (5) 3.2赋予脚本执行权限 (7) 3.3执行脚本 (8) 3.4确认配置结果 (8) 3.5正常使用磁盘 (9) 四、测试 (9) 4.1负载均衡测试 (9) 4.2路径切换测试 (9) 五、常用操作命令 (10) 5.1启停mulitipath服务 (10) 5.2删除现有路径 (10) 5.3格式化路径（重新扫描） (10) 5.4查看多路径 (10) 5.5重载multipathd服务 (10) 5.6查看所有磁盘wwid (10) 5.7显示当前device mapper信息 (11)

说明：本文档中安装部署部分所提到的步骤都在测试环境中通过。可以作为安装部署参考手册。但因环境不同而无法保证在其他环境中准确无误（配置请按照特定环境自行修改）。本文档仅供参考，建议按照官方手册安装配置。蓝色字体—命令行绿色字体—脚本或输出结果暗红字体—表示变量（可更改）红色字体—需注意之处 # — root用户下执行

一、测试环境摘要 FreeNAS模拟iSCSI存储并划分空间分配给Linux5系统二、检查安装multipath 2.1检查是否已安装 [root@linux5 ~]# rpm -qa|grep mapper device-mapper-1.02.55-2.el5 device-mapper-1.02.55-2.el5 device-mapper-event-1.02.55-2.el5 device-mapper-multipath-0.4.7-42.el5 2.2若未安装则安装 2.2.1搭建yum源 mkdir -p /mnt/yum mount /dev/cdrom /mnt/yum 如果从ISO挂载，则使用如下命令： mount -o loop -t iso9660 /tmp/Redhat_5.0_U6_64.ISO /mnt/yum echo "[yum]">/etc/yum.repos.d/yum.repo echo "name=yum">>/etc/yum.repos.d/yum.repo echo "baseurl=file:///mnt/yum/Server">>/etc/yum.repos.d/yum.repo echo "enabled=1">>/etc/yum.repos.d/yum.repo echo "gpgcheck=1">>/etc/yum.repos.d/yum.repo echo "gpgkey=file:///mnt/yum/RPM-GPG-KEY-redhat-release">>/etc/yum.repos .d/yum.repo 2.2.2通过yum源安装并自启动 yum –y install device-mapper device-mapper-multipath

Windows中MPIO配置

Windows中MPIO配置概述 MultiPath I/O（MPIO）技术就是通过一条及以上的物理链路来访问网络存储设备,并且可以使用容错、流量负载平衡以及细粒度的I/O调度策备等方式，为网络存储应用提供更高的可用性和性能优势。目前,大多数厂商都提供了MPIO功能。但其实现技术方向多种。其功能的侧重点也不同，有的只能解决容错问题，有的即能解决容错问题，也能够提高性能。 Mcrosoft的iSCSI 2.x 中的initiator组件可兼容许多厂商提供的MPIO。它主要提供了两个MPIO的设计思路。一种是基于多连接的(Multi-connection)。关于这种方案，在 RFC3720中有具体的描述，在此不缀述。另一种是基于多会话的(Multi-Session)。这种方案是微软独创的。在RFC3720中解释会话是指同一个initiator（以下称客户端）和同一个target（以下称服务端）的逻辑上的连接。在这个逻辑的链路中可以有多个TCP连接组成（即Muti-connection）。而Target的标识在全球是唯一的。微软的思路是：可以有两个相同Target名的Target，但它所提供的LUN必须是指代着相同的存储资源。比如双控存储的两个控制器，但它们与客户端的TCP连接不同。这样，当用微软的客户端去登录这些双控时，就把它们认为同一个Target的不同路径。如下图：

下载如果没有ISCSI的安装包，可以从微软网站上下载： https://www.wendangku.net/doc/3b12030388.html,/downloads/details.aspx?familyid=12CB3C1A15D64585B3 85BEFD1319F825&displaylang=en 安装当安装时需要选择Microsoft MPIO Multipathing Support for iSCSI。如果没有选择的话，两个控制器映射过来的LUN，即使时同一个Target的。分别登录后，也会在磁盘管理中显示为两块磁盘。另外，要注意的是，只有Windows Server系列的操作系统这个选项才是被打开的，否则选择是变灰的。因此，这个实验无法的XP上做。发现Target 当initator成功安装后，就可以做测试了。双击桌面上的iSCSI图标，打开。并点击到DisCovery标签上。点击Target Portals下方的Add按扭，弹出如下对话框：

LINUX下多路径(multi-path)介绍及使用

LINUX下多路径（multi-path）介绍及使用一、什么是多路径普通的电脑主机都是一个硬盘挂接到一个总线上，这里是一对一的关系。而到了有光纤组成的SAN环境，或者由iSCSI组成的IPSAN环境，由于主机和存储通过了光纤交换机或者多块网卡及IP来连接，这样的话，就构成了多对多的关系。也就是说，主机到存储可以有多条路径可以选择。主机到存储之间的IO由多条路径可以选择。每个主机到所对应的存储可以经过几条不同的路径，如果是同时使用的话，I/O流量如何分配？其中一条路径坏掉了，如何处理？还有在操作系统的角度来看，每条路径，操作系统会认为是一个实际存在的物理盘，但实际上只是通向同一个物理盘的不同路径而已，这样是在使用的时候，就给用户带来了困惑。多路径软件就是为了解决上面的问题应运而生的。多路径的主要功能就是和存储设备一起配合实现如下功能： 1.故障的切换和恢复 2.IO流量的负载均衡 3.磁盘的虚拟化由于多路径软件是需要和存储在一起配合使用的，不同的厂商基于不同的操作系统，都提供了不同的版本。并且有的厂商，软件和硬件也不是一起卖的，如果要使用多路径软件的话，可能还需要向厂商购买license才行。比如EMC公司基于linux下的多路径软件，就需要单独的购买license。好在，RedHat和Suse的2.6的内核中都自带了免费的多路径软件包，并且可以免费使用，同时也是一个比较通用的包，可以支持大多数存储厂商的设备，即使是一些不是出名的厂商，通过对配置文件进行稍作修改，也是可以支持并运行的很好的。二、Linux下multipath介绍，需要以下工具包：在CentOS 5中，最小安装系统时multipath已经被安装，查看multipath是否安装如下： 1、device-mapper-multipath：即multipath-tools。主要提供multipathd和multipath等工具和multipath.conf等配置文件。这些工具通过device mapper的ioctr的接口创建和配置multipath 设备（调用device-mapper的用户空间库。创建的多路径设备会在/dev /mapper中）。

Linux下multipath介绍

一、什么是多路径普通的电脑主机都是一个硬盘挂接到一个总线上，这里是一对一的关系。而到了有光纤组成的SAN环境，或者由iSCSI组成的IPSAN环境，由于主机和存储通过了光纤交换机或者多块网卡及IP来连接，这样的话，就构成了多对多的关系。也就是说，主机到存储可以有多条路径可以选择。主机到存储之间的IO由多条路径可以选择。每个主机到所对应的存储可以经过几条不同的路径，如果是同时使用的话，I/O流量如何分配？其中一条路径坏掉了，如何处理？还有在操作系统的角度来看，每条路径，操作系统会认为是一个实际存在的物理盘，但实际上只是通向同一个物理盘的不同路径而已，这样是在使用的时候，就给用户带来了困惑。多路径软件就是为了解决上面的问题应运而生的。多路径的主要功能就是和存储设备一起配合实现如下功能： 1.故障的切换和恢复 2.IO流量的负载均衡 3.磁盘的虚拟化由于多路径软件是需要和存储在一起配合使用的，不同的厂商基于不同的操作系统，都提供了不同的版本。并且有的厂商，软件和硬件也不是一起卖的，如果要使用多路径软件的话，可能还需要向厂商购买license才行。比如EMC公司基于linux下的多路径软件，就需要单独的购买license。好在，RedHat和Suse的2.6的内核中都自带了免费的多路径软件包，并且可以免费使用，同时也是一个比较通用的包，可以支持大多数存储厂商的设备，即使是一些不是出名的厂商，通过对配置文件进行稍作修改，也是可以支持并运行的很好的。二、Linux下multipath介绍，需要以下工具包：在CentOS 5中，最小安装系统时multipath已经被安装，查看multipath是否安装如下：image 1、device-mapper-multipath：即multipath-tools。主要提供multipathd和multipath等工具和multipath.conf等配置文件。这些工具通过device mapper的ioctr的接口创建和配置multipath 设备（调用device-mapper的用户空间库。创建的多路径设备会在/dev /mapper中）。 2、device-mapper：主要包括两大部分：内核部分和用户部分。内核部分主要由device mapper 核心（dm.ko）和一些target driver（md-multipath.ko）。核心完成设备的映射，而target根据映射关系和自身特点具体处理从mappered device 下来的i/o。同时，在核心部分，提供了一个接口，用户通过ioctr可和内核部分通信，以指导内核驱动的行为，比如如何创建mappered device，这些divece的属性等。linux device mapper的用户空间部分主要包括device-mapper这个包。其中包括dmsetup工具和一些帮助创建和配置mappered device的库。这些库主要抽象，封装了与ioctr通信的接口，以便方便创建和配置mappered device。multipath-tool的程序中就需要调用这些库。 3、dm-multipath.ko和dm.ko：dm.ko是device mapper驱动。它是实现multipath的基础。dm-multipath其实是dm的一个target驱动。 4、scsi_id：包含在udev程序包中，可以在multipath.conf中配置该程序来获取scsi设备的序号。通过序号，便可以判断多个路径对应了同一设备。这个是多路径实现的关键。scsi_id 是通过sg驱动，向设备发送EVPD page80或page83 的inquery命令来查询scsi设备的标识。但一些设备并不支持EVPD 的inquery命令，所以他们无法被用来生成multipath设备。但可以改写scsi_id，为不能提供scsi设备标识的设备虚拟一个标识符，并输出到标准输出。

multipath introduction

Configuring Linux to Enable Multipath I/O 存储是数据中心关键组成部分，并且SAN可以对多重冗余数据路径（multiple redundant data paths）提供极好地高可用性和负载均衡。为了在Linux 操作系统环境中充分利用这些好处，企业IT部门可以使用一些程序来建立多路径I/O的配置。在数据中心环境中，为了将宕机时间和服务中断带来的损失最小化，IT部门必须避免在任何高可用性系统中使用单点故障（single point of failure）。对于SAN，管理员可以在服务器和存储系统之间建立多重冗余数据路径（multipaths），来避免硬件错误导致的数据流的中断。为了管理一个multipath I/O配置，管理员应该要保证服务器操作系统支持multipath I/O 并正确配置，来从存储系统中获得数据，在失败的时候以后第二条路径可以作为备用。对于linux系统，有两种multipath I/O程序可以使用：device mapper multipath 和EMC PowerPath 软件。这篇文章提供了这两种应用的概述，并且比较了他们之间的优缺点。 Understanging the basics of multipath I/O 在下面的例图中，是一个典型的高可用性SAN存储的配置。它包括一个Dell PowerEdge 服务器（有几个HBAs----host bus adapters）,两个FC交换机，以及一个Dell/EMC CX系列的存储阵列。一个集群应该包括多个PowerEdge 服务器。正如例图所示，在服务器和存储系统之间有多个数据路径，存储系统提供了必要的冗余（Redundancy）。In such a configuration —for example, a PowerEdge server running Red Hat?Enterprise Linux 4—a logical unit (LUN) on the CX storage that is assigned to the server is detected as many times as there are paths available.的那个一个HBA 驱动加载时，SCSI设备中间层会启动对总线的扫描，然后通过每个可用的路径侦测到所有被分配的存储LUN。于是，就会有很多SCSI磁盘设备被操作系统注册。在例图1中，有四个路径通往存储系统，因此一个被指派给特定的服务器的LUN就被侦测到了四次。这四个SCSI设备被HBA驱动侦测到，并都被注册到操作系统了。对然冗余路径带来了好处，但是它带来的挑战也是必须要考虑的。这些挑战包括为I/O 识别一个特定的设备，管理同一个物理设备的多重设备（managing multiple devices of the same physical device.）

centos上iscsi+multipath多路径存储配置手册

centos上iscsi+multipath多路径存储配置手册目录一：客户端安装iscsi包。二：zai共享存储上为服务器划分磁盘空间。三：启用iscsi设备。四：安装dm-multipath包。五：配置参数修改和测试。一;客户端添加iscsi 安装包。 1、服务器安装iscsi initiator包。安装包从安装光盘中找到 root@https://www.wendangku.net/doc/3b12030388.html,~>rpm -qa |grep iscsi iscsi-initiator-utils-6.2.0.868-0.7.el5 2、在/etc/iscsi/目录下/etc/iscsi/initiatorname.iscsi 查看此文件可发现主机端的iqn号码。在EVA command view管理软件中添加HOST时需用到。二:为服务器划分磁盘阵列的磁盘空间（即Virtual disk）具体详见存储配置。三:启用ISCSI设备 1、在服务器端，启动ISCSI服务： root@https://www.wendangku.net/doc/3b12030388.html,~>service iscsi start 2、查询ISCSI设备（HP storageworks mpx100）target的iqn号码：（必须） root@https://www.wendangku.net/doc/3b12030388.html,~>iscsiadm -m discovery -t sendtargets -p 192.168.14.1 192.168.14.1:3260,0 https://www.wendangku.net/doc/3b12030388.html,.hp:fcgw.mpx100.0.50014380025bad30.50014380025bad38 3、登陆到ISCSI存储设备

linux6.4配置emc存储多路径

操作系统linux6.4 存储：emc wmax 在emc划分好LUN后，通过配置（FC）将空间分配给linux服务器，在Linux系统中可以查看到emc的LUN，在linux中显示为一个物理分区emcpowera 因为存储有多路径冗余，所以在linux系统端需要安装配置多路径管理软件，linux系统自带了一个多路径管理软件multipath，EMC也有自己的多路径管理软件，这里介绍下emcpwerpath多路径的软件的安装和配置。由于emcpower与系统自带的多路径管理软件multipath冲突，所以需要将multipathd服务关闭。将/etc/multipath.conf文件进行备份 #cp /etc/multipath.conf /etc/multipath.conf.bak 编辑/etc/multipath.conf文件 #vi /etc/multipath.conf 修改 blacklist { devnode "*" }

修改multipathd服务 # chkconfig multipathd off # chkconfig --list multipathd 生成新的开机启动加载的.img文件 #dracut /boot/initramfs-wo-DM-$(uname -r).img $(uname -r) 执行完后会生成.img文件/boot/目录下

修改开机启动的.img文件（修改前对其文件进行备份cp grub.conf grub.conf.bak） #vi grup.conf

将initrd修改为新生成的.img文件，保存后重启服务器，查看multipath的状态#multipath -ll multipath配置好后，开始安装emcpower 安装emcpower需要emc的key，可以通过已安装的服务器上产看 #powermt check registration 得到key之后，我们开始安装EMCpowerpath

liunx和DELL MD3200+多路径配置

Redhat5.5+MD3200 配置device-mapper multipath v0.1 by dylan MD32xx及MD32xxi的在linux下的多路径管理已经由redhat的multipath来管理由此产生两个新问题 1，20M的access lun在系统初始化时无法被屏蔽，fdisk –l仍然看到2个20M的accesslun 2，系统下看到的存储上的lun由redhat的device-mapper multipath接管，此例中没有装dell resourceCD提供的scsi_dh_rdac-1.4.1.0-2dkms.noarch.rpm，此包是针对5.4的，装这个包时会生成四个模块dm-multipath.ko，scsi_dh.ko，scsi_dh_rdac.ko，scsi_dh_alua.ko（这四个模块redhat5.5本身就有），此包重生initrd并改写/etc/multipath.conf和/etc/modprobe.conf文件。建议手动安装scsi_dh_rdac-1.4.1.0-2dkms.noarch.rpm去重生initrd文件，不然启动时不会自动加载scsi_dh_rdac.ko（此模块还是需要的，因为32xx产品是LSI的，这个scsi_dh_rdac.ko就是Path Checker，用来检查冗余路径的，参考https://www.wendangku.net/doc/3b12030388.html,/lvm2/wiki/MultipathUsageGuide）。主要步骤：开启multipathd服务，使用multipath –ll查看lun，用fdisk分区，kpartx增加device-mapper，格式化并挂载下边是multipath的配置实例，重点在于系统下对映射Lun的配置，使用multipath的前提 1，modprobe dm-multipath 加载dm-multipath模块及其依赖模块， 2，service multipathd start 开始multipathd服务 1，将MD3200上的lun映射给redhat5.5主机后，用multipath -ll查看，可以看到20M的access lun 和一个2G的映射lun 2，修改/etc/multipath.conf文件，找到blacklist，并在其中添加红圈一行， Blacklist是黑名单列表，意思让multipath输出时不显示它们， Wwid的值为multipath –ll输出的值，看上图可以看到

Linux多路径配置

md3600i存储服务器连接 iscsi+multipath配置在Dell Compellent存储上划分Volume以及Linux多路径配置 LINUX下多路径（multi-path）介绍及使用 2013-05-16 11:15:34| 分类： openfiler系统+fr | 标签： |举报 |字号大中小订阅一、什么是多路径普通的电脑主机都是一个硬盘挂接到一个总线上，这里是一对一的关系。而到了有光纤组成的SAN环境，或者由iSCSI组成的IPSAN环境，由于主机和存储通过了光纤交换机或者多块网卡及IP来连接，这样的话，就构成了多对多的关系。也就是说，主机到存储可以有多条路径可以选择。主机到存储之间的IO由多条路径可以选择。每个主机到所对应的存储可以经过几条不同的路径，如果是同时使用的话，I/O流量如何分配？其中一条路径坏掉了，如何处理？还有在操作系统的角度来看，每条路径，操作系统会认为是一个实际存在的物理盘，但实际上只是通向同一个物理盘的不同路径而已，这样是在使用的时候，就给用户带来了困惑。多路径软件就是为了解决上面的问题应运而生的。多路径的主要功能就是和存储设备一起配合实现如下功能： 1.故障的切换和恢复 2.IO流量的负载均衡 3.磁盘的虚拟化由于多路径软件是需要和存储在一起配合使用的，不同的厂商基于不同的操作系统，都提供了不同的版本。并且有的厂商，软件和硬件也不是一起卖的，如果要使用多路径软件的话，可能还需要向厂商购买license才行。比如EMC公司基于linux下的多路径软件，就需要单独的购买license。好在， RedHat和Suse的2.6的内核中都自带了免费的多路径软件包，并且可以免费使用，同时也是一个比较通用的包，可以支持大多数存储厂商的设备，即使是一些不是出名的厂商，通过对配置文件进行稍作修改，也是可以支持并运行的很好的。二、Linux下multipath介绍，需要以下工具包：在CentOS 5中，最小安装系统时multipath已经被安装，查看multipath是否安装如下：