EMS resolution of split-brain virtual network function components
View Patent ↗An example operation may include a system, comprising one or more of receiving a virtual network function component instance (VNFCI) status notification resumption message with an active state when a peer VNFCI operational state is active, retrieving a timestamp of a VNFCI state change to an active state from an element VNFCI state database, retrieving a timestamp of a peer VNFCI state change to active from an element VNFCI state database, sending one or more of: a request to a virtual network function manager (VNFM) to determine if the VNFCI network is isolating while an operating state was active, and a request to the VNFM to determine if the peer VNFCI network is isolating while an operating state was active, sending a state change request with standby state to the peer VNFCI when the VNFCI is not network isolated and the peer VNFCI is network isolated, and a VNFM response is received regarding the VNFCI, a timeout response from the VNFM, and a VNFM response is received regarding the peer VNFCI, and sending a state change request with standby to the VNFCI with one or more of: the VNFCI network isolate and peer VNFCI is not network isolated, and the VNFCI is network isolated or the peer VNFCI is not network isolated, and the VNFCI is not network isolated and the peer VNFCI is network isolated and the VNFCI is in preferred standby.
1. A system, comprising:
a server hosting an element management system (EMS) controlling a split-brain resolution process for one or more virtual network function component instances (VNFCI), wherein the EMS is configured to:
receive, from a peer VNFCI, a VNFCI status notification resumption message when the peer VNFCI is active;
retrieve a timestamp of a VNFCI state change, of a first VNFCI, to an active state from an element VNFCI state database;
retrieve a timestamp of a VNFCI state change, of the peer VNFCI, to an active state from an element VNFCI state database;
send a request to a virtual network function manager (VNFM) to identify if the first VNFCI was isolating while the first VNFCI was in an active state;
send a request to the VNFM to identify if the peer VNFCI was network isolated while the peer VNFCI was in an active state;
send a state change request, with an attribute specifying a next state of Standby, to the peer VNFCI when the first VNFCI is identified as having not been network isolated, and the peer VNFCI was network isolated;
send the state change request to the first VNFCI when the first VNFCI is identified as having been network isolated, and the peer VNFCI is identified as having not been network isolated; and
send, based on a preferred standby designation, the state change request to either the VNFCI or the peer VNFCI when the first VNFCI and the peer VNFCI are identified as having been network isolated, or when a network isolation status of either the first VNFCI or the peer VNFCI is unknown.
2. The system of claim 1 , wherein the EMS is further configured to:
start a retry timer for the peer VNFCI when the state change request is sent to the peer VNFCI.
3. The system of claim 2 , wherein the EMS is further configured to: stop the retry timer for the peer VNFCI when a state change acknowledgement is received from the peer VNFCI.
4. The system of claim 3 , wherein the EMS is further configured to:
resend the state change request to the peer VNFCI when the peer VNFCI retry timer expires.
5. The system of claim 1 , wherein the EMS is further configured to:
start a retry timer for the first VNFCI when the state change request is sent to the first VNFCI.
6. The system of claim 5 , wherein the EMS is further configured to:
stop the retry timer for the first NVFCI when a state change acknowledgement is received from the first VNFCI.
7. The system of claim 5 , wherein the EMS is further configured to:
send the state change request to the first VNFCI when the VNFCI retry timer for the first VNFCI expires.
8. A method implemented by an element management system (EMS) for controlling a split-brain resolution process for one or more virtual network function component instances (VNFCI), the method comprising:
receiving a VNFCI status notification resumption message, from a peer VNFCI, when the peer VNFCI is active;
retrieving a timestamp of a VNFCI state change, of a first VNFCI, to an active state from an element VNFCI state database;
retrieving a timestamp of a VNFCI state change, of the peer VNFCI, to an active state from an element VNFCI state database;
sending a request to a virtual network function manager (VNFM) to identify if the first VNFCI was is isolating while the first VNFCI was in an active state;
sending a request to the VNFM to identify if the peer VNFCI was network isolated while the peer VNFCI was in an active state;
sending a state change request, with an attribute specifying a next state of Standby, to the peer VNFCI when the first VNFCI is identified as having not been network isolated, and the peer VNFCI was network isolated;
sending the state change request to the first VNFCI when the first VNFCI is identified as having been network isolated, and the peer VNFCI is identified as having not been network isolated, and
sending, based on a preferred standby designation, the state change request to either the VNFCI or the peer VNFCI when the first VNFCI and the peer VNFCI are identified as having been network isolated, or when a network isolation status of either the first VNFCI or the peer VNFCI is unknown.
9. The method of claim 8 , further comprising:
starting a retry timer for the peer VNFCI when the state change request is sent to the peer VNFCI.
10. The method of claim 9 , further comprising:
stopping the retry timer for the peer VNFCI when a state change acknowledgement is received from the peer VNFCI.
11. The method of claim 9 , further comprising:
resending the state change request to the peer VNFCI when the peer VNFCI retry timer expires.
12. The method of claim 8 , further comprising:
starting a retry timer for the first VNFCI when the state change request is sent to the first VNFCI.
13. The method of claim 12 , further comprising:
stopping the retry timer for the first NVFCI when a state change acknowledgement is received from the first VNFCI.
14. The method of claim 12 , further comprising:
sending the state change request to the first VNFCI when the retry timer for the first VNFCI expires.
15. A non-transitory computer readable medium comprising one or more instructions that when read by a processor, of an element management system (EMS) that controls a split-brain resolution process for one or more virtual network function component instances (VNFCI), cause the processor to perform:
receiving a VNFCI status notification resumption message, from a peer VNFCI, when the peer VNFCI is active;
retrieving a timestamp of a VNFCI state change, of a first VNFCI, to an active state from an element VNFCI state database;
retrieving a timestamp of a VNFCI state change, of the peer VNFCI, to an active state from an element VNFCI state database;
sending a request to a virtual network function manager (VNFM) to identify if the first VNFCI was is isolating while the first VNFCI was in an active state;
sending a request to the VNFM to identify if the peer VNFCI was network isolated while the peer VNFCI was in an active state;
sending a state change request, with an attribute specifying a next state of Standby, to the peer VNFCI when the first VNFCI is identified as having not been network isolated, and the peer VNFCI was network isolated;
sending the state change request to the first VNFCI when the first VNFCI is identified as having been network isolated, isolate and the peer VNFCI is identified as having not been network isolated; and
sending, based on a preferred standby designation, the state change request to either the VNFCI or the peer VNFCI when the first VNFCI and the peer VNFCI are identified as having been network isolated, or when a network isolation status of either the first VNFCI or the peer VNFCI is unknown.
16. The non-transitory computer readable medium of claim 15 , wherein the one or more instructions further cause the processor to perform:
starting a retry timer for the peer VNFCI when the state change request is sent to the peer VNFCI.
17. The non-transitory computer readable medium of claim 16 , wherein the one or more instructions further cause the processor to perform:
stopping the retry timer for the peer VNFCI when a state change acknowledgement is received from the peer VNFCI.
18. The non-transitory computer readable medium of claim 16 , wherein the one or more instructions further cause the processor to perform:
resending the state change request to the peer VNFCI when the peer VNFCI retry timer expires.
19. The non-transitory computer readable medium of claim 15 , wherein the one or more instructions further cause the processor to perform:
starting a retry timer for the first VNFCI when the state change request is sent to the first VNFCI.
20. The non-transitory computer readable medium of claim 19 , wherein the one or more instructions further cause the processor to perform:
stopping the retry timer for the first NVFCI when a state change acknowledgement is received from the first VNFCI.