AWS
Common questions about running Tessell-managed databases on Amazon Web Services infrastructure.
Sub-sections: FSx for NetApp ONTAP
Q: How does Tessell provide services to databases running on AWS infrastructure?
A: Tessell leverages Amazon EC2 and Amazon EBS for the core data infrastructure on AWS. Two compute shape families are supported:
High-performance
i4i, i3en series
NVMe local SSDs — unparalleled IOPS
Standard
General-purpose instances
Amazon EBS gp3 or Ultra io2 volumes
Additional infrastructure details:
You can attach an Amazon VPC of your choice to the database VM — either a public or private VPC.
The Tessell Availability Machine protects database data through regular snapshots and transaction log backups, stored using Amazon EBS Snapshots and Amazon S3.
Q: Is Tessell certified by AWS?
A: Yes. Tessell is an AWS-preferred solution listed in the AWS Marketplace and AWS has certified Tessell DBaaS for Oracle. Additionally:
AWS-preferred solution
Listed in the AWS Marketplace
Co-sell ready
AWS sales teams can jointly sell Tessell with AWS services
AWS ISV-A partner
Part of the AWS Independent Software Vendor Accelerate program
Q: What High Availability and Disaster Recovery options does Tessell support on AWS?
A: Tessell supports Multi-AZ deployments on AWS. When enabled, Tessell creates a standby database instance in a different AWS Availability Zone. Key behaviours:
The standby instance is maintained through synchronous replication (Oracle Data Guard for Oracle; native streaming replication for PostgreSQL).
In the event of a primary instance failure, the standby is automatically promoted to primary with no manual intervention required.
A database proxy provides transparent connection failover so applications reconnect without requiring code changes.
For cross-region DR, Tessell replicates snapshots and transaction logs to a second AWS region, with global IP failover to redirect traffic automatically if an entire region becomes unavailable.
Q: How do I automate the gathering of EC2 instance metrics?
A: Tessell provides an automation that collects Amazon CloudWatch metrics for EC2 instances so you can assess your database workloads. The collected metrics are used to provide placement guidance for right-sizing purposes.
Pre-requisites
The following are required to run this automation:
python3
boto3
numpy
argparse
AWS access keys with read-only CloudWatch permission and EC2 permissions
Installation
To install the dependent packages and automation, run:
For the AWS CLI, installation instructions can be found here.
Deploy code
Copy the files ec2-data-collection.sh and ec2-data-collection.py to a location where you plan to execute the automation and make the files executable:
Set up AWS credentials
Configure AWS credentials in the host environment where you run this code. You can get AWS programmatic access from the AWS Console.
Prepare the source database list
Create a text file named instances_list.txt with the list of EC2 instance identifier name(s) separated by a new line. You can get the EC2 instance ID names from the AWS console or CLI. The instance IDs should be formatted as follows: i-123456789.
You can specify n number of EC2 instances in the text file, but ensure that they run in the same region. If the instances are in different regions, you need to gather the information separately.
Example usage
Run the automation with the number of days to be analyzed along with the CloudWatch metric sampling interval. This will take a few minutes depending upon the number of DB instances to be analyzed.
NOTE: It is recommended to run this script for 7 days and a period of 600.
NOTE: This script will need to be run for each region and each account where there are EC2 instances that need metrics gathered.
Q: How do I automate the gathering of RDS/Aurora metrics?
A: Tessell provides an automation that collects RDS/Aurora CloudWatch metrics for assessing your database workloads. The collected metrics can be used to provide placement guidance for right-sizing purposes. You can run this automation either from an EC2 instance or an AWS CloudShell environment.
Preparing the environment — using AWS CloudShell
AWS CloudShell is a browser-based shell that gives you command-line access to your AWS resources in the selected AWS Region. AWS CloudShell comes pre-installed with popular tools for resource management and creation.
Tessell recommends using AWS CloudShell as this has all of the pre-requisites and authentication preloaded. Using CloudShell will avoid many of the steps in this document. To use CloudShell you will need access to the AWS console. You can learn more here: https://aws.amazon.com/cloudshell/
Launch CloudShell from the AWS console.
Copy the automation code into the CloudShell terminal using the upload file option: CloudShell > Actions > Upload file.
Make it an executable file:
Verify the automation code:
You can now go to the steps for executing the automation.
Preparing the environment — using an AWS EC2 instance
Pre-requisites — the following are required to run this automation:
getopt
aws cli
zip
AWS access keys with read-only CloudWatch permission
Installation of getopt:
Debian/Ubuntu
apt-get install util-linux
CentOS/RedHat
yum install gnu-getopt
MacOS
brew install gnu-getopt
For the AWS CLI, installation instructions can be found here.
Installation of zip:
Debian/Ubuntu
apt-get install zip
CentOS/RedHat
yum install zip
Deploy the code — copy the file tessell_fetch_rds_aurora_metrics.sh to a location where you plan to execute the automation and make the file executable:
Verify the installation of the dependent packages and the automation code:
Set up AWS credentials in the host environment where you run this code. You can get AWS programmatic access from the AWS Console.
Prepare the source database list
Create a text file with the list of RDS/Aurora database identifier name(s) separated by a new line. You can get the DB identifier name from the AWS RDS console.
You can specify n number of DB instances in the text file, but ensure that they run in the same region. If the instances are in different regions, you need to gather the information separately.
Example: if you have one RDS and one Aurora cluster with 1 writer and 4 reader nodes, then the file should look like the following:
Execute the automation
Run the automation with the number of days to be analyzed along with the CloudWatch metric sampling interval. This will take a few minutes depending upon the number of DB instances to be analyzed. To gather metrics for an Aurora cluster for the last 7 days with a sampling interval of 86400 seconds:
View logs and metrics
The generated logs and metrics can be found in the /tmp/get_metrics* folder. You can import the generated CSV file into a spreadsheet for better visibility and for performing DB workload analysis with ease: Google Sheets > File > Import > Upload > Drop csv file.
Usage tips
where,
--help | -h: Display this help.--type | -t: Please provide db type either RDS or AURORA to collect metrics [Mandatory].--file | -f: Please provide a file containing a db identifier list separated by new lines [Mandatory].--days | -d: Please provide a number of days to determine the first data point and last data point for metrics.--start_date | -s: Please provide a start date to determine the first data point in the format 'YYYY-MM-DDTHH:MM:SS'.--end_date | -e: Please provide an end date to determine the last data point in the format 'YYYY-MM-DDTHH:MM:SS'.--period | -p: The granularity, in seconds, of the returned data points. Default value is 86400 seconds.
Note: The options -d and -s/-e are mutually exclusive and you can provide either one of them.
Examples:
Last updated
Was this helpful?