Erfahrungen zu Multi-Gesellschaftsinstallationen

Hallo liebe Experten,

Heute interessiere ich mich mal für eure Erfahrungen bzgl. Multi-Gesellschaftsinstallationen.
Folgende Herausforderung: Größerer Konzern mit vielen Gesellschaften in D hat NAV in der Dachgesellschaft gekauft. Jetzt sollen alle Gesellschaften nach und nach auf NAV umgestellt werden. Bedeutet aber in der Endausbaustufe >1000 User. Wie sind eure Erfahrungen zu so einer Konstellation bzw. wie würdet ihr das aufsetzen unter Berücksichtigung, dass nur eine Lizenz in der Dachgesellschaft vorhanden und gewünscht ist?
Ich hatte das bisher nur mit ausländischen Gesellschaften, wo dann sowieso eine Landeslizenz vorhanden sein musste, und daher die User über mehrere Datenbanken verteilt waren.

Edit: Es handelt sich um eine NAV 2018 onPrem Installation.

Gruß,
Horst

Hier sind drei Themen zu betrachten:

1. Lizenz
Mit einer Lizenz darf sowohl der Lizenznehmer, als auch jede Tochtergesellschaft, an welcher der Lizenznehmer >50% der Anteile besitzt, arbeiten.
Auf gut deutsch: Eine Schwester-Gesellschaft (an welcher nicht der Lizenznehmer, sondern dessen übergeordneter Eigentümer die Mehrheit besitzt), darf nicht mit dieser Lizenz betrieben werden.

Eine zusätzliche Bedingung ist, dass sich die Gesellschaften in derselben Datenbank befinden müssen, als als Mandanten angelegt werden müssen.
Sogar wenn der Lizenznehmer selber zwei Datenbanken in derselben Version (z. B. NAV 2018) für sich selber betreiben möchte (z. B. eine separate nur für die Lohn-/Gehalts-Abrechnungen), benötigt er hierfür eine separate Lizenz.
(Diesen Fall haben wir bei uns. Wir benötigen zwei NAV 2017 Lizenzen für ein und dieselbe Gesellschaft, weil wir die Lohnbuchhaltung in einer separaten Datenbank verwalten.)

2. Blockaden
Die einzelnen Gesellschaften werden ja als eigenständige Mandanten laufen, somit sind die Tabellen auf dem SQL-Server je Mandant einmal vorhanden (abgesehen von den mandantenübergreifenden Tabellen).
Somit sollten auch bei >1000 Usern keine Blockaden entstehen, welche auf die Anzahl User zurückzuführen wären.

3. Performance
Auf jeden Fall sollten der SQL-Server, der/die ServiceTier(s) und die Clients auf unterschiedlichen physikalischen Maschinen laufen.
Die Netzwerkverbindung zwischen NST(s) und SQL-Server sollte optimalerweise über Glasfaser laufen.
Wenn die Clients über eine Citrix-Farm auf die NSTs zugreifen, sollte die Citrix-Farm ebenfalls eine Glasfaserverbindung zu den NSTs haben.

Da in der Datenbank sehr viele Gesellschaften sind, könnte man die NSTs nach Gesellschaft unterteilen.
Falls das nicht möglich sein sollte (weil einige Abteilungen mandatenübergreifend aktiv sind), könnte man sich auch einen "Pseudo-Loadbalancer" scripten, welcher die Client-Anmeldungen über einen virtuellen Port reihum auf die verschiedenen NSTs verteilt.
(So verteilen wir z. B. unserer User auf zehn NSTs.)

Und zu guter Letzt eine goldene Regel:
Man kann niemals zuviel Arbeitsspeicher haben, sondern immer nur zu wenig.
Das einzige, was besser ist als viel Arbeitsspeicher, ist noch mehr Arbeitsspeicher.

1. Lizenz
Mit einer Lizenz darf sowohl der Lizenznehmer, als auch jede Tochtergesellschaft, an welcher der Lizenznehmer >50% der Anteile besitzt, arbeiten.
Auf gut deutsch: Eine Schwester-Gesellschaft (an welcher nicht der Lizenznehmer, sondern dessen übergeordneter Eigentümer die Mehrheit besitzt), darf nicht mit dieser Lizenz betrieben werden.

Das ist klar.

Eine zusätzliche Bedingung ist, dass sich die Gesellschaften in derselben Datenbank befinden müssen, als als Mandanten angelegt werden müssen.
Sogar wenn der Lizenznehmer selber zwei Datenbanken in derselben Version (z. B. NAV 2018) für sich selber betreiben möchte (z. B. eine separate nur für die Lohn-/Gehalts-Abrechnungen), benötigt er hierfür eine separate Lizenz.
(Diesen Fall haben wir bei uns. Wir benötigen zwei NAV 2017 Lizenzen für ein und dieselbe Gesellschaft, weil wir die Lohnbuchhaltung in einer separaten Datenbank verwalten.)

Ich denke, das ist das Hauptproblem. Aus meiner Sicht muss sich MS hier bewegen und von ihrem Konzept abweichen. Mir ist überhaupt nicht klar, wie das gehen soll. Ab einer gewissen Anzahl an Gesellschaften kann man gar nicht anders als das über mehrere DBs zu splitten. Alleine schon beim Thema Update... es ist aus meiner Sicht unmöglich alle Gesellschaften auf einen Schlag umzustellen. Selbst in der gegebenen Transitionszeit wird es nicht möglich sein alle Gesellschaften umzustellen. Die Bewertung von MS ist hier meiner Meinung nach eine rein technische und beruht auf veralteten Annahmen. Zumal, warum bietet man dann einen Lizenzupload auf ein Tenant an, rein für SaaS-Anbieter?! Hier verbaut sich MS meiner Meinung nach selbst den Weg hin zu größeren Kunden.

2. Blockaden
Die einzelnen Gesellschaften werden ja als eigenständige Mandanten laufen, somit sind die Tabellen auf dem SQL-Server je Mandant einmal vorhanden (abgesehen von den mandantenübergreifenden Tabellen).
Somit sollten auch bei >1000 Usern keine Blockaden entstehen, welche auf die Anzahl User zurückzuführen wären.

Da mache ich mir auch keine Sorgen. Das Thema Blocks, Deadlocks, etc. ist aus meiner Sicht dadurch recht gut abgefangen, dass gesonderte Mandanten auch immer gesonderte Tabellen auf SQL-Ebene bedeutet. Die mandantenübergreifenden Tabellen kann man aus meiner Sicht in dem Zusammenhang vernachlässigen. Oder siehst du da eine, die kritisch werden könnte?

Auf jeden Fall sollten der SQL-Server, der/die ServiceTier(s) und die Clients auf unterschiedlichen physikalischen Maschinen laufen.

Das ist klar.

Die Netzwerkverbindung zwischen NST(s) und SQL-Server sollte optimalerweise über Glasfaser laufen.
Wenn die Clients über eine Citrix-Farm auf die NSTs zugreifen, sollte die Citrix-Farm ebenfalls eine Glasfaserverbindung zu den NSTs haben.

Ist in einem gemeinsamen RZ, sollte daher kein Problem sein.

Da in der Datenbank sehr viele Gesellschaften sind, könnte man die NSTs nach Gesellschaft unterteilen.
Falls das nicht möglich sein sollte (weil einige Abteilungen mandatenübergreifend aktiv sind), könnte man sich auch einen "Pseudo-Loadbalancer" scripten, welcher die Client-Anmeldungen über einen virtuellen Port reihum auf die verschiedenen NSTs verteilt.
(So verteilen wir z. B. unserer User auf zehn NSTs.)

Es wird beides geben, sowohl zentrale Dienste als auch rein lokale Abteilungen. An einem Split über mehrere NSTs kommt man, denke ich, auch nicht vorbei. Hätte man aber bei mehreren DBs natürlich auch. Wir können nur noch nicht richtig einschätzen, was das denn nachher für den SQL Server bedeutet.

Man kann niemals zuviel Arbeitsspeicher haben, sondern immer nur zu wenig.
Das einzige, was besser ist als viel Arbeitsspeicher, ist noch mehr Arbeitsspeicher.

Das ist auch klar.

Hallo zusammen,

ich möchte mich gerne an das Thema anhängen, weil unsere Problematik gewisse Überschneidungen hat.

Aktuell nutzen wir BC14 On-Premise mit ca. 60 Mandanten und 80+30 (Premium/Team Member) Benutzerlizenzen.
Ich glaube die konkrete NAV/BC Version ist bei diesem Konstrukt aber weniger von Bedeutung (Thread befindet sich in NAV 2018, daher diese Anmerkung).

Die 60 Mandanten werden grundsätzlich von 3 Abteilungen genutzt, die weitestgehend unabhängig voneinander arbeiten.
Aus diesem Grund streben wir eine Trennung der bisherigen Datenbank an, Handling der kompletten DB mit allen Mandanten, Updates, Backups werden zunehmend zur Herausforderung.

Ich strebe folgende Struktur an:

SQL 1
- Datenbank 1
--- 2 Mandanten

SQL 2
- Datenbank 2
--- 15 Mandanten
- Datenbank 3
--- 45 Mandanten

Unsere bisherige Lizenz wird durch weiteren Lizenzkauf um einen zusätzlichen aktiven Enhancement erweitert. In diesem Zuge soll man wohl Lizenzen verschieben können, weil wir dann eine sendende und empfangende Lizenz haben.
Unser BC Lieferant hat uns erklärt, dass die BC Lizenzierung nicht je Datenbank, sondern auch je SQL-Instanz über die Master-DB laufen kann. Solange die Datenbanken 2 und 3 also in derselben Instanz laufen, soll dieselbe Lizenz genutzt werden können.
Wir haben eine gewisse Anzahl an Mitarbeitern, die in Datenbank 2 und 3 arbeiten würden, insofern ist für uns diese Klärung sehr wichtig. Ist eine Lizenzierung über die Master-DB der SQL-Instanz nicht möglich, müssten wir diese Mitarbeiter dann doppelt lizenzieren.

Kann jemand die Aussage unseres Lieferanten bestätigen oder kennt belastbare Unterlagen dazu? Mit dem MS Licensing Guide habe ich diese Fragestellung für uns nicht klären können.

Besten Dank und Gruß!
Stefan

Hast du die Auswirkungen der Datenbank-Splittung bedacht? Zum Beispiel hinsichtlich Stammdatenverwaltung, Intercompany-Abwicklung, Konsolidierung macht das den Alltag deutlich komplizierter für die Anwender. Das Gleichhalten der Objektstände ist für die IT dann aufwändiger. Ich würde da eher hinsichtlich Performance-Optimierung rangehen, davon ausgehend dass das der Grund für die Splittung ist, und schauen wo hier Probleme liegen, die man korrigieren/optimieren kann. Wenn ihr aber die Mandanten in unterschiedlichen Ländern betreibt dann ist die Splittung natürlich interessant hinsichtlich der Lokalisierung. Zu den lizenzrechtlichen Fragen kann ich nicht viel beitragen, im Zweifel sollte man sowas mit Microsoft oder ggf. über Companial definitiv abklären. Ich denke sowas ist in SaaS tatsächlich besser umzusetzen als on premises.

Danke für Deinen Input, enh.
Die genannten Auswirkungen habe ich für uns wie folgt beurteilt:

- Stammdaten: Ist durchaus auch so gewollt. Unser Lieferant hat eine Mandantenübertragung entwickelt (ähnlich wie andere Fibu-Systeme das mit einem Vorlagemandanten machen, der Stammdaten in weitere Mandanten speist). Dieselben Stammdaten werden aber nur genutzt für alle Mandanten in den jeweils getrennten Datenbanken 1,2 und 3.

- Intercompany-Abwicklung benötigen wir bisher nicht, ist auch nicht absehbar.

- Konsolidierung: Wir nutzen für die Konzernkonsolidierung eine separate Software mit Schnittstelle zum Business Central; diese erfüllt alle Wünsche. Besser als Business Central mit Konsolidierung umgeht. Insofern können wir gut damit leben.

Das Gleichhalten der Objektstände ist bei uns kein Thema. Wir machen bisher alle 12 bis 18 Monate nur einen Major Release Wechsel und wollen durchaus auch die Option nutzen die jeweiligen Datenbanken einzeln upzudaten, weil wir mit der Begleitung der Anwender, den vor- und nachgeschalteten Systemen sonst einfach nicht nachkommen, wenn wir die ganze Business Central Landschaft in einem Rutsch updaten. Selbst nehmen wir keine Änderungen an Objekten vor.

Was bleibt sind aus meiner Sicht also nur die lizenzrechtlichen Fragen.

Ich kenne diese technische Möglichkeit, aber meines Wissens nach ist das für die SaaS-Welt erstellt worden. Das entbindet nach meinem Verständnis nicht von den lizenzrechtlichen Regularien, die eine Ein-Datenbank-Politik pro Lizenz bei onPrem vorschreibt. So hatte es Timo ja auch beschrieben:

Eine zusätzliche Bedingung ist, dass sich die Gesellschaften in derselben Datenbank befinden müssen, als als Mandanten angelegt werden müssen.
Sogar wenn der Lizenznehmer selber zwei Datenbanken in derselben Version (z. B. NAV 2018) für sich selber betreiben möchte (z. B. eine separate nur für die Lohn-/Gehalts-Abrechnungen), benötigt er hierfür eine separate Lizenz.