Fresh Content on SharePointJoel.com SharePoint Ads
Subscribe in a reader
There are a few ways to deploy WSS 3.0 farms.
All in One - (Basic) - installs all components on the same server including Windows Internal Database engine. Looking for a limit or best practice? I don't recommend using this if you plan to store more then 5GB. Also if you have more than 25 people, and even if you plan to use this more long term you should consider SQL server even if on the same box, it will make it easier to manage and troubleshoot. In a small environment, you don't have to use a dedicated SQL environment, it could be something that other apps use as well. In basic mode, you have a site when you're done. The web app is extended and you can pick your template for the top level site.
One Web Front End & Local or Remote SQL - (Advanced) - during this install it lays down all the binaries, then you run the psconfig.exe (the configuration wizard). In the wizard you connect to the SQL server whether local or remote. You can always add WFEs later or move from local SQL to a remote SQL server.
Two or More WFE (default advanced install search/index) & Remote SQL - (Advanced) - during this install it lays down all the binaries, then you run the psconfig.exe (the configuration wizard). In the wizard you connect to the SQL server which will create the config database and content databases. Of course with high availability you'll load balance your Web Front Ends, then most likely Cluster your SQL environment, Failover (Active/Passive). Clusters are common and not difficult to administer. Next most common is SQL log shipping with or without clustering, and then database mirroring. There are a few current deployments now using this. Scale is incredible here. Expect 25 requests per second per server, 25K users with light usage, 10K with heavy usage. (assuming a 10% concurrency) Each WFE in this scenario can handle some of the indexing/search function. Assume that the server that the web app was originally extended from will be the server indexing that particular content database. NOTE: No more SQL FTS. Search and Indexing now uses the same engine that MOSS uses. The difference? You can't index data off the box like indexing file shares or public folders, etc... The real thing to note in this mode is that you can change what server is doing the search/indexing function by simply going to the web application then manage the content databases and divide the databases between the WFE servers.
Two WFEs with Search Server (includes Index) & Remote SQL (Advanced) - the install is nearly the same as the first. Install 3 or more boxes all the same (as in the previous example), but only put 2 in load balancing. Go into central administration and in the database UI for managing content databases you click on the database and can choose what server is the search server for each of the databases. In this you add the third server (the one out of rotation) as the search server. The search service can then be stopped on the two web front ends. This server role will simply offload the performance of the indexing and search function. There's no propegation and indexing would be local to the search server. To be honest with you I don't know anyone doing this. I saw a mail from the Admin PM on this right around RTM. From a scale and perf perspective I can see how this could come in handy, but likely won't be planned, but may be useful to know. Let me know if you do use this.
This ability to configure the search server doesn't have to be a third server. Knowing this function exists and the fact that the engine is the same as MOSS may provide some insight into the service. Note the communication which exists between the web front ends. See Technet for more info.
I did find one tiny reference to this server role on a design blog.
Found some more info on the WSS Search role today on TechNet in the WSS tech library:
"Plan for search servers
Windows SharePoint Services 3.0 includes one application server role: search. The Windows SharePoint Services 3.0 search application role includes both the search and indexing components. These components cannot be divided. You can install the search role on a Web server or on a dedicated application server. Unless you are deploying Windows SharePoint Services 3.0 to a standalone computer, installing the search role on the same computer as the database is not recommended.
If a server that hosts Windows SharePoint Services 3.0 search fails, search is unavailable. The amount of time required to restore the search capability depends on if existing content indexes can be restored or if new indexes must be generated by re-crawling the content.
Windows SharePoint Services 3.0 can be deployed to multiple servers for capacity reasons; however, the multiple servers are not redundant. In this scenario, each search server is configured to crawl a different set of content databases. Because the primary reason for deploying multiple search servers is to scale for capacity or performance, subsequent planning articles will help you decide if multiple servers are recommended for your deployment. For more information, see Plan for performance and capacity (Windows SharePoint Services)"
Joel, for one project I am architecting we are looking at using an 4 dedicated WFE, 2x Search (plan to run Excel/BDC on this in future), 1x Index and SQL Cluster. The split from WFE to search is initially driven by the storage estimates for local storage on the search servers. Going forward we expect to have the options of rolling in dedicated WFE for separate portal/web but utilise the SSPs on the shared search/application servers. We have split the search/index as we need redundancy and my understanding is that propagation from the index box does not happen if it is also runs search. The solution is based on 32bit so memory limits also play a part here.
Andrew. What you're saying makes sense for MOSS 2007. This post is about WSS 3.0.
Your farm looks like the classic large farm similar to what many did in SPS 2003.
Looks good. Thumbs up.