Descubra as cargas de trabalho do Oracle Database em NetApp Backup and Recovery
Descubra as cargas de trabalho do Oracle Database no NetApp Backup and Recovery para que você possa protegê-las com backups e Snapshots.
Função necessária do NetApp Console superadministrador de backup e recuperação. Saiba mais "Funções e privilégios de backup e recuperação". "Saiba mais sobre as funções de acesso do NetApp Console para todos os serviços".
Configurar DNS para descoberta de hosts isolados da internet na implantação local do NetApp Console
Se você estiver usando a implantação local do NetApp Console em um ambiente isolado (air-gapped) onde os hosts do banco de dados não são acessíveis por meio de DNS padrão, você deve modificar temporariamente a configuração interna do CoreDNS do RKE2. Isso permite que os pods resolvam nomes de host específicos para endereços IP dentro do cluster, de forma semelhante à adição de entradas em /etc/hosts em um nó.
|
|
Antes de efetuar alterações, verifique a configuração existente do CoreDNS para evitar sobrescrever quaisquer personalizações já feitas. Utilize os manifestos RKE2 para aplicar essa alteração, garantindo que ela seja gerenciada de forma consistente pelo operador e pelo runtime do RKE2. |
-
Mantenha o arquivo HelmChartConfig sob controle de alterações sempre que possível.
-
Use um nome de arquivo claro para que a finalidade da substituição do CoreDNS fique óbvia.
-
Se o registro DNS esperado não estiver visível no Corefile, verifique os logs do servidor RKE2 e confirme a sintaxe do arquivo de manifesto.
-
Verifique a configuração existente do CoreDNS para garantir que você não esteja sobrescrevendo uma alteração já existente:
kubectl -n kube-system get cm rke2-coredns-rke2-coredns -o jsonpath='{.data.Corefile}' -
Copie o seguinte bloco de comando e edite a área
configBlockpara adicionar seus registros DNS estáticos. Isso cria um arquivo YAML HelmChartConfig na pasta de manifestos do RKE2, que o RKE2 aplica automaticamente para substituir a configuração do CoreDNS:sudo tee /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml >/dev/null <<'YAML' apiVersion: helm.cattle.io/v1 kind: HelmChartConfig metadata: name: rke2-coredns namespace: kube-system spec: # NOTE: This is a HelmChartConfig that *overlays* values onto the rke2-coredns # HelmChart already managed by RKE2. RKE2 watches /var/lib/rancher/rke2/server/manifests # and will re-render the rke2-coredns Helm release whenever this file changes. # # The `servers:` list below REPLACES the chart's default server definition, # so every plugin that was in the stock Corefile must be present here. # Do NOT delete plugins you don't recognize -- they are required for cluster DNS. valuesContent: |- servers: - zones: - zone: . port: 53 plugins: - name: errors - name: health configBlock: |- lameduck 10s - name: ready - name: kubernetes parameters: cluster.local in-addr.arpa ip6.arpa configBlock: |- pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 # ───────────────────────── EDIT BELOW ───────────────────────── # Static DNS records for hosts the corporate DNS cannot resolve. # Format: <IP> <FQDN> [optional aliases...] # `fallthrough` MUST stay as the last line -- it lets every other # name go to the upstream resolver via the `forward` plugin below. - name: hosts configBlock: |- 1.2.3.4 example.domain.com exampleshortname fallthrough # ───────────────────────── EDIT ABOVE ───────────────────────── - name: prometheus parameters: 0.0.0.0:9153 - name: forward parameters: . /etc/resolv.conf - name: cache parameters: 30 - name: loop - name: reload - name: loadbalance YAML sudo chmod 600 /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml -
Verifique se o CoreDNS detectou a alteração:
kubectl -n kube-system get cm rke2-coredns-rke2-coredns -o jsonpath='{.data.Corefile}'Se a alteração não estiver visível após alguns minutos, reinicie a implantação do CoreDNS e verifique o Corefile novamente:
kubectl -n kube-system rollout restart deploy/rke2-coredns-rke2-coredns -
Se você precisar remover as entradas depois de descobrir os hosts do banco de dados, faça o seguinte:
-
Exclua o arquivo HelmChartConfig da pasta de manifestos.
-
Reinicie a implementação do CoreDNS:
kubectl -n kube-system rollout restart deploy/rke2-coredns-rke2-coredns
-
Adicione um host do Oracle Database e descubra recursos
Adicione as informações do host do banco de dados Oracle e permita que o NetApp Backup and Recovery descubra as cargas de trabalho. Para cada agente do Console, selecione os sistemas a serem descobertos.
-
No menu NetApp Console, selecione Proteção > Backup e Recuperação.
-
Em Cargas de trabalho, selecione o bloco Oracle.
-
Selecione Descobrir recursos.
-
Selecione Oracle para o campo Tipo de carga de trabalho.
-
Se você ainda não armazenou credenciais para este host Oracle Database, selecione Adicionar credenciais.
-
Selecione o agente do Console a ser usado com este host.
-
Digite um nome para esta credencial.
-
Digite o nome de usuário e a senha da conta.
-
Selecione Concluído.
-
-
Registro do host: Adicione um novo host do Oracle Database. No campo Nome de domínio totalmente qualificado (FQDN) ou endereço IP do host, insira o FQDN ou o endereço IP do host. Para bancos de dados em cluster, você pode inserir o FQDN ou o endereço IP de qualquer nó do cluster. Em seguida, forneça as credenciais, o agente do Console e o número da porta.
-
(Opcional) Se você escolher credenciais para um usuário que não seja root, faça o seguinte:
-
Para obter instruções sobre como adicionar o usuário não root selecionado ao arquivo sudoers no host do Oracle Database, selecione Configurar sudoers.
-
Siga as instruções na caixa de diálogo, marque a caixa de seleção quando terminar e selecione Done.
-
-
Configurações avançadas: faça o seguinte:
-
Insira a porta e o caminho de instalação a serem usados para o NetApp plug-in. O plug-in permite a comunicação entre o host do Oracle Database e NetApp Backup and Recovery.
-
Escolha se deseja permitir que o NetApp Backup e recuperação instale o plug-in automaticamente em cada host ou ignorar a instalação automática do plug-in para todos os hosts. Selecione Mostrar como para obter instruções de instalação manual.
NetApp Backup e recuperação se conecta a cada host via SSH para instalar o plug-in automaticamente. Habilite Usar instalação manual quando qualquer uma das seguintes condições se aplicar:
-
Um ou mais hosts não estão executando o serviço SSH.
-
Qualquer host já possui o NetApp plug-in (inclusive se apenas alguns membros do cluster o tiverem).
-
Você prefere instalar o plug-in em cada host manualmente.
-
-
Se o host do banco de dados estiver em cluster, habilite a opção Adicionar todos os hosts no cluster para descobrir todos os hosts no cluster.
-
Escolha se deseja executar verificações de pré-instalação em cada host antes de instalar automaticamente o plug-in. Se as verificações falharem, a instalação automática do plug-in será interrompida. Para ignorar as verificações e instalar mesmo assim, habilite Ignorar verificações de pré-instalação opcionais (habilitado automaticamente se você escolher instalação manual).
-
-
Selecione Descobrir.
A adição de recursos pode levar vários minutos. Para ver o progresso, selecione Acompanhar progresso na caixa de diálogo de status na parte inferior da página de Inventário ou selecione Monitoramento na navegação à esquerda.
A carga de trabalho do Oracle Database aparece na lista de cargas de trabalho na página de inventário.
Continue para o Painel de NetApp Backup and Recovery
-
No menu NetApp Console, selecione Proteção > Backup e Recuperação.
-
Selecione um bloco de carga de trabalho (por exemplo, Oracle Database).
-
No menu Backup e Recuperação, selecione Painel.
-
Analise o estado da proteção de dados. O número de cargas de trabalho em risco ou protegidas aumenta com base nas cargas de trabalho recém-descobertas, protegidas e com backup realizado.