The question is out there, “if my databases are in the cloud do we need a DBA?” Not a question that DBAs want to hear, but they do want to hear that the answer is, “Yes, of course we still need DBAs.” Even with databases in the cloud approaching the point of extreme automation and possible self-healing, the Cloud DBA has challenges in supporting the environment but with valuable database knowledge and insight to the applications, utilizing the data as a needed force for successful cloud database deployment and maintenance.
The last chapter discussed the DMA, which can be identified more with a systems DBA. The Cloud DBA is going to be more associated with the application DBA. With database design, data services, and working with development teams, the Cloud DBA can step in and be involved in these areas and assist by how they can use the databases in the cloud. They can also work on additional data projects because they are not worrying about the day-to-day keeping-the-lights-on tasks.
Type of Clouds
This is not a type of storm clouds or if you see dragons or bunnies floating in the sky, but cloud is a virtualized environment that is specific for deploying services such as Database as a Service. Cloud computing has tools that can deliver these services through web interfaces and applications instead of directly accessing servers.
Briefly mentioned in the last chapter was the idea of public and private clouds. Typical public cloud offerings are through Oracle, Amazon, Microsoft, and Google. These are servers and environments that can handle several different workloads from applications and might just be application servers and also include databases. Private clouds are developed by the enterprise to be kept in the company’s data center and the resources will only be shared with internal enterprise users. It is typical that both public and private clouds will be used, along with other servers that might be classified as non-cloud or traditional technology services. Hybrid clouds might have the test environment in a public cloud and production in a private cloud.
Tip
Public cloud is not in the company’s data center, and its shared resources and infrastructure are not managed by the company, but by the cloud provider. A Private cloud is in the company data center, and its infrastructure is managed by the company. A Hybrid cloud has some of both – private and public cloud offerings.
There is a wide range of services that can be provided in the cloud, and they might have been services that were already being provided in a virtualized environment in the data center, which would mean that the shift is not as extreme. An environment that has manual intervention that is not as automated or standardized. As seen in Table 5-1, there are different models and levels of the services in the cloud that can be accessed and used by the enterprise. Cloud DBAs have levels of involvement in each of these models.
Table 5-1 Cloud Service Models
Service | Full Name | Purpose |
|---|---|---|
IaaS | Infrastructure as a Service | Bare metal, virtualized computing with networking, storage, and monitoring available |
PaaS | Platform as a Service | Resources with OS, network, and storage. Used for application deployments such as databases |
DBaaS | Database as a Service | Preconfigured deployment of a database for the PaaS environment. Standardized deployment |
SaaS | Software as a Service | Software available via Internet instead of local installations. Office 365 is a typical example |
For private clouds the DMA would be working at the IaaS level and creating a platform to provide for a database to be deployed by the Cloud DBA. If a public cloud, then the Cloud DBA would be deploying at the PaaS level and the DMA would be working with other machines in the data center and not involved in this public offering.
At the SaaS level, applications need data access. It might be data in the cloud or on-premise. The Cloud DBA will help make connects to the data and allow for the connections. The trick here is to monitor and make sure that the right connections are being made and only the access from the application is coming through.
Figure 5-1 Service Model Examples
Figure 5-1 gives the examples of the servers and the Cloud Clients including the Cloud DBA that performs their tasks using a web browser and other mobile apps. Before we get into the Tools and how to perform certain actions, let’s review the tasks of the Cloud DBA.
Tasks
Cloud DBAs perform very similar tasks as on-premise DBAs. The database servers, storage, and network are being maintained by the cloud infrastructure team, but the database needs to be administered properly.
The typical tasks of backup and recovery, database object maintenance, performance tuning, capacity planning, and what a DBA is known for needs to be part of the Cloud DBA’s list of activities. The connections to the database are slightly different, and access to the server directly is not necessarily allowed (unless it is an IaaS cloud environment).
High availability options need to be implemented in the cloud to provide the 24x7 uptime. This might not be as clear as to why high availability is needed if this is a virtualized environment and should have failover built in, but there are also other reasons to implement RAC for rolling patching or using the option of implementing Data Guard. Recovery through Data Guard and using the high availability options for patching and failover will provide additional safety nets for the databases. Private clouds might have these options supported by the DMA or even the system DBA might support them in the cloud.
With databases in the cloud, they can be implemented using containers. The DBA supports these containers either in understanding the business requirements that are needed to construct the standardized container for each database, or they can create the databases and then administer the databases as if it were on-premise. Figure 5-2 has databases in the cloud that are automated for baselines, features, and options of the database. It is a standard configuration to support monitoring and security. This allows many databases to be monitored as one and provisioning of database based on a catalog and self-service options.
Figure 5-2 Cloud Database Tasks
The creation of the database in the cloud is a small number of clicks from the catalog, and a consistent baseline database is created based on the options. The baseline will have a set of configurations and security. The cloud DBA can be the one that helps design these standards and baseline, or it can rely on the already developed containers to deploy. It is the understanding that the database being created automatically places the features and baselines in place. This does simplify the implementation of the database, along with the monitoring because it should not deviate from the baseline or standard. Easy checks against the baseline show what is different, and abnormalities are easier to detect for security purposes.
Cloud DBAs are going to be instrumental in making sure that data sets can talk to each other, which means that this is helping applications get the right APIs and restful data sources or helping with connections to the various data sources. Additional data areas will be discussed in Chapter 7.
The tasks that we have listed so far for the Cloud DBA:
Ensuring Backup and Recovery
Implementing High Availability
Creating Databases from Catalog
Database and Application Projects
Performance Tuning
Monitoring and Consistency Checks
Additional tasks that we will take a look at for the rest of the chapter are these:
Cloud Control
Capacity Planning
Migrations
Patching
It almost seems like a regular DBA job and task list. However, there are more automations and simplified tasks that are part of the cloud environment. Along with these tasks come some old and new tools for the Cloud DBA to use to accomplish them. The Cloud DBA-Oracle: Managing Oracle Database in the Cloud (Apress, 2017) is a great reference.
Tools
Oracle Enterprise Cloud Control is going to assist with on-premise and with Oracle cloud databases. On-premise is like the enterprise manager and is called cloud control because of the release. Cloud control can be used for setting up the configurations and provisioning of the databases. It is a tool that is available to connect into database on-premise, in the Oracle cloud, and other cloud environments public or private.
Managing Cloud Control is another way a Cloud DBA can be fully involved. With other tasks simplified, managing of the tools can be taken over to have a well-supported tool. Options that are available in Cloud Control will help with managing the database security, objects, and other parameters and configurations.
The Cloud Control helps with performance with the tuning tools, baselines, and current activity. It allows for management of the various databases that have been provisioned, and it is a tool to provision additional databases. Depending on the access to Cloud Control, the view can show the environment to have the perspective on performance and see where bottlenecks might be. Viewing resources in Control Cloud shows information not only about performance but capacity.
Another tool for the cloud environment is DBaaSCLI. The DBaaSCLI has restful services and APIs for management of a couple of areas for the databases. Some of the tasks are not available the same way. The access to the server is not allowed because it is a cloud environment. This is the tool and service console that is now what is used to accomplish the following tasks:
Change SYS password
Patch the databases
Rotate master keys for encryption
Data Guard and DR
Check and configure standby database
Switchover and failover standby databases
Other database tools will help in supporting objects, privileges, and data for development and migrations to production environments. Of course, the tools for creating a database are going to be different as it will use the DBaaS user interface or another cloud interface that allows for the database creation.
Capacity Planning
Some of the planning to move to the cloud environment requires capacity planning . It defines the cost of the environment and forecasts growth as planning resources for the private cloud or what makes sense to migrate to the public cloud. Capacity planning means examining CPU, memory, and storage usage and potential growth.
With on-premise database servers, storage planning is to know when new disks need to be allocated, but in the cloud, it is validating that the charges for the public cloud match the resources being used, and that growth matches budget and other planned costs for the databases.
One of many reasons for moving to the Cloud is to be able to have flexible resources. But this does not mean that the understanding of the resources that the database uses is not needed. If an application consumes more at the end of the month, that is not only an opportunity to tune, but an important tracking period to verify that resources are being given since they are needed and that the database is not caged. This is the flexibility of an on-demand resource.
Discovery
As part of the migration to the cloud, a large discovery process might be in order. Discovering the databases that would benefit from the cloud by flexible and on-demand resources, the costs of the data center and maintaining hardware would be valuable information for the baseline of the databases.
Since the cloud is an on-demand environment, others might be creating databases and bring applications into the cloud. The advantage of the cloud is the capture of creation for chargeback purposes. This is where the discovery and capture of the baseline is needed to be able to review the initial costs and demand on the system with the increase in capacity and whatever resources it requires.
If the public cloud is being used, it might require certain consolidation of information of which public cloud is being utilized, details as to offerings that are being considered, and baseline costs with resource statistics from CPU, memory, and storage. The catalog of databases is still a needed tool for the Cloud DBA. The connections and data flows should be simple for the applications and data users, but it is the Cloud DBA that helps make this possible. It is easier if the cloud is in the data center and standardized in a private cloud, but one thing we know as DBAs is that there are reasons for different database platforms and there will be reasons for private and public clouds and probably more than one public cloud. The Cloud DBA is in the position to support this and provide statistics and details around these databases.
A catalog of the databases now includes application, database name, database platform, some basic baseline information, levels of high availability, cloud database, and location. The discovery along the way will continue to support these details and provide capacity information about the resources.
Workload and Data Analysis
The discovery is the baseline and the workload analysis provides the actuals to verify the forecasts. The workload is the size of the user data, and the number of transactions and processes. Sizes of backups of databases and movement from cloud to on-premise for any of these operations are included in the data analysis.
Examination of the workload should have details about the elasticity or constant activity of the processes. This is a critical question about handling workload and peaks for the cloud environment and how they plan to size it and provide additional resources.
The initial questions to evaluate the cloud platform should include these options, on-demand elasticity, data migrations from cloud to on-premise, and on-premise to cloud. These should be part of the cost evaluation to understand, depending on the workload and if the right platform is selected. This type of activity falls with the Cloud DBA because of the knowledge they possess about database environments, and they are probably already collecting these statistics and if not complete, they have the know-how to acquire it. Also important is the sensitivity for the data analysis for security.
The planning and estimates should provide the details to measure and compare the actuals. The discovery and workload analysis feeds the collection of the statistics to make it more predictable and prepare for future environments and growth.
Security
Security features of the cloud environment can then be configured to protect the data. The Cloud DBA is going to understand data protection and how to utilize the database features to prevent unauthorized access to the data. Security options are available but they need to be used and implemented.
In Oracle Cloud the databases come with the Oracle database security features. For example, encryption is enabled and tablespaces will need to be created using encrypt tablespace. The Cloud DBA needs to secure the database, the data at rest through encryption, and access controls using roles for authorizations. Auditing policies need to be enabled for auditing of the databases and monitoring of the activity.
The security options are part of the DBaaS Catalog and there are mandatory security features along with the options. Depending on the data compliance, regulations will apply. Installing the security components may not be necessary. However, implementing security will protect the data and the auditing will verify that the controls are in place.
Separation of Duties almost comes along with the fact that the database is in the cloud. The administration teams do not have access to the data, and the Cloud DBA does not have access to the server. It is now just dependent on making sure that data is isolated and protected through access controls and even using features such as an Oracle Database Vault to protect the data from highly privileged users. Security available on-demand with resources and databases seems to make it simpler for the Cloud DBA.
Migrations
This might actually be the first step in becoming a Cloud DBA, migrating to the cloud. Migrating to the cloud is a transforming process. It can be several systems at once or selectively choosing the databases for the types of cloud environments that they will best function in. As part of the transformation, the Cloud DBA can help along this journey.
The research should bring to the front details about cost savings, options for data access, and efficient mobile support. Cloud environments can provide an on-demand system that will allow the developers to work in and possibly bring the production environment back to a private cloud. This will highlight the business justification to move to the cloud and where it makes sense to be in a private cloud or stay on-premise.
The discovery pieces in capacity planning include looking at the baselines and reviewing the database sizing and analysis to determine which type of cloud infrastructure is going to support the migration. The questions also need to be asked to understand the roles the Cloud DBA is going to play.
Questions around maintenance schedules, workload capacity, and costs of data movement are a few to make note of to have answered before starting migrations. Understanding the responsibilities for the environment will prevent being able to restore or failover to DR. Main areas for understanding if it is the cloud provider or the Cloud DBA:
Backups
Patching
High Availability
Managing Failovers
Managing Files and Backups
Outage Reporting
The migrations do not stop once the database has moved over to the cloud. There are ongoing processes for a few reasons. There might be new data that will need to be migrated to the cloud. There might need to be a restore of a database on-premise to either perform tasks, test, or troubleshoot a problem. There are reasons to move data either for a new migration or in support of development environments. These types of data migrations need to be supported by the Cloud DBA. There should be a few different options to moving data such as cloning, attaching PDBs, and even Data Pump.
Migrations along with capacity planning can keep a Cloud DBA for quite awhile. Even though more databases are planned to be in the cloud, the future growth and movement of data between public, private, and on-premise is going to continue. It will help this migration to the Cloud help the on-demand environment grow.
Application vs. Cloud DBA
After examining all of the tasks of the Cloud DBA, there is similarity to a typical DBA. There are system tasks with backups and high availability, and there are object changes and data migrations. It is just different where the tasks are being accomplished. The installations are handled, configurations are in place with DBaaS options and deployments, but there is a need for understanding the databases and managing the activity in them. There are utilities that are used, but knowing to perform operations and looking to use automations when possible is the value of the Cloud DBA.
Transformation of the DBA to cloud is important for the databases in cloud to be successful for the applications. There is knowledge that the DBA possesses that provides the insight on tuning and capacity planning that is critical for the environment growth and performance. There are additional tasks that the Cloud DBA will perform that are not a complete match to the Application DBA, but since the database is using infrastructure in a private or public cloud the Cloud DBA does not have some of the tasks of the System DBA. Table 5-2 is a demonstration of some of the differences in tasks of the Application and Cloud DBA.
Table 5-2 Cloud Service Models
Tasks | Application DBA | Cloud DBA |
|---|---|---|
Database Creation | X (DBaaS) | |
Patching | X | |
High Availability | X | |
Backups and Recovery | X | X |
Data Migrations | X | X |
Object Management | X | X |
Access Controls | X | X |
Encryption (Data Files) | X | |
Capacity Planning | X | |
Cloud Control Administration | X | |
Understanding Database Tools | X | X |
Database Connections | X | X |
Understanding that some of the tasks that are not checked as an Application DBA might actually be performed by some Application DBAs, and on the other side maybe the backups and recovery might not be performed. This is just an average number of DBA tasks to start to compare the importance of DBAs embracing the cloud environment and seeing what new opportunities are available.
Database creation does become self-service and on-demand, which means that application teams can also perform these tasks but then rely on the DBAs to help with maintenance, tuning, and future growth. Since the DBaaS service supplies the container and catalog for the databases, a DBA can be involved in creating the options and configurations that are in the DBaaS catalog.
DBaaS DBA vs. Cloud DBA
A DBA can work more on the development side and work with the containers. The DBA will need to understand what options and parameters can be configured and implemented as a standard across all of the databases. This will be the baseline of the DBaaS catalog. New features need to be researched by the DBA for compatibility with the DBaaS container. Having a DBA as part of the development team for DBaaS delivers a service that has the knowledge integrated into it for the best possible configuration. The basic database deployment will provide features that are needed and can be used by all. There can be different levels of support, security, or features that are in the catalog available to the applications.
The different levels are not selecting the specific parameters, it is selecting a service such as a high security option, warehouse database, or a level of performance. The grouping of options and parameters is the job of the DBA working on DBaaS. They develop the levels and know what belongs to those options. This also requires knowledge of the platform that the DBaaS databases are going to be deployed.
The Cloud DBA will use the DBaaS catalog and level choices in the catalog to create the databases in the cloud, and the DBaaS DBA will build the blocks and containers needed for the service. A DBaaS DBA will need to understand different programming languages, database development, and configurations. The DBaaS DBA will need to understand more of the infrastructure and the underlying cloud details with servers and OS to ensure that the containers will deploy properly in the cloud. The DBaaS DBA will test the containers and need to make sure that they can test the levels of services of the database. The validation of the database configurations and parameters can make sure that the databases are going to perform as expected and be turned over to the Cloud DBA for management.
Conclusion
A transformation to a Cloud DBA might be an easy path, and there are a few challenges as new tools need to be learned and become part of the day-to-day activities. Monitoring the databases for performance, security, and capacity is emphasized in the cloud. The options might be part of the options of the DBaaS and Cloud databases, but understanding the workings of the database will allow for the proper setup of the database in the cloud.
Migrations to the cloud create a whole new set of challenges, and the right questions need to be asked to make sure that responsibilities and services are clear so that the Cloud DBA can fill in the other activities and validate the other services and management of the cloud provider.
There are many databases that will be moving to public, private clouds, or both, and DBAs can be ready to support the migration and administration of the databases in cloud with the understanding of the roles and tasks that are utilizing the DBA’s knowledge and skills.