![]() | Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition | ||
|
|
![]() |
||||||||||||||||||||||||||||||||
Solution Type Technical Instruction Sure Solution 2249411.1 : How to reinstall Auto Service Request (ASR) on Private Cloud Appliance (PCA) after an image update
In this Document
Applies to:Private Cloud Appliance X6-2 Server Upgrade - Version All Versions to All Versions [Release All Releases]Oracle Virtual Compute Appliance X4-2 Hardware - Version All Versions to All Versions [Release All Releases] Private Cloud Appliance - Version 2.0.4 and later Oracle Virtual Compute Appliance X3-2 Hardware - Version All Versions to All Versions [Release All Releases] Private Cloud Appliance X5-2 Hardware - Version All Versions to All Versions [Release All Releases] Information in this document applies to any platform. GoalHow to reinstall Auto Service Request (ASR) on Private Cloud Appliance (PCA) after an image update. Notes:
If you are installing ASR for the first time, you can use this doc, however a new doc is recommended: How to install Auto Service Request (ASR) on Private Cloud Appliance (PCA) (Doc ID 2032791.1) Starting at release version 2.0.5, the product name changed from Oracle Virtual Compute Appliance (OVCA) to Private Cloud Appliance (PCA). IMPORTANT NOTE: Starting with release version 2.1.1, the ILOM rule 1 at /SP/alertmgmt/rules/1 and the snmptrap port 162 are both now reserved for the PCA software. Prior versions of this document used rule 1 and port 162. ASR will not work properly if either one is used so now both a different rule and different port must be used: rule 2 and port 1162. The examples shown in this document below now use rule 2 and port 1162. -> set /SP/alertmgmt/rules/1/ type=snmptrap destination=192.168.4.216 destination_port=162 level=major snmp_version=2c community_or_username=public -> Bug 25203987 - asrm & snmptrapd duplicate port 162 SolutionInstalling the Software Note: The ASR software is not preserved during image update.
1) Get the current versions of the software Save the following packages into /nfs/shared_storage/ASRM/pkg directory: ASR Manager 5.6.1 (p25203784_561_Linux-x86-64.zip) (Source Link) Note:
If upgrading asrmanager go to 2a. If this is a new install of asrmanager go to 2b. 2a) Upgrade asrmanager Note:
Before upgrading to the latest ASR manager version you must uninstall the previous version first. Previous version was 5.2.1, current version is 5.6.1.
[root@ovcamn05r1 ~]# rpm -qa asrmanager [root@ovcamn05r1 ~]# rpm -e asrmanager-5.2.1-1.noarch Will you be upgrading to a newer version of ASR Manager [y,n,q] y ASR Manager (pid 3535062) is RUNNING. Check that both asrm and asra services are not running. Stop them if they are. [root@ovcamn05r1 ~]# service asrm status
asrm: unrecognized service [root@ovcamn05r1 ~]# service asra status asra: unrecognized service Check and kill any process IDs for either one if they exist. [root@ovcamn05r1 ~]# ps -ef | grep asrm
[root@ovcamn05r1 ~]# ps -ef | grep asra 2b) Install asrmanager [root@ovcamn05r1 pkg]# ovca-check-master
Copyright [2008,2016], Oracle and/or its affiliates. All rights reserved. License and Terms of Use for this software are described at https://support.oracle.com/ (see Legal Notices and Terms of Use). **************************************************************** Please review the security readme for more details. The ASR Manager application is installed in '/opt/asrmanager'. Log files are located in '/var/opt/asrmanager'. ASR Manager is stopped. Please refer to ASR documentation for troubleshooting steps. [root@ovcamn05r1 pkg]# rpm -q asrmanager Create the symlink: [root@ovcamn05r1 ~]# ln -s /opt/asrmanager/bin/asr /usr/bin/asr
3) Disable autoupdate We do not want ASR to autoupdate the asrmanager on the PCA. [root@ovcamn05r1 ~]# /opt/asrmanager/bin/asr disable_autoupdate
Successfully disabled Auto Update functionality. 4) Stop the ASRM service. This service starts automatically at the end of the installation. [root@ovcamn05r1 ~]# service asrm status [root@ovcamn05r1 ~]# service asrm stop [root@ovcamn05r1 ~]# service asra stop [root@ovcamn05r1 ~]# service asrm status [root@ovcamn05r1 ~]# service asra status 5) Turn off the autostart of the ASRM and ASRS service [root@ovcamn05r1 ~]# chkconfig asrm off
[root@ovcamn05r1 ~]# chkconfig asra off 6) Set up the init service to log Starts and Stops of the ASRM Edit the /etc/init.d/asrm file to look like the following. #!/bin/sh
# # Copyright © 2008,2014 Oracle and/or its affiliates. All rights reserved. # Use is subject to license terms. # # chkconfig: 2345 95 20 # description: Auto Service Request Manager # asrm: asrm ### BEGIN INIT INFO # Provides: asrm # Required-Start: $remote_fs # Required-Stop: $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Description: Auto Service Request Manager ### END INIT INFO . /opt/asrmanager/bin/include/asr.linux # check if asrm exists or not case "$1" in echo "" exit 0 7) Preserve the information in the original directories. [root@ovcamn05r1 ~]# mv /var/opt/asrmanager/ /var/opt/orig_asrmanager 8) Repeat steps 2 thru 7 for the other passive Master [root@ovcamn06r1 pkg]# ovca-check-master
NODE: 192.168.4.4 MASTER: False This does not require the other passive Master to become active. Configuring the ASRM for Failover On the Active Master with all ASRM services still stopped. 1) Create the following directories if they have not already been made. Do this on the active Master. [root@ovcamn05r1 ~]# ovca-check-master
NODE: 192.168.4.3 MASTER: True [root@ovcamn05r1 ~]# mkdir /nfs/shared_storage/ASRM [root@ovcamn05r1 ~]# mkdir /nfs/shared_storage/ASRM/VarOptAsrmanager [root@ovcamn05r1 ~]# touch /nfs/shared_storage/ASRM/ASRHA.log [root@ovcamn05r1 ~]# chown -R asrmgr /nfs/shared_storage/ASRM; chgrp -R asrmgr /nfs/shared_storage/ASRM 2) Copy the original files to their shared location Note: Only do this step if this is a new ASR installation.
[root@ovcamn05r1 ~]# cp -rp /var/opt/orig_asrmanager/* /nfs/shared_storage/ASRM/VarOptAsrmanager On both management nodes 3) Create the softlinks to the necessary directories. [root@ovcamn05r1 ~]# ln -s /nfs/shared_storage/ASRM/VarOptAsrmanager /var/opt/asrmanager
[root@ovcamn05r1 ~]# ls -l /var/opt/asrmanager lrwxrwxrwx 1 asrmgr asrmgr 41 Feb 28 15:26 /var/opt/asrmanager -> /nfs/shared_storage/ASRM/VarOptAsrmanager 4) Edit the file: /var/lib/ovca/ovca-system.conf Locate the "foundational_services" section under the [mgmt_init] section, and add in the asrm service: Note: Depending on the image version, the ovca-system.conf file may already contain the snmptrapd entry.
foundational_services: xms ovmm_mysql ovmm tinyproxy dhcpd asrm <-- (add "asrm" if missing) snmptrapd Starting up ASR On the Active Master. 1) Start the asrmanager service and configure for port 1162 On the passive management node, monitor the ASRM startup by first tailing the file /nfs/shared_storage/ASRM/ASRHA.log. [root@ovcamn06r1 ~]# pca-check-master
NODE: 192.168.4.4 MASTER: False [root@ovcamn06r1 ~]# tail -f /nfs/shared_storage/ASRM/ASRHA.log Run the following on the active node. [root@ovcamn05r1 ~]# service asrm start
[root@ovcamn05r1 ~]# /opt/asrmanager/bin/asr set_property snmp.receiver.port 1162 snmp.receiver.port is set to 1162 [root@ovcamn05r1 ~]# service asrm restart 2) Register the asr manager See ASR Installation instructions found in the documentation link on http://www.oracle.com/asr The registration process will ask you for your MOS login. It should be one of the names on the contract for the systems being activated. A standalone ASRM would be necessary if there is no other ASRM at the Customers site. This instance would communicate directly to the Oracle backend systems and is a more standard installation. This method can be used even if the Customer has an ASRM already in use provided they are OK with a second (or third) connection back to Oracle. The basic ASRM registration command is [root@ovcamn05r1 ~]# /opt/asrmanager/bin/asr register
An ASRM could be used as a relay if the Customer already has an existing ASRM which is already in use by other systems in their facility. Since the other systems CAN NOT be routed through the PCA’s internal ASRM, you must route the PCA ASRM thru the existing one. The instructions for setting the ASRM in relay mode are in the ASR installation manual, but in short you will be registering this PCA ASRM to the web address generated by the relay ASRM which must already be configured for relaying the data. (You must follow the instructions in the ASR document in the link above as it may be different with each version of ASR) To get the destination address, enter “show_http_receiver” at the asr prompt on the destination ASRM. It will will return information similar to: [root@ovcamn05r1 ~]# /opt/asrmanager/bin/asr show_http_receiver HTTP Receiver configuration: The basic ASRM relay command is [root@ovcamn05r1 ~]# /opt/asrmanager/bin/asr register -e http://Relay_Node.Company.com:7777/asr
3) Test the connection and confirm ASR is configured for port 1162 [root@ovcamn05r1 ~]# /opt/asrmanager/bin/asr test_connection
Connecting to ASR Manager Relay URL http:// Relay_Node.Company.com:7777/asr Connectivity test to ASR Manager Relay completed successfully. The ASR Manager SNMP listener port is set to 1162 and is able to receive SNMP traps from assets. [root@ovcamn05r1 ~]# curl http:// Relay_Node.Company.com:7777/asr<html> <head> <title>ASR Http Receiver Service</title> <meta http-equiv='Content-Type' content='text/html; charset=UTF-8'><meta http-equiv='refresh' content='5;url=http://Relay_Node.Company/asr'></head> <body> <h1>ASR Http Receiver Service: Up and running ..</h1> </body> </html> 4) Test failover [root@ovcamn05r1 ]# reboot
Monitor by tailing the /nfs/shared_storage/ASRM/ASRHA.log from the other management node. [root@ovcamn06r1 ]# tail -f /nfs/shared_storage/ASRM/ASRHA.log
STOP: ovcamn05r1 02/20/17 14:35:20 START: ovcamn05r1 02/20/17 14:35:20 STOP: ovcamn05r1 02/20/17 14:37:37 START: ovcamn06r1 02/20/17 14:39:15 Setting up Tiny Proxy 1) Determine if you need to upgrade tinyproxy For ASR to work, your PCA must be running tinyproxy 1.8.3 or higher on both of the management nodes. The PCA image version 2.0.1 contains tinyproxy 1.8.2 by default. It will need to be upgraded before ASR will work for the ZFS appliance. Start by verifying which version is on your management nodes. Higher Image version will already have the correct Tiny Proxy rpm installed [root@ovcamn05r1 ~]# ovca-check-master
NODE: 192.168.4.4 MASTER: True [root@ovcamn05r1 ~]# rpm -q tinyproxy tinyproxy-1.8.2-1.el6.x86_64 If the version output of tinyproxy is 1.8.2 then go to step 2 2) Stop the tinyproxy service [root@ovcamn05r1 ~]# service tinyproxy stop
Stopping tinyproxy: [ OK ] 3) Install the new tinyproxy [root@ovcamn05r1 ~]# cd /nfs/shared_storage/ASRM/pkg [root@ovcamn05r1 pkg]# rpm -Uvh tinyproxy-1.8.3-1.el6.x86_64.rpm [root@ovcamn05r1 pkg]# rpm -qi tinyproxy 4) Verify the Configuration file Uncomment the following line under the listen section of the file /etc/tinyproxy/tinyproxy.conf. #
# Listen: If you have multiple interfaces this allows you to bind to # only one. If this is commented out, tinyproxy will bind to all # interfaces present. # Allow 192.168.4.0/24 5) Restart tinyproxy. [root@ovcamn05r1 pkg]# service tinyproxy restart
Starting tinyproxy: [ OK ] 6) Repeat steps 1 thru 5 for the passive Master. Activating the ASR assets Note: ASR asset support
NOTE: Only do this step if this is an upgrade
[root@ovcamn05r1 ~]# asr send_activations -a 2) Enabling the Compute Nodes to send traps ASR activation of the servers used in the PCA are all done in the same manner. The ILOM’s are configured to send the traps when a failure occurs and then you tell the ASRM to accept their input with the ‘activate_asset’ command. Setting up the ILOM to send the traps. On the ILOM’s of the Compute Nodes and the IB switches, set up an alert using the virtual IP address of the management node cluster for the destination. ssh root@ILOM_IP_Address (enter the root password) -> cd /SP/alertmgmt/rules/2 /SP/alertmgmt/rules/2 -> show /SP/alertmgmt/rules/2 Targets: Properties: type = snmptrap -> show /SP/alertmgmt/rules/2 Targets: Properties: type = snmptrap Commands: Send a test trap to verify end-to-end communications. -> set testrule=true Note:Based on the Status, the email account registered to the ASR Manager, Technical contact and the Distribution list setup in MOS should receive an email, which is from the ILOM component.
If the email has not been received, please work with the X86-ASR engineer for further troubleshooting of the issue.
-> exit 3) Enabling the IB switches to send traps In the ILOM’s of switches, set up rule 2 for ASR ssh ilom-admin@ILOM_IP_Address Note: If you logged as root, then type spsh to start the SP shell -> cd /SP/alertmgmt/rules/2 /SP/alertmgmt/rules/2 -> show /SP/alertmgmt/rules/2 Targets: Properties: Commands: -> set level=minor destination=192.168.4.216 destination_port=1162 snmp_version=2c Set 'level' to 'minor' -> show /SP/alertmgmt/rules/2 Targets: Properties: Commands: Send a test trap to verify end-to-end communications. -> set testrule=true Note:Based on the Status, the email account registered to the ASR Manager, Technical contact and the Distribution list setup in MOS should receive an email, which is from the ILOM component.
If the email has not been received, please work with the X86-ASR engineer for further troubleshooting of the issue.
Verify that SNMP Version 2c is enabled on the switch. (This is not required for the management nor compute nodes.) -> cd /SP/services/snmp -> show 4) Enabling the ES1-24 switches to send traps In the ILOM’s of switches, set up rule 2 for ASR ovcasw21ar1 is at 192.168.4.200 ssh root@ILOM_IP_Address -> cd /SP/alertmgmt/rules/2 /SP/alertmgmt/rules/2 -> show/SP/alertmgmt/rules/2 Properties: Commands: -> set level=minor destination=192.168.4.216 destination_port=1162 snmp_version=2c Set 'level' to 'minor' /SP/alertmgmt/rules/2 Properties: Commands: -> Send a test trap to verify end-to-end communications. -> set testrule=true Note:Based on the Status, the email account registered to the ASR Manager, Technical contact and the Distribution list setup in MOS should receive an email, which is from the ILOM component.
If the email has not been received, please work with the X86-ASR engineer for further troubleshooting of the issue.
Verify that SNMP Version 2c is enabled on the switch. (This is not required for the management nor compute nodes.) -> cd /SP/services/snmp -> show -> set v2c=enabled 5) Activating all switches and all server ILOM’s to the ASRM Check the list of activated assets, the snmp test from the ILOM may have already activated them. [root@ovcamn05r1 ~]# ovca-check-master
NODE: 192.168.4.4 MASTER: True [root@ovcamn05r1 ~]# /opt/asrmanager/bin/asr list_asset All of the servers and switches above use the same command to activate them for ASR. [root@ovcamn05r1 ~]# /opt/asrmanager/bin/asr activate_asset –i <IP_of_components_ILOM>
NOTE: If the activation did not work verify you used the IP of the ILOM and not the server.
The following simple script will activate all of the compute node ILOMs in the rack but not the switches nor the management nodes. for NODE in 'ovca-node-db list type=ilom | sort -k 2 | cut -f2 -d" " | cut -f2 -d"=" | grep -v please | sed /^$/d';
do /opt/asrmanager/bin/asr activate_asset -i $NODE; done Sample output: [root@ovcamn05r1 ~]# asr list_asset 6) Activating the ZFS Storage Appliance See the instructions for enabling ASR for the ZFS Storage Appliance found at this (link) Activation may be done via the ZFS Appliance CLI or from the GUI interface. Using the GUI To access the BUI you will need to begin by establishing an IP tunnel thru the management nodes. The following is an image capture for setting up a tunnel using putty First, establish a connection with the management server, use the VIP address to do this. Once you are logged in to the Management node, right-click in the putty title bar and select ‘change settings’. In the left hand pane, under connection -> SSH, select ‘Tunnels’. Ensure the radio buttons for Local and Auto are selected. The destination address should be set to ‘192.168.4.1:215’ (215 is the port you connect to) The source port should be a port that is open on your local system, then click ‘add’ You may need to use ‘192.168.4.2:215’ if it is your active Storage Head. Or you can establish both tunnels as show below. You need to hit the “Apply” button to activate the tunnel. To access the BUI you now simple open a new tab in your favorite browser and plug in the URL https://localhost:9091 (using the above port number)
The ZFS appliance login screen will appear after you confirm the security questions. You will be setting up the ZFS appliance to use a proxy for sending the events to the Oracle backend systems. inet addr: 192.168.4.216 In the end it should look like this Using the CLI interface You will need to log into the active storage head from the management node. Storage Node 01 is at 192.168.4.1 [root@ovcamn05r1 bin]# ssh -l root 192.168.4.1 ovcasn01r1:> ls Properties: Children: Walk your way down the configuration tree to the SCRK service. ovcasn01r1:> configuration Properties: Each of these fields can be set individually and should the same as below using your own login and password. Use the 'set' command to make the following eight changes. ovcasn01r1:configuration services scrk> set soa_id=<Registered MOS user>
ovcasn01r1:configuration services scrk> set soa_password=<password for above user> ovcasn01r1:configuration services scrk> set proxy_on=true ovcasn01r1:configuration services scrk> set proxy_host=192.168.4.216:8888 ovcasn01r1:configuration services scrk> set proxy_user=root ovcasn01r1:configuration services scrk> set proxy_password=Welcome1 ovcasn01r1:configuration services scrk> set updatecheck_on=false ovcasn01r1:configuration services scrk> set time_updatecheck=7d ovcasn01r1:configuration services scrk> commit ovcasn01r1:configuration services scrk> show Properties: <status> = online soa_id = first.last@oracle.com soa_password = ******** proxy_on = true proxy_host = 192.168.4.216:8888 proxy_user = root proxy_password = ******** updatecheck_on = false time_updatecheck = 7d ovcasn01r1:configuration services scrk> test A test event was sent to Oracle using the configured registration information. Oracle will respond by sending a confirmation email to the provided registration email address. If this confirmation email is not received within approximately 30 minutes please contact Oracle Service personnel. If the email has not been received, please work with the X86-ASR engineer for further troubleshooting of the issue. ovcasn01r1:configuration services scrk> exit
Note: You may need to reinstall and/or reconfigure ASR at each image update.
Attachments This solution has no attachment |
||||||||||||||||||||||||||||||||
|