No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

HUAWEI CLOUD Stack 6.5.0 Alarm and Event Reference 04

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
ALM-6028 Time Difference Between the NTP-Client and the NTP-Server Exceeds 60 Seconds

ALM-6028 Time Difference Between the NTP-Client and the NTP-Server Exceeds 60 Seconds

Description

The NTP client periodically (default interval: 2 minutes) checks the time difference between the node where the NTP client is deployed and the node where the active ntp-server service is deployed. This alarm is generated when the time difference exceeds 60s. After the time difference is rectified, the alarm is cleared.

Attribute

Alarm ID

Alarm Severity

Auto Clear

6028

Major

Yes

Parameters

Name

Meaning

Fault Location Info

host_id: specifies the ID of the host for which the alarm is generated.

Additional Info

  • host_id: specifies the ID of the host for which the alarm is generated.
  • hostname: specifies the name of the host for which the alarm is generated.
  • Local_Address: specifies the management IP address of the host.
  • Peer_address: specifies the floating IP address of the NTP server.

Impact on the System

  • If the time difference exceeds 60s, the ntp-client node will not synchronize time with the local active ntp-server node.
  • A valid token cannot be used within its validity period, or an expired token can be still used.
  • Services on the node may be unavailable due to time asynchronization.
  • System data sampling may be incorrect.
  • Data may be lost.

Possible Causes

  • The system time of the node where the local active ntp-server service is deployed is changed.
  • The system time of the node where the ntp-client service is deployed is changed.
  • The standby ntp-server node fails to synchronize time with the active ntp-server node due to a long-period disconnection, but the node where the ntp-client service is deployed synchronizes time with the local active ntp-server node. In this case, an active/standby switchover occurs.
  • The communication between the node where the ntp-client service is deployed and the active ntp-server node resumes after a long-period disconnection.

Procedure

  1. Log in to the FusionSphere OpenStack web client.

    For details, see Logging In to the FusionSphere OpenStack Web Client (ManageOne Mode).

  2. Choose O&M > Routine Maintenance.

    NOTE:

    Forcible time synchronization is risky. This operation can be performed only when services are not deployed yet or when services are running stably. Otherwise, this operation will adversely affect services. Ensure that all system services are stopped before you forcibly synchronize time. Restart the stopped services after time synchronization. This operation cannot be performed remotely.

  3. After 2 minutes, check the system time status in the Time Synchronization area, in which Querying the system status changes into system time error, as shown in the following figure.

  4. Click on the right as instructed. A window is displayed. After 2 minutes, hosts that encounter clock exceptions will be displayed in the window.

  5. Select the hosts to synchronize time and click Synchronize.

    During forcible time synchronization, the management plane will be interrupted for 10 to 15 minutes, service provisioning will fail, and provisioned services will not be affected. Determine whether to perform this operation based on the site requirements.

    NOTE:

    Forcible time synchronization is risky. This operation can be performed only when services are not deployed yet or when services are running stably. Otherwise, services may be interrupted. During forcible time synchronization, all services, except ntp-server, ntp-client, dns-server, cps-monitor, and haproxy, on hosts are restarted. Therefore, this operation cannot be performed remotely.

    Forcible time synchronization is just a mitigation method and cannot resolve this problem thoroughly. If this alarm is generated when the system time of the node where the active ntp-server service is deployed is not manually changed, you must find the reason why the system time of the external clock source changes. For example, if multiple external clock sources are deployed and the time difference between two of them is greater than 60s, the alarm cannot be cleared by forcible time synchronization. In this case, you need to remove the inaccurate clock sources.

  6. After 5 to 10 minutes, query the system time status in the Time Synchronization area again. If the status changes to The system time is normal, the system time is successfully synchronized.

    If the status changes to System synchronization error, forcible time synchronization fails on the hosts.

    Click on the right as prompted. A window is displayed. After 2 minutes, hosts that fail to synchronize time will be displayed in the window, as shown in the following figure.

    Check whether forcible time synchronization fails on any host.

  7. After 5 to 10 minutes, check whether the alarm is cleared.

    • If yes, no further action is required.
    • If no, go to 8.

  8. Contact technical support for assistance.

Related Information

None

Translation
Download
Updated: 2019-08-30

Document ID: EDOC1100062365

Views: 46453

Downloads: 33

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next