Question

Difficulty: Very hardHigh-Performing and Scalable Storage Solutions

A financial analytics firm runs a distributed risk-modeling application across a fleet of 80 Linux-based Amazon EC2 instances. The application requires a shared, POSIX-compliant file system with sub-millisecond latencies, capable of handling an aggregate throughput of up to 40 GB/s40 \text{ GB/s} and 100,000 IOPS100,000 \text{ IOPS} during peak execution. The data set is updated periodically from an Amazon S3 bucket, and the storage must support automatic replication across multiple Availability Zones to ensure high availability. Which combination of storage solutions and configurations should a solutions architect recommend to meet these requirements? (Select TWO.)

  1. Deploy an Amazon FSx for NetApp ONTAP Multi-AZ scale-out file system with multiple High Availability (HA) pairs to scale aggregate throughput and IOPS.Answer
  2. Mount the shared file system on the EC2 instances using the NFS protocol with the nconnect mount option configured to parallelize TCP connections.Answer
  3. C
    Provision an Amazon EBS io2 Block Express volume with Multi-Attach enabled, and format it with a cluster file system to share it across all 80 instances across multiple Availability Zones.
  4. D
    Deploy an Amazon FSx for Lustre scratch file system with a data repository association to Amazon S3, utilizing the Lustre Multi-AZ deployment configuration to automatically replicate files.
  5. E
    Create an Amazon EFS file system configured in Provisioned Throughput mode with EFS Multi-Mount enabled to share block-level volumes across the EC2 instances.

Answer

Deploy an Amazon FSx for NetApp ONTAP Multi-AZ scale-out file system with multiple High Availability (HA) pairs, and mount it using the NFS protocol with the nconnect option enabled.
Deploying an Amazon FSx for NetApp ONTAP Multi-AZ scale-out file system with multiple High Availability (HA) pairs provides a POSIX-compliant, sub-millisecond latency shared file system that scales up to 72 GB/s72 \text{ GB/s} of throughput and 1.6 million1.6 \text{ million} IOPS. Mounting the file system on the Linux EC2 instances using the NFS protocol with the nconnect mount option enables parallelized TCP connections per instance, allowing the fleet to bypass single-connection performance bottlenecks and scale to the required 40 GB/s40 \text{ GB/s} aggregate throughput.

Step-by-Step Solution

1
Analyze latency and interface requirements
The application requires a POSIX-compliant shared file system with sub-millisecond latencies, which points to file systems supporting NFS/SMB protocols (such as Amazon EFS or Amazon FSx).
EBS Multi-Attach requires cluster-aware block storage configurations and is restricted to a single Availability Zone, making it unsuitable for multi-AZ shared file access.
2
Evaluate throughput and IOPS scale
The peak performance requirement is 40 GB/s40 \text{ GB/s} throughput and 100,000 IOPS100,000 \text{ IOPS}. Amazon EFS has a peak throughput limit of 30 GB/s30 \text{ GB/s} for reads and 3 GB/s3 \text{ GB/s} for writes, which is insufficient. Amazon FSx for Lustre supports high throughput but is limited to Single-AZ deployments.
Eliminating solutions that cannot meet either the aggregate throughput limit or the Multi-AZ requirements narrows the choice to Amazon FSx for NetApp ONTAP, which scales up to 72 GB/s72 \text{ GB/s} and 1.6 million1.6 \text{ million} IOPS using scale-out HA pairs.
3
Select configuration options to scale single-instance and aggregate performance
To deliver 40 GB/s40 \text{ GB/s} across 80 instances, client network connections must be optimized. The NFS nconnect mount option must be enabled on the client EC2 instances to open multiple TCP connections per instance.
Single TCP connections are restricted in network throughput. Parallelizing TCP connections via nconnect is a standard practice to maximize data transfer rates to Amazon FSx for NetApp ONTAP.

Key Concept

High-throughput and low-latency shared storage architectures on AWS using Amazon FSx for NetApp ONTAP with client-side performance optimizations.
Estimated Time:3m 0s
Rate this question