1751851
Members
5365
Online
108782
Solutions
SOLVED
1) The original Digital Equipment Corporation storage controller 20 years ago, the HSC, was the Hierarchical Storage Controller. It used a proprietary Computer Interconnect (CI) interface between hosts and storage. As new variants evolved to use other interfaces and protocols, the "HS" stuck with them. It is my understanding, the "V" in HSV stands for "Virtual", as in Virtual Storage Array.
6) A vdisk (virtual disk) is the logical entity that is eventually presented to one or more hosts. One could make an argument that it is not really a (MS-Windows?) LUN until it is presented. A virtual disk Family is a group of the base (active) vdisk and any related snapshots. The snapshots are associated with the base disk and are useless without it. Most virtual disk families typically consist of just the active vdisk.
7) A disk group is a raw storage pool of physical spindles. There is an eight-disk minimum, and if sparing (hot spares) is desired, then the available storage pool is decreased by TWO spindles' worth of space per sparing level (single or double). The impact of sparing per disk group can be minimized by having few disk groups and many disks per group. There is a whitepaper at the EVA web page discussing recommended best practices.
Virtual disks are sliced across the N spindles in the disk group, with 1/Nth of the required storage from each spindle. The redundancy (VRAID) level is selected on a per vdisk basis. A disk group can have many vdisks, some with VRAID5, some with VRAID1 and even some with VRAID0 (just a stripe). Since an EVA3000 can support up to 56 disks, you COULD have at most 7 disk groups. In reality, you want only one or maybe two. Both the EVA3000 and EVA5000 consist of a pair of controllers. Note there is no RAID1 in the traditional sense; VRAID1 is more like RAID 0+1. Every vdisk spans every spindle in its disk group.
9) A snapshot is always derived from the same disk group as the parent (ACTIVE) vdisk. A snapclone can be created from ANY disk group with sufficient storage space. Both snapshot and snapclone can be presented to an arbitrary host; fromm the host point-of-view, either appears as a complete disk. For example, a production database could exist on a vdisk, with backup being done involving a snapshot of the vdisk presented to a different system with tape drive(s). Writing to tape would not impose overhead on the production CPU.
And, both snapshot and snapclone are modifiable after their creation. A snap of the previously mentioned production database could be created and presented to the the developers, again on a non-production system, for development and testing. If during the course of testing they corrupt the database, no big deal. Destroy the snapshot and give them a new one.
Point in time recovery would require presenting both the snapshot and vdisk to some host as two LUNs. At the host, do whatever is required to prepare the volume, then use the host to transfer the data from the snapshot LUN to the vdisk LUN. Depending on what portion of the vdisk has already been reallocated to the snapshot, it may be faster to create a new vdisk of appropriate size and redundancy level, and present that new disk and snapshot to the above-mentioned host. Once the data is restored, simply unpresent the snapshot and ORIGINAL vdisk and delete them. The new vdisk is now simply the production volume. The new vdisk family name could be updated to have the name of the original vdisk family (which would no longer exist).
Hope this helps.
Note: While I am an HPE Employee, all of my comments (whether noted or not), are my own and are not any official representation of the company
6) A vdisk (virtual disk) is the logical entity that is eventually presented to one or more hosts. One could make an argument that it is not really a (MS-Windows?) LUN until it is presented. A virtual disk Family is a group of the base (active) vdisk and any related snapshots. The snapshots are associated with the base disk and are useless without it. Most virtual disk families typically consist of just the active vdisk.
7) A disk group is a raw storage pool of physical spindles. There is an eight-disk minimum, and if sparing (hot spares) is desired, then the available storage pool is decreased by TWO spindles' worth of space per sparing level (single or double). The impact of sparing per disk group can be minimized by having few disk groups and many disks per group. There is a whitepaper at the EVA web page discussing recommended best practices.
Virtual disks are sliced across the N spindles in the disk group, with 1/Nth of the required storage from each spindle. The redundancy (VRAID) level is selected on a per vdisk basis. A disk group can have many vdisks, some with VRAID5, some with VRAID1 and even some with VRAID0 (just a stripe). Since an EVA3000 can support up to 56 disks, you COULD have at most 7 disk groups. In reality, you want only one or maybe two. Both the EVA3000 and EVA5000 consist of a pair of controllers. Note there is no RAID1 in the traditional sense; VRAID1 is more like RAID 0+1. Every vdisk spans every spindle in its disk group.
9) A snapshot is always derived from the same disk group as the parent (ACTIVE) vdisk. A snapclone can be created from ANY disk group with sufficient storage space. Both snapshot and snapclone can be presented to an arbitrary host; fromm the host point-of-view, either appears as a complete disk. For example, a production database could exist on a vdisk, with backup being done involving a snapshot of the vdisk presented to a different system with tape drive(s). Writing to tape would not impose overhead on the production CPU.
And, both snapshot and snapclone are modifiable after their creation. A snap of the previously mentioned production database could be created and presented to the the developers, again on a non-production system, for development and testing. If during the course of testing they corrupt the database, no big deal. Destroy the snapshot and give them a new one.
Point in time recovery would require presenting both the snapshot and vdisk to some host as two LUNs. At the host, do whatever is required to prepare the volume, then use the host to transfer the data from the snapshot LUN to the vdisk LUN. Depending on what portion of the vdisk has already been reallocated to the snapshot, it may be faster to create a new vdisk of appropriate size and redundancy level, and present that new disk and snapshot to the above-mentioned host. Once the data is restored, simply unpresent the snapshot and ORIGINAL vdisk and delete them. The new vdisk is now simply the production volume. The new vdisk family name could be updated to have the name of the original vdisk family (which would no longer exist).
Hope this helps.
Note: While I am an HPE Employee, all of my comments (whether noted or not), are my own and are not any official representation of the company
