Im Publishing-Szenario haben wir mehrere Deployer, die Inhalte sowohl auf das Dateisystem als auch auf die Datenbank (Broker) übertragen. Seiten und Binärdateien werden auf dem Dateisystem abgelegt, alles andere im Broker. Wir haben einen der Deployer, der den Inhalt in die Datenbank schreibt. Ist dies die empfohlene Best Practice?
Wenn die Speicherkonfigurationen in allen Deployern den Inhalt ebenfalls in die Datenbank einfügen, wie geht Tridion damit um? Könnte dies zu doppelten Einträgen, Sperrfehlern usw. führen?
Ich fürchte, zum Zeitpunkt des Schreibens habe ich keinen Zugang zu einer Umgebung, um zu testen, wie das funktionieren würde.
Die empfohlene Vorgehensweise von SDL besteht darin, eine Eins-zu-Eins-Beziehung zwischen einem Deployer und einer Veröffentlichung herzustellen. das bedeutet, solange zwei Deployer den gleichen Inhalt (aus der gleichen Veröffentlichung) nicht veröffentlichen, werden sie nicht kollidieren, wenn es bei einem Dateisystem eine Trennung zwischen den bereitgestellten Sites gibt, z. www / pub1 & amp; www / pub2.
Ihre Erklärung Ihres Szenarios benötigt einige zusätzliche Informationen, um sie vollständig zu machen, aber es klingt höchstwahrscheinlich, dass es mehrere Broker-Datenbanken gibt (wenn auch auf einem einzelnen Datenbankserver gehostet). Dies ist das am häufigsten verwendete Setup für den Umgang mit mehreren Dateisystemen auf Webservern in Kombination mit einem einzelnen Datenbankserver.
Ich persönlich mag diese Einrichtung nicht, da ich denke, dass es besser wäre, Dateisysteminhalte an einem gemeinsamen Ort zu hosten & amp; teilen Sie einzelne DB. Oder besser noch alles in der Datenbank bereitstellen und verwendet so etwas wie DD4T / CWA.
Ich habe ähnliche Konfigurationen gesehen (und sogar basierend auf Kundenbeschränkungen empfohlen), bei denen Sie mehrere Deployer als Ziele für ein bestimmtes Ziel konfiguriert haben.
Nur einer der Deployer kann für dieselbe Transaktion in die Datenbank schreiben, andernfalls haben Sie Parallelitätsprobleme. So schreibt ein Deployer in die Datenbank, während alle anderen in das Dateisystem schreiben.
Alle Broker / Webanwendungen sind so konfiguriert, dass sie aus der Datenbank lesen .
Dies löst das Problem der Bereitstellung auf mehreren Servern und / oder Rechenzentren, wo die Verwendung eines gemeinsamen Dateisystems (bevorzugter Ansatz) nicht möglich ist - sei es aus Kostengründen oder aus anderen Gründen.
Kurz gesagt - keine gute Praxis, aber es ist bekannt, dass es funktioniert.
Julian und Nuno decken die meisten gängigen Szenarien ab. In der Tat ist eine einzelne Datenbank ein einzelner Fehlerpunkt, aber in vielen Installationen wird von Ihnen erwartet, dass Sie mehrere Schemas auf demselben Datenbankserver ausführen, sodass Sie auch dann einen einzigen Fehlerpunkt haben, wenn Sie mehrere "Broker DBs" haben. p>
Eine weitere Alternative sind völlig unabhängige Lieferknoten. Dies kann sogar bedeuten, dass ein Datenbankserver auf Ihrer Präsentationsbox ausgeführt wird. Heutzutage ist es sowieso alles virtuell, sodass Sie separate kleine Datenbankserver betreiben können. (Lizenzkosten wären eine wichtige Einschränkung)
Jeder Zustellungsserver verfügt über eine eigene Datenbank und ein eigenes Dateisystem. Je nachdem, wie viele Sie möchten, sollten Sie möglicherweise nicht mehrere Ziele / Deployer einrichten, also eine Deployment-Instanz bereitstellen und die Dateisystemreplikation und den Datenbankprotokollversand verwenden, um den Inhalt für den Rest zu spiegeln.
Natürlich könnten Sie zwei Deployment-Systeme (oder drei) für Redundanz konfigurieren, vorausgesetzt, Sie können das gesamte Clustering usw. verwalten.
OK - um sauber zu werden - ich habe noch nie einen solchen gebaut, aber ich bin ziemlich sicher, dass Elemente dieser Art von Design mit zunehmender Virtualisierung und Lizenzmodellen, die sie unterstützen, immer häufiger werden. (Vielleicht müssen wir warten, bis Tridion eine Open-Source-Datenbank unterstützt!)
Tags und Links tridion