Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Centralize shared storage: Amazon FSx for OpenZFS Multi-AZ file systems in shared VPCs

6 minute read
Content level: Advanced
0

Semiconductor and high-tech organizations centralize EDA/design storage in a shared-services network account while many design-team accounts consume it. Multi-AZ FSx for OpenZFS in a shared VPC delivers highly available design storage under centralized network governance. Typical uses:

  • Centralized EDA/design-data storage shared across design-team accounts
  • Highly available home/scratch filesystem for verification and simulation users
  • Consolidated network governance for IP-sensitive storage

Overview

Amazon FSx for OpenZFS Multi-AZ deployments run an active and standby file server in two Availability Zones and fail over automatically during planned maintenance or a failure of the active server or its AZ. (Amazon FSx for OpenZFS documentation overview) You can now create these Multi-AZ file systems in shared VPC subnets, so a central networking account owns the VPC while participant accounts consume storage — a common pattern for multi-account organizations centralizing network management.

How shared-VPC Multi-AZ works

The VPC owner controls it. "Owner accounts can manage whether or not participant accounts can create Multi-AZ FSx for OpenZFS file systems in VPC subnets that the owner has shared with participants." This setting must be enabled by the account that owns the VPC; if you're a participant and need it, ask the VPC owner to enable it under their FSx settings. (Creating an Amazon FSx for OpenZFS file system — Shared VPC settings for Multi-AZ)

Floating endpoint IPs handle failover. NFS endpoints on Multi-AZ file systems use floating IP addresses so clients transition seamlessly between the preferred and standby file servers during failover. By default the FSx API selects a /28 (16 addresses) from the VPC CIDR for these floating IPs; you can optionally specify the endpoint IP range and the VPC route tables used for routing. (Accessing your data within the AWS Cloud)

Cross-VPC access requires Transit Gateway. "Only AWS Transit Gateway supports routing to floating IP addresses, which is also known as transitive peering. VPC Peering, Direct Connect, and Site-to-Site VPN don't support transitive peering." So to reach a Multi-AZ file system from outside its VPC, you must use Transit Gateway. (Accessing your data within the AWS Cloud)

How this improves resilience

A Multi-AZ FSx for OpenZFS file system is an HA pair — a preferred (active) file server and a standby in a second Availability Zone, with data replicated across the two AZs and automatic failover/failback. Delivering it from a shared VPC extends that resilience to every consuming account without each team rebuilding HA storage of its own.

  • Automatic cross-AZ failover. The file system fails over from the preferred to the standby server when the preferred server becomes unavailable, when throughput capacity is changed, during planned maintenance, and — for Multi-AZ — on an Availability Zone disruption. "A failover typically takes less than 60 seconds from the detection of the failure on the active file server to the promotion of the standby file server to active status." (Availability and durability for FSx for OpenZFS)
  • Automatic failback. When the preferred server recovers, "Amazon FSx automatically fails back to it, usually in less than 60 seconds" — no manual intervention. (Availability and durability doc)
  • Cross-AZ data durability. Multi-AZ (HA) file systems replicate your data across the two AZs "with a separate copy of your data in each Availability Zone," so data survives an AZ-wide disruption. (What is Amazon FSx for OpenZFS?)
  • Transparent to clients. The floating endpoint IP means "clients automatically fail over and back with the file system"; the route to the active server is updated automatically on failover, giving transparent continuity of service. (FSx for OpenZFS FAQs)
  • Self-healing infrastructure. FSx "continuously monitors for hardware failures, and automatically replaces infrastructure components in the event of a failure." (FSx for OpenZFS FAQs)
  • Layered protection. Independent of the HA pair, FSx takes highly durable daily backups to Amazon S3 (with on-demand backups any time), which you can also copy across Regions for DR. (FSx for OpenZFS FAQs)
  • Rehearsable. You can test failover by modifying the file system's throughput capacity, which sequentially switches out the file servers — a safe way to validate your application's behavior. (Availability and durability doc)

Why the shared-VPC pattern strengthens this. Centralizing the HA file system in an owner-governed VPC means participant/design-team accounts inherit AZ-fault tolerance and a consistent endpoint/route-table configuration instead of each team implementing HA storage differently. It also concentrates the one operational detail that most affects failover availability — complete VPC route-table association with the file system, which "helps prevent loss of availability during a failover" — under the network owner's control. (Accessing your data within the AWS Cloud)

Design note: during failover and failback "I/O might be briefly paused and Amazon CloudWatch metrics might be temporarily unavailable" — build client retry/timeout handling so applications ride through the sub-minute transition. (Availability and durability doc)

Architecture at a glance

multi-az-shared-vpc

Diagram summarizes facts cited above (owner-enabled setting, floating endpoint IP, Transit-Gateway-only routing to floating IPs).

Reference pattern

  1. Owner account shares subnets in ≥2 AZs via AWS RAM and enables the "create Multi-AZ FSx" setting in its FSx settings.
  2. Participant account creates the Multi-AZ FSx for OpenZFS file system into the shared subnets, choosing an endpoint IP range within the VPC CIDR that doesn't overlap subnet CIDRs.
  3. For clients in other VPCs, attach the file system's VPC to Transit Gateway and configure routing to the floating endpoint IPs.
  4. Associate all relevant route tables with the file system — this "helps prevent loss of availability during a failover." (Accessing your data within the AWS Cloud)

Best practices

  • Plan the endpoint IP range up front. Keep it within the VPC CIDR and non-overlapping with subnets to let FSx manage routing automatically; ranges outside the VPC CIDR require extra Transit Gateway routing.
  • Standardize on Transit Gateway for cross-VPC/cross-account access. VPC peering, Direct Connect, and Site-to-Site VPN cannot route to the floating IPs.
  • Keep route-table associations complete. Missing associations can cause availability loss on failover.
  • Separate duties cleanly. Let the networking (owner) account own VPC/subnets/RAM sharing and the participant account own the file system lifecycle.
  • Validate failover. Test active→standby transitions and confirm clients reconnect via the floating endpoint transparently.
  • Handle the brief failover pause in clients. I/O may pause for the sub-minute failover/failback window — set NFS client retry/timeout so applications ride through it rather than erroring.

Resources

No comments

Relevant content