share pt serv plan platf m
DESCRIPTION
sdfsdfasdgTRANSCRIPT
Guia de planejamento de ambientes e farms de servidores do Microsoft SharePoint Server 2010 Microsoft Corporation
Publicado em: janeiro de 2011
Autor: equipe de servidores e do Microsoft Office System ([email protected])
Resumo
Este manual fornece informações e diretrizes para a tomada de decisões sobre a arquitetura do sistema para uma implantação do Microsoft SharePoint Server 2010. Os tópicos incluem requisitos do sistema, autenticação e gerenciamento de continuidade de negócios. As informações sobre planejamento de capacidade são fornecidas em um manual separado (o link é indicado a seguir). As audiências deste guia são especialistas em aplicativos de negócios, especialistas em linha de negócios, arquitetos da informação, generalistas em TI, gerentes de programa e especialistas em infraestrutura que planejam uma solução baseada no SharePoint Server 2010. Este manual faz parte de um conjunto de quatro guias de planejamento que fornecem abrangentes informações de planejamento de TI para o SharePoint Server.
Para obter informações sobre planejamento de capacidade, consulte Capacity planning for Microsoft SharePoint Server 2010 (http://go.microsoft.com/fwlink/?linkid=208221&clcid=0x416).
Para obter informações sobre o planejamento de sites e soluções criados com o uso do SharePoint Server, consulte Planning guide for sites and solutions for Microsoft SharePoint Server 2010, Part 1 (http://go.microsoft.com/fwlink/?linkid=196150&clcid=0x416) e Planning guide for sites and solutions for Microsoft SharePoint Server 2010, Part 2 (http://go.microsoft.com/fwlink/?linkid=208024&clcid=0x416).
O conteúdo deste guia é uma cópia do conteúdo selecionado na SharePoint Server 2010 technical library (http://go.microsoft.com/fwlink/?linkid=181463&clcid=0x416) a partir da data de publicação. Para obter o conteúdo mais atual, consulte a biblioteca técnica na Web.
Este documento é fornecido "no estado em que se encontra". As informações e as exibições expressas neste documento, incluindo URLs e outras referências a sites da Internet, podem ser alteradas sem aviso prévio. Você assume o risco inerente à sua utilização.
Alguns exemplos citados neste documento são fornecidos somente como ilustração e são fictícios. Não há nenhuma intenção, nem por dedução, de qualquer associação ou conexão real.
Este documento não oferece a você quaisquer direitos legais sobre propriedade intelectual em qualquer produto da Microsoft. Este documento pode ser copiado e usado para fins internos e de referência.
© 2011 Microsoft Corporation. Todos os direitos reservados.
Microsoft, Access, Active Directory, Backstage, Excel, Groove, Hotmail, InfoPath, Internet Explorer, Outlook, PerformancePoint, PowerPoint, SharePoint, Silverlight, Windows, Windows Live, Windows Mobile, Windows PowerShell, Windows Server e Windows Vista são marcas registradas ou marcas comerciais da Microsoft Corporation nos Estados Unidos e/ou em outros países.
Conteúdo
Guia de planejamento de ambientes e farms de servidores do Microsoft SharePoint
Server 2010 .................................................................................................................. 1
Obtendo ajuda ..................................................................................................................... 9
Diagramas técnicos (SharePoint Server 2010) ................................................................ 10
Modelos ......................................................................................................................... 10
Dicas para impressão de cartazes ................................................................................ 24
Planejar ambientes e farms de servidores (SharePoint Server 2010) ............................. 25
Requisitos do sistema (SharePoint Server 2010) ............................................................. 26
Requisitos de hardware e software (SharePoint Server 2010)......................................... 27
Visão geral ..................................................................................................................... 27
Requisitos de hardware — servidores Web, servidores de aplicativos e instalações de
servidor único ............................................................................................................. 27
Requisitos de hardware — servidores de bancos de dados ......................................... 28
Requisitos de software .................................................................................................. 29
Acesso ao software aplicável ........................................................................................ 34
Planejar suporte a navegadores (SharePoint Server 2010) ............................................. 37
Sobre o planejamento do suporte para navegadores ................................................... 37
Fase principal do planejamento do suporte ao navegador ........................................... 37
Controles ActiveX .......................................................................................................... 56
URL path length restrictions (SharePoint Server 2010) (em inglês) ................................. 57
Understanding URL and path lengths ........................................................................... 57
URL path length limitations ............................................................................................ 60
Resolving URL length problems .................................................................................... 61
Suporte a IP (SharePoint Server 2010) ............................................................................ 62
Consulte também ........................................................................................................... 63
Windows Server 2008 R2 and SharePoint Server 2010: Better Together (white paper) . 64
Consulte também ........................................................................................................... 64
SQL Server 2008 R2 e Produtos do SharePoint 2010: melhores juntos (white paper)
(SharePoint Server 2010) .............................................................................................. 65
O melhor da produtividade corporativa: Microsoft Office e Microsoft SharePoint (white
paper)............................................................................................................................. 66
Logical architecture planning (SharePoint Server 2010) .................................................. 67
Planejamento da arquitetura de serviços (SharePoint Server 2010) ............................... 68
Sobre aplicativos de serviço .......................................................................................... 68
Infraestrutura de serviços e princípios de design .......................................................... 71
Implantando aplicativos de serviço entre farms ............................................................ 76
Arquiteturas de exemplo ................................................................................................ 77
Farm único, grupo de aplicativos de serviço único ....................................................... 77
Farm único, vários grupos de aplicativos de serviço ..................................................... 79
Farms de serviços corporativos ..................................................................................... 83
Farms de serviços especializados ................................................................................. 86
Farms entre organizações ............................................................................................. 87
Componentes de arquitetura lógica (SharePoint Server 2010) ........................................ 89
Farms de servidores ...................................................................................................... 89
Aplicativos de serviço .................................................................................................... 90
Pools de aplicativos ....................................................................................................... 93
Aplicativos Web ............................................................................................................. 93
Zonas ............................................................................................................................. 95
Política para um aplicativo Web .................................................................................... 97
Bancos de dados de conteúdo ...................................................................................... 99
Conjuntos de sites ....................................................................................................... 101
Sites ............................................................................................................................. 104
Conjuntos de sites com nome de host ........................................................................ 104
Meus Sites ................................................................................................................... 105
Exemplo de design: implantação corporativa (SharePoint Server 2010) ....................... 106
Sobre os exemplos de design ..................................................................................... 107
Metas globais de design .............................................................................................. 109
Farms de servidores .................................................................................................... 110
Usuários, zonas e autenticação .................................................................................. 112
Serviços ....................................................................................................................... 117
Alternativas de autoria e publicação ............................................................................ 119
Sites de administração ................................................................................................ 120
Pools de aplicativos ..................................................................................................... 120
Aplicativos Web ........................................................................................................... 121
Conjuntos de sites ....................................................................................................... 121
Bancos de dados de conteúdo .................................................................................... 125
Zonas e URLs .............................................................................................................. 127
Políticas de zonas ........................................................................................................ 132
Planejar conjuntos de sites nomeados pelo host (SharePoint Server 2010) ................. 133
Sobre conjuntos de sites nomeados pelo host ............................................................ 133
Sobre cabeçalhos de host ........................................................................................... 134
Criar um conjunto de sites nomeado pelo host ........................................................... 135
Criar programaticamente um conjunto de sites nomeado pelo host ........................... 135
Usar caminhos gerenciados com conjuntos de sites nomeados pelo host ................. 136
Expor sites nomeados pelo host sobre HTTP ou SSL ................................................ 137
Configurar SSL para conjuntos de sites nomeados pelo host .................................... 137
Usar conjuntos de sites nomeados pelo host com terminação SSL externa .............. 138
Ambientes hospedados (SharePoint Server 2010) ........................................................ 139
Modelo: arquiteturas de hospedagem para o SharePoint Server 2010 ......................... 140
White paper: SharePoint 2010 para hosters (SharePoint Server 2010) ......................... 141
Planejamento da virtualização (SharePoint Server 2010) .............................................. 142
Suporte e licenciamento de virtualização (SharePoint Server 2010) ............................. 143
Suporte aos Produtos do SharePoint 2010 para virtualização.................................... 143
Virtualização de servidores usando a tecnologia Hyper-V .......................................... 143
Licenciamento de OSE (ambiente de sistema operacional) ....................................... 144
Licenciamento de Produtos do SharePoint 2010 ........................................................ 144
Requisitos de virtualização do Hyper-V (SharePoint Server 2010) ................................ 145
Hardware ..................................................................................................................... 145
Software ....................................................................................................................... 145
Consulte também ......................................................................................................... 146
Planejar arquiteturas virtuais (SharePoint Server 2010) ................................................ 147
Arquiteturas virtuais versus físicas .............................................................................. 147
Exemplo de arquiteturas virtuais para farms de pequeno a médio porte .................... 150
Exemplos de arquitetura virtual para farms de médio a grande porte ........................ 152
Planejar a virtualização (SharePoint Server 2010) ......................................................... 156
Criar um plano para implantar o SharePoint Server 2010 em um ambiente virtual .... 156
Gerenciamento de capacidade e alta disponibilidade em um ambiente virtual (SharePoint
Server 2010) ................................................................................................................ 161
Visão geral da virtualização ......................................................................................... 161
Gerenciamento da capacidade .................................................................................... 162
Capacidade e dimensionamento do servidor de virtualização .................................... 162
Criando e refinando as arquiteturas ............................................................................ 164
Opções adicionais para melhoria da arquitetura ......................................................... 173
Planejar autenticação (SharePoint Server 2010) ........................................................... 175
Planejar métodos de autenticação (SharePoint Server 2010)........................................ 176
Métodos de autenticação com suporte ........................................................................ 176
Modos de autenticação — clássico ou baseado em declarações .............................. 177
Implementando a autenticação do Windows ............................................................... 180
Implementando a autenticação baseada em formulários ............................................ 181
Implementando a autenticação baseada em tokens de SAML ................................... 182
Escolhendo a autenticação para ambientes LDAP ..................................................... 185
Planejando zonas para aplicativos Web ...................................................................... 185
Arquitetura para provedores baseados em tokens de SAML...................................... 189
Planejar o Serviço de Repositório Seguro (SharePoint Server 2010) ............................ 193
Sobre o Serviço de Repositório Seguro ...................................................................... 193
Preparação do serviço de repositório seguro .............................................................. 193
IDs de aplicativo .......................................................................................................... 194
Mapeamentos do serviço de repositório seguro ......................................................... 194
Serviço de repositório seguro e autenticação de declaração...................................... 194
Consulte também ......................................................................................................... 195
Planejar proteção de segurança (SharePoint Server 2010) ........................................... 196
Instantâneos seguros do servidor ............................................................................... 196
Orientação específica para portas, protocolos e serviços ........................................... 200
Planejar alteração automática de senha (SharePoint Server 2010) .............................. 208
Configurando contas gerenciadas ............................................................................... 208
Redefinindo senhas automaticamente em uma agenda ............................................. 208
Detectando o vencimento de senhas .......................................................................... 209
Redefinindo a senha da conta imediatamente ............................................................ 209
Sincronizando as senhas de contas do SharePoint Foundation com os Serviços de
Domínio Active Directory .......................................................................................... 209
Redefinindo todas as senhas imediatamente ............................................................. 209
Processo de alteração de credenciais ......................................................................... 210
Consulte também ......................................................................................................... 210
SQL Server e armazenamento (SharePoint Server 2010) ............................................. 211
Visão geral do SQL Server em um ambiente do SharePoint (SharePoint Server 2010) 212
Produtos do SharePoint 2010 e o mecanismo de banco de dados do SQL Server ... 212
SQL Server como plataforma de dados para business intelligence nos Produtos do
SharePoint 2010 ....................................................................................................... 213
Ferramentas de criação e publicação do SharePoint Server 2010 para business
intelligence ............................................................................................................... 216
Conteúdo relacionado .................................................................................................. 216
Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010) ............................................................................................ 218
Processo de design e configuração do armazenamento e da camada do banco de
dados dos Produtos SharePoint 2010 ..................................................................... 218
Coletar requisitos de armazenamento e de espaço e E/S do SQL Server ................. 219
Escolher a versão e a edição do SQL Server ............................................................. 228
Projetar a arquitetura de armazenamento com base em requisitos de capacidade e E/S
.................................................................................................................................. 229
Estimar requisitos de memória .................................................................................... 231
Entender os requisitos de topologia de rede ............................................................... 232
Configurar o SQL Server ............................................................................................. 232
Validar e monitorar o desempenho do armazenamento e do SQL Server ................. 237
Overview of Remote BLOB Storage (SharePoint Server 2010) (em inglês) .................. 243
Introduction to RBS ...................................................................................................... 243
Using RBS together with SharePoint 2010 Products .................................................. 244
Consulte também ......................................................................................................... 245
Planejar o RBS (Remote BLOB Storage) (SharePoint Server 2010) ............................. 246
Examinar o ambiente ................................................................................................... 246
Avaliar as opções de provedor .................................................................................... 247
Planejar o gerenciamento da continuidade dos negócios (SharePoint Server 2010) .... 249
Recursos de gerenciamento de continuidade de negócios ......................................... 249
Contratos de nível de serviço ...................................................................................... 250
Conteúdo relacionado .................................................................................................. 252
Planejar a proteção do conteúdo usando lixeiras e controle de versão (SharePoint Server
2010) ............................................................................................................................ 253
Protegendo o conteúdo usando lixeiras ...................................................................... 253
Protegendo o conteúdo usando o controle de versão ................................................. 255
Planejar o backup e a recuperação (SharePoint Server 2010) ...................................... 256
Definir os requisitos de negócios ................................................................................. 256
Escolher o que deve ser protegido e recuperado no ambiente................................... 257
Escolher ferramentas ................................................................................................... 261
Determinar estratégias ................................................................................................ 263
Planejar backup avançado e desempenho de recuperação ....................................... 264
Conteúdo relacionado .................................................................................................. 265
Visão geral sobre backup e recuperação (SharePoint Server 2010) ............................. 266
Cenários de backup e recuperação ............................................................................. 266
Arquitetura de backup .................................................................................................. 266
Processos de recuperação .......................................................................................... 274
Conteúdo relacionado .................................................................................................. 277
Planejar a disponibilidade (SharePoint Server 2010) ..................................................... 278
Visão geral de disponibilidade ..................................................................................... 278
Escolhendo uma estratégia e um nível de disponibilidade ......................................... 280
A redundância e o failover entre data centers em locais próximos são configurados
como um único farm (farm "alongado") .................................................................... 290
Planejar a recuperação de desastre (SharePoint Server 2010) ..................................... 293
Visão geral da recuperação de desastre ..................................................................... 293
Escolha uma estratégia de recuperação de desastre ................................................. 294
Planejamento de data centers em espera a frio .......................................................... 295
Planejamento de data centers em espera passiva ..................................................... 295
Planejamento de data centers em espera ativa .......................................................... 295
Requisitos do sistema para recuperação de desastre ................................................ 301
Implantação global de vários farms (SharePoint Server 2010) ...................................... 302
Soluções globais para Produtos do SharePoint 2010 (modelo) ..................................... 303
Soluções de cliente para ambientes WAN (SharePoint Server 2010) ........................... 304
Modos de exibição móveis .......................................................................................... 305
Office Web Apps .......................................................................................................... 305
Cache de documentos do Office 2010 e o protocolo MS-FSSHTTP .......................... 307
Outlook 2010 ............................................................................................................... 309
SharePoint Workspace ................................................................................................ 311
SharePoint Workspace Mobile para Windows Phone 7 .............................................. 312
SharePoint Workspace com Groove Server ................................................................ 313
Planilhas de planejamento para o SharePoint Server 2010 ........................................... 314
Planilhas de planejamento por tarefa .......................................................................... 314
Planilhas de planejamento por título ........................................................................... 318
9
Obtendo ajuda
Todo esforço foi dedicado para garantir a precisão deste guia. Este conteúdo também está disponível online na TechNet Library do Office System, portanto, se encontrar algum problema, veja se há atualizações em:
http://technet.microsoft.com/pt-br/office/bb267342
Se não encontrar a sua resposta no conteúdo online, envie um email para a equipe de conteúdo de servidores e do Microsoft Office System:
Se a sua dúvida for relacionada aos produtos do Microsoft Office, e não ao conteúdo deste guia, pesquise o Centro de Ajuda e Suporte da Microsoft ou a Base de Dados de Conhecimento Microsoft pelo site:
http://support.microsoft.com/?ln=pt-br
10
Diagramas técnicos (SharePoint Server 2010)
Muitos desses recursos são representações visuais de soluções recomendadas. Eles incluem documentos do tamanho de cartazes, disponíveis em formatos que incluem arquivos do Microsoft Office Visio 2007 ou do Microsoft Visio 2010 (.vsd), PDF e XPS. Talvez seja necessário algum software extra para exibir esses arquivos. Consulte a tabela a seguir para obter informações sobre como abrir esses arquivos.
Tipo de arquivo Software
.vsd Office Visio 2007, Microsoft Visio 2010 ou visualizador gratuito do Visio (http://go.microsoft.com/fwlink/?linkid=118761&clcid=0x416)
Se você utiliza o visualizador do Visio, clique com o botão
direito do mouse no link VSD, clique em Salvar Destino Como, salve o arquivo no seu computador e abra-o.
.pdf Qualquer visualizador de PDF, como o Adobe Reader (http://go.microsoft.com/fwlink/?linkid=134751&clcid=0x416)
.xps Windows 7, Windows Vista, Windows XP com o .NET Framework 3.0 ou o XPS Essentials Pack (http://go.microsoft.com/fwlink/?linkid=134750&clcid=0x416)
Modelos Modelos são cartazes de aproximadamente 112 cm x 87 cm que detalham uma área técnica específica. Esses modelos devem ser usados com os artigos correspondentes no TechNet e são criados com o uso do Office Visio 2007. Você pode modificar os arquivos do Visio para demonstrar como planeja incorporar os Produtos do Microsoft SharePoint 2010 ao seu próprio ambiente.
Título Descrição
Exemplo de Design: portal corporativo com autenticação
clássica
Ilustra uma implantação
corporativa típica, com
os tipos mais comuns de sites representados. Os dois exemplos diferem apenas no
modo de autenticação
11
Título Descrição
Visio (http://go.microsoft.com/fwlink/?linkid=196969&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=196970&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=196971&clcid=0x416)
Exemplo de Design: portal corporativo com autenticação
baseada em declarações
Visio (http://go.microsoft.com/fwlink/?linkid=196972&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=196973&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=196974&clcid=0x416)
implementado.
Use esses exemplos de design com o seguinte artigo: Exemplo de
design: implantação
corporativa (SharePoint Server 2010)
Implantação de Produtos do SharePoint 2010 Apresenta informações
relacionadas ao processo de
12
Título Descrição
Visio (http://go.microsoft.com/fwlink/?linkid=183024&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=183025&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=183026&clcid=0x416
implantação, como os
diferentes ambientes e
estágios de implantação,
além de um fluxograma
que ilustra as etapas de instalação e
configuração do
Produtos do SharePoint 2010
Serviços nos Produtos do SharePoint 2010
Visio (http://go.microsoft.com/fwlink/?linkid=167090&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167092&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167091&clcid=0x416)
Descreve e demonstra a
arquitetura de serviços,
inclusive maneiras comuns de implantar
serviços no design geral
da sua solução.
Use esse diagrama com os seguintes artigos:
Services
architecture
planning
(SharePoint
Foundation 2010)
Planejamento da
arquitetura de
serviços
(SharePoint Server
2010)
Serviços entre farms nos Produtos do SharePoint 2010 Demonstra como
implantar serviços entre
os farms para fornecer uma administração
13
Título Descrição
Visio (http://go.microsoft.com/fwlink/?linkid=167093&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167095&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167094&clcid=0x416)
centralizada de serviços.
Use esse diagrama com os seguintes artigos:
Services
architecture
planning
(SharePoint
Foundation 2010)
Planejamento da
arquitetura de
serviços
(SharePoint Server
2010)
Topologias para o SharePoint Server 2010
Visio (http://go.microsoft.com/fwlink/?linkid=167087&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167089&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167088&clcid=0x416)
Descreve maneiras comuns de criar e dimensionar topologias de farm, inclusive planejar em quais
servidores os serviços
serão iniciados.
Topologias de extranet para Produtos do SharePoint 2010 Ilustra as topologias de
extranet específicas e
que foram testadas com os Produtos do SharePoint 2010.
14
Título Descrição
Visio (http://go.microsoft.com/fwlink/?linkid=187987&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=187988&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=187986&clcid=0x416)
Fornece uma comparação do ISA
Server, do Forefront TMG e do Forefront UAG quando utilizados como produto de firewall ou de gateway com os Produtos do SharePoint 2010.
Hospedando ambientes nos Produtos do SharePoint 2010
Visio (http://go.microsoft.com/fwlink/?linkid=167084&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167086&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167085&clcid=0x416)
Resume o suporte para hospedar ambientes e demonstra arquiteturas de hospedagem comuns.
Para obter mais
informações sobre como
projetar e implantar ambientes de hospedagem, consulte o seguinte: White paper: SharePoint 2010 para hosters (SharePoint Server 2010).
Tecnologias de pesquisa dos Produtos do SharePoint 2010 Compara e contrasta as tecnologias de pesquisa que funcionam com os Produtos do SharePoint
15
Título Descrição
Visio (http://go.microsoft.com/fwlink/?linkid=167731&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167733&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167732&clcid=0x416)
2010:
SharePoint
Foundation 2010
Search Server 2010
Express
Search Server 2010
SharePoint Server
2010
FAST Search
Server 2010 for
SharePoint
Planejamento do ambiente de pesquisa do Microsoft SharePoint Server 2010
Visio (http://go.microsoft.com/fwlink/?linkid=167734&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167736&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167735&clcid=0x416)
Descreve as principais
decisões referentes ao
design de arquitetura em ambientes de pesquisa.
Arquiteturas de pesquisa do Microsoft SharePoint Server 2010
Detalha os
componentes físicos e
lógicos da arquitetura
16
Título Descrição
Visio (http://go.microsoft.com/fwlink/?linkid=167737&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167739&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167738&clcid=0x416)
que compõem um
sistema de pesquisa e demonstra as arquiteturas de pesquisa comuns.
Arquiteturas de pesquisa de design do Microsoft SharePoint Server 2010
Visio (http://go.microsoft.com/fwlink/?linkid=167740&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167742&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167741&clcid=0x416)
Descreve as etapas de design iniciais para determinar um design
básico de uma
arquitetura de pesquisa do SharePoint Server 2010.
Modelo dos Serviços Corporativos de Conectividade Os Serviços
Corporativos de Conectividade da
17
Título Descrição
Visio (http://go.microsoft.com/fwlink/?linkid=165565&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=165566&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=165571&clcid=0x416)
Microsoft são um
conjunto de serviços e
recursos do Microsoft SharePoint Server 2010 e do Microsoft SharePoint Foundation 2010 que oferecem suporte para integrar dados de sistemas
externos às soluções
baseadas no Microsoft SharePoint Server e no Microsoft SharePoint Foundation. Este cartaz de modelo descreve a
arquitetura dos Serviços
Corporativos de Conectividade da Microsoft no SharePoint Server 2010 e fornece
informações sobre como
criar soluções baseadas
no serviço.
Use esse modelo com o seguinte artigo: Business Connectivity Services overview
Implantação de Conteúdo no SharePoint Server 2010
Visio (http://go.microsoft.com/fwlink/?linkid=179391&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=179523&clcid=0x416)
Descreve o recurso de implantação de
conteúdo no SharePoint
Server 2010. Inclui
informações sobre o
seguinte:
Visão geral da
implantação de
conteúdo
Descrição de
caminhos e de
trabalhos de
implantação de
conteúdo
Quando usar uma
implantação de
conteúdo
Alternativas à
implantação de
18
Título Descrição
XPS (http://go.microsoft.com/fwlink/?linkid=179524&clcid=0x416)
conteúdo
Ilustra topologias de
farm de implantação
de conteúdo
comuns
Ilustra e explica o
processo geral de
implantação de
conteúdo
Planejamento de atualizações do Microsoft SharePoint
Server 2010
Visio (http://go.microsoft.com/fwlink/?linkid=167098&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167099&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167100&clcid=0x416)
Abrange o planejamento
de uma atualização do
Microsoft Office SharePoint Server 2007 para o SharePoint Server 2010. Inclui
informações sobre o
seguinte:
Requisitos de
atualização:
hardware, sistema
operacional e banco
de dados
Processo de
atualização: etapas
específicas para
seguir antes,
durante e depois da
atualização
Use esse modelo com o seguinte artigo: Upgrading to SharePoint Server 2010
Abordagens de atualização do Microsoft SharePoint Server
2010
Ajuda você a entender
as abordagens do tipo
in-loco, anexação de
banco de dados e
híbrida para atualização
do Office SharePoint Server 2007 para o SharePoint Server 2010.
Veja as topologias
do farm antes,
durante e depois da
19
Título Descrição
Visio (http://go.microsoft.com/fwlink/?linkid=167101&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167102&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167103&clcid=0x416)
atualização
Compare as
vantagens de cada
tipo de abordagem
de atualização
Use esse modelo com os seguintes artigos:
Determine upgrade
approach
(SharePoint Server
2010)
Upgrade process
overview
(SharePoint Server
2010)
Microsoft SharePoint Server 2010 – Teste seu processo de
atualização
Visio (http://go.microsoft.com/fwlink/?linkid=167104&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167105&clcid=0x416)
XPS
Explica a metodologia para testar o processo
de atualização antes de
atualizar do Office SharePoint Server 2007 para o SharePoint Server 2010.
Compreenda as
metas para testar
seu processo de
atualização:
personalizações,
hardware, tempo,
planejamento
Consulte as etapas
específicas a serem
seguidas para testar
o processo de
atualização
Use esse modelo com o seguinte artigo: Use a trial upgrade to find
20
Título Descrição
(http://go.microsoft.com/fwlink/?linkid=167106&clcid=0x416) potential issues (SharePoint Server 2010)
Microsoft SharePoint Server 2010 – Atualização de serviços
Visio (http://go.microsoft.com/fwlink/?linkid=167107&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167108&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167109&clcid=0x416)
Abrange os serviços de
atualização do Office
SharePoint Server 2007 para o SharePoint Server 2010.
Considerações para
serviços
específicos:
Personalização,
Pesquisa,
Formulários do
InfoPath, Excel,
Catálogo de Dados
Corporativos, Logon
Único
Atualização in-loco
com serviços
Atualização com
anexação de banco
de dados com
serviços
Microsoft SharePoint Server 2010 — Atualizando farms pai
e filho
Abrange o processo e
as considerações a se
ter em mente ao atualizar farms que
compartilham serviços
(farms pai e filho).
21
Título Descrição
Visio (http://go.microsoft.com/fwlink/?linkid=190984&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=190985&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=190986&clcid=0x416)
Introdução a business intelligence no SharePoint Server
2010
Visio (http://go.microsoft.com/fwlink/?linkid=167082&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167170&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167171&clcid=0x416)
Abrange uma visão
geral de business intelligence no SharePoint Server e
fornece as informações
a seguir.
Uma visão geral de
cada serviço de
business
intelligence e
quando usar o
serviço.
A arquitetura para o
aplicativo dos
serviços de
business
intelligence e como
eles trabalham em
conjunto em uma
topologia.
Uma lista de
22
Título Descrição
possíveis fontes de
dados para cada
serviço de business
intelligence.
Bancos de dados com suporte para os Produtos do SharePoint 2010
Visio (http://go.microsoft.com/fwlink/?linkid=187970&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=187969&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=187971&clcid=0x416)
Descreve os bancos de dados do Microsoft SQL Server em que o SharePoint Server 2010
é executado.
Produtos SharePoint 2010: processo de virtualização Oferece orientações
relacionadas à
virtualização e aos
vários estágios de
implantação, assim
como requisitos e exemplos.
Use este diagrama com
os artigos nos capítulos
a seguir:
Virtualization
planning
(SharePoint
23
Título Descrição
Visio (http://go.microsoft.com/fwlink/?linkid=195021&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=195022&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=195023&clcid=0x416)
Foundation 2010)
Planejamento da
virtualização
(SharePoint Server
2010)
Controle para o SharePoint Server 2010
Visio (http://go.microsoft.com/fwlink/?linkid=200532&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=200533&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=200534&clcid=0x416)
Ilustra como desenvolver um plano de controle que inclua controle de TI, controle de gerenciamento de informações e controle
de gerenciamento de aplicativos.
Use esse diagrama com os seguintes artigos:
Governance
overview
(SharePoint Server
2010)
Governance
features
(SharePoint Server
2010)
24
Dicas para impressão de cartazes Se tiver uma plotadora, você poderá imprimir os cartazes no tamanho original. Caso contrário, use as etapas a seguir para imprimir em um papel menor.
Imprimir cartazes em papel de tamanho menor
1. Abra o cartaz no Visio.
2. No menu Arquivo, clique em Configuração de Página.
3. Na guia Configurar Impressão, na seção Papel da impressora, selecione o
tamanho de papel desejado.
4. Na guia Configurar Impressão, na seção Zoom de impressão, clique em Caber
em e especifique 1 folha na horizontal por 1 folha na vertical.
5. Na guia Tamanho da Página, clique em Dimensionar para caber o conteúdo do
desenho e clique em OK.
6. No menu Arquivo, clique em Imprimir.
25
Planejar ambientes e farms de servidores (SharePoint Server 2010)
Esta seção contém recursos de planejamento de infraestrutura e artigos desenvolvidos para ajudar no planejamento de farms de servidores e ambientes necessários para oferecer suporte aos sites do SharePoint.
Nesta seção:
Requisitos do sistema (SharePoint Server 2010)
Planejamento da arquitetura de serviços (SharePoint Server 2010)
Componentes de arquitetura lógica (SharePoint Server 2010)
Planejar autenticação (SharePoint Server 2010)
Planejar proteção de segurança (SharePoint Server 2010)
Planejar o gerenciamento da continuidade dos negócios (SharePoint Server 2010)
Performance and capacity management
Planejamento da virtualização (SharePoint Server 2010)
26
Requisitos do sistema (SharePoint Server 2010)
Antes de instalar o Microsoft SharePoint Server 2010, você deve verificar se instalou todos os componentes de hardware e software necessários. Para planejar a implantação de maneira eficiente, é necessário entender o nível de suporte fornecido para os navegadores da Web que você usará no ambiente e a maneira como o suporte para IPv4 e IPv6 é implementado no SharePoint Server 2010. Você também deve entender as restrições de comprimento de URL e caminho no SharePoint Server 2010.
Os artigos desta seção o ajudarão a preparar a instalação do SharePoint Server 2010, fornecendo informações sobre os pré-requisitos necessários à execução do SharePoint Server 2010.
Requisitos de hardware e software (SharePoint Server 2010)
Este artigo descreve os requisitos de hardware e de software que devem ser atendidos para instalar com êxito o SharePoint Server 2010.
Planejar suporte a navegadores (SharePoint Server 2010)
Este artigo descreve os níveis de suporte para navegadores da Web a serem usados com o SharePoint Server 2010.
URL path length restrictions (SharePoint Server 2010) (em inglês)
Este artigo discute as restrições específicas de caracteres e de comprimento de caminhos de URL no SharePoint Server 2010, no Internet Explorer 7 e no Internet Explorer 8 que você deve ter em mente durante o planejamento de sites, da navegação e da estrutura.
Suporte a IP (SharePoint Server 2010)
Este artigo descreve o suporte do SharePoint Server 2010 para IP versão 4 (IPv4) e IP versão 6 (IPv6).
Windows Server 2008 R2 and SharePoint Server 2010: Better Together (white
paper)
Este artigo descreve os benefícios da implantação do SharePoint Server 2010 no Windows Server 2008 R2 Enterprise.
SQL Server 2008 R2 e Produtos do SharePoint 2010: melhores juntos (white paper)
(SharePoint Server 2010)
Este artigo descreve os benefícios da implantação do SharePoint Server 2010 no Microsoft SQL Server 2008 R2 Enterprise e fornece uma comparação da funcionalidade disponível no SharePoint quando ele está sendo executado em diferentes versões e edições do SQL Server.
O melhor da produtividade corporativa: Microsoft Office e Microsoft SharePoint
(white paper)
Este artigo descreve os benefícios do uso do Microsoft Office 2010 com o SharePoint Server 2010.
27
Requisitos de hardware e software (SharePoint Server 2010)
Este artigo lista os requisitos mínimos de hardware e software para instalar e executar o Microsoft SharePoint Server 2010.
Importante:
Se você contatar o suporte técnico da Microsoft com relação a um sistema de produção
que não atende às especificações mínimas de hardware descritas neste documento, o
suporte será limitado até que o sistema seja atualizado para os requisitos mínimos.
Neste artigo:
Visão geral
Requisitos de hardware — servidores Web, servidores de aplicativos e instalações
de servidor único
Requisitos de hardware — servidores de bancos de dados
Requisitos de software
Acesso ao software aplicável
Visão geral O Microsoft SharePoint Server 2010 oferece vários cenários de instalação. No momento, esses incluem instalações de servidor único com banco de dados interno e instalações de farms com um ou vários servidores.
Se você planeja instalar o Microsoft Project Server 2010 com o SharePoint Server 2010, consulte Hardware and software requirements (Project Server 2010). Observe particularmente os navegadores da Web com suporte para os usuários do Project Web App.
Requisitos de hardware — servidores Web, servidores de aplicativos e instalações de servidor único Os requisitos na tabela a seguir se aplicam a instalações de servidor único com banco de dados interno e a servidores que estão executando o SharePoint Server 2010 em uma instalação de farm com vários servidores.
28
Componente Requisito mínimo
Processador 64 bits, quatro núcleos
RAM 4 GB para uso do desenvolvedor ou de
avaliação
8 GB para uso de produção em um farm
com um ou vários servidores
Disco rígido 80 GB para a unidade do sistema
Você precisa ter espaço suficiente para a
instalação base e espaço suficiente para
diagnósticos como geração de logs,
depuração, criação de despejos de memória
e assim por diante. Para uso em produção,
você precisa de espaço livre adicional em
disco para operações diárias. Mantenha
duas vezes mais espaço livre do que a
memória RAM disponível para ambientes de
produção. Para obter mais informações,
consulte Capacity management and sizing for SharePoint Server 2010.
Requisitos de hardware — servidores de bancos de dados Os requisitos da tabela a seguir se aplicam aos servidores de banco de dados em ambientes de produção com vários servidores no farm.
Observação:
Nossas definições de implantações pequenas e médias estão descritas na seção sobre
arquiteturas de referência em Capacity management and sizing for SharePoint Server
2010.
Componente Requisito mínimo
Processador 64 bits, quatro núcleos para implantações de pequeno
porte
64 bits, oito núcleos para implantações de médio porte
RAM 8 GB para implantações de pequeno porte
29
Componente Requisito mínimo
16 GB para implantações de médio porte
Para implantações de grande porte, consulte a seção
"Estimativa dos requisitos de memória" em Planejamento e
configuração de armazenamento e capacidade do SQL
Server (SharePoint Server 2010).
Observação:
Esses valores são maiores que os valores mínimos
recomendados para o SQL Server devido à distribuição de
dados necessária para um ambiente de Produtos do
SharePoint 2010. Para obter mais informações sobre os
requisitos de sistema do SQL Server, consulte o artigo
sobre requisitos de hardware e software para a instalação
do SQL Server 2008 (http://go.microsoft.com/fwlink/?linkid=129377&clcid=0x416).
Disco rígido 80 GB para a unidade do sistema
O espaço no disco rígido depende do tamanho do conteúdo
do SharePoint. Para obter informações sobre como estimar
o tamanho do conteúdo e outros bancos de dados para sua
implantação, consulte Planejamento e configuração de
armazenamento e capacidade do SQL Server (SharePoint Server 2010).
Requisitos de software Os requisitos nas tabelas a seguir se aplicam a um único servidor com instalações de bancos de dados internos e instalações de farm de servidores que incluam um único servidor e vários servidores no farm.
Importante:
O SharePoint Server 2010 não dá suporte a nomes de domínio de rótulo único. Para
obter mais informações, consulte as informações sobre configuração do Windows para
domínios com nomes DNS de rótulo único.
A Ferramenta de Preparação de Produtos do Microsoft SharePoint — que pode ser acessada na página inicial do SharePoint Server 2010 — pode auxiliar na instalação dos pré-requisitos de software do SharePoint Server 2010. Verifique se você possui uma
30
conexão com a Internet, pois alguns desses pré-requisitos são instalados a partir da Internet. Para obter mais informações, consulte Deploy single server with SQL server (SharePoint Server 2010), Deploy single server with built-in database (SharePoint Server 2010) e Multiple servers for a three tier farm (SharePoint Server 2010).
Requisitos mínimos
Ambiente Requisito mínimo
Servidor de banco de dados em um farm
Um dos seguintes:
A edição de 64 bits do Microsoft SQL Server 2008 R2.
A edição de 64 bits do Microsoft SQL Server 2008 com Service Pack 1
(SP1) e Atualização Cumulativa 2. Na página do pacote de atualização
cumulativa 2 para SQL Server 2008 Service Pack 1
(http://go.microsoft.com/fwlink/?linkid=165962&clcid=0x416), clique no
link Exibir e solicitar downloads de hotfix e siga as instruções. Na
página Solicitação de Hotfix, baixe o arquivo
SQL_Server_2008_SP1_Cumulative_Update_2. Quando você instalar o
Microsoft SQL Server 2008 SP1 no Windows Server 2008 R2, talvez
receba um aviso de compatibilidade. Ignore esse aviso e continue a
instalação.
Observação:
Não é recomendável usar a atualização cumulativa 3 ou 4; use a 2, a
5 ou uma atualização cumulativa posterior à 5. Para obter mais
informações, consulte o artigo sobre o pacote de atualização
cumulativa 5 para SQL Server 2008 (http://go.microsoft.com/fwlink/?linkid=196928&clcid=0x416). Baixe o arquivo SQL_Server_2008_RTM_CU5_SNAC.
A edição de 64 bits do Microsoft SQL Server 2005 com Service Pack 3
(SP3). Na página do pacote de atualização cumulativa 3 para SQL Server
2005 Service Pack 3
(http://go.microsoft.com/fwlink/?linkid=165748&clcid=0x416), clique no
link Exibir e solicitar downloads de hotfix e siga as instruções. Na
página Solicitação de Hotfix, baixe o arquivo
SQL_Server_2005_SP3_Cumulative_Update_3.
Para obter mais informações sobre como escolher uma versão do SQL
Server, consulte SQL Server 2008 R2 e Produtos do SharePoint 2010: melhores juntos (white paper) (SharePoint Server 2010).
Servidor
único com
banco de dados interno
A edição de 64 bits do Windows Server 2008 Standard, Enterprise, Data
Center ou Web Server com SP2 ou a edição de 64 bits do Windows
Server 2008 R2 Standard, Enterprise, Data Center ou Web Server. Se
você estiver executando o Windows Server 2008 sem o SP2, o
Ferramenta de Preparação de Produtos do Microsoft SharePoint instalará
o Windows Server 2008 SP2 automaticamente.
31
Ambiente Requisito mínimo
Observação:
É necessário baixar uma atualização para o Windows Server 2008 e o
Windows Server 2008 R2 antes de executar a Instalação. A atualização
é um hotfix para o .NET Framework 3.5 SP1 instalado pela Ferramenta
de preparação. Ele fornece um método de suporte para a autenticação
de token sem segurança de transporte ou criptografia de mensagem no
WCF. Para obter mais informações e links, consulte a seção "Acesso ao
software aplicável", mais adiante neste artigo.
KB979917 - QFE para problemas do Sharepoint - correção do Contador
de Desempenho e Representação de Usuário
(http://go.microsoft.com/fwlink/?linkid=192577&clcid=0x416)
Para o Windows Server 2008 SP2, baixe o arquivo Windows6.0-
KB979917-x64.msu (Vista).
Para o Windows Server 2008 R2, baixe o arquivo Windows6.1-
KB979917-x64.msu (Win7).
Para obter mais informações, consulte o artigo relacionado da Base
de Dados de Conhecimento sobre a ocorrência de dois problemas
durante a implantação de um aplicativo baseado em ASP.NET 2.0 em
um servidor que esteja executando o IIS 7.0 ou o IIS 7.5 no Modo integrado (http://go.microsoft.com/fwlink/?linkid=192578&clcid=0x416).
A ferramenta de preparação instala os seguintes pré-requisitos:
Função Servidor Web (IIS)
Função Servidor de Aplicativos
Microsoft .NET Framework versão 3.5 SP1
SQL Server 2008 Express com SP1
Microsoft Sync Framework Runtime v1.0 (x64)
Microsoft Filter Pack 2.0
Microsoft Chart Controls para o Microsoft .NET Framework 3.5
Windows PowerShell 3.0
SQL Server 2008 Native Client
Microsoft SQL Server 2008 Analysis Services ADOMD.NET
Atualização dos Serviços de Dados ADO.NET para .NET Framework 3.5
SP1
Um hotfix para o .NET Framework 3.5 SP1 que fornece um método de
suporte para autenticação de token sem segurança de transporte ou
criptografia de mensagem no WCF.
Windows Identity Foundation (WIF)
32
Ambiente Requisito mínimo
Observação:
Se o Microsoft "Geneva" Framework estiver instalado, desinstale-o antes de instalar o Windows Identity Foundation (WIF).
Servidores Web front-end e servidores de aplicativos em um farm
A edição de 64 bits do Windows Server 2008 Standard, Enterprise, Data
Center ou Web Server com SP2 ou a edição de 64 bits do Windows
Server 2008 R2 Standard, Enterprise, Data Center ou Web Server. Se
você estiver executando o Windows Server 2008 com o SP1, o
Ferramenta de Preparação de Produtos do Microsoft SharePoint instalará
o Windows Server 2008 SP2 automaticamente.
Observação:
É necessário baixar uma atualização para o Windows Server 2008 e o Windows
Server 2008 R2 antes de executar a Instalação. A atualização é um hotfix para o.
NET Framework 3.5 SP1 instalado pela Ferramenta de preparação. Ele fornece
um método de suporte para a autenticação de token sem segurança de
transporte ou criptografia de mensagem no WCF. Para obter mais informações e
links, consulte a seção "Acesso ao software aplicável".
KB979917 - QFE para problemas do Sharepoint - correção do Contador
de Desempenho e Representação de Usuário
(http://go.microsoft.com/fwlink/?linkid=192577&clcid=0x416)
Para o Windows Server 2008 SP2, baixe o arquivo Windows6.0-
KB979917-x64.msu (Vista).
Para o Windows Server 2008 R2, baixe o arquivo Windows6.1-
KB979917-x64.msu (Win7).
Para obter mais informações, consulte o artigo relacionado da Base
de Dados de Conhecimento sobre a ocorrência de dois problemas
durante a implantação de um aplicativo baseado em ASP.NET 2.0 em
um servidor que esteja executando o IIS 7.0 ou o IIS 7.5 no Modo integrado (http://go.microsoft.com/fwlink/?linkid=192578&clcid=0x416).
A ferramenta de preparação instala os seguintes pré-requisitos:
Função Servidor Web (IIS)
Função Servidor de aplicativo
Microsoft .NET Framework versão 3.5 SP1
Microsoft Sync Framework Runtime v1.0 (x64)
Microsoft Filter Pack 2.0
Microsoft Chart Controls para o Microsoft .NET Framework 3.5
33
Ambiente Requisito mínimo
Windows PowerShell 3.0
SQL Server 2008 Native Client
Microsoft SQL Server 2008 Analysis Services ADOMD.NET
Atualização dos Serviços de Dados ADO.NET para .NET Framework 3.5
SP1
Um hotfix para o .NET Framework 3.5 SP1 que fornece um método de
suporte para autenticação de token sem segurança de transporte ou
criptografia de mensagem no WCF.
Windows Identity Foundation (WIF)
Observação:
Se o Microsoft "Geneva" Framework estiver instalado, desinstale-o antes de instalar o Windows Identity Foundation (WIF).
Computador cliente
Um navegador com suporte. Para obter mais informações, consulte
Planejar suporte a navegadores (SharePoint Server 2010).
Software opcional
Ambiente Software opcional
Servidor único com
servidores Web front-end e de banco de dados interno e servidores de aplicativos em um farm
Microsoft SQL Server 2008 R2 para funcionar com
pastas de trabalho PowerPivot. Para obter mais
informações, consulte o artigo sobre o Microsoft SQL
Server 2008 R2
(http://go.microsoft.com/fwlink/?linkid=179611&clcid=0x
416).
Windows 7 ou Windows Vista. Para obter mais
informações, consulte o artigo sobre como configurar o
ambiente de desenvolvimento para SharePoint Server
(http://go.microsoft.com/fwlink/?linkid=164557&clcid=0x
416).
Pacote de instalação do SQL Server Remote BLOB
Store do Feature Pack para Microsoft SQL Server 2008
R2. Para o download, acesse o Centro de Download
(http://go.microsoft.com/fwlink/?linkid=177388&clcid=0x
416).
A ferramenta de preparação instala o seguinte software
opcional:
34
Ambiente Software opcional
Microsoft SQL Server 2008 R2 Suplemento Reporting
Services para Tecnologias do Microsoft SharePoint
2010 (SSRS), para usar os Serviços do Access para o
SharePoint Server 2010. Para o download, vá para o
Centro de Download
(http://go.microsoft.com/fwlink/?linkid=192588&clcid=0x
416).
Plataforma Microsoft Server Speech, para fazer com
que a correspondência fonética de nomes funcione
corretamente para o SharePoint Search 2010.
Computador cliente Cliente do Microsoft Office 2010. Para obter mais
informações, consulte o artigo sobre o Microsoft Office
2010
(http://go.microsoft.com/fwlink/?linkid=195843&clcid=0x
416).
Microsoft Silverlight 3.
Acesso ao software aplicável Para instalar o Windows Server 2008, o Microsoft SQL Server ou o SharePoint Server, você pode acessar os sites listados nesta seção. É possível instalar a maioria dos pré-requisitos de software por meio da página inicial do SharePoint Server. Os pré-requisitos de software também estão disponíveis nos sites listados nesta seção. As funções de Servidor Web (IIS) e Servidor de Aplicativos podem ser habilitadas manualmente no Gerenciador do Servidor.
Em cenários nos quais a instalação de pré-requisitos diretamente da Internet não é possível ou viável, você pode instalá-los por meio de um compartilhamento de rede. Para obter mais informações, consulte Install prerequisites from a network share (SharePoint Server 2010).
Avaliação do SharePoint Server 2010 Standard
(http://go.microsoft.com/fwlink/?linkid=197413&clcid=0x416)
Avaliação do SharePoint Server 2010 Enterprise
(http://go.microsoft.com/fwlink/?linkid=197414&clcid=0x416)
Pacotes de Idiomas de Servidores 2010 para SharePoint Server 2010, Project
Server 2010, Search Server 2010 e Office Web Apps 2010
(http://go.microsoft.com/fwlink/?linkid=197415&clcid=0x416)
Windows Server 2008 R2 and SharePoint Server 2010: Better Together (white
paper)
O melhor da produtividade corporativa: Microsoft Office e Microsoft SharePoint
(white paper)
35
Windows Server 2008 (http://go.microsoft.com/fwlink/?linkid=197426&clcid=0x416)
Windows Server 2008 R2
(http://go.microsoft.com/fwlink/?linkid=197428&clcid=0x416)
SQL Server 2008 R2 (http://go.microsoft.com/fwlink/?linkid=197429&clcid=0x416)
SQL Server 2008 (http://go.microsoft.com/fwlink/?linkid=179611&clcid=0x416)
SQL Server 2005 (http://go.microsoft.com/fwlink/?linkid=197431&clcid=0x416)
Microsoft SQL Server 2008 SP1
(http://go.microsoft.com/fwlink/?linkid=166490&clcid=0x416)
Pacote de atualização cumulativa 2 para SQL Server 2008 Service Pack 1
(http://go.microsoft.com/fwlink/?linkid=165962&clcid=0x416)
Pacote de atualização cumulativa 5 para SQL Server 2008
(http://go.microsoft.com/fwlink/?linkid=197434&clcid=0x416). Baixe o arquivo
SQL_Server_2008_RTM_CU5_SNAC.
Microsoft SQL Server 2005 SP3
(http://go.microsoft.com/fwlink/?linkid=166496&clcid=0x416)
Pacote de atualização cumulativa 3 para SQL Server 2005 Service Pack 3
(http://go.microsoft.com/fwlink/?linkid=165748&clcid=0x416)
Microsoft Windows Server 2008 SP2
(http://go.microsoft.com/fwlink/?linkid=166500&clcid=0x416)
Windows Server 2008 com SP 2 CORREÇÃO: um hotfix que fornece um método de
suporte à autenticação de token sem segurança de transporte ou criptografia de
mensagens no WCF está disponível para o .NET Framework 3.5 SP1
(http://go.microsoft.com/fwlink/?linkid=160770&clcid=0x416)
Windows Server 2008 R2 CORREÇÃO: um hotfix que fornece um método de
suporte à autenticação de token sem segurança de transporte ou criptografia de
mensagens no WCF está disponível para o .NET Framework 3.5 SP1
(http://go.microsoft.com/fwlink/?linkid=166231&clcid=0x416)
Microsoft .NET Framework 3.5 Service Pack 1
(http://go.microsoft.com/fwlink/?linkid=131037&clcid=0x416)
Microsoft SQL Server 2008 Express Edition Service Pack 1
(http://go.microsoft.com/fwlink/?linkid=166503&clcid=0x416)
Windows Identity Foundation para Windows Server 2008
(http://go.microsoft.com/fwlink/?linkid=160381&clcid=0x416)
Windows Identity Foundation para Windows Server 2008 R2
(http://go.microsoft.com/fwlink/?linkid=166363&clcid=0x416)
Microsoft Sync Framework v1.0
(http://go.microsoft.com/fwlink/?linkid=141237&clcid=0x416)
Microsoft Office 2010 Filter Packs
(http://go.microsoft.com/fwlink/?linkid=191851&clcid=0x416)
Controles de Gráfico da Microsoft para Microsoft .NET Framework 3.5
(http://go.microsoft.com/fwlink/?linkid=141512&clcid=0x416)
Windows PowerShell 2.0
(http://go.microsoft.com/fwlink/?linkid=161023&clcid=0x416)
36
Microsoft SQL Server 2008 Native Client
(http://go.microsoft.com/fwlink/?linkid=166505&clcid=0x416)
Microsoft SQL Server 2008 Analysis Services ADOMD.NET
(http://go.microsoft.com/fwlink/?linkid=160390&clcid=0x416)
KB979917 - QFE para problemas do Sharepoint - correção do Contador de
Desempenho e Representação de Usuário
(http://go.microsoft.com/fwlink/?linkid=192577&clcid=0x416)
Para o Windows Server 2008 SP2, baixe o arquivo Windows6.0-KB979917-
x64.msu (Vista).
Para o Windows Server 2008 R2, baixe o arquivo Windows6.1-KB979917-
x64.msu (Win7).
Atualização dos Serviços de Dados ADO.NET para .NET Framework 3.5 SP1
(http://go.microsoft.com/fwlink/?linkid=163519&clcid=0x416) para Windows Server
2008 SP2
Atualização dos Serviços de Dados ADO.NET para .NET Framework 3.5 SP1
(http://go.microsoft.com/fwlink/?linkid=163524&clcid=0x416) para Windows Server
2008 R2 ou Windows 7
Microsoft Silverlight 3 (http://go.microsoft.com/fwlink/?linkid=166506&clcid=0x416)
Microsoft Office 2010 (http://go.microsoft.com/fwlink/?linkid=195843&clcid=0x416)
Suplemento SQL Server 2008 R2 Reporting Services para Microsoft SharePoint
Technologies 2010 (http://go.microsoft.com/fwlink/?linkid=192588&clcid=0x416)
Pacote de instalação do SQL Server Remote BLOB Store do Feature Pack para
Microsoft SQL Server 2008 R2. Para o download, acesse o Centro de Download
(http://go.microsoft.com/fwlink/?linkid=177388&clcid=0x416).
Plataforma Microsoft Server Speech
(http://go.microsoft.com/fwlink/?linkid=179612&clcid=0x416)
Idioma de reconhecimento de fala para inglês
(http://go.microsoft.com/fwlink/?linkid=179613&clcid=0x416)
Idioma de reconhecimento de fala para espanhol
(http://go.microsoft.com/fwlink/?linkid=179614&clcid=0x416)
Idioma para reconhecimento de fala para alemão
(http://go.microsoft.com/fwlink/?linkid=179615&clcid=0x416)
Idioma para reconhecimento de fala para francês
(http://go.microsoft.com/fwlink/?linkid=179616&clcid=0x416)
Idioma para reconhecimento de fala para japonês
(http://go.microsoft.com/fwlink/?linkid=179617&clcid=0x416)
Idioma para reconhecimento de fala para chinês
(http://go.microsoft.com/fwlink/?linkid=179618&clcid=0x416)
Office Communicator 2007 R2
(http://go.microsoft.com/fwlink/?linkid=196930&clcid=0x416)
Microsoft SharePoint Designer 2010 (32 bits)
(http://go.microsoft.com/fwlink/?linkid=196931&clcid=0x416)
Microsoft SharePoint Designer 2010 (64 bits) (http://go.microsoft.com/fwlink/?linkid=196932&clcid=0x416)
37
Planejar suporte a navegadores (SharePoint Server 2010)
O Microsoft SharePoint Server 2010 oferece suporte a vários navegadores da Web comumente usados. Este artigo descreve níveis diferentes de suporte para navegador da Web e a compatibilidade do navegador para sites publicados, e explica como os controles ActiveX afetam os recursos.
Neste artigo:
Sobre o planejamento do suporte para navegadores
Fase principal do planejamento do suporte ao navegador
Controles ActiveX
Sobre o planejamento do suporte para navegadores O SharePoint Server 2010 oferece suporte a vários navegadores da Web comumente usados. Entretanto, é possível que, em alguns deles, certos recursos do SharePoint Server 2010 sofram downgrade, estejam limitados ou só possam ser acessados por meio de etapas alternativas. Em alguns casos, a funcionalidade pode estar indisponível para tarefas administrativas não críticas.
Como parte do planejamento da implantação do SharePoint Server 2010, recomendamos que você examine os navegadores usados em sua organização para assegurar o melhor desempenho com o SharePoint Server 2010.
Se estiver usando o Microsoft Project Server 2010 no farm do SharePoint Server 2010, observe particularmente as diferenças de requisitos do navegador. Para obter mais informações, consulte Plan browser support (Project Server 2010).
Fase principal do planejamento do suporte ao navegador O suporte ao navegador é uma parte importante da implementação do SharePoint Server 2010. Antes de instalar o SharePoint Server 2010, verifique para quais navegadores o SharePoint Server 2010 apresenta suporte. As informações neste tópico abrangem as seguintes áreas:
Níveis de suporte ao navegador
Matriz de suporte a navegadores
Detalhes do navegador
Compatibilidade do navegador para sites de publicação
Níveis de suporte ao navegador
38
O suporte ao navegador para o SharePoint Server 2010 pode ser dividido em três níveis diferentes, como segue:
Com suporte
Um navegador da Web com suporte é aquele compatível com o SharePoint Server 2010, e todos os seus recursos e funções operam normalmente. Se você encontrar problemas, a equipe de suporte pode ajudá-lo a resolvê-los.
Com suporte e limitações conhecidas
Um navegador da Web com suporte e limitações conhecidas é aquele compatível com o SharePoint Server 2010, embora existam algumas limitações conhecidas. A maioria dos recursos e das funções opera normalmente, mas um ou outro não funciona ou está desabilitado por padrão, e é fácil obter a documentação sobre como resolver esses problemas.
Não testado
Um navegador da Web não testado significa que a sua compatibilidade com o SharePoint Server 2010 não foi testada, e pode haver problemas com o seu uso específico. O SharePoint Server 2010 funciona melhor com navegadores da Web atualizados e baseados em padrões.
Matriz de suporte a navegadores
A tabela a seguir fornece um resumo dos níveis de suporte de navegadores comumente utilizados.
Navegador Com suporte Com suporte
com limitações Não
testado
Internet Explorer 8 (32 bits) X
Internet Explorer 7 (32 bits) X
Internet Explorer 8 (64 bits) X
Internet Explorer 7 (64 bits) X
Internet Explorer 6 (32 bits) X
Mozilla Firefox 3.6 (em sistemas operacionais Windows)
X
Mozilla Firefox 3.6 (em sistemas
operacionais não Windows)
X
Safari 4.04 (em sistemas
operacionais não Windows)
X
Detalhes do navegador
Verifique os detalhes do navegador da web que você possui ou planeja usar na organização para garantir que ele funcione com o SharePoint Server 2010 e de acordo com as suas necessidades de negócios.
Internet Explorer 8 (32 bits)
39
O Internet Explorer 8 (32 bits) tem suporte nos seguintes sistemas operacionais:
Windows Server 2003
Windows Server 2008
Windows Server 2003
Windows 7
Windows Vista
Windows XP
Limitações conhecidas
Não há nenhuma limitação conhecida para o Internet Explorer 8 (32 bits).
Internet Explorer 7 (32 bits)
O Internet Explorer 7 (32 bits) tem suporte nos seguintes sistemas operacionais:
Windows Server 2008
Windows Server 2003
Windows Vista
Windows XP
Limitações conhecidas
Não há nenhuma limitação conhecida para o Internet Explorer 7 (32 bits).
Internet Explorer 6 (32 bits)
O SharePoint Server 2010 não dá suporte ao Internet Explorer 6 (32 bits). Se você usar sites de publicação, consulte a seção Compatibilidade do navegador para sites de publicação neste artigo.
Internet Explorer 8 (64 bits)
O Internet Explorer 8 (64 bits) tem suporte nos seguintes sistemas operacionais:
Windows Server 2008 R2
Windows Server 2008
Windows Server 2003
Windows 7
Windows Vista
Windows XP
Limitações conhecidas
A tabela a seguir lista os recursos e suas limitações conhecidas no Internet Explorer 8 (64 bits).
Recurso Limitação
Conectar ao Outlook, Conectar ao Office e Sincronizar com o SharePoint Workspace
Funciona com um controle ActiveX e o protocolo stssync://. Portanto, a funcionalidade pode ser limitada sem um
controle ActiveX, como o que está incluso
no Microsoft Office 2010. O recurso também
requer um aplicativo que seja compatível
com o protocolo stssync://, como o
40
Recurso Limitação
Microsoft Outlook.
Modo Folha de Dados Requer um controle ActiveX de 64 bits. O
Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle.
Editar no aplicativo do Microsoft Office Requer um controle ActiveX de 64 bits. O Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle.
Exibição do Explorer Removida no SharePoint Server 2010. Bibliotecas que foram atualizadas de
versões anteriores do SharePoint Server
2010 ainda podem ter exibições do
Explorer, que podem não funcionar.
Exportar para o Excel Baixa um arquivo com extensão .iqy no
navegador da Web. Se o Microsoft Excel
não estiver instalado e se nenhum outro
aplicativo estiver configurado para abrir o
arquivo, esse recurso não funcionará.
Carregamento e cópia de arquivo Requer um controle ActiveX de 64 bits. O
Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle.
Integração com o Microsoft InfoPath 2010 Requer um controle ActiveX de 64 bits. O
Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle.
Integração com a Biblioteca de Imagens do
Microsoft PowerPoint 2010
Requer um controle ActiveX de 64 bits, como aquele que é fornecido no Microsoft
Office 2010. O usuário poderá aplicar as
seguintes soluções alternativas quando
nenhum controle tiver sido instalado:
Se um usuário quiser carregar várias
imagens em uma biblioteca de imagens,
ele deverá carregar uma imagem por
vez usando Upload.aspx.
Se um usuário quiser editar uma
imagem em uma biblioteca de imagens,
ele deverá baixar essa imagem, editá-la
e depois carregá-la novamente na
biblioteca de imagens.
Se um usuário quiser baixar mais de
uma imagem de uma biblioteca de
imagens, ele deverá baixar uma
imagem por vez clicando no respectivo
link.
41
Recurso Limitação
Criação de diagramas do Microsoft Visio
2010
Requer um controle ActiveX de 64 bits. O
Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle.
Novo Documento Requer um controle ActiveX de 64 bits. O Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle. Embora o
comando Novo Documento possa não
funcionar, você pode usar a funcionalidade
Carregar Documento. Se você instalar e
configurar Office Web Applications no servidor, o comando Novo Documento
funcionará, e será possível criar um
documento do Office no navegador.
Enviar para Pode aproveitar um controle ActiveX de 64
bits. O Microsoft Office 2010 não fornece
uma versão de 64 bits desse controle. Sem
este, os arquivos não podem ser enviados
de um farm do SharePoint para outro. No entanto, eles ainda podem ser enviados de um site para outro.
Assinatura de formulários (InfoPath Form
Services)
Requer um controle ActiveX de 64 bits. O
Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle.
Integração com planilhas e bancos de dados Requer um controle ActiveX de 64 bits. O Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle. O usuário
poderá aplicar as seguintes soluções
alternativas quando nenhum controle tiver sido instalado:
Se um usuário quiser editar um
documento, ele deverá baixar esse
documento, editá-lo e depois salvá-lo
de volta no servidor.
Em uma lista que requer o check-out de
um documento para edição, o usuário
deve utilizar o menu Editar para fazer
check-out do documento, editá-lo e
depois fazer check-in usando esse
mesmo menu Editar.
Exportar para planilha. Os usuários
podem exportar uma lista do SharePoint
como planilha clicando em Exportar
42
Recurso Limitação
para Planilha, na guia Lista da faixa de
opções.
Conexões entre Web Parts Podem exigir a desativação de
bloqueadores de pop-up de navegadores para sites do SharePoint.
Integração com biblioteca de slides e o
PowerPoint 2010
Requer um controle ActiveX de 64 bits. O
usuário poderá aplicar as seguintes
soluções alternativas quando nenhum
controle tiver sido instalado:
Excluir um slide. Os usuários podem
excluir um slide clicando primeiro nesse
slide e depois clicando em Excluir
Slide. Repita a operação em todos os
slides.
Internet Explorer 7 (64 bits)
O Internet Explorer 7 (64 bits) tem suporte nos seguintes sistemas operacionais:
Windows Server 2008
Windows Server 2003
Windows Vista
Windows XP
Limitações conhecidas
A tabela a seguir lista os recursos e suas limitações conhecidas no Internet Explorer 7 (64 bits).
Recurso Limitação
Conectar ao Outlook, Conectar ao Office e Sincronizar com o SharePoint Workspace
Funciona com um controle ActiveX e o protocolo stssync://. Portanto, a funcionalidade pode ser limitada sem um
controle ActiveX, como o que está incluso
no Microsoft Office 2010. Esse recurso requer um aplicativo que seja compatível
com o protocolo stssync://, como o Microsoft Outlook.
Modo Folha de Dados Requer um controle ActiveX de 64 bits. O
Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle.
Editar no aplicativo do Microsoft Office Requer um controle ActiveX de 64 bits. O
43
Recurso Limitação
Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle.
Exibição do Explorer Removida no SharePoint Server 2010. Bibliotecas que foram atualizadas de
versões anteriores do SharePoint Server
2010 ainda podem ter exibições do
Explorer.
Exportar para o Excel Baixa um arquivo com extensão .iqy no
navegador da Web. Se o Microsoft Excel não estiver instalado e se nenhum outro
aplicativo estiver configurado para abrir o
arquivo, esse recurso não funcionará.
Carregamento e cópia de arquivo Requer um controle ActiveX de 64 bits. O
Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle.
Integração com o Microsoft InfoPath 2010 Requer um controle ActiveX de 64 bits. O
Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle.
Integração com a Biblioteca de Imagens do
Microsoft PowerPoint 2010
Requer um controle ActiveX de 64 bits,
como aquele que é fornecido no Microsoft
Office 2010. O usuário poderá aplicar as
seguintes soluções alternativas quando
nenhum controle tiver sido instalado:
Se um usuário quiser carregar várias
imagens em uma biblioteca de imagens,
ele deverá carregar uma imagem por
vez usando Upload.aspx.
Se um usuário quiser editar uma
imagem em uma biblioteca de imagens,
ele deverá baixar essa imagem, editá-la
e depois carregá-la novamente na
biblioteca de imagens.
Se um usuário quiser baixar mais de
uma imagem de uma biblioteca de
imagens, ele deverá baixar uma
imagem por vez clicando no respectivo
link.
Criação de diagramas do Microsoft Visio
2010
Requer um controle ActiveX de 64 bits. O
Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle.
44
Recurso Limitação
Novo Documento Requer um controle ActiveX de 64 bits. O Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle. Embora o
comando Novo Documento possa não
funcionar, você pode usar a funcionalidade
Carregar Documento. Se você instalar e
configurar Office Web Applications no servidor, o comando Novo Documento
funcionará, e será possível criar um
documento do Office no navegador.
Enviar para Pode aproveitar um controle ActiveX de 64
bits. O Microsoft Office 2010 não fornece
uma versão de 64 bits desse controle. Sem
este, os arquivos não podem ser enviados
de um farm do SharePoint para outro. No entanto, eles ainda podem ser enviados de um site para outro.
Assinatura de formulários (InfoPath Form
Services)
Requer um controle ActiveX de 64 bits. O
Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle.
Integração com planilhas e bancos de dados Requer um controle ActiveX de 64 bits. O
Microsoft Office 2010 não fornece uma
versão de 64 bits desse controle. O usuário
poderá aplicar as seguintes soluções
alternativas quando nenhum controle tiver sido instalado:
Se um usuário quiser editar um
documento, ele deverá baixar esse
documento, editá-lo e depois salvá-lo
de volta no servidor.
Em uma lista que requer o check-out de
um documento para edição, o usuário
deve utilizar o menu Editar para fazer
check-out do documento, editá-lo e
depois fazer check-in usando esse
mesmo menu Editar.
Exportar para planilha. Os usuários
podem exportar uma lista do SharePoint
como planilha clicando em Exportar
para Planilha, na guia Lista da faixa de
opções.
Conexões entre Web Parts Podem exigir a desativação de
45
Recurso Limitação
bloqueadores de pop-up de navegadores para sites do SharePoint.
Integração com biblioteca de slides e o
PowerPoint 2010
Requer um controle ActiveX de 64 bits. O
usuário poderá aplicar as seguintes
soluções alternativas quando nenhum
controle tiver sido instalado:
Excluir um slide. Os usuários podem
excluir um slide clicando primeiro nesse
slide e depois clicando em Excluir
Slide. Repita a operação em todos os
slides.
Mozilla Firefox 3.6 (em sistemas operacionais Windows)
O Mozilla Firefox 3.6 tem suporte nos seguintes sistemas operacionais:
Windows Server 2008 R2
Windows Server 2008
Windows Server 2003
Windows 7
Windows Vista
Windows XP
Limitações conhecidas
A tabela a seguir lista recursos e suas limitações conhecidas no Mozilla Firefox 3.6 (em sistemas operacionais Windows).
Recurso Limitação
Conectar ao Outlook, Conectar ao Office e Sincronizar com o SharePoint Workspace
Funciona com um controle ActiveX, mas requer um adaptador de controle do Firefox. O Microsoft Office 2010
não fornece um adaptador de controle do Firefox para esse
controle. O recurso também requer um aplicativo que seja
compatível com o protocolo stssync://, como o Microsoft
Outlook.
Modo Folha de Dados Requer um controle ActiveX, como aquele que é fornecido
no Microsoft Office 2010, e um adaptador de controle do
Firefox. O Microsoft Office 2010 não fornece um adaptador
de controle do Firefox para esse controle.
Arrastar e soltar Web Parts Não podem ser movidas com o recurso de arrastar e soltar
em páginas de Web Parts. Os usuários devem clicar em
Editar na Web Part, selecionar Modificar Web Part e
depois selecionar a zona na seção Layout da página de
46
Recurso Limitação
propriedades da Web Part. Web Parts podem ser movidas com o recurso de arrastar e soltar em Páginas.
Editar no aplicativo do Microsoft Office
Requer um controle ActiveX, como aquele que é fornecido
no SharePoint Server 2010 e um adaptador de controle do
Firefox. Para obter mais informações sobre o Plug-in para
Firefox do Microsoft Office 2010, consulte o artigo sobre o Plug-in FFWinPlugin (http://go.microsoft.com/fwlink/?linkid=199867&clcid=0x416). Se você instalar e configurar o Office Web Applications no
servidor, o recurso Editar funcionará, e será possível
modificar documentos do Office no navegador. Essa funcionalidade somente funciona com o Microsoft Office 2010 ou um produto equivalente juntamente com um plug-in do Firefox.
Exibição do Explorer Removida no SharePoint Server 2010. Bibliotecas que foram atualizadas de versões anteriores do SharePoint
Server 2010 ainda podem ter exibições do Explorer, que
podem não funcionar. A exibição do Explorer requer o
Internet Explorer.
Exportar para o Excel Baixa um arquivo com extensão .iqy no navegador da Web.
Se o Microsoft Excel não estiver instalado e se nenhum
outro aplicativo estiver configurado para abrir o arquivo,
esse recurso não funcionará.
Carregamento e cópia de
arquivo
Requer um controle ActiveX, como aquele que é fornecido
no Microsoft Office 2010, e um adaptador de controle do
Firefox. O Microsoft Office 2010 não fornece um adaptador
de controle do Firefox para esse controle.
Integração com o Microsoft
InfoPath 2010
Requer um controle ActiveX, como aquele que é fornecido
no Microsoft Office 2010, e um adaptador de controle do
Firefox. O Microsoft Office 2010 não fornece um adaptador
de controle do Firefox para esse controle.
Integração com a Biblioteca
de Imagens do Microsoft PowerPoint 2010
Requer um controle ActiveX, como aquele que é fornecido
no Microsoft Office 2010, e um adaptador de controle do
Firefox. O Microsoft Office 2010 não fornece um adaptador
de controle do Firefox para esse controle. O usuário poderá
aplicar as seguintes soluções alternativas quando nenhum
controle tiver sido instalado:
Se um usuário quiser carregar várias imagens em uma
biblioteca de imagens, ele deverá carregar uma imagem
por vez usando Upload.aspx.
Se um usuário quiser editar uma imagem em uma
biblioteca de imagens, ele deverá baixar essa imagem,
editá-la e depois carregá-la novamente na biblioteca de
47
Recurso Limitação
imagens.
Se um usuário quiser baixar mais de uma imagem de
uma biblioteca de imagens, ele deverá baixar uma
imagem por vez clicando no respectivo link.
Criação de diagramas do
Microsoft Visio 2010
Requer um controle ActiveX, como aquele que é fornecido
no Microsoft Office 2010, e um adaptador de controle do Firefox. O Microsoft Office 2010 não fornece um adaptador
de controle do Firefox para esse controle.
Novo Documento Requer um controle ActiveX, como aquele que é fornecido
no Microsoft Office 2010 e um adaptador de controle do
Firefox. Para obter mais informações sobre o Plug-in para
Firefox do Microsoft Office 2010, consulte o artigo sobre o Plug-in FFWinPlugin (http://go.microsoft.com/fwlink/?linkid=199867&clcid=0x416).
Ainda que o comando Novo Documento possa não
funcionar, você poderá usar a funcionalidade Carregar
Documento. Se instalar e configurar o Office Web Applications no servidor, o comando Novo Documento
funcionará, e será possível criar um documento do Office no
navegador.
Editor de Rich-Text – Barra
de Ferramentas Básica
Um usuário pode atualizar a barra de ferramentas básica do
Editor de Rich-Text para um Editor de Rich-Text Completo
que inclua a faixa de opções, alterando as propriedades de
campo da seguinte forma: em FldEdit.aspx, no menu Configurações de Lista, selecione Configurações de
Campo Específicas. Em seguida, em Colunas, clique em
Descrição. Na seção Configurações de Coluna
Adicionais, em Especifique o tipo de texto que deve ser permitido, selecione Rich text aprimorado (Rich text com imagens, tabelas e hiperlinks).
Enviar para Pode aproveitar um controle ActiveX, como aquele que é
fornecido no Microsoft Office 2010, e um adaptador de
controle do Firefox. O Microsoft Office 2010 não fornece um
adaptador de controle do Firefox para esse controle. Sem
este, os arquivos não podem ser enviados de um farm do
SharePoint para outro. No entanto, eles ainda podem ser enviados de um site para outro.
Assinatura de formulários
(InfoPath Form Services)
Requer um controle ActiveX, como aquele que é fornecido
no Microsoft Office 2010, e um adaptador de controle do
Firefox. O Microsoft Office 2010 não fornece um adaptador
de controle do Firefox para esse controle.
Integração com planilhas e Requer controles ActiveX, como aqueles que são fornecidos
48
Recurso Limitação
bancos de dados no Microsoft Office 2010, e adaptadores de controle do Firefox. O Microsoft Office 2010 não fornece um adaptador
de controle do Firefox para esse controle. O usuário poderá
aplicar as seguintes soluções alternativas quando nenhum
controle tiver sido instalado:
Se um usuário quiser editar um documento, ele deverá
baixar esse documento, editá-lo e depois salvá-lo de
volta no servidor.
Em uma lista que requer o check-out de um documento
para edição, o usuário deve utilizar o menu Editar para
fazer check-out do documento, editá-lo e depois fazer
check-in usando esse mesmo menu Editar.
Exportar para planilha. Os usuários podem exportar
uma lista do SharePoint como planilha clicando em
Exportar para Planilha, na guia Lista da faixa de
opções.
Conexões entre Web Parts Podem exigir a desativação de bloqueadores de pop-up de
navegadores para sites do SharePoint.
Integração com biblioteca
de slides e o PowerPoint 2010
Requer controles ActiveX, como aqueles que são fornecidos
no Microsoft Office 2010, e adaptadores de controle do
Firefox. O Microsoft Office 2010 não fornece um adaptador
de controle do Firefox para esse controle. O usuário poderá
aplicar as seguintes soluções alternativas quando nenhum
controle tiver sido instalado:
Excluir um slide. Os usuários podem excluir um slide
clicando primeiro nesse slide e depois clicando em
Excluir Slide. Repita a operação em todos os slides.
Os seguintes recursos não funcionam nesta plataforma:
Copiar um site para uma apresentação. Esse recurso
permite que os usuários adicionem um slide a uma
apresentação do PowerPoint 2010.
Publicar um slide. Esse recurso permite que os usuários
carreguem um único slide de uma apresentação do
PowerPoint 2010 para uma biblioteca de slides. O
Microsoft Office deve estar instalado no computador
cliente.
Mozilla Firefox 3.6 (em sistemas operacionais não Windows)
O Mozilla FireFox 3.6 tem suporte nos seguintes sistemas operacionais:
Mac OSX
49
UNIX/Linux
Limitações conhecidas
A tabela a seguir lista recursos e suas limitações conhecidas no Mozilla FireFox 3.6 (em sistemas operacionais não Windows).
Recurso Limitação
Conectar ao Outlook, Conectar ao Office e Sincronizar com o SharePoint Workspace
Requer um aplicativo que seja compatível
com o protocolo stssync://, como o Microsoft Outlook.
Modo Folha de Dados Requer um controle ActiveX para o qual a
plataforma não possui suporte. O Microsoft
Office 2010 não fornece um adaptador de
controle do Firefox para esse controle.
Arrastar e soltar Web Parts Não podem ser movidas com o recurso de
arrastar e soltar em páginas de Web Parts.
Os usuários devem clicar em Editar na Web
Part, selecionar Modificar Web Part e
depois selecionar a zona na seção Layout
da página de propriedades da Web Part.
Web Parts podem ser movidas com o
recurso de arrastar e soltar em Páginas.
Editar no aplicativo do Microsoft Office Requer um controle ActiveX para o qual não
há suporte nesta plataforma. Se você
instalar e configurar os Office Web Applications no servidor, o recurso Editar
funcionará e será possível modificar
documentos do Office no navegador.
Exibição do Explorer Removida no SharePoint Server 2010. Bibliotecas que foram atualizadas de
versões anteriores do SharePoint Server
2010 ainda podem ter exibições do
Explorer, que podem não funcionar. A
exibição do Explorer requer o Internet
Explorer.
Exportar para o Excel Baixa um arquivo com extensão .iqy no
navegador da Web. Requer um aplicativo que esteja configurado para abrir esse arquivo.
Carregamento e cópia de arquivo Requer um controle ActiveX para o qual não
há suporte nesta plataforma.
Integração com o Microsoft InfoPath 2010 Requer um controle ActiveX para o qual não
há suporte nesta plataforma.
50
Recurso Limitação
Integração com a Biblioteca de Imagens do
Microsoft PowerPoint 2010
Requer um controle ActiveX para o qual não
há suporte nesta plataforma. O Microsoft
Office 2010 não fornece um adaptador de
controle do Firefox para esse controle. O
usuário poderá aplicar as seguintes
soluções alternativas quando nenhum
controle tiver sido instalado:
Se um usuário quiser carregar várias
imagens em uma biblioteca de imagens,
ele deverá carregar uma imagem por
vez usando Upload.aspx.
Se um usuário quiser editar uma
imagem em uma biblioteca de imagens,
ele deverá baixar essa imagem, editá-la
e depois carregá-la novamente na
biblioteca de imagens.
Se um usuário quiser baixar mais de
uma imagem de uma biblioteca de
imagens, ele deverá baixar uma
imagem por vez clicando no respectivo
link.
Criação de diagramas do Microsoft Visio
2010
Requer um controle ActiveX para o qual não
há suporte nesta plataforma.
Novo Documento Requer um controle ActiveX para o qual não
há suporte nesta plataforma. Embora o
comando Novo Documento possa não
funcionar, você pode usar a funcionalidade
Carregar Documento. Se você instalar e
configurar Office Web Applications no servidor, o comando Novo Documento
funcionará, e será possível criar um
documento do Office no navegador.
Editor de Rich-Text – Barra de Ferramentas
Básica
Um usuário pode atualizar a barra de
ferramentas básica do Editor de Rich-Text
para um Editor de Rich-Text Completo que
inclua a faixa de opções, alterando as
propriedades de campo da seguinte forma:
em FldEdit.aspx, no menu Configurações
de Lista, selecione Configurações de
Campo Específicas. Em seguida, em
Colunas, clique em Descrição. Na seção
Configurações de Coluna Adicionais, em
Especifique o tipo de texto que deve ser
51
Recurso Limitação
permitido, selecione Rich text aprimorado (Rich text com imagens, tabelas e hiperlinks).
Enviar para Pode aproveitar um controle ActiveX para o qual não há suporte nesta plataforma. Sem
este, os arquivos não podem ser enviados
de um farm do SharePoint para outro. No entanto, eles ainda podem ser enviados de um site para outro.
Assinatura de formulários (InfoPath Form
Services)
Requer um controle ActiveX para o qual não
há suporte nesta plataforma.
Integração com planilhas e bancos de dados Requer controles ActiveX para os quais não
há suporte nesta plataforma. O usuário
poderá aplicar as seguintes soluções
alternativas quando nenhum controle tiver sido instalado:
Se um usuário quiser editar um
documento, ele deverá baixar esse
documento, editá-lo e depois salvá-lo
de volta no servidor.
Em uma lista que requer o check-out de
um documento para edição, o usuário
deve utilizar o menu Editar para fazer
check-out do documento, editá-lo e
depois fazer check-in usando esse
mesmo menu Editar.
Exportar para planilha. Os usuários
podem exportar uma lista do SharePoint
como planilha clicando em Exportar
para Planilha, na guia Lista da faixa de
opções.
Conexões entre Web Parts Podem exigir a desativação de
bloqueadores de pop-up de navegadores para sites do SharePoint.
Integração com biblioteca de slides e o
PowerPoint 2010
Requer controles ActiveX para os quais não
há suporte nesta plataforma. O usuário
poderá aplicar as seguintes soluções
alternativas quando nenhum controle tiver sido instalado:
Excluir um slide. Os usuários podem
excluir um slide clicando primeiro nesse
slide e depois clicando em Excluir
52
Recurso Limitação
Slide. Repita a operação em todos os
slides.
Os seguintes recursos não funcionam nesta
plataforma:
Copiar um site para uma apresentação.
Esse recurso permite que os usuários
adicionem um slide a uma
apresentação do PowerPoint 2010.
Publicar um slide. Esse recurso permite
que os usuários carreguem um único
slide de uma apresentação do
PowerPoint 2010 para uma biblioteca
de slides. O Microsoft Office deve estar
instalado no computador cliente.
Observação:
Navegadores FireFox em sistemas UNIX/Linux podem não funcionar com o menu Web
Part.
Observação:
Alguns recursos ActiveX, por exemplo, o modo Folha de Dados da lista e o controle que
exibe as informações da presença do usuário, não funcionam no Mozilla Firefox 3.6. Os
usuários do Firefox podem usar o Plug-in para Firefox do Microsoft Office 2010 para
iniciar documentos.
Safari 4.04 (em sistemas operacionais não Windows)
O Safari 4.0.4 tem suporte nos seguintes sistemas operacionais:
Mac OSX (Versão 10.6, Snow Leopard)
Limitações conhecidas
A tabela a seguir lista recursos e suas limitações conhecidas no Safari 4.04 (em sistemas operacionais não Windows).
Recurso Limitação
Conectar ao Outlook, Conectar ao Office e Sincronizar com o SharePoint Workspace
Requer um aplicativo que seja compatível
com o protocolo stssync://, como o Microsoft Outlook.
53
Recurso Limitação
Modo Folha de Dados Requer um controle ActiveX para o qual não
há suporte nesta plataforma.
Arrastar e soltar Web Parts Não podem ser movidas com o recurso de
arrastar e soltar em páginas de Web Parts.
Os usuários devem clicar em Editar na Web
Part, selecionar Modificar Web Part e
depois selecionar a zona na seção Layout
da página de propriedades da Web Part.
Web Parts podem ser movidas com o
recurso de arrastar e soltar em Páginas.
Editar no aplicativo do Microsoft Office Requer um controle ActiveX para o qual não
há suporte nesta plataforma. Se você
instalar e configurar os Office Web Applications no servidor, o recurso Editar
funcionará e será possível modificar
documentos do Office no navegador.
Exibição do Explorer Removida no SharePoint Server 2010. Bibliotecas que foram atualizadas de
versões anteriores do SharePoint Server
2010 ainda podem ter exibições do
Explorer. A exibição do Explorer requer o
Internet Explorer.
Exportar para o Excel Baixa um arquivo com extensão .iqy no
navegador da Web. Requer um aplicativo que esteja configurado para abrir esse arquivo.
Carregamento e cópia de arquivo Requer um controle ActiveX para o qual não
há suporte nesta plataforma.
Integração com o Microsoft InfoPath 2010 Requer um controle ActiveX para o qual não
há suporte nesta plataforma.
Integração com a Biblioteca de Imagens do
Microsoft PowerPoint 2010
Requer um controle ActiveX para o qual não
há suporte nesta plataforma. O usuário
poderá aplicar as seguintes soluções
alternativas quando nenhum controle tiver sido instalado:
Se um usuário quiser carregar várias
imagens em uma biblioteca de imagens,
ele deverá carregar uma imagem por
vez usando Upload.aspx.
Se um usuário quiser editar uma
imagem em uma biblioteca de imagens,
ele deverá baixar essa imagem, editá-la
54
Recurso Limitação
e depois carregá-la novamente na
biblioteca de imagens.
Se um usuário quiser baixar mais de
uma imagem de uma biblioteca de
imagens, ele deverá baixar uma
imagem por vez clicando no respectivo
link.
Criação de diagramas do Microsoft Visio
2010
Requer um controle ActiveX para o qual não
há suporte nesta plataforma.
Novo Documento Requer um controle ActiveX para o qual não
há suporte nesta plataforma. Embora o
comando Novo Documento possa não
funcionar, você pode usar a funcionalidade
Carregar Documento. Se você instalar e
configurar Office Web Applications no servidor, o comando Novo Documento
funcionará, e será possível criar um
documento do Office no navegador.
Editor de Rich-Text – Barra de Ferramentas
Básica
Um usuário pode atualizar a barra de
ferramentas básica do Editor de Rich-Text
para um Editor de Rich-Text Completo que inclua a faixa de opções, alterando as
propriedades de campo da seguinte forma:
em FldEdit.aspx, no menu Configurações
de Lista, selecione Configurações de
Campo Específicas. Em seguida, em
Colunas, clique em Descrição. Na seção
Configurações de Coluna Adicionais, em
Especifique o tipo de texto que deve ser permitido, selecione Rich text aprimorado (Rich text com imagens, tabelas e hiperlinks).
Enviar para Pode aproveitar um controle ActiveX para o
qual não há suporte nesta plataforma. Sem
este, os arquivos não podem ser enviados
de um farm do SharePoint para outro. No entanto, eles ainda podem ser enviados de um site para outro.
Assinatura de formulários (InfoPath Form
Services)
Requer um controle ActiveX para o qual não
há suporte nesta plataforma.
Integração com planilhas e bancos de dados Requer controles ActiveX para os quais não
há suporte nesta plataforma. O usuário
55
Recurso Limitação
poderá aplicar as seguintes soluções
alternativas quando nenhum controle tiver sido instalado:
Se um usuário quiser editar um
documento, ele deverá baixar esse
documento, editá-lo e depois salvá-lo
de volta no servidor.
Em uma lista que requer o check-out de
um documento para edição, o usuário
deve utilizar o menu Editar para fazer
check-out do documento, editá-lo e
depois fazer check-in usando esse
mesmo menu Editar.
Exportar para planilha. Os usuários
podem exportar uma lista do SharePoint
como planilha clicando em Exportar
para Planilha, na guia Lista da faixa de
opções.
Conexões entre Web Parts Podem exigir a desativação de
bloqueadores de pop-up de navegadores para sites do SharePoint.
Integração com biblioteca de slides e o
PowerPoint 2010
Requer controles ActiveX para os quais não
há suporte nesta plataforma. O usuário
poderá aplicar as seguintes soluções
alternativas quando nenhum controle tiver sido instalado:
Excluir um slide. Os usuários podem
excluir um slide clicando primeiro nesse
slide e depois clicando em Excluir
Slide. Repita a operação em todos os
slides.
Os seguintes recursos não funcionam nesta
plataforma:
Copiar um site para uma apresentação.
Esse recurso permite que os usuários
adicionem um slide a uma
apresentação do PowerPoint 2010.
Publicar um slide. Esse recurso permite
que os usuários carreguem um único
slide de uma apresentação do
PowerPoint 2010 para uma biblioteca
de slides. O Microsoft Office deve estar
instalado no computador cliente.
56
Recurso Limitação
Compatibilidade do navegador para sites de publicação
No caso de sites de publicação, os recursos do Gerenciamento de Conteúdo da Web, no SharePoint Server 2010, oferecem um nível de controle avançado sobre a marcação e o estilo da experiência do leitor. Criadores de páginas podem recorrer a esses recursos como uma ajuda para assegurar que suas páginas sejam compatíveis com navegadores adicionais, inclusive o Internet Explorer 6, no que se refere à visualização de conteúdo. Cabe aos criadores elaborarem páginas adequadas aos navegadores aos quais pretendem oferecer suporte.
Para criar conteúdo, é necessário ter um navegador baseado em padrões, como o Internet Explorer 8 ou o Firefox 3.x.
Controles ActiveX Alguns recursos no SharePoint Server 2010 usam controles ActiveX. Em ambientes seguros, é necessário que esses controles tenham permissão de execução no computador cliente para que os recursos em questão possam funcionar. Alguns controles ActiveX, como os incluídos no Microsoft Office 2010, não funcionam com versões de navegadores de 64 bits. Para o Microsoft Office 2010 (64 bits), apenas os controles a seguir funcionam com navegadores de 64 bits:
ppslax.dll – Integração com a biblioteca de slides e o PowerPoint 2010
name.dll – Informações de presença
57
URL path length restrictions (SharePoint Server 2010) (em inglês)
This article discusses the specific URL path length and character restrictions in Microsoft SharePoint Server 2010, Internet Explorer 7, and Internet Explorer 8 that you should be aware of when planning sites, navigation, and structure. This article does not discuss URL length limitations in other browsers. For this information, see the browser documentation.
In this article:
Understanding URL and path lengths
URL path length limitations
Resolving URL length problems
Understanding URL and path lengths This section discusses URL composition, how SharePoint Server 2010 builds URLs, how URLs are encoded and lengthened, and passed as parameters in other URLs.
SharePoint URL composition
The total length of a SharePoint URL equals the length of the folder or file path, including the protocol and server name and the folder or file name, plus any parameters that are included as part of the URL. The formula is as follows:
URL = protocol + server name + folder or file path + folder or file name+ parameters
For example, the following is a typical URL path to a file stored in Microsoft SharePoint Server 2010:
http://www.contoso.com/sites/marketing/documents/Shared%20Documents/Promotion/Some%20File.xlsx
Where the parts of the URL path are as listed in the following table.
URL part Example
Protocol http://
Server name www.contoso.com/
Folder or file path sites/marketing/documents/Shared%20Documents/Promotion/
File name Some%20File.xlsx
When you go to the site and open the file with Microsoft Office Web Apps, the URL will be as follows:
58
http://www.contoso.com/sites/marketing/documents/_layouts/xlviewer.aspx?id=/sites/marketing/documents/Shared%20Documents/Promotion/Some%20File.xlsx&Source=http%3A%2F%2Fwww%2Econtoso%2Ecom%2Fsites%2Fmarketing%2Fdocuments%2FShared%2520Documents%2FForms%2FAllItems%2Easpx%3FRootFolder%3D%252Fsites%252Fmarketing%252Fdocuments%252FShared%2520Documents%252FPromotion%26FolderCTID%3D0x012000F2A09653197F4F4F919923797C42ADEC&DefaultItemOpen=1
Where the parts of the URL path are as listed in the following table.
URL part
Example
Protocol
http://
Server name
www.contoso.com/
Folder or file path
sites/marketing/documents/Shared%20Documents/Promotion/
Folder or file name
xlviewer.aspx
Parameters
?id=/sites/marketing/documents/Shared%20Documents/Promotion/Some%20File.xlsx
&Source=http%3A%2F%2Fwww%2Econtoso%2Ecom%2Fsites%2Fmarketing%2Fdocuments%2FShared%2520Documents%2FForms%2FAllItems%2Easpx %3FRootFolder%3D%252Fsites%252Fmarketing%252Fdocuments%252FShared%2520Documents%252FPromotion%26FolderCTID%3D0x012000F2A09653197F4F4F919923797C42ADEC
&DefaultItemOpen=1
URL Encoding
URL encoding ensures that all browsers will correctly transmit text in URL strings. Characters such as a question marks (?), ampersands (&), slash marks (/), and spaces might be truncated or corrupted by some browsers. SharePoint Server 2010 adheres to the standards for URL encoding that are defined in The Internet Engineering Task Force (IETF) RFC 3986 (http://go.microsoft.com/fwlink/?LinkId=195564&clcid=0x409).
In the URL path example earlier in this article, the Source parameter contains a double-encoded path and is 262 characters. The first de-encoding reveals:
&Source=http://www.contoso.com/sites/marketing/documents/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2Fsites%2Fmarketing%2Fdocuments%2FShared%20D
59
ocuments%2FPromotion&FolderCTID=0x012000F2A09653197F4F4F919923797C42ADEC which is 216 characters.
De-encoded again reveals:
&Source=http://www.contoso.com/sites/marketing/documents/Shared Documents/Forms/AllItems.aspx?RootFolder=/sites/marketing/documents/Shared Documents/Promotion&FolderCTID=0x012000F2A09653197F4F4F919923797C42ADEC which is 200 characters.
If you have non-standard ASCII characters, such as high-ASCII or double-byte Unicode characters, in the SharePoint URL, each of those characters is URL-encoded into two or more ASCII characters when they are passed to the Web browser. Thus, a URL with many high-ASCII characters or double-byte Unicode characters can become longer than the original un-encoded URL. The list below gives examples of the multiplication factors:
High-ASCII characters — for example, (!, ", #, $, %, &, [Space]): multiplication factor
= 3
Double byte Unicode characters — for example, Japanese, Chinese, Korean, Hindi:
multiplication factor = 9
For example, when you translate the names of sites, library, folder, and file in the URL path http://www.contoso.com/sites/marketing/documents/Shared%20Documents/Promotion/Some%20File.xlsx into Japanese, the resulted encoded URL path will become something like the following:
http://www.contoso.com/sites/%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0/%E6%96%87%E6%9B%B8/DocLib/%E3%83%97%E3%83%AD%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB.xlsx. This path is 224 characters, whereas the original URL path is only 94 characters.
Importante:
The following characters cannot be used in an un-encoded URL: (~, #, %, &, *, {}, \, :, <>,
/, +, |, “).
URL parameters
URL parameters are data that are included as part of the URL that are processed. These parameters are also URL-encoded and can be encoded multiple times, producing very long URLs.
For example, if you browse to a list, the URL might be something like the following: http://www.contoso.com/sites/marketing/documents/Shared%20Documents/Forms/AllItemA.aspx?RootFolder=%2Fsites%2Fmarketing%2Fdocuments%2FShared%20Documents%2FPFPromoti&FolderCTID=0x012000F2A09653197F4F4F919923797C42ADEC&View={CD527605-9A7A-448D-9A35-67A33EF9F766}. This URL is 260 characters.
If you then click Create View on the Library tab, the entire URL is included in the resulting URL as the source parameter and it is encoded to be much longer — for example, http://www.contoso.com/sites/marketing/documents/_layouts/ViewType.aspx?List=%7BED6E21E0%2DDF28%2D4165%2DBC3E%2D5371987CC2D2%7D&Source=http%3A%2F%2Fwww%2Econtoso%2Ecom%2Fsites%2Fmarketing%2Fdocuments%2FShared%25
60
20Documents%2FForms%2FAllItems%2Easpx%3FRootFolder%3D%252Fsites%252Fmarketing%252Fdocuments%252FShared%2520Documents%252FPromotion%26FolderCTID%3D0x012000F2A09653197F4F4F919923797C42ADEC%26View%3D%7BCD527605%2D9A7A%2D448D%2D9A35%2D67A33EF9F766%7D. This URL is 457 characters.
Importante:
SharePoint Server 2010 truncates the URL source parameter if the total URL length to be passed to Internet Explorer is more than 1950 bytes. The source parameter is a reference to a previously visited page. The result of the truncation of the source parameter is that the user will be referred back to default location rather than the location specified in the source parameter.
Other parameters, such as sort orders, root folder parameters, and views are not truncated.
URL path length limitations This section discusses the different URL length limitations in SharePoint Server 2010 and Internet Explorer, and how to plan for URL path lengths.
SharePoint URL path length limitations
The limitations In this section apply to the total length of the URL path to a folder or a file in SharePoint Server 2010 but not to the length of any parameters. Also, these limitations apply only to un-encoded URLs, not to encoded URLs. There is no limit to encoded URLs in SharePoint Server 2010. The limitations are the following:
260 Unicode (UTF-16) code units – the characters in a full file path, not including a
domain/server name.
256 Unicode (UTF-16) code units – the characters in a full folder path, not including
the file name and the domain/server name.
128 Unicode (UTF-16) code units - characters in a path component, that is, a file or
folder name.
260 Unicode (UTF-16) code units – the characters in a full path, including a
domain/server name for use with Office clients.
256 Unicode (UTF-16) code units – the characters in a full path including the
domain/server name, for use with Active X controls.
For more information, see Microsoft Knowledge Base article 894630, You receive a "The specified file or folder name is too long" error message (http://go.microsoft.com/fwlink/?LinkId=195567&clcid=0x409).
61
Observação:
Understanding code units - In most cases, one UTF-16 character equals one UTF-16 code unit. However, characters that use Unicode code points greater than U+10000 will equal two UTF-16 code units. These characters include, but are not limited to, Japanese or Chinese surrogate pair characters. If your paths include these characters, the URL length will exceed the URL length limitation with fewer than 256 or 260 characters.
Internet Explorer URL length limitations
Internet Explorer also has limitations that are separate from those in SharePoint Server 2010. Even though you make the SharePoint Server 2010 URL path shorter than the limitations, you might experience an Internet Explorer URL length limitation because of added parameters and encoding of the URL. You must use the most restrictive limitation as a guideline for planning URL lengths.
Both Internet Explorer 7 and Internet Explorer 8 have a maximum URL length of 2,083 UTF-8 characters and a maximum path length of 2,048 UTF-8 characters. However, in Internet Explorer 7, under certain circumstances, the effective URL length limitation is 1024 UTF-8 characters, not 2083 UTF-8 characters. For more information about the URL length limits in Internet Explorer, see Microsoft Knowledge Base article 208427, Maximum URL length is 2,083 characters in Internet Explorer (http://go.microsoft.com/fwlink/?LinkId=195568&clcid=0x409).
Importante:
Unless all of the browsers in the environment are Internet Explorer 8, use the effective limit of 1024 UTF-8 characters.
Resolving URL length problems There are several ways that you can resolve or mitigate URL length problems in the SharePoint Server 2010 environment. The following list provides suggestions:
Upgrade all the end-user browsers to Internet Explorer 8, which has a longer URL
length limit.
Use shorter names for sites, folders, and documents and control the depth of the site
and folder structures to reduce the lengths of URLs.
If possible or allowed, use ASCII names for sites, folders, and documents. This will
avoid situations where the URL will be lengthened by being encoded.
To reduce the risk that the SharePoint Server 2010 end-users will encounter
problems because of URL length limitations, we recommend that you apply the
following effective limits in the deployment:
256 Unicode (UTF-16) Code units - the effective file path length limitation,
including a domain/server name
128 Unicode (UTF-16) Code units - the path component length limitation
62
Suporte a IP (SharePoint Server 2010)
Este artigo explica o suporte ao endereçamento de protocolos IPv4 e IPv6 nos Produtos do Microsoft SharePoint 2010.
Os Produtos do SharePoint 2010 têm suporte para os seguintes ambientes:
Ambiente só IPv4
Ambiente misto de IPv4 e IPv6
Ambiente só IPv6
Em um ambiente do SharePoint, ―misto‖ pode ser definido como um dos seguintes cenários prováveis:
Ambos os protocolos IPv4 e IPv6 estão sendo executados no seu ambiente.
Alguns de seus computadores clientes estão usando IPv4 e outros estão usando
IPv6.
Os computadores clientes estão usando IPv4, mas o computador que executa o
Microsoft SQL Server usa IPv6.
Por padrão, ambos os protocolos (IPv6 e IPv4) estão instalados e habilitados no Windows Server 2008 e no Windows Server 2008 R2. Quando os dois protocolos estão habilitados, o IPv6 tem preferência em relação ao IPv4. Além disso, é possível remover o IPv4 para que o computador execute exclusivamente o IPv6.
Para determinar a versão que está em uso, você pode usar a ferramenta IPConfig.exe. Para obter informações adicionais, consulte IPConfig (http://go.microsoft.com/fwlink/?linkid=122336&clcid=0x416).
A lista a seguir mostra outras considerações importantes sobre o protocolo IPv6:
Para qualquer computador autenticado com o uso de um controlador de domínio e
que execute apenas o IPv6 em um ambiente com Produtos do SharePoint 2010, o
controlador de domínio deve executar o Windows Server 2008 ou o Windows Server
2008 R2. Verifique se você está usando o service pack correto e qualquer pré-
requisitos de software adicional. Para obter mais informações, consulte Requisitos
de hardware e software (SharePoint Server 2010).
Todas as versões do Microsoft SQL Server com suporte para Produtos do
SharePoint 2010 também têm suporte para IPv6. Para obter mais informações sobre
o suporte IPv6 para o SQL Server 2008, consulte Conexão com o uso do IPv6
(http://go.microsoft.com/fwlink/?linkid=183115&clcid=0x416). Para obter informações
adicionais sobre o suporte IPv6 para o SQL Server 2005, consulte Conexão com o
uso do IPv6 (http://go.microsoft.com/fwlink/?linkid=183118&clcid=0x416).
Nos Produtos do SharePoint 2010, quando o protocolo IPv6 é usado, todas as URLs
de usuário final devem se basear em nomes DNS com registros AAAA. Não há
suporte para navegar até URLs do SharePoint que utilizam endereços IPv6 literais.
Um exemplo de URL com endereço literal é
http://[2001:db8:85a3:8d3:1319:8a2e:370:7344]. No entanto, os Produtos do
SharePoint 2010 têm suporte para a inserção de endereços IPv6 literais para uma
determinada funcionalidade de administração de farm, como a inserção do nome do
63
servidor durante a criação ou a anexação de bancos de dados. Para nomes de
servidores que usam o formato de endereço literal, coloque o endereço literal entre
colchetes. Para obter mais informações sobre registros AAAA, consulte Adicionando
um registro de recurso a uma zona de pesquisa direta
(http://go.microsoft.com/fwlink/?linkid=181956&clcid=0x416).
Para obter informações adicionais sobre o IPv6, consulte os artigos sobre protocolo IP versão 6 (IPv6) (http://go.microsoft.com/fwlink/?linkid=120794&clcid=0x416) e endereçamento IP (http://go.microsoft.com/fwlink/?linkid=120795&clcid=0x416).
Consulte também Outros recursos
Especificação do Protocolo IP, Versão 6 (IPv6)
64
Windows Server 2008 R2 and SharePoint Server 2010: Better Together (white paper)
Este white paper descreve os benefícios da implantação do Microsoft SharePoint Server 2010 no sistema operacional Windows Server 2008 R2 Enterprise e em cenários nos quais os recursos do Windows Server 2003 Enterprise podem ser aplicados.
Baixar este white paper como um arquivo .docx (http://go.microsoft.com/fwlink/?linkid=199051&clcid=0x416).
Baixar este white paper como um arquivo PDF (http://go.microsoft.com/fwlink/?linkid=199052&clcid=0x416).
Baixar este white paper como um arquivo XPS (http://go.microsoft.com/fwlink/?linkid=199053&clcid=0x416).
Consulte também Conceitos
O melhor da produtividade corporativa: Microsoft Office e Microsoft SharePoint (white paper)
SQL Server 2008 R2 e Produtos do SharePoint 2010: melhores juntos (white paper) (SharePoint Server 2010)
Requisitos de hardware e software (SharePoint Server 2010)
65
SQL Server 2008 R2 e Produtos do SharePoint 2010: melhores juntos (white paper) (SharePoint Server 2010)
A escolha de uma edição do Microsoft SQL Server 2008 R2 é uma etapa importante no planejamento da implantação de uma implantação do Microsoft SharePoint Server 2010. Este documento descreve os benefícios da implantação no SQL Server 2008 R2 Enterprise Edition e os cenários em que os respectivos recursos podem ser aplicados.
Baixar este white paper como documento do Word (.docx) (http://go.microsoft.com/fwlink/?linkid=187264&clcid=0x416).
66
O melhor da produtividade corporativa: Microsoft Office e Microsoft SharePoint (white paper)
Este white paper mostra como o Microsoft Office 2010 e o Produtos do Microsoft SharePoint 2010 contribuem con o poderoso design arquitetônico do Microsoft Business Productivity Infrastructure (BPI). Ele fornece uma visão geral de recursos do Office e do SharePoint que funcionavam em conjunto em versões anteriores e enfoca os recursos de integração da experiência do Office 2010 com o Produtos do SharePoint 2010.
Baixe este white paper como um arquivo PDF: O melhor da produtividade corporativa (http://go.microsoft.com/fwlink/?LinkId=209803&clcid=0x416)
67
Logical architecture planning (SharePoint Server 2010)
This section contains articles to help you learn about and plan logical architectures for Microsoft SharePoint Server 2010.
In this section:
Planejamento da arquitetura de serviços (SharePoint Server 2010)
Componentes de arquitetura lógica (SharePoint Server 2010)
Exemplo de design: implantação corporativa (SharePoint Server 2010)Corporate
deployment design sample
Planejar conjuntos de sites nomeados pelo host (SharePoint Server 2010)
68
Planejamento da arquitetura de serviços (SharePoint Server 2010)
Este artigo descreve a arquitetura de serviços para compartilhar aplicativos de serviço de e fornece arquiteturas de exemplo para o Microsoft SharePoint Server 2010.
Neste artigo:
Sobre aplicativos de serviço
Infraestrutura de serviços e princípios de design
Implantando aplicativos de serviço entre farms
Arquiteturas de exemplo
Farm único, grupo de serviços único
Farm único, vários grupos de serviços
Farms de serviços corporativos
Farms de serviços especializados
Farms entre organizações
Ao planejar a sua arquitetura de serviços, considere o seguinte:
Que aplicativos de serviço são exigidos por sua organização?
Alguma equipe exige aplicativos de serviço dedicados?
Quantos farms são exigidos por sua organização?
Existem oportunidades de compartilhamento de serviços entre farms?
As necessidades da sua organização garantem um farm de serviços centralizado?
Os modelos de tamanho de cartaz a seguir também estão disponíveis para serem usados com este artigo. É possível modificar os diagramas nos modelos para representar seus próprios planos de organização.
Serviços no Produtos do Microsoft SharePoint 2010
Visio (http://go.microsoft.com/fwlink/?linkid=167090&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167092&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167091&clcid=0x416)
Serviços entre farms no Produtos do SharePoint 2010
Visio (http://go.microsoft.com/fwlink/?linkid=167093&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167095&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167094&clcid=0x416)
Sobre aplicativos de serviço O SharePoint Server 2010 inclui um conjunto de serviços que podem ser compartilhados entre aplicativos Web. Esses serviços são chamados de aplicativos de serviço. Alguns aplicativos de serviço podem ser compartilhados entre farms. O compartilhamento de
69
aplicativos de serviço entre aplicativos Web e farms reduz muito o número de recursos necessários para o oferecimento desses serviços entre vários sites.
A tabela a seguir lista aplicativos de serviço incluídos no Produtos do SharePoint 2010.
Aplicativos de serviço Descrição SharePoint Foundation 2010
SharePoint Server 2010 Standard
SharePoint Server 2010 Enterprise
Serviços do Access Permite que os usuários
exibam, editem e interajam com bancos de dados do Access 2010 em um navegador da Web.
X
Serviço Conectividade de
Dados Corporativos
Oferece acesso a sistemas de dados de
linha de negócios.
X X X
Aplicativo Serviços do
Excel
Permite que os usuários
exibam e interajam com arquivos do Excel 2010 em um navegador da Web.
X
Serviço Metadados
Gerenciados
Gerencia a infraestrutura de hierarquias de taxonomia, palavras-
chave e marcação social
e publica tipos de
conteúdo entre conjuntos
de sites.
X X
Aplicativo PerformancePoint Service
Oferece os recursos do PerformancePoint.
Serviço de Pesquisa Rastreia conteúdo,
produz partições de
índice e atende a
consultas de pesquisa.
X X
Serviço de Repositório
Seguro
Oferece autenticação de
logon único para o
acesso a vários
aplicativos ou serviços.
X X
Serviço de Controle de
Sessão
Oferece armazenamento
temporário de dados de
sessão de usuário para
X X
70
componentes do SharePoint Server.
Serviço de Conjunto de
Dados de Uso e Integridade
Coleta dados de uso e integridade de todo o
farm e permite a exibição
de vários relatórios de
uso e integridade.
X X X
Serviço de Perfil de
Usuário
Adiciona suporte a sites
Meu Site, páginas de
perfil, marcação social e
outros recursos de
computação social.
X X
Serviço de Gráficos do
Visio
Permite que os usuários
exibam e atualizem diagramas do Visio 2010 publicados em um navegador da Web.
X
Serviço Web Analytics Oferece interfaces de
serviço Web.
X X
Serviços de Automação
do Word
Executa conversões de
documento em massa automatizadas.
X X
Serviço de Configurações
de Inscrição do Microsoft
SharePoint Foundation
Oferece funcionalidade
de vários inquilinos para
aplicativos de serviço.
Rastreia IDs de assinatura e
configurações para
serviços implantados em
modo particionado. Implantado somente por meio do Windows PowerShell.
X X X
Alguns serviços são oferecidos por outros produtos da Microsoft, incluindo os serviços listados na tabela a seguir.
Aplicativo de serviço Descrição
Serviços do Office Web Apps:
Serviço de Exibição do Word
Serviço PowerPoint
Serviços de Cálculo do Excel
O Office Web Apps é uma nova opção de
produtividade baseada na Web oferecida pelos pacotes do Microsoft Office 2010. O Office Web Apps inclui complementos para o Microsoft Word 2010, Microsoft Excel
71
2010, Microsoft PowerPoint 2010 e Microsoft OneNote 2010. Trata-se de
aplicativos autônomos baseados na Web
que oferecem acesso a documentos do Microsoft Word 2010, Microsoft Excel 2010, Microsoft PowerPoint 2010 e Microsoft OneNote 2010 por meio de qualquer
navegador em várias plataformas; recursos
leves de criação e edição em formatos
padrão; compartilhamento e colaboração
nesses documentos por meio do navegador; e uma grande variedade de
cenários habilitados para Web. Os
documentos criados com o Office Web
Apps não são diferentes dos documentos
criados com os aplicativos de área de
trabalho correspondentes. Os serviços
associados são usados para preparar os
documentos para exibição e edição em um
navegador da Web.
Microsoft Project Server 2010 O Microsoft Project Server 2010 hospeda uma ou mais instâncias do Project Web
Access, expondo a funcionalidade de
agendamento e outros cálculos de camada
intermediária nos dados do Microsoft Project
e expondo os serviços Web para a interação
com os dados do Microsoft Project 2010.
Aplicativos de serviço são diferentes dos serviços que são iniciados e interrompidos em servidores específicos e listados na página Serviços no Servidor no site de Administração Central do SharePoint. Alguns dos serviços listados nessa página são associados a aplicativos de serviço, mas estes representam instâncias específicas de serviços que podem ser configurados e compartilhados de formas específicas.
Infraestrutura de serviços e princípios de design O Produtos do SharePoint 2010 aprimora a infraestrutura de serviços que foi introduzida na versão anterior. No Produtos do SharePoint 2010, a infraestrutura para hospedar serviços é transferida para o SharePoint Foundation 2010, e a configuração de opções de serviço é muito mais flexível. Serviços individuais podem ser configurados independentemente, e outras empresas podem adicionar serviços à plataforma.
O compartilhamento de serviços não é mais exclusivo do SharePoint Server, e os serviços não estão mais contidos em SSPs (Provedores de Serviços Compartilhados).
Implantando serviços
Você implanta aplicativos de serviço em um farm usando um dos seguintes métodos:
72
Selecionando serviços ao executar o Assistente de Configuração de Produtos do
SharePoint.
Adicionando serviços um a um na página Gerenciar Aplicativos de Serviço, no site
de Administração Central.
Usando o Windows PowerShell.
Configuração de serviços mais granular
A infraestrutura de serviços atualizada oferece mais controle sobre que serviços são implantados e como os aplicativos de serviço são compartilhados:
1. Você pode implantar apenas os aplicativos de serviço que são necessários para um
farm.
2. Os aplicativos Web podem ser configurados para usar apenas os aplicativos de
serviço necessários, em vez de todos os serviços que foram implantados.
3. Você pode implantar várias instâncias do mesmo serviço em um farm e atribuir
nomes exclusivos aos aplicativos de serviço resultantes.
4. Você pode compartilhar aplicativos de serviço entre vários aplicativos Web dentro do
mesmo farm.
Você pode escolher os aplicativos de serviço para um aplicativo Web ao criá-lo. Também pode modificar mais tarde os aplicativos de serviço associados a um aplicativo Web.
Grupos de aplicativos de serviço
Por padrão, todos os aplicativos de serviço são incluídos em um grupo padrão, a menos que você altere essa configuração para um aplicativo de serviço ao criá-lo. É possível adicionar e remover aplicativos de serviço do grupo padrão a qualquer momento.
Ao criar um aplicativo Web, você pode selecionar o grupo padrão ou criar um grupo personalizado de aplicativos de serviço. Para criar um grupo de aplicativos de serviço personalizado, selecione apenas os aplicativos de serviço que você deseja que o aplicativo Web use.
A captura de tela a seguir mostra uma lista de aplicativos de serviço para um farm de exemplo que poderão ser selecionados caso personalizado seja selecionado durante a criação de um aplicativo Web. Somente os primeiros aplicativos de serviço foram incluídos na imagem.
73
Os grupos personalizados criados na Administração Central não são reutilizáveis em vários aplicativos Web. Sempre que você seleciona personalizado ao criar um aplicativo Web, seleciona aplicativos de serviço apenas para o aplicativo Web que está criando.
Arquitetura lógica
Aplicativos de serviço são implantados em um único site do IIS (Serviços de Informações da Internet ). Esse é o comportamento padrão, e não é possível alterá-lo. No entanto, você pode personalizar a configuração de grupos de aplicativos de serviço e a associação de aplicativos Web aos mesmos.
O diagrama a seguir mostra a arquitetura lógica de uma implantação de farm típica.
74
Observe as seguintes características do farm no diagrama:
Todos os aplicativos de serviço estão contidos no mesmo site do IIS.
75
Existem dois grupos de aplicativos de serviço: o grupo padrão ou um grupo
personalizado. Nem todos os aplicativos de serviço precisam ser incluídos no grupo
padrão. No diagrama, o aplicativo de Serviço F não foi incluído no grupo padrão. Ele
é usado somente por um aplicativo Web.
Os aplicativos Web se conectam ao grupo padrão ou a um grupo personalizado de
aplicativos de serviço. No diagrama, há um grupo personalizado.
É possível implantar os aplicativos de serviço em diferentes pools de aplicativos para obter o isolamento do processo. No entanto, se desejar otimizar o desempenho do farm, é recomendável que você implante os aplicativos de serviço em um pool de aplicativos.
Para obter o isolamento físico de um aplicativo de serviço, escolha ou crie um pool de aplicativos diferente para o aplicativo de serviço, como mostrado no diagrama a seguir.
Conexões para aplicativos de serviço
Quando um aplicativo de serviço é criado, é simultaneamente criada uma conexão para ele. Uma conexão é uma entidade virtual que conecta aplicativos Web a aplicativos de serviço. No Windows PowerShell, essas conexões são chamadas de proxies. "Proxy" aparece no fim da descrição de tipo de conexões na página Gerenciar Aplicativos de Serviço na Administração Central. Algumas conexões podem incluir configurações que podem ser modificadas. Por exemplo, conexões para o aplicativo de serviço Metadados Gerenciados incluem diversas configurações, incluindo Administradores de Repositórios de Termos e Idioma Padrão.
Administração de aplicativos de serviço
Em vez de serem gerenciados por meio de um site de administração separado, os aplicativos de serviço são gerenciados diretamente na Administração Central. Se necessário, eles podem ser monitorados e gerenciados remotamente. Também é possível gerenciá-los e escrever scripts para eles usando o Windows PowerShell.
76
Implantando aplicativos de serviço entre farms Alguns aplicativos de serviço podem ser compartilhados entre farms. Outros aplicativos de serviço podem ser compartilhados somente em um único farm de servidores.
O diagrama a seguir mostra que aplicativos de serviço podem ser compartilhados entre farms e que aplicativos de serviço estão limitados a um único farm.
Orientação de design
A orientação a seguir se aplica ao compartilhamento de aplicativos de serviço entre farms:
77
Os aplicativos de serviço que oferecem suporte ao compartilhamento entre farms
podem ser executados em um farm central e consumidos de outros farms.
Cada aplicativo Web pode ser configurado para usar aplicativos de serviço de farms
diferentes. Por exemplo, você pode compartilhar o serviço de Perfil de Usuário entre
aplicativos Web em diversos farms de servidores, ao mesmo tempo que pode
configurar alguns aplicativos de serviço, como o serviço Conectividade de Dados
Corporativos, para uso local.
Em grandes ambientes, os aplicativos de serviço de computação intensiva podem
ser executados em um farm central para minimizar a carga administrativa e crescer,
de maneira fácil e eficiente, à medida que os requisitos aumentam. Para obter mais
informações, consulte Farms de serviços corporativos, mais adiante neste artigo.
Implantando serviços entre farms
O compartilhamento de aplicativos de serviço entre farms requer várias etapas:
1. Configure farms confiáveis.
Verifique se os farms trocaram certificados para confiarem uns nos outros. Exporte o certificado para um arquivo e faça backup desse arquivo antes de se conectar a serviços entre farms.
2. Publique os aplicativos de serviço.
Para compartilhar um aplicativo de serviço entre farms, primeiro publique o serviço.
3. Conecte-se a aplicativos de serviço entre farms.
Para consumir um serviço publicado por um farm remoto, crie uma conexão com ele. Esse processo solicita que você insira a URL de um serviço publicado, exibida durante o processo de publicação. Uma conexão com o farm local é criada para conexão com o aplicativo de serviço do farm remoto.
Se os farms de servidores estiverem localizados em dois domínios, o aplicativo de serviço de Perfil de Usuário exigirá que ambos os domínios confiem um no outro. Para que os recursos de administração de aplicativo de serviço Conectividade de Dados Corporativos e Repositório Seguro funcionem do farm consumidor, o domínio do farm de publicação deverá confiar no domínio do farm consumidor Outros aplicativos de serviço entre farms funcionam sem um requisito de confiança entre domínios.
Para obter mais informações sobre como configurar serviços a serem usados entre farms, consulte Connect to a service application on a remote farm (SharePoint Server 2010).
Arquiteturas de exemplo O restante deste artigo oferece arquiteturas de exemplo para cenários de implantação comum.
Farm único, grupo de aplicativos de serviço único em uma arquitetura que inclui um único farm e um único grupo de aplicativos de serviço, o grupo de aplicativos de serviço padrão é usado para todos os aplicativos Web no farm. Todos os sites têm acesso a todos os aplicativos de serviço implantados no farm.
78
Vantagens
Essa arquitetura oferece as seguintes vantagens:
Essa é a arquitetura mais simples a ser implantada.
Todos os aplicativos de serviço estão disponíveis para todos os aplicativos Web.
Os recursos do farm são usados com mais eficiência.
Todos os aplicativos de serviço são gerenciados de forma central.
Desvantagens
Existem várias desvantagens a serem consideradas para esta arquitetura:
79
Não é possível isolar dados de aplicativo de serviço.
Os departamentos ou equipes individuais não podem gerenciar aplicativos de
serviço por conta própria.
Recomendações
A arquitetura que inclui um único farm e um único grupo de aplicativos de serviço é a configuração recomendada para a maioria das organizações, pelo menos inicialmente. Essa configuração funciona bem quando você deseja hospedar vários sites para uma única empresa no mesmo farm.
Use esta configuração para cumprir as seguintes metas:
Você desejar otimizar os recursos exigidos para a execução de aplicativos de
serviço em um farm.
Você está compartilhando dados de conteúdo e de perfil entre sites que, caso
contrário, exigem isolamento de processo por motivo de desempenho ou segurança.
Farm único, vários grupos de aplicativos de serviço Se as equipes exige aplicativos de serviço dedicados, crie uma arquitetura usando um ou mais grupos personalizados de aplicativos de serviço. Siga estas diretrizes:
Implante aplicativos de serviço específicos para uso dedicado por uma ou mais
equipes em uma organização.
Verifique se os aplicativos de serviço dedicados também não foram incluídos no
grupo padrão.
Crie um ou mais aplicativos Web que usem um grupo personalizado de aplicativos
de serviço. O administrador do SharePoint selecione os aplicativos de serviço
incluídos no grupo personalizado.
No diagrama a seguir, o Farm B mostra uma arquitetura de exemplo com dois grupos de aplicativos de serviço. Neste exemplo, a equipe de Finanças exige um aplicativo dos Serviços do Excel dedicado. Os Serviços do Access também serão implantados para essa equipe.
80
Você pode criar mais de um grupo de aplicativos de serviço dedicados. No diagrama a seguir, dois grupos personalizados são criados no Farm C. Criando a partir da arquitetura do Farm B, aplicativos de serviço de Dados Gerenciados e Conectividade de Dados Corporativos dedicados são implantados no farm para serem usados pelo departamento de RH. Isso resulta em um segundo grupo de aplicativos de serviço personalizado, além do primeiro grupo de aplicativos de serviço dedicado criado para a equipe de Finanças.
81
Os aplicativos de serviço implantados para uso dedicado podem compartilhar o mesmo pool de aplicativos ou ser implantados em um pool de aplicativos separado para isolamento adicional. O design do Farm B (dois diagramas atrás) obtém o isolamento de
82
processo para aplicativos de serviço implantados para a equipe de Finanças ao colocar esses aplicativos de serviço em um pool de aplicativos dedicado. Para o Farm C, mostrado no diagrama anterior, um pool de aplicativos é usado para todos os aplicativos de serviço; nessa arquitetura, os aplicativos de serviço são implantados para otimizar o desempenho.
Conectando a vários aplicativos de serviço de Metadados Gerenciados
Um grupo de aplicativos de serviço pode incluir vários aplicativos de serviço de Metadados Gerenciados. Por exemplo, no diagrama do Farm C, o grupo personalizado realçado em verde inclui dois aplicativos de serviço de Metadados Gerenciados.
Neste cenário, os sites nos aplicativos Web exibem taxonomia, marcação social e outros recursos de ambos os aplicativos de serviço de Metadados Gerenciados. Ao contrário de outros serviços entre farms, as Web Parts incluem dados de vários aplicativos de serviço de Metadados Gerenciados por padrão.
Para obter mais informações sobre como gerenciar vários aplicativos de serviço de Metadados Gerenciados, consulte Managed metadata service application overview (SharePoint Server 2010).
Vantagens
As arquiteturas que incluem vários grupos de aplicativos de serviço oferecem as seguintes vantagens:
Elas acomodam várias metas organizacionais no mesmo farm.
Os dados de serviço podem ser isolados.
Equipes ou departamentos individuais podem gerenciar os aplicativos de serviço
dedicados para sua utilização.
Os sites podem ser configurados para usar um subconjunto de aplicativos de
serviço.
Desvantagens
As desvantagens das arquiteturas que usam mais de um grupo de aplicativos de serviço incluem o seguinte:
Elas têm a configuração e o gerenciamento mais complexos.
Os recursos do farm são consumidos para oferecer suporte a várias instâncias dos
mesmos aplicativos de serviço, o que pode afetar o desempenho.
Recomendações
As arquiteturas que incluem vários grupos de aplicativos de serviço funcionam bem para empresas com divisões ou equipes que exigem aplicativos de serviço dedicados ou dados de serviço isolados, ou para sites que são configurados com um escopo mais restrito, como a colaboração de parceiros.
Adicionalmente, quando vários grupos de aplicativos de serviço são configurados, equipes e sites podem consumir serviços oferecidos em toda a extensão da empresa, como serviços de perfil e de pesquisa, ao mesmo tempo que o uso de serviços direcionados é isolado por motivo de segurança ou de desempenho.
Os aplicativos de serviço geralmente implantados para uso dedicado de uma equipe ou departamento específico incluem:
83
Serviços do Excel Para otimizar o desempenho para uma determinada equipe ou
para isolar dados confidenciais.
Metadados Gerenciados Para permitir que uma equipe ou departamento gerencie
sua própria taxonomia, hierarquias, palavras-chave e assim por diante. O SharePoint
Server 2010 combina os resultados de vários aplicativos de serviço de Metadados
Gerenciados para que taxonomias, tipos de conteúdo e outros elementos possam
ser compartilhados em uma organização.
Conectividade de Dados Corporativos Equipes ou departamentos individuais
podem integrar seus próprios sistemas de linha de negócios e manter os dados
isolados do resto da organização.
Em alguns casos, um grupo de aplicativos de serviço dedicado é configurado para restringir a lista de serviços usados por um aplicativo Web. Por exemplo, um site de colaboração de parceiro pode ser configurado para consumir um subconjunto dos aplicativos de serviço oferecidos pelo farm.
Farms de serviços corporativos Um farm de serviços corporativos é um farm de servidores dedicado à hospedagem de aplicativos de serviço para uma organização. O diagrama a seguir mostra um farm de serviços corporativos que hospeda os aplicativos de serviço entre farms implantados com mais frequência. Mostra também vários tipos comuns de farms que consomem serviços de um farm de serviços corporativos.
84
O restante desta seção descreve os outros farms do diagrama. O Farm 2, o Farm 3 e o Farm 4 representam os tipos de farms com mais probabilidade de consumir serviços de um farm de serviços corporativos.
85
Farms de conteúdo publicado (todos os aplicativos de serviço são remotos)
Você pode implantar um farm de servidores sem implantar qualquer aplicativo de serviço localmente. No Farm 2, nenhum aplicativo de serviço é hospedado localmente. Todos os aplicativos de serviço são consumidos de um farm separado.
Essa configuração funciona bem para o conteúdo publicado. Reduz os esforços administrativos necessários para hospedar um farm de conteúdo publicado e permite que uma organização aproveite as vantagens dos aplicativos de serviço gerenciados de forma centralizada.
Use essa configuração quando tiver as seguintes metas:
Você deseja otimizar os recursos de um farm para a hospedagem de conteúdo em
vez da execução de aplicativos de serviço.
Você está integrando com perfis, metadados, pesquisa e outros recursos
gerenciados de forma centralizada de toda a organização.
Farms de colaboração (mistura de aplicativos de serviço locais e remotos)
O Farm 3 representa um farm otimizado para colaboração. Todos os aplicativos de serviço que não podem ser compartilhados entre farms são hospedados localmente. Entre eles, podemos incluir os aplicativos de serviço relacionados a cliente, que são importantes para a colaboração. Os aplicativos de serviço entre farms são consumidos de um farm de serviços corporativos (Farm 1).
Os farms podem consumir de um ou mais farms remotos. No diagrama, o Farm 3 também consome o serviço de Metadados Gerenciados de um farm de departamento especializado (Farm 4) para integrar-se com a taxonomia, marcação social e outros recursos gerenciados de forma autônoma desse departamento.
Se houver vários aplicativos de serviço de Metadados Gerenciados, um dos aplicativos de serviço deverá ser designado como o aplicativo de serviço principal que hospedará a taxonomia corporativa. Todas as outras instâncias desse aplicativo de serviço serão secundárias e fornecerão dados adicionais aos dados do aplicativo de serviço primário. Ao contrário de outros serviços entre farms, as Web Parts incluem dados de vários aplicativos de serviço de Metadados Gerenciados por padrão.
Essa é a configuração recomendada para empresas que hospedam vários farms para atender às suas necessidades de negócios. Use-a para cumprir as seguintes metas:
Otimizar recursos administrativos e de farm no nível empresarial para hospedagem
de serviços (Farm 1).
Otimizar recursos no nível do farm para hospedagem de sites de colaboração (Farm
3).
Integrar com perfis, metadados, pesquisa e outros recursos gerenciados de forma
centralizada em toda a organização.
Integrar com metadados produzidos por uma equipe ou departamento especializado
(Farm 4).
Farms para departamentos especializados (mistura de aplicativos de serviço locais e remotos)
Algumas equipes de uma organização podem exigir uma implantação separada de serviços específicos pelos seguintes motivos:
86
Para garantir o isolamento de dados (como dados de Conectividade de Dados
Corporativos).
Para oferecer a capacidade de gerenciar de forma autônoma aplicativos de serviço
(como Metadados Gerenciados).
O Farm 4 oferece um exemplo. As características desse farm incluem o seguinte:
Ele consome aplicativos de serviço gerenciados de forma centralizada que incluem
Metadados Gerenciados.
Também inclui seu próprio aplicativo de serviço de Metadados Gerenciados de
forma que essa equipe possa gerenciar de forma autônoma seus próprios
metadados. Como esse aplicativo de serviço é compartilhado, os metadados do
resto da organização podem ser integrados a esses metadados.
Use esta configuração para cumprir as seguintes metas:
Permitir que uma equipe ou departamento especializado gerencie metadados por
conta própria.
Garantir que dados de serviço específicos sejam isolados e gerenciados
separadamente do resto da organização.
Farms de serviços especializados Considere a implantação de farms de serviço especializados para otimizar recursos de farm para aplicativos de serviço específicos. Isso permite que você aumente o farm de servidores e melhore o hardware para otimizar o desempenho para um aplicativo de serviço específico.
O aplicativo de serviço principal que pode garantir um farm de serviços dedicado é Pesquisa. Pesquisa tem requisitos de desempenho e capacidade exclusivos. Ao descarregar o aplicativo de serviço de Pesquisa em um farm dedicado, os recursos poderão ser otimizados para o restante dos aplicativos de serviço entre farms.
O diagrama a seguir mostra dois farms de serviços centralizados. Um farm está otimizado para Pesquisa. O outro farm hospeda todos os outros aplicativos de serviço entre farms.
87
Farms entre organizações Os aplicativos de serviço podem ser compartilhados entre quaisquer farms, e não somente entre farms de serviços corporativos. Considere o compartilhamento de aplicativos de serviço entre farms nos cenários a seguir.
Cenário A: para oferecer aplicativos de serviço em toda a empresa sem um farm de serviços corporativos dedicado, como mostrado no diagrama a seguir.
Cenário B: para compartilhar recursos entre farms e para impedir a implantação de aplicativos de serviço redundantes, como mostrado no diagrama a seguir.
88
89
Componentes de arquitetura lógica (SharePoint Server 2010)
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 um aplicativo 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
90
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.
91
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 Pools de aplicativos 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
92
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.
93
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
94
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 Zonas 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.
95
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
96
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
97
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
98
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:
A diretiva pode ser aplicada em todas
as zonas ou em uma zona.
Você pode inserir nomes de usuário,
nomes de grupos ou endereços de
email.
Especificar as permissões que deseja
aplicar à diretiva
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:
Nenhuma: nenhuma diretiva
Negar gravação: nenhum acesso a
gravação
Negar tudo: nenhum acesso
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.
99
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.
100
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.
101
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.
102
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:
Site Pessoal (100 MB)
Sites de Equipe (2.000 MB)
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
103
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 Conjuntos de sites nomeados pelo host 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.
104
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.
105
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.
106
Exemplo de design: implantação corporativa (SharePoint Server 2010)
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: Portal corporativo com autenticação clássica
Exemplo de design: Portal corporativo com autenticação baseada em declarações
Para baixar qualquer um desses modelos, consulte o artigo sobre Exemplos de design do SharePoint Server 2010: Portal corporativo com autenticação clássica ou com autenticação baseada em declarações (http://go.microsoft.com/fwlink/?linkid=196872&clcid=0x416).
Neste artigo:
Sobre os exemplos de design
Metas globais de design
Farms de servidores
Usuários, zonas e autenticação
Serviços
Alternativas de autoria e publicação
Sites de administração
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 ilustram uma implantação corporativa genérica do Microsoft SharePoint Server 2010. Eles se aplicam a quase todos os componentes de arquitetura lógica e ilustram 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 Microsoft Office SharePoint Server 2007 para o Microsoft
SharePoint Server 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 de formulários, com o objetivo de coletar
credenciais do Windows que são encaminhadas para o SharePoint Server 2010.
São adicionadas ao diretório corporativo contas de funcionários parceiros.
107
Autenticação de declarações: esse exemplo de design incorpora o novo modelo de
autenticação de 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 ilustram uma implantação corporativa para uma empresa fictícia denominada Fabrikam, Inc. Essa implantação inclui dois farms de servidor. Um deles hospeda a intranet da empresa e o site do parceiro, e o outro hospeda o site da empresa (www.fabrikam.com). O restante desta seção descreve esses sites nível superior.
Intranet
A intranet corporativa inclui os seguintes sites:
Conteúdo publicado da intranet (como HRweb)
Sites de equipes colaborativos
Meus Sites
Juntos, estes são os sites de conteúdo e de colaboração que os funcionários usarão todos os dias. Individualmente, cada um desses aplicativos representa um tipo distinto de conteúdo. Cada tipo de conteúdo:
Enfatiza recursos diferentes do SharePoint Server 2010.
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 de cada um desses aplicativos destinam-se a otimizar o desempenho e a segurança.
O design de aplicativos de serviço reúne esses três aplicativos para fornecer:
Navegação entre os aplicativos
Pesquisa no âmbito da empresa
Metadados empresariais e dados de perfis compartilhados
O diagrama a seguir ilustra os três aplicativos que formam a intranet corporativa.
108
As URLs nessa ilustração referem-se ao exemplo de design de autenticação clássica.
Aplicativo Web do 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.
No exemplo de design, o aplicativo Web do parceiro é hospedado pelo mesmo farm que hospeda o conteúdo da intranet.
Site da empresa na Internet
O site da empresa na Internet é a presença da empresa na Internet. O conteúdo é disponibilizado para clientes por meio da configuração do acesso anônimo com permissões somente leitura. Os principais fatores que determinam as opções de design desse aplicativo são:
Isolamento de conteúdo: os clientes não podem acessar nenhum outro tipo de
conteúdo hospedado no farm de servidores.
Gerenciamento direcionado: o acesso autorizado é fornecido a funcionários que
gerenciam o site por meio da execução de tarefas administrativas e de autoria.
Autoria e publicação de conteúdo seguro: um conjunto de sites separado é
hospedado no Farm A, no aplicativo Web do parceiro, para autoria. Isso permite a
colaboração segura e o desenvolvimento de conteúdo com funcionários internos e
remotos e também com parceiros editoriais especializados no desenvolvimento de
sites ou na autoria de conteúdo. A publicação de conteúdo é configurada de forma a
publicar automaticamente o conteúdo do conjunto de sites de autoria do primeiro
farm no conjunto de sites de produção do segundo farm. O diagrama a seguir ilustra
o processo de publicação.
109
Metas globais de design O exemplo de design fornece implementações práticas de recursos do SharePoint Server 2010 em vários tipos comuns de aplicativos. As implementações de design para cada um dos aplicativos individuais são abordadas neste artigo. As principais metas do exemplo de design incluem:
Usar a quantidade mínima de farms de servidores para hospedar os tipos mais
comuns de sites geralmente exigidos por uma empresa; ou seja, sites de intranet,
extranet e da Internet.
Criar uma estrutura para projetar um ambiente que possa se expandir. Decisões de
design para aplicativos individuais não impedem o acréscimo de outros aplicativos.
Por exemplo, uma implantação inicial pode incluir somente sites de equipes de
colaboração ou apenas os três aplicativos que compõem uma intranet (sites de
equipes, Meus Sites e conteúdo de intranet publicado). Usando um design de
arquitetura lógica semelhante, você pode adicionar aplicativos à solução sem afetar
o design dos aplicativos iniciais. Em outras palavras, o design não incorpora opções
de design que limitam o uso do ambiente.
Fornecer acesso a diversos grupos de usuários sem comprometer a segurança do
conteúdo nos diferentes tipos de sites. 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
110
internos. Entretanto, com o uso de um design similar, você cria a oportunidade de
também permitir acesso a funcionários remotos, funcionários parceiros, empresas
parceiras e 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.
O restante deste artigo discute cada componente lógico que aparece no exemplo de design (de cima para baixo), bem como as opções de design que são aplicadas ao exemplo de design. A finalidade dessa abordagem é demonstrar as diferentes maneiras de se configurar componentes da arquitetura lógica com base no aplicativo.
Farms de servidores O exemplo de design incorpora o uso de dois farms de servidores. Esta seção descreve os requisitos de licenciamento que afetam o número de farms de servidores necessários em um ambiente corporativo e observa as topologias dos farms de servidor que são ilustradas no exemplo de design.
Requisitos de licenciamento
Para hospedar conteúdo de intranet e sites da Internet, são necessários pelo menos dois servidores para atender aos requisitos de licenciamento.
As duas licenças de servidor a seguir estão disponíveis para o SharePoint Server 2010:
Microsoft SharePoint Server 2010, licença de Servidor: esta é a licença
apropriada para conteúdo de intranet colaborativo, exigindo o uso de CALs
(Licenças de Acesso para Cliente). Se forem criados sites para colaboração de
parceiros, será preciso garantir a aquisição do número necessário de CALs para
funcionários parceiros.
Microsoft SharePoint Server 2010 for Internet sites: esta licença destina-se
somente a sites voltados para a Internet, não exigindo o uso de CALs. Se você criar
sites para colaboração de parceiros, não precisará adquirir outras CALs. Entretanto,
não será possível criar sites destinados exclusivamente para uso por parte dos seus
funcionários.
Observação:
Essas licenças não podem ser combinadas no mesmo computador servidor, nem no
mesmo farm de servidores.
Considerando-se as opções de licenciamento, a decisão de design mais crítica é determinar qual farm hospedará o aplicativo Web do parceiro. No exemplo de design, o primeiro farm hospeda o conteúdo da intranet, e o segundo hospeda o site da empresa na Internet. De acordo com as condições de licenciamento, qualquer um dos farms pode hospedar o aplicativo Web do parceiro.
Com uma opção dos dois farms, a diretriz de design geral para determinar qual farm deve hospedar o aplicativo Web do parceiro inclui:
Natureza da colaboração: se a principal finalidade de um site de extranet de
parceiro for comunicar informações com segurança para vários parceiros, um farm
111
de servidores da Internet será a opção mais econômica. Por outro lado, se a
principal finalidade for trabalhar de modo colaborativo com um pequeno número de
funcionários parceiros, um farm de servidores de intranet talvez seja uma escolha
melhor. Escolha a opção com a qual você poderá otimizar seu farm de acordo com a
função planejada.
Número de funcionários parceiros: se você colabora com muitos funcionários
parceiros e considera importante reduzir os custos, é possível hospedar com
segurança o conteúdo anônimo e colaborativo em um farm da Internet usando a
licença de sites da Internet.
No exemplo de design, o aplicativo Web do parceiro destina-se à colaboração intensa com empresas parceiras, incluindo o desenvolvimento e a preparação do site da Internet da empresa. Colocar o aplicativo Web do parceiro no primeiro farm permite que a organização otimize cada um dos dois farms para o uso pretendido de cada um (conteúdo de colaboração versus conteúdo somente leitura). Porém, qualquer um dos farms pode hospedar o aplicativo Web do parceiro.
O exemplo de design inclui o Microsoft Office Web Apps. O Office Web Apps exige uma licença de cliente do Microsoft Office 2010. Em outras palavras, se você disponibilizar o Office Web Apps para os parceiros, também deverá adquirir licenças de cliente do Office 2010 para eles.
Topologia dos farms de servidores
Cada farm de servidores no exemplo de design é composto por cinco servidores com esta topologia:
Dois servidores Web front-end
Um servidor de aplicativos
Dois servidores de banco de dados, clusterizados ou espelhados
O exemplo de design ilustra a arquitetura lógica do SharePoint Server 2010, mostrando que:
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 Performance and capacity management (SharePoint Server 2010).
Dimensionamento além de dois farms
Sua empresa pode precisar de mais do que os dois farms representados. Os sites que são candidatos a farm dedicado incluem:
Meus Sites: muitas organizações com grandes quantidades de funcionários ou
alunos optam por hospedar Meus Sites em um farm de servidores dedicado.
Autoria e preparação de sites: se o conteúdo publicado for complexo ou extenso, o
processo de autoria e preparação pode ser melhor otimizado com a hospedagem
112
desses sites em um farm de servidor único dedicado, usando uma licença do
Microsoft SharePoint Server 2010 for Internet Sites. Por exemplo, a publicação de
um conteúdo que inclui metadados marcados aumenta a complexidade do exemplo
de design de serviços entre o farm de autoria e o farm publicado, incluindo o
compartilhamento do serviço entre os farms e a tomada de decisões sobre como
esse serviço pode ser compartilhado em outros tipos de aplicativos Web em um farm
multiuso.
Sites do parceiro: exigências de segurança e isolamento podem justificar um farm
dedicado para colaboração de parceiros. Isto cria um isolamento físico entre o
conteúdo exclusivamente interno e o conteúdo desenvolvido em colaboração com
parceiros externos.
Usuários, zonas e autenticação Ao criar um aplicativo Web no SharePoint Server 2010, é preciso escolher 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 Server 2010. A tabela abaixo resume as duas abordagens.
Tipo de autenticação Descrição Recomendações
Autenticação clássica As contas de usuário são tratadas
pelo SharePoint Server 2010 como contas tradicionais do Windows Active Directory. 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 Microsoft Office SharePoint Server 2007, nos
quais não é
exigida a
autenticação
baseada em formulários.
Você não
precisará
executar a migração de
usuários se
estiver atualizando e selecionar a autenticação no
modo clássico.
Autenticação baseada em
declarações
As contas de usuário são tratadas
pelo SharePoint Server 2010 como
identidades de declarações.
A autenticação
baseada em
declarações é
113
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.
recomendada para novas
implantações do
SharePoint Server 2010. Ela
é necessária
para atualizar
soluções do
Office SharePoint Server 2007 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 assimilada na versão anterior. Por esse motivo, esse exemplo fornece um roteiro de atualização do Office SharePoint Server 2007 para o SharePoint Server 2010.
A única limitação é que a autenticação baseada em formulários não tem suporte no modo clássico. Ao se usar a autenticação no modo clássico, todas as contas autenticadas devem residir no AD DS (Serviços de Domínio Active Directory). 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 ilustra quatro classes diferentes 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.
114
A conta de rastreamento de pesquisa exige acesso a pelo menos uma zona usando autenticação NTLM. Se nenhuma das zonas de usuários for configurada para usar a autenticação NTLM, configure a zona personalizada para usar essa autenticação.
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 Server 2010 e é necessária para atualizar as soluções do Office SharePoint Server 2007 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 o Windows Live ID, os Serviços de Federação Active Directory 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.
115
No exemplo de design, o site de conteúdo de intranet publicado, os sites de equipes e Meus Sites só podem ser acessados por funcionários, estejam eles dentro ou fora da rede. O exemplo de design implementa apenas uma URL (via SSL), que pode ser usada interna e externamente. São usadas contas do Active Directory. 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 pode ser acessado por 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 com 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 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 (http://go.microsoft.com/fwlink/?linkid=196776&clcid=0x416).
116
No exemplo de design com autenticação baseada em declarações, o farm publicado está configurado para usar a autenticação no modo clássico. Uma alternativa é usar a autenticação baseada em declarações também para o farm publicado, além de implementar uma zona separada para usuários anônimos. O elemento importante do design é o uso de uma zona separada para usuários anônimos, de forma a criar isolamento entre o ambiente somente leitura e o ambiente de leitura-gravação, independentemente de qual modo de autenticação esteja implementado. A tabela abaixo mostra as zonas, os usuários e o tipo de autenticação ilustrados para o farm publicado.
Mais uma vez, a conta de rastreamento de pesquisa requer acesso a pelo menos uma zona usando a autenticação NTLM, que por sua vez pode ser adicionada a uma zona de autenticação por declarações, se necessário. No modo clássico, se nenhuma das zonas de usuários for configurada para usar a autenticação NTLM, configure a zona personalizada para usar essa autenticação.
Zonas
Quando você cria zonas, várias decisões são essenciais para o sucesso da implantação. Elas 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 incorporadas no exemplo de design.
Requisitos de configuração da zona Padrão
A zona que merece a maior consideração é a zona Padrão. O SharePoint Server 2010 impõe 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 a partir da 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 email e alerta
devem poder acessar os links através da zona Padrão. Isso é especialmente
importante para proprietários de sites.
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.
117
Configurando zonas para um ambiente de extranet
Em um ambiente de extranet, o design de zonas é crítico pelos seguintes motivos:
As solicitações de usuários podem ser iniciadas em várias redes diferentes. No
exemplo de design, os usuários iniciam solicitações na rede interna, na Internet e em
empresas parceiras.
Os usuários consomem o conteúdo em vários aplicativos Web. No exemplo de
design, a intranet é composta de três aplicativos Web diferentes. Além disso, os
funcionários internos e remotos têm a possibilidade de contribuir e administrar o
conteúdo em todos os aplicativos Web: intranet, o site do parceiro e o site da
empresa na Internet.
Em um ambiente de extranet, verifique se os seguintes princípios de design estão sendo observados:
Configure zonas entre vários aplicativos Web de forma que elas sejam espelhos uma
das outras. A configuração da autenticação e os usuários planejados devem ser
idênticos. No entanto, as políticas associadas a zonas podem ser diferentes entre os
aplicativos Web. Por exemplo, certifique-se de que a zona da Internet seja usada
para os mesmos funcionários em 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 aplicativo Web.
Configure mapeamentos de acesso alternativos de maneira apropriada e precisa
para cada zona e cada recurso. Mapeamentos de acesso alternativos são criados
automaticamente na ocasião em que a zona é criada. Entretanto, o SharePoint
Server 2010 pode ser configurado para rastrear conteúdo em recursos externos,
como em um compartilhamento de arquivos. Links para esses recursos externos
devem ser criados manualmente para cada zona com o uso de mapeamentos de
acesso alternativos.
Se as zonas nos aplicativos Web não se espelharem, e os links para recursos externos não forem adequados, os riscos serão os seguintes:
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.
Serviços A arquitetura de serviços ilustrada mostra a opção mais complexa para implantar serviços nos três diferentes tipos de sites: intranet, site do parceiro e site da empresa na Internet. Serviços dedicados e particionados são implantados para o site do parceiro. Uma instância separada do aplicativo de serviço de Metadados Gerenciados é implantada para uso exclusivo do conjunto de sites de autoria e do site publicado na Internet.
Uma alternativa muito mais simples é implantar um conjunto de aplicativos de serviço e compartilhar cada serviço, conforme necessário, entre os sites. Essa arquitetura depende da filtragem de segurança para mostrar somente o conteúdo ao qual os usuários possuem acesso. O diagrama abaixo ilustra essa abordagem mais simples.
118
A principal decisão de design para implantar aplicativos de serviço é o quanto deve ser expandida a taxonomia organizacional. A arquitetura de serviços pode ser simplificada pelo compartilhamento de metadados gerenciados, do perfil de usuários e da pesquisa em todos os aplicativos Web e pela utilização da filtragem de segurança para gerenciar o acesso ao conteúdo. Na arquitetura simplificada descrita neste artigo, uma instância do serviço de Metadados Gerenciados é compartilhada em todos os sites. Contudo, com essa configuração, todos os usuários têm acesso à taxonomia corporativa. Os arquitetos de soluções devem decidir se serão ou não implementadas várias instâncias do serviço de Metadados Gerenciados. Eles também precisarão decidir em que medida compartilhar os dados de Perfil de Usuários.
Site do parceiro
Para o site do parceiro (grupo personalizado no Farm 1), os serviços mínimos indicados pelo exemplo de design são Pesquisa e Metadados Gerenciados. Se você adicionar o Office Web Apps ao grupo de serviços usados pelo site do parceiro, certifique-se de ter as licenças corretas para todos os usuários desse site, inclusive os parceiros. O aplicativo de serviço de Perfil de Usuários não é incluído pelo exemplo de design, para impedir que os usuários parceiros pesquisem dados pessoais na organização.
Na arquitetura simplificada, os parceiros têm acesso a toda a taxonomia corporativa e podem pesquisar dados pessoais na organização. Contudo, a pesquisa limita os resultados aos sites e ao conteúdo aos quais esses parceiros têm acesso.
Se os seus sites de parceiro exigem isolamento de conteúdo entre projetos, a implantação de aplicativos de serviço dedicados e particionados é uma boa escolha, conforme ilustrado no exemplo de design. Isso aumenta a complexidade da arquitetura de serviços, mas garante que os parceiros não tenham acesso a metadados associados ao conteúdo da Intranet ou mesmo a outros projetos dentro do site do parceiro.
119
Site da empresa na Internet
Na arquitetura de design simplificada, o aplicativo de serviços corporativos de Metadados Gerenciados também é compartilhado com o site publicado na Internet. No exemplo de design, é implantada uma instância dedicada do aplicativo de serviços de Metadados Gerenciados no farm de colaboração para uso exclusivo por parte do conjunto de sites de autoria e do farm publicado.
Se o farm publicado for anônimo e somente leitura, não haverá risco de se expor metadados gerenciados não associados ao conteúdo publicado. Os usuários anônimos têm acesso somente ao conteúdo publicado e não podem enviar classificações nem criar outros tipos de metadados.
O compartilhamento do aplicativo de serviços de Metadados Gerenciados na organização (conforme ilustrado na arquitetura simplificada deste artigo) permite que os autores utilizem a taxonomia corporativa. Por outro lado, implantar uma instância dedicada do serviço para autoria e publicação (conforme ilustrado no exemplo de design) garante o isolamento dos metadados gerenciados.
Uma instância dedicada do aplicativo de serviço de Pesquisa é implantada no farm que hospeda o site da empresa na Internet. Esta é a configuração recomendada para um site publicado na Internet.
Alternativas de autoria e publicação No site da empresa na Internet, o exemplo de design ilustra um processo de publicação que inclui o uso do recurso de implantação de conteúdo para mover o conteúdo de um conjunto de sites de autoria para o farm de publicação. Uma alternativa mais simples a essa abordagem é criar diretamente no farm de publicação. Esse processo costuma ser chamado de autoria em produção.
A autoria no ambiente de produção simplifica consideravelmente a solução, consolidando os serviços em um farm e dispensando a necessidade de se implantar conteúdo. O exemplo de design inclui as zonas adicionais que podem ser usadas pelos autores para trabalhar com segurança sem prejudicar os usuários anônimos. Lembre-se de bloquear o acesso anônimo de entrada na porta associada às zonas usadas pelos autores. Se o seu site apresentar menos de 500 gravações por hora de atividade de autoria, é improvável que o desempenho do site publicado seja prejudicado durante o processo de autoria no ambiente de produção.
O SharePoint Server 2010 inclui recursos de publicação que podem ser usados neste cenário para garantir que o conteúdo não fique exposto aos usuários anônimos até que esteja pronto. Para obter mais informações, consulte os seguintes artigos:
Agendamento das datas de início e término para uma página publicada
(http://go.microsoft.com/fwlink/?linkid=196777&clcid=0x416)
Aprovação ou rejeição de um envio pendente
(http://go.microsoft.com/fwlink/?linkid=196778&clcid=0x416)
Definição de permissões para publicação
(http://go.microsoft.com/fwlink/?linkid=196779&clcid=0x416)
120
Sites de administração No exemplo de design, o site da Administração Central de cada farm de servidores é hospedado em um 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.
As URLs com carga balanceada para sites de administração não são mencionadas no exemplo de design ou neste artigo. As recomendações incluem:
Se números de porta forem usados em URLs administrativas, use portas não
padrão. 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.
Além dessas recomendações, você tem a opção de balancear a carga do site da Administração Central em vários servidores de aplicativos para obter redundância.
Pools de aplicativos Pools de aplicativos do IIS (Serviços de Informações da Internet) separados geralmente são implementados para se obter isolamento de processo entre conteúdos. Pools de aplicativos fornecem uma maneira para que vários sites sejam executados no mesmo computador servidor, mas ainda mantenham seus próprios processos de trabalho e identidade. Isso reduz a exploração em um site que fornece uma oportunidade para que um invasor introduza código no servidor para atacar outros sites.
Em termos práticos, considere o uso de um pool de aplicativos dedicado para cada um destes cenários:
Para separar o conteúdo autenticado do conteúdo anônimo.
Para isolar aplicativos que armazenam senhas e interagem com aplicativos
empresariais externos (embora o Serviço de Repositório Seguro possa ser usado
para essa finalidade).
Para isolar aplicativos nos quais os usuários tenham grande liberdade para criar e
administrar sites e colaborar no conteúdo.
O exemplo de design usa pools de aplicativos da seguinte maneira:
Cada site de administração é hospedado em um pool de aplicativos dedicado. Este é
um requisito dos Produtos do SharePoint 2010.
O conteúdo de intranet é dividido em dois pools de aplicativos diferentes. O
conteúdo colaborativo (Meus Sites e sites de equipes) é hospedado em um pool de
aplicativos. O conteúdo de intranet publicado é hospedado em um pool de
aplicativos separado. Essa configuração fornece isolamento de processos para o
conteúdo de intranet publicado, no qual o uso de conexões de dados empresariais é
mais provável.
O aplicativo Web do parceiro é hospedado em um pool de aplicativos dedicado.
O site da empresa na Internet é hospedado em um pool de aplicativos dedicado no
segundo farm. Se esse farm também tiver que hospedar conteúdo para colaboração
121
de parceiro, esses dois tipos de conteúdo (Internet e parceiro) serão hospedados em
dois pools de aplicativos diferentes.
Aplicativos Web Um aplicativo Web é um site do IIS criado e usado pelos Produtos do SharePoint 2010. Cada aplicativo Web é representado por um site diferente no IIS.
Em termos gerais, use aplicativos Web dedicados para:
Separar o conteúdo anônimo do conteúdo autenticado. No exemplo de design, o
site da empresa na Internet fica hospedado em um aplicativo Web dedicado e em
um pool de aplicativos.
Isolar usuários. No exemplo de design, o site 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 da intranet.
Impor permissões. Um aplicativo Web dedicado fornece a oportunidade de impor
permissões por meio de políticas, usando a página Política para Aplicativo Web na
Administração Central. 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 em documentos individuais no aplicativo Web.
Otimizar o desempenho. Os aplicativos 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 de Meus Sites incluem
um grande número de sites pequenos. Em contraste, 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 por dados com características similares, otimizando assim seu
desempenho. No exemplo de design, Meus Sites e sites de equipe não têm
requisitos exclusivos de isolamento de dados: eles compartilham o mesmo pool de
aplicativos. Entretanto, Meus Sites e sites de equipe 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 do conteúdo de Meus Sites se este não for o tipo mais essencial de
conteúdo da sua organização. Isso permite restaurar o conteúdo mais crítico antes
da restauração do conteúdo de Meus Sites. No exemplo de design, Meus Sites
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 exemplo de design, são atender aos requisitos para o design de URLs e criar divisões lógicas de conteúdo.
122
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", mais adiante neste artigo. Além da segunda camada de conjuntos de sites, cada site é um subsite.
O diagrama a seguir ilustra a hierarquia de 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 exemplo de design incorpora opções baseadas na natureza do aplicativo.
Conteúdo de intranet publicado
A suposição para o aplicativo Web de conteúdo de intranet publicado é que várias divisões na empresa hospedarão o conteúdo publicado. No exemplo de design, o conteúdo de cada divisão fica hospedado em um conjunto de sites separado. Isso proporciona as seguintes vantagens:
Cada divisão pode gerenciar e conceder permissão para o respectivo conteúdo de
maneira independente.
O conteúdo de cada divisão pode ser armazenado em um banco de dados dedicado.
As desvantagens de se usar vários conjuntos de site incluem:
Não é possível compartilhar páginas mestras, layouts de página, modelos, Web
Parts e a navegação entre conjuntos de sites.
É necessário mais esforço para coordenar as personalizações e a navegação entre
conjuntos de sites.
Dependendo da arquitetura de informações e do design do aplicativo de intranet, o conteúdo publicado pode ser exibido ao usuário como um único aplicativo. De modo alternativo, cada conjunto de sites pode ser exibido como um site separado.
Meus Sites
Meus Sites têm características distintas, e as recomendações para a implantação desse recurso são objetivas. No exemplo de design, o aplicativo Meu Site incorpora um site de nível superior com a URL de http://my. O primeiro conjunto de sites de nível superior que é criado usa o modelo Host de Meu Site. 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 Host de Meu Site. O nome de usuário é anexado à URL no formato http://my personal/nomedeusuário. A seguinte ilustração mostra Meus Sites.
123
Sites de equipe
Você pode usar qualquer uma das seguintes abordagens para projetar conjuntos de sites em um aplicativo de Site de Equipe:
Permitir que as equipes criem conjuntos de sites por meio da criação de sites
pessoais. A vantagem dessa abordagem é que as equipes podem criar facilmente
um site, conforme necessário, sem a assistência de um administrador. Porem,
abordagem apresenta várias desvantagens, entre elas:
Não é possível implementar uma taxonomia ponderada.
O aplicativo pode ficar difícil de gerenciar.
Sites são facilmente abandonados.
Não é possível compartilhar modelos e navegação entre projetos ou equipes
que, de outra forma, poderiam compartilhar um conjunto de sites.
Criar um número específico de conjuntos de sites para a sua organização com base
no seu modo de operação. Nessa abordagem, conjuntos de sites são criados pelo
administrador do SharePoint. 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 exemplo de design incorpora a segunda abordagem, o que resulta em uma hierarquia similar de conjunto de sites para os sites de equipe no que se refere ao conteúdo de intranet publicado. 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 mostra sugestões para vários tipos de organizações.
Tipo de organização Taxonomias sugeridas de conjunto de sites
Implantação de produtos Crie um conjunto de sites para cada
produto em desenvolvimento. Permita
que as equipes de contribuição criem
sites no conjunto de sites.
Para cada projeto de desenvolvimento
em longo prazo, crie um conjunto de
sites para cada equipe extensa que
contribua no produto. Por exemplo, crie
um conjunto de sites para cada uma
destas equipes: designers, engenheiros
e desenvolvedores de conteúdo.
Pesquisa Crie um conjunto de sites para cada
projeto de pesquisa em longo prazo.
Crie um conjunto de sites para cada
categoria de projetos de pesquisa.
124
Tipo de organização Taxonomias sugeridas de conjunto de sites
Instituição de ensino superior Crie um conjunto de sites para cada
departamento acadêmico.
Escritório legislativo estadual Crie um conjunto de sites para cada
partido político. Representantes
governamentais que compartilhem
filiação partidária podem compartilhar
modelos e navegação.
Crie um conjunto de sites para cada
comitê ou crie um conjunto de sites
para todos os comitês.
Escritório jurídico corporativo Crie um conjunto de sites para cada
cliente corporativo.
Fabricação Crie um conjunto de sites para cada
linha de produtos.
Aplicativo Web de 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 desse aplicativo incluem assegurar que:
Os proprietários de projetos possam criar sites facilmente para colaboração dos
parceiros.
Parceiros e outros contribuidores tenham acesso apenas ao projeto 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 identificar facilmente os sites que não estão mais em
uso e excluí-los.
Para atender a esses requisitos, o exemplo de design incorpora um conjunto de sites para cada projeto. Dessa forma, os seguintes benefícios são obtidos:
Conjuntos individuais de sites fornecem o nível adequado de isolamento entre
projetos.
A criação de sites pessoais pode ser implementada.
125
O aplicativo Web do parceiro também hospeda os conjuntos de sites de desenvolvimento de conteúdo para o site da empresa na Internet e, por isso, conjuntos de sites separados são criados para autoria e preparação.
Site da empresa na Internet
O site da empresa na Internet incorpora um único conjunto de sites de nível raiz. Todos os sites subordinados a esse conjunto são subsites. Essa estrutura simplifica as URLs de páginas do site. O diagrama a seguir ilustra a arquitetura do site da empresa na Internet.
Bancos de dados de conteúdo Você pode usar estas duas abordagens para incorporar bancos de dados de conteúdo ao design (o exemplo de design incorpora as duas abordagens):
Estabeleça tamanhos de destino para os bancos de dados de conteúdo com avisos
adequados de limite máximo. Crie um novo banco de dados quando os limites
máximos de tamanho forem atingidos. Com essa abordagem, conjuntos de sites são
adicionados automaticamente ao banco de dados ou aos bancos de dados
disponíveis com base exclusivamente nos destinos de tamanho. Essa é a
abordagem de uso mais comum.
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
as seguintes 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 acessíveis para operações de leitura e gravação.
Crie os conjuntos de sites. Eles são automaticamente adicionados ao banco de
dados.
126
Defina o status de todos os outros bancos de dados como Pronto.
Conteúdo de intranet publicado
Para o conteúdo de intranet publicado, o exemplo de design incorpora um único banco de dados para facilitar o gerenciamento. Adicione bancos de dados com base nas metas de tamanho de destino, se necessário.
Meus Sites
Para Meus Sites, o exemplo de design 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 pessoal.
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 200 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 lixeira de segundo estágio = 15%
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, um novo recurso Meus Sites será adicionado 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.
Sites de equipe
Para sites de equipe, o exemplo de design obtém novamente eficiência de dimensionamento ao gerenciar bancos de dados quanto ao tamanho máximo de destino. Os sites de equipe da maioria das organizações tendem a ser muito maiores do que Meus Sites. O exemplo de design fornece definições de banco de dados com base em um limite de 30 GB para conjuntos de sites. Escolha o limite adequado aos sites de equipe da sua organização.
Outra abordagem para organizações cujas equipes requerem amplo espaço de armazenamento é designar um único banco de dados para cada conjunto de sites de equipe de nível superior.
Web do parceiro
Semelhante ao recurso Meus Sites, a Web do parceiro obtém eficiência de dimensionamento ao gerenciar bancos de dados quanto ao tamanho máximo de destino.
127
Porém, no exemplo de design, a Web do parceiro também hospeda o conjunto de sites de autoria para o site da empresa na Internet. Consequentemente, o design do banco de dados incorpora as duas abordagens:
O conjunto de sites de autoria fica hospedado em um banco de dados dedicado.
As configurações de banco de dados e tamanho são definidas para gerenciar todos
os outros sites e bancos de dados.
Como a Web do parceiro fica hospedada em um aplicativo Web dedicado, você pode criar limites de tamanho mais adequados aos tipos de tamanhos que são criados. O exemplo 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
Conjunto de sites de autoria hospedado em um banco de dados dedicado
Site da empresa na Internet
Usando um único conjunto de sites no design do site da empresa na Internet, você utiliza um único banco de dados para esse aplicativo Web.
Zonas e URLs O exemplo de design ilustra 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. Essa é uma exigência
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
128
exemplo, sites de equipe), o exemplo de design 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, escolha 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, se for utilizada. 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.
Intranet
Cada um dos três aplicativos Web que compõem a intranet exige 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 por 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 do SharePoint (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
Conteúdo de intranet
publicado
http://fabrikam https://intranet.fabrikam.com
Sites de equipe http://teams/ https://teams.fabrikam.com
Meus Sites http://my https://my.fabrikam.com
Site de 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 por declarações, cada um desses usuários 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 (ou seja, diferentes métodos de autenticação e diferentes políticas de zona). A tabela a seguir
129
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
Site da empresa na Internet
O site da empresa na Internet é um site público e pode ser acessado por qualquer usuário através da URL padrão, http://www.fabrikam.com. As políticas da zona Internet são aplicadas (ou seja, acesso anônimo e negar gravação).
Entretanto, para oferecer suporte a tarefas de administração e autoria no site público, o exemplo de design incorpora URLs para funcionários internos e remotos. Você pode usar políticas para que essas zonas garantam o acesso adequado aos grupos de segurança pretendidos para tarefas de autoria e manutenção. Os exemplos de design de autenticação clássica e de autenticação por declarações usam a mesma abordagem para esse farm. A tabela a seguir mostra as URLs de cada zona.
Zona URL
URL de funcionário interno http://fabrikamsite/
URL de funcionário remoto https://fabrikamsite.fabrikam.com
URL de cliente http://www.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.
É possível 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://fabrikam/hr. Como
existe um impacto de desempenho para cada caminho explícito adicionado, 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 conjuntos de sites com suporte
130
para a criação de sites pessoais; por exemplo, Meus Sites. Um exemplo de URL de
um conjunto de sites criado por meio desse método é http://my/personal/user1.
O exemplo de design incorpora o uso dos dois tipos, conforme descrito nas seções a seguir.
Inclusões explícitas: conteúdo de intranet publicado
No exemplo de design, o aplicativo Web de intranet publicado incorpora o uso de inclusões explícitas.
Conteúdo de intranet publicado
No aplicativo Web de conteúdo de intranet publicado, uma inclusão explícita é usada para cada subsite; por exemplo, RH, Instalações e Compras. Cada um desses conjuntos de sites pode ser associado a outro banco de dados de conteúdo, se necessário. O uso de inclusões explícitas, neste exemplo, pressupõe que nenhum outro tipo de site tenha sido criado no aplicativo Web, nem mesmo inclusões de curinga.
O limite recomendado para sites criados com uma inclusão explícita é de aproximadamente 20. Se a organização precisar de um número maior de conjuntos de sites, considere o uso de uma inclusão de curinga ou o uso de conjuntos de sites com nome de host.
No exemplo de design de autenticação clássica, o uso de inclusões explícitas resulta nas URLs mostradas na tabela a seguir.
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. O objetivo desse site é hospedar conteúdo para usuários.
Inclusões de curinga: Sites de Equipe, Meus Sites e Web do Parceiro
Sites de Equipe, Meus Sites 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.
131
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.
Meus Sites
O recurso Meus Sites oferece a criação de sites pessoais. Quando um usuário navegando na intranet clica primeiro em Meu Site, esse elemento é automaticamente criado para o usuário. No exemplo de design, Meus Sites apresentam uma inclusão de curinga denominada /personal (http://my/personal). O recurso Meu Site anexa automaticamente o nome de usuário à URL.
No exemplo de design de autenticação clássica, isso resulta em URLs no formato mostrado na tabela a seguir.
Funcionário interno (zona da Intranet) Funcionário remoto (zona Padrão)
http://my/personal/user1 https://my.fabrikam.com/personal/user1
http://my/personal/user2 https://my.fabrikam.com/personal/user2
http://my/personal/user3 https://my.fabrikam.com/personal/user3
Aplicativo Web do parceiro
O aplicativo Web do parceiro foi projetado para permitir que os funcionários criem facilmente sites seguros 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.
132
Parceiro (zona da Extranet)
https://partnerweb.fabrikam.com/sites/project1
https://partnerweb.fabrikam.com/sites/project2
https://partnerweb/fabrikam.com/sites/project3
A exceção para o aplicativo Web do parceiro, conforme ilustrado nos exemplos de design, é o conjunto dedicado à criação do conteúdo para o site da empresa na Internet. Para esse conjunto de sites, uma inclusão explícita é usada. Isso fornece um exemplo de uso de inclusões explícitas e de curinga no mesmo aplicativo Web.
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. Se adicionar ou alterar uma política de zona, a pesquisa precisará rastrear novamente os sites para obter as novas permissões.
Políticas não são usadas no exemplo de design de autenticação por 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 por 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.
Os exemplos de design fornecem exemplos de várias políticas para obter o seguinte:
Negar acesso de gravação no conteúdo publicado.
Garantir que autores e testadores tenham o acesso apropriado ao conteúdo
publicado.
133
Planejar conjuntos de sites nomeados pelo host (SharePoint Server 2010)
Neste artigo:
Sobre conjuntos de sites nomeados pelo host
Sobre cabeçalhos de host
Criar um conjunto de sites nomeado pelo host
Criar programaticamente um conjunto de sites nomeado pelo host
Usar caminhos gerenciados com conjuntos de sites nomeados pelo host
Expor sites nomeados pelo host sobre HTTP ou SSL
Configurar SSL para conjuntos de sites nomeados pelo host
Usar conjuntos de sites nomeados pelo host com terminação SSL externa
O Microsoft SharePoint Server 2010 tem suporte para conjuntos de sites baseados em caminho e nomeados pelo host. A diferença principal entre os dois tipos de conjuntos de sites é que todos os conjuntos de sites baseados em caminho em um aplicativo Web compartilham o mesmo nome de host (nome DNS), já cada conjunto de sites nomeado pelo host em um aplicativo Web recebe um nome DNS exclusivo.
Os conjuntos de sites baseados em caminhos fornecem uma solução de hospedagem corporativa, sendo que todos eles compartilham o mesmo nome de host do aplicativo Web. Em uma implantação baseada em caminho, é possível ter um único conjunto de sites na raiz do aplicativo Web e conjuntos de sites adicionais em caminhos gerenciados no aplicativo Web.
Conjuntos de sites nomeados pelo host fornecem uma solução escalonável de hospedagem na Web com cada conjunto de sites atribuído a um nome DNS exclusivo. Em uma implantação de hospedagem na Web, cada conjunto de sites nomeado pelo host tem sua própria URL de nomenclatura de host intuitiva, como http://customer1.contoso.com, http://customer2.contoso.com ou http://www.customer3.com/.
O SharePoint Server 2010 fornece dois aprimoramentos significativos para conjuntos de sites nomeados pelo host: a capacidade de usar caminhos gerenciados com conjuntos de sites nomeados pelo host e a capacidade de usar terminação SSL externa com esse tipo de conjunto de sites.
Sobre conjuntos de sites nomeados pelo host Hosters da Web fornecem aos clientes espaço no servidor Web para hospedar seus próprios sites. Em um ambiente do SharePoint Server 2010 baseado em caminho, esses sites geralmente seriam atribuídos a http://www.contoso.com/sites/customer1, http://www.contoso.com/sites/customer2 etc. No entanto, os clientes de hospedagem na Web normalmente querem ter seus sites disponíveis em uma nomenclatura de domínio intuitiva, como http://customer1.contoso.com, http://customer2.contoso.com etc.
134
Uma forma de dar suporte a essa solicitação do cliente é fornecer a cada cliente seu próprio aplicativo Web e atribuir o nome DNS exclusivo do cliente a esse aplicativo Web. No entanto, os aplicativos da Web do SharePoint Server 2010 não são tão bem dimensionados quanto os conjuntos de sites do SharePoint Server 2010. O SharePoint Server 2010 dá suporte para conjuntos de sites nomeados pelo host como uma alternativa à criação de aplicativos da Web separados para cada cliente. Conjuntos de sites nomeados pelo host podem ser dimensionados para milhares de conjuntos de sites, pois todos podem existir em um único aplicativo Web e ainda oferecer o recurso de nomenclatura intuitiva.
Como os conjuntos de sites nomeados pelo host têm uma URL exclusiva, eles não dão suporte para mapeamentos de acesso alternativo e sempre se considera que estão na zona Padrão. Se você precisar dar suporte a conjuntos de sites que respondam a várias URLs de nome de host, considere o uso de conjuntos de sites baseados em caminho com mapeamentos de acesso alternativos, em vez de conjuntos de sites nomeados pelo host. Há várias opções de configuração adicionados a serem levadas em conta durante o provisionamento de um novo site do SharePoint Server 2010. A especificação do modelo de site apropriado durante a criação de site determinará quais Web parts pré-configuradas e outros elementos da interface de usuário estarão disponíveis em um novo site. Em um cenário de hospedagem, provavelmente você vai querer selecionar um modelo de site de equipe (valor de "STS#0" ao criar o site) ou um site em branco sem Web parts ou listas predefinidas (valor de "STS#1"). Além disso, considere a especificação de cotas do site em cada conjunto de sites recém-provisionado.
Sobre cabeçalhos de host Os cabeçalhos de host se referem à parte do protocolo HTTP que informa ao servidor da Web o nome DNS do site ao qual o cliente está se conectando. Você pode aplicar cabeçalhos de host em dois níveis diferentes no SharePoint Server 2010:
O nível do aplicativo Web (site do IIS)
O nível do conjunto de sites
É importante entender a distinção entre esses dois níveis. Os cabeçalhos de host no nível do site do IIS somente se destinam a conjuntos de sites baseado em caminho. Os cabeçalhos de host no nível do conjunto de sites somente se destinam a conjuntos de sites nomeados pelo host. Na maioria dos casos, a aplicação de uma associação de cabeçalho de host no nível do site do IIS torna impossível acessar conjuntos de sites nomeados pelo host por meio do site do IIS. Isso ocorre porque o IIS não responderá a solicitações de nomes de host que forem diferentes da associação de cabeçalho de host.
Conjuntos de sites baseados em caminho e nomeados pelo host podem coexistir no mesmo aplicativo Web e podem existir em vários aplicativos da Web. Para assegurar que os dois tipos de conjuntos de sites estejam acessíveis para os usuários, não coloque associações de cabeçalho de host no site do IIS atribuído à zona Padrão do seu aplicativo Web, se houver conjuntos de sites nomeados pelo host nesse aplicativo Web. Você pode aplicar associações de cabeçalho de host aos sites do IIS nas outras zonas do aplicativo Web. Isso permite a você usar a zona Padrão com conjuntos de sites nomeados pelo host ao permitir a utilização da funcionalidade de mapeamento de acesso alternativo nas outras zonas para conjuntos de sites baseados em caminho.
Você pode modificar manualmente as associações de cabeçalho de host no site do IIS Web usando o Gerenciador do IIS, mas isso não é recomendável. As alterações feitas com o Gerenciador do IIS não serão registradas no SharePoint Server 2010. Se o
135
SharePoint Server 2010 tentar provisionar um site do IIS em outro computador no farm para o mesmo aplicativo Web e zona, a associação de cabeçalho de host original será usada no lugar da associação modificada. Para modificar uma associação existente de um site do IIS, remova o aplicativo Web da zona e estenda novamente o aplicativo Web para a zona com a associação que você deseja usar.
Criar um conjunto de sites nomeado pelo host Use o Windows PowerShell para criar um conjunto de sites nomeado pelo host. Você não pode usar o aplicativo Web da Administração Central do SharePoint Server 2010 para criar um conjunto de sites nomeado pelo host, mas pode usar a Administração Central para gerenciar o conjunto de sites depois de criá-lo.
Você pode criar um conjunto de sites nomeado pelo host usando o cmdlet New-SPSite
do Windows PowerShell com o parâmetro -HostHeaderWebApplication
, como mostrado no exemplo seguinte:
1. Para criar um conjunto de sites nomeado pelo host usando o Windows PowerShell,
verifique se os seguintes requisitos mínimos são atendidos: Consulte Add-
SPShellAdmin.
2. No menu Iniciar, clique em Todos os Programas.
3. Clique em Produtos do Microsoft SharePoint 2010.
4. Clique em Shell de Gerenciamento do SharePoint 2010.
5. No prompt de comando do Windows PowerShell (isto é, PS C:\>), digite o seguinte:
Código da cópia
New-SPSite http://host.header.site.url -OwnerAlias DOMAIN\username - HostHeaderWebApplication http://servername
Isso cria um conjunto de sites nomeado pelo host com a URL http://host.header.site.url
no aplicativo Web SharePoint Server 2010 com a URL http://servername
.
Criar programaticamente um conjunto de sites nomeado pelo host Além de usar o Windows PowerShell para criar sites nomeados pelo host, você pode usar o modelo de objeto do SharePoint Server 2010. O seguinte exemplo de código cria o conjunto de sites nomeado pelo host com a URL http://host.header.site.url
no aplicativo Web SharePoint Server 2010 com a URL http://servername
:
136
Código da cópia
SPWebApplication webApp = SPWebApplication.Lookup(new Uri("http://www.contoso.com")); SPSiteCollection sites = webApp.Sites; SPSite Site = null; Site = sites.Add("http://hoster.contoso.com", "Site_Title", "Site_Description", 1033, "STS#0", "contoso\owner", "Owner_Display_Name", "Owner_Email", "contoso\secondaryowner, "Secondary_Owner_Display_Name", "Secondary_Owner_Email", true);
O SharePoint Server 2010 é fornecido com um conjunto de serviços Web para várias tarefas de usuário e administrativas. Uma dessas tarefas administrativas é a criação de um novo conjunto de sites. O método de serviço Web CreateSite não dá suporte à criação de conjuntos de sites nomeados pelo host. Uma solução alternativa para esse problema é escrever um serviço Web que inclua o exemplo de código da API.
Usar caminhos gerenciados com conjuntos de sites nomeados pelo host O SharePoint Server 2010 adiciona suporte para caminhos gerenciados com conjuntos de sites nomeados pelo host. Os hosters podem fornecer vários conjuntos de sites ao mesmo cliente e cada conjunto de sites compartilha o nome de host exclusivo do cliente, diferenciado pelo caminho da URL após o nome de host.
Caminhos gerenciados para conjuntos de sites nomeados pelo host são diferentes de caminhos gerenciados para conjuntos de sites baseados em caminho. os caminhos gerenciados para conjuntos de sites nomeados pelo host não se aplicam a conjuntos de sites baseados em caminho; nem os caminhos gerenciados para conjuntos de sites baseados em caminho se aplicam a conjuntos de sites nomeados pelo host. Os caminhos gerenciados criados para conjuntos de sites nomeados pelo host estão disponíveis para todos os conjuntos de sites nomeados pelo host no farm, independentemente do aplicativo Web no qual o conjunto de sites nomeado pelo host está. Você deve criar um conjunto de sites nomeado pelo host raiz para um nome de host antes de criar um conjunto de sites nomeado pelo host com caminho gerenciado para esse nome de host.
Você pode criar um caminho gerenciado para uso com conjuntos de sites nomeados pelo host usando o cmdlet New-SPManagedPath
do Windows PowerShell com o parâmetro -HostHeader
, conforme mostrado no seguinte exemplo:
Código da cópia
New-SPManagedPath pathname -HostHeader
137
Um conjunto de sites nomeado pelo host criado em um caminho gerenciado é mostrado no seguinte exemplo:
Código da cópia
New-SPSite http://host.header.site.url/pathname/sitename -OwnerAlias DOMAIN\username -HostHeaderWebApplication http://servername
Expor sites nomeados pelo host sobre HTTP ou SSL Os conjuntos de sites nomeados pelo host usarão o mesmo esquema de protocolo da URL pública na zona Padrão do aplicativo Web. Se você quiser fornecer os conjuntos de sites nomeados pelo host no aplicativo Web sobre HTTP, verifique se a URL pública na zona Padrão do aplicativo Web é uma URL baseada em HTTP. Para fornecer conjuntos de sites nomeados pelo host no aplicativo Web sobre SSL, verifique se a URL pública na zona Padrão do aplicativo Web é uma URL baseada em HTTPS.
Diferentemente de uma versão anterior, o SharePoint Server 2010 não tem suporte para um conjunto de sites nomeado pelo host usando URLs baseadas em HTTP e SSL simultaneamente. Se for necessário que alguns conjuntos de sites nomeados pelo host estejam disponíveis sobre HTTP enquanto outros precisarem estar disponíveis sobre SSL, separe os conjuntos de sites nomeados pelo host em dois aplicativos Web diferentes dedicados para esse tipo de acesso. Nesse cenário, os conjuntos de sites nomeados pelo host HTTP devem estar em um aplicativo Web dedicado para acesso HTTP e os conjuntos de sites nomeados pelo host SSL devem estar em um aplicativo Web dedicado para acesso SSL.
Configurar SSL para conjuntos de sites nomeados pelo host Em cenários de hospedagem, os hosters podem configurar um único aplicativo Web com SSL e depois criar vários conjuntos de sites nomeados pelo host nesse aplicativo Web. Para navegar para um site sobre SSL, é necessário instalar um certificado de servidor e atribuí-lo ao site do IIS. Cada conjunto de sites nomeado pelo host em um aplicativo Web compartilhará o certificado de servidor exclusivo atribuído ao site do IIS.
Os hosters precisam adquirir um certificado curinga ou um certificado de nome alternativo de assunto e depois usar uma política de URL de conjunto de sites nomeado pelo host que corresponda a esse certificado. Por exemplo, se um hoster adquire um certificado curinga *.contoso.com, esse hoster terá que gerar URLs do conjunto de sites nomeado pelo host, como https://site1.contoso.com, https://site2.contoso.com etc., para permitir que esses sites sejam aprovados na validação SSL do navegador. No entanto, se os clientes precisarem de nomes de domínio de segundo nível exclusivos para seus sites, o hoster terá que criar vários aplicativos Web, em vez de vários conjuntos de sites nomeados pelo host.
138
Para configurar SSL para conjuntos de sites nomeados pelo host, habilite o SSL ao criar o aplicativo Web. Isso criará um site da IIS com uma associação SSL, em vez de uma associação HTTP. Após a criação do aplicativo Web, abra o Gerenciador do IIS e atribua um certificado a essa associação SSL. Em seguida, você poderá criar conjuntos de sites nesse aplicativo Web.
Usar conjuntos de sites nomeados pelo host com terminação SSL externa Como o SharePoint Server 2010 usa a URL pública na zona Padrão do aplicativo Web para determinar se os conjuntos de sites nomeados pelo host serão renderizados como HTTP ou SSL, agora você pode usar conjuntos de sites nomeados pelo host com terminação SSL externa. Há 3 requisitos para utilização da terminação SSL com conjuntos de sites nomeados pelo host:
A URL pública na zona Padrão do aplicativo Web deve ser uma URL baseada em
HTTPS.
O terminador SSL ou o proxy reverso precisa preservar o cabeçalho de host HTTP
original do cliente.
Se a solicitação SSL do cliente for enviada para a porta SSL padrão (443), o
terminador SSL ou o proxy reverso deve encaminhar a solicitação HTTP
descriptografada ao servidor Web front-end na porta HTTP padrão (80). Se a
solicitação SSL do cliente for enviada a uma porta SSL não padrão, o terminador
SSL ou o proxy reverso deverá encaminhar a solicitação HTTP descriptografada ao
servidor Web front-end na mesma porta não padrão.
Para usar conjuntos de sites nomeados pelo host com terminação SSL externa, configure seu aplicativo Web da maneira como faria normalmente para terminação SSL e verifique se ele atende aos requisitos descritos acima. Neste cenário, o SharePoint Server 2010 renderizará links de seus conjuntos de sites nomeados pelo host nesse aplicativo Web usando HTTPS, em vez de HTTP.
139
Ambientes hospedados (SharePoint Server 2010)
Nesta seção:
Modelo: arquiteturas de hospedagem para o SharePoint Server 2010
White paper: SharePoint 2010 para hosters (SharePoint Server 2010)
140
Modelo: arquiteturas de hospedagem para o SharePoint Server 2010
Este modelo resume o suporte para hospedar ambientes e demonstra arquiteturas de hospedagem comuns. Antes de aprender sobre ambientes de hospedagem, é importante entender a arquitetura de serviços. Para obter mais informações, consulte Planejamento da arquitetura de serviços (SharePoint Server 2010).
Hospedando ambientes nos Produtos do SharePoint 2010
Visio (http://go.microsoft.com/fwlink/?linkid=167084&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=167086&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=167085&clcid=0x416)
141
White paper: SharePoint 2010 para hosters (SharePoint Server 2010)
Este white paper apresenta à comunidade de hospedagem uma visão geral do Microsoft SharePoint Server 2010 e dos componentes básicos do Microsoft SharePoint Foundation, além de diretrizes detalhadas de arquitetura para suporte aos requisitos multilocação dos hosters. Embora este documento possa ser usado por qualquer pessoa para saber mais sobre qualquer recurso importante dos Produtos do SharePoint 2010, seu foco é no modo como esses novos recursos afetam e oferecem suporte à comunidade de hospedagem.
SharePoint 2010 para hosters (http://go.microsoft.com/fwlink/?linkid=190783&clcid=0x416)
142
Planejamento da virtualização (SharePoint Server 2010)
Esta seção contém artigos projetados para ajudá-lo a planejar e implementar uma solução de virtualização de servidores em farms de servidores do Microsoft SharePoint Server 2010.
Nesta seção:
Suporte e licenciamento de virtualização (SharePoint Server 2010)
Requisitos de virtualização do Hyper-V (SharePoint Server 2010)
Planejar arquiteturas virtuais (SharePoint Server 2010)
Planejar a virtualização (SharePoint Server 2010)
Gerenciamento de capacidade e alta disponibilidade em um ambiente virtual
(SharePoint Server 2010)
143
Suporte e licenciamento de virtualização (SharePoint Server 2010)
Este artigo oferece informações de suporte e licenciamento para o uso de tecnologias de virtualização de servidor para a implantação de Produtos do SharePoint 2010 em um ambiente virtual.
Suporte aos Produtos do SharePoint 2010 para virtualização Todos os elementos do Microsoft SharePoint Server 2010 têm suporte completo quando implantados em um ambiente do Tecnologia Windows Server 2008 Hyper-V. Além disso, qualquer tecnologia de suporte relacionada ou necessária também terá suporte.
Observação:
O suporte à virtualização do SharePoint Server 2010 inclui tecnologias de virtualização de
terceiros hospedadas ou baseadas em hardware e certificadas pela Microsoft. Para obter
mais informações sobre certificação e sobre os fornecedores participantes, consulte o
artigo sobre o Programa de Validação de Virtualização de Servidores (SVVP)
(http://go.microsoft.com/fwlink/?linkid=125649&clcid=0x416).
Virtualização de servidores usando a tecnologia Hyper-V A partir do Windows Server 2008, a virtualização de servidor usando o Hyper-V tem sido uma parte integrante do sistema operacional. O Hyper-V está disponível em todas as edições do sistema operacional, assim como o Microsoft Hyper-V Server 2008.
Recomendamos o uso do Windows Server 2008 R2 ou do Microsoft Hyper-V Server 2008 R2 como servidores de virtualização para a implantação de seus Produtos do SharePoint 2010. Essas versões oferecem:
Recursos adicionais, como maior suporte para processadores virtuais e maior
suporte de memória para máquinas virtuais.
Aprimoramentos de desempenho, como desempenho aprimorado de unidades de
disco rígido virtual e adaptadores de rede.
Para obter mais informações, consulte o artigo sobre novidades no Hyper-V no Windows Server 2008 R2 (http://go.microsoft.com/fwlink/?linkid=155234&clcid=0x416).
144
Licenciamento de OSE (ambiente de sistema operacional) Antes de começar a planejar a virtualização, você precisa determinar os requisitos de licenciamento para o seu ambiente de virtualização. Existem dois tipos de ambientes de sistema operacional (OSEs):
Um ambiente físico de sistema operacional
Um ou mais ambientes virtuais de sistema operacional
Um ambiente virtual de sistema operacional é configurado para ser executado em um sistema de hardware virtual (ou, caso contrário, emulado). O uso de tecnologias que criam OSEs virtuais não altera os requisitos de licenciamento para o sistema operacional e qualquer aplicativo executado no OSE.
O modelo de licenciamento do sistema operacional Windows Server para sistemas de processadores físicos de vários núcleos se baseia no número de processadores físicos instalados no hardware. Esse modelo se estende a processadores virtuais configurados para uma máquina virtual executada em um servidor de virtualização. Para fins de licenciamento, um processador virtual é considerado como tendo o mesmo número de threads e núcleos de cada processador físico no sistema de hardware físico subjacente.
Para obter mais informações sobre requisitos de licenciamento:
Licenciamento de produtos Microsoft Server em ambientes virtuais
(http://go.microsoft.com/fwlink/?linkid=187741&clcid=0x416)
Este white paper oferece uma visão geral dos modelos de licenciamento da Microsoft para o sistema operacional e aplicativos do servidor sob ambientes virtuais.
Calculadores de virtualização do Windows Server
(http://go.microsoft.com/fwlink/?linkid=187742&clcid=0x416)
Os Calculadores de Virtualização do Windows Server oferecem duas maneiras de estimar o número e o custo de licenças do Windows Server Standard Edition, Enterprise Edition e Datacenter Edition necessárias para seus cenários de virtualização para ajudá-lo a determinar a edição com melhor custo-benefício do Windows Server.
Observação:
Embora o Microsoft Hyper-V Server 2008 R2 não exija uma licença para o servidor de
virtualização, os requisitos de licenciamento devem ser atendidos para os OSEs virtuais.
Licenciamento de Produtos do SharePoint 2010 Todos os elementos do farm do SharePoint instalados em uma máquina virtual devem atender aos requisitos de licenciamento do SharePoint Server 2010, além das tecnologias relacionadas e de suporte.
145
Requisitos de virtualização do Hyper-V (SharePoint Server 2010)
Este artigo fornece os requisitos de hardware e software para o uso de virtualização baseada em hardware. Embora o Tecnologia Windows Server 2008 Hyper-V seja o tópico central deste documento, os requisitos de hardware básicos para habilitar a virtualização baseada em hardware também se aplicam a tecnologias de virtualização de terceiros que são certificadas pela Microsoft.
Hardware Os requisitos para virtualização baseada em hardware são:
Virtualização assistida por hardware, que está disponível em processadores com
uma opção de virtualização — especificamente, processadores com tecnologia Intel
Virtualization Technology (Intel VT) ou AMD Virtualization (AMD-V).
A DEP (Prevenção de Execução de Dados) imposta por hardware está disponível e
habilitada.
Você pode usar uma das seguintes ferramentas para determinar se o processador em um servidor existente tem suporte para o Hyper-V:
Utilitário para verificação de compatibilidade entre o Hyper-V e AMD (arquivo .zip)
(http://go.microsoft.com/fwlink/?linkid=150561&clcid=0x41
Utilitário para identificação de processador Intel (versão para Windows)
(http://go.microsoft.com/fwlink/?linkid=150562&clcid=0x416)
Software Um dos seguintes produtos Microsoft é necessário para o Hyper-V:
Windows Server 2008 (todas as edições do Windows Server 2008, exceto Windows
Server 2008 for Itanium-Based Systems, Windows Web Server 2008 e Windows
Server 2008 Foundation)
Microsoft Hyper-V Server 2008
Windows Server 2008 R2 (todas as edições do Windows Server 2008 R2, exceto
Windows Server 2008 R2 for Itanium-Based Systems, Windows Web
Server 2008 R2 e Windows Server 2008 R2 Foundation)
Hyper-V Server R2
O Windows Server 2008 R2 é recomendado para servidores de virtualização devido aos vários aprimoramentos introduzidos para Hyper-V, como:
Migração ao vivo para mover uma máquina virtual em execução de um nó de cluster
para outro
Ganho significativo em termos de desempenho e escalabilidade
146
Suporte avançado a processadores
Armazenamento de máquina virtual avançado
Suporte a redes avançado
Para obter mais informações, consulte o artigo sobre novidades no Hyper-V no Windows Server 2008 R2 (http://go.microsoft.com/fwlink/?linkid=155234&clcid=0x416).
Consulte também Conceitos
Suporte e licenciamento de virtualização (SharePoint Server 2010)
147
Planejar arquiteturas virtuais (SharePoint Server 2010)
Este artigo aborda as principais considerações sobre o planejamento de arquiteturas virtuais usando as funções de servidor do Microsoft SharePoint Server 2010. Não inclui recomendações ou dados de planejamento de capacidade ou desempenho. Descreve orientações gerais sobre planejamento de ambientes virtuais e inclui arquiteturas de exemplo para farms de pequeno, médio e grande portes.
Neste artigo:
Arquiteturas virtuais versus físicas
Exemplo de arquiteturas virtuais para farms de pequeno a médio porte
Exemplos de arquitetura virtual para farms de médio a grande porte
Arquiteturas virtuais versus físicas Normalmente, uma organização considera uma mudança para arquiteturas virtuais porque deseja reduzir o número de servidores necessários para hospedar uma solução, para usar mais eficientemente o hardware existente ou economizar energia e espaço. A capacidade para automatizar a implantação do servidor também é uma motivação primária para implantar um ambiente de servidor virtual.
Virtualizando servidores Web e servidores de aplicativo
As funções de servidor Web e de servidor de aplicativos são boas candidatas à virtualização. Quando você planeja um ambiente virtual, uma abordagem razoável é aplicar topologia, desempenho e orientação de capacidade para planejar o ambiente físico, e usar o número resultante de servidores Web e servidores de aplicativo, incluindo funções de servidor de aplicativo específicas, como um ponto de partida para o ambiente virtual.
Em um ambiente virtual; no entanto, mais servidores virtuais podem ser necessários para prover o mesmo nível de serviço e desempenho durante os horários de pico que o fornecido pelos servidores físicos. Os resultado dependerão dos serviços específicos e dos padrões de uso desses serviços.
Isso posto, executar em um ambiente virtual propicia a flexibilidade de realocar recursos em máquinas virtuais à medida que isso for necessário para ajustar o desempenho.Também é possível adicionar e remover servidores virtuais facilmente para resolver picos no uso de serviços específicos que ocorram em momentos previsíveis durante o ano.
Virtualizando o SQL Server
A questão de virtualizar ou não o Microsoft SQL Server é algo a se debater e depende das metas gerais de uma implantação. Um ambiente virtual do SQL Server normalmente executa um pouco mais lento do que em um ambiente físico, embora o desempenho tenha melhorado com o lançamento das novas versões. Com a versão mais recente da função Hyper-V (incluída no Windows Server 2008 R2), os testes de desempenho do
148
SQL Server indicam que pode ser obtido o mesmo resultado (comparado a um servidor físico) em uma máquina virtual convidada ao custo de um pequeno aumento no uso da CPU.
Há outras coisas a serem consideradas antes de se planejar a virtualização do SQL Server, por exemplo, o número de núcleos de CPU exigido pelo SQL Server, o plano de failover e disponibilidade, e as opções de otimização de armazenamento. Independentemente, os benefícios de implantação do SQL Server para um ambiente virtual podem superar o custo de desempenho.
Organizações que hospedam farms do SharePoint e planejam implantar e recriar farms frequentemente (por exemplo, empresas de hospedagem) tirarão o maior proveito adicionando o SQL Server ao ambiente virtual. A virtualização do SQL Server também pode ser útil em uma solução temporária ou transitória, por exemplo, durante a combinação de vários farms em um farm corporativo e na retirada de hardware. Organizações que extraiam o máximo de hardware limitado terão o maior benefício implantando o SQL Server em servidores físicos. Os exemplos neste artigo incluem ambientes que adotaram ambas as abordagens.
Para obter mais informações, consulte Executando o SQL Server 2008 em um Ambiente do Hyper-V — Melhores Práticas e Recomendações de Desempenho (http://go.microsoft.com/fwlink/?linkid=134106&clcid=0x416). Esse white paper se baseia em uma versão anterior de Hyper-V. Procure uma versão mais nova desse documento no final da primavera (boreal) de 2010.
Virtualizando outros servidores no ambiente
As soluções do Produtos do SharePoint 2010 dependem de outros servidores no ambiente. Esta seção apresenta orientação geral sobre o faturamento nessa arquitetura virtual.
Active Directory
É recomendado que, no mínimo, o controlador do domínio raiz de um ambiente de serviços de diretório Active Directory seja hospedado em um servidor físico fora de ambientes virtuais. Se necessário, os controladores de domínio adicionais podem ser implantados como servidores virtuais.
Para obter mais informações sobre como implantar o Active Directory em ambiente virtuais, consulte os seguintes recursos:
Blog de Sander Berkouwer: Active Directory em ambientes de Hyper-V, Parte 2
(http://go.microsoft.com/fwlink/?linkid=186927&clcid=0x416)
Considerações sobre Planejamento de Controladores de Domínio Virtualizados
(http://go.microsoft.com/fwlink/?linkid=186928&clcid=0x416)
Produtos de gateway
Os produtos de gateway incluem:
Microsoft Forefront Unified Access Gateway (UAG)
Microsoft Forefront Threat Management Gateway (TMG)
Para obter uma maior disponibilidade, é recomendado posicionar esses produtos fora do ambiente virtual do Produtos do SharePoint 2010. Para obter mais informações sobre como configurar os ambientes virtuais desses produtos de gateway, consulte a documentação do produto.
Testando lado a lado
149
Se estiver preocupado sobre como a implantação das funções de servidor do Produtos do SharePoint 2010 em um ambiente virtual poderá afetar o desempenho, teste as funções específicas que você planeja implantar. Você pode usar os resultados para decidir quantos servidores virtuais implantar para determinada função, ou para implantar uma função específica no ambiente virtual. Por exemplo, se o farm rastreará um grande volume de conteúdo, os resultados dos testes poderão levá-lo a implantar a função de rastreamento em um servidor físico dedicado.
Um meio para testar um ambiente virtual é implantar uma função específica virtual e fisicamente, e comparar os dados de parâmetro de comparação de rede, memória, disco e CPU. A ilustração a seguir apresenta um exemplo de como testar funções de servidor específicas usando um número limitado de servidores.
Nessa ilustração, funções específicas são implantadas no ambiente virtual. Um servidor de teste físico é configurado para testar cada função, um de cada vez, de modo que os dados de parâmetro de comparação possam ser coletados lado a lado. Não se esqueça de levar em consideração as diferenças entre os ambientes físico e virtual que afetarão resultados de teste, como especificações de hardware diferentes.
Se já tiver um farm, adicione um host virtual e alterne para máquinas virtuais que tenham funções equivalentes, para ver como o desempenho virtual de cada função é afetada. Você também pode verificar como as diferentes combinações de funções afetam o desempenho geral do farm. O exemplo a seguir ilustra essa ideia.
150
Exemplo de arquiteturas virtuais para farms de pequeno a médio porte O ponto de partida da substituição de um farm físico usando um farm virtual é de usar dois a quatro servidores host físicos. Para cada host, o número de servidores que pode ser implantado é determinado pelos recursos de memória, CPU, disco e rede disponíveis.
As duas ilustrações a seguir apresentam implantações de exemplo em que os servidores Web e as funções de servidor de aplicativo são implantados em um ambiente virtual.
151
Neste exemplo, esteja ciente do seguinte:
Os recursos mínimos para CPUs e RAM representam os pontos de partida para o
farm. Como são reservados apenas dois núcleos para cada imagem virtual, este
exemplo é apropriado apenas para ambientes de verificação de conceito ou de
desenvolvimento em que o desempenho não seja um problema. Reserve recursos
sobressalentes suficientes para serem realocados com base no monitoramento de
desempenho.
O SQL Server é implantado em servidores físicos, em vez de em servidores virtuais.
Os servidores Web e de aplicativo são redundantes em dois servidores host.
Três servidores Web estão implantados no ambiente virtual para fins de alta
disponibilidade.
152
Os controladores de domínio do Active Directory são implantados em servidores
físicos.
Para ambientes de teste piloto e de produção, quatro núcleos são o ponto de partida mínimo recomendado para máquinas virtuais. Os seguintes ambientes virtuais usam menos máquinas virtuais para obter esse objetivo.
Este exemplo representa um ambiente de ponto de partida. Talvez você tenha de adicionar recursos, dependendo do padrão de uso do farm.
Exemplos de arquitetura virtual para farms de médio a grande porte Com servidores host maiores, é possível alocar mais recursos às imagens virtuais. A ilustração a seguir apresenta uma implementação de exemplo que usa mais CPUs e RAM.
153
Se os benefícios da virtualização do SQL Server superarem a compensação de desempenho, o SQL Server poderá ser implantado como convidado, como mostrado na ilustração a seguir.
154
Neste exemplo, esteja ciente do seguinte:
Apenas uma instância do SQL Server é implantada para cada host. Em ambientes
virtuais de pequeno e médio porte, é recomendado não implantar mais de um SQL
Server convidado por host.
Ambos os servidores host incluem mais memória para acomodar o número de
servidores virtuais, incluindo SQL Server.
Se determinada função de servidor consumir tantos recursos a ponto de afetar adversamente o desempenho geral do ambiente virtual, dedique um servidor físico para essa função. Dependendo dos padrões de uso de uma organização, essas funções podem incluir servidores de rastreamento, o servidor que importa perfis, o Aplicativo de Serviços do Excel ou outros serviços amplamente utilizados. A ilustração fornece um exemplo.
155
Neste exemplo:
O SQL Server é implantado em servidores físicos. Remova o SQL Server do
ambiente virtual antes de remover as funções de serviço do aplicativo.
A função de rastreamento é implantada em um servidor físico. Em alguns ambientes,
uma função diferente pode ser candidata a ser implantada em um servidor físico,
dependendo do uso.
156
Planejar a virtualização (SharePoint Server 2010)
Este artigo descreve o processo de planejamento a ser seguido para a implantação bem-sucedida do Microsoft SharePoint Server 2010 em um ambiente virtual. Cada etapa no processo de planejamento inclui links para a documentação apropriada. Pressupõe-se que você tenha determinado a solução do SharePoint Server 2010 que deseja implantar em um ambiente virtual. Na superfície, a implantação de um farm do SharePoint Server 2010 em máquinas virtuais é igual à implantação de um farm nos servidores físicos. No entanto, a implantação em um ambiente virtual envolve um nível diferente de planejamento que leva em conta as características do Tecnologia Windows Server 2008 Hyper-V e o modo como máquinas virtuais, adaptadores de rede virtuais e discos rígidos virtuais são implementados em um servidor de virtualização.
Antes de começar a desenvolver seu plano de virtualização, é recomendável ler o Guia de planejamento e implantação do Hyper-V (http://go.microsoft.com/fwlink/?linkid=187964&clcid=0x416).
Informações detalhadas sobre os seguintes assuntos estão fora do escopo deste artigo, mas são fornecidas em outros artigos:
Gerenciamento de capacidade
Alta disponibilidade
Usando o ambiente virtual
Requisitos de segurança
Recuperação de desastre
Planejamento da continuidade dos negócios
Um ambiente virtual consiste em duas camadas inter-relacionadas, sendo uma camada física e uma virtual. Uma alteração de configuração em qualquer camada afeta os servidores nas outras camadas. Essa inter-relação se torna evidente quando você planeja, implanta e usa o SharePoint Server 2010 em um ambiente virtual.
Criar um plano para implantar o SharePoint Server 2010 em um ambiente virtual Você deve abordar o planejamento para um farm virtual da mesma forma que planejaria um farm físico. A maioria dos problemas e requisitos de implantação do SharePoint Server 2010 em servidores físicos (se não todos) se aplica igualmente às máquinas virtuais. As decisões que você tomar, como os requisitos mínimos de processador ou memória, terão um impacto direto sobre o número de hosts de virtualização necessários, bem como a capacidade de dar suporte adequado às máquinas virtuais identificadas para o farm.
Depois que terminar de planejar um farm físico, você terá todas as informações necessárias para criar a arquitetura de virtualização. Em tese, essa arquitetura é a mais próxima possível da solução de virtualização final que você pretende colocar em
157
produção. Na realidade, a arquitetura provavelmente será alterada à medida que você avançar na fase de implantação do ciclo de vida do sistema. De fato, você pode determinar que algumas funções de servidor do farm não são boas candidatas para virtualização.
As principais etapas de planejamento, tarefas e referências são resumidas no procedimento a seguir.
Para criar um plano de virtualização
1. Determine o escopo da virtualização
A determinação do escopo é um fator-chave de contribuição para a implementação, o gerenciamento e a avaliação bem-sucedidos do seu projeto de virtualização. Considere o fato de que muitas soluções têm vários componentes de farm. Por exemplo, um portal da Web voltado para a Internet geralmente tem um farm de publicação, um farm de criação e um farm de teste ou garantia de qualidade. Ao determinar o escopo, você tem de decidir se virtualizará parte da infraestrutura da solução ou toda ela.
Use a lista de tarefas a seguir para determinar o escopo da virtualização.
Tarefa 1: identifique todos os farms necessários para implementar sua solução.
Tarefa 2: para cada farm, determine o número de servidores necessários e a
função que cada servidor terá no farm.
Tarefa 3: identifique quais farms você deseja implantar em um ambiente virtual.
A criação do escopo da solução aprimora o escopo da implantação, o que facilita a implementação e o gerenciamento. Para obter mais informações, consulte Plan for sites and solutions (SharePoint Server 2010). E embora as soluções compartilhem elementos comuns, cada uma delas tem seus próprios requisitos. Para obter mais informações, consulte Fundamental site planning (SharePoint Server 2010). O artigo Plan for social computing and collaboration (SharePoint Server 2010) mostra uma das soluções populares.
Aprimore o escopo de acordo com as metas e os objetivos da solução, os requisitos da solução ou a unidade de negócio.
2. Identifique os servidores a serem virtualizados
Identifique os servidores que são bons candidatos à virtualização. Sob uma perspectiva técnica e de suporte da Microsoft, todos os servidores SharePoint podem ser virtualizados. A decisão de virtualizar um determinado servidor do farm deve se basear no seguinte:
Políticas de conformidade corporativa (por exemplo, legais e técnicas)
Benefícios derivados da consolidação de servidores, como a redução do
consumo de energia e dos requisitos de espaço físico. Para obter mais
informações, consulte o artigo sobre virtualização de servidor
(http://go.microsoft.com/fwlink/?linkid=187965&clcid=0x416).
Requisitos de capacidade (consulte a próxima etapa de planejamento)
3. Identifique os requisitos de capacidade de cada servidor do farm
Determine os requisitos de recursos de cada servidor do farm como se ele fosse um servidor físico. Considere funções de servidor especializadas, como hospedagem de componentes do Enterprise Search. Você precisa especificar a quantidade de recursos necessários para cada um dos seguintes componentes de servidor:
158
Memória
Número de processadores e velocidade mínima do relógio
Número e tamanho dos discos rígidos
Número de adaptadores de rede e a taxa de transferência necessária
Observação:
Para servidores físicos e máquinas virtuais, planeje o pico de carga e determine como os
picos de curto prazo na carga serão administrados.
4. Determine se a máquina virtual pode atender aos requisitos físicos.
É necessário determinar se cada máquina virtual identificada na Etapa 3 pode atender aos requisitos de capacidade de um servidor físico correspondente. Execute pelo menos as seguintes tarefas:
Tarefa 1: avalie o requisito de memória no contexto da capacidade do host de
virtualização disponível.
Tarefa 2: avalie o requisito de processador. O Hyper-V tem um limite de quatro
processadores virtuais por máquina virtual. Se um servidor físico do farm exigir
oito processadores, determine se esse requisito pode ser atendido
dimensionando o número de máquinas virtuais em um farm.
Tarefa 3: avalie o requisito de armazenamento da máquina virtual no contexto de
armazenamento físico local ou SAN.
5. Determine os requisitos de host de virtualização
Determine os requisitos mínimos de host (memória, número de núcleos, número e tamanho de discos rígidos locais, número de adaptadores de rede). Além disso, considere e planeje o seguinte:
Escalabilidade: determine se você pode adicionar mais CPUs, mais memória,
mais discos rígidos e mais adaptadores de rede ao computador host.
Importante:
Dependendo do fabricante e do modelo do computador, talvez você não consiga
aumentar a capacidade. É necessário ter essa informação antes de usar ou comprar um
servidor.
Capacidade extra do host: determine se o host tem a capacidade de
dimensionar máquinas virtuais existentes ou adicionar mais máquinas virtuais.
Isso será muito importante se você estiver planejando usar cluster de failover,
migração rápida ou migração ao vivo do Hyper-V.
Importante:
Planeje o pico de carga e determine como os picos de carga de curto prazo serão
administrados.
6. Crie a arquitetura de virtualização
Uma arquitetura bem projetada é necessária para uma solução bem-sucedida. Para o SharePoint Server 2010, uma topologia básica em três camadas fornece a base de todas as soluções. Os seguintes elementos constituem um bom projeto baseado na topologia recomendada:
159
Bom desempenho geral
Facilidade de manutenção e atualização
Flexibilidade
Escalabilidade
Alta disponibilidade
Para obter mais informações, consulte Planejar ambientes e farms de servidores (SharePoint Server 2010).
Um modelo de arquitetura de virtualização consiste nos hosts de virtualização e nas máquinas virtuais que constituem a topologia do farm. Esse modelo permite a você visualizar o ambiente virtual que planeja implantar. Para obter mais informações, consulte Planejar arquiteturas virtuais (SharePoint Server 2010).
Observação:
Esteja preparado para aprimorar a arquitetura à medida que avançar no processo de
planejamento. As etapas a seguir podem ditar alterações na arquitetura.
7. Identifique os requisitos de armazenamento
Determine a quantidade de armazenamento físico local ou de SAN necessária para armazenamento relacionado ao Hyper-V, como arquivos de configuração, VHDs (discos rígidos virtuais) e instantâneos.
8. Identifique os requisitos de backup e recuperação
Além dos servidores do farm, você deve planejar o backup e a recuperação para todo o farm ou parte dele. Para obter mais informações, consulte Backup and recovery (SharePoint Server 2010).
9. Determine os requisitos de alta disponibilidade e crie uma solução
Identifique as abordagens para a obtenção de alta disponibilidade para servidores Web, servidores de aplicativos e bancos de dados. As estratégias típicas incluem o seguinte:
Hardware e servidores redundantes
Componentes com permuta automática
Cluster de failover para servidores virtuais e físicos. Para obter mais
informações, consulte o artigo sobre como usar Hyper-V e cluster de failover
(http://go.microsoft.com/fwlink/?linkid=187967&clcid=0x416).
Cluster ou espelhamento para servidores de banco de dados.
10. Identifique os indicadores de integridade e capacidade para monitorar o ambiente
virtual. Para obter mais informações, consulte Gerenciamento de capacidade e alta
disponibilidade em um ambiente virtual (SharePoint Server 2010).
Combine os indicadores-chave derivados nas etapas anteriores com o planejamento que você executou para o SharePoint Server 2010. Para obter mais informações, consulte Planejar ambientes e farms de servidores (SharePoint Server 2010). Você tem de determinar todos os indicadores de integridade e capacidade para coletar medições dos seguintes objetos no ambiente virtual:
Máquinas virtuais com o SharePoint Server 2010 instalado
Máquinas virtuais que não fazem parte do farm, como um servidor de firewall
Hosts de virtualização
160
Componentes de rede
Depois que você começar a coletar dados do ambiente virtual, poderá criar uma linha de base, que poderá ser usada para avaliar e ajustar o ambiente virtual durante a implantação e após a entrada do farm em produção.
11. Crie um plano de implantação para a fase de implantação do ciclo de vida do
sistema.
Para obter mais informações, consulte o modelo de Implantação de Produtos do SharePoint 2010, disponível no artigo Diagramas técnicos (SharePoint Server 2010).
12. Crie um plano de manutenção
Crie um plano de manutenção que permita implementar alterações de senha e aplicar atualizações de software, service packs e hotfixes. Esse plano deverá conter as máquinas virtuais e os hosts de virtualização.
161
Gerenciamento de capacidade e alta disponibilidade em um ambiente virtual (SharePoint Server 2010)
Este artigo fornece informações sobre o gerenciamento da capacidade e a alta disponibilidade de uma hospedagem de ambiente virtual do Microsoft SharePoint Server 2010. Combinamos esses dois conceitos no artigo porque capacidade e dimensionamento são aspectos importantes do desenvolvimento de um plano de virtualização e da arquitetura de um ambiente virtual, e também porque o gerenciamento da capacidade não está isolado da alta disponibilidade em um ambiente virtual. No caso dos hosts de virtualização, a insuficiência de capacidade pode bloquear a alta disponibilidade no nível do farm e do host.
Assim como em outros aspectos de um ambiente virtual, como backup e recuperação, o gerenciamento da capacidade e a alta disponibilidade precisam acomodar duas camadas do ambiente virtual, que são as máquinas virtuais usadas para o SharePoint Server 2010 e os servidores físicos usados para hospedar essas máquinas virtuais. No caso de um ambiente híbrido, também pode ser necessário trabalhar com servidores de farm do Microsoft SharePoint Server.
Neste artigo:
Visão geral da virtualização
Gerenciamento da capacidade
Capacidade e dimensionamento do servidor de virtualização
Criando e refinando as arquiteturas
Opções adicionais para melhoria da arquitetura
Visão geral da virtualização O servidor de virtualização, implementado pelo Tecnologia Windows Server 2008 Hyper-V ou pelo Microsoft Hyper-V Server 2008, é baseado em hardware e também é mencionado como virtualização assistida por hardware, em contrapartida à virtualização assistida por software. O hipervisor do Hyper-V tem um caminho de comunicação para e de interação com os componentes de hardware do servidor mais direto do que as tecnologias de virtualização assistida por software. O resultado final é um desempenho melhor do que uma tecnologia de virtualização assistida por software. Para obter mais informações sobre a arquitetura do Hyper-V, consulte o documento sobre introdução ao Hyper-V do Windows Server 2008 (http://go.microsoft.com/fwlink/?linkid=188006&clcid=0x416) e o documento sobre monitoramento do desempenho do Hyper-V (http://go.microsoft.com/fwlink/?linkid=187746&clcid=0x416).
Embora um servidor físico possa atender aos requisitos do Hyper-V, cada servidor físico é único. Todo fabricante usa sua própria implementação de processadores, tecnologia multinuclear, memória, barramento de dados, discos rígidos e adaptadores de rede.
162
Além disso, o design do hardware e a implementação variam de modelo para modelo, mesmo que os modelos sejam produzidos pelo mesmo fabricante. Isso realça a necessidade de testes rigorosos ao implantar o SharePoint Server 2010 em um ambiente virtual.
Programas de software e aplicativos apresentam as mesmas variações de desempenho de hardware. Alguns programas fazem intensivo da CPU, outros demandam muita memória e outros fazem uso intensivo do disco rígido. O SharePoint Server tem suas próprias necessidades de capacidade, assim como o IIS (Internet Information Server) e o SQL Server 2008. Mais uma vez, testes rigorosos são necessários.
O gerenciamento da capacidade exige que você considere o servidor de virtualização, a solução de armazenamento, a infraestrutura de rede, as tecnologias em execução em um ambiente do SharePoint Server e os recursos habilitados ao implementar a sua solução do SharePoint Server.
Gerenciamento da capacidade O gerenciamento da capacidade amplia o conceito de planejamento de capacidade para expressar a abordagem cíclica em que a capacidade de uma implantação do SharePoint Server 2010 é continuamente monitorada e otimizada para acomodar as condições e os requisitos em constante transformação. Você pode aplicar essa abordagem a todos os farms do SharePoint Server, incluindo aqueles totalmente virtualizados e os que estejam parcialmente virtualizados. Para obter uma visão geral do gerenciamento de capacidade, consulte Capacity management and sizing for SharePoint Server 2010. Recursos adicionais de gerenciamento de capacidade podem ser encontrados na página sobre gerenciamento da capacidade do SharePoint Server 2010 (http://go.microsoft.com/fwlink/?linkid=194748&clcid=0x416), na Central de Recursos.
Capacidade e dimensionamento do servidor de virtualização Assim que tiver as recomendações de design e dimensionamento de um farm do SharePoint Server, você poderá projetar a arquitetura física do host de virtualização que é exigida para suporte ao farm virtual. Para obter mais informações sobre arquiteturas virtuais, consulte Planejar arquiteturas virtuais (SharePoint Server 2010).
É recomendável usar os princípios aplicáveis do gerenciamento de capacidade do SharePoint Server 2010 e usá-los como guia para um ambiente virtual. As seguintes atividades ilustram a natureza iterativa do design, dimensionamento e ajuste de uma arquitetura física no planejamento inicial da implantação em um ambiente de produção.
163
Observação:
Se você fizer todo o planejamento e teste, a arquitetura e as configurações de servidor
só precisarão ser alteradas se houver um aumento significativo e imprevisto no uso do
farm ou então porque novos recursos foram adicionados à sua solução do SharePoint
Server.
Antes de iniciar a implantação do farm, crie uma arquitetura virtual e física usando o
dimensionamento de máquina virtual e servidor de virtualização. No caso de vários
hosts de virtualização, essa arquitetura deverá incluir a distribuição de máquinas
virtuais.
Durante a fase piloto da implantação, colete dados de integridade e desempenho
que possam ser usados para estabelecer benchmarks para as máquinas virtuais e
os hosts de virtualização do farm.
Durante a fase de teste da implantação referente à aceitação do usuário, ajuste as
configurações do host de virtualização e da máquina virtual com base nos dados de
benchmark. Se necessário, altere a arquitetura física redistribuindo as máquinas
virtuais nos hosts de virtualização.
Após a implantação, continue a coletar benchmarks de integridade e desempenho e
a refinar a máquina virtual e, se aplicável, as configurações da máquina física. Se
necessário, ajuste as duas arquiteturas.
É muito importante que você possa analisar os dados de desempenho do host de virtualização e da máquina virtual e que, além disso, possa entender como isso se reflete nas necessidades de capacidade e os efeitos do aplicativo na capacidade. Você também precisa entender os limites de desempenho e capacidade. Devido à inter-relação entre a camada virtual e a camada física, tudo que afetar a capacidade da máquina virtual e o desempenho também terá efeito direto no host ou precisará ser acomodado por meio de alterações na configuração do host de virtualização para manter um desempenho aceitável no farm.
Em alguns casos, pode ser necessário alterar a arquitetura física adicionando mais hosts de virtualização e alterando a distribuição das máquinas virtuais na arquitetura física.
Importante:
Em testes de benchmark entre um computador físico e uma máquina virtual, a
produtividade da máquina virtual geralmente não coincide com a do computador físico. O
desempenho da máquina virtual é, com raras exceções, sempre menor do que o
desempenho do computador físico. O grau de diferença de desempenho depende dos
recursos do host de virtualização, dos aplicativos em execução e dos benchmarks
escolhidos para uso como principais indicadores de desempenho.
É recomendável ler o documento sobre desempenho do Hyper-V, em Perguntas Frequentes sobre o R2 (http://go.microsoft.com/fwlink/?linkid=187745&clcid=0x416), que foi atualizado para refletir as informações de capacidade e desempenho do Windows Server 2008 R2 e Windows Server 2008 com Service Pack 2 (SP2). Essa seção de
164
Perguntas Frequentes contém respostas para perguntas comuns referentes ao Hyper-V, fornece diretrizes e inclui links para artigos detalhados, que você pode usar para desenvolver benchmarks para host de virtualização, máquinas virtuais e rede do Windows.
Também é recomendável ler as seguintes publicações sobre contadores de desempenho do Hyper-V:
Contadores de desempenho do Hyper-V, parte um de muitas, visão geral
(http://go.microsoft.com/fwlink/?linkid=125651&clcid=0x416)
Contadores de desempenho do Hyper-V, parte dois de muitas, conjunto de
contadores "Hipervisor do Hyper-V"
(http://go.microsoft.com/fwlink/?linkid=125652&clcid=0x416)
Contadores de desempenho do Hyper-V, parte três de muitas, conjunto de
contadores "Processadores lógicos do hipervisor do Hyper-V"
(http://go.microsoft.com/fwlink/?linkid=125653&clcid=0x416)
Contadores de desempenho do Hyper-V, parte quatro de muitas, conjunto de
contadores "Processador virtual do hipervisor do Hyper-V" e "Processador virtual raiz
do hipervisor do Hyper-V"
(http://go.microsoft.com/fwlink/?linkid=125655&clcid=0x416)
Criando e refinando as arquiteturas Uma arquitetura completa consiste em hosts de virtualização, máquinas virtuais e máquinas físicas que compõem o ambiente do SharePoint Server a ser implantado. Para obter mais informações sobre arquiteturas de virtualização, consulte Planejar arquiteturas virtuais (SharePoint Server 2010).
O desenvolvimento e a implementação de uma arquitetura virtual consiste nestas etapas:
1. Criar a arquitetura virtual e física. Crie uma arquitetura para apoiar as metas do seu
farm do SharePoint Server 2010.
2. Analisar as arquiteturas. Identifique e obtenha todas as informações que estiverem
faltando ou que irão melhorar o design do ambiente a ser implantado.
3. Refinar as arquiteturas. Use as informações da etapa 2 para refinar a arquitetura.
4. Continue refinando a arquitetura e as configurações de servidor à medida que você
avança pelos vários estágios de implantação. Para obter mais informações sobre os
estágios de implantação, consulte os modelos Implantação de Produtos do
SharePoint 2010 e Produtos do SharePoint 2010: Processo de Virtualização,
disponíveis no artigo Diagramas técnicos (SharePoint Server 2010).
Criar a arquitetura
Crie um modelo de arquitetura que você possa usar como ferramenta de avaliação e ajuste das configurações de máquina virtual e host de virtualização. Use os critérios a seguir como guia para o desenvolvimento do modelo:
Identifique o número de máquinas virtuais necessárias e a função de cada uma
delas no farm do SharePoint Server.
165
Especifique os requisitos de cada máquina virtual (espaço em disco, memória e
número de processadores). Isso se baseia nos requisitos de capacidade do
SharePoint Server.
Especifique os requisitos do host de virtualização (espaço em disco, memória e
número de processadores). Isso se baseia nos requisitos da máquina virtual.
Identifique a distribuição das máquinas virtuais nos hosts de virtualização. Isso se
baseia nos requisitos de alta disponibilidade e é imposto pela quantidade e
capacidade de hosts de virtualização.
Identifique os requisitos gerais de rede e armazenamento.
Leve em consideração a expansão nos hosts de virtualização e nas máquinas
virtuais (aumento ou expansão).
Depois de criar um modelo de arquitetura, você precisará analisar as duas arquiteturas para validar o design e também as configurações de host de virtualização e máquina virtual.
Analisar as arquiteturas
O objetivo fundamental da análise de arquitetura é determinar se ela é compatível com êxito a solução do SharePoint Server 2010 a ser implantada. Entretanto, é aceitável pressupor que o design e as configurações de servidor serão alterados à medida que você avançar no processo de implantação.
A ilustração a seguir mostra um exemplo de arquitetura virtual para um farm composto de servidores Web front-end, servidores de aplicativos e servidores de banco de dados. Essa arquitetura representa os farms de pequeno a médio porte descritos no documento sobre Exemplo de arquiteturas virtuais para farms de pequeno a médio porte. Podemos usá-la para mostrar os principais elementos a serem considerados na análise dos requisitos de capacidade e disponibilidade de um farm virtual.
Importante:
O dimensionamento do servidor de virtualização e da máquina virtual na seguinte
ilustração não são uma determinação.
Figura 1. Arquitetura preliminar
166
Use os critérios fornecidos para a criação de uma arquitetura virtual para analisar a arquitetura de exemplo mostrada na ilustração anterior. A arquitetura da ilustração pressupõe que todos os servidores Web front-end e os servidores de aplicativos sejam
167
máquinas virtuais. Não foi determinado se os servidores de banco de dados do farm são máquinas físicas ou virtuais.
Análise do host de virtualização
As tabelas a seguir (HOST-1 e HOST-2) fornecem uma análise de cada host de virtualização e usam memória, processadores e escalabilidade como critérios. A análise do host é seguida por uma análise do design.
HOST-1
Critérios Análise
Memória Após a fatoração em 2 GB de RAM para o
sistema operacional do host e o uso dos
requisitos de RAM projetados, há uma
estimativa de 2 GB de RAM disponíveis
para uso futuro.
Processadores A lógica para mapeamento de processador
virtual é 8:10 (1:1,25), o que significa que a
CPU é ligeiramente superinscrita. Isso pode
não ser um problema em um ambiente de
teste.
Importante:
A superinscrição da CPU em um servidor de
virtualização reduz o desempenho global. A
extensão desse efeito é determinada pela
carga colocada nas máquinas virtuais.
Como prática recomendada, se possível,
não superinscreva a CPU do servidor de
virtualização.
Escalabilidade Isso não é uma opção porque não há
memória suficiente. Além disso, o grau de
superinscrição da CPU (mesmo adicionando
uma máquina virtual aos dois
processadores) pode provocar um efeito significativo no desempenho.
HOST-2
Critérios Análise
Memória Após a fatoração em 2 GB de RAM para o
168
Critérios Análise
sistema operacional do host e o uso dos requisitos de RAM projetados, há uma
estimativa de 6 GB de RAM disponíveis
para uso futuro.
Processadores A lógica para o mapeamento de
processador virtual é 8:8 (1:1), o que atende
à diretriz de prática recomendada.
Escalabilidade Há memória suficiente para aumentar a
alocação de memória nas máquinas virtuais.
Há capacidade suficiente para adicionar
uma nova máquina virtual aos dois
processadores de 4 GB de RAM. Isso
significa que a CPU do host de virtualização
pode ficar ligeiramente superinscrita (8:10), mas, assim como no HOST-1, isso pode
não ser um problema em um ambiente de
teste.
Análise de projetos
A arquitetura de exemplo geralmente mostra um grau de alta disponibilidade para os servidores do farm. Por exemplo, há três servidores Web front-end distribuídos no HOST-1 e no HOST-2, e os servidores de banco de dados (clusterizados ou espelhados) também residem em hosts de virtualização separados ou em servidores físicos separados. A alta disponibilidade no nível do host de virtualização não faz parte da arquitetura e não há informações pertinentes. As informações a seguir são necessárias para que o design possa ser revisado:
Tamanho do banco de dados
O tamanho do banco de dados de conteúdo determina como você configura e distribui todos os servidores do farm.
Subsistema de armazenamento
Por exemplo, na arquitetura de exemplo, nenhuma informação é fornecida sobre o número de discos necessários em cada máquina virtual nem há qualquer indicação de distribuição e capacidade de disco. Essas informações são muito importantes para determinar e configurar o sistema de armazenamento. A arquitetura de exemplo usa o armazenamento local. É preciso determinar se isso é adequado ao seu ambiente ou se você prefere usar uma configuração de disco de passagem para um LUN em uma SAN.
Requisitos de rede
O número de adaptadores de rede e a produtividade mínima precisam ser identificados.
Configurações de disco rígido virtual
Também é preciso determinar qual das configurações de disco rígido do Hyper-V você deseja usar (por exemplo, tamanho fixo, passagem). Para obter mais informações, consulte o documento sobre planejamento de discos e armazenamento
169
(http://go.microsoft.com/fwlink/?linkid=188007&clcid=0x416) e o documento sobre desempenho do disco rígido virtual: Windows Server 2008/Windows Server 2008 R2/Windows 7 (http://go.microsoft.com/fwlink/?linkid=186519&clcid=0x416).
Após a conclusão da revisão do design, a próxima etapa é refinar a arquitetura.
Refinar a arquitetura
O escopo de refinamento da arquitetura depende da arquitetura inicial, dos resultados da análise e do plano de implementação. Usando o exemplo fornecido, há cenários onde você pode decidir não fazer qualquer alteração. Por exemplo:
A arquitetura preliminar é adequada ao teste inicial, verificação de conceito e
implantação piloto limitada.
Os hosts de virtualização são somente para teste e serão substituídos por hosts com
capacidade maior durante a fase de teste de aceitação do usuário.
O farm virtual é somente para teste e será desligado após a conclusão do teste. Em
alguns casos, o ambiente pode ser preservado e utilizado posteriormente para testar
atualizações de software.
A ilustração a seguir mostra uma arquitetura revisada, que é mais adequada a um farm de produção.
Figura 2. Arquitetura revisada
170
Na arquitetura revisada, a principal hipótese é a de que você queira manter oito servidores de virtualização de mercadoria centrais. As alterações na ilustração precedente reflete essa hipótese e inclui estas considerações:
171
O tamanho estimado do banco de dados de conteúdo é de 1 TB (terabyte).
O objetivo é fornecer alta disponibilidade para todos os servidores do farm e
maximizar o desempenho na infraestrutura.
Os servidores de banco de dados são servidores físicos que podem ser
clusterizados ou espelhados para apoiar a alta disponibilidade. Cada servidor tem 8
núcleos, 16 GB de RAM e usa unidades para reduzir a latência.
Análise do host de virtualização
As tabelas a seguir (HOST-1 e HOST-2 revisadas) fornecem uma análise de cada host de virtualização e usam memória, processadores e escalabilidade como critérios. A análise do host é seguida por uma análise do design.
HOST-1 revisada
Critérios Análise
Memória Após a fatoração em 2 GB de RAM para o
sistema operacional do host e o uso dos
requisitos de RAM projetados, há uma
estimativa de 2 GB de RAM disponíveis
para uso futuro.
Processadores A lógica para o mapeamento de
processador virtual é 8:10 (1:1,25), o que
implica uma ligeira superinscrição.
Escalabilidade Há uma margem de memória disponível
para aumentar a alocação de memória para
as máquinas virtuais. Com base na
quantidade de memória e na razão do
processador, não há capacidade de host
suficiente para adicionar mais uma máquina
virtual.
HOST-2 revisada
Critérios Análise
Memória Após a fatoração em 2 GB de RAM para o
sistema operacional do host e o uso dos
requisitos de RAM projetados, há uma
estimativa de 4 GB de RAM disponíveis
para uso futuro.
Processadores A lógica para o mapeamento de
processador virtual é 8:12 (1:1,50), o que
implica uma superinscrição de 50%.
Escalabilidade Há uma margem de memória disponível
172
Critérios Análise
para aumentar a alocação de memória para
as máquinas virtuais. Com base na
quantidade de memória e na razão do
processador, não há capacidade de host
suficiente para adicionar mais uma máquina
virtual.
Análise de projetos
Cada máquina virtual usa uma configuração de três unidades, dimensionadas de
acordo com a diretriz de práticas recomendadas do SharePoint Server. Essas
unidades geralmente são configuradas da seguinte forma:
Unidade C (50 GB) para instalação do Windows
Unidade D (50 GB) para arquivos do SharePoint Server 2010
Unidade E (300 GB) conteúdo da Web e arquivos de log
Cada servidor Web front-end é configurado com quatro processadores virtuais
(4xVP) e 8 GB de RAM. Esta é a configuração mínima recomendada para um
ambiente de produção.
O número de servidores Web front-end é aumentado para quatro para suportar a
clusterização e a alta disponibilidade efetivas. Essa configuração de quatro
servidores é particularmente adequada à instalação de atualizações de software,
pois sempre haverá dois servidores disponíveis durante a instalação das
atualizações.
Os dois servidores de aplicativos (App-1, App-2) fornecem alta disponibilidade. O
App-1 hospeda a Administração Central, o componente Rastreamento de pesquisa e
o índice passivo do componente Consulta de pesquisa. O número de processadores
e a quantidade de memória são baseados no tamanho estimado do banco de dados
de conteúdo.
App-2 é um servidor dedicado de consulta de pesquisa. Ele também contém uma cópia da Administração Central. O número de processadores e a quantidade de memória são baseados no tamanho estimado do banco de dados de conteúdo.
Para alta disponibilidade, a Administração Central também é instalada em um
servidor Web front-end em outro host.
Os servidores de banco de dados são servidores físicos que são clusterizados ou
espelhados para garantir a alta disponibilidade. Essa mudança para servidores
físicos traz os benefícios de aumentar a capacidade do host de virtualização para os
servidores de farm virtuais e melhorar o desempenho global do banco de dados.
Observação:
Como indicado anteriormente neste artigo, a decisão de virtualizar ou não os servidores
de banco de dados é complexa e exige muito planejamento e teste.
Do ponto de vista da rede, os dois hosts de virtualização são configurados com dois
adaptadores de rede físicos e separados, de 1 gigabit. Essa é uma prática
recomendada para garantir que o tráfego de dados no host de virtualização e na
173
máquina virtual fique separado, visando melhorar o desempenho e fornecer alguma
redundância de adaptador.
Cada host de virtualização utiliza uma VLAN (LAN virtual) que fornece os seguintes
benefícios: segregação de rede, segurança e desempenho melhorados.
A arquitetura virtual e física revisada é consideravelmente melhorada e pode ser implantada em um ambiente de produção. Entretanto, é importante observar que, quando configurados, os recursos disponíveis do host de virtualização não aceitam o dimensionamento do farm. Além disso, não são compatíveis com a migração de um servidor de farm de um host para outro, caso surja essa necessidade.
Na realidade, se você quiser implantar o farm de exemplo na produção, é recomendável considerar estas atualizações:
Aumente a capacidade do host de virtualização usando um computador de 16
núcleos com 48 ou 64 gigabytes de RAM.
Adicione um ou mais hosts de virtualização.
Para obter o nível ideal de alta disponibilidade, considere as opções adicionais da seção a seguir.
Opções adicionais para melhoria da arquitetura A seção anterior forneceu opções para revisão do modelo. Há, é claro, outras opções para obter melhor desempenho e alta disponibilidade. A expansão do ambiente de host de virtualização ou o aumento dos hosts de virtualização são boas alternativas, embora os custos sejam sempre um problema. A estratégia de virtualização da sua organização ajudará a definir a melhor abordagem.
Dica:
Em termos de custos, comprar um servidor que tenha mais capacidade do que a
necessária em curto prazo é menos dispendioso do que atualizar um servidor para
ganhar mais capacidade. Isso é especialmente verdadeiro no caso de atualizações de
memória, o que geralmente implica jogar fora os módulos de memória existentes e
comprar um conjunto completo de memória nova para atualizá-la.
Ganhos de desempenho podem ser obtidos com estas opções:
Implante ou compre servidores com processadores SLAT (Second-Level Address
Translation) habilitados. Em processadores Intel, esse recurso é mencionado como
Nested Page Tables (tabelas de páginas aninhadas) e está disponível nos
processadores da série Nehalem 55xx. Para AMD, o recurso é mencionado como
EPT (Enhanced Page Tables, tabelas de páginas aprimoradas).
Implante ou compre servidores que forneçam Estacionamento do Núcleo de CPU,
um recurso que permite que o Hyper-V em execução use o menor número de
núcleos de processador para atender à demanda de carga de trabalho.
174
Investigue o descarregamento de chimney de TCP, as VMQ (Filas da Máquina
Virtual) e os quadros jumbo. Esses recursos melhoram o desempenho da rede e
reduzem a utilização da CPU, aumentando assim a capacidade global do sistema.
Investigue o suporte a quadros jumbo para acelerar o desempenho de rede ao
transferir grandes volumes de dados. Entretanto, é preciso testar isso totalmente,
pois quadros jumbo não funcionam em todos os ambientes.
Investigue a junção do adaptador. Esse recurso pode melhorar o desempenho de
rede e fornecer recurso de failover aos adaptadores de rede físicos.
Importante:
A junção de adaptador é uma solução terceirizada e com suporte apenas pelo
fornecedor. Para obter mais informações, consulte o documento sobre a política de
suporte da Microsoft para NIC Teaming com Hyper-V (http://go.microsoft.com/fwlink/?linkid=194749&clcid=0x416).
Para garantir a alta disponibilidade de um ambiente virtual, considere a implementação de clusterização de failover do Windows Server 2008 R2 e a migração dinâmica do Hyper-V, da seguinte maneira:
O escopo da clusterização de failover pode incluir hosts de virtualização e máquinas
virtuais em cada host. Se um host de virtualização falhar inesperadamente, as
máquinas virtuais farão failover automaticamente em outro host de virtualização.
A migração dinâmica é uma solução de tempo de inatividade planejado. Você pode
migrar as máquinas virtuais em execução para outro servidor (sem tempo de
inatividade), desligar o servidor físico e executar a manutenção. Quando concluir a
manutenção no servidor, use a migração dinâmica para mover as máquinas virtuais
de volta ao servidor físico original.
Para obter mais informações, consulte o documento sobre Hyper-V: como usar o Hyper-V e a clusterização de failover (http://go.microsoft.com/fwlink/?linkid=187967&clcid=0x416) e o documento sobre Hyper-V: como usar a migração dinâmica com volumes compartilhados de cluster no Windows Server 2008 R2 (http://go.microsoft.com/fwlink/?linkid=188009&clcid=0x416).
175
Planejar autenticação (SharePoint Server 2010)
Nesta seção:
Planejar métodos de autenticação (SharePoint Server 2010)
Plan for claims authentication (SharePoint Server 2010)
Planejar o Serviço de Repositório Seguro (SharePoint Server 2010)
176
Planejar métodos de autenticação (SharePoint Server 2010)
Este artigo descreve os métodos e os modos de autenticação aceitos pelo Microsoft SharePoint Server 2010. Autenticação é o processo de validação da identidade de um usuário. Após essa validação, o processo de autorização determina quais sites, conteúdo e outros recursos o usuário pode acessar. Modos de autenticação determinam como as contas são usadas internamente pelo SharePoint Server 2010.
Neste artigo:
Modos de autenticação — clássico ou baseado em declarações
Implementando a autenticação baseada em formulários
Implementando a autenticação baseada em tokens de SAML
Escolhendo a autenticação para ambientes LDAP
Implementando a autenticação baseada em tokens de SAML
Escolhendo a autenticação para ambientes LDAP
Planejando zonas para aplicativos Web
Arquitetura para provedores baseados em tokens de SAML
Métodos de autenticação com suporte O SharePoint Server 2010 dá suporte a métodos de autenticação incluídos em versões anteriores e também introduz a autenticação baseada em tokens, que tem como base o protocolo SAML (Security Assertion Markup Language) como opção. A tabela a seguir lista os métodos de autenticação com suporte.
Método Exemplos Observações
Windows NTLM
Kerberos
Anônima
Básica
Digest
Neste momento,
não há suporte
para a autenticação de
certificados do Windows.
Autenticação baseada em
formulários
Protocolo LDAP
Banco de dados SQL ou
outros bancos de dados
Provedores de associações e
de funções personalizados ou
177
Método Exemplos Observações
de terceiros
Autenticação baseada em tokens
SAML
Serviços de Federação do
Active Directory (AD FS) 2.0
Provedor de identidade de
terceiros
Protocolo LDAP
Só tem suporte
com o SAML 1.1, que usa o protocolo WS-F PRP.
Modos de autenticação — clássico ou baseado em declarações O SharePoint Server 2010 introduz a autenticação baseada em declarações, que tem como base o Windows Identity Foundation (WIF). Você pode usar qualquer um dos métodos de autenticação com suporte que possua autenticação baseada em declarações. Também pode usar a autenticação de modo clássico, que dá suporte à autenticação do Windows.
Ao criar um aplicativo Web, selecione um dos dois métodos de autenticação para uso com esse aplicativo: clássico ou baseado em declarações.
Se você selecionar o modo clássico, poderá implementar a autenticação do Windows. As contas de usuário serão tratadas pelo SharePoint Server 2010 como contas do AD DS (Serviços de Domínio Active Directory).
178
Se você selecionar a autenticação baseada em declarações, o SharePoint Server 2010 transformará automaticamente todas as contas de usuário em identidades de declarações, resultando em um token de declarações para cada usuário. O token de declarações contém as declarações que pertencem ao usuário. As contas do Windows serão convertidas em declarações do Windows. Os usuários associados baseados em formulários serão transformados em declarações de autenticação com base em formulários. As declarações incluídas em tokens baseados em SAML poderão ser usadas pelo SharePoint Server 2010. Além disso, os desenvolvedores e administradores do SharePoint poderão aumentar os tokens de usuário com mais declarações. Por exemplo, as contas de usuário do Windows e as contas baseadas em formulários poderão ser aumentadas com mais declarações usadas pelo SharePoint Server 2010.
O gráfico a seguir resume o suporte aos tipos de autenticação por cada modo de autenticação.
Tipo Autenticação de modo clássico Autenticação
baseada em
declarações
Windows
NTLM
Kerberos
Anônima
Básica
Digest
Sim Sim
Autenticação baseada em
formulários
LDAP
Banco de dados SQL ou outros
bancos de dados
Provedores de associações e
de funções personalizados ou
de terceiros
Não Sim
Autenticação baseada em tokens
de SAML
AD FS 2.0
Windows Live ID
Provedor de identidade de
terceiros
LDAP
Não Sim
179
Um farm do SharePoint Server 2010 pode incluir uma combinação de aplicativos Web que usam ambos os modos. Os serviços não diferenciam entre contas de usuário que sejam contas tradicionais do Windows e contas de declarações do Windows. Consequentemente, um usuário que pertença a sites configurados para usarem uma combinação de modos de autenticação obterá resultados de pesquisa de todos os sites aos quais tenha acesso, independentemente do modo configurado para aplicativos Web. O usuário não é interpretado como duas contas de usuário diferentes. Isso ocorre porque os serviços e os aplicativos de serviço usam identidades de declarações para comunicação entre farms, independentemente do modo selecionado para aplicativos Web e usuários.
Entretanto, os usuários que pertencem a mais de um repositório de usuários reconhecido por aplicativos Web do SharePoint Server são tratados como contas de usuário separadas, dependendo da identidade usada para fazer logon.
A seguinte diretriz poderá ajudá-lo a decidir qual modo selecionar:
Para novas implementações do SharePoint Server 2010, use a autenticação
baseada em declarações. Com essa opção, todos os tipos de autenticação com
suporte estarão disponíveis para aplicativos Web. Não há nenhuma razão prática
para selecionar a autenticação de modo clássico para novas implantações, mesmo
que o ambiente inclua somente contas do Windows. A autenticação do Windows é
implementada da mesma forma, independentemente do modo selecionado. Não há
etapas adicionais para implementar a autenticação do Windows quando o modo de
autenticação baseado em declarações é usado.
Se você estiver atualizando uma solução de versão anterior para o SharePoint
Server 2010 e essa solução só incluir contas do Windows, será possível usar a
autenticação de modo clássico. Isso permite usar o mesmo design para zonas e
URLs.
Se você estiver atualizando uma solução que exija autenticação baseada em
formulários, a única opção será atualizar para a autenticação baseada em
declarações.
Se você estiver atualizando de uma versão anterior para o SharePoint Server 2010 e selecionar a autenticação baseada em declarações, tenha em mente as seguintes considerações:
O código personalizado talvez precise ser atualizado. As Web Parts ou outro código
personalizado, que dependa ou utilize identidades do Windows, deverão ser
atualizados. Se o código personalizado usar identidades do Windows, use a
autenticação de modo clássico até que o código seja atualizado.
A migração de muitos usuários do Windows para identidades de declarações é
demorada. Quando você alterar um aplicativo Web do modo clássico para o modo
baseado em declarações durante o processo de atualização, deverá usar o Windows
PowerShell para converter identidades do Windows em identidades de declarações.
Esse processo pode ser lento. Verifique se há tempo suficiente durante o processo
de atualização para concluir a tarefa.
Alertas de pesquisa não têm suporte atualmente com a autenticação baseada em
declarações.
A autenticação de declarações tem como base o WIF. O WIF é um conjunto de classes do .NET Framework que são usadas para implementar a identidade baseada em declarações. A autenticação de declarações depende de padrões, como o WSF e o WS-
180
Trust, e de alguns protocolos, como o SAML. Para obter mais informações sobre a autenticação de declarações, consulte os seguintes recursos:
Identidade baseada em declarações para Windows: uma introdução ao Active
Directory Federation Services 2.0, ao Windows CardSpace 2.0 e ao Windows
Identity Foundation (white paper)
(http://go.microsoft.com/fwlink/?linkid=198942&clcid=0x416)
Home page do Windows Identity Foundation
(http://go.microsoft.com/fwlink/?linkid=198943&clcid=0x416)
Não é necessário ser um arquiteto de declarações para usar a autenticação de declarações no SharePoint Server 2010. Entretanto, a implementação de autenticação baseada em tokens de SAML requer coordenação com os administradores do ambiente baseado em declarações, conforme descrito posteriormente neste artigo.
Implementando a autenticação do Windows O processo de implementação de métodos de autenticação do Windows é semelhante para ambos os modos de autenticação (clássico ou baseado em declarações). A escolha da autenticação baseada em declarações para um aplicativo Web não aumenta a complexidade da implementação de métodos de autenticação do Windows. Esta seção resume o processo para cada método.
Autenticação integrada do Windows — Kerberos e NTLM
O protocolo Kerberos e o protocolo NTLM são métodos de autenticação integrada do Windows, que permitem aos clientes autenticar de forma simplificada, sem a necessidade de fornecer credenciais. Os usuários que acessarem sites do SharePoint via Windows Explorer serão autenticados usando as credenciais com as quais o processo do Internet Explorer estiver sendo executado. Por padrão, essas credenciais são aquelas usadas para fazer logon no computador. Os serviços ou aplicativos que acessarem o SharePoint Server no modo de autenticação integrada do Windows tentarão autenticar usando as credenciais do thread em execução, que é a identidade do processo por padrão.
O NTLM é a forma mais simples de implementar a autenticação do Windows. Basta selecionar essa opção quando você estiver criando um aplicativo.
O protocolo Kerberos é um protocolo seguro que dá suporte à autenticação de tíquete. O uso do protocolo Kerberos requer a configuração adicional do ambiente. Para habilitar a autenticação Kerberos, os computadores cliente e servidor devem ter uma conexão confiável com o KDC (Centro de Distribuição de Chaves) do domínio. A configuração do protocolo Kerberos envolve a configuração de SPNs (nomes da entidade de serviço) no AD DS antes da instalação do SharePoint Server 2010.
As etapas a seguir resumem o processo de configuração da autenticação Kerberos:
1. Configure a autenticação Kerberos para comunicações SQL criando SPNs no AD DS
para a conta de serviço do SQL Server.
2. Crie SPNs para aplicativos Web que usarão a autenticação Kerberos.
3. Instale o farm do SharePoint Server 2010.
4. Configure serviços específicos no farm para usar contas específicas.
5. Crie os aplicativos Web que usarão a autenticação Kerberos.
181
Para obter mais informações, consulte Configure Kerberos authentication (SharePoint Server 2010).
Adicionalmente, para aplicativos Web com autenticação de declarações, as declarações para o serviço de token do Windows devem ser configuradas para delegação restrita. A delegação restrita é necessária para a conversão de declarações em tokens do Windows. Para ambientes que incluem várias florestas, uma confiança bidirecional entre florestas é necessária para o uso das declarações no serviço de token do Windows. Para obter mais informações sobre como configurar esse serviço, consulte Configure Kerberos authentication for the claims to Windows token service (SharePoint Server 2010).
A autenticação Kerberos permite a delegação de credenciais de cliente para acessar sistemas de dados back-end, o que requer configuração adicional dependendo do cenário. A tabela a seguir apresenta exemplos.
Cenário Configuração adicional
Delegando uma identidade do cliente a um servidor back-end.
Exibindo RSS feeds para conteúdo
autenticado.
Configure a delegação restrita de Kerberos
para computadores e contas de serviço.
Delegação de identidades para o Microsoft
SQL Server Reporting Services (SSRS)
Configure SPNs para contas do SQL Server Reporting Services.
Configure a delegação para o SQL Server
Reporting Services.
Delegação de identidades para o Serviços
do Excel no SharePoint
Configure a delegação restrita para
servidores que executam os Serviços do
Excel.
Configure a delegação restrita para a conta
de serviço dos Serviços do Excel.
Para obter mais informações sobre como configurar a autenticação Kerberos, incluindo as etapas de configuração de cenários comuns, consulte o artigo sobre configuração da autenticação Kerberos para Produtos e Tecnologias do Microsoft SharePoint 2010 (white paper) (http://go.microsoft.com/fwlink/?linkid=197178&clcid=0x416).
Digest e Básica
A implementação da autenticação Digest e Básica requer a configuração desses métodos de autenticação diretamente no IIS (Serviços de Informações da Internet).
Implementando a autenticação baseada em formulários A autenticação baseada em formulários é um sistema de gerenciamento de identidades que se baseia na autenticação de provedores de função e associação ASP.NET. No SharePoint Server 2010, a autenticação baseada em formulários só está disponível quando a autenticação baseada em declarações é usada.
182
A autenticação baseada em formulários pode ser usada com credenciais armazenadas no AD DS, em um banco de dados, como um banco de dados do SQL Server, ou em um repositório de dados LDAP, como o Novell eDirectory, o NDS (Novell Directory Services) ou o Sun ONE. A autenticação baseada em formulários permite a autenticação de usuários com base na validação da entrada de credenciais de um formulário de logon. As solicitações não autenticadas são redirecionadas para uma página de logon, onde o usuário deve fornecer credenciais válidas e enviar o formulário. Se a solicitação puder ser autenticada, o sistema emitirá um cookie que contém uma chave para restabelecer a identidade de solicitações subsequentes.
Para usar a autenticação baseada em formulários de forma a autenticar usuários em um sistema de gerenciamento de identidades que não se baseie no Windows ou que seja externo, registre o provedor de associação e o gerenciador de funções no arquivo Web.config. O registro do gerenciador de funções é um novo requisito do SharePoint Server 2010. Na versão anterior, isso era opcional. O SharePoint Server 2010 usa a interface padrão do gerenciador de funções ASP.NET para coletar informações de grupos sobre o usuário atual. Cada função ASP.NET é tratada como um grupo de domínios pelo processo de autorização no SharePoint Server 2010. Registre os gerenciadores de funções no arquivo Web.config da mesma forma que você registra os provedores de associação para autenticação.
Para gerenciar usuários associados ou funções no site da Administração Central do SharePoint, você deve registrar o provedor de associação e o gerenciador de funções no arquivo Web.config do site da Administração Central. Também é necessário registrar o provedor de associação e o gerenciador de funções no arquivo Web.config do aplicativo Web que hospeda o conteúdo.
Para obter mais informações sobre como configurar a autenticação baseada em formulários, consulte os seguintes recursos:
Artigo do TechNet: Configure forms-based authentication for a claims-based Web
application (SharePoint Server 2010)
Artigo de blog do MSDN sobre autenticação baseada em declarações "Cheat Sheet"
(Parte 1) (http://go.microsoft.com/fwlink/?linkid=198944&clcid=0x416)
Artigo do MSDN sobre autenticação de formulários em Produtos e Tecnologias do
SharePoint (Parte 2): exemplos de provedores de função e associação
(http://go.microsoft.com/fwlink/?linkid=198945&clcid=0x416)
Implementando a autenticação baseada em tokens de SAML A autenticação baseada em tokens de SAML requer coordenação com os administradores de um ambiente baseado em declarações, seja o seu próprio ambiente interno ou um ambiente de parceiro. O AD FS 2.0 é um exemplo de ambiente baseado em declarações.
Um ambiente baseado em declarações inclui um IP-STS (serviço de token de segurança de provedor de identidade). O IP-STS emite tokens de SAML em nome dos usuários que estão incluídos no diretório de usuários associado. Os tokens podem incluir qualquer número de declarações sobre um usuário, como um nome de usuário e os grupos aos quais esse usuário pertence.
183
O SharePoint Server 2010 aproveita as vantagens das declarações incluídas em tokens fornecidos por um IP-STS para autorizar usuários. Em ambientes de declarações, um aplicativo que aceita tokens de SAML é conhecido como RP-STS (STS de terceira parte confiável). Um aplicativo de terceira parte confiável recebe o token de SAML e usa as declarações nele contidas para decidir se concede ao cliente acesso ao recurso solicitado. No Produtos do SharePoint 2010, cada aplicativo Web configurado para usar um provedor SAML é adicionado ao servidor IP-STS como uma entrada RP-STS separada. Um farm do SharePoint pode incluir várias entradas RP-STS.
A implementação da autenticação baseada em tokens de SAML com o Produtos do SharePoint 2010 envolve os seguintes processos de planejamento avançado:
1. Exportar o certificado de autenticação de tokens do IP-STS. Esse certificado é
conhecido como ImportTrustCertificate. Copie o certificado para um computador
servidor no farm do SharePoint Server 2010.
2. Definir a declaração que será usada como o identificador exclusivo do usuário. Isso
é conhecido como a declaração da identidade. Muitos exemplos desse processo
usam o nome de email do usuário como identificador exclusivo. Coordene-se com o
administrador do IP-STS para determinar o identificador correto, pois somente o
proprietário do IP-STS sabe o valor no token que será sempre exclusivo por usuário.
A identificação do identificador exclusivo do usuário faz parte do processo de
mapeamento de declarações. Mapeamentos de declarações são criados com o
Windows PowerShell.
3. Definir mapeamentos de declarações adicionais. Defina as declarações adicionais
do token de entrada que serão usadas pelo farm do SharePoint Server 2010. As
funções de usuário são um exemplo de declaração que pode ser usada para
recursos de permissão no farm do SharePoint Server 2010. Todas as declarações
de um token de entrada que não possuam um mapeamento serão descartadas.
4. Criar um novo provedor de autenticação via Windows PowerShell para importar o
certificado de autenticação de tokens. Esse processo cria
SPTrustedIdentityTokenIssuer. Durante esse processo, especifique a declaração de
identidade e as declarações adicionais que você mapeou. Será também necessário
criar e especificar um realm associado ao primeiro aplicativo Web do SharePoint que
está sendo configurado para autenticação baseada em tokens de SAML. Após a
criação de SPTrustedIdentityTokenIssuer, será possível criar e adicionar mais
realms a outros aplicativos Web do SharePoint. É assim que se configuram vários
aplicativos Web para usar o mesmo SPTrustedIdentityTokenIssuer.
5. Para cada realm adicionado a SPTrustedIdentityTokenIssuer, é necessário criar uma
entrada RP-STS no IP-STS. Isso pode ser feito antes que o aplicativo Web do
SharePoint seja criado. De qualquer forma, planeje a URL antes de criar os
aplicativos Web.
6. Criar um novo aplicativo Web do SharePoint e configurá-lo para usar o provedor de
autenticação recém-criado. O provedor de autenticação será exibido como opção na
Administração Central quando o modo de declarações estiver selecionado para o
aplicativo Web.
É possível configurar vários provedores de autenticação baseada em tokens de SAML. Entretanto, você só pode usar um certificado de autenticação de tokens uma única vez em um farm. Todos os provedores configurados serão exibidos como opções na
184
Administração Central. Declarações de diferentes ambientes STS confiáveis não entrarão em conflito.
Se você estiver implementando a autenticação baseada em tokens de SAML com uma empresa parceira e seu próprio ambiente incluir um IP-STS, convém trabalhar com o administrador do seu ambiente interno de declarações para estabelecer uma relação confiável do IP-STS interno com o STS parceiro. Essa abordagem não requer a adição de outro provedor de autenticação ao farm do SharePoint Server 2010. Ela também permite que seus administradores de declarações gerenciem todo o ambiente de declarações.
Observação:
Se você usar a autenticação baseada em tokens de SAML com o AD FS em um farm do
SharePoint Server 2010 que tenha vários servidores Web em uma configuração de
balanceamento de carga, o desempenho e a funcionalidade da exibição de páginas da
Web do cliente poderão ser afetados. Quando o AD FS fornece o token de autenticação
ao cliente, esse token é submetido ao SharePoint Server 2010 para cada elemento de
página com permissão restrita. Se a solução de balanceamento de carga não estiver
usando afinidade, cada elemento protegido será autenticado em mais de um servidor do
SharePoint Server 2010, o que pode resultar na rejeição do token. Após o token ser
rejeitado, o SharePoint Server 2010 redirecionará o cliente para reautenticação no
servidor AD FS. Depois disso, um servidor AD FS poderá rejeitar várias solicitações feitas
em um período de tempo curto. Esse comportamento serve originalmente para proteger
contra um ataque de negação de serviço. Se o desempenho for negativamente afetado
ou se as páginas não forem carregadas completamente, considere definir o
balanceamento de carga para uma única afinidade. Isso isola as solicitações feitas aos
tokens de SAML em um único servidor Web.
Para obter mais informações sobre como configurar a autenticação baseada em tokens de SAML, consulte os seguintes recursos:
Artigo do TechNet: Configure authentication using a SAML security token
(SharePoint Server 2010)
Artigo de blog do MSDN sobre autenticação baseada em declarações "Cheat Sheet"
(Parte 2) (http://go.microsoft.com/fwlink/?linkid=198946&clcid=0x416)
Artigo de blog do TechNet sobre considerações de planejamento da autenticação
baseada em declarações no SharePoint 2010
(http://go.microsoft.com/fwlink/?linkid=198947&clcid=0x416)
Artigo de blog do TechNet sobre a criação de uma declaração de identidade e
função para um aplicativo de autenticação de declarações do SharePoint 2010
(http://go.microsoft.com/fwlink/?linkid=198948&clcid=0x416)
Artigo de blog do TechNet sobre como criar vários aplicativos Web de autenticação
de declarações em um único farm do SharePoint 2010
(http://go.microsoft.com/fwlink/?linkid=198949&clcid=0x416)
185
Escolhendo a autenticação para ambientes LDAP Ambientes LDAP podem ser implementados por autenticação baseada em formulários ou por autenticação baseada em tokens de SAML. É recomendável usar a autenticação baseada em formulários porque ela é menos complexa. Entretanto, se o ambiente incluir suporte para WS-Federation 1.1 e SAML Token 1.1, convém usar o SAML. A sincronização de perfis não tem suporte em provedores LDAP que não estejam associados ao ADFS 2.0.
Planejando zonas para aplicativos Web Zonas representam diferentes caminhos lógicos para ganhar acesso aos mesmos sites em um aplicativo Web. Cada aplicativo Web pode incluir até cinco zonas. Quando um aplicativo Web é criado, a zona padrão é criada. Para criar zonas adicionais, estenda o aplicativo Web e selecione um dos nomes de zona restantes: intranet, extranet, Internet ou personalizado.
Em versões anteriores, zonas são usadas para implementar diferentes tipos de autenticação para usuários provenientes de diferentes redes ou provedores de autenticação. Na versão atual, a autenticação de declarações permite que vários tipos de autenticação sejam implementados na mesma zona.
O planejamento de zonas depende de qual dos modos a seguir será selecionado para um aplicativo Web:
Modo clássico — de maneira semelhante às versões anteriores, somente um tipo de
autenticação pode ser implementado por zona. Entretanto, na versão atual, somente
a autenticação do Windows pode ser implementada quando o modo clássico é
selecionado. Consequentemente, várias zonas podem ser usadas somente para
implementar vários tipos de autenticação do Windows ou para implementar o mesmo
tipo de autenticação do Windows em diferentes repositórios do Active Directory.
Autenticação de declarações — vários provedores de autenticação podem ser
implementados em uma única zona. Várias zonas também podem ser usadas.
Implementando mais de um tipo de autenticação em uma única zona
Se você estiver usando a autenticação de declarações e implementando mais de um tipo de autenticação, convém implementar vários tipos de autenticação na zona padrão. Isso resulta na mesma URL para todos os usuários.
Quando você estiver implementando vários tipos de autenticação na mesma zona, as seguintes restrições serão aplicáveis:
Somente uma instância da autenticação baseada em formulários pode ser
implementada em uma zona.
A Administração Central permite usar um método de autenticação integrada do
Windows e a autenticação básica ao mesmo tempo. Caso contrário, não será
possível implementar mais de um tipo de autenticação do Windows em uma zona.
Se vários provedores de autenticação baseada em tokens de SAML forem configurados para um farm, todos eles serão exibidos como opções quando você criar um aplicativo Web ou uma nova zona. Vários provedores de SAML podem ser configurados na mesma zona.
186
O diagrama a seguir ilustra vários tipos de autenticação implementados na zona padrão de um site de colaboração de parceiro.
No diagrama, usuários de diferentes repositórios de diretórios acessam o site de parceiro
187
usando a mesma URL. Uma caixa tracejada ao redor das empresas parceiras mostra a relação entre o diretório do usuário e o tipo de autenticação configurado na zona padrão. Para obter mais informações sobre esse exemplo de design, consulte Exemplo de design: implantação corporativa (SharePoint Server 2010).
Planejando o rastreamento de conteúdo
O componente de rastreamento requer acesso ao conteúdo usando NTLM. Pelo menos uma zona deve ser configurada para usar a autenticação NTLM. Se a autenticação NTLM não estiver configurada na zona padrão, o componente de rastreamento poderá usar outra zona que esteja configurada para usar essa autenticação.
Implementando mais de uma zona
Se você pretende implementar mais de uma zona para um aplicativo Web, siga estas diretrizes:
Use a zona padrão para implementar as configurações de autenticação mais
seguras. Se não for possível associar uma solicitação a uma zona específica, as
configurações de autenticação e outras políticas de segurança da zona padrão serão
aplicadas. A zona padrão é aquela gerada na criação inicial de um aplicativo Web.
Geralmente, as configurações de autenticação mais seguras são as criadas para
acesso do usuário final. Consequentemente, os usuários finais podem acessar a
zona padrão.
Use o número mínimo de zonas necessárias para fornecer acesso aos usuários.
Cada zona é associada a um novo site e domínio do IIS para acessar o aplicativo
Web. Adicione novos pontos de acesso somente quando forem necessários.
Verifique se há pelo menos uma zona configurada para usar a autenticação NTLM
para o componente de rastreamento. Não crie uma zona dedicada para o
componente de índice se ela não for necessária.
O diagrama a seguir ilustra várias zonas que são implementadas para acomodar diferentes tipos de autenticação para um site de colaboração de parceiro.
188
No diagrama, a zona padrão é usada para funcionários remotos. Cada zona tem uma URL diferente associada. Os funcionários utilizam uma zona diferente dependendo de onde estão trabalhando: no escritório ou remotamente. Para obter mais informações
189
sobre esse exemplo de design, consulte Exemplo de design: implantação corporativa (SharePoint Server 2010).
Arquitetura para provedores baseados em tokens de SAML A arquitetura para implementar provedores baseados em tokens de SAML inclui os seguintes componentes:
Serviço de token de segurança do SharePoint Esse serviço cria os tokens de SAML que são utilizados pelo farm. O serviço é automaticamente criado e iniciado em todos os servidores de um farm. Ele é usado para comunicação entre farms, pois toda essa comunicação usa a autenticação de declarações. Ele também é utilizado para métodos de autenticação implementados para aplicativos Web que usam autenticação de declarações, incluindo a autenticação do Windows, a autenticação baseada em formulários e a autenticação baseada em tokens de SAML. Você deve configurar o serviço de token de segurança durante o processo de implantação. Para obter mais informações, consulte Configure the security token service (SharePoint Server 2010).
Certificado de autenticação de tokens (ImportTrustCertificate) Esse é o certificado que é exportado de um IP-STS. O certificado é copiado para um servidor no farm. Após usar o certificado para criar um SPTrustedIdentityTokenIssuer, você não pode usá-lo novamente para criar outro. Se quiser usar o certificado para criar outro SPTrustedIdentityTokenIssuer, primeiro você deverá excluir aquele já existente. Antes da exclusão, você deve desassociá-lo de todos os aplicativos Web que o estejam utilizando.
Declaração de identidade A declaração de identidade é a declaração originada de um token de SAML que é o identificador exclusivo do usuário. Somente o proprietário do IP-STS sabe qual valor no token será sempre exclusivo para cada usuário. A declaração de identidade é criada como um mapeamento de declarações regular durante o processo de mapeamento de todas as declarações desejadas. A declaração que funciona como declaração de identidade é declarada quando o SPTrustedIdentityTokenIssuer é criado.
Outras declarações Consistem em declarações adicionais de um tíquete de SAML que descrevem usuários. Podem incluir funções de usuário, grupos de usuários ou outros tipos de declarações, como vencimento. Todos os mapeamentos de declarações são criados como objetos que são replicados entre os servidores em um farm do SharePoint Server.
Realm Na arquitetura de declarações do SharePoint, o URI ou a URL associado a um aplicativo Web do SharePoint que está configurado para usar um provedor baseado em token de SAML representa um realm. Ao criar um provedor de autenticação baseado em SAML no farm, você pode especificar os realms ou as URLs de aplicativos Web que deseja que o IP-STS reconheça, um de cada vez. O primeiro realm é especificado quando você cria o SPTrustedIdentityTokenIssuer. Realms adicionais podem ser adicionados após a criação de SPTrustedIdentityTokenIssuer. Realms são especificados com uma sintaxe semelhante a: $realm = "urn:sharepoint:meus_sites". Após adicionar o domínio ao SPTrustedIdentityTokenIssuer, você deve criar uma relação de confiança do RP-STS com o realm no servidor IP-STS. Esse processo envolve a especificação da URL para o aplicativo Web.
SPTrustedIdentityTokenIssuer Esse é o objeto criado no farm do SharePoint que inclui os valores necessários para se comunicar com e receber tokens do STS-IP. Ao
190
criar SPTrustedIdentityTokenIssuer, você especifica o certificado de autenticação de tokens a ser usado, o primeiro realm, a declaração que representa a declaração da identidade e qualquer declaração adicional. Só é possível associar um certificado de autenticação de tokens de um STS a um SPTrustedIdentityTokenIssuer. No entanto, após criar o SPTrustedIdentityTokenIssuer, você pode adicionar realms a outros aplicativos Web. Depois que um realm é adicionado a SPTrustedIdentityTokenIssuer, ele também deve ser adicionado ao STS-IP como uma terceira parte confiável. O objeto SPTrustedIdentityTokenIssuer é replicado entre servidores no farm do SharePoint Server.
Serviço de token de segurança de terceira parte confiável (RP-STS) No SharePoint Server 2010, cada aplicativo Web que está configurado para usar um provedor de SAML é adicionado ao servidor IP-STS como uma entrada de RP-STS. Um farm do SharePoint Server pode incluir várias entradas de RP-STS.
Serviço de token de segurança de provedor de identidade (IP-STS) Esse é o serviço de token seguro no ambiente de declarações que emite tokens de SAML em nome dos usuários que estão incluídos no diretório de usuários associado.
O diagrama a seguir ilustra a arquitetura de declarações do Produtos do SharePoint 2010.
191
O objeto SPTrustedIdentityTokenIssuer é criado com o uso de vários parâmetros. O diagrama a seguir ilustra os principais parâmetros.
192
Conforme ilustrado pelo diagrama, um SPTrustedIdentityTokenIssuer pode incluir somente uma declaração de identidade, um parâmetro SignInURL e um parâmetro Wreply. No entanto, pode incluir vários realms e vários mapeamentos de declarações. O parâmetro SignInURL especifica a URL à qual redirecionar uma solicitação do usuário para autenticação no IP-STS. Alguns servidores IP-STS exigem o parâmetro Wreply, que é definido como verdadeiro ou falso, sendo falso por padrão. Só use o parâmetro Wreply se ele for exigido pelo STS-IP.
193
Planejar o Serviço de Repositório Seguro (SharePoint Server 2010)
No Microsoft SharePoint Server 2010, o Serviço de Repositório Seguro substitui o recurso de logon único (SSO). O Serviço de Repositório Seguro é um serviço de autorização com reconhecimento de declaração que inclui um banco de dados seguro para armazenamento das credenciais associadas às IDs de aplicativo. Essas IDs podem ser usadas para autorizar acesso a fontes de dados externas.
Neste artigo:
Sobre o Serviço de Repositório Seguro
Preparação do serviço de repositório seguro
IDs de aplicativo
Mapeamentos do serviço de repositório seguro
Serviço de repositório seguro e autenticação de declaração
Sobre o Serviço de Repositório Seguro O Serviço de Repositório Seguro é um serviço de autorização executado em um servidor de aplicativos. Ele fornece um banco de dados que se destina a armazenar as credenciais (formada pela identidade do usuário e pela senha) das IDs de aplicativo que podem ser usadas pelos aplicativos para autorizar o acesso a recursos compartilhados. Por exemplo, o SharePoint Server 2010 pode usar o banco de dados de repositório seguro para armazenar e recuperar credenciais de acesso a fontes de dados externas. Tal serviço apresenta suporte para o armazenamento de credenciais de vários sistemas back-end usando diversas IDs de aplicativo.
Preparação do serviço de repositório seguro Ao preparar a implantação do Serviço de Repositório Seguro, observe estas diretrizes importantes:
Execute o Serviço de Repositório Seguro em um pool de aplicativos separado que
não seja usado por outro serviço.
Execute o Serviço de Repositório Seguro em um servidor de aplicativos separado
que não seja usado por outro serviço.
Crie o banco de dados de repositório seguro em um servidor de aplicativos separado
que execute o SQL Server. Não use a mesma instalação do SQL Server dos bancos
de dados de conteúdo.
Antes de gerar uma nova chave de criptografia, faça backup do banco de dados de
repositório seguro. Faça backup também depois da criação inicial do banco de
dados e sempre que as credenciais forem recriptografadas. Durante a geração de
uma nova chave, é possível que as credenciais sejam recriptografadas com ela. Se
194
a atualização da chave falhar ou a senha for esquecida, talvez essas credenciais
deixem de ser utilizáveis.
Faça backup da chave de criptografia depois da configuração inicial do Serviço de
Repositório Seguro e repita esse procedimento sempre que gerar novamente a
chave.
Não armazene a mídia de backup da chave de criptografia no mesmo local que a
mídia de backup do banco de dados de repositório seguro. Se um usuário obtiver
uma cópia do banco de dados e da chave, as credenciais armazenadas no banco de
dados podem ficar comprometidas.
IDs de aplicativo Cada entrada do Serviço de Repositório Seguro contém uma ID de aplicativo usada para recuperar um conjunto de credenciais a partir do banco de dados de repositório seguro. Cada ID pode ter permissões aplicadas de modo que apenas usuários ou grupos específicos possam acessar as credenciais armazenadas para ele. Os aplicativos usam tais IDs para recuperar as credenciais a partir do banco de dados de repositório seguro em nome do usuário. Desse modo, eles podem usar as credenciais recuperadas e acessar uma fonte de dados.
As IDs de aplicativo são usadas para mapear usuários a conjuntos de credenciais. Há mapeamentos disponíveis para grupos ou pessoas. Em um mapeamento de grupo, cada usuário pertencente a um grupo de domínio específico é mapeado ao mesmo conjunto de credenciais. Em um mapeamento individual, cada usuário é mapeado a um conjunto de credenciais exclusivo.
Mapeamentos do serviço de repositório seguro O Serviço de Repositório Seguro trabalha com mapeamentos individuais ou de grupo. Mantém um conjunto de credenciais para as IDs de aplicativo dos recursos armazenados no banco de dados de repositório seguro. As credenciais individuais de um aplicativo são recuperadas com base nessa ID. Os mapeamentos individuais são úteis quando você precisa das informações de logon do acesso do usuário individual aos recursos compartilhados. Para mapeamentos de grupo, uma camada de segurança verifica as credenciais do grupo dos diversos usuários do domínio, com base em um único conjunto de credenciais, para um recurso identificado por uma ID de aplicativo armazenada no banco de dados de repositório seguro. Além de os mapeamentos de grupo serem mais fáceis de se manter do que os individuais, ainda podem significar ganho no desempenho.
Serviço de repositório seguro e autenticação de declaração O Serviço de Repositório Seguro é um serviço com reconhecimento de declaração. Ele pode aceitar tokens de segurança, descriptografá-los (para obter a ID de aplicativo) e realizar a pesquisa. Quando um STS (Serviço de Token de Segurança) do SharePoint Server 2010 emite um token em resposta a uma solicitação de autenticação, o Serviço
195
de Repositório Seguro descriptografa o token e lê o valor da ID de aplicativo. Em seguida, usa essa ID para recuperar as credenciais do banco de dados de repositório do armazenamento seguro. As credenciais, por sua vez, são usadas para autorizar o acesso aos recursos.
Consulte também Outros recursos
Configure the Secure Store Service
196
Planejar proteção de segurança (SharePoint Server 2010)
Este artigo descreve a segurança reforçada das funções de servidor Web, servidor de aplicativos e servidor de banco de dados do Microsoft SharePoint Server 2010, além de fornece orientação detalhada sobre requisitos de proteção específicos para portas, protocolos e serviços do Produtos do Microsoft SharePoint 2010.
Neste artigo:
Instantâneos seguros do servidor
Orientação específica para portas, protocolos e serviços
Instantâneos seguros do servidor Em um ambiente de farm de servidores, servidores individuais desempenham funções específicas. As recomendações de segurança reforçada para esses servidores dependerão da função que cada um desempenha.
Funções de servidor Web e servidor de aplicativos
Função de servidor de banco de dados
Os instantâneos são divididos em categorias de configuração comuns. As características definidas para cada categoria representam o estado ideal de proteção para o Produtos do Microsoft SharePoint 2010. Este artigo não inclui orientações de proteção para outro software no ambiente.
Funções de servidor Web e servidor de aplicativos
Esta seção identifica características de proteção para servidores Web e servidores de aplicativos. Algumas orientações se aplicam a aplicativos de serviço específicos. Nesses casos, as características correspondentes precisam ser aplicadas apenas aos servidores que estão executando os serviços associados aos aplicativos de serviço especificados.
Categoria Característica
Serviços listados no snap-in MMC de
serviços
Habilite os seguintes serviços:
Compartilhamento de Arquivo e
Impressora
Serviço de Estado do ASP.NET (se
estiver usando o InfoPath Forms
Services ou o Microsoft Project Server
2010)
Serviço de Estado de Exibição (se
estiver usando o InfoPath Forms
Services)
197
Serviço de Publicação na World Wide
Web
Certifique-se de que estes serviços não
estejam desabilitados:
Declarações para Serviço de Token do
Windows
Administração do SharePoint 2010
Timer do SharePoint 2010
Rastreamento do SharePoint 2010
Gravador VSS do SharePoint 2010
Certifique-se de que estes serviços não
estejam desabilitados nos servidores que
hospedam as funções correspondentes:
Host do código de usuário do
SharePoint 2010
Pesquisa do SharePoint Foundation V4
Pesquisa do SharePoint Server 14
Os seguintes serviços são exigidos pelo
aplicativo de serviço de Perfil de
Usuário no servidor que importa perfis
do repositório de diretórios:
Serviço do Forefront Identity
Manager
Serviço de Sincronização do
Forefront Identity Manager
Portas e protocolos TCP 80, TCP 443 (SSL)
Portas personalizadas para
rastreamento de pesquisa, se
configuradas
Serviço de Compartilhamento de
Arquivo e Impressora — um dos
seguintes, usados por funções de
pesquisa:
SMB diretamente hospedado
(TCP/UDP 445) — esta é a porta
recomendada
NetBios sobre TCP/IP (NetBT)
(portas TCP/UDP 137, 138, 139) —
desabilite esta porta se não usá-la
Portas necessárias para comunicação
entre servidores Web e aplicativos de
serviço (o padrão é HTTP):
198
Associação HTTP: 32843
Associação HTTP: 32844
Associação net.tcp: 32845
(somente se um terceiro tiver
implementado essa opção para um
aplicativo de serviço)
Portas necessárias para sincronização
de perfis entre o Produtos do
SharePoint 2010 e o Active Directory no
servidor que executa o agente do
Forefront Identity Management:
TCP/5725
TCP/UDP 389 (serviço LDAP)
TCP/UDP 88 (Kerberos)
TCP/UDP 53 (DNS)
UDP 464 (Alterar Senha do
Kerberos)
Para obter informações sobre como
sincronizar perfis com outros
repositório de diretórios, consulte
Requisitos de proteção do serviço
de Perfil do Usuário, mais adiante
neste artigo.
Porta UDP 1434 e porta TCP 1433 —
portas padrão para comunicação do
SQL Server. Se essas portas forem
bloqueadas no computador do SQL
Server (recomendado) e os bancos de
dados forem instalados em uma
instância nomeada, configure um alias
de cliente do SQL Server para conexão
com a instância nomeada.
TCP/IP 32846 para o Serviço de Código
de Usuário do Microsoft SharePoint
Foundation (para soluções de área
restrita) — Essa porta deve estar aberta
para conexões de saída em todos os
servidores Web. Ela deve estar aberta
para conexões de entrada nos
servidores Web ou de aplicativos onde
o serviço está ativado.
Verifique se as portas permanecem
abertas para os aplicativos Web que os
usuários podem acessar.
Bloqueie o acesso externo à porta
199
usada pelo site da Administração
Central.
TCP/25 (SMTP para integração de
email)
Registro Sem orientações adicionais
Auditoria e log Se os arquivos de log forem realocados, verifique se os locais foram atualizados de acordo. Atualize as ACLs (listas de controle
de acesso) do diretório também.
Segurança de acesso a código Verifique se você possui o conjunto mínimo
de permissões de segurança de acesso a
código habilitado para seu aplicativo Web.
O elemento <trust> no Web.config para cada aplicativo Web deve ser definido como WSS_Minimal (onde WSS_Minimal tem seus padrões baixos conforme definido em
14\config\wss_minimaltrust.config) ou como
seu próprio arquivo de políticas
personalizado, minimamente definido.
Web.config Siga estas recomendações para cada
arquivo Web.config criado depois que você
executar a Instalação:
Não permita a compilação ou a geração
de scripts de páginas de bancos de
dados por meio de elementos
PageParserPaths.
Verifique se <SafeMode>
CallStack=""false"" e se
AllowPageLevelTrace=""false"".
Verifique se o limite da Web Part para o
número máximo de controles por zona
foi definido como baixo.
Verifique se a lista SafeControls foi
definida como o conjunto mínimo de
controles necessários aos seus sites.
Verifique se a sua lista SafeTypes do
fluxo de trabalho foi definida como o
nível mínimo de SafeTypes
necessários.
Verifique se customErrors está ativado
(<customErrors mode=""Ativado""/>).
Considere suas configurações de proxy
da Web conforme necessário
200
(<system.net>/<Proxypadrão>).
Defina o limite de Upload.aspx para o o
maior tamanho razoavelmente
esperado para os carregamentos feitos
pelos usuários (o padrão é 2 GB). O
desempenho pode ser afetado por
carregamentos que excedem 100 MB.
Função de servidor de banco de dados
A principal recomendação para o Produtos do SharePoint 2010 é proteger a comunicação entre farms bloqueando as portas padrão usadas para a comunicação com o Microsoft SQL Server e estabelecendo portas personalizadas para essa comunicação. Para obter mais informações sobre como configurar portas para a comunicação do SQL Server, consulte Bloqueando as portas padrão do SQL Server, mais adiante neste artigo.
Categoria Característica
Portas Bloquear a porta UDP 1434.
Considerar o bloqueio da porta TCP
1433.
Este artigo não descreve como proteger o SQL Server. Para obter mais informações sobre como proteger o SQL Server, consulte Protegendo o SQL Server (http://go.microsoft.com/fwlink/?linkid=186828&clcid=0x416).
Orientação específica para portas, protocolos e serviços O restante deste artigo descreve com mais detalhes os requisitos específicos de proteção para o Produtos do SharePoint 2010.
Nesta seção:
Bloqueando as portas padrão do SQL Server
Comunicação do aplicativo de serviço
Requisitos do serviço de Compartilhamento de Arquivo e Impressora
Requisitos de proteção do serviço de Perfil do Usuário
Conexões a servidores externos
Requisitos de serviço para integração de email
Requisitos de serviço para estado da sessão
Serviços dos Produtos do SharePoint 2010
Arquivo Web.config
201
Bloqueando as portas padrão do SQL Server
As portas específicas usadas para conectar o SQL Server são afetadas pelo fato de os bancos de dados estarem instalados em uma instância padrão do SQL Server ou em uma instância nomeada do SQL Server. A instância padrão do SQL Server escuta solicitações do cliente na porta TCP 1433. Uma instância nomeada do SQL Server escuta em um número de porta atribuído aleatoriamente. Além disso, o número de porta de uma instância nomeada poderá ser atribuído novamente se a instância for reiniciada (dependendo da disponibilidade do número da porta atribuído anteriormente).
Por padrão, os computadores clientes que se conectam ao SQL Server primeiro se conectam usando a porta TCP 1433. Se essa comunicação não for bem-sucedida, os computadores clientes consultarão o Serviço de Resolução do SQL Server que está escutando na porta UDP 1434 para determinar a porta em que a instância do banco de dados está escutando.
O comportamento padrão de comunicação de porta do SQL Server introduz vários problemas que afetam a proteção do servidor. Primeiro, as portas usadas pelo SQL Server são muito conhecidas, e o serviço de resolução do SQL Server tem sido alvo de ataques de saturação de buffer e negação de serviço, incluindo o worm "Slammer". Mesmo que o SQL Server seja atualizado para atenuar os problemas de segurança do Serviço de Resolução do SQL Server, as portas bem conhecidas continuam sendo um alvo. Segundo, se os bancos de dados forem instalados em uma instância nomeada do SQL Server, a porta de comunicação correspondente será atribuída aleatoriamente e poderá ser alterada. Esse comportamento pode potencialmente impedir a comunicação de servidor a servidor em um ambiente protegido. A capacidade de controlar as portas TCP que serão abertas ou bloqueadas é essencial para proteger seu ambiente.
Consequentemente, a recomendação para um farm de servidores é atribuir números de porta estáticos a instâncias nomeadas do SQL Server e bloquear a porta UDP 1434 para impedir que possíveis invasores acessem o Serviço de Resolução do SQL Server. Além disso, convém reatribuir a porta usada pela instância padrão e bloquear a porta TCP 1433.
Existem diversos métodos que podem ser usados no bloqueio de portas. Você pode bloquear essas portas usando um firewall. No entanto, a menos que você possa garantir que não haja outras rotas no segmento de rede nem usuários mal-intencionados com acesso ao segmento de rede, a recomendação é bloqueá-las diretamente no servidor que hospeda o SQL Server. Isso pode ser feito usando o Firewall do Windows no Painel de Controle.
Configurando instâncias de banco de dados do SQL Server para que elas escutem em uma porta fora do padrão
O SQL Server oferece a capacidade de reatribuir as portas que são usadas pela instância padrão e instâncias nomeadas. No SQL Server 2005 e no SQL Server 2008, reatribua portas usando o Gerenciador de Configurações do SQL Server.
Configurando aliases de cliente do SQL Server
Em um farm de servidores, todos os servidores Web front-end e servidores de aplicativos são computadores clientes do SQL Server. Se você bloquear a porta UDP 1434 no computador com SQL Server ou alterar a porta padrão para a instância padrão, configure um alias de cliente do SQL Server em todos os servidores que se conectam ao computador com SQL Server.
202
Para se conectar a uma instância do SQL Server 2005 ou SQL Server 2008, instale os componentes de cliente do SQL Server no computador de destino e configure o alias de cliente do SQL Server usando o Gerenciador de Configurações do SQL Server. Para instalar os componentes de cliente do SQL Server, execute a Instalação e selecione somente os seguintes componentes de cliente para instalar:
Componentes de Conectividade
Ferramentas de gerenciamento (inclui Gerenciador de Configurações do SQL
Server)
Para ver etapas específicas de proteção para bloquear portas SQL padrão, consulte Hardening SQL Server for SharePoint environments.
Comunicação do aplicativo de serviço
Por padrão, a comunicação entre os servidores Web e os aplicativos de serviço de um farm ocorre usando HTTP com associação à porta 32843. Quando você publica um aplicativo de serviço, pode selecionar HTTP ou HTTPS com as seguintes associações:
Associação HTTP: porta 32843
Associação HTTPS: porta 32844
Além disso, terceiros que desenvolvem aplicativos de serviço podem implementar uma terceira opção:
Associação net.tcp: porta 32845
Você pode alterar a associação do protocolo e da porta para cada aplicativo de serviço. Na página Aplicativos de Serviço, na Administração Central, selecione o aplicativo de serviço e clique em Publicar.
A comunicação entre os aplicativos de serviço e o SQL Server ocorre nas portas padrão do SQL Server ou nas portas que você configura para a comunicação do SQL Server.
Requisitos do serviço Compartilhamento de Arquivo e Impressora
Diversos recursos fundamentais dependem do serviço Compartilhamento de Arquivo e Impressora e dos protocolos e portas correspondentes. Entre eles estão incluídos, mas sem limitação, o seguinte:
Consultas de pesquisa Todas as consultas de pesquisa exigem o serviço de
Compartilhamento de Arquivo e Impressora.
Rastreamento e indexação de conteúdo Para rastrear conteúdo, servidores que
incluem componentes de rastreamento enviam solicitações por meio do servidor
Web front-end. O servidor Web front-end se comunica com os bancos de dados de
conteúdo de forma direta e envia resultados de volta aos servidores que incluem
componentes de rastreamento. A comunicação exige o serviço de Compartilhamento
de Arquivo e Impressora.
Propagação de índice se um aplicativo de serviço de Pesquisa for configurado
com componentes de rastreamento e de consulta que estejam distribuídos em vários
servidores, os servidores com os componentes de rastreamento copiarão os
arquivos de índice de conteúdo para os servidores com componentes de consulta.
Essa ação exige o serviço de Compartilhamento de Arquivo e Impressora e os
protocolos e portas correspondentes.
O serviço de Compartilhamento de Arquivo e Impressora exige o uso de pipes nomeados. Pipes nomeados podem se comunicar usando os protocolos SMB diretamente hospedado ou NetBT. Para obter um ambiente seguro, é recomendado usar
203
o protocolo SMB diretamente hospedado em vez do NetBT. As recomendações de proteção fornecidas neste artigo pressupõem que o SMB será usado.
A tabela a seguir descreve os requisitos de proteção introduzidos pela dependência do serviço Compartilhamento de Arquivo e Impressora.
Categoria Requisitos Observações
Serviços Compartilhamento de Arquivo e Impressora
Requer o uso de pipes nomeados.
Protocolos Pipes nomeados que usam SMB diretamente hospedado
Desabilitar o NetBT
Os pipes nomeados podem usar o NetBT em vez do SMB diretamente hospedado. No entanto, o NetBT
não é tão seguro
quanto o SMB diretamente hospedado.
Portas Um dos seguintes:
SMB diretamente hospedado
(TCP/UDP 445) —
recomendado
NetBT (portas TCP/UDP 137,
138, 139)
Desabilite o NetBT (portas 137, 138 e 139)
se não estiver
sendo usado
Para obter mais informações sobre como desabilitar o NetBT, consulte o artigo 204279 da Base de Dados de Conhecimento da Microsoft, Hospedagem direta de SMB sobre TCP/IP (http://go.microsoft.com/fwlink/?linkid=76143&clcid=0x416).
Requisitos de proteção do serviço de Perfil do Usuário
O aplicativo de serviço de Perfil de Usuário usa o agente do Forefront Identity Management para sincronizar perfis entre o Produtos do SharePoint 2010 e o Active Directory ou um serviço de diretórios LDAP. Esse agente é instalado em todos os servidores em um farm do SharePoint, mas é necessário apenas no servidor configurado para sincronização com o repositório de diretórios.
O agente do Forefront Identity Management inclui os dois serviços a seguir, que devem permanecer habilitados no servidor configurado para rastrear o Active Directory ou outro repositório de diretórios:
Serviço do Forefront Identity Manager
Serviço de Sincronização do Forefront Identity Manager
Além disso, a porta TCP 5725 deve estar aberta no servidor que executa o agente do Forefront Identity Management e que está configurado para rastrear um repositório de diretórios.
204
Nos ambientes do Active Directory, as seguintes portas devem permanecer abertas para comunicação entre o servidor do Produtos do SharePoint 2010 que sincroniza com o repositório de armazenamento e o servidor que está executando o Active Directory:
TCP/UDP 389 (serviço LDAP)
TCP/UDP 88 (Kerberos)
TCP/UDP 53 (DNS)
UDP 464 (Alterar Senha do Kerberos)
Para obter mais informações sobre os requisitos de proteção do agente do Forefront Identity Management, incluindo os requisitos de porta de outros tipos de diretório, consulte Portas de Comunicação, Direitos e Permissões do Agente de Gerenciamento (http://go.microsoft.com/fwlink/?linkid=186832&clcid=0x416).
Conexões com servidores externos
Vários recursos do SharePoint Server 2010 podem ser configurados para acessar dados que residem em computadores de servidores fora do farm de servidores. Se você configurar o acesso aos dados que estão localizados em tais computadores externos, habilite a comunicação entre os computadores apropriados. Na maioria dos casos, as portas, protocolos e serviços usados dependem do recurso externo. Por exemplo:
Conexões com compartilhamentos de arquivos usam o serviço Compartilhamento de
Arquivo e Impressora.
Conexões com bancos de dados externos do SQL Server usam portas padrão ou
personalizadas para comunicação do SQL Server.
Em geral, conexões com bancos de dados Oracle normalmente usam OLE DB.
Conexões com serviços Web usam HTTP e HTTPS.
A tabela a seguir lista os recursos que podem ser configurados para acessar dados que residam em computadores do servidor fora do farm de servidores.
Recurso Descrição
Rastreamento de conteúdo É possível configurar regras para rastrear
dados que residam em recursos externos, incluindo sites, compartilhamentos de
arquivo, pastas públicas do Exchange e
aplicativos de dados corporativos. Durante o rastreamento de fontes de dados
externos, a função de rastreamento se
comunica diretamente com esses recursos externos.
Para obter mais informações, consulte
Planejar o rastreamento de conteúdo (Office
SharePoint Server) [http://technet.microsoft.com/pt-br/library/cc262926(office.12).aspx ].
Conexões da Conectividade de Dados
Corporativos
Os servidores Web e os servidores de aplicativos se comunicam diretamente com os computadores configurados para
205
conexões de Conectividade de Dados
Corporativos.
Para obter mais informações, consulte
Planejar conexões de dados corporativos
com o Catálogo de Dados Corporativos
[http://technet.microsoft.com/pt-br/library/cc262899(office.12).aspx].
Recebendo pastas de trabalho do Microsoft Office Excel
Se as pastas de trabalho abertas no
Aplicativo de Serviços do Excel se
conectarem a alguma fonte de dados externa (por exemplo, Analysis Services e SQL Server), as portas TCP/IP apropriadas precisarão estar abertas para se
conectarem a essas fontes de dados
externos. Para obter mais informações,
consulte Planejar conexões de dados
externos para os Serviços do Excel
[http://technet.microsoft.com/pt-br/library/cc262899(office.12).aspx].
Se caminhos UNC (convenção de
nomenclatura universal) válidos estiverem
configurados como locais confiáveis no
Aplicativo de Serviços do Excel, a função do
aplicativo dos Serviços de Cálculo do Excel
usará os protocolos e portas usados pelo
serviço de Compartilhamento de Arquivo e
Impressora para receber pastas de trabalho do Office Excel por meio de um caminho UNC.
As pastas de trabalho armazenadas nos
bancos de dados de conteúdo, ou
carregadas ou baixadas de sites pelos
usuários, não são afetadas por essa
comunicação.
Requisitos de serviço para integração de email
A integração de email exige o uso de dois serviços:
Serviço SMTP
Serviço Microsoft SharePoint Directory Management
Serviço SMTP
A integração de email requer o uso do serviço SMTP em pelo menos um dos servidores Web front-end no farm de servidores. O serviço SMTP é necessário para emails de entrada. Para emails de saída, você pode usar o serviço SMTP ou rotear emails de saída por um servidor de email dedicado na sua organização, por exemplo, o computador do Microsoft Exchange Server.
206
Serviço Microsoft SharePoint Directory Management
O Produtos do SharePoint 2010 inclui um serviço interno, o Serviço de Gerenciamento de Diretório do Microsoft SharePoint, para criar grupos de distribuição de email. Ao configurar a integração de email, você tem a opção de habilitar o recurso do Serviço de Gerenciamento de Diretório, que permite que os usuários criem listas de distribuição. Quando os usuários criam um grupo do SharePoint e selecionam a opção para criar uma lista de distribuição, o Serviço de Gerenciamento de Diretório do Microsoft SharePoint cria a lista de distribuição do Active Directory correspondente no ambiente do Active Directory.
Em ambientes com segurança reforçada, a recomendação é restringir o acesso ao Serviço de Gerenciamento de Diretório do Microsoft SharePoint protegendo o arquivo associado a esse serviço: SharePointEmailws.asmx. Por exemplo, você pode permitir acesso a esse arquivo apenas pela conta do farm de servidores.
Adicionalmente, esse serviço exige permissões no ambiente do Active Directory para criar objetos de lista de distribuição do Active Directory. A recomendação é configurar uma UO (Unidade Organizacional) separada no Active Directory para objetos do Produtos do SharePoint 2010. Somente essa UO deverá permitir acesso de gravação à conta usada pelo Serviço de Gerenciamento de Diretório do Microsoft SharePoint.
Requisitos de serviço para estado da sessão
Tanto o Project Server 2010 quanto o InfoPath Forms Services mantêm o estado da sessão. Se você estiver implantando esses recursos ou produtos no farm de servidores, não desabilite o Serviço de Estado do ASP.NET. Além disso, se estiver implantando o InfoPath Forms Services, não desabilite o serviço Exibir Estado.
Serviços dos Produtos do SharePoint 2010
Não desabilite os serviços que são instalados pelo Produtos do SharePoint 2010 (listados anteriormente no instantâneo).
Se o seu ambiente não permitir serviços que sejam executados como um sistema local, apenas convém desabilitar o serviço do SharePoint 2010 Administration se você souber quais serão as consequências e puder contorná-las. Esse é um serviço Win32 executado como um sistema local.
Esse serviço é usado pelo serviço de Timer do SharePoint 2010 para executar ações que necessitem de permissões administrativas no servidor, como a criação de sites do IIS (Serviços de Informações da Internet), a implantação de código e a parada e início de serviços. Se você desabilitar esse serviço, não poderá concluir as tarefas relacionadas à implantação do site da Administração Central. Use o Windows PowerShell para executar o cmdlet Start-SPAdminJob (ou use a ferramenta de linha de comando Stsadm.exe para executar a operação execadmsvcjobs) com o objetivo de fazer implantações de vários servidores para o Produtos do SharePoint 2010 e executar outras tarefas relacionadas à implantação.
Arquivo Web.config
O .NET Framework, e o ASP.NET em especial, usam os arquivos de configuração formatados em XML para configurar aplicativos. O .NET Framework depende de arquivos de configuração para definir as opções de configuração. Arquivos de configuração são arquivos XML em formato de texto. Vários arquivos de configuração podem existir, e normalmente existem, em um único sistema.
As configurações gerais do sistema para o .NET Framework estão definidas no arquivo Machine.config, que está localizado na pasta
207
%SystemRoot%\Microsoft.NET\Framework\%VersionNumber%\CONFIG\. As configurações padrão contidas no arquivo Machine.config podem ser modificadas para afetar o comportamento de aplicativos que usam o .NET Framework em todo o sistema.
Você poderá alterar a configuração do ASP.NET para um único aplicativo se criar um arquivo Web.config na pasta raiz do aplicativo. Quando isso é feito, as configurações do arquivo Web.config substituem as configurações do arquivo Machine.config.
Quando você estende um aplicativo Web usando a Administração Central, o Produtos do SharePoint 2010 cria automaticamente um arquivo Web.config para o aplicativo Web.
O instantâneo do servidor Web e do servidor de aplicativos apresentado anteriormente neste artigo lista as recomendações para configurar os arquivos Web.config. Essas recomendações se aplicam a cada arquivo Web.config criado, incluindo o arquivo Web.config para o site da Administração Central.
Para obter mais informações sobre os arquivos de configuração do ASP.NET e sobre a edição do arquivo Web.config, consulte Configuração do ASP.NET (http://go.microsoft.com/fwlink/?linkid=73257&clcid=0x416).
208
Planejar alteração automática de senha (SharePoint Server 2010)
Para simplificar o gerenciamento de senhas, o recurso de alteração automática de senha permite que você atualize e implante senhas sem precisar executar tarefas de atualização manual de senha entre várias contas, serviços e aplicativos. Você pode configurar o recurso de alteração automática de senha para determinar se uma senha está prestes a expirar e redefini-la usando uma longa cadeia de caracteres aleatória criptograficamente forte. Para implementar o recurso de alteração automática de senha, você precisa configurar contas gerenciadas.
Neste artigo:
Configurando contas gerenciadas
Redefinindo senhas automaticamente em uma agenda
Detectando o vencimento de senhas
Redefinindo a senha da conta imediatamente
Sincronizando as senhas de contas do SharePoint Foundation com os Serviços de
Domínio Active Directory
Redefinindo todas as senhas imediatamente
Processo de alteração de credenciais
Configurando contas gerenciadas O Microsoft SharePoint Server 2010 suporta a criação de contas gerenciadas para melhorar a segurança e garantir o isolamento de aplicativo. Usando contas gerenciadas, você pode configurar o recurso de alteração automática de senha para implantar senhas em todos os serviços do farm. Você pode configurar aplicativos e serviços do SharePoint, em execução nos servidores de aplicativo em um farm do SharePoint, para usar diferentes contas de domínio. Também pode criar várias contas no AD DS (Serviços de Domínio Active Directory) e registrar cada uma dessas contas no SharePoint Server 2010. É possível mapear contas gerenciadas para vários serviços e aplicativos no farm.
Redefinindo senhas automaticamente em uma agenda Antes da implementação do recurso de alteração automática de senha, a atualização de senhas exigia a redefinição de cada senha de conta no AD DS e, depois, a atualização manual de senhas de conta em todos os serviços executados em todos os computadores do farm. Para isso, era necessário executar a ferramenta de linha de comando Stsadm ou usar o aplicativo Web da Administração Central do SharePoint. Usando o recurso de alteração automática de senha, você pode agora registrar as contas gerenciadas e habilitar o SharePoint Server 2010 para controlar as senhas de
209
contas. Os usuários devem ser avisados sobre as alterações de senha planejadas e interrupções de serviço correlatas, mas as contas usadas por um farm do SharePoint, aplicativos Web e serviços variados podem ser redefinidas automaticamente e implantadas no farm conforme necessário, com base em agendas de redefinição de senha configuradas individualmente.
Detectando o vencimento de senhas Os departamentos de TI normalmente impõem uma diretiva que exige que todas as senhas de conta de domínio sejam redefinidas regularmente, por exemplo, a cada 60 dias. O SharePoint Server 2010 pode ser configurado para detectar o vencimento de uma senha iminente e enviar uma notificação por email para um administrador designado. Mesmo sem a intervenção do administrador, o SharePoint Server 2010 pode ser configurado para gerar e redefinir senhas automaticamente. A agenda de redefinição automática de senha também é configurável para garantir que o impacto de possíveis interrupções de serviço durante uma redefinição de senha seja mínimo.
Redefinindo a senha da conta imediatamente Você sempre pode substituir a agenda de redefinição automática de senha e forçar uma redefinição de senha de conta de serviço imediata, usando um valor de senha específica. Nesse cenário, a senha da conta de serviço também pode ser alterada no AD DS pelo SharePoint Server 2010. Em seguida, a nova senha é imediatamente propagada para outros servidores no farm.
Sincronizando as senhas de contas do SharePoint Foundation com os Serviços de Domínio Active Directory Se as senhas de conta do AD DS e do SharePoint Server 2010 não forem sincronizadas, os serviços do farm do SharePoint não serão iniciados. Se um administrador do Active Directory alterar uma senha de conta do Active Directory sem coordenar a alteração de senha com o administrador do SharePoint, heverá o risco de interrupção do serviço. Nesse cenário, o administrador do SharePoint imediatamente pode redefinir a senha da página de Gerenciamento de Conta usando o valor de senha que foi alterado no AD DS. A senha é atualizada e imediatamente propagada para outros servidores do farm do SharePoint.
Redefinindo todas as senhas imediatamente Se o administrador deixar a organização ou se as senhas de conta de serviço precisarem ser redefinidas imediatamente por qualquer motivo, você poderá criar rapidamente um script do Windows PowerShell que chamará os cmdlets de alteração de senha. Esse script pode ser usado para gerar novas senhas aleatórias e implantar as novas senhas imediatamente.
210
Processo de alteração de credenciais Quando o SharePoint Server 2010 altera as credenciais de uma conta gerenciada, o processo de alteração de credenciais ocorre em um servidor do farm. Cada servidor do farm será avisado de que as credenciais estão prestes a serem alteradas, e os servidores podem realizar ações de pré-alteração críticas, se necessário. Se a senha da conta ainda não foi alterada, o SharePoint Server 2010 tentará alterá-la usando uma senha inserida manualmente ou uma cadeia de caracteres aleatória de criptografia forte. As configurações de complexidade serão consultadas na diretiva adequada (rede ou local), e a senha gerada equivalerá às configurações detectadas. O SharePoint Server 2010 tentará confirmar uma alteração de senha. Se não conseguir, tentará novamente usando uma nova sequência, por um número especificado de vezes. Se a o processo de atualização da senha da conta tiver êxito, ele prosseguirá para o próximo serviço dependente, no qual tentará novamente realizar a alteração de senha. Se não tiver êxito, cada serviço dependente será avisado de que pode retomar as atividades normais. O êxito ou falha na confirmação da alteração da senha resultará na geração de uma notificação automática de status de alteração de senha, que será enviada por email para os administradores do farm.
Consulte também Outros recursos
Configure automatic password change (SharePoint Server 2010)
211
SQL Server e armazenamento (SharePoint Server 2010)
Esta seção descreve como planejar a configuração do Microsoft SQL Server e do armazenamento para o Microsoft SharePoint Server 2010. Nesta seção:
Visão geral do SQL Server em um ambiente do SharePoint (SharePoint Server
2010)
Este artigo descreve a relação entre o SharePoint Server 2010 e as versões com suporte do SQL Server. Ele também descreve como você pode interagir com os bancos de dados e introduz maneiras de utilizar os recursos de relatórios e BI (business intelligence) do SQL Server com o SharePoint Server 2010.
SQL Server 2008 R2 e Produtos do SharePoint 2010: melhores juntos (white paper)
(SharePoint Server 2010)
Este artigo descreve os benefícios do uso do SharePoint Server 2010 com o SQL Server 2008 R2 Enterprise Edition.
Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)
Este artigo descreve um processo para planejar o armazenamento e a capacidade do SQL Server para uma implantação do SharePoint Server 2010.
Overview of Remote BLOB Storage (SharePoint Server 2010) (em inglês)
Este artigo descreve como o SharePoint Server 2010 funciona com o Remote BLOB Storage.
Planejar o RBS (Remote BLOB Storage) (SharePoint Server 2010)
Este artigo descreve os fatores que devem ser considerados durante a mudança para uma solução de Remote BLOB Storage.
212
Visão geral do SQL Server em um ambiente do SharePoint (SharePoint Server 2010)
Este artigo descreve o relacionamento entre o Microsoft SharePoint Server 2010 e as versões com suporte do Microsoft SQL Server. Também descreve como você pode interagir com os bancos de dados e introduz maneiras de usar os recursos de relatório e BI (business intelligence) do SQL Server com o SharePoint Server 2010.
Para obter mais informações sobre as versões com suporte do SQL Server, consulte Requisitos de hardware e software (SharePoint Server 2010).
Neste artigo:
Produtos do SharePoint 2010 e o mecanismo de banco de dados do SQL Server
SQL Server como plataforma de dados para business intelligence nos Produtos do
SharePoint 2010
Ferramentas de criação e publicação do SharePoint Server 2010 para business
intelligence
Produtos do SharePoint 2010 e o mecanismo de banco de dados do SQL Server O SharePoint Server 2010 é um aplicativo criado com base no mecanismo de banco de dados do SQL Server. Grande parte do conteúdo e das configurações no SharePoint Server 2010 é armazenada em bancos de dados relacionais. O SharePoint Server 2010 usa os seguintes tipos de bancos de dados:
Configuração O banco de dados de Configuração e o banco de dados de
conteúdo da Administração Central são chamados de bancos de dados de
configuração. Eles contêm dados sobre configurações de farm, como bancos de
dados usados, sites do IIS (Serviços de Informações da Internet) ou aplicativos Web,
soluções, pacotes de Web Parts, modelos de sites, cota padrão e tipos de arquivos
bloqueados. Um farm pode ter apenas um conjunto de bancos de dados de
configuração.
Conteúdo Bancos de dados de conteúdo armazenam todo o conteúdo do site:
documentos de site, como arquivos em bibliotecas de documentos, dados de lista;
propriedades de Web Parts; e nomes e direitos de usuário. Todos os dados de um
determinado site residem em um banco de dados de conteúdo. Cada aplicativo Web
pode ter vários bancos de dados de conteúdo. Cada conjunto de sites pode ser
associado a apenas um banco de dados de conteúdo, embora um banco de dados
de conteúdo possa ser associado a vários conjuntos de sites.
Aplicativo de serviço Bancos de dados de aplicativos de serviço armazenam
dados para uso por um aplicativo de serviço. Os bancos de dados para aplicativos
de serviço variam significativamente em suas utilizações.
213
Para obter uma lista completa dos bancos de dados que oferecem suporte ao SharePoint Server 2010, consulte Database types and descriptions (SharePoint Server 2010).
Trabalhando com os bancos de dados do SQL Server que oferecem suporte aos Produtos do SharePoint 2010
Os bancos de dados do SQL Server que oferecem suporte ao SharePoint Server 2010 podem ser criados pelo SharePoint Server 2010 ou por um administrador de banco de dados. Para obter mais informações, consulte Deploy using DBA-created databases (SharePoint Server 2010).
A Microsoft não oferece suporte direto para a consulta ou a modificação dos bancos de dados compatíveis com o SharePoint Server 2010, com exceção do banco de dados do aplicativo de serviço Coleta de Dados de Uso e Integridade, que pode ser consultado diretamente e pode ter seu esquema adicionado.
Os bancos de dados do SQL Server que oferecem suporte ao SharePoint Server 2010 estão sujeitos a limitações de tamanho e a recomendações de configuração que não são padrão do SQL Server. Para obter mais informações, consulte Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010).
SQL Server como plataforma de dados para business intelligence nos Produtos do SharePoint 2010 O SharePoint Server 2010 pode ser usado com ferramentas de BI do SQL Server para analisar e exibir dados de BI de maneiras significativas. O SQL Server fornece a infraestrutura de dados primários e a plataforma de business intelligence que fornece aos autores de relatórios e usuários comerciais dados confiáveis, escalonáveis e seguros.
As seções a seguir descrevem as tecnologias e os recursos no SQL Server que dão suporte para a funcionalidade e os recursos de business intelligence no SharePoint Server 2010.
Mecanismo de banco de dados do SQL Server
O mecanismo de banco de dados do SQL Server é o serviço essencial para armazenamento, processamento e proteção dos dados. Os dados de BI podem ser coletados no mecanismo de banco de dados do SQL Server. Para obter mais informações, consulte o artigo sobre o mecanismo de banco de dados do SQL Server (http://go.microsoft.com/fwlink/?linkid=199540&clcid=0x416).
SSAS (SQL Server Analysis Services): dados multidimensionais
Dados multidimensionais do Microsoft SQL Server Analysis Services (SSAS) permitem projetar, criar e gerenciar estruturas multidimensionais que contêm detalhes e dados agregados de várias fontes de dados. Está disponível no SQL Server 2008 R2 um assistente de cubo que simplifica o modo de criação de cubos. Dados dimensionais ou dados de cubo são uma fonte de dados prototípica para os tipos de análise que podem ser feitos com o uso de aplicativos de serviço relacionados a business intelligence no SharePoint Server 2010. Para saber mais como dados relacionais e multidimensionais ajudam os usuários a analisar dados, consulte Data warehousing, OLAP and relational
214
data for business intelligence in SharePoint. Para obter mais informações, consulte o artigo sobre SQL Server Analysis Services – Dados Multidimensionais (http://go.microsoft.com/fwlink/?linkid=199541&clcid=0x416).
SQL Server Analysis Services: mineração de dados
As ferramentas de mineração de dados do SQL Server Analysis Services fornecem um conjunto de algoritmos de mineração de dados padrão do setor e outras ferramentas que ajudam a descobrir tendências e padrões nos dados. Os seguintes suplementos do Excel ajudam a executar análise de previsão:
O suplemento Ferramentas de Análise de Tabela para Excel fornece ferramentas
fáceis de usar que aproveitam as vantagens da Mineração de Dados do Analysis
Services para a execução de análises avançadas em dados de planilhas. Para obter
mais informações, consulte o artigo sobre mineração de dados do SQL Server
Analysis Services (http://go.microsoft.com/fwlink/?linkid=199543&clcid=0x416).
O Cliente de Mineração de Dados para Excel permite que os usuários criem, testem
e consultem modelos de mineração de dados no Microsoft Office Excel 2007 usando
dados de planilha ou dados externos disponíveis via Analysis Services.
Observação:
Para habilitar suplementos, você deve ter uma conexão com o servidor.
SSRS (SQL Server Reporting Services)
O Microsoft SQL Server Reporting Services (SSRS) e o SharePoint Server 2010 são facilmente integrados. O SQL Server Reporting Services possui uma gama completa de ferramentas com as quais você pode criar, implantar e gerenciar relatórios para sua organização. Ele também apresenta recursos que permitem estender e personalizar a funcionalidade de relatório.
A funcionalidade disponível inclui:
A criação de relatórios com o Construtor de Relatórios 3, uma das ferramentas de
criação do SQL Server Reporting Services, que pode ser iniciada diretamente do
SharePoint Server 2010.
A publicação de relatórios SSRS no SharePoint Server 2010.
Você pode publicar tipos de conteúdo de servidor de relatório em uma biblioteca do SharePoint e depois consultar e gerenciar esses documentos em um site do SharePoint.
Para obter mais informações sobre o SSRS, consulte o artigo sobre o SQL Server Reporting Services (http://go.microsoft.com/fwlink/?linkid=199545&clcid=0x416). Para obter mais informações sobre como instalar os diferentes modos de integração, consulte Overview of SQL Server Reporting Services reports in SharePoint.
SSIS (SQL Server Integration Services)
O Microsoft SQL Server Integration Services (SSIS) fornece soluções avançadas de integração e transformação de dados. Você pode criar um processo ETL (extração, transformação e carregamento) repetível para automatizar a movimentação de dados a partir de determinadas fontes, como arquivos de dados XML, arquivos simples ou fontes de dados relacionais, para um ou mais destinos. Se os dados derivarem de diferentes
215
fontes, mas não tiverem sido extraídos ou purificados para obterem os benefícios oferecidos em aplicativos de BI, o SQL Server Integration Services poderá ajudar a prepará-los. Para obter mais informações, consulte o artigo sobre o SQL Server Integration Services (http://go.microsoft.com/fwlink/?linkid=199546&clcid=0x416).
BIDS (Business Intelligence Development Studio)
O BIDS (Microsoft Business Intelligence Development Studio) fornece assistentes intuitivos para a criação de soluções de integração, relatórios e análise em um ambiente unificado. Ele dá suporte ao ciclo de vida completo de desenvolvimento, teste e implantação de soluções e relatórios. O BIDS tem como base o ambiente de desenvolvimento do Visual Studio 2005, mas o personaliza com as extensões e os tipos de projeto específicos aos serviços do SQL Server para relatórios, fluxos de dados ETL, cubos OLAP e estrutura de mineração de dados.
PowerPivot para Excel e PowerPivot para SharePoint
O PowerPivot é um suplemento que permite aos usuários criar soluções de BI de autoatendimento. Ele também facilita o compartilhamento e a colaboração nessas soluções em um ambiente do SharePoint Server 2010. O PowerPivot também permite que organizações de TI aumentem sua eficácia operacional com ferramentas de gerenciamento do Microsoft SQL Server 2008. Os componentes do PowerPivot incluem:
O PowerPivot para Excel 2010 é um suplemento de análise de dados que fornece
recursos avançados de computação diretamente do Microsoft Excel 2010. O
PowerPivot para Excel (anteriormente conhecido como "Gemini") permite que os
usuários analisem grandes quantidades de dados. Sua integração com o SharePoint
Server 2010 ajuda os departamentos de TI a monitorar e gerenciar como os usuários
colaboram. O suplemento remove o limite de um milhão de linhas para planilhas e
fornece cálculos rápidos para grandes conjuntos de dados. Para obter mais
informações, consulte a visão geral do PowerPivot
(http://go.microsoft.com/fwlink/?linkid=199547&clcid=0x416).
O PowerPivot para SharePoint 2010 estende o SharePoint Server 2010 e os
Serviços do Excel de forma a adicionar suporte a processamento, à colaboração e
ao gerenciamento de documentos do servidor para as pastas de trabalho do
PowerPivot publicadas em sites do SharePoint. Para obter mais informações,
consulte o artigo sobre o PowerPivot para SharePoint
(http://go.microsoft.com/fwlink/?linkid=199547&clcid=0x416).
Master Data Services
O SQL Server Master Data Services permite gerenciar centralmente ativos de dados importantes de toda a empresa e entre vários sistemas para fornecer dados mais confiáveis aos aplicativos de BI. O Master Data Services ajuda a criar um centro de distribuição de dados mestres que inclui um aplicativo de gerenciamento de dados de clientes finos para um administrador de dados. O aplicativo também pode aplicar fluxo de trabalho a proprietários atribuídos, aplicar regras de negócios extensíveis para garantir a qualidade dos dados e aplicar estratégias de gerenciamento de hierarquias e atributos. Para obter mais informações, consulte o artigo sobre o Master Data Services (http://go.microsoft.com/fwlink/?linkid=199548&clcid=0x416).
StreamInsight e processamento de eventos complexos
O Microsoft StreamInsight é um novo recurso no SQL Server 2008 R2 que apresenta uma plataforma avançada para o desenvolvimento e a implantação de aplicativos CEP (processamento de eventos complexos). O CEP é uma tecnologia de processamento de
216
fluxo de eventos com alta produtividade e baixa latência. O StreamInsight permite que você analise os dados sem primeiro armazená-los, além disso, ele ajuda a monitorar os dados de várias origens para detectar padrões, tendências e exceções de maneira praticamente instantânea. A habilidade de monitorar, analisar e agir em relação aos dados em movimento de forma controlada por evento oferece uma oportunidade significativa para tomar decisões comerciais de forma mais rápida e consciente. Para obter mais informações, consulte Microsoft StreamInsight (http://go.microsoft.com/fwlink/?linkid=199549&clcid=0x416).
Ferramentas de criação e publicação do SharePoint Server 2010 para business intelligence Veja a seguir as ferramentas de criação e publicação do SharePoint Server 2010 que contribuem com a criação de KPIs, scorecards, painéis e relatórios. Cada uma das ferramentas pode ser vinculada a dados relacionais e multidimensionais do SQL Server. Para saber mais, consulte Data warehousing, OLAP and relational data for business intelligence in SharePoint. Para obter mais informações sobre os serviços e ver como cada ferramenta usa os dados do SQL Server, consulte Architecture for business intelligence in SharePoint Server 2010 e Choosing a business intelligence tool in SharePoint Server.
Serviços do Excel Use o Excel 2010 e os Serviços do Excel para visualizar,
atualizar e interagir com modelos analíticos conectados a fontes de dados. Também
use esses dados para análise, filtragem e apresentação de dados armazenados
localmente. O Excel 2010 é a ferramenta de criação. Os Serviços do Excel permitem
que você publique arquivos do Excel 2010 no SharePoint Server 2010.
Serviços do Visio Use os Serviços do Visio para criar uma representação visual
das estruturas de negócios que estão associadas aos dados. Alguns exemplos
incluem a criação de recursos, sistemas e processos visuais que mostram o
desempenho visual. Por exemplo, um engenheiro pode usar a visualização para criar
objetos associados a dados que representam um processo.
Serviços PerformancePoint Use os Serviços PerformancePoint para criar painéis,
scorecards e KPIs (indicadores chave de desempenho) que oferecem uma versão
resumida do desempenho dos negócios. Os Serviços PerformancePoint oferecem ao
usuário análises integradas para monitoramento, análise e geração de relatórios.
Aplicativo de serviço Web Analytics Use o aplicativo de serviço Web Analytics
para saber mais sobre as visitas aos sites do SharePoint. O aplicativo de serviço
Web Analytics coleta dados sobre como os usuários finais acessam as páginas do
SharePoint.
Conteúdo relacionado
Central de recursos Gerenciamento da continuidade dos negócios para
SharePoint Server 2010
Business Intelligence no SharePoint Server 2010
217
(http://go.microsoft.com/fwlink/?linkid=199757&clcid=0x416)
Microsoft Business Intelligence (http://go.microsoft.com/fwlink/?linkid=199758&clcid=0x416)
SQL Server Tech Center (http://go.microsoft.com/fwlink/?linkid=199760&clcid=0x416)
Dados multidimensionais do SSAS (SQL Server Analysis Services) (http://go.microsoft.com/fwlink/?linkid=199761&clcid=0x416)
Mineração de dados do SSAS (SQL Server Analysis
Services) (http://go.microsoft.com/fwlink/?linkid=199762&clcid=0x416)
Conteúdo do desenvolvedor Centro de desenvolvedores do SharePoint (http://go.microsoft.com/fwlink/?linkid=159918&clcid=0x416)
Centro de desenvolvedores do SQL Server (http://go.microsoft.com/fwlink/?linkid=199764&clcid=0x416)
Mecanismo de banco de dados do SQL Server (http://go.microsoft.com/fwlink/?linkid=199765&clcid=0x416)
SSRS (SQL Server Reporting Services) (http://go.microsoft.com/fwlink/?linkid=199766&clcid=0x416)
SQL Server StreamInsight (http://go.microsoft.com/fwlink/?linkid=199767&clcid=0x416)
218
Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010)
Este artigo descreve como planejar e configurar o armazenamento e a camada do banco de dados do Microsoft SQL Server em um ambiente do Microsoft SharePoint Server 2010.
As informações de planejamento de capacidade neste documento fornece diretrizes a serem usadas por você em seu planejamento. Elas se baseiam em testes realizados na Microsoft em ativos em uso. No entanto, os resultados obtidos por você podem variar com base nos equipamentos usados e nos recursos implementados.
Como o SharePoint Server geralmente é executado em ambientes em que os bancos de dados são gerenciados por administradores de bancos de dados do SQL Server separados, este documento é destinado ao uso conjunto por implementadores de farms do SharePoint Server e administradores de bancos de dados do SQL Server. Ele pressupõe um grande entendimento do SharePoint Server e do SQL Server.
Este artigo pressupõe que você está familiarizado com os conceitos apresentados em Capacity management and sizing for SharePoint 2010 Products.
Processo de design e configuração do armazenamento e da camada do banco de dados dos Produtos SharePoint 2010 É recomendável que você divida o processo de design do armazenamento e da camada do banco de dados nas etapas a seguir. Cada seção fornece informações detalhadas sobre cada etapa de design, incluindo requisitos e práticas recomendadas de armazenamento:
Coletar requisitos de armazenamento e de espaço e E/S do SQL Server
Escolher a versão e a edição do SQL Server
Projetar a arquitetura de armazenamento com base em requisitos de capacidade e
E/S
Estimar requisitos de memória
Entender os requisitos de topologia de rede
Configurar o SQL Server
Validar e monitorar o desempenho do armazenamento e do SQL Server
219
Coletar requisitos de armazenamento e de espaço e E/S do SQL Server Vários fatores de arquitetura do SharePoint Server 2010 influenciam o design do armazenamento. A quantidade usada de conteúdo, recursos e aplicativos de serviço, o número de farms e a necessidade de disponibilidade são fatores-chave.
Antes de começar a planejar o armazenamento, você deve conhecer os bancos de dados que o SharePoint Server 2010 pode usar.
Nesta seção:
Bancos de dados usados por Produtos do SharePoint 2010
Conhecer o SQL Server e o IOPS
Estimar as necessidades de IOPS e armazenamento central
Estimar necessidades de armazenamento do aplicativo de serviço e IOPS
Determinar as necessidades de disponibilidade
Bancos de dados usados por Produtos do SharePoint 2010
Os bancos de dados instalados com o SharePoint Server 2010 dependem dos recursos que estejam sendo usados no ambiente. Todos os ambientes do Produtos do SharePoint 2010 dependem dos bancos de dados do sistema do SQL Server. Esta seção fornece um resumo dos bancos de dados instalados com o SharePoint Server 2010. Para obter informações detalhadas, consulte Database types and descriptions (SharePoint Server 2010) e o artigo sobre modelo de banco de dados (http://go.microsoft.com/fwlink/?linkid=187968&clcid=0x416).
Versão e edição do produto Bancos de dados
SharePoint Foundation 2010 Configuração
Conteúdo da Administração Central
Conteúdo (um ou mais)
Coleta de Dados de Uso e Integridade
Conectividade de Dados Corporativos
Serviço de Registro de Aplicativo (em caso
de atualização do Catálogo de Dados
Corporativos do Microsoft Office SharePoint Server 2007)
Serviço de Configurações de Inscrição (se
habilitado por meio do Windows PowerShell)
Bancos de dados adicionais para o SharePoint Server 2010 Standard Edition
Aplicativo de serviço de pesquisa:
Administração de pesquisa
Rastreamento (um ou mais)
Propriedades (uma ou mais)
Aplicativo de serviço de Perfil de Usuário:
220
Versão e edição do produto Bancos de dados
Perfil
Sincronização
Marcação social
Aplicativo de serviço do Web Analytics
Preparo
Relatórios
Repositório seguro
Estado
Metadados Gerenciados
Serviços de Automação do Word
Bancos de dados adicionais para o SharePoint Server 2010 Enterprise Edition
PerformancePoint
Bancos de dados adicionais para o Project Server 2010
Rascunho
Publicado
Arquivo morto
Relatórios
Bancos de dados adicionais para o FAST Search Server
Administração de pesquisa
Se você estiver fazendo uma integração mais completa com o SQL Server, seu ambiente também poderá inclui bancos de dados adicionais, como ocorre nos seguintes cenários:
O Microsoft SQL Server 2008 R2 PowerPivot para Microsoft SharePoint 2010 pode
ser usado em um ambiente do SharePoint Server 2010 que inclui o SQL Server 2008
R2 Enterprise Edition e oSQL Server Analysis Services. Você também deve planejar
dar suporte para o banco de dados do aplicativo PowerPivot, caso ele esteja sendo
usado, e para a carga adicional sobre o sistema. Para obter mais informações,
consulte o artigo sobre como planejar uma implantação do PowerPivot em um farm
do SharePoint (http://go.microsoft.com/fwlink/?linkid=186698&clcid=0x416).
O plug-in do Microsoft SQL Server 2008 Reporting Services (SSRS) pode ser usado
com qualquer ambiente dos Produtos do SharePoint 2010. Se estiver usando o plug-
in, planeje oferecer suporte para os dois bancos de dados do SQL Server 2008
Reporting Services e para a carga adicional necessária para o SQL Server 2008
Reporting Services.
Conhecer o SQL Server e o IOPS
Em qualquer servidor que hospede o SQL Server, é muito importante que o servidor obtenha a resposta mais rápida possível do subsistema de E/S.
Uma quantidade maior de discos ou matrizes mais rápidos fornecem IOPS (operações de E/S por segundo) suficientes, embora mantendo baixa latência e enfileiramento em todos os discos.
221
Uma baixa resposta do subsistema de E/S não pode ser compensada pela inclusão de outros tipos de recursos, como CPU ou memória; no entanto, ela pode influenciar e causar problemas para todo o farm. Planeje uma latência mínima antes da implantação e monitore os sistemas existentes.
Antes de implantar um novo farm, é recomendável que você avalie o desempenho do subsistema de E/S usando a ferramenta de parâmetro de comparação de subsistema de disco SQLIO. Para obter detalhes, consulte o artigo sobre a ferramenta de parâmetro de comparação de subsistema de disco SQLIO (http://go.microsoft.com/fwlink/?linkid=105586&clcid=0x416).
Para obter informações detalhadas sobre como analisar os requisitos de IOPS do ponto de vista do SQL Server, consulte o documento sobre como analisar características de E/S e dimensionar sistemas de armazenamento para aplicativos de bancos de dados do SQL Server (http://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx).
Estimar as necessidades de IOPS e armazenamento central
O armazenamento da configuração e do conteúdo e as IOPS são a camada básica que você deve planejar em todas as implantações do SharePoint Server 2010.
Armazenamento de configuração e IOPS
Os requisitos de armazenamento para o banco de dados de Configuração e o banco de dados de conteúdo da Administração Central não são grandes. É recomendável alocar 2 GB para o banco de dados de Configuração e 1 GB para o banco de dados de conteúdo da Administração Central. Com o tempo, o banco de dados de Configuração pode crescer e passar de 1 GB, mas isso não acontece rapidamente — ele cresce aproximadamente 40 MB para cada 50 mil conjuntos de sites.
Os logs de transação do banco de dados de Configuração podem ser grandes. É recomendável, portanto, que você altere o modelo de recuperação do banco de dados de completo para simples.
Observação:
Se desejar usar o espelhamento do banco de dados do SQL Server para fornecer
disponibilidade para o banco de dados de Configuração, você deverá usar o modelo de
recuperação completo.
Os requisitos de IOPS para o banco de dados de Configuração e o banco de dados de conteúdo da Administração Central são mínimos.
Armazenamento de conteúdo e IOPS
A estimativa do armazenamento e das IOPS necessárias para bancos de dados de conteúdo não é uma atividade precisa. Ao testar e explicar as informações a seguir, pretendemos ajudar você a obter estimativas a serem usadas para determinar o tamanho inicial da sua implantação. No entanto, quando seu ambiente estiver em execução, esperamos que você recalcule suas necessidades de capacidade com base nos dados do ambiente real.
Para obter mais informações sobre nossa metodologia geral de planejamento de capacidade, consulte Capacity management and sizing for SharePoint 2010 Products.
Estimar o armazenamento do banco de dados de conteúdo
222
O seguinte processo descreve como estimar de modo aproximado o armazenamento necessário para bancos de dados de conteúdo, sem considerar os arquivos de log:
1. Calcule o número esperado de documentos. Esse valor é expresso na fórmula como
D.
A forma de cálculo do número de documentos será determinada pelos recursos que você estiver usando. Por exemplo, para sites do Meu Site ou sites de colaboração, é recomendável calcular o número esperado de documentos por usuário e multiplicar esse valor pelo número de usuários. Para sites de gerenciamento de registros ou de publicação de conteúdo, você pode calcular o número de documentos gerenciados e gerados por um processo.
Se você estiver migrando de um sistema atual, talvez seja mais fácil extrapolar o uso e a taxa de crescimento atual. Se estiver criando um novo sistema, avalie os compartilhamentos de arquivos existentes ou outros repositórios e faça a estimativa com base nessa taxa de uso.
2. Estime o tamanho médio dos documentos que está armazenando. Esse valor é
expresso na fórmula como S.Talvez valha a pena estimar médias para diferentes
tipos ou grupos de sites. O tamanho médio do arquivo para sites do Meu Site,
repositórios de mídia e diferentes portais de departamentos pode variar
significativamente.
3. Estime o número de itens da lista no ambiente. Esse valor é expresso na fórmula
como L.
É mais difícil estimar itens da lista do que documentos. Geralmente usamos uma estimativa equivalente a três vezes o número de documentos (D), mas isso varia com base em como você espera usar seus sites.
4. Determine o número aproximado de versões. Estime o número médio de versões
que qualquer documento de uma biblioteca terá (esse valor geralmente será muito
menor do que o número máximo permitido de versões). Esse valor é expresso na
fórmula como V.
O valor de V deve ser maior do que zero.
5. Use a seguinte fórmula para estimar o tamanho de seus bancos de dados de
conteúdo:
Tamanho do banco de dados = ((D × V) × S) + (10 KB × (L + (V × D)))
O valor de 10 KB na fórmula é uma constante que estima aproximadamente a quantidade de metadados exigidos pelo SharePoint Server 2010. Se o seu sistema exigir o uso significativo de metadados, convém aumentar essa constante.
Como exemplo, se você pretendesse usar a fórmula para estimar a quantidade de espaço de armazenamento necessário para os arquivos de dados de um banco de dados de conteúdo em um ambiente de colaboração com as características a seguir, seriam necessários aproximadamente 105 GB.
Entrada Valor
Número de documentos (D) 200.000
Calculado como 10.000 usuários vezes 20
documentos
223
Entrada Valor
Tamanho médio dos documentos (S) 250 KB
Itens da lista (L) 600.000
Número de versões não atuais (V) 2
Presumindo que o máximo permitido de
versões é 10
Tamanho do banco de dados = (((200.000 x 2)) × 250) + ((10 KB × (600.000 + (200.000 x 2))) = 110.000.000 KB ou 105 GB
Recursos que afetam o tamanho dos bancos de dados de conteúdo
O uso dos seguintes recursos do SharePoint Server 2010 pode afetar significativamente o tamanho dos bancos de dados de conteúdo:
Lixeiras Enquanto um documento não for totalmente excluído das lixeiras de
primeiro e segundo estágio, ele ocupará espaço em um banco de dados de
conteúdo. Calcule quantos documentos são excluídos a cada mês para determinar o
efeito das lixeiras no tamanho dos bancos de dados de conteúdo. Para obter mais
informações, consulte Configure Recycle Bin settings (SharePoint Server 2010).
Auditoria Os dados de auditoria podem compor e usar grandes quantidades de
espaço em um banco de dados de conteúdo, especialmente se a auditoria de
exibição estiver ativada. Em vez de permitir que os dados de auditoria se expandam
sem limite, recomendamos que você habilite apenas a auditoria dos eventos que
sejam importantes para cumprir requisitos regulatórios ou para controles internos.
Use as seguintes diretrizes para estimar o espaço que precisará reservar para dados
de auditoria:
Estime o número de novas entradas de auditoria para um site e multiplique esse
número por 2 KB (as entradas geralmente estão limitadas a 4 KB, com um
tamanho médio aproximado de 1 KB).
Com base no espaço que você deseja alocar, determine o número de dias de
logs de auditoria que deseja manter.
Office Web Apps. Se o Office Web Apps estiver sendo usado, o cache do Office Web
Apps poderá afetar significativamente o tamanho de um banco de dados de
conteúdo. Por padrão, o cache do Office Web Apps é configurado como 100 GB.
Para obter mais informações sobre o tamanho do cache do Office Web Apps,
consulte Manage the Office Web Apps cache.
Estimar os requisitos de IOPS do banco de dados de conteúdo
Os requisitos de IOPS para bancos de dados de conteúdo variam muito de acordo com o modo como o seu ambiente está sendo usado e com a quantidade existente de espaço em disco e servidores. Em geral, é recomendável comparar a carga de trabalho prevista em seu ambiente com uma das soluções testadas. Para obter mais informações, consulte Performance and capacity test results and recommendations.
224
Importante:
O teste do conteúdo desta seção ainda não foi concluído. Verifique a existência de
informações adicionais.
Estimar necessidades de armazenamento do aplicativo de serviço e IOPS
Depois de estimar as necessidades de armazenamento de conteúdo e de IOPS, você deverá determinar o armazenamento e as IOPS exigidas pelos aplicativos de serviço que estão sendo usados em seu ambiente.
Requisitos de IOPS e armazenamento de aplicativos de serviço do SharePoint Foundation 2010
Para estimar os requisitos de armazenamento dos aplicativos de serviço no sistema, primeiro você deve conhecer os aplicativos de serviço e saber como usá-los. Os aplicativos de serviço disponíveis no SharePoint Foundation 2010 que têm bancos de dados são listados na tabela a seguir.
Banco de dados de aplicativos de serviço Recomendação de estimativa de tamanho
Coleta de Dados de Uso e Integridade O banco de dados de Uso pode crescer muito rapidamente e exigir um grande volume de IOPS.
Por exemplo, em ambientes de colaboração
que usam configurações predefinidas, um
milhão de solicitações HTTP exige 2 GB de
armazenamento.
Use uma das seguintes fórmulas para
estimar a quantidade necessária de IOPS:
115 × visitas/segundo
5 × solicitações HTTP
Se você precisar restringir o tamanho do
banco de dados de uso, é recomendável
começar registrando em log apenas as
solicitações de páginas. Você também pode
restringir o tamanho do banco de dados
definindo o intervalo de dados padrão a ser
mantido como inferior a duas semanas.
Se possível, coloque o banco de dados de
Uso em seu próprio disco ou eixo.
Serviço Conectividade de Dados
Corporativos
O tamanho do banco de dados dos serviços
Conectividade de Dados Corporativos é
afetado principalmente pelo número de tipos
de conteúdo externo a que você planeja dar
225
Banco de dados de aplicativos de serviço Recomendação de estimativa de tamanho
suporte. Aloque 0,5 MB para cada tipo de
conteúdo externo. Se você não sabe de
quantos tipos de conteúdo externo poderá
precisar, é recomendável alocar 50 MB. Os
requisitos de IOPS são mínimos.
Serviço de Registro de Aplicativo Aloque 1 GB apenas se estiver fazendo
uma atualização do Catálogo de Dados
Corporativos do Microsoft Office SharePoint
Server 2007. Os requisitos de IOPS são
mínimos.
Configurações de inscrição Aloque 1 GB. Os requisitos de IOPS são
mínimos.
Requisitos de IOPS e armazenamento de aplicativos de serviço do SharePoint Server 2010
Para estimar os requisitos de armazenamento dos aplicativos de serviço no sistema, primeiro você deve conhecer os aplicativos de serviço e saber como usá-los. Os aplicativos de serviço disponíveis no SharePoint Server 2010 que têm bancos de dados são listados na tabela a seguir.
Aplicativo de serviço Recomendação de estimativa de tamanho
Pesquisa A Pesquisa exige três bancos de dados.
Seu ambiente pode incluir vários bancos de
dados de Propriedade e Rastreamento.
O banco de dados de administração de
Pesquisa geralmente é pequeno: aloque
10 GB.
Para estimar o armazenamento necessário
para seus bancos de dados de Propriedade e Rastreamento, use os seguintes multiplicadores:
Rastreamento: 0,046 × (soma dos
bancos de dados de conteúdo)
Propriedade: 0,015 × (soma dos bancos
de dados de conteúdo)
Os requisitos de IOPS para Pesquisa são
significativos.
Para o banco de dados de
Rastreamento, a pesquisa exige de
3.500 a 7.000 IOPS.
Para o banco de dados de Propriedade,
226
Aplicativo de serviço Recomendação de estimativa de tamanho
a pesquisa precisa de 2.000 IOPS.
Para obter informações detalhadas sobre
como estimar a capacidade necessária para
Pesquisa, consulte Performance and capacity test results and recommendations.
Perfil do Usuário O aplicativo de serviço do Perfil do Usuário
está associado a três bancos de dados:
Perfil, Sincronização e Marcação Social.
Para estimar o armazenamento necessário
para os bancos de dados, use as seguintes
informações:
Perfil. Com configurações predefinidas,
em um ambiente configurado para usar
o Active Directory, o banco de dados de
perfil exigirá aproximadamente 1 MB
por perfil de usuário.
Sincronização. Com configurações
predefinidas, em um ambiente com
poucos grupos por usuário, o banco de
dados de sincronização exigirá
aproximadamente 630 KB por perfil de
usuário. O arquivo de dados usará 90%
do espaço.
Marcação social. Com configurações
prévias, o banco de dados de marcação
social exigirá aproximadamente
0,009 MB por marca, comentário ou
classificação. Para estimar quantas
marcas ou notas os usuários criarão,
analise as seguintes informações sobre
o site del.icio.us:
Aproximadamente 10% dos
usuários são considerados ativos.
Os usuários ativos criam 4,5
marcas e 1,8 comentários por mês.
Em um ambiente de colaboração dinâmica
com 160.000 perfis de usuários, cinco
grupos, 79.000 marcas, comentários e
classificações (2.500 comentários, 76.000
marcas e 800 classificações) e
configurações predefinidas, temos os
seguintes tamanhos para estes bancos de dados:
227
Aplicativo de serviço Recomendação de estimativa de tamanho
Nome do banco de dados
Tamanho do banco de dados
Perfil 155 GB
Sincronização 96 GB
Marcação social 0,66 GB
Metadados gerenciados O aplicativo de serviço Metadados
Gerenciados tem um banco de dados. O tamanho do banco de dados é afetado pelo
número de tipos de conteúdo e palavras-
chave usados no sistema. Muitos ambientes
incluirão várias instâncias do aplicativo de
serviço Metadados Gerenciados. Para obter
informações detalhadas sobre como estimar
o tamanho e os requisitos de IOPS desse banco de dados, consulte Performance and capacity test results and recommendations.
Web Analytics O Web Analytics tem dois bancos de dados:
Preparo e Relatórios. Muitos fatores
influenciam o tamanho dos bancos de
dados. Entre eles, estão o período de
retenção, o volume diário de dados
rastreados e o número de conjuntos de
sites, sites e subsites no aplicativo Web que
está sendo analisado. Para obter
informações detalhadas sobre como estimar
seus requisitos de tamanho e IOPS, consulte Performance and capacity test results and recommendations.
Repositório seguro O tamanho do banco de dados do aplicativo de serviço de Repositório Seguro é
determinado pelo número de credenciais no
repositório e pelo número de entradas na
tabela de auditoria. É recomendável alocar
5 MB para cada 1.000 credenciais para ele.
A necessidade de IOPS é mínima.
Estado O aplicativo de serviço de Controle de
Sessão tem um banco de dados. É
recomendável alocar 1 GB para ele. A
necessidade de IOPS é mínima.
Serviço Word Automation O aplicativo de serviço Word Automation
228
Aplicativo de serviço Recomendação de estimativa de tamanho
tem um banco de dados. É recomendável
alocar 1 GB para ele. A necessidade de
IOPS é mínima.
PerformancePoint O aplicativo de serviço PerformancePoint
tem um banco de dados. É recomendável
alocar 1 GB para ele. A necessidade de
IOPS é mínima.
Determinar as necessidades de disponibilidade
A disponibilidade é um grau pelo qual um ambiente do SharePoint Server 2010 é percebido por usuários como disponível. Um sistema disponível é um sistema flexível — ou seja, incidentes que afetem o serviço ocorrem com pouca frequência e ações oportunas e eficientes são tomadas quando eles ocorrem.
Os requisitos de disponibilidade podem aumentar significativamente suas necessidades de armazenamento. Para obter informações detalhadas, consulte Planejar a disponibilidade (SharePoint Server 2010).
Escolher a versão e a edição do SQL Server Embora o Produtos do SharePoint 2010 possa ser executado no Microsoft SQL Server 2008 R2, SQL Server 2008 ou no SQL Server 2005, é altamente recomendável que você considere a possibilidade de executar seu ambiente na Enterprise Edition do SQL Server 2008 ou do SQL Server 2008 R2 para aproveitar os recursos adicionais de desempenho, disponibilidade, segurança e gerenciamento por ela fornecidos. Para obter mais informações sobre os benefícios de usar o SQL Server 2008 R2 Enterprise Edition, consulte SQL Server 2008 R2 e Produtos do SharePoint 2010: melhores juntos (white paper) (SharePoint Server 2010).
Você deve avaliar especialmente sua necessidade dos seguintes recursos:
Compactação de backup A compactação de backup pode agilizar qualquer
backup do SharePoint e está disponível no SQL Server 2008 Enterprise Edition ou
no SQL Server 2008 R2 Standard Edition. Ao configurar a opção de compactação
em seu script de backup ou ao configurar o servidor que está executando o SQL
Server para compactar por padrão, você pode reduzir significativamente o tamanho
do seus backups de bancos de dados e logs remetidos. Para obter mais
informações, consulte o artigo sobre compactação de backup (SQL Server)
(http://go.microsoft.com/fwlink/?linkid=129381&clcid=0x416).
Observação:
Não há suporte para a compactação de dados do SQL Server para o Produtos do
SharePoint 2010.
Criptografia de dados transparente Se os seus requisitos de segurança incluírem
a necessidade de criptografia de dados transparente, você deverá usar o SQL
Server Enterprise Edition.
229
Aplicativo de serviço do Web Analytics Se você planeja usar o aplicativo de
serviço do Web Analytics para análise significativa, avalie o uso do SQL Server
Enterprise Edition para que o sistema se beneficie do particionamento de tabelas.
Implantação de conteúdo Se você planeja usar o recurso de implantação de
conteúdo, avalie o uso do SQL Server Enterprise Edition para que o sistema se
beneficie dos instantâneos do banco de dados do SQL Server.
Remote BLOB storage Se você quiser aproveitar o remote BLOB storage em um
banco de dados ou local fora dos arquivos associados a cada banco de dados de
conteúdo, use o SQL Server 2008 ou o SQL Server 2008 R2 Enterprise Edition.
Administrador de recursos O Administrador de Recursos é uma tecnologia
lançada no SQL Server 2008 para gerenciar cargas de trabalho e recursos do SQL
Server por meio da especificação de limites para o consumo de recursos por
solicitações de entrada. O Administrador de Recursos permite diferenciar cargas de
trabalho e alocar CPU e memória à medida que elas são solicitadas, com base nos
em limites especificados por você. Ele está disponível apenas no SQL Server 2008
ou no SQL Server 2008 R2 Enterprise Edition. Para obter mais informações sobre o
uso do Administrador de Recursos, consulte o artigo sobre como gerenciar cargas
de trabalho do SQL Server com o Administrador de Recursos.
É recomendável usar o Administrador de Recursos com o SharePoint Server 2010 para:
Limitar a quantidade de recursos do SQL Server consumida pelos servidores
Web visados pelo componente de rastreamento de pesquisa. Como prática
recomendada, limite o componente de rastreamento a dez por cento da CPU
quando o sistema estiver sobrecarregado.
Monitorar quantos recursos cada banco de dados consome no sistema — por
exemplo, você pode usar o Administrador de Recursos para ajudar a determinar
a melhor colocação de bancos de dados entre computadores que estão
executando o SQL Server.
PowerPivot para SharePoint 2010 Permite que os usuários
compartilhem análises e modelos de dados gerados por usuários e colaborem neles
no Excel e no navegador enquanto atualiza automaticamente essas análises. Faz
parte do SQL Server 2008 R2 Enterprise Edition Analysis Services.
Projetar a arquitetura de armazenamento com base em requisitos de capacidade e E/S A arquitetura de armazenamento e os tipos de disco selecionados para o seu ambiente podem afetar o desempenho do sistema.
Nesta seção:
Escolher uma arquitetura de armazenamento
Escolher tipos de disco
Escolher tipos de RAID
Escolher uma arquitetura de armazenamento
Há suporte para as arquiteturas de armazenamento DAS (armazenamento de conexão direta), SAN (rede de área de armazenamento) e NAS (armazenamento conectado à
230
rede) com o SharePoint Server 2010, mas o suporte para NAS se restringe apenas ao uso com bancos de dados de conteúdo configurados para utilizar remote BLOB storage. Sua escolha depende de fatores da sua solução de negócios e da sua infraestrutura existente.
Qualquer arquitetura de armazenamento deve dar suporte para suas necessidades de disponibilidade e ter um desempenho adequado em IOPS e latência. Para ter suporte, o sistema deve retornar de modo consistente o primeiro byte de dados dentro 20 milissegundos (ms).
DAS (armazenamento de conexão direta)
O DAS é um sistema de armazenamento digital diretamente conectado a um servidor ou a uma estação de trabalho, sem uma rede de armazenamento intermediária. Os tipos de disco físico DAS incluem SAS (Serial Attached SCSI) e SATA (Serial Attached ATA).
Em geral, é recomendável que você escolha uma arquitetura DAS quando uma plataforma de armazenamento compartilhada não possa assegurar um tempo de resposta de 20 ms e capacidade suficiente para IOPS médio e máximo.
SAN (rede de área de armazenamento)
A SAN é uma arquitetura para conectar dispositivos remotos de armazenamento de computador (como matrizes de discos e bibliotecas de fitas) a servidores de um modo que os dispositivos sejam exibidos como conectados localmente ao sistema operacional (por exemplo, armazenamento em bloco).
Em geral, é recomendável escolher uma SAN quando os benefícios do armazenamento compartilhado sejam importantes para a sua organização.
Estes são alguns benefícios do armazenamento compartilhado:
Realocação mais fácil de armazenamento em disco entre servidores.
Pode atender a vários servidores.
Nenhuma limitação de número de discos que podem ser acessados.
NAS (armazenamento conectado à rede)
Uma unidade de NAS é um computador autônomo conectado a uma rede. Seu único objetivo é fornecer serviços de armazenamento de dados baseados em arquivos para outros dispositivos na rede. O sistema operacional e outros softwares na unidade de NAS fornecem a funcionalidade do armazenamento de dados, sistemas de arquivos e acesso a arquivos, bem como o gerenciamento dessas funcionalidades (por exemplo, armazenamento de arquivos).
Observação:
O suporte para NAS se restringe apenas ao uso com bancos de dados de conteúdo
configurados para utilizar remote BLOB storage. Qualquer arquitetura de
armazenamento de rede deve responder a um ping dentro de 1 ms e deve retornar o
primeiro byte de dados em 20 ms. Essa restrição não se aplica ao provedor
FILESTREAM local do SQL Server porque ele apenas armazena dados localmente no mesmo servidor.
Escolher tipos de disco
231
Os tipos de disco usados no sistema podem afetar a confiabilidade e o desempenho. Com todos os outros fatores inalterados, unidades maiores aumentam o tempo médio de busca. O SharePoint Server 2010 dá suporte aos seguintes tipos de unidades:
SCSI
SATA
SAS
FC
Interface IDE
Unidade de estado sólido ou Disco Flash
Escolher tipos de RAID
O RAID (Redundant Array of Independent Disks) é usado geralmente para melhor as características de desempenho de discos individuais (por meio da distribuição de dados por vários discos) e para fornecer proteção contra falhas de disco individuais.
Todos os tipos de RAID dão suporte ao SharePoint Server 2010; no entanto, é recomendável usar o RAID 10 ou uma solução de RAID específica de um fornecedor com desempenho equivalente.
Ao configurar uma matriz RAID, não se esqueça de alinhar o sistema de arquivos ao deslocamento informado pelo fornecedor. Na ausência de orientação do fornecedor, consulte o artigo sobre práticas recomendadas de E/S pré-implantação do SQL Server (http://go.microsoft.com/fwlink/?linkid=105583&clcid=0x416).
Para obter mais informações sobre como provisionar RAID e o subsistema de E/S do SQL Server, consulte o artigo sobre práticas recomendadas do SQL Server (http://go.microsoft.com/fwlink/?linkid=168612&clcid=0x416).
Estimar requisitos de memória A memória necessária para o SharePoint Server 2010 está diretamente relacionada ao tamanho dos bancos de dados de conteúdo hospedados em um servidor que executa o SQL Server.
À medida que você adiciona aplicativos de serviço e recursos, seus requisitos tendem a crescer. A tabela a seguir dá diretrizes sobre a quantidade de memória recomendável.
Observação:
Nossas definições de implantações pequenas e médias são descritas na seção
"Arquiteturas de referência" do artigo Capacity management and sizing for SharePoint
Server 2010.
Tamanho combinado de bancos de dados de
conteúdo
RAM recomendada para computadores que executam o SQL Server
Mínimo para pequenas implantações de
produção
8 GB
232
Tamanho combinado de bancos de dados de
conteúdo
RAM recomendada para computadores que executam o SQL Server
Mínimo para médias implantações de
produção
16 GB
Recomendação para até 2 terabytes 32 GB
Recomendação para a faixa entre 2
terabytes até o máximo de 5 terabytes
64 GB
Observação:
Esses valores são maiores do que os recomendados como mínimos para o SQL Server
devido à distribuição dos dados necessários para um ambiente do SharePoint Server
2010. Para obter mais informações sobre requisitos de sistema do SQL Server, consulte
Requisitos de hardware e software para a instalação do SQL Server 2008
(http://go.microsoft.com/fwlink/?linkid=129377&clcid=0x416).
Estes são alguns dos outros fatores que podem influenciar a memória exigida:
O uso de espelhamento do SQL Server.
O uso frequente de arquivos maiores do que 15 megabytes (MB).
Entender os requisitos de topologia de rede Planeje as conexões de rede dentro dos farms e entre eles. É recomendável usar uma rede de baixa latência.
A lista a seguir fornece algumas práticas recomendadas:
Todos os servidores no farm devem ter largura de banda e latência de LAN (rede
local) para o servidor que está executando o SQL Server. A latência não deve ser
maior do que 1 ms.
Não é recomendável uma topologia de WAN (rede de longa distância) em que um
servidor que esteja executando o SQL Server seja implantado remotamente de
outros componentes do farm através de uma rede com latência maior do que 1 ms.
Essa topologia não foi testada.
Planeje uma rede WAN adequada se estiver planejando usar o espelhamento do
SQL Server ou o envio de logs para manter um site remoto atualizado.
É recomendável que os servidores Web e os servidores de aplicativos tenham dois
adaptadores de rede: um para gerenciar o tráfego do usuário final e o outro para
gerenciar a comunicação com os servidores que executam o SQL Server.
Configurar o SQL Server As seções a seguir descrevem como planejar a configuração do SQL Server para o SharePoint Server 2010.
233
Nesta seção:
Determinar quantas instâncias ou servidores são necessários
Configurar o armazenamento e a memória
Definir opções do SQL Server
Configurar bancos de dados
Estimar quantos servidores são necessários
Em geral, o SharePoint Server 2010 é designado para aproveitar o dimensionamento do SQL Server — ou seja, o SharePoint Server 2010 pode ter um desempenho melhor com um grande número de servidores de médio porte que executam o SQL Server do que com apenas alguns grandes servidores.
Sempre coloque o SQL Server em um servidor dedicado que não esteja executando qualquer outra função de farm ou hospedando bancos de dados de qualquer outro aplicativo, a menos que você esteja implantando o sistema em um servidor autônomo.
A seguir, é apresentada uma orientação geral sobre quando implantar um servidor adicional para executar o SQL Server:
Adicione outro servidor de banco de dados quando tiver mais de quatro servidores
Web que estejam sendo executados em plena capacidade.
Adicione outro servidor de banco de dados quando seus bancos de dados de
conteúdo ultrapassarem 5 terabytes.
Observação:
A Microsoft dá suporte a configurações de servidor que não seguem esta orientação.
Para promover o armazenamento seguro de credenciais quando estiver executando o aplicativo de serviço Repositório Seguro, é recomendável que o banco de dados de repositório seguro esteja hospedado em uma instância separada de banco de dados em que o acesso seja limitado a um administrador.
Configurar o armazenamento e a memória
No servidor que está executando o SQL Server 2008, é recomendável que o cache L2 por CPU tenha um mínimo de 2 MB para melhorar a memória.
Siga as recomendações de configuração de armazenamento do fornecedor
Para obter um desempenho ideal ao configurar uma matriz de armazenamento física, siga as recomendações de configuração de hardware informadas pelo fornecedor de armazenamento, em vez de adotar os valores padrão do sistema operacional.
Se você não receber orientações do fornecedor, recomendamos que use o utilitário de configuração de disco DiskPart.exe para configurar o armazenamento para o SQL Server 2008. Para obter mais informações, consulte o artigo sobre melhores práticas de E/S de pré-implantação (http://go.microsoft.com/fwlink/?linkid=105583&clcid=0x416).
Forneça o máximo de recursos possível
Verifique se os canais de E/S do SQL Server para os discos não são compartilhados por outros aplicativos, como o arquivo de paginação e os logs do IIS (Serviços de Informações da Internet).
234
Forneça o máximo possível de banda larga. Maior banda larga de barramento ajuda a melhorar a confiabilidade e o desempenho. Lembre-se de que o disco não é o único usuário da banda larga de barramento — por exemplo, você também deve considerar o acesso à rede.
Definir opções do SQL Server
As seguintes configurações e opções do SQL Server devem ser definidas antes da implantação do SharePoint Server.
Não habilite estatísticas de criação automática em um SQL Server que esteja dando
suporte ao SharePoint Server. O SharePoint Server implementa estatísticas
específicas. Nenhuma estatística adicional é necessária. As estatísticas de criação
automática podem alterar significativamente o plano de execução de uma consulta
de uma instância do SQL Server para outra instância do SQL Server. Portanto, para
dar suporte consistente para todos os clientes, o SharePoint Server fornece dicas
codificadas para consultas, de acordo com a necessidade, para fornecer o melhor
desempenho em todos os cenários.
Para garantir um desempenho ideal, é altamente recomendável definir o grau
máximo de paralelismo como 1 para servidores de banco de dados que hospedam
bancos de dados do SharePoint Server 2010. Para obter mais informações sobre
como definir o grau máximo de paralelismo, consulte o artigo sobre a opção de
grau máximo de paralelismo
(http://go.microsoft.com/fwlink/?linkid=189030&clcid=0x416).
Para facilitar a manutenção, configure aliases de conexão do SQL Server para cada
servidor de banco de dados em seu farm. Um alias de conexão é um nome
alternativo que pode ser usado para estabelecer uma conexão com uma instância do
SQL Server. Para obter mais informações, consulte o artigo sobre como definir um
alias do SQL Server (SQL Server Management Studio)
(http://go.microsoft.com/fwlink/?linkid=132064&clcid=0x416).
Configurar bancos de dados
As orientações a seguir descrevem práticas recomendadas de planejamento na configuração de cada banco de dados em seu ambiente.
Separe e priorize seus dados em discos
De modo ideal, você deve colocar o banco de dados tempdb, os bancos de dados de conteúdo, o banco de dados de Uso, os bancos de dados de pesquisa e os logs de transações do SQL Server 2008 em discos rígidos separados.
A lista a seguir fornece algumas práticas recomendadas de priorização de dados:
Ao priorizar dados em discos mais rápidos, use a seguinte classificação:
1. Arquivos de dados tempdb e logs de transações
2. Arquivos de log de transações do banco de dados
3. Bancos de dados de pesquisa, com exceção do banco de dados de
administração de Pesquisa
4. Arquivos de dados de banco de dados
Em um site de portal fortemente orientado à leitura, priorize dados em relação a logs.
235
Testes e dados de clientes mostram que o desempenho de farms do SharePoint
Server 2010 pode ser muito prejudicado por E/S insuficiente de disco para o tempdb.
Para evitar esse problema, aloque discos dedicados para o tempdb. Se uma alta
carga de trabalho estiver projetada ou monitorada — ou seja, a operação de leitura
média ou a operação de gravação média exigir mais do que 20 ms — talvez você
precise reduzir o afunilamento separando os arquivos em discos ou substituindo os
discos por outros mais rápidos.
Para melhorar o desempenho, coloque o tempdb em uma matriz RAID 10. O número
de arquivos de dados do tempdb deve ser igual ao número de núcleos de CPUs e os
arquivos de dados do tempdb devem ser definidos com o mesmo tamanho. Conte
processadores de núcleo duplo como duas CPUs para essa finalidade. Conte cada
processador que dê suporte a hyperthreading como uma CPU. Para obter mais
informações, consulte o artigo sobre como otimizar o desempenho do tempdb
(http://go.microsoft.com/fwlink/?linkid=148537&clcid=0x416).
Separe dados de banco de dados e arquivos de log de transações em diferentes
discos. Se os arquivos precisarem compartilhar discos porque os arquivos são muito
pequenos para justificar o uso de um disco inteiro ou de uma faixa inteira, ou se
faltar espaço em disco, coloque os arquivos que têm padrões de uso diferentes no
mesmo disco para minimizar solicitações de acesso simultâneo.
Consulte o fornecedor do seu hardware de repositório para obter informações sobre
como configurar todos os logs e os bancos de dados de pesquisa a fim de otimizar a
gravação em sua solução de repositório específica.
Use vários arquivos de dados para bancos de dados de conteúdo
Siga estas recomendações para melhorar o desempenho:
Crie apenas arquivos no grupo de arquivos primário do banco de dados.
Distribua os arquivos por discos separados.
O número de arquivos de dados deve ser menor ou igual ao número de núcleos de
CPUs. Conte processadores de núcleo duplo como duas CPUs para essa finalidade.
Conte cada processador que dê suporte a hyperthreading como uma CPU.
Crie arquivos de dados de mesmo tamanho.
Importante:
Embora você possa usar as ferramentas de backup e recuperação internas do
SharePoint Server 2010 para fazer backup e recuperar vários arquivos de dados, se
você substituí-los no mesmo local, as ferramentas não poderão restaurar vários arquivos
de dados em um local diferente. Por esse motivo, é altamente recomendável que, ao
usar vários arquivos de dados para um banco de dados de conteúdo, você use as
ferramentas de backup e recuperação do SQL Server. Para obter mais informações
sobre como fazer backup e recuperar o SharePoint Server 2010, consulte Planejar o
backup e a recuperação (SharePoint Server 2010).
Para obter mais informações sobre como criar e gerenciar grupos de arquivos, consulte o artigo sobre arquivos e grupos de arquivos físicos de banco de dados (http://go.microsoft.com/fwlink/?linkid=117909&clcid=0x416).
236
Limite o tamanho do banco de dados de conteúdo para melhorar a capacidade de gerenciamento
Planeje o dimensionamento do banco de dados para melhorar a capacidade de gerenciamento, o desempenho e a facilidade de atualização do seu ambiente.
Para ajudar a garantir o desempenho do sistema, é altamente recomendável limitar o tamanho dos bancos de dados de conteúdo a 200 GB.
Um conjunto de sites não deve ultrapassar 100 GB, a menos que haja apenas um conjunto de sites no banco de dados. Esse limite existe para que você possa usar as ferramentas de backup granular do SharePoint Server 2010 para mover um conjunto de sites para outro banco de dados, se precisar.
Importante:
Há suporte para tamanhos de bancos de dados de conteúdo de até 1 terabyte somente
para grandes repositórios de um único site e arquivos nos quais os dados permanecem
razoavelmente estáticos, como sistemas de gerenciamento de documentos de referência
e sites de Central de Registros. Há suporte para tamanhos de bancos de dados maiores
nesses cenários porque seus padrões de E/S e formatos típicos de estrutura de dados
foram projetados e testados em escalas maiores.
Se o seu design exigir um banco de dados maior do que o padrão recomendado, siga esta orientação:
Para bancos de dados que contenham muitos arquivos grandes armazenados como
BLOBs (objetos binários grandes), avalie a possibilidade de usar RBS (remote BLOB
storage). O RBS é adequado nas seguintes circunstâncias:
1. Quando você estiver executando sites que contenham arquivos grandes pouco
acessados, como repositórios de conhecimento.
2. Quando você tiver terabytes de dados.
3. Para arquivos de vídeo ou mídia.
Para obter mais informações, consulte Planejar o RBS (Remote BLOB Storage) (SharePoint Server 2010).
Siga práticas recomendadas de exibição de dados de grandes bancos de dados.
Para obter mais informações, consulte SharePoint Server 2010 Capacity
Management: Software Boundaries and Limits.
Para obter mais informações sobre repositórios de documentos em grande escala, consulte a seção sobre estimativa de requisitos de desempenho e capacidade para repositórios de documentos em grande escala, disponível em Performance and capacity test results and recommendations (SharePoint Server 2010).
Gerencie de modo proativo o crescimento dos arquivos de dados e log
É recomendável gerenciar de maneira proativa o crescimento dos arquivos de dados e log, considerando as seguintes recomendações:
Sempre que possível, expanda previamente todos os arquivos de dados e log para
seu tamanho final previsto.
237
É recomendável habilitar o aumento automático por razões de segurança. Não
confie nas configurações padrão de aumento automático. Leve em conta as
seguintes diretrizes ao configurar o aumento automático:
Quando planejar bancos de dados de conteúdo que ultrapassem o tamanho
recomendado (200 GB), defina o valor de aumento automático do banco de
dados para um número fixo de megabytes, e não para uma porcentagem. Isso
reduz a frequência com que o SQL Server aumenta o tamanho de um arquivo.
Aumentar o tamanho do arquivo é uma operação de bloqueio que envolve o
preenchimento do novo espaço com páginas vazias.
Defina o valor de aumento automático para o banco de dados de Repositório de
Propriedades do aplicativo de serviço de Pesquisa como 10 por cento.
Se não houver previsão de que o tamanho calculado do banco de dados de
conteúdo alcance o tamanho máximo recomendado de 200 GB dentro de um
ano, defina-o como o tamanho máximo que o banco de dados deve alcançar em
um ano (com 20% de margem adicional de erro) usando a propriedade ALTER
DATABASE MAXSIZE. Revise periodicamente essa configuração para verificar
se ela ainda tem um valor adequado com base nas taxas de crescimento
anteriores.
Mantenha um nível de pelo menos 25 por cento de espaço disponível nos discos
para estabelecer padrões de crescimento e uso máximo. Se você estiver
gerenciando o crescimento por meio da inclusão de discos em uma matriz RAID ou
da alocação de mais armazenamento, monitore o tamanho do disco cuidadosamente
para evitar ficar sem espaço.
Validar e monitorar o desempenho do armazenamento e do SQL Server Teste se a solução de desempenho e backup do seu hardware permite que você cumpra seus SLAs (contratos de nível de serviço). Teste especificamente o subsistema de E/S do computador que está executando o SQL Server para garantir que o desempenho seja satisfatório.
Teste a solução de backup que você está usando para garantir que ela possa fazer backup do sistema dentro da janela de manutenção disponível. Se a solução de backup não puder atender aos SLAs exigidos por seu negócio, avalie a possibilidade de usar uma solução de backup incremental, como o System Center Data Protection Manager (DPM) 2010.
É importante controlar os seguintes componentes de recursos de um servidor que executa o SQL Server: CPU, memória, taxa de acertos do cache e subsistema de E/S. Quando um ou mais dos componentes parecerem lentos ou sobrecarregados, analise a estratégia apropriada com base na carga de trabalho atual e projetada. Para obter mais informações, consulte o artigo sobre como solucionar problemas de desempenho no SQL Server 2008 (http://go.microsoft.com/fwlink/?linkid=168448&clcid=0x416).
A seção a seguir relaciona os contadores de desempenho de uso recomendado para monitorar o desempenho dos bancos de dados do SQL Server que estão sendo executados em seu ambiente do SharePoint Server 2010. Também estão descritos valores aproximados de integridade para cada contador.
238
Para obter detalhes sobre como monitorar o desempenho e usar contadores de desempenho, consulte o artigo sobre como monitorar desempenho (http://go.microsoft.com/fwlink/?linkid=189032&clcid=0x416).
Contadores do SQL Server a serem monitorados
Monitore os seguintes contadores do SQL Server para garantir a integridade de seus servidores:
Estatísticas gerais Este objeto fornece contadores para monitorar a atividade
geral em todo o servidor, como o número de conexões atuais e o número de
usuários que se conectam e desconectam por segundo de computadores que
executam uma instância do SQL Server. Avalie a possibilidade de monitorar o
seguinte contador:
Conexões de usuário Este contador mostra a quantidade de conexões de
usuário no seu computador que executa o SQL Server. Se você vir esse número
crescer 500 por cento em relação à linha de base, talvez experimente uma
redução do desempenho.
Bancos de dados Este objeto fornece contadores para monitorar operações de
cópia em massa, produtividade de backup e restauração e atividades de log de
transações. Monitore as transações e o log de transações para determinar o volume
de atividades dos usuários no banco de dados e o quanto o log de transações está
ficando cheio. O volume de atividades dos usuários pode determinar o desempenho
do banco de dados e afetar o tamanho do log, o bloqueio e a replicação. Monitorar a
atividade de log de baixo nível para medir a atividade dos usuários e o uso de
recursos pode ajudar você a identificar afunilamentos de desempenho. Avalie a
possibilidade de monitorar o seguinte contador:
Transações/s Este contador mostra a quantidade de transações por segundo
em um determinado banco de dados ou no servidor inteiro. Esse número é mais
para a sua linha de base e para ajudar você a solucionar problemas.
Bloqueios Este objeto fornece informações sobre bloqueios do SQL Server em
tipos de recursos individuais. Avalie a possibilidade de monitorar os seguintes
contadores:
Tempo de Espera Médio (ms) Este contador mostra a quantidade média de
tempo de espera para cada solicitação de bloqueio que resultou em uma espera.
Tempo de Espera de Bloqueio (ms) Este contador mostra o tempo de espera
para bloqueios no último segundo.
Esperas de Bloqueio/s Este contador mostra o número de bloqueios por
segundo que não puderam ser atendidos imediatamente e precisaram esperar
recursos.
Número de deadlocks Este contador mostra o número de deadlocks por
segundo no computador que executa o SQL Server. O valor não deve ser maior
do que 0.
Travas Este objeto fornece contadores para monitorar bloqueios internos de
recursos do SQL Server chamados travas. A monitoração de travas para determinar
a atividade dos usuários e o uso de recursos pode ajudar você a identificar os
afunilamentos de desempenho. Avalie a possibilidade de monitorar os seguintes
contadores:
239
Tempo Médio de Espera de Trava (ms) Este contador mostra o tempo médio
de espera de trava para solicitações de trava que precisaram esperar.
Esperas de Trava/s Este contador mostra o número de solicitações de trava
que não puderam ser atendidas imediatamente.
Estatísticas SQL Este objeto fornece contadores para monitorar a compilação e o
tipo de solicitações enviadas para uma instância do SQL Server. A monitoração do
número de compilações e recompilações de consultas e do número de lotes
recebidos por uma instância do SQL Server indica a rapidez com que o SQL Server
está processando as consultas de usuários e a eficiência com que o otimizador de
consulta está processando as consultas. Avalie a possibilidade de monitorar os
seguintes contadores:
Compilações de SQL/s Este contador indica o número de vezes que o
caminho de código de compilação é inserido por segundo.
Recompilações de SQL/s Este contador indica o número de recompilações da
instrução por segundo.
Gerenciador de Buffer Este objeto fornece contadores para monitorar como o
SQL Server usa a memória para armazenar páginas de dados, estruturas de dados
internas e o cache de procedimento, bem como contadores para monitorar o E/S
físico enquanto o SQL Server lê e grava páginas de banco de dados. Avalie a
possibilidade de monitorar o seguinte contador:
Taxa de Acertos do Cache do Buffer
Este contador mostra a porcentagem de páginas encontradas no cache do buffer
sem a necessidade de ler do disco. A taxa é o número total de acertos de cache
dividido pelo número total de pesquisas de cache nos últimos mil acessos a
páginas. Como ler do cache é muito mais caro do que ler do disco, convém que
essa taxa seja alta. Geralmente, você pode aumentar a taxa de acertos do
cache do buffer aumentando a quantidade de memória disponível para o SQL
Server.
Cache de Planos Este objeto fornece contadores para monitorar como o SQL
Server usa a memória para armazenar objetos como procedimentos armazenados,
instruções Transact-SQL ad-hoc e preparadas e gatilhos. Avalie a possibilidade de
monitorar o seguinte contador:
Taxa de Acertos do Cache
Este contador indica a taxa entre acertos e pesquisas de cache para planos.
Contadores do servidor físico a serem monitorados
Monitore os seguintes contadores para assegurar a integridade dos computadores que executam o SQL Server:
Processador: % Tempo do Processador: _Total Este contador mostra a
porcentagem de tempo que o processador está executando processos do aplicativo
ou do sistema operacional diferentes de Ocioso. No computador que estiver
executando o SQL Server, esse contador deverá ficar entre 50 por cento e 75 por
cento. No caso de sobrecarga constante, investigue se existe uma atividade anormal
de processos ou se o servidor precisa de CPUs adicionais.
240
Sistema: Comprimento da Fila de Processador Este contador mostra o número
de threads na fila do processador. Monitore este contador para assegurar que ele
permaneça inferior ao dobro do número de núcleos de CPU.
Memória: Mbytes Disponíveis Este contador mostra a quantidade de memória
física, em megabytes, disponível para processos executados no computador.
Monitore este contador para assegurar a manutenção de um nível de pelo menos
20 por cento do total de RAM física disponível.
Memória: Páginas/s Este contador mostra a taxa em que as páginas são lidas do
disco ou nele gravadas para resolver falhas de página de hardware. Monitore este
contador para assegurar que ele permaneça abaixo de 100.
Para obter mais informações e métodos de solução de problemas de memória, consulte o artigo sobre o monitoramento do uso da memória pelo SQL Server 2005 (http://go.microsoft.com/fwlink/?linkid=105585&clcid=0x416).
Contadores de disco a serem monitorados
Monitore os seguintes contadores para assegurar a integridade dos discos. Observe que os seguintes valores são medidos ao longo do tempo — não são valores que ocorrem durante um pico repentino e não se baseiam em uma única medição.
Disco Físico: % Tempo de Disco: DataDrive Este contador mostra a
porcentagem do tempo decorrido em que a unidade de disco selecionada está
ocupada atendendo a solicitações de leitura ou gravação – é um indicador geral de
como o disco está ocupado. Se o contador PhysicalDisk: % Tempo de Disco for
alto (mais do que 90 por cento), verifique o contador PhysicalDisk: Comprimento
da Fila de Disco Atual para ver quantas solicitações do sistema estão aguardando
o acesso ao disco. O número de solicitações de E/S em espera deve ser mantido em
não mais de 1,5 a 2 vezes o número de eixos que constituem o disco físico.
Disco Lógico: Transferências de Disco/s Este contador mostra a taxa em que
são executadas as operações de leitura e gravação no disco. Use este contador
para monitorar as tendências de crescimento e fazer previsões adequadamente.
Disco Lógico: Bytes de Leitura de Disco/s e Disco Lógico: Bytes de Gravação
de Disco/s Estes contadores mostram a taxa em que os bytes são transferidos do
disco durantes as operações de leitura e gravação.
Disco Lógico: Média de Bytes de Disco/Leitura Este contador mostra o número
médio de bytes transferidos do disco durante as operações de leitura. Esse valor
pode refletir a latência do disco — operações de leitura maiores podem resultar em
latência ligeiramente maior.
Disco Lógico: Média de Bytes de Disco/Gravação Este contador mostra o
número médio de bytes transferidos para o disco durante as operações de gravação.
Esse valor pode refletir a latência do disco — operações de gravação maiores
podem resultar em latência ligeiramente maior.
Disco Lógico: Comprimento da Fila de Disco Atual Este contador mostra o
número de solicitações pendentes no disco no momento em que os dados de
desempenho são coletados. Para este contador, valores menores são melhores.
Valores maiores do que 2 por disco podem indicar um afunilamento e devem ser
investigados. Isso significa que um valor até 8 é aceitável para uma LUN (unidade
lógica) constituída de quatro discos. Os afunilamentos podem criar uma lista de
pendências capaz de se difundir para além do servidor atual que está acessando o
241
disco e provocar longos tempos de espera para os usuários. As possíveis soluções
para um afunilamento são adicionar mais discos à matriz de RAID, substituir os
discos existentes por discos mais rápidos ou mover alguns dados para outros discos.
Disco Lógico: Comprimento Médio da Fila de Disco Este contador mostra o
número médio de solicitações de leitura e gravação que foram enfileiradas para o
disco selecionado durante o intervalo da amostra. A regra é que deve haver no
máximo duas solicitações pendentes de leitura e gravação por eixo, mas isso pode
ser difícil de medir por causa da virtualização do armazenamento e de diferenças em
níveis de RAID entre configurações. Procure comprimentos de fila de disco maiores
do que a média em combinação com latências de disco maiores do que a média.
Essa combinação pode indicar que o cache da matriz de armazenamento está
sendo superutilizado ou que o compartilhamento do eixo com outros aplicativos está
afetando o desempenho.
Disco Lógico: Média de Disco s/Leitura e Disco Lógico: Média de Disco
s/Gravação Estes contadores mostram o tempo médio, em segundos, de uma
operação de leitura ou gravação no disco. Monitore estes contadores para assegurar
que eles permaneçam abaixo de 85 por cento da capacidade do disco. O tempo de
acesso a disco aumenta exponencialmente se operações de leitura ou gravação
representarem mais de 85 por cento da capacidade do disco. Para determinar a
capacidade específica do seu hardware, consulte a documentação do fornecedor ou
use a Ferramenta de Parâmetro de Comparação de Subsistema de Disco SQLIO
para calculá-la. Para obter mais informações, consulte o artigo sobre a Ferramenta
de Parâmetro de Comparação de Subsistema de Disco SQLIO
(http://go.microsoft.com/fwlink/?linkid=105586&clcid=0x416).
Disco Lógico: Média de Disco s/Leitura Este contador mostra o tempo
médio, em segundos, de uma operação de leitura do disco. Em um sistema bem
ajustado, os valores ideais vão de 1 a 5 ms para logs (idealmente 1 ms em uma
matriz em cache) e de 4 a 20 ms para dados (idealmente menos do que 10 ms).
Latências maiores podem ocorrer durante momentos de pico, mas se forem
registrados valores maiores regularmente, você deverá investigar a causa.
Disco Lógico: Média de Disco s/Gravação Este contador mostra o tempo
médio, em segundos, de uma operação de gravação no disco. Em um sistema
bem ajustado, os valores ideais vão de 1 a 5 ms para logs (idealmente 1 ms em
uma matriz em cache) e de 4 a 20 ms para dados (idealmente menos do que
10 ms). Latências maiores podem ocorrer durante momentos de pico, mas se
forem registrados valores maiores regularmente, você deverá investigar a causa.
Quando você usar configurações de RAID com os contadores Média de Disco s/Leitura ou Média de Disco s/Gravação, use as fórmulas relacionadas na tabela a seguir para determinar a taxa de entrada e saída no disco.
Nível de RAID Fórmula
RAID 0 E/Ss por disco = (leituras + gravações) /
número de discos
RAID 1 E/Ss por disco = [leituras + (2 × gravações)]
/ 2
RAID 5 E/Ss por disco = [leituras + (4 × gravações)]
242
Nível de RAID Fórmula
/ número de discos
RAID 10 E/Ss por disco = [leituras + (2 × gravações)]
/ número de discos
Por exemplo, se você tiver um sistema RAID 1 com dois discos físicos e seus contadores tiverem os valores mostrados na tabela a seguir:
Contador Valor
Média de
Disco s/Leitura
80
Disco
Lógico:
Média de
Disco
s/Gravação
70
Comprimento
Médio da Fila
de Disco
5
O valor de E/S por disco pode ser calculado da seguinte forma: (80 + (2 × 70))/2 = 110
O comprimento da fila de disco pode ser calculado da seguinte forma: 5/2 = 2,5
Nessa situação, você tem um afunilamento de E/S limítrofe.
Outras ferramentas de monitoração
Você também pode monitorar a latência de disco e analisar tendências usando a exibição de gerenciamento dinâmico sys.dm_io_virtual_file_stats no SQL Server 2008. Para obter mais informações, consulte o artigo sobre sys.dm_io_virtual_file_stats (Transact-SQL) (http://go.microsoft.com/fwlink/?linkid=105587&clcid=0x416).
243
Overview of Remote BLOB Storage (SharePoint Server 2010) (em inglês)
This article describes how you can use Microsoft SharePoint Server 2010 together with Remote BLOB Storage (RBS) and Microsoft SQL Server 2008 Express e Microsoft SQL Server 2008 R2 Express to optimize database storage resources.
Before you implement RBS, we highly recommend that you evaluate its potential costs and benefits. For more information and recommendations about using RBS in a SharePoint Server 2010 installation, see Planejar o RBS (Remote BLOB Storage) (SharePoint Server 2010).
In this article:
Introduction to RBS
Using RBS together with SharePoint 2010 Products
Introduction to RBS RBS is a library API set that is incorporated as an add-on feature pack for Microsoft SQL Server. It can be run on the local server running Microsoft SQL Server 2008 R2, SQL Server 2008 or SQL Server 2008 R2 Express. To run RBS on a remote server, you must be running SQL Server 2008 R2 Enterprise edition. RBS is not supported for Microsoft SQL Server 2005.
Binary large objects (BLOBs) are data elements that have either of the following characteristics:
Unstructured data that has no schema (such as a piece of encrypted data).
A large amount of binary data (many megabytes or gigabytes) that has a very simple
schema, such as image files, streaming video, or sound clips.
By default, Microsoft SQL Server stores BLOB data in its databases. As a database’s usage increases, the total size of its BLOB data can expand quickly and grow larger than the total size of the document metadata and other structured data that is stored in the database. Because BLOB data can consume a lot of file space and uses server resources that are optimized for database access patterns, it can be helpful to move BLOB data out of the SQL Server database, and into a separate file.
Before RBS was supported in SQL Server, expensive storage such as RAID 10 was required for the whole SQL database including BLOB data. By using RBS, you can move 80 to 90 percent of the data (that is, BLOBs) onto less expensive storage such as RAID 5 or external storage solutions.
RBS uses a provider to connect to any dedicated BLOB store that uses the RBS APIs. Storage solution vendors can implement providers that work with RBS APIs. SharePoint Server 2010 supports a BLOB storage implementation that accesses BLOB data by using the RBS APIs through such a provider. You can implement RBS for Produtos do Microsoft SharePoint 2010 by using a supported provider that you obtain from a third-party vendor. Most third-party providers store BLOBs remotely.
244
In addition to third-party providers, you can use the RBS FILESTREAM provider that is available through the Pacote de instalação do SQL Server Remote BLOB Store do Feature Pack para Microsoft SQL Server 2008 R2. The RBS FILESTREAM provider uses the SQL Server FILESTREAM feature to store BLOBs in an additional resource that is attached to the same database and stored locally on the server. The FILESTREAM feature manages BLOBs in a SQL database by using the underlying NTFS file system.
The location that an RBS provider stores the BLOB data depends on the provider that you use. In the case of the SQL FILESTREAM provider, the data is not stored in the MDF file, but in another file that is associated with the database.
This implementation of the FILESTREAM provider is known as the local FILESTREAM provider. You can conserve resources by using the local RBS FILESTREAM provider to place the extracted BLOB data on a different (cheaper) local disk such as RAID 5 instead of RAID 10. You cannot use RBS with the local FILESTREAM provider on remote storage devices, such as network attached storage (NAS). The FILESTREAM provider is supported when it is used on local hard disk drives only.
A remote RBS FILESTREAM provider that is available in SQL Server 2008 R2 Express can store BLOB data on remote commodity storage such as direct-attached storage (DAS) or NAS. However, SharePoint Server 2010 does not currently support the remote RBS FILESTREAM provider.
Using RBS together with SharePoint 2010 Products SharePoint Server 2010 supports the FILESTREAM provider that is included in the Pacote de instalação do SQL Server Remote BLOB Store do Feature Pack para SQL Server 2008 R2. This version of RBS is available at http://go.microsoft.com/fwlink/?LinkID=177388. Be aware that this is the only version of RBS that is supported by SharePoint Server 2010. Earlier versions are not supported. Third-party RBS providers can also be used with the RBS APIs to create a BLOB storage solution that is compatible with SharePoint Server 2010.
In SharePoint Server 2010, site collection backup and restore and site import or export will download the file contents and upload them back to the server regardless of which RBS provider is being used. However, the FILESTREAM provider is the only provider that is currently supported for Produtos do SharePoint 2010 farm database backup and restore operations.
When RBS is implemented, SQL Server itself is regarded as an RBS provider. You will encounter this factor when you migrate content into and out of RBS.
If you plan to store BLOB data in an RBS store that differs from your SharePoint Server 2010 content databases, you must run SQL Server 2008 com SP1 e Atualização Cumulativa 2. This is true for all RBS providers.
The FILESTREAM provider that is recommended for upgrading from stand-alone installations of Windows SharePoint Services 3.0 that have content databases that are over 4 gigabytes (GB) to SharePoint Server 2010 associates data locally with the current content database, and does not require SQL Server Enterprise Edition.
245
Importante:
RBS does not enable any kind of direct access to any files that are stored in Produtos do Microsoft SharePoint 2010. All access must occur by using Produtos do SharePoint 2010 only.
Consulte também Outros recursos
FILESTREAM Overview
FILESTREAM Storage in SQL Server 2008
Remote BLOB Store Provider Library Implementation Specification
246
Planejar o RBS (Remote BLOB Storage) (SharePoint Server 2010)
Por padrão, o SQL Server armazena dados BLOB (objeto binário grande) em seus bancos de dados. À medida que o uso do banco de dados aumenta, o tamanho total dos dados BLOB armazenados nele pode se expandir rapidamente e crescer mais do que o tamanho total dos metadados de documento e de outros dados estruturados armazenados no banco de dados. Os dados BLOB consomem grandes quantidades de espaço de arquivo e usam recurso do servidor otimizados para padrões de acesso a banco de dados, em vez do armazenamento de arquivos grandes.
RBS (Remote BLOB Storage) é uma API de biblioteca definida e incorporada como um pacote de recursos complementar para o Microsoft SQL Server. Ele pode ser executado no servidor local executando o Microsoft SQL Server 2008 R2, o SQL Server 2008 ou o SQL Server 2008 R2 Express. Para executar o RBS em um servidor remoto, você deve estar executando o SQL Server 2008 R2 Enterprise edition. O RBS foi projetado para mover o repositório de BLOBs de servidores de banco de dados para soluções de armazenamento de mercadorias. O RBS economiza um espaço significativo, conserva recursos de servidor caros e fornece um modelo padronizado para os aplicativos acessarem dados BLOB. No Microsoft SharePoint Server 2010, o RBS pode ser usado para bancos de dados de conteúdo apenas.
Para obter mais informações básicas sobre o RBS, incluindo uma discussão sobre o provedor FILESTREAM, consulte Overview of Remote BLOB Storage (SharePoint Server 2010) (em inglês).
O RBS pode oferecer os seguintes benefícios:
Dados BLOB podem ser armazenados em dispositivos de armazenamento mais
baratos, que são configurados para administrar o armazenamento simples.
A administração do armazenamento BLOB é controlada por um sistema projetado
especificamente para trabalhar com dados BLOB.
Os recursos do servidor de banco de dados são liberados para operações de banco
de dados.
Esses benefícios não são gratuitos. Antes de implementar o RBS com o SharePoint Server 2010, você deve avaliar se esses benefícios potenciais superam os custos e as limitações da implementação e manutenção do RBS. Este artigo descreve o processo de avaliação desse tópico.
Neste artigo:
Examinar o ambiente
Avaliar as opções de provedor
Examinar o ambiente Para iniciar sua análise do RBS, examine o tamanho dos bancos de dados de conteúdo. Se o tamanho desses bancos de dados atender aos critérios de uma recomendação
247
RBS, você deverá considerar que tipo de conteúdo está sendo acessado e como ele está sendo usado.
Tamanhos dos bancos de dados de conteúdo
Você pode esperar benefícios do RBS nos seguintes casos:
Os bancos de dados de conteúdo têm mais de 500 GB (gigabytes).
Os arquivos de dados BLOB têm mais de 256 KB (quilobytes).
Os arquivos de dados BLOB têm pelo menos 80 KB e o servidor de banco de dados
é um afunilamento de desempenho. Nesse caso, o RBS reduz a carga de E/S e de
processamento no servidor de banco de dados.
Embora a presença de muitos BLOBs pequenos possa causar alguma queda no desempenho, o custo do armazenamento geralmente é o fator mais importante quando você avalia o RBS. Em geral, a queda prevista no desempenho é uma troca aceitável para a economia no hardware de armazenamento.
Tipo de conteúdo e uso
O RBS é mais benéfico em sistemas que armazenam arquivos muito grandes, como mídia digital. Em geral, o RBS é implementado em ambientes nos quais arquivos grandes armazenados são armazenados raramente, como um arquivo morto. Se essa situação descreve seu ambiente, você deverá considerar a implementação do RBS.
Se estiver armazenando muitos arquivos pequenos (com menos de 256 KB) acessados com frequência por muitos usuários, talvez seja melhor experimentar a latência aumentada nos sites que tiverem muitos arquivos pequenos armazenados no RBS. A latência aumentada é um fator de custo que você deve considerar ao avaliar o RBS para sua solução de armazenamento. No entanto, é improvável que essa seja a consideração mais importante. A quantidade de latência aumentada também está relacionada ao provedor de RBS que você usa.
Avaliar as opções de provedor O RBS requer um provedor que conecte as APIs do RBS e o SQL Server.
Importante:
O RBS pode ser executado no servidor local com o Microsoft SQL Server 2008 R2, o SQL Server 2008 ou o SQL Server 2008 R2 Express. Para executar o RBS em um
servidor remoto, você deve ter o SQL Server 2008 R2 Enterprise edition. O SharePoint
Server 2010 requer o uso da versão do RBS fornecida com o Pacote de instalação do
SQL Server Remote BLOB Store do Feature Pack para Microsoft SQL Server 2008 R2.
As versões anteriores do RBS não funcionarão com o SharePoint Server 2010. Além
disso, o RBS não tem suporte no SQL Server 2005.
É possível manter BLOBs no armazenamento de mercadorias, como DAS (direct-attached storage) ou NAS (network attached storage), conforme o suporte do provedor. O provedor FILESTREAM tem suporte do SharePoint Server 2010 quando usado apenas nas unidades de disco rígido local. Você não pode usar RBS com FILESTREAM em dispositivos de armazenamento remoto, como NAS.
A tabela a seguir resume os benefícios e as limitações do FILESTREAM.
248
Requisito operacional RBS com FILESTREAM RBS sem FILESTREAM
Backup integrado do SQL Server e
recuperação do Repositório de
BLOB
Sim Sim
Migração com script para BLOBs Sim Sim
Dá suporte para espelhamento Não Não
Envio de logs Sim Sim, com
implementação
do provedor
Instantâneos de banco de dados Não1 Não1
Replicação geo Sim Não
Criptografia Somente NTFS Não
NAS (Network Attached Storage) Sem suporte do Produtos do SharePoint 2010
Sim, com
implementação
do provedor
1Se o provedor RBS que você está usando não tiver suporte para instantâneos, não será possível usá-los para implantação de conteúdo ou backup. Por exemplo, o provedor SQL FILESTREAM não tem suporte para instantâneos.
Se o FILESTREAM não for um provedor prático para o seu ambiente, você poderá adquirir um provedor de terceiros com suporte. Nesse caso, você deverá avaliar os seguintes critérios ao comprar um provedor:
Funcionalidade de backup e restauração
Recuperação de desastre testada
Implantação e migração de dados
Impacto no desempenho
Custos administrativos a longo prazo
Importante:
Não recomendamos que você desenvolva seu próprio provedor, a menos que você seja
um ISV (fornecedor independente de software) com bastante experiência em projetar
soluções de armazenamento.
249
Planejar o gerenciamento da continuidade dos negócios (SharePoint Server 2010)
O gerenciamento de continuidade de negócios consiste em decisões de negócios, processos e ferramentas que você implementa com antecedência para lidar com crises. A crise pode afetar somente o seu comércio ou ser parte de um evento local, regional ou nacional.
Recursos do Microsoft SharePoint Server 2010 provavelmente fazem parte de sua estratégia de gerenciamento de continuidade de negócios, mas seu plano geral deve ser muito mais abrangente e incluir os seguintes elementos:
Procedimentos claramente documentados.
Armazenamento de registros de negócios fora do local.
Contatos claramente designados.
Treinamento contínuo da equipe, incluindo práticas e buscas.
Mecanismos de recuperação fora do local.
Neste artigo:
Recursos de gerenciamento de continuidade de negócios
Contratos de nível de serviço
Recursos de gerenciamento de continuidade de negócios O Microsoft SharePoint Server 2010 inclui os recursos a seguir, que dão suporte ao gerenciamento de continuidade de negócios.
Controle de versão Os usuários podem perder dados ao substituir um documento.
Com o controle de versão, os usuários podem manter várias versões do mesmo
documento em uma biblioteca de documentos. No caso de uma alteração
indesejada, um documento substituído ou um documento corrompido, a versão
anterior pode ser facilmente restaurada pelo usuário. Quando o controle de versão
está habilitado, os usuários podem recuperar seus dados por conta própria.
Para obter mais informações, consulte Planejar a proteção do conteúdo usando lixeiras e controle de versão (SharePoint Server 2010).
Lixeira O SharePoint Server 2010 inclui uma Lixeira de dois estágios. Os usuários
que têm as permissões apropriadas podem usar a Lixeira de primeiro estágio para
recuperar documentos, itens de lista, listas e bibliotecas de documentos que foram
excluídos de um site. Os administradores de conjuntos de site podem usar a Lixeira
de segundo estágio, também chamada de Lixeira de Conjuntos de Sites, para
recuperar itens que foram excluídos da Lixeira de primeiro estágio. Quando a Lixeira
250
de primeiro estágio é habilitada, os usuários podem recuperar dados por conta
própria.
Para obter mais informações, consulte Planejar a proteção do conteúdo usando lixeiras e controle de versão (SharePoint Server 2010).
Central de Registros Os sites da Central de Registros dão suporte ao
armazenamento de registros de gerenciamento por razões legais, regulatórias ou
comerciais. Para obter mais informações, consulteRecords management planning
(SharePoint Server 2010).
Backup e recuperação Você pode usar cmdlets do Windows PowerShell ou o site
da Administração Central do SharePoint para o backup e a recuperação de farms,
bancos de dados, aplicativos Web e conjuntos de sites. Há também muitas
ferramentas externas e de terceiros que podem ser usadas para backup e
recuperação de dados. Para obter mais informações, consulte Planejar o backup e a
recuperação (SharePoint Server 2010).
Disponibilidade Não existe um recurso único que ofereça disponibilidade em um
ambiente do SharePoint Server 2010. Você pode escolher entre muitas abordagens
para aprimorar a disponibilidade, como:
Tolerância a falhas de componentes e da rede.
Redundância de funções de servidor e servidores em um farm.
Para obter mais informações sobre disponibilidade, consulte Planejar a disponibilidade (SharePoint Server 2010).
Recuperação de desastre Não existe um recurso único que ofereça recuperação
de desastre em um ambiente do SharePoint Server 2010. Você pode escolher entre
muitas abordagens para aprimorar a disponibilidade quando um centro de dados fica
offline, como:
Repositório externo de backups, dentro e fora de sua região.
Envio de imagens de servidores a locais externos.
Operação de vários data centers, mas fornecimento de dados através de apenas
um deles, mantendo os outros disponíveis em espera.
Para obter mais informações sobre a recuperação de desastre, consulte Planejar a recuperação de desastre (SharePoint Server 2010).
Contratos de nível de serviço O gerenciamento de continuidade de negócios é uma área fundamental em que grupos de TI oferecem contratos de nível de serviço para definir as expectativas com grupos de clientes. Muitas organizações de TI oferecem vários contratos de nível de serviço, que são associados a diferentes níveis de estorno.
A lista a seguir descreve recursos comuns de contratos de nível de serviço do gerenciamento de continuidade de negócios:
Controle de versão
Se oferecido.
Espaço alocado.
Lixeiras
251
Se oferecido.
Espaço alocado para a Lixeira de primeiro estágio e para a Lixeira de segundo
estágio.
Período em que os itens são mantidos antes de serem excluídos
permanentemente em cada Lixeira.
Encargos adicionais para recuperação de itens permanentemente excluídos da
Lixeira de segundo estágio.
Backup e recuperação
SLAs de backup e recuperação geralmente identificam objetos e serviços que podem ser armazenados em backup e recuperados, e os objetivos de tempo, ponto e nível de recuperação de cada um deles. O SLA também pode identificar a janela de backup disponível para cada objeto. Para obter mais informações sobre SLAs de backup e recuperação, consulte Planejar o backup e a recuperação (SharePoint Server 2010).
O objetivo de tempo de recuperação (RTO) representa a duração máxima de um
processo de recuperação de dados. Ele é determinado pela quantidade de
tempo que a empresa poderá suportar se o site ou o serviço ficar indisponível.
Objetivo de ponto de recuperação (RPO) é o objetivo do tempo máximo entre o
último backup disponível e qualquer possível ponto de falha. É determinado pela
quantidade de dados que a empresa pode se dar ao luxo de perder em caso de
falha.
O Objetivo de nível de recuperação (RLO) é o objetivo que define a
granularidade com a qual você poderá recuperar dados — indicando se você
poderá recuperar o farm inteiro, aplicativo Web, conjunto de sites, site, lista,
biblioteca ou item.
Disponibilidade.
Para cada componente de um farm que é coberto por um plano de disponibilidade, um SLA de disponibilidade pode identificar a disponibilidade como um percentual do tempo de ativação, muitas vezes expresso como o número de noves, ou seja, o percentual de tempo durante o qual um determinado sistema está ativo e funcionando. Por exemplo, considera-se que um sistema com um percentual de tempo de ativação de 99,999% tenha cinco noves de disponibilidade.
Observação:
Ao calcular a disponibilidade, a maioria das organizações especificamente isenta ou
adiciona horas para atividades de manutenção planejada.
Para obter mais informações, consulte Planejar a disponibilidade (SharePoint Server 2010).
Recuperação de desastre
Para cada componente de um farm que é coberto por um plano de recuperação de desastre, um SLA pode identificar os objetivos de ponto e tempo de recuperação. Diferentes objetivos de tempo de recuperação são frequentemente definidos para diferentes circunstâncias, por exemplo, uma emergência local versus uma emergência regional.
Para obter mais informações, consulte Planejar a recuperação de desastre (SharePoint Server 2010).
252
Conteúdo relacionado
Central de recursos Gerenciamento de Continuidade de Negócios para o
SharePoint Server 2010 (http://go.microsoft.com/fwlink/?linkid=199235&clcid=0x416)
Conteúdo para o Profissional
de TI
Planejar o backup e a recuperação (SharePoint Server
2010)
Visão geral sobre backup e recuperação (SharePoint Server
2010)
Planejar a proteção do conteúdo usando lixeiras e controle
de versão (SharePoint Server 2010)
Planejar a disponibilidade (SharePoint Server 2010)
Availability configuration (SharePoint Server 2010)
Planejar a recuperação de desastre (SharePoint Server
2010)
Conteúdo para o
desenvolvedor
Proteção de dados e recuperação
(http://go.microsoft.com/fwlink/?linkid=199237&clcid=0x416)
253
Planejar a proteção do conteúdo usando lixeiras e controle de versão (SharePoint Server 2010)
Planejar o uso de lixeiras e controle de versão em um ambiente para ajudar os usuários a proteger e recuperar os dados. As lixeiras e o controle de versão são componentes essenciais de uma estratégia de continuidade de negócios.
Lixeiras Os usuários podem usar lixeiras para recuperar objetos excluídos. O Microsoft SharePoint Server 2010 dá suporte a dois estágios de lixeiras: a Lixeira de primeiro estágio e a Lixeira de Conjunto de Sites, também chamada de Lixeira de segundo estágio. Quando as Lixeiras são habilitadas, os usuários podem restaurar itens contidos nelas, inclusive arquivos, documentos, itens de lista, listas e bibliotecas de documentos excluídos.
Controle de versão Usuários podem usar o controle de versão para ajudar a impedir a perda de dados provocada pela substituição de um documento. Quando o proprietário de um site ativa o controle de versão em uma biblioteca de documentos ou lista, a biblioteca ou lista mantém várias cópias de um documento, item ou arquivo. No caso de uma alteração indesejada, um arquivo substituído ou documento corrompido, a versão anterior pode ser facilmente restaurada pelo usuário.
Neste artigo:
Protegendo o conteúdo usando lixeiras
Protegendo o conteúdo usando o controle de versão
Protegendo o conteúdo usando lixeiras O SharePoint Server 2010 dá suporte a dois estágios de lixeiras: a Lixeira de primeiro estágio e a Lixeira de Conjunto de Sites ou de segundo estágio. As lixeiras são habilitadas e configuradas no nível do aplicativo Web. Elas coletam documentos e itens de lista excluídos. Quando um item de lista é excluído, todos os seus anexos também são excluídos e podem ser restaurados da Lixeira.
As Lixeiras podem conter várias cópias de um documento, cada uma delas com o mesmo nome de arquivo e origem. Esses documentos não podem ser restaurados sobre uma cópia existente de um documento. As Lixeiras não podem ser usadas para recuperar versões anteriores ou substituições acidentais de documentos – você deve usar o controle de versão para habilitar essa funcionalidade.
A tabela a seguir descreve como um item é excluído e recuperado da Lixeira de primeiro estágio e da Lixeira de segundo estágio.
Quando um usuário O item é O item pode ser restaurado por
254
Quando um usuário O item é O item pode ser restaurado por
Exclui um item Mantido na Lixeira de primeiro
estágio até que o item seja
excluído da Lixeira ou até que ele
tenha permanecido nela por um
período mais longo do que o limite
de tempo configurado para manter um item na Lixeira.
Usuários ou
administradores do conjunto de sites
Exclui um item da Lixeira Mantido na Lixeira de segundo
estágio
Administradores de conjuntos de sites
A desativação da Lixeira para um aplicativo Web esvazia todas as Lixeiras e exclui permanentemente todos os itens contidos nelas.
Lixeira de primeiro estágio
A Lixeira de primeiro estágio está localizada no nível de site e está disponível para os usuários que têm permissões Colaboração, Design ou Controle Total em um site. Quando um usuário exclui um item de um site, o item é enviado à Lixeira de primeiro estágio do site. Os itens localizados nas Lixeiras de primeiro estágio são contabilizados para a cota do site. Os itens permanecem em uma das Lixeiras de primeiro estágio do site até que um período de tempo especificado seja atingido (a configuração padrão é 30 dias).
Quando um item é excluído da Lixeira, é enviado para a Lixeira de segundo estágio.
Observação:
O limite de tempo para as Lixeiras aplica-se ao tempo total depois que o primeiro item é
excluído, não ao tempo gasto em qualquer um dos estágios de Lixeira.
Lixeira de segundo estágio (Conjunto de Sites)
A Lixeira de segundo estágio está localizada no nível de administrador de conjunto de sites. A Lixeira de segundo estágio está organizada em dois modos de exibição: os objetos nas Lixeiras de primeiro estágio de todos os sites do conjunto de sites e os objetos na Lixeira de segundo estágio. Quando um item é excluído da Lixeira de primeiro estágio, só pode ser recuperado da Lixeira de segundo estágio por um administrador de conjunto de sites.
Os itens permanecem na Lixeira de segundo estágio até que um período de tempo especificado seja atingido (a configuração padrão é 30 dias) ou até que a Lixeira de segundo estágio atinja seu limite de tamanho, quando então os itens mais antigos são excluídos. O limite de tempo para as Lixeiras aplica-se ao tempo total depois que o item é excluído inicialmente, não ao tempo gasto em qualquer um dos estágios de Lixeira.
Quando uma Lixeira de segundo estágio é habilitada para um aplicativo Web, é recomendável designar o espaço em disco disponível para a Lixeira de segundo estágio como um percentual da cota alocada para o aplicativo Web. Itens armazenados na
255
Lixeira de segundo estágio não são contabilizados para a cota do site; no entanto, o tamanho especificado para a Lixeira de segundo estágio aumenta o tamanho total do site e do banco de dados de conteúdo que o hospeda. Se não tiver sido definida uma cota de site, não haverá limite para o tamanho da Lixeira de segundo estágio.
Se você alocou 100 megabytes (MB) de espaço para o aplicativo Web, por exemplo, a alocação de uma cota de 50% para a Lixeira de segundo estágio atribui 50 MB para a Lixeira de segundo estágio e 150 MB para o aplicativo Web como um todo. Você pode atribuir até 100% como cota da Lixeira de segundo estágio.
Para obter mais informações sobre a definição de cotas, consulte
Planejar manutenção e gerenciamento de site (SharePoint Server 2010)
Criar modelos de cota (SharePoint Server 2010)
Para obter mais informações sobre como os usuários podem usar a Lixeira no SharePoint Server 2010, consulte Exibir, restaurar ou excluir itens na Lixeira (http://go.microsoft.com/fwlink/?linkid=90917&clcid=0x416)
Para obter informações sobre como configurar Lixeiras, consulte Configurar Lixeira (SharePoint Server 2010).
Protegendo o conteúdo usando o controle de versão O controle de versão trata do problema da perda de dados com a substituição de um documento. Ele permite que a biblioteca de documentos mantenha várias cópias do mesmo documento. No caso de uma alteração indesejada, uma substituição ou um documento corrompido, a versão anterior pode ser facilmente restaurada pelo usuário. O controle de versão pode ser habilitado no nível de biblioteca ou de lista. É possível usar o controle de versão para itens e arquivos.
Antes de configurar o controle de versão, leia Planejar manutenção e gerenciamento do site (SharePoint Server 2010).
Para obter mais informações sobre configurar o controle de versão, consulte Habilitar e configurar controle de versão (SharePoint Server 2010).
Os administradores devem gerenciar atentamente o controle de versão, pois se os sites tiverem várias versões de arquivos e documentos, poderão se tornar muito grandes. Se você não restringir o tamanho dos sites, eles poderão exceder a capacidade de armazenamento. Os administradores de farms podem gerenciar esse problema estabelecendo contratos de nível de serviço com os proprietários dos sites e definindo cotas de tamanho nos sites. Para obter mais informações sobre o gerenciamento do controle de versão, consulte Gerenciar controle de versão usando cotas (SharePoint Server 2010).
256
Planejar o backup e a recuperação (SharePoint Server 2010)
Este artigo descreve os estágios envolvidos no planejamento de backup e recuperação, o que inclui a determinação das estratégias de backup e recuperação para um ambiente do Microsoft SharePoint Server e a tomada de decisão sobre as ferramentas a serem usadas. Os estágios não precisam ser concluídos na ordem listada, e o processo pode ser iterativo.
Ao planejar a maneira como você usará o backup e a recuperação no caso de recuperação de desastre, considere eventos, falhas e erros comuns; emergências locais; e emergências regionais.
Para obter informações detalhadas sobre o backup e recuperação do Microsoft SharePoint Server, consulte Visão geral sobre backup e recuperação (SharePoint Server 2010).
Neste artigo:
Definir os requisitos de negócios
Escolher o que deve ser protegido e recuperado no ambiente
Escolher ferramentas
Determinar estratégias
Planejar backup avançado e desempenho de recuperação
Definir os requisitos de negócios Para definir os requisitos de negócios, determine os seguintes aspectos para cada farm e serviço do ambiente:
O RPO (Objetivo de ponto de recuperação) representa a quantidade máxima de
tempo entre o último backup disponível e qualquer possível ponto de falha. Ele é
determinado pelo volume de dados cuja perda a empresa poderá suportar se ocorrer
uma falha.
O RTO (Objetivo de tempo de recuperação) representa a duração máxima de um
processo de recuperação de dados. Ele é determinado pela quantidade de tempo
que a empresa poderá suportar se o site ou o serviço ficar indisponível.
Objetivo de nível de recuperação (RLO) é o objetivo que define a granularidade com
a qual você poderá recuperar dados — indicando se você poderá recuperar o farm,
aplicativo Web, conjunto de sites, site, lista, biblioteca ou item inteiro.
RPO e RTO menores e granularidade maior de RLO, tudo isso tende a custar mais.
Há uma planilha útil para ajudá-lo a planejar as estratégias de backup e recuperação do ambiente do SharePoint Server 2010 disponível para download na pasta de trabalho de planejamento de backup e recuperação dos Produtos do SharePoint 2010 (http://go.microsoft.com/fwlink/?linkid=184385&clcid=0x416).
257
Escolher o que deve ser protegido e recuperado no ambiente Os requisitos de negócios ajudarão você a determinar quais componentes do ambiente devem ser protegidos e a granularidade necessária para recuperá-los.
A tabela a seguir lista os possíveis componentes de um ambiente SharePoint cuja proteção talvez seja conveniente e as ferramentas que você pode usar para fazer o backup e a recuperação de cada componente.
Componente Backup do SharePoint Microsoft SQL Server 2008 com Service Pack 1 (SP1) e
Atualização
Cumulativa 2
System Center Data Protection Manager (DPM) 2010
Backup do sistema de arquivos
Farm Sim Sim6
Aplicativos de serviço Sim
Aplicativo Web Sim
Bancos de dados de
conteúdo
Sim Sim Sim
Conjunto de sites Sim1, 2 Sim1, 2 Sim1, 2
Site Sim2 Sim2
Sim
Lista ou biblioteca de documentos
Sim2 Sim2 Sim
Item de lista ou documento Sim
Conteúdo armazenado em
repositórios de BLOB
remotos
Sim3 Sim3 Sim3
Personalizações
implantadas como pacotes
de solução
Sim7
Sim7 Sim6, 7
Alterações feitas no
Web.config por meio da
Central de Administração
ou de uma API
Sim Sim Sim4
Definições de configuração Sim2, 8 Sim2, 8 Sim 2, 9
258
Componente Backup do SharePoint Microsoft SQL Server 2008 com Service Pack 1 (SP1) e
Atualização
Cumulativa 2
System Center Data Protection Manager (DPM) 2010
Backup do sistema de arquivos
(SharePoint)
Personalizações não
implantadas como pacotes
de solução
Sim. Os arquivos
poderão ser
recuperados se estiverem protegidos como arquivos.4, 5
Sim
Alterações do Web.config
que não foram feitas por
meio da Central de
Administração ou de uma
API
Sim4
Sim
Configurações do IIS que
não foram definidas por
meio do SharePoint
Sim5 Sim
Bancos de dados do SQL Server Reporting Services
Sim Sim
1O recurso de backup e restauração no nível do farm e no nível do banco de dados poderá ser usado para recuperação de conjunto de sites se um único conjunto estiver armazenado em um banco de dados.
2Os backups nos níveis do farm e do banco de dados podem ser usados com a recuperação do banco de dados desanexado do SharePoint Server para restaurar conjuntos de sites, sites, listas e configurações.
3O backup e a recuperação de conteúdo armazenado em repositórios de BLOB remotos incluem outros conteúdos, desde que o provedor de RBS (Remote BLOB Storage) em uso tenha esse recurso.
4O backup das alterações feitas no Web.config pode ser feito com o backup de sistema de arquivos no DPM 2010.
5As configurações do IIS podem ser recuperadas por meio de um backup bare-metal no DPM 2010.
259
6O DPM 2010 pode recuperar esse item usando uma combinação de backup bare-metal e de backup do SharePoint Server. Não é possível fazer backup do item ou recuperá-lo como um objeto.
7Os pacotes de soluções totalmente confiáveis são armazenados no banco de dados de configuração, e as soluções em área restrita são armazenadas nos bancos de dados de conteúdo. É possível recuperá-los como parte da recuperação do farm ou do banco de dados de conteúdo.
8As definições da configuração podem ser recuperadas de backups no nível do farm. Para obter mais informações, consulte Restore a farm (SharePoint Server 2010).
9É possível recuperar o banco de dados de conteúdo da Administração Central e o banco de dados de configuração de um farm do SharePoint Server 2010, mas apenas como parte de uma recuperação completa para o mesmo farm, com os mesmos computadores.
Observação:
É possível registrar o SharePoint Server 2010 com o Backup do Windows Server, usando
a operação stsadm.exe -o -registerwsswriter, para configurar o gravador VSS (Serviço
de Cópias de Sombra de Volume) para o SharePoint Server. O Backup do Windows
Server, por sua vez, inclui o SharePoint Server 2010 nos backups de todo o servidor. Ao
restaurar um backup do Windows Server, você pode selecionar o Microsoft SharePoint
Foundation (independentemente da versão do Produtos do SharePoint 2010 instalada), e
todos os componentes informados pelo gravador VSS do SharePoint Server 2010 nesse servidor no momento do backup serão restaurados.
O uso do Backup do Windows Server é recomendado apenas para uso com
implantações de servidor único.
Escolher o que deve ser recuperado dos bancos de dados de conteúdo do SharePoint
Em um banco de dados de conteúdo, você pode recuperar conjuntos de sites, sites, listas e bibliotecas.
As ferramentas de backup e recuperação fornecem diferentes níveis de recuperação de conteúdo em um banco de dados de conteúdo. A recuperação de um objeto de um banco de dados de conteúdo é sempre mais complexa do que a recuperação de todo esse banco de dados.
Protegendo as personalizações
As personalizações em sites do SharePoint podem incluir:
Páginas mestras, layouts de páginas e folhas de estilo em cascata. Esses objetos
são armazenados no banco de dados de conteúdo de um aplicativo Web.
Web Parts, definições de sites ou listas, colunas personalizadas, novos tipos de
conteúdo, campos personalizados, ações personalizadas, fluxos de trabalho
codificados ou atividades e condições de fluxo de trabalho.
Soluções de terceiros e os respectivos arquivos binários e chaves de Registro
associados, como IFilters.
Alterações nos arquivos XML padrão.
260
Definições de sites personalizados (Webtemp.xml).
Alterações no arquivo Web.config.
A forma como as personalizações são implantadas e as alterações são feitas no arquivo Web.config tem um impacto significativo sobre que ferramentas podem ser usadas no backup e recuperação de personalizações. Para oferecer a maior oportunidade de recuperação, é recomendado implantar personalizações usando pacotes de soluções e fazer alterações no arquivo Web.config por meio da Central de Administração ou das APIs do SharePoint e do modelo de objeto.
Protegendo fluxos de trabalho
Fluxos de trabalho são um caso especial de personalizações que você pode fazer backup e recuperar. Verifique se o seu plano de backup e recuperação está preparado para lidar com qualquer um dos seguintes cenários aplicáveis ao seu ambiente:
Os fluxos de trabalho declarativos, como aqueles criados no Microsoft SharePoint
Designer 2010, são armazenados no banco de dados de conteúdo para o conjunto
de sites no qual são implantados. Fazer backup do banco de dados de conteúdo
protege esses fluxos de trabalho.
As ações personalizadas de fluxo de trabalho declarativo têm componentes nos três
seguintes locais:
1. Os assemblies do Visual Studio para as Atividades são armazenados no
catálogo de assemblies global (GAC).
2. Os arquivos de definição XML (arquivos .ACTIONS) são armazenados no
diretório 14\TEMPLATE\{LCID}\Workflow.
3. Uma entrada XML para marcar a atividade como um tipo autorizado é
armazenada no arquivo Web.config para os aplicativos Web nos quais é
utilizada.
Se os fluxos de trabalho do seu farm usam ações personalizadas, convém usar um sistema de backup de arquivo para proteger esses arquivos e entradas XML. Semelhante aos recursos do SharePoint Server, como Web parts e receptores de eventos, esses arquivos devem ser reaplicados ao farm conforme necessário após a recuperação.
Fluxos de trabalho que dependem de código personalizado, como os que são
criados por meio do Visual Studio, são armazenados em dois locais. Os assemblies
do Visual Studio para o fluxo de trabalho são armazenados no catálogo de
assemblies global (GAC), e os arquivos de definição XML são armazenados no
diretório Features. O mesmo acontece com outros tipos de recursos do SharePoint
Server, como Web parts e receptores de eventos. Se o fluxo de trabalho tiver sido
instalado como parte de um pacote de solução, o backup do banco de dados de
conteúdo protegerá esses fluxos de trabalho.
Se você criar um fluxo de trabalho personalizado que interaja com um conjunto de
sites diferente daquele no qual o fluxo de trabalho foi implantado, faça backup dos
dois conjuntos de sites para proteger o fluxo de trabalho. Isso inclui os fluxos de
trabalho gravados em uma lista de histórico ou em outra lista personalizada em um
conjunto de sites diferente. O backup do farm é suficiente para fazer backup de
todos os conjuntos de sites no farm e todos os fluxos de trabalho associados a eles.
O backup e a restauração dos fluxos de trabalho que ainda não foram implantados
devem ser feitos separadamente, como qualquer outro arquivo de dados. Durante o
261
desenvolvimento de um novo fluxo de trabalho que ainda não tenha sido implantado
no farm do SharePoint Server, faça backup da pasta na qual você armazena os
arquivos de projeto de fluxo de trabalho usando o Backup do Windows ou outro
aplicativo de backup de sistema de arquivos.
Protegendo aplicativos de serviço
Os aplicativos de serviço em um ambiente do SharePoint Server podem ser formados por configurações de serviço e um ou mais bancos de dados, ou apenas por configurações de serviço. Não é possível restaurar um aplicativo de serviço completo usando uma simples restauração de banco de dados; no entanto, você pode restaurar os bancos de dados para um aplicativo de serviço e provisionar novamente tal aplicativo. Para obter mais informações, consulte Restore a service application (SharePoint Server 2010).
Protegendo os bancos de dados do SQL Server Reporting Services
As atividades de backup e recuperação do SharePoint Server não incluem os bancos de dados do SQL Server Reporting Services. Você deve usar as ferramentas do SQL Server. Para obter mais informações, consulte o artigo sobre operações de backup e restauração para uma instalação do Reporting Services (http://go.microsoft.com/fwlink/?linkid=186642&clcid=0x416).
Escolher ferramentas Para escolher as ferramentas corretas para backup e recuperação, você precisa determinar se pode atender aos critérios de continuidade definidos para a sua empresa no orçamento referente a tempo e recursos.
Os principais fatores a serem considerados ao escolher ferramentas são:
Velocidade de backup: a ferramenta pode ser executada na janela de manutenção
do banco de dados? Teste todo o sistema de backup para garantir que ele atenda às
suas necessidades no hardware.
Integridade da recuperação.
Granularidade dos objetos que podem ser recuperados.
Tipo de backup para o qual há suporte (completo, diferencial ou incremental).
Complexidade do gerenciamento da ferramenta.
A tabela a seguir compara o tipo de backup e o tamanho do farm cujo backup pode ser concluído em uma janela de 6 horas para as ferramentas de backup e recuperação disponibilizadas pela Microsoft.
Ferramenta Tipo de backup Tamanho do
backup concluído
em seis horas1
Backup e recuperação do farm do
SharePoint
Completo, diferencial 600 GB
SQL Server Completo, diferencial 600 GB
System Center Data Protection Incremental Terabytes
262
Ferramenta Tipo de backup Tamanho do
backup concluído
em seis horas1
Manager
1O tamanho do backup foi determinado pela execução de backup de um sistema que totaliza o tamanho especificado no hardware de teste listado na seção a seguir.
Observação:
Os backups do SharePoint Server e do SQL Server foram realizados com a compactação
de backup ativada.
Hardware de teste
A tabela a seguir lista o hardware usado nos testes que determinaram o tamanho do backup que pôde ser concluído em uma janela de seis horas.
Componente Descrição
Processador Processador dual de 64 bits, 3 GHz
RAM 8 GB
Disco Partição formatada do sistema de arquivos
NTFS de 2 terabytes
Rede Conexão de 100 megabits por segundo
(Mbps) ou mais rápida entre os
computadores clientes e o servidor
Compartilhamento de rede Compartilhamento de rede com 1,25 terabytes de espaço livre
Observação:
O limite de tamanho superior para execução de backups de conjuntos de sites do
SharePoint Server 2010 é de 85 GB.
Para obter informações detalhadas sobre sistemas de backup e recuperação que podem ser usados com o Microsoft SharePoint Server, consulte os seguintes recursos:
Visão geral sobre backup e recuperação (SharePoint Server 2010)
Fazendo backup e restaurando bancos de dados no SQL Server
(http://go.microsoft.com/fwlink/?linkid=186643&clcid=0x416)
263
Visão geral do Data Protection Manager 2010 Release Candidate
(http://go.microsoft.com/fwlink/?linkid=186655&clcid=0x416)
Determinar estratégias Com base nos requisitos de negócios, nas necessidades de recuperação e nas ferramentas escolhidas, determine e documente as estratégias de backup e recuperação para o seu ambiente.
Não é raro que os departamentos de TI com suporte para o SharePoint Server decidam pelo uso de várias ferramentas para proteger o ambiente ao determinar as estratégias que utilizarão.
Por exemplo, em um ambiente com bancos de dados gerenciados por DBAs, as estratégias na seguinte lista podem ser aplicadas:
Os backups de todos os bancos de dados são feitos pelo SQL Server. O intervalo de
backup definido para cada banco de dados leva em consideração o seguinte:
O impacto comercial do conteúdo ou do serviço.
A taxa padrão de alterações para o banco de dados.
O impacto que o backup tem no desempenho do ambiente.
Bancos de dados de conteúdo pequenos, que mudam rapidamente e têm altíssimo
impacto comercial têm a proteção adicional dos instantâneos de banco de dados do
SQL Server, que são armazenados em um disco físico separado. Apenas um
instantâneo é armazenado por banco de dados, e os instantâneos são descartados
regularmente, para reduzir o impacto sobre o desempenho. O intervalo de
instantâneo definido para cada banco de dados leva em consideração:
O impacto comercial do conteúdo ou do serviço.
A taxa padrão de alterações para o banco de dados.
O impacto que o instantâneo tem no desempenho do ambiente.
A quantidade de espaço necessária para armazenar o instantâneo.
A recuperação a partir de um instantâneo é mais rápida do que a recuperação padrão porque um instantâneo, junto com seu banco de dados subjacente, pode ser tratado pelo SharePoint Server como um banco de dados desanexado. No entanto, o processo de criação de instantâneos pode baixar o desempenho do banco de dados subjacente. É recomendado testar o efeito dos instantâneos sobre o desempenho do sistema antes de implementá-los, e descartá-los regularmente para diminuir o espaço necessário.
Observação:
Se você estiver usando um RBS cujo provedor não ofereça suporte a instantâneos, não
poderá usar instantâneos para backup. Por exemplo, o provedor SQL FILESTREAM não
oferece suporte a instantâneos.
O backup do SharePoint Server é usado para proteger aplicativos de serviço. O
intervalo de backup é baseado no seguinte:
O impacto comercial do serviço.
A taxa de alteração padrão do banco de dados.
O impacto que o backup tem no desempenho do banco de dados.
264
Todas as operações de restauração são executadas por meio do SharePoint Server.
A escolha do sistema de recuperação a ser usado é determinada pelo tipo de
backup disponível e pelo objeto a ser restaurado.
Outras ferramentas devem fazer parte da estratégia de continuidade dos negócios. Considere como você usará as Lixeiras e o controle de versão nos conjuntos de sites de todo o ambiente. Para obter mais informações, consulte Planejar o gerenciamento da continuidade dos negócios (SharePoint Server 2010).
Planejar backup avançado e desempenho de recuperação Ao planejar sua estratégia de backup e recuperação, considere as seguintes recomendações que podem ajudá-lo a minimizar o efeito do backup e da recuperação no desempenho do sistema.
Por padrão, a maioria dos trabalhos de backup consome a maior quantidade possível de recursos de E/S para concluir o trabalho no tempo disponível para manutenção. Portanto, é possível que você observe um enfileiramento em disco e também que todas as solicitações de E/S retornem mais lentamente do que o normal. Essa situação é comum e não deve ser considerada um problema.
Seguir as recomendações de configuração do SQL Server e armazenamento
Siga as recomendações gerais para configuração do SQL Server e armazenamento de um ambiente do SharePoint Server. Para obter mais informações, consulte Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010).
Minimizar a latência entre o SQL Server e o local de backup
Em geral, é melhor usar um disco local para os backups, e não uma unidade de rede. Se estiver fazendo backup de vários servidores, talvez seja conveniente ter um computador conectado diretamente, no qual ambos os servidores possam gravar. Unidades de rede cuja latência com outras unidades de rede ou com computadores executando o SQL Server seja menor ou igual a 1 milissegundo apresentarão um bom desempenho. Se o seu farm tiver vários servidores (incluindo o computador com o SQL Server em execução), use os caminhos de rede UNC para o local de backup do farm do SharePoint.
Evitar conflitos de processamento
Não execute trabalhos de backup nos momentos em que os usuários precisam acessar o sistema.
Para evitar afunilamentos de E/S, execute o backup principal em um disco separado e somente depois copie para fita.
Considere intercalar os backups para que não ocorra o backup de todos os bancos de dados simultaneamente.
Os backups do SharePoint Server usam os backups do SQL Server. Quando usar compactação nos seus backups, evite sobrecarregar o SQL Server. Por exemplo, algumas ferramentas de backup de terceiros compactam dados durante o backup, o que pode comprometer o desempenho do SQL Server. Há ferramentas disponíveis para acelerar os processos de compactação e controlar o impacto sobre o SQL Server.
265
Seguir as recomendações de otimização de backup e restauração do SQL Server
Se estiver executando o SQL Server 2008 Enterprise, é recomendado usar a compactação de backup. Para obter mais informações, consulte o artigo sobre compactação do backup (SQL Server) (http://go.microsoft.com/fwlink/?linkid=179525&clcid=0x416).
Se estiver usando backups do SQL Server, use uma combinação de backups completos, diferenciais e de log de transação do modelo de recuperação completa para minimizar o tempo da recuperação. Os backups diferenciais de banco de dados geralmente são mais rápidos de criar do que os backups completos de banco de dados e reduzem a quantidade de logs de transações necessária à recuperação do banco de dados.
Se estiver usando o modelo de recuperação completa no SQL Server 2008, recomendamos o uso da opção truncar durante o backup para evitar problemas de manutenção.
Para obter recomendações detalhadas sobre como otimizar o desempenho do backup e da restauração do SQL Server, consulte Otimizando o desempenho de backup e restauração em um SQL Server (http://go.microsoft.com/fwlink/?linkid=126630&clcid=0x416).
Garantir desempenho suficiente de gravação na unidade de backup
Considere cuidadosamente o uso de RAID (Redundant Array of Independent Disks) no dispositivo de backup de disco. Por exemplo, o RAID 5 tem baixo desempenho de gravação, aproximadamente a mesma velocidade de um único disco. (Isso ocorre porque o RAID 5 precisa manter as informações de paridade.) O uso do RAID 10 para um dispositivo de backup pode acelerar os backups. Para obter mais informações sobre como usar o RAID com backups, consulte o artigo sobre como configurar o RAID para obter a máxima taxa de transferência de E/S do SQL Server (http://go.microsoft.com/fwlink/?linkid=126632&clcid=0x416).
Conteúdo relacionado
Central de recursos Business Continuity Management for SharePoint Server 2010(http://go.microsoft.com/fwlink/?linkid=199235&clcid=0x416)
Conteúdo do
profissional de TI
Visão geral sobre backup e recuperação (SharePoint Server
2010)
Backup and recovery (SharePoint Server 2010)
Planejar a disponibilidade (SharePoint Server 2010)
Availability configuration (SharePoint Server 2010)
Planejar a recuperação de desastre (SharePoint Server 2010)
Conteúdo do
desenvolvedor
Proteção e recuperação de dados
(http://go.microsoft.com/fwlink/?linkid=199237&clcid=0x416)
266
Visão geral sobre backup e recuperação (SharePoint Server 2010)
Este artigo descreve a arquitetura de backup e os processos de recuperação disponíveis no Microsoft SharePoint Server 2010, incluindo backup e recuperação granulares e de farm e recuperação de um banco de dados de conteúdo desanexado. Operações de backup e restauração podem ser realizadas por meio da interface do usuário ou pelos cmdlets do Windows PowerShell. Ferramentas de backup e restauração internas talvez não atendam a todas as necessidades de sua organização.
Neste artigo:
Cenários de backup e recuperação
Arquitetura de backup
Processos de recuperação
Cenários de backup e recuperação O backup e a recuperação de dados dão suporte a vários cenários de negócios, como:
Recuperação de conteúdo excluído acidentalmente que não está protegido pela
Lixeira nem pelo controle de versão.
Movimentação de dados entre instalações, como parte de uma atualização de
hardware ou software.
Recuperação de uma falha inesperada.
Arquitetura de backup O SharePoint Server 2010 fornece dois sistemas de backup: de farm e granular.
Arquitetura de backup de farm
A arquitetura de backup de farm no SharePoint Server 2010 inicia um backup do Microsoft SQL Server de bancos de dados de conteúdo e de aplicativos de serviço, grava o conteúdo da configuração em arquivos e cria backups dos arquivos de partição da indexação de pesquisa.
A ilustração a seguir mostra o sistema de backup de farm.
267
Há suporte para backups completos e diferenciais. Os backups completos criam um novo backup do sistema completo. Os backups diferenciais criam um backup de todos os dados armazenados em bancos de dados que foram alterados desde o último backup completo.
O sistema de backup do farm é organizado hierarquicamente. Os componentes de um farm que podem ser selecionados para backup incluem os seguintes itens:
Farm O farm é o objeto de nível mais alto. Você pode selecionar entre as seguintes
opções ao executar um backup de farm:
Dados de configuração e conteúdo (padrão)
É feito o backup de todo o farm de servidores. Isso inclui configurações do banco de dados de configuração.
Apenas configuração
As configurações do banco de dados de configuração são feitas para que você possa aplicar configurações entre farms. Para obter mais informações, consulte Uso e benefícios do backup de configuração mais adiante neste artigo.
268
Aplicativo Web Em um aplicativo Web, você pode selecionar um ou mais bancos
de dados de conteúdo para fazer backup dos mesmos.
Um backup de aplicativo Web inclui o seguinte:
Nome do pool de aplicativos e conta do pool de aplicativos
Configurações de autenticação
Configurações gerais de aplicativos Web, como alertas e caminhos gerenciados
Informações de associação do IIS (Serviços de Informações da Internet), como
tipo de protocolo, cabeçalho do host e número de porta
Alterações no arquivo Web.config feitas por meio do modelo de objeto ou da
Administração Central
Observação:
Alterações no arquivo Web.config que foram feitas para dar suporte à aplicação baseada
em declarações que usa a autenticação baseada em formulários não são incluídas em
backups, pois essas alterações são feitas manualmente. Para obter mais informações,
consulte Considerações sobre o uso de backups de farm, mais adiante neste artigo.
Soluções de área restrita
Para obter recomendações sobre como proteger essas configurações, consulte Planejar o backup e a recuperação (SharePoint Server 2010) Plan for backup and recovery (SharePoint Foundation).
Serviços e aplicativos de serviço (não compartilhados) Um exemplo de serviço
não compartilhado é o Serviço de Controle de Sessão. Os backups de serviços e
aplicativos de serviço contêm as configurações de um serviço ou aplicativo de
serviço e os bancos de dados associados a ele.
Importante:
Os backups de aplicativos de serviço não incluem o proxy relacionado. Para fazer
backup do aplicativo de serviço e do respectivo proxy, você precisa fazer backup do farm
ou executar dois backups consecutivos, selecionando o aplicativo de serviço em um
backup e selecionando o proxy associado no segundo backup.
Não é possível fazer backup individualmente de muitos bancos de dados de aplicativo de serviço do SharePoint Server 2010. Para fazer backup somente de bancos de dados de aplicativo de serviço, você deve usar o backup do SQL Server.
Proxies para aplicativos de serviço que não são compartilhados
Serviços compartilhados Serviços compartilhados requerem um aplicativo de
serviço e um proxy de aplicativo de serviço para serem executados. Se você
selecionar o nó Serviços Compartilhados, todos os aplicativos de serviço e os
proxies de aplicativos de serviço relacionados no farm serão submetidos a backup.
269
Observação:
A hierarquia de backup permite selecionar aplicativos de serviço e proxies de aplicativos
de serviço individuais para backup. No entanto, quando você seleciona um ou todos os
aplicativos de serviço, ou um ou todos os proxies, os objetos relacionados não são
submetidos a backup por padrão. Para fazer backup de ambas as partes de um serviço
específico, selecione o nó Serviços Compartilhados ou execute dois backups
consecutivos, selecionando o aplicativo de serviço em um backup e o proxy de aplicativo
de serviço associado no segundo backup.
Observação:
Algumas configurações no ambiente do SharePoint Server não são incluídas em um
backup de farm. Elas incluem as seguintes configurações que são armazenadas em
servidores Web:
Senhas de contas de pool de aplicativos
Configurações de compactação HTTP
Definições de tempo limite
Filtros personalizados da interface ISAPI
Associação de domínio de computador
Configurações do protocolo IPsec
Configurações de balanceamento de carga de rede
Certificados SSL
Configurações de endereço IP dedicado
Processo de backup do aplicativo de serviço de Pesquisa
O backup e a recuperação do aplicativo de serviço de Pesquisa são um caso especial devido à complexidade das interações entre os componentes do aplicativo.
Quando um backup do aplicativo de serviço de Pesquisa é iniciado, o SharePoint Server 2010 inicia um backup do SQL Server do banco de dados de administração de Pesquisa, de bancos de dados de rastreamento e de bancos de dados de propriedade, além de fazer o backup dos arquivos de partição de índice em paralelo.
Considere como os processos de backup e recuperação para o aplicativo de serviço de Pesquisa afetam seu contrato de nível de serviço. Por exemplo, considere como uma pausa em todos os rastreamentos pode afetar a atualização dos resultados de pesquisa.
O processo de backup é o seguinte:
1. As mesclagens mestras são pausadas para preservar o índice mestre.
2. Um backup completo do banco de dados é iniciado.
3. O backup do índice mestre é realizado.
4. Os rastreamentos são pausados. A pausa do rastreamento é muito mais curta do
que durante um backup da pesquisa do Microsoft Office SharePoint Server 2007 e
não dura ao longo de todo o processo de backup.
270
5. O backup de todos os índices de sombra é realizado.
6. Um backup incremental do banco de dados é iniciado.
7. Os rastreamentos são retomados.
8. As mesclagens mestras são retomadas.
Uso e benefícios do backup de configuração
Um backup de configuração extrai e faz o backup das definições de configuração de um banco de dados de configuração. Usando ferramentas internas, você pode fazer o backup da configuração de qualquer banco de dados de configuração, se ele estiver atualmente anexado a um farm ou não. Para obter informações detalhadas sobre como fazer o backup de uma configuração, consulte Back up a farm configuration (SharePoint Server 2010).
Um backup de configuração pode ser restaurado para o mesmo — ou qualquer outro — farm de servidores. Quando uma configuração é restaurada, ela substitui as configurações presentes no farm que têm valores definidos no backup de configuração. Se nenhuma configuração presente no farm estiver contida no backup de configuração, não haverá alteração. Para obter informações detalhadas sobre como restaurar uma configuração de farm, consulte Restore a farm configuration (SharePoint Server 2010).
Observação:
As configurações de aplicativos Web e aplicativos de serviço não são incluídas em um
backup de configuração. Você pode usar os cmdlets do Windows PowerShell para
configurações de cópia e de documento dos aplicativos de serviço. Para obter mais
informações, consulte Document farm configuration settings (SharePoint Server 2010) e
Copy configurations from one farm to another (SharePoint Server 2010).
As situações em que convém restaurar uma configuração de um farm para outro incluem:
Replicação de uma configuração de farm padronizada a ser usada em todo um
ambiente.
Movimentação de configurações de um ambiente de desenvolvimento ou de teste
para um ambiente de produção.
Movimentação de configurações de uma instalação autônoma para um ambiente de
farm.
Configuração de um farm para fazer parte de um ambiente de espera.
O SharePoint Server armazena os seguintes tipos de configurações no backup apenas de configuração:
Antivírus
Gerenciamento de direitos de informação (IRM)
Configurações de email de saída (restauradas somente ao ser realizada uma
substituição).
Personalizações implantadas como soluções confiáveis
Log de Diagnóstico
Considerações sobre o uso de backups de farm
271
Considere o seguinte antes de usar backups de farm:
Não existe um sistema de agendamento interno para backups. Para agendar um
backup, é recomendável criar um script de backup usando o Windows PowerShell e,
em seguida, usar o Agendador de Tarefas do Windows para executar o script de
backup regularmente.
Não é recomendável usar o backup de metabase do IIS para proteger as
configurações do IIS. Em vez disso, documente todas as configurações do IIS para
cada servidor Web usando uma ferramenta que ofereça o monitoramento de
configuração desejado, como o Microsoft System Center Configuration Manager
2010.
O backup e a recuperação do SharePoint Server 2010 podem ser executados junto
com os recursos do SQL Server Enterprise, como compactação de backup e
criptografia de dados transparente.
Se você estiver executando o SQL Server Enterprise, é altamente recomendável usar a compactação de backup. Para obter mais informações sobre compactação de backup, consulte o artigo sobre compactação de backup (SQL Server) (http://go.microsoft.com/fwlink/?linkid=129381&clcid=0x416).
Se optar por executar os bancos de dados com criptografia de dados transparente, você deverá fazer backup manual da chave e restaurá-la; o backup e a restauração do SharePoint Server 2010 não o lembrarão sobre a chave. Para obter mais informações sobre criptografia de dados transparente, consulte o artigo sobre TDE (criptografia de dados transparente) (http://go.microsoft.com/fwlink/?linkid=129384&clcid=0x416).
Se um banco de dados de conteúdo estiver definido para usar o provedor RBS
(Remote BLOB Storage) SQL FILESTREAM, o provedor RBS deverá estar instalado
no servidor do banco de dados cujo backup está sendo feito e no servidor de banco
de dados para o qual ele está sendo recuperado.
O backup do SharePoint Server 2010 não protege:
Alterações no arquivo Web.config em servidores Web que não são feitas por
meio da Administração Central ou do modelo de objeto.
Personalizações em um site que não são implantadas como parte de uma
solução confiável ou em área restrita.
Se você estiver compartilhando aplicativos de serviço entre farms, lembre-se de que
os certificados de confiança que foram trocados não são incluídos em backups de
farms. Você deve fazer backup do repositório de certificados separadamente ou
manter os certificados em local separado. Ao restaurar um farm que compartilha um
aplicativo de serviço, você deve importar e reimplantar os certificados e, em seguida,
restabelecer as relações de confiança entre farms.
Para obter mais informações, consulte Exchange trust certificates between farms (SharePoint Server 2010).
Quando você restaura um farm ou aplicativo Web que está configurado para usar
qualquer tipo de autenticação baseada em declarações, provedores duplicados ou
adicionais podem parecer estar habilitados. Se aparecerem duplicatas, você deverá
salvar manualmente cada zona de aplicativo Web para removê-las.
Etapas adicionais são necessárias quando você restaura um farm que contém um
aplicativo Web configurado para usar autenticação baseada em formulários. É
272
necessário registrar novamente os provedores de associação e de função no arquivo
Web.config e, em seguida, reimplantar os provedores. Você deverá executar essas
etapas se estiver restaurando no nível de aplicativo Web ou de farm.
Para obter mais informações, consulte Back up a Web application (SharePoint Server 2010), Planejar métodos de autenticação (SharePoint Server 2010) e Configure claims authentication (SharePoint Server 2010).
Arquitetura de exportação e backup granular
A arquitetura de exportação e backup granular usa consultas Transact-SQL e chamadas de exportação. A exportação e backup granular é uma operação que utiliza mais processamento e leitura do que o backup de farm.
Por meio do sistema de backup granular, um usuário pode fazer o backup de um conjunto de sites ou exportar um site ou uma lista.
Observação:
Fluxos de trabalho não são incluídos em exportações de sites ou listas.
Se você estiver executando o SQL Server Enterprise, o sistema de backup granular poderá usar, opcionalmente, instantâneos de banco de dados do SQL Server para garantir que os dados permaneçam consistentes enquanto o backup ou a exportação estiver em andamento. Quando um instantâneo é solicitado, um instantâneo de banco de dados do SQL Server do banco de dados de conteúdo apropriado é tirado e o SharePoint Server o utiliza para criar o backup ou exportar o pacote. Em seguida, esse instantâneo é excluído. Instantâneos de banco de dados são vinculados ao banco de dados dos quais se originaram Se o banco de dados de origem ficar offline por qualquer motivo, o instantâneo não estará disponível. Para obter mais informações sobre instantâneos de banco de dados, consulte o artigo sobre instantâneos de banco de dados (http://go.microsoft.com/fwlink/?linkid=166158&clcid=0x416).
As vantagens de fazer backup de um conjunto de sites usando um instantâneo incluem:
O instantâneo assegura que os dados que estão sendo lidos permaneçam
consistentes enquanto a operação é executada.
Os usuários podem continuar a interagir com o conjunto de sites durante o backup a
partir do instantâneo do banco de dados. Isso inclui adicionar, editar e excluir
conteúdo. No entanto, as alterações feitas pelo usuário no site ativo não serão
incluídas no backup do conjunto de sites, pois o backup é baseado no instantâneo
do banco de dados.
No entanto, instantâneos de bancos de dados podem prejudicar o desempenho. Para obter mais informações sobre instantâneos de bancos de dados e desempenho, consulte o artigo sobre limitações e requisitos de instantâneos de bancos de dados (http://go.microsoft.com/fwlink/?linkid=166159&clcid=0x416).
Você pode usar o backup granular e exportar para o conteúdo armazenado em um banco de dados configurado para usar o provedor RBS SQL FILESTREAM.
273
Observação:
Se o provedor RBS que você está usando não tiver suporte para instantâneos, não será
possível usá-los para implantação de conteúdo ou backup. Por exemplo, o provedor SQL
FILESTREAM não tem suporte para instantâneos.
Observação:
Não é recomendável usar o backup do conjunto de sites do SharePoint Server 2010 para
conjuntos de sites com mais de 85 GB.
A ilustração a seguir mostra o backup granular e o sistema de exportação.
274
Processos de recuperação O SharePoint Server 2010 dá suporte às seguintes opções de recuperação internas primárias:
Restaurar de um backup de farm criado com ferramentas internas ou de um backup
de componente criado com o sistema de backup de farm.
Restaurar de um backup de conjuntos de sites.
275
Conectar-se a um banco de dados de conteúdo usando o recurso de banco de
dados de conteúdo desanexado, fazer o backup ou a exportação dos seus dados e,
em seguida, restaurar ou importar esses dados.
Restaurar por meio de um backup de farm
Os itens que podem ser recuperados de um backup de farm são:
Farm
Dados de configuração e conteúdo (padrão)
O farm de servidores inteiro é restaurado. Isso inclui as configurações do banco de dados de configuração e os pacotes de soluções confiáveis.
Apenas configuração
Apenas os dados de configuração são restaurados. Isso substitui quaisquer configurações do farm com valores definidos no backup apenas de configuração.
Aplicativos Web
Restaura aplicativos Web.
Aplicativos de serviço
Restaura aplicativos de serviço. A recuperação dos aplicativos de serviço pode ser complexa, pois o SharePoint Server 2010 não pode reconfigurar totalmente os proxies de aplicativos de serviço durante o processo de restauração. Os proxies de aplicativos de serviço são restaurados, mas não são colocados em grupos de proxies. Portanto, não são associados a aplicativos Web. Para obter mais informações sobre como restaurar um aplicativo de serviço de Pesquisa, consulte Processo de recuperação do aplicativo de serviço de Pesquisa. Para obter informações específicas sobre as operações envolvidas na restauração de aplicativos de serviço específicos, consulte Restore a service application (SharePoint Server 2010).
Bancos de dados de conteúdo
Quando os bancos de dados de conteúdo são restaurados, as soluções de área restrita associadas aos conjuntos de site relacionados também são restauradas.
Restaurando como novo versus restaurando como substituição
Por padrão, a recuperação do SharePoint Server 2010 restaura qualquer objeto como uma nova instância do objeto, em vez de substituir as instâncias existentes com o mesmo nome.
Quando você restaura um farm ou objeto como novo, os objetos a seguir não funcionam sem ajustes, pois são atribuídos novos valores a todos os GUIDs de objetos.
Farm. Ao restaurar um farm como novo, você deve:
Recriar as configurações de mapeamento de acesso alternativo. A recuperação
do SharePoint Server 2010 só restaura a zona Padrão do aplicativo Web.
Redefinir as configurações de qualquer origem externa de aplicativos de
Serviços Corporativos de Conectividade e Metadados Gerenciados.
Associar novamente os proxies de aplicativos de serviço a grupos de proxies,
pois os proxies de aplicativos de serviço não são atribuídos a grupos de proxies
quando restaurados. Todos os aplicativos Web serão associados ao grupo de
proxies padrão. Você deverá associar aplicativos Web a outros grupos de
proxies, se desejar fazer isso.
276
Aplicativo Web.
Se o nome e a URL do aplicativo Web fornecidos corresponderem a um nome e
a uma URL de aplicativo Web já existentes no farm, a recuperação do
SharePoint Server 2010 os combinará.
Se não desejar combinar aplicativos Web, renomeie o aplicativo Web ao
restaurá-lo como novo.
Quando um aplicativo Web é restaurado como novo no mesmo ambiente, mas
sem que haja uma combinação de aplicativos Web, muitos outros parâmetros e
objetos também devem ser alterados. Por exemplo, talvez seja necessário
fornecer diferentes caminhos de arquivos de bancos de dados e nomes de
bancos de dados.
Aplicativos de serviço e proxies de aplicativos de serviço
Se recuperar um aplicativo de serviço e também recuperar o proxy de aplicativo
de serviço relacionados, você deverá associar o proxy de aplicativo de serviço a
um grupo de proxies.
Se recuperar um aplicativo de serviço e não recuperar também o proxy de
aplicativo de serviços relacionados, você deverá recriar o proxy de aplicativo de
serviço.
Observação:
Não é possível restaurar um aplicativo de serviço como novo no mesmo farm. É possível
restaurar um aplicativo de serviço como novo em outro farm.
Quando um objeto é restaurado e o objeto existente é substituído, nenhuma alteração é necessária.
Processo de recuperação do aplicativo de serviço de Pesquisa
O processo de recuperação do aplicativo de serviço de Pesquisa varia, dependendo de você estar restaurando como novo ou restaurando como substituição. Quando você restaura como substituição, não são necessárias outras etapas.
O processo de restaurar como novo é o seguinte:
1. Restaure o serviço de aplicativo como novo e especifique as novas informações de
topologia do farm durante a restauração.
2. Restaure o proxy do aplicativo de serviço como novo. Se não tiver restaurado o
proxy do aplicativo de serviço, você deverá criar um novo proxy do aplicativo de
serviço e associá-lo ao aplicativo de serviço de Pesquisa.
3. Associe o proxy do aplicativo de serviço ao grupo de proxies apropriado e associe o
grupo de proxies (caso não seja o grupo padrão) ao aplicativo Web apropriado.
4. Em implantações com menos privilégios, inicie o serviço de Pesquisa e o serviço
Web de consulta ao administrador de Pesquisa com a conta apropriada.
Para obter mais informações sobre como recuperar o aplicativo de serviço de Pesquisa, consulte Restore Search (SharePoint Server 2010).
Restaurando de um backup de conjuntos de sites
Apenas conjuntos de sites podem ser recuperados de um backup de conjuntos de sites.
Recuperando de um banco de dados de conteúdo desanexado
277
O SharePoint Server 2010 permite conectar-se a e fazer backup de um banco de dados de conteúdo que esteja anexado a uma instância do SQL Server, mas que não esteja associado a um aplicativo Web local do SharePoint. Os bancos de dados desanexados aos quais você pode se conectar incluem bancos de dados de conteúdo somente leitura restaurados do SQL Server ou backups do SQL Server e instantâneos de bancos de dados do SQL Server de bancos de dados de conteúdo.
A recuperação é um processo de dois estágios:
1. Fazer backup ou exportar o objeto do banco de dados de conteúdo desanexado.
2. Restaurar ou importar a saída da etapa anterior para o SharePoint Server 2010.
É possível fazer backup dos itens a seguir ou exportá-los de um banco de dados desanexado usando exportação e backup granular e, e em seguida, restaurá-los.
Conjunto de sites
Fazer backup usando o backup de conjuntos de sites e recuperar usando uma restauração de conjunto de sites.
Site
Exportar e depois importar.
Listas e bibliotecas
Exportar e depois importar.
Você pode usar a importação para recuperar conteúdo do qual fez backup de um banco de dados configurado para usar o provedor RBS SQL FILESTREAM. O conteúdo recuperado será armazenado pelo SharePoint Server 2010 usando o provedor de armazenamento definido no momento para esse banco de dados de conteúdo; ou seja, se o banco de dados de conteúdo não estiver definido para usar RBS, os dados serão armazenados no banco de dados de conteúdo. Se o banco de dados de conteúdo estiver definido para usar RBS, os dados serão armazenados no RBS.
Conteúdo relacionado
Central de recursos Business Continuity Management para SharePoint Server 2010 (http://go.microsoft.com/fwlink/?linkid=199235&clcid=0x416)
Conteúdo do IT pro Planejar o backup e a recuperação (SharePoint Server
2010)
Backup and recovery (SharePoint Server 2010)
Conteúdo do desenvolvedor Proteção e recuperação de dados
(http://go.microsoft.com/fwlink/?linkid=199237&clcid=0x416)
278
Planejar a disponibilidade (SharePoint Server 2010)
Este artigo descreve as principais decisões a serem tomadas ao escolher as estratégias de disponibilidade para um ambiente do Microsoft SharePoint Server 2010.
Quando estiver revisando cuidadosamente seus requisitos de disponibilidade, esteja ciente de que quanto maior o nível de disponibilidade e quanto mais sistemas você protege, mais complexa e onerosa provavelmente será a sua solução de disponibilidade.
Nem todas as soluções em uma organização devem exigir o mesmo nível de disponibilidade. Você pode oferecer diferentes níveis de disponibilidade para sites diferentes, serviços diferentes ou farms diferentes.
Neste artigo:
Visão geral de disponibilidade
Escolhendo uma estratégia e um nível de disponibilidade
A redundância e o failover entre data centers em locais próximos são configurados
como um único farm (farm "alongado")
Visão geral de disponibilidade A disponibilidade é um grau pelo qual um ambiente do SharePoint Server é percebido por usuários como disponível. Um sistema disponível é um sistema flexível — ou seja, incidentes que afetem o serviço ocorrem com pouca frequência e ações oportunas e eficientes são tomadas quando eles ocorrem.
A disponibilidade faz parte do gerenciamento de continuidade de negócios (BCM) e está relacionada a backup e recuperação e recuperação de desastre. Para obter mais informações sobre esses processos relacionados, consulte Planejar o backup e a recuperação (SharePoint Server 2010) e Planejar a recuperação de desastre (SharePoint Server 2010).
Observação:
Ao calcular a disponibilidade, a maioria das organizações especificamente isenta ou
adiciona horas para atividades de manutenção planejada.
Uma das medidas mais comuns de disponibilidade é o percentual de duração da operação, expresso como número de noves — ou seja, o percentual de tempo em que um determinado sistema está ativo e em funcionamento. Por exemplo, diz-se que um sistema com percentual de duração da operação de 99,999 tem cinco noves de disponibilidade.
A tabela a seguir correlaciona o percentual de duração da operação com equivalentes de hora de calendário.
279
Percentual de duração da
operação aceitável
Tempo de inatividade por dia Tempo de inatividade
por mês
Tempo de inatividade por ano
95 72 minutos 36 horas 18,26 dias
99 (dois noves) 14,40 minutos 7 horas 3,65 dias
99,9 (três noves) 86,40 segundos 43 minutos 8,77 horas
99,99 (quatro noves) 8,64 segundos 4 minutos 52,60 minutos
99,999 (cinco noves) 0,86 segundo 26 segundos 5,26 minutos
Se você puder fazer uma boa estimativa sobre o número total de horas de tempo de inatividade provável por ano, poderá usar as fórmulas a seguir para calcular o percentual de duração da operação para um ano, um mês ou uma semana:
% duração da operação/ano = 100 - (8760 - número total de horas de tempo de inatividade por ano)/8760
% duração da operação/mês = 100 - ((24 × número de dias do mês) - número total de horas de tempo de inatividade nesse mês do calendário)/(24 × número de dias do mês)
% duração da operação/semana = 100 - (168 - número total de horas de tempo de inatividade nessa semana)/168
Custos de disponibilidade
Quanto maior o nível de disponibilidade e quanto mais sistemas você protege, mais complexa e onerosa provavelmente será a sua solução de disponibilidade. Quando você investe em disponibilidade, os custos incluem o seguinte:
Hardware e software adicionais, o que poderá aumentar a complexidade de
interações entre aplicativos de software e configurações.
Complexidade operacional adicional.
Os custos de aumentar a disponibilidade devem ser avaliados em conjunto com as necessidades da sua empresa — nem todas as soluções em uma organização devem exigir o mesmo nível de disponibilidade. Você pode oferecer diferentes níveis de disponibilidade para sites diferentes, serviços diferentes ou farms diferentes.
A disponibilidade é uma área fundamental em que grupos de TI (tecnologia da informação) oferecem contratos de nível de serviço para definir as expectativas com grupos de clientes. Muitas organizações de TI oferecem vários contratos de nível de serviço, que são associados a diferentes níveis de estorno.
Determinando requisitos de disponibilidade
Para medir a tolerância da sua organização em relação ao tempo de inatividade de um site, serviço ou farm, responda às seguintes perguntas:
Se o site, serviço ou farm ficar indisponível, os funcionários não conseguirão
executar as responsabilidades de trabalho esperadas?
280
Se o site, serviço ou farm ficar indisponível, as transações empresariais e de clientes
serão paradas, levando a perdas de negócios e de clientes?
Se você respondeu sim para uma dessas perguntas, deverá investir em uma solução de disponibilidade.
Escolhendo uma estratégia e um nível de disponibilidade Você pode optar entre várias abordagens para aumentar a disponibilidade no ambiente do SharePoint Server, incluindo o seguinte:
Aprimorar a tolerância a falhas de componentes de hardware de servidor.
Aumentar a redundância de funções de servidor em um farm.
Tolerância a falhas de componente de hardware
A tolerância a falhas de componente de hardware é a redundância de componentes de hardware e sistemas de infraestrutura, como fontes de alimentação, no nível do servidor. Quando estiver planejando a tolerância a falhas de componentes de hardware, considere o seguinte:
A redundância completa de todos os componentes de um servidor pode ser
impossível ou impraticável. Use outros servidores para obter redundância adicional.
Garanta que os servidores tenham várias fontes de alimentação conectadas a fontes
de energia diferentes para obter a redundância máxima.
Em qualquer sistema, recomendamos que você trabalhe com fornecedores de hardware para obter hardware tolerante a falhas apropriado ao sistema, incluindo matrizes RAID (redundant array of independent disks).
Redundância em um farm
O SharePoint Server 2010 oferece suporte à execução de funções de servidor em computadores redundantes (ou seja, dimensionamento) em um farm para aumentar a capacidade e oferecer disponibilidade básica.
A capacidade necessária determina o número de servidores e o tamanho dos servidores em um farm. Depois de atingir os seus requisitos de capacidade base, talvez seja necessário adicionar mais servidores para aumentar a disponibilidade geral. A ilustração a seguir mostra como você pode oferecer redundância para cada função de servidor.
Disponibilidade em um farm de servidores
281
A tabela a seguir descreve as funções de servidor em um ambiente do SharePoint Server 2010 e as estratégias de redundância que podem ser usadas para cada uma delas em um farm.
Função de servidor Estratégia de redundância preferencial em um
farm
Servidor Web front-end Implante vários servidores Web front-end
em um farm e use o NLB (Balanceamento
282
Função de servidor Estratégia de redundância preferencial em um
farm
de Carga de Rede).
Servidor de aplicativos Implante vários servidores de aplicativos em
um farm.
Servidor de banco de dados Implante servidores de banco de dados usando cluster ou espelhamento de banco de dados de alta disponibilidade.
Estratégias de disponibilidade de banco de dados
Você pode usar o cluster de failover do Microsoft SQL Server ou o espelhamento de banco de dados de alta disponibilidade do SQL Server para oferecer suporte à disponibilidade de bancos de dados em um ambiente do SharePoint Server.
Cluster de failover do SQL Server
O cluster de failover pode oferecer suporte a disponibilidade para uma instância do SQL Server. Um cluster de failover é uma combinação de um ou mais nós ou servidores e dois ou mais discos compartilhados. Uma instância de cluster de failover aparece como um único computador, mas tem funcionalidade que oferece failover de um nó para outro caso o nó atual fique indisponível. O SharePoint Server pode ser executado em qualquer combinação de nós ativos e passivos em um cluster com suporte do SQL Server.
O SharePoint Server faz referências ao cluster como um todo; dessa forma, o failover é automático e direto da perspectiva do SharePoint Server.
Para obter informações detalhadas sobre cluster de failover, consulte Introdução ao cluster de failover do SQL Server 2008 (http://go.microsoft.com/fwlink/?linkid=102837&clcid=0x416) e Configure availability by using SQL Server clustering (SharePoint Server 2010).
Espelhamento de alta disponibilidade do SQL Server
O espelhamento de banco de dados é uma tecnologia do SQL Server que pode oferecer redundância de bancos de dados por banco de dados. No espelhamento de banco de dados, as transações são enviadas diretamente de um banco de dados e de um servidor principal para um banco de dados espelho quando o buffer de log de transações do banco de dados principal é gravado no disco. Essa técnica é capaz de manter o banco de dados espelho praticamente atualizado com o banco de dados principal. O SQL Server Enterprise Edition dispõe de uma funcionalidade adicional que melhora o desempenho de espelhamento do banco de dados. Para obter mais informações, consulte SQL Server 2008 R2 e Produtos do SharePoint 2010: melhores juntos (white paper) (SharePoint Server 2010).
Para espelhamento em um farm do SharePoint Server, você deverá usar o espelhamento de alta disponibilidade, também conhecido como modo de alta segurança com failover automático. O espelhamento de banco de dados de alta disponibilidade envolve três instâncias de servidor:uma principal, um espelho e uma testemunha. O servidor testemunha permite que o SQL Server faça o failover automático do servidor principal para o servidor espelho. O failover do banco de dados principal para o banco de dados de espelho normalmente leva alguns segundos.
283
Uma alteração de versões anteriores é que o SharePoint Server reconhece espelhamentos. Depois de configurar uma instância de espelho de banco de dados do SQL Server, você utiliza a Administração Central do SharePoint ou cmdlets do Windows PowerShell para identificar a localização do servidor de banco de dados (espelho) de failover para um banco de dados de configuração, um banco de dados de conteúdo ou um banco de dados de aplicativo de serviço. A definição da localização do banco de dados de failover adiciona um parâmetro à cadeia de conexão que o SharePoint Server usa para se conectar ao SQL Server. No caso de um evento de expiração de tempo limite do SQL Server, ocorrerá o seguinte:
1. O servidor testemunha configurado para espelhamento do SQL Server
automaticamente alterna as funções dos bancos de dados primário e espelho.
2. O SharePoint Server tenta automaticamente contatar o servidor especificado como o
banco de dados de failover.
Para obter informações sobre como configurar o espelhamento de banco de dados, consulte Configure availability by using SQL Server database mirroring (SharePoint Server 2010).
Para obter informações gerais sobre o espelhamento de banco de dados, consulte Espelhamento de banco de dados (http://go.microsoft.com/fwlink/?linkid=180597&clcid=0x416).
Observação:
Não é possível espelhar bancos de dados configurados para usar o provedor remoto de
repositório de BLOB de FILESTREAM do SQL Server.
Comparação de estratégias de disponibilidade de banco de dados para um único farm: cluster de failover do SQL Server versus espelhamento de alta disponibilidade do SQL Server
A tabela a seguir compara o cluster de failover ao espelhamento de alta disponibilidade do SQL Server síncrono.
Cluster de failover do SQL Server Espelhamento de alta disponibilidade do SQL Server
Tempo para failover O membro de cluster assume a falha imediatamente.
O espelho assume a falha imediatamente.
Consistência transacional? Sim Sim
Simultaneidade transacional? Sim Sim
Tempo para recuperação Tempo menor para recuperação
(milissegundos)
Tempo ligeiramente menor para
recuperação
284
Cluster de failover do SQL Server Espelhamento de alta disponibilidade do SQL Server
(milissegundos)
Etapas exigidas para failover? A falha é automaticamente
detectada pelos nós do banco de
dados; o SharePoint Server 2010
faz referência ao cluster para que o
failover seja direto e automático.
A falha é
automaticamente detectada pelo banco de dados; o SharePoint Server 2010
reconhecerá o
local do espelho se tiver sido configurado corretamente, portanto, o
failover será
automático.
Proteção contra falha de
armazenamento?
Não protege contra falha de
armazenamento, pois o armazenamento é compartilhado
entre os nós do cluster.
Protege contra falha de armazenamento porque os dois servidores de banco de dados, principal e espelho, gravam nos discos locais.
Tipos de armazenamento com suporte
Armazenamento compartilhado (mais caro).
É possível usar o
DAS (direct-attached
storage), que é
mais econômico.
Requisitos de local Os membros do cluster devem estar na mesma sub-rede.
Os servidores principal, espelho e testemunha deve estar na mesma LAN (viagem de ida e volta com
latência de até 1
milissegundo)
Modelo de recuperação É recomendável o modelo de
recuperação completa do SQL
Server. Você pode usar o modelo
Exige o modelo
de recuperação
completa do SQL
285
Cluster de failover do SQL Server Espelhamento de alta disponibilidade do SQL Server
de recuperação simples do SQL
Server, porém, se o cluster for
perdido, o único ponto de
recuperação disponível será o
último backup completo.
Server.
Sobrecarga de desempenho Alguma redução de desempenho
pode ocorrer durante um failover.
O espelhamento de alta disponibilidade
introduz latência
transacional
porque é
síncrono. Ele
também exige
memória
adicional e sobrecarga de processador.
Carga operacional Configurada e mantida no nível de
servidor.
A carga
operacional é
maior do que o clustering. Deve ser configurada e mantida em todos os bancos de dados. A
reconfiguração
após o failover é
manual.
Estratégias de redundância de aplicativo de serviço
A estratégia de redundância a ser seguida para proteger os aplicativos de serviço executados em um farm varia conforme o local onde o aplicativo de serviço armazena os dados.
Aplicativos de serviço que armazenam dados fora de um banco de dados
Para proteger os aplicativos de serviço que armazenam dados fora de um banco de dados, instale-os em vários servidores de aplicativos para oferecer redundância ao ambiente.
Nesta versão do SharePoint Server, quando você instalar um aplicativo de serviço em vários servidores de aplicativos, os trabalhos de timer serão executados em todos os servidores de aplicativos que estiverem executando a instância do serviço associada a esse aplicativo de serviço ou no primeiro servidor disponível. Se houver falhas em um
286
servidor de aplicativos, os trabalhos de timer executados nesse servidor serão reiniciados em outro servidor quando o próximo trabalho de timer estiver programado para ser executado.
A instalação de um aplicativo de serviço em vários servidores de aplicativos mantém o aplicativo de serviço funcionando, mas não garante que os dados não serão perdidos. Se houver falha em um servidor de aplicativos, as conexões ativas desse servidor serão perdidas e os usuários perderão alguns dados.
Os seguintes aplicativos de serviço armazenam dados fora de um banco de dados:
Serviços do Access
Aplicativo de Serviços do Excel
Aplicativos de serviço que armazenam dados em bancos de dados
Para ajudar a proteger os aplicativos de serviço que armazenam dados em bancos de dados, execute as seguintes etapas:
1. Instale o serviço em vários servidores de aplicativos para fornecer redundância no
ambiente.
2. Configure o cluster ou o espelhamento do SQL Server para proteger os dados.
Estes aplicativos de serviço armazenam dados em bancos de dados:
Aplicativo de serviço de pesquisa, incluindo os seguintes bancos de dados:
Administração de Pesquisa
Rastreamento
Propriedade
Observação:
Há suporte para o espelhamento dos bancos de dados de Pesquisa, mas oferecer
redundância para a Pesquisa exige trabalho adicional. Para obter detalhes, consulte
Estratégias de redundância de pesquisa em um farm.
Serviço de Perfil de Usuário, incluindo os seguintes bancos de dados:
Perfis
Social
Sincronização
Observação:
Não há suporte para o espelhamento do banco de dados de Sincronização.
Aplicativo Serviço Conectividade de Dados Corporativos
Aplicativo de serviço de Registro de Aplicativo
Não é recomendável fazer o espelhamento do banco de dados de Registro de Aplicativo porque ele é usado apenas durante a atualização de informações do Catálogo de Dados Corporativos do Microsoft Office SharePoint Server 2007 para o SharePoint Server 2010.
Aplicativo de Serviço de Conjunto de Dados de Uso e Integridade
287
Observação:
Não é recomendável fazer o espelhamento do banco de dados de registro em log do
aplicativo de serviço de Conjunto de Dados de Uso e Integridade.
Aplicativo de serviço de Metadados Gerenciados
Aplicativo de serviço de Repositório Seguro
Aplicativo de serviço de Controle de Sessão
Aplicativo de serviço do Web Analytics, incluindo os seguintes bancos de dados:
Relatórios
Preparo
Observação:
Não há suporte para o espelhamento do banco de dados de Preparo.
Aplicativo de serviço dos Word Automation Services
Serviço de Configurações de Inscrição do Microsoft SharePoint Foundation
Serviços PerformancePoint
Estratégias de redundância de pesquisa em um farm
Somente Servidor
O aplicativo de serviço de Pesquisa é um caso especial de redundância em um farm. A ilustração a seguir mostra como a redundância e o failover podem ser configurados para um aplicativo de serviço de Pesquisa médio dedicado que rastreia aproximadamente 40 milhões de itens. Para obter mais informações sobre a arquitetura do aplicativo de serviço de Pesquisa, consulte "Arquiteturas de pesquisa do Microsoft SharePoint Server 2010" no artigo Diagramas técnicos (SharePoint Server 2010).
Aplicativo de serviço de Pesquisa Redundante
288
Servidor de consulta. Um servidor de consulta hospeda os componentes e as
partições de índice de uma consulta.
289
Os componentes de consulta retornam os resultados da pesquisa. Cada
componente de consulta faz parte de uma partição de índice, que é associada a
um banco de dados de propriedade específico que contém metadados
associados a determinado conjunto de conteúdo rastreado. Você pode fazer
com que uma partição de índice fique redundante adicionando componentes de
consulta "espelhados" à ela e colocando-os em servidores de farm diferentes.
Observação:
O uso do termo componentes de consulta espelhados refere-se a cópias de arquivo
idênticas, e não ao espelhamento de bancos de dados do SQL Server.
As partições de índice são grupos de componentes de consulta, cada um com
um subconjunto do índice de texto completo que retorna os resultados da
pesquisa. Cada partição de índice é associada a um banco de dados de
propriedade específico que contém metadados associados a determinado
conjunto de conteúdo rastreado. Você pode escolher quais servidores de um
farm lidarão com as consultas criando um componente de consulta nesse
servidor. Se quiser equilibrar a carga de manipulação de consultas em vários
servidores do farm, adicione componentes de consulta a uma partição de índice
e associe-os aos servidores que deseja usar para lidar com as consultas. Para
obter mais informações, consulte Add or remove a query component. Você pode
fazer com que uma partição de índice fique redundante adicionando
componentes de consulta espelhados à ela e colocando-os em servidores de
consulta diferentes.
Servidor de rastreamento. Um servidor de rastreamento hospeda componentes de
rastreamento e um componente de administração de pesquisa.
Os componentes de rastreamento processam rastreamentos de fontes de
conteúdo, propagam arquivos de índice resultantes aos componentes de
consulta e adicionam informações sobre o local e o agendamento de
rastreamento de fontes de conteúdo aos bancos de dados de rastreamento
associados. Eles também são associados a um único aplicativo de serviço de
Pesquisa. Você pode distribuir a carga de rastreamento adicionando
componentes de rastreamento a diferentes servidores de rastreamento. Você
pode ter quantos componentes de rastreamento os recursos permitirem em um
servidor de rastreamento especificado. Se você tiver muitos locais de conteúdo,
poderá adicionar componentes de rastreamento e bancos de dados de
rastreamento e dedicá-los ao conteúdo específico. Cada componente de
rastreamento em determinado servidor de rastreamento deve estar associado a
um banco de dados de rastreamento separado. Para obter redundância, é
recomendável que você tenha no mínimo dois componentes de rastreamento.
Cada um deles deve ser definido para rastrear os dois bancos de dados de
rastreamento. Se um banco de dados ultrapassar 25 milhões de itens, é
recomendável adicionar um novo banco de dados de rastreamento e
componente de rastreamento.
O componente de administração de pesquisa monitora as ações de entrada do
usuário e atualiza o banco de dados de administração de pesquisa. Apenas um
componente de administração de pesquisa é permitido por aplicativo de serviço
de Pesquisa. O componente de administração de pesquisa pode ser executado
290
em qualquer servidor, preferencialmente em um servidor de rastreamento ou de
consulta.
Servidores de banco de dados. Os servidores de banco de dados hospedam bancos
de dados de rastreamento, de propriedade, de administração de pesquisa e outros
bancos de dados do SharePoint Server 2010.
Banco de dados de rastreamento
Os bancos de dados de rastreamento contêm dados relacionados ao local das fontes de conteúdo, agendamentos de rastreamento e outras informações específicas às operações de rastreamento de determinado aplicativo de serviço de Pesquisa. Você pode distribuir a carga do banco de dados adicionando bancos de dados de rastreamento a diferentes computadores que estiverem executando o SQL Server. Os bancos de dados de rastreamento são associados a componentes de rastreamento e podem ser dedicados a hosts específicos por meio da criação de regras de distribuição de host. Para obter mais informações sobre os componentes de rastreamento, consulte Add or remove a crawl component. Para obter mais informações sobre as regras de distribuição de host, consulte Add or remove a host distribution rule. Os bancos de dados de rastreamento serão redundantes se forem espelhados ou implantados em um cluster de failover do SQL Server.
Banco de dados de propriedade
Os bancos de dados de propriedade contêm metadados associados ao conteúdo rastreado. Você pode distribuir a carga das consultas do banco de dados adicionando bancos de dados de propriedade a diferentes computadores que estejam executando o SQL Server. Os bancos de dados de propriedade são associados a partições de índice e retornam todos os metadados associados ao conteúdo nos resultados da consulta.
Os bancos de dados de propriedade serão redundantes se forem espelhados ou implantados em um cluster de failover do SQL Server.
Banco de dados de administração de pesquisa
Há apenas um banco de dados de Administração de Pesquisa por instância do aplicativo de serviço de Pesquisa em um farm.
O banco de dados de Administração de Pesquisa será redundante apenas se for espelhado ou implantado em um cluster de failover do SQL Server.
Para obter mais informações sobre a redundância de pesquisa, consulte Manage Search topology.
A redundância e o failover entre data centers em locais próximos são configurados como um único farm (farm "alongado") Algumas empresas têm data centers localizados próximos entre si, com conexões de largura de banda alta, e, dessa forma, eles podem ser configurados como um único farm. Isso é chamado de farm "alongado". Para que um farm alongado funcione, a latência deve ser menor do que 1 milissegundo entre o SQL Server e os servidores Web front-end em uma única direção e a largura de banda deve ser de pelo menos 1 gigabit por segundo.
291
Nesse cenário, você pode fornecer tolerância a falhas. Siga as diretrizes padrão para criar redundância de bancos de dados e aplicativos de serviço.
A ilustração a seguir mostra um farm alongado.
Farm alongado
292
293
Planejar a recuperação de desastre (SharePoint Server 2010)
Este artigo descreve decisões importantes para a escolha de estratégias de recuperação de desastre para um ambiente do Microsoft SharePoint Server 2010.
Neste artigo:
Visão geral da recuperação de desastre
Escolha uma estratégia de recuperação de desastre
Planejamento de data centers em espera a frio
Planejamento de data centers em espera passiva
Planejamento de data centers em espera ativa
Requisitos do sistema para recuperação de desastre
Visão geral da recuperação de desastre Para os fins deste artigo, definimos a recuperação de desastre como a capacidade de se recuperar de uma situação em que um data center que hospeda o SharePoint Server se torna indisponível.
A estratégia de recuperação de desastre que você usa para o SharePoint Server deve ser coordenada com a estratégia de recuperação de desastre para a infraestrutura relacionada, incluindo domínios do Active Directory, Exchange Server e Microsoft SQL Server. Trabalhe com os administradores da infraestrutura de que você necessita a fim de projetar um plano e uma estratégia de recuperação de desastre coordenados.
O tempo e o esforço imediato para colocar outro farm em funcionamento em um local diferente muitas vezes são chamados de espera ativa, passiva ou a frio. Nossas definições para esses termos são:
Espera ativa Um segundo data center que pode fornecer disponibilidade em segundos ou minutos.
Espera passiva Um segundo data center que pode fornecer disponibilidade em minutos ou horas.
Espera a frio Um segundo data center que pode fornecer disponibilidade em horas ou dias.
A recuperação de desastre pode ser um dos requisitos mais caros de um sistema. Quanto menor for o intervalo entre a falha e a disponibilidade e quanto mais sistemas você proteger, mais complexa e dispendiosa provavelmente será a solução de recuperação de desastre. Quando você investe em data centers em espera ativa ou passiva, os custos incluem:
Hardware e software adicionais, que frequentemente aumentam a complexidade das
operações entre aplicativos de software, como scripts personalizados para failover e
recuperação.
Complexidade operacional adicional.
294
Os custos de manutenção de data centers em espera ativa ou passiva devem ser avaliados com base nas necessidades comerciais. Nem todas as soluções em uma organização exigem o mesmo nível de disponibilidade após um desastre. Você pode oferecer níveis diferentes de recuperação de desastre para diferentes tipos de conteúdo, serviços ou farms — por exemplo, conteúdo com alto impacto em relação aos negócios, serviços de pesquisa ou um farm de publicação na Interne
A recuperação de desastre é uma área crucial em que grupos de tecnologia da informação (TI) oferecem contratos de nível de serviço para definir as expectativas com grupos de clientes. Muitas organizações de TI oferecem vários contratos de nível de serviço associados a níveis de cobrança diferentes.
Ao implementar o failover entre farms de servidores, é recomendável que primeiro você implante e ajuste a solução principal em um farm e, em seguida, implemente e teste a recuperação de desastre.
Escolha uma estratégia de recuperação de desastre Você pode escolher entre diversas abordagens para fornecer recuperação de desastre para um ambiente do SharePoint Server, dependendo de suas necessidades comerciais. Os exemplos a seguir mostram os motivos pelos quais as empresas podem escolher estratégias de recuperação de desastre em espera a frio, passiva ou ativa.
Estratégia de recuperação de desastre em espera a frio: uma empresa envia
backups para dar suporte à recuperação bare-metal de armazenamento externo
local e regional regularmente e tem contratos em vigor para aluguel de servidores de
emergência em outra região.
Prós:
Frequentemente, essa é a opção com manutenção mais barata em termos
operacionais.
Muitas vezes, é uma opção cara em termos de recuperação, pois exige que
servidores físicos sejam configurados corretamente após um desastre.
Contras: essa é a opção com recuperação mais lenta.
Estratégia de recuperação de desastre em espera passiva: uma empresa envia
imagens de servidores virtuais a farms de recuperação de desastre locais e
regionais.
Prós: frequentemente, essa opção tem custo relativamente baixo em termos de recuperação, pois um farm de servidores virtual pode exigir pouca configuração após a recuperação.
Contras: pode ser muito dispendioso e demorado manter essa opção.
Estratégia de recuperação de desastre em espera ativa: uma empresa executa
vários data centers, mas fornece conteúdo e serviços por meio de apenas um deles.
Prós: essa opção costuma ter recuperação relativamente rápida.
Contras: a configuração e a manutenção podem ser bastante dispendiosas.
295
Importante:
Seja qual for a solução de recuperação de desastre que você decidir implementar para
seu ambiente, provavelmente ocorrerá alguma perda de dados.
Planejamento de data centers em espera a frio Em um cenário de recuperação de desastre em espera a frio, você pode executar a recuperação configurando um novo farm em um novo local (de preferência, usando uma implantação controlada por script) e restaurando backups. Ou então, é possível executar a recuperação restaurando um farm por meio de uma solução de backup, como o Microsoft System Center Data Protection Manager 2007, que protege seus dados no nível do computador e permite restaurar cada servidor individualmente. Este artigo não contém instruções detalhadas sobre criação e recuperação em cenários em espera a frio. Para obter mais informações, consulte:
Restore a farm (SharePoint Server 2010)
Restore customizations (SharePoint Server 2010)
Planejamento de data centers em espera passiva Em um cenário de recuperação de desastre em espera passiva, para criar uma solução em espera passiva, crie de maneira consistente e frequente imagens virtuais dos servidores no farm, as quais você enviará a um local secundário. Nesse local, deve haver um ambiente disponível em que você possa facilmente configurar e conectar as imagens para recriar o ambiente de farm.
Este artigo não contém instruções detalhadas sobre criação de soluções em espera passiva. Para obter mais informações sobre como planejar a implantação de farms usando soluções virtuais, consulte Planejar a virtualização (SharePoint Server 2010).
Planejamento de data centers em espera ativa Em um cenário de recuperação de desastre em espera ativa, você pode configurar um farm de failover para fornecer recuperação de desastre em um data center separado do farm principal. Um ambiente com um farm de failover separado tem as seguintes características:
Um banco de dados de configuração separado e um banco de dados de conteúdo
da Administração Central devem ser mantidos no farm de failover.
Todas as personalizações devem ser implantadas nos dois farms.
296
Observação:
É aconselhável usar a implantação com script para criar o farm principal e de failover
usando as mesmas configurações e personalizações. Para obter mais informações,
consulte Install SharePoint Server 2010 by using Windows PowerShell.
As atualizações devem ser aplicadas aos dois farms, separadamente.
Os bancos de dados de conteúdo do SharePoint Server podem ser espelhados de
forma assíncrona ou enviados com logs para o farm de failover.
Observação:
O espelhamento do SQL Server só pode ser usado para copiar bancos de dados para
um único servidor espelho, mas você pode enviar logs para vários servidores
secundários.
Os aplicativos de serviço podem ou não ser enviados com logs a um farm. Para
obter mais informações, consulte Redundância de aplicativos de serviço em data
centers mais adiante neste artigo.
Esta topologia poderá ser repetida em vários data centers se você configurar o envio de logs do SQL Server para um ou mais data centers adicionais.
Consulte o fornecedor da SAN para determinar se você pode usar a replicação de SAN em outro mecanismo para o qual haja suporte, para fornecer disponibilidade entre data centers.
A ilustração a seguir mostra farms principais e de failover antes do failover.
Fams principal e de failover antes do failover
297
Redundância de aplicativos de serviço entre data centers
298
Para oferecer disponibilidade a aplicativos de serviço entre data centers, é recomendável que, para os serviços que podem ser executados entre farms, você execute um farm de serviços separado, que possa ser acessado por meio dos data centers principal e secundário.
Para serviços que não podem ser executados entre farms, e para oferecer disponibilidade ao próprio farm de serviços, a estratégia de fornecimento de redundância entre data centers a um aplicativo de serviço pode variar. A estratégia a ser adotada depende dos seguintes fatores:
Há valor comercial na execução do aplicativo de serviço no farm de recuperação de
desastre quando ele não está em uso.
Os bancos de dados associados ao aplicativo de serviço podem ser enviados com
logs ou espelhados de forma assíncrona.
O aplicativo de serviço pode ser executado com bancos de dados somente leitura.
As seções a seguir descrevem as estratégias de recuperação de desastre recomendadas para cada aplicativo de serviço. Os aplicativos de serviço são agrupados por estratégia.
Bancos de dados que podem ser enviados com logs ou espelhados de forma assíncrona
Depois que um aplicativo de serviço é inicialmente implantado em um farm secundário, os bancos de dados que dão suporte aos aplicativos de serviço a seguir podem ser espelhados de forma assíncrona ou enviados com logs entre farms:
Aplicativo de serviço de Registro de Aplicativo
Bancos de dados: serviço de Registro de Aplicativo
Aplicativo de serviço Conectividade de Dados Corporativos
Bancos de dados: Conectividade de Dados Corporativos
Aplicativo de serviço de Metadados Gerenciados
Bancos de dados: serviços de Metadados Gerenciados
Observação:
Se a marcação estiver em uso, para utilizar com êxito o aplicativo de serviço de
Metadados Gerenciados no farm de recuperação de desastre, você deverá também
enviar com logs ou espelhar o banco de dados de Marcação para o aplicativo de serviço
de Perfil de Usuário.
Serviços PerformancePoint
Bancos de dados: aplicativo de Serviço do PerformancePoint
Aplicativo de serviço do Project Server
Bancos de dados: Rascunho, Publicado, Arquivo Morto, Relatório
O Project Server 2010 exige sincronização entre seus bancos de dados. É possível replicar o Project Server entre farms usando um mecanismo de replicação assíncrona (espelhamento de banco de dados assíncrono, envio de logs ou replicação de SAN assíncrona). Porém, para recuperação, verifique se os logs do banco de dados do Project são sincronizados à medida que você restaura.
299
Observação:
Apesar da recomendação de enviar com logs ou espelhar os bancos de dados do Project
Server para o farm de recuperação de desastre, não é possível executar o aplicativo de
serviço do Project Server em bancos de dados somente leitura. Portanto, não é
aconselhável executar o aplicativo de serviço do Project Server no farm de recuperação
de desastre antes do failover. Para sincronizar com êxito os bancos de dados do Project
Server no farm de recuperação de desastre, configure carimbos de data/hora ou
marcação de log nos bancos de dados.
Aplicativo de serviço de Repositório Seguro
Bancos de dados: Repositório Seguro
Aplicativo de serviço de Coleta de Dados de Uso e Integridade
Bancos de dados: registro em log
Observação:
É possível enviar com logs ou espelhar o banco de dados de registro em log. No entanto,
é recomendável não executar o serviço Coleta de Dados de Uso e Integridade no farm de
recuperação de desastre e não espelhar nem enviar com logs o banco de dados de
registro em log.
Aplicativo de serviço de Perfil de Usuário
Bancos de dados: Perfil, Sincronização, Marcação Social
É possível enviar com logs o banco de dados de Marcação Social do serviço de Perfil de Usuário. Não é possível enviar com logs os bancos de dados de Perfil e Sincronização.
Para fornecer redundância ao aplicativo de serviço de Perfil de Usuário, primeiro implante o aplicativo de serviço nos data centers principal e secundário.
Para o banco de dados de Marcação Social, configure o envio de logs.
Para configurar os bancos de dados de Perfil e Sincronização, é aconselhável recuperar um backup dos bancos de dados no data center secundário e anexá-lo ao aplicativo de serviço de Perfil de Usuário nesse data center.
Para manter os perfis sincronizados, execute o Mecanismo de Replicação de Perfil de Usuário incluído no SharePoint Administration Toolkit após a atualização dos dados do perfil no farm principal. Para obter mais informações, consulte User Profile Replication Engine Overview (SharePoint Server 2010).
Aplicativo de serviço do Web Analytics
Bancos de dados: Preparo, Relatório
Observação:
É aconselhável enviar com logs ou espelhar os bancos de dados de Preparo e Relatório
do Web Analytics. No entanto, não é aconselhável executar o aplicativo de serviço do
Web Analytics no farm de recuperação de desastre antes do failover.
Aplicativos de serviço e bancos de dados que não podem ser enviados com logs nem espelhados de forma assíncrona
300
Os aplicativos de serviço a seguir devem ser implantados nos farms principal e de failover e não podem ser enviados com logs nem espelhados de forma assíncrona. Para a maioria desses aplicativos de serviço, é recomendável implantá-los e verificar se o farm de failover tem as mesmas definições de configuração que o farm principal. Se alterações de configuração que afetam o serviço forem feitas no farm principal, você deverá atualizar o farm de failover.
Aplicativo de serviço de Configurações de Inscrição do Microsoft SharePoint
Foundation
Banco de dados: Inscrição
Observação:
Não há suporte para o envio de logs do banco de dados de Configurações de Inscrição.
Serviços do Access
Bancos de Dados: nenhum
Serviços do Excel
Bancos de Dados: nenhum
Pesquisa
Bancos de dados: Rastreamento, Propriedade, Administração da Pesquisa
A pesquisa requer total sincronização entre seus bancos de dados e o índice. Por causa desse requisito, não é possível replicar a pesquisa entre farms usando um mecanismo de replicação assíncrona (espelhamento de banco de dados assíncrono, envio de logs ou replicação de SAN assíncrona).
Para realizar uma pesquisa atualizada em um farm de failover, execute a pesquisa no farm secundário.
Importante:
O aplicativo de serviço de Pesquisa no farm de failover deve ser definido para rastrear
ativamente o farm secundário. No failover, configure a associação a aplicativos Web para
usar o aplicativo de serviço de Pesquisa de failover.
Serviço de Controle de Sessão
Bancos de dados: Controle de Sessão
Observação:
Não há suporte para o envio do banco de dados de Controle de Sessão com logs.
Serviços do Visio
Bancos de Dados: nenhum
Word Automation Services
Bancos de dados: Word Automation Services
Não há suporte para o envio do banco de dados do Word Automation Services com logs.
301
Requisitos do sistema para recuperação de desastre Em um cenário ideal, os sistemas e componentes de failover correspondem aos sistemas e componentes principais de todas as maneiras: plataforma, hardware e número de servidores. No mínimo, o ambiente de failover deve ser capaz de lidar com o tráfego esperado durante um failover. Tenha em mente que somente um subconjunto de usuários pode ser atendido pelo site de failover. Os sistemas devem ser correspondentes pelo menos nos seguintes itens:
Versão e todas as atualizações do sistema operacional
Versões e todas as atualizações do SQL Server
Versões e todas as atualizações dos Produtos do SharePoint 2010
Embora este artigo aborde principalmente a disponibilidade de Produtos do SharePoint 2010, a duração da operação do sistema também será afetada pelos outros componentes no sistema. Particularmente, faça o seguinte:
Garanta que as dependências de infraestrutura, como energia, resfriamento, rede,
diretório e SMTP, sejam totalmente redundantes.
Escolha um mecanismo de comutação (DNS ou balanceamento de carga de
hardware) que atenda às suas necessidades.
302
Implantação global de vários farms (SharePoint Server 2010)
Esta seção contém recursos para ajudá-lo a projetar arquiteturas que se estendem por localizações geográficas.
Nesta seção:
Soluções globais para Produtos do SharePoint 2010 (modelo)
Soluções de cliente para ambientes WAN (SharePoint Server 2010)
303
Soluções globais para Produtos do SharePoint 2010 (modelo)
Este modelo ilustra as arquiteturas com suporte para implantação dos Produtos do Microsoft SharePoint 2010 geograficamente.
Soluções globais para os produtos do SharePoint 2010
Visio (http://go.microsoft.com/fwlink/?linkid=206424&clcid=0x416)
PDF (http://go.microsoft.com/fwlink/?linkid=206429&clcid=0x416)
XPS (http://go.microsoft.com/fwlink/?linkid=206432&clcid=0x416)
304
Soluções de cliente para ambientes WAN (SharePoint Server 2010)
Muitas organizações incluem usuários que são distribuídos em links WAN e usuários que nem sempre estão conectados à rede. Os Produtos do Microsoft SharePoint 2010 acomodam vários cenários de rede e ambientes de trabalho. Este artigo descreve as soluções clientes que podem ser usadas em conexões de rede lentas ou quando os usuários estão offline.
Neste artigo:
Modos de exibição móveis
Office Web Apps
Cache de documentos do Office 2010 e o protocolo MS-FSSHTTP
Outlook 2010
SharePoint Workspace
SharePoint Workspace Mobile para Windows Phone 7
SharePoint Workspace com Groove Server
As tabelas a seguir comparam as soluções indicando as circunstâncias em que uma solução funciona melhor e o escopo de acesso fornecido pela solução para sites do SharePoint. O restante do artigo descreve as soluções em mais detalhes.
305
Modos de exibição móveis Os modos de exibição móveis não são apenas dispositivos móveis. Em ambientes de largura de banda baixa ou de latência alta — como latências de 300 milissegundos ou mais — os modos de exibição móveis podem fornecer desempenho aceitável quando são usados para navegar em uma hierarquia de sites, preencher formulários simples e exibir dados de texto.
Para exibir um modo de exibição móvel em um navegador não móvel, acrescente ?mobile=1 à URL de qualquer site do SharePoint.
Por padrão, os modos de exibição móveis são habilitados para a maioria das listas e bibliotecas que usam modelos padrão. Por padrão, os modos de exibição móveis não são habilitados para listas ou bibliotecas personalizadas ou para listas/bibliotecas criadas em versões anteriores do produto atualizado para o Microsoft SharePoint Foundation 2010. Os modos de exibição móveis não estão disponíveis para os tipos de exibição Folha de Dados e Gantt.
Para configurar modos de exibição móveis para listas e bibliotecas, consulte Configure mobile views (SharePoint Server 2010).
Office Web Apps O Microsoft Office Web Apps são complementos online para o Microsoft Word, o Microsoft Excel, o Microsoft PowerPoint e o Microsoft OneNote, os quais habilitam as pessoas a acessar arquivos e fazer edições leves em um navegador sem baixar ou carregar arquivos por conexões de largura de banda baixa ou latência alta.
306
Quando o Office Web Apps está habilitado para um conjunto de sites, você pode escolher entre exibir e editar arquivos em um navegador, conforme mostrado na ilustração a seguir.
Na maior parte das vezes, a abertura de arquivos em um navegador resulta em um tempo mais rápido para visualização da primeira página do que a abertura de arquivos em um dos aplicativos clientes do Microsoft Office 2010.
Além disso, os usuários da organização podem usar telefones celulares e dispositivos móveis habilitados para navegador para ler documentos do Word, do Excel e do PowerPoint armazenados em um computador com o SharePoint Server, caso os modos de exibição e o conteúdo habilitados para acesso móvel estejam publicados sem firewall. Os seguintes dispositivos oferecem suporte móvel para o Office Web Apps:
Windows Phone 7
Windows Mobile
BlackBerry
iPhone, iPod Touch
Nokia S60
Telefones com recursos em japonês, incluindo NTT DOCOMO, SoftBank e au by
KDDI
307
O Microsoft Silverlight pode melhorar a experiência do usuário do Office Web Apps. O Silverlight é um plug-in gratuito capaz de fornecer experiências avançadas na Web para muitos navegadores. O plug-in Silverlight não precisa ser instalado no navegador cliente para que seja possível usar o Office Web Apps. Entretanto, a instalação do plug-in Silverlight no navegador pode oferecer os seguintes benefícios:
Quando os usuários utilizam o Word Web App em navegadores que têm o plug-in
Silverlight instalado, eles podem agilizar o carregamento de página, melhorar a
fidelidade de texto em zoom total, obter suporte para configurações do otimizador
Microsoft ClearType e aumentar a precisão em locais de instâncias de cadeia de
caracteres de pesquisa quando utilizarem o recurso Localizar nesse comando de
Página.
Quando os usuários utilizam o PowerPoint Web App em navegadores que têm o
plug-in Silverlight instalado, eles agilizam o carregamento de página, as animações
são exibidas com mais perfeição e a apresentação de slides é ampliada para o
tamanho da janela do navegador.
Não há benefícios adicionais noExcel Web App e no OneNote Web App quando o Silverlight é instalado no navegador cliente.
Para obter mais informações sobre o Silverlight, consulte Microsoft Silverlight (http://go.microsoft.com/fwlink/?linkid=206068&clcid=0x416).
Para obter mais informações sobre o Office Web Apps, consulte Implantação do Microsoft Office Web Apps (http://go.microsoft.com/fwlink/?linkid=206018&clcid=0x416).
Cache de documentos do Office 2010 e o protocolo MS-FSSHTTP O Office 2010 combinado aos Produtos do SharePoint 2010 melhoram a experiência dos usuários que utilizam e gerenciam arquivos em conexões de rede lentas. Os arquivos abertos em sites do SharePoint 2010 são baixados por meio de transferência assíncrona de arquivo e armazenados localmente no cache. Como resultado, os arquivos são abertos com mais rapidez e os usuários podem começar a usá-los antes da conclusão do download. Além disso, somente as alterações feitas nos arquivos — e não os arquivos inteiros — são transmitidas entre os Produtos do SharePoint 2010 e os computadores clientes. Esses recursos são possibilitados pela nova Sincronização de Arquivos via SOAP, pelo protocolo HTTP (MS-FSSHTTP).
As configurações e os recursos do Cache de Documentos podem ser acessados e gerenciados por meio do Centro de Carregamento, um novo recurso do Office 2010 que é automaticamente instalado. Os usuários podem acessar o Centro de Carregamento clicando no respectivo ícone localizado na área de notificação ou abrindo-o pelo menu Iniciar.
308
O Centro de Carregamento lista todos os arquivos armazenados em cache. As versões em cache dos arquivos podem ser colocadas offline e gerenciadas por meio do Centro de Carregamento. Os usuários podem monitorar o status dos arquivos que estão sendo carregados. Como mostrado na ilustração a seguir, os usuários também podem gerenciar as configurações de cache para determinar por quanto tempo os arquivos ficarão retidos no cache e para excluir todos os arquivos armazenados em cache, se necessário.
309
Os usuários não precisam acessar e gerenciar o Centro de Carregamento para obter as vantagens dos recursos de armazenamento em cache do Office 2010. A funcionalidade do Office 2010 ocorre em segundo plano, inclusive sem intervenção do usuário.
Observação:
Quando os usuários trabalham com versões anteriores do Office, como o Office 2007, o
BranchCache pode ser usado para reduzir a utilização de largura de banda e os tempos
de download do conteúdo acessado com frequência. O BranchCache, quando habilitado
no servidor e em computadores clientes, reduz consideravelmente o tempo de abertura
de arquivos armazenados em cache. Entretanto, o BranchCache não reduz a quantidade
de largura de banda de rede utilizada ao salvar um arquivo no site do SharePoint. O
BranchCache não pode ser usado em combinação com o Cache de Documentos e o
protocolo MS-FSSHTTP. Se os dois recursos BranchCache e Cache de Documentos
forem implementados, a comunicação será feita por meio do protocolo MS-FSSHTTP. O
uso do SharePoint Server 2010 em combinação com o Office 2010 resulta em um
desempenho geral significativamente melhor da WAN.
Para obter mais informações sobre como usar o BranchCache, consulte Visão geral do BranchCache no Windows 7 e no Windows Server 2008 R2 (http://go.microsoft.com/fwlink/?linkid=206069&clcid=0x416).
Para obter mais informações sobre as configurações do Centro de Carregamento e do Cache de Documentos do Office, consulte os seguintes artigos:
Centro de Carregamento do Microsoft Office 2010
(http://go.microsoft.com/fwlink/?linkid=206070&clcid=0x416)
Configurações do Cache de Documentos do Office
(http://go.microsoft.com/fwlink/?linkid=206071&clcid=0x416)
Outlook 2010 Os usuários podem sincronizar uma biblioteca do SharePoint, lista de contatos, lista de tarefas, lista de tarefas de projeto e um determinado tipo de lista externa do SharePoint
310
com o Outlook 2010. Como muitos usuários dos Produtos do SharePoint 2010 também usam o Outlook 2010 para colaborar e coordenar atividades e projetos, a capacidade de sincronizar essas bibliotecas e listas pode ajudar os usuários a serem mais eficientes, principalmente quando trabalharem offline ou quando não for conveniente acessar sites do SharePoint.
Assim como em outros aplicativos do Office 2010, os arquivos do SharePoint sincronizados com o Outlook 2010 são baixados, carregados e armazenados em cache por meio do protocolo MS-FSSHTTP. O resultado é um desempenho em conexões de rede lentas melhor do que o desempenho obtido em versões anteriores.
Para sincronizar uma biblioteca do SharePoint com o Outlook 2010, na guia Biblioteca, no grupo Conectar e Exportar, clique em Conectar com o Outlook, como mostrado na ilustração a seguir.
Quando os usuários trabalham offline, as alterações feitas em arquivos são salvas localmente. Ao entrarem novamente em modo online, os usuários podem carregar as alterações na biblioteca do SharePoint, quando o aplicativo cliente fizer a primeira sincronização, ou manter os arquivos alterados localmente.
Considere os seguintes aspectos ao planejar o uso do Outlook 2010 em um ambiente WAN:
O Outlook 2010 não oferece sincronização ponto a ponto de conteúdo em sites do
SharePoint. O Outlook 2010 dispõe de uma experiência offline pessoal para
membros individuais da equipe.
Por padrão, o check-out dos arquivos sincronizados não é automático. Não é
possível fazer check-out de um arquivo no Outlook 2010. A prática recomendada é
fazer o check-out de arquivos nos Produtos do SharePoint 2010 antes de sincronizar
e editar o conteúdo no Outlook 2010.
Para obter mais informações, consulte o artigo sobre sincronização de conteúdo do SharePoint 2010 com o Outlook 2010 (http://go.microsoft.com/fwlink/?linkid=206097&clcid=0x416).
311
SharePoint Workspace O Microsoft SharePoint Workspace 2010, anteriormente Microsoft Office Groove, é um aplicativo cliente do Microsoft SharePoint Server 2010 e do Microsoft SharePoint Foundation 2010 que oferece suporte à colaboração online e offline.
O SharePoint Workspace 2010 foi criado com base na versão anterior e adiciona novas ferramentas avançadas, permitindo que os usuários acessem e compartilhem conteúdo armazenado em sites do SharePoint, mesmo quando os usuários não estão conectados a redes corporativas. O SharePoint Workspace 2010 está incluído no Microsoft Office Professional Plus 2010 e oferece a experiência offline mais robusta para sites do SharePoint, possibilitando que os usuários coloquem offline sites inteiros do SharePoint.
A ilustração a seguir demonstra como sincronizar um site com o SharePoint Workspace 2010.
Para obter mais informações, consulte Novidades no SharePoint Workspace 2010 (http://go.microsoft.com/fwlink/?linkid=206098&clcid=0x416).
312
SharePoint Workspace Mobile para Windows Phone 7 O Windows Phone 7 inclui o Microsoft Office Mobile, que permite aos usuários trabalhar com arquivos em seus telefones. O Microsoft SharePoint Workspace Mobile faz parte do Office Mobile e já está no telefone no Office Hub, conforme mostrado na ilustração a seguir.
Os usuários móveis podem usar o Windows Phone 7 e o Microsoft SharePoint Workspace Mobile para fazer o seguinte:
Exibir conteúdo hospedado em um site do SharePoint 2010.
Abrir e editar arquivos do Word, Excel, PowerPoint e OneNote, hospedados em um
site do SharePoint 2010.
Navegar em sites, listas e bibliotecas de documentos do SharePoint 2010.
Aumentar a segurança de acesso remoto a recursos corporativos por meio do
Microsoft Forefront Unified Access Gateway (UAG), se a empresa utilizá-lo.
313
Os usuários também podem utilizar o Microsoft SharePoint Workspace Mobile para colocar arquivos do SharePoint 2010 offline no telefone. Os usuários podem abrir e editar os arquivos e depois salvá-los no site do SharePoint, quando voltarem ao modo online.
Para obter mais informações, consulte Office Mobile 2010 para Windows Phone 7 (http://go.microsoft.com/fwlink/?linkid=206099&clcid=0x416).
SharePoint Workspace com Groove Server O SharePoint Workspace 2010 também pode ser usado juntamente com o Microsoft Groove Server para oferecer colaboração ponto a ponto, sem exigir que todos os membros da equipe estejam conectados aos Produtos do SharePoint 2010. A colaboração pode ser estendida externamente à rede privada para parceiros e sites de campo confiáveis. Com essa configuração, pelo menos um membro da equipe deve ter acesso aos sites do SharePoint. Outros membros da equipe devem ter acesso ao computador do membro da equipe com acesso aos sites do SharePoint ou devem acessar diretamente os sites do SharePoint. A ilustração a seguir mostra um exemplo dessa arquitetura.
Para obter mais informações sobre o SharePoint Workspace e o Groove Server, consulte Plan for SharePoint Workspace 2010.
314
Planilhas de planejamento para o SharePoint Server 2010
Neste artigo:
Planilhas de planejamento por tarefa
Planilhas de planejamento por título
Esse artigo fornece links para planilhas que podem ser usadas para registrar informações coletadas e decisões tomadas enquanto você planeja a implantação do Microsoft SharePoint Server 2010. Use essas planilhas em conjunto com Planning and architecture for Office SharePoint Server 2007, não como um substituto para ele.
Planilhas de planejamento por tarefa
Para esta tarefa
Use esta planilha Para fazer isso
Plan sites and site collections (SharePoint Server 2010)
Planilha de dados de planejamento de sites (http://go.microsoft.com/fwlink/?linkid=167837&clcid=0x416)
Planejar sites e conjuntos de
sites de nível
superior, e registrar
decisões
referentes a temas de sites
e navegação.
Plan site navigation (SharePoint Server 2010)
Planilha de dados de planejamento de sites (http://go.microsoft.com/fwlink/?linkid=167837&clcid=0x416)
Planejar sites e conjuntos de
sites de nível
superior, e registrar
decisões
referentes a temas de sites
e navegação.
Plan for using themes (SharePoint Server 2010)
Planilha de dados de planejamento de sites (http://go.microsoft.com/fwlink/?linkid=167837&clcid=0x416)
Planejar sites e conjuntos de
sites de nível
superior, e registrar
decisões
referentes a
315
Para esta tarefa
Use esta planilha Para fazer isso
temas de sites
e navegação.
Plan incoming e-mail (SharePoint Server 2010)
Planejar a planilha de emails de entrada (http://go.microsoft.com/fwlink/?linkid=200542&clcid=0x416)
Planejar emails de entrada para permitir que sites do SharePoint recebam e armazenem mensagens de email e anexos em listas e bibliotecas.
Plan content deployment (SharePoint Server 2010)
Planilha de dados de implantação de conteúdo
(http://go.microsoft.com/fwlink/?linkid=167835&clcid=0x416)
Planeje a
exportação e a
importação de
servidores nos farms da sua topologia de
implantação de
conteúdo e
planeje os caminhos e os trabalhos de
implantação de
conteúdo.
Managed metadata planning
Planilha de planejamento de conjuntos de termos(http://go.microsoft.com/fwlink/?linkid=163486&clcid=0x416)
Determine a taxonomia
básica,
incluindo termo, uso,
proprietário e
grupo.
Plan managed metadata (SharePoint Server 2010)
Planilha de planejamento de conjunto de termos detalhados(http://go.microsoft.com/fwlink/?linkid=163487&clcid=0x416)
Determine a taxonomia, incluindo
características
de identificação
detalhadas, como medidas.
Plan managed metadata
Planilha de planejamento de serviços de metadados
gerenciados(http://go.microsoft.com/fwlink/?linkid=164578&clcid=0x416)
Planeje o compartilhamento de
316
Para esta tarefa
Use esta planilha Para fazer isso
(SharePoint Server 2010)
informações de
metadados usando
serviços de
metadados gerenciados e
conexões.
Document management planning (SharePoint Server 2010)
Planilha de participantes do gerenciamento de documentos (http://go.microsoft.com/fwlink/?linkid=165871&clcid=0x416)
Identifique participantes do planejamento de gerenciamento de documentos e registre
práticas de
gerenciamento de documentos.
Document management planning (SharePoint Server 2010)
Planilha de análise de uso do documento
(http://go.microsoft.com/fwlink/?linkid=165873&clcid=0x416)
Registre informações
coletadas ao analisar o uso de documentos.
Document management planning (SharePoint Server 2010)
Planilha de políticas
(http://go.microsoft.com/fwlink/?linkid=165883&clcid=0x416)
Planeje
políticas de
gerenciamento
de informações
para tipos de
conteúdo.
Records management planning (SharePoint Server 2010)
Planilha de planejamento de registros in-loco(http://go.microsoft.com/fwlink/?linkid=185011&clcid=0x416)
Identifique os tipos de registro e de
conteúdo a
serem armazenados em bibliotecas de documentos normais.
Planejar o backup e a
Pasta de trabalho de planejamento do backup e da
recuperação
Ajudar no planejamento
317
Para esta tarefa
Use esta planilha Para fazer isso
recuperação (SharePoint Server 2010)
(http://go.microsoft.com/fwlink/?linkid=184385&clcid=0x416) das estratégias
de backup e
recuperação do
ambiente do SharePoint Server 2010.
Plan document management
Plan document management Planeje um tipo de conteúdo.
Plan and prepare for upgrade (SharePoint Server 2010)
Planilha de atualização
(http://go.microsoft.com/fwlink/?linkid=179928&clcid=0x416)
Registrar informações
sobre o ambiente ao se preparar para a atualização.
Plan Content Organizer settings (SharePoint Server 2010)
Planilha de configurações do Organizador de Conteúdo
(http://go.microsoft.com/fwlink/?linkid=189018&clcid=0x416)
Determine e registre como as
configurações
do organizador
de conteúdo
no seu site podem ser uma parte efetiva de uma
solução de
armazenamento e roteamento
de conteúdo
baseada em metadados.
Plan Content Organizer rules (SharePoint Server 2010)
Planilha de regras do Organizador de Conteúdo
(http://go.microsoft.com/fwlink/?linkid=189019&clcid=0x416)
Planeje regras
que serão uma
parte efetiva
de sua solução
de armazenamento e roteamento baseada em metadados.
318
Planilhas de planejamento por título
Use esta planilha Para esta tarefa
Para fazer isso
Planilha de análise de uso do documento
(http://go.microsoft.com/fwlink/?linkid=165873&clcid=0x416)
Plan document management
Registre
informações
coletadas ao analisar o uso de documentos.
Pasta de trabalho de planejamento do backup e da
recuperação
(http://go.microsoft.com/fwlink/?linkid=184385&clcid=0x416)
Planejar o backup e a recuperação (SharePoint Server 2010)
Ajudar no planejamento das estratégias
de backup e
recuperação do
ambiente do SharePoint Server 2010.
Planilha de dados de implantação de conteúdo
(http://go.microsoft.com/fwlink/?linkid=167835&clcid=0x416)
Plan content deployment (SharePoint Server 2010)
Planeje a
exportação e a
importação de
servidores nos farms da sua topologia de implantação de
conteúdo e
planeje os caminhos e os trabalhos de implantação de
conteúdo.
Planilha de regras do Organizador de Conteúdo
(http://go.microsoft.com/fwlink/?linkid=189019&clcid=0x416)
Metadata-based routing and storage planning (SharePoint Server 2010)
Planeje regras
que serão uma
parte efetiva
de sua solução
de armazenamento e roteamento baseada em metadados.
Planilha de configurações do Organizador de Conteúdo
(http://go.microsoft.com/fwlink/?linkid=167835&clcid=0x416)
Metadata-based routing and storage planning
Determine e registre como as
configurações
do organizador
319
Use esta planilha Para esta tarefa
Para fazer isso
(SharePoint Server 2010)
de conteúdo
no seu site podem ser uma parte efetiva de uma
solução de
armazenamento e roteamento
de conteúdo
baseada em metadados.
Planilha de tipo de Conteúdo
(http://go.microsoft.com/fwlink/?linkid=165878&clcid=0x416)
Plan document management
Planeje um tipo de conteúdo.
Planilha de planejamento de conjunto de termos detalhados(http://go.microsoft.com/fwlink/?linkid=163487&clcid=0x416)
Managed metadata planning
Determine a taxonomia, incluindo
características
de identificação
detalhadas, como medidas.
Planilha de bibliotecas de documentos (http://go.microsoft.com/fwlink/?linkid=165874&clcid=0x416)
Plan document management
Planeje bibliotecas com base em sites e em tipos de documentos.
Planilha de participantes do gerenciamento de documentos (http://go.microsoft.com/fwlink/?linkid=165871&clcid=0x416)
Plan document management
Identifique participantes do planejamento de gerenciamento de documentos e registre
práticas de
gerenciamento de documentos.
Planilha de planejamento de registros in-loco(http://go.microsoft.com/fwlink/?linkid=185011&clcid=0x416)
Plan records manageme
Identifique os tipos de registro e de
320
Use esta planilha Para esta tarefa
Para fazer isso
nt conteúdo a
serem armazenados em bibliotecas de documentos normais.
Planilha de planejamento de serviços de metadados
gerenciados(http://go.microsoft.com/fwlink/?linkid=164578&clcid=0x416)
Managed metadata planning
Planeje o compartilhamento de
informações de
metadados usando
serviços de
metadados gerenciados e
conexões.
Planejar a planilha de emails de entrada (http://go.microsoft.com/fwlink/?linkid=200542&clcid=0x416)
Plan incoming e-mail (SharePoint Server 2010)
Planeje emails de entrada para permitir que sites do SharePoint recebam e armazenem mensagens de email e anexos em listas e bibliotecas.
Planilha de políticas
(http://go.microsoft.com/fwlink/?linkid=165883&clcid=0x416)
Plan document management
Planeje
políticas de
gerenciamento
de informações
para tipos de
conteúdo.
Planilha de dados de planejamento de sites (http://go.microsoft.com/fwlink/?linkid=167837&clcid=0x416)
Plan sites and site collections (SharePoint Server 2010)
Plan site navigation (SharePoint Server
Planejar sites e conjuntos de sites de nível
superior, e registrar
decisões
referentes a temas de sites
e navegação.
321
Use esta planilha Para esta tarefa
Para fazer isso
2010)
Plan for using themes (SharePoint Server 2010)
Planilha de planejamento de conjuntos de termos(http://go.microsoft.com/fwlink/?linkid=163486&clcid=0x416)
Managed metadata planning
Determine a taxonomia básica,
incluindo termo, uso,
proprietário e
grupo.
Planilha de atualização
(http://go.microsoft.com/fwlink/?linkid=179928&clcid=0x416)
Plan and prepare for upgrade (SharePoint Server 2010)
Registrar
informações
sobre o ambiente ao se preparar para a
atualização.