Skip to main content
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Entdecken Sie Oracle-Datenbank-Workloads in NetApp Backup and Recovery

Beitragende netapp-mwallis
Änderungen vorschlagen
PDFs

Oracle Database Workloads in NetApp Backup und Recovery erkennen, um sie mit Backups und Snapshots zu schützen.

Erforderliche NetApp Console-Rolle Backup and Recovery Superadministrator. Informationen zu "Backup und Recovery Rollen und Berechtigungen". "Erfahren Sie mehr über die Zugriffsrollen der NetApp Console für alle Dienste".

DNS für die Erkennung von Hosts in isolierten Umgebungen in der lokalen NetApp Console-Bereitstellung konfigurieren

Wenn die NetApp Console lokal in einer abgeschotteten Umgebung bereitgestellt wird, in der Datenbankhosts nicht über das Standard-DNS erreichbar sind, ist eine temporäre Anpassung der internen RKE2 CoreDNS-Konfiguration erforderlich. So können Pods bestimmte Hostnamen innerhalb des Clusters in IP-Adressen auflösen, ähnlich wie das Hinzufügen von Einträgen zu /etc/hosts auf einem Knoten.

Wichtig Vor Änderungen sowohl die bestehende CoreDNS-Konfiguration als auch die bestehende rke2-coredns-config.yaml HelmChartConfig prüfen, um ein Überschreiben vorhandener Anpassungen zu vermeiden. Auf den meisten NetApp Console lokalen Bereitstellungsknoten ist diese Datei bereits vorhanden und enthält bereits Ressourcenanforderungen. Wenn die Datei bereits existiert, sollte sie nicht neu erstellt werden, sondern lediglich der servers: Block an die bestehende valuesContent angehängt werden. Diese Änderung wird mit RKE2-Manifests angewendet, sodass sie weiterhin konsistent vom RKE2 Operator und der Laufzeitumgebung verwaltet wird.
Bevor Sie beginnen

  • Die HelmChartConfig-Datei sollte nach Möglichkeit unter Änderungskontrolle stehen.

  • Ein eindeutiger Dateiname sorgt dafür, dass der Zweck der CoreDNS Override offensichtlich ist.

  • Falls der erwartete DNS-Eintrag in der Corefile nicht sichtbar ist, sollten die RKE2-Serverprotokolle überprüft und die Syntax der Manifestdatei bestätigt werden.

Schritte

  1. Die bestehende CoreDNS-Konfiguration sollte daraufhin geprüft werden, ob keine bestehende Änderung überschrieben wird:

    kubectl -n kube-system get cm rke2-coredns-rke2-coredns -o jsonpath='{.data.Corefile}'

  2. Es wird überprüft, ob die HelmChartConfig-Datei existiert:

    sudo cat /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml
    Falls die Datei existiert

    1. Das folgende Skript fügt den servers: Block an die bestehende HelmChartConfig Datei an:

      MANIFEST=/var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml

# 1. Back up first
sudo cp -a "$MANIFEST" "$MANIFEST.bak.$(date +%Y%m%d-%H%M%S)"

# 2. Safety checks: valuesContent must be the last key, no servers: block yet
grep -n 'servers:' "$MANIFEST"        # must return nothing
tail -c 1 "$MANIFEST" | od -c | head  # file must end with a newline

# 3. Append ONLY the servers block (nothing above it changes)
sudo tee -a "$MANIFEST" >/dev/null <<'YAML'
    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

# 4. Confirm the merged result
sudo cat "$MANIFEST"

    2. Es sollte sichergestellt sein, dass die einzige Änderung an der HelmChartConfig-Datei das Hinzufügen des servers: Blocks ist.

    Wenn die Datei nicht existiert

    1. Bearbeiten Sie den configBlock Bereich des folgenden Skripts und fügen Sie Ihre statischen DNS-Einträge hinzu. Dadurch wird eine HelmChartConfig YAML-Datei im RKE2-Manifeste-Ordner erstellt, die RKE2 automatisch anwendet, um die CoreDNS-Konfiguration zu überschreiben:

      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

    2. Das Skript kopieren und ausführen.

  3. Es wird geprüft, ob CoreDNS die Änderung übernommen hat:

    kubectl -n kube-system get cm rke2-coredns-rke2-coredns -o jsonpath='{.data.Corefile}'

    Wenn die Änderung nach einigen Minuten nicht sichtbar ist, die CoreDNS-Bereitstellung neu starten und anschließend die Corefile erneut überprüfen:

    kubectl -n kube-system rollout restart deploy/rke2-coredns-rke2-coredns

  4. Falls Sie die Einträge entfernen müssen, nachdem Sie die Datenbank-Hosts entdeckt haben, gehen Sie wie folgt vor:

    Wenn Sie eine bestehende Datei erweitert haben

    1. Die gesicherte Datei wiederherstellen oder nur den servers: Block aus der Datei löschen:

      sudo cp -a /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml.bak.<timestamp> \
/var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml

      Die Datei sollte nicht gelöscht werden, da sie die vorhandene RKE2 Ressourceneinstellungen enthält.

    2. Nach dem Wiederherstellen der Datei die Host-Einträge entfernen. Veraltete Einträge können Probleme bei der Host-Erkennung und geplanten Backups verursachen.

    3. Die CoreDNS-Bereitstellung wird neu gestartet:

      kubectl -n kube-system rollout restart deploy/rke2-coredns-rke2-coredns
    Wenn Sie eine neue Datei erstellt haben

    1. Die HelmChartConfig-Datei aus dem Manifeste-Ordner löschen:

      sudo rm /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml

    2. Nach dem Löschen der Datei die Host-Einträge entfernen. Veraltete Einträge können Probleme bei der Host-Erkennung und geplanten Backups verursachen.

    3. Die CoreDNS-Bereitstellung wird neu gestartet:

      kubectl -n kube-system rollout restart deploy/rke2-coredns-rke2-coredns

Fügen Sie einen Oracle Database-Host hinzu und entdecken Sie Ressourcen

Fügen Sie die Hostinformationen der Oracle-Datenbank hinzu und lassen Sie NetApp Backup and Recovery die Workloads erkennen. Für jeden Console-Agenten werden die zu erkennenden Systeme ausgewählt.

Schritte

  1. Im NetApp Console-Menü Schutz > Backup und Recovery auswählen.

  2. Wählen Sie unter Workloads die Kachel Oracle aus.

  3. Wählen Sie Ressourcen entdecken.

  4. Wählen Sie Oracle für das Feld Workload type aus.

  5. Wenn Sie noch keine Anmeldeinformationen für diesen Oracle Database-Host gespeichert haben, wählen Sie Add credentials.

    1. Wählen Sie den Konsolenagenten aus, der mit diesem Host verwendet werden soll.

    2. Geben Sie einen Namen für diese Anmeldeinformationen ein.

    3. Geben Sie den Benutzernamen und das Kennwort für das Konto ein.

    4. Wählen Sie Fertig.

  6. Hostregistrierung: Einen neuen Oracle Database Host hinzufügen. Im Feld Host-FQDN oder IP-Adresse den FQDN oder die IP-Adresse des Hosts eingeben. Für Clusterdatenbanken kann der FQDN oder die IP-Adresse eines beliebigen Knotens im Cluster eingegeben werden. Anschließend Anmeldeinformationen, den Console Agent und die Portnummer angeben.

  7. (Optional) Wenn Sie Anmeldeinformationen für einen Nicht-Root-Benutzer auswählen, führen Sie Folgendes aus:

    1. Anweisungen zum Hinzufügen des ausgewählten Nicht-Root-Benutzers zur sudoers-Datei auf dem Oracle Database Host finden Sie unter Configure sudoers.

    2. Folgen Sie den Anweisungen im Dialog, aktivieren Sie das Kontrollkästchen, wenn Sie fertig sind, und wählen Sie Fertig.

  8. Erweiterte Einstellungen: Führen Sie Folgendes aus:

    1. Geben Sie den Port und den Installationspfad für das NetApp Plug-in ein. Das Plug-in ermöglicht die Kommunikation zwischen dem Oracle-Datenbankhost und NetApp Backup and Recovery.

    2. Wählen Sie, ob NetApp Backup und Recovery das Plug-in automatisch auf jedem Host installieren oder die automatische Plug-in-Installation für alle Hosts überspringen soll. Wählen Sie Anleitung anzeigen, um Anweisungen zur manuellen Installation zu erhalten.

      Hinweis

      NetApp Backup und Recovery verbindet sich per SSH mit jedem Host, um das Plug-in automatisch zu installieren. Manuelle Installation verwenden ist zu aktivieren, wenn einer der folgenden Punkte zutrifft:

      • Auf einem oder mehreren Hosts läuft der SSH-Dienst nicht.

      • Auf jedem Host ist das NetApp Plug-in bereits vorhanden (auch wenn es nur auf einigen Cluster-Mitgliedern vorhanden ist).

      • Sie bevorzugen es, das Plug-in auf jedem Host manuell zu installieren.

    3. Wenn der Datenbankhost in einem Cluster organisiert ist, aktivieren Sie die Option Alle Hosts im Cluster hinzufügen, um alle Hosts im Cluster zu ermitteln.

    4. Wählen Sie, ob vor der automatischen Installation des Plug-ins auf jedem Host Vorabprüfungen durchgeführt werden sollen. Schlagen die Prüfungen fehl, wird die automatische Plug-in-Installation gestoppt. Um die Prüfungen zu umgehen und das Plug-in trotzdem zu installieren, aktivieren Sie Optionale Vorabprüfungen überspringen (automatisch aktiviert, wenn Sie die manuelle Installation wählen).

  9. Wählen Sie Entdecken.

    Tipp Das Hinzufügen von Ressourcen kann einige Minuten dauern. Der Fortschritt ist im Statusdialog unten auf der Inventarseite unter Fortschritt verfolgen oder in der linken Navigation unter Überwachung einsehbar.
Ergebnis

Die Oracle Database Workload erscheint in der Workload-Liste auf der Inventarseite.

Weiter zum NetApp Backup and Recovery Dashboard

  1. Im NetApp Console-Menü Schutz > Backup und Recovery auswählen.

  2. Eine Workload-Kachel auswählen (z. B. Oracle Database).

  3. Wählen Sie im Menü „Sichern und Wiederherstellen“ die Option „Dashboard“ aus.

  4. Der Zustand des Datenschutzes wird angezeigt. Die Anzahl der gefährdeten oder geschützten Workloads erhöht sich entsprechend den neu erkannten, geschützten und gesicherten Workloads.