23
NIC-Teaming, ein PC im gleichen Subnetz direkt am Server
Guten Abend zusammen!
Aus Performance-Gründen wollen wir einen Server (IBM x3500 M4) über zwei im Fußboden verlegte Netzwerkkabel per NIC-Teaming mit einem Switch (HP 1820-24G) verbinden. Das Problem: Ein Rechner (in der angehängten Graphik PC7, rechts unten), soll weiterhin im gleichen Subnetz bleiben und muß dann direkt am Server angeschlossen werden. In der Graphik ist oben der jetzige, unten der geplante Zustand zu sehen. Geht das überhaupt, und was ist dann zu beachten? Der PC7 muß zur eMail-Bearbeitung zumindest Zugriff auf den am Switch angeschlossenen Router haben. Oder wäre nur ein zweites Subnetz mit statischen Routen über den Server eine Lösung?
Hat jemand einen Vorschlag? Ich wäre sehr dankbar, da ich mit diesem Thema nicht so vertraut bin.
ErwinS
Aus Performance-Gründen wollen wir einen Server (IBM x3500 M4) über zwei im Fußboden verlegte Netzwerkkabel per NIC-Teaming mit einem Switch (HP 1820-24G) verbinden. Das Problem: Ein Rechner (in der angehängten Graphik PC7, rechts unten), soll weiterhin im gleichen Subnetz bleiben und muß dann direkt am Server angeschlossen werden. In der Graphik ist oben der jetzige, unten der geplante Zustand zu sehen. Geht das überhaupt, und was ist dann zu beachten? Der PC7 muß zur eMail-Bearbeitung zumindest Zugriff auf den am Switch angeschlossenen Router haben. Oder wäre nur ein zweites Subnetz mit statischen Routen über den Server eine Lösung?
Hat jemand einen Vorschlag? Ich wäre sehr dankbar, da ich mit diesem Thema nicht so vertraut bin.
ErwinS
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 345958
Url: https://administrator.de/contentid/345958
Printed on: April 25, 2024 at 05:04 o'clock
23 Comments
Latest comment
Hi,
der Kern Deines Problems:
Du hast nur begrenzt viele Kabel im Boden liegen und kannst nicht weitere legen. Richtig?
Und jetzt willst Du wissen, wie Du den PC weiterhin ans Netz bekommst, wenn Du ihm sein Kabel wegnimmst, damit dieses an den Server kann. Auch richtig?
E.
der Kern Deines Problems:
Du hast nur begrenzt viele Kabel im Boden liegen und kannst nicht weitere legen. Richtig?
Und jetzt willst Du wissen, wie Du den PC weiterhin ans Netz bekommst, wenn Du ihm sein Kabel wegnimmst, damit dieses an den Server kann. Auch richtig?
E.
Ja, das hast Du richtig erkannt, Danke. Vor ca. acht Jahren haben wir die zwei damals seriellen Kabel (Terminalbetrieb) durch zwei Cat 5e Kabel ersetzt, drei wären nicht durch das Leerrohr gegangen. Und die vor acht Jahren neu eingesetzte Praxissoftware wird nach jedem Quartalsupdate noch zähflüssiger...
Und warum schreibst Du das dann nicht so?
Neue Leitung
WLAN
Server als Router
Neue Leitung
WLAN
Server als Router
Hallo,
Einen kleinen Teaming fähigen Switch dort wo der Server steht. Dort dann mit den Server ein Team und den PC7 dran. Und zwischen deinen nun 2 Switchen ebenfalls Team bauen.
Oder die CAT 5e Kabel raus, Glasfaser rein (dann passen mehr als nur 2 Verbindungen), Medienwandler an beiden enden und darüber deinen Server un PC7 anbinden. Evtl Optiken mit 10 GBit/s anstelle von Team.
Gruß,
Peter
Einen kleinen Teaming fähigen Switch dort wo der Server steht. Dort dann mit den Server ein Team und den PC7 dran. Und zwischen deinen nun 2 Switchen ebenfalls Team bauen.
Oder die CAT 5e Kabel raus, Glasfaser rein (dann passen mehr als nur 2 Verbindungen), Medienwandler an beiden enden und darüber deinen Server un PC7 anbinden. Evtl Optiken mit 10 GBit/s anstelle von Team.
Und die vor acht Jahren neu eingesetzte Praxissoftware wird nach jedem Quartalsupdate noch zähflüssiger...
Und wie soll da jetzt ein Team weiterhelfen oder für abhilfe schaffen? Würde ja auch bedeuten das deine GigaBit Verkabelung definitiv zu langsam ist.Gruß,
Peter
Mir ist gerade noch eine weitere Lösungsmöglichkeit eingefallen, die vielleicht am einfachsten wäre:
Auf dem Server haben wir einen Terminalserver laufen. Vielleicht sollte man den PC7 einfach auf Terminalserverbetrieb umstellen, wenn andere Lösungen zu aufwändig sind. Das sollte doch auch mit einer IP-Adresse außerhalb des Subnetzes gehen?
Auf dem Server haben wir einen Terminalserver laufen. Vielleicht sollte man den PC7 einfach auf Terminalserverbetrieb umstellen, wenn andere Lösungen zu aufwändig sind. Das sollte doch auch mit einer IP-Adresse außerhalb des Subnetzes gehen?
Zitat von @Pjordorf:
Hallo,
Einen kleinen Teaming fähigen Switch dort wo der Server steht. Dort dann mit den Server ein Team und den PC7 dran. Und zwischen deinen nun 2 Switchen ebenfalls Team bauen.
Oder die CAT 5e Kabel raus, Glasfaser rein (dann passen mehr als nur 2 Verbindungen), Medienwandler an beiden enden und darüber deinen Server un PC7 anbinden. Evtl Optiken mit 10 GBit/s anstelle von Team.
Gruß,
Peter
Hallo,
Einen kleinen Teaming fähigen Switch dort wo der Server steht. Dort dann mit den Server ein Team und den PC7 dran. Und zwischen deinen nun 2 Switchen ebenfalls Team bauen.
Oder die CAT 5e Kabel raus, Glasfaser rein (dann passen mehr als nur 2 Verbindungen), Medienwandler an beiden enden und darüber deinen Server un PC7 anbinden. Evtl Optiken mit 10 GBit/s anstelle von Team.
Und die vor acht Jahren neu eingesetzte Praxissoftware wird nach jedem Quartalsupdate noch zähflüssiger...
Und wie soll da jetzt ein Team weiterhelfen oder für abhilfe schaffen? Würde ja auch bedeuten das deine GigaBit Verkabelung definitiv zu langsam ist.Gruß,
Peter
Ich weiß, dass jeder Rechner nach wie vor nur mit 1 GBit bedient wird. Aber wenn mehrere Rechner gleichzeitig auf die Datenbanken zugreifen, und dazwischen noch Druckaufträge gesendet werden, sollte es doch eine gewisse Verbesserung bringen.
Das Problem ist das Programm, mittlerweile in ca. 450 Datenbanken aufgeteilt (meines Wissens Access) und eine Umstellung auf z.B SQL ist nicht in Sicht.
Gruß Erwin
Zitat von @ErwinS:
Ja, das hast Du richtig erkannt, Danke. Vor ca. acht Jahren haben wir die zwei damals seriellen Kabel (Terminalbetrieb) durch zwei Cat 5e Kabel ersetzt, drei wären nicht durch das Leerrohr gegangen. Und die vor acht Jahren neu eingesetzte Praxissoftware wird nach jedem Quartalsupdate noch zähflüssiger...
hm... Theorg... Mediatix ???Ja, das hast Du richtig erkannt, Danke. Vor ca. acht Jahren haben wir die zwei damals seriellen Kabel (Terminalbetrieb) durch zwei Cat 5e Kabel ersetzt, drei wären nicht durch das Leerrohr gegangen. Und die vor acht Jahren neu eingesetzte Praxissoftware wird nach jedem Quartalsupdate noch zähflüssiger...
... also das Nic Teaming bring dir nix...
Ich weiß, dass jeder Rechner nach wie vor nur mit 1 GBit bedient wird. Aber wenn mehrere Rechner gleichzeitig auf die Datenbanken zugreifen, und dazwischen noch Druckaufträge gesendet werden, sollte es doch eine gewisse Verbesserung bringen.
nö... wie den? bei RDP ????? Das Problem ist das Programm, mittlerweile in ca. 450 Datenbanken aufgeteilt (meines Wissens Access) und eine Umstellung auf z.B SQL ist nicht in Sicht.
ja... also das Nic Teaming bring dir nix...Mir ist gerade noch eine weitere Lösungsmöglichkeit eingefallen, die vielleicht am einfachsten wäre:
Auf dem Server haben wir einen Terminalserver laufen.
so... jetzt mal Butter bei die Fische, du schreibst du willst einenTerminal Server mit Nic Teaming schneller machen!Auf dem Server haben wir einen Terminalserver laufen.
so ein RDP Client braucht maximal einige MB´s und nutzt deine Gigabit verbindung ca. zu 2-3 %
Und die vor acht Jahren neu eingesetzte Praxissoftware wird nach jedem Quartalsupdate noch zähflüssiger...
ist dein Server und seine Software auch 8 Jahre alt?ich denke das:
A. dein server einfach nur alt und durch ist!
B. wenn der server nicht so alt ist, ihr einen konfig Problem habt!
C. bei so vielen kleinen DB´s würde ich ein Raid 10 mit SSD´s erstellen
beschreib mal deinen Server näher.. also hardware und software
Frank
Hallo Frank,
Der Server IBM x3500 M4 (siehe Graphik oben) mit XEON 2620 V2 ist zwei Jahre alt, hat 40 GB RAM, installiert ist Windows Server 2012 R2.
Installiert ist ein Raid 5 mit drei SAS-Platten 10 GBit/sec und einer Spare-Platte.
Der Terminalserver (16 von den 40 GB RAM) wurde ursprünglich für externen Zugriff eingerichtet, mittlerweile haben wir auch zwei interne Plätze eingebunden, um die Performance zu verbessern, die anderen Arbeitsplätze hängen nicht am Terminalserver.
Bei der eingesetzten Software handelt es sich hauptsächlich um x.concept. Auch Kollegen berichten von Performance-Problemen. Beispielsweise kommt immer wieder die Meldung "Keine Rückmeldung von x.concept", wartet man dann eine halbe Minute oder mitunter länger, geht es wieder weiter. Und das z.B. auf einem Arbeitsplatz mit SSD-Platte...
Andere Software, z.B. docArchiv, läuft im Vergleich dazu geradezu flüssig.
Der Server IBM x3500 M4 (siehe Graphik oben) mit XEON 2620 V2 ist zwei Jahre alt, hat 40 GB RAM, installiert ist Windows Server 2012 R2.
Installiert ist ein Raid 5 mit drei SAS-Platten 10 GBit/sec und einer Spare-Platte.
Der Terminalserver (16 von den 40 GB RAM) wurde ursprünglich für externen Zugriff eingerichtet, mittlerweile haben wir auch zwei interne Plätze eingebunden, um die Performance zu verbessern, die anderen Arbeitsplätze hängen nicht am Terminalserver.
Bei der eingesetzten Software handelt es sich hauptsächlich um x.concept. Auch Kollegen berichten von Performance-Problemen. Beispielsweise kommt immer wieder die Meldung "Keine Rückmeldung von x.concept", wartet man dann eine halbe Minute oder mitunter länger, geht es wieder weiter. Und das z.B. auf einem Arbeitsplatz mit SSD-Platte...
Andere Software, z.B. docArchiv, läuft im Vergleich dazu geradezu flüssig.
Zitat von @ErwinS:
Hallo Frank,
Der Server IBM x3500 M4 (siehe Graphik) mit XEON 2620 V2 ist zwei Jahre alt, hat 40 GB RAM, installiert ist Windows Server 2012 R2.
Installiert ist ein Raid 5 mit drei SAS-Platten 10 GBit/sec und einer Spare-Platte.
ok...Hallo Frank,
Der Server IBM x3500 M4 (siehe Graphik) mit XEON 2620 V2 ist zwei Jahre alt, hat 40 GB RAM, installiert ist Windows Server 2012 R2.
Installiert ist ein Raid 5 mit drei SAS-Platten 10 GBit/sec und einer Spare-Platte.
bei ixxConcept brauchst du dringend ein SSD Raid.... so wird das nix!
Server 2012 R2 & ixxConcept, da wurde auf SMB1 umgestellt! deinen clients wird es egal sein, ob du mit 10 Gbit, oder als NIC Team ankommst. SMB1 bremst auf 10 Mbit.
Tip: stell alles auf RDP um... bau den Server um mit einem Raid 10 SSD Raid!
Der Terminalserver (16 von den 40 GB RAM) wurde ursprünglich für externen Zugriff eingerichtet, mittlerweile haben wir auch zwei interne Plätze eingebunden, um die Performance zu verbessern, die anderen Arbeitsplätze hängen nicht am Terminalserver.
warum nsind nicht alle platze auf RDP umgestellt worden?
Bei der eingesetzten Software handelt es sich hauptsächlich um ixxConcept. Auch Kollegen berichten von Performance-Problemen. Beispielsweise kommt immer wieder die Meldung "Keine Rückmeldung von ixxConcept", wartet man dann eine halbe Minute oder mitunter länger, geht es wieder weiter. Und das z.B. auf einem Arbeitsplatz mit SSD-Platte...
Andere Software, z.B. docArchiv, läuft im Vergleich dazu geradezu flüssig.
tja.. schade... du hast vor 2 Jahren einen neuen Server gekauft, und es sind viele Fehler gemacht worden!
Frank
Moin,
ich würde - wie von Pjordorf vorgeschlagen - einen weiteren 5 oder 8Port-Switch zwischen setzen und gut:
Sauberer wäre es natürlich dort ein LWL mit 12 oder 24 Phasern durch zu schieben. Der erforderliche Platz für ein 12-LWL: ca die dicke eines CAT7-Kabels... aber dann musst du entweder noch entsprechende Medienkonverter beschaffen und/ oder den Server mit einer LWL-NIC ausstatten und deinen 1820-24G mit GBics bestücken (wobei der nur zwei Ports hat...)
Alles drum und dran also teurer als den zusätzlichen 8-Port Switch...
Ggf. kannst anstelle des 1820-8G auch den 1920-8G verwenden, der hat wenigstens schon 2 SFP-Ports dabei... solltet ihr später mal auf LWL umsatteln, wären die Switche schon mal vorbereitet....
Gruß
em-pie
€dit: Grafik resized...
ich würde - wie von Pjordorf vorgeschlagen - einen weiteren 5 oder 8Port-Switch zwischen setzen und gut:
Sauberer wäre es natürlich dort ein LWL mit 12 oder 24 Phasern durch zu schieben. Der erforderliche Platz für ein 12-LWL: ca die dicke eines CAT7-Kabels... aber dann musst du entweder noch entsprechende Medienkonverter beschaffen und/ oder den Server mit einer LWL-NIC ausstatten und deinen 1820-24G mit GBics bestücken (wobei der nur zwei Ports hat...)
Alles drum und dran also teurer als den zusätzlichen 8-Port Switch...
Ggf. kannst anstelle des 1820-8G auch den 1920-8G verwenden, der hat wenigstens schon 2 SFP-Ports dabei... solltet ihr später mal auf LWL umsatteln, wären die Switche schon mal vorbereitet....
Gruß
em-pie
€dit: Grafik resized...
Zitat von @em-pie:
Moin,
ich würde - wie von Pjordorf vorgeschlagen - einen weiteren 5 oder 8Port-Switch zwischen setzen und gut:
Sauberer wäre es natürlich dort ein LWL mit 12 oder 24 Phasern durch zu schieben. Der erforderliche Platz für ein 12-LWL: ca die dicke eines CAT7-Kabels... aber dann musst du entweder noch entsprechende Medienkonverter beschaffen und/ oder den Server mit einer LWL-NIC ausstatten und deinen 1820-24G mit GBics bestücken (wobei der nur zwei Ports hat...)
Alles drum und dran also teurer als den zusätzlichen 8-Port Switch...
Ggf. kannst anstelle des 1820-8G auch den 1920-8G verwenden, der hat wenigstens schon 2 SFP-Ports dabei... solltet ihr später mal auf LWL umsatteln, wären die Switche schon mal vorbereitet....
Gruß
em-pie
Moin,
ich würde - wie von Pjordorf vorgeschlagen - einen weiteren 5 oder 8Port-Switch zwischen setzen und gut:
Sauberer wäre es natürlich dort ein LWL mit 12 oder 24 Phasern durch zu schieben. Der erforderliche Platz für ein 12-LWL: ca die dicke eines CAT7-Kabels... aber dann musst du entweder noch entsprechende Medienkonverter beschaffen und/ oder den Server mit einer LWL-NIC ausstatten und deinen 1820-24G mit GBics bestücken (wobei der nur zwei Ports hat...)
Alles drum und dran also teurer als den zusätzlichen 8-Port Switch...
Ggf. kannst anstelle des 1820-8G auch den 1920-8G verwenden, der hat wenigstens schon 2 SFP-Ports dabei... solltet ihr später mal auf LWL umsatteln, wären die Switche schon mal vorbereitet....
Gruß
em-pie
gute lösung, hilft aber nicht bei seinem eigentlichen Problem!
Frank
Hallo Frank,
vielen Dank für Deine ausführlichen Antworten, jetzt ahne ich zumindest, woher die Probleme kommen (ich lese mich gerade etwas über SMB1 ein) und weiß, wohin die Reise gehen sollte.
Ja, der Terminalserver ist als VM aufgesetzt, dann müssen wir eben noch RDP-Lizenzen kaufen. Aber der eine oder andere Rechner (z.B. mit EKG- oder Ultraschall-Anbindung) ist eben nur sehr schwer als RDP-Client zu realisieren. Aber wenn die meistgenutzten Rechner wieder schneller wären, könnte man das auch noch akzeptieren.
Jedenfalls glaube ich nun auch nicht mehr an eine Verbesserung durch NIC-Teaming.
Gruß Erwin
vielen Dank für Deine ausführlichen Antworten, jetzt ahne ich zumindest, woher die Probleme kommen (ich lese mich gerade etwas über SMB1 ein) und weiß, wohin die Reise gehen sollte.
Ja, der Terminalserver ist als VM aufgesetzt, dann müssen wir eben noch RDP-Lizenzen kaufen. Aber der eine oder andere Rechner (z.B. mit EKG- oder Ultraschall-Anbindung) ist eben nur sehr schwer als RDP-Client zu realisieren. Aber wenn die meistgenutzten Rechner wieder schneller wären, könnte man das auch noch akzeptieren.
Jedenfalls glaube ich nun auch nicht mehr an eine Verbesserung durch NIC-Teaming.
Gruß Erwin
Hallo Erwin,
selbst EKG- oder Ultraschall-Anbindung ist für rdp kein Problem... dafür gibbet Serial Port Server etc...
und der Fußschalter zum auslösen am Ultraschall ist auch kein Problem!
Frank
Hallo em-pie,
vielen Dank für Deine Mühe!
Ja, irgendwann wird man auch um LWL nicht mehr herumkommen. Der Geschwindigkeitszuwachs, den die Hardware permanent immer wieder bringt, wird durch die Software völlig aufgefressen.
Aber die jetzige Installation sollte schon noch einige Jahre reichen, aber man muß natürlich jetzt schon an die Zukunft denken.
Gruß Erwin
vielen Dank für Deine Mühe!
Ja, irgendwann wird man auch um LWL nicht mehr herumkommen. Der Geschwindigkeitszuwachs, den die Hardware permanent immer wieder bringt, wird durch die Software völlig aufgefressen.
Aber die jetzige Installation sollte schon noch einige Jahre reichen, aber man muß natürlich jetzt schon an die Zukunft denken.
Gruß Erwin
Hallo Frank,
das Ultraschallgerät ist über eine separate Graphikkarte an den Rechner angebunden. Geht das auch mit RDP?
Gruß Erwin
das Ultraschallgerät ist über eine separate Graphikkarte an den Rechner angebunden. Geht das auch mit RDP?
Gruß Erwin
Zitat von @ErwinS:
Hallo Frank,
das Ultraschallgerät ist über eine separate Graphikkarte an den Rechner angebunden. Geht das auch mit RDP?
du meinst mit einer Falcon Eagel PCI karte... mit BNC stecker Hallo Frank,
das Ultraschallgerät ist über eine separate Graphikkarte an den Rechner angebunden. Geht das auch mit RDP?
nun, die einfachste lösung wäre an diesem PC x.concept als Remote APP laufen zu lassen.. die daten (Bilder)werden zum export eh verschoben.. und der rest geht über GDT...
Gruß Erwin
Hallo,
das Grundproblem ist nicht die Netzwerkbandbreite (1GB) oder das Transport-Protokoll (SMB1), dein Problem ist die ACCESS-Datenbank.
Access ist ein Datenbank-System für lokale Nutzung, d.h. Datenbank und Zugriff erfolgen vom gleichen Rechner. Nicht über das Netzwerk. Access hat keine Client-Server-Architektur.
Die Lösung ist also der Terminal-Betrieb (wie du ja schon richtig erkannt hast), bei dem die Daten(-bank) den Rechner (Server) nicht verläßen.
Du schreibst davon, dass der Terminal-Server als VM läuft. Die Server-Instanz, auf dem ixxConcept läuft, auch? Und docArchiv?
Setzt Du für die VM Hyper-V ein? Ist der IBM-Server als reiner Hyper-V-Server konfiguriert, auf dem dann mehere virtuelle Server (Terminal, DB, Druck usw) laufen oder laufen DB, Druck usw. direkt auf dem "Blech" und zusätzlich eine VM mit dem Terminal-Server? Bei letzterem: Warum den Terminal-Server als VM und nicht auch direkt auf dem "Blech"? (Ich habe für eine ERP-Anwendung - 10 User - einen Server, der ist DB-Server (MS-SQL für ERP), Applikations-Server (ERP-Anwendung) und Terminal-Server in einem. Alles läuft direkt auf dem "Blech". Natürlich mit SSD-RAID, ausreichend RAM usw.. Der "schöne" Nebeneffekt ist, dass der Support-Dienstleister alleine für die "Kiste" zuständig ist, ich muß nur den Netzwerkanschluß bereitstellen.)
Ich glaube, den größten Performance-Gewinn würdest du durch eine Optimierung des Servers und der darauf laufenden Dienste/Applikationen bekommen. Die Server-Hardware und die Netzwerk-Anbindung sind dein kleinstes Problem.
Jürgen
das Grundproblem ist nicht die Netzwerkbandbreite (1GB) oder das Transport-Protokoll (SMB1), dein Problem ist die ACCESS-Datenbank.
Access ist ein Datenbank-System für lokale Nutzung, d.h. Datenbank und Zugriff erfolgen vom gleichen Rechner. Nicht über das Netzwerk. Access hat keine Client-Server-Architektur.
Die Lösung ist also der Terminal-Betrieb (wie du ja schon richtig erkannt hast), bei dem die Daten(-bank) den Rechner (Server) nicht verläßen.
Du schreibst davon, dass der Terminal-Server als VM läuft. Die Server-Instanz, auf dem ixxConcept läuft, auch? Und docArchiv?
Setzt Du für die VM Hyper-V ein? Ist der IBM-Server als reiner Hyper-V-Server konfiguriert, auf dem dann mehere virtuelle Server (Terminal, DB, Druck usw) laufen oder laufen DB, Druck usw. direkt auf dem "Blech" und zusätzlich eine VM mit dem Terminal-Server? Bei letzterem: Warum den Terminal-Server als VM und nicht auch direkt auf dem "Blech"? (Ich habe für eine ERP-Anwendung - 10 User - einen Server, der ist DB-Server (MS-SQL für ERP), Applikations-Server (ERP-Anwendung) und Terminal-Server in einem. Alles läuft direkt auf dem "Blech". Natürlich mit SSD-RAID, ausreichend RAM usw.. Der "schöne" Nebeneffekt ist, dass der Support-Dienstleister alleine für die "Kiste" zuständig ist, ich muß nur den Netzwerkanschluß bereitstellen.)
Ich glaube, den größten Performance-Gewinn würdest du durch eine Optimierung des Servers und der darauf laufenden Dienste/Applikationen bekommen. Die Server-Hardware und die Netzwerk-Anbindung sind dein kleinstes Problem.
Jürgen
Hallo Jürgen,
ein Mitarbeiter des regional zuständigen ixxConcept-Vertriebsteams hat vor zwei Jahren die erste 2012R2-Instanz als Domain-Server direkt auf dem "Blech" installiert, die zweite für den Terminalserver als VM auf die erste aufgesetzt, also nicht in eine separate Partition. Der Terminalserver wird nach einem Start des Hauptservers ebenfalls automatisch gestartet, Hyper-V tritt gar nicht in Erscheinung.
docArchiv läuft unter SQL auf dem "Hauptserver", auf dem auch die Netzwerkdrucker installiert sind, auf den Arbeitsplätzen und dem Terminalserver werden jeweils Clients gestartet. Für ein Teilprogramm von ixxConcept wurde vor einem Jahr ebenfalls SQL installiert, der größte Teil läuft jedoch nach wie vor auf den Arbeitsplätzen und dem Terminalserver, wobei der Hauptserver quasi als File-Server fungiert. Wie ich bereits oben geschrieben habe, ist eine Umstellung des Komplettprogramms auf SQL nicht in Sicht.
Das mag vielleicht damit zusammenhängen, dass docConcept vor einigen Jahren von Medatixx übernommen wurde, weiterhin als x.concept vertrieben und betreut wird, Medatixx jedoch eine eigene SQL-Lösung (x.isynet) mit eingebracht hat.
Meine Tochter hat schon wiederholt überlegt, auf x.isynet oder auf ein ganz anderes Programm umzusteigen, aber die Kosten wären natürlich entsprechend hoch (Konvertierung des Datenbestandes, Neuinstallation, möglicherweise eine SQL-Serverlizenz kaufen, Einarbeitung der Mitarbeiter etc.).
Aber die Wartezeiten, wenn x.concept seine "Denkpausen" hat und ein paar Patienten an der Anmeldung in der Schlange stehen oder in den Sprechzimmern der Gemeinschaftspraxis z.B. auf ihren Rezeptausdruck warten, sind schon extrem ärgerlich...
Ich danke Dir für Deinen ausführlichen Beitrag
Gruß Erwin
PS: Microsoft Access läuft (oder lief?) schon im Netzwerk, ich habe früher mal eine Anwendung programmiert. Allerdings werden dann die ganzen Datentabellen hin- und hergeschaufelt, so dass ich seinerzeit auch auf einen Terminalserver umgestiegen bin - das war noch unter Windows 2000.
ein Mitarbeiter des regional zuständigen ixxConcept-Vertriebsteams hat vor zwei Jahren die erste 2012R2-Instanz als Domain-Server direkt auf dem "Blech" installiert, die zweite für den Terminalserver als VM auf die erste aufgesetzt, also nicht in eine separate Partition. Der Terminalserver wird nach einem Start des Hauptservers ebenfalls automatisch gestartet, Hyper-V tritt gar nicht in Erscheinung.
docArchiv läuft unter SQL auf dem "Hauptserver", auf dem auch die Netzwerkdrucker installiert sind, auf den Arbeitsplätzen und dem Terminalserver werden jeweils Clients gestartet. Für ein Teilprogramm von ixxConcept wurde vor einem Jahr ebenfalls SQL installiert, der größte Teil läuft jedoch nach wie vor auf den Arbeitsplätzen und dem Terminalserver, wobei der Hauptserver quasi als File-Server fungiert. Wie ich bereits oben geschrieben habe, ist eine Umstellung des Komplettprogramms auf SQL nicht in Sicht.
Das mag vielleicht damit zusammenhängen, dass docConcept vor einigen Jahren von Medatixx übernommen wurde, weiterhin als x.concept vertrieben und betreut wird, Medatixx jedoch eine eigene SQL-Lösung (x.isynet) mit eingebracht hat.
Meine Tochter hat schon wiederholt überlegt, auf x.isynet oder auf ein ganz anderes Programm umzusteigen, aber die Kosten wären natürlich entsprechend hoch (Konvertierung des Datenbestandes, Neuinstallation, möglicherweise eine SQL-Serverlizenz kaufen, Einarbeitung der Mitarbeiter etc.).
Aber die Wartezeiten, wenn x.concept seine "Denkpausen" hat und ein paar Patienten an der Anmeldung in der Schlange stehen oder in den Sprechzimmern der Gemeinschaftspraxis z.B. auf ihren Rezeptausdruck warten, sind schon extrem ärgerlich...
Ich danke Dir für Deinen ausführlichen Beitrag
Gruß Erwin
PS: Microsoft Access läuft (oder lief?) schon im Netzwerk, ich habe früher mal eine Anwendung programmiert. Allerdings werden dann die ganzen Datentabellen hin- und hergeschaufelt, so dass ich seinerzeit auch auf einen Terminalserver umgestiegen bin - das war noch unter Windows 2000.
PS: Microsoft Access läuft schon im Netzwerk, ich habe früher mal eine Anwendung programmiert. Allerdings werden dann die
ganzen Datentabellen hin- und hergeschaufelt, so dass ich seinerzeit auch auf einen Terminalserver umgestiegen bin.......
ganzen Datentabellen hin- und hergeschaufelt, so dass ich seinerzeit auch auf einen Terminalserver umgestiegen bin.......
Hallo,
genau das meinte ich. Bei einer Client-Server-Struktur wie bei SQL wird nur die "Frage" und die "Antwort" (ausgewählte Datensätze entsprechend der SQL-Abfrage) über das Netzwerk transportiert. Das Durchsuchen der DB erfolgt auf dem Server; die DB "verläßt" den Server nicht.
Bei Access erfolgt das Durchsuchen der DB immer auf dem lokalen Rechner und wenn die DB auf einem Server liegt, muß die ganze DB über das Netzwerk zum lokalen Rechner transportiert werden. Das sind natürlich erheblich größere Datenmengen als bei einer SQL-Abfrage.
Ich kenne die von dir eingesetzten Programme nicht. Mir ist nur aufgefallen, das die Strukturierung der Dienste/ Applikationen auf die verfügbaren Server (egal ob Blech oder VM) sehr "gewöhnungsbedürftig" ist. Und genau hier scheint das Problem zu liegen. Grundlegende Design-Regel wurden hier mißachtet!
Hyper-V tritt gar nicht in Erscheinung.
Wenn du eine VM im Einsatz hast, brauchst du einen Hypervisor (MS Hyper-V, VMware ESX oder Player/Workstation, Xen oder was es sonst noch gibt). Bei einem Windows-Server wäre Hyper-V naheliegend. https://de.wikipedia.org/wiki/Hypervisor
Bei einer produktiven Umgebung läuft der Hypervisor auf dem "Blech" und nur der!!! Keine anderen Dienste oder Anwendungen. Alles andere wird in VMs gepackt. Und dabei kann man dann die Dienste und Applikationen sauber trennen.
ZB. ist ein DC ein DC und nichts anderes. Maximal noch DNS und DHCP, aber auf keinen Fall noch DB- oder Terminal-Server oder Hypervisor.
Beispielsweise wird beim Installieren der DC-Funktion auf einem Server der Schreib-Cache der Festplatten aus Sicherheitsgründen deaktiviert. Das ist natürlich für einen DB- oder File-Server äußerst kontraproduktiv.
Du solltest mal einen Fachmann dein System neu planen und strukturieren lassen. Das muß ja nicht zwingend zur Beschaffung zusätchlicher Software/ Lizenzen oder Hardware führen. Es würde das System aber sicher schneller und stabiler machen.
Jürgen
PS: Unabhängig von dem oben erläuterten Problem könntest du durch Austausch des Switches und der NIC im Server den Link auf 2,5, 4 oder gar 10GB verbessern und hättest den 2. Link dann immer noch für den PC frei.
Hallo,
Ein Hypervisor vom Typ I läuft direkt auf dem Blech. dazu zählt auch der MS Hyper-V.
Ein Hypervisor vom Typ II läuft in einem Betriebssystem welches auf dem Blech läuft. Ist also nur eine Software wie z.B. Word oder Excel, und daher auch nicht Perfomant. Lass den Host (so nnnt sich der Gastgeber - das Blech) mal stark arbeiten und dein Hypervisor Typ II bekommt massiv probleme = deine clients bekommen noch mehr Probleme.
Hier wäre ESXi oder Hyper-V zur implementierung im Einsatz gekommen. Vermutlich sind deine Festplatten nur noch am Rotieren
Und deine vielen verschiedenen Datenbanken und Anwendungen tun das restliche um dort die Erwartungshaltung eines jeden im Tiefbohrschacht (fangen so bei 3 Kilometer tiefe an) zu versenken. Da solltest du eher Froh sein das dort überhaupt noch etwas geht - und bitte begrag deine Hoffnung es könnte schneller gehen.
Gruß,
Peter
Zitat von @ErwinS:
ein Mitarbeiter des regional zuständigen ixxConcept-Vertriebsteams hat vor zwei Jahren die erste 2012R2-Instanz als Domain-Server direkt auf dem "Blech" installiert, die zweite für den Terminalserver als VM auf die erste aufgesetzt,
Und beantworte doch bitte noch wie und mit welchem Hypervisor der Bertriebsmitarbeiter denn denn TerminalServer auf dein Server 2012R2 installiert hat. Vermutlich mit einem Type 2 Hypervisor = Banane.ein Mitarbeiter des regional zuständigen ixxConcept-Vertriebsteams hat vor zwei Jahren die erste 2012R2-Instanz als Domain-Server direkt auf dem "Blech" installiert, die zweite für den Terminalserver als VM auf die erste aufgesetzt,
Ein Hypervisor vom Typ I läuft direkt auf dem Blech. dazu zählt auch der MS Hyper-V.
Ein Hypervisor vom Typ II läuft in einem Betriebssystem welches auf dem Blech läuft. Ist also nur eine Software wie z.B. Word oder Excel, und daher auch nicht Perfomant. Lass den Host (so nnnt sich der Gastgeber - das Blech) mal stark arbeiten und dein Hypervisor Typ II bekommt massiv probleme = deine clients bekommen noch mehr Probleme.
Hier wäre ESXi oder Hyper-V zur implementierung im Einsatz gekommen. Vermutlich sind deine Festplatten nur noch am Rotieren
Und deine vielen verschiedenen Datenbanken und Anwendungen tun das restliche um dort die Erwartungshaltung eines jeden im Tiefbohrschacht (fangen so bei 3 Kilometer tiefe an) zu versenken. Da solltest du eher Froh sein das dort überhaupt noch etwas geht - und bitte begrag deine Hoffnung es könnte schneller gehen.
Gruß,
Peter
Hallo Peter,
Natürlich läuft Hyper-V auf dem Hauptserver. Ich meinte mit "Hyper-V tritt gar nicht in Erscheinung" nur, dass beim Starten des "Blechs" der Terminalserver automatisch gestartet wird, dieser also nicht "manuell" über Hyper-V aufgerufen werden muss.
Gruß Erwin
Natürlich läuft Hyper-V auf dem Hauptserver. Ich meinte mit "Hyper-V tritt gar nicht in Erscheinung" nur, dass beim Starten des "Blechs" der Terminalserver automatisch gestartet wird, dieser also nicht "manuell" über Hyper-V aufgerufen werden muss.
Gruß Erwin
Hallo,
Du kennst doch
Ein Server ist ein Server ist ein Server ist ein Server...
Ein Router ist ein Router ist ein Router ist ein Router...
Ein DC ist ein DC ist ein DC ist ein DC iste ein DC ...
Ein Hypervisor ist ein Hypervisor ist ein Hypervisor ist ein Hypervisor...
Warum tun alle ahnungslosen auf eine MS Hyper-V Software drauf die dort nichts zu suchen hat? Weil bei allen anderen Hypervisoren geht es ja nicht.
Auf dein Blech welches der Hypervisor ist, gehört nichts anderes als VMs drauf, noch nicht einmal Word soll da drauf. Du hättest darauf achten sollen/müssen das deine Dienste und Apllicationen getrennt bleiben und denen jeweils ein eigen VM geben sollen. Dann wärst du flexibler und könntest genau sagen was der Flaschenhals ist. So aber - Designfehler.
PS: Selbst das zuerst installierte Windows Server OS läuft nach der Installation der Rolle Hyper-V und einem neustart selbst als VM, auch wenn du es nicht siehst. Das ist die Parent..... MS Hyper-V ist halt anders als alle anderen Hypervisoren (Microkernel vs Monolithic) https://blogs.technet.microsoft.com/chenley/2011/02/23/hyper-v-microkern ...
Gruß,
Peter
Du kennst doch
Ein Server ist ein Server ist ein Server ist ein Server...
Ein Router ist ein Router ist ein Router ist ein Router...
Ein DC ist ein DC ist ein DC ist ein DC iste ein DC ...
Ein Hypervisor ist ein Hypervisor ist ein Hypervisor ist ein Hypervisor...
Warum tun alle ahnungslosen auf eine MS Hyper-V Software drauf die dort nichts zu suchen hat? Weil bei allen anderen Hypervisoren geht es ja nicht.
Auf dein Blech welches der Hypervisor ist, gehört nichts anderes als VMs drauf, noch nicht einmal Word soll da drauf. Du hättest darauf achten sollen/müssen das deine Dienste und Apllicationen getrennt bleiben und denen jeweils ein eigen VM geben sollen. Dann wärst du flexibler und könntest genau sagen was der Flaschenhals ist. So aber - Designfehler.
PS: Selbst das zuerst installierte Windows Server OS läuft nach der Installation der Rolle Hyper-V und einem neustart selbst als VM, auch wenn du es nicht siehst. Das ist die Parent..... MS Hyper-V ist halt anders als alle anderen Hypervisoren (Microkernel vs Monolithic) https://blogs.technet.microsoft.com/chenley/2011/02/23/hyper-v-microkern ...
Ich meinte mit "Hyper-V tritt gar nicht in Erscheinung" nur, dass beim Starten des "Blechs" der Terminalserver automatisch gestartet wird
Das ist ein normal zu erwartendes Ereigniss bzw. ist so geplant (By Design) dieser also nicht "manuell" über Hyper-V aufgerufen werden muss.
Wär ja sonst blöd wenn am 24.12 gegen 23:59 keiner da wäre um den zu starten Gruß,
Peter
jo... liebe Leser
wie ich schon geschrieben habe:
der TO kann eigentlich Nix dafür... die möchtegern system einrichter von x.concept arbeiten auf computerbild niveau!
es sind auch keine ACCES DB´s sondern FoxPro und teilweise FLATFile DB´s... etc etc.. da kannst du nur mit SMB1 Arbeiten!
ab einer gewissen DB größe & menge wird es einfach nur langsam! mit normalen Spindeln kommst du da nicht bei.
wir haben die erfahrung gemacht, das ein Raid 10 mit SSD´s am besten ist... natürlich im RDS betrieb..
für geizige tut es aber auch ein Raid 1
der TO wäre gut beraten, den Server mal ordentlich einzurichten... ein Systemhaus steht im dazu gerne bei!
Frank
wie ich schon geschrieben habe:
tja.. schade... du hast vor 2 Jahren einen neuen Server gekauft, und es sind viele Fehler gemacht worden!
der TO kann eigentlich Nix dafür... die möchtegern system einrichter von x.concept arbeiten auf computerbild niveau!
es sind auch keine ACCES DB´s sondern FoxPro und teilweise FLATFile DB´s... etc etc.. da kannst du nur mit SMB1 Arbeiten!
ab einer gewissen DB größe & menge wird es einfach nur langsam! mit normalen Spindeln kommst du da nicht bei.
wir haben die erfahrung gemacht, das ein Raid 10 mit SSD´s am besten ist... natürlich im RDS betrieb..
für geizige tut es aber auch ein Raid 1
der TO wäre gut beraten, den Server mal ordentlich einzurichten... ein Systemhaus steht im dazu gerne bei!
Frank
