Here a larger weight is attributed to the server that contains the master database, because - as we will later discover - if the two servers are active at the web and business layers, data will only be written to one of the two databases, the master, before being duplicated on the other, the slave. As a result, the server that contains the local master database is more reactive than its counterpart, which will have 10 ms latency between SBG and RBX when writing data via the vRack - the private network that interconnects the two machines. This is why, to balance the load, we send 60% more requests to first server.
The LB IP also helps to keep the infrastructure available. If one server becomes unavailable (you can check availability by pinging the http (80), HTTPS (443), MySQL (3306) or PostgreSQL (5432) ports), traffic will be redirected to another server until the unavailable server is once again available.
Lastly, an SSL certificate attached to the LB IP has been set up to secure users' connections to the infrastructure.