what you have described sounds feasible - basically, you are installing two clusters with an external load-balancer in front of them, is that correct?
If it is, then you just need to take into account the fact that the clusters will be, from Zato’s perspective, completely independent, and it will be the external load-balancer’s job to make it all work in an HA fashion.
Also, if each system (physical server or virtual) contains one cluster, that is, if one cluster is wholly installed on one system only, then there is no difference in performance between having one or more Zato servers on that system as long as they have the same total of gunicorn workers as there are CPUs available.
For instance, let’s say that each system has four CPUs. Then, as long as we are discussing HTTP-based transactions, you will get the same req/s regardless if it’s one server with four workers, two servers each with two workers or if it’s four servers each with one worker.
Things will be different with in 3.0 if publish/subscribe is used because there, it will be possible to guarantee better performance depending on what kind of pub/sub clients are connected to Zato (e.g. WebSockets/REST/AMQP/Flat files) and how many there are of them (e.g. dozens vs. thousands).
But this will apply for 3.0 onwards, and only with pub/sub, which will effectively turn Zato into a possibly stateful platform that keeps track of messages in transit whereas 2.0 is fairly stateless and what really matters is simply that you have a total of gunicorn workers that matches the number of CPUs, as far as performance is concerned.