This post is more than 5 years old
39 Posts
0
715786
SAN HQ enquiry
I just setup SAN HQ and need some clarification:
1. Does SAN HQ need access to my iSCSI network to work? When I use my management IP, it prompted me for Group IP which is my iSCSI network. In this case, should I route my iSCSI network into my management/server network just for SAN HQ? Or should I reconfigure my SAN HQ into my iSCSI network instead so that I can continue to keep my iSCSI network isolated from my management and server networks?
Also, shouldn't my Group IP be within my iSCSI network subnet or should it be within my management/server network so that SAN HQ can access it?
2. Is the Group SNMP community name the same as the Equal Logic group name or Member name or any name I just add into the the SNMP Access entry?
3. Should the SNMP trap destinations the IP address of the SAN HQ server?
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
1
March 5th, 2013 05:00
Re: 1 Yes, the SANHQ server needs access to both Mgmt and iSCSI subnets You're Group IP is for iSCSI only. That has to be on the same subnet as the iSCSI ports. You don't have to route the iSCSI subnet, installing a NIC on the SANHQ server that's on the iSCSI subnet prevents you from having to route it. Which would somewhat defeat the need for dedicated management port.
Re: 2 SNMP name. Not usually. There's no requirement. When in doubt you can enter public
re: Syslog. SANHQ is a syslog server, it will configure the array to point syslog messages at the SANHQ server
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
1
March 7th, 2013 18:00
On your remote site you must allow access to both Management and iSCSI ports. Just providing the Mgmt port isn't enough.
If you have a member below 5.0.8 then the group does not function at the higher level, but at the lowest common firmware compatibility level.
napalmer7
9 Posts
1
March 13th, 2013 08:00
Crescendas,
The ethernet ports that must be reachable by the SAN HQ Server will depend on how your group is configured. If you have fully configured a dedicated management network then SAN HQ will require access to the Group's Management IP address, this is separate from your Group iSCSI IP address, and each member's dedicated management ethernet port. If you are not using a dedicated management network then SAN HQ will require access to the Group's (iSCSI) IP address and at least one ethernet port on each member.
The SAN HQ Server does not need to use SNMP traps so adding the Server's IP address to the list of trap destinations would not be beneficial.
When you configure SANAssist on a group you are required to add the SAN HQ Server's IP address to the list of syslog message servers. This enables SANAssist's Event Driven data collection, in addition to the standard Weekly and On-Demand. An Event Driven data collection is triggered when the SAN HQ Server receives a critical event notification through the syslog mechanism.
The recommended practice for a remote site using a WAN connection is to have a secondary SAN HQ Server deployed locally at the remote site and configured to connect to all your PS Series groups locally. You can then use a remote, client only, SAN HQ installation to connect to multiple SAN HQ Servers over the WAN connection. This will allow the SAN HQ Server to utilize the faster local network for all standard data polling and SANAssist functionality in addition to not requiring you to expose your management or iSCSI network over the WAN.
In response to your outstanding issue #2, this is most likely caused by you adding the group using an incorrect well known address. If your group is fully configured for dedicated management only traffic, you should double check that the IP address you used to add the group matches the IP address specified in the Group Manager in the Group Configuration 'Advanced' tab. If your group is partially configured for dedicated management only traffic then you may receive these types of alerts and experience issues when configuring SANAssist.
In response to issue #3, can you verify that your SAN HQ Server's IP address is listed in the Group Manager's Group Configuration under the 'Notifications' tab? The IP Address should be displayed under the 'Event Logs' section and the checkbox 'Send events to syslog servers' should be checked. If not, please add the IP address to the list and check the checkbox then click the save 'Disk' icon at the top right of the Group Manager. If this does not resolve your issue, you may need to verify that your network is not blocking UDP traffic over port #514 and that the system running your SAN HQ Server does not have another syslog service installed.
Issue #4 is most likely related to why you are seeing the alert for issue #2. Can you verify your group configuration is either fully configured for dedicated management traffic or if you are not using a dedicated management traffic that none of your members are configured with an active management-only ethernet port? Once that has been resolved, please try to configure SANAssist on your group again and let me know the result.
crescendas
39 Posts
1
March 13th, 2013 20:00
Hi, the issues have been resolved by completely uninstalling SanHQ and remove all logs and settings, then reinstall it again. It appears that previous conflicting settings are retained when I remove and add EQL back into SanHQ!
crescendas
39 Posts
0
March 4th, 2013 23:00
btw, must I setup a syslog server for SAN Assist to function?
crescendas
39 Posts
0
March 5th, 2013 16:00
Thanks Don! Adding a second NIC into the iSCSI network is a great idea!
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
March 5th, 2013 19:00
You don't need an additional syslog server for SANassist. That works very differently from syslog. Periodically it will run utils on the arrays, gather the output and upload it to Dell. Also where there are problems with an array, it will send out an alert. This will be tied into both proactive maint and case generation going forward.
crescendas
39 Posts
0
March 5th, 2013 20:00
Noted.
btw, One of my Equal Logic is at remote site. This mean I will still need to reroute it's iSCSI network over the WAN thru VPN into my SAN HQ server! :(
crescendas
39 Posts
0
March 7th, 2013 17:00
I have 4 outstanding issues with San HQ:
1. San HQ keep prompting Critical Alert on our first EQL (local) that one of the newly replaced harddisk from Dell has outdated firmware. Dell support told us that this is alright and suggest that we leave the firmware as it is despite the alert is at critical level.
2. San HQ keep prompting Warning Alert on our second EQL (remote) that the group default added was using non WKA address (we add management IP instead of Group/iSCSI IP) and also warn that it's network port cannot be reached to obtain network performance data.
3. Events/Audit Logs is not working despite I have done all the necessary:
4. SAN Assist refused to work. I understand that it requires firmware of at least 5.0.8 to function, so one of them has an outdated firmware will not work. However, the other one fulfilled the requirement. Is it because it require group/iSCSI IP to work and Management IP is insufficient?
crescendas
39 Posts
0
March 7th, 2013 18:00
This doesn't make any sense to block SAN assist to function on one EQL just because the other one is not supported. In this case, my best opinion is to setup 2 SAN HQ, each for just one EQL locally at each site so that:
1. The lower firmware EQL will not affect the higher firmware EQL
2. The localized SAN HQ will have access to the local EQL iSCSI ports
*sigh*
crescendas
39 Posts
0
March 12th, 2013 19:00
In order to avoid WKA error and to access my remote iSCSI network, I have actually cloned the SanHQ virtual machine to the remote site to run locally in order to accses it's iSCSI network. I have also upgraded my local Equal Logic firmware to the latest 5.2.6.
However, I found that San Assist for both sites failed due to unknown credential failure. Suspecting that the duplication might contain the other Equal Logic settings, I process to remove both Equal Logic from SanHQ and add just the local Equal Logic. However, this did not resolve San Assist error. Any idea?
JohnB999
11 Posts
0
July 18th, 2013 07:00
I have a similar issue to the one described in this thread.
I have just installed a new vewsion of SAN HQ (2.6), and copied the logs over from our old SAN HQ server.
Now the new server is complaining about the WKA addresses. Is it possible to correct the WKA addresses and retain our old logs? I ask because it looks like the SAN IP addresses are embedded in the filenames of the logs. So, if I reconnect the groups to SAN HQ, will I lose I logs?
Can I maybe rename the logs files to match the WKA addresses?
napalmer7
9 Posts
1
July 23rd, 2013 07:00
JonB999,
The standard practice in this scenario is to stop monitoring on the group using an incorrect WKA and re-add the group using the new WKA. Additional details are available in the SAN Headquarters Release Notes under the heading ‘Handling Group Address Changes.’
You can attempt renaming the files associated with the group, however this is not a supported operation. If you choose to perform this operation it’s recommended that you create a SAN HQ Archive of the group (or a backup of the entire log directory) beforehand. Here’s a step by step guide to renaming the necessary files/details for a WKA address change:
1. If you have configured SupportAssist, previously called SANAssist, for the group you should delete the group’s configuration using the SupportAssist settings page.
2. Close all active SAN Headquarters Clients
3. Stop the SAN HQ Service (it is called Eqlxperf in Windows services)
4. Navigate to the SAN HQ log directory.
5. Rename both of the group’s .GRPDESC files to the appropriate name. For example:
a. GroupDescriptorC192.168.2.2.grpdesc GroupDescriptorC[New WKA Address Here].grpdesc
b. GroupDescriptorS192.168.2.2.grpdesc GroupDescriptorS[New WKA Address Here].grpdesc
6. Open each of the .GRPDESC files in notepad or your standard text editor and modify the following two entries:
a. [New WKA Address Here]
b. [New WKA Address Here]< ResolvedConnectionIpAddress>
7. Rename all of the group’s *.GRPLOG files to the appropriate name. For example:
a. GRP192.168.2.2FREQ0.grplog GRP[New WKA Address Here]Freq0.grplog
b. GRP192.168.2.2SysLog.grplog GRP[New WKA Address Here]Syslog.grplog
8. Rename all of the group’s *.XML files to the appropriate name. For example:
a. GRP192.168.2.2FREQ0.xml GRP[New WKA Address Here]Freq0.xml
9. Restart the SAN HQ Service
10. Launch the SANHQ Client
As I stated, this is not a standard operation and may result in corruption of this group’s log data. If you perform this operation without taking a backup of your data then all group specific information may be lost.
JohnB999
11 Posts
0
July 25th, 2013 02:00
Thank you very much napalmer7, that procedure worked perfectly!
crescendas
39 Posts
0
June 6th, 2014 03:00
Recently, I'm forced to deploy a new SANHQ 3 on Windows 8 because it no longer support Windows XP where SANHQ 2.5 was installed and there is no direct upgrade path from XP to 8.
But the SANHQ 2.5 client was installed on a Windows 7, so it can upgrade directly to SANHQ 3. However, because the new SANHQ 3 is now on another IP address, the client insist to connect to the old IP address. Is there a way to update the IP address from 192.168.100.46/log to 192.168.100.47/monitor as I can't it anywhere in the client menu: