AWS-Solution-Architect-Associate Question: 1
A 3-tier e-commerce web application is current deployed on-premises and
will be migrated to AWS for greater scalability and elasticity The web
server currently shares read-only data using a network distributed file
system The app server tier uses a clustering mechanism for discovery and
shared session state that depends on IP multi cast The database tier
uses shared-storage clustering to provide database fall over capability,
and uses several read slaves for scaling Data on all servers and the
distributed file system directory is backed up weekly to off-site tapes.
Which AWS storage and database architecture meets the requirements of the application?
A. Web servers: store read-only data in S3, and copy from S3 to
root volume at boot time. App servers: share state using a combination
of Dynamo DB and IP uni cast. Database: use RDS with multi-AZ deployment
and one or more read replicas. Backup: web servers, app servers, and
database backed up weekly to Glacier using snapshots.
B. Web servers: store read-only data in an EC2 NFS server, mount
to each web server at boot time. App servers: s hare state using a
combination of Dynamo DB and IP multicast. Database: use RDS with multi-
AZ deployment and one or more Read Replicas. Backup: web and app
servers backed up weekly via AMIs, database backed up via DB snapshots.
C. Web servers: store read-only data in S3, and copy from S3 to
root volume at boot time. App servers: share state using a combination
of Dynamo DB and IP uni cast. Database: use RDS with multi-AZ deployment
and one or more Read Replicas. Backup: web and app servers backed up
weekly vi a AMIs, database backed up via DB snapshots.
D. Web servers: store read-only data in S3, and copy from S3 to
root volume at boot time. App servers: share state using a combination
of Dynamo DB and IP uni cast. Database: use RDS with multi-AZ
deployment. Backup: web and app servers backed up weekly via AMIs,
database backed up via DB snapshots.
Answers: A
Explanation:
Amazon RDS Multi-AZ deployments provide enhanced availability and
durability for Database (DB) Instances, making them a natural fit for
production database workloads. When you provision a Multi-AZ DB
Instance, Amazon RDS automatically creates a primary DB Instance and
synchronously replicates the data to a standby instance in a different
Availability Zone (AZ). Each AZ runs on its own phys ically distinct,
independent infrastructure, and is engineered to be highly reliable. In
case of an infrastructure failure (for example, instance hardware
failure, storage failure, or network disruption), Amazon RDS performs an
automatic fail over to the st and by, so that you can resume database
operations as soon as the fail over is complete. Since the endpoint for
your DB Instance remains the same after a fail over, your application
can resume database operation without the need for manual administrative
intervention.
Benefits
Enhanced Durability
Multi-AZ deployments for the MySQL , Oracle , and PostgreSQL engines
utilize synchronous physical replication to keep data on the standby
up-to-date with the primary. Multi-AZ deployments for the SQL Server
engine use synchronous logical replication to achieve the same result,
employing SQL Server- native Mirroring technology. Both approaches
safeguard your data in the event of a DB Instance failure or loss of an
Availability Zone.
If a storage volume on your primary fails in a Multi-AZ deployment,
Amazon RDS automatically initiates a fail over to the up- to-date
standby. Compare this to a Single-AZ deployment: in case of a Single-AZ
database failure, a user-initiated point-in-time-restore operation will
be required. This operation can take several hours to complete, and any
data updates that occurred after the latest restorable time (typically
within the last five minutes) will not be available.
Amazon Aurora employs a highly durable, SSD-backed virtualized storage
layer purpose-built for database workloads. Amazon Aurora automatically
replicates your volume six ways, across three Availability Zones. Amazon
Aurora storage is fault-tolerant, transparently handling the loss of up
to two copies of data without affecting database write availability and
up to three copies without affecting read availability. Amazon Aurora
storage is also self-healing. Data blocks and disks are continuously
scanned for errors and replaced automatically.
Increased Availability
You also benefit from enhanced database
availability when running Multi-AZ deployments. If an Availability Zone
failure or DB Instance failure occurs, your availability impact is
limited to the time automatic fail over takes to complete: typically
under one minute for Amazon Aurora and one to two minutes for other
database engines (see the RDS FAQ for details).
No comments:
Post a Comment