Developed with
QA

Contents

keyboard_tab
Alibaba RDS
1
Course Overview
PREVIEW2m 8s

The course is part of this learning path

play-arrow
Start course
Overview
Difficulty
Beginner
Duration
42m
Students
52
Description

This course covers the fundamentals of the relational database offerings in Alibaba Cloud and will help prepare you for the ACA exam.

First, we'll cover Alibaba Cloud Relational Database Services including an overview of some of the services that are provided with it. We'll then look at the main components of RDS in Alibaba, including different database engines, storage types, high availability, fault tolerance, and disaster recovery, before moving on to examine the features of RDS such as security, database and account management, read-only instances, monitoring, and backups.

We'll consolidate all this information by taking you through a guided demonstration of creating an RDS instance using the Alibaba Console.

If you have any feedback relating to this course, feel free to contact us at support@cloudacademy.com.

Learning Objectives

  • Understand the different relational database solutions available within Alibaba Cloud
  • Determine which database service would be best suited for your expected workloads

Intended Audience

This course is intended for:

  • Database administrators or cloud architects
  • Anyone looking learn how to use Alibaba RDS

Prerequisites

There are no prerequisites to this course as it is a fundamental introduction to the relational database service that Alibaba provides. Any knowledge of the Alibaba cloud platform and relational databases would, however, be advantageous. 

Transcript

Hello, and welcome to session two, RDS components. In this session, I'll talk you through the main components of the Alibaba Cloud Relation Database Service or RDS. Before you create an RDS service, you should understand the following components that make up the service.

The first component we should cover is an instance. An RDS instance is a database service running on a virtual server, on which you can create and manage a single database or multiple databases. You can choose the database engine, CPU, memory, storage, and network used by the RDS instance. Each instance or server that is created has a running cost associated to it. RDS provides a wide selection of instance types, optimized for different use cases.

The first thing to decide when provisioning an RDS service is to choose which payment type to use. This is the billing method. There are two types of billing method. The first one is pay as you go. Each instance provisioned is charged on an hourly basis and is suitable for short-term use. Storage is only charged for the amounts of data that is stored. There are no long-term commitments or upfront payments, you can activate or release instances at any time.

The second method is subscription. This is an upfront payment better suited for those requiring long-term use. It's more cost effective than pay as you go instances and you can receive larger discounts, the longer the selected subscription period. The subscription period can be monthly, between one to 11 months or yearly, between one to five years.

A subscription-build instance cannot be released within the subscription period. It's worth noting, however, that you can switch from subscription billing to pay as you go billing, as well as switching from pay as you go billing to subscription billing.

The next thing to consider is where to provision the service. So you need to choose a region. A region is a physical location with one or more data centers that are spread all over the world to reduce network latency. To maximize the access speed, select a region in close proximity to the geographic location where your users reside. Ensure that the RDS instances are created in the same region as the ECS instances that you want to connect to the database.

In this particular use case, an ECS instance would be the client machine that is accessing data on the database server. If the clients reside in different regions to the servers, they cannot communicate over an internal network to implement optimal performance and communication would have to take place over public a network, which will incur additional charges.

At the time of this recording, there are presently 21 regions available worldwide, 10 in China and 11 internationally, but it's worth noting that not all regions currently support all database engines.

The next component to choose is then, is which database engine to use. RDS allows you to select from a range of different database engines. These currently include MySQL, commonly called My Sequel, which is generally considered to be the number one open source relation database management system or IDB. This is the community-developed fork of MySQL, PostgreSQL, another open source database, Postgre Plus Advanced Server, which is highly compatible with Oracle. The Oracle database is a common platform in many corporate environments. And SQL Server, this is a Microsoft database with a number of different licensing options.

Some of the engines also have multiple versions available, as you can see in the following diagram. Once you've chosen the required engine and version, you then need to choose the edition.

Now RDS provides five different editions. There's basic, high availability, enterprise, AlwaysOn, and high performance. Which edition you choose is dependent on various factors. For example, the database engine and version that's selected controls which of the editions become available. Where there are multiple additions available for a particular engine, then the functionality of the different editions needs to be considered, as this has an impact on things like high availability, disaster recovery, and cost.

Let's have an overview of each one. In the basic condition, the database system consists of only one instance and it's called the primary instance. This addition is cost-effective because there is only one database server. If the primary instance breaks down unexpectedly, is executed any changes, or is updating its version, the database service may be unavailable for a long period of time.

The high availability edition has one primary instance and one secondary instance. Data is synchronously replicated from the primary instance to the secondary instance. If the primary instance breaks down unexpectedly, the database system automatically fails over to the secondary instance. Primary and secondary instances can be deployed in the same zone or in different zones in the same region to support cross-zone disaster recovery.

The enterprise edition uses a three instance architecture that consists of one primary instance and two secondary instances. Data is synchronously replicated from the primary instance to the secondary instances to ensure data consistency. The primary and secondary instances can be deployed in three different zones in the same region to support cross-zone disaster recovery. The enterprise edition also supports automatic scaling, backup and restoration.

The AlwaysOn edition or as it was previously known, the Cluster edition, currently only supports SQL Server 2017 enterprise edition. And it's based on the native AlwaysOn technology of SQL Server. The AlwaysOn edition separates computing from storage and has one primary instance and one secondary instance. Like the high availability edition, data is synchronously replicated from the primary to the secondary instance. It also supports read-write splitting and up to seven scale on-demand read-only instances can be created. The primary instance asynchronously replicates to these instances to give read-only copies of the database, which enhances performance.

And lastly, the high-performance edition. Currently, only MySQL version eight and 5.6 supports the high-performance edition. And it consists of one primary instance and one or more secondary instances where all instances read and write to the same storage.

The next component to consider is the storage type. Available storage is dependent on the database engine and version selection, as well as the chosen edition. The amount of storage required can be changed after the RBS instances are deployed and can be increased or decreased.

The storage media is backed by SSD or solid state drives and RDS supports three types of SSDs, local SSD, standard SSD and enhanced SSD. A local SSD resides on the same server as the database engine. You can store data on a local SSD to reduce IO latency.

A standard SSD has an elastic block storage device that is designed based on a distributed storage architecture. You can store data on a standard SSD to separate computing from storage.

Enhanced SSD is a new SSD product designed by Alibaba Cloud, based on next generation distributed block storage architecture. It integrates 25-gigabit ethernet and remote direct memory access technologies to provide super high performance at low latency. It can process up to 1 million random read-write requests per second.

Enhanced SSDs come in three performance levels. Performance level one, which is the regular enhanced SSD. Performance level two, which has twice the IOPS and throughput than PL1. And PL3, which has IOPS that are 20 times higher than PL1 and throughput that is 11 times higher than PL1.

Enhanced SSDs are obviously the most expensive from the storage offerings. Depending on the edition that was selected, basic, enterprise, high availability or high performance, the next thing to consider or more correctly to choose, if required, is the primary node deployment zone and the deployment method.

A zone is an independent area within a region, which is provided with independent power supplies and networks. Zones in the same region generally provide the same services. And just for clarity, primary node is just another name for primary instance. For RDS instances, you can choose the zone within the chosen region where the primary node or instance will reside. 

For the deployment method, there are two options. They are single zone deployment which means that the primary and secondary instances are located in the same zone. Now this would give high availability and low network latency, being in the same zone. The instances can withstand a server or rack failure, but the zone itself becomes a single point of failure.

So the other option is multi-zone deployment which means that the primary and secondary instances are located in different zones in the same region, for cross-zone disaster recovery. Instances deployed in multiple zones can survive an entire data center failure.

It's worth noting that no additional fees are charged for this functionality. The basic condition doesn't support multi-zone deployment as it only contains one primary instance. It's also worth noting that multi-zone deployment is not available in all regions.

At the beginning of this session, I talked about what an instance was, a database service running on a virtual server. And I said that you can choose the CPU and memory used by the virtual servers.

RDS supports many different instance types. Instance types comprise varying combinations of CPU, memory, maximum connections and IOPS utilization. RDS provides a wide selection of instance types to fit different use cases. And some of these instances have either dedicated or shared resources.

To support this functionality, RDS provides two categories of instance families, entry level and enterprise level. The entry level provides a general purpose instance. A general purpose instance has dedicated memory resources allocated to it, but share CPU and storage resources with the other general purpose instances that are deployed on the same physical host server. The storage capacity of a general purpose instance is independent of CPU and memory and can be flexibly configured, based on business requirements.

The enterprise-level provides a dedicated instance or a dedicated host. A dedicated instance, as the name implies, has dedicated memory and dedicated CPU resources allocated to it, and reserve storage. So one instance is not affected by the other instances that are deployed on the same physical host server. A dedicated host occupies all of the resources on the physical host server where it resides.

As previously mentioned earlier in this session, to prevent unwanted extra network charges, you need to ensure that the RDS server instances and the client ECS instances are on the same internal private network. If the clients and servers reside in the same internal network, they can communicate with optimal performance and there's no associated network traffic costs. If they cannot communicate in a local private network, then public network charges will occur.

So let's have a recap of what we've covered so far. There are currently 21 locations or regions around the world where you can provision the RDS service and each region has one or more zones. There are four main database engines to choose from, MySQL, PostgreSQL, SQL Server and MariaDB. Some of these have multiple versions.

The different editions, high availability, high performance, enterprise, and AlwaysOn allow you to provision for high availability and or disaster recovery, if required. This is not supported with the basic condition.

There are three different storage types to choose from, local SSD, standard SSD and enhanced SSD. And two types of network are supported, classic and virtual private cloud or VPC. Although best practice is to use VPC. And finally, it's worth noting that all of the regions do not support all of the engines. All of the engines do not support all of the editions and all of the editions do not support all of the storage types.

That concludes this session on RDS components. I hope you've enjoyed it and I look forward to talking to you in the next session, RDS features.

About the Author
Avatar
David Bedford
Principal Technical Learning Specialist - Cloud
Students
96
Courses
3

David’s IT career started in 1990, when he took on the role of Database Administrator as a favor for his boss. He redirected his career into the Client Server side of Microsoft with NT4, and then progressed to Active Directory and each subsequent version of Microsoft Client/Server Operating Systems. In 2007 he joined QA as a Technical Trainer, and has delivered training in Server systems from 2003 to 2016 and Client systems from XP onwards. Currently, David is a Principal Technical Learning Specialist (Cloud), and delivers training in Azure Cloud Computing, specializing in Infrastructure Compute and Storage. David also delivers training in Microsoft PowerShell, and is qualified in the Alibaba Cloud Space.