In this work, we compare two ONOS architectures, old (before v1.14) and new (v1.14 and after), in terms of their availability and answer the question if the new outperforms the old architecture. ONOS is a widely used and popular open source SDN controller that changed his architecture with version 1.14 to enable in service software upgrades. For this we create a GSPN model, upon which we can present that the new architecture has a higher availability, especially in environments with less available hardware.
respectively. The last two Sections 6 and 7 answer the research question, conclude the paper and point out interesting future work. 2
2.1
In this section relevant basics are presented and explained, so the reader is well suited for the upcoming technicalities.
Dependability is a group of concepts and attributes, the most relevant are explained in this
section. [
Reliability is the continuity of correct service [
Availability is the probability for correct service in a given moment. A highly available
system is a system that has a high probability to work as expected in any given moment,
at best always. This probability can be calculated with MT TMFT+TMFT T R [
Threats to the dependability of a system are faults, errors and failures.
Faults are the basis of the threats, they can activate errors. They are either introduced
during development, via incorrect code, due to physical problems, e.g. an old hard drive stops
working, or are generated from outside the system, e.g. during interaction with the user [
Errors are part of the system’s state and may activate failures if the error has external
consequences. Errors can be detected if they generate any kind of message or signal [
A Failure is in [
Consensus protocols help to synchronize a state across distributed systems. In consensus
protocols there is one leader which will order incoming updates. It will then ask the participating
systems if a certain order is consistent with their respective state. If the majority of systems
acknowledge the update, it is committed by the leader and each system applies the update.
The same way consensus can be used to elect a participating system to their leader [
2.3
Networks have a control and a data plane, while the control plane is more of a logical nature,
the data plane is more of a physical nature. The control plane can insert, modify or delete
forwarding rules to impact routes through the network. The data plane forwards packets from
one ingress port to certain egress ports according to the set forwarding rules. In traditional
networks, both planes reside in each router. SDNs split these planes, the SDN controller has
the control over the routers which are only left with the data plane. Routers are then called
SDN switches. The control plane can be ’in-band’, on the same links as the data plane, or
’out-of-band’, on own links. As an example, when in an out-of-band control plane a controller
has a direct connection to a certain switch, the same connection in in-band control planes
may require additional switches in between. [
The controller communicates in three major ways [
The ’Open Network Operating System’ (ONOS) is, next to OpenDaylight, the largest open
source SDN controller and is widely mentioned in publications [
This section will present published work with a similar context in Section 3.1 and work with similar tools or formalism in Section 3.2. 3.1
[
The authors of [
[
The goal of [
The goal of [
The GreatSPN tool and the GSPN formalism are widely used in the context of performance
evaluation, for example in following publications.
[
GreatSPN and GSPN are used for validation and solving.
[
In this section, we will present and reason the elements and parameters of our assumed model. 4.1
The work on a new ONOS architecture arose 2017 with the formation of the ONOS internal
’In Service Software Upgrade’ team2. An ISSU means to upgrade software that is currently
running and answering requests. The goal is to upgrade without a loss of availability. For
this goal the ISSU team decided to change ONOS’ architecture: ’[...] In past versions, ONOS
embedded Atomix nodes to form Raft clusters, replicate state, and coordinate state changes.
In ONOS 1.14, that functionality is moved into a separate Atomix cluster’ [
The differences between the architectures is best presented with two example clusters. The example cluster of an old ONOS architecture in Figure 1 contains three item types, ONOS controllers (C1-C3, squares), SDN switches (S1-S3, circles) and hosts (H1-H3, hexagons). Each controller has contact to each switch (green dotted lines), but only one controller is the master of a switch (bold green dotted lines). Also, there is a communication between the controllers (purple dotted lines). The black lines between switches and hosts are signaling the connectivity between these items. The example cluster of a new ONOS architecture in Figure 1 is noticeably noisier. Here we have one item type more in the cluster, Atomix instances (A1-A3, triangles). Additionally, to the Atomix instances, we have more links, these connect each Atomix instance with each controller (blue dotted lines). Our controllers still have their controller to controller communication (red dotted lines).
The interesting point is the mentioned additional noise in the new example cluster. This separation of Atomix and ONOS brings certain flexibility benefits like dynamic horizontal scaling of the ONOS instances and separate and easier upgrade of ONOS and Atomix instances. It also brings some costs in form of additional links, communication, instances and nodes, if each instance is deployed on its own node. This leads us to question if this new architecture benefits the overall availability. We want to analyze the following points: – Do the additional elements in the cluster harm the overall availability? – If so, does it only decrease cluster availability in certain scenarios? 4.2
To make the description of the model easier, we classify elements of our model as either objects or behaviour of these objects. In the following we will present included and excluded model elements and argue why.
Objects are either up or failed, like for example in [
- We consider five versions of ONOS instances in our work. v1.13, v1.14 and three future
placeholder versions of ONOS that are based upon v1.14. The placeholder versions are
named ’v1.14 vX’ where X is 2, 3 or 4, ’vX’ for short. ’v1.14 v1’ would be the normal
v1.14. Each version has its own software failure rate.
- We also consider Atomix instances. Together with the ONOS instances, these elements
are the core of our model.
- We consider links between Atomix and Atomix and between ONOS and Atomix.
- As an own object we model the consensus protocol status. The consensus protocol
is up, if the majority of Atomix instances are up. Otherwise, it is failed. Reason: This
is due to the basic requirement of the Raft consensus protocol, which needs an active
participation of the majority of instances as explained in Section 2. In the following
sections we will use ’consensus’ and ’consensus protocol’ interchangeably.
- The cluster availability is also modeled as an object. It is up, if consensus and at least
one ONOS instance is up, in any other case it is failed. Reason: Only if consensus is up,
which includes that enough Atomix instances are up, and at least one ONOS instance is
up, the cluster can work as intended and so only then it is available.
- Failure of ONOS and Atomix instances can be due to hardware failures, software
failures and network partitions. Every instance has its own hardware node and all nodes
are equal. Reason: The consideration of these failures is intuitive. Besides that, we
assume that each instance has its own node to achieve a simpler model in contrast when
we would consider shared nodes. This node separation can also be found in [
Once a certain amount of links has failed, one respective instance fails. Links are either
between the Atomix instances or between Atomix and ONOS instances. In the example
in Figure 1 this would mean that for each two Atomix links one Atomix instance fails,
or that after three failed ONOS-Atomix links one ONOS instance fails. Reason: The
consideration of link failures and partition is an interesting topic for this work as it hits
one of the main points of the architecture change, the additional links. We do not consider
specific node connections of links, as it would drastically increase the models complexity
and also would overstep set time limits of this work. As for why we see this as a failure,
with reference to [
- Our model focuses on the control plane, so the data plane is not considered. Reason:
As it can be observed from the old cluster to the new cluster in Figure 1 the connections
(green dotted lines) between SDN controller, SDN switches and hosts do not differ. We
reason that the architectural change in the control plane does not affect the data plane in
any way and so the impact of the data plane on the overall availability is equally in both
architectures and so can be omitted as we are only interested in the changes between the
two architectures.
- We model a failure detection probability of 100%, which in other words excludes this
from the model. Reason: This approach simplifies our model and can also be found in
[
U/m/OGtYzVy_CwAJ, https://groups.google.com/a/onosproject.org/g/onosdev/c/hzfjjEyruGo/m/xsnEiMCdAwAJ and https://docs.google.com/document/d/1xZ3Wnr6VZS34paYVdZhF8WWo3M6VWKNJXQTmBnnM7Y
4.3
According to the included elements explained above, we will now present the used parameters. As for wording we use ’parameter’ and ’rate’ interchangeably. 28.28 per year 22.47 per year 20.10 per year 18.05 per year 2 per hour 30 per year 6 per minute 4 per year 12 per hour 4 per hour 6 per day 2 per year 2 per day 3 per year 4 per hour
The ONOS parameters from [
For Atomix we could not find any published work that states specific values for it. What
we could find was a software failure rate of one week in [
The Atomix software repair duration is set by us to 10 seconds. This number is gathered by a coarse grained test we did by starting and stopping an Atomix container within a Virtual Machine with 6 vCPUs and 14 GB RAM with an i7-9750H. We assume that an ONOS deployment could be done via Kubernetes, as they suggest on their website5. The number above is reasoned like following, one second is the time Kubernetes needs to perform liveness and readiness probes to check the status of the Atomix instance. If the instance is detected as unhealthy, it is shutdown which takes up around two seconds and starts up a new one on the same host which takes up roughly seven seconds. As we deploy the new Atomix instance on the same node we need to wait for the old one to be shutdown.
Getting the Atomix and ONOS upgrade durations is hard, as there exists no documentation for either one online. Furthermore, the tools that an installed ONOS version provides, do not contain hints on how to upgrade an existent cluster. As the upgrade of Atomix and
ONOS instances is mainly done via shutting down the old version and starting a new version instance in its place6, one could argue that we plainly could take the time that needs. So for Atomix that would be nine seconds, as described above minus the one second for failure detection that is not necessary in this proactive process. For ONOS a restart takes around seven seconds, measured in the same environment. The problem is that these numbers seem pretty low for a major version upgrade. For this reason we set the upgrade duration arbitrarily.
For Atomix upgrade this means five minutes with regard to the easy upgrade as described in Section 4.2. We set the ONOS upgrade durations to 15 minutes, for the failure free upgrade, and four hours, when failures are encountered by the expert. 15 minutes, since we assume that upgrading ONOS is more complex than to upgrade Atomix due to expected data migration. The four hours are a mean of considering pretty simple errors, like wrong IP address in configuration, and more complex ones, like (partly) failed data migration.
In Table 4 we listed all sourced or calculated bugs per hour per ONOS version. Bugs per hour of v1.10, v1.12 and v1.13 are based upon published work, these are also the basis for our calculation of v1.11, v1.14 and the upgrades after v1.14. Version 1.14 and the upgrades are based upon the logarithmic trend, as we expect that fewer bugs are getting fixed for each release as it gets more time intensive to fix them. 4.4
In the following section we will present one part of our GSPN model in detail7. Figure 2 contains the following Atomix elements:
Aup : Holds tokens that represent up Atomix instances.
ASW failed : Holds tokens that represent failed Atomix instances due to software failure. AHW failed : Holds tokens that represent failed Atomix instances due to hardware failure. COup : Holds at most one token, representing that consensus is up.
COfailed : Holds at most one token, representing that consensus is failed.
FSW : This transition represents a software failure of an Atomix instance. When it fires, it moves one token from the Aup place into the ASW failed place. Additionally, it has an inhibitor arc to COfailed and its rate is defined by the AtomixSW F ailRate parameter. RSW : This transition represents a software recovery of an Atomix instance. When it fires, it moves one token from the ASW failed place into the Aup place. Its rate is defined by the AtomixSW RecRate parameter.
FHW : This transition represents a hardware failure of an Atomix instance. When it fires, it moves one token from the Aup place into the AHW failed place. Its rate is defined by the HW F ailRate parameter.
RHW : This transition represents a hardware recovery of an Atomix instance. When it fires, it moves one token from the AHW failed place into the Aup place. Its rate is defined by the HW RecRate parameter.
FCO : This transition represents the failure of the consensus protocol. When it fires, it moves one token from the COup place into the COfailed place. Additionally, it has an inhibitor arc to Aup with the multiplicity of atomixmajority, whereas atomixmajority is equal to the rounded down result of atomixcount . Its rate is immediate.
2+1
Appendix (Figure 11) RCO : This transition represents the recovery of the consensus protocol. When it fires, it moves one token from the COfailed place into the COup place. Additionally, it has one input and output arc to Aup with the multiplicity of atomixmajority each. Its rate is immediate. 5
We validated our model with simulations. GreatSPN features tools to analyze performance
aspects of a GSPN or SWN model, e.g. with the ’WNSIM’ tool mentioned which was used
by [
For our sensitivity analysis, we interrupt a simulation after one hour. Each sensitivity analysis analyzes one parameter. All others parameters are unaltered, see Section 4.3 for parameter default values. The value of an analyzed parameter is altered with each ’step’. We configured our steps to be between -5 and 10 inclusive, each step differs 10% step from the default value which is used in step 0. For example with the ON OSSW RecRate parameter we have the different values per step: Step -5, -50% : 1440 0; 5 = 720 ...
Step -1, -10% : 1440 0; 9 = 1296 Step 0, +0% : 1440 1 = 1440 (default value) ...
Step 10, +100% : 1440 2 = 2880 For parameters with integer values, the difference is 1 stepno. Each step is repeated five times. Each repetition starts with its own seed which is the value of BASHs $RANDOM variable at that moment. So from a different perspective, each analyzed parameter, step, repetition and architecture is a separate simulation with a unique seed. As an optimization, not all parameters are executed in all architectures. For example, the upgrade parameters are only analyzed in the new architecture as they have no impact in the old architecture.
In all simulations, the step difference did not propagate to the cluster availability. In other words, when the value of a parameter was increased by 10%, the cluster availability did change by less than 10%. We present one sensitivity result in more depth, as an example how these results have to be read and interpreted. In Figure 3 we can see the mean result of multiple sensitivity analysis of the U pgradeClusterRate parameter. In the sensitivity analysis we focus on how much a paramter change influences the overall result. The results have a blue line if the sensitivity analysis was done only once, and it is green like in our example if the analysis was repeated multiple times, the green line then represents the mean. Like explained above, the sensitivity analysis has 16 steps, from -5 to 10 inclusive. Three exemplary steps of the mentioned sensitivity results and their meaning are described next: Step 0 : The base value of the sensitivity analysis is always step 0 as it represents results with the default values of our model from Section 4.3. In this case step 0 results in a cluster availability of 0; 9999872 (99; 99872%).
Step -5 : The parameter has -50% of its default value (1440 0; 5). This results in a cluster availability of 0; 9999817. This is a difference to our base cluster availability of about 0; 00055%, this is far from -50%.
Step 4 : The parameter has +40% of its default value (1440 1; 4). This results in a cluster availability of 0; 9999904. This is a difference to our base cluster availability of about 0; 00032%, which is far away from +40%.
So the change of the parameter value did influence to the cluster availability, but not by the same percentage.
This can be observed for all other results too. More result examples like the one just described. Some of them will be discussed multiple times in the upcoming sections, the figures are placed next to the discussion that depends the most on it. 5.2
Besides looking at sensitivity we are now looking at the plausibility of some simulation results, partly already created during sensitivity analysis.
In contrast to the sensitivity analysis, it is very important for the plausibility analysis to
consider the context of the analyzed parameter, as different parameters have different impact
on the cluster’s availability. For example an increased recovery rate is expected to increase
the cluster availability while an increased failure rate is expected to decrease it.
For the basic architecture results we take both unaltered architectures, execute each
five times and calculate the mean of all repetitions. Like a sensitivity analysis without steps.
The simulation results reveal an availability of 99,9981% for the new and 99,99550% for the
old architecture. These results are just slightly above of the 99,99% availability that ONOS
specified themselves [
Exemplary in the Figures 4 and 6 we can observe the hardware failure rate and link failure results. The results match our expectations, as the increasing failure rate decreases the cluster availability in both architectures.
In Figure 3 we can also observe that sometimes the results line takes rapid changes. This could be a hint that we have set a too low repetition count, and we need a higher variety of results per steps to get a more consistent course of the steady state availability. Even though, the differences between steps are minimal, they begin to differ from the fifth decimal place onwards. For this reason we do not further investigate this problem.
The upgrade cluster rate results in Figure 3 show a mean of multiple sensitivity analysis as the result is counterintuitive, hence a green instead of a blue line. With a faster upgrade rate the cluster availability decreases slightly. Even though the observed difference from the start of the trend line to its end is minimal9, we want to give an idea why the trend line could behave this way. With a higher upgrade rate, the cluster has more often instances that are being upgraded, which takes the cluster one instance closer to unavailability. By that we mean, if a cluster has three Atomix instances and one is being upgraded, the cluster is only left with two up Atomix instances, if one of them fails, the cluster becomes unavailable as too few up Atomix instances are left to keep the consensus up. 6
In this section we will compare the availability of the two ONOS’ architectures. First by taking a new look at the results from the sensitivity analysis from Section 5.1 in Section 6.1. Afterwards we will present specific deployment scenarios and interpret their results in Section 6.2. Finally, in Section 6.3 we will answer the research question, if the architecture change was beneficial for ONOS’ availability. It will turn out that the new architecture has an overall higher availability than the old architecture. 6.1
In the following we will present results of the sensitivity analysis results originally intended for Section 5, but they fit much better here as they let us compare the availability in both architectures. These results may not have been gathered if we had executed the simulations manually like mentioned in Section 5.
Link failure and recovery rate sensitivity results can be seen in Figures 4 and 5. We can observe that the new architecture does not depend on link availability as much as the old architecture does. It also has a higher mean availability throughout the comparison.
We come to this conclusion for the link failure rate since the new architecture trend line changes slightly. The old architecture trend line has a bigger difference between its start and end value. In other words, the higher failure rate is more noticeable in the old architecture. 9 With an absolute value of about 0,0000025 (0; 999985 Additionally, the new architecture trend line stays on a high level between 0,99998 and 1. The old architecture comes into that range with two steps, but its trend line is way lower, between 0,99995 and 0,99994.
For the link recovery rate we can observe and interpret the same. The new architecture trend line is on a higher level and also changes slightly, while the old architecture trend line is way lower and has a higher change from the trend line start to end.
At last, one remark to [
Hardware failure and recovery rate sensitivity results can be seen in Figures 6 and 7. Both architectures behave the same when the hardware failure and recovery rates change. Different is the degree of which the availability is impacted.
The hardware failure rate sensitivity analysis for the new and old architecture in Figure 6 clearly shows, that the new architecture is less dependent on its hardware, as its trend line declines less steep when compared to the old architecture.
In the old architecture the hardware recovery rate develops slightly worse than in the new architecture, as with better recovery rates the availability does not rise as fast as in the new architecture. It also does not reach cluster availabilities beyond 0; 99998 as often as the new architecture does, especially in later steps when the recovery rate is 180% (step 8) to 200% (step 10) of its default value.
Like observed in the link rate results, the availability of the new architecture is generally higher and less dependent on other elements, compared to the old architecture. 6.2
Additional to our results from Section 5, we now present scenarios to compare the availability in both architectures with specific viewpoints for a more in depth comparison. For the upgrade scenarios we simulate four deployments. Two are the unaltered v1.14 and v1.13 architectures. The other two are altered v1.14 architectures. One has no upgrade at all, which means that ONOS is never upgraded to improve its availability. The other considers upgrades, but all ONOS versions have the same availability, so if for example new bugs are introduced with a release, others are fixed. In the following this scenario is called ’stagnating’.
The results of this deployment scenario can be seen in Figure 8. On the left side we can observe that the deployment with a stagnating upgrade in the new architecture has the worst availability. Second is the old architecture which is followed up by the unaltered new architecture and the new architecture without any upgrade.
It makes sense, that the new architecture has a higher availability than the old architecture, as already presented in Sections 5.1 and 5.2. That a new architecture with unchanging failure rates after each upgrade performs the worst can be reasoned with the point that an upgrade always means that during an upgrade of an instance we are one instance closer to unavailability, as described in Section 5.2. So in other words we ’buy’ the upgrade with availability, but the availability does not improve afterwards to balance out the cost.
We expected that the unaltered new architecture would result in the highest availability, as it contains the improving ONOS availability with each upgrade. Because of this, it is a surprise that the new architecture without any upgrade has the best availability, even though the difference is very low. This surprise maybe due to the fact, that the availability improvement after an upgrade is not high enough to balance out the mentioned cost. To test if this assumption is true, we simulated the new architecture in four additional scenarios as an extension to the presented scenarios above. Each ’increase’ scenario increases the ONOS availability, by decreasing the ONOS software failure rate of the upgrades by (2 + (increasenumber 1) 6)%. This is done to see, how much the upgrades need to improve the ONOS availability before we can balance out the cost of an upgrade. All decrease percentages are listed in Table 2.
The results can be seen on the right side in Figure 8. We do not further explain the difference between the ’increase1’ and the basic new architecture results since their difference is negligible10. We can observe, that with increasing ONOS availability, the results come closer to the ’no upgrade’ scenario and even can surpass it with ’increase3’ and ’increase4’. So if our assumed ONOS software failure rates would decrease significantly of about the value of ’increase3’ in Table 2 or more, the cluster availability would benefit from upgrades. In other words, the ONOS software failure rate would be needed to decrease around 23% for the first, 33% for the second and 41% for the fourth upgrade when compared to the v1 software failure rate to balance the overhead. An overview of the default and needed software failure rates and their decreases in percent can be found within Section A.2 in Table A.2. Different Atomix and ONOS counts are set in our next deployment scenarios. The combinations of the two counts are arbitrarily set.
The results can be seen in Figure 9. Scenarios that deploy the old architecture are named like <onoscount>’o’ and the new architecture deployments are named like <onoscount><atomixcount>’n’. We also will use the term of the ’consensus instances’, by which we mean ONOS instances in the old and Atomix instances in the new architecture. We are creating this term as it shortens the explanation, and they respectively are the basis for the consensus status.
Interesting to see, is that the consensus instance count mainly influences the cluster availability, to observe between 23n and 57n as they are sorted by the second number. With one exception to 29n which has a very high consensus instance count, but with a very low ONOS count which we assume diminishes the availability, because the cluster is close to unavailability with just two ONOS instances. Especially during an upgrade, with reference to Section 6.2.
Although this work only looks at the availability a deployment can offer and does not consider for example load on the instances or operational costs, we want to point out, that an availability beyond 99,999% is achieved in the old architecture with fewer instances than in the new architecture. To reach this availability, the old architectures needs at least five ONOS instances, while the new architecture needs at least three ONOS and five Atomix instances. This result could be interesting for future work, e.g. if this is still true once the model considers load on the instances or the availability is put into context with operational costs. The new architecture within ONOS v1.14 or newer, should especially be considered in deployments with lower hardware and link availability as shown in Section 6.1. Especially if the hardware’s reliability or maintenance is worse than what we assumed in Section 4.3. This is important as it could mean in this case to increase unavailability within a year from 26 minutes (99,995%) to 657 minutes (99,875%)11.
That the new architecture performs better in terms of availability than the old
architecture can also be seen in Section 6.2 in our upgrade and deployment scenarios. In our upgrade
scenarios we could observe that the upgrade comes with an availability cost. So operators of
ONOS in the new architecture should not update every release but pick the ones that are
needed, when viewed from the availability point of view. With reference to [
When we looked at the instance counts, we could see that for the old architecture at least five ONOS instances should be deployed. In the new architecture the operator should deploy at least five instances of Atomix and at least three instances of ONOS from an availability point of view. In these deployments, both architectures can reach a cluster availability beyond 99,999%.
So, to answer our research question which architecture has a higher cluster steady state availability, we strongly recommend ONOS v1.14 or newer with the new architecture over ONOS v1.13 and older with the old architecture. Especially in environments with worse hardware or link availability than we assumed. The higher availability of the new architecture in these environments does mainly come from the increased count of links and hardware nodes. And so its higher tolerance towards single failures of such elements. 7
In this work we presented and evaluated the research question, if the additional complexity in the new architecture harms the overall availability and if so, if this is only the case in certain scenarios.
This research question was formulated and reasoned in Section 4. In this section we also defined our model elements. Our GSPN model was then validated in Section 5, with emphasis on the results of automated simulations. With them, we could show, that no parameter overwhelmingly influences the results. And we explained that these are plausible. Although some results were counterintuitive at first sight, they could be reasoned. In Section 6 we took once more a look at the results of simulations and could observe that the new architecture performs better than the old architecture in terms of availability. This was confirmed with specific deployment scenarios. The section was concluded with, besides others, recommendations for ONOS deployments. Even though, the fact that the new architecture can be easily upgraded, was not the main factor for the availability gain over the old architecture in our model. This was foreshadowed in the counterintuitive results in Section 6 mentioned above. The availability gain over the old architecture is based upon the addition of new hardware nodes and especially links. Single hardware or link failures can be much easier tolerated as the cluster has a higher replication degree.
We conclude this work, with a clear recommendation for the new ONOS architecture in ONOS version 1.14 and onwards.
Our work can be extended in multiple ways. One idea is to create a more realistic model, e.g. include load dependent reliability into the model or include a more sophisticated network partitioning. Additional ideas can be found in Sections 4.2 and 6.2. Here we want to remind the reader, that some of our rates, as explained in Section 4.3, are based upon older literature 11 Calculated with (1 availability) 365 24 60. or are guessed. So our results should be taken with a grain of salt. Further specific and reliable rates are needed for future work for more realistic performance analyzations.
When the model becomes more complex, a switch from GSPN to Stochastic Well-Formed
nets, may help to improve the models readability and maintainability. Additionally, one could
think about creating a hierarchical model like done in [
In the appendix we present additional information that may interest readers. We explain further information of the stacked failure extension in Section A.1, ONOS software failure rates to surpass the ’no upgrade’ scenario from Section 6.2 in Section A.2, and the full GSPN model in Section A.3.
A.1
To model stacked failures, we need to consider the dependencies the have between each other. For a start, any failure (software, hardware, network partition) can happen on top of any other, with one exception. Software failures are overwritten by a hardware failure, as a software cannot be executed on top of failed hardware. This can be seen in Figure 10. To improve readability, the failure transitions are horizontal and the recovery transitions are immediate and vertical. This has no semantic meaning.
This becomes more complex if we want to incorporate that into the presented model, we need to keep track which instance has currently which failures, to make sure it is recovered the correct way. For example a partitioned node with a software failure, must recover both before that instance is up again. Especially for ONOS, this would drastically increase the amount of transitions and places, as we have to model each specific failure scenario for each version.
With reference to Section 6.2, we now list the needed ONOS software failure rate for each version, so our model could benefit from upgrades in terms of availability. These numbers are based upon our parameters described in Section 4.3. In Figure 11 we added the full GSPN model, so that one can better understand how the squares are connected.
Version
Calculated: Based upon logarithmic trend from Excel: f (x) = 0; 005386747003005 ln(x) + 0; 017517342986504
Fig. 11. Our model in GSPN and GreatSPN