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-70201 Number of Networks Managed by a DHCP Agent Exceeded the Threshold

ALM-70201 Number of Networks Managed by a DHCP Agent Exceeded the Threshold

Description

This alarm is generated when the number of networks managed by a DHCP agent exceeds the threshold (200 x 0.85).

Attribute

Alarm ID

Alarm Severity

Auto Clear

70201

Major

Yes

Parameters

Name

Meaning

Fault Location Info

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

Additional Info

error_info: Networks Exceeds Limitation on a DHCP agent

Impact on the System

  • The memory usage of the host corresponding to the DHCP-agent may be too high, affecting other services on the host.
  • If the number of networks managed by all DHCP agents in the system is greater than the threshold (200), some networks in the system are not bound to DHCP agents. VMs created using these networks cannot obtain IP addresses using the DHCP function provided by Neutron.

Possible Causes

  • Too many networks are created in the AZ.
  • DHCP re-scheduling is manually or automatically triggered, causing a specific DHCP agent to manage too many networks.
  • Redundant Neutron namespaces exist on a node.

Procedure

  1. Log in to the FusionSphere OpenStack web client.

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

  2. On the Summary page, obtain the management IP address of the host in the OM IP Address column based on the host ID or host name in the alarm additional information.
  3. Use PuTTY to log in to the host for which the alarm is generated using the management IP address of the host.

    The default user name is fsp. The default password is Huawei@CLOUD8.

    The system supports both password and public-private key pair for identity authentication. If the public-private key pair is used for login authentication, see detailed operations in Using PuTTY to Log In to a Node in Key Pair Authentication Mode.

  4. Run the following command and enter the password of user root to switch to user root:

    su - root

    The default password of user root is Huawei@CLOUD8!.

  5. Run the following command to disable user logout upon system timeout:

    TMOUT=0

  6. Run the following command to import environment variables:

    source set_env

    Information similar to the following is displayed:

      please choose environment variable which you want to import: 
      (1) openstack environment variable (keystone v3) 
      (2) cps environment variable 
      (3) openstack environment variable legacy (keystone v2) 
      (4) openstack environment variable of cloud_admin (keystone v3) 
      please choose:[1|2|3|4] 

  7. Enter 1 to enable Keystone V3 authentication and enter the password of OS_USERNAME as prompted.

    Default account format: DCname_admin; default password: FusionSphere123.

  8. Check the number of networks and that of DHCP agents in the system.

    1. Run the neutron agent-list | grep neutron-dhcp-agent | grep $host_id command to query the deployed DHCP agents in the agent list.
      NOTE:

      For $host_id, see the location information in the alarm parameters.

    2. Run the neutron net-list-on-dhcp-agent $dhcp_agent_id command to check all networks managed by a DHCP-agent. In the preceding command, $dhcp_agent_id indicates the ID that you query in 8.a.
    3. Collect statistics on the number of DHCP agents and that of networks bound to each DHCP agent and check whether the DHCP agents are insufficient.

      If the number is too large, you can use the wc command of Linux to collect statistics.

      • Run the neutron agent-list | grep neutron-dhcp-agent | wc –l command to collect statistics on the number of DHCP agents.
      • Run the neutron net-list-on-dhcp-agent $dhcp_agent_id | wc -l command to collect statistics on the number of networks bound to the DHCP agent. The query result minus 4 is the number of networks bound to the DHCP-agent.
    4. Run the following commands to check the networks that are not bound to the DHCP agent in the system:

      net_id=`neutron net-list | awk '{print $2}'`

      for i in $net_id;do if [ "$i" != "id" ];then c=`neutron dhcp-agent-list-hosting-net $i | awk '{print $6}' | tr "\n" " "`; if [ "$c" = " " ];then echo unbonded network_id is $i;fi;fi;done

  9. Check whether the DHCP server is a distributed DHCP server based on the deployment scenario.

    • If yes, go to 11.
    • If no, go to 10.
    The determination method is as follows:
    • Region Type I scenario:
      • In Region Type I, the cascading system uses centralized DHCP by default.
      • For the cascaded system in Region Type I, run the following command:

        cps template-params-show --service network-agent neutron-dhcp-agent

        In the command output, check whether dhcp_distributed is set to True. If yes, the distributed DHCP is used.

    • In Region Type II, run the following command:

      cps host-role-list $host_id | grep dhcp

      Check whether dhcp is displayed in the first column. If yes, the centralized DHCP is used.

    • In Region Type III, run the following command:

      cps template-params-show --service neutron neutron-dhcp-agent

      In the command output, check whether dhcp_distributed is set to True. If yes, the distributed DHCP is used.

  10. Check whether the alarm is generated because the number of deployed DHCP agents is insufficient based on the relationship between the number of networks and that of DHCP agents.

    Based on the query result in 8.c, if the average number of networks bound to the DHCP agent, namely, the total number of networks bound to DHCP agents divided by the number of DHCP agents obtained in 8.c, is greater than the value of (200 x 0.85), the DHCP agents are insufficient.

    • If yes, increase the DHCP roles in the AZ.. Then determine the number of DHCP agents to be added based on the number of networks that are not bound to the DHCP agents and manually schedule the networks that exceed the threshold and are managed by the DHCP agents to the newly added DHCP agent.
    • If no, manually schedule the networks that exceed the threshold and are managed by the DHCP agents to the light-load DHCP agents.
      For example:
      1. Run the neutron dhcp-agent-network-remove $dhcp_agent_id $network_id to remove the network from the old DHCP agent.
      2. Run the neutron dhcp-agent-network-add $dhcp_agent_id $network_id command to bind the network to the new DHCP agent.
      3. Run the neutron dhcp-agent-list-hosting-net $network_id command to check whether the rescheduling is successful.

  11. Check whether the alarm is generated because the number of deployed DHCP agents is insufficient based on the relationship between the number of networks and that of DHCP agents.

    Identification method: Based on the query result in 8.c, if the average number of networks bound to the DHCP agent, namely, the total number of networks bound to DHCP agents divided by the number of DHCP agents obtained in 8.c, is greater than the value of (200 x 0.85), the DHCP agents are insufficient.

    • If yes, add the host and migrate the VMs on which the alarm is generated to the new host on the Service OM web client.
    • If no, manually migrate the VMs on the host where the alarm is generated to the specified host whose number of DHCP agents does not exceed the threshold on the Service OM web client.
    NOTE:

    VM live migration may interrupt services for a short period of time.

  12. Re-scheduling DHCP agents may cause namespace residuals. Determine the scenario where the current environment is deployed and obtain section "Manual Audit."Start the system audit for redundant Neutron namespace (DHCP and router namespaces) again.

    • Region Type I scenario:
    • Region Type II and Region Type III scenarios:

  13. Check the audit report after the audit is complete. If any redundant namespace still exists, handle the issue based on section "Handling Redundant Neutron Namespaces."

Translation
Download
Updated: 2019-08-30

Document ID: EDOC1100062365

Views: 45732

Downloads: 33

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