Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Mac Server Ausfälle

Mac Server Ausfälle

ricard06.11.1623:03
Hallo,

wir betreiben einen macOS server unter El Capitan. Er läuft auf einem Mac Mini 2012 mit 4 GB RAM.
Super happy damit, nur haben wir das Problem, dass der Server öfters unerreichbar ist. Sporadisch, manchmal "fängt" er sich wieder, manchmal muss ich ihn per Hand neustarten.
Inkl. DNS-Server (Webseiten unerreichbar) geht dann nichts mehr. Kann dann auch nicht mit der Bildschirmfreigabe draufschauen.

Meine Vermutung ist ja, dass der Server (unter Last) schlapp macht, wenn der RAM zuneige geht. Schaue ich aber in die Statistik, sehe ich, dass er nie mehr als 3GB RAM braucht und der Speicherdruck auch nie höher als 50% ist.
Das Problem tritt schon auf, wenn nur 2-3 Clients mit dem Server arbeiten.

Aktivierte Dienste: Dateifreigabe, Kalender, Kontakte, Profilmanager, VPN, Websites, Wiki, DNS, Open Directory.

Grüße
Richard
0

Kommentare

arminhempel
arminhempel07.11.1600:23
Schwierig zu diagnostizieren, sowas. Sind die Platten/SSDs, von denen gebootet wird, denn in Ordnung? Das ist bei uns Fehlerquelle No. 1 für OSX-Server-Abstürze.
0
MacRudi07.11.1602:18
Ist es ein Server-Modell, also mit zwei Festplatten? Was hat er da drin? Wieviel GHz?
0
ahnungsloser07.11.1607:39
Bei uns ist Crashplan (aktuell 4.8) für dieses Verhalten zuständig. Hast du dieses vielleicht auch am laufen?
0
virk
virk07.11.1608:16
- Ist das Ethernet okay. Ich kenne solche Phänomene, die durch einen sterbenden switch (schrechliches Phänomen; sie siechen dahin, geben aber Lebenszeichen von sich und wenn man sie testet, geben sie alles )verursacht worden sind. Vielleicht kannst Du den server testweise über airport einbinden und switche tauschen?
- Wer vergibt bei Euch die IP-Adressen? Oder: Kann es sein, dass es Konflikte mit vpn gibt; das bspw. gleiche Netzwerkadressen für beide Netze verwendet werden? Kannst Du vpn mal ausschalten und sehen, ob es noch immer passiert.
- Hat vielleicht ein Rechner des teilnehmenden Netzes eine feste IP, die mit dem vpn clasht? (hier vor kurzem mein thread )
- Hast Du bereits in die Server-Protokolle reingesehen? Nicht, dass ich jetzt wüsste, wo genau Du gucken solltest
- Ich habe hier einen macmini late 2014 8GB yosemite-server laufen. Das, was Du vermutest (macht "schlapp", "fängt sich wieder"), würde ich ihm nicht zutrauen; Fehler könnte auch sterbende Platte/Ram sein.
- Kannst Du das Problem reproduzieren/forcieren?
„Gaststättenbetrieb sucht für Restaurant und Biergarten Servierer:innen und außen.“
0
caMpi
caMpi07.11.1609:09
virk
(macht "schlapp", "fängt sich wieder")
Das kenne ich auch von irgendwoher, auch in Verbindung mit OS X Server(.app) und Mac mini.
Ich komm aber nicht mehr drauf...
Besteht das Problem bei dir von Anfang an? Ich glaube das hing mit irgendeinem Dienst zusammen... DNS? DHCP? OD? Ist aber schon Jahre her...
„Keep IT simple, keep IT safe.“
0
ricard07.11.1622:35
Hallo Leute,

erst mal vielen Dank für die zahlreichen Antworten.
arminhempel
Sind die Platten/SSDs, von denen gebootet wird, denn in Ordnung? Das ist bei uns Fehlerquelle No. 1 für OSX-Server-Abstürze.
Habe jetzt alle Festplatten und alle Partitionen über das Festplattendienstprogramm überprüft ("Erste Hilfe"). Die Überprüfung (wenn es die war, die du meintest) ging schneller, als erwartet. Ohne Macken.
MacRudi
Ist es ein Server-Modell, also mit zwei Festplatten? Was hat er da drin? Wieviel GHz?
Nein, es ist der Mac Mini 6,1 mit 2,5 GHz i5. Intern ist eine Samsung Evo SSD installiert und extern ein WD Thunderbolt Duo und eine USB-3-Intenso-Platte.
ahnungsloser
Bei uns ist Crashplan (aktuell 4.8) für dieses Verhalten zuständig. Hast du dieses vielleicht auch am laufen?
Habe die Software nicht installiert. Generell ist auch nichts weiter installiert, als WD Utility.
virk
- Ist das Ethernet okay. Ich kenne solche Phänomene, die durch einen sterbenden switch (schrechliches Phänomen; sie siechen dahin, geben aber Lebenszeichen von sich und wenn man sie testet, geben sie alles )verursacht worden sind. Vielleicht kannst Du den server testweise über airport einbinden und switche tauschen?
Switche sind ein brennendes Thema in dem Haus. Es sind viele kleine im Haus verteilt und viele auch "in Reihe geschaltet". Ich kann da leider auch nicht viel dran ändern. Aber die gute Nachricht: ich weiß ja welche Clients im Netzwerk sind (und beim Auftreten des Problems war nur der eine iMac an) und die Switches sind mittlerweile alle "nicht älter als 5 Jahre".
Aber ja, das werde ich nochmal verfolgen – zeitintensives Thema…
Kannst du erklären, was ein sterbender Switch mit dem Netzwerk anstellt?
virk
- Wer vergibt bei Euch die IP-Adressen? Oder: Kann es sein, dass es Konflikte mit vpn gibt; das bspw. gleiche Netzwerkadressen für beide Netze verwendet werden? Kannst Du vpn mal ausschalten und sehen, ob es noch immer passiert.
- Hat vielleicht ein Rechner des teilnehmenden Netzes eine feste IP, die mit dem vpn clasht? (hier vor kurzem mein thread )
Das macht die FRITZ!Box 6490. Hab auch extra DHCP beim Server ausgeschaltet gelassen. VPN läuft mittlerweile (direkt auf den Mac), IPs sind außerhalb des eigentlichen Ranges. Vorher gab es Probleme, da die VPN-Verbindung der Fritzbox die des Macs blockiert hatte.
virk
- Hast Du bereits in die Server-Protokolle reingesehen? Nicht, dass ich jetzt wüsste, wo genau Du gucken solltest
Nach dem Neustart waren die Logs wieder so voll geschrieben, dass ich die relevanten Logs zum jeweiligen Zeitpunkt nicht mehr gefunden habe. Muss beim nächsten Mal direkt in die Logs schauen
virk
- Ich habe hier einen macmini late 2014 8GB yosemite-server laufen. Das, was Du vermutest (macht "schlapp", "fängt sich wieder"), würde ich ihm nicht zutrauen; Fehler könnte auch sterbende Platte/Ram sein.
RAM ist original, aber wollte ja sowieso updaten, es sei denn, ich kanns herauszögern… (Noch ist der Server gar nicht voll im Betrieb, sondern in der Einführungsphase)
virk
- Kannst Du das Problem reproduzieren/forcieren?
Ne, leider nicht/wüsste nicht wie. Das eine Mal war ich mit VPN verbunden und habe auf eine Freigabe Daten kopiert Mac abgestürzt. Die anderen Male "einfach so", ohne, dass ich jetzt noch wüsste, was ausschlaggebend war.
caMpi
Besteht das Problem bei dir von Anfang an? Ich glaube das hing mit irgendeinem Dienst zusammen... DNS? DHCP? OD?
Haben den Server erst seit grob einer Woche am laufen Von daher kann ich sagen, dass das Problem von Anfang an besteht.
DHCP war nicht aktiviert, OD kann ich ja nicht so ohne weiteres deaktivieren…
DNS habe ich jetzt deaktiviert, d.h. ich muss es jetzt weiter verfolgen.
0
MikeMuc07.11.1623:40
Lager die VPN-Endpunkte auf die FB aus. Dann kommst du, sofern du grad daheim bist, wenigstens noch ins Netz und kannst schauen "wie weit du noch kommst" im Netz. So ist halt, wenn der Server nicht mag, auch gleich dein Zugangspunkt mit flöten
Wie ist dein DNS konfiguriert? Gehen alle Fragen der Rechner erst über den Server? Muß das so sein oder kannst du nicht den DNS der FB verwenden. Dann sollten die Clients weiter surfen können wenn der Server ausfällt.
Brauchst du die ganzen Dienste die du auf dem Server an hast? Lokale Websites? Was davon kann erstmal abgeschaltet werden? Dann jeweils 2 Wochen warten und erst wenn keine Problem mehr auftreten einen Dienst nach dem anderen wieder aktivieren.
0
virk
virk08.11.1608:01
ricard
Kannst du erklären, was ein sterbender Switch mit dem Netzwerk anstellt?
Nein, ich Detail habe ich da keine Ahnung. Das Problem bei uns waren switche, die alle langsam gestorben sind; eigentlich funktionierten sie, aber halt nicht mehr 100%-ig. Herauszufinden, woran die Probleme lagen, wurde halt ein wenig aufwendig. Die switche liegen bei uns noch irgendwo rum. Jemand, dem ich sie geben würde und der sie einbauen würde, würde sie zunächst als i.O. klassifizieren
ricard
Ne, leider nicht/wüsste nicht wie. Das eine Mal war ich mit VPN verbunden und habe auf eine Freigabe Daten kopiert Mac abgestürzt. Die anderen Male "einfach so", ohne, dass ich jetzt noch wüsste, was ausschlaggebend war.

Von "wo" nach "wo" warst Du mit VPN verbunden? Waren beide Netze wirklich getrennt? Gib' mal beide IPs der internen Netze mit Teilnetzmaske an, die während der VPN-Verbindung in "Benutzung" waren.

Wir haben bei uns ein ähnliches Szenario:
- Fritzbox 7340 (192.168.1.1 fest, wird demnächst auf 192.168.2xx geändert, wegen vpn) als DHCP-Server und für den Internet-Zugang und als DECT-Basis
- Macmini-Yosemite-server (192.168.1.2 fest) als Datei-server, apache (wiki), Kontakte, Kalender (wird nicht genutzt). Den Rest des server benötigen wir bislang nicht. Macmini hängt per ethernet im Netzwerk, hat aber gleichzeitig internetsharing an, so dass die airport-Karte des minis als weiterer drahtloser accesspoint genutzt werden kann. Darüber kann man ins internet als auch auf die serverdienste des mini zugreifen. (Andere Rechner sieht man hierüber nicht)
- Alle clients (7 Mitarbeiter mit Macs, ein paar Dosen, unendliche Mobiltelefone von Angehörigen, Gästen, etc) bekommen ihre IP über die Fritzbox.
- Die vpn-Verbindung, damit ich den Server über vnc von aussen erreichen kann, wurde in der Fritzbox eingerichtet.

Die ein oder andere Änderung werde ich noch wohl durchführen aber bei uns läuft das szenario superstabil: noch nie ein Problem mit dem Server, der übrigens von einer USB3-SSD gestartet wird
„Gaststättenbetrieb sucht für Restaurant und Biergarten Servierer:innen und außen.“
0
caMpi
caMpi08.11.1608:07
Wenn auf der Fritzbox User angelegt sind, werden für sie Adressen für VPN reserviert, egal ob das aktiv ist oder nicht. In der Regel hängen sich diese IP-Adressen direkt an die DHCP-Range an. Steht halt nirgendwo.
Sterbende Switche stellen Pakete nicht mehr richtig zu, es kommt zu Packet Loss oder allgemein hohen Laufzeiten.
Die 6490 (von KD) belegt seit einer aktuelleren Firmware neben ihrer primären IP (Standard 192.168.178.1) außerdem noch die letzte IP innerhalb ihres Subnetzes (Standard 192.168.178.254). Wenn der Server diese IP hat ist das auch schlecht. Schalte den Server doch mal aus, und starte einen Ping auf seine Adresse.
Das von mir angesprochene Problem lag damals übrigens am Wiki-Server. Dabei hing aber der Server nicht netzwerkseitig sondern machte einfach mal Pause, dann ging es weiter. Die Verbindungen zum Server issen dabei nie ab.
Die Frage ist: Stürzt der Server wirklich ab, oder ist er einfach nicht mehr erreichbar? Hast du die Möglichkeit einen Bildschirm dranzuhängen? Ansonsten würde ich einfach mal (vom Server aus) einen Dauerping z.B. auf die Fritzbox machen, und mir das Ergebnis in eine Textdatei wegschreiben lassen.
„Keep IT simple, keep IT safe.“
0
ricard17.11.1617:07
Hallo,
hier noch mal eine aktuelle Rückmeldung.
Soweit ich das jetzt beurteilen kann, war tatsächlich der Wiki-Server ausschlaggebend. Die Problematik hat sich hochgeschaukelt, als ein Kollege versucht hat, einen Ordner mit Bildern auf eine Dateifreigabe hochzuladen. Die Verbindung ist konsequent immer wieder abgestürzt.
Ich saß daneben und konnte sehen: Ping auf Server nicht möglich. 5 Minuten später, Server wieder erreichbar, neuer Versuch vom Kollegen, Server wieder unerreichbar usw.
Dann habe ich den Wiki-Server deaktiviert erst mal nichts gebracht dann neugestartet und seit dem läuft der Server durchgehend (über 1 Woche).
Schade, denn eigentlich hatte ich vor, den Wiki-Server zu verwenden. Und eigentlich muss es doch noch eine Ursache geben, denn caMpi hat das Problem ja auch gehabt…
Der DNS-Server läuft jetzt übrigens auch wieder. Und da ich auch den RADIUS-Server fürs WLAN verwenden will, und da wir Netzwerkaccounts und Dateifreigaben verwenden ist mir 24/7-Erreichbarkeit schon wichtig (eigentlich steht das außer Frage).
Beste Grüße und Vielen Dank an alle.
0
MacRudi17.11.1619:39
Und wenn Du dieses spezielle Hochladen den Mitarbeitern erklärst, dass sie es sein lassen?
0
ricard17.11.1619:49
Ich glaube, das Deaktivieren von Dateifreigaben ist nicht Sinn der Sache (also er hat jetzt "normal" einen Ordner hochgeladen)
Und der Server ist ja nicht nur dann ausgefallen, wenn man Bilder hochkopiert hat.
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.