Bei der täglichen Arbeit erfolgt die Speicherung von Dokumenten in der Regel über Online-Produktivitätssoftware und Cloudspeicher. Es wird schwieriger, wenn eine Anwendung größere Mengen verarbeiten, speichern und abrufen muss. Ein elektronisches Dokumentenmanagementsystem (EDMS) ist die bessere Lösung, da es für die Speicherung, Indizierung und den Abruf von Dokumenten mit hoher Leistung und Verfügbarkeit konzipiert ist und einige Funktionen wie anpassbare Metadaten und Versionskontrolle enthält.
Es gibt zwar viele SaaS-basierte EDMS-Lösungen, aber Sie können auch Ihr eigenes Open-Source-EDMS einsetzen, um die vollständige Kontrolle über Ihre Daten zu behalten. In diesem Beitrag erfahren Sie, wie Sie ein hochverfügbares Mayan-EDMS einrichten, das auf einer PostgreSQL-Datenbank basiert.
EDMS-Vorteile
Diese Konfiguration ist ideal, wenn Sie eine große Anzahl von Dokumenten speichern und verarbeiten und ein EDMS benötigen, das mit einer webbasierten Anwendung verbunden ist, so dass keine clientseitigen Installationen erforderlich sind. Der Betrieb eines EDMS als zentrale Drehscheibe gewährleistet:
- Sicherheit, Datenschutz und vollständige Kontrolle über Ihre Daten;
- einfache Integration mit Software von Drittanbietern; und
- Automatisierung von Dokumenten-Workflows für Geschäftsprozesse.
Warum PostgreSQL?
PostgreSQL ist ein leistungsstarkes, objektrelationales Open-Source-Datenbankmanagementsystem, das für seine Skalierbarkeit, Sicherheit und Leistung sehr geschätzt wird. Um eine durchgängige Skalierung für Ihre Anwendung zu unterstützen, muss Ihre Datenbank auch hochverfügbar sein. Daher enthält dieses Architekturbeispiel ein Replikationstool speziell für PostgreSQL.
Erste Schritte mit Mayan EDMS
Mayan ist ein webbasiertes Open-Source-EDMS, das in Python geschrieben ist. Mayan wird standardmäßig auf einem einzigen System installiert und ausgeführt; alle Ihre Anwendungs- und Datenbankkomponenten können auf einem einzigen Server oder in mehreren Docker-Containern laufen. Obwohl dies für Tests oder triviale Umgebungen großartig ist, wollen wir für eine Produktionsumgebung hohe Verfügbarkeit und ein weithin bekanntes und angenommenes Konzept, das als SoC-Prinzip (Separation of Concern) bekannt ist. Dies ist eine wichtige Best Practice für den Aufbau von mehrschichtigen und skalierbaren Anwendungen. Diese Referenzarchitektur zeigt, wie man das mit Mayan erreicht.
Profis
- Open Source bedeutet keine Lizenzgebühren
- Einfaches Speichern, Anzeigen und Zurücksetzen von Dokumentversionen
- Volltextsuche in Dokumenten mit anpassbaren benutzerdefinierten Metadaten
- Flexible Zugriffskontrollen zur Gestaltung effektiver Benutzerrollen und Berechtigungen
- Anpassbare Workflows mit Ereignisauslösern, um Dokumente auf dem neuesten Stand zu halten
Nachteile
- Komplex für kleinere Anwendungsfälle
- Die Benutzeroberfläche ist weniger intuitiv als bei anderen Lösungen
- Ressourcenintensiv für CPUs mit optischer Zeichenerkennung (OCR)
Referenzarchitektur der Anwendung
Um die Fähigkeiten von Mayan in einer realen Anwendung zu optimieren, nutzt unsere Architektur:
- NGINX: Webserver
- Prometheus & GrafanaMonitoring und Beobachtungstools
- PostgreSQL: Datenbank
- Bucardo: PostgreSQL bi-direktionale Datenbankreplikation
- Linode-Objektspeicher: S3-kompatibler und hochverfügbarer Speicher
- keepalived: IP-Ausfallsicherung
Ein NodeBalancer verteilt den Datenverkehr auf unsere Anwendungsknoten. Wenn ein Anwendungsserver ausfällt, leitet der Lastausgleichsdienst den Datenverkehr nur an den gesunden Knoten weiter. Sobald sich der kranke Knoten wieder erholt hat, wird die Verteilung der Verbindungen wie zuvor fortgesetzt. Dies macht es einfach, Anwendungsserver ohne Ausfallzeiten hinzuzufügen, zu entfernen oder zu aktualisieren, während die Verbindungen zu den PostgreSQL-Datenbankknoten aufrechterhalten werden.
Für das "Gehirn" der Anwendung werden Mayan und NGINX auf denselben virtuellen Maschinen eingesetzt und wir können Mayans Unterstützung für s3boto3 als Speicher-Backend nutzen, um unsere Dokumente auf Linodes S3-kompatibles Object Storage hochzuladen.
Wenn Ihre Anwendung geschäftskritisch ist und PostgreSQL als primäre Backend-Datenbank verwendet, bietet die Integration von Bucardo eine bessere Betriebszeitgarantie und macht Ihre Datenbank fehlertolerant.
Sie können Hochverfügbarkeit und Replikation auch mit einem verwalteten Datenbankservice erreichen, der PostgreSQL unterstützt, aber bedenken Sie, dass die meisten DBaaS-Angebote sich darauf konzentrieren, PostgreSQL-Versionen zu aktualisieren und Ihren Datenbank-Cluster online und verfügbar zu halten. Durch die Implementierung von Bucardo erhält Ihre PostgreSQL-Datenbank eine bidirektionale Replikation zwischen zwei oder mehr Datenbankknoten, wodurch eine hohe Verfügbarkeit Ihrer Datenbank gewährleistet wird.
In diesem Beispiel sind alle Knoten mit Cloud-Firewalls zum Schutz vor dem öffentlichen Internet gesichert und kommunizieren intern über private VLAN. Die Anwendungsserver stellen die Verbindung zu den Datenbanken über eine gemeinsame schwebende VLAN IP-Adresse mit keepalived her, um die Ausfallsicherung zu erleichtern.
Keepalived oder ein anderes IP-Failover-System wie FRRouting (FRR) wird auf der Datenbankebene implementiert, so dass ein gesunder Datenbankknoten mit dem Cluster Ihrer Anwendungsknoten verbunden wird.
Erreichen von Fehlertoleranz für kritische Dateien
Ein EDMS dient oft als zentraler Knotenpunkt für den täglichen Betrieb und hostet einige der wichtigsten Dateien Ihres Unternehmens. Unsere Anwendung ist auf jeder Ebene redundant ausgelegt, um eine grundlegende Fehlertoleranz und optimale Leistung zu gewährleisten:
- Die Dokumente werden auf Linode's hochverfügbarem Object Storage gespeichert.
- Die Datenbank befindet sich auf einem separaten Knoten, um die Leistung zu erhöhen und einen Single Point of Failure zu vermeiden.
- Bucardo führt eine automatische Datenbankreplikation zwischen den Postgres-Knoten durch.
Entdecken Sie weitere technische Inhalte und Architekturen
Unser Solutions Engineering Team stellt Frameworks, Leitfäden und Tools wie dieses zur Verfügung, um Entwicklern die Erstellung von Anwendungen zu erleichtern, die den Best Practices für Software-Architektur folgen. Schauen Sie sich unsere Galera-Cluster-Referenzarchitektur für eine hochverfügbare MySQL/MariaDB-Architektur an, oder durchsuchen Sie unsere verfügbaren Referenzarchitekturbeispiele auf Linode Docs.
Kommentare (2)
How much those it cost to implement the mayan edms in a month and in a year.
Your swift response is best appreciated
If you’re using the Terraform script in our guide , you will deploy four 2GB compute instances ($48.00) and an Object Storage Bucket ($5.00). Additionally, as mentioned in the guide, you will want to deploy an additional node for Prometheus and Grafana ($5.00) as well as a NodeBalancer ($10.00). These services together would be roughly $68.00/month before taxes. This is assuming the amount of data your Object Storage was not more than 250GB and you stayed within your Network Transfer Allowance. Again, based on these assumptions, your yearly cost would be roughly $812.00.
You have the option to edit the Terraform script and change the default compute instance to a Nanode, however, I can’t guarantee the performance of the deployment with that plan.