distance between Application server and database server

[former_member209962]

Hi All,

We have question regarding database server and application in a distributed environment where application is running on separate server and database server running on separate server.

Can we run database server on separate location and application server on separate location (with in distance for 5 KM)

Thanks

Tabrayz

[michael_eaton3]

Technically, yes you can. However if performace is important then the network speed between the sites will be critical.

In reality you don't want to be doing this for a production system.

[dvankempen · Accepted solution]

As Michael comments, technically possible, but unconventional architecture. Network connection needs to be extremely fast. Typically, you would want to keep your database and application server as close as possible to keep latency to a minimum

E.g. Microsoft Azure offers proximity placement groups so that even virtualised environments are physically close.

• https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/sap/sap-proximity-placement-scenar...

[former_member209962]

Hi Michael / Denys,

Thanks for your comments appreciated !

Yes this is not for production environment , as I mention we have distributed landscape App server and DB server separate.

We have DR (disaster recovery) for DB server at different DC which is close to our main DC, however for application there is no DR , so for example if DB server goes down, application connect to DR server and it works, but as you rightly mention network speed is critical . If we want to avoid this we should have additional App serve at DR site also..

So just wondering how we can achieve this shall we install app server and connect to DR db and then keep it shutdown always?? or any other thoughts please advice..

Thanks

Tabrayz

[dvankempen]

You might want to look at this from a service perspective, not the individual technical components. For the service (app) to be available, component x, y, and z need to be functional (including connectivity, latency, etc.).

Whether the DR site needs to be idle or can be leveraged for other purposes (training, test/QA, development) depends on the RTO (recovery time objective).

It might take a while for a VLDB to be up and running with all relevant data loaded in memory / caches. If this downtime is acceptable, cold standby often provides the lowest TCO. If not, warm standby might be required.

For example, SAP HANA provides active/active read-enabled system replication where both sites are synchronised with takeover possible in a matter of seconds. The secondary system is accessible for reporting purposes (read-only) to offload the primary site. Other database vendors offer similar configurations.