Componentes de arquitetura lógica (SharePoint Server 2010)
Aplica-se a: SharePoint Foundation 2010, SharePoint Server 2010
Tópico modificado em: 2016-11-30
Existe uma variedade de formas de organizar os componentes em um design de arquitetura lógica. Cada um dos componentes apresenta diferentes oportunidades de compartilhamento e de isolamento. Antes de começar o seu design de arquitetura lógica:
Saiba quais são os seus objetivos de compartilhamento e de isolamento.
Avalie as condições de cada opção.
Cada seção deste artigo descreve um componente de arquitetura lógica em particular e discute as considerações a seguir para esse componente: capacidade, compartilhamento e isolamento, itens configuráveis, administração e recomendações de planejamento.
Neste artigo:
Farms de servidores
Aplicativos de serviço
Pools de aplicativos
Aplicativos Web
Zonas
Política para aplicativos Web
Bancos de dados de conteúdo
Conjuntos de sites
Sites
Conjuntos de sites com nome de host
Meus Sites
Farms de servidores
Um farm de servidores representa o elemento de nível superior de um design. Farms de servidores individuais oferecem isolamento físico.
Diversos critérios determinados por sua organização poderão afetar o número de farms de servidores necessários, incluindo:
O uso intenso dos serviços pode exigir um ou mais farms de serviços dedicados.
Divisões operacionais de responsabilidade separadas.
Fontes de fundos dedicadas.
Locais de datacenter separados.
Requisitos de mercado para isolamento físico entre sites.
No entanto, você pode cumprir muitos requisitos de isolamento em um único farm de servidores. Por exemplo, é possível usar diferentes pools de aplicativos do IIS (Serviços de Informações da Internet) com diferentes identidades de processo para obter isolamento no nível do processo para aplicativos de sites e de serviço.
Além dos requisitos de isolamento que podem exigir mais de um farm de servidores, uma organização pode implementar vários farms de servidores para atender aos objetivos de desempenho e de escala, aos requisitos de licenciamento ou a um ambiente de publicação.
Aplicativos de serviço
Um aplicativo de serviço fornece um recurso que pode ser compartilhado por sites em um farm ou, em alguns casos, em vários farms.
No SharePoint Server 2010, os serviços não estão mais contidos em um SSP (Provedor de Serviços Compartilhados). Em vez disso, a infraestrutura de hospedagem de serviços foi movida para o Microsoft SharePoint Foundation 2010 e as configurações de oferta de serviço estão mais flexíveis. Serviços individuais podem ser configurados independentemente e terceiros podem adicionar serviços à plataforma.
Você só pode implantar os serviços necessários para um farm. Serviços implantados são chamados de aplicativos de serviço.
Aplicativos de serviço são associados a aplicativos Web. Cada aplicativo pode ser configurado de maneira diferente:
Aplicativos Web podem ser configurados para usar somente os serviços necessários, em vez de todos os serviços implantados.
Você pode implantar várias instâncias do mesmo serviço em um farm e atribuir nomes exclusivos aos aplicativos de serviço resultantes.
Você pode compartilhar aplicativos de serviço entre vários aplicativos Web dentro do mesmo farm.
Alguns aplicativos de serviço podem ser compartilhados entre farms.
Capacidade
Não há limite recomendado para o número de aplicativos de serviço em um único farm.
Compartilhamento e isolamento
Aplicativos de serviço podem ser compartilhados de duas maneiras:
Compartilhando o mesmo aplicativo de serviço e os mesmos dados. Esse é o comportamento padrão para serviços compartilhados entre aplicativos Web. Por exemplo, resultados de pesquisas são compartilhados entre aplicativos Web que consomem o mesmo aplicativo de pesquisa.
Compartilhando somente o aplicativo de serviço, mas isolando os dados através da implantação do serviço no modo particionado. Em um ambiente hospedado, você pode implantar aplicativos de serviço no modo particionado usando o Windows PowerShell. Os dados de cada locatário são armazenados em uma partição separada no banco de dados do serviço. A ID de inscrição de um locatário é usada para mapear os dados de serviço do locatário para seus sites. Por exemplo, se você implantar o serviço de pesquisa no modo particionado, cada locatário exibirá somente resultados de pesquisa do seu próprio conteúdo.
Observação
Nem todos os aplicativos de serviço dão suporte ao particionamento.
Inversamente, aplicativos de serviço podem ser isolados de duas maneiras:
Implantando vários aplicativos de serviço em pools de aplicativos separados para obter o isolamento de serviços e dados de serviço. Por exemplo, uma equipe do departamento financeiro pode exigir um aplicativo do Serviço Corporativo de Conectividade de Dados separado e dedicado.
Implantando serviços no modo particionado. Essa abordagem funciona bem em ambientes hospedados nos quais os locatários nunca compartilharão dados de serviço. No entanto, pode não ser prático em ambientes nos quais haja uma combinação de necessidades por dados de serviço compartilhados e isolados.
Se necessário, você pode isolar aplicativos de serviço adicionalmente implantando-os em pools de aplicativos separados para obter o isolamento de processos. No entanto, pools de aplicativos são um recurso limitado e se forem usados muitos deles, o desempenho do farm será afetado. Para obter mais informações, consulte Application pools neste artigo.
Itens configuráveis
A tabela a seguir exibe os itens configuráveis que contribuem para o isolamento e o compartilhamento.
Item |
Descrição |
Grupo padrão |
Por padrão, todos os aplicativos de serviço são incluídos no grupo padrão. É possível adicionar e remover aplicativos de serviço do grupo padrão a qualquer momento, inclusive durante a criação de um. Durante a criação de um aplicativo Web, você pode selecionar o grupo padrão ou criar um grupo de serviços personalizado. Você cria um grupo de serviços personalizado selecionando somente os aplicativos de serviço que deseja que o aplicativo Web use. |
Conexão (proxy) |
Ao criar um aplicativo de serviço, é simultaneamente criada uma conexão para ele. Uma conexão é uma entidade virtual que conecta aplicativos Web a aplicativos de serviço. Alguns aplicativos de serviço, como o Serviço de Metadados Gerenciados, armazenam configurações nas conexões. No Windows PowerShell, as conexões são chamadas de proxies. |
Permissões do aplicativo de serviço |
Você pode delegar o gerenciamento de aplicativos de serviço a outros usuários, concedendo a eles permissões a um ou mais aplicativos de serviço. |
Locais de host confiáveis de Meu Site |
Em organizações nas quais vários aplicativos de Serviço de Perfil de Usuário são implantados, esse recurso garante que os usuários criem um Meu Site no local destinado ao seu perfil. Esse recurso impede que os usuários criem vários Meus Sites em uma organização. |
Administração
A configuração e o gerenciamento de aplicativos de serviço podem ser delegados a administradores especializados no gerenciamento de serviços individuais, como pesquisa, perfis de usuário e metadados gerenciados.
Em um ambiente hospedado, os locatários podem gerenciar algumas das configurações de serviço para a sua organização.
Recomendações de planejamento
Configure os aplicativos de serviço para compartilhar recursos entre vários aplicativos Web ou para isolar conteúdos.
Por exemplo, vários sites residentes em diferentes aplicativos Web e pools de aplicativos podem ser unificados por meio do compartilhamento de serviços em um grupo de proxies padrão para fornecer taxonomia, tipo de conteúdo e compartilhamento de perfil em uma intranet. Isso permite a personalização e a padronização em toda a empresa por meio de vários sites e aplicativos. Essa opção fornece um exemplo de isolamento do processo de balanceamento (implementando aplicativos e pools de aplicativos Web separados) com a necessidade comercial de compartilhar informações e aproveitar dados de perfil entre os aplicativos.
Você também pode configurar os aplicativos de serviço para aperfeiçoar seus objetivos gerais de isolamento. Por exemplo, usar um conjunto de serviço dedicado para colaboração com parceiros garante que os usuários parceiros não possam acessar informações sigilosas no ambiente da sua intranet. É possível configurar o serviços individuais para isolar ainda mais conteúdos entre conjuntos de sites. Você pode, por exemplo:
Limitar os escopos de pesquisa aos conjuntos de sites individuais.
Configurar o serviço de Perfil de Usuário para exibir somente usuários que sejam parte da mesma unidade organizacional no AD DS (Serviços de Domínio Active Directory).
Use a ferramenta de linha de comando Stsadm para configurar o People Picker para que exiba somente os usuários membros do conjunto de sites.
Ao criar sua estratégia de serviços para uma organização, considere as maneiras como você pode configurar os serviços individuais para aprimorar suas metas gerais de compartilhamento ou isolamento de conteúdo.
Ao criar uma estratégia de serviços para um ambiente de hospedagem, determine que serviços serão disponibilizados e particionados.
Pools de aplicativos
No IIS (Serviços de Informações da Internet) 7.0, um pool de aplicativos é um grupo de uma ou mais URLs atendidas por um processo de trabalho ou conjunto de processos de trabalho.
Ao criar conjuntos de sites e serviços nos Produtos do SharePoint 2010, você seleciona um pool de aplicativos a ser usado ou cria um novo pool de aplicativos. Cada pool de aplicativos tem seu próprio processo de trabalho e pode ter uma identidade separada (conta de segurança), o que impede a interação de dois processos.
Capacidade
A sobrecarga de memória de um pool de aplicativos é de 30 a 50 megabytes (MB) mais qualquer memória para os aplicativos que estejam sendo executados no espaço de processo do pool de aplicativos. Em geral, as diversas exigências de aplicativos rapidamente levam o uso da memória de um pool de aplicativos para 800 MB ou mais. O limite para o número de pools de aplicativos é influenciado pela memória disponível no sistema. Ou seja, o número de pools de aplicativos é ditado por estes dois fatores:
Memória endereçável disponível.
A quantidade de memória consumida por aplicativos executados no pool de aplicativos.
A diretriz geral para desempenho aceitável é usar oito ou menos pools de aplicativos.
Compartilhamento e isolamento
Os pools de aplicativos do IIS oferecem uma forma de vários sites serem executados no mesmo computador servidor e, ainda assim, terem seus próprios processos de trabalho e identidade. Isso pode ajudar a impedir a exploração de um site, que permite que o invasor injete código malicioso para atacar sites em pools de aplicativos diferentes. Além disso, essa estratégia isola o código que introduz problemas de memória ou outros problemas para que o código problemático não afete todos os aplicativos.
Itens configuráveis
É recomendável usar, se necessário, uma identidade de pool de aplicativos separada para cada pool de aplicativos por segurança e motivos de isolamento.
Administração
Se identidades separadas forem usadas para cada pool de aplicativos, cada identidade terá que ser mantida.
Recomendações de planejamento
Na prática, considere o uso de um pool de aplicativos dedicado para cada um dos motivos a seguir:
Separar conteúdo autenticado do conteúdo principalmente anônimo.
Isolar aplicativos que armazenam senhas e interagem com aplicativos de negócios externos, por exemplo, conexões do Conectividade de Dados Corporativos.
Aplicativos Web
Um aplicativo Web é um site do IIS criado e usado pelos Produtos do SharePoint 2010. Um aplicativo Web pode ser estendido até quatro vezes para criar quatro zonas adicionais nos Produtos do SharePoint 2010, resultando em até cinco sites do IIS associados a um único aplicativo Web, cada site do IIS associado a uma zona diferente. Você pode atribuir a cada aplicativo Web um nome de domínio exclusivo. Para obter mais informações, consulte Zones neste artigo.
Compartilhamento e isolamento
Cada aplicativo Web possui um nome de domínio exclusivo, o que ajuda a impedir ataques de script entre sites.
Itens configuráveis
A tabela a seguir exibe os itens configuráveis que contribuem para o isolamento e o compartilhamento.
Item |
Descrição |
Aplicativos de serviço |
Os aplicativos de serviço são associados a aplicativos Web. Ao criar um aplicativo Web, você pode selecionar o grupo de proxies padrão (conjunto de aplicativos de serviço padrão) ou pode especificar um conjunto de aplicativos de serviço personalizado. Todos os sites de um aplicativo Web consomem serviços dos mesmos aplicativos de serviço. Um aplicativo de serviço pode fornecer serviços para mais de um aplicativo Web, compartilhando assim dados de conteúdo e de perfil entre os aplicativos Web. |
Zonas |
Em um aplicativo Web, você pode criar até cinco zonas. Use zonas para impor condições de acesso e de política diferentes para grupos grandes de usuários. |
Política para aplicativos Web |
Crie uma diretiva para reforçar permissões em uma ou mais zonas em um aplicativo Web. Uma diretiva pode ser criada para um usuário ou grupo de usuários específico. Para obter mais informações, consulte Política para um aplicativo Web neste artigo. |
Administração
A administração contínua de aplicativos Web não é significativa.
Recomendações de planejamento
Em termos gerais, use os aplicativos Web para:
Separar conteúdo disponível a usuários anônimos a partir de conteúdo disponível para usuários autenticados.
Isole usuários. Por exemplo, você pode garantir que parceiros não tenham acesso ao conteúdo da intranet colocando sites de parceiros em um aplicativo Web separado.
Impor permissões por meio do uso de diretivas. Por exemplo, você pode criar uma política para negar explicitamente o acesso de gravação a um ou mais grupos de usuários. As políticas para um aplicativo Web são impostas independentemente das permissões configuradas em sites ou documentos individuais do aplicativo Web.
Otimize o desempenho do banco de dados. Os aplicativos obtêm um desempenho melhor se forem colocados em bancos de dados de conteúdo com outros aplicativos de características de dados similares. Por exemplo, as características de dados de Meus Sites normalmente incluem um grande número de sites pequenos. Em contraste, os sites de equipe normalmente englobam um número menor de sites muito grandes. Ao colocar esses dois tipos diferentes de sites em aplicativos Web separados, os bancos de dados resultantes serão compostos de dados com características similares, otimizando seu desempenho.
Otimize a capacidade de gerenciamento. Como a criação de aplicativos Web separados resulta em sites e bancos de dados separados, você poderá implementar limites diferentes para a Lixeira, expiração e tamanho de cada site, e negociar contratos de nível de serviço diferentes. Por exemplo, você poderia dar mais tempo para restaurar sites que não sejam fundamentais para seus negócios.
Zonas
As zonas representam caminhos lógicos diferentes (URLs) de obtenção de acesso ao mesmo aplicativo Web. Em cada aplicativo Web, você pode criar até cinco zonas usando um dos nomes de zona disponíveis: Padrão, Intranet, Internet, Personalizado ou Extranet. Cada nome pode ser selecionado apenas uma vez por aplicativo Web. Cada zona é representada por um site diferente no IIS.
A zona Padrão é aquela criada primeiro quando um aplicativo Web é criado. As outras zonas são criadas pela extensão de um aplicativo Web.
Capacidade
Você pode criar até cinco zonas em um aplicativo Web. Normalmente, as zonas são coordenadas entre aplicativos Web para que zonas do mesmo nome sejam configuradas para os mesmos usuários.
Compartilhamento e isolamento
As zonas oferecem um método de particionamento de usuários por:
Tipo de autenticação: cada zona pode ser configurada para usar um provedor de autenticação diferente, permitindo que você compartilhe o mesmo conteúdo entre empresas parceiras.
Zona de rede: cada zona pode ser configurada para acomodar entradas de usuários de uma zona de rede diferente, como uma extranet ou a Internet.
Permissões de política: você pode permitir ou negar explicitamente o acesso de leitura ou gravação a conteúdo por zona com base em uma conta de usuário ou conta de grupo.
Itens configuráveis
A tabela a seguir exibe os itens configuráveis que contribuem para o compartilhamento e o isolamento.
Item |
Descrição |
Provedor de autenticação |
Cada zona pode ser configurada para usar um provedor de autenticação diferente. |
Acesso anônimo |
Ative ou desative o acesso anônimo por zona. |
Secure Sockets Layer (SSL) |
Ative ou desative SSL por zona. |
URL pública e mapeamento de acesso alternativo |
Especifique o nome do domínio que os usuários digitarão para acessar conteúdo no aplicativo Web. Como alternativa, use o mapeamento de acesso alternativo para mapear URLs amigáveis ou apropriadas à zona para a URL padrão (nome e porta do servidor) em cada zona. O mapeamento de acesso alternativo oferece suporte a terminação SSL externa. A terminação SSL externa é quando um servidor proxy termina uma solicitação SSL e a encaminha a um servidor Web usando HTTP. Nesse caso, os mapeamentos de acesso alternativo podem ser configurados para retornarem essas solicitações usando SSL, mantendo a comunicação segura entre o cliente e o servidor proxy. |
Política para aplicativos Web |
Crie um conjunto exclusivo de políticas para cada zona do aplicativo Web. Se você tiver um grupo especial de usuários que exija exceções à sua política geral de segurança, considere o uso de uma zona separada para acomodá-los. |
Administração
Se você usar o mapeamento de acesso alternativo, considere que todas as URLs públicas exigem entradas DNS para o mapeamento de URLs públicas ao endereço IP do balanceador de carga usado para o farm.
Recomendações de planejamento
Quando você cria zonas, várias decisões são críticas 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 algumas das recomendações de planejamento e requisitos para zonas, inclusive a zona padrão.
Email administrativo é enviado com links a partir da zona Padrão. Isso inclui email para proprietários de sites que estejam se aproximando dos limites de cota. consequentemente, os usuários que recebem emails e alertas administrativos devem ser capazes de acessar links por meio da zona Padrão. Isso é especialmente importante para proprietários de site.
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.
A zona Padrão deve ser a zona mais segura. Isso acontece porque quando uma solicitação de usuário não puder se associada à zona, a autenticação e as políticas da zona Padrão serão aplicadas.
Em um ambiente de extranet, o design de zonas é fundamental por dois motivos:
As solicitações de usuário podem ser iniciadas a partir de várias redes diferentes, como a rede interna, a rede de uma empresa parceira ou a Internet.
Os usuários consomem conteúdo de vários aplicativos Web. Por exemplo, um ambiente de intranet poderia incluir sites hospedados em vários aplicativos Web diferentes. Adicionalmente, os funcionários podem ter acesso ao conteúdo da intranet e ao conteúdo de colaboração 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.
Política para um aplicativo Web
Uma política para um aplicativo Web impõe permissões sobre todo o conteúdo de um aplicativo Web, permitindo que você defina políticas de segurança para usuários no nível do aplicativo Web. As permissões de uma política substituem todas as outras configurações de segurança definidas para sites e conteúdo.
Você pode configurar política baseada em usuários ou grupos de usuários no AD DS, mas não em grupos do SharePoint. Uma política pode ser definida para o aplicativo Web em geral ou somente para uma zona específica.
Capacidade
Não há restrições de capacidade que se aplicam a políticas para aplicativos Web.
Compartilhamento e isolamento
Uma política para um aplicativo Web oferece um método de configurar permissões baseado em usuários e a zona por onde eles acessam conteúdo.
Por exemplo, ao usar uma política, você pode:
Permitir que a equipe de Assistência técnica tenha acesso a todo o conteúdo.
Negar acesso de gravação a parceiros ou fornecedores.
Negar acesso aos dados protegidos para um grupo de usuários, independentemente de como os proprietários de sites configuram permissões.
Garantir que a conta de rastreamento tenha acesso para rastrear todo o conteúdo.
Itens configuráveis
A tabela a seguir exibe os itens configuráveis que contribuem para o isolamento e o compartilhamento.
Item |
Descrição |
Diretiva de usuário |
Crie uma diretiva aplicável a usuários ou grupos de usuários:
Você pode modificar os níveis de permissão padrão ou criar novos níveis de permissão clicando na diretiva de Permissão quando criar a diretiva na Administração Central. |
Diretiva anônima |
Se o acesso anônimo for habilitado para o aplicativo Web em uma ou mais zonas, você pode criar uma diretiva que se aplique a todos os usuários anônimos. As configurações padrão de diretiva são:
Os níveis de diretiva de usuário anônimo não podem ser modificados. |
Diretiva de permissão |
Edite as permissões específicas associadas a um dos níveis de permissão padrão ou crie um novo nível de diretiva de permissão. Além disso, você pode especificar as permissões específicas permitidas ou negadas para sites e conjuntos de sites. Após criar um novo nível de permissão, você pode criar uma diretiva de usuário que use a diretiva de permissão. |
Administração
A administração em andamento de diretivas para aplicativos Web não é significativa.
Recomendações de planejamento
Considere o uso de diretivas para gerenciar grandes grupos de usuários, em vez de usuários individuais, já que as diretivas são gerenciadas centralmente.
Bancos de dados de conteúdo
Como padrão, todo conteúdo para um aplicativo Web é armazenado em um único banco de dados de conteúdo. Você pode dividir o conteúdo em vários bancos de dados no nível de conjunto de sites. Um banco de dados de conteúdo pode incluir um ou mais conjuntos. Um único conjunto não pode se estender a vários bancos de dados. O backup e a restauração de sites ocorrem no nível do banco de dados de conteúdo.
Capacidade
A diretriz para um desempenho aceitável é implementar no máximo 100 bancos de dados por aplicativo Web.
Compartilhamento e isolamento
O planejamento de bancos dados permite a otimização para eficiência (vários conjuntos de sites compartilhando um banco de dados) ou isolamento (um banco de dados por conjunto de sites).
Obtenha eficiência de dimensionamento gerenciando bancos de dados até o tamanho máximo do destino. Nesse caso, você configura as definições dos bancos de dados para adicionar conjuntos de sites aos bancos de dados existentes até que o número máximo de conjuntos de sites seja atingido. O número máximo de conjuntos de sites é obtido calculando o tamanho médio ou máximo dos conjuntos de sites dividido pelo tamanho máximo de destino do banco de dados. Essa abordagem funciona bem quando se espera um grande número de pequenos conjuntos de sites, como Meus Sites.
Obtenha o isolamento de conteúdos entre equipes ou projetos limitando o banco de dados a um único conjunto de sites. Essa abordagem permite o gerenciamento independente do conteúdo de equipes individuais. Por exemplo, você pode gerenciar o banco de dados de cada equipe de forma independente para backup, recuperação e migração. Essa abordagem fornece a oportunidade de implementar diferentes contratos de nível de serviço para diferentes equipes ou projetos. Essa abordagem também permite gerenciar o conteúdo durante o ciclo de vida de um projeto. Por exemplo, você pode arquivar um banco de dados quando um projeto tiver sido concluído.
Itens configuráveis
A tabela a seguir exibe os itens configuráveis que contribuem para o isolamento e o compartilhamento.
Item |
Descrição |
Servidor de banco de dados |
Especificar em qual computador com SQL Server deve ser criado um banco de dados de conteúdo. |
Servidor de failover |
Você pode optar por associar um banco de dados de conteúdo a um servidor de failover específico usado em conjunto com o espelhamento de banco de dados do SQL Server. |
Configurações de capacidade |
Você pode especificar o número de sites que podem ser criados antes que um evento de aviso seja gerado e o máximo número de sites possa ser criado em cada banco de dados. |
Administração
Um plano de administração de banco de dados gerenciável equilibra o número de bancos de dados com os recursos exigidos para gerenciar os bancos de dados.
A administração de bancos de dados inclui:
Criação de novos bancos de dados para novos sites ou conjuntos de sites de equipes que exigem bancos de dados dedicados.
Monitoração dos tamanhos dos bancos de dados e criação de novos bancos de dados quando os destinos de tamanho se aproximam.
Backup e restauração de bancos de dados.
Recomendações de planejamento
Escolha uma destas duas 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ífico. 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 desejar associar conjuntos de sites a bancos de dados de conteúdo específico, pode usar um destes métodos:
Use o Windows PowerShell para criar um conjunto de sites em um banco de dados novo.
Aplique as seguintes configurações de capacidade de banco de dados na página Gerenciar Definições de Banco de Dados de Conteúdo no site da Administração Central do SharePoint:
Número de sites antes de um aviso de evento 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 as seguintes etapas:
Adicione um banco de dados de conteúdo para o aplicativo Web e verifique se o seu status está definido 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 podem ser criados novos conjuntos de sites. Entretanto, aqueles já existentes em bancos de dados offline continuam acessíveis para operações de leitura e gravação.
Crie os conjuntos de sites. Eles são automaticamente adicionados ao banco de dados online.
Defina o status de todos os outros bancos de dados como Pronto.
Conjuntos de sites
Um conjunto de sites é um grupo de sites que têm o mesmo proprietário e compartilham as configurações de administração. Cada conjunto de sites contém um site de nível superior e pode conter um ou mais subsites.
Capacidade
A diretriz recomendável para um desempenho aceitável é implementar menos de 50.000 conjuntos de sites de banco de dados de conteúdo. No entanto, o desempenho pode ser afetado ao atingir o nível de 10.000 sites. O dimensionamento pela distribuição de conjuntos de sites por vários servidores de banco de dados oferece capacidade de armazenamento e taxa de transferência adicionais.
Compartilhamento e isolamento
Os conjuntos de sites oferecem diversas oportunidades de compartilhamento e isolamento que afetam permissões, navegação e implantação de recursos.
Os itens a seguir podem ser compartilhados em um conjunto de sites, mas não podem ser compartilhados entre conjuntos de sites (exceto os itens armazenados no diretório _layouts:
Páginas mestras
Layouts de página
Imagens
Modelos de site
Além disso, as permissões e a navegação são isoladas no nível do conjunto de sites das seguintes maneiras:
Os subsites em um conjunto de sites podem herdar permissões do site de nível superior.
Os conjuntos de sites não podem herdar permissões de outros conjuntos de sites.
Não há navegação interna de um conjunto de sites para outro.
Finalmente, o SharePoint Server 2010 agrega resultados da pesquisa em conjuntos de sites com base nas permissões de um usuário, independentemente do número de conjuntos de sites ou bancos de dados (dependendo dos escopos de pesquisa).
É importante observar que, apesar de as permissões serem aplicadas em sites individuais, os sites continuam vulneráveis a ataques de scripts intersite de outros sites do domínio.
Itens configuráveis
A tabela a seguir exibe os itens configuráveis que contribuem para o isolamento e o compartilhamento.
Item |
Descrição |
Administrador do conjunto de sites |
Você pode especificar um usuário para ser o administrador primário do conjunto de sites e um usuário para ser o administrador secundário. Em Administração Central, não é possível inserir mais de uma conta ou uma conta de grupo para essas funções. |
Modelo de site |
Um modelo de site determina que listas e recursos estarão disponíveis em seu site. Vários aspectos de um site podem ser personalizados depois de sua criação. No entanto um modelo não pode ser alterado uma vez que o site tenha sido criado. |
Modelo de cota |
Você pode aplicar um modelo de cota para limitar os recursos usados em um conjunto de sites. Os seguintes modelos são fornecidos:
|
A tabela a seguir exibe itens configuráveis em um conjunto de sites que contribuem para o isolamento e compartilhamento. Essas configurações ficam disponíveis depois que você cria o conjunto de sites usando as configurações na tabela anterior.
Item |
Descrição |
Administradores do conjunto de sites |
Você pode especificar várias contas de usuário como administradoras de conjuntos de sites. Não é possível adicionar contas de grupo. |
Nível de permissão |
Adicione contas de grupo e de usuário para conjuntos de sites e especifique os níveis de permissão para cada uma. |
Administração
A criação de conjuntos de sites não exige entradas DNS (exceto se você estiver criando conjuntos de sites nomeados pelo host) e pode ser facilmente automatizada ou delegada aos usuários. Você pode criar conjuntos de sites para os seus sites de equipe centralmente ou permitir que os usuários criem seus próprios conjuntos de sites usando o Gerenciamento de Site Pessoal.
O uso de um banco de dados dedicado para um conjunto de sites possibilita a realização de backup e recuperação no nível do conjunto de sites.
Recomendações de planejamento
Arquitetura lógica de ponte de conjuntos de sites e arquitetura de informação. Ao criar seus conjuntos de sites, considere estas duas tarefas de planejamento:
Criar URLs consistentes em sua organização.
Criar divisões lógicas de conteúdo.
A menos que esteja usando um conjunto de sites nomeados pelo host, cada aplicativo Web deve ter um único conjunto de sites de nível raiz. Isso fornece um único caminho de URL para os sites que residem no aplicativo Web. Isso também é necessário se você estiver implementando várias zonas em um aplicativo Web. Para obter mais informações, consulte Host-named site collections neste artigo.
Muitas organizações planejam implementar vários conjuntos de sites em um aplicativo Web para serem usados por diferentes equipes ou divisões na organização. As metas comuns de planejamento incluem:
Manter um conjunto de sites separado e independente para cada equipe.
Criar uma URL exclusiva para cada equipe.
Isolar conteúdo entre equipes.
Para atingir essas metas, você pode usar caminhos gerenciados para incorporar vários conjuntos de site de nível superior em um aplicativo Web. 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 existem em um caminho distinto abaixo do site raiz. Sem caminhos gerenciados, todos os sites criados abaixo do conjunto de sites raiz fazem parte do conjunto de sites raiz.
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 que você atribui. Uma inclusão explícita é aplicada somente a um conjunto de sites. Você pode associar cada um desses conjuntos de sites a um banco de dados de conteúdo diferente, caso deseje gerenciar o crescimento e oferecer a oportunidade de fazer backup e restaurar esses sites separadamente. Um exemplo de URL para um conjunto de sites criado usando esse método é http://fabrikam/hr. O limite de conjuntos de sites criados com uma inclusão explícita é de aproximadamente 100 conjuntos de sites em um aplicativo Web; no entanto, 20 é um bom limite operacional. Se a sua organização exigir um número maior de conjuntos de sites, use uma inclusão de curingas.
Inclusão de curingas: um caminho adicionado à URL. Esse caminho indica que todos os sites especificados diretamente depois do nome do caminho são conjuntos de sites exclusivos. Essa opção é geralmente usada para suporte ao Gerenciamento de Site Pessoal, como Meus Sites ou sites criados para colaboração de parceiros. Exemplos de URLs para conjuntos de sites criados usando esse método são HTTP://partnerweb/sites/Project1 e http://partnerweb/sites/Project2. Nesses exemplos, "http://partnerweb" representa o conjunto de sites raiz e "/sites" representa a inclusão de curinga.
Sites
Um site consiste em uma ou mais páginas da Web e outros itens relacionados (como listas, bibliotecas e documentos) que estão hospedados em um conjunto de sites.
Capacidade
A diretriz para um desempenho aceitável é implementar menos de 250.000 sites por conjunto de sites. Você pode criar um número total bastante grande de sites aninhando os subsites. No entanto, um grande número de subsites aninhados pode afetar muito o tempo necessário para atualização de sites. Cinco mil sites em um conjunto de sites é uma boa meta operacional.
Compartilhamento e isolamento
Os sites incluem navegadores internos de um subsite para outro em um conjunto de sites. Não há navegação interna de um conjunto de sites para outro.
Como nos conjuntos de sites, sites separados são vulneráveis a ataques de scripts intersite de outros sites do domínio.
Elementos configuráveis
Você pode adicionar contas de grupo ou de usuário ao grupo Proprietários de cada site, no próprio site.
Administração
Você pode usar uma variedade de ferramentas para fazer backup e restaurar sites individuais.
Conjuntos de sites com nome de host
Os conjuntos de sites com nome de host são uma opção se você desejar criar vários conjuntos de sites no nível de raiz em um aplicativo Web. Por exemplo, os administradores para organizações de hospedagem usam conjuntos de sites com nome de host para criar vários sites com nome de domínio.
Não há modo especial, como modo de cabeçalho de host, que é exigido para criar conjuntos de sites nomeados pelo host. Os conjuntos de sites nomeados pelo host são criados usando o Windows PowerShell. Além disso, usando o Windows PowerShell, você pode usar caminhos gerenciados com conjuntos de sites nomeados pelo host (New-SPManagedPath ?HostHeader).
Os conjuntos de sites nomeados pelo host oferecem mais controle sobre URLs. No entanto, conjuntos de sites nomeados pelo host só estão disponíveis através da zona Padrão. Contas de usuário configuradas para realizar autenticação através de outras zonas não podem acessar conjuntos de sites nomeados pelo host.
Nos Produtos do SharePoint 2010, conjuntos de sites nomeados pelo host oferecem suporte a uma terminação SSL externa. No entanto, somente o esquema de protocolo pode ser alterado externamente (http:// ou https://). O servidor proxy reverso não pode alterar o nome do host ou o número da porta (exceto para trocar da porta SSL padrão para a porta HTTP padrão).
Capacidade
Você pode criar até 100.000 conjuntos de sites com nome de host em um único site do IIS.
Compartilhamento e isolamento
Os nomes de domínio independentes que resultam de conjuntos de sites com nome de host ajudam a prevenir ataques de scripts intersite entre dois sites.
Administração
As tarefas administrativas para conjuntos de sites com nome de host incluem:
Adicionar conjuntos de sites nomeados pelo host usando o Windows PowerShell.
Cada conjunto de sites com nome de host exige uma entrada DNS separada.
Meus Sites
Meus Sites são sites especiais do SharePoint personalizados para cada usuário. Os Meus Sites são habilitados por padrão como parte do serviço de Perfil do Usuário e cada usuário de uma organização pode criar um Meu Site exclusivo. Para obter informações sobre capacidade, compartilhamento, isolamento e administração, consulte Sites acima, neste artigo.