The Bad News: The core open source base of Wordpress does make quite a few assumptions about being run on a single server (wp-content, user uploads and media library to name a few)
The Good News: Pretty much all cloud providers (including Azure) have abstractions that allow you to work around these design limitations.
Fundamentally, you'll be addressing the following concerns:
- Load Balancing traffic between two (or more) "front-end" Wordpress web / app servers. Not too difficult since Wordpress is MOSTLY stateless unless you're letting users login to the sites. This is done via a combination of DNS and Load Balancers. You'll need support for 2 IP's for your app servers - 1 set will connect to the subnet that is routable via Internet (though hopefully protected by a firewall not outlined below) and the other two will be on a DIFFERENT subnet that is isolated from the other network and contains the Database Server Instances but basic outline is like such:
/-- (10.0.0.1 - eth0) wp1.domain.com (10.0.1.1 - eth2)
(Public IP) wp.domain.com
\-- (10.0.0.2 - eth1) wp2.domain.com (10.0.1.2 - eth3)
Managing sessions IF you are letting users login to the sites. If so, you'll need to ensure when they login to server 1 that either all of their future requests get routed to that server (sticky sessions) or that it doesn't matter which server they access because sessions are managed via some other mechanism (via Zend Server Session Clustering, for example).
Managing Admin Logins IF you are letting some users login to the back-end to manage content (similar to above).
Choosing DB System that is ALSO Highly Available. No point in having two front end servers if your DB crashing brings the whole system down. You'll need to leverage MySQL Master / Slave replication via ClearDB or modify WordPress via plugin to leverage SQL Server so you can use its native clustering systems. This will mean you need at least 4 VM's if you want to manage the DB layer yourself (2 x App & 2 x DB). Here's how that might look:
/-- wp1.domain.com (10.0.1.1)\---/(10.0.1.3) db1.domain.com (10.0.2.3)\
wp.domain.com X |
\-- wp2.domain.com (10.0.1.2)/---\(10.0.1.4) db2.domain.com (10.0.2.3)/
NOTE - to ensure reliable failover & protect the security of the system, a THIRD network subnet is usually used to connect the two database nodes to each other via a private channel that is separated from the other communication networks that the app servers use to talk to the database & the app servers use to communicate with the outside world.
Enabling Connection Pooling to maximize performance and reliability of your app server's database connections.
Leveraging a Caching plugin like W3 Total Cache or Super Cache to minimize load on front end servers.
The Following guides offer specifics on how you can address each of the above challenges. There are several ways to handle each in Azure, so it's up to you to decide how you want to attack each challenge then deal with the constraints each of those choices imposes as you work up and down the stack.