KR102899701B1 - Cloud bases open database management platform and program performing cloud based open database managing method - Google Patents

Abstract

A cloud-based open database management platform and a cloud-based open database management method are disclosed. According to one embodiment of the present invention, a computer program stored in a computer-readable medium is provided for performing the cloud-based open database management method, wherein the computer program causes a computer to perform the following steps, the steps including: receiving a request to create a unit set and one or more units from an execution engine; activating a unit set controller of a DB common management unit and creating a shared setting; activating a unit controller of the DB common management unit; declaring a storage space in the unit controller; creating a pod and deploying a cluster; and creating a unit including the pod.

Description

Cloud-based open database management platform and program performing cloud-based open database management method

The present invention relates to a cloud-based open database management platform and a program for performing a cloud-based open database management method.

Modern applications work in conjunction with massive databases.

Figure 1 is a diagram illustrating the database operation method. (a) shows the traditional method, and (b) shows the general Kubernetes (K8s) utilization method.

The traditional approach (on-premise or virtual machine-based deployment) depicted in Figure 1 (a) requires manual management of many tasks, including deployment, expansion, high availability, updates, and monitoring, and requires separate management of infrastructure and databases, resulting in complex operations. Furthermore, it suffers from low scalability, infrastructure dependency, and significant human resource requirements.

In contrast, deploying a database using a cloud platform like Kubernetes, as illustrated in Figure 1 (b), automates most tasks and significantly improves scalability, recoverability, and resource efficiency. Automating APs and integrating infrastructure and database management facilitates operational convenience and enables command-line database management.

However, these cloud-based services require specialized personnel with expertise in cloud technologies like Kubernetes, and database maintenance can be challenging. Furthermore, managing numerous resources increases workload and time, increasing the likelihood of human error.

The matters described in the technical background of this invention are for understanding the background of the invention, and cannot be determined to be prior art already known to a person with ordinary skill in the field to which this technology belongs.

Korean Patent No. 10-2209044 (registered on January 22, 2021) - Cloud system with cloud-native database structure

The present invention provides a cloud-based open database management platform and a program for performing a cloud-based open database management method that can be operated with simple training without specialized knowledge, and that can easily and quickly resolve problems while maintaining continuity without server downtime and service interruption even in the event of a failure through an integrated UI interface.

The present invention provides a cloud-based open database management platform and a program for performing a cloud-based open database management method that can meet various open database and middleware task requirements through a platform that supports and manages an open database, can rapidly expand by applying a microservice architecture, can support multiple database cluster architectures, and can meet workload management patterns through common workloads.

Other purposes of the present invention will be readily understood through the following description.

According to one aspect of the present invention, there is provided a computer program stored in a computer-readable medium for performing a cloud-based open database management method, the computer program causing a computer to perform the following steps, the steps including: receiving a request to create at least one of a unit set and a unit from an execution engine; activating a unit set controller of a DB common management unit and creating a shared setting; activating a unit controller of the DB common management unit; declaring a storage space in the unit controller; creating a pod and deploying a cluster; and creating a unit including the pod.

The above shared setting creation step, the storage space declaration step, the pod creation and cluster deployment step, and the unit creation step can be processed in an open database by commanding the Kubernetes API server.

The method may further include: receiving an update request for one or more of a unit set and units from the execution engine; activating the unit set controller; updating shared settings, the number of units, unit templates, and service settings in the unit set controller; activating the unit controller; and updating storage space and service settings in the unit controller.

The update step in the above unit set controller, the update step in the above unit controller can be processed in the open database by commanding the Kubernetes API server.

The method may further include: receiving a service creation request from the execution engine; activating the unit set controller; updating service settings in the unit set controller; activating the unit controller; and updating service settings in the unit controller.

The update step in the above unit set controller, the update step in the above unit controller can be processed in the open database by commanding the Kubernetes API server.

The method may further include receiving a request to delete one or more of a unit set and a unit from the execution engine; activating the unit set controller; deleting a service setting from the unit set controller; activating the unit controller; deleting the service setting from the unit controller, releasing the storage space, deleting the pod, and deleting the unit.

The deletion step in the above unit set controller and the deletion step in the above unit controller can be processed in an open database by commanding the Kubernetes API server.

Meanwhile, according to another aspect of the present invention, a computer program stored in a computer-readable medium is provided for performing a cloud-based open database management method, wherein the computer program causes a computer to perform the following steps, the steps including: receiving an open database related event from an execution engine; activating a controller related to the open database in a DB-specific management unit; requesting resource information related to the open database from the controller; creating a manager related to the open database based on the resource information; and performing an operation corresponding to the event in the manager.

The above open database related event may be a MySQLReplication event, the administrator may be a MySQL administrator, and the action corresponding to the event may be a MySQL master-slave update.

Alternatively, the above open database related event may be a ProxySQLSync event, the administrator may be a ProxySQL administrator and a MySQL administrator, and the action corresponding to the event may be synchronization of ProxySQL and MySQL.

Alternatively, the above open database related event may be a RedisReplication event, the manager may be a Redis manager, and the action corresponding to the event may be a Redis master-slave update.

Alternatively, the above open database related event may be a Redis Cluster event, the administrator may be a Redis administrator, and the action corresponding to the event may be Redis synchronization within the Redis cluster.

Other aspects, features and advantages other than those described above will become apparent from the following drawings, claims and detailed description of the invention.

According to an embodiment of the present invention, operation is possible with simple training without specialized knowledge, and through an integrated UI interface, continuity is maintained without server downtime and service interruption even in the event of a failure, and problems can be easily and quickly resolved.

Additionally, it can meet the needs of various open database and middleware operations through a platform that supports and manages open databases, can rapidly scale by applying a microservice architecture, support multiple database cluster architectures, and can meet workload management patterns through common workloads.

The effects that can be obtained from the present invention are not limited to the effects mentioned above, and other effects not mentioned can be clearly understood by a person having ordinary skill in the art to which the present invention belongs from the description below.

Figure 1 is a diagram showing the database operation method.
Figure 2 is a configuration diagram of a cloud-based open database management system according to one embodiment of the present invention;
FIG. 3 is a configuration diagram of a management platform included in a cloud-based open database management system according to one embodiment of the present invention;
FIG. 4 is a configuration diagram of an execution engine included in a cloud-based open database management system according to one embodiment of the present invention;
Figures 5 and 6 are flowcharts of an open database management method performed in an execution engine of a system according to one embodiment of the present invention, particularly in a DB common management unit.
FIG. 7 and FIG. 8 are flowcharts of an open database management method performed by an execution engine of a system according to one embodiment of the present invention, particularly a DB specific management unit.
Figure 9 is a functional configuration diagram of a cloud-based open database management system according to one embodiment of the present invention;
FIG. 10 is a drawing showing a DB operation support method in a system according to one embodiment of the present invention;
FIG. 11 is a diagram showing functions provided by a system according to one embodiment of the present invention;
Figure 12 is a diagram illustrating the configuration of a system according to one embodiment of the present invention.

The present invention is susceptible to various modifications and embodiments. Specific embodiments are illustrated and described in detail in the drawings. However, this is not intended to limit the present invention to specific embodiments, but rather to encompass all modifications, equivalents, and alternatives falling within the spirit and technical scope of the present invention.

When a component is referred to as being "connected" or "connected" to another component, it should be understood that it may be directly connected or connected to that other component, but that there may be other components intervening. Conversely, when a component is referred to as being "directly connected" or "connected" to another component, it should be understood that there are no other components intervening.

Terms such as first, second, etc. may be used to describe various components, but these components should not be limited by these terms. These terms are used solely to distinguish one component from another.

The terminology used herein is merely used to describe specific embodiments and is not intended to limit the present invention. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this specification, it should be understood that the terms "comprises" or "has" indicate the presence of a feature, number, step, operation, component, part, or combination thereof described in the specification, but do not exclude in advance the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

In addition, it is to be understood that the components of the embodiments described with reference to each drawing are not limited to the specific embodiments, but may be implemented to be included in other embodiments within the scope in which the technical idea of the present invention is maintained, and that multiple embodiments may be re-implemented as a single integrated embodiment even if a separate description is omitted.

In addition, when describing with reference to the attached drawings, identical components will be assigned identical or related reference numerals regardless of the drawing reference numbers, and redundant descriptions thereof will be omitted. When describing the present invention, if a detailed description of a related known technology is judged to unnecessarily obscure the gist of the present invention, the detailed description thereof will be omitted.

Additionally, terms such as “part,” “unit,” “module,” and “device” described in the specification mean a unit that processes at least one function or operation, which may be implemented by hardware, software, or a combination of hardware and software.

The terms used in this specification are as follows.

A container is a unit that runs an application and its dependencies in an isolated environment.

A sidecar container is a container that assists or extends the functionality of the main container.

A pod is the smallest deployment unit in Kubernetes where containers run.

The Kubernetes API Server is the central API endpoint through which the Kubernetes cluster and all its components communicate, handling requests to query or control the cluster's state.

The Controller is a component that communicates with the Kubernetes API server and manages resources to maintain the cluster's state at the desired target state.

CRD (Custom Resource Definition) is a feature that allows users to define new resources to communicate with the Kubernetes API server and be managed by the controller.

A Service is a Kubernetes resource that exposes network services externally or internally, enabling communication between Pods.

Replication means duplication and multiplexing.

ProxySQL is a high-performance middle-tier software for MySQL-compatible databases. It sits between the client and the database server, managing connections and providing features such as load balancing, caching, and query routing to improve database performance and availability.

FIG. 2 is a configuration diagram of a cloud-based open database management system according to one embodiment of the present invention.

A cloud-based open database management system (100) according to one embodiment of the present invention is characterized by supporting and managing an open database under a cloud environment.

The cloud-based open database management system (100) according to the present embodiment may be a cloud-native platform that supports open database management in a cloud environment, such as Kubernetes (or Openshift, Tanzu). For ease of understanding and explanation of the invention, the following description will focus on Kubernetes.

The cloud-based open database management system (100) can be easily installed on a Kubernetes cluster and can manage various types of open databases.

Manageable open databases can include various types of open source databases, such as RDBMS (MySQL), cache (Redis), non-relational databases (ElasticSearch), MQ (Kafka), PostgreSQL, and Zookeeper. Here, a Message Queue (MQ) is a system that asynchronously transfers data between applications that produce data or messages (producers) and applications that consume them (consumers). Produced messages are stored in a queue, and consumers can retrieve them in order or according to established policies when needed.

The cloud-based open database management system (100) is a control plane platform that supports and manages databases in Kubernetes. The control plane refers to a set of components responsible for managing and controlling the entire distributed system. In systems like Kubernetes, the control plane maintains the cluster's state, controls workload distribution and scaling, and performs overall cluster management.

Referring to FIG. 2, a cloud-based open database management system (100) may include a management platform (110) and an execution engine (120).

The management platform (110) provides an API interface and workflow management execution. It manages workflows in custom resources (CRs) and enables the use of Kubernetes API resource objects. Furthermore, by applying a microservices architecture, it can rapidly expand to include other types of open database services.

The execution engine (120) is composed of independent modules and can enable data state maintenance and operational automation. The execution engine (120) can be designed using a Kubernetes-based operator framework.

The cloud-based open database management system (100) is a scalable platform that meets the requirements of Kubernetes multi-cluster orchestration.

FIG. 3 is a configuration diagram of a management platform included in a cloud-based open database management system according to one embodiment of the present invention.

The management platform (110) may include a web server (114), an integrated interface provider (111), an API server (113), and an expansion module (113).

The web server (Nginx) (114) is configured to be connected to the user (administrator) side, and supports large-scale traffic processing and fast website operation through static file serving, load balancing, and proxy functions.

The integrated interface provision unit (111) provides an integrated UI for users (administrators).

The API server (113) provides services for communicating with the execution engine (120). The API server (113) is a platform management core based on the design and development of the SpringCloud microservice framework. Management functions can be provided using a Restful API. MySQL database data storage management functions, Redis cache-accelerated data query functions, and other features can be utilized.

The extension module (113) is used for database connection, user, and library management. The extension module (113) is a platform extension component that provides extensible functionality for database services and middleware services. For example, it can support MySQL user management and MySQL database management.

Referring again to FIG. 2, the execution engine (120) may include a DB common management unit (121) and a DB specific management unit (122).

The DB Common Management Unit (121) creates and manages UnitSets and Units, which are user-defined resources (CRDs). It provides common functions for managing various databases and middleware services. This creates a deployment environment and provides the system's infrastructure.

The DB common management unit (121) can manage and monitor various resources (CPU, memory, network, etc.) of nodes, namespaces, and PODs.

The DB specific management unit (122) focuses on database cluster management and manages and coordinates relationships between different service components.

The DB-specific management unit (122) manages and distributes the database, supports replication, and can automatically synchronize database user and replication information. In other words, it can configure cluster relationships, set up database replication (e.g., MySQL Primary/Replica replication), cluster architecture (e.g., Redis), and coordinate interactions between different services.

FIG. 4 is a configuration diagram of an execution engine included in a cloud-based open database management system according to one embodiment of the present invention.

The execution engine (120) may include a Kubernetes API server (123), a DB common management unit (121), a DB specific management unit (122), and one or more pods (210).

The DB common management unit (121) manages common parts regardless of the type of database service.

The DB common management unit (121) may include a unit set (Unitset) corresponding to two CRDs and each controller (1211, 1212) for managing the units (Unit).

A pod (210) including a container (211) in which a database is loaded and a sidecar container (212) that manages the container (211) in which a database service is executed may be one of the units.

A unitset is a unit that groups units running the same service for DB functions such as clusters and replication.

The unit controller (1212) and unit set controller (1211) included in the DB common management unit (121) can continuously check whether the unit and unit set meet the user's needs and send a request to the Kubernetes API server (123) to update them according to the user's needs.

The sidecar container (212) communicates with the container (211) containing the database and can ultimately execute requests from the controller (1211, 1212).

The DB specific management unit (122) defines and manages elements for managing a specific database service type.

The DB specific management unit (122) may include each controller (1221 to 1224) for managing MySQLReplication, ProxysqlSync, RedisReplication, and RedisCluster corresponding to four CRDs.

MySQLReplication is a CRD that continuously synchronizes data and settings to maintain a master-slave structure between units (mysql containers) within the same unit set.

ProxysqlSync is a CRD that synchronizes settings between Proxysql and the mysql connected to it.

RedisReplication is a CRD that continuously synchronizes data and settings to maintain a master-slave structure between units (redis containers) within the same unit set.

RedisCluster is a CRD that configures a cluster by synchronizing the data distribution storage settings of units (redis containers) within the same unit set.

FIG. 5 and FIG. 6 are flowcharts of an open database management method performed by an execution engine of a system according to one embodiment of the present invention, particularly a DB common management unit.

Referring to FIG. 5, the DB common management unit (121) can receive a unit set and/or unit creation request (step S310).

According to the request, the unit set controller (1211) is activated (step S311) and the shared settings (ConfigMap) are set (step S312).

Next, the unit controller (1212) is activated (step S313) and a storage space (PVC) is declared (step S314). Then, a pod is created and a cluster is deployed (step S315). A unit is created including the created pod (step S316).

It is determined whether the created unit and/or unit set is operating normally (step S317), and if not, the process returns to step S311. If it is operating normally, the creation of the unit set and/or unit is terminated.

Here, for steps S312, S314, S315, and S316, the controller (1211, 1212) can transmit the corresponding command to the Kubernetes API server (113) to be processed.

The DB common management unit (121) can receive a unit set and/or unit update request (step S320).

In response to the request, the unit set controller (1211) is activated (step S321), the shared settings (ConfigMap) are updated (step S322), the number of units is updated (step S323), and the unit template is updated (step S324). In addition, the service settings are updated (step S325).

Next, the unit controller (1212) is activated (step S326), the storage space (PVC) is updated (step S327), and the service settings are updated (step S328).

It is determined whether the updated unit and/or unit set is operating normally (step S329), and if not, the process returns to step S321. If it is operating normally, the unit set and/or unit update is terminated.

Here, for steps S322, S323, S324, S325, S327, and S328, the controller (1211, 1212) can transmit the corresponding command to the Kubernetes API server (113) to be processed.

Referring to FIG. 6, the DB common management unit (121) can receive a service creation request (step S330).

In response to a service creation request, the unit set controller (1211) is activated (step S331) and the service settings are updated (step S332).

Next, the unit controller (1212) is activated (step S333) and the service settings can be updated (step S334).

Determine whether the service created based on the updated service settings is operating normally (step S335). If not, return to step S331. If it is operating normally, service creation is terminated.

Here, in steps S331, S332, and S334, the controller (1211, 1212) can transmit the corresponding command to the Kubernetes API server (113) to be processed.

The DB common management unit (121) can receive a unit set and/or unit deletion request (step S340).

According to the request, the unit set controller (1211) is activated (step S341) and the service settings are deleted (step S342).

Next, the unit controller (1212) is activated (step S343), the service settings are deleted (step S344), the storage space (PVC) is released (step S345), the pod is deleted (step S346), and finally the unit is deleted (step S347).

After deleting a unit/unit set, determine whether it is operating normally (step S348). If it is not operating normally, return to step S341. If it is operating normally, delete of the unit set and/or unit is terminated.

Here, for steps S342, S344, S345, S346, and S347, the controller (1211, 1212) can transmit the corresponding command to the Kubernetes API server (113) to be processed.

FIG. 7 and FIG. 8 are flowcharts of an open database management method performed by an execution engine of a system according to one embodiment of the present invention, particularly a DB specific management unit.

Referring to FIG. 7, the DB specific management unit (122) can receive a request regarding a MySQLReplication event (step S360).

In this case, the MySQLReplication controller (1221) is activated (step S361). Then, MySQLReplication resource information is requested (step S362) and a MySQL administrator is created (step S363).

The MySQL administrator (step S364) creates a MySQL master-slave and updates it (step S365).

Afterwards, it is determined whether the system is operating normally (step S366), and if it is not operating normally, it returns to step S361. If it is operating normally, the MySQLReplication event is terminated.

Here, for steps S352 and S355, the controller (1221) can transmit the corresponding command to the Kubernetes API server (113) to be processed.

Additionally, the DB specific management unit (122) can receive a request regarding a ProxySQLSync event (step S370).

In this case, the ProxySQLSync controller (1222) is activated (step S371).

And, in binary form, ProxySQLSync resource information can be requested (step S372a) and a ProxySQL administrator can be created (step S373a). In addition, MySQLReplication resource information can be requested (step S372b) and a MySQL administrator can be created (step S373b).

The created ProxySQL manager (step S374a) and MySQL manager (step S374b) can be updated after synchronizing ProxySQL and MySQL (step S375).

Afterwards, it is determined whether the system is operating normally (step S376), and if it is not operating normally, it returns to step S371. If it is operating normally, the ProxySQLSync event is terminated.

Here, for steps S362a, S365a, S362b, and S365b, the controller (1222) can transmit the corresponding command to the Kubernetes API server (113) to be processed.

Referring to FIG. 8, the DB specific management unit (122) can receive a request regarding a RedisReplication event (step S380).

In this case, the RedisReplication controller (1223) is activated (step S381). Then, RedisReplication resource information is requested (step S382) and a Redis manager is created (step S383).

The created Redis manager (step S384) updates the Redis master-slave (step S385).

Afterwards, it is determined whether the system is operating normally (step S386), and if it is not operating normally, it returns to step S381. If it is operating normally, the RedisReplication event is terminated.

Here, in steps S372 and S375, the controller (1223) can transmit the corresponding command to the Kubernetes API server (113) to be processed.

Additionally, the DB specific management unit (122) can receive a request regarding a Redis Cluster event (step S390).

In this case, the Redis Cluster controller (1224) is activated (step S391). Then, Redis Cluster resource information is requested (step S392) and a Redis manager is created (step S393).

The created Redis manager (step S394) synchronizes Redis within the Redis cluster (step S395).

Afterwards, it is determined whether the system is operating normally (step S396), and if it is not operating normally, it returns to step S391. If it is operating normally, the Redis Cluster event is terminated.

Here, in steps S382 and S385, the controller (1224) can transmit the corresponding command to the Kubernetes API server (113) to be processed.

Figure 9 is a functional configuration diagram of a cloud-based open database management system according to one embodiment of the present invention.

A cloud-based open database management system (100) may functionally include a resource manager (310), a DB manager (320), and a system manager (330).

The resource manager (310) facilitates easy and stable database construction and management. It creates the units or scopes required for database configuration. It automates storage allocation and management, simplifying maintenance tasks.

The resource manager (310) can provide an easy-to-view monitoring of the unit's status, CPU and memory usage, and service status.

A project is a unit that allows you to manipulate resource object content in isolation from the resources. The project management module allows you to manage resources based on Kubernetes namespaces. By logically dividing projects into compartments, each team can operate resources independently.

This may include project creation management, which creates a project that creates an independent work environment; project activation management, which enables or disables projects to efficiently manage resources; and project modification/deletion management, which modifies project names when necessary or deletes projects that are no longer needed.

A cluster is the unit where applications are run and managed in Kubernetes. Clusters play a central role in deploying and managing resources in the system, and the cluster management module allows for the registration of multiple clusters and their central management. It supports the registration of Kubernetes clusters from various vendors, including Red Hat's OpenShift and VMware's Tanzu. It can include cluster registration, activation, modification/deletion, and resource management functions.

The Software Management module lists the versions of each database type installed in the cluster. It provides centralized, automatic distribution and activation management of database version information running within the created cluster, along with search functions. The Software Deployment feature automatically deploys and manages new database software registrations to the cluster. The Software Activation Management feature allows you to activate or deactivate software as needed, facilitating efficient resource utilization. The Software Search feature checks the status of registered software and allows you to quickly access necessary information.

The Zone Management module isolates resource areas and provides logical separation of cluster resources. Resource isolation enables stable maintenance by resolving failures within isolated resources. The Zone Add function adds zones based on a new cluster and allocates resources. The Zone Activation Management function can deactivate zones at specific times for resource management or maintenance. Deactivated zones do not receive resource allocation. The Zone Edit/Delete function can modify the name or description of a zone or delete a zone.

The Host Group management module groups machines with similar functions or applications according to business type, based on preset conditions. It can provide flexible, multi-dimensional resource configuration and management capabilities to meet diverse needs. For example, grouping by region, server rack, or similar tasks facilitates management. The Host Group Add function groups and manages hosts within clusters and zones. Host groups allow for efficient deployment by grouping servers with similar roles. The Host Group Activation Management function enables host groups to be activated or deactivated as needed. The Host Group Edit/Delete functions allow for modifying the name or description of a host group, and deleting groups that are no longer needed.

The Host management module assigns system labels to server equipment so that the platform can identify nodes. Kubernetes runs worker nodes by deploying containers into pods running on the host. Therefore, the host assigns labels to nodes so that the platform can identify and manage them. If a host experiences a problem or lacks resources, it can be isolated and restored to use once the problem is resolved. The Host Registration feature adds new hosts to the cluster and registers them with the system. The Host Isolation/Recovery feature allows you to isolate a host if it experiences a problem or lacks resources, and then restore it to use once the problem is resolved. The Host Logout feature allows you to safely log out of hosts that are no longer needed.

The Storage Class management module configures various storage dockings where data is stored. It can support a variety of storage types, from local disks to cloud-based storage. This allows you to store and manage application data. The Storage Class Registration feature registers new storage classes to provide the storage space required by applications. The Storage Class Activation Management feature allows you to manage resources by activating or deactivating storage as needed. The Storage Class Edit/Delete feature allows you to modify the name and description of storage classes, or delete unnecessary storage.

The S3 Storage management module configures S3 storage docking for backup. S3 Storage is a large-capacity data storage solution provided by Amazon. It supports integration with S3 Storage, allowing users to easily configure and manage backup strategies to achieve automatic data backup and recovery. The S3 Storage registration function allows users to register S3 Storage to securely store and back up data. The S3 Storage start/stop function enables users to activate or deactivate storage as needed, allowing for continuous backup management. The S3 Storage logout function allows users to log out of S3 Storage as needed, thereby disabling it as a backup resource. This allows for efficient data backup operations.

The DB manager (320) can configure an open database using replication and high availability deployment functions in a Kubernetes (K8s) environment based on the settings configured in the resource manager (310).

The Service Scale Management module configures multiple CPUs and memory of varying sizes. Service Scale Management is the ability to adjust resource sizes. Resources can be scaled up or down as needed, optimizing both performance and cost.

The scale-out feature allows you to freely configure the resources required by a service, such as CPU and memory. Furthermore, you can also allocate specialized resources required by each database service (e.g., ProxySQL for MySQL, Sentinel for Redis). For example, for a MySQL service, you can configure the resources allocated to it to 1 CPU and 1 GB of memory. In addition to the basic MySQL, the system can also be configured with ProxySQL to provide load balancing and high availability.

The scale enable/disable feature allows you to conserve resources by enabling them when needed and disabling them when not needed. The scale delete feature allows you to manage resources by deleting scales that are no longer needed.

The Service Order Management module allows users to create, request, inspect, and execute services. It can include replication settings and high availability options. This module allows users to request desired services and deploy them. Users can select the required services, configure resources, and place orders, much like ordering from a shopping mall.

The Add Order feature allows you to select a project and cluster to deploy a service, then configure settings like CPU, memory, and storage size. For example, you can add an order by selecting a version of a service like MySQL or Redis, setting the number of replicas, and setting the storage capacity.

In the order approval function, when the administrator reviews and approves the order, the set resources are allocated to the cluster.

The order execution feature actually deploys the service once the order is approved. You can then monitor the service's status in real time and check its progress. This feature streamlines the service deployment process, allowing you to quickly request and use desired resources.

The Service management module handles the overall operation and maintenance of the database service. This includes database version upgrades, reset sources (master/slave role distribution), backup/restore, schema and user creation and authorization, and service architecture monitoring.

The service creation feature allows you to easily deploy services like MySQL and Redis, configure the required resources, and add high-availability options to ensure stability.

The service modification and upgrade feature allows you to expand resources, such as CPU and memory, in real time if they become insufficient while the service is running. It also allows you to upgrade to the latest version of the service.

The service backup and recovery feature allows you to periodically back up service data to prevent data loss and to restore data when necessary to maintain safety.

The service status monitoring function allows you to check the status of running services, resource usage, event logs, etc. in real time, enabling a quick response when a problem occurs.

The service deletion feature allows you to safely delete services that are no longer needed, saving resources.

The Service Unit (SMU) management module allows for management and operation of individual units, the logical units where actual database services are running. It monitors and manages databases, performs backups and recovery, and enables rapid disaster recovery through service reconfiguration in the event of a failure.

The unit stop function allows you to stop a unit for maintenance work while maintaining service availability.

The Unit Start function can be used to reactivate stopped units and normalize service operation.

Unit reconfiguration capabilities maintain high service availability by reconfiguring units when problems arise or expansion is required. This ensures rapid recovery even in the event of a failure.

Real-time parameter modification allows for parameter modifications to optimize performance without service interruption. Critical parameters take effect after a reboot.

The unit status monitoring function allows you to monitor the status of CPU, memory, traffic, etc. in real time, allowing you to detect and resolve problems early.

Manage resources efficiently by safely deleting units you no longer need using the unit deletion function.

Service database management allows you to easily create and delete databases on your cluster through a GUI. Service user management allows you to create users who can access your database and grant them permissions.

The system manager (330) can manage logs of events occurring in the system. The system manager (330) can include a platform log function, which is a list of logs of events occurring.

Therefore, the system enables easy backup and recovery. Furthermore, in the event of a database failure, the roles of each server can be changed, enabling rapid response.

You can create a schema in the created open database, and you can also create users and grant them permissions for each database.

The cloud-based open database management system according to this embodiment provides a platform for easier, faster, and more convenient management of command-based Kubernetes environments, significantly reducing workload by improving staff efficiency and effectiveness. Furthermore, seamless integration of various systems streamlines operations and reduces complexity.

Additionally, sophisticated database service support is possible. The system according to this embodiment supports the sophisticated management of the following complex database operation methods.

Figure 10 is a drawing showing a DB operation support method in a system according to one embodiment of the present invention.

First, there's the Primary/Replica pattern. This pattern is widely used in RDBMSs, where one primary database is used exclusively for writes, while multiple replica databases are used exclusively for reads. By replicating data in this way, writes and reads can be separated and traffic distributed. MySQL is a prime example. This allows for efficient traffic distribution and optimized system performance.

The second is the Caching pattern. This utilizes a caching system like Redis to speed up data access. While caches can provide much faster responses than databases, cache capacity is limited, so strategic planning regarding which data to cache and how long to store it is crucial. In particular, a cache read/write strategy is essential to address data inconsistencies between the cache and the database. This system ensures both high performance and data consistency through this caching pattern.

Finally, there's the NewSQL pattern. In a distributed system, maintaining data consistency across multiple nodes is crucial. To achieve this, this system uses a Raft-based consensus algorithm to maintain data consistency. This pattern ensures that each node in a distributed database environment maintains the same state and automatically manages data synchronization and replication across multiple nodes.

In this way, this system can support stable services even in complex DB operating environments through various patterns.

The Raft (Reliable, Replicated, Redundant, and Fault-Tolerant) algorithm is a distributed consensus algorithm used in Kubernetes' etcd. The Raft algorithm is a distributed consensus method that ensures that all nodes in the cluster have the same copy of changes received from clients through log replication.

The Raft algorithm consists of nodes with three roles: leader, follower, and candidate.

The Leader communicates with clients and receives change requests. It periodically sends a heartbeat request (AppendEntry) with the changes to followers.

Followers store changes requested by the leader. They have a leader election period (Term). They wait for leader requests during the election timeout period, and when the timeout expires, they become candidates.

A candidate requests a leader election vote (RequestVote) from itself and other followers. If it receives a vote from more than half of the nodes in the cluster, it becomes the leader. Upon receiving a request from the leader, it updates its leader information and becomes a follower.

Figure 11 is a drawing showing functions provided by a system according to one embodiment of the present invention.

This system can provide flexibility for various functions and expansion of resource management, order management, platform management, and service management.

Resource management provides functions for managing system resources such as hosts, storage, and clusters. Work order management provides functions for controlling the creation, approval, and execution of tasks. Service management is a core system function, providing functions such as service modification, upgrades, and starting/stopping/deleting. Platform management provides platform management for users, groups, roles, and missions.

FIG. 12 is a diagram illustrating the configuration of a system according to one embodiment of the present invention.

Referring to FIG. 12, a cloud-based open database management system (100) includes a processor (410) and a memory (420). The memory (420) stores one or more instructions executable by the processor (410). The processor (410) executes one or more instructions stored in the memory (420). The processor (410) can perform one or more of the operations described above by executing the instructions. In addition, the configuration of the present invention described above may be a configuration implemented by instructions executed by the processor (410).

The embodiments described above may be implemented using hardware components, software components, and/or a combination of hardware components and software components. For example, the devices, methods, and components described in the embodiments may be implemented using one or more general-purpose computers or special-purpose computers, such as, for example, a processor, a controller, a central processing unit (CPU), a graphics processing unit (GPU), an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable logic unit (PLU), a microprocessor, an application specific integrated circuit (ASICS), or any other device capable of executing instructions and responding to them.

The open database management method described above can also be implemented in the form of a recording medium containing computer-executable instructions, such as an application or program module executed by a computer. The computer-readable medium can be any available medium that can be accessed by a computer, and includes both volatile and nonvolatile media, removable and non-removable media. Furthermore, the computer-readable medium can include computer storage media. The computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented using any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data.

The above-described open database management method can be executed by an application installed by default on the terminal (which may include a program included in a platform or operating system installed by default on the terminal), or by an application (i.e., a program) directly installed on the master terminal by the user through an application providing server, such as an application store server, an application, or a web server related to the service. In this sense, the above-described open database management method can be implemented as an application (i.e., a program) installed by default on the terminal or directly installed by the user, and recorded on a computer-readable recording medium such as the terminal.

Although the present invention has been described above with reference to embodiments thereof, it will be understood by those skilled in the art that various modifications and changes may be made to the present invention without departing from the spirit and scope of the present invention as set forth in the claims below.

100: Cloud-based open database management system
110: Management Platform 111: Unified Interface
112: API Server 113: Extension Module
114: Web server
120: Execution Engine 121: DB Common Management Unit
122: DB-specific management unit 123: Kubernetes API server
210: Pad 211: Container
212: Sidecar Container 310: Resource Manager
320: DB Manager 330: System Manager

Claims (13)

delete delete delete delete delete delete delete delete A computer program stored in a computer-readable storage medium to perform a cloud-based open database management method, wherein the computer program causes a computer to perform the following steps, wherein the steps are:
Step of receiving open database related events from the execution engine;
A step of activating a controller related to the open database in a DB specific management unit;
A step of requesting resource information about the open database from the controller;
A step of creating an administrator for the open database based on the above resource information;
Including a step of performing an action corresponding to the above event in the above manager,
A computer program stored in a computer-readable storage medium, characterized in that the above open database related event is a MySQLReplication event, the administrator is a MySQL administrator, and the action corresponding to the event is a MySQL master-slave update.
delete A computer program stored in a computer-readable storage medium to perform a cloud-based open database management method, wherein the computer program causes a computer to perform the following steps, wherein the steps are:
Step of receiving open database related events from the execution engine;
A step of activating a controller related to the open database in a DB specific management unit;
A step of requesting resource information about the open database from the controller;
A step of creating an administrator for the open database based on the above resource information;
Including a step of performing an action corresponding to the above event in the above manager,
A computer program stored in a computer-readable storage medium, characterized in that the above open database related event is a ProxySQLSync event, the administrator is a ProxySQL administrator and a MySQL administrator, and the action corresponding to the event is synchronization of ProxySQL and MySQL.
A computer program stored in a computer-readable storage medium to perform a cloud-based open database management method, wherein the computer program causes a computer to perform the following steps, wherein the steps are:
Step of receiving open database related events from the execution engine;
A step of activating a controller related to the open database in a DB specific management unit;
A step of requesting resource information about the open database from the controller;
A step of creating an administrator for the open database based on the above resource information;
Including a step of performing an action corresponding to the above event in the above manager,
A computer program stored in a computer-readable storage medium, characterized in that the above open database related event is a RedisReplication event, the manager is a Redis manager, and the action corresponding to the event is a Redis master-slave update.
A computer program stored in a computer-readable storage medium to perform a cloud-based open database management method, wherein the computer program causes a computer to perform the following steps, wherein the steps are:
Step of receiving open database related events from the execution engine;
A step of activating a controller related to the open database in a DB specific management unit;
A step of requesting resource information about the open database from the controller;
A step of creating an administrator for the open database based on the above resource information;
Including a step of performing an action corresponding to the above event in the above manager,
A computer program stored in a computer-readable storage medium, characterized in that the above open database related event is a Redis Cluster event, the manager is a Redis manager, and the action corresponding to the event is Redis synchronization within the Redis cluster.