Server Identification Component for Clustered Application Latency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In cloud computing, clustered applications face inefficiencies due to high latency when application containers access database instances located on remote physical servers, as they are unaware of the infrastructure and server locations, leading to increased network hops and undesirable latency.
Innovation Solution
A server identification component collects and maintains data on server locations, latency, and resource availability, providing application containers with a ranked list of nearest database instances based on proximity and latency, allowing them to target the local or nearest instance for data access, thereby reducing latency and improving performance.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If application containers access database instances on remote physical servers without infrastructure awareness, then database redundancy and availability are maintained, but access latency increases and network traffic efficiency decreases
Solution Approach 1:
The system performs preliminary actions by maintaining an infrastructure data structure that pre-stores server location information, latency metrics, and resource availability data before access requests occur. The server identification component queries this pre-prepared data structure to determine the nearest database instance, avoiding real-time discovery and reducing access latency while maintaining redundancy through multiple instance options.
2Productivity
If application containers are provided with infrastructure information about server locations and latency, then access efficiency improves, but system complexity increases due to additional data collection and management requirements
Solution Approach 1:
The server identification component acts as an intermediary between application containers and the infrastructure data structure. It queries the pre-stained infrastructure data, processes the information to identify the nearest database instance, and returns the result to the application container. This intermediary approach simplifies the interface for application containers while managing the complexity of infrastructure data collection and maintenance centrally.
Solution Approach 2:
The system performs preliminary actions by maintaining an infrastructure data structure that pre-stores server location information, latency metrics, and resource availability data before access requests occur. This pre-computed data eliminates the need for real-time discovery and reduces access latency while maintaining redundancy through multiple instance options.
3Reliability
If multiple database instances maintain the same data set across different physical servers, then redundancy and availability improve, but network traffic and access overhead increase
Solution Approach 1:
The system applies local quality by directing application containers to access database instances based on their local proximity and latency characteristics. Each application container queries the server identification component to determine the nearest database instance, ensuring that data access occurs locally rather than remotely. This localized access approach maintains the redundancy benefits of multiple instances while minimizing network traffic by selecting the最优 local instance for each access request.
Data Source
AI summary
This disclosure describes techniques for providing virtual resources (e.g., containers, virtual machines, etc.) of a clustered application with information regarding a cluster of physical servers on which the distributed clustered application is running. A virtual resource that supports the clustered application is executed on a physical server of the cluster of physical servers. The virtual resource may receive an indication of a database instance (or other application) running on a particular physical server of the cluster of physical servers that is nearest the physical server. The database instance may be included in a group of database instances that are maintaining a common data set on respective physical servers of the group of physical servers. The virtual resource may then access the database instance on the particular physical server based at least in part on the database instance running on the particular server that is nearest the physical server.