Conceitos de alta disponibilidade e recuperação de desastre no SharePoint Server
APLICA-SE A:
2013 2016 2019 Subscription Edition 
SharePoint no Microsoft 365
Alta disponibilidade e recuperação de desastres são as maiores prioridades ao criar especificações para um plano e sistema de um farm do SharePoint Server. Outros aspectos do plano, como alto desempenho e capacidade serão negados se os servidores do farm não estiverem altamente disponíveis ou um farm não puder ser recuperado.
Para projetar e implementar uma estratégia efetiva que mantenha operações eficientes e ininterruptas, é preciso entender os conceitos básicos de alta disponibilidade e recuperação de desastres. Esses conceitos também são importantes para avaliar e escolher as melhores soluções técnicas para seu ambiente do SharePoint.
Apresentação do gerenciamento da continuidade dos negócios
O gerenciamento da continuidade dos negócios é um processo ou programa de gerenciamento que define, avalia e ajuda a gerenciar os riscos para a execução continuada de uma organização. O gerenciamento da continuidade dos negócios foca a criação e manutenção de uma plano de continuidade dos negócios, que é um roteiro de operações contínuas para quando as operações normais dos negócios são interrompidas por condições adversas. Essas condições podem ser naturais, causadas pelo homem ou uma combinação das duas. Um plano de continuidade é oriundo das seguintes análises e entradas:
Uma análise do impacto nos negócios
Uma análise de ameaças e riscos
Uma definição dos cenários de impacto
Um conjunto de requisitos de recuperação documentados
O resultado é composto de um projeto de solução ou opções identificadas, um plano de implementação, um plano de aceitação de testes e da organização e um plano ou cronograma de manutenção.
Um exemplo de gerenciamento de continuidade de negócios é Recuperação de desastres e proteção para dados e aplicativos, que fornece um instantâneo do programa de continuidade de negócios na Microsoft.
Obviamente, as Tecnologias de Informação (TI) são um aspeto significativo do planeamento da continuidade do negócio para muitas organizações. No entanto, a continuidade do negócio é mais abrangente - inclui todas as operações necessárias para garantir que uma organização pode continuar a fazer negócios durante e imediatamente após um grande evento disruptivo. Um plano de continuidade de negócio inclui, mas não se limita a, os seguintes elementos:
políticas, processos e procedimentos
opções possíveis e responsabilidade pela tomada de decisões
recursos humanos e instalações
tecnologia da informação
Embora a alta disponibilidade e a recuperação de desastres sejam sempre comparadas ao gerenciamento da continuidade dos negócios, elas são, na verdade, subconjuntos do gerenciamento da continuidade dos negócios.
Descrevendo a alta disponibilidade
Para determinado serviço ou aplicativo de software, a alta disponibilidade é medida basicamente em termos da experiência e das expectativas do usuário final. O impacto nos negócios tangível e percebido do tempo de inatividade pode ser expresso em termos de perda de informações, dano à propriedade, produtividade reduzida, custos de oportunidade, danos contratuais ou perda da reputação da empresa.
O objetivo principal de uma solução de alta disponibilidade é minimizar ou reduzir o impacto do tempo de inatividade. Uma estratégia segura para isso equilibra da melhor forma os processos empresarias e os SLAs (contrato de nível de serviço) com recursos técnicos e custos de infraestrutura.
Uma plataforma é considerada altamente disponível de acordo com o contrato e as expectativas dos clientes e participantes. A disponibilidade de um sistema pode ser expressa por meio deste cálculo:
Tempo de atividade real/tempo de atividade esperado X 100%
O valor resultante é sempre expresso pelo setor em termos do número de noves que a solução oferece; cujo propósito é comunicar um número anual de minutos de tempo de atividade possível ou, inversamente, minutos de tempo de inatividade.
| Número de noves | Porcentagem de disponibilidade | Total anual de tempo de inatividade |
|---|---|---|
| 2 |
99% |
3 dias, 15 horas |
| 3 |
99,9% |
8 horas, 45 minutos |
| 4 |
99,99% |
52 minutos, 34 segundos |
| 5 |
99,999% |
5 minutos, 15 segundos |
Tempo de inatividade planejado versus não planejado
As indisponibilidades do sistema são antecipadas ou planejadas ou são o resultado de uma falha não planejada. O tempo de inatividade não precisa ser considerado de forma negativa quando é gerenciado apropriadamente. Esses são os dois tipos principais de tempo de inatividade previsto:
Manutenção planeada. Uma janela de tempo é preanunciada e coordenada para tarefas de manutenção planejadas, como aplicação de patch de software, atualizações de hardware, reindexação offline, carregamento de dados ou ensaio de procedimentos de recuperação de desastres. Procedimentos operacionais deliberados e bem gerenciados devem minimizar o tempo de inatividade e impedir qualquer perda de dados. As atividades de manutenção planejadas podem ser vistas como investimentos necessários para impedir ou reduzir outros cenários de indisponibilidade potencialmente mais severos.
Indisponibilidade não planejada. Falhas de processo, infraestrutura ou no nível do sistema podem ocorrer de forma não planejada ou incontrolável ou podem ser previsíveis, mas consideradas muito improváveis ou de impacto aceitável. Uma solução robusta de alta disponibilidade detecta esses tipos de falhas, recupera-se automaticamente da indisponibilidade e, então, restabelece a tolerância a falhas.
Quando for estabelecer SLAs de alta disponibilidade, será preciso calcular KPIs (indicadores-chave de desempenho) separados para atividades de manutenção planejadas e tempo de inatividade não planejado. Esta abordagem permite contrastar seu investimento em atividades de manutenção planejadas com o benefício de evitar o tempo de inatividade não planejado.
Disponibilidade degradada
A alta disponibilidade não deve ser considerada um proposição de "tudo ou nada". Como alternativa a uma indisponibilidade completa, é sempre aceitável para o usuário final que um sistema esteja parcialmente disponível, tenha funcionalidade limitada ou desempenho degradado. Esses graus variáveis de disponibilidade abrangem:
Operações adiadas ou somente leitura. Durante uma janela de manutenção ou uma recuperação de desastre em fases, a recuperação dos dados ainda é possível, mas novos fluxos de trabalho e processamentos em segundo plano podem ser temporariamente interrompidos ou colocados em fila.
Latência dos dados e responsividade do aplicativo. Devido a uma carga de trabalho pesada, lista de pendências de processamento ou falha parcial na plataforma, recursos limitados de hardware podem ser sobrecarregados ou subdimensionados. A experiência do usuário pode ser afetada, mas o trabalho ainda pode ser feito de uma forma menos produtiva.
Falhas parciais, transitórias ou iminentes. A robustez da lógica do aplicativo ou da pilha de hardware que tenta novamente fazer a autocorreção ao encontrar um erro. Esses tipos de problemas podem aparecer ao usuário final como latência de dados ou fraca responsividade do aplicativo.
Falha parcial de ponta a ponta. Indisponibilidades planejadas ou não planejadas podem ocorrer em camadas verticais da pilha da solução (infraestrutura, plataforma e aplicativo) ou horizontalmente entre diferentes componentes funcionais. Os usuários podem perceber um sucesso parcial ou uma degradação, dependendo dos recursos ou componentes afetados.
A aceitação desses cenários subideais deve ser considerada como parte de um espectro de disponibilidade degradada, levando a uma indisponibilidade completa e como etapas intermediárias de uma recuperação de desastre em fases.
Quantificando o tempo de inatividade
Quando ocorre o tempo de inatividade, seja ele planejado ou não, o principal objetivo dos negócios é trazer o sistema novamente online e minimizar a perda de dados. Cada minuto de tempo de inatividade tem custos diretos e indiretos. Com um tempo de inatividade não planejado, é preciso equilibrar o tempo e esforço necessários para determinar porque a indisponibilidade ocorreu, qual é o estado atual do sistema e quais são as etapas necessárias para se recuperar da indisponibilidade.
Em um ponto predeterminado de uma indisponibilidade, é preciso tomar ou buscar as decisões sobre os negócios a fim de parar a investigação sobre a indisponibilidade e realizar as tarefas de manutenção, recuperar-se da indisponibilidade trazendo o sistema online novamente e, se necessário, restabelecer a tolerância a falhas.
Objetivos de recuperação
A redundância dos dados é um componente-chave de uma solução de alta disponibilidade. A atividade transacional em sua instância primária do SQL Server é aplicada de forma síncrona ou assíncrona a uma ou mais instâncias secundárias. Quando ocorre uma indisponibilidade, as transações que estavam em trânsito podem ser revertidas ou perdidas nas instâncias secundárias devido a atrasos na propagação dos dados.
É possível medir o impacto e definir objetivos de recuperação em termos de tempo necessário para voltar aos negócios e tempo de latência existente na última transação recuperada:
Objetivo de tempo de recuperação (RTO). Trata-se da duração da indisponibilidade. O objetivo inicial é fazer com que o sistema fique online em, pelo menos, uma capacidade somente leitura para facilitar a investigação da falha. No entanto, o objetivo principal é restaurar o serviço completo no ponto em que as novas transações podem ocorrer.
Objetivo do ponto de recuperação (RPO). Isso é sempre referido como uma medida de perda de dados aceitável. Trata-se do intervalo de tempo ou latência entre a última transação de dados comprometida antes da falha e os dados mais recentes recuperados após a falha. A perda real de dados pode variar dependendo da carga de trabalho no sistema no momento da falha, do tipo de falha e do tipo de solução de alta disponibilidade usada.
Observação
[!OBSERVAçãO] Um objetivo relacionado é o Objetivo do nível de recuperação (RLO). Este objetivo define a granularidade na qual deve ser possível recuperar os dados: se deve ser possível recuperar todo o farm, o aplicativo Web, o conjunto de sites, o site , a lista, a biblioteca ou o item. Para saber mais, confira Planejamento de backup e recuperação no SharePoint Server.
Valores de RTO e RPO devem ser usados como objetivos para indicar a tolerância dos negócios ao tempo de inatividade e a perda de dados aceitável, além das medidas de monitoramento da integridade da disponibilidade.
Justificando ROI custo de oportunidade
Os custos aos negócios do tempo de inatividade podem ser financeiros ou na forma da reputação da marca vista pelo cliente. Esses custos podem aumentar com o tempo ou podem incorrer em certo ponto na janela de indisponibilidade. Além de projetar o custo de ocorrência de uma indisponibilidade com determinado tempo de recuperação e ponto de recuperação de dados, é possível também calcular o processo empresarial e os investimentos em infraestrutura necessários para alcançar os objetivos de RTO e RPO ou evitar a indisponibilidade de todos juntos. Esses objetos de investimento devem abranger:
Evitando o tempo de inatividade. Os custos de recuperação de uma indisponibilidade são evitados todos juntos se uma indisponibilidade não ocorre em primeiro lugar. Os investimentos abrangem o custo de hardware ou infraestrutura redundante e tolerante a falhas, distribuição de cargas de trabalho em pontos isolados da falha e tempo de inatividade planejado para manutenção preventiva.
Automatizando a recuperação. Se ocorre uma falha no sistema, é possível reduzir consideravelmente o impacto do tempo de inatividade na experiência do cliente por meio da recuperação automática e transparente.
Utilização de recursos. A infraestrutura secundária ou de espera pode permanecer ociosa aguardando uma indisponibilidade. Ela também pode ser aproveitada para cargas de trabalho somente leitura ou para aprimorar o desempenho geral do sistema distribuindo as cargas de trabalho em todo o hardware disponível.
Para determinados objetivos de RTO e RPO, os investimentos necessários em disponibilidade e recuperação, combinados com os custos projetados do tempo de inatividade podem ser expressos e justificados como uma função de tempo. Durante uma indisponibilidade real, isso permite que você tome decisões baseadas no custo e no tempo de inatividade decorrido.
Monitorando a integridade da disponibilidade
Sob um ponto de vista operacional, durante uma indisponibilidade real, você não deve tentar considerar todas as varáveis relevantes e calcular o ROI ou custos de oportunidade em tempo real. Em vez disso, você deve monitorar a latência dos dados nas instâncias de espera como proxy de RPO esperado.
No evento de uma indisponibilidade, também deve ser limitado o tempo inicial gasto investigando a causa raiz durante a indisponibilidade e, em vez disso, focar a validação da integridade de seu ambiente de recuperação e, depois, basear-se em logs detalhados do sistema e cópias secundárias dos dados para fins de perícia subsequente.
Planejando para a recuperação de desastres
Enquanto os esforços de alta disponibilidade envolvem o que deve ser feito para impedir uma indisponibilidade, os esforços de recuperação de desastres tratam do que é feito para restabelecer a alta disponibilidade depois da indisponibilidade.
Tanto quanto possível, as responsabilidades e os procedimentos de recuperação de desastres devem ser formulados antes que uma indisponibilidade real ocorra. Com base no monitoramento ativo e em alertas, a decisão de iniciar um plano de failover e recuperação manual ou automático deve estar vinculada aos limites de RTO e RPO pré-estabelecidos. O escopo de um plano seguro de recuperação de desastres deve conter:
Granularidade da falha e recuperação. Dependendo do local e do tipo de falha, será possível realizar uma ação corretiva em diferentes níveis, isto é, centro de dados, infraestrutura, plataforma, aplicativo ou carga de trabalho.
Material de origem investigativa. Linha de base e histórico de monitoramento, alertas do sistema, logs de eventos e consultas de diagnósticos recentes devem todos estar prontamente acessíveis pelas partes apropriadas.
Coordenação de dependências. Na pilha do aplicativo e nos participantes, quais são as dependências do sistema e dos negócios?
Árvore de decisões. Uma árvore de decisão predeterminada, validada e que pode ser repetida, incluindo responsabilidades das funções, triagem de falhas, critérios de failover em termos de objetivos de RPO e RTO e etapas de recuperação prescritas.
Validação. Depois de seguir as etapas para se recuperar de uma indisponibilidade, o que deve ser feito para verificar se o sistema retornou às operações normais?
Documentação. Capturar todos os itens acima em um conjunto de documentação com detalhes e clareza suficientes para que uma equipe terceirizada possa executar o plano de recuperação com o mínimo de ajuda. Este tipo de documentação é geralmente chamado de "manual de execução" ou "livro de receita".
Ensaios de recuperação. Exercitar regularmente o plano de recuperação de desastres para estabelecer as expectativas da linha de base para objetivos de RTO e considerar a rotação regular de hospedagem do site de produção principal em cada um dos principais sites de recuperação de desastres.
Confira também
Conceitos
Escolher uma estratégia de recuperação de desastre para o SharePoint Server
Outros recursos
Que cargas de trabalho podem ser protegidas pelo Azure Site Recovery?