vincentx11 opened a new issue, #52698: URL: https://github.com/apache/doris/issues/52698
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/doris/issues?q=is%3Aissue) and found no similar issues. ### Description Premise Constraints: - Due to project requirements, the deployment environment does not have the conditions to build and maintain a k8s cluster. There are only two high-configured servers that can be mounted with multiple data disks. - All existing applications are deployed by orchestrating service instances through docker compose. Therefore, it is hoped that doris cluster can also be built and maintained via docker compose in staging environment. Background of Requirements: 1. The doris cluster is mainly used by flink-doris-connector. Different from accessing Doris using a MySQL-compatible JDBC driver, when flink-doris-connector reads and writes data, after completing communication and metadata interaction with FE, it will directly communicate with BE. Under this general background, it is imperative that the cluster where Flink is located must have network connectivity with all BE nodes. 2. docker-compose is used for managing each node. Since it already has the capability of direct communication using servicename, there is no desire to maintain another set of mappings between instances and IPs. That is, docker compose only focuses on the management of service node names and does not need to care about IP change binding. 3. In the current network architecture of doris, inter-node communication is extremely sensitive to IP changes. Once the IP of a node changes, various communication problems will be encountered when it rejoins the cluster, and maintenance is far less convenient than using hostname. Analysis of Current Situation: 1. Regarding requirement 1, it requires that the BE nodes in the Doris cluster can be accessed by external clusters. If the intranet IP used during node registration is adopted, this expectation obviously cannot be achieved. There are two ways to achieve this effect: - When registering BE, uniformly use network configurations that are reachable for external cluster communication, such as public IP, domain name, etc. - BE communication adopts domain names or hostnames. Intra-cluster communication goes through internal DNS, and communication between different clusters or networks goes through external DNS. 2. Requirements 2 and 3 both point to the solution of using hostnames for node communication. ### Solution Regarding the several implementation methods in Requirement 1, if external accessible network communication is uniformly used, the delays caused by various network overheads within the cluster will seemingly affect the communication efficiency and stability of the cluster. To sum up, we should need a `IP-insensitive Doris cluster maintained by docker compose`. Unfortuntely, the `docker-compose` solution provided by the official website cannot achieve the above goal, because both FE and BE must be configured with a valid IP address when starting up. The official website's elaboration on FQDN is only focused on bare-metal deployment and Kubernetes deployment, with no relevant discussion on enabling FQDN in the docker compose deployment method. How can I deploy a `IP-insensitive Doris cluster maintained by docker compose`? However, if such an environment can be quickly set up using docker compose, it will not only solve the scenario problems mentioned above but also, I believe, be of great benefit to the trial use and promotion of Doris. After all, not all developers have the conditions for deploying and maintaining Kubernetes. ### Are you willing to submit PR? - [ ] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
