HP DL160 HP ProLiant Storage Server User Guide (440584-004, February 2008) - Page 131

Protocol planning, Cluster Aware

Page 131 highlights

Virtual names and addresses are the only identification used by clients on the network. Because the names and addresses are virtual, their ownership can transition from one node to the other during a failover, preserving access to the resources in the cluster group. A cluster uses at least two network connections on each node: • The private cluster interconnect or "heartbeat" crossover cable connects to one of the network ports on each cluster node. In more than two node deployments, a private VLAN on a switch or hub is required for the cluster interconnect. • The public client network subnet connects to the remaining network ports on each cluster node. The cluster node names and virtual server names have IP addresses residing on these subnets. NOTE: If the share is to remain available during a failover, each cluster node must be connected to the same network subnet. It is impossible for a cluster node to serve the data to a network to which it is not connected. Protocol planning Not all file sharing protocols can take advantage of clustering. If a protocol does not support clustering, it will not have a cluster resource and will not failover with any cluster group. In the case of a failover, a client cannot use the virtual name or virtual IP address to access the share since the protocol cannot failover with the cluster group. The client must wait until the initial node is brought back online to access the share. HP recommends placing cluster aware and non cluster aware protocols on different file shares. Table 23 Sharing protocol cluster support Protocol Client Variant Cluster Aware (supports failover) Supported on cluster nodes CIFS/SMB Windows NT Yes Yes Windows 2000 Windows 95 Windows 98 Windows ME NFS UNIX Yes Yes Linux HTTP Web No Yes FTP Many Yes Yes NCP Novell No Yes AppleTalk Apple No No iSCSI Standards-based iSCSI initiator Yes Yes HP ProLiant Storage Server 131

  • 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
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172

Virtual names and addresses are the only identification used by clients on the network. Because the
names and addresses are virtual, their ownership can transition from one node to the other during a
failover, preserving access to the resources in the cluster group.
A cluster uses at least two network connections on each node:
The private cluster interconnect or “heartbeat” crossover cable connects to one of the network
ports on each cluster node. In more than two node deployments, a private VLAN on a switch or
hub is required for the cluster interconnect.
The public client network subnet connects to the remaining network ports on each cluster node.
The cluster node names and virtual server names have IP addresses residing on these subnets.
NOTE:
If the share is to remain available during a failover, each cluster node must be connected to the same
network subnet. It is impossible for a cluster node to serve the data to a network to which it is not connected.
Protocol planning
Not all file sharing protocols can take advantage of clustering. If a protocol does not support clustering,
it will not have a cluster resource and will not failover with any cluster group. In the case of a failover,
a client cannot use the virtual name or virtual IP address to access the share since the protocol cannot
failover with the cluster group. The client must wait until the initial node is brought back online to
access the share.
HP recommends placing cluster aware and non cluster aware protocols on different file shares.
Table 23 Sharing protocol cluster support
Supported on cluster
nodes
Cluster Aware
(supports failover)
Client Variant
Protocol
Yes
Yes
Windows NT
CIFS/SMB
Windows 2000
Windows 95
Windows 98
Windows ME
Yes
Yes
UNIX
NFS
Linux
Yes
No
Web
HTTP
Yes
Yes
Many
FTP
Yes
No
Novell
NCP
No
No
Apple
AppleTalk
Yes
Yes
Standards-based iSCSI
initiator
iSCSI
HP ProLiant Storage Server
131