Optimizing cluster applications in cluster infrastructure
By using server identification components in a cloud computing environment to collect and maintain physical server location and latency data, and providing a database instance ranking list to the application container, it solves the problem of latency and inefficiency when accessing database instances by cluster application virtual resources, and achieves efficient and low-latency access effects.
Patent Information
- Application Number
- CN202080052596.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2019-08-16
- Filing Date
- 2020-08-14
- Publication Date
- 2025-05-16
- Estimated Expiration
- 2040-08-14
AI Technical Summary
In a cloud computing environment, it is difficult for cluster applications to efficiently access database instances located in a physical server cluster, especially when database instances are distributed on different physical servers in the cluster, which can lead to access latency and inefficiency.
By implementing server identification components in a physical server cluster, collecting and maintaining the location and delay data of each physical server, providing the application container with a ranking list of database instances, and selecting the optimal database instance for access based on the proximity and delay of the physical server.
Reduces latency for virtual resources to access database instances, improves access efficiency and performance, and reduces network traffic across physical server clusters.
Smart Images

Figure CN114174993B_ABST
Abstract
Description
[0001] Related applications
[0002] This application claims priority to U.S. Patent Application No. 16 / 543,250, filed on August 16, 2019, which is incorporated herein by reference in its entirety. Technical Field
[0003] The present disclosure generally relates to providing a distributed cluster application with information about a cluster of physical servers on which the distributed cluster application is running. Background Art
[0004] Cloud computing provides users with access to computing resources to meet their computing resource needs. In some examples, service providers can manage and provide cloud computing resources to users to meet their needs without requiring users to invest in and maintain their own computing infrastructure. Cloud computing often involves the use of a data center network that contains servers, routers, and other devices that provide computing resources to users, such as computing resources, network resources, storage resources, database resources, application resources, etc. Virtualization technology can be used to allocate users a portion of computing resources that remains available during peak user demand. This virtualized portion of computing resources, or virtualized network, can be scaled up (or down) according to the computing needs of a given user without having to maintain excessive computing capacity. For example, an online retailer can scale a virtualized network of computing resources to meet the growing demand during the holiday shopping season without having to maintain the underlying physical computing infrastructure used to provide the retailer's online presence.
[0005] To support applications using cloud computing, clustering technology can be used to organize multiple physical servers into a cluster (or a group of servers that behaves like a single system). Clustered servers can improve the availability and scalability of clustered applications or services. For example, if one or more nodes (or servers) in the physical underlying cluster fails, other nodes begin providing the application or service so that the failure does not terminate the functionality of the user's clustered application.
[0006] Typically, a single physical server can use virtualization technology to run multiple application instances in a cluster application, such as multiple virtual machines and / or multiple application containers running the application. Each application container of the cluster application can access (e.g., read, write, etc.) a stable set of replicated data maintained across multiple physical servers (e.g., in a database instance). By running database instances that maintain the same data set on different physical servers in the physical underlying cluster, redundancy and high availability are provided for the application containers when accessing the data set. Therefore, in order to maintain the same data set with higher redundancy and availability, it may be advantageous to instantiate database instances (or other storage instances) on different physical servers in the physical underlying cluster. Summary of the Invention
[0007] One aspect of the present disclosure provides a physical server arranged in a physical server cluster that executes a cluster application, the physical server comprising: one or more processors; and one or more non-transitory computer-readable media storing computer-executable instructions, which, when executed by the one or more processors, cause the one or more processors to: execute virtual resources that support the cluster application, the virtual resources being included in a set of virtual resources running on each physical server in the physical server cluster; receive an indication of a database instance running on a specific physical server closest to the physical server in the physical server cluster, the database instance being included in a set of database instances that maintain a common data set, the common data set being replicated and maintained on each physical server in the physical server cluster. , the common data set runs on the physical server and is accessible to the virtual resource, the common data set is maintained across the physical server cluster that supports the set of database instances, and the receiving of an indication of a database instance running on a specific physical server that is closest to the physical server in the physical server cluster includes: receiving a ranked list of the database instances, wherein the database instances in the ranked list are ranked based at least in part on how close the physical server is to the respective physical servers that instantiate the database instances; selecting the database instance from the set of database instances based at least in part on the specific physical server that is closest to the physical server on which the virtual resource is executed; and causing the virtual resource to access the database instance on which the virtual resource is executed.
[0008] One aspect of the present disclosure provides a method for clustering applications, comprising: executing an application container on a physical server in a physical server cluster, the application container being included in a group of application containers for executing a cluster application on the physical server cluster, wherein each application container in the group of application containers runs an individual instance of an application; receiving, at the application container, an indication of a database instance running on a specific physical server closest to the physical server in the physical server cluster, the database instance being included in a group of database instances, the group of database instances maintaining a common data set, the common data set being replicated and maintained on each physical server in the physical server cluster, the common data set running on the physical server and accessible by the application container, the common data set being distributed across the group of database instances supporting In one embodiment, a physical server cluster is maintained, and receiving an indication of a database instance running on a specific physical server that is closest to the physical server in the physical server cluster includes: receiving a ranked list of the database instances at the application container, ranking the database instances based at least in part on how close the physical server of the application container is to the respective physical servers that instantiate the database instances; selecting the database instance from the group of database instances based at least in part on the specific physical server that is closest to the physical server on which the application container is executed; and accessing the database instance by the application container based at least in part on the database instance being on the specific physical server that is closest to the physical server on which the application container is executed.
[0009] One aspect of the present disclosure provides a system for cluster applications, comprising: one or more processors; and one or more non-transitory computer-readable media storing computer-executable instructions, which, when executed by the one or more processors, cause the one or more processors to: instantiate an application container on a first physical server in a physical server cluster, the application container being included in a set of application containers of a cluster application, the set of application containers being executed on the physical server cluster, wherein each application container in the set of application containers runs an individual instance of an application; and receive infrastructure data, the infrastructure data indicating respective physical servers in the physical server cluster that are running respective database instances in a set of database instances, the set of database instances maintaining a common data set, the common data set being in the physical server cluster. is replicated and maintained on each physical server of the infrastructure data, the common data set runs on the physical server and can be accessed by the application container, and the common data set is maintained across the physical server cluster that supports the set of database instances; based on the respective physical servers indicated in the infrastructure data, a second physical server closest to the first physical server is identified, including: determining a ranked list of the database instances, wherein the database instances are ranked in the ranked list based at least in part on how close the first physical server is to the respective physical servers that are running the database instances; and sending an indication to the first physical server of the database instance running on the second physical server or at least one of the second physical servers, including: sending the ranked list of database instances to the first physical server.
[0010] One aspect of the present disclosure provides a physical server arranged in a physical server cluster that executes a cluster application, the physical server comprising: a device for executing an application container on a physical server in the physical server cluster, the application container being included in a group of application containers that execute the cluster application on the physical server cluster, wherein each application container in the group of application containers runs an individual instance of an application; a device for receiving, at the application container, an indication of a database instance running on a specific physical server that is closest to the physical server in the physical server cluster, the database instance comprising a group of database instances that maintain a common data set, the common data set being replicated and maintained on each physical server in the physical server cluster, the common data set running on the physical server and accessible by the application container, the common data set spanning the group of database instances that support the application container. The physical server cluster is maintained, and the device for receiving at the application container an indication of a database instance running on a specific physical server that is closest to the physical server in the physical server cluster includes: a device for receiving at the application container a ranked list of the database instances, ranking the database instances based at least in part on how close the physical server of the application container is to the respective physical servers that instantiate the database instances; a device for selecting the database instance from the group of database instances based at least in part on the specific physical server that is closest to the physical server on which the application container is executed, and the database instance; and a device for accessing the database instance by the application container at least in part based on the database instance being located on the specific physical server that is closest to the physical server on which the application container is executed.
[0011] One aspect of the present disclosure provides a computer program product comprising instructions, which, when executed by a computer, cause the computer to perform the steps of the method described in the present disclosure.
[0012] One aspect of the present disclosure provides a computer-readable medium comprising instructions, which, when executed by a computer, causes the computer to perform the steps of the method described in the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0013] The following detailed description is provided with reference to the accompanying drawings. In each figure, the leftmost digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numeral in different figures indicates similar or identical items. The systems depicted in the figures are not drawn to scale, and components in the figures may not be drawn to scale.
[0014] Figure 1Illustrated is a system architecture diagram of an example environment in which a server identification component provides information to a distributed cluster application about a physical server cluster on which the distributed cluster application is running.
[0015] Figure 2 A component diagram illustrating an example process in which an application container on a cluster node performs a DNS lookup to identify the physical server that is running the nearest database instance.
[0016] Figure 3 A component diagram illustrating example components of a cloud computing network is illustrated.
[0017] Figure 4 A flow diagram is illustrated of an example method for a virtual resource that enables a cluster application to receive information about a database instance running on a proximal physical server in a cluster of physical servers and access the database instance.
[0018] Figure 5 A flow chart illustrating an example method for an application container that enables a clustered application to receive information about and access a database instance running on a proximal physical server in a cluster of physical servers.
[0019] Figure 6 A flow chart illustrating an example method for providing information about a physical server cluster that is running a cluster application to an application container that supports the cluster application.
[0020] Figure 7 Illustrated is a computing system diagram illustrating a configuration of a data center that can be used to implement aspects of the technology disclosed herein.
[0021] Figure 8 is a computer architecture diagram showing an illustrative computer hardware architecture for implementing a server device that can be used to implement aspects of the various techniques presented herein. DETAILED DESCRIPTION
[0022] Overview
[0023] Various aspects of the invention are set out in the independent claims and preferred features are set out in the dependent claims. Features of one aspect may be applicable to each aspect alone or in combination with other aspects.
[0024] The present disclosure describes a technique for providing virtual resources (e.g., containers, virtual machines, etc.) of a cluster application with information about a physical server cluster on which the distributed cluster application is running. The method includes executing virtual resources that support the cluster application on a physical server in the physical server cluster. The method also includes receiving an indication of a database instance running on a specific physical server in the physical server cluster that is closest to the physical server. The database instance can be included in a group of database instances that maintain a common data set on each physical server in the physical server group. In addition, the method includes enabling the virtual resource to access the database instance on the specific physical server based at least in part on the database instance running on the specific server that is closest to the physical server.
[0025] Furthermore, the techniques described herein may be performed by a system and / or device having a non-transitory computer-readable medium having stored thereon computer-executable instructions that, when executed by one or more processors, perform the methods described above.
[0026] Example Embodiments
[0027] The usefulness of server virtualization (from virtual machines to containers to storage devices) has led to the rapid growth of cloud computing and data centers. Using virtualization technology, a single physical server can use server virtualization (e.g., a software layer called a hypervisor) to host multiple applications, operating systems and / or data storage instances. In this way, multiple applications or processes can be executed on a single physical server to improve the overall hardware utilization of the physical server. Some cloud computing systems can utilize application clusters (or software clusters), in which multiple physical servers become physical server clusters or server groups, just like a single system. Each server in the physical cluster maintains the same data set and runs or supports the same application (referred to herein as a cluster application) together. For example, a virtual machine (VM) and / or an application container can run the process of an application to provide a distributed cluster application. Distributed cluster applications running on a physical server cluster have multiple advantages, such as improved availability, improved scalability and failover protection.
[0028] In a cluster application, multiple application containers (or other virtual resources) can run on a single server, with each application container running a separate instance of an application or service. Since these application containers are running instances of the same application, these containers typically need to access the same data set that supports or is used by the application. For example, an online retailer can use cloud computing to support a cluster application that includes multiple application containers, which are scaled to process orders made using the retailer's online site or application. These application containers may need to access a common data set, such as a catalog of goods provided by the retailer, data used to perform transactions, etc. Therefore, a physical server cluster can further support a set of database instances running on these physical servers to maintain the same data set on these physical servers that can be accessed by the application containers. These database instances can run within the containers themselves on multiple physical servers, so that these containers form the cluster itself, or form a group of database instances.
[0029] Typically, each database instance may have an affinity that is tied to the physical server where the actual persistent data set or volume is stored. Application containers running instances of clustered applications may be provided with a list of members of a database instance group because these application containers can utilize any database instance on any physical server (or node) in the underlying cluster (since each database instance in the group maintains the same data set). However, because these containers can utilize any database instance, inefficiencies may occur when the application container accesses (e.g., reads or writes) a specific database instance. For example, an application container may be running on a first physical server in a cluster of physical servers and determine to access a data set maintained by a database instance running on a second physical server in the cluster.
[0030] However, because the application container has no knowledge of the cluster's physical server infrastructure and where the database instance is running, the second physical server may be located at a relatively long distance from the first physical server, which may result in undesirable latency. For example, the distance between the first and second servers may be large and / or may require a large number of hops between nodes, which may result in excessive latency when the application container accesses the dataset. Therefore, because any dataset maintained by various database instances may be utilized by the application container, and because the application container has no knowledge of the location of the server running the database instance, the application container may access a dataset located on a physical server in the underlying cluster, which may result in undesirable latency.
[0031] The present disclosure describes a technique for providing information to an application container (and / or other virtual resources) of a cluster application that indicates the location of servers included in a physical server cluster that are running a distributed cluster application. As described above, a cluster application can access a common data set that is replicated and maintained across a physical server cluster by a group of database instances running on the physical server cluster. The techniques described herein include providing information to an application container about which database instance is running locally on the same physical server as the application container or is otherwise located "closest" to the application container. In this way, the application container can target the local database instance or otherwise nearest database instance that maintains the data set to reduce latency in access events performed by the application container.
[0032] In some examples, the server identification component can identify which containers or other virtual resources are instantiated on different physical servers in a physical cluster. For example, the server identification component can be included in or associated with a scheduler / orchestrator for an application container, database instance, or the like. When a physical server or node is added to the underlying physical cluster, the server identification component can identify the database instance or other container service instantiated on each physical node in the physical cluster. When a new database instance is instantiated, the server identification component can algorithmically name the instance using a scheme that provides a uniquely identifiable DNS entry for each database instance.
[0033] In some examples, the server identification component can maintain various physical cluster data, such as server location data indicating the location of physical servers in the cluster, latency data indicating latency between different physical servers, resource availability data indicating how much capacity the physical servers have, and / or other data. The server identification component can periodically or continuously collect data to determine the location of the physical servers relative to each other, and the total latency of access events between the physical servers. The server identification component can store indications of which database instances are running on which physical servers in the physical cluster, as well as indications of where containers are instantiated, where they are running, or where they will be instantiated. The server identification component can determine the nearest database instance for a container based on various metrics, such as geographic proximity and / or latency between the various servers running the container and the database instance.
[0034] When a new container application is added or instantiated on the physical cluster, the server identification component can transmit the name or other indication of the nearest database instance (e.g., a locally running database instance) to the container application. The container application can then store the indication of the nearest database instance, and when the container application needs to access (e.g., read, write, etc.) the replicated data set maintained by the database instance, the container application can communicate with the nearest database instance.
[0035] In some examples, the server identification component can provide the application container with a ranked list of database instances, where the database instances are ranked based on how close they are to the application container (e.g., location proximity, latency, etc.). The application container can access the highest-ranked or closest database instance indicated in the list. However, if there is a problem accessing a database instance ranked higher in the list (e.g., timeout, database instance failure, etc.), the application container can move down the ranked database instance list to access the next closest database instance to the container. In this way, the time and resources required for the application container to access the database instance are reduced, and the performance of the application container is improved.
[0036] While the techniques described herein primarily refer to application containers, they are generally applicable to any virtualized computing resource, including virtual machines. Furthermore, while these techniques are described with reference to distributed database applications, they are equally applicable to any distributed application deployed on a cluster of physical servers. For example, these techniques can be equally applicable to storage instances that provide object storage or other long-term storage and / or larger object storage.
[0037] The techniques described herein provide various improvements and efficiencies related to distributed clustered applications. For example, the techniques described herein can reduce the amount of time or latency required for an application container or other virtual resource of a clustered application to process workloads and / or respond to requests. Furthermore, because the application container accesses the nearest database instance, rather than a database instance that may be located on a server far from the application container in the physical cluster, the techniques described herein can be used to reduce the amount of network traffic across the physical server cluster.
[0038] Below will be more fully described certain embodiments and examples of the present disclosure with reference to the accompanying drawings, in which various aspects are shown. However, these various aspects can be implemented in many different forms and should not be construed as being limited to the embodiments set forth herein. The present disclosure includes various variations of the embodiments as described herein. The same numbers always refer to the same elements.
[0039] Figure 1 A system architecture diagram of an example environment 100 is illustrated in which a server identification component provides information to a distributed cluster application about a physical server cluster on which the distributed cluster application is running.
[0040] In some examples, computing resources of cloud computing network 102 can be utilized by virtual workload orchestration component 104 to instantiate, support, run, and / or execute virtual resources (e.g., virtual machines, containers, etc.). Cloud computing network 102 can include a cluster of managed physical servers 106(1)-106(N), where N is any integer greater than 1. Servers 106 can be stored in data centers whose locations are distributed across geographic regions. Cloud computing network 102 can be a distributed network through which users (typically customers) can interact via user devices to manage or otherwise interact with services provided by cloud computing network 102.
[0041] The cloud computing network 102 can provide on-demand availability of computing system resources, such as data storage, computing power (e.g., CPU, GPU, etc.), networks, databases, etc., without the need for direct active management by users. In some examples, the cloud computing network 102 can be managed and maintained by a service provider, so that users do not have to invest in and maintain computing infrastructure for their computing resource needs. Typically, users can be provided with access to or allocated use of a portion of the computing resources in the cloud computing network 102. The cloud computing network 102 can be scaled based on the needs of individual users, such as by adding resources or reducing resources. Some parts of the cloud computing network 102 can be allocated using hardware virtualization so that these parts of the cloud computing network 102 can be configured and managed by users (e.g., security configuration, load balancing configuration, etc.). However, the cloud computing network 102 does not have to be managed by a service provider and can be managed by any entity, including the users themselves who run applications or services. In
[0042] In some examples, a user of cloud computing network 102 may request that multiple physical servers 106 in cloud computing network 102 be grouped into a physical cluster 110, where each server 106 is a cluster node 108. Generally, a physical cluster 110 may refer to a group of servers 106 that work together in a system or network to provide users with benefits such as higher availability of applications or services. Each node 108 in a physical cluster 110 may run or execute one or more virtual resources, such as application containers 112, virtual machines, and the like, that run applications, services, processes, and the like. By running application containers 112 on different cluster nodes 108, physical cluster 110 can reduce downtime and disruptions by allowing another server 106 to take over in the event of an outage. For example, if one of the servers 106 experiences a service outage, the workload on that server 106 can be redistributed to another server 106 before clients experience any downtime. In this way, physical cluster 110 can support applications and services with higher levels of availability, reliability, and scalability than those provided by a single server 106.
[0043] As described above, each physical server 106 (or cluster node 108) in the physical cluster 110 can support one or more application containers 112. The application containers 112 can each encapsulate the files, dependencies, libraries, etc. of an application or service to run on the operating system of the physical server 106. In some examples, a single physical server 106 can run multiple application containers 112 on the same operating system at the same time. In this way, the physical server 106 can run multiple application containers 112, each running a separate instance of the same application. However, in some examples, the physical server 106 can run one or more virtual machines, each of which runs a separate instance of an application, service, or other process. The application containers 112 can generally run or support any service, application, cluster environment, etc.
[0044] In some examples, application containers 112 of a cluster application can access (e.g., read, write, etc.) one or more dataset replicas 116(1)-116(N) maintained across multiple physical servers 106, such as through corresponding database instances 114 running on the physical servers 106 storing the dataset replicas 116. The database instances 114 can be included in a database instance group 118 running on the physical cluster 110. For example, the database instances 114 can run within containers themselves on the multiple physical servers 106, such that the containers form the cluster itself, or form the database instance group 118.
[0045] Typically, each database instance 114 has an affinity to the physical server 106 that stores the actual persistent dataset replica 116 or volume. By running database instances 114 that maintain the same dataset 116 on different physical servers 106 in the physical cluster 110, redundancy and high availability are provided for application containers 112 when accessing the dataset 116. Therefore, to maintain dataset replicas 116 with greater redundancy and availability, it may be advantageous to instantiate database instances 114 (or other storage instances) on different physical servers 106 in the physical cluster 110.
[0046] As described above, an application container 112 can generally utilize any database instance 114 in a group 118 because these database instances maintain a common dataset replica 116. However, inefficiencies may exist when an application container 112 accesses (e.g., reads or writes) a particular database instance 114. For example, an application container 112 may be running on a first physical server 106(1) in a physical cluster 110 and determine to access a dataset replica 116(N) maintained by a database instance 114(1) running on a second physical server 106(N) in the physical cluster 110. However, the second physical server 106(N) may be located a relatively long distance from the first physical server 106(1) in the physical cluster 110, which may result in undesirable delays.
[0047] The techniques described herein include collecting various data, such as infrastructure data and location data of the physical cluster 110 that indicates on which physical server 106 the application container 112 and database instance 114 are running. In some examples, the virtual workload orchestration component 104 can be an orchestration platform for the application container 112 that manages containerized applications in a cluster environment. The virtual workload orchestration component 104 can perform or manage tasks such as application container 112 deployment, scaling, configuration, version control, rolling updates, etc. The virtual workload orchestration component 104 can include a scheduler component 120 that manages cluster applications by deploying application containers 112 to cluster nodes 108. Generally, the scheduler component 120 attempts to match the application container 112 and / or database instance 114 to an appropriate set of resources on the cluster node 108, in accordance with techniques known in the art.
[0048] The virtual workload orchestration component 104 may include a server identification component 122 that determines on which physical server 106 the application container 112 and database instance 114 are running. For example, the server identification component 122 can identify the application container 112, database instance 114, and / or other container services to be instantiated on each cluster node 108 in the physical cluster 110. When a new database instance 114 is instantiated, the server identification component 122 can algorithmically name the database instance 114 using a scheme that provides a uniquely identifiable DNS entry for each database instance 114. The server identification component 122 can uniquely name the database instance 114 so that the application container 112 can perform a DNS lookup to identify the location of the database instance 114.
[0049] In some examples, the server identification component 122 can maintain various data about the physical cluster 110, such as server location data indicating the location of the physical servers 106 in the physical cluster 110, latency data indicating the latency between different physical servers 106, resource availability data indicating how much capacity the physical servers 106 have, and / or other data. The server identification component 122 can periodically or continuously collect data to determine the location of the physical servers 106 relative to each other and the total latency of access events between the physical servers 106. The server identification component 122 can store an indication of which database instances 114 are running on which physical servers 106 in the physical cluster 110, as well as an indication of where the application container 112 is instantiated, where it is running, or where it will be instantiated. The server identification component 122 can determine the nearest database instance(s) 114 to the application container 112 based on various metrics, such as the geographic proximity and / or latency between the physical servers 106 running the application container 112 and the database instance 114.
[0050] When a new application container 112 is added or instantiated on the physical cluster 110, the server identification component 122 can transmit the name or other indication of the nearest database instance 114 (e.g., a database instance running locally) to the application container 112. Additionally or alternatively, the server identification component 122 can continuously or periodically send updated indications of the nearest database instance 114 to the application container 112. The application container 112 can then store the indication of the nearest database instance 114 and communicate with the nearest database instance 114 when the application container 112 needs to access (e.g., read, write, etc.) the dataset replica 116 maintained by the database instance 114.
[0051] In some examples, the server identification component 122 can provide the application container 112 with a ranked list 124 of database instances 114, where the database instances 114 are ranked based on how close they are to the application container 112 to which the list 124 is provided (e.g., location proximity, latency, etc.). The application container 112 can access the highest-ranked or closest database instance 114 indicated in the ranked list 124. However, if there is a problem accessing the highest-ranked database instance 114 in the ranked list 124 (e.g., a timeout, a database instance failure, etc.), the application container 112 can move down the ranked list 124 of ranked database instances 114 to access the next closest database instance 114 to the application container 112. In this way, the time and amount of resources required for the application container 112 to access the database instance 114 are reduced, and the performance of the application container 112 is improved.
[0052] like Figure 2 As described in more detail in , the application container 112 can perform a DNS lookup to identify the location of the nearest database instance 114 based on the name of the database instance 114 provided in the ranked list 124. However, in some examples, as opposed to the ranked list 124, only an indication or name of only the nearest database instance 114 can be provided to the application container 112.
[0053] As shown, the application container 112 running on cluster node 108(1) may have received an indication that database instance 114(1) is running locally on cluster node 108(1) and that database instance 114(1) is the closest instance maintaining a dataset copy 116(1). Therefore, the application container 112 running on cluster node 108(1) can access the dataset copy 116(1) maintained by database instance 114(1). As further shown, the application container 112 running on cluster node 108(2) can receive an indication that the closest database instance 114(1) is running on cluster node 108(1) and access the dataset copy 116(1) maintained by that database instance 114(1). In addition, in some examples, if the closest database instance 114 fails, the application container 112 can begin accessing the next highest ranked database instance 114 in the ranked list 124 provided by the virtual workload orchestration component 104.
[0054] In some examples, virtual workload orchestration component 104 may place an upper limit on the number of database instances 114 such that the number of members in database instance group 118 is less than the size (or number of members) of physical cluster 110. This upper limit may be beneficial or desirable when there are a large number of physical servers 106 in the underlying physical cluster 110. As another example, virtual workload orchestration component 104 may wish to limit database instances 114 to physical node members and avoid virtual machine (VM)-based node members.
[0055] In some examples, the number of application containers 112 can be scaled based on the number of users 126 interacting with the clustered application. Users 126 can include one or more individual users, groups of users, organizations, businesses, or other entities that interact with the cloud computing network 102 via respective user devices 128. User devices 128 can be any type of computing device capable of connecting to the cloud computing network 102 via a suitable data communications network 130, such as, but not limited to, laptop or desktop computers, tablet computing devices, server computers, televisions, or mobile phones. Administrative users employed by the operator of the cloud computing network 102, such as administrators who manage the operation of the cloud computing network 102, can also connect to, manage, and utilize resources provided by the service provider network 102 in a similar manner.
[0056] Users 126 may provide input data 132 via network(s) 130 to interact with cluster applications supported by application containers 112 running on physical cluster 110. For example, users 126 may submit requests such as to process data, retrieve data, store data, etc., causing application containers 112 to be added or subtracted to handle the requests based on demand.
[0057] In some cases, server identification component 122 may not be included in virtual workload orchestration component 104. Instead, server identification component 122 may be in another service or component, depending on the architecture and associated components of cloud computing network 102. In a further example, server identification component 122 may be included in scheduler component 120. In general, the logic of server identification component 122 may be located in different locations, associated with different entities, run on different servers, include logic across multiple servers, and / or be any other arrangement depending on the architecture being utilized.
[0058] Figure 2 A component diagram 200 illustrates an example process for an application container 112 on a cluster node 108 to perform a DNS lookup to identify a physical server 106 that is running a nearest database instance 114. As shown, a server identification component 122 can provide a ranked list 124(1) of names of database instances 114 to an application container 112 running on a cluster node 108(1). The application container 112 can store the ranked list 124(1) of database instances 114 locally on the cluster node 108(1).
[0059] In some examples, the names of the database instances 114 in the ranked list may indicate which cluster node 108 the corresponding database instance 114 is running on. For example, the name indicating the database instance 114 may also indicate the name of the associated cluster node 108. Furthermore, the name may also indicate whether the database instance 114 is on a local cluster node 108 (e.g., the application container 112 and the database instance 114 are running on the same cluster node 108) or on a remote cluster node 108.
[0060] To determine the address of the cluster node 108 that is executing the nearest database instance 114, the application container 112 can utilize the DNS server 204 to perform a DNS lookup 202. For example, the application container 112 can forward or provide the name (e.g., domain name) of the nearest database instance 114 to the DNS server 204 in the DNS lookup request 202. The DNS server can then find an entry in the DNS table 206 that corresponds to the name of the nearest database instance 114. The address can include an IP address, a MAC address, and / or any other type of address that can locate the nearest database instance 114. The DNS server 204 can identify the corresponding address and return the address to the application container 112 on the cluster node 108(1). The application container 112 can then access the database instance 114(1) using the address provided from the DNS server 204. In some instances, the nearest database instance 114 is a local database instance 114(1) running on the same cluster node 108(1) as the application container 112. However, in some examples, the closest database instance 114 may be located on another cluster node 108 in the physical cluster 110 that is closest (eg, lowest latency, closest geographical proximity, etc.) to the application container 112 on cluster node 108 ( 1 ).
[0061] Figure 3 A component diagram 300 of example components of a cloud computing network 102 is illustrated. As shown, the service provider network 102 may include one or more hardware processors 302 (processors) configured to execute one or more stored instructions. The processor(s) 302 may include one or more cores. Additionally, the cloud computing network 102 may include one or more network interfaces 304 configured to provide communication between the cloud computing network 102 and other devices (e.g., user device(s) 128) and between devices in the cloud computing network 102 (e.g., cluster nodes 108, load balancers, routers, etc.). The network interfaces 304 may include devices configured to couple to personal area networks (PANs), wired and wireless local area networks (LANs), wired and wireless wide area networks (WANs), and the like. For example, the network interfaces 304 may include interfaces to Ethernet, Wi-Fi, and the like. TM and other compatible devices.
[0062] The cloud computing network 102 may include a computer-readable medium 306 storing one or more operating systems 310. The operating system(s) 310 may generally support basic functionality of devices in the cloud computing network 102, such as scheduling tasks on the devices, executing applications on the devices, controlling peripheral devices, and the like. The computer-readable medium 306 may also store a virtual workload orchestration component 104, which is configured to perform at least the functions described herein when executed by the processor(s) 302. In addition to the scheduler component 120 and the server identification component 122, the virtual workload orchestration component 104 may also store one or more controller components 312 and one or more APIs 314.
[0063] The controller component 312 can perform routine tasks to ensure that the desired state of the database instances 114 and / or application containers 112 matches the observed state. For example, the controller component 312 can determine that the correct number of application containers 112 and / or database instances 114 are running for their respective clusters or groups. For example, the controller component 312 can identify the state of the physical server 106 and respond when the server 106 is down. In some examples, the controller component 312 can identify the state of the physical server to respond to, such as when a component within the server 106 causes the server 106 to be "down", when a virtual machine instance fails, and / or when any other event to which the controller component 312 is to respond may occur. The API 314 can generally serve as the basis for a declarative configuration scheme for the virtual workload orchestration component 104.
[0064] The cloud computing network 102 may also include the aforementioned physical cluster 110, which in turn includes cluster nodes 108 that are executing application containers 112 and database instances 114. For example, each cluster node 108 may include one or more processors 302 configured to execute the application containers 112 (and / or virtual machines) and database instances 114 (and / or other storage instances) described herein.
[0065] The cloud computing network 102 may include a data repository 308 stored on a device of the cloud computing network 102 or across multiple devices of the cloud computing network 102. The data repository may include a file repository 316, which includes one or more images. These images may include static files containing executable code for running isolated processes, such as application container 112 images, virtual machine images, database instance 114 images, etc. Images 318 may include system libraries, system tools, and other platform settings that software programs need to run on the virtualized platform.
[0066] The data repository 308 may also store physical cluster data 330, such as server location data 332, latency data 334, and resource availability data 336. Server location data 332 may include various types of data indicating the location of cluster nodes 108. For example, server location data 332 may indicate the geographic location of cluster nodes 108, the physical distance between cluster nodes 108, the network communication distance between cluster nodes, and the like. Latency data 334 may indicate the latency between cluster nodes 108. For example, latency data 334 may indicate the latency between cluster nodes 108, allowing the total latency between any two nodes in the physical cluster 110 to be determined. Resource availability data 336 may indicate the amount of different types of computing resources (e.g., compute, storage, database, network, etc.) available on each cluster node 108. In some cases, resource availability data 336 may be considered when determining which database instance 114 an application container 112 is to access. For example, if two database instances 114 are both in close proximity to an application container 112, the application container 112 may access the database instance 114 with greater resource availability.
[0067] The server identification component 122 can utilize one or more of the server location data 332, the latency data 334, and / or the resource availability data 336 to determine a ranked list 124 of database instances 114 as described herein (e.g., ranking based on lowest latency, ranking based on closest location, considering resource availability among multiple nearby instances, etc.). Additionally, the data repository 308 can store database instance names 338 that are determined for different database instances 114 based on the physical servers 106 on which they are running.
[0068] Figure 4 、 Figure 5 and Figure 6 Flowcharts illustrating example methods 400, 500, and 600 are shown, which illustrate methods that are at least partially Figure 1-Figure 3 Various aspects of the functions performed by the cloud computing network 102 described in this document. Figure 4 、 Figure 5 and Figure 6 The logical operations described may be implemented as: (1) a sequence of computer-implemented acts or program modules running on a computing system and / or (2) interconnected machine logic circuits or circuit modules within the computing system.
[0069] The implementation of the various components described herein is a matter of choice depending on the performance and other requirements of the computing system. Therefore, the logical operations described herein are variously referred to as operations, structural devices, actions, or modules. These operations, structural devices, actions, and modules may be implemented in software, firmware, dedicated digital logic, and any combination thereof. It should also be understood that more than one operation may be performed. Figure 4 、 Figure 5 and Figure 6 and more or fewer operations as shown in the description herein. These operations may also be performed in parallel, or in a different order than those described herein. Some or all of these operations may also be performed by components other than those specifically identified. Although the techniques described in this disclosure refer to specific components, in other examples, these techniques may be implemented with fewer components, more components, different components, or components in any configuration.
[0070] Figure 4 A flow chart is illustrated of an example method 400 for a virtual resource (e.g., an application container 112, a virtual machine, etc.) that enables a cluster application to receive information about and access a database instance 114 running on a nearest physical server 106 in a physical server cluster. The virtual resource may be executed on one or more processors of a physical server 106 included in a physical cluster 110. The physical server 106 may include one or more processors and one or more non-transitory computer-readable media storing computer-readable executable instructions (e.g., an application container 112) that, when executed by the one or more processors, cause the one or more processors to perform the method 400.
[0071] At 402, a physical server 106 may execute virtual resources (e.g., application containers 112, virtual machines, etc.) that support a clustered application. The virtual resources may be included in a set of virtual resources that run on individual physical servers 106 in a physical server cluster (e.g., physical cluster 110) and support the clustered application. The virtual resources may execute after instantiation or during normal execution of an application or service.
[0072] At 404, the physical server 106 may receive an indication of a database instance 114 running on a particular physical server 105 that is closest to the physical server 106 in the physical server cluster 110. The database instance 114 may be included in a group of database instances (e.g., database instance group 118) that maintain a common data set (e.g., data set replica 116) on various physical servers 106 in the physical server cluster 110.
[0073] At 406, the physical server 106 can select the database instance 114 from the set of database instances 118 based at least in part on the particular physical server 106 being closest to the physical server 106. In some examples, the particular physical server 106 running the database instance 114 can be the same physical server 106 running (e.g., locally) the virtual resource. In some examples, the particular physical server 106 is a different physical server from the physical server 106, and the particular physical server 106 running the database instance 114 is closest to the physical server 106 of the virtual resource such that at least one of the following occurs: the virtual resource accesses the database instance 114 from the set of database instances with minimal network latency, or the physical server 106 is located closest to the particular physical server 106 in the physical server cluster 110.
[0074] At 408 , the physical server 106 may enable the virtual resource to access the database instance 114 (eg, read data from and / or write data to the dataset replica 116 ).
[0075] In some examples, the method 400 performed by the physical server 106 may also include receiving a ranked list 124 of database instances 114, where the database instances 114 are ranked based at least in part on how close the physical server 106 is to the respective physical servers 106 on which the database instances 114 are instantiated. In an example, if the physical server 106 determines that a database instance 114 running on a particular physical server 106 is not available for access by the virtual resource (e.g., due to a failure), the physical server 106 may identify a secondary database instance 114 from the ranked list 124 that is accessible to the virtual resource and enable the virtual resource to access the secondary database instance 114.
[0076] Figure 5 A flow diagram is illustrated of an example method 500 for an application container 112 that enables a clustered application to receive information about and access a database instance 114 running on a nearest physical server 106 in a cluster of physical servers 110 .
[0077] At 502 , an application container 112 can be executed on a physical server 106 in a physical server cluster 110 . In some examples, the application container 112 is included in a set of application containers 112 of a cluster application executing on the physical server cluster 110 .
[0078] At 504, the application container 112 may receive an indication (e.g., a domain name) of a database instance 114 running on a particular physical server 106 that is closest to the physical server 106 in the physical server cluster 110. The database instance 114 may be included in a set of database instances 118 that maintain a common data set 116 on various physical servers 106 in the physical server cluster 110.
[0079] At 506, the application container 112 can select a database instance 114 from the set of database instances 118 based at least in part on the particular physical server 106 being closest to the physical server 106. For example, the application container 112 can identify the database instance 114 as the closest database instance 114 based on the ranked list 124 (or an indication of a single, closest instance 114).
[0080] At 508, the application container 112 can access the particular database instance 114 based at least in part on the particular server 106 being closest to the physical server 106. For example, the application container 112 can read from, write to, or otherwise access the dataset replica 116 maintained by the database instance 114 determined to be the closest application container 112.
[0081] Figure 6 A flow chart of an example method 600 for providing information about a physical server cluster 110 running a cluster application to an application container 112 supporting a cluster application is shown. In some examples, the method 600 can be performed by a system including one or more processors and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform various operations. The system performing the method 600 can be on a single device or on multiple devices, each having at least one corresponding processor. In some examples, the system can correspond to or include one or more components of the virtual workload orchestration component 104.
[0082] At 602 , the system can instantiate an application container 112 on a first physical server 106 in a physical server cluster 110 . In an example, the application container 112 is included in a set of application containers of a cluster application executing on the physical server cluster 110 .
[0083] At 604, the system can receive infrastructure data (e.g., physical cluster data 330) indicating respective physical servers 106 in the physical server cluster 110 that are running respective database instances 114 in a set of database instances 118. The set of database instances 114 can maintain a common data set (e.g., data set replicas 116).
[0084] At 606, the system may identify, from the various physical servers 106 indicated in the infrastructure data, a second physical server 106 that is closest to the first physical server 106. A particular database instance 114 may be indicated as running on the second physical server 106 based on the stored indications of servers 106 running application containers 112 and instances 114.
[0085] At 608, the system can send an indication of the specific database instance 114 to the first physical server 106 or at least one of the second physical server 106. For example, the system can send a notification to the application container (or the first physical server 106 that is running the application container 112) indicating the name of the specific database instance 114 and / or only indicating the second physical server 106 that is running the specific database instance 114.
[0086] In some examples, the system can further determine (using latency data 334) a network latency between the first physical server 106 and each physical server 106 in the physical server cluster 110 that is running each database instance 114. The system can then determine that the network latency between the first physical server 106 and the second physical server 106 is the lowest of the network latency. In an example, the second physical server 106 is identified as being closest to the first physical server 106 based at least in part on the network latency being the lowest of the network latency.
[0087] In an example, the system may further determine (using the infrastructure data) a location of each physical server 106 in the physical server cluster 110 that is running each database instance 114. The system may further determine, based on the location, that a first location of the first physical server 106 is closest to a second location of the second physical server 106 among the locations of the physical servers 106. In an example, the second physical server 106 is identified as being closest to the first physical server 106 based at least in part on the first location being closest to the second location.
[0088] Figure 7 is a computing system diagram illustrating the configuration of a data center 700 that can be used to implement aspects of the technology disclosed herein. Figure 7The example data center 700 shown in FIG. 1 includes several server computers 702A-702F (which may be referred to herein as "server computer 702" in the singular or as "server computers 702" in the plural) for providing computing resources. In some examples, the resources and / or server computers 702 may include or correspond to the physical servers 106 described herein.
[0089] The server computers 702 can be standard tower, rack, or blade server computers that are appropriately configured to provide the computing resources described herein. As described above, the computing resources provided by the cloud computing network 102 can be data processing resources, such as VM instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, network resources, etc. Some servers 702 can also be configured to execute resource managers that can instantiate and / or manage computing resources. For example, in the case of VM instances, the resource manager can be a hypervisor or other type of program configured to enable multiple VM instances to execute on a single server computer 702. The server computers 702 in the data center 700 can also be configured to provide network services and other types of services.
[0090] exist Figure 7 In the example data center 700 shown in FIG, an appropriate LAN 708 is also utilized to interconnect the server computers 702A-702F. It should be understood that the configuration and network topology described herein have been greatly simplified, and that many more computing systems, software components, networks, and network devices may be utilized to interconnect the various computing systems disclosed herein and provide the functionality described above. Appropriate load balancing devices or other types of network infrastructure components may also be used to balance the load between the data centers 700, between each of the server computers 702A-702F in each data center 700, and possibly between the computing resources in each server computer 702. It should be understood that reference to FIG. Figure 7 The depicted configuration of data center 700 is illustrative only and other implementations may be utilized.
[0091] like Figure 7 As shown in , server computers 702 can each execute one or more application containers 112 that access dataset replicas 116 managed and maintained by database instances 114. In general, server computers 702 can run application containers 112 designated to support a single cluster application or designated for multiple cluster applications.
[0092] In some instances, cloud computing network 102 can provide computing resources, such as application containers 112, VM instances, and storage, on a permanent or on-demand basis. Among other types of functionality, the computing resources provided by cloud computing network 102 can be used to implement the various services described above. The computing resources provided by cloud computing network 102 can include various types of computing resources, such as data processing resources, such as application containers 112 and VM instances, data storage resources, network resources, data communication resources, network services, and the like.
[0093] Each type of computing resource provided by cloud computing network 102 can be general purpose or available in a variety of specific configurations. For example, data processing resources can be available as physical computers or VM instances in a variety of different configurations. VM instances can be configured to execute applications, including web servers, application servers, media servers, database servers, some or all of the aforementioned network services, and / or other types of programs. Data storage resources can include file storage devices, block storage devices, etc. Cloud computing network 102 can also be configured to provide other types of computing resources not specifically mentioned herein.
[0094] In one embodiment, the computing resources provided by the cloud computing network 102 may be enabled by one or more data centers 700 (referred to herein as "data center 700" in the singular or as "data center 700" in the plural). A data center 700 is a facility for housing and operating computer systems and associated components. A data center 700 typically includes redundant and backup power, communications, cooling, and security systems. The data centers 700 may also be located in geographically different locations. An illustrative embodiment of a data center 700 that can be used to implement the technology disclosed herein will be described below with reference to Figure 7 Provide a description.
[0095] Figure 8 An example computer architecture is shown for a server computer 702 capable of executing program components for implementing the functionality described above. Figure 8 The computer architecture shown in the diagram illustrates a traditional server computer, workstation, desktop computer, laptop computer, tablet computer, network device, e-reader, smart phone or other computing device, and can be used to execute any software components presented herein. In some examples, server computer 702 can correspond to physical server 106 described herein.
[0096] The computer 702 includes a substrate 802 or "motherboard" that is a printed circuit board to which multiple components or devices can be connected via a system bus or other electrical communication path. In one illustrative configuration, one or more central processing units ("CPUs") 804 operate in conjunction with a chipset 806. The CPU 804 can be a standard programmable processor that performs the arithmetic and logic operations required for the operation of the computer 702.
[0097] The CPU 804 performs operations by manipulating switching elements that distinguish and change discrete physical states from one state to the next. Switching elements typically include electronic circuits that maintain one of two binary states (e.g., flip-flops) and electronic circuits that provide an output state based on a logical combination of the states of one or more other switching elements (e.g., logic gates). These basic switching elements can be combined to create more complex logic circuits, including registers, adder-subtractors, arithmetic logic units, floating-point units, and the like.
[0098] Chipset 806 provides an interface between CPU 804 and the remaining components and devices on substrate 802. Chipset 806 can provide an interface to RAM 808, which serves as the main memory in computer 702. Chipset 806 can also provide an interface to computer-readable storage media, such as read-only memory ("ROM") 810 or non-volatile RAM ("NVRAM"), for storing basic routines that help start computer 702 and transfer information between various components and devices. Depending on the configuration described herein, ROM 810 or NVRAM can also store other software components required for the operation of computer 702.
[0099] The computer 702 can operate in a networked environment using logical connections to remote computing devices and computer systems via a network, such as network 708. Chipset 806 may include functionality for providing network connectivity via NIC 812 (e.g., a Gigabit Ethernet adapter). NIC 812 is capable of connecting the computer 702 to other computing devices via network 708 (or 130). It should be understood that multiple NICs 812 may be present in the computer 702, thereby connecting the computer to other types of networks and remote computer systems.
[0100] The computer 702 can be connected to a storage device 818 that provides non-volatile storage for the computer. The storage device 818 can store an operating system 820, programs 822, and data, which have been described in more detail herein. The storage device 818 can be connected to the computer 702 via a storage controller 814 connected to the chipset 806. The storage device 818 can be composed of one or more physical storage units. The storage controller 814 can interface with the physical storage units via a serial attached SCSI ("SAS") interface, a serial advanced technology connection ("SATA") interface, a fiber channel ("FC") interface, or other types of interfaces to physically connect and transfer data between the computer and the physical storage units.
[0101] The computer 702 can store data on the storage device 818 by converting the physical state of the physical storage unit to reflect the information being stored. In different embodiments of the present specification, the specific conversion of the physical state may depend on various factors. Examples of such factors may include, but are not limited to, the technology used to implement the physical storage unit, whether the storage device 818 is characterized as a primary storage device or a secondary storage device, etc.
[0102] For example, the computer 702 can store information to the storage device 818 by issuing instructions through the storage controller 814 to change the magnetic properties of a specific location in a disk drive unit, the reflective or refractive properties of a specific location in an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of the physical media are possible without departing from the scope and spirit of the present description, and the foregoing examples are provided merely to facilitate the description. The computer 702 can also read information from the storage device 818 by detecting the physical state or properties of one or more specific locations in the physical storage unit.
[0103] In addition to the mass storage device 818 described above, the computer 702 may access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. Those skilled in the art will appreciate that computer-readable storage media are any available media that provide non-transitory storage of data and that can be accessed by the computer 702. In some examples, the operations performed by the cloud computing network 102 and / or any components included therein may be supported by one or more devices similar to the computer 702. In other words, some or all of the operations performed by the cloud computing network 102 and / or any components included therein may be performed by one or more computer devices 702 operating in a cloud-based arrangement.
[0104] By way of example and not limitation, computer-readable storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM ("EPROM"), electrically erasable programmable ROM ("EEPROM"), flash memory or other solid-state storage technology, compact disk ROM ("CD-ROM"), digital versatile disk ("DVD"), high-definition DVD ("HD-DVD"), BLU-RAY or other optical storage devices, cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory manner.
[0105] As described above, the storage device 818 may store an operating system 820 for controlling the operation of the computer 702. According to one embodiment, the operating system comprises a LINUX operating system. According to another embodiment, the operating system comprises a LINUX operating system from Microsoft Corporation in Redmond, Washington. SERVER operating system. According to further embodiments, the operating system may include a UNIX operating system or one of its variants. It should be understood that other operating systems may also be used. The storage device 818 may be used to store other systems or applications and data used by the computer 702.
[0106] In one embodiment, the storage device 818 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into the computer 702, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. As described above, these computer-executable instructions transform the computer 702 by specifying how the CPU 804 transitions between states. According to one embodiment, the computer 702 can access a computer-readable storage medium storing computer-executable instructions that, when executed by the computer 702, perform the operations described above with respect to Figures 1-6 The computer 702 may also include a computer-readable storage medium having stored thereon instructions for performing any other computer-implemented operations described herein.
[0107] The computer 702 may also include one or more input / output controllers 816 for receiving and processing input from a variety of input devices, such as a keyboard, mouse, touchpad, touch screen, electronic stylus, or other types of input devices. Similarly, the input / output controller 816 may provide output to a display, such as a computer monitor, flat-panel display, digital projector, printer, or other type of output device. It should be understood that the computer 702 may not include Figure 8 All components shown in the Figure 8Other components explicitly shown in the Figure 8 A completely different architecture than the one shown in .
[0108] The server computer 702 can support a virtualization layer 824, such as one or more application containers 112 executing in an operating system 820. In some examples, the virtualization layer 824 can be supported by a hypervisor that provides one or more virtual machines running on the server computer 702 to perform the functions described herein. The virtualization layer 824 can generally support virtual resources that perform at least some of the techniques described herein. For example, as shown, the application container 112 can receive a ranked list 124 of database instances 114 from the virtual workload orchestration component 104. The application container 112 can then access the nearest database instance 114, which can be a local database instance 114 that maintains a replica of the dataset 116 on the server computer 702.
[0109] In summary, the present disclosure describes a technique for providing virtual resources (e.g., containers, virtual machines, etc.) of a cluster application with information about a physical server cluster on which the distributed cluster application is running. The virtual resources supporting the cluster application are executed on physical servers in the physical server cluster. The virtual resources can receive an indication of a database instance (or other application) running on a particular physical server that is closest to the physical server in the physical server cluster. The database instance can be included in a group of database instances that maintain a common data set on each physical server in the physical server group. The virtual resource can then access the database instance on a particular physical server based at least in part on the database instance running on the particular server that is closest to the physical server.
[0110] Although the present invention has been described with respect to specific examples, it should be understood that the scope of the present invention is not limited to these specific examples. Since other modifications and variations to adapt to specific operating requirements and environments will be obvious to those skilled in the art, the present invention is not to be considered limited to the examples selected for the purpose of disclosure, but rather covers all changes and modifications that do not depart from the true spirit and scope of the present invention.
[0111] Although the present application describes embodiments with specific structural features and / or methodological actions, it should be understood that the claims are not necessarily limited to the specific features or actions described. Instead, the specific features and actions are merely illustrative of some embodiments that fall within the scope of the claims of the present application.
Claims
1. A physical server, arranged in a physical server cluster executing a cluster application, the physical server comprising: one or more processors; as well as One or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to: executing a virtual resource supporting the cluster application, the virtual resource being included in a set of virtual resources running on each physical server in the physical server cluster; Receiving an indication of a database instance running on a specific physical server that is closest to the physical server in the physical server cluster, the database instance being included in a group of database instances that maintain a common data set that is replicated and maintained on each physical server in the physical server cluster, the common data set running on the physical server and accessible by the virtual resource, the receiving an indication of the database instance running on the specific physical server that is closest to the physical server in the physical server cluster comprising: receiving a ranked list of the database instances, wherein the database instances in the ranked list are ranked based at least in part on how close the physical server is to respective physical servers that instantiate the database instances; selecting the database instance from the set of database instances based at least in part on the particular physical server running the database instance being closest to the physical server on which the virtual resource is executed; and The virtual resource is caused to access the database instance on which the virtual resource is executed.
2. The physical server according to claim 1, wherein: The virtual resources include virtual machines.
3. The physical server according to claim 1 or 2, wherein: The virtual resources include application containers.
4. The physical server according to claim 1 or 2, wherein: The specific physical server on which the database instance is running is the same as the physical server on which the virtual resource is running.
5. The physical server according to claim 1 or 2, wherein: The particular physical server is different from the physical server; and The specific physical server that is running the database instance is closest to the physical server of the virtual resource, such that at least one of the following two occurs: The virtual resource accesses the database instance in the set of database instances with minimal network latency; or The physical server is located at a position in the physical server cluster that is closest to the specific physical server.
6. The physical server of claim 1 or 2, comprising further computer executable instructions which, when executed by the one or more processors, cause the one or more processors to: determining that a database instance running on the particular physical server is not available for access by the virtual resource; identifying, from the ranked list of database instances, a secondary database instance accessible by the virtual resource; and The virtual resource is enabled to access the secondary database instance.
7. The physical server according to claim 1 or 2, wherein: The indication of the database instance includes a domain name associated with the database instance, and the physical server includes additional computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to: performing a Domain Name System (DNS) lookup to identify an Internet Protocol (IP) address associated with the particular physical server, Wherein receiving the indication of the database instance includes identifying, based at least in part on the DNS lookup, an indication that the particular physical server is closest to the physical server.
8. A method for cluster application, comprising: executing an application container on a physical server in a physical server cluster, the application container being included in a set of application containers of a cluster application executing on the physical server cluster, wherein each application container in the set of application containers runs an individual instance of an application; At the application container, receiving an indication of a database instance running on a specific physical server closest to the physical server in the physical server cluster, the database instance being included in a group of database instances that maintain a common data set, the common data set being replicated and maintained on each physical server in the physical server cluster, the common data set running on the physical server and accessible to the application container, the receiving an indication of the database instance running on the specific physical server closest to the physical server in the physical server cluster comprising: receiving, at the application container, a ranked list of the database instances, ranking the database instances based at least in part on how close the physical server of the application container is to respective physical servers that instantiate the database instances; selecting the database instance from the set of database instances based at least in part on the particular physical server running the database instance being closest to the physical server on which the application container is executed; and The database instance is accessed by the application container based at least in part on the database instance being on the particular physical server on which the application container is executed that is closest to the physical server.
9. The method of claim 8, wherein: The specific physical server that is running the database instance is the same as the physical server that is running the application container.
10. The method according to claim 8 or 9, wherein: The particular physical server is different from the physical server; and The specific physical server that is running the database instance is closest to the physical server of the application container, so that at least one of the following two items occurs: The application container accesses the database instance in the set of database instances with minimal network latency; or The physical server is located at a position in the physical server cluster that is closest to the specific physical server.
11. The method according to claim 8 or 9, further comprising: determining that a database instance running on the particular physical server is not available for access by the application container; identifying, from the ranked list of database instances, a secondary database instance accessible to the application container; and The secondary database instance is accessed by the application container.
12. The method according to claim 8 or 9, wherein: The indication of the database instance includes a domain name associated with the database instance, and the method further includes: performing a Domain Name System (DNS) lookup to identify an Internet Protocol (IP) address associated with the particular physical server, Wherein receiving the indication of the database instance includes identifying, based at least in part on the DNS lookup, an indication that the particular physical server is closest to the physical server.
13. A system for cluster applications, comprising: one or more processors; as well as One or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to: instantiating an application container on a first physical server in the physical server cluster, the application container being included in a set of application containers of a cluster application, the set of application containers executing on the physical server cluster, wherein each application container in the set of application containers runs an individual instance of an application; receiving infrastructure data indicating respective physical servers in the physical server cluster that are running respective database instances in a set of database instances, the set of database instances maintaining a common data set, the common data set being replicated and maintained on each physical server in the physical server cluster, the common data set running on the physical servers and accessible to the application container; Identifying, based on the respective physical servers indicated in the infrastructure data, a second physical server that is closest to the first physical server, comprising: determining a ranked list of the database instances, wherein the database instances are ranked in the ranked list based at least in part on how close the first physical server is to the respective physical servers on which the database instances are running; and Sending an indication of at least one of the database instances running on the second physical server or the second physical server to the first physical server includes sending a ranked list of the database instances to the first physical server.
14. The system of claim 13, comprising further computer executable instructions which, when executed by the one or more processors, cause the one or more processors to: determining a network delay between the first physical server and each of the physical servers in the physical server cluster that is running each of the database instances; and determining that a network delay between the first physical server and the second physical server is the lowest of the network delays, in, Based at least in part on the network delay being the lowest of the network delays, the second physical server is identified as being closest to the first physical server.
15. The system of claim 13 or 14, comprising further computer executable instructions which, when executed by the one or more processors, cause the one or more processors to: Using the infrastructure data, determining the location of each physical server in the physical server cluster that is running each database instance; and According to the positions, determining that a first position of the first physical server is closest to a second position of the second physical server among the positions of the physical servers, in, Based at least in part on the first location being closest to the second location, the second physical server is identified as being closest to the first physical server.
16. The system of claim 13 or 14, wherein: The first physical server is identical to the second physical server.
17. The system of claim 13 or 14, wherein: The first physical server is different from the second physical server; and The second physical server that is running the database instance is closest to the first physical server, so that at least one of the following two items occurs: The application container accesses the database instance in the set of database instances with minimal network latency; or The first physical server is located at a position closest to the second physical server in the physical server cluster.
18. A physical server, arranged in a physical server cluster executing a cluster application, the physical server comprising: means for executing an application container on a physical server in a physical server cluster, the application container being included in a set of application containers of a cluster application executing on the physical server cluster, wherein each application container in the set of application containers runs an individual instance of an application; Means for receiving, at the application container, an indication of a database instance running on a specific physical server in the physical server cluster that is closest to the physical server, the database instance comprising a group of database instances that maintain a common data set, the common data set being replicated and maintained on each physical server in the physical server cluster, the common data set running on the physical server and accessible to the application container, the means for receiving, at the application container, an indication of a database instance running on a specific physical server in the physical server cluster that is closest to the physical server comprises: means for receiving, at the application container, a ranked list of the database instances, the database instances being ranked based at least in part on how close the physical server of the application container is to respective physical servers that instantiate the database instances; means for selecting the database instance from the set of database instances based at least in part on the particular physical server running the database instance being closest to the physical server on which the application container is executed; and Means for accessing, by the application container, the database instance based at least in part on the database instance being located on the particular physical server on which the application container is executed that is closest to the physical server.
19. The physical server of claim 18, further comprising means for implementing the method of any one of claims 9 to 12.
20. A computer program product comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method as claimed in any one of claims 8 to 12.
21. A computer readable medium comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method of any one of claims 8 to 12.
Citation Information
Patent Citations
Directory-services-based launcher for load-balanced, fault-tolerant, access to closest resources
US20010023440A1
Systems and methods for distance and performance based load balancing
US20130297596A1