Amostra de design: sites de colaboração (SharePoint Foundation 2010)
Aplica-se a: SharePoint Foundation 2010
Tópico modificado em: 2016-11-30
Este artigo descreve uma implementação prática de componentes de arquitetura lógica para se obter um design viável e foi concebido para uso junto com os seguintes exemplos de design:
Exemplo de design: sites de colaboração com autenticação clássica
Exemplo de design: sites de colaboração com autenticação baseada em declarações
Para baixar qualquer um desses modelos, consulte o artigo sobre Exemplos de design do SharePoint Foundation 2010: colaboração com autenticação clássica ou com autenticação baseada em declarações (https://go.microsoft.com/fwlink/?linkid=219157&clcid=0x416).
Neste artigo:
Sobre os exemplos de design
Metas globais de design
Farms de servidores
Usuários, zonas e autenticação
Sites de administração
Serviços
Pools de aplicativos
Aplicativos Web
Conjuntos de sites
Bancos de dados de conteúdo
Zonas e URLs
Políticas de zonas
Os exemplos de design mostram uma implantação corporativa genérica do SharePoint Foundation 2010. Eles se aplicam a quase todos os componentes de arquitetura lógica e mostram como esses componentes são incorporados no design global. Os dois exemplos ilustram os mesmos serviços e sites, mas incorporam métodos de autenticação diferentes, como se segue:
Autenticação clássica: esse exemplo de design representa um caminho para a atualização de sites do Windows SharePoint Services 3.0 para o SharePoint Foundation 2010. Ele incorpora a autenticação clássica, na qual são usados métodos de autenticação do Windows para acessar sites. É usada uma zona diferente para cada método de autenticação. Embora a autenticação do Windows seja usada para sites do SharePoint, um produto de firewall ou gateway pode ser configurado para usar a autenticação baseada em formulários, com o objetivo de coletar credenciais do Windows que são encaminhadas para o SharePoint Foundation 2010. São adicionadas ao diretório corporativo contas de funcionários parceiros.
Autenticação baseada em declarações: esse exemplo de design incorpora o novo modelo de autenticação baseada em declarações. Vários provedores de autenticação e diferentes tipos de autenticação são implementados em uma única zona. A autenticação de declarações oferece suporte para a autenticação baseada em formulários, a autenticação baseada em tokens SAML e a autenticação do Windows. Esse exemplo de design adiciona empresas parceiras que usam autenticação baseada em tokens SAML para autenticação direta em diretórios de parceiros. Há diversas opções de provedores para contas de funcionários parceiros.
Use o exemplo de design que melhor representa seus requisitos de autenticação.
Este artigo descreve as metas de design para os exemplos e explica como essas metas serão alcançadas com o uso dos componentes de arquitetura lógica ilustrados nos exemplos.
Sobre os exemplos de design
Os exemplos de design mostram uma implantação de uma empresa fictícia chamada Fabrikam, Inc. Se você estiver planejando uma solução com um ou mais dos tipos de sites de colaboração representados nesse modelo, poderá usar o modelo como base para seu próprio projeto.
O modelo mostra uma implantação genérica do SharePoint Foundation 2010 e representa os três seguintes tipos de sites de colaboração:
Sites de equipe
Sites pessoais
Sites de colaboração de parceiro
Eles se aplicam a quase todos os componentes de arquitetura lógica e mostram como esses componentes são incorporados no design global. Este artigo descreve as metas de design para os exemplos e explica como essas metas serão alcançadas com o uso dos componentes de arquitetura lógica ilustrados no modelo.
Cada um dos diferentes tipos de sites de colaboração:
Hospeda dados com características diferentes.
Está sujeito a um perfil de utilização diferente.
Exige uma estratégia diferente de gerenciamento de permissões.
Consequentemente, as opções de design no modelo se destinam a otimizar o desempenho e a segurança de cada aplicativo.
Sites de equipe
Os sites de equipe representam sites de colaboração altamente estruturados e gerenciados com as seguintes características:
Há um número menor de conjuntos de sites de alto nível e esses conjuntos se destinam à inclusão de uma grande quantidade de dados (em comparação com os sites pessoais).
As URLs de nível superior são significativos para cada equipe.
As hierarquias, taxonomias e personalizações do site têm mais consideração.
Cada conteúdo de equipe está em um banco de dados separado e pode ser gerenciado separadamente.
Sites pessoais
Os sites pessoais fornecem uma alternativa para os sites de equipe altamente gerenciados. Você pode permitir que os usuários criem seus próprios conjuntos de sites usando o Gerenciamento de Site Pessoal. Ative o Gerenciamento de Site Pessoal na Administração Central. Esse método é melhor usado quando você deseja permitir que grupos ou comunidades criem sites. Esse método também funciona bem quando você está hospedando sites e deseja permitir que os usuários criem sites sem aguardar por um processo detalhado.
As características dos sites pessoais são geralmente diferentes dos sites altamente gerenciados. Essas características podem incluir o seguinte:
Número grande de conjuntos de site de nível superior
Pequena quantidade de dados por conjunto de sites
As URLs que são gerenciadas automaticamente mas geralmente não significativas
Existem diversas compensações que você deve conhecer ao planejar a implementação dos sites pessoais. As compensações na seguinte lista afetarão a forma na qual você gerencia os sites pessoais:
Em vez de implementar uma taxonomia, os sites são criados livremente, sem um princípio de organização entre sites. Como cada novo site é um conjunto de sites, os modelos e a navegação não podem ser compartilhados entre sites pessoais.
Como cada conjunto de sites oferece pesquisa somente para o conteúdo nesse conjunto de sites, não há agregação de resultados de pesquisa entre os conjuntos de sites.
Os conjuntos de sites podem variar muito em tamanho e utilização.
Sites podem ser facilmente abandonados.
O gerenciamento de sites pessoais pode incluir o gerenciamento do armazenamento de conteúdos com base no tamanho de destino dos bancos de dados de conteúdo e na exclusão regular de sites que não são mais usados.
Para obter mais informações sobre como implementar o Gerenciamento de Site Pessoal, consulte Turn on or turn off self-service site creation (SharePoint Foundation 2010).
Sites de colaboração de parceiro
O aplicativo Web do parceiro hospeda sites disponíveis externamente para colaboração segura com empresas parceiras e parceiros individuais. Esse aplicativo tem como objetivo facilitar para os funcionários a criação de sites para colaboração segura. Os parceiros não têm permissão de acesso a outros tipos de conteúdo hospedados no farm de servidores. O design de aplicativos de serviço e zonas está direcionado para essa meta. Além disso, os proprietários de sites individuais gerenciam as permissões de seus sites, convidando somente os participantes necessários para colaboração.
Metas globais de design
O modelo mostra uma implementação prática dos recursos do SharePoint Foundation 2010 com vários tipos diferentes de aplicativos de colaboração (sites de equipe, sites pessoais e sites de parceiro). As implementações de design de cada aplicativo de site são abordadas neste artigo. As metas principais de design para o modelo incluem o seguinte:
Criar uma estrutura para projetar um ambiente que possa se expandir. Decisões de design para aplicativos individuais de colaboração não impedem a adição de outros aplicativos. Por exemplo, uma implantação inicial pode incluir somente sites de equipe de colaboração ou sites de parceiro. Usando um design de arquitetura lógica semelhante, você pode adicionar os outros tipos de sites de colaboração à solução sem afetar o design dos sites de colaboração. Em outras palavras, o design não incorpora opções de design que limitam o uso do ambiente.
Fornecer acesso a diversas classes de usuários sem comprometer a segurança do conteúdo nos diferentes aplicativos de colaboração. Usuários de diferentes zonas da rede (interna e externa) com fornecedores de autenticação diferentes podem participar da colaboração. Além disso, os usuários só podem acessar o conteúdo destinados a eles. Ao seguir um design de arquitetura lógica semelhante, você cria a oportunidade de fornecer acesso aos usuários em vários locais e com objetivos diferentes. Por exemplo, seu design inicial pode se destinar apenas a funcionários internos. Entretanto, com o uso de um design similar, você permite o acesso a funcionários remotos, funcionários parceiros ou mesmo clientes.
Garantir que o design possa ser usado em um ambiente de extranet. São feitas opções de design deliberadas para garantir que os farms de servidores possam ser implantados com segurança em uma rede de perímetro ou em qualquer uma das topologias de extranet.
O restante deste artigo discute cada componente lógico que aparece no modelo (de cima para baixo), bem como as opções de design que são aplicadas ao modelo. A finalidade dessa abordagem é demonstrar as diferentes maneiras de se configurar componentes da arquitetura lógica com base no aplicativo.
Farms de servidores
O modelo mostra um farm de cinco servidores. No entanto, o modelo poderia ser implementado em qualquer tamanho de farm, incluindo um único servidor. O farm de servidores no modelo é composto por cinco servidores com esta topologia:
Dois servidores Web front-end
Um servidor de aplicativos para o servidor de pesquisa ou os aplicativos de serviço (opcional)
Dois servidores de banco de dados, clusterizados ou espelhados
O modelo mostra a arquitetura lógica do SharePoint Foundation 2010 mostrando o seguinte:
Todos os sites são espelhados nos servidores Web front-end.
O site da Administração Central está instalado em um servidor de aplicativos para ficar protegido contra o acesso direto dos usuários.
Na verdade, o número de computadores servidores e a topologia do farm de servidores não são importantes para a arquitetura lógica, exceto para aumentar a capacidade e o desempenho conforme necessário. A arquitetura lógica pode ser projetada independentemente da topologia do farm de servidores. O processo de planejamento do desempenho e da capacidade ajudará a dimensionar o farm de servidores de forma que ele atenda às suas metas de desempenho e de capacidade. Para obter mais informações, consulte Recomendações e resultados de testes de desempenho e capacidade (SharePoint Foundation 2010).
Usuários, zonas e autenticação
Ao criar um aplicativo Web no SharePoint Foundation 2010, é preciso selecionar a autenticação baseada em declarações ou a autenticação clássica. O modo de autenticação determina como as contas são usadas internamente pelo SharePoint Foundation 2010. A tabela abaixo resume as duas abordagens.
Tipo de autenticação |
Descrição |
Recomendações |
Autenticação de modo clássico |
As contas de usuário são tratadas pelo SharePoint Foundation 2010 como contas tradicionais dos Serviços de Domínio Active Directory (AD DS). Há suporte para os seguintes protocolos de autenticação: Kerberos, NTLM, Básica, Digest e Anônimo. Não há suporte para a autenticação baseada em formulários. Apenas um método de autenticação pode ser configurado em uma zona. |
O modo clássico é recomendado para a atualização de ambientes do Windows SharePoint Services 3.0, nos quais não é exigida a autenticação baseada em formulários. Se você estiver atualizando, não precisará executar a migração de usuário caso selecione a autenticação de modo clássico. |
Autenticação baseada em declarações |
As contas de usuário são tratadas pelo SharePoint Foundation 2010 como identidades de declarações. Contas do Windows são automaticamente convertidas em identidades de declarações. Esse modo também oferece suporte para a autenticação baseada em formulários e para a autenticação em um provedor de identidade confiável. Podem ser configurados em uma única zona vários tipos de autenticação. |
A autenticação baseada em declarações é recomendada para novas implantações do SharePoint Foundation 2010. Ela é necessária para atualizar soluções do Windows SharePoint Services 3.0 que exigem a autenticação baseada em formulários. |
Os dois exemplos de design abordados neste artigo representam essas duas opções. As seções a seguir discutem especificamente como a autenticação é incorporada nesses dois exemplos de design.
Exemplo de design com autenticação no modo clássico
O exemplo de design que usa a autenticação no modo clássico incorpora a abordagem tradicional de autenticação de uma zona por tipo que foi usada na versão anterior. Por esse motivo, esse exemplo fornece um roteiro de atualização do Windows SharePoint Services 3.0 para o SharePoint Foundation 2010.
O único problema é que a autenticação baseada em formulários não tem suporte no modo clássico. Quando você usa a autenticação de modo clássico, todas as contas autenticadas devem residir nos Serviços de Domínio Active Directory (AD DS). A recomendação para os usuários que estejam acessando sites remotamente é utilizar a autenticação baseada em formulários no produto de firewall ou gateway para coletar as credenciais do Windows que são encaminhadas ao farm do SharePoint.
O exemplo no modo clássico mostra três classes de usuários, cada uma delas atribuída a uma zona diferente. Em cada aplicativo Web, você pode criar até cinco zonas usando um dos nomes de zona disponíveis: Padrão, Intranet, Internet, Personalizada ou Extranet.
A tabela a seguir mostra as zonas, os usuários e o tipo de autenticação determinado pelo exemplo de design no modo clássico.
| Zona | Usuários | Autenticação |
|---|---|---|
Intranet |
Funcionários internos |
NTLM ou Kerberos |
Padrão |
Funcionários remotos |
NTLM ou Kerberos (usando a autenticação baseada em formulários no produto de firewall ou gateway para coletar e encaminhar as credenciais) |
Extranet |
Parceiros individuais |
NTLM ou Kerberos (usando a autenticação baseada em formulários no produto de firewall ou gateway para coletar e encaminhar as credenciais) |
Exemplo de design com autenticação baseada em declarações
A autenticação baseada em declarações é recomendada para todas as novas implantações do SharePoint Foundation 2010 e é necessária para atualizar as soluções do Windows SharePoint Services 3.0 que exigem a autenticação baseada em formulários. Além de fornecer os métodos padrão de autenticação do Windows, a autenticação baseada em declarações permite a autenticação com base em outros diretórios, como Windows Live ID, Active Directory Federation Services (AD FS) 2.0 ou um provedor de identidade de terceiros que ofereça suporte para tokens de SAML e o protocolo WS Federation.
No exemplo de design com autenticação baseada em declarações, a autenticação baseada em declarações é usada no farm colaborativo. Essa autenticação permite o uso de vários tipos de autenticação na mesma zona. O exemplo de design usa a zona Padrão para todos os tipos de autenticação. A tabela abaixo mostra as zonas, os usuários e o tipo de autenticação indicados por esse exemplo para o farm colaborativo.
| Zona | Usuários | Autenticação |
|---|---|---|
Intranet |
Funcionários internos e remotos |
AD DS (ou repositório do LDAP com autenticação baseada em formulários ou autenticação SAML) |
Padrão |
Parceiros individuais |
Windows Live com autenticação SAML ou banco de dados do SQL Server com autenticação baseada em formulários |
Extranet |
Empresas parceiras |
Provedor de identidade de parceiro confiável com autenticação SAML |
No exemplo de design, os sites de equipe e os sites pessoais só estão disponíveis a funcionários, estejam eles dentro ou fora da rede. O exemplo de design implementa apenas uma URL (que usa SSL) para cada um desses sites, que pode ser usada interna e externamente. São usadas contas do AD DS. Se necessário, o LDAP pode ser usado com a autenticação baseada em formulários ou SAML, que requer configuração adicional.
No exemplo de design, o aplicativo Web do parceiro representa um site de extranet que está disponível a funcionários parceiros e empresas parceiras. O uso da autenticação baseada em declarações neste cenário exige a definição de configurações de confiança para usar um ou mais STS (serviços de token de segurança) externos. Isso pode ser fornecido através de uma das abordagens a seguir:
O farm do SharePoint pode ser configurado para confiar em um STS externo, como o STS associado ao Windows Live (para a autenticação de parceiros individuais) ou o STS que reside em uma empresa parceira (para autenticação diretamente no diretório do parceiro).
O STS dentro do ambiente corporativo pode ser configurado para confiar em um STS externo. Essa relação deve ser estabelecida explicitamente pelos administradores nas duas organizações. Neste cenário, o farm do SharePoint é configurado para confiar apenas no STS que reside em seu próprio ambiente corporativo. Esse STS interno verifica o token que recebe do STS externo e depois emite um token que permite ao usuário parceiro acessar o farm do SharePoint. Esta é a abordagem recomendada.
Uma alternativa à implementação de um ambiente baseado em declarações para autenticar parceiros é usar a autenticação baseada em formulários e gerenciar essas contas usando um repositório separado, como um banco de dados.
Para obter mais informações sobre como implementar o ambiente de autenticação baseada em declarações, consulte o white paper sobre identidade baseada em declarações para o Windows: introdução aos Serviços de Federação Active Directory 2.0, ao Windows CardSpace 2.0 e ao Windows Identity Foundation (https://go.microsoft.com/fwlink/?linkid=196776&clcid=0x416).
Zonas
Quando você cria zonas, várias decisões são importantes para o sucesso da implantação. Tais decisões incluem decisões de projeto e de configuração para as seguintes zonas:
A zona Padrão
Zonas para acesso externo
As seções a seguir descrevem as decisões que são incorporadas ao modelo.
Requisitos de configuração da zona Padrão
A zona que merece a maior consideração é a zona Padrão. O SharePoint Foundation 2010 inclui os seguintes requisitos sobre a configuração da zona Padrão:
Quando uma solicitação de usuário não puder ser associada a uma zona, são aplicadas a autenticação e as políticas da zona Padrão. Consequentemente, a zona Padrão deve ser a mais segura.
Emails administrativos são enviados com links para a zona Padrão. Esses emails incluem mensagens para os proprietários de sites que estão atingindo limites de cota. Consequentemente, os usuários que recebem esses tipos de mensagens e alertas devem poder acessar os links através da zona Padrão. Isso é especialmente importante para proprietários de sites.
Os conjuntos de sites com nome de host só estão disponíveis através da zona Padrão. Todos os usuários que devem acessar conjuntos de sites com nome de host devem ter acesso através da zona Padrão.
Configurando zonas para um ambiente de extranet
Em um ambiente de extranet, o design de zonas é muito importante pelos seguintes motivos:
As solicitações de usuários podem ser iniciadas em várias redes diferentes. No modelo, os usuários iniciam solicitações na rede interna, na Internet e em empresas parceiras.
Usuários podem participar da colaboração entre vários aplicativos Web. Por exemplo, os funcionários internos e remotos podem contribuir potencialmente e administrar conteúdo em todos os aplicativos Web: sites de equipe, sites pessoais e sites de parceiro.
Em um ambiente de extranet, verifique se os seguintes princípios estão sendo observados:
Configurar zonas entre vários aplicativos Web para espelhar umas às outras. A configuração de autenticação e os usuários destinatários devem ser os mesmos. No entanto, as políticas associadas a zonas podem ser diferentes entre aplicativos Web. Por exemplo, verifique se a zona da Intranet é usada para os mesmos funcionários entre todos os aplicativos Web. Em outras palavras, não configure a zona da Intranet para funcionários internos em um aplicativo Web e para funcionários remotos em outro.
Configurar os mapeamentos de acesso alternativo de modo correto e preciso para cada zona e cada recurso.
Nos exemplos de design, a zona Padrão de cada aplicativo Web é configurada de forma idêntica. Além disso, outras zonas são configuradas de forma idêntica em todos os aplicativos Web, conforme necessário.
Mapeamentos de acesso alternativos são criados automaticamente na ocasião em que a zona é criada. No entanto, se você usar um servidor proxy ou produto de gateway para tornar os sites disponíveis na Internet, terá que adicionar uma entrada de mapeamento de acesso alternativo adicional a cada zona. Isso garante que as URLs que são retornadas para os usuários fora da rede interna estejam disponíveis para usuários de acordo com o contexto de sua zona.
Se as zonas nos aplicativos Web não se espelharem, e os links para recursos externos forem incorretos, os riscos incluirão o seguinte:
Nomes de servidores, nomes DNS (Domain Name System) e endereços IP poderão ficar expostos fora da rede interna.
Os usuários não conseguirão acessar sites e outros recursos.
Sites de administração
No modelo, o site de Administração Central é hospedado no servidor de aplicativos. Isso protege o site do contato direto com os usuários. Se um afunilamento de desempenho ou o comprometimento da segurança afetar a disponibilidade dos servidores Web front-end, o site da Administração Central permanecerá disponível. Além disso, o site de Administração Central é hospedado dentro de um pool de aplicativos dedicado e do aplicativo Web.
As URLs com carga balanceada para sites de administração não são articuladas no modelo ou neste artigo. As recomendações incluem:
Se números de porta forem usados em URLs administrativas, use portas não padrão. Por padrão, os números de porta são incluídos em URLs por padrão. Embora números de portas não costumem ser usados em URLs de clientes, seu uso para sites de administração pode aumentar a segurança ao limitar o acesso a esses sites a portas não padrão.
Crie entradas DNS separadas para sites de administração.
Serviços
A arquitetura de serviços que é ilustrada no modelo só representa dois aplicativos de serviços incluídos no SharePoint Foundation 2010. Os dois agrupamentos de serviços (representados usando uma caixa vermelha ou uma caixa com pontilhados azuis) não são necessários no exemplo fornecido porque eles incluem os mesmos dois aplicativos de serviços. No entanto, considere os aplicativos de serviços que são necessários para os sites de parceiro e configure os dois grupos de serviços adequadamente. As opções a serem consideradas incluem:
Considere se uma instância separada do aplicativo Serviço de Conectividade de Dados Corporativos é necessária para os sites de parceiros. Se ela for necessária, considere a implantação desse aplicativo de serviço nos sites de parceiro no modo particionado. Isso garante que os parceiros que não tenham acesso aos dados nos sites de parceiros.
As empresas de terceiros podem desenvolver os aplicativos de serviços para o SharePoint Foundation 2010. Se você estiver usando esses, decida se são apropriados para serem usados em todos os sites.
Pools de aplicativos
Os pools de aplicativos separados do Serviços de Informações da Internet (IIS) são geralmente implementados para obter a isolação de processo nos sites. Pools de aplicativos permitem que vários sites sejam executados no mesmo computador servidor, mas ainda mantenham seus próprios processos de trabalho e identidade. Isso reduz quaisquer possíveis problemas de segurança em um só site que permitem que um invasor injete código no servidor para atacar outros sites.
Em termos práticos, considere o uso de um pool de aplicativos dedicado para os seguintes cenários:
Para separar o conteúdo autenticado do conteúdo anônimo.
Para isolar os locais que se destinam principalmente à colaboração com parceiros externos ou clientes. Isso isola as contas externas para os sites dentro de um pool de aplicativos.
Para isolar sites nos quais os usuários tenham mais liberdade para criar e administrar sites e colaborar no conteúdo.
O modelo usa pools de aplicativos da seguinte maneira:
O site de administração é hospedado em um pool de aplicativos dedicado. Esse é um requisito do SharePoint Foundation 2010.
Todos os aplicativos de serviços são implantados em um único pool de aplicativos. A menos que haja uma razão convincente para implantar aplicativos de serviços em pools de aplicativos diferentes, essa é a configuração recomendada. Usar um pool de aplicativos para todos os aplicativos de serviços otimiza o desempenho e reduz o número de pools de aplicativos a ser gerenciado.
Os sites de colaboração internos (sites de equipe e sites pessoais) são hospedados em um pool de aplicativos.
O aplicativo Web do parceiro é hospedado em um pool de aplicativos dedicado.
Aplicativos Web
Um aplicativo Web é um site do IIS criado e usado pelo Produtos do SharePoint 2010. Cada aplicativo Web é representado por um site diferente no IIS. Você pode atribuir a cada aplicativo Web um nome de domínio exclusivo, o que ajuda a evitar ataques de script entre sites.
Em termos gerais, use os aplicativos Web para:
Separar o conteúdo anônimo do conteúdo autenticado.
Isolar usuários. No modelo, a Web do parceiro fica hospedado em um aplicativo Web dedicado e em um pool de aplicativos, para garantir que os parceiros não tenham acesso ao conteúdo de colaboração interna.
Impor permissões. Um aplicativo Web dedicado fornece a oportunidade de impor permissões usando a página Política para Aplicativo Web na Administração Central. Por exemplo, você pode criar uma política nos sites de colaboração interna para negar explicitamente o acesso a um ou mais contas de parceiros. As políticas para um aplicativo Web são impostas independentemente das permissões configuradas em sites ou em documentos individuais no aplicativo Web.
Otimizar o desempenho. Os sites apresentarão melhor desempenho se forem colocados em aplicativos Web com outros aplicativos de características de dados similares. Por exemplo, as características de dados dos sites pessoais incluem muitos sites pequenos. Em contraste, sites de equipe normalmente consistem em um número menor de sites muito grandes. Ao colocar esses dois tipos de sites em aplicativos Web separados, os bancos de dados resultantes serão compostos por dados com características similares, otimizando assim seu desempenho. No exemplo de modelo, os sites de equipe e os sites pessoais não têm requisitos exclusivos de isolamento de dados: eles compartilham o mesmo pool de aplicativos. Entretanto, os sites de equipe e os sites pessoais foram colocados em aplicativos Web separados para otimizar o desempenho.
Otimizar a capacidade de gerenciamento. Como a criação de aplicativos Web separados resulta em sites e bancos de dados separados, é possível implementar diferentes limites de site (Lixeira, expiração e tamanho) e negociar diferentes contratos de nível de serviço. Por exemplo, você poderá conceder mais tempo para a restauração dos sites pessoais se este não for o tipo mais importante de conteúdo da sua organização. Isso permite restaurar o conteúdo mais importante antes da restauração desses sites. No modelo, os sites pessoais estão inseridos em um aplicativo Web separado para permitir que os administradores gerenciem o crescimento de maneira mais intensa em comparação a outros aplicativos.
Conjuntos de sites
O conjunto de sites abrange a arquitetura lógica e a arquitetura de informações. As metas de design para conjuntos de sites, no modelo, são atender aos requisitos para o design de URLs e criar divisões lógicas de conteúdo.
Para atender aos requisitos de design de URLs, cada aplicativo Web inclui um único conjunto de sites de nível raiz. Caminhos gerenciados são usados para incorporar uma segunda camada de conjuntos de sites de nível superior. Para obter mais informações sobre requisitos de URL e sobre o uso de caminhos gerenciados, consulte Zonas e URLs posteriormente neste artigo. Além da segunda camada de conjuntos de sites, cada site é um subsite.
A figura a seguir mostra a hierarquia dos sites de equipe.
.gif "Sites de equipe")
Devido à necessidade de um conjunto de sites de nível raiz, as decisões de design enfatizam a segunda camada de conjuntos de sites. O modelo incorpora opções baseadas na natureza do aplicativo.
Sites pessoais
No modelo, os sites pessoais incorporam um site de nível superior que tem a URL http://sites. Um caminho gerenciado é incorporado (usando a inclusão de curinga), o que permite um número indefinido de sites criados pelo usuário. Todos os sites sob o caminho gerenciado são conjuntos de sites independentes que herdam o modelo de site que foi usado para criar o site de nível superior.
Para obter mais informações sobre sites pessoais, consulte Planejar o processo de criação de sites (SharePoint Foundation 2010).
Sites de equipe
Quando você projeta conjuntos de sites em um aplicativo de site da equipe, recomendamos que você crie um número finito de conjuntos de sites para a organização com base na maneira como a organização opera. Nessa abordagem, os conjuntos de sites são criados pelo administrador do SharePoint Foundation 2010. Depois de criado o conjunto de sites, as equipes podem criar sites nesse conjunto de acordo com as suas necessidades.
Essa abordagem possibilita implementar uma taxonomia ponderada que fornece estruturação para a forma como os sites de equipe são gerenciados e ampliados. Também há maior oportunidade de compartilhar modelos e navegação entre projetos e equipes que compartilham um conjunto de sites. O desafio para os arquitetos de informações é criar uma segunda camada de conjuntos de sites que faça sentido para a organização. A tabela a seguir lista as sugestões para vários tipos de organizações.
| Tipo de organização | Taxonomias sugeridas de conjunto de sites |
|---|---|
Implantação de produtos |
|
Pesquisa |
|
Instituição de ensino superior |
|
Escritório legislativo estadual |
|
Escritório jurídico corporativo |
|
Fabricação |
|
Web do parceiro
O objetivo do aplicativo Web do parceiro é ser utilizado para colaboração com parceiros externos em projetos com escopos ou durações específicos. Por padrão, os sites no aplicativo Web do parceiro não devem estar relacionados. Os requisitos do aplicativo Web do parceiro incluem assegurar que:
Os proprietários de projetos possam criar sites facilmente para colaboração dos parceiros.
Parceiros e outros contribuidores tenham acesso apenas aos projetos em que trabalham.
As permissões sejam gerenciadas por proprietários de sites.
Os resultados de pesquisa em um projeto não exponham o conteúdo de outros projetos.
Os administradores possam descobrir facilmente os sites que não estão mais em uso e excluí-los.
Para satisfazer esses requisitos, o modelo incorpora um conjunto de sites para cada projeto, que oferece os seguintes benefícios:
Conjuntos individuais de sites fornecem o nível adequado de isolamento entre projetos.
A criação de sites pessoais pode ser implementada.
Bancos de dados de conteúdo
Você pode usar as duas abordagens para incorporar bancos de dados de conteúdo ao design. O modelo incorpora as duas seguintes abordagens:
Estabeleça tamanhos de destino para os bancos de dados de conteúdo com avisos de limite máximo apropriados. Crie novos bancos de dados quando os limites máximos de tamanho forem atingidos. Com essa abordagem, os conjuntos de sites são adicionados automaticamente ao banco de dados ou bancos de dados disponíveis, somente com base nos destinos de tamanho.
Associe conjuntos de sites a bancos de dados de conteúdo específicos. Essa abordagem permite que você posicione um ou mais conjuntos de sites em um banco de dados dedicado que pode ser gerenciado independentemente de outros bancos de dados.
Se optar por associar conjuntos de sites a bancos de dados de conteúdo específicos, você poderá usar um destes métodos:
Use o Windows PowerShell para criar um conjunto de sites em um banco de dados específico.
Designe um banco de dados a um único conjunto de sites aplicando as seguintes configurações de capacidade de banco de dados:
Número de sites antes de um evento de Aviso ser gerado = 1
Número máximo de sites que podem ser criados neste banco de dados = 1
Adicione um grupo de conjuntos de sites a um banco de dados dedicado executando estas etapas:
No aplicativo Web, crie o banco de dados e defina seu status como Pronto.
Defina o status de todos os outros bancos de dados como Offline. Enquanto os bancos de dados de conteúdo estiverem offline, não será possível criar novos conjuntos de sites. Entretanto, aqueles já existentes em bancos de dados offline continuarão disponíveis para operações de leitura e gravação.
Crie os conjuntos de sites. Eles são automaticamente adicionados ao banco de dados.
Defina o status de todos os outros bancos de dados como Pronto.
Sites de equipe
O exemplo de design incorpora um banco de dados dedicado para cada conjunto de sites de equipe. Essa abordagem permite gerenciar cada banco de dados de equipe de forma independente para backup, restauração e migração. Além disso, quando um projeto está completo, você pode arquivar facilmente o banco de dados associado ao projeto. O exemplo de design fornece definições de banco de dados com base em um limite de 30 GB para conjuntos de sites. Escolha um limite apropriado para os sites de equipe em sua organização.
Sites pessoais
Para os sites pessoais, o modelo obtém eficiência de dimensionamento ao gerenciar bancos de dados quanto ao tamanho máximo de destino. As configurações a seguir são definidas para se atingir essa meta:
Limite máximo de armazenamento do site: essa configuração, definida na página Modelos de Cota da Administração Central, limita o tamanho de um site.
Lixeira de segundo estágio: essa configuração, definida na página Definições Gerais do Aplicativo Web, determina a quantidade de espaço adicional que é alocada para a Lixeira de segundo estágio.
Número máximo de sites que podem ser criados neste banco de dados: essa configuração é definida quando você cria um banco de dados. Calcule o tamanho total permitido usando os números que você especificar para os dois valores anteriores. Em seguida, com base na meta de tamanho para cada banco de dados, determine quantos sites caberão no banco de dados.
O exemplo de design fornece as seguintes definições de exemplo de tamanho, com base no tamanho de um banco de dados de destino, que corresponde a 175 GB, e no tamanho de Meu Site de destino, que é de 1 GB:
Limites de tamanho por site = 1 GB
Tamanho de destino do banco de dados = 175 GB
Reservado para a Lixeira de segundo estágio = 15 por cento
Número máximo de sites = 180
Aviso de nível do site = 150
Quando o aviso de nível do site for alcançado, crie um novo banco de dados. Depois de criar o novo banco de dados, novos sites pessoais serão adicionados alternadamente ao novo banco de dados e ao banco de dados existente até ser alcançado o número máximo de sites de um dos bancos de dados.
Web do parceiro
Semelhante aos sites pessoais, a Web do parceiro obtém eficiência de dimensionamento ao gerenciar bancos de dados quanto ao tamanho máximo de destino.
Como a Web do parceiro fica hospedada em um aplicativo Web dedicado, você pode criar limites de tamanho adequados aos tipos de sites que são criados. A amostra de design fornece as seguintes configurações de tamanho de exemplo:
Tamanho de destino do banco de dados = 200 GB
Cota de armazenamento por site = 5 GB
Número máximo de sites = 40
Zonas e URLs
O modelo mostra como coordenar URLs entre vários aplicativos em uma implantação corporativa.
Metas de design
As metas a seguir influenciam as decisões de design para URLs:
Convenções de URL não limitam as zonas através das quais o conteúdo pode ser acessado.
As portas padrão HTTP e HTTPS (80 e 443) podem ser usadas em todos os aplicativos no exemplo de design.
Números de porta não são incluídos nas URLs. Na prática, esses números de porta não costumam ser usados em ambientes de produção.
Princípios de design
Para atingir essas metas de design, os seguintes princípios de design são aplicados:
Conjuntos de sites com nome de host não são usados. Observe que esses tipos de conjuntos são diferentes dos cabeçalhos de host do IIS. Conjuntos de sites com nome de host não trabalham com o recurso de mapeamentos de acesso alternativos. Esse recurso é necessário para acessar o mesmo conteúdo em várias URLs de domínio. Consequentemente, quando sites com nome de host são usados, eles ficam disponíveis somente através da zona Padrão.
Cada aplicativo incorpora um único conjunto de sites raiz. Esse é um requisito para o uso de mapeamentos de acesso alternativos. Se vários conjuntos de sites raiz forem necessários em um aplicativo Web, e você pretende usar somente a zona Padrão para o acesso dos usuários, conjuntos de sites com nome de host serão uma boa opção.
Para os aplicativos que incluem vários conjuntos de sites de alto nível, nos quais cada conjunto de sites representa uma equipe ou um projeto de nível superior (por exemplo, sites de equipe), o modelo incorpora caminhos gerenciados, que fornecem maior controle sobre as URLs desses tipos de site.
Compensações de design
Atingir as metas de design implica algumas compensações, entre elas:
As URLs são mais longas.
Conjuntos de sites com nome de host não são usados.
Projetando URLs com carga balanceada
Ao criar um aplicativo Web, selecione uma URL com carga balanceada a ser atribuída ao aplicativo. Além disso, crie uma URL com carga balanceada para cada zona criada em um aplicativo Web. A URL com carga balanceada inclui protocolo, esquema, nome de host e porta. Essa URL deve ser exclusiva em todos os aplicativos Web e zonas. Consequentemente, cada aplicativo e cada zona em cada aplicativo exigem uma URL exclusiva no exemplo de design.
Sites de colaboração interna
Os dois tipos de sites de colaboração interna exigem uma URL exclusiva. No exemplo de design, o público-alvo pretendido para o conteúdo de intranet é formado por funcionários internos e remotos. No exemplo de design de autenticação baseada em declarações, os funcionários usam as mesmas URLs de cada um desses aplicativos, independentemente de trabalharem no local ou remotamente. Embora essa abordagem adicione uma camada de segurança ao design (todo o tráfego ocorre via SSL), ela exige o roteamento do tráfego interno por meio do produto de firewall ou de gateway junto com o tráfego remoto ou a definição de um ambiente DNS dividido para resolver solicitações internas na rede interna.
Para o exemplo de design de autenticação clássica, as URLs são diferentes para funcionários internos e remotos. A tabela a seguir mostra as URLs de funcionários internos e remotos para acessar cada aplicativo no exemplo de design de autenticação clássica.
| Aplicativo | URL de funcionário interno | URL de funcionário remoto |
|---|---|---|
Sites de equipe |
http://teams/ |
https://teams.fabrikam.com |
Sites pessoais |
http://sites |
https://sites.fabrikam.com |
Web do parceiro
No exemplo de design, o site do parceiro é acessado por funcionários internos, remotos e por funcionários parceiros. No exemplo de design de autenticação baseada declarações, cada usuário insere a mesma URL, independentemente do método de autenticação. No exemplo de design de autenticação clássica, cada tipo diferente de usuário insere uma URL distinta. Embora os funcionários remotos e os funcionários parceiros acessem externamente o site do parceiro via SSL (HTTPS), cada grupo exige uma URL diferente para aplicar os benefícios do uso de zonas separadas. Esses benefícios incluem os diferentes métodos de autenticação e as diferentes políticas de zona. A tabela a seguir mostra as URLs que funcionários internos, remotos e parceiros usam para acessar o site do parceiro, conforme mostrado no exemplo de design de autenticação clássica.
| Zona | URL |
|---|---|
URL de funcionário interno |
http://partnerweb/ |
URL de funcionário remoto |
https://remotepartnerweb.fabrikam.com |
URL de parceiro |
https://partnerweb.fabrikam.com |
Usando inclusões explícitas e de curinga para caminhos de URL
A definição de caminhos gerenciados permite que você especifique quais caminhos no namespace da URL de um aplicativo Web são usados para conjuntos de sites. Você pode especificar que um ou mais conjunto de sites existam em um caminho distinto abaixo do site raiz. Sem caminhos gerenciados, todos os sites criados abaixo do conjunto de sites raiz fazem parte desse conjunto.
Você pode criar os dois tipos de caminhos de gerenciamento a seguir:
Inclusão explícita: um conjunto de sites com a URL explícita atribuída por você. Uma inclusão explícita é aplicada somente a um conjunto de sites. É possível criar várias inclusões explícitas abaixo de conjunto de sites raiz. Um exemplo de URL para um conjunto de sites criado com o uso desse método é http://team/team1. Existe um impacto de desempenho para cada caminho explícito adicionado; portanto, convém limitar a 20 o número de conjuntos de sites criados com uma inclusão explícita.
Inclusão de curinga: um caminho adicionado à URL. Esse caminho indica que todos os sites especificados logo após o nome do caminho são conjuntos de sites exclusivos. Essa opção é geralmente usada para aplicativos com suporte para a criação de sites pessoais. Um exemplo de URL de um conjunto de sites criado por meio desse método é http://sites/selfservice/site1.
O exemplo de design incorpora o uso dos dois tipos, conforme descrito nas seções a seguir.
Inclusões explícitas
O exemplo de design não incorpora atualmente o uso de inclusões explícitas. A tabela a seguir fornece um conjunto de URLs de exemplo para um site de intranet Fabrikam que usa a autenticação clássica na qual as URLs são diferentes para o acesso interno e o acesso remoto de funcionários.
| Funcionário interno (zona da Intranet) | Funcionário remoto (zona Padrão) |
|---|---|
http://fabrikam |
https://intranet.fabrikam.com |
http://fabrikam/hr |
https://intranet.fabrikam.com/hr |
http://fabrikam/facilities |
https://intranet.fabrikam.com/facilities |
http://fabrikam/purchasing |
https://intranet.fabrikam.com/purchasing |
Nesse exemplo, o conjunto de sites raiz, http://fabrikam, representa a home page padrão da intranet. Esse site pode hospedar conteúdo para usuários. O próximo site no caminho, por exemplo, http://fabrikam/hr e http://fabrikam/facilities, é a inclusão implícita.
Inclusões de curinga: sites de equipe, sites pessoais e Web do parceiro
Os sites de equipe, os sites pessoais e o aplicativo Web do parceiro incorporam o uso de uma inclusão de curinga. Esse tipo de inclusão é ideal para aplicativos que permitem aos usuários criar seus próprios conjuntos de sites e para aplicativos Web que incluem muitos conjuntos de sites. Uma inclusão de curinga indica que o próximo item após o curinga é um site raiz de um conjunto de sites.
Sites de equipe
No aplicativo de sites de equipe, a inclusão de curinga é usada para cada conjunto de sites de equipe. Boas práticas de governança recomendam que você mantenha o número de sites de equipe de nível superior em um intervalo gerenciável. Além disso, a taxonomia de sites de equipe deve ser lógica em relação ao modo de operação dos seus negócios.
No exemplo de design de autenticação clássica, o uso de inclusões de curinga resulta nas URLs mostradas na tabela a seguir.
| Funcionário interno (zona da Intranet) | Funcionário remoto (zona Padrão) |
|---|---|
http://teams/sites/team1 |
https://teams.fabrikam.com/sites/team1 |
http://teams/sites/team2 |
https://teams.fabrikam.com/sites/team2 |
http://teams/sites/team3 |
https://teams.fabrikam.com/sites/team3 |
Nesse exemplo, o conjunto de sites raiz, http://team, não hospeda necessariamente o conteúdo para usuários.
Sites pessoais
No modelo, os sites pessoais incluem uma inclusão de curinga denominada /selfservice (http://sites/selfservice).
Isso resulta em URLs no formato listado na tabela a seguir.
| Funcionário interno (zona da Intranet) | Funcionário remoto (zona Padrão) |
|---|---|
http://sites/selfservice/site1 |
https://sites.fabrikam.com/selfservice/site1 |
http://sites/selfservice/site2 |
https://sites.fabrikam.com/selfservice/site2 |
http://sites/selfservice/site3 |
https://sites.fabrikam.com/selfservice/site3 |
Web do parceiro
A Web do parceiro foi projetado para permitir que os funcionários criem facilmente sites para colaboração com parceiros externos. Para contribuir com essa meta, a criação de sites pessoais é permitida.
No exemplo de design de autenticação clássica, o aplicativo Web do parceiro apresenta uma inclusão de curinga denominada /sites (http://partnerweb//sites). Isso resulta em URLs no formato mostrado na tabela a seguir.
| Funcionário interno (zona da Intranet) | Funcionário remoto (zona Padrão) |
|---|---|
http://partnerweb//sites/project1 |
https://remotepartnerweb.fabrikam.com/sites/project1 |
http://partnerweb//sites/project2 |
https://remotepartnerweb.fabrikam.com/sites/project2 |
http://partnerweb//sites/project3 |
https://remotepartnerweb.fabrikam.com/sites/project3 |
Os contribuidores parceiros podem acessar os sites de parceiros usando as URLs listadas na tabela a seguir.
| Parceiro (zona da Extranet) |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb.fabrikam.com/sites/project3 |
Coordenação de URLs com AAM e DNS
Configure mapeamentos de acesso alternativo para cada URL de site no farm. Isso garante que as solicitações da Web sejam mapeadas para o site correto, especialmente em ambientes que utilizam as tecnologias de balanceamento de carga ou de proxy reverso.
A tabela a seguir lista as informações necessárias para criar ou modificar os mapeamentos de acesso alternados com base na versão de autenticação clássica do exemplo de design de arquitetura lógica.
| Site | Cabeçalho do host | Zona | Porta | URL pública do AAM |
|---|---|---|---|---|
Sites de equipe |
equipes |
Intranet |
80 |
http://teams/ |
teams.fabrikam.com |
Padrão |
443 |
https://teams.fabrikam.com |
|
Sites pessoais |
sites |
Intranet |
80 |
http://sites |
sites.fabrikam.com |
Padrão |
443 |
https://sites.fabrikam.com |
|
Web do parceiro |
partnerweb |
Intranet |
80 |
http://partnerweb/ |
remotepartnerweb.fabrikam.com |
Padrão |
443 |
https://remotepartnerweb.fabrikam.com |
|
partnerweb.fabrikam.com |
Extranet |
443 |
https://partnerweb.fabrikam.com |
As URLs de nome exclusivo, como http://teams, podem ser configuradas para o acesso à intranet. Essas URLs são resolvidas pelo cliente por meio do acréscimo de sufixo DNS do cliente, como fabrikam.com, e da realização de uma pesquisa de DNS para o nome com o sufixo. Por exemplo, quando um computador cliente no domínio fabrikam.com solicita http://teams, o computador envia uma solicitação para o DNS por http://teams.fabrikam.com.
O DNS deve ser configurado para usar um registro para cada FQDN (nome de domínio totalmente qualificado). O registro A aponta para o endereço IP com balanceamento de carga dos servidores Web que estão hospedando um site. Em uma implantação típica de produção, os servidores são configurados para usar endereços IP atribuídos estaticamente, além registros A atribuídos estaticamente no DNS.
Depois de receber os endereços IP virtuais do balanceador de cargas, o navegador cliente estabelece a comunicação com um servidor Web de front-ends no farm e envia uma solicitação HTTP com a URL original de nome exclusivo, http://teams. IIS e Produtos do SharePoint 2010 reconhecem-na como uma solicitação para a zona Intranet, com base nas configurações definidas nos mapeamentos de acesso alternado (consulte a tabela anterior). Em vez disso, se o usuário tivesse solicitado https://teams.fabrikam.com, o processo seria o mesmo, exceto que IISe Produtos do SharePoint 2010 receberiam esse FQDN e reconheceriam essa solicitação como sendo para a zona Padrão.
Em ambientes com múltiplos domínios, insera registros CNAME de DNS nos domínios em que os sites não residem. Por exemplo, se o ambiente de rede Fabrikam incluir um segundo domínio chamado europe.fabrikam.com, os registros CNAME serão inseridos para esses sites no domínio da Europa. Para o site intranet dos sites de equipe (http://teams), um registro CNAME denominado teams é adicionado ao domínio europe.fabrikam.com que aponta para teams.fabrikam.com. Em seguida, quando o sufixo DNS de um cliente é anexado às solicitações de pesquisa de DNS, uma solicitação para http://teams a partir do domínio Europe emite uma pesquisa de DNS por teams.europe.fabrikam.com e por ser dirigido pelo registro CNAME para teams.fabrikam.com.
Observação
Há um problema conhecido com alguns clientes Kerberos e resolução de registros CNAME. Para obter mais informações, consulte Problemas conhecidos com a configuração Kerberos (SharePoint Server 2010).
Políticas de zonas
É possível criar uma política para que um aplicativo Web imponha permissões no nível do aplicativo Web. Uma política pode ser definida para o aplicativo Web em geral ou somente para uma zona específica. Uma política impõe permissões em todo o conteúdo existente no aplicativo Web ou na zona. As permissões da política substituem todas as outras definições de segurança configuradas para sites e conteúdo. Você pode configurar a política com base em usuários ou em grupos de usuários, mas não em grupos do SharePoint.
Políticas não são usadas no exemplo de design de autenticação baseada em declarações para o farm colaborativo, no qual vários tipos de autenticação estão habilitados em uma única zona. Elas são implementadas no exemplo de design de autenticação clássica e no farm publicado do exemplo de design de autenticação baseada em declarações no qual a autenticação do Windows está prescrita. No farm publicado, o uso de políticas acrescenta uma camada adicional de segurança entre usuários anônimos e usuários com acesso para gerenciar sites.
O exemplo de design fornece uma ilustração: como negar o acesso a contas de parceiros pelos sites de colaboração interna.