Planejar a disponibilidade (SharePoint Foundation 2010)
Aplica-se a: SharePoint Foundation 2010
Tópico modificado em: 2016-11-30
Este artigo descreve as principais decisões a serem tomadas durante a escolha de estratégias de disponibilidade para um ambiente do Microsoft SharePoint Foundation 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 Foundation é 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 backup e recuperação (SharePoint Foundation 2010) e Planejar a recuperação de desastre (SharePoint Foundation 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.
| 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?
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 Foundation, 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 Foundation 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
.gif "Disponibilidade de farm único")
A tabela a seguir descreve as funções de servidor em um ambiente do SharePoint Foundation 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 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 Foundation.
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 Foundation pode ser executado em qualquer combinação de nós ativos e passivos em um cluster com suporte do SQL Server.
O SharePoint Foundation faz referências ao cluster como um todo; dessa forma, o failover é automático e direto da perspectiva do SharePoint Foundation.
Para obter informações detalhadas sobre cluster de failover, consulte Introdução ao cluster de failover do SQL Server 2008 (https://go.microsoft.com/fwlink/?linkid=102837&clcid=0x416) e Configure availability by using SQL Server clustering (SharePoint Foundation 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 espelhamento em um farm do SharePoint Foundation, 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.
Uma alteração de versões anteriores é que o SharePoint Foundation 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 Foundation usa para se conectar ao SQL Server. No caso de um evento de expiração de tempo limite do SQL Server, ocorrerá o seguinte:
O servidor testemunha configurado para espelhamento do SQL Server automaticamente alterna as funções dos bancos de dados primário e espelho.
O SharePoint Foundation 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 Foundation 2010).
Para obter informações gerais sobre o espelhamento de banco de dados, consulte Espelhamento de banco de dados (https://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 (milissegundos) |
Etapas exigidas para failover? |
A falha é automaticamente detectada pelos nós do banco de dados; o SharePoint Foundation 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 Foundation 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 devem 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 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. |
Exige o modelo de recuperação completa do SQL 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 em bancos de dados
Para ajudar a proteger os aplicativos de serviço que armazenam dados em bancos de dados, execute as seguintes etapas:
Instale o serviço em vários servidores de aplicativos para fornecer redundância no ambiente.
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 Serviço de Conectividade de Dados Corporativos
Aplicativo do 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 Windows SharePoint Services 3,0 para o SharePoint Foundation 2010.
Aplicativo de Serviço de Conjunto de Dados de Uso e Integridade
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.
Serviço de Configurações de Inscrição do Microsoft SharePoint Foundation
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.
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
.gif "Farm \"estendido\"")