Better be safe than sorry: Backup-Möglichkeiten der NiFi Registry

Die NiFi Registry, als Sub-Projekt von Apache NiFi, eignet sich hervorragend, um Dataflows zu versionieren. Änderungen in Dataflows lassen sich nachvollziehen und es gibt eine Commit-Historie mit entsprechenden Commit-Nachrichten. Aus diesen und weiteren Gründen haben wir uns bereits in einem vorherigen Blogartikel für die Registry ausgesprochen. Doch wenn alle Dataflows in der Registry gespeichert werden, stellt sich zwangsläufig die Frage: Was passiert mit den Daten, wenn die Registry ausfällt und welche Backup-Möglichkeiten bietet uns die Registry?

Diese Frage werden wir in folgendem Blogartikel beantworten und Ihnen Wege aufzeigen, wie Sie die Registry sichern können.

Was, wie und wo? Grundsätzliches über die Registry

Die NiFi Registry nutzt sogenannte PersistenceProvider. Darüber kann definiert werden, wo die Flows abgelegt werden sollen. Zusätzlich zu den Flows arbeitet die Registry mit Metadaten. Dazu gehören die Namen und zusätzliche Details der Buckets und Flows. Diese Metainformationen werden separat von den Flows in einer Datenbank gespeichert. Dazu aber später mehr …

In der Registry kann zwischen drei verschiedenen PersistenceProvider gewählt werden:

1. FileSystemFlowPersistenceProvider
2. GitFlowPersistenceProvider
3. DatabaseFlowPersistenceProvider

Beim DatabaseFlowPersistenceProvider handelt es sich nicht um die Metadatenbank. Stattdessen können auch dort die Flows gesichert werden.

Oldie but goldie: Das Dateisystem

Out-of-the-box ist der FileSystemFlowPersistenceProvider aktiviert. Dieser speichert die Flows und Buckets einfach im Dateisystem, üblicherweise im Ordner flow_storage, ab. Die Struktur sieht dabei wie folgt aus: 

Flow Storage Directory/
├── {bucket-id}/
│   └── {flow-id}/
│       ├── {version}/{version}.snapshot
└── d1beba88-32e9-45d1-bfe9-057cc41f7ce8/
    └── 219cf539-427f-43be-9294-0644fb07ca63/
        ├── 1/1.snapshot
        └── 2/2.snapshot
 

Für jeden Bucket wird ein Ordner mit der jeweiligen Bucket-ID erstellt. Das ist nicht sehr übersichtlich, aber funktional.

Die einfachste Form einer Sicherung von einer Registry, die im Dateisystem verwaltet wird? Ein Backup des entsprechenden Ordners! Das kann über klassische Linux-Methoden geschehen oder der Ordner wird über einen Netzwerkshare eingebunden, denn hohe Performance-Ansprüche hat die Registry nicht! 

Habe ich "git" gehört?

Wir haben gesehen, ein Backup des Dateisystems ist nicht sonderlich anspruchsvoll. Geht es besser?

Absolut! Die Registry unterstützt ebenfalls den GitFlowPersistenceProvider. Hierbei werden die Flows zunächst ebenfalls auf dem lokalen Dateisystem abgespeichert. Der Unterschied zur ersten Methode und gleichzeitig ein Vorteil: Die Flows können direkt auf einen Remote Git-Server gepushed werden. Dazu zählen alle großen Anbieter wie GitHub, GitLab, BitBucket. Prinzipiell kann aber jeglicher Server genutzt werden, der das "git"-Kommando unterstützt.

Zusätzlich werden die Dateien auf dem Dateisystem übersichtlicher verwaltet und es kann direkt erkannt werden, welcher Flow, zu welchem Bucket gehört:

Flow Storage Directory/
├── .git/
├── Bucket_A/
│   ├── bucket.yml
│   ├── Flow_1.snapshot
│   └── Flow_2.snapshot
└── Bucket_B/
    ├── bucket.yml
    └── Flow_4.snapshot
 

Was bedeutet das nun konkret?

Wenn der GitProvider konfiguriert ist, wird bei jedem Commit in der NiFi UI zeitgleich ein Commit im darunterliegenden Git-Repository gemacht. Dabei wird die komplette Commit-Message aus NiFi genutzt und zusätzlich wird der User protokolliert.

Zusätzlich kann eine automatische Push-Funktion aktiviert werden, sodass jeder Commit direkt auf den Server gepusht wird.

Die großen Git Hoster, wie GitHub, GitLab oder BitBucket bieten neben dem reinen Speichern der Daten viele weitere Möglichkeiten wie eine CI/CD-Integration oder automatische Sicherheitschecks gegen verwendete Pakete. Dazu bieten sie auch alle eine übersichtliche UI, mit der beispielsweise die Commit-Historie sehr schön als Graph dargestellt werden kann. Dadurch lassen sich die verschiedenen Dataflow-Versionen und die getätigten Änderungen abermals besser nachverfolgen.

Viel wichtiger ist jedoch die Ticket-Integration. Bei BitBucket mit Jira, oder GitLab mit Issues lassen sich Querverweise zwischen Commits und den Tickets erstellen. Soll also ein neues Feature implementiert werden oder wird ein Bug gelöst werden, kann in der Commit-Nachricht von NiFi einfach die Ticketnummer notiert werden. Dadurch gibt es im Ticket automatisch einen Verweis auf den Commit im Repository.

Und was ist mit dem Backup?

Wird der GitProvider verwendet, um die Flows zu speichern und die automatische Push-Funktion auf das Remote-Repository ist aktiviert, müssen Sie bestenfalls gar nichts weiter tun. Die großen Anbieter wie GitLab und GitHub sichern die Repositories bereits redundant. Nutzen Sie einen unternehmensinternen Git-Server, wird dieser mit großer Sicherheit auch schon gesichert. Fragen Sie im Zweifel aber bei dem zuständigen Team nach!

Verzichten Sie auf die automatische Push-Funktion. So werden die Dataflows genau wie beim FileSystemFlowPersistenceProvider im lokalen Dateisystem gespeichert, nur in einem anderen Format. Sie müssen sich also eine eigene Backup-Strategie überlegen, oder Sie nutzen die gleiche wie für den FileSystemFlowPersistenceProvider. 

Ab in die Datenbank!

Zuletzt gibt es die Möglichkeit, die Dataflows in einer Datenbank zu speichern. Das bietet sich immer dann an, wenn im Unternehmen schon ein Datenbankserver läuft und dieser über Backup- und Hochverfügbarkeitsmechansimen verfügt.

Prinzipiell werden drei verschiedene Datenbanksysteme unterstützt: H2, PostgreSQL (10.x - 13.x) und MySQL (8.0).

Die Konfiguration ist einfach gehalten. Wenn dieser Provider ausgewählt wird, werden in der Datenbank auch die Metadaten gespeichert. Daher gibt es nur eine Einstellung, die für die Metadaten.

Die Einstellungen für eine PostgreSQL sehen in der nifi-registry.properties beispielsweise wie folgt aus: 

nifi.registry.db.url=jdbc:postgresql://<POSTGRES-HOSTNAME>/nifireg
nifi.registry.db.driver.class=org.postgresql.Driver
nifi.registry.db.driver.directory=/path/to/drivers
nifi.registry.db.username=nifireg
nifi.registry.db.password=changeme
 

Es werden also die Datenbank-URL, der Datenbank-Driver, die Klasse sowie User und Passwort benötigt. 

Metadaten über Metadaten …

Wir haben zu Beginn erwähnt, dass NiFi auch Metadaten speichert. Dazu gehören zum Beispiel die verschiedenen Buckets mit ihren IDs und den Flows.

Diese Daten werden standardmäßig in einer H2-Datenbank auf dem lokalen Dateisystem gespeichert. Wird der FileSystemFlowPersistenceProvider für die Flows und die H2-Datenbank für die Metadaten genutzt, müssen beide gesichert werden.

Am einfachsten ist es allerdings, wenn der Git- oder DatabaseFlowPersistenceProvider genutzt wird.

Wird die Git-Variante verwendet, kann sich die Registry die Metadaten bei der Wiederherstellung aus den Repository-Daten holen. Die Metadaten müssen also nicht extra gesichert werden. Bei der Datenbankvariante werden, wie oben beschrieben, die Flows und die Metadaten in einer Datenbank gespeichert. Auch hier muss sich nicht extra um die Metadaten gekümmert werden.

Also?

Wir empfehlen, die Registry auf jeden Fall zu sichern. Das kann entweder über den Git- oder über den Datenbankprovider geschehen. Gibt es bereits eine hochverfügbare und gesicherte Datenbank, so spricht nichts dagegen, diese auch als PersistenceProvider zu nutzen.

Allerdings hat sich in der Praxis gezeigt, dass vor allem die Ticketintegration mit Jira oder Issues ein sehr empfehlenswertes Feature ist. Damit bekommen die Flows und Versionen eine noch bessere Nachvollziehbarkeit.

Haben Sie spezielle Fragen zu den Backup-Strategien, oder generell zu Themen rund um Apache NiFi? Dann sprechen Sie uns gerne an! 

Seminarempfehlungen