ESX / ESXi - Hilfethread

[LaMagra-X]

Das macht schon wieder stutzig. Das BIOS müsste UTC sein. Nimm doch einfach NTP.

Mit Zeit spaßt man nicht, da hängt so viel dran. Zertifikate sind noch das kleinste Übel. VPN-Tunnel, die sich irgendwann nicht mehr aufbauen, weil die Uhr driftet, sind dann schon für Fortgeschrittene. Korrekte Zeit ist der wichtigste Dienst, den jeder Host braucht, noch vor DNS (DNSSEC lässt grüßen).

Und was heißt das konkret? Am Domaincontroller einen NTP installieren?

EDIT:

Die Synchronisation habe ich nicht aktiviert (siehe Scrennshot)

 

[TCM]

Zuerst mal im ESXi den NTP-Client aktivieren, denn keine Hardware-Uhr läuft genau, wirklich keine. Dann Zeitsynchronisation in die VMs einschalten.

Es ist in Sachen Zeit auch drauf zu achten, ob der Schalter in den VM Optionen gesetzt ist, der die ESXi Zeit eiskalt auf die VM überträgt. In Zeitkritischen Anwendungen ist das tödlich
Weil die Zeit der VM anders läuft, als die des Hosts. Somit hat man alle Nase lang Zeitsprünge drin. Je nach Refreshzeit. -> Klare Empfehlung dies nicht zu tun.

Kann ich absolut nicht nachvollziehen. Ich habe die Option bei OpenBSD-VMs aktiviert. Der Gast kriegt damit ein sysctl, was alle 15s aktualisiert wird:

hw.sensors.vmt0.timedelta0=0.000000 secs, OK, Tue Feb 19 11:02:39.678

Damit kann ich in der VM einen ntpd laufenlassen, der nur auf diesen Sensor achtet (ohne Netzwerkzugriff) und damit die Uhr "smooth" hält, indem er wie normal auch den drift ausgleicht.

# cat /etc/ntpd.conf
# $OpenBSD: ntpd.conf,v 1.11 2009/05/18 16:13:48 stevesk Exp $
# sample ntpd configuration file, see ntpd.conf(5)

# Addresses to listen on (ntpd does not listen by default)
#listen on *

# sync to a single server
#server ntp

# use a random selection of NTP Pool Time Servers
# see http://support.ntp.org/bin/view/Servers/NTPPoolServers
#servers pool.ntp.org

# use a specific local timedelta sensor (radio clock, etc)
#sensor nmea0

# use all detected timedelta sensors
sensor *

 

[fdsonne]

@TCM
es kann dir passieren, das die Uhr in der VM selbst deutlich verkehrt läuft. Dieser Schalter prügelt dabei eiskalt die Hostzeit in die VM. Ohne wenn und aber. Das sinnlose ist aber, der Zeitgeber zeigt dir kein Offset an
Sicher, es sind nur ein paar ms Unterschied. Für unkritische Anwendungen ist das schmerzfrei. Zeitkritische Anwendungen, wo anhand von Laufzeiten agiert wird beispielsweise sind an der Stelle tödlich. Ich habe schon negative Laufzeiten gesehen usw.

Beispielsweise sind auch Windows VM als AD Member nicht primär so zu betreiben, weil das AD ne eigene Zeit distributiert. Die sich von der Hostzeit ggf. unterscheiden kann.

Als NTP selbst würde ich den Spaß so auch nicht laufen lassen, weil du nämlich die Gefahr läufst, das du vergleichsweise große Sprünge im jeweiligen Aktualisierungsintervall hast. Somit diese Sprünge ungünstigerweise auch ggf. im LAN breitgestreut werden.

Wir nutzen zum Beispiel hier ne externe Zeitquelle. Irgend so ne Station auf dem Dach, geht mit Funk. Und schiebt den Spaß ins LAN.
Die DCs holen die Zeit von dort, alle Clients und Memberserver von den DCs. Nebeinbei gibts noch nen quasi allgemeingültigen NTP. Der holt die Zeit auch von der externen Quelle. Alle *nix Büchsen sowie die ESXi Hosts holen den Spaß direkt vom allgemeinen NTP. Das ganze wird weltweit distributiert

 

[TCM]

@TCM
es kann dir passieren, das die Uhr in der VM selbst deutlich verkehrt läuft. Dieser Schalter prügelt dabei eiskalt die Hostzeit in die VM. Ohne wenn und aber. Das sinnlose ist aber, der Zeitgeber zeigt dir kein Offset an
Sicher, es sind nur ein paar ms Unterschied. Für unkritische Anwendungen ist das schmerzfrei. Zeitkritische Anwendungen, wo anhand von Laufzeiten agiert wird beispielsweise sind an der Stelle tödlich. Ich habe schon negative Laufzeiten gesehen usw.

Beispielsweise sind auch Windows VM als AD Member nicht primär so zu betreiben, weil das AD ne eigene Zeit distributiert. Die sich von der Hostzeit ggf. unterscheiden kann.

Als NTP selbst würde ich den Spaß so auch nicht laufen lassen, weil du nämlich die Gefahr läufst, das du vergleichsweise große Sprünge im jeweiligen Aktualisierungsintervall hast. Somit diese Sprünge ungünstigerweise auch ggf. im LAN breitgestreut werden.

Wir nutzen zum Beispiel hier ne externe Zeitquelle. Irgend so ne Station auf dem Dach, geht mit Funk. Und schiebt den Spaß ins LAN.
Die DCs holen die Zeit von dort, alle Clients und Memberserver von den DCs. Nebeinbei gibts noch nen quasi allgemeingültigen NTP. Der holt die Zeit auch von der externen Quelle. Alle *nix Büchsen sowie die ESXi Hosts holen den Spaß direkt vom allgemeinen NTP. Das ganze wird weltweit distributiert

Wie gesagt, das deckt sich absolut nicht mit meinen Erfahrungen.

Der Host läuft erstens auch mit NTP, d.h. der sollte schon eine ziemlich genaue und schwankungsfreie Zeit haben. Zweitens wird die Zeit nicht in die VM "geprügelt", sondern nur bereitgestellt, wo sie von einem ntpd erfasst wird, welcher wiederum die Gast-Zeit beschleunigt/verlangsamt, um am Ende eine synchrone Zeit zum Host zu haben.

Ich habe in den letzten 3 Monaten nicht eine Meldung im Log, dass auch nur die Uhrenfrequenz der VM angepasst wurde, geschweige denn Zeitsprünge stattfanden.

Auf meinem "echten" ntpd, der auf richtiger Hardware läuft, sieht das z.B. so aus:

Feb 17 09:45:52 svc ntpd[15475]: adjusting clock frequency by 0.075485 to 146.128989ppm
Feb 17 21:47:02 svc ntpd[15475]: adjusting clock frequency by 0.062562 to 146.191550ppm
Feb 18 16:08:08 svc ntpd[15475]: adjusting clock frequency by -0.088023 to 146.103527ppm

Beachte, dass es hier um die Frequenz geht, nicht um die Zeit. Das Minus heißt also nicht, dass die Zeit zurückging, sondern nur dass die Frequenz minimal nach unten angepasst wurde.

Und wie gesagt, in den VMs habe ich nach einiger Zeit keine solche Meldung mehr, d.h. die Uhr läuft dann absolut synchron zum ESXi.

Wir nutzen zum Beispiel hier ne externe Zeitquelle. Irgend so ne Station auf dem Dach, geht mit Funk. Und schiebt den Spaß ins LAN.
Die DCs holen die Zeit von dort, alle Clients und Memberserver von den DCs. Nebeinbei gibts noch nen quasi allgemeingültigen NTP. Der holt die Zeit auch von der externen Quelle. Alle *nix Büchsen sowie die ESXi Hosts holen den Spaß direkt vom allgemeinen NTP. Das ganze wird weltweit distributiert

Sind die DCs virtuell? Dann wäre es in der Tat grob fahrlässig, den ESXi und die VMs die Zeit von verschiedenen Quellen holen zu lassen und könnte zu den geschilderten Problemen führen.

 

[LaMagra-X]

Mal ne Frage zu Snapshots in einem Windows Server 2012 AD.

Ich habe jetzt einmal einen Snapshot eines DCs wiederhergestellt und prompt gab es Probleme. Ist es überhaupt möglich einen Domaincontroller innerhalb eines Forest aus mehreren DCs wiederherzustellen? Bzw. was muss man beachten?

 

[FLiNTx]

War da nicht was, dass MS sagt, DCs solle man garnicht virtualisieren - oder werf ich da was durcheinander?

 

[Steggi]

@ LaMagra-X: Snapshots und DC's sind eine SEHR SEHR SCHLECHTE Idee und entsprechend fährst du damit auch gegen die Wand

War da nicht was, dass MS sagt, DCs solle man garnicht virtualisieren - oder werf ich da was durcheinander?

Naja, es sollte schon immer ein Physikalischer DC mit dabei sein, damit dir das AD nicht komplett wegbricht, wenn dir der ESXi mal ausfällt. Ich hab hier auch einen DC als VM und einen auf nem physikalischem Server am laufen, damit es eben genau zu diesem Szenario nicht kommt.

@euch beide: Schaut euch einfach mal folgenden Blogeintrag an --> LDAP://Yusufs.Directory.Blog/ - Die NO-GOs und Empfehlungen zu virtuellen DCs

 

[Neo4096]

also meiner Meinung nach benötigt man keinen physikalischen DC. Im VCenter kann man doch auch Reglen festlegen, dass zum Beispiel die VMs DC1 und DC2 nie auf dem gleichen Host laufen dürfen. Und in VSphere ist die Zeitsynchronisierung mit dem Host glaube ich standardmäßig eh deaktiviert.

 

[LaMagra-X]

War da nicht was, dass MS sagt, DCs solle man garnicht virtualisieren - oder werf ich da was durcheinander?

Doch, darf man schon. Man muss eben nur ein paar Regeln beachten. Aber gut bewandert bin ich da auch nicht, deswegen frage ich.

@ LaMagra-X: Snapshots und DC's sind eine SEHR SEHR SCHLECHTE Idee und entsprechend fährst du damit auch gegen die Wand

Naja, es sollte schon immer ein Physikalischer DC mit dabei sein, damit dir das AD nicht komplett wegbricht, wenn dir der ESXi mal ausfällt. Ich hab hier auch einen DC als VM und einen auf nem physikalischem Server am laufen, damit es eben genau zu diesem Szenario nicht kommt.

@euch beide: Schaut euch einfach mal folgenden Blogeintrag an --> LDAP://Yusufs.Directory.Blog/ - Die NO-GOs und Empfehlungen zu virtuellen DCs

Ich habe 2 virtualisierte DCs. Laufen beide auf unterschiedlichen Hosts. Danke für den Link.

also meiner Meinung nach benötigt man keinen physikalischen DC. Im VCenter kann man doch auch Reglen festlegen, dass zum Beispiel die VMs DC1 und DC2 nie auf dem gleichen Host laufen dürfen. Und in VSphere ist die Zeitsynchronisierung mit dem Host glaube ich standardmäßig eh deaktiviert.

Ja, so handhabe ich es auch.


Grüße

 

[LichtiF]

Naja wir haben hier 4 ESXi und sogar 4 DCs davon ist einer aber immer noch eine Hardwarekiste einfach auch aus dem Grund das ohne DNS kein Internet mehr geht und wir dann einen Sturm auf die Hotline haben wenn wir mal geplant die ESXi und den Storage herunter fahren.

Die Beamten hätte ja dann nichts zu tun in der Zeit

 

[LaMagra-X]

Die Beamten hätte ja dann nichts zu tun in der Zeit

 

[fdsonne]

Ich habe in den letzten 3 Monaten nicht eine Meldung im Log, dass auch nur die Uhrenfrequenz der VM angepasst wurde, geschweige denn Zeitsprünge stattfanden.

Eventuell zeigt sich das gar nicht? Weil der Host ändert das ja irgendwie intern, nicht auf OS ebene...
Es ist halt auffällig, verschiedene VMs auf ein und der selben Hardware und alle Uhren laufen anders

Sind die DCs virtuell? Dann wäre es in der Tat grob fahrlässig, den ESXi und die VMs die Zeit von verschiedenen Quellen holen zu lassen und könnte zu den geschilderten Problemen führen.

Natürlich sind die DCs virtuell
Zumindest alle bis auf einen...
Aber ist ja auch egal. Vor allem haben die *nix Kisten nicht primär was mit dem AD Umfeld zu tun. Es geht viel eher darum, insich konsistente Zeiten zu bekommen und nicht auf ms Sekundengenau alle Systeme aktuell zu halten.
Und da kann es dir eben passieren, das diese Kette unterbrochen wird, wenn du einer VM das reindrückst, diese aber ggf. dazu noch NTP technisch ne Zeit woanders her holt (ala AD)

Naja wir haben hier 4 ESXi und sogar 4 DCs davon ist einer aber immer noch eine Hardwarekiste einfach auch aus dem Grund das ohne DNS kein Internet mehr geht und wir dann einen Sturm auf die Hotline haben wenn wir mal geplant die ESXi und den Storage herunter fahren.

Dafür gibts voll redundate Storage/Hostsysteme
Da kannst du schon den Spaß von A nach B umziehen ohne dediziert nen Unterbruch zu erzeugen.

 

[Hansman71]

Ich habe eine Optimierungsfrage:
Auf meinem N40l habe ich ESXi laufen.
1. VM = Astaro
2. VM = Freenas
Ich habe eine HDD für die Systeme.
Zwei physisch separate HDDs für den Storage.
Soweit läuft alles - aber uuuuuunheimlich lahm.

Konkret mit ca 1 MB/s, wenn ich z.B. Lieder von meinem PC auf das "Z-Laufwerk" kopiere.

Ich habe zwar aktuell nur einen 100er-Switch, aber soooo lahm sollte es wohl auch damit nicht sein.
Ich habe die 2 HDDs als ZFS als Mirror verknüpft, aber auch ohne RAID wären es ja dann nur 2 MB/s

Könnte es an der Art der Zuweisung der HDD für den Storage an die FreeNAS-VM liegen?
Muss ich diese durchreichen, damit ich Tempo bekomme?

Ich weiß ich habe mehrere Flaschenhälse drin, aber wo ist der engste?

 

[Steggi]

Naja wir haben hier 4 ESXi und sogar 4 DCs davon ist einer aber immer noch eine Hardwarekiste einfach auch aus dem Grund das ohne DNS kein Internet mehr geht und wir dann einen Sturm auf die Hotline haben wenn wir mal geplant die ESXi und den Storage herunter fahren.

Joa, so ein ähnliches Szenario kenne ich nur zu gut, wo es nur einen virtuellen DC gab und das Storage unter W2K8 das AD brauchte um den ESXi's den Zugriff auf die Shares zu geben. Der virtuelle DC lag sinniger Weise natürlich auch auf diesem Share, auf das der ESXi ohne AD nicht zugreifen konnte

@ Hansman71:

Kürzlich hatten schon einige User ein ähnliches Problem, dass die Schreibperformance des NXXl extremst lahm ist. Bei den Usern war der Writecache des Controllers deaktiviert. Prüf das doch bitte mal im Bios deines N40L's

 

[fdsonne]

wer das so betreibt, hats aber auch nicht verstanden Steggi...
Der DC ist ja sowieso voll "clusterfähig". Einfach ne weitere Kiste reinklemmen und gut ist. Ohne groß Spezialkonfig.

 

[TobiasAlt]

kurze Frage, denn ich bin momentan unschlüssig

Habe hier ein Storage mit 13*600GB
Welche Raid Aufteilung wäre empfehlenswert?

Var1: 2x Raid5 (2x 6*600) + 1x HotSpare = Netto 2x 2,79TB
Var2: 1x Raid5 (12*600) + 1x HotSpare = Netto 6,13TB
Var3: 1x Raid10 (12*600) + 1x HotSpare = Netto 3,34TB

 

[Hansman71]

Danke für den Hinweis!
Da ich sowieso noch das BIOS flashen wollte, habe ich jetzt noch einen Grund mehr, meinen Bildschirm in den Keller zu tragen

 

[TCM]

Eventuell zeigt sich das gar nicht? Weil der Host ändert das ja irgendwie intern, nicht auf OS ebene...
Es ist halt auffällig, verschiedene VMs auf ein und der selben Hardware und alle Uhren laufen anders

Es hat sich gezeigt, als ich die VMs neu aufgesetzt hatte. Da gabs dann eine Zeit lang die Meldungen, dass die Frequenz mal hoch, mal runter angepasst wird.

Und ich glaube nicht daran, dass der Host das in den Gast drückt. Der Host stellt ein Interface bereit, mit dem der Gast arbeiten kann. Nur weil vielleicht die VMware Tools unter Windows nichts weiter machen als periodisch die Zeit hart zu setzen, heißt das ja nicht, dass der Host das in den Gast reinforciert. Für OpenBSD gibt es keine VMware Tools, trotzdem kann es das Interface mit einer eigenen Implementierung (vmt(4)) nutzen. Das zeigt sich dann im vSphere Client als

VMware Tools: Running (3rd-party/Independent)

 

[LaMagra-X]

Ich habe eine Optimierungsfrage:
Auf meinem N40l habe ich ESXi laufen.
1. VM = Astaro
2. VM = Freenas
Ich habe eine HDD für die Systeme.
Zwei physisch separate HDDs für den Storage.
Soweit läuft alles - aber uuuuuunheimlich lahm.

Konkret mit ca 1 MB/s, wenn ich z.B. Lieder von meinem PC auf das "Z-Laufwerk" kopiere.

Ich habe zwar aktuell nur einen 100er-Switch, aber soooo lahm sollte es wohl auch damit nicht sein.
Ich habe die 2 HDDs als ZFS als Mirror verknüpft, aber auch ohne RAID wären es ja dann nur 2 MB/s

Könnte es an der Art der Zuweisung der HDD für den Storage an die FreeNAS-VM liegen?
Muss ich diese durchreichen, damit ich Tempo bekomme?

Ich weiß ich habe mehrere Flaschenhälse drin, aber wo ist der engste?

Also ich musste ja auch die Erfahrung machen, dass ein Storage-Controller ohne Cache unheimlich lahm ist...was hast du denn da genau im Einsatz?

 

[Hansman71]

Meines Wissens ist das ein On-Board Controller.

Ich hatte das mit dem "enable Write-Cache" auch mal in dem N40L - Thread gelesen, aber gedacht, dass das nur für die Speed-Junkys wäre...

 

[LichtiF]

Naja es gibt wohl generell Probleme mit Freenas und Fas4free unter ESXi was die Geschwindigkeit angeht wenn man die Hardware nicht direkt an die VM durchreichen kann.

 

[LaMagra-X]

Ganz und gar nicht.
Ich habe hier 2x Lenovo RD330 Server...zunächst hatten die einen SAS-Controller ohne Cache verbaut...das ganze lief dann mit 4x15K SAS Platten im RAID10 und es war quälend langsam.

Dann den SAS-Controller getauscht gegen einen mit Cache und siehe da, die VMs unter ESXi laufen blitzschnell. Ich hätte es auch nicht gedacht, dass die VMs so enorm vom Cache profitieren.

Ob das jetzt bei dir auch nur daran liegt kann ich nicht sagen.

 

[LichtiF]

Ich habe hier schon öfters gelesen das Leute mit Freenas oder Nas4free Probleme haben mit langsamen Geschwindigkeiten und mit zb OMV das doppelte haben bei gleicher Hardware.

Den link hatte jemand mal im N40L Sammelforum gepostet:

ESXi5 und FreeBSD schlechte performance - BSDForen.de


Wenn man schnellen Virtualisierten Storage will muss man wohl die Hardware durchreichen an die VM ist halt immer eine Frage was man daheim braucht.

 

[TobiasAlt]

mit FreeNas hatte ich auch Probleme, schaut euch mal "OpenFiler" an

 

[fdsonne]

Und ich glaube nicht daran, dass der Host das in den Gast drückt. Der Host stellt ein Interface bereit, mit dem der Gast arbeiten kann. Nur weil vielleicht die VMware Tools unter Windows nichts weiter machen als periodisch die Zeit hart zu setzen, heißt das ja nicht, dass der Host das in den Gast reinforciert. Für OpenBSD gibt es keine VMware Tools, trotzdem kann es das Interface mit einer eigenen Implementierung (vmt(4)) nutzen. Das zeigt sich dann im vSphere Client als

VMware Tools: Running (3rd-party/Independent)

Sind ja doch VMware Tools drauf. Nur eben nicht direkt von VMware. Woher die genau sind, ist ja egal. Tools sind Tools.
Ich meine, ganz ohne Tools (also wenn dort steht, Tools nicht ausgeführt, hast du auch keine Zeitsyncro. Bin ich mir aber nicht 100% sicher...

Und sicher drückt der Host das direkt in die VM. Wie sonst soll das laufen?
Es ist ja nur ein Stück Abstraktionsschicht. Die eine Hardware quasi vollständig emuliert. Das was der Taktgeber in Hardware ist, ist bei ner VM eben in Software. und diesen Spaß kann der Host halt direkt ändern, wenn die Settings gesetzt sind. Ob das die VM direkt mitbekommt!? Sprich ob das direkt in irgendwelchen Logs auftaucht, keine Ahnung. Denn wenn die VM nicht weis, das sich die Zeit geändert hat, kann sie auch nix protokollieren

 

[TCM]

Sind ja doch VMware Tools drauf. Nur eben nicht direkt von VMware. Woher die genau sind, ist ja egal. Tools sind Tools.
Ich meine, ganz ohne Tools (also wenn dort steht, Tools nicht ausgeführt, hast du auch keine Zeitsyncro. Bin ich mir aber nicht 100% sicher...

Und sicher drückt der Host das direkt in die VM. Wie sonst soll das laufen?
Es ist ja nur ein Stück Abstraktionsschicht. Die eine Hardware quasi vollständig emuliert. Das was der Taktgeber in Hardware ist, ist bei ner VM eben in Software. und diesen Spaß kann der Host halt direkt ändern, wenn die Settings gesetzt sind. Ob das die VM direkt mitbekommt!? Sprich ob das direkt in irgendwelchen Logs auftaucht, keine Ahnung. Denn wenn die VM nicht weis, das sich die Zeit geändert hat, kann sie auch nix protokollieren

Ich glaube, ich habe jetzt oft genug beschrieben, wie es augenscheinlich funktioniert, weil sich alle Logs und Beobachtungen damit decken. Warum kommst du immer wieder an und behauptest das Gegenteil?

Edit: Wenn man time sync per ESXi einschaltet, aber keine Tools installiert hat, driftet die Uhr trotzdem. Das wäre ein weiteres Indiz, dass da nix in die VM gedrückt wird, sondern die Mitarbeit der Tools nötig ist. Zwischen Host und Gast gibts also ein Interface, was die Tools nutzen müssen, um im Gast die Zeit einzustellen. Nur dass die BSD Tools nicht selbst die Zeit setzen, sondern dem ntpd im Gast einen Offset bereitstellen, nach dem dieser die Uhr beschleunigen/verlangsamen kann.

Ich weiß nicht, wie ich es noch verständlicher machen soll.

 

[Hansman71]

Ich werde jetzt mit meiner FreeNAS-Installation erst einmal den Cache aktivieren.
Außerdem macht das Durchreichen bei mir auch Sinn, da die beiden HDDs ausschließlich für diese VM vorgesehen sind.
Wenn's dann immernoch zu lahm ist, suche ich mir ein neues NAS-Programm.

Danke für die Hinweise!

 

[fdsonne]

Ich glaube, ich habe jetzt oft genug beschrieben, wie es augenscheinlich funktioniert, weil sich alle Logs und Beobachtungen damit decken. Warum kommst du immer wieder an und behauptest das Gegenteil?

Edit: Wenn man time sync per ESXi einschaltet, aber keine Tools installiert hat, driftet die Uhr trotzdem. Das wäre ein weiteres Indiz, dass da nix in die VM gedrückt wird, sondern die Mitarbeit der Tools nötig ist. Zwischen Host und Gast gibts also ein Interface, was die Tools nutzen müssen, um im Gast die Zeit einzustellen. Nur dass die BSD Tools nicht selbst die Zeit setzen, sondern dem ntpd im Gast einen Offset bereitstellen, nach dem dieser die Uhr beschleunigen/verlangsamen kann.

Ich weiß nicht, wie ich es noch verständlicher machen soll.

Ja und?
Das ändert doch am gesagten nix...
Ich sagte, das die Uhr prinzipiell nahezu immer falsch geht. Vor allem in der VM.
Und das ich den Sync via VM Settings in gewissen Situationen für todlich halte, weil der Zeitdrift ggf. so riesig ist, das es zu einem riesigen Zeitsprung kommt. Das ist potentiell problematisch. Nicht mehr und nicht weniger.
Wie und was und wo genau da gemacht wird, ist doch vollkommen irrelevant dabei.

 

[therealJMC]

@TCM @fdsonne

In gewisser Weise habt ihr beide Recht. In Windows/Linux(zumindest bei meinen Ubuntus) wird im zusammenspiel mit den Tools die Zeit hart gebügelt - mit allen daraus resultierenden Problemen u.U.

Wenn aber das aktivieren des Zeitsync auf BSD z.B. lediglich eine Zeitquelle zur Verfügung stellt die die Zeit nicht setzt sondern dem ntp zur Verfügung stellt ist das ja ne recht vernünftige Methode.

Somit ist das aktivieren des Sync aber nicht pauschal schlecht - es kommt auf das System an das darunter arbeitet...

 

[Eye-Q]

kurze Frage, denn ich bin momentan unschlüssig

Habe hier ein Storage mit 13*600GB
Welche Raid Aufteilung wäre empfehlenswert?

Var1: 2x Raid5 (2x 6*600) + 1x HotSpare = Netto 2x 2,79TB
Var2: 1x Raid5 (12*600) + 1x HotSpare = Netto 6,13TB
Var3: 1x Raid10 (12*600) + 1x HotSpare = Netto 3,34TB

Ohne konkrete Anforderungen kann so eine Frage unmöglich beantwortet werden.

Wie viele VMs sollen drauf laufen? Was für Dienste (Exchange/Datenbanken/Terminalserver/wasauchimmer) sollen darauf laufen? Je nachdem gibt es unterschiedliche optimale Aufteilungen.

Außerdem wäre es gut zu wissen, ob ein RAID 10 überhaupt ausgenutzt werden könnte oder ob das Teil per 1 Gbit/s iSCSI o.ä. angebunden ist.