- Community Home
- >
- Storage
- >
- Entry Storage Systems
- >
- Disk Enclosures
- >
- Re: Fully Pre-Carving an EVA Array - Good or Bad?
Disk Enclosures
1752805
Members
5482
Online
108789
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
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
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
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
12-14-2006 05:41 AM
12-14-2006 05:41 AM
Re: Fully Pre-Carving an EVA Array - Good or Bad?
Peter,
Glad this caught your attention..
"One of the taks that needs lots of CPU ressources in an EVA is deleting VDISKs. The larger the VDISK is and the more blocks that are actually allocated the longer it takes. "
So do you agree that pre-allocating and simply re-using VDISKS can be considered a good practice?
We currently have EVA5K's -- currently at VCS 3.028 which we are planning to upgrade to VCS 4.004 or whatever will be available early next year. The reason for this is so we can do away with SecurePath and just use DMP on VxVM. We've been using VxVM/DMP on both EVA 5K and XP disks that are currently co-presented on our HP-UX/Solaris hosts. The EVA side, it is still path protected by SecurePath and DMP ignores it.. Once we are at A/A(VCS 4.X) on the EVA5Ks - we intend to drop SecurePath and just have VxVM/DMP manage pathing/balancing on the EVA LUNS...
And with this, we will now be managing/treating EVA Vdisks as if they were XP disks... we will no longer "delete" vdisks but simply uninitialize and de-present them.
Glad this caught your attention..
"One of the taks that needs lots of CPU ressources in an EVA is deleting VDISKs. The larger the VDISK is and the more blocks that are actually allocated the longer it takes. "
So do you agree that pre-allocating and simply re-using VDISKS can be considered a good practice?
We currently have EVA5K's -- currently at VCS 3.028 which we are planning to upgrade to VCS 4.004 or whatever will be available early next year. The reason for this is so we can do away with SecurePath and just use DMP on VxVM. We've been using VxVM/DMP on both EVA 5K and XP disks that are currently co-presented on our HP-UX/Solaris hosts. The EVA side, it is still path protected by SecurePath and DMP ignores it.. Once we are at A/A(VCS 4.X) on the EVA5Ks - we intend to drop SecurePath and just have VxVM/DMP manage pathing/balancing on the EVA LUNS...
And with this, we will now be managing/treating EVA Vdisks as if they were XP disks... we will no longer "delete" vdisks but simply uninitialize and de-present them.
Hakuna Matata.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-14-2006 07:38 AM
12-14-2006 07:38 AM
Solution
Hi Nelson
Yes, preallocating is a good practice!
When going to VCS4.004 you need to make sure that you set your pathes correctly especially when doing heavy reads!
You know since with VCS4.x all LUNs can be accessed through both controllers and if you set round robbin you could end up doing lots of proxy reads through the "wrong" controller which means overhead!
So best is to have your preferred pathes on the LUN owning controller!
This will be adresse by implementing ALUA which for the EVA to my knowledge is currently only available for Windows with MPIO DSM 2.01.00 and Solaris with MPxIO.
ALUA means Asymmetric Logical Units Access and has been defined by INCITS T10.
You will see it more and more in the future!
Perhaps with VxVM/DMP as well?!
Cheers
Peter
PS: To make my previous post clearer: You cannot convert a container directly to a VDISK, you can use it to create snapshots or snapclones! See attached a scteenshot of CV with the button to create a container. Note that the vdisk needs to be unpresented before you get this option!
Yes, preallocating is a good practice!
When going to VCS4.004 you need to make sure that you set your pathes correctly especially when doing heavy reads!
You know since with VCS4.x all LUNs can be accessed through both controllers and if you set round robbin you could end up doing lots of proxy reads through the "wrong" controller which means overhead!
So best is to have your preferred pathes on the LUN owning controller!
This will be adresse by implementing ALUA which for the EVA to my knowledge is currently only available for Windows with MPIO DSM 2.01.00 and Solaris with MPxIO.
ALUA means Asymmetric Logical Units Access and has been defined by INCITS T10.
You will see it more and more in the future!
Perhaps with VxVM/DMP as well?!
Cheers
Peter
PS: To make my previous post clearer: You cannot convert a container directly to a VDISK, you can use it to create snapshots or snapclones! See attached a scteenshot of CV with the button to create a container. Note that the vdisk needs to be unpresented before you get this option!
I love storage
- « Previous
-
- 1
- 2
- Next »
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