Synchronisation von mehreren MasterServer

[S.Beckmann]

An alle, die Interesse haben, in der Hoffnung, dass es uns auch wieder zu gute kommt, dass es in das offizielle Produkt einfliesst, und dass wir Weiterentwicklungen daran nicht mehr selber bezahlen müssen:

Wir haben eine Infrastruktur, welche sich aus mehreren MasterServer zusammen Setzt. (Beispiel: Entwicklung -> Integration -> Abnahme -> Produktion)

Ein Paket müsste 4x eingetragen werden. Und da keinen regelmässigen DBSync in frage kommt, mussten wir eine Lösung haben. Da für ein kontrolliertes Release Management einen Automatischen Sync nicht Ideal ist, kann man diese Lösung von Hand anstossen!
Wir haben nun bei matrix42 DTS- Sync-Jobs entwickeln lassen, welche von einem Paket aufgerufen werden. Über die Softwareverteilung kann nun das Paket bei bedarf gepuscht werden, so dass der Sync ausgeführt wird.
Über Variabeln wird dann gesteuert, welche DTS-Syncs gleichzeitig ausgeführt werden können. Z.B. bei Paket-Job kann man über eine Variable genau mitgeben welche/s Paket/e gesynct werden kann/können, man kann ein einzelnes Paket angeben, oder Paketgruppen. Für Paketgruppen braucht es eine Namenskonvention die das zu lässt, sonnst gehen nur einzelne Pakete...

Folgende Jobs gibt es:

- DBSYNC_Configurator_EmpSyncJobs.dts
- DBSYNC_Configurator_Packages.dts
- DBSYNC_Configurator_PMv2.dts
- DBSYNC_Installer_BootTemplates_BootPXE.dts
- DBSYNC_Installer_DriverProfiles.dts
- DBSYNC_Installer_EISOption.dts
- DBSYNC_Installer_OSSource.dts
- DBSYNC_Installer_OSTemplates.dts
- DBSYNC_Manager_CustomFields.dts
- DBSYNC_Manager_ExternelTools.dts
- DBSYNC_Manager_InvConfiguration.dts
- DBSYNC_Manager_InvHistory.dts
- DBSYNC_Manager_OSINI.dts
- DBSYNC_Manager_RemoteControl.dts
- DBSYNC_Manager_UnmanagedDevices.dts
- DBSYNC_Manager_Variables.dts
- DBSYNC_PB_PathName.dts

Dies ermöglicht uns alle Server aktuell zu halten, ohne jedes Mal alles von Hand eingeben zu müssen.

Um die Dateien zu Syncen, haben wir über 80 EmpSync- Jobs! Dies ist notwendig, wenn man Masterserver abgleichen will, und einen Konzept wie Entwicklung/Testing/Abnahme/Produktion sauber Händeln will, und dies sich nicht alles auf einem Server abspielen soll. Wir sind so in der Lage sehr Detailliert zu Syncen. Leider können wir mit EmpSync immer noch nicht die Pakete einzeln Syncen, aber solange das DB- Objekt nicht vorhanden ist, und es Freigegeben ist, kann da nicht viel passieren. Wir hoffen aber auf eine EmpSync- Version die das irgendwann mal zulassen wird.

So, wer noch mehr Infos will, der soll sich melden... Wer es einsetzen möchte, der soll sich bei matrix42 melden, wir wären erfreut, wenn wir feststellen könnten, dass das Produkt noch bei anderen Firmen verwendet wird und eine kurze Info im Forum wäre auch schön...
Ach ja, das Paket/Produkt heisst "DB Syncjobs"

[Stefan Tacke]

Hallo Stefan,
was für eine DB habt ihr denn. SQL oder Oracle. Wir nutzen Oracle und ich muss leider immer wieder feststellen, das gerade bei Neuerungen es immer wieder probleme gibt.

Gruss Stefan Tacke

[S.Beckmann]

Hallo Stefan

Ich habe da schlechte Nachrichten, wir verwenden MS- SQL Server und das in der Version 8.0 (2000) und haben die Scripts dafür entwickeln lassen.

Stefan

[Stefan Tacke]

Das hab ich mir doch schon fast gedacht.

[Manni]

Hallo Stefan,

so, wie sich das anhört ist es genau das, was wir benötigen.
Auch wir benötigen die Frexibilität, weil Pakete bestimmte Freigaben und Testphasen durchlaufen müssen und kontrolliert eingesetzt werden müssen.
Ich habe es bereits über den Support angefordert und werde dann nach dem Test meine Erfahrung mitteilen.

Eine Frage hätte ich.
Werden über diese Sync-Jobs auch die SoftwareIDs mitrepliziert, oder werden neue erzeugt.
Wenn sie mitrepliziert wird haben wir das Problem, dass wir ja bisher die Pakete händisch angelegt haben und dann eventuelle eingetragene Abhängigkeiten ins Nirvana zeigen.

Gruß, Manfred

[S.Beckmann]

Hallo Manfred

Wir gehen davon aus, dass der untergeordnete Server, also z.B. Integration, nach einem Sync identisch mit dem Entwicklungsserver sein soll. Und das setzten wir durch, so dass nach einem Sync, alles vorhaden ist was in der Entwciklung bekannt ist, und alle entfernt ist, was nicht mehr vorhanden ist...

Aber nun im Detail zur Frage, das Andere war nur Einleitung

Es wird anhand des Namen geprüfft, ob ein Paket mit dem selben Namen schon vorhanden ist. Wenn nein, wird dies gesynct.
Wenn ich alles richtig verstanden habe, wird auf jedem System bei jedem Paket eine eigene ID erstellt.
Wenn Du ALLE Pakete unt Abhängikeiten auf dem 1. Server konfigurierst, dann sollten auch die Abhängikeiten da erfasst werden, denn diese werden ebenfalls gesynct!

So, hoffe habe die Frage beantworten können, obschon ich mir wegen den ID's nicht 100% sicher bin, das müsste man kurz die Entwicklung da fragen...

Gruss aus der Schweiz
Stefan

[Manni]

Hallo Stefan,

klingt wirklich vielversprechend.

Sind die sync-Jobs schon auf R2 angepasst.
Mit dem Update sind ja sehr viele Tables modifiziert worden. Könnte mir gut vorstellen, dass die meisten nicht mehr funktionieren. Müsst Ihr für solche Modifikationen auch zahlen?

lg,
Manfred

[rknatz]

Hallo Zusammen,

zu dieser Thematik ein offizielles Statement von matrix42. Es handelt sich hierbei um eine reine Projektlösung, die nicht vom Support unterstützt wird. Selbstverständlich bieten wir Kunden die Interesse an dieser Lösung haben an, dies über ein Projekt zu implementieren. Hierzu sprechen Sie bitte Ihren Territory Manager an.


Reinhard Knatz
Leiter Support matrix42

[S.Beckmann]

Hallo Manfred

Es war offenbar nicht klar genug, dass dies nicht über den Support gehen kan! Habe dann Herr Knatz darum gebeten den Thread wieder zu öffnen, und das nochmals klar zu stellen.
Also, da der Thread wieder offen ist, kann ich nun Deine Frage beantworten...

Die Jobs sind noch nicht auf R2 angepasst, wären aber daran interessiert . Wir müsste auf jeden Fall Kosten übernehmen, um die Scripts dahingehend zu erweitern. Solange es kein offizielles Addon ist, wird sich daran auch nichts ändern.

Ich kann keine Aussage zum Preis machen, lediglich soll erwähnt sein, dass wir über 300 Stunden darauf verwendet haben die Scripts zu testen, und wir schon wieder kleine Fehler gefunden haben... Hoffe dass es nun die letzten waren... Aber es ist sehr gut zu erkennen, dass nicht nur Kosten gegenüber matrix42 anfallen, sondern man selber viel investieren muss.

Diese Scripts, und davon bin ich überzeugt, sind sehr nützlich! Es macht durchaus Sinn, dass man mind. immer ein Testsystem zusätzlich hat. Will man die beiden Systeme von Hand updaten kann das schnell viel Geld und Zeit kosten. Wir verwenden ein Mehrstufiges System und werden so n - Server identisch halten können. Jede änderung müsste n- mal wiederholt werden!

Wir wollten auf keinen Fall eine Lösung die nur für uns gemacht wird. Jede Entwicklung die wir finanzieren, sollte auch so sein, dass es ins Produkt einfliessen kan. Leider ist es nun aber soweit gekommen, dass es nur für uns entwickelt wurde!
Ich verstehe, dass das nicht sofort einfliessen kan, aber ev. wäre es ja mal möglich über ein System nachzudenken, bei dem man Kosten übernimmt, und die Erweiterungen allen zu verfügung stellt. Ev. auch ein System, bei dem man wider Geld bekommt. (Bsp.: Ein Produkt wird auf 50 Euro geschätzt, Firma X bezahlt diese 50 Euro die Nächste Firma bezahlt 40 Euro, 10 Euro gehen an die Firma N, der Rest in einen Pot. Die nächste Firma würde dann noch 30 Euro bezahlen, je 5 Euro an die andern beiden, die restlichen 20 auch wieder in einen Pot. Weiterentwicklungen würden dann aus diesem Pot bezahlt. Wenn nicht mehr genug da sind, werden alle solidarisch die Differenz bezahlen, oder matrix42 übernimmt den Rest...

Da ist nur eine Idee, es gibt sicher noch bessere Modelle...

Auf jeden Fall sind wir daran interessiert dass es weiter geht! Ich hätte noch so viele Ideen und kann diese erst dann anpacken, wenn ich auf breite Unterstützung der Community und dem richtigen Modell zählen kan.

Apropos Community, um heraus zu finden wass die Community braucht, wäre eine Art Umfrage doch genial. Man könnte eine Liste mit bekannten Problemen, Verbesserungeswünsche und Erweiterungen Public machen, welche man per Mail erweitern lassen kan. Die Liste müsste nach Thema, Typ und Prio sortierbar sein. So könnte man aus jeder Gruppe von Zeit zu Zeit Umfragen machen, um dann darüber abstimmen zu lassen, welche Punkt wirklich wichtig sind. Ev. gibt es ja darunter Punkt die etwas schneller einfliessen können, als im regulären Zyklus, der ist einfach zu lange!
Aber das war nur ein kleiner Ausflug in meine Gedankenwelt!

So, das war's mal wieder von mir...

Steff