20
Verbindungsabbrüche im Netzwerk
Ich betreibe ein Netzwerk mit 12 PC und einem SBS 2011 in einer Arztpraxis. Die Verkabelung wurde 1998 mit Leonie Q-Line 4P22 SC 300 Kabeln und Cat5 Dosen von der Fa. Ackermann ausgeführt. Zwischenzeitlich haben wir alle PC und den Server mt Gigabit Netzwerkkarten ausgestattet, die alten Dosen und Kabel sind aber geblieben. Seit ca. 2 Jahren haben wir immer wieder Verbindungsabbrüche zwischen unserem Arztpraxisprogramm Medistar, welches auf dem Server läuft und den Clientcomputern.
Meine Frage: Kann ich das Netzwerk testen, indem ich händisch die Verbindungsgeschwindigkeit der Netzwerkkarten von Autonegotiation auf 100 MBit Vollduplex herabsetze ? Wenn das Netzwerk 100MBit, aber nicht Gigabit tauglich ist, würde der Fehler dann verschwinden ?
Im voraus vielen Dank für Eure Tips!
Meine Frage: Kann ich das Netzwerk testen, indem ich händisch die Verbindungsgeschwindigkeit der Netzwerkkarten von Autonegotiation auf 100 MBit Vollduplex herabsetze ? Wenn das Netzwerk 100MBit, aber nicht Gigabit tauglich ist, würde der Fehler dann verschwinden ?
Im voraus vielen Dank für Eure Tips!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 212849
Url: https://administrator.de/contentid/212849
Ausgedruckt am: 23.11.2024 um 05:11 Uhr
20 Kommentare
Neuester Kommentar
Ja, das kannst du machen !
Sinn macht es an der NIC und am Switchport die Geschw. fest auf 100 Mbit und Fullduplex zu setzen.
Du solltest das mal nur für 2-3 PCs machen im netz, denn so hast du einen Vergleich ob diese Links im Gegensatz zu den Gig Links dann stabiler arbeiten.
Normalerweise erfordert GiG Ethernet mindestens Cat 5e Kabel und Cat5e fähige Dosen und Patchpanels.
Ob dein "Leonie" Kabel und die Ackermann Dosen das sind ist aus deinem Post nicht ersichtlich...leider
Generell kann man sagen das das aber auch mit stinknormalem Cat5 Kabel läuft wenn die einzelnen Längen der Kabel nicht lang sind bzw. an die 100 Meter Grenze kommen.
Der Abbruch muss allerdings nicht ungebdingt aus der Physisk resultieren ! Es kann ja auch die SW selber sein !!
Auch das solltest du wasserdicht testen indem du z.B. mal ein kleines Ping Tool wie den "Big Brother"
http://kin.klever.net/bigbrother
über längere Zeit auf ein paar Clients laufen lässt. So hast du überhaupt erstmal einen Überblick ob die Netz Infrastruktur fehlerhaft ist oder ob das was anderes ist !
Sinn macht es an der NIC und am Switchport die Geschw. fest auf 100 Mbit und Fullduplex zu setzen.
Du solltest das mal nur für 2-3 PCs machen im netz, denn so hast du einen Vergleich ob diese Links im Gegensatz zu den Gig Links dann stabiler arbeiten.
Normalerweise erfordert GiG Ethernet mindestens Cat 5e Kabel und Cat5e fähige Dosen und Patchpanels.
Ob dein "Leonie" Kabel und die Ackermann Dosen das sind ist aus deinem Post nicht ersichtlich...leider
Generell kann man sagen das das aber auch mit stinknormalem Cat5 Kabel läuft wenn die einzelnen Längen der Kabel nicht lang sind bzw. an die 100 Meter Grenze kommen.
Der Abbruch muss allerdings nicht ungebdingt aus der Physisk resultieren ! Es kann ja auch die SW selber sein !!
Auch das solltest du wasserdicht testen indem du z.B. mal ein kleines Ping Tool wie den "Big Brother"
http://kin.klever.net/bigbrother
über längere Zeit auf ein paar Clients laufen lässt. So hast du überhaupt erstmal einen Überblick ob die Netz Infrastruktur fehlerhaft ist oder ob das was anderes ist !
Moin,
1998 war CAT5 noch CAT5. Heute ist CAT5 normiert wie das frühere CAT5e, das per se für GBIT-LAN standardisiert war. Prinzipiell würde ich bei Dir von "echtem" CAT5 ausgehen ... dann kann dann GBIT-LAN funktionieren, muss aber nicht. Ruf doch mal den Hersteller an, wenn Du schon Markenkabel eingezugen hast ...
Das Ausprobieren mit fixen 100Mbit ist nicht weiter auffwändig, kannst Du schon mal spielen ... ob aber dort der Hase im Pfeffer liegt??
Gibt es events auf dem Server oder den Clients, die zeitlich zum Problem passen? Ist die Hardware des Servers geeignet und up to date?
LG, Thomas
1998 war CAT5 noch CAT5. Heute ist CAT5 normiert wie das frühere CAT5e, das per se für GBIT-LAN standardisiert war. Prinzipiell würde ich bei Dir von "echtem" CAT5 ausgehen ... dann kann dann GBIT-LAN funktionieren, muss aber nicht. Ruf doch mal den Hersteller an, wenn Du schon Markenkabel eingezugen hast ...
Das Ausprobieren mit fixen 100Mbit ist nicht weiter auffwändig, kannst Du schon mal spielen ... ob aber dort der Hase im Pfeffer liegt??
Gibt es events auf dem Server oder den Clients, die zeitlich zum Problem passen? Ist die Hardware des Servers geeignet und up to date?
LG, Thomas
Hallo,
was verstehst Du unter "Verbindungsabbrüchen"? Meinst Du eine "Time Out"- Fehlermeldung in Deinem Medistar- Client? Oder verliert der PC die Verbindung zum Netzwerk (keine Laufwerkszugriffe)? Wie äußert sich der Fehler konkret.
Ich hatte mal einen ähnlichen Effekt: Wir setzen das Programm HWP von Sage als Buchhaltungssoftware ein. Eine zeitlang flogen bestimmte Clients mit einem "Time Out"- Fehler aus ihrer Verbindung zum HWP- Server. Alle anderen Netzwerkdienste funktionierten einwandfrei. Nach (jahre-) langem Streit mit dem uns betreuenden Sage- Partner und diversen Strukturänderungen im Netzwerk (Verkabelungsfehler wurden vorher durch erneute Zertifizierung-Messung der Links ausgeschlossen) und einem Wechsel des Suportpartners habe ich folgene Vermutung für die Verbindungsabbrüche. Sage hat das Zeitfenster, in dem ein Client auf eine Server- Anfrage antworten muß (oder umgekehrt) so klein gehalten, das "normale" Verzögerungen im Datentransfer schon zu einem "Time Out" führen können. Andere Netzwerkfunktionen sind da wesentlich tolleranter oder machen einfach einen Reconnect. Unter "normaler" Verzögerung im Netzwerk verstehe ich den immer mal wieder auftretenden "Stau" durch Switch-Auslastung, Server~ usw.. Mitlerweile ist es so, dass sich alle an der "Buchhaltung" beteiligten Komponenten (Clients, DB- Server, AD- Server, Print- Server) als VM´s in einem eigenem VLAN befinden. Damit hatte ich dann endlich "Ruhe".
Wenn du ein hardwaremäßig nicht geeignettes Gigabit-Netzwerk vermutest, leihe Dir ein einsprechendes Meßgerät aus und messe die Links durch. Da erhälts Du ein entsprechenden Meß- Protokoll- Ausdruck. Alles andere ist in diesem Zusammenhang "Bastelei".
Versuche den Datenverkehr der Medistar- Applikation im Switch zu priorisieren.
Befreie den Server von allen "Nicht-" Medistar- Diensten. Denke auch an den Virenscanner und automatische Update- Suchen von MS oder anderen Anwendungen (Java, Adobe....), die einen Rechner kurzzeitig "blockieren" können. Schaue Dir in diesem Zusammenhang auch mal die Clients an.
MfG
Jürgen
was verstehst Du unter "Verbindungsabbrüchen"? Meinst Du eine "Time Out"- Fehlermeldung in Deinem Medistar- Client? Oder verliert der PC die Verbindung zum Netzwerk (keine Laufwerkszugriffe)? Wie äußert sich der Fehler konkret.
Ich hatte mal einen ähnlichen Effekt: Wir setzen das Programm HWP von Sage als Buchhaltungssoftware ein. Eine zeitlang flogen bestimmte Clients mit einem "Time Out"- Fehler aus ihrer Verbindung zum HWP- Server. Alle anderen Netzwerkdienste funktionierten einwandfrei. Nach (jahre-) langem Streit mit dem uns betreuenden Sage- Partner und diversen Strukturänderungen im Netzwerk (Verkabelungsfehler wurden vorher durch erneute Zertifizierung-Messung der Links ausgeschlossen) und einem Wechsel des Suportpartners habe ich folgene Vermutung für die Verbindungsabbrüche. Sage hat das Zeitfenster, in dem ein Client auf eine Server- Anfrage antworten muß (oder umgekehrt) so klein gehalten, das "normale" Verzögerungen im Datentransfer schon zu einem "Time Out" führen können. Andere Netzwerkfunktionen sind da wesentlich tolleranter oder machen einfach einen Reconnect. Unter "normaler" Verzögerung im Netzwerk verstehe ich den immer mal wieder auftretenden "Stau" durch Switch-Auslastung, Server~ usw.. Mitlerweile ist es so, dass sich alle an der "Buchhaltung" beteiligten Komponenten (Clients, DB- Server, AD- Server, Print- Server) als VM´s in einem eigenem VLAN befinden. Damit hatte ich dann endlich "Ruhe".
Wenn du ein hardwaremäßig nicht geeignettes Gigabit-Netzwerk vermutest, leihe Dir ein einsprechendes Meßgerät aus und messe die Links durch. Da erhälts Du ein entsprechenden Meß- Protokoll- Ausdruck. Alles andere ist in diesem Zusammenhang "Bastelei".
Versuche den Datenverkehr der Medistar- Applikation im Switch zu priorisieren.
Befreie den Server von allen "Nicht-" Medistar- Diensten. Denke auch an den Virenscanner und automatische Update- Suchen von MS oder anderen Anwendungen (Java, Adobe....), die einen Rechner kurzzeitig "blockieren" können. Schaue Dir in diesem Zusammenhang auch mal die Clients an.
MfG
Jürgen
Hi Dr. Möck,
Ein Test mit 100Mbit/s und gar feste Vollduplex Einstellungen sind kontraproduktiv.
Deine Kabel sind für Gigabit überquaklifiziert. Die Dosen, laut den damaligen Specs, machen sauber Gigabit. Das gilt immer noch.
Wenn unbedingt 100Mbit, dann autonegation mit max 100Mbit/s, was aber nicht viele Switche unterstützen.
Und ein Verbindungsabbruch ist je kein Vorgang, der durch das Wackeln am Kabel verursacht wrid.
Aber - Wie äußert sich der Verbindungsabbruch? Kurzes Hängen, Neuanmeldung?
Also guck erst mal auf die Infrastruktur, die aktiv ist.
Was ist das für ein Switch?
Wie ist der SBS mit dem Switch verbunden?
Wer macht DNS und DHCP?
Und wenn es ein gemanagter Switch ist (wie sollte man sonst FDX einstellen), dann kannst du schon mal einen Wireshark laufen lassen. Erst an einem normalen Switchport ohne weitere Konfiguration. Später am Spiegelport (Monitor) des Servers.
Gruß
Netman
Ein Test mit 100Mbit/s und gar feste Vollduplex Einstellungen sind kontraproduktiv.
Deine Kabel sind für Gigabit überquaklifiziert. Die Dosen, laut den damaligen Specs, machen sauber Gigabit. Das gilt immer noch.
Wenn unbedingt 100Mbit, dann autonegation mit max 100Mbit/s, was aber nicht viele Switche unterstützen.
Und ein Verbindungsabbruch ist je kein Vorgang, der durch das Wackeln am Kabel verursacht wrid.
Aber - Wie äußert sich der Verbindungsabbruch? Kurzes Hängen, Neuanmeldung?
Also guck erst mal auf die Infrastruktur, die aktiv ist.
Was ist das für ein Switch?
Wie ist der SBS mit dem Switch verbunden?
Wer macht DNS und DHCP?
Und wenn es ein gemanagter Switch ist (wie sollte man sonst FDX einstellen), dann kannst du schon mal einen Wireshark laufen lassen. Erst an einem normalen Switchport ohne weitere Konfiguration. Später am Spiegelport (Monitor) des Servers.
Gruß
Netman
Moin nochmal,
. Als Laie hat man es eben gut in einem Fachforum - ich darf alles babeln, und keiner darf mir das übelnehmen 
Frage ist tatsächlich: wie machen sich die Verbindungsabbrüche bemerkbar? Hängt da nur Medistar? Oder bricht die komplette client-server-Kommunikation zusammen? Was nutzt Medistar eigentlich für eine Datenbank?
LG, Thomas
Befreie den Server von allen "Nicht-" Medistar- Diensten.
das wird beim SBS schwierig ...Denke auch an den Virenscanner
... und Firewall!Deine Kabel sind für Gigabit überquaklifiziert
Das würde ich (als Laie) bezweifeln. 1998 war für GBIT CAT5e Standard ... wie die Leonie-Kabel allerdings spezifiziert sind ... keine-Ahnung . Als Laie hat man es eben gut in einem Fachforum - ich darf alles babeln, und keiner darf mir das übelnehmen Frage ist tatsächlich: wie machen sich die Verbindungsabbrüche bemerkbar? Hängt da nur Medistar? Oder bricht die komplette client-server-Kommunikation zusammen? Was nutzt Medistar eigentlich für eine Datenbank?
LG, Thomas
Hallo,
gab es bei MS nicht eine Option, den SBS mit oder ohne SQL-DB zu kaufen. Und konnte man dann nicht mehr als einen phy. Server installieren (DB-Server und Server für den "Rest" - AD, File, Mail usw.). In der langen Geschichte des SQL-Servers von MS gab es immer die Empfehlung, ihn separat zu installieren. Der SQL-Server von MS ist eben ein kleines "Sensibelchen".
Aber wir wissen ja noch nicht, ob MS-SQL im Einsatz ist.
Auch unsere anderen Fragen wurden ja noch nicht beantwortet.
Mir fallen da noch die "modernen" Stromspar- Funktionen im Netzwerk ein. Wenn die NIC oder der Switch-Port aus Energiespar-Gründen "schlafen" geht, erhöht sich die Latenz im Netzwerk beim "Aufwachen" spürbar. Gab es gerade in der ct einen Artikel drüber.
MfG
Jürgen
gab es bei MS nicht eine Option, den SBS mit oder ohne SQL-DB zu kaufen. Und konnte man dann nicht mehr als einen phy. Server installieren (DB-Server und Server für den "Rest" - AD, File, Mail usw.). In der langen Geschichte des SQL-Servers von MS gab es immer die Empfehlung, ihn separat zu installieren. Der SQL-Server von MS ist eben ein kleines "Sensibelchen".
Aber wir wissen ja noch nicht, ob MS-SQL im Einsatz ist.
Auch unsere anderen Fragen wurden ja noch nicht beantwortet.
Mir fallen da noch die "modernen" Stromspar- Funktionen im Netzwerk ein. Wenn die NIC oder der Switch-Port aus Energiespar-Gründen "schlafen" geht, erhöht sich die Latenz im Netzwerk beim "Aufwachen" spürbar. Gab es gerade in der ct einen Artikel drüber.
MfG
Jürgen
Hallo,
das Leoni Kabel ist wohl tauglich, bei den Dosen und den Patchfeldern weiß ich es nicht, da steht nur CAT 5 drauf.
Der Abbruch gestaltet sich folgendermaßen: 1 Client verliert die Verbundung zum Server, daraufhin wird der Dienst auf dem Server beendet und alle 12 PC verlieren die Verbindung, aber nur mit Medistar. Alle anderen Programme, z.B. Outlook und Exchange laufen problemlos weiter. Der Abbruch wird im Windows Anwendungsprotokoll als Fehler protokolliert:
Protokollname: Application
Quelle: RPCI
Datum: 29.07.2013 14:10:05
Ereignis-ID: 0
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: SERVER2.medislim.local
Beschreibung:
Die Beschreibung für die Ereignis-ID "0" aus der Quelle "RPCI" wurde nicht gefunden. Entweder ist die Komponente, die dieses Ereignis auslöst, nicht auf dem lokalen Computer installiert, oder die Installation ist beschädigt. Sie können die Komponente auf dem lokalen Computer installieren oder reparieren.
Falls das Ereignis auf einem anderen Computer aufgetreten ist, mussten die Anzeigeinformationen mit dem Ereignis gespeichert werden.
Die folgenden Informationen wurden mit dem Ereignis gespeichert:
RPCI-Info
RPC-Verbindung zu Computer WORK27, Task 8 unterbrochen, EmergencyClose fehlgeschlagen, Context = 852F40, Exception = 0
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="RPCI" />
<EventID Qualifiers="0">0</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2013-07-29T12:10:05.000000000Z" />
<EventRecordID>1495057</EventRecordID>
<Channel>Application</Channel>
<Computer>SERVER2.medislim.local</Computer>
<Security />
</System>
<EventData>
<Data> RPCI-Info</Data>
<Data>RPC-Verbindung zu Computer WORK27, Task 8 unterbrochen, EmergencyClose fehlgeschlagen, Context = 852F40, Exception = 0</Data>
</EventData>
</Event>
Der RPCI Dienst ist wie folgt definiert:
MEDISTAR RPCI
Der Zugriff von einer Workstation aus erfolgt über ein RPC-Call (Remote Procedure Call). Dieser kann als Anfrage
über NamedPipe, TCP oder UDP erfolgen. Diese Anfrage wird auf dem Server vom Dienst “MEDISTAR RPCI” entgegengenommen
und an dem ISAM weitergeleitet. Die erforderlichen TCP-Ports, die eingehend geöffnet sein müssen,
sind die Ports 137, 138, 139 und 4445.
Zusätzlich muss für die Kommunikation via TCP/UDP der konfigurierbare Port eingehend geöffnet sein (default:
16000).
MEDISTAR ISMON
Der “MEDISTAR ISMON” ist der WatchDog vom ISAM. Bei Fehlern schreibt dieser die Informationen in das Windows-
Ereignisprotokoll.
das Leoni Kabel ist wohl tauglich, bei den Dosen und den Patchfeldern weiß ich es nicht, da steht nur CAT 5 drauf.
Der Abbruch gestaltet sich folgendermaßen: 1 Client verliert die Verbundung zum Server, daraufhin wird der Dienst auf dem Server beendet und alle 12 PC verlieren die Verbindung, aber nur mit Medistar. Alle anderen Programme, z.B. Outlook und Exchange laufen problemlos weiter. Der Abbruch wird im Windows Anwendungsprotokoll als Fehler protokolliert:
Protokollname: Application
Quelle: RPCI
Datum: 29.07.2013 14:10:05
Ereignis-ID: 0
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: SERVER2.medislim.local
Beschreibung:
Die Beschreibung für die Ereignis-ID "0" aus der Quelle "RPCI" wurde nicht gefunden. Entweder ist die Komponente, die dieses Ereignis auslöst, nicht auf dem lokalen Computer installiert, oder die Installation ist beschädigt. Sie können die Komponente auf dem lokalen Computer installieren oder reparieren.
Falls das Ereignis auf einem anderen Computer aufgetreten ist, mussten die Anzeigeinformationen mit dem Ereignis gespeichert werden.
Die folgenden Informationen wurden mit dem Ereignis gespeichert:
RPCI-Info
RPC-Verbindung zu Computer WORK27, Task 8 unterbrochen, EmergencyClose fehlgeschlagen, Context = 852F40, Exception = 0
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="RPCI" />
<EventID Qualifiers="0">0</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2013-07-29T12:10:05.000000000Z" />
<EventRecordID>1495057</EventRecordID>
<Channel>Application</Channel>
<Computer>SERVER2.medislim.local</Computer>
<Security />
</System>
<EventData>
<Data> RPCI-Info</Data>
<Data>RPC-Verbindung zu Computer WORK27, Task 8 unterbrochen, EmergencyClose fehlgeschlagen, Context = 852F40, Exception = 0</Data>
</EventData>
</Event>
Der RPCI Dienst ist wie folgt definiert:
MEDISTAR RPCI
Der Zugriff von einer Workstation aus erfolgt über ein RPC-Call (Remote Procedure Call). Dieser kann als Anfrage
über NamedPipe, TCP oder UDP erfolgen. Diese Anfrage wird auf dem Server vom Dienst “MEDISTAR RPCI” entgegengenommen
und an dem ISAM weitergeleitet. Die erforderlichen TCP-Ports, die eingehend geöffnet sein müssen,
sind die Ports 137, 138, 139 und 4445.
Zusätzlich muss für die Kommunikation via TCP/UDP der konfigurierbare Port eingehend geöffnet sein (default:
16000).
MEDISTAR ISMON
Der “MEDISTAR ISMON” ist der WatchDog vom ISAM. Bei Fehlern schreibt dieser die Informationen in das Windows-
Ereignisprotokoll.
Server hat folgende Konstellation:
Supermicro 1U SATA Server w/ 2x Intel Xeon Quad Core 2.5GHz/28GB RAM X7DBU SC815TQ
Switch: HP ProCurve 2810-24G
Wie kann ich den Datenverkehr des Medistar Programms im Switch priorisieren?
DNS und DHCP macht der SBS 2011, die Verbindung zum Switch läuft über 1 Kabel, was CAT 5e verifiziert ist.
Medistar nutzt eine Oracle Datenbank, aber auch verschiedene "ISAM-Datenbanken"
Supermicro 1U SATA Server w/ 2x Intel Xeon Quad Core 2.5GHz/28GB RAM X7DBU SC815TQ
Switch: HP ProCurve 2810-24G
Wie kann ich den Datenverkehr des Medistar Programms im Switch priorisieren?
DNS und DHCP macht der SBS 2011, die Verbindung zum Switch läuft über 1 Kabel, was CAT 5e verifiziert ist.
Medistar nutzt eine Oracle Datenbank, aber auch verschiedene "ISAM-Datenbanken"
Moin
Das wurde erreicht durch Auffrufen von "csetup.exe -sysop". Dort im Reiter Optionen können/konnten diese Werte angepasst werden.
Ich glaube aber nicht, dass es daran lag, sondern eher an anderen Dingen, wie bspw. dem Problem, das die Verbindung zur Datenbank auf dem Server abbrach, sobald die HDD im Client-PC in den Stromsparmodus gewechselt ist.
Hatte ich bei vielen Installationen dieses Programms beobachtet.
Wie aqui es schon sagte, ist es oftmals ein SW- und kein HW-Problem.
Ich hatte mal einen ähnlichen Effekt: Wir setzen das Programm HWP von Sage als Buchhaltungssoftware ein.
Wohl eher die Auftragsbearbeitung, denn die Buchhaltung, aber will ich mal nicht so kleinlich sein. Eine zeitlang flogen bestimmte Clients mit einem "Time Out"- Fehler aus ihrer Verbindung zum HWP- Server. Alle anderen Netzwerkdienste
funktionierten einwandfrei. Nach (jahre-) langem Streit mit dem uns betreuenden Sage- Partner und diversen
Strukturänderungen im Netzwerk (Verkabelungsfehler wurden vorher durch erneute Zertifizierung-Messung der Links
ausgeschlossen) und einem Wechsel des Suportpartners habe ich folgene Vermutung für die Verbindungsabbrüche. Sage hat
das Zeitfenster, in dem ein Client auf eine Server- Anfrage antworten muß (oder umgekehrt) so klein gehalten, das
"normale" Verzögerungen im Datentransfer schon zu einem "Time Out" führen können.
Es gab/gibt dort eine Funktion, die Verbindungstimeouteinstellungen zu verändern.funktionierten einwandfrei. Nach (jahre-) langem Streit mit dem uns betreuenden Sage- Partner und diversen
Strukturänderungen im Netzwerk (Verkabelungsfehler wurden vorher durch erneute Zertifizierung-Messung der Links
ausgeschlossen) und einem Wechsel des Suportpartners habe ich folgene Vermutung für die Verbindungsabbrüche. Sage hat
das Zeitfenster, in dem ein Client auf eine Server- Anfrage antworten muß (oder umgekehrt) so klein gehalten, das
"normale" Verzögerungen im Datentransfer schon zu einem "Time Out" führen können.
Das wurde erreicht durch Auffrufen von "csetup.exe -sysop". Dort im Reiter Optionen können/konnten diese Werte angepasst werden.
Ich glaube aber nicht, dass es daran lag, sondern eher an anderen Dingen, wie bspw. dem Problem, das die Verbindung zur Datenbank auf dem Server abbrach, sobald die HDD im Client-PC in den Stromsparmodus gewechselt ist.
Hatte ich bei vielen Installationen dieses Programms beobachtet.
Andere
Netzwerkfunktionen sind da wesentlich tolleranter oder machen einfach einen Reconnect. Unter "normaler" Verzögerung
im Netzwerk verstehe ich den immer mal wieder auftretenden "Stau" durch Switch-Auslastung, Server~ usw.. Mitlerweile ist
es so, dass sich alle an der "Buchhaltung" beteiligten Komponenten (Clients, DB- Server, AD- Server, Print- Server) als
VM´s in einem eigenem VLAN befinden. Damit hatte ich dann endlich "Ruhe".
Natürlich könnte es auch sein, dass es ein Problem mit unsauber programmierter Software war. Habe ich bei diesem Produkt heute noch regelmäßig.Netzwerkfunktionen sind da wesentlich tolleranter oder machen einfach einen Reconnect. Unter "normaler" Verzögerung
im Netzwerk verstehe ich den immer mal wieder auftretenden "Stau" durch Switch-Auslastung, Server~ usw.. Mitlerweile ist
es so, dass sich alle an der "Buchhaltung" beteiligten Komponenten (Clients, DB- Server, AD- Server, Print- Server) als
VM´s in einem eigenem VLAN befinden. Damit hatte ich dann endlich "Ruhe".
Befreie den Server von allen "Nicht-" Medistar- Diensten. Denke auch an den Virenscanner
Virenwächter sind die ersten Programme, die bei Verbindungsproblemen temporär deinstalliert und nicht deaktiviert werden sollten.Wie aqui es schon sagte, ist es oftmals ein SW- und kein HW-Problem.
Zitat von @drmmoeck:
Wie kann ich den Datenverkehr des Medistar Programms im Switch priorisieren?
DNS und DHCP macht der SBS 2011, die Verbindung zum Switch läuft über 1 Kabel, was CAT 5e verifiziert ist.
Medistar nutzt eine Oracle Datenbank, aber auch verschiedene "ISAM-Datenbanken"
Wie kann ich den Datenverkehr des Medistar Programms im Switch priorisieren?
DNS und DHCP macht der SBS 2011, die Verbindung zum Switch läuft über 1 Kabel, was CAT 5e verifiziert ist.
Medistar nutzt eine Oracle Datenbank, aber auch verschiedene "ISAM-Datenbanken"
Die Datenbanken sind der Schlüssel zur Fehlersuche. Wie viele sind es denn neben Oracle.
Liegen die alle auf dem selben Server?
"RPCI" sagt mir nichts. Ich dachte erst an eine Art Protokoll oder Ereignis. Ist aber wohl der Name von?
Den Switch brauchst du dafür nicht zu priorisieren, zumal alles über die üblichen Ports läuft.
Der Switch wird auch keinen Stress haben. Kann man mit dem freien Tool Switchportmonitor via SNMP testen. -> http://www.it-administrator.de/downloads/software/86411/
Gruß
Netman
Hallo, Herr Kollege,
noch ein Weisskittel hier im board?
Das sieht mir vordergründig nicht nach einem Strippenproblem aus.
Erste Frage: Was sagt der Support von Medistar zu dem Sachverhalt?
Zweite Frage: Wie ausgelastet ist der SBS, wenn dort die Medistar-Datenbanken laufen?
Dritte Frage: Was hast Du für Festplatten im Server (SATA / SAS, welche Rotationsgeschwindigkeit) und was für ein Festplattencontroller / RAID-Design wird benutzt?
Ich habe insgesamt den Eindruck, dass sich viele AIS auf grottenalten Datenbankdesigns rumlümmeln, es entzieht sich auch völlig meiner Kenntnis, was die Softwarehäuser mit den nicht unerheblichen "Pflegegebühren" veranstalten ... ausser nutzlose gimmicks kostenpflichtig implementieren zu wollen.
Prinzipiell empfiehlt sich, Folgendes zu überprüfen:
- Treiber der NIC aktuell?
- Firmware des RAID-controllers und der Festplatten aktuell?
- BIOS der beteiligten Büchsen aktuell?
- Energiesparoptionen an NIC und Festplatten inaktiv?
- DNS / DHCP in Ordnung (ich persönlich arbeite in der Praxis ausschliesslich mit festen Adressen - etwas grösserer Aufwand, aber ein gutes Gefühl)
- Zeitsynchronisation im LAN korrekt?
- RAM in Ordnung?
- Server - Festplatten in Ordnung?
LG, Thomas
noch ein Weisskittel hier im board
?Das sieht mir vordergründig nicht nach einem Strippenproblem aus.
Erste Frage: Was sagt der Support von Medistar zu dem Sachverhalt?
Zweite Frage: Wie ausgelastet ist der SBS, wenn dort die Medistar-Datenbanken laufen?
Dritte Frage: Was hast Du für Festplatten im Server (SATA / SAS, welche Rotationsgeschwindigkeit) und was für ein Festplattencontroller / RAID-Design wird benutzt?
Ich habe insgesamt den Eindruck, dass sich viele AIS auf grottenalten Datenbankdesigns rumlümmeln, es entzieht sich auch völlig meiner Kenntnis, was die Softwarehäuser mit den nicht unerheblichen "Pflegegebühren" veranstalten ... ausser nutzlose gimmicks kostenpflichtig implementieren zu wollen.
Prinzipiell empfiehlt sich, Folgendes zu überprüfen:
- Treiber der NIC aktuell?
- Firmware des RAID-controllers und der Festplatten aktuell?
- BIOS der beteiligten Büchsen aktuell?
- Energiesparoptionen an NIC und Festplatten inaktiv?
- DNS / DHCP in Ordnung (ich persönlich arbeite in der Praxis ausschliesslich mit festen Adressen - etwas grösserer Aufwand, aber ein gutes Gefühl
)- Zeitsynchronisation im LAN korrekt?
- RAM in Ordnung?
- Server - Festplatten in Ordnung?
LG, Thomas
Zitat von @goscho:
Es gab/gibt dort eine Funktion, die Verbindungstimeouteinstellungen zu verändern.
Das wurde erreicht durch Auffrufen von "csetup.exe -sysop". Dort im Reiter Optionen können/konnten diese Werte
angepasst werden.
Ich glaube aber nicht, dass es daran lag, sondern eher an anderen Dingen, wie bspw. dem Problem, das die Verbindung zur Datenbank
auf dem Server abbrach, sobald die HDD im Client-PC in den Stromsparmodus gewechselt ist.
Hatte ich bei vielen Installationen dieses Programms beobachtet.
Es gab/gibt dort eine Funktion, die Verbindungstimeouteinstellungen zu verändern.
Das wurde erreicht durch Auffrufen von "csetup.exe -sysop". Dort im Reiter Optionen können/konnten diese Werte
angepasst werden.
Ich glaube aber nicht, dass es daran lag, sondern eher an anderen Dingen, wie bspw. dem Problem, das die Verbindung zur Datenbank
auf dem Server abbrach, sobald die HDD im Client-PC in den Stromsparmodus gewechselt ist.
Hatte ich bei vielen Installationen dieses Programms beobachtet.
Danke für den Tipp. Werde ich mir mal näher anschauen.
Noch ein Hinweis an drmmoeck:
Unser Sage- Partner weist auch immer darauf hin, dass die Art des Zugriffs (NamePipe, TCP usw.) entscheidend für die Stabilität der Verbindung ist. Nutze doch mal eine andere Verbindung.
Ich kann keine-ahnung nur beipflichten, erstmal ist der Support von Medistar gefordert. Wenn MS den Vorgang im Ereignisprotokoll vermerkt, muß der Medistar-Support mit seinen Verbindungen zu Oracle und MS doch eine Antwort geben können.
MfG
Jürgen
Zitat von @keine-ahnung:
Hallo, Herr Kollege,
noch ein Weisskittel hier im board?
Das sieht mir vordergründig nicht nach einem Strippenproblem aus.
Erste Frage: Was sagt der Support von Medistar zu dem Sachverhalt?
Hallo, Herr Kollege,
noch ein Weisskittel hier im board
?Das sieht mir vordergründig nicht nach einem Strippenproblem aus.
Erste Frage: Was sagt der Support von Medistar zu dem Sachverhalt?
vermutet ein Netzwerkproblem>
Zweite Frage: Wie ausgelastet ist der SBS, wenn dort die Medistar-Datenbanken laufen?
CPU 2%, Arbeitsspeicher59%, Netzwerk 0,12%
Dritte Frage: Was hast Du für Festplatten im Server (SATA / SAS, welche Rotationsgeschwindigkeit) und was für ein
Festplattencontroller / RAID-Design wird benutzt?
Hatte zunächst 2 SATA II Platten als Raid 1 mit dem werksseitig eingebauten Intel Controller laufen, seit 4 Wochen jetzt eine Samsung 840Pro SSD mit 500GB mit einem PCI-e Controller ohne Raid. System ist gefühlt doppelt so schnell, macht aber weiter die gleichen Abbrüche.
Ich habe insgesamt den Eindruck, dass sich viele AIS auf grottenalten Datenbankdesigns rumlümmeln, es entzieht sich auch
völlig meiner Kenntnis, was die Softwarehäuser mit den nicht unerheblichen "Pflegegebühren" veranstalten
... ausser nutzlose gimmicks kostenpflichtig implementieren zu wollen.
Prinzipiell empfiehlt sich, Folgendes zu überprüfen:
- Treiber der NIC aktuell?
- Firmware des RAID-controllers und der Festplatten aktuell?
ja, ebenfalls
- BIOS der beteiligten Büchsen aktuell?
bis dato nicht kontrolliert
- Energiesparoptionen an NIC und Festplatten inaktiv?
ja- DNS / DHCP in Ordnung (ich persönlich arbeite in der Praxis ausschliesslich mit festen Adressen - etwas grösserer
Aufwand, aber ein gutes Gefühl)
Aufwand, aber ein gutes Gefühl
)denke ich schon, beides funktioniert vordergründig gut
- Zeitsynchronisation im LAN korrekt?
ja
- RAM in Ordnung?
RAM ist < 6 Monate alt, es stürzt ja auch nur der eine Dienst ab und nicht der Rechner
- Server - Festplatten in Ordnung?
ja
LG, Thomas
Hallo,
was sagt denn nun der Medistar- Support zu dem Problem? Überhaupt schon dort mal angefragt?
Frage am Rande: Das sieht mir sehr nach einem "Eigenbau-Server" aus. Kann sich der Arzt keinen zertfizierten Server leisten? Und wie sieht das der Medistar- Support? Das ist zwar nicht die Ursache für das Problem, doch stellt sich mir die Frage, wie man eine geschäftskritische Software auf so einem Server laufen läßt.
Storage ohne RAID; Komponenten, die nicht für den gemeinsamen Einsatz zertifiziert sind; in der Summe Hardware, die nicht für die eingesetzte Software zertifiziert ist usw. Ich will hier keine Werbung für die großen Serverhersteller machen, aber die zentrale Software in einer Arzt- Praxis auf einem "Eigenbau- Server" ist für alle Beteiligten (der Arzt als Verantwortlicher, die Srechstundenhilfe als Benutzer, die Patienten als die Dateneigentümer und nicht zuletzt Du, als IT- Betreuer) Russisches Roulette!
MfG
Jürgen
was sagt denn nun der Medistar- Support zu dem Problem? Überhaupt schon dort mal angefragt?
Frage am Rande: Das sieht mir sehr nach einem "Eigenbau-Server" aus. Kann sich der Arzt keinen zertfizierten Server leisten? Und wie sieht das der Medistar- Support? Das ist zwar nicht die Ursache für das Problem, doch stellt sich mir die Frage, wie man eine geschäftskritische Software auf so einem Server laufen läßt.
Storage ohne RAID; Komponenten, die nicht für den gemeinsamen Einsatz zertifiziert sind; in der Summe Hardware, die nicht für die eingesetzte Software zertifiziert ist usw. Ich will hier keine Werbung für die großen Serverhersteller machen, aber die zentrale Software in einer Arzt- Praxis auf einem "Eigenbau- Server" ist für alle Beteiligten (der Arzt als Verantwortlicher, die Srechstundenhilfe als Benutzer, die Patienten als die Dateneigentümer und nicht zuletzt Du, als IT- Betreuer) Russisches Roulette!
MfG
Jürgen
Zitat von @chiefteddy:
was sagt denn nun der Medistar- Support zu dem Problem? Überhaupt schon dort mal angefragt?
Das hatte der Kollege bereits geschrieben? Das "vermutete Netzwerkproblem" ist auch eine Standardfloskel, wenn diese verschxxxenen Datenbanken querschiessen was sagt denn nun der Medistar- Support zu dem Problem? Überhaupt schon dort mal angefragt?
. Schuld sind immer die Anderen ...Bezüglich der genutzten HDD stimme ich ein Stück weit zu, aber auch diese werden nicht des Rätsels Lösung sein ...
Du als IT- Betreuer
Ich fürchte fast, der TO ist eher mein Kollege als Deiner .RAM ist < 6 Monate alt, es stürzt ja auch nur der eine Dienst ab und nicht der Rechner
Beides will jetzt nicht viel heissen - lass da zumindest mal memtest oder Ähnliches rüberlaufen ....Vordergründig würde ich mich aber zunächst um Virenscanner und Firewall kümmern wollen ...
LG, Thomas
Stimme ich Dir ausdrücklich zu. Jedesmal war was anderes in meinem Netz Schuld. Am Ende habe ich ihnen ein Netzwerk nach ihren Wünschen "gebaut" (geht mit VM´s ja relativ leicht), und siehe da, die Probleme waren immer noch da. Da wurde die Luft für sie ganz dünn. Und schwups waren sie den Vertrag los. Marktwirtschaft hat eben auch Vorteile.
...
Vordergründig würde ich mich aber zunächst um Virenscanner und Firewall kümmern wollen ...
Vordergründig würde ich mich aber zunächst um Virenscanner und Firewall kümmern wollen ...
Hier noch mal der Hinweis, das unser neuer Systempartner (für Sage - HWP) ausdrücklich darauf verweist, dass als Netzwerk- Protokoll ausschließlich TCP/IP genutzt werden soll, nicht NamePipes oä.. (in der Client- Server- Konfiguration von Medistar einstellen, wenn möglich) Mal nachschauen, gegebenenfalls ändern und testen.
MfG
Jürgen
Hallo,
Medistar kommuniziert bereits über Name Pipe und TCP Port 16000. Ich hatte nach 2 Jahren den Server hardwaremäßig komplett erneuert:, das Problem ist geblieben. Das mit der Firewall und der Deinstallation des Virenwächters (TrendMicro Worry free Business Security) werde ich ausprobieren.
Erst mal vielen Dank für Eure Tips !
Medistar kommuniziert bereits über Name Pipe und TCP Port 16000. Ich hatte nach 2 Jahren den Server hardwaremäßig komplett erneuert:, das Problem ist geblieben. Das mit der Firewall und der Deinstallation des Virenwächters (TrendMicro Worry free Business Security) werde ich ausprobieren.
Erst mal vielen Dank für Eure Tips !
Ist die Kommunikation zwecks TCP Port 16000 auch in der Registry des Servers und den Sysconf.s des jeweiligen Rechners sauber drinnen?
Das Phänomen mit den Abrissen, ensteht im Struktur des Domänen Aufbaus. Medistar und Domäne ist immer so eine Sache.
Welche Rechte haben die User an den Pcs?
Ansonsten was für ein Switch wurde verwendet? Konnte nichts darüber lesen. Lieber eine Dumme als eine zu sehr intelligente Switch testen.
Die Verkabelung kannst du testweise mit on the fly Kabeln testen, sprich, die auffäligsten Rechner direkt mit dem Switch verbinden. Wenn es auch für einen Tag ist.
Firewall Einstellungen prüfen, ob alle Ports freigegeben sind. Die Strukturen der Firewall Erkennung ob privat oder ähnliches prüfen. Wenn es auch öffentlich steht, dann ist sie fast dicht.
Oder in der Gruppenrichtlinien prüfen ob die Netzwerkszugriffe irgendwie erschwert werde wie z.B. Anonymen Zugriff auf Named Pipes und Freigaben einschränken, oder
Anonyme SID Namensübersetzung zulassen.
Das Phänomen mit den Abrissen, ensteht im Struktur des Domänen Aufbaus. Medistar und Domäne ist immer so eine Sache.
Welche Rechte haben die User an den Pcs?
Ansonsten was für ein Switch wurde verwendet? Konnte nichts darüber lesen. Lieber eine Dumme als eine zu sehr intelligente Switch testen.
Die Verkabelung kannst du testweise mit on the fly Kabeln testen, sprich, die auffäligsten Rechner direkt mit dem Switch verbinden. Wenn es auch für einen Tag ist.
Firewall Einstellungen prüfen, ob alle Ports freigegeben sind. Die Strukturen der Firewall Erkennung ob privat oder ähnliches prüfen. Wenn es auch öffentlich steht, dann ist sie fast dicht.
Oder in der Gruppenrichtlinien prüfen ob die Netzwerkszugriffe irgendwie erschwert werde wie z.B. Anonymen Zugriff auf Named Pipes und Freigaben einschränken, oder
Anonyme SID Namensübersetzung zulassen.
Wir haben inzwischen die CAT5 Dosen gegen CAT 6 getauscht und neue Patchfelder gesetzt. Die Kabel sind geblieben, ebenso der Switch. Danach sind die Abbrüche um 98% zurückgegangen und kommen nur noch sehr sporadisch vor (1x alle 2 Wochen). Des Rätsels Lösung war also doch wohl unsere Verkabelung. Nochmal allen vielen Dank für Eure Tips und Hinweise!
Auch wenn das jetzt ein bisschen blöd klingt:
Wenn mans genau nimmt muss man zwischen Cat5 und Cat5e unterscheiden. Es gibt die 100%ige Gigabit Sicherheit.
Das trifft ähnlich auf Cat6 zu. Cat6 ist für 250MHz ausgelegt. Das braucht keiner. Cat6A ist für 500MHz ausgelegt und ddas ist schon 10Gbit - tauglich.
Ich vermute aber, dass die Auflegemethode ein kritischer Faktor ist, nicht unbedingt die Hardware. Beim Auflegen konnte man früher sehr viel falsch machen. Heuzutage gibt es fast nur mehr ok oder geht gar nicht.
Beim Erden der Buchsen gibt es auch ncoh eine Möglichkeit Fehler zu machen.
Deine Massnahmen ziehen sich aber so als Empfehlungen durch die ganze Normendiskussion von 100Mbit/s bis 10.000Mbit/s. Die feste Verkabelung ist schwerer auszutauschen. Also lass uns nach anderen Methoden suchen
Gruß
Netman
und vielen Dank für die Rückmeldung
P.S: Stelle den Beitrag auf gelöst.
Wenn mans genau nimmt muss man zwischen Cat5 und Cat5e unterscheiden. Es gibt die 100%ige Gigabit Sicherheit.
Das trifft ähnlich auf Cat6 zu. Cat6 ist für 250MHz ausgelegt. Das braucht keiner. Cat6A ist für 500MHz ausgelegt und ddas ist schon 10Gbit - tauglich.
Ich vermute aber, dass die Auflegemethode ein kritischer Faktor ist, nicht unbedingt die Hardware. Beim Auflegen konnte man früher sehr viel falsch machen. Heuzutage gibt es fast nur mehr ok oder geht gar nicht.
Beim Erden der Buchsen gibt es auch ncoh eine Möglichkeit Fehler zu machen.
Deine Massnahmen ziehen sich aber so als Empfehlungen durch die ganze Normendiskussion von 100Mbit/s bis 10.000Mbit/s. Die feste Verkabelung ist schwerer auszutauschen. Also lass uns nach anderen Methoden suchen
Gruß
Netman
und vielen Dank für die Rückmeldung
P.S: Stelle den Beitrag auf gelöst.
