Per il lavoro quotidiano, l'archiviazione dei documenti avviene in genere tramite software di produttività online e cloud storage. Le difficoltà aumentano quando un'applicazione deve elaborare, archiviare e recuperare volumi maggiori. L'utilizzo di un sistema di gestione elettronica dei documenti (EDMS) è una soluzione migliore, in quanto sono progettati per archiviare, indicizzare e recuperare i documenti con prestazioni e disponibilità elevate, e alcuni includono funzioni come metadati personalizzabili e controllo delle versioni.
Sebbene siano disponibili molte soluzioni EDMS basate su SaaS, potete implementare il vostro EDMS open source per mantenere il controllo completo sui vostri dati. In questo post scoprirete come configurare un EDMS Maya ad alta disponibilità supportato da un database PostgreSQL.
Vantaggi dell'EDMS
Questa configurazione è ideale per chi archivia ed elabora un gran numero di documenti e ha bisogno di un EDMS collegato a un'applicazione basata sul Web, eliminando la necessità di installazioni lato client. La gestione di un EDMS come hub centrale garantisce:
- sicurezza, privacy e controllo totale dei vostri dati;
- facile integrazione con software di terze parti
- automazione dei flussi documentali per i processi aziendali.
Perché PostgreSQL?
PostgreSQL è un potente sistema open source di gestione di database relazionali a oggetti, molto apprezzato per la sua scalabilità, sicurezza e prestazioni. Per supportare la scalabilità end-to-end dell'applicazione, il database deve essere altamente disponibile, quindi questo esempio di architettura incorpora uno strumento di replica specifico per PostgreSQL.
Come iniziare con Mayan EDMS
Mayan è un EDMS open source basato sul web e scritto in Python. Mayan si installa ed esegue su un singolo sistema; tutti i componenti dell'applicazione e del database possono risiedere su un singolo server o all'interno di diversi container Docker. Sebbene questo sia ottimo per i test o per ambienti banali, per un ambiente di produzione vogliamo un'alta disponibilità e un concetto ampiamente conosciuto e adottato, noto come principio SoC (Separation of Concern). Si tratta di una best practice fondamentale per la costruzione di applicazioni stratificate e scalabili. Questa architettura di riferimento dimostra come farlo con Mayan.
Pro
- Open source significa nessun costo di licenza
- Archiviare, visualizzare e ripristinare facilmente le versioni dei documenti
- Ricerca full text dei documenti utilizzando metadati personalizzabili definiti dall'utente
- Controlli di accesso flessibili per progettare ruoli e autorizzazioni efficaci per gli utenti.
- Flussi di lavoro personalizzabili con trigger di eventi per mantenere aggiornati i documenti
Contro
- Complesso per i casi d'uso più piccoli
- L'interfaccia utente è meno intuitiva rispetto ad altre soluzioni
- Pesantezza delle risorse per le CPU che eseguono il riconoscimento ottico dei caratteri (OCR)
Architettura di riferimento dell'applicazione
Per ottimizzare le capacità di Mayan in applicazioni reali, la nostra architettura utilizza:
- NGINX: Server web
- Prometheus & Grafana: Strumenti di monitoraggio e osservabilità
- PostgreSQL: Database
- Bucardo: replica bidirezionale del database PostgreSQL
- Linode Object Storage: S3- storage compatibile e altamente disponibile
- keepalived: Failover IP
Un NodeBalancer distribuisce il traffico ai nostri nodi applicativi. Se un server applicativo si guasta, il servizio di bilanciamento del carico inizierà a dirigere il traffico solo verso il nodo sano. Non appena il nodo non sano si riprende, riprende il bilanciamento delle connessioni come prima. In questo modo è facile aggiungere, rimuovere o aggiornare i server applicativi senza tempi di inattività, mantenendo le connessioni ai nodi del database PostgreSQL.
Per il "cervello" dell'applicazione, Mayan e NGINX sono distribuiti sulle stesse macchine virtuali e possiamo sfruttare il supporto di Mayan per s3boto3 come backend di archiviazione per caricare i nostri documenti sull'Object Storage compatibile con S3 di Linode.
Se la vostra applicazione è mission-critical e utilizza PostgreSQL come database di backend primario, l'integrazione di Bucardo offre una migliore garanzia di uptime e rende il database tollerante ai guasti.
È anche possibile ottenere l'alta disponibilità e la replica con un servizio di database gestito che supporta PostgreSQL, ma tenete presente che la maggior parte delle offerte DBaaS si concentra sull'aggiornamento delle versioni di PostgreSQL e sul mantenimento del cluster di database online e disponibile. L'implementazione di Bucardo fornisce al database PostgreSQL una replica bidirezionale tra due o più nodi di database, garantendo l'alta disponibilità del database.
In questo esempio, tutti i nodi sono protetti da firewall cloud per la protezione da Internet e comunicano internamente tramite VLAN private. I server applicativi si collegano ai database tramite un indirizzo IP condiviso su VLAN flottante con keepalived per facilitare il failover.
Keepalived, o un altro sistema di failover IP come FRRouting (FRR), è implementato a livello di database in modo che un nodo di database sano sia collegato al cluster dei nodi applicativi.
Ottenere la tolleranza ai guasti per i file critici
Un EDMS funge spesso da hub centrale per le operazioni quotidiane e ospita alcuni dei file più critici dell'organizzazione. La nostra applicazione è costruita con ridondanza ad ogni livello per garantire la tolleranza ai guasti e ottimizzare le prestazioni:
- I documenti sono archiviati nell'Object Storage altamente disponibile di Linode.
- Il database si trova su un nodo separato per aumentare le prestazioni ed evitare un singolo punto di guasto.
- Bucardo esegue la replica automatica del database tra i nodi Postgres.
Esplora altri contenuti tecnici e architetture
Il nostro team di Solutions Engineering condivide framework, guide e strumenti come questo per facilitare agli sviluppatori la creazione di applicazioni che seguono le migliori pratiche per l'architettura del software. Consultate la nostra architettura di riferimento del cluster Galera per un'architettura MySQL/MariaDB ad alta disponibilità, oppure sfogliate gli esempi di architettura di riferimento disponibili su Linode Docs.
Commenti (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.