There is so much unnecessary confusion over server roles in SharePoint. Let me take the opportunity to simplify these roles, so you can see it is much much simpler than it is made out to be or even that original design.
SharePoint roles are really a description of what services are running on the server, and because of the past we've overcomplicated the way we think about servers roles, app servers, tiers, topologies, and farms.
The SharePoint Roles you've heard
- Web Front End - Every farm has one of these. It's where IIS is
- Query
- Index
- Calc
- App server - another name for all the goo that isn't the WFE
- Central Admin/SSP Admin
- Infopath - NOT A ROLE (This can NEVER be taken off the web front end)
- SQL - Not a SharePoint role and should not contain SharePoint code unless it's an all in one.
There are 2 server roles for 97% of the SharePoint World.
WFE - WFE/Query/Calc/Central Admin/SSP Admin
Index (the most common offloaded server role) (Note: Don't get carried away with what I'm saying. There is a Query/Index Gotcha.)
(Another 3% should know the all in one where WFE and all that jazz are combined with the Index.)
Why would I say you really only need to know about 2 roles?
First the Query role is the lightest role and doesn't really need to be offloaded. If it does you really are better off with an SSP farm which is focused on Search which would turn that Query server back into a WFE/Query box.
The Calc role is oversold. Excel services is cool, but no one is really able to stress it to the part where it needs separate servers. If you find a case, it's a .01% case, completely uncommon. MS IT had to reallocate and they
Infopath - not a server role, there was a license for forms server, that was never really used. Forget you ever heard about it. It's a dead end.
Central Admin/SSP Admin - I've heard people putting this on it's own server, totally unnecessary you don't have to put it on every server in the farm, but you don't have to buy a server for this purpose either.
Target - you can use existing roles for doing that.
What about MASSIVE farms?
In massive farms you have two choices. You put WFE/Query together and have a bunch of em, or you specialize search into it's own farm, maybe even two search farms, but you don't ever really need to offload query. Don't let an architect push you into having 2 WFE, 2 Query, 1 Index, 2 SQL. You are better off with 4 WFE/Query and 1 Index and 2 SQL or a Content farm of 2 WFE/Query and 2 SQL and a separate Search farm 2 WFE/Query 1 Index box and Shared SQL backend. Make sense?
Does this turn your world upside down or is it game changing?
Need an Exception?
A special customer that has a requirement for no data of any type in their public DMZ. They HAVE to have their data in the 2nd tier. Hence they put the WFE ONLY (remember that option no one uses) box in the pub DMZ and the 2 Query and Index boxes and SQL in their APP DMZ. They likely could have configured ISA publishing rules or used IAGin the pub DMZ and put the 3 SharePoint boxes in the App DMZ, but that's a design decision.