Vai al contenuto principale
BlogBasi di datiImplementare un sistema di gestione elettronica dei documenti basato sul cloud

Implementazione di un sistema di gestione elettronica dei documenti basato sul cloud

Altamente disponibile-EDMS-con-Mayan-e-PostgreSQL

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:

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)

  1. Author Photo

    How much those it cost to implement the mayan edms in a month and in a year.
    Your swift response is best appreciated

Lascia una risposta

Il vostro indirizzo e-mail non sarà pubblicato. I campi obbligatori sono contrassegnati da *