Introduction to Tuxedo multi-host mode (MP)

[Description]
An independent tuxedo application system can be deployed on multiple machines. These servers are connected over the network. This deployment method is called the MP method. Among these servers, you need to select a server as the logic master server. On this server, there is a dbbl process responsible for the management of the entire tuxedo application system. Each server has a BBL process, which communicates with the dbbl process and manages the configurations on the respective servers. There is also a process named Bridge on each server and a process named tlisten, which is responsible for communication between servers.
In the MP mode, how does tuxedo control and coordinate the collaboration between each server? If the MP mode is configured, load balancing and fault tolerance can be performed between these servers, and the client can establish a connection with any of the servers, for example, if the server does not have the service to be called by the client, tuxedo can automatically send the request to other machines with the service and return the result to the client, requests are transmitted between these servers through the bridge process. Of course, these are transparent to the client. In addition, if Server Load balancer (ldbal = Y) is configured, tuxedo sends requests to the server with lower load according to their load conditions. It also provides the software-level cluster function. If one or more servers (not all of them) fail, normal machines can continue to run, if the network connection between them is disconnected, the bridge process will automatically retry and multiple network connection paths can be configured between these servers. When one of these servers fails, other connection paths are automatically used.
[Configuration]
1. These servers can access each other through the network. (This seems like a lot more)
2. tuxedo server is correctly installed on each server.
3. The application has been published to these servers, that is, the servers to be released by a server.Code Deploy to this server.
4. Determine whether a server is a logical master.
5. Modify the relevant content in ubbconfig as follows:
* Resource
Model MP
Options LAN and migrate (optional)
Master dbbl on this server is responsible for communicating with BBL on other servers
Bblquery the BBL on each server sends status information to dbbl on the master machine every scanunit * bblquery seconds. The default value is 300 seconds.
Dbblwait if the master machine does not receive the status information sent by a server, it will wait for scanunit * dbblwait seconds. If it has not received the status information sent by the server, this server will be detached (parttioned). The default value is 20 seconds.
* Machines in this section, you need to configure each server included in the tuxedo application system. If the server is a UNIX server, you need to configure UID and GID (you can view it by using the id command in UNIX)
* In this section, the network configures the IP address for communications between servers and the bridge process. In an MP tuxedo application system, different servers communicate through the bridge process, the listening IP address and port of the bridge are specified in naddr. If you want to specify the network device used by the bridge in UNIX, if it is in Windows NT, do not
6. Before the tuxedo system is started, communication between different servers is conducted through the tlisten process, because there is no bridge process yet. Nlsaddr is the IP address and port on which the tlisten process listens. Therefore, start the tlisten process on all servers.
Note: you only need to configure and compile the ubbconfig file on the master machine. When the file is started, dbbl will automatically
The tuxconfig file on the master machine is sent to other servers.
Start the tlisten process on a Windows Server
Tlisten-l // 10.10.10.10: 6600
Start the tlisten process on a UNIX Server
Tlisten-D/dev/TCP-l // 10.10.10.10: 6600