Exemplo de design de arquitetura lógica: sites de colaboração
Atualizado em: 2009-04-23
Neste artigo:
Sobre o modelo
Metas gerais do projeto
Farms de servidores
Usuários, zonas e autenticação
Sites de administração
Pools de aplicativos
Aplicativos Web
Conjuntos de sites
Bancos de dados de conteúdo
Zonas e URLs
Diretivas de zona
Fazendo backup e restaurando sites de colaboração
Projetando colaboração externa segura
Este artigo descreve uma implantação prática de componentes de arquitetura lógica para obter um design viável. Este artigo deve ser usado em conjunto com o seguinte modelo de design de exemplo de arquitetura lógica de colaboração do Windows SharePoint Services (em inglês) (https://go.microsoft.com/fwlink/?linkid=124861\&clcid=0x416) (em inglês).
Sobre o modelo
O modelo ilustra a implantação em uma empresa fictícia chamada Fabrikam, Inc. Se estiver planejando uma solução com um ou mais dos tipos de sites de colaboração representados nesse modelo, você poderá usar o modelo como base para o seu próprio design.
O modelo ilustra uma implantação genérica do Windows SharePoint Services 3.0, com três tipos diferentes de sites de colaboração representados:
Sites de equipe
Sites pessoais
Sites de colaboração de parceiros
O modelo aplica quase todos os componentes de arquitetura lógica e ilustra como esses componentes são incorporados ao design global. Este artigo descreve as metas de design do modelo e explica como essas metas são alcançadas com a utilização dos componentes de arquitetura lógica ilustrados no modelo.
Cada tipo de site de colaboração:
Hospeda dados com diferentes características.
Está sujeito a um perfil de uso diferente.
Exige uma estratégia diferenciada de gerenciamento de permissões.
Consequentemente, as opções de design do modelo devem otimizar o desempenho e a segurança de cada aplicativo.
Sites de equipe
Os sites de equipe representam os sites de colaboração significativamente estruturados e gerenciados, nos quais:
Há um número menor de conjuntos de sites de nível superior e o objetivo desses conjuntos de sites é incluir uma grande quantidade de dados (em contraposição aos sites pessoais).
As URLs de nível superior têm significado para cada equipe.
Mais planejamento é investido em hierarquias de sites, taxonomias e personalizações.
O conteúdo de cada equipe fica armazenado em um banco de dados separado e pode ser gerenciado também separadamente.
O seguinte diagrama ilustra a hierarquia de sites de equipe:
.gif "Organização de sites de equipe")
Sites pessoais
Os sites pessoais fornecem uma alternativa aos sites de equipe altamente gerenciados. Você pode permitir que usuários e equipes criem seus próprios conjuntos de sites, usando o Gerenciamento de Sites Pessoais, um recurso que é ativado na Administração Central. A melhor utilização desse método ocorre quando o objetivo é permitir que grupos ou comunidades criem sites. Além disso, esse método funcionará bem se você hospedar sites e quiser permitir que os usuários criem sites, mas sem um processo detalhado.
Em geral, as características dos sites pessoais são diferentes em relação aos sites altamente gerenciados. As características podem incluir o seguinte:
Grande número de conjuntos de sites de nível superior.
Pequena quantidade de dados por conjunto de sites.
URLs automaticamente geradas, porém, pouco significativas.
O seguinte diagrama ilustra os sites pessoais conforme implementados no design de exemplo:
.gif "Sites para criação de site pessoal")
Há várias alternativas a serem consideradas durante o planejamento da implementação de sites pessoais, e essas alternativas afetam a maneira como esses tipos de site são gerenciados:
Em vez de implementar uma taxonomia criteriosa, os sites são criados à vontade, sem qualquer princípio organizacional entre eles. Como cada novo site é um conjunto de sites, não é possível compartilhar modelos e navegação entre os sites pessoais.
Como cada conjunto de sites fornece pesquisa somente para conteúdo nesse conjunto de sites, não há nenhuma agregação de resultados de pesquisa nos conjuntos de sites.
Os conjuntos de sites podem variar bastante em tamanho e uso.
Os sites podem ser facilmente abandonados.
O gerenciamento de sites pessoais pode incluir a administração do armazenamento de conteúdo, com base no tamanho pretendido dos bancos de dados de conteúdo, e a exclusão regular dos sites descontinuados.
Para obter mais informações sobre a implementação do Gerenciamento de Sites Pessoais, consulte Plan process for creating sites (Windows SharePoint Services).
Sites de colaboração de parceiros
O aplicativo Partner Web hospeda sites disponibilizados externamente para colaboração segura com os funcionários de empresas parceiras. O objetivo desse aplicativo é facilitar a criação de sites pelos funcionários, para colaboração segura. Os principais fatores que orientam as opções de design desse aplicativo incluem:
**Isolamento de conteúdo **Os parceiros não têm permissão para acessar outros tipos de conteúdo hospedados no farm de servidores.
**Autenticação separada das contas de parceiros **As contas de parceiros são gerenciadas por meio de autenticação de formulários. Essas contas não são adicionadas ao diretório corporativo.
**Gerenciamento de permissões **Cada proprietário de sites gerencia as permissões de seus sites, convidando somente os participantes necessários para colaborar.
O seguinte diagrama ilustra os sites de colaboração de parceiros.
.gif "Hierarquia de sites de projeto em um partner Web")
Metas gerais do projeto
O modelo ilustra uma implementação prática de recursos do Windows SharePoint Services 3.0 em vários tipos de aplicativos de colaboração (sites de equipe, sites pessoais e sites de parceiros). As implementações de design para cada um dos aplicativos de site são discutidas neste artigo. As principais metas de design incluem:
Criar uma estrutura de design de ambiente que possa crescer. As decisões de design de um aplicativo de colaboração individual não impedem a adição de outros aplicativos. Por exemplo, uma implantação inicial pode incluir somente sites de equipe colaborativos ou somente sites de parceiro. Ao usar um design de arquitetura lógica semelhante, você pode adicionar outros tipos de sites de colaboração para a solução, porém, sem afetar o design dos sites de colaboração iniciais. Em outras palavras, o design não incorpora opções design que limitem o uso do ambiente.
Fornecer acesso para várias classes de usuários, sem comprometer a segurança do conteúdo existente nos diferentes aplicativos de colaboração. Os usuários de diferentes zonas da rede (interna e externa) e com diferentes provedores de autenticação podem participar da colaboração. Além disso, os usuários só podem acessar o conteúdo destinado a eles. Seguindo um design de arquitetura lógica semelhante, você cria a oportunidade para fornecer acesso a usuários de vários locais e com diferentes objetivos. Por exemplo, o design inicial pode ser destinado somente ao acesso de funcionários internos. No entanto, usando um design semelhante, você pode permitir o acesso de funcionários remotos, funcionários de parceiros e até mesmo de clientes.
Verifique se o design pode ser utilizado em um ambiente de extranet. Você pode tomar decisões deliberadas de design para garantir que os farms de servidores sejam implantados com segurança em uma rede de perímetro ou em qualquer uma das topologias abordadas em Design extranet farm topology (Windows SharePoint Services).
O restante deste artigo aborda cada um dos componentes lógicos que aparecem no modelo (de cima para baixo) e discute as opções de design aplicadas ao modelo. O objetivo dessa abordagem é demonstrar as diferentes maneiras de configurar os componentes de arquitetura lógica com base no aplicativo.
Farms de servidores
O modelo ilustra um farm de cinco servidores. Entretanto, o modelo pode ser implementado em farms de qualquer tamanho, incluindo o farm de servidor único. O farm de servidores do modelo é composto por cinco servidores com a seguinte topologia:
Dois servidores Web front-end
Um servidor de aplicativos para cada servidor
Dois servidores de banco de dados, agrupados ou espelhados
O modelo ilustra a arquitetura lógica do Windows SharePoint Services 3.0, mostrando que:
Todos os sites são espelhados nos servidores Web front-end.
O site Administração Central é instalado em um servidor de aplicativos para protegê-lo contra o acesso direto de usuários.
Na realidade, 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 o necessário. A arquitetura lógica pode ser criada independentemente da topologia do farm de servidores. O processo de planejamento de desempenho e capacidade ajuda você a dimensionar o farm de servidores para atender aos objetivos de desempenho e capacidade. Para obter mais informações, consulte Plan for performance and capacity (Windows SharePoint Services).
Usuários, zonas e autenticação
O modelo ilustra cinco classes diferentes de usuários, cada uma atribuída a uma zona diferente. Em cada aplicativo Web é possível criar até cinco zonas, usando um dos nomes de zona disponíveis: Padrão, Intranet, Internet, Personalizada ou Extranet. Um farm que hospede mais de um aplicativo Web pode dar suporte às solicitações de usuários em mais de cinco zonas da rede (até cinco zonas por aplicativo Web). No entanto, o modelo mostra somente cinco zonas.
Usuários e autenticação
O modelo demonstra como a autenticação é aplicada aos usuários nas diferentes zonas da rede. A tabela a seguir também demonstra a autenticação aplicada a cada tipo de usuário e zona.
| Zona | Usuários | Autenticação |
|---|---|---|
Intranet |
Funcionários internos |
NTLM (Autenticação Integrada do Windows) |
Padrão |
Funcionários remotos |
NTLM (Integrada do Windows) ou autenticação de formulários com o protocolo LDAP. |
Extranet |
Funcionários de parceiros |
Autenticação de formulários |
Funcionários internos
A zona Intranet é usada para acesso de funcionários internos. A Autenticação Integrada do Windows é usada.
Funcionários remotos
A zona Padrão é usada para acesso de funcionários remotos. As metas de design da zona Padrão são:
Autenticar em relação ao ambiente interno do serviço de diretório do Active Directory.
Simplificar o gerenciamento de permissões, usando a autenticação do Windows tanto para funcionários internos quanto remotos. Essa meta é importante porque, se os usuários se conectarem a sites por meio de dois provedores de autenticação diferentes, o Windows SharePoint Services 3.0 criará duas contas diferentes para cada usuário, e cada uma das duas contas deverá ter permissões.
O modelo apresenta duas opções diferentes para autenticar funcionários remotos. Com a primeira opção (autenticação Integrada do Windows com NTLM), as duas metas de design são atingidas. A segunda opção (autenticação de formulários com LDAP) satisfaz a primeira meta, mas não a segunda. Consequentemente, a primeira opção é o método preferido para usuários remotos.
A tabela a seguir resume as diferenças entre essas duas opções de autenticação.
| Tipo de comparação | Autenticação integrada do Windows, usando NTLM | Autenticação de formulários, usando um provedor LDAP |
|---|---|---|
Funcionalidade |
Esse método se baseia na utilização do Internet Security and Acceleration (ISA) Server 2006 ou do Intelligent Application Gateway (IAG 2007) para autenticar usuários e, então, enviar as credenciais de usuário para o Windows SharePoint Services 3.0. Esses servidores usam autenticação de formulários para autenticar usuários em relação ao ambiente do Active Directory. Em seguida, encaminham as credenciais do Windows para o Windows SharePoint Services 3.0. Para obter mais informações, consulte estes recursos:
Como a zona é padrão, a autenticação NTLM é utilizada para satisfazer uma exigência do componente de índice. Para obter mais informações, consulte a seção "Requisitos de configuração da zona padrão", posteriormente neste artigo. |
O Windows SharePoint Services 3.0 usa autenticação de formulários com um provedor LDAP para autenticar funcionários remotos no ambiente interno do Active Directory. |
Vantagens |
O Windows SharePoint Services 3.0 não cria duas contas diferentes para usuários que trabalham interna e remotamente. Isso simplifica bastante o gerenciamento de permissões. |
Não requer um servidor proxy para autenticar usuários e encaminhar credenciais. |
Desvantagens |
Requer coordenação adicional do ISA Server 2006, bem como sua configuração, ou outro produto de servidor proxy. |
Se os usuários se conectarem ao Windows SharePoint Services 3.0 interna e remotamente, duas contas de usuário diferentes serão criadas no Windows SharePoint Services 3.0. Consequentemente, as duas contas exigem permissões para sites e documentos. Os funcionários precisarão gerenciar as permissões de seus próprios sites e documentos para as duas contas de usuário se planejarem trabalhar interna e remotamente na rede. |
Funcionários de parceiros
Os funcionários de parceiros acessam a rede por meio da zona Extranet e são autenticados com o uso da autenticação de formulários. Isso exige um diretório e provedor separados, como o banco de dados e o provedor do Microsoft SQL Server, para armazenar contas de parceiros na extranet. Vantagens dessa abordagem: você pode gerenciar contas de parceiro separadamente e não é necessário adicionar contas de parceiro ao diretório de funcionários internos.
Como alternativa, você pode usar o SSO (logon único) da Web para autenticar em relação ao diretório próprio de um parceiro. No entanto, essa abordagem exige uma zona separada para cada diretório de parceiro.
Como o modelo considera que a Fabrikam está trabalhando com parceiros de várias empresas diferentes no mesmo aplicativo de parceiro, a autenticação de formulários é utilizada. O diretório e o provedor não são especificados.
Zonas
Quando você cria zonas, várias decisões importantes são cruciais para o sucesso da implantação. Essas decisões incluem decisões de criação e configuração das seguintes zonas:
A zona Padrão
Zonas para acesso externo
As seções a seguir descrevem as decisões incorporadas ao modelo.
Requisitos de configuração da zona Padrão
A zona que envolve a maior consideração é a zona Padrão. O Windows SharePoint Services 3.0 estabelece os seguintes requisitos para a maneira como a zona Padrão é configurada:
Quando uma solicitação de usuário não puder ser associada a uma zona, a autenticação e as diretivas da zona Padrão serão aplicadas. Portanto, a zona Padrão deve ser a mais segura.
O componente de índice exige acesso ao conteúdo de pelo menos uma zona para rastrear conteúdo. O componente de índice usa autenticação NTLM. Por isso, para rastrear conteúdo, pelo menos uma das zonas deve ser configurada para usar autenticação NTLM. Além disso, o rastreador sondará as zonas na seguinte ordem, até encontrar uma zona que possa ser autenticada: zona Padrão, zona Intranet, zona Internet, zona Personalizada e zona Extranet. Contudo, se o rastreador encontrar primeiro uma zona configurada para usar autenticação Kerberos, básica ou de resumo, o rastreador não autenticará nem tentará acessar a zona seguinte. Assim, verifique se a configuração das zonas não impede o componente de índice de rastrear conteúdo. Para obter mais informações sobre os requisitos de autenticação relacionados ao rastreamento de conteúdo, consulte Plan authentication methods.
Um email administrativo é enviado com links da zona Padrão. Inclui mensagens de email para proprietários de sites que estejam prestes a atingir os limites de cota. Consequentemente, os usuários que receberem esse tipo de email devem poder acessar links por meio da zona Padrão. Isso é importante principalmente para os proprietários de site.
Os conjuntos de sites nomeados pelo host só estão disponíveis por meio da zona Padrão. Todos os usuários que precisarem acessar conjuntos de sites nomeados pelo host deverão ter via zona Padrão.
No modelo, a zona Padrão é usada para o acesso de funcionários remotos pelos seguintes motivos:
Os funcionários podem acessar links no email administrativo, independentemente de acessarem os sites interna ou remotamente.
Nomes de servidor e URLs internos são protegidos contra exposição quando a zona associada a uma solicitação de usuário não pode ser determinada. Como a zona Padrão já está configurada para funcionários remotos, as URLs não expõem dados confidenciais quando essa zona é aplicada.
Configurando zonas para ambientes de extranet
Em um ambiente de extranet, o design das zonas é crítico pelos seguintes motivos:
As solicitações de usuário podem ser iniciadas em várias redes diferentes. No modelo, os usuários iniciam as solicitações na rede interna, na Internet e em empresas parceiras.
Os usuários podem participar da colaboração em vários aplicativos Web. Por exemplo, funcionários internos e remotos podem contribuir e administrar conteúdo em todos os aplicativos Web: sites de equipe, sites pessoais e Partner Web.
Em um ambiente de extranet, verifique se os seguintes princípios são cumpridos:
Configurar zonas entre vários aplicativos Web para espelhar umas às outras. A configuração de autenticação e os usuários pretendidos devem ser os mesmos. No entanto, as diretivas associadas às zonas podem ser diferentes nos aplicativos Web. Por exemplo, verifique se a zona Intranet é usada para os mesmos funcionários em todos os aplicativos Web. Em outras palavras, não configure a zona Intranet para funcionários internos em um aplicativo Web e para funcionários remotos em outro.
Configurar corretamente, e com precisão, os mapeamentos alternativos de acesso para cada zona e recurso.
No modelo, a zona Padrão de cada aplicativo Web está configurada de forma idêntica para acesso de funcionários remotos. Além disso, a zona Intranet está configurada de forma idêntica em todos os aplicativos Web para acesso de funcionários internos. A zona de Extranet está configurada para apenas um aplicativo Web.
Os mapeamentos alternativos de acesso são automaticamente criados quando você cria a zona. Entretanto, se usar um produto de servidor proxy ou de gateway para disponibilizar sites na Internet, você precisará adicionar uma entrada de mapeamento alternativo de acesso para cada zona. Isso garante que as URLs retornadas aos usuários externos à rede interna sejam disponibilizadas para os usuários de acordo com o contexto da zona deles. Para obter mais informações, consulte Plan alternate access mappings.
Se as zonas nos aplicativos Web não espelharem umas às outras e os links para recursos externos não forem adequados, os riscos incluem:
Os nomes de servidor, os nomes DNS (sistema de nomes de domínio) e os endereços IP podem ser potencialmente expostos fora da rede interna.
Os usuários talvez não possam acessar sites e outros recursos.
Sites de administração
No modelo, o site da Administração Central fica hospedado no servidor de pesquisa. Isso protege o site contra contato direto do usuário. Se um afunilamento de desempenho ou um comprometimento de segurança afetar a disponibilidade dos servidores Web front-end, o site da Administração Central permanecerá disponível. Além disso, o site da Administração Central é hospedado dentro de um pool de aplicativos dedicado e no aplicativo Web.
As URLs com balanceamento de carga dos sites de administração não são articuladas no modelo ou neste artigo. As recomendações incluem:
Se forem usados números de porta em URLs administrativas, use portas não padrão. Números de porta são incluídos nas URLs por padrão. Embora esses números geralmente não sejam usados em URLs voltadas para o cliente, o uso deles em sites de administração pode aumentar a segurança, limitando o acesso a esses sites às portas não padrão.
Criar entradas de DNS separadas para sites de administração.
Pools de aplicativos
Os pools de aplicativos separados dos Serviços de Informações da Internet (IIS) geralmente são implementados para obter o isolamento de processos entre os sites. Os pools de aplicativos fornecem uma maneira de executar vários sites no mesmo computador servidor, porém, mantendo seus próprios processos de trabalho e sua própria identidade. Isso reduz os possíveis problemas de segurança em um site que permita que um invasor injete código no servidor para atacar outros sites.
Na prática, considere a possibilidade de usar um pool de aplicativos dedicado em cada um dos seguintes cenários:
Separar conteúdo autenticado do conteúdo anônimo.
Isolar sites destinados principalmente à colaboração com parceiros ou clientes externos. Isso isola contas externas para sites em um único pool de aplicativos.
Isolar sites onde os usuários tenham mais liberdade de criar e administrar sites para colaborar no conteúdo.
O modelo usa pools de aplicativos da seguinte forma:
O site de administração é hospedado em um pool de aplicativos dedicado. Esse é um requisito do Windows SharePoint Services 3.0.
Os sites de colaboração interna (sites de equipe e sites pessoais) são hospedados em um único pool de aplicativos.
O aplicativo Partner Web é hospedado em um pool de aplicativos dedicado.
Aplicativos Web
O aplicativo Web é um site do IIS criado e utilizado pelos Produtos e Tecnologias do SharePoint. Cada aplicativo Web é representado por um site diferente no IIS. Você atribui a cada aplicativo Web um único nome de domínio, o que ajuda a evitar ataques de script entre sites.
Em termos gerais, use os aplicativos Web para:
Separar conteúdo anônimo de conteúdo autenticado.
Isolar usuários. No modelo, o Partner Web é hospedado em um aplicativo Web e em um pool de aplicativos dedicado 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 Diretiva de Aplicativo Web, na Administração Central. Por exemplo, é possível criar uma diretiva nos sites de colaboração interna para explicitamente negar acesso a contas de parceiros. As diretivas de um aplicativo Web são impostas independentemente das permissões configuradas em cada site ou documento incluído no aplicativo Web.
Otimizar desempenho. Os sites conseguirão ter um desempenho melhor se forem colocados em aplicativos Web com outros aplicativos que tenham características de dados semelhantes. Por exemplo, as características de dados de sites pessoais incluem um grande número de sites de tamanho pequeno. Por outro lado, os sites de equipe geralmente abrangem um número menor de sites muito grandes. Colocando esses dois tipos de sites diferentes em aplicativos Web separados, os bancos de dados resultantes serão compostos de dados com características semelhantes, o que otimiza o desempenho do banco de dados. No 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. Apesar disso, os sites de equipe e os sites pessoais são colocados em aplicativos Web separados para otimizar o desempenho.
Otimizar o gerenciamento. Como a criação de aplicativos Web separados resulta em sites e bancos de dados separados, você pode implementar diferentes limites de site (lixeira, validade e tamanho) e negociar diferentes acordos no nível de serviço. Por exemplo, é possível permitir mais tempo para a restauração de conteúdo de sites pessoais se esse não for o tipo de conteúdo mais crítico da sua organização. Isso permite que você restaure o conteúdo mais crítico antes de restaurar o conteúdo desses sites. No modelo, os sites pessoais são colocados em um aplicativo Web separado para permitir que os administradores gerenciem mais rigorosamente o crescimento, em comparação com outros aplicativos.
Conjuntos de sites
Os conjuntos de sites ligam a arquitetura lógica e a arquitetura de informação. As metas de projeto dos conjuntos de sites no modelo são: satisfazer os requisitos de design de URL e criar divisões lógicas de conteúdo.
Para satisfazer os requisitos de design de URL, cada aplicativo Web inclui um único conjunto de sites no nível raiz. Os caminhos gerenciados são usados para incorporar uma segunda camada de conjuntos de sites de nível superior. Para obter mais informações sobre os requisitos de URL e sobre como usar 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.
.jpg "Arquitetura lógica para sites de colaboração")
Devido ao requisito de um conjunto de sites no nível raiz, as decisões de design giram em torno da 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 na URL de 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 abaixo do caminho gerenciado são conjuntos de sites independentes, que herdam o modelo de site utilizado para criar o site de nível superior. Esta figura ilustra os sites pessoais.
Para obter mais informações sobre sites pessoais, consulte Plan process for creating sites (Windows SharePoint Services).
Sites de equipe
Durante a criação de conjuntos de sites em um aplicativo de site de equipe, a recomendação é criar um número finito de conjuntos de sites para a sua organização, baseando-se na maneira como a sua organização funciona. Nessa abordagem, os conjuntos de sites são criados por um administrador do Windows SharePoint Services 3.0. Após a criação do conjunto de sites, as equipes podem criar sites no conjunto de sites, baseando-se em suas necessidades.
Essa abordagem fornece a oportunidade de implementar uma taxonomia significativa que, por sua vez, ofereça a estrutura de gerenciamento e crescimento dos sites de equipe. Há também mais oportunidades de compartilhar modelos e navegação entre projetos e equipes que compartilhem um conjunto de sites. O desafio dos arquitetos da informação é criar uma segunda camada de conjuntos de sites que faça sentido para a organização. A tabela a seguir lista sugestões para os diferentes tipos de organização.
| Tipo de organização | Sugestões de taxonomias para conjuntos de sites |
|---|---|
Desenvolvimento de produto |
|
Pesquisa |
|
Instituição de educação superior |
|
Agência de legislação estadual |
|
Escritório jurídico corporativo |
|
Fabricação |
|
Partner Web
O Partner Web destina-se ao uso na colaboração com parceiros externos, em projetos com escopos ou durações finitos. Pelo design, os sites existentes no aplicativo Partner Web não devem ser relacionados. Os requisitos do Partner Web incluem a garantia de que:
Os proprietários de projeto possam criar sites com facilidade para colaboração com parceiros.
Os parceiros e outros colaboradores tenham acesso somente ao projeto em que estejam trabalhando.
As permissões sejam gerenciadas pelos proprietários dos sites.
Os resultados de pesquisa oriundos de um projeto não exponham conteúdo de outros projetos.
Os administradores possam identificar facilmente os sites que não são mais usados e excluí-los.
Para atender a esses requisitos, o modelo incorpora um conjunto de sites para cada projeto, o que fornece estes benefícios:
Os conjuntos de sites individuais fornecem o nível adequado de isolamento entre projetos.
A criação de site pessoal pode ser implementada.
Bancos de dados de conteúdo
Você pode usar estas duas abordagens para incorporar bancos de dados de conteúdo ao design (o modelo incorpora as duas abordagens):
Estabelecer os tamanhos pretendidos para os bancos de dados de conteúdo, com limites de aviso de tamanho adequados. Criar um novo banco de dados quando esses limites forem atingidos. Com essa abordagem, os conjuntos de sites são adicionados automaticamente a um ou mais bancos de dados disponíveis, com base apenas nos tamanhos pretendidos.
Associar conjuntos de sites a bancos de dados de conteúdo específico. Essa abordagem permite colocar um ou mais conjuntos de sites em um banco de dados dedicado que possa ser gerenciado independentemente do restante.
Ao optar pela associação de conjuntos de sites a bancos de dados de conteúdo específico, você poderá usar os seguintes métodos:
Use a ferramenta de linha de comando Stsadm para criar um conjunto de sites em um banco de dados específico.
Designar 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 que um evento de aviso seja 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 as seguintes etapas:
No aplicativo Web, crie o banco de dados e defina o 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, novos conjuntos de sites não poderá ser criados. Entretanto, aqueles já existentes em bancos de dados offline continuarão acessíveis para operações de leitura e gravação.
Crie os conjuntos de sites. Eles são adicionados automaticamente ao banco de dados.
Defina o status de todos os outros bancos de dados como Pronto.
Sites de equipe
O modelo incorpora um banco de dados dedicado para cada um dos conjuntos de sites de equipe. Essa abordagem permite gerenciar o banco de dados de cada equipe independentemente para backup, restauração e migração. Além disso, quando um projeto for concluído, você poderá arquivar facilmente o banco de dados associado ao projeto.
Sites pessoais
Para sites pessoais, o modelo obtém eficiência de escala, gerenciando bancos de dados até o tamanho máximo pretendido. As seguintes configurações são definidas para atingir esse objetivo:
Limitar o armazenamento do site a no máximo Essa configuração, que você define na página Modelos de Cota, na Administração Central, limita o tamanho de um site pessoal.
Lixeira de Segundo Estágio Essa configuração, que você define na página Configurações Gerais, no Aplicativo Web, determina a quantidade de espaço adicional que é alocado 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 para os sites, usando os números que você especificou para os dois valores anteriores. Em seguida, com base no tamanho pretendido para cada banco de dados, determine quantos sites caberão no banco de dados.
O modelo fornece as seguintes configurações de tamanho de exemplo, com base no tamanho pretendido de 100 gigabytes (GB) para o banco de dados e um tamanho pretendido de 500 megabytes (MB) para o site pessoal:
Limites de tamanho por site = 500 MB
Tamanho pretendido para o banco de dados = 100 GB
Número máximo de sites = 200
Aviso de nível de site = 175
Quando o aviso de nível de site for atingido, crie um novo banco de dados. Depois criado o novo banco de dados, novos sites pessoais serão adicionados alternadamente ao novo banco de dados e ao banco de dados existente, até que o número máximo de sites de um dos bancos de dados seja atingido.
Partner Web
De modo similar aos sites pessoais, o Partner Web obtém eficiência de escala ao gerenciar bancos de dados até o tamanho máximo pretendido.
Como o Partner Web fica hospedado em um aplicativo Web dedicado, você pode criar limites de tamanho que sejam mais adequados aos tipos de tamanhos criados. O modelo fornece as seguintes configurações de tamanho de exemplo:
Tamanho pretendido para o banco de dados = 100 GB
Cota de armazenamento por site = 5 GB
Número máximo de sites = 20
Zonas e URLs
O modelo ilustra como coordenar URLs em vários aplicativos de uma implantação corporativa.
Metas de design
As seguintes metas influenciam as decisões de design de URLs:
As convenções de URL não limitam as zonas por meio das quais o conteúdo pode ser acessado.
As portas HTTP e HTTPS padrão (80 e 443) podem ser usadas em todos os aplicativos do modelo.
Os números de porta não são incluídos nas URLs. Na prática, os números de porta geralmente não são usados em ambientes de produção.
Princípios de design
Para atingir as metas de design, os seguintes princípios de design são aplicados:
Conjuntos de nomeados por host não são usados. Observe que esses conjuntos de sites são diferentes nos cabeçalhos de host do IIS. Os conjuntos de sites nomeados por host não funcionam com o recurso de mapeamento alternativo de acesso. Esse recurso é necessário para acessar o mesmo conteúdo por meio de várias URLs de domínio. Consequentemente, quando são utilizados os sites nomeados por host, eles só estão disponíveis por meio da zona Padrão. O recurso de mapeamento alternativo de acesso também dá suporte para terminação externa do protocolo SSL, permitindo que os cenários de acesso de funcionários remotos e acesso de parceiros utilizem SSL (HTTPS). Para obter mais informações sobre como usar conjuntos de sites nomeados por host, consulte White paper: Create shared hosting solutions on Windows SharePoint Services.
Cada aplicativo incorpora um único conjunto de sites raiz. Esse é um requisito para usar mapeamentos alternativos de acesso. Se forem necessários vários conjuntos de sites raiz em um aplicativo Web e se você tiver a intenção de usar somente a zona Padrão para acesso de usuário, os conjuntos de sites nomeados por 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. Esses caminhos proporcionam um controle maior sobre as URLs desses tipos de sites.
Compensações do design
O cumprimento das metas de design resulta em algumas compensações, inclusive as seguintes:
URLs mais longas.
Conjuntos de sites nomeados por host não são usados.
Criando URLs com balanceamento de carga
Ao criar um aplicativo Web, escolha uma URL com balanceamento de carga para atribuir a ele. Além disso, crie uma URL com balanceamento de carga para cada zona criada no aplicativo Web. A URL com balanceamento de carga inclui protocolo, esquema, nome do host e porta, se usada. Essa URL deve ser exclusiva em todos os aplicativos Web e zonas. Consequentemente, cada aplicativo e cada zona dentro de cada aplicativo exige uma URL exclusiva no modelo.
Sites de colaboração interna
Os dois diferentes tipos de sites de colaboração interna exigem uma URL exclusiva. No modelo, o público-alvo desses sites é composto por funcionários internos e remotos. A tabela a seguir lista as URLs de funcionários internos e remotos para acessar cada aplicativo.
| 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 |
Partner Web
No modelo, o Partner Web é acessado por funcionários internos, remotos e de parceiros. Embora tanto os funcionários remotos quanto os funcionários de parceiros acessem o Partner Web externamente, usando SSL (HTTPS), cada um exige uma URL diferente para aplicar os benefícios da utilização de zonas separadas — isto é, diferentes métodos de autenticação e diretivas de zona. A tabela a seguir lista as URLs usadas por funcionários internos, remotos e de parceiros para acessar o Partner Web.
| 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 caractere curinga para caminhos de URL
Ao definir caminhos gerenciados, você pode especificar quais caminhos no namespace de URL de um aplicativo Web serão utilizados para conjuntos de sites. É possível especificar a existência de um ou mais conjuntos de sites em um caminho distinto abaixo do site raiz. Sem os caminhos gerenciados, todos os sites criados abaixo do site raiz farão parte do conjunto de sites raiz.
Você pode criar estes dois tipos de caminhos gerenciados:
Inclusão explícita Um conjunto de sites com a URL explícita que você atribuir. A inclusão explícita é aplicada a apenas um conjunto de sites. Você pode criar muitas inclusões explícitas abaixo de um conjunto de sites raiz. Exemplo de URL para um conjunto de sites criado com esse método: http://team/Team1.
Inclusão de caractere curinga Um caminho adicionado à URL. Ele indica que todos os sites especificados imediatamente após o nome do caminho são conjuntos de sites exclusivos. Essa opção geralmente é usada para aplicativos que aceitam a criação de site pessoal. Exemplo de URL para um conjunto de sites criado com esse método: http://sites/site1.
O modelo incorpora o uso dos dois tipos, conforme descrito nas próximas seções.
Inclusões explícitas: sites de equipe
No modelo, os dois aplicativos de site de equipe incorporam o uso de inclusões explícitas.
Sites de equipe
No aplicativo de sites de equipe, uma inclusão explícita é usada para cada conjunto de sites de equipe. O limite de escala em conjuntos de sites criados com uma inclusão explícita é de 100 sites. As boas práticas de gerenciamento recomendam que você mantenha o número de sites de equipe de nível superior dentro de um limite gerenciável. Além disso, a taxonomia dos sites de equipe deve ser lógica para o modo de operação da sua empresa. Muitas organizações se adaptam bem à recomendação de 100 sites. Caso a sua empresa precise de uma escala maior para sites de equipe, use uma inclusão de caractere curinga.
No modelo, o uso de inclusões explícitas resulta nas URLs da tabela a seguir.
| Funcionário interno (zona Intranet) | Funcionário remoto (zona Padrão) |
|---|---|
http://team/Team1 |
https://team.fabrikam.com/Team1 |
http://team/Team2 |
https://team.fabrikam.com/Team2 |
http://team/Team3 |
https://team.fabrikam.com/Team3 |
Nesse exemplo, o conjunto de sites raiz, http://team, não hospeda necessariamente o conteúdo dos usuários.
Inclusões de curinga: Partner Web e sites pessoais
O Partner Web e os sites pessoais incorporam o uso de uma inclusão de curinga. Essas inclusões são ideais para aplicativos que permitem aos usuários criar seus próprios conjuntos de sites. Uma inclusão de curinga indica que o item após o curinga é um site raiz de um conjunto de sites.
Sites pessoais
No modelo, os sites pessoais contêm uma inclusão curinga chamada /sites (http://selfservice/sites).
Isso resulta em URLs no formato listado na tabela a seguir.
| Interno (zona Intranet) | Funcionário remoto (zona Padrão) |
|---|---|
http://selfservice/sites/site1 |
https://selfservice.fabrikam.com/sites/site1 |
http://selfservices/sites/site2 |
https://selfservice.fabrikam.com/sites/site2 |
http://selfservice/sites/user3 |
https://selfservices.fabrikam.com/personal/user3 |
Partner Web
O Partner Web foi projetado para permitir que os funcionários criem facilmente sites seguros para colaboração com parceiros externos. Para dar suporte a essa meta, a criação de site pessoal é permitida.
No modelo, o Partner Web adiciona uma inclusão de curinga chamada /sites (http://partnerweb/sites). Isso resulta em URLs no formato listado na tabela a seguir.
| Funcionário interno (zona 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 colaboradores parceiros podem acessar os sites do Partner Web com as URLs listadas na tabela a seguir.
| Parceiro (zona Extranet) |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb/fabrikam.com/sites/project3 |
Diretivas de zona
Você pode criar uma diretiva para um aplicativo Web para impor permissões no nível do aplicativo Web. Uma diretiva pode ser definida para o aplicativo Web em geral ou apenas para uma zona específica. A diretiva impõe permissões em todo o conteúdo do aplicativo Web ou da zona. As permissões de diretiva substituem todas as outras configurações de segurança definidas para sites e conteúdo. É possível configurar a diretiva com base em usuários ou em grupos de usuários, mas não em grupos do SharePoint.
O modelo fornece um exemplo: negação de acesso de contas de parceiros a sites de colaboração interna.
Fazendo backup e restaurando sites de colaboração
Há várias opções de backup e restauração de conteúdo que são adequadas aos sites de colaboração:
Ferramentas internas de backup e recuperação — Use as ferramentas que vêm com o Windows SharePoint Services 3.0 se os bancos de dados tiverem 100 GB e não incluírem muita personalização ou se as personalizações constituírem um pacote como solução.
Ferramentas de backup e recuperação do Microsoft SQL Server 2005 — Use essas ferramentas se tiver um administrador de banco de dados SQL.
Para obter mais informações, consulte Choose backup and recovery tools (Windows SharePoint Services).
Projetando colaboração externa segura
O cartaz de exemplo de design inclui uma visão geral de como planejar a colaboração externa segura. Esta seção inclui o texto de introdução de cada item e links para os respectivos artigos na biblioteca TechNet.
| Recomendação de design | Diretriz |
|---|---|
Escolher uma topologia de extranet |
Proteja seu farm de servidores, usando um firewall de borda em uma rede de perímetro. Para obter mais informações, consulte estes artigos na TechNet:
|
Comunicação cliente-servidor segura |
A colaboração segura em um ambiente de extranet se baseia na comunicação segura entre computadores clientes e o ambiente de farm de servidores. Quando apropriado, use o protocolo SSL para garantir a segurança da comunicação entre computadores clientes e servidores. Para obter mais informações, consulte estes artigos na TechNet: |
Proteção de servidores back-end e do site Administração Central |
A colaboração externa segura exige servidores de Internet. É possível limitar a exposição ao tráfego da Internet, colocando um firewall entre os servidores Web e os demais servidores e hospedando o site Administração Central em um servidor back-end. Para obter mais informações, consulte estes artigos na TechNet:
|
Configurar mapeamentos alternativos de acesso |
Os mapeamentos alternativos de acesso oferecem suporte aos cenários de desenvolvimento de Internet nos quais a URL de uma solicitação Web recebida pelos Serviços de Informações da Internet (IIS) não é a mesma URL digitada por um usuário. Há maior probabilidade de que isso ocorra em cenários de implantação que incluam publicação de proxy reverso e balanceamento de carga. Por exemplo, servidores proxy reversos podem executar funcionalidade avançada, como recebimento de uma solicitação Web via Internet, e, para isso, usam o protocolo SSL (HTTPS), mas, para encaminhar a solicitação para o servidor, usam HTTP. Esse processo é denominado "terminação externa de SSL". Para obter mais informações, consulte Plan alternate access mappings. |
Baixar este manual
Este tópico está incluído no seguinte manual baixável para facilitar a leitura e a impressão:
Consulte a lista completa de manuais disponíveis na página de download de manuais do Windows SharePoint Services (em inglês).