Absorbing Analysis of a One-Out-of-Three Cold-Warm Standby Cloud Server System with Repairable Switch

2.1 Three-tier redundancy structure

The CSS consists of one fully operational primary tier (a), one partially energized warm standby (b), and one entirely de-powered cold standby (c) that remains inactive until activation. Table 1 encapsulates the qualitative characteristics, while the DTMC delineates the quantitative dynamics presented in Section 3.

Table 1. Comparison of cloud server tiers

2.2 Modelling assumptions

A1. Failure independence – The failure time of every hardware entity (a, b, c, switch s) is statistically independent.

Justification: Physical separation and independent power feeds are mandatory in Tier-III/IV data centers [1, 16, 17].

A2. Constant failure rate – The failure rates of each entity are λ, ε, β, and q for a, b, c, and s, respectively.

Justification: Allows constant transition probabilities over one discrete step; consistent with references [1, 7, 9, 17].

A3. Optimal fault detection – The switch s is notified immediately when the currently active unit fails.

Justification: Dual watchdog timers and heartbeat mechanisms achieve detection coverage above 99.98% in modern platforms [8, 18].

A4. Sequential failover – In the event of the active unit's failure, the system attempts to promote unit b; activation of unit c occurs just if unit b is inaccessible [8].

Justification: Matches the BIOS/firmware logic implemented by major OEMs (Dell, HPE, Supermicro).

A5. Repairable switch, non-repairable servers throughout the operations – The switch is repaired at a constant rate p (discrete-time probability p per step); servers a, b, and c remain unrepaired due to the focus on a "no-repair window" induced by exogenous calamities [1].

Justification: Aligns with disaster-recovery literature [19] and differentiates the present work from ergodic models.

A6. Absorbing catastrophe – The system attains an absorbing state (irreversible total failure) if either

(i) all three servers, a, b, and c, are down;

(ii) the switch s is failed when a promotion is necessary.

Justification: Captures both resource-exhaustion and switch-over failure modes identified in studies [10, 18].

A7. Unitary time step – A single discrete step equates to the total of the mean detection delay, mean switch latency, and mean VM resume latency, approximately 1 minute in enterprise clouds [13]. All transition probabilities are contingent upon this step length.

2.3 Transition-probability constraints and normalization

Let the step length be Δ = 1 min. For any transient state i, the sum of one-step departure probabilities must equal 1. Consequently, for each row i of the transition matrix P:

$\sum_j P_{i j}=1$ and $P_{i i}=1-\sum_{j \neq i} P_{i j} \forall i \in Transient$

The expressions quoted in the original manuscript are the self-loop probabilities that guarantee the above normalization. For example, the first row (State 1: an active, b and c standby, s operational) satisfies:

$P_{11}=1-(\mathrm{q}+\varepsilon+\lambda)$, with $\mathrm{q}+\varepsilon+\lambda<1$

Analogous inequalities apply to every row; they are not global parameter constraints but simply ensure that the diagonal element remains a valid probability. Violating any inequality would imply that the total exit probability in one minute exceeds 1, an obvious modelling inconsistency.

Based on assumptions A1 through A7, Figure 1 illustrates the system's Markov transition diagram, and the associated transition rate matrix P is delineated (refer to the Appendix).

Using a Discrete-Time Markov Chain (DTMC) model with 17 states (12 transient, 5 absorbing), we analyze system behavior through key reliability metrics: AP, MTTA, time-to-failure distribution via Monte Carlo simulation, and time-dependent reliability. All numerical computations were performed in MATLAB using a constructed transition probability matrix based on assumed failure rates: λ = 0.1197, β = 0.0542, and ε = 0.3 for primary, cold, and warm units, respectively, and a repairable switch with a failure rate q = 0.1 and repair rates p = 0.5. This section presents refined interpretations of the results, focusing on behavioural patterns, risk profiles, and design implications.

4.1 AP – patterns, clusters, and design influence

The absorption probability matrix (Table 2) and Figure 3 indicate a significant convergence toward Absorbing State 13, which corresponds to complete system failure due to cascading unit failures with a non-functional switch. Across all transient states, this state dominates the long-term failure landscape, capturing between 55% and 89% of all absorption pathways. Notably, States 1, 4, 5, 7, 10, 11, and 15 exhibit AP into State 13 exceeding 70%, indicating that once the system enters these configurations—typically involving partial degradation and switch stress—it is highly likely to progress irreversibly toward total collapse.

A cluster analysis of transient states based on absorption profiles identifies three distinct behavioral groups:

Group A (High Risk to State 13): For States 1, 4, 5, 7, 10, and 11, the row-averaged switch-utilization intensity λ/(λ + ε + q) ≥ 0.68 and the absorption probability into State 13 ranges from 72% to 89%.

Group B (Moderate Switch-Dependent Risk): States 6, 8 and 12 exhibit a joint exit-rate ratio ε/(ε + q) ≈ 0.75, so roughly three-quarters of their outgoing trajectories land in State 9 (switch-only failure) or State 17 (cold-unit failure) rather than the dominant State 13.

Group C (Low Probability Absorption Targets): States 3, 14, 15, 16 — These are rarely reached or have minimal contribution to final absorption, particularly States 3 and 16, which maintain consistently low absorption weights (< 5%). This implies they are either transiently visited or represent less probable failure sequences.

Design Implication: The overwhelming dominance of State 13 highlights that switch reliability is the single most critical factor in preventing total system failure. For cloud administrators, this means:

Prioritizing redundant or hardened switching mechanisms, implementing predictive diagnostics for switch degradation, and triggering proactive failover protocols before prolonged warm-standby engagement occurs.

System architects should treat the switch not merely as a control component but as a mission-critical element whose failure mode dictates overall system survivability.

3.jpg

Figure 3. APs from each transient state to each absorbing state

Table 2. APs from each transient state to each absorbing state

Note: transient state (TS); absorbing state (AS).

4.2 MTTA: Operational resilience and maintenance planning

The MTTA computed via the fundamental matrix N, Eq. (2) quantifies the expected duration before system collapse from any given transient state (see Table 3 and Figure 4).

Table 3. MTTA for transient states

4.jpg

Figure 4. MTTA for transient states

Two states stand out: State 1 (initial operational) and State 4 (primary failed, warm active, switch functional), with MTTAs of 24.45 and 24.24 minutes, respectively—significantly higher than others.

In contrast, States 11 and 14 exhibit the shortest MTTAs (3.33 min), indicating rapid progression to failure. State 11 involves cold-unit activation with switch instability, while State 14 reflects dual-unit degradation under switch strain—both are high-risk configurations requiring immediate intervention.

Practical interpretation for system designers:

1. Long MTTA ≠ high reliability alone: while States 1 and 4 offer extended windows, their eventual absorption into State 13 at high probability suggests resilience without sustainability. Thus, long MTTA must be paired with active recovery mechanisms to avoid inevitable collapse.
2.  Maintenance scheduling: following Rausand and Hoyland [1], inspection intervals should be ≤ 0.2 × MTTA to detect drift before absorption; hence, systems entering State 14 demand ≤ 40 s diagnostic action, whereas State 6 (≈ 21 min) tolerates ≈ 4 min response latency.
3. Graceful-degradation pathways: designers can use MTTA heat-maps to construct fallback sequences that navigate the system through high-MTTA transient states, optimizing emergency response time.

These insights enable risk-aware orchestration policies in cloud-management platforms, where automation decisions are conditioned on the current Markov state and predicted absorption timelines.

4.3 Monte Carlo estimation of absorption time: stochastic behavior and risk mitigation

To capture the stochastic nature of failure propagation, we ran 1,000 independent discrete-time trajectories starting from State 1, advancing at each step according to the embedded DTMC. Transitions were sampled by inverse-transform: draw U ~ Uniform (0,1) and compare with the cumulative row of the transition matrix. No fixed seed was used (MATLAB Mersenne-Twister reinitialized from the system clock on every run) to guarantee statistical independence; reproducibility is nevertheless ensured by archiving the script and parameter set.

The empirical histogram of absorption times (Figure 5) is right-skewed: mode 5–10 min, median 14 min, mean 20.3 min. The heavy tail shows that 10% of paths survive beyond 40 min—a direct input for service-level agreements: “Under the defined disaster scenario, we guarantee with 90% confidence that the system will either be fully restored or will have failed within 40 minutes”.

5.jpg

Figure 5. Monte Carlo simulation of absorption time for the DTMC starting from State 1

The histogram effectively visualizes the density of failure occurrences over time, enabling administrators to estimate:

1. The peak-risk window (first 15 min).
2. The tail probability for the Service-Level Agreement (SLA) wording above.
3. Contingency staffing—extra on-call engineers scheduled during the 5–15 min peak.

Risk mitigation insights:

1. The skewness implies that reliability cannot be assessed solely by average performance. A small fraction of systems may survive much longer, offering opportunities for emergency patching or migration (do not plan only for the average 20 min; keep warm spares ready for ≤ 15 min).
2. To reduce tail risk, operators should implement dynamic redundancy reconfiguration upon detection of early degradation signs (e.g., promote cold unit immediately when switch-health warning appears—this trims the upper 10% tail to ≈ 3% in follow-up runs).
3. The simulation supports SLA modeling, allowing estimation of probabilistic uptime guarantees under disaster conditions (Embed the 40-min / 90% figure in the disaster-recovery SLA; the Monte-Carlo histogram supplies the audited numeric evidence).

4.4 Reliability over time: temporal decay and operational risk assessment

System reliability R(t) (probability of remaining in transient (non-absorbing) states at time t), is computed via $R(t)=\pi_0 Q^t \mathbf{1}$, where, $\pi_0$ is the initial state vector. Figure 6 shows per-state curves, and Figure 2 gives the temporal panorama.

State 14 exhibits the highest initial reliability yet steepest decay; dropping below 0.3 by t = 15 min—an apparent contradiction that arises because State 14 is a high-stress transitional phase (cold unit active, switch impaired): temporary resilience but no sustainability.

In contrast, States 11 and 12 maintain flatter profiles (≈ 0.55 at t = 15 min), signaling superior long-term robustness despite lower initial values.

Operational-risk threshold: We adopt R(t) < 0.5 as the point of unacceptable vulnerability. Under this criterion:

1. State 14 crosses 0.5 at t ≈ 8 min,
2. State 8 fails by t = 12 min,
3. Whereas States 1 and 4 remain above 0.5 until t = 22 min, confirming their role as stable operating baselines.

Cumulative reliability (total operational expectancy) is computed as:

$C R=\int_0^{\infty} R(t) d t \approx \sum_{k=0}^{\infty} R(k \Delta t) \Delta t(\Delta t=1 \min )$

States 1 and 4 lead in CR, reinforcing their suitability during crisis stabilization.

Recommendation for Administrators:

1. States exhibiting high initial reliability yet steep decay (e.g., State 14) should be evacuated within 5 min to maintain SLA compliance.
2. Use real-time telemetry to detect entry into R(t) < 0.55 states and trigger automated recovery actions (e.g., virtual machine migration, external switch reroutes).
3. Incorporate state-dependent reliability models into cloud orchestration engines to dynamically adjust workload distribution and failure response priorities.

6.jpg

Figure 6. System reliability over time for each transient state

This comprehensive analysis demonstrates that system resilience is not determined by individual component reliability alone, but by the interaction between redundancy architecture, switch integrity, and dynamic state evolution. By leveraging DTMC-based metrics, cloud operators can move beyond static redundancy planning toward adaptive, state-aware reliability management—critical for mission-critical infrastructures facing extreme disruptions.