Share Pt Serv Plan Platf m

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.

http://go.microsoft.com/fwlink/?linkid=208221&clcid=0x416








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


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


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


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:

[email protected]

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




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



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




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







http://technet.microsoft.com/library/2170a997-9340-42ad-8d6a-41f9b4dccdfd(Office.14).aspx





13

Título Descrição




centralizada de serviços.


Services

architecture

planning

(SharePoint

Foundation 2010)

Planejamento da

arquitetura de

serviços

(SharePoint Server

2010)

Topologias para o SharePoint Server 2010




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




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




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




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




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




que compõem um

sistema de pesquisa e demonstra as arquiteturas de pesquisa comuns.

Arquiteturas de pesquisa de design do Microsoft SharePoint Server 2010




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




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



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




http://technet.microsoft.com/library/02f10b70-d634-41ae-914e-5de337c8b408(Office.14).aspx

http://technet.microsoft.com/library/02f10b70-d634-41ae-914e-5de337c8b408(Office.14).aspx



18

Título Descrição


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




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





http://technet.microsoft.com/library/396c85d9-4b86-484e-9cc5-f6c4d725c578(Office.14).aspx

http://technet.microsoft.com/library/396c85d9-4b86-484e-9cc5-f6c4d725c578(Office.14).aspx

19

Título Descrição




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



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




http://technet.microsoft.com/library/f11e6c4f-dc2a-4d17-a2c8-9455792b4b9b(Office.14).aspx




http://technet.microsoft.com/library/4d7a8038-4b27-4bd8-a855-585db4e924a8(Office.14).aspx







http://technet.microsoft.com/library/2b5d3825-adba-4185-84f2-ef59e8110fac(Office.14).aspx

http://technet.microsoft.com/library/2b5d3825-adba-4185-84f2-ef59e8110fac(Office.14).aspx

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




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




Introdução a business intelligence no SharePoint Server

2010




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




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




http://technet.microsoft.com/library/3b81b666-cd81-42d2-85e4-d9f759377d61(Office.14).aspx



23

Título Descrição




Foundation 2010)

Planejamento da

virtualização

(SharePoint Server

2010)

Controle para o SharePoint Server 2010




Ilustra como desenvolver um plano de controle que inclua controle de TI, controle de gerenciamento de informações e controle

de gerenciamento de aplicativos.


Governance

overview

(SharePoint Server

2010)

Governance

features

(SharePoint Server

2010)







http://technet.microsoft.com/library/df399658-84ac-4ca6-aaf4-378eef361cbb(Office.14).aspx




http://technet.microsoft.com/library/39c7a362-7131-4295-a931-5741e0e4c7b4(Office.14).aspx




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)

http://technet.microsoft.com/library/8dd52916-f77d-4444-b593-1f7d6f330e5f(Office.14).aspx

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.


(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


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.

http://technet.microsoft.com/library/32d82f51-546a-42a3-ade5-54cc4dfdcb87(Office.14).aspx

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.


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

http://technet.microsoft.com/library/031b0634-bf99-4c23-8ebf-9d58b6a8e6ce(Office.14).aspx




29


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



http://support.microsoft.com/kb/300684/pt-br

http://support.microsoft.com/kb/300684/pt-br

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.

http://technet.microsoft.com/library/356d3a0b-fc26-455c-9afb-6d2ffdceef84(Office.14).aspx

http://technet.microsoft.com/library/356d3a0b-fc26-455c-9afb-6d2ffdceef84(Office.14).aspx

http://technet.microsoft.com/library/bd99c3a9-0333-4c1c-9793-a145769e48e6(Office.14).aspx

http://technet.microsoft.com/library/bd99c3a9-0333-4c1c-9793-a145769e48e6(Office.14).aspx

http://technet.microsoft.com/library/4982a861-ad5c-43e4-a49f-958afd4370aa(Office.14).aspx







31


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


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


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



SQL Server 2008 Native Client


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


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


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


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


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


Avaliação do SharePoint Server 2010 Enterprise


Pacotes de Idiomas de Servidores 2010 para SharePoint Server 2010, Project

Server 2010, Search Server 2010 e Office Web Apps 2010


Windows Server 2008 R2 and SharePoint Server 2010: Better Together (white

paper)

O melhor da produtividade corporativa: Microsoft Office e Microsoft SharePoint

(white paper)




http://technet.microsoft.com/library/3ede6cef-193d-4c25-8d41-cacabab95ac9(Office.14).aspx

http://technet.microsoft.com/library/3ede6cef-193d-4c25-8d41-cacabab95ac9(Office.14).aspx





35

Windows Server 2008 (http://go.microsoft.com/fwlink/?linkid=197426&clcid=0x416)

Windows Server 2008 R2


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


Pacote de atualização cumulativa 2 para SQL Server 2008 Service Pack 1


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


Pacote de atualização cumulativa 3 para SQL Server 2005 Service Pack 3


Microsoft Windows Server 2008 SP2


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


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


Microsoft .NET Framework 3.5 Service Pack 1


Microsoft SQL Server 2008 Express Edition Service Pack 1


Windows Identity Foundation para Windows Server 2008


Windows Identity Foundation para Windows Server 2008 R2


Microsoft Sync Framework v1.0


Microsoft Office 2010 Filter Packs


Controles de Gráfico da Microsoft para Microsoft .NET Framework 3.5





























36

Microsoft SQL Server 2008 Native Client




KB979917 - QFE para problemas do Sharepoint - correção do Contador de

Desempenho e Representação de Usuário


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


Idioma de reconhecimento de fala para inglês


Idioma de reconhecimento de fala para espanhol


Idioma para reconhecimento de fala para alemão


Idioma para reconhecimento de fala para francês


Idioma para reconhecimento de fala para japonês


Idioma para reconhecimento de fala para chinês


Office Communicator 2007 R2


Microsoft SharePoint Designer 2010 (32 bits)


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

http://technet.microsoft.com/library/3d804f63-ed37-4ec9-8100-d550dd5e5e8e(Office.14).aspx

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





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).



Windows Server 2008

Windows Server 2003

Windows Vista

Windows XP


Não há nenhuma limitação conhecida para o Internet Explorer 7 (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.




Windows Server 2008

Windows Server 2003

Windows 7

Windows Vista

Windows XP


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


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



Integração com o Microsoft InfoPath 2010 Requer um controle ActiveX de 64 bits. O



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



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)




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


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.



Windows Server 2008

Windows Server 2003

Windows Vista

Windows XP


A tabela a seguir lista os recursos e suas limitações conhecidas no Internet Explorer 7 (64 bits).

Recurso Limitação


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



Editar no aplicativo do Microsoft Office Requer um controle ActiveX de 64 bits. O

43

Recurso Limitação






Explorer.


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



Integração com o Microsoft InfoPath 2010 Requer um controle ActiveX de 64 bits. O





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:














link.


2010




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







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




Services)




Integração com planilhas e bancos de dados Requer um controle ActiveX de 64 bits. O


versão de 64 bits desse controle. O usuário












mesmo menu Editar.





opções.


45

Recurso Limitação



PowerPoint 2010









slides.

Mozilla Firefox 3.6 (em sistemas operacionais Windows)

O Mozilla Firefox 3.6 tem suporte nos seguintes sistemas operacionais:


Windows Server 2008

Windows Server 2003

Windows 7

Windows Vista

Windows XP


A tabela a seguir lista recursos e suas limitações conhecidas no Mozilla Firefox 3.6 (em sistemas operacionais Windows).

Recurso Limitação


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





Integração com o Microsoft

InfoPath 2010





Integração com a Biblioteca

de Imagens do Microsoft PowerPoint 2010




de controle do Firefox para esse controle. O usuário poderá

aplicar as seguintes soluções alternativas quando nenhum


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


no Microsoft Office 2010, e um adaptador de controle do Firefox. O Microsoft Office 2010 não fornece um adaptador


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)





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




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





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


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


Requer um aplicativo que seja compatível


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.




Explorer, que podem não funcionar. A

exibição do Explorer requer o Internet

Explorer.


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


50

Recurso Limitação



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

















link.


2010



Novo Documento Requer um controle ActiveX para o qual não

há suporte nesta plataforma. Embora o







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




Services)



Integração com planilhas e bancos de dados Requer controles ActiveX para os quais não

há suporte nesta plataforma. O usuário












mesmo menu Editar.





opções.




PowerPoint 2010

Requer controles ActiveX para os quais não







52

Recurso Limitação


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


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)


A tabela a seguir lista recursos e suas limitações conhecidas no Safari 4.04 (em sistemas operacionais não Windows).

Recurso Limitação


Requer um aplicativo que seja compatível


53

Recurso Limitação

Modo Folha de Dados Requer um controle ActiveX para o qual não


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.




Explorer. A exibição do Explorer requer o

Internet Explorer.


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


Integração com o Microsoft InfoPath 2010 Requer um controle ActiveX para o qual não















54

Recurso Limitação







link.


2010



Novo Documento Requer um controle ActiveX para o qual não

há suporte nesta plataforma. Embora o







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




Services)



Integração com planilhas e bancos de dados Requer controles ActiveX para os quais não


55

Recurso Limitação












mesmo menu Editar.





opções.




PowerPoint 2010

Requer controles ActiveX para os quais não








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


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

http://go.microsoft.com/fwlink/?LinkId=195564&clcid=0x409


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


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)





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:



Exemplo de design: implantação corporativa (SharePoint Server 2010)Corporate

deployment design sample

Planejar conjuntos de sites nomeados pelo host (SharePoint Server 2010)

68


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




Serviços entre farms no Produtos do SharePoint 2010




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

http://technet.microsoft.com/library/31b48cd6-3dda-4942-9ccc-1ded58791004(Office.14).aspx#About

http://technet.microsoft.com/library/31b48cd6-3dda-4942-9ccc-1ded58791004(Office.14).aspx#DesignPrinciples

http://technet.microsoft.com/library/31b48cd6-3dda-4942-9ccc-1ded58791004(Office.14).aspx#CrossFarmDeployment

http://technet.microsoft.com/library/31b48cd6-3dda-4942-9ccc-1ded58791004(Office.14).aspx#Examples

http://technet.microsoft.com/library/31b48cd6-3dda-4942-9ccc-1ded58791004(Office.14).aspx#SingleFarmSingleService

http://technet.microsoft.com/library/31b48cd6-3dda-4942-9ccc-1ded58791004(Office.14).aspx#SingleFarmMultipleService

http://technet.microsoft.com/library/31b48cd6-3dda-4942-9ccc-1ded58791004(Office.14).aspx#Enterprise

http://technet.microsoft.com/library/31b48cd6-3dda-4942-9ccc-1ded58791004(Office.14).aspx#Optimized

http://technet.microsoft.com/library/31b48cd6-3dda-4942-9ccc-1ded58791004(Office.14).aspx#CrossOrg







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.

http://technet.microsoft.com/library/31b48cd6-3dda-4942-9ccc-1ded58791004(Office.14).aspx#Enterprise

http://technet.microsoft.com/library/e8f2c08c-8e9f-40b4-b066-747d65dcb0e4(Office.14).aspx

http://technet.microsoft.com/library/e8f2c08c-8e9f-40b4-b066-747d65dcb0e4(Office.14).aspx

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:

http://technet.microsoft.com/library/ecd9e1d1-3e56-4ab9-80e1-29972586c5a7(Office.14).aspx

http://technet.microsoft.com/library/ecd9e1d1-3e56-4ab9-80e1-29972586c5a7(Office.14).aspx

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


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

http://technet.microsoft.com/library/5aa6512c-cde4-42bc-9e5a-c26445a18d92(Office.14).aspx#section3


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.


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.


É 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.


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.


Cada aplicativo Web possui um nome de domínio exclusivo, o que ajuda a impedir ataques de script entre sites.



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.


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.


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.


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.


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.


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.



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.


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.


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.



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.


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.


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.



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.


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.


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.


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


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


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


Aprovação ou rejeição de um envio pendente


Definição de permissões para publicação





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.


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.


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


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


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.


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


http://teams//sites/Team1 https://teams.fabrikam.com/sites/Team1



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.


http://my/personal/user1 https://my.fabrikam.com/personal/user1



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



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







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


143


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)


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


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


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)


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




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


Considerações sobre Planejamento de Controladores de Domínio Virtualizados


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


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:

http://technet.microsoft.com/library/f2cb570f-f893-4b42-b8a7-d944952b6626(Office.14).aspx

http://technet.microsoft.com/library/d59e6849-84af-4ad0-abed-68fae92574c6(Office.14).aspx

http://technet.microsoft.com/library/d59e6849-84af-4ad0-abed-68fae92574c6(Office.14).aspx

http://technet.microsoft.com/library/4c7e118f-e3f3-450d-acf1-4e219c932fce(Office.14).aspx

http://technet.microsoft.com/library/4c7e118f-e3f3-450d-acf1-4e219c932fce(Office.14).aspx


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


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

http://technet.microsoft.com/library/71abd06e-6730-442e-b2c1-e3ba9c04d497(Office.14).aspx



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.

http://technet.microsoft.com/library/8ea43453-2cb6-4b97-9634-e825904d23c1(Office.14).aspx#VOver

http://technet.microsoft.com/library/8ea43453-2cb6-4b97-9634-e825904d23c1(Office.14).aspx#CapMan

http://technet.microsoft.com/library/8ea43453-2cb6-4b97-9634-e825904d23c1(Office.14).aspx#CapSize

http://technet.microsoft.com/library/8ea43453-2cb6-4b97-9634-e825904d23c1(Office.14).aspx#CreateAnalyzeRefine

http://technet.microsoft.com/library/8ea43453-2cb6-4b97-9634-e825904d23c1(Office.14).aspx#AddOpts




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


Contadores de desempenho do Hyper-V, parte dois de muitas, conjunto de

contadores "Hipervisor do Hyper-V"


Contadores de desempenho do Hyper-V, parte três de muitas, conjunto de

contadores "Processadores lógicos do hipervisor do Hyper-V"


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"


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


168

Critérios Análise

sistema operacional do host e o uso dos requisitos de RAM projetados, há uma


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





para uso futuro.


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





para uso futuro.


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)

http://technet.microsoft.com/library/ba21da28-81c3-4e7a-9a16-69274277528a(Office.14).aspx

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.


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


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)


Home page do Windows Identity Foundation


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.

http://technet.microsoft.com/library/3f849874-1580-47d3-af88-042a3494909f(Office.14).aspx

http://technet.microsoft.com/library/3f849874-1580-47d3-af88-042a3494909f(Office.14).aspx

http://technet.microsoft.com/library/9736e391-1dbf-4a37-b95d-3fdaa5baac7d(Office.14).aspx






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


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.

http://technet.microsoft.com/library/fd1391bb-c787-4742-b007-bf57e18dad66(Office.14).aspx

http://technet.microsoft.com/library/fd1391bb-c787-4742-b007-bf57e18dad66(Office.14).aspx





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


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


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


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://technet.microsoft.com/library/33a9bbc3-fcf5-4aaa-97ec-cd1c7a44d279(Office.14).aspx

http://technet.microsoft.com/library/33a9bbc3-fcf5-4aaa-97ec-cd1c7a44d279(Office.14).aspx









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

http://technet.microsoft.com/library/156cbd50-a05b-4490-b869-f74e2fc0e09d(Office.14).aspx

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.


Configure the Secure Store Service

http://technet.microsoft.com/library/29c0bc76-d835-401b-a2fb-abb069e84125(Office.14).aspx

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)

http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#ServerSnapshots

http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#PortProtocolService

http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#WebAndAppServer

http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#DatabaseServer

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

http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#UserProfile


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

http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#BlockingSQL


http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#BlockingSQL

http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#ServiceApp

http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#FPS


http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#External

http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#Email

http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#SessionState

http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#SharePoint

http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#WebConfig

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

http://technet.microsoft.com/library/2c727311-e83e-4f7b-b02c-9a0699a81e64(Office.14).aspx

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.


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.


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.

http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#SMTP

http://technet.microsoft.com/library/7dcb6a86-f9d4-4c0f-b7c6-fa12a47029c4(Office.14).aspx#DMS

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

http://technet.microsoft.com/library/a96146cd-9973-4680-9a0b-d91ec51200d5(Office.14).aspx

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.


Configure automatic password change (SharePoint Server 2010)

http://technet.microsoft.com/library/5eccfa5b-05ec-46b6-935c-a2d8487965da(Office.14).aspx

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.



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


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

http://technet.microsoft.com/library/9b1e8b21-7675-4186-beb6-3adeef4360e6(Office.14).aspx


http://technet.microsoft.com/library/798aa915-7025-4adc-a210-4f6ff14c43fc(Office.14).aspx

http://technet.microsoft.com/library/798aa915-7025-4adc-a210-4f6ff14c43fc(Office.14).aspx


http://technet.microsoft.com/library/27587e9d-5d16-4dc1-abf8-f74fb7f906a8(Office.14).aspx

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






http://technet.microsoft.com/library/44be0f8c-e167-4b92-9125-2c03b4e440cf(Office.14).aspx

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


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


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




http://technet.microsoft.com/library/13cb12fe-d8dd-451b-89e4-7d2aa68ba9aa(Office.14).aspx

http://technet.microsoft.com/library/13cb12fe-d8dd-451b-89e4-7d2aa68ba9aa(Office.14).aspx

http://technet.microsoft.com/library/0e62326f-cdb9-4cb6-b36a-e0bb8047b55f(Office.14).aspx

http://technet.microsoft.com/library/0e62326f-cdb9-4cb6-b36a-e0bb8047b55f(Office.14).aspx




217


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



http://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx




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.

http://technet.microsoft.com/library/abcf2ba8-86f6-4116-8461-b3e5fc6fedfb(Office.14).aspx

http://technet.microsoft.com/library/9a75a461-6c86-4b61-be98-bcaf9290f2da(Office.14).aspx

http://technet.microsoft.com/library/c7f0ba55-d909-4665-85ba-706ef08d3ec8(Office.14).aspx

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


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


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


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)


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 à

http://msdn.microsoft.com/pt-br/library/bb933866.aspx

http://msdn.microsoft.com/pt-br/library/bb933866.aspx

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


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).

http://technet.microsoft.com/library/3d7496d6-1a0b-4efd-bfe4-6e15c98ea932(Office.14).aspx#Section6_1






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


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)


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


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.

http://technet.microsoft.com/library/6a13cd9f-4b44-40d6-85aa-c70a8e5c34fe(Office.14).aspx

http://technet.microsoft.com/library/6a13cd9f-4b44-40d6-85aa-c70a8e5c34fe(Office.14).aspx



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


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




242

Nível de RAID Fórmula

/ número de discos


/ 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.

http://technet.microsoft.com/library/33633593-0f1b-4f15-858b-ddaaeb20d7ee(Office.14).aspx#Section2

http://technet.microsoft.com/library/33633593-0f1b-4f15-858b-ddaaeb20d7ee(Office.14).aspx#Section3

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.

http://go.microsoft.com/fwlink/?LinkID=177388

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.


FILESTREAM Overview

FILESTREAM Storage in SQL Server 2008

Remote BLOB Store Provider Library Implementation Specification

http://go.microsoft.com/fwlink/?LinkID=166020&clcid=0x409



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

http://technet.microsoft.com/library/c838462c-58b3-4fbd-bcfb-e3e2eff0efd0(Office.14).aspx#SectionENV

http://technet.microsoft.com/library/c838462c-58b3-4fbd-bcfb-e3e2eff0efd0(Office.14).aspx#EvalProv

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

http://technet.microsoft.com/library/1c030561-e15f-43a0-9ef2-f43e67fb4c67(Office.14).aspx


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


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://technet.microsoft.com/library/be4e1054-ada6-4eea-a92d-e35d1da61eb9(Office.14).aspx


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.

http://technet.microsoft.com/library/7942ef65-c309-402d-b4bb-d54e686fc5d9(Office.14).aspx

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

http://technet.microsoft.com/library/3e9dcd50-53e6-4471-a969-aeb4d079dfa3(Office.14).aspx




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



263

Visão geral do Data Protection Manager 2010 Release Candidate


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).


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)


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://technet.microsoft.com/library/be4e1054-ada6-4eea-a92d-e35d1da61eb9(Office.14).aspx


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

http://technet.microsoft.com/library/a6d383c0-3817-4acd-afa9-ad7a9b7e6b5a(Office.14).aspx

http://technet.microsoft.com/library/a6d383c0-3817-4acd-afa9-ad7a9b7e6b5a(Office.14).aspx

http://technet.microsoft.com/library/d849b7df-b26d-45f6-a74f-6641f18788cf(Office.14).aspx

http://technet.microsoft.com/library/73d7f970-c378-4b31-92d5-48cdeb8075e6(Office.14).aspx

http://technet.microsoft.com/library/8404adef-6bfb-4795-be16-15739e1212f5(Office.14).aspx

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. É



http://technet.microsoft.com/library/6d8a9d37-d400-4d7c-b4f1-bf3c5643c98c(Office.14).aspx

http://technet.microsoft.com/library/6d8a9d37-d400-4d7c-b4f1-bf3c5643c98c(Office.14).aspx

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.

http://technet.microsoft.com/library/e0ad657d-f5d1-4cae-bb0d-d2b619eed261(Office.14).aspx

http://technet.microsoft.com/library/e0ad657d-f5d1-4cae-bb0d-d2b619eed261(Office.14).aspx

http://technet.microsoft.com/library/83762baa-b23b-4b63-b14f-350421d9f18a(Office.14).aspx




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).


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

http://technet.microsoft.com/library/f50ca1b2-5075-49f6-9689-46c7b8a29b47(Office.14).aspx

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.


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






278


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.



http://technet.microsoft.com/library/5972de7b-c47d-4877-8101-0a424255caa4(Office.14).aspx

http://technet.microsoft.com/library/5972de7b-c47d-4877-8101-0a424255caa4(Office.14).aspx

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

http://technet.microsoft.com/library/e66f17d6-3e75-445b-802b-3112933820fd(Office.14).aspx

http://technet.microsoft.com/library/e66f17d6-3e75-445b-802b-3112933820fd(Office.14).aspx


284


(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


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

http://technet.microsoft.com/library/67eb6292-98f2-4dea-93b8-110b9c6cb632(Office.14).aspx#Search

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

http://technet.microsoft.com/library/da990ab4-1164-412d-9b37-2c20b57bd5e2(Office.14).aspx

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.

http://technet.microsoft.com/library/7651c3d6-93f9-4b15-9e45-3c23f0f733e3(Office.14).aspx

http://technet.microsoft.com/library/7651c3d6-93f9-4b15-9e45-3c23f0f733e3(Office.14).aspx

http://technet.microsoft.com/library/6ab1724f-8a5a-47f1-b9d6-719ae4f994fc(Office.14).aspx

http://technet.microsoft.com/library/ff30cd9b-a827-4bee-b38a-ed2c3b6b3b47(Office.14).aspx

http://technet.microsoft.com/library/ff30cd9b-a827-4bee-b38a-ed2c3b6b3b47(Office.14).aspx

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.

http://technet.microsoft.com/library/7942ef65-c309-402d-b4bb-d54e686fc5d9(Office.14).aspx

http://technet.microsoft.com/library/38147eec-d89a-478a-956a-779fe76c6679(Office.14).aspx

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

http://technet.microsoft.com/library/7443092a-87a6-4063-a7d0-8d10d9d23682(Office.14).aspx

http://technet.microsoft.com/library/84a80c36-f79a-4270-bb2c-d1eac72fcc36(Office.14).aspx#ServiceAppRedundancy

http://technet.microsoft.com/library/84a80c36-f79a-4270-bb2c-d1eac72fcc36(Office.14).aspx#ServiceAppRedundancy

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

http://technet.microsoft.com/library/d1e61565-7d7d-4694-aa8f-a0ca9ee20377(Office.14).aspx

http://technet.microsoft.com/library/d1e61565-7d7d-4694-aa8f-a0ca9ee20377(Office.14).aspx

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


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


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







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.

http://technet.microsoft.com/library/b31b1204-1cdd-4e11-80e8-a9252e097cb9(Office.14).aspx

http://technet.microsoft.com/library/b31b1204-1cdd-4e11-80e8-a9252e097cb9(Office.14).aspx

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


Configurações do Cache de Documentos do Office


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.


http://technet.microsoft.com/library/e8a433c1-ea1f-4cf7-adc8-50972f58d465(Office.14).aspx

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)



sites de nível


decisões


e navegação.

Plan for using themes (SharePoint Server 2010)



sites de nível


decisões

referentes a

http://technet.microsoft.com/library/0ed0b44c-d60d-4b85-87de-19065d968835(Office.14).aspx

http://technet.microsoft.com/library/0ed0b44c-d60d-4b85-87de-19065d968835(Office.14).aspx

http://technet.microsoft.com/library/cb6871cc-7fc5-4b54-9940-8c0ed51cb08f(Office.14).aspx







http://technet.microsoft.com/library/89bc3f15-d823-445f-9bea-27d5abf3b488(Office.14).aspx






http://technet.microsoft.com/library/bab1595f-4a73-4f46-be9f-831c46ae4805(Office.14).aspx







315

Para esta tarefa


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


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

http://technet.microsoft.com/library/ca092ed2-4aa2-4c2e-b273-661ca6a76e01(Office.14).aspx







http://technet.microsoft.com/library/edcdacca-8013-460e-95a0-d2b83b6cc7ef(Office.14).aspx








http://technet.microsoft.com/library/522699b0-8a89-46ef-9c40-d4c222a863b8(Office.14).aspx


















316

Para esta tarefa



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.


Planilha de análise de uso do documento


Registre informações

coletadas ao analisar o uso de documentos.


Planilha de políticas


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

http://technet.microsoft.com/library/cb57d4f7-8353-420b-8a10-d05c9bdf1b56(Office.14).aspx































317

Para esta tarefa


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


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


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


Planeje regras

que serão uma

parte efetiva

de sua solução

de armazenamento e roteamento baseada em metadados.






http://technet.microsoft.com/library/83079d8c-c64d-40b8-80c6-bab3c8bd44f6(Office.14).aspx







http://technet.microsoft.com/library/655fcd53-aa3c-4139-8f9d-b8a2b8d0b567(Office.14).aspx
















318

Planilhas de planejamento por título

Use esta planilha Para esta tarefa

Para fazer isso

Planilha de análise de uso do documento



Registre

informações

coletadas ao analisar o uso de documentos.

Pasta de trabalho de planejamento do backup e da

recuperação


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


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


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


Metadata-based routing and storage planning

Determine e registre como as

configurações

do organizador































319


Para fazer isso


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



Planeje um tipo de conteúdo.

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.

Planilha de bibliotecas de documentos (http://go.microsoft.com/fwlink/?linkid=165874&clcid=0x416)


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)


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


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)


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



Planeje

políticas de

gerenciamento

de informações

para tipos de

conteúdo.


Plan sites and site collections (SharePoint Server 2010)

Plan site navigation (SharePoint Server

Planejar sites e conjuntos de sites de nível


decisões


e navegação.





























321


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)


Determine a taxonomia básica,

incluindo termo, uso,

proprietário e

grupo.

Planilha de atualização


Plan and prepare for upgrade (SharePoint Server 2010)

Registrar

informações

sobre o ambiente ao se preparar para a

atualização.

















