Internet SharePoint sites get more accurate with a larger bandwidth when the multi-farm deployment is chosen. When you have physically separated data centers, or different customization approaches and policies, or even different support policies and SLA, you might also chose multi-farm deployment. Although, the real use of multi-farm is in a development-test-production scenario. The developer farm would be a place where developers could deploy their features, trying to integrate their individual portions of code to the entire solution. The development could then produce a .msi file packaging all that .wsp files and installing them on the test server. When client gives you the green light, you’re good to go to the production server. That’s the multi-server most usual case.
Farm deployment is more likely Internet or even high-loaded Intranet websites that got a real good planning on which ones are the application servers and which ones are the web front end servers. Those Farm deployments can vary on a single farm to a large farm.
Single farm deployment would match a really small Intranet or a developer’s machine case. Single farm deployments consists on real simple and good environments to test your development work, since you manage from SQL to the 14 folder from a single machine.
Infrastructure vs. content database
When developing custom applications on the SharePoint platform, there’s always the possibility that resources to those applications come from either infrastructure, e.g. file system, or come from content database, e.g. typed SharePoint objects. Either way, it is important to know that when dealing with NLB WFE servers, all the files that are in the infrastructure layer must be present on all WFEs’ file systems.
Web applications
A web applications is created when Central Administration is first installed. More web applications can be installed by time. Each one is ran under a user account of the farm’s domain, using a specific Authentication method (either classic or claims-based). Creating new web applications imply on choosing it’s security configuration, configuring NLB, and attaching an application pool under IIS, but fortunately most of that work is made through a wizard in SharePoint. SP 2010 introduces a new architecture view, where web applications can be now associated with different services through service proxies.
Each Web application, even the extended ones, have an entry point on the file system, right on the c:\inetpub\ directory. Those web applications also maps to the 14 hive, including the _controltemplates, _layouts, _vit_bin and _wpresources virtual directories. Also, each web application has a special file on the root of it, the web.config file. That file is responsible for holding application settings, several modules, safe entries, and so on.
Application pools
An application pool defines a group of one or more worker processes, configured with common settings that serve requests to one or more applications that are assigned to that application pool. Because application pools allow a set of Web applications to share one or more similarly configured worker processes, they provide a convenient way to isolate a set of Web applications from other Web applications on the server computer. Process boundaries separate each worker process; therefore, application problems in one application pool do not affect Web sites or applications in other application pools. Application pools significantly increase both the reliability and manageability of your Web infrastructure.
You can choose to use the default application pool provided by IIS on install, or you can create your own application pool. You can run as many application pools on your IIS 7 server as you need, though this can affect server performance. Application pools can contain one or more worker processes. Each worker process represents work being done for a Web site, Web application, or Web service. You can create a Web garden by enabling multiple worker processes to run in a single application pool.
Feature activation failures
Activation dependencies must abide by certain rules to avoid, for example, circular dependencies, dependency chains that limit performance, and so on.
Same-Scope Rules
# If a Feature is dependent on another Feature at the same scope, and the second Feature is not activated when the first one is activated, Microsoft SharePoint Foundation activates the second Feature.
# If a Feature is deactivated, SharePoint Foundation deactivates a same-scope dependent hidden Feature when the last visible Feature that has an activation dependency on that hidden Feature is deactivated.
Cross-Scope Rules
# Cross-scope activation dependencies are not supported if the Feature depended upon is at a more restrictive scope. For example, a site collection–scoped Feature cannot have an activation dependency on a Web site–scoped Feature.
# Feature activation dependencies are not supported across scopes if the Feature that is depended upon is not visible. In other words, a Web site–scoped feature cannot be dependent on a site collection–scoped Feature that is not visible in the user interface.
# If the Feature that is depended upon is not activated, activation of the depending Feature fails. For example, if a Web site–scoped Feature depends on a site collection–scoped Feature that is not activated, activation of the Web site-scoped Feature (or of a site definition that contains a Web site-scoped Feature) fails.
General Rules
# Dependencies can work only one level deep. In other words, dependency chains are not supported. SharePoint Foundation does not support more than one level in activation dependencies if the last Feature is visible—that is if a visible Feature depends on a second visible Feature that in turn depends on a third visible Feature. However, SharePoint Foundation does support more than one level in activation dependencies if a visible Feature depends on a second visible Feature that in turn depends on a hidden Feature.
# You can target an activation dependency against hidden or visible Features, but hidden Features cannot have activation dependencies. The Hidden attribute on the Feature element determines whether the Feature is displayed in the user interface.
# When more than one Feature has a dependency on a given Feature, keep in mind the danger of leaving one of the depending Features without the required Feature dependencies. For example, assume that a visible, site collection–scoped Feature named Feature B depends on a hidden, site collection–scoped Feature named Feature A, and that a third visible, Web site–scoped Feature named Feature C is also dependent on Feature A. Deactivating Feature B also deactivates Feature A, thus leaving Feature C without the required Feature dependencies.
Publishing application to front end
Applications published to the front end consists on having a solution package that gets first installed on the farm and then deployed to web applications. Once a solution package is installed, features, resources, images and other kind of information is installed on the web front end server. It’s important to notice that some features for example can be hidden from UI SharePoint administration, and some information like images and resources are only visible on the 14 hive.
It’s also important that all applications installed on a NLB farm get deployed on the WFE servers that need the file system files to exist, otherwise they would be missing and responses could not be mounted successfully.
Security context
SharePoint uses a user security token created by either Windows authentication or forms authentication to establish its own security context. SP security token is used to conduct access to control checks in internal WSS objects such as sites, lists, and items. However, just because SharePoint adds it’s own authorization layer doesn’t mean that the Windows authorization layer goes away.
The SharePoint components you write, such as Web Parts and application pages, often must access external resources. Access control to these external resources is controlled not by SP, but instead by the Windows operating system itself, which means that you also must be aware of the current Windows security context as well as the WSS security context.
The standard web.config file for SharePoint Web applications has the following entry:
By setting the impersonate attribute to true, SharePoint instructs the ASP.NET runtime to process all requests under the Windows security context of the current user. When you write code for a Web Part or application page that attempts to access an external resource, such as a file system resource, database call, or Web service call, it runs under the impersonated Windows identity. This enables the Windows authorization subsystem (local or remote) to determine whether it should grant or deny access.
Understanding the Windows security context is fairly straightforward when you are using the default Windows Authentication provider because its identity is synchronized to the same user account as the identity of the SharePoint security context. However, things aren’t so obvious when you are using forms authentication. Because forms authentication doesn’t involve authenticating against a Windows account, the Windows security content takes on the identity of the IUSR_MACHINENAME account, or the account specified in the Authentication Methods dialog box of IIS (the same dialog box that enables IIS anonymous access).
Please note that forms authentication impersonates the anonymous access Windows account. As credentials leave SharePoint and transition to the Windows authentication protocol, this anonymous user account is used.
Feature scope
You can activate a Feature for a single scope, including farm, Web application, site collection, and Web site. The Feature scope is determined by the setting of the Scope attribute in the Feature element.
While a Web site Feature is one that you scope at the individual Web site level, a site collection Feature contains items that apply to the site collection as a whole (for example, content types that are shared across the site collection), as well as items that can be activated per site. Elements that can have either site collection or site scope include list definitions (templates and instances), modules (file sets), and item content type behaviors (per-item custom menu options and per-item events).
You can activate or deactivate a Web application Feature, and it can contain, for example, the following types of elements:
# Administrative Web application links or other links
# Delegate control registrations
# Feature/site template associations
# Document transform registrations
You scope a farm Feature for an entire server farm. A farm Feature contains a number of elements that are critical for implementing applications and logic anywhere within a deployment.
Feature dependencies
A Feature activation dependency expresses a requirement in the relationship between two Features. You can express activation dependencies either for Features of the same scope or for Features at a higher scope. A cross-scope activation dependency exists when a Feature at a particular scope has a dependency on another Feature that is at a different scope. An example of a cross-scope activation dependency would be a Web site–scoped Feature being dependent on a site collection–scoped Feature.
More Here
Courtesy:http://sharepointstream.com/2010/12/15/identify-and-resolve-deployment-issues/