Additional Deployment Options

From AgileApps Support Wiki
Revision as of 23:27, 1 July 2015 by imported>Aeric
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

To further improve the performance of the system, data safety and data security, there are some additional things you can do:

  • Send database backups to a distant, remote server.
    Keep the replicated database on premise, for instant failover when needed. But for disaster recovery, keep the backup database 1000 miles away, or more.
  • Allow only the backup server to connect to the backup port.
    In addition to requiring the username and password to connect to the backup port, allow connections only from a specific IP address.
  • Add a Dynamic Site Accelerator--in effect, a giant cache in the cloud
    For example, use the Akamai accelerator.
  • Add Database Clustering.
    With a database cluster, the application server sees a single database, but inside the cluster many database servers are at work.

Notepad.png

Note:
All of those options are in effect in the public cloud installation of the AgileApps Cloud platform, with the exception of database clustering. (So far, the performance profile has not required it, despite having thousands of users on the system.)

Additional DB Clustering Notes:

  • Third party database clustering systems work well.
  • The AgileApps Cloud platform currently supports MySQL version 5.5. But MySQL native clustering becomes stable only in version 5.6.
  • Whichever system is used for DB clustering, it should support multi-master replication. Otherwise, separate replication nodes are needed for every system in the cluster, and failover procedures become tricky.
  • The Quartz scheduler has yet to be tested for scheduled reports and backups when DB clustering is in effect.