CN108632151B - Cluster router board card access method and device and cluster router - Google Patents
Cluster router board card access method and device and cluster router Download PDFInfo
- Publication number
- CN108632151B CN108632151B CN201710181220.2A CN201710181220A CN108632151B CN 108632151 B CN108632151 B CN 108632151B CN 201710181220 A CN201710181220 A CN 201710181220A CN 108632151 B CN108632151 B CN 108632151B
- Authority
- CN
- China
- Prior art keywords
- board card
- board
- backplane
- request
- backboard
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/30—Decision processes by autonomous network management units using voting and bidding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/60—Router architectures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
Abstract
The invention provides a method and a device for accessing a board card of a cluster router and the cluster router, and belongs to the technical field of communication. The cluster router comprises a first board card and a second board card, wherein a hardware master is inserted into the first board card, and a hardware standby is inserted into the second board card. The method comprises the following steps: receiving a backboard access information request sent by a main service process, wherein the backboard access information request is used for the second board card to send to a backboard daemon thread of the first board card when the main service process is distributed to the hardware standby; receiving an access result of a backboard daemon thread of the first board card for accessing backboard information; and feeding back the access result to the main business process. The method and the device can realize that the main service process can be distributed to any board card, thereby realizing the separation of the service and the board card, and improving the stability and the reliability of the cluster router on the basis of saving the cost.
Description
Technical Field
The present invention relates to the field of communications technologies, and in particular, to a method and an apparatus for accessing a board card of a cluster router, and a cluster router.
Background
In current cluster routers, traffic exists in both master (M) and standby (S) modes. The service master executes the service function, and the service standby mainly executes the work of switching the service master to replace the original master when the master goes down, so that the service continuity is ensured. During the operation process of the business owner, some information (such as GMAC) related to the machine frame needs to be queried or modified, and the information is generally stored on the backplane of the machine frame. In order to ensure the safety of data operation, the physical attributes of the board cards accessing the backplane are limited, namely only the board card of the hardware master can access the backplane. Therefore, at present, the service master is allocated to the board card of the hardware master by default, and the service slave is allocated to the board card of the hardware slave. Therefore, the result of the strong binding between the main and standby hardware of the service and the main and standby hardware of the board card is caused. Moreover, in the cluster system, there are many kinds of services, and the board resources are limited, and if the policy of strong binding is adopted, the load of some boards in the system is increased, and the stability and reliability of the system are reduced.
In order to solve the problems, the prior art mainly improves the process by hardware logic. The first technique is: hardware logic does mutual exclusion between a main hardware and a standby hardware, namely the main hardware or the standby hardware can be accessed, but only the main hardware or the standby hardware can be accessed at the same time. The second technique is: the content on the machine frame back plate is moved to the board cards, but when the business owner modifies the information, the information needs to be synchronized to other board cards and the information of the corresponding board cards needs to be updated, namely, the consistency of the information on all the board cards needs to be ensured.
Either the first or second technique described above requires upgrading and revising of hardware logic. This presents a problem: no effective improvement can be made to the board or device already in use. This results in wasted device resources and increases the cost of enterprise operations to some extent. Moreover, for the second technique, information related to the machine frame is put on each board card, which involves the occupation of board card storage resources and the maintenance of data synchronization, thus increasing the load of each board card intangibly.
Therefore, it is necessary to provide a method and an apparatus for accessing a board card of a cluster router, and a cluster router, so as to avoid the above situations.
Disclosure of Invention
The invention mainly aims to provide an online monitoring method, device and system, which can monitor the running condition of a single board online, facilitate the analysis of the reason of communication abnormity, enhance the maintainability of the single board, and have simple hardware design and low maintenance cost of the whole system.
In order to achieve the above object, the present invention provides a method for accessing a board card of a cluster router, where the cluster router includes a first board card and a second board card, where a hardware host is inserted into the first board card, and a hardware standby is inserted into the second board card, and the method includes: receiving a backboard access information request sent by a main service process, wherein the backboard access information request is used for the second board card to send to a backboard daemon thread of the first board card when the main service process is distributed to the hardware standby; receiving an access result of the backboard daemon thread of the first board card for accessing the backboard information; and feeding back the access result to the main business process.
Optionally, the backboard information access request is further used for the first board to send to a backboard daemon thread of the first board when the main service process is allocated to the hardware master.
Optionally, before the receiving a request for accessing backplane information sent by a host business process, the method further includes: a start-up version; setting a backboard daemon thread of the first board card at the initial stage of version starting; dynamically competing and electing the main service; and creating the corresponding main business process according to the election result.
Optionally, before receiving an access result of the backplane daemon thread of the first board accessing the backplane information, the method further includes: and under the condition that the time interval for sending the request reaches a preset time threshold, the first board card or the second board card sends the request to a backboard daemon thread of the first board card again.
Optionally, when the request for accessing the backplane information is a read request, the receiving an access result of the backplane daemon thread of the first board accessing the backplane information includes: and receiving the data of the local cache read by the backboard daemon thread of the first board card.
Optionally, when the request for accessing the backplane information is a write request, the receiving an access result of the backplane daemon thread of the first board accessing the backplane information includes: and judging whether the data of the backboard daemon thread writing request of the first board card is consistent with the data of the local cache, and if not, updating the backboard information.
In addition, to achieve the above object, the present invention further provides a device for accessing a board card of a cluster router, where the cluster router includes a first board card and a second board card, where a hardware host is inserted into the first board card, and a hardware standby is inserted into the second board card, and the device includes: the first receiving module is used for receiving a backboard access information request sent by a main service process, wherein the backboard access information request is used for sending the backboard daemon thread of the first board card to the second board card when the main service process is distributed to the hardware standby; the second receiving module is used for receiving an access result of the backboard daemon thread of the first board card for accessing the backboard information; and the feedback module is used for feeding back the access result to the main service process.
Optionally, the backboard information access request is further used for the first board to send to a backboard daemon thread of the first board when the main service process is allocated to the hardware master.
Optionally, the apparatus further comprises: the starting module is used for starting the version; the setting module is used for setting a backboard daemon thread of the first board card at the initial stage of version starting; the election module is used for dynamically competing and electing the main service; and the creating module is used for creating the corresponding main business process according to the election result.
Optionally, the apparatus further comprises: the judging module is used for judging whether the time interval from the request sending reaches a preset time threshold value or not, and if so, the sending module is triggered; the sending module is configured to enable the first board card or the second board card to send the request to a backplane daemon thread of the first board card again.
Optionally, when the request for accessing the backplane information is a read request, the second receiving module is specifically configured to receive data that is read by a backplane daemon thread of the first board card and is locally cached.
Optionally, when the request for accessing the backplane information is a write request, the determining module is further configured to determine whether data of the backplane daemon thread write request of the first board card is consistent with locally cached data, and if not, update the backplane information.
In addition, in order to achieve the above object, the present invention further provides a cluster router, which includes a first board card and a second board card, wherein a hardware master is inserted into the first board card, a hardware slave is inserted into the second board card, and the second board card is configured to send a backplane information access request sent by a main service process to a backplane daemon thread of the first board card when the main service process is allocated to the hardware slave; the first board card is used for triggering the backboard daemon thread to access backboard information and feeding back an access result to the main business process.
Optionally, the first board is further configured to send the request to a backplane daemon thread of the first board when the main service process is allocated to the hardware master.
Optionally, when the request is a read notification message, the first board card is further configured to trigger the backplane daemon thread to read locally cached data.
Optionally, when the request is a write request, the first board card is further configured to trigger the backplane daemon thread to determine whether data of the write request is consistent with locally cached data, and if not, update the backplane information.
According to the cluster router board card access method, device and cluster router provided by the invention, the access backboard information request sent by the main service process is received, wherein the access backboard information request is used for the second board card to send to the backboard daemon thread of the first board card when the main service process is distributed to the hardware standby, the access result of the backboard daemon thread of the first board card for accessing the backboard information is received, and the access result is fed back to the main service process, so that the main service process can be distributed to any board card, the separation of the service and the board card is realized, and the stability and the reliability of the cluster router are improved on the basis of saving the cost.
Drawings
FIG. 1 is a block diagram of a router system according to the preferred embodiment of the present invention;
fig. 2 is a schematic flowchart of a board card access method of a cluster router according to a first embodiment of the present invention;
FIG. 3 is a schematic flow chart of example one of the first embodiment;
fig. 4 is a flowchart of example two in the first embodiment;
fig. 5 is a flowchart of example three in the first embodiment;
fig. 6 is a flowchart of example four in the first embodiment;
fig. 7 is a schematic flowchart of a board card access method of a cluster router according to a second embodiment of the present invention;
fig. 8 is a schematic flowchart of a board card access method of a cluster router according to a third embodiment of the present invention;
fig. 9 is a schematic block diagram of a board card access device of a cluster router according to a fourth embodiment of the present invention.
The implementation, functional features and advantages of the objects of the present invention will be further explained with reference to the accompanying drawings.
Detailed Description
Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are illustrative and intended to be illustrative of the invention and are not to be construed as limiting the invention.
The invention provides a cluster router, and the system comprises a router cluster system center frame (CCC) and a router cluster system line card frame (CLC). And the router cluster system central frame (CCC) and the router cluster system line card frame (CLC) are respectively provided with at least one corresponding machine frame and at least one corresponding board card. Each board card is connected with the pin holes of the back plate through pins, and control surface communication between the board cards and between the back plate is connected. By cascading the optical modules and the optical fibers for each frame, control plane communication between the frames is realized.
Referring to fig. 1, a cluster router according to a first embodiment of the present invention is shown. The system is a 2+2 cluster router, and comprises 4 machine frames, namely 2 CCCs and 2 CLCs formed by cascading optical modules and optical fibers. Each CCC and CLC respectively comprises a board card 1, a board card 2 and a backboard, wherein the board cards are connected with a backboard pinhole through a contact pin, and control surface communication between the board cards and between the backboard is connected. In other embodiments, the cluster router may also be a "1 + 2" system, a "2 + 4" system, etc., and the present invention is not limited in this regard.
Taking one of the machine frames as an example, the machine frame includes a first board card and a second board card, wherein a hardware host is inserted on the first board card, and a hardware standby is inserted on the second board card.
And the first board card is used for sending the request to a backboard daemon thread of the first board card when the main service process is distributed to the hardware master.
And the second board card is used for sending a backboard access information request sent by the main business process to the backboard daemon thread of the first board card when the main business process is distributed to the hardware standby.
The first board card is further configured to trigger the backplane daemon thread to access backplane information, and feed back an access result to the main service process.
Further, when the request is a read notification message, the first board card is further configured to trigger the backplane daemon thread to read locally cached data.
Further, when the request is a write request, the first board card is further configured to trigger the backplane daemon thread to determine whether data of the write request is consistent with locally cached data, and if not, update the backplane information.
Based on the above cluster router, the following embodiments are proposed.
Referring to fig. 2, in a method for accessing a board card of a cluster router according to a first embodiment of the present invention, in this embodiment, a machine frame includes a first board card and a second board card, where a hardware host is inserted into the first board card, and a hardware standby is inserted into the second board card. The method comprises the following steps:
Further, if it is determined that the single board is not allocated to the hardware master or the hardware slave, the single board is considered to be abnormal, and the single board is restarted.
Specifically, if the main service is allocated to the hardware master, the process on the main service sends a message to notify the backplane daemon thread of the board through a specific interface.
And step 204, enabling the second board card to send the request to a backboard daemon thread of the first board card.
Specifically, if the main service is allocated to the hardware standby, the process on the main service sends a message to notify the backplane daemon thread of the board through a specific interface.
Specifically, the received access result of the backplane daemon thread of the first board card is returned to the main business process.
Further, after the main service process receives the backplane access result returned by the backplane daemon thread, the main service process can continue other service processes.
In this embodiment, if the main service is hardware-based, message exchange does not involve a Central Processing Unit (CPU), so that the reliability of the message can be ensured. If the main service is on the hardware, the message interaction is across CPUs, and the reliability of the message is ensured through a reliable message interaction mechanism.
In this embodiment, the backplane information is stored in the local CPU in a local cache manner, so as to reduce access to the backplane information as much as possible.
For example, referring to fig. 3, if the request for accessing backplane information is a read request and the host business process is assigned to the hardware host, steps 203 and 205 include:
Specifically, if there is a read request in a business process of a first board (i.e., a hardware host board), and a backplane daemon thread on a hardware host is already in a Working (WORK) state by using a driver of a state machine, a read message is directly sent to notify the backplane daemon thread of the board.
Specifically, the locally cached data read by the local backplane daemon thread is received. Accordingly, in a subsequent step (step 206), the read data is acknowledged to the main business process.
For example, referring to fig. 4, if the request for accessing backplane information is a read request and the host business process is allocated to the hardware device, steps 204 and 205 include:
Specifically, if there is a read request in the service process of the second board (i.e., the hardware standby board), since the backplane daemon thread on the hardware standby board is driven by the state machine to be in a SLEEP (SLEEP) state, a message needs to be sent to notify the backplane daemon thread of the first board (i.e., the hardware main board).
Specifically, the backplane daemon thread on the hardware master adopts the state machine driving to be in the WORK (WORK) state, and directly receives the read local cache data. Accordingly, in a subsequent step (step 206), the read data is acknowledged to the main business process.
For example, referring to fig. 5, if the request for accessing backplane information is a write request and the host business process is assigned to the hardware host, steps 203 and 205 include:
Specifically, if there is a write request in a business process of a first board (i.e., a hardware host board), and at this time, a backplane daemon thread on a hardware host is already in a Working (WORK) state by using a driver of a state machine, a message is directly sent to notify the backplane daemon thread of the board.
Specifically, the write request data is compared with the locally cached data, and if the write request data is inconsistent with the locally cached data, step 530 is performed, and if the write request data is inconsistent with the locally cached data, step 206 is performed, that is, the write request data is directly responded to the main business process.
Specifically, if the requested write data is inconsistent with the locally cached data, the backplane information is updated, and in the subsequent step (step 206), the updated data is responded to the main business process.
For example, referring to fig. 6, if the request for accessing backplane information is a write request and the host business process is allocated to the hardware device, steps 204 and 205 include:
Specifically, if there is a write request in a service process of the second board card (i.e., the hardware standby board card), since the backplane daemon thread on the hardware standby board card is driven by the state machine to be in a SLEEP (SLEEP) state, a message needs to be sent to notify the backplane daemon thread of the first board card (i.e., the hardware main board card).
Specifically, the backplane daemon thread on the hardware master is already in a Working (WORK) state by adopting the driving of the state machine, compares the data requested to be written with the data cached locally, and if the data requested to be written and the data cached locally are not consistent, the step 630 is performed, and if the data requested to be written and the data cached locally are not consistent, the step 206 is performed, that is, the written data are directly responded to the main business process.
Specifically, if the requested write data is inconsistent with the locally cached data, the backplane information is updated, and in the subsequent step (step 206), the updated data is responded to the main business process.
In the board card access method for the cluster router in the embodiment, by receiving a backboard information access request sent by a main service process, when the main service process is allocated to a hardware master or a hardware standby, a first board card or a second board card sends the request to a backboard daemon thread of the first board card, receives an access result of the backboard daemon thread of the first board card accessing the backboard information, and feeds the access result back to the main service process, the main service process can be allocated to any board card, so that the service and the board card are separated, and the stability and the reliability of the cluster router are improved on the basis of saving the cost.
Referring to fig. 7, a second embodiment of the present invention further provides a method for accessing a board card of a cluster router. In the second embodiment, the access method of the cluster router board card is a further improvement on the first embodiment, except that before step 201 in the first embodiment, the method further includes the following steps:
Specifically, after the router cluster system is built, the version is started.
Specifically, in the initialization stage, a backplane daemon thread is set for the first board card to maintain backplane information.
Specifically, according to a preset election mechanism, dynamic competitive election is performed on the main software service and the standby software service, so that election is not bound with the main hardware service of the board card forcibly.
According to the board card access method of the cluster router, a backboard daemon thread is set for each mainboard card, dynamic competitive election of main services is carried out on the first board card, a corresponding main service process is created according to an election result, the main and standby of the services can be separated from the main and standby of board card hardware, deployment of the services is independent of the board cards, the main and standby of the services can be deployed in a mixed mode, existing equipment resources can be effectively utilized, and cost of enterprise operation is reduced.
Referring to fig. 8, a third embodiment of the present invention further provides a method for accessing a board card of a cluster router. In a third embodiment, the method for accessing a cluster router board card is a further improvement made on the basis of the first embodiment or the second embodiment, and is different in that before a backplane daemon thread of the first board card accesses backplane information, the method further includes the following steps:
The method for accessing the board card of the cluster router in the embodiment adopts the synchronous message interface, and ensures the reliability of the cross-CPU message by setting the timeout mechanism.
Referring to fig. 9, a fourth embodiment of the present invention provides a device for accessing a board card of a cluster router, where the device includes:
and a start module 910 for starting the version.
Specifically, after the router cluster system is built, the startup module 910 starts the startup version.
The setting module 920 is configured to set a backplane daemon thread of the first board card at an initial stage of version startup.
Specifically, in the initialization stage, the setting module 920 sets a backplane daemon thread for the first board card to maintain backplane information.
And an election module 930 for dynamically competing for election of the main service.
Specifically, according to a preset election mechanism, the election module 930 performs dynamic competitive election on the main hardware and the standby hardware of the software service, so that the election is not bound to the main hardware and the standby hardware of the board card.
And a creating module 940, configured to create a corresponding main service process according to the election result.
The first receiving module 950 is configured to receive a backplane information access request sent by a host business process.
The determining module 960 is configured to determine that the main service process is allocated to the hardware master or the hardware slave, and trigger the sending module 970 if the main service process is allocated to the hardware master or the hardware slave.
Further, if the determining module 960 determines that the allocation is not to the hardware master or the hardware slave, it is determined that the allocation is abnormal, and the board is restarted.
A sending module 970, configured to enable the first board card or the second board card to send the request to a backplane daemon thread of the first board card.
Specifically, if the main service is allocated to the hardware master, the process on the main service sends a message to notify the backplane daemon thread of the board through a specific interface. If the main service is distributed to the hardware standby, the process on the main service sends a message to inform a backboard daemon thread of the board through a specific interface.
A second receiving module 980 is configured to receive an access result of the backplane daemon thread of the first board card accessing the backplane information.
A feedback module 990, configured to feed back the access result to the main service process.
Specifically, the feedback module 990 returns the received access result of the backplane daemon thread of the first board card to the main service process.
Further, after the main service process receives the backplane access result returned by the backplane daemon thread, the main service process can continue other service processes.
In this embodiment, if the main service is hardware-based, message exchange does not involve a Central Processing Unit (CPU), so that the reliability of the message can be ensured. If the main service is on the hardware, the message interaction is across CPUs, and the reliability of the message is ensured through a reliable message interaction mechanism.
In this embodiment, the backplane information is stored in the local CPU in a local cache manner, so as to reduce access to the backplane information as much as possible.
Further, the determining module 960 is further configured to determine whether a time interval from the request sending reaches a preset time threshold. If so, the triggering module 970 triggers the first board card or the second board card to resend the request to the backplane daemon thread of the first board card, and if not, continues to wait, so that a synchronous message interface is adopted, and the reliability of the cross-CPU message is ensured by setting a timeout mechanism.
For example, if the request for accessing the backplane information is a read request and the main service process is allocated to the hardware master, the sending module 970 is specifically configured to enable the first board to send a read notification message to the backplane daemon thread of the first board.
Specifically, if there is a read request in a business process of a first board (i.e., a hardware host board), and a backplane daemon thread on a hardware host is already in a Working (WORK) state by using a driver of a state machine, a read message is directly sent to notify the backplane daemon thread of the board.
Correspondingly, the second receiving module 980 is specifically configured to receive data, which is read by the backplane daemon thread of the first board, of the local cache. Specifically, the locally cached data read by the local backplane daemon thread is received.
For example, if the request for accessing the backplane information is a read request and the main service process is allocated to the hardware backup, the sending module 970 is specifically configured to send a read notification message to the backplane daemon thread of the first board by the second board.
Specifically, if there is a read request in the service process of the second board (i.e., the hardware standby board), since the backplane daemon thread on the hardware standby board is driven by the state machine to be in a SLEEP (SLEEP) state, a message needs to be sent to notify the backplane daemon thread of the first board (i.e., the hardware main board).
Correspondingly, the second receiving module 980 is specifically configured to read the locally cached data by the backplane daemon of the first board. Specifically, the backplane daemon thread on the hardware master adopts the state machine to drive the backplane daemon thread to be in a WORK (WORK) state, and directly receives the read data of the local cache.
For example, if the request for accessing the backplane information is a write request and the main service process is allocated to the hardware master, the sending module 970 is specifically configured to send a write notification message to the backplane daemon thread of the first board by the first board.
Specifically, if there is a write request in a business process of a first board (i.e., a hardware host board), and at this time, a backplane daemon thread on a hardware host is already in a Working (WORK) state by using a driver of a state machine, a message is directly sent to notify the backplane daemon thread of the board.
Correspondingly, the determining module 960 is further configured to determine whether data of the backplane daemon thread write request of the first board card is consistent with locally cached data, if not, update the backplane information, and if so, trigger the feedback module 990.
Specifically, the determining module 960 compares the data requested to be written with the locally cached data, if the data is inconsistent, the backplane information is updated, and if the data is not consistent, the feedback module 990 is triggered, that is, the written data is directly responded to the main service process.
Specifically, if the requested write data is inconsistent with the locally cached data, the backplane information is updated.
For example, if the request for accessing the backplane information is a write request and the main service process is allocated to the hardware standby, the sending module 970 is specifically configured to enable the second board to send a write notification message to the backplane daemon thread of the first board.
Specifically, if there is a write request in a service process of the second board card (i.e., the hardware standby board card), since the backplane daemon thread on the hardware standby board card is driven by the state machine to be in a SLEEP (SLEEP) state, a message needs to be sent to notify the backplane daemon thread of the first board card (i.e., the hardware main board card).
Correspondingly, the determining module 960 is further configured to determine whether data of the backplane daemon thread write request of the first board card is consistent with locally cached data, if not, update the backplane information, and if so, trigger the feedback module 990.
Specifically, the backplane daemon thread on the hardware master is already in a Working (WORK) state by adopting the driving of the state machine, compares the data requested to be written with the locally cached data, updates the backplane information if the data requested to be written and the locally cached data are inconsistent, and triggers the feedback module 990 if the data requested to be written are not consistent, that is, the written data are directly responded to the main service process.
Specifically, if the requested write data is inconsistent with the locally cached data, the backplane information is updated.
In the board card access device of the cluster router in this embodiment, the first receiving module 950 receives a request for accessing backplane information sent by a main service process, when the main service process is allocated to a hardware host or a hardware standby, the sending module 970 enables the first board card or the second board card to send the request to a backplane daemon thread of the first board card, the second receiving module 980 receives an access result of the backplane daemon thread of the first board card for accessing backplane information, and the feedback module 990 feeds back the access result to the main service process, so that the main service process can be allocated to any board card, thereby realizing separation of services and board cards, and thus improving stability and reliability of the cluster router on the basis of saving cost.
It should be noted that, in this document, the term "comprises/comprising" or any other variation thereof is intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.
Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which is stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (such as a mobile phone, a computer, a server, an air conditioner, or a network device) to execute the method according to the embodiments of the present invention.
The above description is only a preferred embodiment of the present invention, and not intended to limit the scope of the present invention, and all modifications of equivalent structures and equivalent processes, which are made by using the contents of the present specification and the accompanying drawings, or directly or indirectly applied to other related technical fields, are included in the scope of the present invention.
Claims (16)
1. A method for accessing a cluster router board card is characterized in that the cluster router comprises a first board card and a second board card, wherein a hardware main board card is inserted into the first board card, and a hardware standby board card is inserted into the second board card, and the method comprises the following steps:
receiving a backboard access information request sent by a main service process, wherein the backboard access information request is used for the second board card to send to a backboard daemon thread of the first board card when the main service process is distributed to the hardware standby;
receiving an access result of the backboard daemon thread of the first board card for accessing the backboard information;
and feeding back the access result to the main business process.
2. The method of claim 1, wherein the request for access backplane information is further used by the first board to send a backplane daemon thread of the first board when the host business process is assigned to the hardware host.
3. The method according to claim 1, wherein before the receiving the request for accessing backplane information sent by the host business process, the method further comprises:
a start-up version;
setting a backboard daemon thread of the first board card at the initial stage of version starting;
dynamically competing and electing the main service;
and creating the corresponding main business process according to the election result.
4. The cluster router board access method according to claim 1 or 2, wherein before receiving an access result of the backplane daemon thread of the first board accessing the backplane information, the method further comprises:
and under the condition that the time interval for sending the request reaches a preset time threshold, the first board card or the second board card sends the request to a backboard daemon thread of the first board card again.
5. The method according to claim 1 or 2, wherein when the request for accessing backplane information is a read request, the receiving an access result of the backplane daemon thread of the first board accessing backplane information includes:
and receiving the data of the local cache read by the backboard daemon thread of the first board card.
6. The cluster router board access method according to claim 1 or 2, wherein when the request for accessing backplane information is a write request, the receiving an access result of the backplane daemon thread of the first board accessing backplane information includes:
and judging whether the data of the backboard daemon thread writing request of the first board card is consistent with the data of the local cache, and if not, updating the backboard information.
7. The utility model provides a cluster router integrated circuit board access arrangement, its characterized in that, cluster router includes first integrated circuit board and second integrated circuit board, wherein, it is main to have inserted hardware on the first integrated circuit board, it is equipped with to have inserted hardware on the second integrated circuit board, the device includes:
the first receiving module is used for receiving a backboard access information request sent by a main service process, wherein the backboard access information request is used for sending the backboard daemon thread of the first board card to the second board card when the main service process is distributed to the hardware standby;
the second receiving module is used for receiving an access result of the backboard daemon thread of the first board card for accessing the backboard information;
and the feedback module is used for feeding back the access result to the main service process.
8. The device of claim 7, wherein the request for access backplane information is further used for the backplane daemon thread of the first board to send to the first board when the host business process is assigned to the hardware host.
9. The apparatus of claim 7, further comprising:
the starting module is used for starting the version;
the setting module is used for setting a backboard daemon thread of the first board card at the initial stage of version starting;
the election module is used for dynamically competing and electing the main service;
and the creating module is used for creating the corresponding main business process according to the election result.
10. The apparatus as claimed in claim 7 or 8, further comprising:
the judging module is used for judging whether the time interval from the request sending reaches a preset time threshold value or not, and if so, the sending module is triggered;
the sending module is configured to enable the first board card or the second board card to send the request to a backplane daemon thread of the first board card again.
11. The access device for the cluster router board card according to claim 7 or 8, wherein when the request for accessing the backplane information is a read request, the second receiving module is specifically configured to receive data that is read by a backplane daemon thread of the first board card and is locally cached.
12. The device of claim 10, wherein when the request for accessing the backplane information is a write request, the determining module is further configured to determine whether data of the write request of the backplane daemon thread of the first board is consistent with data of the local cache, and if not, update the backplane information.
13. A cluster router is characterized by comprising a first board card and a second board card, wherein a hardware main card is inserted on the first board card, a hardware standby card is inserted on the second board card,
the second board card is used for sending a backboard access information request sent by the main business process to the backboard daemon thread of the first board card when the main business process is distributed to the hardware standby;
the first board card is used for triggering the backboard daemon thread to access backboard information and feeding back an access result to the main business process.
14. The cluster router of claim 13, wherein the first board is further configured to send the request to a backplane daemon thread of the first board when the host business process is assigned to the hardware host.
15. The cluster router of claim 13 or 14, wherein when the request is a read notification message, the first board is further configured to trigger the backplane daemon thread to read locally cached data.
16. The cluster router according to claim 13 or 14, wherein when the request is a write request, the first board card is further configured to trigger the backplane daemon thread to determine whether data of the write request is consistent with locally cached data, and if not, update the backplane information.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710181220.2A CN108632151B (en) | 2017-03-24 | 2017-03-24 | Cluster router board card access method and device and cluster router |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710181220.2A CN108632151B (en) | 2017-03-24 | 2017-03-24 | Cluster router board card access method and device and cluster router |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108632151A CN108632151A (en) | 2018-10-09 |
| CN108632151B true CN108632151B (en) | 2022-03-11 |
Family
ID=63706671
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710181220.2A Active CN108632151B (en) | 2017-03-24 | 2017-03-24 | Cluster router board card access method and device and cluster router |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108632151B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115150317B (en) * | 2022-06-22 | 2023-09-12 | 杭州迪普科技股份有限公司 | Routing table entry issuing method and device, electronic equipment and computer readable medium |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101159990B (en) * | 2007-09-13 | 2010-07-14 | 中兴通讯股份有限公司 | Transmission equipment service panel bus selecting method |
| CN101197716B (en) * | 2007-11-21 | 2010-07-07 | 上海华为技术有限公司 | Method and device for capturing single plate ability |
| CN101977139B (en) * | 2010-07-28 | 2012-09-05 | 北京星网锐捷网络技术有限公司 | Route retransmission realization device and method, and switching equipment |
| CN101924655B (en) * | 2010-08-23 | 2015-06-03 | 中兴通讯股份有限公司 | Method and device for supporting login of multi-serial port terminal |
| CN101938417A (en) * | 2010-09-01 | 2011-01-05 | 中兴通讯股份有限公司 | Method for realizing configuration of main and auxiliary board cards as well as board cards |
| US8886834B2 (en) * | 2010-12-14 | 2014-11-11 | Cisco Technology, Inc. | Hot standby neighbor discovery protocol for internet protocol version 6 |
| CN102185753B (en) * | 2011-01-30 | 2013-10-30 | 广东佳和通信技术有限公司 | Device for realizing dual-backup switching of Ethernet link inside communication equipment |
| WO2014075216A1 (en) * | 2012-11-13 | 2014-05-22 | 华为技术有限公司 | Method and network device for establishing virtual cluster |
-
2017
- 2017-03-24 CN CN201710181220.2A patent/CN108632151B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN108632151A (en) | 2018-10-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11531625B2 (en) | Memory management method and apparatus | |
| WO2018149221A1 (en) | Device management method and network management system | |
| WO2019179026A1 (en) | Electronic device, method for automatically generating cluster access domain name, and storage medium | |
| CN101056205A (en) | A management method, system and device based on ATCA architecture-based server | |
| CN111897666B (en) | Method, device and system for communication between multiple processes | |
| CN111385296A (en) | Business process restarting method, device, storage medium and system | |
| WO2021004256A1 (en) | Node switching method in node failure and related device | |
| CN104077111A (en) | Concurrent access control method and device for service operations | |
| CN111459403B (en) | Storage hardware management method and device | |
| CN108632151B (en) | Cluster router board card access method and device and cluster router | |
| CN109120680B (en) | Control system, method and related equipment | |
| CN107547277B (en) | Method for realizing virtualization control board and network communication equipment | |
| CN109933435B (en) | Control method and device and computer equipment | |
| CN112073555A (en) | Method for configuring IP address, electronic device and computer readable storage medium | |
| CN111427259A (en) | Frame slot type main/standby switching method, intelligent device and storage medium | |
| CN111699479A (en) | Log processing method, log processing device and computer-readable storage medium | |
| CN111586140A (en) | Data interaction method and server | |
| CN113760610A (en) | OpenStack-based bare computer high-availability realization method and device and electronic equipment | |
| CN115587049A (en) | Memory recovery method and device, electronic equipment and storage medium | |
| CN114675902A (en) | Software version management method and management device based on embedded equipment | |
| CN114356970A (en) | Storage system resource caching method and device | |
| CN110365839B (en) | Shutdown method, shutdown device, shutdown medium and electronic equipment | |
| CN111225007B (en) | Database connection method, device and system | |
| WO2020238057A1 (en) | Redis-based mqtt cluster monitoring method, apparatus, and storage medium | |
| CN110231961B (en) | Control method and system for restarting main control board |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |