High availability

Overview

This article describes the high availability (HA) options for a Turbo360 private hosting instance. It covers App Service zone redundancy, SQL database zone redundancy, storage redundancy tiers, and the configuration steps required to achieve each level of availability. These configurations protect your Turbo360 instance against single-node failures, availability zone outages, and storage hardware failures.

Business value

High availability configuration reduces unplanned downtime caused by infrastructure failures that would otherwise take down the entire Turbo360 instance. Distributing compute and data resources across availability zones ensures that a single datacenter failure does not interrupt monitoring, cost analysis, or alerting operations.

Prerequisites

• A completed Turbo360 private deployment (see Deployment)
• A Premium tier App Service Plan (zone redundancy is not available on Standard tier)
• Contributor access to the Turbo360 resource group
• The target Azure region must support availability zones (not all regions do)

Required permissions

Dependencies

• Zone redundancy for App Service requires a Premium App Service Plan at a minimum of 3 instances. Single-instance plans cannot be made zone-redundant.
• Zone redundancy for SQL requires the Business Critical or Premium service tier.

How it works

Turbo360 private hosting achieves high availability through the native redundancy mechanisms of the underlying Azure resources:

• App Service zone redundancy: Instances of the Web App and Function Apps are distributed across availability zones in the region. If one zone fails, the remaining instances continue serving traffic.
• SQL zone redundancy: The SQL database uses synchronous replication across availability zones. A zone failure triggers automatic failover to a replica with no data loss and minimal downtime.
• Storage Account redundancy: Zone-redundant storage (ZRS or GZRS) replicates data synchronously across three availability zones. A zone failure does not interrupt storage operations.

Without zone redundancy, a single availability zone failure takes down the Turbo360 instance until Azure recovers the affected zone.

Configuration

App Service zone redundancy

Zone redundancy for App Service must be enabled at the App Service Plan level. It cannot be added to an existing plan; it requires redeployment.

Enable zone redundancy on a new App Service Plan:

1. In the Azure portal, navigate to App Service Plans > + Create.
2. Select the region and set the plan tier to Premium (P1v3 or higher).
3. Under Zone redundancy, select Enabled.
4. Set the instance count to 3 or more (minimum required for zone-redundant plans).
5. Complete the plan creation.
6. Move the Turbo360 Web App and Function Apps to the new plan.

SQL zone redundancy

Enable zone redundancy on an existing SQL database:

1. In the Azure portal, navigate to the SQL database.
2. Select Compute + storage under Settings.
3. Ensure the service tier is Premium or Business Critical.
4. Under Zone redundancy, toggle to Enabled.
5. Click Apply. This operation restarts the database and may cause a brief connection interruption (typically under 30 seconds for Business Critical tier).

Storage Account redundancy

Upgrade to ZRS or GZRS:

1. Navigate to the Storage Account in the Azure portal.
2. Select Redundancy under Data management.
3. Change the redundancy to ZRS (zone redundancy only) or GZRS (zone redundancy plus geo-redundancy).
4. Click Save. Data migration to ZRS/GZRS runs in the background and may take several hours for large storage accounts.

Example scenario

A platform engineer receives a requirement that Turbo360 must tolerate a single availability zone failure without downtime. They create a new Premium P2v3 App Service Plan with zone redundancy enabled and 3 instances, migrate the Web App and three Function Apps to the new plan, upgrade the SQL database from Standard to Premium tier with zone redundancy enabled, and change the Storage Account redundancy from LRS to ZRS. The instance now tolerates a single zone failure with automatic recovery and no manual intervention.

Limitations

• Zone redundancy for App Service cannot be enabled on an existing App Service Plan. A new zone-redundant plan must be created and resources migrated.
• Zone redundancy for SQL requires the Premium or Business Critical tier. Standard tier SQL does not support zone redundancy.
• Zone redundancy requires a minimum of three App Service instances. Scale-down below three instances disables zone redundancy guarantees.
• Not all Azure regions support availability zones. Verify zone availability for your deployment region in the Azure documentation before planning HA configuration.
• Zone-redundant configurations incur additional Azure costs compared to single-zone deployments (higher App Service Plan tier, additional SQL tier, ZRS storage pricing).
• Zone redundancy protects against a single zone failure. It does not protect against a full regional outage. For regional resilience, see Disaster recovery.

Troubleshooting

1. Zone redundancy toggle is not available in App Service Plan settings
   Cause: Zone redundancy cannot be enabled on an existing plan. It must be set at plan creation time.
   Fix: Create a new Premium App Service Plan with zone redundancy enabled during creation. Migrate the Web App and Function Apps to the new plan.

2. SQL zone redundancy option is greyed out
   Cause: The SQL database is on Standard tier, which does not support zone redundancy.
   Fix: Scale the SQL database to Premium or Business Critical tier in the Azure portal, then enable zone redundancy.

3. App Service Plan shows zone redundancy as enabled but only has 1 or 2 instances
   Cause: Instance count was not set to the required minimum of 3 at creation time.
   Fix: Scale the App Service Plan to 3 or more instances under Scale out (App Service plan) in the Azure portal.

4. Storage Account redundancy change to ZRS is taking longer than expected
   Cause: ZRS conversion migrates all stored data in the background. Duration depends on the amount of data in the account.
   Fix: This is expected behaviour. Monitor progress in the Azure portal under Storage Account > Redundancy. The account remains accessible during conversion.

5. Turbo360 is unresponsive after SQL zone redundancy is enabled
   Cause: Enabling zone redundancy triggers a brief database restart during which connections are interrupted.
   Fix: Wait 1–2 minutes for the database to come back online. The Web App and Function Apps reconnect automatically. If the application remains unresponsive after 5 minutes, restart the App Service resources.

FAQs

1. Does zone redundancy for App Service automatically scale instances across zones?
   Yes. When zone redundancy is enabled with 3 or more instances, Azure distributes the instances across the available zones in the region automatically. You do not need to pin instances to specific zones.

2. Can I enable zone redundancy after my initial deployment without downtime?
   For SQL, enabling zone redundancy on an existing Premium or Business Critical database causes only a brief (typically under 30-second) connection interruption. For App Service, zone redundancy requires creating a new plan and migrating resources, which involves brief restarts during migration.

3. What is the difference between zone redundancy and geo-redundancy?
   Zone redundancy protects against the failure of a single availability zone within a region. Geo-redundancy (GRS, GZRS) protects against a complete regional outage by replicating data to a secondary region. For full resilience, both are recommended. See Disaster recovery.

Related articles

• Disaster recovery
• Backup & recovery
• Environment health
• Infrastructure requirements
• Private hosting architecture