Fiabilidade na Pesquisa de IA do Azure
No Azure, confiabilidade significa resiliência e disponibilidade se houver uma interrupção ou degradação do serviço. No Azure AI Search, a fiabilidade pode ser alcançada num único serviço ou através de vários serviços de pesquisa em regiões separadas.
Implante um único serviço de pesquisa e aumente a escala para alta disponibilidade. Você pode adicionar várias réplicas para lidar com cargas de trabalho de indexação e consulta mais altas. Se o seu serviço de pesquisa oferecer suporte a zonas de disponibilidade, as réplicas serão automaticamente provisionadas em diferentes data centers físicos para maior resiliência.
Implante vários serviços de pesquisa em diferentes regiões geográficas. Todas as cargas de trabalho de pesquisa estão totalmente contidas em um único serviço executado em uma única região geográfica, mas em um cenário de vários serviços, você tem opções para sincronizar o conteúdo para que ele seja o mesmo em todos os serviços. Você também pode configurar uma solução de balanceamento de carga para redistribuir solicitações ou fazer failover se houver uma interrupção de serviço.
Para continuidade de negócios e recuperação de desastres em nível regional, planeje uma topologia inter-regional, consistindo em vários serviços de pesquisa com configuração e conteúdo idênticos. Seu script ou código personalizado fornece o mecanismo de "failover" para um serviço de pesquisa alternativo se um de repente ficar indisponível.
Elevada disponibilidade
No Azure AI Search, as réplicas são cópias do seu índice. Um serviço de pesquisa é comissionado com pelo menos uma réplica e pode ter até 12 réplicas. Adicionar réplicas permite que o Azure AI Search faça reinicializações de máquina e manutenção em uma réplica, enquanto a execução da consulta continua em outras réplicas .
Para cada serviço de pesquisa individual, a Microsoft garante, pelo menos, 99,9% de disponibilidade para configurações que satisfaçam estes critérios:
Duas réplicas de elevada disponibilidade de cargas de trabalho só de leitura (consultas)
Três ou mais réplicas de elevada disponibilidade de cargas de trabalho de leitura-escrita (consultas e indexação)
O sistema possui mecanismos internos para monitorar a integridade da réplica e a integridade da partição. Se você provisionar uma combinação específica de réplicas e partições, o sistema garantirá esse nível de capacidade para o seu serviço.
Não é disponibilizado nenhum SLA para o escalão Gratuito. Para obter mais informações, consulte SLA para Azure AI Search.
Suporte à zona de disponibilidade
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. No Azure AI Search, 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 data centers físicos (ou zonas) dentro dessa região.
As zonas de disponibilidade são usadas quando você adiciona duas ou mais réplicas ao seu serviço de pesquisa. Cada réplica é colocada em uma zona de disponibilidade diferente dentro da região. Se você tiver mais réplicas do que as zonas disponíveis na região do serviço de pesquisa, as réplicas serão distribuídas entre as zonas da forma mais uniforme possível. Não há nenhuma ação específica de sua parte, exceto criar um serviço de pesquisa em uma região que forneça zonas de disponibilidade e, em seguida, configurar o serviço para usar várias réplicas.
Pré-requisitos
- A camada de serviço deve ser Standard ou superior.
- A região de serviço deve estar em uma região que tenha zonas disponíveis (listadas na seção a seguir).
- A configuração deve incluir várias réplicas: duas para cargas de trabalho de consulta somente leitura, três para cargas de trabalho de leitura-gravação que incluem indexação.
Regiões suportadas
O suporte para zonas de disponibilidade depende da infraestrutura e do armazenamento. Atualmente, duas zonas que foram anunciadas em outubro de 2023 têm armazenamento insuficiente e não fornecem uma zona de disponibilidade para o Azure AI Search:
- Israel Central
- Norte da Itália
Caso contrário, as zonas de disponibilidade para o Azure AI Search são suportadas nas seguintes regiões:
| País/Região | Implantação |
|---|---|
| Leste da Austrália | 30 de janeiro de 2021 ou posterior |
| Sul do Brasil | 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 |
| EUA centrais | 4 de dezembro de 2020 ou posterior |
| Norte da China 3 | 7 de setembro de 2022 ou posterior |
| Ásia Leste | 13 de janeiro de 2022 ou posterior |
| E.U.A. Leste | 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 |
| Alemanha Centro-Oeste | 3 de maio de 2021 ou posterior |
| Leste do Japão | 30 de janeiro de 2021 ou posterior |
| Coreia do Sul 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 |
| Catar Central | 25 de agosto de 2022 ou posterior |
| Norte da África do Sul | 7 de setembro de 2022 ou posterior |
| E.U.A. Centro-Sul | 30 de abril de 2021 ou posterior |
| Sudeste Asiático | 31 de janeiro de 2021 ou posterior |
| Suécia Central | 21 de janeiro de 2022 ou posterior |
| Norte da Suíça | 7 de setembro de 2022 ou posterior |
| Norte dos E.A.U. | 9 de setembro de 2022 ou posterior |
| Sul do Reino Unido | 30 de janeiro de 2021 ou posterior |
| US Gov - Virginia | 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 |
Nota
As zonas de disponibilidade não alteram os termos do Contrato de Nível de Serviço do Azure AI Search. Você ainda precisa de três ou mais réplicas para consultar a alta disponibilidade.
Vários serviços em regiões geográficas separadas
A redundância de serviço é necessária se os seus requisitos operacionais incluírem:
Requisitos de continuidade de negócios e recuperação de desastres (BCDR) (o Azure AI Search não fornece failover instantâneo se houver uma interrupção).
Desempenho rápido para um aplicativo distribuído globalmente. Se as solicitações de consulta e indexação vierem de todo o mundo, os usuários mais próximos do data center do host terão um desempenho mais rápido. Criar mais serviços em regiões com proximidade com esses usuários pode equalizar o desempenho para todos os usuários.
Se você precisar de dois ou mais serviços de pesquisa, criá-los em regiões diferentes pode atender aos requisitos do aplicativo para continuidade e recuperação, além de tempos de resposta mais rápidos para uma base global de usuários.
O Azure AI Search não fornece um método automatizado de replicação de índices de pesquisa entre regiões geográficas, mas existem algumas técnicas que podem tornar esse processo simples de implementar e gerenciar. Essas técnicas são descritas nas próximas seções.
O objetivo de um conjunto distribuído geograficamente de serviços de pesquisa é ter dois ou mais índices disponíveis em duas ou mais regiões, onde um usuário é roteado para o serviço Azure AI Search que fornece a menor latência:
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.
Gorjeta
Para obter ajuda na implantação de vários serviços de pesquisa em várias regiões, consulte este exemplo do Bicep no GitHub que implanta uma solução de pesquisa multirregional totalmente configurada. O exemplo oferece duas opções para sincronização de índice e redirecionamento de solicitação usando o Gerenciador de Tráfego.
Sincronize dados em vários serviços
Há duas opções para manter dois ou mais serviços de pesquisa distintos sincronizados:
- Extraia atualizações de conteúdo para um índice de pesquisa usando um indexador.
- Envie conteúdo por push para um índice usando a API Adicionar ou Atualizar Documentos (REST) ou uma API equivalente ao SDK do Azure.
Para configurar qualquer opção, recomendamos usar o script Bicep de exemplo no repositório azure-search-multiple-region , modificado para suas regiões e estratégias de indexação.
Opção 1: Usar indexadores para atualizar 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, extraindo dados do mesmo local. Cada serviço em cada região tem seu próprio indexador e um índice de destino (seu índice de pesquisa não é compartilhado, o que significa que cada índice tem sua própria cópia dos dados), mas cada indexador faz referência à mesma fonte de dados.
Aqui está um visual de alto nível de como seria essa arquitetura.
Opção 2: Usar APIs REST para enviar atualizações de conteúdo por push em vários serviços
Se você estiver usando a API REST do Azure AI Search para enviar conteúdo para seu índice de pesquisa, poderá manter seus vários serviços de pesquisa sincronizados enviando alterações para todos os serviços de pesquisa sempre que uma atualização for necessária. No 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.
Solicitações de consulta de failover ou redirecionamento
Se você precisar de redundância no nível da solicitação, o Azure fornece várias opções de balanceamento de carga:
- Azure Traffic Manager, usado para rotear solicitações para vários sites localizados geograficamente que, em seguida, são apoiados por vários serviços de pesquisa.
- Application Gateway, usado para balancear a carga entre servidores em uma região na camada de aplicativo.
- Azure Front Door, usado para otimizar o roteamento global de tráfego da Web e fornecer failover global.
Alguns pontos a ter em mente ao avaliar as opções de balanceamento de carga:
A pesquisa é um serviço de back-end que aceita solicitações de consulta e indexação de um cliente.
As solicitações do cliente para um serviço de pesquisa devem ser autenticadas. Para acessar operações de pesquisa, o chamador deve ter permissões baseadas em função ou fornecer uma chave de API na solicitação.
Os pontos de extremidade de serviço são alcançados por padrão por meio de uma conexão pública com a Internet. Se você configurar um ponto de extremidade privado para conexões de cliente originadas de uma rede virtual, use o Application Gateway.
O Azure AI Search aceita solicitações endereçadas ao ponto de
<your-search-service-name>.search.windows.netextremidade. Se você chegar ao mesmo ponto de extremidade usando um nome DNS diferente no cabeçalho do host, como um CNAME, a solicitação será rejeitada.
O Azure AI Search fornece um exemplo de implantação de várias regiões que usa o Gerenciador de Tráfego do Azure para redirecionamento de solicitação se o ponto de extremidade primário falhar. Essa solução é útil quando você encaminha para um cliente habilitado para pesquisa que chama apenas um serviço de pesquisa na mesma região.
O Azure Traffic Manager é usado principalmente para rotear o tráfego de rede entre diferentes pontos de extremidade com base em métodos de roteamento específicos (como prioridade, desempenho ou localização geográfica). Ele atua no nível DNS para direcionar as solicitações de entrada para o ponto de extremidade apropriado. Se um ponto de extremidade que o Gerenciador de Tráfego está atendendo começar a recusar solicitações, o tráfego será roteado para outro ponto de extremidade.
O Gerenciador de Tráfego não fornece um ponto de extremidade para uma conexão direta com a Pesquisa de IA do Azure, o que significa que você não pode colocar um serviço de pesquisa diretamente atrás do Gerenciador de Tráfego. Em vez disso, a suposição é que as solicitações fluem para o Gerenciador de Tráfego, depois para um cliente da Web habilitado para pesquisa e, finalmente, para um serviço de pesquisa no back-end. O cliente e o serviço estão localizados na mesma região. Se um serviço de pesquisa ficar inativo, o cliente de pesquisa começará a falhar e o Gerenciador de Tráfego redirecionará para o cliente restante.
Sobre a residência de dados em uma implantação de várias regiões
Quando você implanta vários serviços de pesquisa em várias regiões geográficas, seu conteúdo é armazenado na região escolhida para cada serviço de pesquisa.
O Azure AI Search não armazenará dados fora da sua região especificada sem a sua autorização. A autorização está implícita quando você usa recursos que gravam em um recurso de Armazenamento do Azure: cache de enriquecimento, sessão de depuração, armazenamento de conhecimento. Em todos os casos, a conta de armazenamento é aquela que você fornece, na região de sua escolha.
Nota
Se a conta de armazenamento e o serviço de pesquisa estiverem na mesma região, o tráfego de rede entre a pesquisa e o armazenamento usará um endereço IP privado e ocorrerá pela rede de backbone da Microsoft. Como os endereços IP privados são usados, não é possível configurar firewalls IP ou um ponto de extremidade privado para segurança de rede. Em vez disso, use a exceção de serviço confiável como alternativa quando ambos os serviços estiverem na mesma região.
Sobre interrupções de serviço e eventos catastróficos
Conforme declarado no Contrato de Nível de Serviço (SLA), a Microsoft garante um alto nível de disponibilidade para solicitações de consulta de índice quando uma instância de serviço do Azure AI 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 AI Search é configurada com três ou mais réplicas. No entanto, não há nenhum mecanismo interno 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 uma região diferente 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 preencher e atualizar índices podem lidar com a recuperação de desastres por meio de indexadores geoespecíficos que recuperam dados da mesma fonte de dados. Dois serviços em regiões diferentes, cada um executando um indexador, poderiam indexar a mesma fonte de dados para obter redundância geográfica. Se você estiver indexando a partir de fontes de dados que também são redundantes geograficamente, lembre-se de que os indexadores do Azure AI Search só podem executar indexação incremental (mesclando atualizações de documentos novos, modificados ou excluídos) a partir de réplicas primárias. Em um evento de failover, certifique-se de redirecionar o indexador para a nova réplica primária.
Se você não usa indexadores, você usaria o código do aplicativo para enviar objetos e dados para diferentes serviços de pesquisa em paralelo. Para obter mais informações, consulte Manter os dados sincronizados em vários serviços.
Fazer backup e restaurar alternativas
Uma estratégia de continuidade de negócios para a camada de dados geralmente inclui uma etapa de restauração a partir do backup. Como o Azure AI Search não é uma solução primária de armazenamento de dados, a Microsoft não fornece um mecanismo formal para backup e restauração de autoatendimento. No entanto, você pode usar o código de exemplo index-backup-restore neste repositório de exemplo do Azure AI Search .NET para fazer backup de sua definição de índice e instantâneo para uma série de arquivos JSON e, em seguida, 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 do aplicativo usado para criar e preencher um índice é a opção de restauração de fato se você excluir um índice por engano. Para reconstruir um índice, exclua-o (supondo que ele exista), recrie o índice no serviço e recarregue recuperando dados do seu armazenamento de dados primário.
Próximos passos
- Revise os limites de serviço para saber mais sobre os níveis de preços e limites de serviços para cada um.
- Revise Planejar a capacidade para saber mais sobre combinações de partição e réplica.
- Revise o estudo de caso: use a pesquisa cognitiva para dar suporte a cenários complexos de IA para obter mais orientação de configuração.