- Community Home
- >
- Storage
- >
- Entry Storage Systems
- >
- Disk Enclosures
- >
- Re: EVA4000 throughput
Categories
Company
Local Language
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
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
Community
Resources
Forums
Blogs
- 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
тАО11-21-2005 10:48 PM
тАО11-21-2005 10:48 PM
As you know on EVA 4000 there are 4 Host ports. Each of them can connect with a 2 Gb/s connection to a SAN switch. So what does HP say EVA 4000 can handle 350 MB/s throughput? How can I test it?
Alireza
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-21-2005 11:51 PM
тАО11-21-2005 11:51 PM
Re: EVA4000 throughput
Bullcookies.
Sustained throughput is different than bus speeds.
You can test the performance with some performance testing software and a large configuration. We typically test with as many drives as the array can handle, and usually in RAID1. Of course, you'll need several fast servers.
Regards,
Vince
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2005 03:21 AM
тАО11-22-2005 03:21 AM
Re: EVA4000 throughput
It seems I did not explain clear. I mean as long as we have 2 Gb/s connection we cannot get 350 MB/s. How did HP test it?
Alireza
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2005 03:40 AM
тАО11-22-2005 03:40 AM
Re: EVA4000 throughput
350/4 = 87.5 MegaBytes/second throughput per port.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2005 04:30 AM
тАО11-22-2005 04:30 AM
Re: EVA4000 throughput
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2005 04:52 AM
тАО11-22-2005 04:52 AM
Re: EVA4000 throughput
You don't create a LUN, you create a virtual disk. The virtual disk is then mapped to the SCSI LUN address space of each defined host when you 'present' it. You normally have 4 paths, so there are 4 different SCSI LUNs to access a single virtual disk.
It is important to understand that on every EVA (3000/4000/5000/6000/8000) a single virtual disk is managed by one of the controllers at a time - a different virtual disk, of course, can be managed by the other controller.
On the new EVAs (4000/6000/8000) you can do I/O through the non-managing controller as well, but there is a performance loss, because the data need to be re-routed over the mirror ports to the managing controller. It is not a great deal for write I/Os, because the data is usually sent anyway to go into the mirror cache, but the read I/Os will create additional traffic.
The paths through the managing controller are called the performance paths and I recommend that you only use them. That will give you two paths with 200 MegaBytes/second - should be OK, because the EVA4000 has two back-end loops with 200 MegaBytes/second anyway.
In most cases you are dealing with multiple virtual disks. You should divide them over both controllers so that you have some kind of load sharing and can make efficient use of all 4 paths.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2005 06:53 AM
тАО11-22-2005 06:53 AM
Re: EVA4000 throughput
I want to setup an enormous Oracle RAC system. I need I/O bandwidth as much as possible. I would rather to use all 350MB/s capacity of EVA4000. According to Oracle 10g documentation, I need just one disk (LUN or anything else that is existed in EVA environment) for storing my data (we will use new Oracle ASM technology instead of old RAW portions as a shared storage). I/O capacity is very important for our DBA and because of that we want to buy EVA. We will use EVA 2C1D configuration. What is your solution for this case?
Any kind of experience and help are highly appreciated
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2005 07:05 AM
тАО11-22-2005 07:05 AM
Re: EVA4000 throughput
I am a bit skeptical that you will be able to get 350MB/s with an EVA4000 2C1D, because it has only 14 disk drives. Each drive would have to be able to run with almost 200 IOPS to be able to deliver that much data.
The chunk size is 128KB, so:
350,000,000 / 14 / 128,000 = 195.3125
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2005 07:49 AM
тАО11-22-2005 07:49 AM
Re: EVA4000 throughput
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2005 07:58 AM
тАО11-22-2005 07:58 AM
Re: EVA4000 throughput
Than bind first LUN for one EVA controller, second--to another.