Typical MMO architecture works like this:
Clients connect to some form of a userserver (after going through an auth process, which may be its own server), which handles traffic for a set of users. Typically, multiple userservers are run for each world server. You may get shuffled between userservers for a variety of reasons. You may get clustered because of geographical proximity in thr world, for example.
User connections are multiplexed through to the world servers which actually run the simulation. World servers may or may not require zoning between them depending on how much proxying they do along the boundaries. Most world server architectures use static geographical load balancing, but some have used various forms of dynamic load balancing, and are not doing load purely based on geographical proximity.
World servers are typically managed by some sort of nanny process. It's not unusual to launch world servers for instances, for world servers to go down and be relaunched while not damaging the cluster as a whole, etc.
There may also be DB processes -- there's almost certainly DB servers.
In terms of server CPU usage, there's really nothing stopping you from running an OS plus a few thousand concurrent connections as long as you can handle the sockets and aren't running much else on the box. But it's very heavily dependent on the amount of additional processing required for your world -- scripting, pathfinding, AI, etc -- and on the n^2 problem of densely packed crowds. Even old text muds regularly for hundreds on one world -- and no, modern MMO servers are *not* necessarily more intensive in terms of their CPU demands. (Tho of course the overall architecture is more complex).
The largest demands these days tend to actually be pathfinding and "awareness" (radial searches, radial notifications), unless you are running a crazy fast heartbeat. Typical heartbeats are on the order of 100-250ms.
Typical clusters are well over a dozen machines. I am pretty sure WoW does not run on just four per shard. But the machines can also be multicore, of course.
Clients connect to some form of a userserver (after going through an auth process, which may be its own server), which handles traffic for a set of users. Typically, multiple userservers are run for each world server. You may get shuffled between userservers for a variety of reasons. You may get clustered because of geographical proximity in thr world, for example.
User connections are multiplexed through to the world servers which actually run the simulation. World servers may or may not require zoning between them depending on how much proxying they do along the boundaries. Most world server architectures use static geographical load balancing, but some have used various forms of dynamic load balancing, and are not doing load purely based on geographical proximity.
World servers are typically managed by some sort of nanny process. It's not unusual to launch world servers for instances, for world servers to go down and be relaunched while not damaging the cluster as a whole, etc.
There may also be DB processes -- there's almost certainly DB servers.
In terms of server CPU usage, there's really nothing stopping you from running an OS plus a few thousand concurrent connections as long as you can handle the sockets and aren't running much else on the box. But it's very heavily dependent on the amount of additional processing required for your world -- scripting, pathfinding, AI, etc -- and on the n^2 problem of densely packed crowds. Even old text muds regularly for hundreds on one world -- and no, modern MMO servers are *not* necessarily more intensive in terms of their CPU demands. (Tho of course the overall architecture is more complex).
The largest demands these days tend to actually be pathfinding and "awareness" (radial searches, radial notifications), unless you are running a crazy fast heartbeat. Typical heartbeats are on the order of 100-250ms.
Typical clusters are well over a dozen machines. I am pretty sure WoW does not run on just four per shard. But the machines can also be multicore, of course.