Pillar Axiom 300 Storage System
 
Pillar Axiom 500 Storage System
 
Pillar Axiom 600 Storage System
 

PLA-Support>Sun Systems>DISK>Axiom>SN-DK: Ax600
 

Applies to:

Goal

 This document will provide details and required steps to setup of Pillar Axiom Callhome automatic log collection process for R5 and higher.

Solution

Background

Callhome bundles, formally known as System Information Files, are built from individual pieces of information.

Callhome transfers are performed by secure copy to the hostname callhome.support.pillardata.com. If the callhome fails, the Axiom attempts to send a failure notice by email to the hostname of the callhome server.

Change history:

1- As of July 8th 2013, the callhome infrastructure has moved from California to Colorado.

The callhome server address changed on the 17th of June 2013. Customers using old server IP address; IP 209.120.231.12 instead of 192.18.110.66 must update the callhome details with new values given above.
The new DNS name will be callhome-pillar.oracle.com however it is not to be used by customers at the moment. If a customer uses HTTPS and updates to this new DNS name, the transaction would fail as the security certificates are bound to callhome.support.pillardata.com

2- As of October 31th 2015 CallHome IP change

CallHome IP has been changed from 192.18.110.66 to 129.157.65.45 at October 31, 2015. Customers using old server IP address; IP 192.18.110.66 instead of 129.157.65.45 must update the callhome details with new values given above. The new DNS name will be callhome-pillar.oracle.com however it is not to be used by customers at the moment. If a customer uses HTTPS and updates to this new DNS name, the transaction would fail as the security certificates are bound to callhome.support.pillardata.com

To address this issue, the only hostname that should be used for callhome is callhome.support.pillardata.com

callhome.support.pillardata.com now resolves to callhome-pillar.oracle.com with a new IP 129.157.65.45

Again, callhome-pillar.oracle.com is NOT to be used for callhome configuration. 

Known Issues with Site Networking Requirements

On releases below 1.1 (010100-002300) or 1.2 (010200-010900), the Axiom must be able to ping the callhome server by hostname.  If the ping fails, the transfer would not be attempted.  This issue has been verified and resolved on both 1.1 and 1.2

If the callhome transfer fails, the Axiom will attempt to send a failure email directly to the callhome server.  Many IT organizations have policies and firewalls that require all internal systems to send email to corporate mail transfer gateways.

The Axiom Pilot IP interfaces do no support manual configuration of speed or duplex.  If auto-negotiation fails,  the link may fail to operate properly, causing timeouts on large data transfers such as callhome transfers or update packages.  If the other end of the link (typically a switch port) has been manually configured or does not support auto-negotiation (for example, inexpensive hubs), the link will fail to operate properly.  Do not attempt to manually configure the external switch ports for 100M bit, Full Duplex, operation as this will cause auto-negotiation to fail.

Note: if auto-negotiation fails or manual configuration of the external switch port is required, try setting the switch port to 100 Mbit half-duplex.  Auto-negotiation will fail on the Pilot interface, but hopefully that will result in a 100 Mbit half-duplex connection, which is better than duplex mismatch.

Site Networking Requirements

All 3 IP addresses used by Axiom (Pilot0 IP address, Pilot1 IP address and Axiom Public Management (shared) IP address) must have correct privileges to perform callhome, if there is any restriction to  access outside of internal network managed by firewall or special network setup tools.

DNS Access is Required.  The Axiom pilot management interfaces must be able to resolve the hostname of the callhome server.  If the Axiom is installed in a firewall environment, Port 53, Domain Name Services, must be allowed for the Management IP addresses to a DNS server that is able to accurately resolve the callhome server hostname.  If the hostname to IP address lookup fails, the callhome will fail.

ICMP Echo Request & Reply is required below R1.1. See known issues.  The Axiom Management IP must be able to send a ping and receive a reply from the callhome server.  This ping is sent using the hostname, so accurate DNS results are required

Callhome data transfers using Port 22. The ability to use the SCP protocol will be deactivated in June 2014 Until then it is possible to ask a customer to use the SCP protocol as a test method but cannot be used as a workaround for failing HTTPS transfers

Callhome data transfers use Port 443.  The site firewalls must be configured to allow Port 443 from the Axiom management IP to reach the callhome server.  The transfers are done https over port 443 to the callhome hostname, so accurate DNS results are required.  The transfers are encrypted.

Proxy user/password usage is not supported. If the customer uses a proxy connections to access the Internet that require username/password authentication this will make callhome log transfers fail.Please enable Pillar Axiom pilot IP address to access callhome server without a user/password.

Callhome failure notices use Port 25.  See known issues.  If the callhome fails, the Axiom will attempt to send an email to the hostname of the callhome server with an XML file indicating the failure.

In R4 and below the Axiom Storage Manager GUI uses Port 80 or 443.  R5 uses a Java based GUI that connects over port 26008.  Although this is not required for callhome, the storage administrators will only be able to access the GUI if the correct ports are open.

In R4 and below the CLI Port is 26004.  R5 the CLI port is 26008.  Although this is not required for callhome, if the Axiom is installed in a firewall environment, Port 26004 is used for pdscli, supporttool, and Axiom Path Manager (SAN) access for R4 and below.  For R5 axiomcli and pdscli access is over port 26008, and APM clients over port 26004. This port must be available for CLI commands or tools such as PDSquery as well as any SAN client using APM.  The data transfers are encrypted using the Pilot keys.

Callhome Process

The callhome server fully qualified hostname is callhome.support.pillardata.com.  This hostname resolves to IP address 129.157.65.45.
The callhome server address changed on the 31th of October 2015. Customers using old server IP address; IP 192.18.110.66 instead of 129.157.65.45 must update the callhome details with new values given above.
The new DNS name will be callhome-pillar.oracle.com however it is not used at the moment. If a customer uses HTTPS and updates to the new DNS name, the transaction would fail as the security certificates are bound to callhome.support.pillardata.com
If you need to configure a firewall by IP address, be absolutely certain to check the DNS resolution for callhome.support.pillardata.com, verify that the IP is 129.157.65.45 and that the IP address is authorized on the firewall.

Check each of the DNS servers configured on the Axiom:

nslookup callhome.support.pillardata.com 192.135.82.44        <-- IP@ of your DNS server
Server:  xxxxxxxxx
Address:  192.135.82.44

Non-authoritative answer:
Name:    callhome-pillar.oracle.com
Address:  129.157.65.45                               <-- correct IP address of the callhome server
Aliases:  callhome.support.pillardata.com

In R4 and below go to System tab -> Networking -> Modify Network Settings under the <Action> menu -> Call-Home tab -> verify entries in the Call-home Primary DNS and Call-Home Secondary DNS fields.
If DNS would not work, the <Bug 16989302> is opened for this issue in order to get a workaround to replace the address in R4

In R5 go to Configure -> Global Settings -> Networking -> right click and select Modify Network Settings -> under the Interface tab verify Primary and Secondary DNS server entries.

The callhome files are retrieved from the callhome server by a script that opens the file and extracts the system serial number from the XML information in the callhome bundle. The results are stored as directories under the System Serial Number in the callhome directories.  The contents are stored in those Serial Number directories in separate sub-directories containing the XML files, the Statistics files, and the TDS (slammer and pilot log) files.  The XML file contains the names of the other files of any given callhome bundle.

There is typically several minutes delay from the time a file arrives until it appears in the Serial Number folder for that system.

Setup:

A- Configure DNS Settings
You can set the primary and secondary Domain Name Server (DNS) to resolve email server and CallHome server to the correct IP addresses. The DNS settings allow the Pillar Axiom system to send Call‑Home configuration information and event notifications to designated email recipients.

1- From the Configure tab, click Global Settings > Networking.
2- Choose Actions > Modify Network Settings.

3- From the Interfaces tab, enter the Primary DNS Server IP address.
4- Enter the Secondary DNS Server IP address.

5- To save your changes, click OK.

B- Configure Call-Home Settings

Configuring the Call-Home settings allows the Pillar Axiom system to send the event logs and messages to Oracle Pillar Callhome servers.

1. From the Configure tab, click Global Settings --> Networking.
   
   
2. Choose Actions --> Modify Network Settings.
   
   
3. From the Notification tab Call-Home Configuration area.
   Choose Pillar Server and the HTTPS protocol.
   Make sure the name of the server is callhome.support.pillardata.com
   Set up the proxy server if you are using one. 
   Select Enable large file transfers to allow the system to send additional log files (payload) to the Call-Home server.
   
   
4. From Callhome triggering area.
   Select Event triggered callhome. This will allow SRs to be automatically created.
   Select Standard periodic callhomes with a recurence of 1 and weekly interval. This will be used as the heartbeat between your Axiom and Oracle's ASR (Automatic Service Request).
   You may want to proactively send a larger call home weekly. This may help to provide historical traces for customer support when you are opening a SR (Service Request) .
   
   
5. You should leave the amount of recent events to be sent to 100.
   
   

7- To save your changes, click OK.

C- Test Call-Home
You can confirm that the network settings are configured correctly for the Call‑Home feature. This confirmation ensures that event logs can be sent to Pillar/Oracle.
The system sends a Call‑Home message to verify that Call‑Home feature is correctly configured.
Note: Only Primary Administrator or Administrator 1 accounts are allowed to test Call‑Home.
1- From the Configure tab, click Global Settings > Networking.
2- From the Network Settings overview page, choose Actions > Test Call‑Home.

3- Confirm that you want to send test Call‑Home information to the specified Call‑Home server and click OK.
Note: Wait at least 10 minutes before testing Call‑Home again.

D- Display the Event Log and Details

Review the event log to monitor events that have occurred in the Pillar Axiom system. If too many events display on the screen, you can apply filters to the list.

1. From the Monitor tab, click Event Log.
2. Review the event log details to ensure that the information is what you expect.
   
   
   
   You can review the event properties from the Pillar Axiom system and copy them to the clipboard. This allows you to capture the event details and send them to Technical Support for example.
   
   
3. Select  Callhome event from the list.
4. Choose Actions > Event Properties.
   
   
   
   
5. To copy the event properties to the clipboard, click Copy to Clipboard.
   
   
   
   
6. When you are finished reviewing the event properties, click Close.

E- View Log Bundle

To Review log bundle go to Support tab. From the Support tab, click Tools > System Logs.

F- Steps via AxiomCLI for R5

You can use the call_home command to enable and configure the Call‑Home settings for the types of Call‑Home bundles such as a large file, as well as primary and secondary periodic log collections.

1. Login to AxiomCLI with an administartor account
   
   axiomcli login -u admin001 -p password axiomhost.domain
   
   
2. Get help about command
   
   axiomcli call_home -help
   
   
3. List current callhome matrix and settings
   
   axiomcli call_home -list -matrix -settings
   
   
4. If you think it is required reset settings to default values
   
   axiomcli call_home -reset
   
   
5. Enable callhome with selected details
   
   axiomcli call_home -modify -enableEventTrigger -enableLargeFile -enableStandardPeriodic  -enableLargerPeriodic -pillarDestination -server server-ip-or-dns -https
   
   
6. Check status after settign the values
   
   axiomcli call_home -list -matrix -settings
   
   
7. Run a test callhome
   
   axiomcli call_home -test
   
   

G- Steps via AxiomCLI for R4

1. Login to AxiomCLI with an administartor account
   
   axiomcli axiom_login -u <administrator_user> -p <password> <pilot_IP>
   
   
2. List current callhome settings
   
   axiomcli pilot_config -list -details
   
   
3. If you think it is required to disable callhome
   
   axiomcli pilot_config -modify -nocallhome
   
   
4. 4- Enable callhome with default values
   
   axiomcli pilot_config -modify -callhome -pillarcallhome
   
   
5. Enable callhome with selected details. You should give details for local server, directory and username if you will not use default values
   
   axiomcli pilot_config -modify -callhome -callhomeserver callhome.support.pillardata.com -directory /home/callhome/spool/ -user callhome
   
   
6. Check settings again
   
   axiomcli pilot_config -list -details

For more details you can check documentation. To see documentation go to Support tab. From the Support tab, click Documentation.

References

This solution has no attachment