Disponibilidade e continuidade dos negócios no Azure Cognitive Search

No Cognitive Search, a disponibilidade é alcançada por meio de várias réplicas, enquanto a continuidade dos negócios (e recuperação de desastre) é alcançada por meio de vários serviços de pesquisa. Este artigo fornece diretrizes que você pode usar como ponto de partida para desenvolver uma estratégia que atenda aos seus requisitos de negócios tanto para disponibilidade como para operações contínuas.

Alta disponibilidade

No Cognitive Search, as réplicas são cópias do seu índice. Ter várias réplicas permite que o Azure Cognitive Search faça reinicializações e manutenção do computador em uma réplica, enquanto a execução da consulta continua em outras réplicas. Para obter mais informações sobre como adicionar réplicas, consulte Adicionar ou reduzir réplicas e partições.

Para cada serviço de pesquisa individual, a Microsoft garante pelo menos 99,9% de disponibilidade para configurações que atendem a estes critérios:

  • Duas réplicas para alta disponibilidade de cargas de trabalho somente leitura (consultas)

  • Três ou mais réplicas para alta disponibilidade das cargas de trabalho de leitura/gravação (consultas e indexação)

Nenhum SLA é fornecido para a camada Gratuita. Para obter mais informações, confira SLA para o Azure Cognitive Search.

Residência de dados

O Azure Cognitive Search não armazena dados do cliente fora da região especificada pelo cliente sem a sua autorização.

Zonas de Disponibilidades

As Zonas de disponibilidade são um recurso da plataforma Azure que divide os data centers de uma região em grupos de locais físicos distintos para fornecer alta disponibilidade, dentro da mesma região. Se você usa as Zonas de Disponibilidade para o Cognitive Search, as réplicas individuais são as unidades para atribuição de zona. Um serviço de pesquisa é executado dentro de uma região; suas réplicas são executadas em diferentes zonas.

Você pode utilizar Zonas de Disponibilidade com o Pesquisa Cognitiva do Azure adicionando duas ou mais réplicas ao serviço de pesquisa. Cada réplica será colocada em uma zona de disponibilidade diferente dentro da região. Se você tiver mais réplicas do que Zonas de Disponibilidade, as réplicas serão distribuídas entre Zonas de Disponibilidade o mais uniforme possível. Não há nenhuma ação específica da sua parte, exceto criar um serviço de pesquisa em uma região que fornece Zonas de Disponibilidade e configurar o serviço para usar várias réplicas.

Atualmente, o Azure Pesquisa Cognitiva dá suporte a Zonas de Disponibilidade para serviços de camada Standard ou de pesquisa mais alta que foram criados em uma das seguintes regiões:

Região Distribuir
Leste da Austrália 30 de janeiro de 2021 ou posterior
Brazil South 2 de maio de 2021 ou posterior
Canadá Central 30 de janeiro de 2021 ou posterior
Índia Central 20 de janeiro de 2022 ou posterior
Centro dos EUA 4 de dezembro de 2020 ou posterior
Leste da Ásia 13 de janeiro de 2022 ou posterior
Leste dos EUA 27 de janeiro de 2021 ou posterior
Leste dos EUA 2 30 de janeiro de 2021 ou posterior
França Central 23 de outubro de 2020 ou posterior
Centro-Oeste da Alemanha 3 de maio de 2021 ou posterior
Leste do Japão 30 de janeiro de 2021 ou posterior
Coreia Central 20 de janeiro de 2022 ou posterior
Norte da Europa 28 de janeiro de 2021 ou posterior
Leste da Noruega 20 de janeiro de 2022 ou posterior
Centro-Sul dos Estados Unidos 30 de abril de 2021 ou posterior
Sudeste da Ásia 31 de janeiro de 2021 ou posterior
Suécia Central 21 de janeiro de 2022 ou posterior
Sul do Reino Unido 30 de janeiro de 2021 ou posterior
Gov. dos EUA – Virgínia 30 de abril de 2021 ou posterior
Europa Ocidental 29 de janeiro de 2021 ou posterior
Oeste dos EUA 2 30 de janeiro de 2021 ou posterior
Oeste dos EUA 3 02 de junho de 2021 ou posterior

Zonas de Disponibilidade não têm impacto sobre o contrato de nível de serviço de pesquisa cognitiva do Azure. Você ainda precisa de 3 ou mais réplicas para a alta disponibilidade da consulta.

Vários serviços em regiões geográficas separadas

Embora a maioria dos clientes use apenas um serviço, a redundância de serviço poderá ser necessária se os requisitos operacionais incluírem o seguinte:

  • BCDR (continuidade dos negócios e recuperação de desastres) (o Cognitive Search não fornece failover instantâneo no caso de uma falha).
  • Aplicativos implantados globalmente. Se as solicitações de consulta e indexação vierem de todo o mundo, os usuários que estão mais próximos do host data center terão um desempenho mais rápido. Criar serviços adicionais em regiões com maior proximidade a esses usuários pode equilibrar o desempenho para todos os usuários.
  • Arquiteturas multilocatários, às vezes, chamam dois ou mais serviços.

Se você precisar de mais dois serviços de pesquisa, poderá criá-los em regiões diferentes para atender aos requisitos de aplicativos de continuidade e recuperação, bem como tempos de resposta mais rápidos para uma base de usuários global.

No momento, o Azure Cognitive Search não fornece um método automatizado de replicação geográfica de índices de pesquisa entre regiões, mas existem algumas técnicas que podem ser usadas para tornar esse processo simples de implementar e gerenciar. Elas serão descritas nas próximas seções.

O objetivo de um conjunto de serviços de pesquisa distribuídos geograficamente é ter dois ou mais índices disponíveis em duas ou mais regiões para que o usuário seja encaminhado para o serviço do Azure Cognitive Search que ofereça a menor latência:

Cross-tab of services by region

Você pode implementar essa arquitetura criando vários serviços e projetando uma estratégia para sincronização de dados. Opcionalmente, você pode incluir um recurso como o Gerenciador de Tráfego do Azure para solicitações de roteamento. Para saber mais, confira Criar um serviço de pesquisa.

Manter os dados sincronizados em vários serviços

Há duas opções para manter dois ou mais serviços de pesquisa distribuídos em sincronia, que são o uso do Indexador do Azure Cognitive Search ou a API Push (também conhecida como a API REST do Azure Cognitive Search).

Opção 1: usar indexadores para atualizar o conteúdo em vários serviços

Se você já estiver usando o indexador em um serviço, poderá configurar um segundo indexador em um segundo serviço para usar o mesmo objeto de fonte de dados, obtendo dados do mesmo local. Cada serviço em cada região tem seu próprio indexador e um índice de destino (o índice de pesquisa não é compartilhado, o que significa que os dados estão duplicados), mas cada indexador faz referência à mesma fonte de dados.

Aqui está um Visual de alto nível da aparência dessa arquitetura.

Single data source with distributed indexer and service combinations

Opção 2: usar APIs REST para enviar atualizações de conteúdo por push em vários serviços

Se estiver usando a API REST do Azure Cognitive Search para buscar conteúdo para seu índice de pesquisa, você pode manter em sincronia seus vários serviços de pesquisa enviando por push as alterações para todos os serviços de pesquisa, sempre que uma atualização for necessária. Em seu código, certifique-se de lidar com casos em que uma atualização para um serviço de pesquisa falha, mas é bem-sucedida para outros serviços de pesquisa.

Usar o Gerenciador de Tráfego do Azure para coordenar solicitações

Gerenciador de Tráfego do Azure permite que você encaminhe solicitações para vários sites localizados geograficamente que recebem suporte de vários Serviços de pesquisa. Uma vantagem do Gerenciador de Tráfego é que ele pode investigar o Azure Cognitive Search para garantir sua disponibilidade e encaminhar os usuários aos serviços de pesquisa alternativos em caso de inatividade. Além disso, se você estiver encaminhando solicitações de pesquisa por meio dos Sites do Azure, o Gerenciador de Tráfego do Azure permitirá o balanceamento de carga de casos em que o site está ativo, mas não o Azure Cognitive Search. Veja um exemplo de uma arquitetura que aproveita o Gerenciador de Tráfego.

Cross-tab of services by region, with central Traffic Manager

Recuperação de desastre e interrupções de serviço

Conforme indicado no SLA (Contrato de Nível de Serviço), garantimos um alto nível de disponibilidade para solicitações de consulta de índice quando uma instância de serviço do Azure Cognitive Search é configurada com duas ou mais réplicas e solicitações de atualização de índice quando uma instância de serviço do Azure Cognitive Search é configurada com três ou mais réplicas. No entanto, não existe mecanismo integrado para recuperação de desastres. Se o serviço contínuo for necessário no caso de uma falha catastrófica fora do controle da Microsoft, recomendamos o provisionamento de um segundo serviço em outra região e a implementação de uma estratégia de replicação geográfica para garantir que os índices sejam totalmente redundantes em todos os serviços.

Os clientes que usam indexadores para popular e atualizar índices podem lidar com a recuperação de desastre por meio de indexadores específicos à geografia utilizando a mesma fonte de dados. Dois serviços em diferentes regiões, cada um executando um indexador, poderiam indexar a mesma fonte de dados para obter a redundância geográfica. Se você estiver indexando fontes de dados que tenham redundância geográfica, lembre-se de que os indexadores do Azure Cognitive Search só podem executar indexação incremental (mesclando atualizações de documentos novos, modificados ou excluídos) de réplicas primárias. Em um evento de failover, verifique se você apontou novamente o indexador para a nova réplica primária.

Se você não usar indexadores, você usará o código do aplicativo para enviar objetos e dados por push para diferentes serviços de pesquisa em paralelo. Para obter mais informações, confira Manter dados sincronizados em vários serviços.

Alternativas de backup e restauração

Como o Azure Cognitive Search não é uma solução de armazenamento primário de dados, a Microsoft não fornece um mecanismo formal de backup e restauração de autoatendimento. No entanto, você pode usar o código index-backup-restore exemplificado neste repositório do Azure Cognitive Search em .NET para fazer backup da definição de índice e do instantâneo para uma série de arquivos JSON e depois usar esses arquivos para restaurar o índice, se necessário. Essa ferramenta também pode mover índices entre camadas de serviço.

Caso contrário, o código de aplicativo usado para criar e popular um índice será a opção de restauração de fato se você excluir um índice por engano. Para recompilar um índice, exclua-o (supondo que ele exista), recrie o índice no serviço e recarregue-o recuperando dados do armazenamento de dados primário.

Próximas etapas

Para saber mais sobre os limites de serviços e os tipos de preço para cada um, confira Limites do serviço. Examine o artigo Planejar capacidade para saber mais sobre as combinações de partição e réplica, ou confira o Estudo de caso: Usar pesquisa cognitiva para dar suporte a cenários de IA complexos para obter dicas do mundo real.