2 file server in einem Netzwerk

[#1]

Hallo Zusammen,

ist es in Ordnung dass wir 2 File Server auf unserem Netzwerk installieren, muss man auf etwas achten? Z.B der Name von windvsw1? vielen dank im Voraus

[#2]

Geht das auch etwas genauer? Sie wollen 2 DATEV FileServer im Netzwerk installieren? Und 2 unterschiedliche Clients (PCs/WTS/RDS) dran hängen?

2x WINDVSW1 geht nicht, weil sich DATEV insbesondere an der CONFIGDB stört, die es auch 2x gibt und nie in einem Netzwerk geben darf bzw. nicht so, dass man von 1 PC aus auf beide CONFIGDBs schauen kann. Kann man ja mit Firewalls, unterschiedlichen IP-Kreisen, ... lösen. 

Auf Wunsch des Autors durch @Dirk_Jendritzki geändert

[#3]

---

@Tissen  schrieb:

Hallo Zusammen,

ist es in Ordnung dass wir 2 File Server auf unserem Netzwerk installieren, muss man auf etwas achten? Z.B der Name von windvsw1? vielen dank im Voraus

---

Mehr als ein Fileserver ist nicht das Problem, mehrere DATEV Fileserver mit WinDVSW1 möchte nicht haben.

[#4]

ein Fileserver ist schon installiert und ist im Betrieb brauchen wir weiterer. es geht um ein WTS Umgebung, das heißt wenn ich anstatt windvsw1 für zweiten FileServer windvsw2 nehme, gibt es kein Problem oder? Danke

[#5]

Hi,

---

2x WINDVSW1 geht nicht, weil sich DATE insbesondere an der CONFIGGB stört, die es auch 2x gibt und nie in einem Netzwerk geben darf bzw. nicht so, dass man von 1 PC aus auf beide CONFIGDBs schauen kann. Kann man ja mit Firewalls, unterschiedlichen IP-Kreisen, ... lösen. 

---

das ist nicht ganz korrekt. 1x CONFIGDB in dem Netzwerk ist richtig. Es kann aber durchaus \\Server1\windvsw1 und \\Server2\windvsw1 geben, da sich die komplette URL letztendlich unterscheidet. Es ist meines Wissen auch nicht notwendig die configdb im windvsw1 zu parken. Erleichtert aber die Suche für die Programme...

Für einen Admin ist es allerdings deutlich einfacher, wenn die windvsw-Verzeichnisse fortlaufend nummeriert werden.

Mit den IP-Kreisen wird auch immer schwieriger, es sei denn wir setzen uns mit IPv6 auseinander. Seit SMB3 verwendet Microsoft vorzugsweise IPv6. Wenn also IPv4 segmentiert ist, würde ein theoretischer Zugriff über IPv6 erfolgen und beide Netze sind auf einem Client sichtbar. 

Dann besser ein VLAN dazwischen, damit auf IP-Ebene nichts anbrennen kann... 

Grüße

Chr.Ockenfels

[#6]

---

@chrisocki  schrieb:

das ist nicht ganz korrekt. 1x CONFIGDB in dem Netzwerk ist richtig. Es kann aber durchaus \\Server1\windvsw1 und \\Server2\windvsw1 geben, da sich die komplette URL letztendlich unterscheidet. Es ist meines Wissen auch nicht notwendig die configdb im windvsw1 zu parken. Erleichtert aber die Suche für die Programme...

---

Das geht aus meiner Sicht trotzdem nicht, weil DATEV im Netz nach der CONFIGDB sucht und dann 2 findet. Egal, ob WINDVSW1 oder 2. Das muss meines Wissens nach sauber getrennt werden. Unsere alte DATEV Umgebung sah vor, dass es WINDVSW2 bzgl. eines extra DMS-Servers gibt. Ich habe dann Clients als TS-Client aktiviert (VIWAS und Co.) und wo hat sich der Client reingeschrieben, ohne, dass ich das irgendwo angeben hätte können? WINDVSW2. Toll. Das Update zu VIWAS läuft dann natürlich gegen die Wand. 

VLAN ist auch eine Idee. Daran hatte ich gar nicht gedacht. 👍

[#7]

Aus welchem Grunde 2 Server?
- Zwei "Kanzleien", die am selben Netz hängen (überschneidende MD- Nummern) -> 2 * DATEV oder

- Aufteilung der Daten aus strategischen Gründen 1 * DATEV & 1 * sonstiges
PS: der neue WTS sollte doch auf den DATEV- File & SQL- Server zugreifen.

[#8]

@chrisockischrieb, dass es nur eine config.db im Netz geben darf, bei der Anlage von weiteren SQL Servern mit windvsw2 etc. wird diese Datei schlicht gelöscht, die Pfade stehen ja in windvsw1, also kein Problem.

@martinkolbergin größeren Umgebungen ist es durchaus üblich mehrere SQL Server einzusetzen, allein schon um die Rechnungswesendatei nicht allzu groß werden zu lassen. Kann über Datenpfade geregelt werden, aber es bleibt dann immer noch bei einer SQL Instanz. Trennung nach Sachgebieten ist hier der Vater des Gedanken, wenn z. B. viele MA auf BiBer arbeiten zieh das schon eine große Last auf die Datenbank. Nimmt man diese auf einen eigenen Server kann dies das Laben beschleunigen.

Bei mehreren Kanzleien ist das beim Einsatz von Unternehmensstrukturen sogar äußerst sinnvoll.

[#9]

@metalposaunist @chrisocki  wegen unserem Tunneling können wir Vlanning nicht nutzen so einzige Möglichkeit ist ein Server mit anderem windvsw wie windvsw2. bin richtig verstanden?

[#10]

Bringt meiner Meinung nach nichts, weil es um Freigabe- und NTFTS Rechte geht. 1 PC darf nie gleichzeitig auf WINDVSW1 und 2 kommen. Sonst weiß der PC / Server nicht, welches DATEV er nun nutzen soll und findet der Client 2x CONFIGDB mag DATEV das überhaupt nicht. Selbst wenn man dem Client sagt "nutze WINDVSW1", heißt das bei DATEV noch lange nicht, dass die Installationsroutine nicht doch auch die andere Freigabe nutzt. 

Wie man das in Ihrem Fall nun löst, muss man sich genau anschauen. Ggf. auch mit der DATEV zusammen. Ggf. mit einem DATEV Systempartner aus Ihrer Nähe.

Ohne Plan, wie man es technisch löst, würde ich nicht einfach drauflos installieren. Das kann böse enden. 

[#11]

---

@metalposaunist  schrieb:

---

@chrisocki  schrieb:

das ist nicht ganz korrekt. 1x CONFIGDB in dem Netzwerk ist richtig. Es kann aber durchaus \\Server1\windvsw1 und \\Server2\windvsw1 geben, da sich die komplette URL letztendlich unterscheidet. Es ist meines Wissen auch nicht notwendig die configdb im windvsw1 zu parken. Erleichtert aber die Suche für die Programme...

---

Das geht aus meiner Sicht trotzdem nicht, weil DATEV im Netz nach der CONFIGDB sucht und dann 2 findet. Egal, ob WINDVSW1 oder 2. Das muss meines Wissens nach sauber getrennt werden. Unsere alte DATEV Umgebung sah vor, dass es WINDVSW2 bzgl. eines extra DMS-Servers gibt. Ich habe dann Clients als TS-Client aktiviert (VIWAS und Co.) und wo hat sich der Client reingeschrieben, ohne, dass ich das irgendwo angeben hätte können? WINDVSW2. Toll. Das Update zu VIWAS läuft dann natürlich gegen die Wand. 

VLAN ist auch eine Idee. Daran hatte ich gar nicht gedacht. 👍

---

Ich schrieb ja: 

1x CONFIGDB im Netz

2x windvsw1 möglich (natürlich nur eine windvsw1 mit CONFIGDB).

Die CONFIGDB dürfte auch in der Freigabe "DATEVSchlumpf" liegen und die Nutzdaten auf den windvsw-Freigaben. Hauptsache ist, dass sie nur einmal existiert.

Grüße

Chr.Ockenfels

[#12]

---

@Tissen  schrieb:

ein Fileserver ist schon installiert und ist im Betrieb brauchen wir weiterer. es geht um ein WTS Umgebung, das heißt wenn ich anstatt windvsw1 für zweiten FileServer windvsw2 nehme, gibt es kein Problem oder? Danke

---

Warum brauchen Sie eigentlich einen weiteren? Wofür denn? Für DATEV? Liegts an der Kapazität? 

Was hat die WTS-Umgebung damit zu tun? Einen zweiten Filserver brauchen Sie dafür doch nicht, oder?

[#13]

Hi,

---

@Tissen  schrieb:

@metalposaunist @chrisocki  wegen unserem Tunneling können wir Vlanning nicht nutzen so einzige Möglichkeit ist ein Server mit anderem windvsw wie windvsw2. bin richtig verstanden?

---

hier reden wir aber über zwei verschiedene Dinge, oder?

Tunnel: VPN-Tunnel liegen meines Wissens auch schon in der Anwendungsschicht des OSI-Modells. Somit ergeben sich hier die Abhängigkeiten der Firewall.

VLAN: Liegen unterhalb der Anwendungsschicht (Bsp. IP) des OSI-Modells.

Mit VLAN's können Sie Netzwerke auf einem Switch logisch von einander trennen. Wenn Sie auf einem Switch ohne VLAN mehrere IP-Netze einrichten, kann ein Client durchaus mit allen Netzen reden, wenn er die IP-Bereiche kennt und auch eine IP von den Netzen bezogen/eingerichtet bekommen hat.

Bei einem VLAN wird das nichts. Je nach Konfiguration ist auf einem Switch-Port nur ein VLAN erlaubt. Selbst eine Einrichtung in der Netzwerkkarte würde nichts bringen, da der Switch nur das konfigurierte VLAN erlaubt.

Grüße

Chr.Ockenfels

[#14]

Hi,

@martinkolbergin größeren Umgebungen ist es durchaus üblich mehrere SQL Server einzusetzen, allein schon um die Rechnungswesendatei nicht allzu groß werden zu lassen. Kann über Datenpfade geregelt werden, aber es bleibt dann immer noch bei einer SQL Instanz. Trennung nach Sachgebieten ist hier der Vater des Gedanken, wenn z. B. viele MA auf BiBer arbeiten zieh das schon eine große Last auf die Datenbank. Nimmt man diese auf einen eigenen Server kann dies das Laben beschleunigen.

---

Wir haben auch bei Kanzleizukäufen mitunter die Datenbanken der gekauften Kanzlei einfach als zusätzlichen Datenpfad ins Netz integriert. Ging deutlich schneller wie die Sichern-Einspielen-Variante über die Bestandsdienste. Lediglich die EO-Stammdaten wurden exportiert und importiert. Die Leistungen haben dann über die Erstbestückung wieder "zueinander" gefunden. Auch Dokumente (Dokumentenablage / DMS classic) waren über dieses Verfahren mitunter wieder zusammenzuführen.

Auch war bei der Kanzlei ein Lastthema ausschlaggebend für eine Verteilung auf zwei FileServer.

Grüße

Chr.Ockenfels

[#15 · Accepted solution]

Hi,

---

@Tissen  schrieb:

ein Fileserver ist schon installiert und ist im Betrieb brauchen wir weiterer. es geht um ein WTS Umgebung, das heißt wenn ich anstatt windvsw1 für zweiten FileServer windvsw2 nehme, gibt es kein Problem oder? Danke

---

grundsätzlich so machbar. Wenn aber der bestehende Fileserver noch ausreichend Kapazitäten hat, würde auch ein Zusammenlegen auf der bestehenden Maschine funktionieren.

Fragen sind: Soll ein einheitlicher EO-Bestand genutzt werden? Wie sollen die alten EO-Daten vorgehalten werden? Reicht es ggf. die Datenpfade der leistungserstellenden Anwendungen zu separieren? u.s.w. Die Frage ob ein oder zwei FileServer ist dann hier eigentlich schon (fast) ohne Belang.

Grüße

Chr.Ockenfels

[#16]

---

@chrisocki  schrieb:

1x CONFIGDB im Netz

2x windvsw1 möglich (natürlich nur eine windvsw1 mit CONFIGDB).

Die CONFIGDB dürfte auch in der Freigabe "DATEVSchlumpf" liegen und die Nutzdaten auf den windvsw-Freigaben. Hauptsache ist, dass sie nur einmal existiert.

---

Und dann hat man in der zentralen CONFIGDB die Daten für 2 DATEV Installationen, die sich am besten wohl nicht kennen sollten? Und wenn man die wieder trennen will oder anders flexibel sein will ... halte ich für keine gute Idee. 

[#17]

---

@metalposaunist  schrieb:

---

@chrisocki  schrieb:

1x CONFIGDB im Netz

2x windvsw1 möglich (natürlich nur eine windvsw1 mit CONFIGDB).

Die CONFIGDB dürfte auch in der Freigabe "DATEVSchlumpf" liegen und die Nutzdaten auf den windvsw-Freigaben. Hauptsache ist, dass sie nur einmal existiert.

---

Und dann hat man in der zentralen CONFIGDB die Daten für 2 DATEV Installationen, die sich am besten wohl nicht kennen sollten? Und wenn man die wieder trennen will oder anders flexibel sein will ... halte ich für keine gute Idee. 

---

Wenn solch große Umgebungen getrennt werden sollen, ist die fehlende CONFIGDB auf dem zweiten Server das kleinste Übel... 

In der angesprochenen Kanzlei hatten wir 7-windvsw-Freigaben auf zwei Server verteilt. Teilweise nach Sachgebiet (interne Buchhaltung/Personalwesen), die dann auch noch einen eigenen KommServer (ingesamt 3) brauchten, in denen dann der Datenpfad der RZ-Komm umgebogen wurde.

Aber alles in einem zentralen EO-Datenbestand... 

Grüße

Chr.Ockenfels