Open Source Dokumentenmanagement
Dokumentation
Durchsuchbare Dokumentation aufrufen | Zurück zur Dokumentationsübersicht
Navigation: Dokumentationen agorum core > agorum core sichern und wiederherstellen > Historie und Versionierung von Dokumenten > agorum core storage
agorum core storage konfigurieren
Das Modul aktivieren
Um agorum core storage zu verwenden, aktivieren Sie das Modul zuerst über das agorum core support tool. Starten Sie danach den agorum core-Server neu.
Parameter konfigurieren
Nach der Aktivierung des Moduls stellen Sie grundlegende Parameter im agorum core support tool ein.
- Öffnen Sie links in der Seitenleiste Weitere Apps und dann Support tool.
- Wählen Sie links im Menü Storage > Storage configuration.
Hinweis: Wenn Sie zusätzlich agorum core sync 2.0 verwenden und die Sync-Server auf das gleiche Storage zugreifen sollen, müssen Sie bei der Konfiguration bestimmte Punkte beachten (siehe undefined>agorum core sync 2.0).
Folgende Parameter können Sie konfigurieren:
| Parameter | Beschreibung |
|---|---|
| ChunkExpirationTime | Definiert die Zeit in Sekunden, in der Datenblöcke aufbewahrt werden, bevor sie agorum core storage löscht, nachdem ein Löschvorgang in agorum core für diese Objekte durchgeführt wurde. Ein Minimum von 86400 Sekunden (1 Tag) ist Pflicht, um die Transaktionskonsistenz sicherzustellen. Hinweis: Der Parameter ChunkExpirationTime ist bei der gemeinsamen Nutzung in einer Clusterlösung essenziell. Durch sie kann sichergestellt werden, dass der Content im agorum core storage so lange vorliegt, bis alle beteiligten Server die Änderung oder Löschung des Objekts durch den agorum core sync 2.0 mitbekommen haben. Wählen Sie einen Wert, der sicherstellt, dass alle Cluster-Server innerhalb dieser Zeit synchronisiert wurden und die Information erhalten haben. Des Weiteren ist dieser Parameter je nach Backup-Szenario entsprechend zu setzen, um Datenverlust zu vermeiden. Prinzipiell gilt, dass der Wert des Parameters größer sein muss als die Dauer des Full-Back-ups. |
| VerificationEnabled | Definiert, ob das System im Hintergrund auf die Konsistenz der ausgelagerten Daten prüft. |
| VerificationThrottleDelay | Definiert die Zeit in Millisekunden, die das System wartet, bis es das nächste Objekt prüft. Im Standard 200 Millisekunden (entspricht ca. 4 Datenblöcke/s). Durch diese Bremsung wird die Systembelastung verringert.
Achtung: Beeinträchtigung der Systemleistung durch einen Wert von 0. Das System arbeitet bei diesem Wert nur noch langsam. Verwenden Sie einen solchen Wert nur kurzfristig, etwa zur Prüfung bei Problemen mit dem agorum core storage. |
Das Modul konfigurieren
- Öffnen Sie links in der Seitenleiste Weitere Apps und dann Storage.
- Klicken Sie oben rechts im Abschnitt Konfiguration auf das Ordnersymbol
Neu > Back-End-Konfiguration. - Wählen Sie eine der folgenden Treiberklassen aus.
Lokales Dateisystem
Für Filesystem-Storages empfohlen, da dieser Treiber performant ist.
Amazon S3
Funktioniert nur, wenn die Festplatte Amazon Simple Storage Service (Amazon S3) eingesetzt wird.
Ceph S3
Funktioniert nur, wenn eine Ceph-Festplatte (Ceph-Storage) eingesetzt wird (siehe Ceph-Treiber konfigurieren).
MySQL
Für Testzwecke gedacht, nicht für den produktiven Einsatz. - Geben Sie die Daten zur Treiberklasse ein.
Daten zur Treiberklasse eingeben
Hinweis: Die Einstellungen Deduplizierung und Synchrone Deduplizierung sind bei jedem Treiber vorhanden. Setzen Sie dort den Haken nur, wenn Sie die Parameter VerificationEnabled sowie De-duplication aktiviert haben.
| Feld / Parameter | Beschreibung |
|---|---|
| Treiber | Definiert die Treiberklasse. |
| Deduplizierung | Überprüft den im agorum core storage gelagerten Content auf Duplikate und löscht diese. |
| Synchrone Deduplizierung | Aktiviert Das System verwendet die synchrone Deduplizierung. Deaktiviert Das System verwendet die asynchrone Deduplizierung. |
| Basisordner | Definiert den Storage-Basisordner. Dieser Ordner muss auf dem Betriebssystem liegen. |
Zugangsdaten und Speicherkapazität prüfen
Um zu prüfen, ob die eingetragenen Zugangsdaten korrekt sind und das Backend über ausreichend Speicherkapazität verfügt, gehen Sie folgendermaßen vor:
- Klicken Sie im Dialog Back-End-Konfiguration rechts auf Info.
Ergebnis: Ein weiterer Dialog öffnet sich, der die Speicherbelegung auf dem agorum core storage darstellt.
• Ist Ihr Backend korrekt konfiguriert, erhalten Sie eine grafische Information zur Speicherkapazität.
• Bei fehlerhaften Eingaben erhalten Sie eine entsprechende Fehlermeldung, wie folgende Abbildung beispielhaft zeigt.
Den Content auslagern (einlagern)
Hinweis: Durch den Einsatz eines Workers arbeitet das System die definierten agorum core storage Backends von oben nach unten a. Dabei gilt, dass eine später gesetzte Regel früher gesetzte Regeln teilweise oder vollständig außer Kraft setzen kann.
Beispiel
Wenn auf Files/Bereich 1/Unterbereich 1 die Definition Storage A gesetzt wird und danach auf Files die Definition Storage B, so gilt die zuletzt gesetzte Regel, hier Storage B. Die Definition mit Storage A hat keine Auswirkung mehr und wird nicht angewendet.
Beim Setzen von verschiedenen Konfigurationen sollten die Ordner idealerweise der Tiefe nach von oben nach unten abgearbeitet werden.
So lagern Sie Content auf dem Storage aus:
- Öffnen Sie links in der Seitenleiste Weitere Apps und dann Storage.
- Rufen Sie links im Bereich Ordner das gewünschte Verzeichnis auf.
- Klicken Sie bei einem Eintrag in die Spalte Back-End.
- Wählen Sie die gewünschte Back-End-Konfiguration.
- Klicken Sie in einen leeren Bereich.
- Bestätigen Sie die Abfrage.
Hinweis: Die Auslagerung beginnt rekursiv (aber nicht unbedingt in der Reihenfolge der Ordnertiefe) unmittelbar ab Zuweisung des Backends.
Hinweis: Die Ordnersymbole färben sich blau, wenn eine Back-End-Konfiguration eingetragen ist.
Backup und Restore
Die ausgelagerten Dateien müssen unabhängig vom Backup der agorum core-Datenbank gesichert werden.
- Das Storage ist so konstruiert, dass die zeitliche Sicherung des Storages auch nach der Sicherung der Datenbank erfolgen kann und nicht unbedingt gleichzeitig geschehen muss.
- Das Storage muss immer zeitlich gleichzeitig oder nach der Datenbank gesichert wird und nie vor der Datenbank-Sicherung.
- Der Unterschied zwischen der Sicherung des Storages und der Datenbank darf nicht mehrere Tage betragen, sondern maximal wenige Stunden.
Neben dem Backend an sich muss auch der Ordner mit dem backendtransaction-Handling unter folgendem Pfad gesichert werden:
Je nach Infrastruktur kann das Backup etwa mit einem täglichen Snapshot oder einer inkrementellen Sicherung nach folgendem Schema realisiert werden:
- Vollsicherung am Wochenende
- tägliche inkrementelle Sicherung an den Folgetagen der Woche
Achten Sie bei einem Restore darauf, dass der Datenbankstand zum Stand des Storages passt. Der Datenbankstand darf nicht neuer und nur im Rahmen des konfigurierten Parameters ChunkExpirationTime älter sein als der Stand des Storages. Welches Backup-Verfahren ideal für Ihr System und Ihre Arbeitsweise ist, klären Sie mit einem Spezialisten.