{"id":93878,"date":"2020-09-10T19:42:02","date_gmt":"2020-09-10T17:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie"},"modified":"2020-09-10T19:42:02","modified_gmt":"2020-09-10T17:42:02","slug":"kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie","title":{"rendered":"Come integrare PostgreSQL \"libero\" in un rigido ambiente enterprise","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Molti conoscono il database PostgreSQL, che ha dimostrato di essere efficace in installazioni di piccole dimensioni. Tuttavia, la tendenza a passare all'Open Source \u00e8 diventata sempre pi\u00f9 evidente, anche per le grandi aziende e le esigenze enterprise. In questo articolo, parleremo di come integrare Postgres in un ambiente aziendale e condivideremo la nostra esperienza nella creazione di un sistema di backup (SRK) per questo database, utilizzando come esempio il sistema di backup Commvault. <\/p>\n

\"Come
\nPostgreSQL ha gi\u00e0 dimostrato il suo valore: il database funziona bene, \u00e8 utilizzato da aziende digitali rinomate come Alibaba e TripAdvisor, e l'assenza di costi di licenza lo rende un'alternativa attraente a giganti come MS SQL o Oracle DB. Tuttavia, quando iniziamo a considerare PostgreSQL nel contesto Enterprise, ci imbattiamo immediatamente in requisiti rigorosi: \"Come gestiamo la resilienza della configurazione? La recovery da disastri? Dove si trova il monitoraggio completo? Il backup automatizzato? L'uso delle librerie a nastro sia direttamente che come storage secondario?\"
\n<\/a><\/noindex>
\n\"Come
\nDa un lato, PostgreSQL non ha strumenti di backup integrati come i database 'maturi' RMAN di Oracle DB o SAP Database Backup. Dall'altro, i fornitori di sistemi di backup aziendale (Veeam, Veritas, Commvault) supportano PostgreSQL, ma in realt\u00e0 lavorano solo con configurazioni specifiche (di solito standalone) e con una serie di limitazioni. <\/p>\n

Sistemi di backup appositamente progettati per PostgreSQL, come Barman, Wal-g, pg_probackup, sono estremamente popolari in installazioni di piccole dimensioni o dove non sono richiesti pesanti backup di altri elementi del panorama IT. Ad esempio, oltre a PostgreSQL, nell'infrastruttura possono esserci sistemi fisici e virtuali, OpenShift, Oracle, MariaDB, Cassandra, ecc. \u00c8 preferibile eseguire backup con uno strumento comune. Utilizzare una soluzione separata esclusivamente per PostgreSQL \u00e8 una cattiva idea: i dati verrebbero copiati su disco per poi essere trasferiti su nastro. Questa duplicazione del backup aumenta il tempo di backup e, cosa pi\u00f9 critica, il tempo di ripristino. server<\/a>In una soluzione enterprise, il backup dell'installazione avviene su un certo numero di nodi di un cluster dedicato. Tuttavia, ad esempio, Commvault funziona solo con un cluster a due nodi in cui Primary e Secondary sono rigidamente assegnati a nodi specifici. Ha senso effettuare il backup solo dal Primary, dato che il backup dal Secondary presenta le sue limitazioni. A causa delle caratteristiche del database, il dump non viene creato sul Secondary, quindi rimane solo l'opzione del backup a livello di file.<\/p>\n

Per ridurre il rischio di inattivit\u00e0, nella creazione di un sistema di failover viene creata una configurazione cluster 'viva', e il Primary pu\u00f2 migrare gradualmente tra diversi server. Ad esempio, il software Patroni avvia il Primary su un nodo randomizzato del cluster. Il SRK non ha modo di monitorare questo 'out-of-the-box', e se la configurazione cambia, i processi si rompono. Cio\u00e8, l'implementazione di una gestione esterna ostacola il corretto funzionamento del SRK, poich\u00e9 il server di gestione non comprende quali dati copiare e da quale fonte.<\/p>\n

Un'altra problematica riguarda la realizzazione del backup in Postgres. \u00c8 possibile tramite dump, e per piccole basi funziona. Ma nelle grandi basi, il dump richiede tempo, molte risorse e pu\u00f2 portare a un crash dell'istanza del database.<\/p>\n

Il backup a livello di file migliora la situazione, ma sulle grandi basi \u00e8 lento, poich\u00e9 funziona in modalit\u00e0 single-threaded. Inoltre, i fornitori impongono una serie di limitazioni aggiuntive. Si pu\u00f2 non utilizzare contemporaneamente il backup a livello di file e il backup a livello di dump, oppure non si supporta la deduplicazione. Ci sono molte problematiche, e spesso \u00e8 pi\u00f9 semplice scegliere un costoso ma collaudato DB rispetto a Postgres.<\/p>\n

Non si pu\u00f2 tornare indietro! Mosca \u00e8 alle spalle della squadra di sviluppatori!<\/p>\n

Tuttavia, recentemente il nostro team si \u00e8 trovato di fronte a una sfida difficile: nel progetto di creazione del SIS OSAGO 2.0, dove abbiamo sviluppato l'infrastruttura IT, gli sviluppatori hanno scelto PostgreSQL per il nuovo sistema.<\/h2>\n

\nPer i grandi sviluppatori di software, utilizzare soluzioni open-source 'alla moda' \u00e8 molto pi\u00f9 semplice. Nel personale di Facebook ci sono abbastanza specialisti che mantengono il funzionamento di questo database. Nel caso dell'RSA, tutte le attivit\u00e0 'del secondo giorno' gravavano sulle nostre spalle. Ci \u00e8 stato richiesto di garantire la resilienza, costruire un cluster e, naturalmente, impostare il backup. La logica delle azioni era la seguente: <\/p>\n

Insegnare al SRK a effettuare il backup dalla nodo Primary del cluster. Per questo, il SRK deve trovarlo \u2014 quindi \u00e8 necessaria un'integrazione con qualche soluzione di gestione del cluster PostgreSQL. Nel caso dell'RSA, \u00e8 stato utilizzato il software Patroni. <\/p>\n