Hallo,
Also erstmal vielen Dank an Euch alle. Die Installation des ESX 2.5 Servers stellte kein Problem dar.
Das Einzige Problem das ich habe, hat mit dem Failover auf der MSA1000 zu tun.
Meine MSA 1000 hat 2 Controller und 2 SAN Switches.
Wenn beide HBA's eines Servers auf einen SAN Switch angeschlossen werden, funktioniert der Failover. Ist ein HBA auf Switch 1 der zweite HBA auf Switch 2 funktioniert der Failover nicht?
Das HP Carecenter kann mir hier nicht weiterhelfen, da HP den ESX Server nicht unterstützt.
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
ESX 2.5 & MSA 1000
All servers must use the same preferred and active paths.
All servers must use the same alternate path to logical units (LUNs).
The storage processor owning the LUNs must be on the preferred and active path connection.
Viewing Storage Processor Port Configuration
To view storage processors and related ports on the preferred path, log on to your ESX Server machine as root and enter the following command:
wwpn.pl -v
The output lists the World Wide Port Names (WWPNs) of HBAs on your ESX Server and storage processors on the FAStT. Compare these to those listed in the FAStT profile. The target numbers and WWPNs must be identical as seen by each ESX Server connected to the same FAStT.
Resetting Persistent Bindings
In certain configurations, persistent bindings may have been saved while the servers were connected to SANs with different configurations, which may cause incorrect persistent bindings to be saved. If this occurs, you can reset and update the persistent bindings to use the correct paths to the SAN LUNs. To reset the persistent bindings settings through the VMware Service Console:
Log on to the service console as root.
Delete /etc/vmware/pbindings:
rm /etc/vmware/pbindings
Use a text editor on the service console to edit /etc/init.d/vmware.
Find the following line:
save_san_persistent_bindings
Add a comment (#) to the beginning of the line:
# save_san_persistent_bindings
Save the file.
Reboot ESX Server.
Log on to the service console as root.
Use a text editor on the service console to edit /etc/init.d/vmware.
Find the following line:
# save_san_persistent_bindings
Remove the comment (#) from the line:
save_san_persistent_bindings
Save the file.
Enter the following command:
wwpn.pl -v
Note: Run wwpn.pl on all ESX Servers connected to the same FAStT Storage Server and compare the output. If the target numbers and storage processor ports WWPNs do not match, then you may need to investigate the SAN cabling scheme. Refer to Knowlege Base article 1301, at http://www.vmware.com/support/kb/enduse ... faqid=1301, for instructions on setting connections for SAN failover using two storage processors.
For more information, see "Using Persistent Binding" at http://www.vmware.com/support/esx2/doc/ ... disks.html
Configuring SAN Failover for FAStT Storage Servers Using Two or More Storage Processors
To configure a proper highly available SAN failover configuration with FAStT storage models equipped with two storage processors, each ESX Server must have:
Two Fibre Channel host bus adapters (HBAs), such as QLogic or Emulex.
Two fibre switches.
Two storage processors (SPs): SPA and SPB. Each storage processor must have at least two ports connected to the SAN.
Use the following connection settings:
HBA0 and HBA1 on each ESX Server connected to switches 1 and 2, respectively.
Switch 1 connected to port 1 on SPA and port 2 on SPB. Switch 2 connected to port 2 on SPA and port 1 on SPB. Make sure to connect SPA ports to the lower switch port number compared to SPB ports. This allows SPA ports to be on the first paths seen by the host bus adapters in ESX Servers.
This configuration provides two paths from each HBA. The order of the paths in the above configuration provides HBA and switch failover without the need to trigger Auto-Volume Transfer (AVT). LUNs must be owned by the storage processor to which the preferred and active paths are connected (in the above configuration, they should be owned by SPA). Only a storage processor failure triggers AVT on the FAStT Storage Server. Please note that the above assumes that the switches are not connected via Inter-Switch Link (ISL) in one fabric.
Viewing Multipath Information
To view your current multipathing configuration, log on to your ESX Server machine as root and enter:
vmkmultipath -q
The output lists all known paths to each SAN LUN. The asterisk (*) indicates that the path is the current, active path, and the pound sign (#) indicates that this is the preferred path from the server to the LUN. When connected to IBM FAStT SANs, the default policy in ESX Server 2.0.1 is fixed and the default policy in ESX Server 2.1 is MRU.
For more information on configuring multipathing, see "Using Multipathing in ESX Server" at http://www.vmware.com/support/esx2/doc/ ... disks.html.
All servers must use the same alternate path to logical units (LUNs).
The storage processor owning the LUNs must be on the preferred and active path connection.
Viewing Storage Processor Port Configuration
To view storage processors and related ports on the preferred path, log on to your ESX Server machine as root and enter the following command:
wwpn.pl -v
The output lists the World Wide Port Names (WWPNs) of HBAs on your ESX Server and storage processors on the FAStT. Compare these to those listed in the FAStT profile. The target numbers and WWPNs must be identical as seen by each ESX Server connected to the same FAStT.
Resetting Persistent Bindings
In certain configurations, persistent bindings may have been saved while the servers were connected to SANs with different configurations, which may cause incorrect persistent bindings to be saved. If this occurs, you can reset and update the persistent bindings to use the correct paths to the SAN LUNs. To reset the persistent bindings settings through the VMware Service Console:
Log on to the service console as root.
Delete /etc/vmware/pbindings:
rm /etc/vmware/pbindings
Use a text editor on the service console to edit /etc/init.d/vmware.
Find the following line:
save_san_persistent_bindings
Add a comment (#) to the beginning of the line:
# save_san_persistent_bindings
Save the file.
Reboot ESX Server.
Log on to the service console as root.
Use a text editor on the service console to edit /etc/init.d/vmware.
Find the following line:
# save_san_persistent_bindings
Remove the comment (#) from the line:
save_san_persistent_bindings
Save the file.
Enter the following command:
wwpn.pl -v
Note: Run wwpn.pl on all ESX Servers connected to the same FAStT Storage Server and compare the output. If the target numbers and storage processor ports WWPNs do not match, then you may need to investigate the SAN cabling scheme. Refer to Knowlege Base article 1301, at http://www.vmware.com/support/kb/enduse ... faqid=1301, for instructions on setting connections for SAN failover using two storage processors.
For more information, see "Using Persistent Binding" at http://www.vmware.com/support/esx2/doc/ ... disks.html
Configuring SAN Failover for FAStT Storage Servers Using Two or More Storage Processors
To configure a proper highly available SAN failover configuration with FAStT storage models equipped with two storage processors, each ESX Server must have:
Two Fibre Channel host bus adapters (HBAs), such as QLogic or Emulex.
Two fibre switches.
Two storage processors (SPs): SPA and SPB. Each storage processor must have at least two ports connected to the SAN.
Use the following connection settings:
HBA0 and HBA1 on each ESX Server connected to switches 1 and 2, respectively.
Switch 1 connected to port 1 on SPA and port 2 on SPB. Switch 2 connected to port 2 on SPA and port 1 on SPB. Make sure to connect SPA ports to the lower switch port number compared to SPB ports. This allows SPA ports to be on the first paths seen by the host bus adapters in ESX Servers.
This configuration provides two paths from each HBA. The order of the paths in the above configuration provides HBA and switch failover without the need to trigger Auto-Volume Transfer (AVT). LUNs must be owned by the storage processor to which the preferred and active paths are connected (in the above configuration, they should be owned by SPA). Only a storage processor failure triggers AVT on the FAStT Storage Server. Please note that the above assumes that the switches are not connected via Inter-Switch Link (ISL) in one fabric.
Viewing Multipath Information
To view your current multipathing configuration, log on to your ESX Server machine as root and enter:
vmkmultipath -q
The output lists all known paths to each SAN LUN. The asterisk (*) indicates that the path is the current, active path, and the pound sign (#) indicates that this is the preferred path from the server to the LUN. When connected to IBM FAStT SANs, the default policy in ESX Server 2.0.1 is fixed and the default policy in ESX Server 2.1 is MRU.
For more information on configuring multipathing, see "Using Multipathing in ESX Server" at http://www.vmware.com/support/esx2/doc/ ... disks.html.
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 21 Gäste