Relational Database Service 8.1 Overview

8 Relational Database Service

8.1 Overview

DB instances are basic building blocks of Amazon RDS. Very much like in case of EC2, DB instances are deployed in the isolated cloud environment and can contain multiple user-defined databases within one database engine. In order to connect and manage these databases, the user can use the very same tools he uses with regular, stand-alone database servers (for instance SQL Server Management Studio with MS SQL Server, MySQL Workbench with MySQL). Moreover, DB instance allows setting the computation and memory capacity as well as specifying associated storage capacity. Each database engine has its specific requirements for its minimum and maximum storage capacity. Additionally, DB instances can be of two types – standard instances or provisioned IOPS²⁷ instances. Both of these types use Amazon EBS volumes as their storage provider however in case of provisioned IOPS instances RDS provides additional, dedicated capacity for input/output operations. These types of instances are typically used in heavy-load applications or environments with massive database communication.

Like with EC2 instances, an access to DB instances is also managed with use of security groups, however in this case, other than specifying allowed IP ranges they are also used to allow access for running Amazon EC2 instances. This way the user can have his DB instance linked to his EC2 instance without explicitly specifying access for its IP address, which allows to cope with dynamic nature of EC2 addressing (unless public static IP address is used). Moreover, in order to manage various DB servers configurations, DB parameters groups are used. These groups contain configurations for different DB engines and can be used with DB instances of the same type. These configurations usually contain several key/value tags used to specify rules and settings such as file stream access level, lightweight pooling, automatic updates, locks, maximum of worker threads and many others. Usually, when no parameter group is found upon instance creation, AWS generate a default one with default values for the specific database engine [22].

When creating a SQL Server DB instance, several steps are needed. The first and arguably the most important one is to select SQL Server edition. Much like with Oracle, there are several versions of SQL Server that are specific tailored for various user needs. AWS support at total four SQL Server editions: Express Edition, Web Edition, Standard Edition and Enterprise Edition. In this order, each consecutive edition adds up on new features that were unavailable to its predecessor [23]. Once the user chooses the right edition, he can determine the type of SQL Server. AWS support both 2008 R2 as well as newer 2012. Next step is to choose instance size. Instance sizes are very similar to EC2 instance types varying from small to xlarge. These types aren’t used for DB engines themselves but rather for virtual instances the servers run on. Another very important step is to specify allocated storage size. As already mentioned, the user can only choose within allowed minimum and maximum. These two values differ by server editions (Express Edition – 20GB, 1024GB; Enterprise Edition – 200GB, 1024GB). Then the user can decide to allocate additional storage for IO operations by enabling creation of provisioned IOPS instance. Another step is to specify an identifier for his DB Instance as well as Master Username and Master Password. These credentials will belong to a user with administrator rights to database server. As such, once the instance is launched, it is a good policy not to use them directly from an application but to create separate SQL user accounts with individual logins instead.

Other configurations are available for the user as well. As such, he can specify DB instance port (native port is 1433), choose default availability zone and associate one or multiple DB security groups with the new instance. Finally, he has an option to enable automatic backups, schedule backups and choose when AWS should perform maintenance. After these are configured and set, AWS proceed to allocate necessary resources and launch the new DB instance.

8.2 RDS in Kentico AWS Manager

All the manipulation with RDS in Kentico AWS Manager is done through RDSManager class that encapsulates all web service calls. Although KAM only attempts to load the information once, it offers an option to the user to repeat the query by refreshing the view. This can be done as many times as the user desires. If any instance is found, its information is processed by KAM and passed to DB instance table bundled in an object – a wrapper. This model is then used by instance table to populate a template and new selectable data item is rendered in the view.

In addition to query existing instances, KAM also offer to the user an option to create new instances. In the current form this functionality is implemented in a separate view that embeds web browser control. Upon its selection, the user is redirected to AWS management console wizard for launch of new DB instance. I decided to choose this approach because of two reasons. Firstly, the creation of new DB instance is a lengthy process that requires many parameters. Since this process has already been encapsulated in AWS management console, I didn’t deem necessary to reinvent the wheel by implementing it again in KAM. Secondly, unlike EC2 launch process, the integration of Kentico CMS with RDS doesn’t depend on DB instance creation. This means that Kentico CMS only requires a running instance. As such, the creation process is unimportant. Once the new instance begins to launch, the user is once again redirected to the RDS view where he can observe his new instance being configured.

Kentico CMS can be configured to use RDS instance through EC2 instance creation wizard. This occurs in the step where the user defines configuration details for IIS and database. KAM gives the user the chance to choose either local database server (default option) that comes with the underlying AMI or to use Amazon RDS instead. If the user selects this option, he is once again redirected to RDS view with DB instance details. This time, however, new options are available. In addition to refreshing the view and creating new DB instance, the user can select any running instance in order to use with Kentico CMS. Only those instances whose status says running are selectable. Once an instance of this type is selected, KAM automatically populates Master Username field based on its data and prompts the user for Master Password. And here lies yet another issue with AWS. The problem is that Amazon purposely doesn’t allow any API call that would return instance’s Master Password. As such, KAM has no way of determining this password for selected instance and must ask the user for it. Moreover, it is extremely difficult to test this password correctness. This is because access to DB instance is being regulated by security groups and by default nothing has permissions to access new instances. As such, to fully test provided password, KAM would have to add the user’s public IP address in the security group and after the password has been tested, KAM would have to remove it. As this behavior would be both tedious and lengthy, there are currently no mechanisms in place to verify the password.

After the user approves an instance, some of its information is stored in the session object. Then, as a new EC2 instance is being created, this information is pulled out of session and together with EC2 security group details is used by RDSManager to authorize instance’s access to RDS DB instance. Authorization is executed in several steps. KAM doesn’t alter the security group of chosen DB instance but rather creates a new one. Then it authorizes EC2 security group by adding its unique identifier to the newly created RDS security group and as it creates a new permission. In the last step, this security group is added to user-chosen DB instance by RDSManager. This way, all the previous access rights (described in original security groups) are retained and only the new security rule (access for EC2 instance is added). Once our EC2 instance launches, DB instance endpoint along with Master Username and Master Password are passed to it in a form of user data which Kentico installer uses to create and prepopulate CMS database.