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

AMI Smart Meter Reading Solution V200R010C10 Planning and Design Guide

This document describes the overall and detailed design of functions and services in the AMI Smart Meter Reading Solution.
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).
Remote Disaster Recovery

Remote Disaster Recovery

The AMI solution supports remote disaster recovery to ensure security of data and services. The EEM, DCP, and database support remote disaster recovery. The remote disaster recovery solution is deployed to ensure continuous and highly-efficient service running. Database and network backup ensures service running after an active/standby switchover.

In the remote disaster recovery solution, the production center and disaster recovery center need to be deployed. Normally, service exchange is performed in the production center, and application systems in the disaster recovery center used as the backup are not enabled. When a disaster occurs, the disaster recovery center can be enabled. In this case, all services are switched to the disaster recovery center. The product center and disaster recovery center belong to different data centers. Ensure that there are reachable routes between the product center and disaster recovery center so that data of the production center can be backed up to the disaster recovery center. This ensures service running after an active/standby switchover.

The remote disaster recovery solution uses manual switching. The disaster recovery center is configured with application and database servers corresponding to those in the production center, and has corresponding software installed. Normally, services in the disaster recovery center are disabled. When a disaster occurs, servers and application software in the disaster recovery center are enabled to implement fast switching of services after manual decision-making. Manual switching has low running risks, costs, and maintenance workload, and ensures implementation of the disaster recovery solution.

The AMI solution uses application-level disaster recovery solution in active/standby mode. During service system deployment, the AMI solution uses the F5 load balancer to load balancer services. During disaster recovery, manual switching is performed in the context of network reliability based on load balancing. The third-party application system, EEM, and DCP support the Oracle database. The Data Guard (DG) is preferred for disaster recovery. In addition, the tool used to detect the database status is deployed, so the database status can be switched if required. Dedicated optical fiber links need to be deployed between the production and disaster recovery centers to ensure that backup data can be efficiently transmitted to the disaster recovery center.

Remote Disaster Recovery of the EEM

The remote disaster recovery solution of the EEM can be deployed in the single-node system or cluster mode. When the remote disaster recovery solution is deployed in the single-node system, the EEM in the production center and disaster recovery center is deployed in the single-node system. When the remote disaster recovery solution is deployed in cluster mode, the EEM in the production center and disaster recovery center is deployed in cluster mode. In this situation, the third-party application system of the data center and DCP also use the cluster mode, and the F5 load balancer is used to implement load balancing. The F5 load balancer achieves service switching from the production center to the network and link of the disaster recovery center.

In cluster mode, when DCUs and GRPS meters connect to the DCP, they first connect to the F5 load balancer through the egress router of the data center. Based on configured DCP server information on the F5 load balancer and address mapping on DCUs and GRPS meters, the F5 load balancer uses an algorithm to connect DCUs and GRPS meters to DCP servers. Then DCUs and GRPS meters go online. The F5 load balancer implements DCP load balancing. In the disaster recovery solution, the production center and disaster recovery center are configured with the same F5 load balancer and virtual IP address. DCP node information in each data center is configured in the server pool of the F5 load balancer, and the F5 load balancer can communicate with DCP nodes in the server pool. Normally, application systems and the F5 load balancer in the production center work properly, and application systems and the F5 load balancer in the disaster recovery center are in backup state. When a disaster occurs, application systems and the F5 load balancer in the disaster recovery center are enabled to implement fast switching of services after manual decision-making. The F5 load balancer in the disaster recovery center uses the same virtual IP address as that in the production center and terminals access application systems using the virtual IP address of the F5 load balancer, so terminals do not detect the switching between the production center and disaster recovery center.

User information of the EEM and third-party application system and device data are stored in the database. After an active/standby switchover, application systems of the disaster recovery center can obtain information from its database. To ensure service running after an active/standby switchover, the software and hardware configurations of application systems and servers in the disaster recovery center need to meet the following requirements:
  • The versions of the third-party application system, EEM, and DCP are the same as those in the production center.
  • The versions of operating systems of application system servers are the same as those in the production center.
  • The time zone and time settings of operating systems of application system servers are the same as those in the production center.
  • The software configurations of application system servers are the same as those in the production center.
  • The hardware configurations of application system servers are the same as those in the production center.

In the AMI solution, users can access the third-party application system and EEM through the IP address or DNS in the browser. The production center and disaster recovery center use different IP addresses to provide external services. After an active/standby switchover, a different IP address is used to access the third-party application system and EEM. If DNS is used to access the third-party application system and EEM, the DNS server needs to be deployed in the production center and disaster recovery center and the domain name is mapped to the external IP address of the data center.

Remote Disaster Recovery of a Database

Service continuity is the objective of the disaster recovery solution. Data must be continuous to ensure service continuity. Data integrity and consistency are the key for service continuity, and data replication ensures data synchronization between the production center and disaster recovery center. The Oracle database and MySQL database support cluster deployment, active/standby backup, and data replication, implementing data backup of active and standby databases.

In the AMI solution, the third-party application system uses the Oracle database, and the EEM and DCP use the Oracle database and MySQL database. When remote disaster recovery of the EEM is deployed, the remote disaster recovery configuration needs to be performed for the database. Both the Oracle database and MySQL database support remote disaster recover.

In the AMI solution, there are many terminals and the terminals generate a large amount of data. During data backup, there are high requirements for the data transmission efficiency. In the disaster recovery solution, to improve the data replication efficiency and reliability, you are advised to use optical fibers for data transmission in the production center and disaster recovery center and deploy a dedicated network of core switches between the two centers.

Remote Disaster Recovery of the Oracle Database

In the remote disaster recovery solution, the Oracle Data Guard (DG) is used to implement remote disaster recovery. The DG is a component of the Oracle database and is used to implement remote disaster recovery and backup of the Oracle database. The DG uses Oracle Net to connect different Oracle databases. The Oracle database can be distributed in different geographical areas or deployed on the same server. For the DG, one database is used as the production database, and other databases are used as standby databases. One DG allows a maximum of 30 standby databases. The production database is used for service and data exchange with applications and accessed by most applications. The standby database is responsible for receiving data of the production database and switches to the production database to provide services for external applications when the production database cannot work properly.

The Oracle database in the single-node system, Oracle RAC, or Oracle HA can be used as the production or standby database. In cluster mode, Oracle HA or Oracle RAC needs to be deployed. Oracle RAC is recommended to ensure data reliability and database performance. When the production center works properly, the DG backs up data of the production database to the disaster recovery center. When an exception occurs, an active/standby switchover is performed to restore the database of the disaster recovery center, the DG automatically sends the backup log file to the standby database of the disaster recovery center to ensure data consistency of the production and standby databases.

Remote Disaster Recovery of the MySQL Database

Remote disaster recovery of the MySQL database is implemented through data replication and restoration of the active database. The MySQL database supports synchronous, unidirectional, and asynchronous data replication modes. During replication, one MySQL database server is used as the active server, and one or more database servers are used as standby servers. The active server writes updated data of the database into the log file. The standby server obtains updated data of the active server from the log file and takes corresponding actions in its database to ensure data synchronization with the active server.

Replication of the MySQL database is implemented based on the binary log. The active server needs to record all modified data in the binary log, so the binary log of the active server must be enabled to implement data replication and restoration. Each standby server receives updated data in the binary log of the active server, copies data, and performs the same operations as those of the active database so that data of the active and standby databases are consistent.

Translation
Download
Updated: 2019-03-07

Document ID: EDOC1100069579

Views: 7182

Downloads: 13

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