What do you run on your website? Do you have a LAMP stack? That’s Linux, Apache, MySQL and P{HP,erl,ython} for the uninitiated. I normally run a LAP/LM app stack duo. This allows me to separate the MySQL database from the web stack, and use it for other purposes as well. I include such services as xbmc and MS Access/Libre Office Database as MySQL clients as well. It makes sense to isolate the MySQL server.
There are also several web servers, or LAP stacks in my home. I keep one instance for my production site (this page here), and a handful of others for testing and development. They all share the same LM stack.
Recently I was required to produce a WIMP stack, that’s Windows, IIS, MySQL, and php, for development purposes. The architecture is almost completely different, but it’s now using my LM stack for database as well.
There are a few things to consider when you’re deciding between a single LAMP stack (or multiple LAMP stacks) and a LAP/LM stack.
Data Isolation
By offloading your data onto a separate LM stack, you can isolate your data from the application reducing the possible impact of a system intrusion. In a traditional LAMP stack, a compromised website means a compromised database as well. With a separate LM stack, only your LAP stack and it’s associated data are compromised. Other databases on the same site can generally be assumed safe.
Furthermore, by providing a separate LM stack, you need not provide any public access to your database. By placing it on a separate VLAN distinct from your internet VLAN you can achieve a separate level of protection.
Data Consolidation
You can host several distinct datasets on a single LM server. MySQL stores it’s data in “schemas”, which consist of all the data associated with a single application or user. Schema’s are usually individually secured, and multiple schemas can be run on a single instance of MySQL. By storing all your schemas on a single instance of MySQL, you retain the ability to isolate your data, and you gain the ability to pool resources.
Additionally, by consolidating your data, you reduce the impact of backups. It’s simpler to backup all the data on a single database server than it is to backup data spread across several servers.
Finally, other applications such as mythtv can only function properly if a single database is available to all instances.
Resource Allocation
MySQL is a memory hog. By allocating only a single machine (virtual or real) to MySQL, you’re able to consolidate this memory usage. The remaining LAP stack is relatively lightweight. Data management is the most resource-intensive portion of most applications.
Resource Expansion
When all your data is consolidated, isolated, and all your resources are properly allocated, you can identify how much data you have and your data access patterns. With all your data in one place you may start to notice bottlenecks.
Disk
You may run out of disk space, in a virtual machine you can expand your storage, in a physical environment you can buy a larger disk.
you may also notice performance bottlenecks from your disk. This shouldn’t be an issue in a virtual environment where your disk storage is on a SAN. In a physical environment, you can store your data on a raid1 or multiple raid1 arrays or use something like ZFS to improve overall throughput by pooling disk resources.
Memory
Memory is cheap. Adding memory to a single LM machine should be well within anyone’s budget.
Other resources.
CPU and Networking resources, as well as other various throughput bottlenecks can be more expensive to deal with, leading to Horizontal Expansion.
Horizontal Expansion
Horizontal Expansion, or Horizontal Scaleout, is adding additional MySQL servers to handle increased load at any of the above levels. When all your data is in one place, choosing how to spread out is simple.
If you’ve got a single, high throughput dataset, you may consider using a master/slave setup, where reads can be balanced, and writes get sent to the master. If you’ve got multiple schemas under varying levels of load, you can simply split out to two separate MySQL servers. The trick is to spread the heavy load schemas and the light load schemas out evenly amongst the servers. This is made easier when you’ve got your data consolidated as above. If your usage is reaching extreme levels, you may want to look into using NDB Cluster with MySQL.
Other considerations
Ultimately, whether you chose to use a LAMP stack or a LAP/LM stack is going to depend on you and your needs. What resources you have available and your level of comfort with the Linux command line may also influence your decision.
Whatever you choose, you should always remember to backup your data frequently, and routinely monitor your logs for unexpected activity.
There are many guides for installing a LAMP stack, and adapting them for LAP/LM stacks is simple.