Differenze

Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.

--- utenti:extraway_platform_server:extraway_overview [2023/03/21 11:22] – [Note sullo Spreader] chiara.pavanati
+++ utenti:extraway_platform_server:extraway_overview [2023/03/21 11:53] (versione attuale) – [Glossario, Acronimi e Note] chiara.pavanati
@@ Linea 616: / Linea 616: @@
 Poi fa altrettanto con **FO2** e con **FO3**. Avendo superato "la metà" dei server disponibili sul Front Office, lo **Spreader** richiede all'**Arbiter**, con un'operazione atomica, di porre in "stand by" le **macchine FO4** ed **FO5** e di riportare "on line" **FO1**, **FO2** ed **FO3** che essendo tutte aggiornate ed in "maggioranza" possono meglio servire l'utenza.
-Di seguito provvede a compiere l'aggiornamento su **FO4* ed **FO5** richiedendo che vengano poste "on line" appena aggiornate per rimpinguare il **pool** di **macchine disponibili** all'utenza.
+Di seguito provvede a compiere l'aggiornamento su **FO4** ed **FO5** richiedendo che vengano poste "on line" appena aggiornate per rimpinguare il **pool** di **macchine disponibili** all'utenza.
 Se nel **procedimento** descritto una **macchina** risulta non raggiungibile, spenta, precedentemente posta in "stand by" e non rimessa "on line" a causa di un **errore** di **aggiornamento**, lo **Spreader** stabilisce quale sia la **combinazione migliore** di **macchine** da lasciare "on line" per garantire il miglior **servizio** al **miglior stato d'avanzamento**. Se le **macchine FO** sono allineate in modo diverso, il **delta** che viene calcolato comprende il **materiale** necessario a condurle tutte allo stato d'**aggiornamento** corrente anche  a costo di applicare aggiornamenti già applicati in parte (senza con questo impattare sulla **validità** degli **archivi**).
@@ Linea 622: / Linea 622: @@
 ==== Estensione degli Scenari, il Disaster Recovery ====
-Gli scenari, semplici e complessi, sin ora descritti consentono di costruire una struttura con diversi livelli di sicurezza già in essa. Ad esempio, un Back Office separato e configurato con un Cluster è ragionevolmente solido ed ha un Back Up naturale nel Front Office. Una struttura che preveda più Front Office ha in essa una sicurezza intrinseca di continuità del servizio.
+Gli **scenari**, semplici e complessi, sin ora descritti consentono di costruire una **struttura** con diversi **livelli** di **sicurezza** già in essa. Ad esempio, un **Back Office** separato e configurato con un **Cluster** è ragionevolmente solido ed ha un **back up** naturale nel **Front Office**. Una **struttura** che preveda **più Front Office** ha in essa una **sicurezza** intrinseca di continuità del **servizio**.
-Se a questi scenari vogliamo affiancare un ulteriore livello di sicurezza entriamo nell'ambito del "Disaster Recovery" per il quale valgono le considerazioni già fatte negli scenari descritti. Anche in quel caso possono essere ipotizzati scenari semplici e complessi per il nodo “secondario” indipendenti dalla configurazione data a quello "primario".
+Se a questi **scenari** vogliamo affiancare un ulteriore livello di **sicurezza** entriamo nell'ambito del **Disaster Recovery** per il quale valgono le considerazioni già fatte negli scenari descritti. Anche in quel caso possono essere ipotizzati scenari semplici e complessi per il **nodo “secondario”** indipendenti dalla **configurazione** data a quello "primario".
-Esso consiste, solitamente, nella replicazione dell'hardware (nella forma più opportuna) e di tutti i dati disponibili ed allineati in una struttura differente. Per "struttura", in questo caso, facciamo riferimento "fisicamente" ad un luogo diverso, servito differentemente sia dal punto di vista elettrico che per ogni altro aspetto logistico.
+Esso consiste, solitamente, nella **replicazione** dell'**hardware** (nella forma più opportuna) e di tutti i **dati** disponibili ed allineati in una **struttura** differente. Per struttura, in questo caso, facciamo riferimento fisicamente ad un luogo diverso, servito differentemente sia dal **punto** di **vista elettrico** che per ogni altro aspetto **logistico**.
-Quello che può essere replicato in questa differente struttura è un qualsiasi scenario "minore o uguale" a quello primario che può essere mantenuto allineato con degli automatismi con cadenza giornaliera o con quella ritenuta più opportuna.
+Quello che può essere replicato in questa differente **struttura** è un qualsiasi **scenario** "minore o uguale" a quello primario che può essere mantenuto allineato con degli **automatismi** con **cadenza giornaliera** o con quella ritenuta più opportuna.
-Gli strumenti a disposizione, dal trasferimento e l'applicazione di un backup all'uso dello Spreader, consentono di avere un allineamento ragionevolmente "fresco" della copia presso la struttura secondaria ed essa può essere concepita come sola salvaguardia dei dati (quindi una copia fedele del Back Office consultabile) sia come una completa replicazione della configurazione primaria.
+Gli **strumenti** a disposizione, dal trasferimento e l'applicazione di un **backup** all'uso dello **Spreader**, consentono di avere un **allineamento** ragionevolmente "fresco" della copia presso la **struttura secondaria** ed essa può essere concepita come sola **salvaguardia** dei dati (quindi una copia fedele del Back Office consultabile) sia come una completa **replicazione** della **configurazione primaria**.
-Anche se per il "nodo primario" si fosse scelta una configurazione minima in essa dovrebbe trovare posto per lo meno uno spreader che provvederà a mantenere aggiornata una delle replicazioni che seguono.
+Anche se per il **nodo primario** si fosse scelta una **configurazione minima** in essa dovrebbe trovare posto per lo meno uno **spreader** che provvederà a mantenere aggiornata una delle **replicazioni** che seguono.
-La replicazione dello scenario dovrebbe essere integrale. La replicazione integrale va vista come la riproduzione, presso diversa struttura, di una configurazione minima o scalata come dagli scenari descritti. Essa può essere una versione "ridotta" (ovvero priva di scalatura orizzontale o verticale o con una scalatura ridotta) di quella primaria ma comunque pienamente funzionante.
+La **replicazione** dello **scenario** dovrebbe essere **integrale**. La replicazione integrale va vista come la **riproduzione**, presso diversa **struttura**, di una **configurazione** minima o scalata come dagli scenari descritti. Essa può essere una **versione** "ridotta" (ovvero priva di scalatura orizzontale o verticale o con una scalatura ridotta) di quella primaria ma comunque pienamente funzionante.
-Tramite spreader (considerando il BackOffice dell'installazione "secondaria" al pari di un Front Office da aggiornare da parte del nodo "primario") si può mantenere aggiornato il secondo nodo ed in esso si provvederà, se anche il nodo secondario è scalato verticalmente, ad aggiornare il proprio Front Office avvalendosi di un'installazione “locale” dello spreader.
+Tramite **spreader** (considerando il BackOffice dell'installazione "secondaria" al pari di un Front Office da aggiornare da parte del nodo "primario") si può mantenere aggiornato il secondo **nodo** ed in esso si provvederà, se anche il **nodo secondario** è scalato verticalmente, ad aggiornare il proprio **Front Office** avvalendosi di un'**installazione “locale”** dello spreader.
-In caso il nodo "secondario" venga chiamato in causa per indisponibilità del "primario" esso prevederà un ambiente completo che consentirà di proseguire tanto nell'attività redazionale quanto in quella di fruizione del sistema mantenendo eventualmente distinte le due realtà.
+In caso il **nodo secondario** venga chiamato in causa per indisponibilità del **primario** esso prevederà un **ambiente** completo che consentirà di proseguire tanto nell'**attività redazionale** quanto in quella di fruizione del **sistema** mantenendo eventualmente distinte le due **realtà**.
 __Si tratta attualmente dello scenario più completo ed esaustivo__.
-Possono essere presi in esame altri scenari in cui il nodo "secondario" ha una replicazione parziale del nodo "primario", replicando in esso il solo Back Office o il solo Front Office.
+Possono essere presi in esame altri scenari in cui il **nodo secondario** ha una replicazione parziale del **nodo primario**, replicando in esso il solo **Back Office** o il solo **Front Office**.
 ==== Conclusioni ====
-Concludendo, gli scenari che si possono realizzare sono stati ampiamente descritti e possono essere ottenuti combinando in vario modo le possibilità esposte. La scelta sulla configurazione più opportuna deve tenere in considerazione due fattori evidenti: la scalabilità orizzontale garantisce di adeguarsi alle performance richieste dal sistema in virtù del carico di lavoro previsto sulla base dell'utenza che ne farà uso, potenzialità in parte ottenibile anche con la scalabilità verticale, ma rispetto a quest'ultima offre tipicamente maggiori risultati e da garanzie di continuità nell'erogazione del servizio che la sola scalabilità verticale non può offrire.
+Concludendo, gli **scenari** che si possono realizzare sono stati ampiamente descritti e possono essere ottenuti combinando in vario modo le **possibilità** esposte. La scelta sulla **configurazione** più opportuna deve tenere in considerazione due **fattori** evidenti: la **scalabilità orizzontale** garantisce di adeguarsi alle performance richieste dal sistema in virtù del **carico** di **lavoro** previsto sulla base dell'utenza che ne farà uso, potenzialità in parte ottenibile anche con la **scalabilità verticale**, ma rispetto a quest'ultima offre tipicamente maggiori risultati e da **garanzie** di **continuità** nell'**erogazione** del **servizio** che la sola scalabilità verticale non può offrire.
-L'unico reale vincolo si ha nella realizzazione di un Cluster per il DataBase Server del BO (o globale se non v'è distinzione tra le due parti) in quanto non è possibile adottare una configurazione in Load Balancing ma solo in Fault Tollerance per lo meno sino a quando alcune limitazioni esistenti nella piena accessibilità delle risorse condivise non saranno superate dei produttori di hardware e software di base.\\
+L'unico reale **vincolo** si ha nella realizzazione di un **Cluster** per il **DataBase Server** del BO (o globale se non v'è distinzione tra le due parti) in quanto non è possibile adottare una **configurazione** in **Load Balancing** ma solo in **Fault Tollerance** per lo meno sino a quando alcune **limitazioni** esistenti nella piena **accessibilità** delle **risorse condivise** non saranno superate dei **produttori** di **hardware** e **software** di base.
-Questo, per lo meno, sulla base dell'esperienza sino ad ora accumulata in proposito.
+Questo, per lo meno, sulla base dell'**esperienza** sino ad ora accumulata in proposito.
 ==== Gli sviluppi futuri ====
-Se il documento ha raggiungo lo scopo, il lettore avrò ora un quadro sufficientemente chiaro di cosa si possa realizzare con il software della 3D Informatica ed in particolare saprà comprendere quale tra gli scenari descritti potrà soddisfare pienamente le proprie esigenze.\\
+Se il **documento** ha raggiungo lo **scopo**, il **lettore** avrà ora un **quadro** sufficientemente chiaro di cosa si possa realizzare con il **software** della 3D Informatica ed in particolare saprà comprendere quale tra gli **scenari descritti** potrà soddisfare pienamente le proprie **esigenze**.
-Oltre a ciò il lettore avrà anche compreso come il modificarsi del carico di lavoro o delle esigenze di fruizione delle informazioni nell'arco del tempo non trovino in eXtraWay un limite bensì un valido alleato, pronto a modellare le proprie capacità al servizio del più importante degli obiettivi che accomunano 3D Informatica e coloro che ne hanno scelto la tecnologia: fornire un servizio solido e performante che unisca un'ampia fruibilità delle informazioni alle tecniche più adatte per garantire la massima sicurezza dei dati stessi.
+Oltre a ciò il **lettore** avrà anche compreso come il modificarsi del **carico** di **lavoro** o delle esigenze di **fruizione** delle **informazioni** nell'arco del tempo non trovino in **eXtraWay** un **limite** bensì un valido alleato, pronto a modellare le proprie **capacità** al **servizio** del più importante degli **obiettivi** che accomunano 3D Informatica e coloro che ne hanno scelto la **tecnologia**: fornire un **servizio solido** e performante che unisca un'ampia **fruibilità** delle **informazioni** alle tecniche più adatte per garantire la massima **sicurezza** dei **dati** stessi.
+Questo è quanto abbiamo voluto fare sino ad ora ma certo possiamo fare molto di più. Per venire ulteriormente incontro alle **esigenze** della **clientela** ci sono **progetti** che riteniamo degni di essere presi in esame, anche se parte di essi non vedrà la luce se non tra diverso tempo.
-Questo è quanto abbiamo voluto fare sino ad ora ma certo possiamo fare molto di più. Per venire ulteriormente incontro alle esigenze della clientela ci sono progetti che riteniamo degli di essere presi in esame, anche se parte di essi non vedrà la luce se non tra diverso tempo.\\
 Tra essi ci preme sottolineare:
 === Hot Backup ===
-Tra le esigenze che ci sono state spesso esposte c'è quella di poter compiere backup senza causare una effettiva interruzione dei servizi, garantendo quanto meno la consultazione delle informazioni contenute nei Data Base.\\
+Tra le esigenze che ci sono state spesso esposte c'è quella di poter compiere **backup** senza causare una effettiva **interruzione** dei **servizi**, garantendo quanto meno la **consultazione** delle **informazioni** contenute nei Data Base.
-Una simile modalità consiste in un congelamento effettuato direttamente dallo strato più basso, ovvero il DataBase Server, delle sole funzionalità di modifica così da consentire la copia e quindi il salvataggio della fotografia del Data Base in un dato momento senza con questo inibire la consultazione. In uno scenario ideale un parco utenti anche molto vasto è in realtà composto da una minoranza che ha funzioni di redazione ed una maggioranza che invece si limita alla fruizione dei Data Base. Lo scenario proposto consentirebbe quindi di limitare l'operato solo di una minoranza.
+Una simile modalità consiste in un **congelamento** effettuato direttamente dallo **strato** più basso, ovvero il **DataBase Server**, delle sole funzionalità di **modifica** così da consentire la **copia** e quindi il **salvataggio** della fotografia del Data Base in un dato momento senza con questo inibire la **consultazione**. In uno scenario ideale un parco utenti anche molto vasto è in realtà composto da una minoranza che ha funzioni di **redazione** ed una maggioranza che invece si limita alla **fruizione** dei **Data Base**. Lo scenario proposto consentirebbe quindi di limitare l'**operato** solo di una minoranza.
 === Scalabilità Orizzontale del Tier DataBase Server ===
-Questo è tra i progetti più ambiziosi ma, al contempo, uno dei più importanti.\\
+Questo è tra i **progetti** più **ambiziosi** ma, al contempo, uno dei più importanti.
-Nei diversi scenari che sono stati presentati, specie in quelli complessi, è stato più volte posto in evidenza come la scalabilità verticale sia sempre garantita mentre quella orizzontale si riferisca esclusivamente ai primi due livelli del software in quanto attuali limiti tecnologici impediscono di garantire scalabilità sul livello che insiste sui Data Base.\\
-Al fine di superare questo vincolo con il pieno rispetto delle diverse piattaforme su cui eXtraWay può essere installato (ed in considerazione di costituire anche installazioni scalate su hardware di diversa tipologia che si avvalgano di Sistemi Operativi diversi) esiste un progetto di realizzazione di un servizio di sincronizzazione e locking delle basi dati da installare parallelamente ad eXtraWay su tutti i server coinvolti nel cluster. A tale servizio verrebbe demandato il compito di garantire un accesso sempre corretto e, la dove necessario, esclusivo unendo le esigenze del Back Office con la grande flessibilità del Front Office.\\
+Nei diversi **scenari** che sono stati presentati, specie in quelli complessi, è stato più volte posto in evidenza come la **scalabilità verticale** sia sempre garantita mentre quella orizzontale si riferisca esclusivamente ai primi due livelli del software in quanto attuali **limiti tecnologici** impediscono di garantire scalabilità sul livello che insiste sui **Data Base**.
-Ad esso può affiancarsi, ulteriormente, un intervento sull'Arbiter, che comunque sarebbe una componente indispensabile in un simile scenario, perchè le attività redazionali vengano distribuite equamente su tutti i server per ottenere la miglior distribuzione di carico ovvero concentrate su un singolo server del cluster, il principale di essi, per ottimizzare proprio il compito del servizio di sincronizzazione.\\
-Una volta realizzato questo servizio le possibilità di scalatura delle configurazioni eXtraWay diverrebbe, di fatto, senza limite.
+Al fine di superare questo **vincolo** con il pieno rispetto delle diverse piattaforme su cui eXtraWay può essere installato (ed in considerazione di costituire anche **installazioni scalate** su hardware di diversa tipologia che si avvalgano di Sistemi Operativi diversi) esiste un progetto di realizzazione di un **servizio** di **sincronizzazione** e **locking** delle basi dati da installare parallelamente ad eXtraWay su tutti i **server** coinvolti nel **cluster**. A tale servizio verrebbe demandato il compito di garantire un **accesso** sempre corretto e, la dove necessario, esclusivo unendo le esigenze del **Back Office** con la grande **flessibilità** del **Front Office**.
+Ad esso può affiancarsi, ulteriormente, un intervento sull'**Arbiter**, che comunque sarebbe una componente indispensabile in un simile scenario, perché le **attività redazionali** vengano distribuite equamente su tutti i **server** per ottenere la miglior **distribuzione** di **carico** ovvero concentrate su un **singolo server** del **cluster**, il principale di essi, per ottimizzare proprio il **compito** del servizio di **sincronizzazione**.
+Una volta realizzato questo servizio le possibilità di **scalatura** delle **configurazioni eXtraWay** diverrebbe, di fatto, senza limite.
 === Servizio di Content Server ===
-Le applicazioni documentali quali quelle che ci si propone di realizzare con eXtraWay fanno ampio uso di documenti informatici e digitali da considerarsi come allegati dei singoli record degli archivi.\\
+Le **applicazioni documentali** quali quelle che ci si propone di realizzare con **eXtraWay** fanno ampio uso di **documenti informatici** e **digitali** da considerarsi come **allegati** dei **singoli record** degli **archivi**.
-Essi possono essere di dimensioni contenute come di ampie dimensioni così come possono essere in numero esiguo come in quantità ragguardevoli. L'esperienza insegna che solitamente essi rappresentano una parte imponente dell'intero Data Base, per dimensioni ed aspetti quantitativi.\\
-Parimenti di questi file si può dire che:\\
-  * Nella stragrande maggioranza dei casi non possono e non devono essere mai cambiati, al limite sottoposti a versioning, operazione che ne deve comunque garantire la reperibilità in originale. Essi possono quindi essere sottoposti a Backup meno frequenti in quanto destinati ad essere invariabili ma vengono ad appartenere sempre e comunque ai Backup di tutto l'archivio.
-  * A seconda della natura di tali files le applicazioni possono aver necessità di sfruttarne delle trasformazioni, basti pensare ad un file .PDF non modificabile come versione pubblica di un documento effettivamente registrato in formato Microsoft Word oppure un'immagine ad alta risoluzione della quale si voglia mostrare una versione ridotta (thumb nail) ovvero una versione non sfruttabile perché modificata con un WaterMark. Ciascuna di queste conversioni dev'essere pianificata a monte perché essa possa essere sfruttata applicativamente.
-Ciascuno di questi casi viene attualmente gestito da strumenti esistenti che vanno dalla politica di distribuzione degli allegati su disco, alla gestione delle loro trasformazioni con procedure off-line alla realizzazione di complesse modalità di Backup per ottenere risultati parziali.
-Con la realizzazione di un simile strumento esso può essere sottoposto a proprie politiche di Backup e replicazione, può compiere autonomamente ed a run-time le conversioni richieste rendendole estremamente dinamiche ed adattabili quindi al variare delle esigenze applicative senza dover compiere attività di manutenzione/trasformazione del Data Base.\\
+Essi possono essere di **dimensioni** contenute come di ampie dimensioni così come possono essere in numero esiguo come in quantità ragguardevoli. L'**esperienza** insegna che solitamente essi rappresentano una parte imponente dell'intero **Data Base**, per **dimensioni** ed **aspetti quantitativi**.
-A sua volta esso può rappresentare un ulteriore grado di scalabilità orizzontale del tier inerente i DataBase con un ulteriore beneficio sia prestazionale che architetturale.
+Parimenti di questi **file** si può dire che:
+  * Nella stragrande maggioranza dei **casi** non possono e non devono essere mai cambiati, al limite sottoposti a **versioning**, operazione che ne deve comunque garantire la **reperibilità** in **originale**. Essi possono quindi essere sottoposti a **Backup** meno frequenti in quanto destinati ad essere **invariabili** ma vengono ad appartenere sempre e comunque ai **Backup** di tutto l'**archivio**.
+  * A seconda della natura di tali files le **applicazioni** possono aver necessità di sfruttarne delle **trasformazioni**, basti pensare ad un **file** ''.PDF'' **non modificabile** come versione pubblica di un documento effettivamente registrato in formato **Microsoft Word** oppure un'**immagine** ad **alta risoluzione** della quale si voglia mostrare una **versione ridotta** (**thumb nail**) ovvero una versione non sfruttabile perché modificata con un **WaterMark**. Ciascuna di queste conversioni dev'essere pianificata a monte perché essa possa essere sfruttata applicativamente.
+Ciascuno di questi casi viene attualmente gestito da **strumenti esistenti** che vanno dalla **politica** di **distribuzione** degli **allegati** su **disco**, alla gestione delle loro **trasformazioni** con procedure off-line alla realizzazione di complesse modalità di **Backup** per ottenere risultati parziali.
+Con la realizzazione di un simile strumento esso può essere sottoposto a proprie **politiche** di **Backup** e **replicazione**, può compiere autonomamente ed a **run-time** le **conversioni** richieste rendendole estremamente **dinamiche** ed **adattabili** quindi al variare delle esigenze applicative senza dover compiere attività di manutenzione/trasformazione del Data Base.
+A sua volta esso può rappresentare un ulteriore grado di **scalabilità orizzontale** del **tier** inerente i **DataBase** con un ulteriore **beneficio** sia **prestazionale** che **architetturale**.
 ===== Glossario, Acronimi e Note =====
-Questo documento descrive il significato dei termini più frequentemente utilizzati nella documentazione inerente il server e la piattaforma documentale **eXtraWay**.\\
+Questo **documento** descrive il **significato** dei **termini** più frequentemente utilizzati nella **documentazione** inerente il **server** e la **piattaforma documentale eXtraWay**.
-La conoscenza dei significati di questi termini può essere fondamentale per la corretta comprensione della documentazione.
+La **conoscenza** dei **significati** di questi termini può essere fondamentale per la **corretta comprensione** della **documentazione**.
 ^DocWay                |Applicazione di Protocollo Informatico e Gestione Documentale realizzata facendo uso della Piattaforma eXtraWay|