HP BL680c XenServer Administrator's Guide 4.1.0 - Page 20

Warning, 2.4. Shared iSCSI Storage

Get HP BL680c - ProLiant - G5 PDF manuals and user guides
UPC - 884420396314
View all HP BL680c manuals
Add to My Manuals
Save this manual to your list of manuals

Page 20 highlights

Storage for virtual disks (VDIs). VDIs are stored in the Microsoft VHD format only. Moreover, as NFS SRs can be shared, VDIs stored in a shared SR allow VMs to be started on any XenServer Hosts in a resource pool and be migrated between them using XenMotion with no noticeable downtime. Creating an NFS SR requires the hostname or IP address of the NFS server. The sr-probe command can provide a list of valid destination paths exported by the server on which the SR may be created. The NFS server must be configured to export the specified path to all XenServer Host in the pool, or the creation of the SR and the plugging of the PBD record will fail. As mentioned at the beginning of this chapter, VDIs stored on NFS are sparse. The image file is allocated as the VM writes data into the disk. This has the considerable benefit that VM image files take up only as much space on the NFS filer as is required. If a 100GB VDI is allocated for a new VM and an OS is installed, the VDI file will only reflect the size of the OS data that has been written to the disk rather than the entire 100GB. VHD files may also be chained, allowing two VDIs to share common data. In cases where a NFS-based VM is cloned, the resulting VMs will share the common on-disk data at the time of cloning. Each will proceed to make its own changes in an isolated copy-on-write version of the VDI. This feature allows NFS-based VMs to be quickly cloned from templates, facilitating very fast provisioning and deployment of new VMs. As VHD-based images involve extra metadata to provide sparseness and chaining, the format is not as high-performance as LVM-based storage. In cases where performance really matters, it is well worth forcibly allocating the sparse regions of an image file. This will improve performance at the cost of consuming additional disk space. XenServer's NFS and VHD implementation assume that they have full control over the SR directory on the NFS server. Administrators should not modify the contents of the SR directory, as this can risk corrupting the contents of VDIs. For NFS best practices, there are performance and access control issues to consider. Access control can specify which client IP address has access to an NFS export. Alternatively, one can allow world read/write access control. The administrator ought to make policy decisions based on the specific requirements of their installation. XenServer has been tuned for enterprise-class filers that use non-volatile RAM to provide fast acknowledgments of write requests while maintaining a high degree of data protection from failure. For reference, XenServer has been tested extensively against Network Appliance FAS270c and FAS3020c filers, using Data OnTap 7.2.2. In situations where XenServer is used with lower-end filers, it will err on the side of caution by waiting for all writes to be acknowledged before passing acknowledgments on to guest VMs. This will incur a noticeable performance cost, and might be remedied by setting the filer to present the SR mount point as an asynchronous mode export. Asynchronous exports acknowledge writes that are not actually on disk, and so administrators should consider the risks of failure carefully in these situations. Warning Since VDIs on NFS SRs are created as sparse, administrators must ensure that enough disk space exists on NFS SRs for all required VDIs. XenServer Hosts do not enforce that the space required for VDIs on NFS SRs is actually present. 3.2.4. Shared iSCSI Storage XenServer provides support for shared SRs on iSCSI LUNs. iSCSI is supported using the open-iSCSI software iSCSI initiator or by using a supported iSCSI Host Bus Adapter (HBA). The steps for using iSCSI HBAs are identical to those for Fibre Channel HBAs, both of which are described in Section 3.2.5, "Shared LVM storage over FC or iSCSI hardware HBAs ". 14

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
Storage
14
for virtual disks (VDIs). VDIs are stored in the Microsoft VHD format only. Moreover, as NFS SRs can be
shared, VDIs stored in a shared SR allow VMs to be started on any XenServer Hosts in a resource pool
and be migrated between them using XenMotion with no noticeable downtime.
Creating an NFS SR requires the hostname or IP address of the NFS server. The sr-probe command can
provide a list of valid destination paths exported by the server on which the SR may be created. The NFS
server must be configured to export the specified path to all XenServer Host in the pool, or the creation of
the SR and the plugging of the PBD record will fail.
As mentioned at the beginning of this chapter, VDIs stored on NFS are sparse. The image file is allocated as
the VM writes data into the disk. This has the considerable benefit that VM image files take up only as much
space on the NFS filer as is required. If a 100GB VDI is allocated for a new VM and an OS is installed, the
VDI file will only reflect the size of the OS data that has been written to the disk rather than the entire 100GB.
VHD files may also be chained, allowing two VDIs to share common data. In cases where a NFS-based VM
is cloned, the resulting VMs will share the common on-disk data at the time of cloning. Each will proceed to
make its own changes in an isolated copy-on-write version of the VDI. This feature allows NFS-based VMs
to be quickly cloned from templates, facilitating very fast provisioning and deployment of new VMs.
As VHD-based images involve extra metadata to provide sparseness and chaining, the format is not as
high-performance as LVM-based storage. In cases where performance really matters, it is well worth forcibly
allocating the sparse regions of an image file. This will improve performance at the cost of consuming
additional disk space.
XenServer's NFS and VHD implementation assume that they have full control over the SR directory on the
NFS server. Administrators should not modify the contents of the SR directory, as this can risk corrupting
the contents of VDIs.
For NFS best practices, there are performance and access control issues to consider. Access control can
specify which client IP address has access to an NFS export. Alternatively, one can allow world read/write
access control. The administrator ought to make policy decisions based on the specific requirements of
their installation.
XenServer has been tuned for enterprise-class filers that use non-volatile RAM to provide fast acknowl-
edgments of write requests while maintaining a high degree of data protection from failure. For reference,
XenServer has been tested extensively against Network Appliance FAS270c and FAS3020c filers, using
Data OnTap 7.2.2.
In situations where XenServer is used with lower-end filers, it will err on the side of caution by waiting for
all writes to be acknowledged before passing acknowledgments on to guest VMs. This will incur a notice-
able performance cost, and might be remedied by setting the filer to present the SR mount point as an
asynchronous mode export. Asynchronous exports acknowledge writes that are not actually on disk, and
so administrators should consider the risks of failure carefully in these situations.
Warning
Since VDIs on NFS SRs are created as sparse, administrators must ensure that enough disk space
exists on NFS SRs for all required VDIs. XenServer Hosts do not enforce that the space required
for VDIs on NFS SRs is actually present.
3.2.4. Shared iSCSI Storage
XenServer provides support for shared SRs on iSCSI LUNs. iSCSI is supported using the open-iSCSI
software iSCSI initiator or by using a supported iSCSI Host Bus Adapter (HBA). The steps for using iSCSI
HBAs are identical to those for Fibre Channel HBAs, both of which are described in Section 3.2.5, “Shared
LVM storage over FC or iSCSI hardware HBAs ”.