Conceitos de alta disponibilidade e recuperação de desastre no SharePoint ServerHigh availability and disaster recovery concepts in SharePoint Server

Resumo: entendendo os conceitos de alta disponibilidade e recuperação de desastres no SharePoint Server 2016 e SharePoint 2013 para poder escolher a melhor estratégia para seu farm.Summary: Understand high availability and disaster recovery concepts in SharePoint Server 2016 and SharePoint 2013 so you can choose the best strategy for your farm.

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.High availability and disaster recovery is the highest priority when you create a plan and system specifications for a SharePoint Server farm. Other aspects of the plan, such as high performance and capacity, are negated if farm servers are not highly available or a farm cannot be recovered.

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.To design and implement an effective strategy that maintains efficient and uninterrupted operations, you should understand the basic concepts of high availability and disaster recovery. These concepts are also important to evaluate and pick the best technical solutions for your SharePoint environment.

Apresentação do gerenciamento da continuidade dos negóciosIntroduction to business continuity management

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:Business continuity management is a management process or program that defines, assesses, and helps manage the risks to the continued running of an organization. Business continuity management focuses on creating and maintaining a business continuity plan, which is a roadmap for continuing operations when normal business operations are interrupted by adverse conditions. These conditions can be natural, man-made, or a combination of both. A continuity plan is derived from the following analyses and inputs:

  • Uma análise do impacto nos negóciosA business impact analysis

  • Uma análise de ameaças e riscosA threat and risk analysis

  • Uma definição dos cenários de impactoA definition of the impact scenarios

  • Um conjunto de requisitos de recuperação documentadosA set of documented recovery requirements

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.The result is a solution design or identified options, an implementation plan, a testing and organization acceptance plan, and a maintenance plan or schedule.

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.An example of business continuity management is Disaster recovery and protection for data and applications, which provides a snapshot of the business continuity program at Microsoft.

Obviamente, a TI (tecnologia da informação) é um aspecto significativo do planejamento da continuidade dos negócios para muitas organizações. No entanto, a continuidade dos negócios é mais abrangente: ela inclui todas as operações que são necessárias para assegurar que uma organização possa continuar a fazer negócios durante e imediatamente depois de um grande evento perturbador.Obviously Information Technology (IT) is a significant aspect of business continuity planning for many organizations. However, business continuity is more encompassing - it includes all the operations that are needed to make sure that an organization can continue to do business during and immediately after a major disruptive event. A business continuity plan includes, but is not limited to, the following elements:

  • políticas, processos e procedimentospolicies, processes and procedures

  • opções possíveis e responsabilidade pela tomada de decisõespossible options and decision-making responsibility

  • recursos humanos e instalaçõeshuman resources and facilities

  • tecnologia da informaçãoinformation technology

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.Although high availability and disaster recovery are often equated to business continuity management; they are in fact, subsets of business continuity management.

Descrevendo a alta disponibilidadeDescribing high availability

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.For a given software application or service, high availability is ultimately measured in terms of the end user's experience and expectations. The tangible and perceived business impact of downtime may be expressed in terms of information loss, property damage, decreased productivity, opportunity costs, contractual damages, or the loss of goodwill.

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.The principal goal of a high availability solution is to minimize or mitigate the impact of downtime. A sound strategy for this optimally balances business processes and Service Level Agreements (SLAs) with technical capabilities and infrastructure costs.

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:A platform is considered highly available per the agreement and expectations of customers and stakeholders. The availability of a system can be expressed as this calculation:

Tempo de atividade real/tempo de atividade esperado X 100%Actual uptime/Expected uptime 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.The resulting value is often expressed by industry in terms of the number of 9's that the solution provides; meant to convey an annual number of minutes of possible uptime, or conversely, minutes of downtime.

Número de novesNumber of 9's Porcentagem de disponibilidadeAvailability Percentage Total anual de tempo de inatividadeTotal Annual Downtime
22.
99%99%
3 dias, 15 horas3 days, 15 hours
33.
99,9%99.9% for solutions
8 horas, 45 minutos8 hours, 45 minutes
44.
99,99%99.99%
52 minutos, 34 segundos52 minutes, 34 seconds
55.
99,999%99.999%
5 minutos, 15 segundos5 minutes, 15 seconds

Tempo de inatividade planejado versus não planejadoPlanned versus unplanned downtime

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:System outages are either anticipated or planned for, or they are the result of an unplanned failure. Downtime need not be considered negatively if it is appropriately managed. There are two key types of foreseeable downtime:

  • Manutenção planejada. 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.Planned maintenance. A time window is preannounced and coordinated for planned maintenance tasks such as software patching, hardware upgrades, password updates, offline re-indexing, data loading, or the rehearsal of disaster recovery procedures. Deliberate, well-managed operational procedures should minimize downtime and prevent any data loss. Planned maintenance activities can be seen as investments needed to prevent or mitigate other potentially more severe unplanned outage scenarios.

  • 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.Unplanned outage. System-level, infrastructure, or process failures may occur that are unplanned or uncontrollable, or that are foreseeable, but considered either too unlikely to occur, or are considered to have an acceptable impact. A robust high availability solution detects these types of failures, automatically recovers from the outage, and then reestablishes fault tolerance.

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.When establishing SLAs for high availability, you should calculate separate key performance indicators (KPIs) for planned maintenance activities and unplanned downtime. This approach allows you to contrast your investment in planned maintenance activities against the benefit of avoiding unplanned downtime.

Disponibilidade degradadaDegraded availability

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:High availability should not be considered as an all-or-nothing proposition. As an alternative to a complete outage, it is often acceptable to the end user for a system to be partially available, or to have limited functionality or degraded performance. These varying degrees of availability include:

  • 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.Read-only and deferred operations. During a maintenance window, or during a phased disaster recovery, data retrieval is still possible, but new workflows and background processing may be temporarily halted or queued.

  • 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.Data latency and application responsiveness. Due to a heavy workload, a processing backlog, or a partial platform failure, limited hardware resources may be over-committed or under-sized. User experience may suffer, but work may still get done in a less productive manner.

  • 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.Partial, transient, or impending failures. Robustness in the application logic or hardware stack that retries or self-corrects upon encountering an error. These types of issues may appear to the end user as data latency or poor application responsiveness.

  • 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.Partial end-to-end failure. Planned or unplanned outages may occur gracefully within vertical layers of the solution stack (infrastructure, platform, and application), or horizontally between different functional components. Users may experience partial success or degradation, depending upon the features or components that are affected.

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.The acceptability of these suboptimal scenarios should be considered as part of a spectrum of degraded availability leading up to a complete outage, and as intermediate steps in a phased disaster recovery.

Quantificando o tempo de inatividadeQuantifying downtime

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.When downtime does occur, either planned, or unplanned, the primary business goal is to bring the system back online and minimize data loss. Every minute of downtime has direct and indirect costs. With unplanned downtime, you must balance the time and effort needed to determine why the outage occurred, what the current system state is, and what steps are needed to recover from the outage.

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.At a predetermined point in any outage, you should make or seek the business decision to stop investigating the outage or performing maintenance tasks, recover from the outage by bringing the system back online, and if needed, reestablish fault tolerance.

Objetivos de recuperaçãoRecovery objectives

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.Data redundancy is a key component of a high availability database solution. Transactional activity on your primary SQL Server instance is synchronously or asynchronously applied to one or more secondary instances. When an outage occurs, transactions that were in flight may be rolled back, or they may be lost on the secondary instances due to delays in data propagation.

É 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:You can both measure the impact, and set recovery goals in terms of how long it takes to get back in business, and how much time latency there is in the last transaction recovered:

  • 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.Recovery Time Objective (RTO). This is the duration of the outage. The initial goal is to get the system back online in at least a read-only capacity to facilitate investigation of the failure. However, the primary goal is to restore full service to the point that new transactions can take place.

  • 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.Recovery Point Objective (RPO). This is often referred to as a measure of acceptable data loss. It is the time gap or latency between the last committed data transaction before the failure and the most recent data recovered after the failure. The actual data loss can vary depending upon the workload on the system at the time of the failure, the type of failure, and the type of high availability solution used.

    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.A related objective is Recovery level objective (RLO). This objective defines the granularity with which you must be able to recover data — whether you must be able to recover the whole farm, Web application, site collection, site, list or library, or item. For more information, see Plan for backup and recovery in 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.You should use RTO and RPO values as goals that indicate business tolerance for downtime and acceptable data loss, and as metrics for monitoring availability health.

Justificando ROI custo de oportunidadeJustifying ROI or opportunity cost

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:The business costs of downtime may be either financial or in the form of customer goodwill. These costs may accrue with time, or they may be incurred at a certain point in the outage window. In addition to projecting the cost of incurring an outage with a given recovery time and data recovery point, you can also calculate the business process and infrastructure investments needed to attain your RTO and RPO goals or to avoid the outage all together. These investment themes should include:

  • 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.Avoiding downtime. Outage recovery costs are avoided all together if an outage doesn't occur in the first place. Investments include the cost of fault-tolerant and redundant hardware or infrastructure, distributing workloads across isolated points of failure, and planned downtime for preventive maintenance.

  • 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.Automating recovery. If a system failure occurs, you can greatly mitigate the impact of downtime on the customer experience through automatic and transparent recovery.

  • 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.Resource utilization. Secondary or standby infrastructure can sit idle, awaiting an outage. It also can be leveraged for read-only workloads, or to improve overall system performance by distributing workloads across all available hardware.

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.For given RTO and RPO goals, the needed availability and recovery investments, combined with the projected costs of downtime, can be expressed and justified as a function of time. During an actual outage, this allows you to make cost-based decisions based on the elapsed downtime.

Monitorando a integridade da disponibilidadeMonitoring availability health

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.From an operational point of view, during an actual outage, you should not attempt to consider all relevant variables and calculate ROI or opportunity costs in real time. Instead, you should monitor data latency on your standby instances as a proxy for expected RPO.

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.In the event of an outage, you should also limit the initial time spent investigating the root cause during the outage, and instead focus on validating the health of your recovery environment, and then rely upon detailed system logs and secondary copies of data for subsequent forensic analysis.

Planejando para a recuperação de desastresPlanning for disaster recovery

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.While high availability efforts entail what you do to prevent an outage, disaster recovery efforts address what is done to re-establish high availability after the outage.

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:As much as possible, disaster recovery procedures and responsibilities should be formulated before an actual outage occurs. Based upon active monitoring and alerts, the decision to initiate an automated or manual failover and recovery plan should be tied to pre-established RTO and RPO thresholds. The scope of a sound disaster recovery plan should include:

  • 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.Granularity of failure and recovery. Depending upon the location and type of failure, you can take corrective action at different levels; that is, data center, infrastructure, platform, application, or workload.

  • 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.Investigative source material. Baseline and recent monitoring history, system alerts, event logs, and diagnostic queries should all be readily accessible by appropriate parties.

  • Coordenação de dependências. Na pilha do aplicativo e nos participantes, quais são as dependências do sistema e dos negócios?Coordination of dependencies. Within the application stack, and across stakeholders, what are the system and business dependencies?

  • Árvore de decisão. 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.Decision tree. A predetermined, repeatable, validated decision tree that includes role responsibilities, fault triage, failover criteria in terms of RPO and RTO goals, and prescribed recovery steps.

  • 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?Validation. After taking steps to recover from the outage, what must be done to verify that the system has returned to normal operations?

  • 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".Documentation. Capture all of the above items in a set of documentation, with sufficient detail and clarity so that a third party team can execute the recovery plan with minimal assistance. This type of documentation is commonly called a 'run book' or a 'cook book'.

  • 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.Recovery rehearsals. Regularly exercise the disaster recovery plan to establish baseline expectations for RTO goals, and consider regular rotation of hosting the primary production site on the primary and each of the disaster recovery sites.

Confira tambémSee also

ConceitosConcepts

Escolher uma estratégia de recuperação de desastre para o SharePoint ServerChoose a disaster recovery strategy for SharePoint Server