Description

The alarm module checks the OpenStack service every two minutes. This alarm is generated when the alarm module detects that the OpenStack server is abnormal or unavailable for three consecutive times. This alarm is cleared when the OpenStack server recovers.

Attribute

Parameters

Impact on the System

Administrators cannot manage VMs from the OpenStack platform.

Possible Causes

• The user name, password, domain name (tenant name), or project name for interconnecting with OpenStack has been changed but has not been synchronized to FusionAccess.
• The OpenStack Identity (IAM) or Nova (ECS) service is not running properly.

• IP address conflict.
• The DNS server is not running properly.
• The network is faulty.

Procedure

1. Try to log in to the Cloud Server Console using the user name and password used by FusionAccess to interconnect with OpenStack.
   • If the login succeeded, go to Step 2.
   • If the login failed:

     In the event of incorrect accounts or passwords, go to Step 3.

     In the event of service exception or internal exception, contact IAM technician to handle the OpenStack Identity (IAM) service exceptions.

2. Check whether the domain name (tenant name) or project name for interconnecting with OpenStack has been changed.
   • If yes, log in to FusionAccess, choose System > System Configuration > Virtual Environment > OpenStack, and modify OpenStack environment configurations.
   • If no, go to Step 3.

3. Check whether the password of the account for interconnecting with OpenStack has been changed.
   • If yes, log in to FusionAccess, choose System > System Configuration > Virtual Environment > OpenStack, and modify OpenStack environment configurations.
   • If no, go to Step 4.

4. Log in to the server where the alarm is generated using an administrator account and run the arping -c 3 -f -D -I eth0 IP address of the server where the alarm is generated command to check whether IP conflict occurs.
   • If yes, go to Step 5.
   • If no, go to 7 .

     If the information similar to the following is displayed, no IP conflict occurs:

     ARPING 192.168.162.11 from 0.0.0.0 eth0 
     Sent 3 probes (3 broadcast(s)) 
     Received 0 response(s) 
     (Note: The IP addresses are only examples. Use the actual IP addresses.)     

     If the information similar to the following is displayed, IP conflict occurs:

     ARPING 192.168.162.11 from 0.0.0.0 eth0 
     Unicast reply from 192.168.162.11 [12:6E:D4:AB:CD:EF]  1.022ms 
     Sent 1 probes (1 broadcast(s)) 
     Received 1 response(s) 
     (Note: The preceding IP addresses and MAC addresses are only examples. Use the actual IP addresses and MAC addresses.)     

5. Log in to the server that causes the IP conflict, shut down the server or change the server IP address, and run the arping -c 3 -f -D -I eth0 IP address of the server where the alarm is generated command again on the server where the alarm is generated to check whether the IP conflict persists.
   • If yes, contact Huawei technical support.
   • If no, go to Step 6.

6. Choose FusionAccess > Alarm to check whether the alarm still exists.
   • If yes, go to Step 7.
   • If no, no further operation is required.

7. Log in to the ITA server as user gandalf, and check whether the OpenStack server network is normal. Run ping -c 3 floating IP address of the OpenStack server or DMZ_tenant network plane IP address of the API gateway to check whether the communication is normal.
   • If yes, go to Step 8.
   • If no, go to Step 12.

     The communication is normal if the command output is as follows:

     PING 192.168.190.2 (192.168.190.2) 56(84) bytes of data. 
     64 bytes from 192.168.190.2: icmp_seq=1 ttl=64 time=0.047 ms 
     64 bytes from 192.168.190.2: icmp_seq=2 ttl=64 time=0.057 ms 
     64 bytes from 192.168.190.2: icmp_seq=3 ttl=64 time=0.058 ms 
     (Note: The IP addresses are only examples. Use the actual IP addresses.)     

8. Choose FusionAccess > Alarm to check whether the URL in the alarm details contains the IP address.
   • If yes, go to Step 13.
   • If no, go to Step 9.

9. Check whether the domain name of the OpenStack URL can be accessed. Run ping -c 3 URL domain name of the OpenStack Identity (IAM) service to check whether the communication is normal.
   • If yes, go to Step 13.
   • If no, go to Step 10.

     The communication is normal if the command output is as follows:

     PING identity.az1.dc1.domainname.com (192.168.190.3) 56(84) bytes of data. 
     64 bytes from identity.az1.dc1.domainname.com (192.168.190.3): icmp_seq=1 ttl=64 time=0.038 ms 
     64 bytes from identity.az1.dc1.domainname.com (192.168.190.3): icmp_seq=2 ttl=64 time=0.047 ms 
     64 bytes from identity.az1.dc1.domainname.com (192.168.190.3): icmp_seq=3 ttl=64 time=0.056 ms 
     (Note: The IP addresses are only examples. Use the actual IP addresses.)     

10. Choose FusionAccess > Alarm to check whether any DNS alarm exists.
    • If yes, handle the DNS alarm according to the DNS alarm informationDNS alarm information and go to Step 11.
    • If no, go to Step 11.

11. Choose FusionAccess > System > Initial Configuration > Desktop Component to view the DNS IP address, and log in to the DNS server using the IP address to check whether the OpenStack URL is configured.
    • If yes, go to Step 13.
    • If no, configure the OpenStack URL on the DNS and go to Step 13.
    Figure 11-1 OpenStack URL configuration
    

12. Locate and rectify the network fault based on the actual situation on site.
13. If the OpenStack server is running abnormally, locate and rectify the fault based on the actual situation on site. Check whether the fault is rectified?
    • If yes, go to Step 16.
    • If no, continue to rectify the fault.

14. Contact the maintenance personnel of the ApiGateway service to check that whether the API interfaces of the IAM, ECS, VPC, EVS, and IMS services are registered to the ApiGateway of the tenant.
15. Are the APIs already registered?
    • If yes, go to Step 16.
    • If no, register the unregistered APIs to the ApiGateway.

16. Choose FusionAccess > Alarm to check whether the alarm exists.
    • If yes, wait for 6 minutes. If the alarm still exists, contact Huawei technical support.
    • If no, no further operation is required.

Related Information

None