Database di distribuzione del contenuto da più deployer (DB Broker)

Question

Nello scenario di pubblicazione che ho, abbiamo diversi deployer che spingono il contenuto sia sul file system che sul database (broker). Le pagine e i binari vengono messi nel file system, tutto il resto nel broker. Abbiamo uno dei deployer che inserisce il contenuto nel database. È questa la migliore pratica consigliata?

Se le configurazioni di archiviazione di tutti i deployer inseriscono il contenuto nel database, come gestisce Tridion? Ciò potrebbe causare voci duplicate, errori di blocco ecc.?

Ho paura al momento della scrittura, non ho accesso a un ambiente per verificare come funzionerebbe.

Answer 1

La pratica SDL è quella di avere una relazione uno a uno tra un deployer e una pubblicazione; ciò significa che fino a quando due deployer non pubblicheranno lo stesso contenuto (dalla stessa pubblicazione), non collideranno se forniscono, se un file system, esiste una separazione tra i siti distribuiti, ad es. www/pub1 & www/pub2.

La spiegazione del proprio scenario richiede alcune informazioni aggiuntive per completarla, ma sembra molto probabile che ci siano più database di broker (anche se ospitati su un singolo server di database). Questa è l'impostazione più comune quando si gestiscono più file system sui server Web, combinati con un singolo server di database.

Personalmente non mi piace questa configurazione in quanto penso che sarebbe meglio ospitare il contenuto del file system in una posizione condivisa & condividere un singolo DB. O meglio ancora distribuire tutto al database e usa qualcosa come DD4T/CWA.

Answer 2

Ho visto (e anche consigliato in base alle limitazioni del cliente) configurazioni simili in cui sono presenti più deployer configurati come destinazioni di un dato target.

Solo uno dei deployer può scrivere nel database per la stessa transazione, altrimenti si avranno problemi di concorrenza. Quindi un deployer scrive nel database, mentre tutti gli altri scrivono sul file system.

Tutti i broker/applicazioni Web sono configurati su letto dal database.

Questo risolve il problema della distribuzione su più server e/o centri dati in cui l'utilizzo di un file system condiviso (approccio preferenziale) non è fattibile, sia per costi che per qualsiasi altra ragione).

In breve, non una best practice, ma è noto che funziona.

Answer 3

Gli approcci di Julian e Nuno riguardano la maggior parte degli scenari comuni. In effetti, un singolo database è un singolo punto di errore, ma in molte installazioni, si prevede di eseguire più schemi sullo stesso server di database, quindi si ha ancora un singolo punto di errore anche se si dispone di più "DB di broker".

Un'altra alternativa da considerare è i nodi di consegna totalmente indipendenti. Questo potrebbe significare anche l'esecuzione di un server di database sulla tua casella di presentazione. Al giorno d'oggi è tutto virtuale, quindi è possibile eseguire piccoli server di database separati. (I costi di licenza sarebbero un limite importante)

Ogni server di consegna ha il proprio database e il proprio file system. A seconda del numero desiderato, è possibile che non si desideri impostare più destinazioni/deployer, quindi distribuirli a uno e utilizzare la replica del file system e il log shipping del database per rispecchiare il contenuto sul resto.

Naturalmente, è possibile configurare due sistemi di distribuzione (o tre) per la ridondanza, supponendo che si può gestire tutto il raggruppamento ecc

OK - a venire pulito - non ho mai costruito uno come questo, ma io Sono abbastanza sicuri che elementi di questo tipo di design diventeranno più comuni con l'aumentare della virtualizzazione e modelli di licenza che lo supportano. (Forse dovremo aspettare che Tridion supporti un database open source!)