Combined availability and redundancy

This page explains how RANCAQ calculates the availability of a CI or service from its components, and how to model components that replace each other (redundancy). Everything here is visible only to users with the View assets permission; redundancy groups can be changed only with Manage assets.

Measured and calculated

RANCAQ distinguishes two kinds of figures and always labels them differently:

A calculated figure never replaces a measured one. When a service has a reference monitor, the measured figure remains the service's official figure; the calculated figure helps explain where outages come from and how fragile the setup is.

Structure models and their formulas

The examples below use per-component availability to explain the intuition.

Series — everything must be up

An application runs on a VM, the VM runs on a host, the host needs a switch. If any of them fails, the application is unavailable.

Textbook formula: A = A₁ × A₂ × A₃. Three components at 99% each → 99% × 99% × 99% ≈ 97.0%. The longer the chain, the lower the total.

Parallel — one is enough

Two internet links: the office stays connected as long as either is up.

Textbook formula: A = 1 − (1 − A₁)(1 − A₂). Two links at 99% → 1 − 0.01 × 0.01 = 99.99%.

At least N of M

Three servers behind a load balancer, and the load is only handled when at least two are up. Series is the "M of M" case, parallel is "1 of M".

Cluster

For service-level redundancy, create one cluster asset (e.g. "Web Cluster"), link the members as its dependencies in one redundancy group, and make the cluster a component of the service.

How RANCAQ calculates: timelines, not multiplication

The formulas above are only correct when component outages never happen at the same time. In reality they often do — a power cut takes down the switch and the server in the same hour. Multiplication counts that outage twice, so the figure is too low; for two links that fail together, the parallel formula is too high.

RANCAQ therefore calculates moment by moment from the actual monitor history:

1. For every moment in the period, each component's state is read from its monitors: available, unavailable, or unknown (no data).
2. A CI's state = its own monitors' state and the state of all its dependencies at that moment (series), except dependencies grouped in a redundancy group: the group is satisfied when at least N members are available.
3. Availability = available time ÷ (available + unavailable time). Time without data is left out of the denominator but lowers coverage.

Example: a 10-hour period. The application and the database both fail from hour 1 to 2 due to a power cut. Multiplication would give 90% × 90% = 81%; RANCAQ gives 90%, because the application was only unavailable for one hour.

When outages never overlap, RANCAQ's result equals the multiplication formula.

Combined availability card (asset detail)

The card shows several viewpoints for the last 30 days, 7 days, this month, or last month (workspace time zone, 24×7):

• This asset only (measured) — from the asset's own monitors. With several monitors, the asset is unavailable when any of them is.
• Including dependencies (calculated) — this asset and everything it needs, at all levels.
• Possible range — when there is time without data: the lower bound if all of it was down, the upper bound if all of it was up.
• Outage contributors — components that were unavailable at the same time as this asset, and for how long.
• No data — monitored components that sent no data while the result could not be determined, and for how long. This is what lowers coverage or causes "not enough data"; check their monitor senders.
• Single points of failure — components whose failure alone makes this asset unavailable. Components inside a redundancy group are excluded unless the group requires every member.
• Not monitored — components without an active monitor. They are assumed always available so the calculation stays useful while the CMDB is only partly monitored; their number and names are always shown. Add monitors for a more honest figure.

What counts as a dependency is the same as the Upstream part of the relationship tree: "depends on", "runs on", and its container ("part of"). "Connected to" relations are not counted.

Component tree in Monitoring

From Monitoring → Overview (the Tree button in each monitor's Components column) and Monitoring → Service level (the Tree button in the Calculated column), you can open the component tree without leaving the page:

• The tree is the same as the Upstream part of the asset detail relation tree; for a service, it starts from the service's component assets and what they depend on.
• Every asset shows its current monitor status (Up, Down, No data, or not monitored). Status is never inherited from dependencies.
• When figures are available, every asset also shows its own availability (measured) and availability with dependencies (calculated) for the selected period. On Service level, the period follows the report period.
• Branches leading to a Down asset are already expanded when the dialog opens, and collapsed branches say how many down assets they contain, so the asset that brings a service or CI down is visible right away.

Redundancy groups

The Redundancy groups card on the asset detail page groups direct dependencies that replace each other:

1. Make sure the asset has at least two direct dependencies ("depends on" or "runs on").
2. Click Add group, name it (e.g. "Internet links"), tick its members, and choose Minimum up (e.g. 1 of 2).
3. Save. The Combined availability card is recalculated right away.

Dependencies outside a group are all required. One relation can belong to only one group. If members are removed so fewer remain than the minimum, the group is flagged and all remaining members are treated as required. Every group change is recorded in the audit log.

Limitations

• The calculation uses current relations and groups; relation changes during the period are not reconstructed.
• Maintenance windows are not excluded yet.
• Tracing stops at 10 levels or 500 components; components beyond that are assumed available and the card says so.
• Looping relations are ignored at the point where they loop back, and the card says so.