Multipath Testing...

[Simon_G]

Greetings!

I have set up device mapper multipath on rhel 6.2 and have storage from  vendors attached, (HP EVA, EMC Symm, Hitachi). I am trying to think of some test scenarios, itis a 2 node ORACLE RAC cluster. I wanted to have all scenarios for failover and multipath testing and also performance parameters. Could someone suggest some useful scenarios for this kind of environment?

Thanks

Simon.

[Matti_Kurkela]

You might want to:

- compare the built-in defaults (listed in /usr/share/doc/device-mapper-multipath-<version>/multipath.conf.defaults) to the most recent recommendations from the storage manufacturers, and if there are differences, see if they have significant performance impact either way

- test the different path selector algorithms, particularly in situations where one or more paths have failed/running slower than normal: I'd guess the queue-length and service-time selectors might perform significantly better than round-robin when there is a fault that causes a path to slow down but not quite fail completely.

For performance testing, important cases will depend on the nature of your application. But backup and restore are always important: see how the test environment handles the full backup & restore of a database that is at least roughly similar to a production workload you're familiar with.

[Simon_G]

Matti

Thanks much for your reply!

I will certainly look into those. We are using EMC PowerPath now, so trying our best to make this as close as possible to EMC PowerPath. One thing is i am not able to pull the FA port details summary that PP provides (looks like not possible with Linux Multipath).  Is there a way to test performance parameters?

Regards

Simon

[Matti_Kurkela]

 > Is there a way to test performance parameters?

The usual way for performance testing: choose some task that is repeatable, make the system do it N number of times as fast as possible, see how much time it takes, divide by N to get a value that describes the "speed" of the system regarding the task.

You could do this with some tasks that are relevant to your specific workload, or you could use I/O benchmarking tools, like iozone, iometer or fio for example:

http://www.iozone.org/

http://www.iometer.org/

http://pkgs.repoforge.org/fio/