Software Architecture - Availability

Availability

  • Definition: Availability refers to a property of software that indicates it is present and operational to execute its designated tasks as required.

Reliability

  • Definition: The ability of an item to perform a required function under stated conditions for a specified period of time.

  • Characteristic expression: Expressed probabilistically as the likelihood that an item will perform its function under specified conditions for a designated time frame.

  • Source: According to IEEE Transactions on Reliability, V.19, N.4, Nov. 1970.

Interrelationship of Key Concepts

  • Availability

    • Can be defined as:

    • Availability = Reliability + Recovery

    • Recovery implies the system's ability to self-repair following a failure.

  • Dependability: Refers to the capacity to avoid failures that are unacceptably frequent or severe.

Detailed Availability

  • Cumulative Service Outage: Defines availability as the ability of a system to mask or repair faults so that total service outage does not exceed an acceptable threshold over a defined time interval.

  • Judgment Influence: Availability definitions require an understanding of failure as subject to interpretation by external agents, typically human assessors.

Further Relations

  • Security:

    • Availability shares a close relationship with security, particularly through denial-of-service (DoS) attacks which deliberately seek to render systems unavailable.

  • Performance:

    • Availability also correlates closely with performance because it can be challenging to distinguish between a system failure and suboptimal response times.

  • Safety:

    • Safety is allied with availability in relation to preventing hazardous system states and managing implications when failures transpire.

Faults and Failures

  • Fault Definition: A fault is identified as the underlying cause of a failure.

  • Types of Faults:

    • Can be internal (within the system) or external (outside influences).

  • Fault Management:

    • Faults can be:

    • Prevented

    • Tolerated

    • Removed

    • Forecasted

    • These capabilities contribute to a system's resilience against faults.

  • Key Concerns:

    • Detection of system faults.

    • Frequency of occurrences.

    • Post-fault occurrences, such as system downtime.

    • Safe fault occurrence procedures.

    • Prevention of faults.

    • Required notifications during failure events.

Availability Metrics

  • Steady-State Availability Formula:

    • The formula to derive steady-state availability is given by:
      A=MTBFMTBF+MTTRA = \frac{MTBF}{MTBF + MTTR}

    • MTBF: Mean Time Between Failures.

    • MTTR: Mean Time to Repair.

    • In a software context, understanding potential causes of failure, their probabilities, and repair timelines is essential.

  • Service-Level Agreements (SLAs):

    • Scheduled downtime does not count against availability requirements as outlined in SLAs.

Fault Detection and Correlation

  • Detection Prior to Reporting:

    • In operational systems, faults are internally detected and correlated before any reporting or repair occurs.

  • Fault Categorization:

    • Faults are characterized based on severity (e.g., critical, major, minor) and service impact (service-affecting vs non-service-affecting) to provide timely operator information on system status for effective repair strategies.

  • Repair Strategy:

    • May either be automated or necessitate manual intervention.

System Availability Requirements

  • High Availability Benchmark:

    • Generally targets availability of 99.999% (termed as “5 nines”) or higher.

    • Only unscheduled outages affect system downtime.

Planning for Failure

  • Inevitability of Failure:

    • Failure should be recognized as nearly inevitable, necessitating proactive planning to handle its occurrence effectively.

  • Understanding Failures:

    • Identify types and consequences of failures relevant to the system's context.

Techniques for Failure Analysis

  • Hazard Analysis:

    • Catalogs operational hazards and categorizes them by severity:

    • Catastrophic

    • Hazardous

    • Major

    • Minor

    • No effect

    • Examples from the aeronautical domain such as the DO-178B standard highlight these levels.

  • Fault Tree Analysis:

    • Analytical method to specify a detrimental state impacting safety or reliability and analyze fault causes.

  • FMECA: Failure Mode, Effects, and Criticality Analysis logs types of failures and evaluates their severe effects, using historical data from analogous systems.

Fault Tree Analysis Mechanics

  • Construction of Fault Trees:

    • Graphically portrays all sequential and parallel fault paths leading to an undesired state (the “top event”).

  • Gate Symbols:

    • Utilize Boolean logic diagrams to connect events within fault trees, facilitating fault identification and diagnosis during system operation.

  • Runtime Diagnostics:

    • Fault trees can aid real-time failure diagnosis, directing focus back to contributing faults for repair initiation.

FMECA Findings

  • Cataloging Failures:

    • FMECA provides insights into prevalent failure types via historical data, underscoring the need for a proactive approach in identifying potential issues.

  • Probabilities and Effects:

    • Historical data tables demonstrate the frequency of specific failures like short circuits or open circuits in systems.

General Scenarios for Availability

  • Factors Affecting Availability:

    • Various influences include:

    • Human errors

    • Hardware issues

    • Software flaws

    • Physical infrastructure challenges

    • Environmental conditions

  • Scenario Dynamics:

    • Availability can be measured through defined categories such as detection, recovery, and operational responses during faults or failures.

Tactics for Availability Assurance

  • Understanding Failures:

    • A failure indicates a system's incapacity to deliver consistent service as per specification. Faults comprising combinations can potentially lead to failures.

  • Availability Tactics Categories:

    • Fault Detection

    • Fault Recovery

    • Fault Prevention

  • Tactics Implementation:

    • Architectures may inherit these tactics from existing software infrastructures, placing a designer’s focus on selecting and appropriating the correct set of tactics.

Fault Detection Strategies

  • Detection Methods:

    • Various actions ensure fault identification, such as:

    • Ping/echo

    • Monitoring

    • Heartbeat signals

    • Time stamps

    • Sanity checks

    • Condition monitoring

    • Voting approaches (e.g., functional redundancy)

    • Exception detection strategies (e.g., parameters, timeouts)

    • Self-testing

Recovery Tactics Post-Fault

  • Preparation-and-Repair Tactics:

    • Focus on retry processes and the introduction of redundancies for fault recovery.

  • Reintroduction Tactics:

    • Address reintegration of a rehabilitated component into regular service.

  • Reintroduction Methods:

    • Include strategies such as shadowing, state resynchronization, escalating restart mechanisms, and Non-stop Forwarding (NSF).

Fault Prevention Strategies

  • Proactive Measures:

    • Focus on runtime strategies that circumvent fault occurrences through solid engineering practices.

  • Prevention Tactics:

    • Methods such as:

    • Removal from service

    • Transaction approaches

    • Predictive modeling

    • Exception prevention

    • Enhancement of competence sets

Design Checklist for Availability

  • Supporting Design Processes:

    • An availability checklist aids design and analysis activities critical for quality attributes.

  • Availability Checklist Examples:

    • A series of tables presents these checklists, although specific contents not provided here.