Resiliência de Aplicações: Mantenha Aplicações Windows Disponíveis

Introdução

As aplicações do Windows muitas vezes dependem de muito mais do que o servidor que as hospeda. Bases de dados, serviços de identidade, armazenamento, gateways, redes e pontos finais de utilizador podem afetar se uma aplicação continua utilizável durante uma interrupção. Este artigo explica como as equipas de TI podem avaliar essas dependências, projetar resiliência em torno das aplicações do Windows existentes, monitorizar as camadas corretas e testar se os planos de recuperação realmente preservam as funções de negócio das quais os utilizadores dependem.

O que é a Resiliência de Aplicações?

A resiliência da aplicação é a capacidade de uma aplicação e da infraestrutura ao seu redor de continuar a fornecer funções vitais durante uma interrupção e de se recuperar de forma previsível após uma falha.

A interrupção pode ser pequena ou grande, e as causas podem variar desde falhas de hardware ou do sistema operativo, falhas de aplicações, atualizações falhadas, interrupções de base de dados, interrupções de rede, falhas de autenticação, exaustão de recursos, dependências indisponíveis ou incidentes de segurança.

Uma arquitetura resiliente reconhece que falhas são inevitáveis e, em vez de tentar prevenir cada incidente, as organizações de TI buscam limitar o impacto de cada um e estabelecer procedimentos de recuperação controlados para manter ou restaurar o serviço.

A Resiliência da Aplicação É Mais do Que o Tempo de Atividade do Servidor

Um erro comum é usar a disponibilidade de um servidor como um proxy para a disponibilidade da aplicação, que é executada no servidor.

Para que uma aplicação empresarial esteja verdadeiramente disponível, um número de componentes precisa estar disponível ao mesmo tempo:

Infraestrutura → Sistema operativo → Aplicação → Dependências → Caminho de acesso → Sessão de utilizador → Processo de negócio

Um problema com qualquer elemento nesta cadeia pode resultar na aplicação estar efetivamente indisponível.

Por exemplo, um servidor de aplicações pode estar saudável enquanto a sua base de dados está inacessível. Uma aplicação publicada pode estar a funcionar corretamente, mas uma falha no gateway torna impossível para os funcionários remotos acederem a ela. Os utilizadores podem até conseguir iniciar a aplicação, mas serem impedidos de completar uma transação porque um serviço de licenciamento, arquivo ou backend não está disponível.

A resiliência da aplicação, portanto, deve ser medida com base na capacidade do usuário de realizar a tarefa comercial necessária, em vez de se considerar se um servidor é capaz de responder a uma verificação de disponibilidade ou saúde.

Por que a resiliência de aplicações é diferente para aplicações Windows?

As práticas modernas de resiliência estão cada vez mais focadas em aplicações nativas da nuvem, contêineres, microserviços e orquestração automatizada. Embora estas sejam abordagens valiosas, nem sempre são aplicáveis a todas as organizações.

Muitas organizações têm aplicações legadas de negócios em Windows que foram desenvolvidas antes de as arquiteturas nativas da nuvem serem comuns. O software ERP, aplicações de contabilidade, aplicações de manufatura, aplicações de saúde, aplicações de engenharia e aplicações desenvolvidas internamente podem ser todas críticas para as operações de uma organização.

Reestruturar essas aplicações como microserviços pode ser extremamente caro, tecnicamente desafiador ou até mesmo completamente inviável se a organização não controlar o código-fonte.

Nesses casos, pode haver um valor significativo em tornar as operações em torno da aplicação mais resilientes, em vez de tentar tornar a própria aplicação mais resiliente. Publicação de aplicações pode fazer parte desta abordagem mantendo as aplicações Windows existentes numa infraestrutura centralizada enquanto muda a forma como os utilizadores acedem a elas. Isso pode incluir alterações à infraestrutura que hospeda a aplicação, como eliminar restrições de infraestrutura, criar hosts de aplicação redundantes, permitir métodos de acesso alternativos e implementar procedimentos de recuperação mais responsivos para o host da aplicação.

Em Que Caso A Disponibilidade De Uma Aplicação Windows Poderia Falhar?

Construir resiliência de aplicações começa com a descoberta dos componentes necessários para entregar com sucesso uma aplicação de seus hosts para os usuários. Este processo destaca pontos potenciais de falha que podem derrubar uma aplicação inteira.

Hosts de Aplicação

Uma aplicação a correr num único servidor Windows tem um claro ponto único de falha.

Problemas de hardware, atualizações do Windows, corrupção do sistema operativo, exaustão de recursos ou falhas de aplicação podem interromper todos os utilizadores que dependem dessa máquina. Se as necessidades de disponibilidade o exigirem, podem ser implementados múltiplos hosts de aplicação para reduzir a dependência de uma única máquina e fornecer capacidade quando um servidor se torna indisponível.

Bases de Dados, Armazenamento e Outras Dependências

Muitas aplicações Windows dependem de serviços externos ao host da aplicação. Esses serviços podem incluir:

• bancos de dados SQL
• compartilhamentos de arquivos
• servidores de licenciamento
• Active Directory
• Sistema de Nomes de Domínio (DNS)
• certificados
• APIs
• middleware
• armazenamento em rede
• infraestrutura de impressão

A introdução de um segundo servidor de aplicação oferece resiliência mínima se eles compartilharem uma dependência comum de banco de dados ou armazenamento que não está disponível. Torna-se evidente que o mapeamento de dependências precisa se estender além da infraestrutura de aplicação visível.

Autenticação e Identidade

Os utilizadores não conseguem aceder a uma aplicação saudável se a infraestrutura de autenticação necessária não estiver disponível.

As equipas de TI precisam identificar os serviços de identidade dos quais as suas aplicações críticas dependem e garantir que têm planos de failover em vigor para quando esses recursos estiverem inacessíveis. Active Directory, plataformas de identidade em nuvem, serviços de autenticação multifator (MFA) e gateways de autenticação podem ser todos utilizados para fornecer uma cadeia de disponibilidade para uma aplicação.

Caminhos de Rede e Acesso Remoto

Para aplicações Windows centralizadas, a conectividade entre os utilizadores e o ambiente da aplicação representa outro possível domínio de falha.

Vamos imaginar a cadeia completa:

Dispositivo do utilizador → Internet ou LAN → gateway → host da aplicação → serviços de backend

Uma falha em qualquer parte desta cadeia pode impedir os usuários de realizarem seus trabalhos, mesmo que a aplicação esteja funcionando corretamente. Isso é particularmente relevante para organizações distribuídas, onde a aplicação pode estar ativa e funcionando no data center, mas inacessível para usuários em outra localização.

Endpoints

A resiliência da aplicação não requer necessariamente que a estação de trabalho normal de um usuário esteja disponível.

Oferecer aos usuários autorizados os meios para acessar aplicações hospedadas centralmente a partir de um dispositivo alternativo ou via um navegador pode garantir o acesso, caso um laptop se torne indisponível, um escritório se torne inacessível ou os funcionários precisem trabalhar de um local diferente.

A arquitetura de entrega de aplicações pode ser um componente de uma estratégia mais ampla de continuidade de negócios.

Qual é o processo de construção de resiliência de aplicações para aplicações Windows?

Nenhuma tecnologia única torna a aplicação resiliente. As equipas de TI, em vez disso, têm de reduzir o número de falhas que podem derrubar uma função completa e preparar mecanismos de recuperação controlada para aquelas que permanecem.

1. Identificar Aplicações Críticas e Processos de Negócio

Nem todas as aplicações requerem o mesmo grau de proteção. Comece por determinar quais aplicações suportam operações primárias, quais utilizadores dependem delas e a sua tolerância a paragens.

Dois objetivos de recuperação traduzem os requisitos de negócios em especificações técnicas. Orientações de planejamento de contingência do NIST define o Objetivo de Tempo de Recuperação (RTO) e o Objetivo de Ponto de Recuperação (RPO) como parâmetros chave para determinar os requisitos de recuperação:

• Objetivo de Tempo de Recuperação (RTO): uma duração de inatividade aceitável antes que o serviço seja restaurado.
• Objetivo de Ponto de Recuperação (RPO): um intervalo de perda de dados aceitável, medido em tempo.

Uma aplicação utilizada intensivamente para processar pedidos pode ter um RTO de minutos, enquanto uma aplicação de relatórios financeiros executada uma vez por semana pode suportar dias de inatividade.

RTO e RPO definem o tipo de proteção necessária para uma aplicação: failover instantâneo, restabelecimento rápido de serviços ou apenas um procedimento de recuperação documentado.

2. Mapeie toda a cadeia de dependência da aplicação

Documente tudo o que precisa estar presente para que a aplicação funcione corretamente.

Não pare no executável ou servidor Windows. Não se esqueça de bases de dados, armazenamento, autenticação, DNS, redes, certificados, sistemas de licenciamento, gateways e serviços externos.

Para cada um, pergunte:

O que acontece com a aplicação se isso desaparecer?

Este exercício irá revelar pontos únicos de falha ocultos e estabelecer a sequência de recuperação. Restaurar um host de aplicação primeiro não ajuda muito se o seu banco de dados, serviço de identidade ou armazenamento ainda não estiver disponível.

3. Remover Pontos Únicos Críticos de Falha

Uma vez estabelecida a árvore de dependência, determine quais componentes devem ser tornados redundantes, com base na importância para os negócios e nos objetivos de recuperação.

No caso da entrega de aplicações Windows, isso pode envolver a implementação de vários servidores de aplicações em vez de depender das capacidades de um único host. Com uma camada de balanceamento de carga, as sessões podem ser distribuídas entre as instâncias de aplicações durante as operações normais. No caso de uma falha do host, as conexões de entrada podem ser direcionadas para instâncias de servidores de aplicações saudáveis.

O planejamento de redundância deve ser informado pela análise de dependência, no entanto. Múltiplos servidores de aplicação acessando um único banco de dados crítico, gateway de rede ou camada de armazenamento ainda apresentam um único ponto de falha.

O design de alta disponibilidade deve, portanto, considerar o serviço de aplicação como uma entidade integrada. Para ambientes Windows Server que exigem redundância a nível de infraestrutura, Documentação de Failover Clustering da Microsoft fornece orientações adicionais sobre topologias de alta disponibilidade e recuperação de desastres.

4. Separar Aplicações de Endpoints Individuais

Instalar uma aplicação crítica diretamente na estação de trabalho de cada funcionário pode criar um tipo diferente de problema de resiliência. Se os usuários perderem o acesso ao seu computador habitual, também podem perder o acesso às aplicações de que precisam para continuar a trabalhar.

Centralizando aplicações em hosts Windows geridos e a apresentação da interface da aplicação aos utilizadores elimina este risco. Os dados e o estado da aplicação são armazenados no host Windows gerido e acedidos por pontos finais autorizados.

Ao fazer isso, tornamos a aplicação disponível para os utilizadores, mesmo que mudem de dispositivos ou locais. Embora a centralização de aplicações não elimine problemas de infraestrutura, ajuda a movê-la para um ambiente onde pode ser controlada pela TI.

5. Fornecer Mais De Um Método Prático de Acesso

A resiliência também pode ser alcançada evitando a dependência desnecessária de um único tipo de endpoint ou método de conexão.

Dependendo da arquitetura de entrega de aplicações, os utilizadores podem usar diferentes acesso remoto métodos, incluindo um cliente compatível com RDP, lançador de aplicativos dedicado, portal web ou sessão de navegador HTML5.

Métodos alternativos de conexão não devem ser confundidos com redundância de infraestrutura. Se todos estiverem dependendo do mesmo servidor com falha, a aplicação ainda estará indisponível.

Eles fornecem resiliência de acesso quando a interrupção afeta o dispositivo normal de um usuário, o cliente instalado ou a localização, em vez do próprio serviço de aplicação.

6. Monitorar Antes que a Degradação se Torne uma Interrupção

A resiliência da aplicação não se trata apenas de recuperação, mas uma deteção precoce pode evitar a degradação em uma falha.

Indicadores úteis em ambientes de aplicações Windows são utilização da CPU, pressão de memória, capacidade do disco e I/O, utilização da rede, sessões ativas, processo da aplicação, tempo de resposta, conexão falhada e disponibilidade de serviços dependentes.

Monitoramento de tendências é crucial, pois um servidor que se aproxima repetidamente dos seus limites pode ainda estar online enquanto a experiência do usuário se deteriora gradualmente.

Alertas de limiar permitem que os administradores investiguem os precursores de um incidente antes que os usuários percam o acesso.

7. Planeje para Picos de Capacidade e Failover

Uma aplicação que sobrevive a falhas a nível de hardware, mas que se torna completamente incapaz de funcionar sob demandas aumentadas, não é verdadeiramente resiliente a falhas de qualquer tipo.

O planejamento da capacidade deve levar em consideração não apenas os padrões de uso diário, mas também contabilizar picos devido a demandas sazonais, mudanças de turnos, crescimento ou requisitos de hospedagem para outras aplicações.

Particularmente em ambientes de hospedagem multi-servidor, a perda de um único servidor deve ser considerada garantindo que outros nós de hospedagem tenham capacidade extra para acomodar quaisquer processos que de outra forma seriam executados no nó com falha.

Caso contrário, os procedimentos de fail-over podem simplesmente transformar um incidente isolado em um amplo problema de desempenho do sistema.

8. Proteger Dados e Configuração

Um servidor Windows de substituição é de pouca utilidade se a TI não conseguir restaurar os componentes necessários para fazer a aplicação funcionar.

Isto pode significar que os procedimentos de backup precisam incluir dados de aplicação, bases de dados, arquivos de configuração, certificados, definições de aplicação, perfis de utilizador, configuração de infraestrutura, scripts e informações de licenciamento.

A estratégia variará dependendo do Objetivo de Tempo de Recuperação (RTO) e do Objetivo de Ponto de Recuperação (RPO) da aplicação.

Acima de tudo, assegure-se de que um backup bem-sucedido não é igual a uma recuperação bem-sucedida. As equipas de TI devem testar se é possível restaurar todo o serviço de aplicação a partir de dados e configurações protegidos.

9. Reduzir o Raio de Ação das Alterações

Não é sempre uma questão de um desastre imprevisto que causa interrupções. Elas também podem ser causadas por melhorias implementadas. Assim, patches do Windows, atualizações de aplicativos e drivers, políticas de segurança e mudanças de configuração também podem ter um impacto negativo na disponibilidade do aplicativo. Recomenda-se evitar fazer mudanças semelhantes em todos os hosts de produção ao mesmo tempo, se possível.

Em uma configuração de múltiplos servidores, é possível realizar as alterações de melhoria em etapas, permitindo assim que o administrador se certifique de que tudo está funcionando corretamente. A capacidade de reverter as alterações feitas também é essencial.

Assim, ao projetar procedimentos de contingência, as opções de reversão também devem ser consideradas. O processo deve ser devidamente documentado, e a equipe deve saber o que fazer se uma alteração falhar, em vez de simplesmente deixar a critério deles.

10. Design para Degradação Elegante

A resiliência não se trata de manter 100% das funções normais em funcionamento o tempo todo.

Em alguns casos, sustentar operações para usuários ou aplicações chave pode ser mais importante do que manter todos os serviços disponíveis para todos os usuários. As prioridades podem ser estabelecidas antes que um incidente ocorra pelas equipes de TI.

Se houver capacidade disponível que possa ser utilizada, pode fazer sentido alocá-la primeiro à produção, ao atendimento ao cliente, às finanças ou a outras funções.

Isso é degradação elegante: manter a capacidade de executar as funções que geram o maior valor para os negócios, em vez de deixar a falha de elementos menos críticos fazer o sistema inteiro falhar.

Como as equipas de TI devem monitorizar a resiliência das aplicações?

Monitorar servidores individuais pode ser útil, mas o monitoramento de resiliência deve refletir o serviço total da aplicação conforme percebido pelos usuários.

Um modelo realista compreende várias camadas:

Camada	O que Monitorar	Exemplo de Falha
Hospedeiro	CPU, RAM, disco, disponibilidade do SO	Servidor sobrecarregado ou offline
Aplicação	Processo e status do serviço	Falhas de aplicação
Dependência	Base de dados, DNS, identidade, armazenamento	A aplicação inicia, mas não consegue operar.
Acesso	Gateway, portal, caminho de rede	Os utilizadores não conseguem conectar-se
Sessão	Utilizadores ativos, falhas, latência	A aplicação está online, mas inutilizável.
Função empresarial	Conclusão bem-sucedida do fluxo de trabalho	O utilizador não consegue completar a tarefa necessária.

A camada de função empresarial é uma das mais simples de ignorar.

Os painéis de infraestrutura podem mostrar todos os servidores, serviços e caminhos de rede como saudáveis, enquanto o fluxo de trabalho de um usuário real está comprometido. É importante, portanto, que aplicações críticas monitorem sua saúde a partir da perspectiva da operação que foram projetadas para suportar.

Como Deve Ser Testada a Resiliência da Aplicação?

Uma arquitetura de resiliência que nunca experimentou uma falha controlada contém suposições não testadas.

Utilize testes para avaliar a resposta do sistema quando componentes-chave se tornam indisponíveis. Os testes devem incluir a desativação de um host de aplicação, a interrupção de um serviço de aplicação, a simulação da perda de uma rota de rede, a verificação do comportamento do gateway ou do balanceamento de carga, a restauração a partir de backup e o acesso à aplicação a partir de um ponto final alternativo.

Os processos de teste devem ir além dos aspectos técnicos da recuperação. As equipas de TI devem rever se os alertas estão a ser enviados ao pessoal administrativo correto, se os passos de recuperação estão a ser realizados na sequência correta e se os utilizadores conseguem realizar uma tarefa empresarial real após os serviços terem sido restaurados.

Os procedimentos operacionais são parte integrante de um sistema resiliente. Procedimentos de escalonamento de alertas: quem recebe o alerta? Quem tem a autoridade para iniciar a transferência? Onde estão armazenados a documentação de recuperação e as credenciais? Qual dependência precisa ser ativada primeiro?

A redundância técnica oferece pouco benefício se os processos para recuperar o acesso não foram testados.

Qual pode ser a lista de verificação da resiliência da aplicação?

Antes de embarcar em uma aplicação crítica do Windows resiliente, as equipes de TI devem ser capazes de responder às seguintes perguntas:

• Quais processos de negócios dependem da aplicação?
• Quais são os seus RTO e RPO?
• Quais servidores, bases de dados e serviços externos são necessários?
• Onde estão os seus pontos críticos de falha?
• Pode outro host de aplicação aceitar utilizadores se um host falhar?
• Os utilizadores podem conectar-se se o seu ponto final ou localização normal não estiver disponível?
• Há capacidade de reserva suficiente para operação degradada?
• Estão os problemas de infraestrutura, dependência e sessão a ser monitorizados ativamente?
• Os administradores são alertados antes que os limites importantes se tornem falhas?
• Os dados e a configuração da aplicação estão protegidos?
• A restauração foi realmente testada?
• As alterações problemáticas podem ser revertidas?
• Está documentada a sequência de recuperação?
• Os utilizadores conseguem completar o processo de negócios necessário após a recuperação?

Nem todas as respostas exigem uma infraestrutura de alta disponibilidade cara. O nível certo de proteção depende do custo e do impacto operacional do tempo de inatividade.

O que importa é que as decisões sobre disponibilidade, redundância e recuperação sejam tomadas deliberadamente, em vez de serem assumidas.

Como o TSplus pode ajudar a manter as aplicações do Windows disponíveis?

Para organizações que dependem de aplicações Windows existentes, podemos ajudar a melhorar a disponibilidade centralizando as aplicações em servidores Windows geridos e entregando-as aos utilizadores através de clientes compatíveis com RDP, acesso ao estilo RemoteApp ou um portal web HTML5. Isso reduz a dependência de terminais individuais dos utilizadores e dá às equipas de TI mais flexibilidade quando os utilizadores precisam de se conectar a partir de outro dispositivo ou localização.

TSplus Acesso Remoto também pode suportar implementações em múltiplos servidores com balanceamento de carga e acesso baseado em gateway. Quando combinado com bases de dados resilientes, armazenamento, serviços de identidade e redes, esta arquitetura pode reduzir a dependência de um único host de aplicação e ajudar a manter o acesso a aplicações críticas do Windows durante interrupções na infraestrutura.

Conclusão

A resiliência da aplicação depende da compreensão do caminho completo entre a infraestrutura e o uso empresarial. A redundância, monitorização, backup, planeamento de capacidade e procedimentos de recuperação são mais eficazes quando são projetados em torno de dependências de aplicação e objetivos de recuperação claramente definidos.

Para aplicações Windows existentes, a resiliência muitas vezes vem do fortalecimento do ambiente em torno do software, em vez de reconstruir a própria aplicação. O teste chave continua simples: quando ocorre uma interrupção, os usuários conseguem continuar a trabalhar ou a TI consegue restaurar a função empresarial necessária dentro da janela de recuperação acordada?