Disaster Recovery (DR) is a process that helps you prepare for any kind of unwanted disaster. The DR process is designed to reduce the negative impact on a company due to a loss of any service. In the production world of scalable applications, DR is just as important as any other nonfunctional requirement. In this article, we will discuss how to use CPM effectively to achieve proper Disaster Recovery for AWS.
Data security is an essential requirement when storing data on the cloud. AWS offers various types of storage including EBS that offers persistent data storage. Along with persistence, EBS also provides an easy way to encrypt your data using a 256-bit key based encryption mechanism. The AWS EBS-managed encryption helps user get rid of tasks such as creating, managing, and securing your own key management service.
AWS EBS is particularly well-suited when you have persistent data storage needs, such as databases. In addition, since consistent backups are most important in production, EBS becomes an obvious choice since it allows you to create point-in-time `crash consistent' snapshots of the volumes. These are helpful when you want to restore data to a specific point in time.
Sometimes you need to rescue the data stored on AWS EBS volume that is attached to an original Amazon EC2 instance in your production environment. In case the instance is terminated or inaccessible, you can still access the data stored on that Instance EBS.
The following steps are useful when handling a failure scenario:
- You need to detach the volume from the original EC2 instance after stopping it.
- Attach the same volume to the newly launched EC2 instance.
- After remounting the volume, the data can be easily accessible.
As an organization grows, data also grows and it's generated from large number of endpoints like desktops, laptops, servers, virtual machines and many more devices. Automating your backup solution is cost effective and saves time.
However, trying to leverage traditional, non-cloud native solutions in order to backup AWS resources may be costly and ineffective. Traditional backup software and methods are very centralized by nature, holding disadvantages such as creating single points of failure as well as the high cost of software licenses and required dedicated hardware resources.
Ephemeral storage is the volatile temporary storage attached to your instances which is only present during the running lifetime of the instance. In the case that the instance is stopped or terminated or underlying hardware faces an issue, any data stored on ephemeral storage would be lost. This storage is part of the disk attached to the instance. It turns out to be a fast performing storage solution, but a non persistent one, when compared to EBS backup volumes. Ephemeral storage is ideally used for any temporary data such as cache, buffers, session data, swap volume etc. Apart from this, multiple ephemeral storage can be used together as RAID volumes and for specific Hadoop jobs where high performance and multiple nodes sharing the same data is desired.
In the growing world of data security and privacy requirements, encryption is a de facto need of cloud based applications. AWS EBS which provides data persistence also offers an easy to use, 256 bit key based encryption mechanism for EBS volumes. It builds, manages and secures a key management service for data owners.
XFS uses database journaling technology to provide high reliability and rapid recovery. Recovery after a system crash is completed within a few seconds. XFS is designed for use on most systems from desktop to supercomputer systems. Its major features include:
- Fast & trustable recovery after system crashes because of the use of journaling technology.
- Extremely high I/O performance that scales well on multiprocessing systems.
Amazon EBS volumes are persistent block level storage that are offered by Amazon Web Services (AWS). Whenever you create either a magnetic volume, an SSD volume (gp2) or Provisioned IOPS based SSD volume, all storage blocks are immediately allocated to you. However, when each individual block is accessed for the first time within those volumes, you might experience a 5-50% increase in I/O latency. This happens because when you try to access a block within one of the volumes mentioned above, the block needs to either be wiped clean or restored from a snapshot. This becomes a problem for performance intensive workloads that require fast read and write operations.
Imagine you are part of a media organization that is running a website on an EC2 instance and is storing all of its media files (e.g., images, videos) in an EBS volume. In the beginning, everything goes smoothly, but as the organization gains more and more popularity, website traffic increases. As a result, image load times also increase. In efforts to identify the root cause behind this increase, you realize that the network throughput between EC2 instances and EBS volumes is fluctuating. Therefore, you need a solution that provides dedicated network throughput between EC2 instances and EBS volumes, consequently choosing to go with EBS optimized instances.
With the world of the cloud growing at exponential rates, the demand for persistent storage is also increasing. AWS EBS offers persistent storage for Amazon EC2. EBS is a cost effective, plug and play device that can be attached to one instance at a time. EBS also offers a backup and recovery mechanism with the help of snapshots. With growing storage needs, users may have to think about increasing the size of their storage. Users may also shrink large EBS volumes to save on unutilized volume costs.
AWS CloudWatch provides different EBS performance metrics, including:
While troubleshooting and debugging the issue, the organization discovers that their instances have sufficient CPU and memory resources, but the connection between EC2 instances and EBS volumes is throttled at the network level.
How-to Change Your EBS Volume Type
In this how-to guide, you will learn how to modify an EBS volume type, which we will demonstrate by upgrading an attached magnetic EBS volume to a PIOPS/General Purpose SSD EBS volume.
An Example Use Case
A news website is running their complete stack on Amazon Web Services (AWS) where all the news content is stored on magnetic EBS volumes. As they grow, they witness performance issues with their websites. On performing further analysis, they figured out the performance of their magnetic EBS volume is getting throttled around 200 IOPS and throughput is reaching the maximum capacity of 90MBps. In order to enhance system performance, they decided to move to General Purpose SSD volumes, which can offer up to 10,000 IOPS per volume and a max throughput of 160MBps. An additional advantage they found by moving to General Purpose SSDs is that it they offer upto 16TB of volume, compared to Magnetic volumes' 1TB.