.. _multinode-modular-cluster-with-app-database-nodes: Multinode Modular Cluster with Application and Database Nodes ----------------------------------------------------------------- .. _21.1|VOSS-837: .. index:: voss;voss workers .. index:: web;web service In order to achieve Geo-Redundancy using Application and Database nodes, you need the consider the following: * Six Application and Database nodes - 3 nodes with an application role and 3 nodes with a database role - are clustered and split over two geographically disparate locations. * Two Web Proxy nodes to provide High Availability that ensure an Application role failure is gracefully handled. More may be added if Web Proxy nodes are required in a DMZ. It is strongly recommended *not* to allow customer end-users the same level of administrator access as the restricted groups of provider- and customer administrators. This is why Self-service web proxies as well as Administrator web proxies should be used. Systems with Self-service only web proxies are *only* recommended where the system is customer facing, but where the customer does not administer the system themselves. * Web Proxy, application and database nodes can be contained in separate firewalled networks. * Database synchronization takes places between all database role nodes, thereby offering Disaster Recovery and High Availability. * All nodes in the cluster are active. Primary and fall-back Secondary Database servers can be configured manually. Refer to the Platform Guide for further details. The diagrams in this section illustrate: * the six node cluster * 2 Web Proxy nodes in a DMZ * 4 (2 admin, 2 Self-service) Web Proxy nodes in a DMZ |6-node-modular-cluster| |modular-cluster-site-dmz| |modular-cluster-site-dmz-admin-self-webprx| .. |6-node-modular-cluster| image:: /src/images/6-node-modular-cluster.png .. |modular-cluster-site-dmz| image:: /src/images/modular-cluster-site-dmz.png .. |modular-cluster-site-dmz-admin-self-webprx| image:: /src/images/modular-cluster-site-dmz-admin-self-webprx.png