High Availability and Disaster Recovery
Flowgear uses dedicated virtual infrastructure for each subscription and offers plan- and region-dependent resilience and disaster-recovery options. Exact topology, recovery objectives, storage replication, network addresses, and failover procedures are deployment-specific. Confirm them with Flowgear before relying on them in a continuity plan.
Some subscription plans include a secondary region for disaster recovery. Depending on the plan, this can be cold standby, where secondary compute starts during failover, or hot failover, where it is already running. Confirm which arrangement is provisioned for your subscription before testing or relying on the secondary region.
Tenant routing and regional sign-in
Azure Traffic Manager provides DNS-based failover, directing the Tenant hostname to the available region according to the subscription's configured recovery mode. For a Tenant key of testcorp, the usual hostname, testcorp.flowgear.net, resolves to either p-testcorp.flowgear.net or s-testcorp.flowgear.net.
Health probes check that the Tenant is responsive. Failover occurs when the Tenant remains unresponsive for an extended period, rather than immediately after a single failed request.
| Tenant value at Console sign-in | Endpoint | Purpose |
|---|---|---|
testcorp |
https://testcorp.flowgear.net |
Follow the Tenant's normal DNS-based regional routing. |
p-testcorp |
https://p-testcorp.flowgear.net |
Connect explicitly to the provisioned primary region. |
s-testcorp |
https://s-testcorp.flowgear.net |
Connect explicitly to the provisioned secondary region. |
To inspect or manage a particular region, enter its prefixed key in the Tenant field when signing in to the Console, then complete sign-in as usual. For example, use s-testcorp to check secondary-region hosts. The regional endpoint must be available: a cold-standby region may not accept connections until its compute has started.
The prefixes identify the provisioned regions. During failover, the secondary region can take the active primary role. Signing in with p-testcorp or s-testcorp directs your Console connection; it does not change DNS routing or select which region the platform recognizes as primary. Return to the unprefixed Tenant key when you want your connection to follow normal routing again.
Data and credential availability
Tenant data, protected credentials, and logs have their own resilience arrangements, separate from the number of compute hosts in your plan. The standard provisioning configuration provides the following protection; confirm any deployment-specific variations with Flowgear.
| Data | Availability and recovery |
|---|---|
| Tenant data | Multiple copies are maintained in the primary region, with replication to a separate paired region. The secondary copy supports read access, but cross-region replication is asynchronous, so it can lag behind recent writes. Recovery of write access is a separate part of restoring service. |
| Protected credentials and certificates | Managed replication maintains copies within the region and across availability zones where supported. Supported paired regions also provide cross-region replication and provider-managed recovery. Regional recovery can take longer than Tenant routing failover, and access to existing values can recover before updates to them are available. |
| Logs | Each provisioned region has separate log storage with multiple local copies. Logs do not have the same cross-region replication configuration as Tenant data, so verify the availability of each region's logs during recovery. |
Replication protects against infrastructure failure; backups and revision recovery address changes or deletions that also propagate to replicas. A regional outage can affect compute, data access, and credentials differently. Verify all three during a recovery exercise, and reconcile recent business operations because asynchronous replication does not guarantee that every last write survives a regional failure.
Automatic Workflow operation
Flowgear uses known host health to determine the active primary region. Automatic Workflow activation is managed only by that region: Always On for the v1 Runtime, and enabled published schedule and listener Workflows for the v2 Runtime. Connecting explicitly to the other region does not start a second set of automatic Workflows there.
After a failure or recovery, allow time for host health and automatic Workflow operation to converge. Check the expected Workflows and external side effects before treating recovery as complete. Regional routing and automatic activation are separate parts of recovery; successful Console sign-in alone does not prove that scheduled or listening Workflows are operating.
Runtime-specific recovery
Workflow execution and private-network recovery procedures depend on the runtime:
- v1 Runtime High Availability and Disaster Recovery
- v2 Runtime High Availability and Disaster Recovery
For either runtime, test Environment hostnames, authorization, provider reachability, revision recovery, logs, and business reconciliation under a controlled plan. Reconfirm subscription and regional details before every exercise.