- Community Home
- >
- Servers and Operating Systems
- >
- HPE ProLiant
- >
- ProLiant Servers (ML,DL,SL)
- >
- Does Multipath required in Shared SAN environment
ProLiant Servers (ML,DL,SL)
1753554
Members
4646
Online
108795
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-15-2009 09:07 AM
тАО08-15-2009 09:07 AM
Does Multipath required in Shared SAN environment
we have
DL380 (2 server) with 4 HBA Cards(two each)
HP MSA2000 SAN 01
HP FABRIC switch 02
and I run RHEL 5.2 OS with oracle 11g cluster active/passive.
since I have the redundant paths to storage, do I need to activate redhar Multipath service?
DL380 (2 server) with 4 HBA Cards(two each)
HP MSA2000 SAN 01
HP FABRIC switch 02
and I run RHEL 5.2 OS with oracle 11g cluster active/passive.
since I have the redundant paths to storage, do I need to activate redhar Multipath service?
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-15-2009 11:09 AM
тАО08-15-2009 11:09 AM
Re: Does Multipath required in Shared SAN environment
You need multipathing when You have multiple paths to same LUN.
Remember to give Kudos to answers! (click the KUDOS star)
You can find me from Twitter @JKytsi
You can find me from Twitter @JKytsi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-15-2009 07:30 PM
тАО08-15-2009 07:30 PM
Re: Does Multipath required in Shared SAN environment
In this case yes, I have Multipath to same LUN(first path: node A -> HBA A -> controller A -> LUN 01 and second path controller B: node A -> HBA B -> controller B -> LUN 01).
when fail of one path still I can access the LUN from available path.
I believe I allready have hardware Multipathing. Then why should I use RHEL 5.3 Multipath service?
when fail of one path still I can access the LUN from available path.
I believe I allready have hardware Multipathing. Then why should I use RHEL 5.3 Multipath service?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-15-2009 11:51 PM
тАО08-15-2009 11:51 PM
Re: Does Multipath required in Shared SAN environment
Yes, you have multiple paths from each server to disks at the hardware level. But without some kind of multipath service, your system does not "know" that and cannot redirect I/O operations to another path if one path fails.
With a multipath HW configuration, you'll need a component in your system that knows that e.g. /dev/sda and /dev/sdk are in fact the same disk: if an I/O operation through /dev/sda fails, the same operation can be retried through /dev/sdk.
Usually, this is done at the OS level, and a new device is set up for the function of "access a particular disk using any available path". With RedHat multipath service, these devices are named like /dev/mapper/mpath or /dev/mapper/. If the applications use these devices, it is possible to add and remove disk paths while the applications are running: the multipath service will automatically re-map the I/O operations to use the appropriate paths.
If your application explicitly uses e.g. /dev/sda in its configuration and the path /dev/sda fails, the application will fail. Then the application configuration must be changed to make it use the other path.
The multipath service will also allow load-balancing between the paths: when both paths are OK but one HBA is busy transferring data from another disk, the multipath service can reroute the request through the other HBA. This will maximize the available data bandwidth, and will give you better performance.
MK
With a multipath HW configuration, you'll need a component in your system that knows that e.g. /dev/sda and /dev/sdk are in fact the same disk: if an I/O operation through /dev/sda fails, the same operation can be retried through /dev/sdk.
Usually, this is done at the OS level, and a new device is set up for the function of "access a particular disk using any available path". With RedHat multipath service, these devices are named like /dev/mapper/mpath
If your application explicitly uses e.g. /dev/sda in its configuration and the path /dev/sda fails, the application will fail. Then the application configuration must be changed to make it use the other path.
The multipath service will also allow load-balancing between the paths: when both paths are OK but one HBA is busy transferring data from another disk, the multipath service can reroute the request through the other HBA. This will maximize the available data bandwidth, and will give you better performance.
MK
MK
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP