Movable Type Architectures
Here is a page that over time will document both proven and conceptual ways to architecture your Movable Type install.
Six Apart's Architecture Guide
This architecture was discussed on a recent ProNet phone call. David Jacobs, John Emerson, Brad Choate and Neil Epstein have helped refine this architecture over the past year.
Any architecture setup should be flexible to the needs of your client and your system. Before undergoing any architectural refresh, it's worth your time to do load testing and profiling on your current system to identify your pain points. This topic is covered more in MTProfiling.
MySQL is a greedy process, and generally speaking you don't want your database and application competing for resources. The good news is that as you allow MySQL more resources it can be perform better for you.
Another thing to consider is IO and disk fragmentation over time. When you have a DB and heavily used file system on the same partition, you can run the risk of the disk becoming too fragmented slowly down read and write times. Separating them prevents to a great extent this from happening, or at least from becoming to large of a problem.
It's highly recommended that administrators of large MT installs raise the caching and connection limits in my.cnf. MySQL 5 allows more caching options and in my experience has been more stable than earlier versions. Your mileage may vary.
Comments, Trackbacks, Feedback Server (Users)
Segmenting off network traffic for comments and trackbacks insulates the MT Application for spam attacks, or even rushes of legitimate comments.
A key ingredient on this machine is the RebuildQueue plugin which comes with a syncing daemon that can push new files to a remote system. RebuildQueue publishes a manifest of changed files that can be used by other applications to facilitate this process.
The downside is that it can take a minute or two for comments to be made live on the News Server(s). When using this system make sure you tell your users, "it may take a minute for your comment to appear" to set their expectation accordingly.
MT App Server (Editors)
This is very similar to the Comment Server - except the majority of traffic generated is from the CMS app. Humans publishing stories, moderating comments, etc. takes place here. This is on a separate machine so that it can be insulated from network traffic coming from beyond the firewall.
It too uses the RebuildQueue plugin as the Comment Server does. If the RebuildQueue begins to take more resources (i.e. if you are rebuilding more often) the RebuildQueue process can be niced down, or other servers can run multiple worker processes.
World Facing Web Servers (Published Content)
These are dumb servers. Content is synced to them from the MT App Server(s) and Feedback Server(s) via Rsync or a mounted NFS partition.
- Hostnames: Web01-nn
- Software: Apache
This cluster would serve static pages only - all published blog content.
- Hostnames: App01-nn
- Software: Apache, fastcgi/mod_perl
This cluster is responsible for serving up the application. You could afford to make this a small cluster. The RebuildQueue plugin ensures that the user never waits for the rebuild process. All pages get queued up to be rebuilt as some point in the future.
- Hostname: DB01-02
- Software: MySQL
Two machines - one for active, and one in hot standby and backup for DR.
- Hostname: FS01
Primary file system - this contains the files that get rsynced out to the Web Cluster.
- Hostnames: FS02-nn
Contains rebuild queue workers and publishes files over to FS01 over NFS.
- Hostname: TB01-nn
Set of servers dedicated to processing TrackBacks so that spam attacks do not put other machines and performance at risk.
- Hostnames: Comment01-nn
Rationale for this is same as TrackBack cluster.
Revision #1 by Byrne Reese dated 2006-12-13 20:10:24.