High Availability Resouces

High availability (HA) is a characteristic of a system which aims to ensure an agreed

level of operational performance, usually uptime, for a higher than normal
period.Modernization has resulted in an increased reliance on these systems.

Computing environments configured to provide nearly full-time availability are known as

high availability systems. Such systems typically have redundant hardware and software that
makes the system available despite failures. Well-designed high availability systems avoid
having single points-of-failure.This process remasters systemwide resources, recovers partial or
failed transactions, and restores the system to normal, preferably within a matter of
microseconds. The more transparent that failover is to users, the higher the availability of the
system.

Measuring Availability

We can classify systems and evaluate their expected availability by system type. Mission-critical
and business-critical applications such as e-mail and Internet servers probably require a
significantly greater availability than do applications that have a smaller number of users. As
well, some systems could have a continuous (24 hours a day, seven days a week) uptime
requirement, while others such as a stock market tracking system will have nearly continuous
uptime requirements for specific time frames, such as when a stock market is open.

High Availability Measurements

The software industry generally measures availability by using two types of metrics
(measurements):

● The mean time to recover

The industry focuses on mean time to recover (MTTR) issues and investigates how to optimally
design systems to reduce these. MTBF is generally more applicable to hardware availability
metrics

● The mean time between failures

We can design Real Application Clusters to avoid single points-of-failure, component failures
might not necessarily result in application unavailability. Hence, Real Application Clusters can
greatly reduce the mean time between failures(MTBF) from an application availability
standpoint.
Downtime can be either planned or unplanned.They can be broadly classified as system faults,
data and media errors, and site outages. This unplanned downtime is disruptive because it is
difficult to predict its timing.

Unplanned Downtime

A well designed Real Application Clusters system has redundant components that protect
against most failures and that provide an environment without single points-of-failure. Working
with our hardware vendor is key to building fully redundant cluster environments for Real
Application Clusters.

Planned Downtime

How High Availability Works

High availability functions as a failure response mechanism for infrastructure. The way that it
works is quite simple conceptually but typically requires some specialized software and
configuration.

Planning for High Availability

High availability is the result of thorough planning and careful system design. We can conduct
high availability planning at two levels:

● The system level with a broad perspective

● The failure protection level to ensure against a long list of potential causes of failures

System Level Planning

System level planning involves:

Capacity Planning

High availability requires the timely processing of transactions for a system to be deemed
completely available. While this chapter does not provide extended capacity planning
discussions, adequate system resources for managing application growth are important for
maintaining availability.Real Application Clusters enables us to add nodes to our system to
increase capacity and handle application growth. We can do this with minimal interference to
existing client transactions.

Redundancy Planning

Redundancy planning means duplicating system components so that no single component

failure increases system downtime. Redundant components are often used in high-end SMP
machines to protect against failures. For example, redundant power supplies and redundant
cooling fans are not uncommon in high-end SMP server systems. A clustered Real Application
Clusters environment can extend this redundant architecture by creating complete redundancy
so that there is no single point-of-failure.

AWS High Availability & Fault Tolerance

Architecture
● Amazon Web Services provides services and infrastructure to build reliable, fault-
tolerant, and highly available systems in the cloud.
● Fault-tolerance defines the ability for a system to remain in operation even if some of
the components used to build the system fail.
 ● Most of the higher-level services, such as S3, SimpleDB, SQS, and ELB, have been built
with fault tolerance and high availability in mind.
● Services that provide basic infrastructure, such as EC2 and EBS, provide specific features,
such as availability zones, elastic IP addresses, and snapshots, that a fault-tolerant and
highly available system must take advantage of and use correctly.

Regions & Availability Zones

Amazon Web Services are available in geographic Regions and with multiple Availability
zones (AZs) within a region, which provide easy access to redundant deployment locations.

● AZs are distinct geographical locations that are engineered to be insulated from
failures in other AZs.
● Regions and AZs help achieve greater fault tolerance by distributing the application
geographically and help build multi-site solutions.
 ● AZs provide inexpensive, low latency network connectivity to other Availability
Zones in the same Region
● By placing EC2 instances in multiple AZs, an application can be protected from
failure at a single data center
● It is important to run independent application stacks in more than one AZ, either in
the same region or in another region, so that if one zone fails, the application in the
other zone can continue to run.

Auto Scaling

● Auto Scaling helps to automatically scale EC2 capacity up or down based on defined
rules.
● Auto Scaling also enables addition of more instances in response to an increasing
load; and when those instances are no longer needed, they will be automatically
terminated.
● Auto Scaling enables terminating server instances at will, knowing that replacement
instances will be automatically launched.
● Auto Scaling can work across multiple AZs within an AWS Region

Configuring Auto Scaling

● First, we create an image of the instance (AMI), select “Instances”.

● Select the instance.
● Press “Actions”> “Image”> “Create Image”.

● Assign a name to the AMI, description and activate the option “No reboot”, the latter to
prevent the instance from restarting when creating the AMI.
● Verify that the AMI has been created successfully, select “AMIs” from the side menu.
● Check that the “Status” is “available”.
● The next step is to create the Auto Scaling Group; select “Launch Configurations” from
the side menu.
●
● Click on “Create AWS Auto Scaling Group”.
●
● Press “Create Launch Configuration”.
● Select “My AMIs” and the previously created AMI.

● Select the type of instance desired for the slave instances (slaves) created by the Auto
Scaling Group and press “Next: Configure details”.
● Select the option “Select an existing security group” to assign the same Security Group
of the master instance.

● Check that the settings are correct and create the launch configuration by pressing
“Create launch configuration”.
● Choose an existing key and accept that we have access to it; create the launch
configuration.
● The next thing is to configure the Auto Scaling group; Name the group of instances,
determine the number of instances with which it will start, select the VPC and the
private subnet, we also specify that the traffic will come from a Load Balancer so that
the “slave” instances are automatically added to it. Press “Next: Configure scaling
policies.”

● Adjust group policies.

● Determine the maximum number of possible instances in the group.

● Add a new alarm for the increase of instances:

● Create a topic (topic) to which name is assigned and emails to which they will be
notified (if they are two or more, separate them with commas), establish the maximum
percentage in a period of time, name the alarm and create it.
● In “Take the action” we establish that it increases the number of instances by 1 in 1.

● Add a new alarm for the decrement of instances:

● Create a topic (topic) to which name is assigned and emails to which they will be
notified (if they are two or more, separate them with commas), establish the minimum
percentage in a period of time, name the alarm and create it.
● Review the configuration and create the Auto Scaling group.

● In a few minutes, we can see in “Instances” the instance that is created automatically.
Elastic Load Balancing – ELB
● Elastic Load balancing is an effective way to increase the availability of a system and
distributes incoming traffic to application across several EC2 instances
● With ELB, a DNS host name is created and any requests sent to this host name are
delegated to a pool of EC2 instances
● ELB supports health checks on hosts, distribution of traffic to EC2 instances across
multiple availability zones, and dynamic addition and removal of EC2 hosts from the
load-balancing rotation
● Elastic Load Balancing detects unhealthy instances within its pool of EC2 instances
and automatically reroutes traffic to healthy instances, until the unhealthy instances
have been restored seamlessly using Auto Scaling.
● Auto Scaling and Elastic Load Balancing are an ideal combination – while ELB gives a
single DNS name for addressing, Auto Scaling ensures there is always the right
number of healthy EC2 instances to accept requests.
● ELB can be used to balance across instances in multiple AZs of a region.

Configuring Load balancer

Elastic Load Balancing supports two types of load balancers: Application Load Balancers and
Classic Load Balancers.

To Create a Classic Load Balancer:

● Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

● On the navigation bar, choose a region for our load balancer. Be sure to select the same
region that we selected for our EC2 instances.
● On the navigation pane, under LOAD BALANCING, choose Load Balancers.
● Choose Create Load Balancer.
● Choose Classic Load Balancer, and then choose Continue

To define our load balancer

● Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

● On the navigation pane, under LOAD BALANCING, choose Load Balancers.
 ● Choose Create Load Balancer.
● For Select load balancer type, choose Classic Load Balancer.
● For Load Balancer name, type a name for our load balancer.
The name of our Classic Load Balancer must be unique within our set of Classic Load
Balancers for the region, can have a maximum of 32 characters, can contain only
alphanumeric characters and hyphens, and must not begin or end with a hyphen.
● For Create LB inside, select the same network that we selected for our instances: EC2-
Classic or a specific VPC.
● [Default VPC or our custom created VPC] If we selected a default VPC and would like to
choose the subnets for our load balancer, select Enable advanced VPC configuration.
● For Listener Configuration, leave the default listener, and choose Add to add another
listener. For Load Balancer Protocol for the new listener, select HTTPS (Secure HTTP).
This updates Load Balancer Port, Instance Protocol, and Instance Port.
By default, Instance Protocol is HTTP and Instance Port is 80.
If we want to set up back-end instance authentication, change the instance protocol to
HTTPS (Security HTTP). This also updates Instance Port.
● [EC2-VPC] For Available subnets, select at least one available subnet using its add icon.
The subnets are moved under Selected subnets. To improve the availability of our load
balancer, select subnets from more than one Availability Zone.
Note
If we selected EC2-Classic as our network, or we have a default VPC but did not select
Enable advanced VPC configuration, we do not see the user interface to select subnets.
we can add at most one subnet per Availability Zone. If we select a second subnet from
an Availability Zone where there is already a selected subnet, this subnet replaces the
currently selected subnet for that Availability Zone.

Elastic IPs – EIPs

● Elastic IP addresses are public static IP addresses that can be mapped
programmatically between instances within a region.
● EIPs associated with the AWS account and not with a specific instance or lifetime of
an instance.
● Elastic IP addresses can be used for instances and services that require consistent
endpoints, such as, master databases, central file servers, and EC2-hosted load
balancers
● Elastic IP addresses can be used to work around host or availability zone failures by
quickly remapping the address to another running instance or a replacement
instance that was just started.
To allocate Elastic IP address:

1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2

2. Select Elastic IP address in the left pane and click Allocate new address
3. Once the IP address is allocated, select it in a list and choose Associate address from
Actions drop-down.
4. Associate the IP address with EC2 instances.
5. Repeat these steps for the second EC2 instance.

Relational Database Service – RDS

● RDS makes it easy to run relational databases in the cloud
● RDS Multi-AZ deployments, where a synchronous standby replica of the database is
provisioned in a different AZ, which helps increase the database availability and
protect the database against unplanned outages
● In case of a failover scenario, the standby is promoted to be the primary seamlessly
and will handle the database operations.
● Automated backups, enabled by default, of the database provides point-in-time
recovery for the database instance.
● RDS will back up our database and transaction logs and store both for a user-
specified retention period.
● In addition to the automated backups, manual RDS backups can also be performed
which are retained until explicitly deleted.
● Backups help recover from higher-level faults such as unintentional data
modification, either by operator error or by bugs in the application.
● RDS Read Replicas provide read-only replicas of the database an provides the ability
to scale out beyond the capacity of a single database deployment for read-heavy
database workloads
● RDS Read Replicas is a scalability and not a High Availability solution
Simple Storage Service – S3
● S3 provides highly durable, fault-tolerant and redundant object store
● S3 stores objects redundantly on multiple devices across multiple facilities in an S3
Region
● S3 is a great storage solution for somewhat static or slow-changing objects, such as
images, videos, and other static media.
● S3 also supports edge caching and streaming of these assets by interacting with the
Amazon CloudFront service.

Route 53
● Amazon Route 53 is a highly available and scalable DNS web service.
● Queries for the domain are automatically routed to the nearest DNS server and thus
are answered with the best possible performance.
● Route 53 resolves requests for our domain name (for example, www.example.com)
to our Elastic Load Balancer, as well as our zone apex record (example.com).

Configuring Route 53

Create Route 53 DNS Zone

Login to our AWS console and navigate to Services >> Networking & Content Delivery and click
Route 53.

If we don’t have a domain name we can register one for our business in this screen under
Domain registration.
If we already have a domain name we can click Get Started under DNS management.

Now we can create a new hosted zone here.

Click Create Hosted Zone.

In Domain name enter our domain name.

In Type choose Public Hosted Zone.

Click Create.

Now a set of Nameserver (NS) records will get created and assigned for our domain name.

Configure DNS in Domain

Now to make our domain to use Route 53 we need to update the nameservers of our domain
name with the one provided here.

To update login to our domain registrar and choose to add custom nameservers and add these
four NS records.

Once the update is done the requests to our domain name will get routed through Route 53.
Setup DNS Records
These are some commonly used DNS Records to map our domain name to EC2 Instance or
other services.

● A Record – IPv4 address, maps IP of the host with a domain.

● AAAA Record – IPv6 address, mainly used in HTTP(S), SSL Proxy, and TCP Proxy
Load balancing.
● CNAME – Alias for one name to another (www.domain.com, points to
domain.com)
● MX – Manages where emails should be delivered.
● TXT – Any text content, like domain owner verification text or something like that

For example to route our users to view the website in EC2 Instance we need to create an A
record in our DNS zone.

Click Create Record Set.

In the Name leave it blank.

In Type select A – IPv4 address.

In the Value enter the Elastic IP assigned to our EC2 Instance.

Click Create.
Now we have pointed our domain to our EC2 Instance.

Next we need to create a CNAME record for the www subdomain to point to the Elastic IP
address.

Click Create Record Set.

In the Name type www.

In Type select CNAME – Canonical name.

In the Value enter our domain name.

Click Create.

So finally the overall setup looks similar to the one below.

Likewise we can create MX records or TXT records for our domain name.

CloudFront

● CloudFront can be used to deliver website, including dynamic, static and streaming
content using a global network of edge locations.
● Requests for our content are automatically routed to the nearest edge location, so
content is delivered with the best possible performance.
● CloudFront is optimized to work with other Amazon Web Services, like S3 and EC2
● CloudFront also works seamlessly with any non-AWS origin server, which stores the
original, definitive versions of our files.
Configuring CloudFront

Using the AWS Management Console, we will create a CloudFront distribution, and configure it
to serve the S3 bucket we previously created.

1. Open the Amazon CloudFront console at

https://console.aws.amazon.com/cloudfront/home .
2. From the console dashboard, click Create Distribution.

3. Click Get Started in the Web section.

4. Specify the following settings for the distribution:

● In the Origin Domain Name field Select the S3 bucket we created previously.
● In Restrict Bucket Access click the Yes radio then click Create a New Identity.
● Click the Yes, Update Bucket Policy Button.

● Scroll down to the Distribution Settings section, in the Default Root Object field enter
index.html
● Click Create Distribution.
● To return to the main CloudFront page click Distributions from the left navigation menu.
5. After CloudFront creates our distribution which may take approximately 10 minutes, the
value of the Status column for our distribution will change from In Progress to Deployed.

6. When our distribution is deployed, confirm that we can access our content using our
new CloudFront Domain Name which we can see in the console. Copy the Domain Name
into a web browser to test.

7. we now have content in a private S3 bucket, that only CloudFront has secure access to.
CloudFront then serves the requests, effectively becoming a secure, reliable static
hosting service with additional features available such as custom certificates and
alternate domain names .
Elastic Kubernetes Service

Amazon EKS is a managed service that makes it easy for us to run Kubernetes on AWS
without needing to install and operate our own Kubernetes control plane or worker nodes.

“AWS EKS provides us the cluster which is highly secure and available. It automates key
tasks such as patching, node provisioning, and updates”

● When we set up EKS on AWS, it gives us a control plane that is available across multiple
availability zones, if there is an issue with any of the control planes EKS automatically
detects and replaces those unhealthy control plane nodes, and provides on-demand,
zero downtime upgrades, and patching.
● EKS offers a 99.95% uptime SLA. At the same time, the EKS console provides
observability of our Kubernetes clusters so we can identify any issue quickly and get it
resolved.

Provision our Resources For Scale:

● EKS managed services come pre-configured with the required compute (Server
resources)provisioning which is designed to scale our K8S app. We don’t need to
manage those configurations manually.
● EKS also supports AWS Fargate to automatically provision on-demand serverless
compute for our applications.
● Highly Secure K8s Environment :
● The Clusters deployed using EKS is highly secured and automatically apply the latest
security patches to our cluster’s control plane.
 Amazon EKS runs Kubernetes control and data plane instances across multiple
Availability Zones to ensure high availability. Amazon EKS automatically detects and replaces
unhealthy control plane instances, and it provides automated version upgrades and patching
for them. This control plane consists of at least two API server nodes and three etcd nodes that
run across three Availability Zones within a region. Amazon EKS uses the architecture of AWS
Regions to maintain high availability.
Amazon ECR hosts images in a highly available and high-performance architecture,
enabling we to reliably deploy images for container applications across Availability Zones.
Amazon ECR works with Amazon EKS, Amazon ECS, and AWS Lambda, simplifying development
to production workflow.
Amazon ECS is a regional service that simplifies running containers in a highly available
manner across multiple Availability Zones within an AWS Region. Amazon ECS includes multiple
scheduling strategies that place containers across our clusters based on our resource needs (for
example, CPU or RAM) and availability requirements.