Plano de Resiliência
Sua empresa ou organização possui requisitos específicos para uma integração de dados de ressubmissão. Planeje o tempo para planejar uma arquitetura de integração que atenda aos seus requisitos em seus particulars, antes de começar a criar detalhes.
Determinar Requisitos de Resiliência
Antes de explorar o que fará com que seu ambiente resiliente, primeiro é necessário definir o que a resiliência significa que você e sua empresa. Em outras palavras, qual é o custo associado a uma paralisação do processo de integração?
Para alguns clientes, uma interrupção de alguns minutos é aceitável e só atrasará parcialmente um processo em lote executado bem dentro de sua janela de processamento. Para outros clientes, mesmo alguns segundos de paralisação do sistema resultam em perdas financeiras que têm impacto direto no negócio.
A partir dessa perspectiva, é importante examinar os seguintes elementos:
- Qual é a duração de uma paralisação aceitável no seu ambiente? Aqui você deve definir o custo para o negócio no caso de uma paralisação do sistema e descreve como essa paralisação evoluirá com a duração da paralisação.
- Quais tecnologias são usadas e como elas podem entregar no nível esperado de serviço? Você está usando uma abordagem em tempo real ou em lote? Ou uma combinação dos dois? Quantos dados você está processando?
Definir uma Arquitetura Resiliente
Definir uma arquitetura resiliente requer a verificação da solução completa de integração de dados.
No caso de um processo de integração, você precisa considerar os seguintes componentes da arquitetura (hardware e software):
- Resiliência do sistema de origem
- Resiliência do sistema de destino
- Resiliência da área de preparação se qualquer uma for usada
- Resiliência das ferramentas de integração de dados
- Resiliência da orquestração (se estiver fora da ferramenta ETL)
- Resiliência da rede (de uma perspectiva de conectividade e de largura de banda)
Você também deve considerar os requisitos em termos de Recuperação de Desastres e Alta Disponibilidade. O que acontece se você perder o data center em que esta infraestrutura está instalada?
Os seguintes elementos são obrigatórios para que a instalação do Oracle Data Integrator seja resiliente:
- Seus agentes precisam ser redundantes: os agentes de JEE são projetados para oferecer resiliência na qual um balanceador de carga distribuirá a carga entre os agentes.
- O repositório do Oracle Data Integrator precisa estar em execução em um sistema resiliente: uma instalação do Oracle RAC ou Exadata seria um requisito mínimo, para que a perda de um nó não Média a perda da infraestrutura completa. Para implantações do Oracle Cloud, a Oracle Database Exadata Cloud Service fornece uma solução resiliente.
- Se você estiver usando um produto externo para orquestrar os processos do Oracle Data Integrator ( Oracle Integration para instância), é necessário certificar-se de que esse produto também seja resiliente.
Se você estiver considerando uma estratégia de Recuperação de Desastres, os mesmos elementos descritos acima serão obrigatórios, portanto, será necessário certificar-se de que:
- Você tem uma cópia (recente o suficiente) do repositório do Oracle Data Integrator em seu site DR para que você possa continuar executando seus processos do Oracle Data Integrator.
- Você tem agentes Oracle Data Integrator disponíveis nesse site DR para acessar este repositório.
- Você tem acesso aos sistemas de origem e de destino ou acesso a uma cópia dos sistemas de origem e de destino.
Para o Oracle Data Integrator especificamente, haverá dois elementos da topologia que devem ser validados:
- O endereço IP ou o nome do servidor do Repositório de Trabalho do Oracle Data Integrator é armazenado no Repositório Mestre do Oracle Data Integrator. Se o nome ou o endereço IP for alterado quando você estiver alternando para o seu site DR, é necessário certificar-se de que essas informações sejam atualizadas antes de iniciar o Oracle Data Integrator.
- O endereço IP ou o nome do servidor para os sistemas de origem e destino são armazenados no repositório de Trabalho. Há duas estratégias possíveis:
- Defina contextos separados para cada ambiente (principal e DR) que permita que você tenha duas definições de servidor físico distintas para cada unidade lógica.
- Ou substitua o endereço IP ou os nomes do servidor antes de iniciar o Oracle Data Integrator no site DR.
- Em todos os casos, qualquer script usando o SDK que substitui informações nos repositórios do Oracle Data Integrator deve ter um script reverso para restaurar as informações no site principal.
Planejar Cargas Iniciais e Sucessos
As chances serão necessárias para projetar um processo um pouco diferente para a carga inicial do sistema de destino, antes de você se concentrar nos carregamentos regulares (como quase em tempo real ou diários).
Essa situação é considerada, se você quiser se proteger contra interrupções futuras imprevistas, é crucial manter e manter esses processos de carga iniciais. A capacidade de reexecutar uma carga inicial (ou uma carga inicial parcial) nunca deve estar subordinada, especialmente quando se encaixar nas seguintes situações:
- Um flaw principal foi descoberto na validade dos dados carregados (dados ausentes, fórmula inválida no ETL etc.).
- Uma grande paralisação ocorre no sistema-alvo, resultando em perda de dados em massa.
- Por algum motivo, os processos de integração não podem ser executados por um período muito longo.
Ter a capacidade de executar cargas iniciais - veja também a capacidade de instanciar novos ambientes.
Você também pode aprimorar essas estratégias de carregamento com a capacidade de reaplicar um carregamento anterior (como um mês anterior de dados). Isso exigiria uma combinação de uma limpeza parcial dos dados carregados, além de uma carga parcial.