Compartilhar via

Perguntas frequentes sobre resiliência de aplicativos do Azure NetApp Files

  • Artigo

Este artigo responde a perguntas frequentes (FAQs) sobre a resiliência de aplicativos do Azure NetApp Files.

O que você recomenda para lidar com possíveis interrupções de aplicativo devido a eventos de manutenção do serviço de armazenamento?

O Azure NetApp Files pode passar por manutenção planejada ocasional (por exemplo, atualizações de plataforma, atualizações de serviço ou software). De uma perspectiva de protocolo de arquivo (NFS/SMB), as operações de manutenção não causam interrupções, desde que o aplicativo possa lidar com as pausas de E/S que podem ocorrer brevemente durante esses eventos. As pausas de E/S normalmente são curtas, variando de alguns segundos a 30 segundos. O protocolo NFS é especialmente avançado, e as operações de arquivo cliente-servidor continuam normalmente. Alguns aplicativos podem exigir ajuste para lidar com pausas de E/S por 30 a 45 segundos. Sendo assim, verifique se você está ciente das configurações de resiliência do aplicativo para lidar com os eventos de manutenção do serviço de armazenamento. Em aplicativos com interação humana que utilizam o protocolo SMB, as configurações de protocolo padrão geralmente são suficientes.

Importante

Para garantir uma arquitetura resiliente, é crucial reconhecer que a nuvem opera sob um modelo de responsabilidade compartilhada. Esse modelo engloba a plataforma de nuvem do Azure, seus serviços de infraestrutura, a camada de sistema operacional e fornecedores de aplicativos. Cada um desses componentes desempenha um papel vital no tratamento normal de possíveis interrupções de aplicativos que podem surgir durante eventos de manutenção do serviço de armazenamento.

Preciso tomar precauções especiais com aplicativos baseados em SMB?

Sim, determinados aplicativos baseados em SMB exigem Failover Transparente SMB. O Failover Transparente do SMB permite operações de manutenção no serviço do Azure NetApp Files sem interromper a conectividade com os aplicativos de servidor que armazenam e acessam dados em volumes de SMB. Para oferecer suporte ao failover transparente de SMB para aplicativos específicos, o Azure NetApp Files agora oferece suporte à opção de compartilhamentos de disponibilidade contínua SMB. O uso da Disponibilidade Contínua do SMB só tem suporte para cargas de trabalho em:

Cuidado

Não há suporte para aplicativos personalizados com a Disponibilidade Contínua SMB e não podem ser usados com volumes habilitados para Disponibilidade Contínua SMB.

Estou executando o IBM MQ no Azure NetApp Files. Quais precauções posso tomar para evitar interrupções devido a eventos de manutenção do serviço de armazenamento, apesar de usar o protocolo NFS?

Se você está executando o aplicativo IBM MQ em uma configuração de arquivos compartilhados, em que os dados e logs do IBM MQ são armazenados em um volume Azure NetApp Files, as seguintes considerações são recomendadas para melhorar a resiliência durante eventos de manutenção do serviço de armazenamento:

  • Você deve usar somente o protocolo NFS v4.1.
  • Para Alta Disponibilidade, você deve usar uma configuração de várias instâncias do IBM MQ usando volumes NFS v4.1 compartilhados.
  • Você deve verificar a funcionalidade da configuração de várias instâncias da IBM usando volumes NFS v4.1 compartilhados.
  • Você deve implementar uma arquitetura IBM MQ em expansão, em vez de usar uma configuração ampla do IBM MQ de várias instâncias. Ao espalhar a carga de processamento de mensagens em vários pares de múltiplas instâncias do IBM MQ, a chance de interrupção do serviço pode ser diminuída porque cada par de múltiplas instâncias do MQ estaria processando menos mensagens.

Observação

O número de mensagens que cada par de várias instâncias do MQ deve processar é altamente dependente de seu ambiente específico. Você precisa decidir quantos pares de várias instâncias do MQ seriam necessários ou quais seriam as regras de escala ou reba de escala.

A arquitetura de expansão seria composta por vários pares de várias instâncias do IBM MQ implantados por trás de um Azure Load Balancer. Os aplicativos configurados para se comunicar com o IBM MQ seriam configurados para se comunicar com as instâncias do IBM MQ por meio Azure Load Balancer. Para obter suporte relacionado ao IBM MQ em volumes NFS compartilhados, você deve obter suporte do fornecedor na IBM.

Estou executando o Apache ActiveMQ com LevelDB ou KahaDB no Azure NetApp Files. Quais precauções posso tomar para evitar interrupções devido a eventos de manutenção do serviço de armazenamento, apesar de usar o protocolo NFS?

Se você está executando o Apache ActiveMQ, é recomendável implantar a Alta Disponibilidade do ActiveMQ com o Cofres de Armazenamento Conectáveis.

Os modelos de alta disponibilidade (HA) do ActiveMQ garantem que uma instância do agente esteja sempre online e seja capaz de processar o tráfego de mensagens. Os dois modelos mais comuns de HA do ActiveMQ envolvem o compartilhamento de um sistema de arquivos em uma rede. A finalidade é fornecer o LevelDB ou o KahaDB para as instâncias do agente ativo e passivo. Esses modelos de HA exigem que um bloqueio no nível do sistema operacional seja obtido e mantido em um arquivo nos diretórios LevelDB ou KahaDB, chamado "lock". Há alguns problemas com esse modelo de HA do ActiveMQ. Eles podem levar a uma situação de "sem mestre", em que a réplica não está ciente de que pode bloquear o arquivo. Eles também podem levar a uma configuração "mestre-mestre" que resulta em corrupção de índice ou diário e, por fim, perda de mensagens. A maioria desses problemas deriva de fatores fora do controle do ActiveMQ. Por exemplo, um cliente NFS mal otimizado pode fazer com que os dados de bloqueio se tornem obsoletos com carga, levando a um tempo de inatividade “sem mestre” durante o failover.

Como a maioria dos problemas com essa solução de alta disponibilidade deriva do bloqueio de arquivo impreciso no nível do sistema operacional, a comunidade do ActiveMQ introduziu o conceito de um bloqueio de armazenamento conectável na versão 5.7 do agente. Essa abordagem permite que um usuário aproveite um meio diferente do bloqueio compartilhado, usando um bloqueio de banco de dados JDBC em nível de linha em vez de um bloqueio de sistema de arquivos no nível do sistema operacional. Para obter suporte ou consultoria em arquiteturas e implantações de HA do ActiveMQ, você deve entrar em contato com o OpenLogic by Force.

Estou executando o Apache ActiveMQ com LevelDB ou KahaDB no Azure NetApp Files. Quais precauções posso tomar para evitar interrupções devido a eventos de manutenção do serviço de armazenamento apesar de usar o protocolo SMB?

A recomendação geral do setor é não executar seu armazenamento compartilhado KahaDB em CIFS [Common Internet File System]/SMB. Se você estiver tendo problemas para manter o estado de bloqueio preciso, confira o Bloqueio de Armazenamento Conectável do JDBC, que pode fornecer um mecanismo de bloqueio mais confiável. Para obter suporte ou consultoria em arquiteturas e implantações de HA do ActiveMQ, você deve entrar em contato com o OpenLogic by Force.

Estou executando o Boomi no Azure NetApp Files. Quais precauções posso tomar para evitar interrupções devido a eventos de manutenção do serviço de armazenamento?

Se você estiver executando o Boomi, é recomendável seguir as Melhores Práticas do Boomi para Alta Disponibilidade e Recuperação de Desastre em Tempo de Execução.

A Boomi recomenda que o Boomi Molecule seja usado para implementar alta disponibilidade para Boomi Atom. Os requisitos do sistema do Boomi Molecule declaram que NFS com bloqueio de NFS habilitado (suporte a NLM) ou compartilhamentos de arquivos SMB podem ser usados. No contexto do Azure NetApp Files, os volumes NFSv4.1 têm suporte para NLM.

A Boomi recomenda que o compartilhamento de arquivos SMB seja usado com VMs do Windows; para NFS, a Boomi recomenda VMs do Linux.

Observação

Os Compartilhamentos de Disponibilidade Contínua do Azure NetApp Files não têm suporte com o Boomi.

Próximas etapas