NilsK

Moin, die Aussagen sind richtig. Ein Host ist ein Host und nur ein Host. Niemals etwas dazu laufen lassen, schon gar keinen DC. Wenn der Host nur als Host läuft, darf man mit einer Standard-Lizenz zwei Windows-Server-VMs darauf betreiben. Wenn der Host nicht nur Host wäre, sondern noch für etwas anderes genutzt würde, dann dürfte man nur noch eine VM darauf betreiben. Das ist aber uninteressant, weil man das nicht tut. Dukels Hinweis beschreibt gut, wie du das machen solltest. Aufwand etwa eine halbe Stunde. [Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte | faq-o-matic.net] http://www.faq-o-matic.net/2010/05/03/warum-der-hyper-v-host-keine-weiteren-dienste-ausfhren-sollte/ Gruß, Nils

Moin, ich muss mich auch korrigieren. Offenbar kann man einen vSphere-/ESXi-Server tatsächlich ins AD aufnehmen. https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2075361 Gruß, Nils

Moin, wie soll er denn? Manuell eintragen. Von selbst tragen sich (fast) nur Windows-Clients ein, die der Domäne angehören. Alle anderen Einträge nimmt man manuell vor. Veraltete Einträge manuell zu löschen, ist auch völlig normal. DNS aktualisiert sich nicht von selbst - abgesehen von neuen Einträgen für Windows-Domänenclients. Die automatische Bereinigung, die Sunny61 vorschlägt, ist prinzipiell eine gute Sache, hat aber ihre Ecken und Kanten. So wirkt sie nur bei dynamischen Einträgen, nicht aber bei statischen. Außerdem kann sie durchaus zu Problemen führen, weil sich Server manchmal dynamisch eintragen, ihre Daten danach aber nicht wieder aktualisieren. Wenn dann die Bereinigung zuschlägt, ist der Eintrag des Servers weg. Das habe ich auch schon bei Domänencontroller-Einträgen gesehen, obwohl es da nicht vorkommen sollte. Bei automatischen Bereinigungen also immer genau beobachten, was passiert! (Und: Nur auf einem DNS-Server pro Domäne aktivieren, nicht auf mehreren.) Gruß, Nils

Moin, mit einer Web-Recherche wirst du sicher Software finden, die dir diese Funktion ermöglicht. Eine denkbare Alternative wären USB-Device-Server, mit denen du einen einfachen USB-Scanner über das Netzwerk von verschiedenen Clients erreichbar machen kannst. Dabei läuft auf dem Client eine spezielle Software, die über das LAN eine USB-Verbindung herstellt. Produkte von Silex oder SEH werden da oft genommen. Gruß, Nils

Moin, huiuiui - nehmt es mir nicht übel, aber jetzt bekommt es doch einen esoterischen Touch. Der TO ist offenbar mit Architektur und Einrichtung der Storage-Anbindung sowie des Netzwerkdesigns stark überfordert. Jetzt noch mit Befindlichkeiten in Bezug auf Verschlüsselung zu kommen, wenn in dem Thread offenbar geworden ist, dass die bisherigen Entscheidungen überhaupt nicht auf geschäftlichen Anforderungen beruhen, ist dann doch etwas weit hergeholt. Ebenso weit hergeholt ist es, eine grundsätzliche Überlegenheit von SMB 3.x gegenüber iSCSI oder FC in Bezug auf Sicherheit konstruieren zu wollen. Gruß, Nils

Moin, OK, danke für die Rückmeldung! Gruß, Nils

Moin, OK, das ist mit großer Sicherheit dein Problem. Auf einem Host installiert man nichts. Insbesondere keinen SQL Server. Und schon gar nicht zwei. Und auch keine Treiber für ISDN-Hardware. Vereinfacht gesagt: SQL Server nimmt sich RAM, der dem Host dann nicht zur Verfügung steht. Und der Taskmanager ist kein geeignetes Tool, um bei einem Hypervisor die Ressourcen zu überwachen - er sieht nicht genug. [Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte | faq-o-matic.net] http://www.faq-o-matic.net/2010/05/03/warum-der-hyper-v-host-keine-weiteren-dienste-ausfhren-sollte/ Deine vCPU-Zuweisung ist auch nicht gut. Wozu sollen deine VMs so viel Prozessorleistung brauchen? Wie du 10 vCPUs auf sechs Cores unterbringst, ist mir auch gerade nicht ganz klar. Ist Hyper-Threading aktiv? Dann ginge das, aber es ist ganz, ganz weit weg von Best Practice. Niemals mehr vCPUs zuweisen als der Host Cores hat. Ich bezweifle energisch, dass irgendeine deiner VMs mehr als 4 vCPUs braucht. Setz das als Maximum und gehe von 1-2 vCPUs als Standard aus. Gruß, Nils

Moin, ich würde auch mal schauen, ob das RAM physisch in Ordnung ist. Ist NUMA Spanning aktiv? Läuft sonst auf dem Host noch was? Applikationen, Virenscanner, Agenten ...? Abgesehen davon, ist die Konfiguration der VMs beim Speicher etwas exotisch. Bei statischem RAM hat die RAM-Priorität keine Auswirkung, die ist nur für dynamischen Speicher gedacht und auch da nur sinnvoll, wenn der Host regelmäßig weniger Arbeitsspeicher hat als die VMs wollen. Die eine VM, die mit Dynamic Memory läuft, könnte ja auch statisch 8 GB bekommen. Und nebenbei: Ist das ein produktiver Server? Sind die Client-Betriebssysteme korrekt lizenziert? Gruß, Nils

Moin, ja, die Idee wäre das Update der Integrationsdienste ... wie in dem Artikel beschrieben. Basale Fehler kannst du ausschließen, z.B. vNIC nicht an den vSwitch gebunden? Gruß, Nils

Moin, entschuldige die klaren Worte, aber ich halte dein Design für Unsinn. Keine Redundanz, Abhängigkeit von einer IP-Adresse ... nee. Gruß, Nils

Moin, nur vergleichshalber: Welche Nummer steht bei dir am Ende, wenn du die Version mit "winver" nachsiehst? Die ist zur Identifikation relevanter. Gruß, Nils

Moin, interessant, wie manche Leute beraten ... wenn HV nicht relevant ist, warum verkauft man dann eines der komplexesten Cluster-Konstrukte, die es derzeit gibt? :confused: Sagen wir mal so: Würde ich sonst fragen? ;) Ein Cluster hat immer ein Quorum-Modell, bei dir eben File Share Witness. Um nun genau diesen Witness zu entfernen, musst du das Modell ändern. Beispielsweise auf "kein Quorum", dann Witness raus, Modell wieder ändern, neuen Witness rein. Ansonsten ist das aber eine Umgebung, die ich für unverantwortbar halte, daher verabschiede ich mich hier. Gruß, Nils

Moin, selbst wenn ich auf dem Gebiet aktiv wäre, wären mir deine Anforderungen dann doch etwas zu schwammig, um eine Empfehlung auszusprechen ... ;) Gruß,Nils

Moin, ich gehe davon aus, dass man das nicht ohne Neuinstallation hinbekommt. Konkrete Erfahrung kann ich dabei aber nicht vorweisen. Gruß, Nils

Moin, eben. Daher finde ich das, was du direkt darüber geschrieben hast, schon sehr mutig. :D Aus vielen Jahren Erfahrung kann ich sagen, dass man Domänen fast immer repariert bekommt. Von daher stimme ich Doso zu, der mir zugestimmt hat. ;) Gruß, Nils

Moin, ich würde sogar noch weiter gehen: Wenn der Seafile-Server von einem Dienstleister verwaltet wird, dann ist eine AD-Anbindung ein No-go. Sonst hat der Dienstleister Zugriff auf die AD-Anmeldung. Das ist ein nicht vertrauenswürdiges System. Gruß, Nils

Moin, ziehen wir die Frage doch mal andersrum auf: Das Storage kann ja mit Sicherheit auch iSCSI. Wie wäre es, darauf umzusteigen? Gruß, Nils

Moin, ich kann zu dem konkreten Fehler leider nichts beitragen, möchte aber trotzdem grundsätzliche Zweifel an dem Design anmelden. Auch wenn man Windows-Cluster mittlerweile sehr einfach einrichten kann, sollte ein Cluster nicht einfach sein. Dein Setup unterschreitet die Empfehlung von drei Nodes für S2D als Minimum. Ja, Zwei-Node-Cluster sind zugelassen, aber die Empfehlung sieht aus gutem Grund mehr vor. Zudem ist ein SOHO-NAS wirklich nicht als Clusterkomponente geeignet, auch nicht, wenn es "nur" den Zeugen darstellen soll. Von einem Cluster erwartet man hohe Zuverlässigkeit. Das muss sich in der gesamten Umgebung widerspiegeln. Spart man an der falschen Stelle (und Sparen ist bei einem Cluster fast immer an der falschen Stelle), dann ist das Konstrukt nicht mehr zuverlässig. Wenn das Budget Sparsamkeit erfordert - was völlig OK ist -, dann richten sich die Möglichkeiten nach dem Budget. Man wird dann aber eben nicht denselben Grad an Verfügbarkeit erreichen. EDIT: Ein Einfall noch zum Entfernen des Witness: Hast du vorher das Quorum-Modell umgestellt? Gruß, Nils

Moin, ich versteh deine Darstellung nicht ganz, aber mir scheint da noch ein grundlegendes Missverständnis der Netzwerke in Hyper-V vorzuliegen. Das Grundsetup würde ich so machen: Je Host beide NICs zu einem Team zusammenbinden. Die Netzwerkkabel kommen an "tagged" Ports. Die VLAN-Zuweisung geschieht über Hyper-V, nicht über den Switch. An dieses Team wird der vSwitch gebunden. Für jedes Host-Netzwerk wird eine vNIC erzeugt, das muss per PowerShell geschehen. Diese vNICs bekommen ihr VLAN-Tag und die Bandbreitenreservierung. Die IP-Adressen für die Host-Netzwerke werden in die zugehörigen vNICs eingetragen. Die VMs bekommen ganz normal ihre vNICs, je nach Bedarf mit VLAN-Tag oder ohne. Wenn die VMs dann ihr Storage über einen UNC-Pfad finden, muss der Servername dort auf die IP-Adresse auflösen, die der Host eben nur über seine Storage-vNIC erreicht. Die IP-Segmente müssen also so eindeutig sein, dass der Host nicht auf die Idee kommt, den Traffic in eins seiner anderen Netzwerke zu routen. Gruß, Nils

Moin, das ist letztlich eine Frage von Design und Operating ... du hast schon Recht, dass bei Ausfall des "Hauptswitches" die Funktionen des Clusters (= die VMs) ohnehin nicht zur Verfügung stehen. Dann nützt der separate Heartbeat nichts und kann sich u.U. sogar negativ auswirken (einzige Netzwerkverbindung wäre der Heartbeat, alles andere ist tot - das kann einen Cluster durchaus zusätzlich verwirren). Schon weil die VMs in dem Fall ihr Storage verlieren, wird man vor einem geplanten Ausfall des Switches (Firmware-Updates z.B.) alle VMs herunterfahren wollen. Das ist dann eine Operating-Frage. Was den Cluster-Heartbeat selbst angeht: Den kann man ohne weiteren Hardware-Aufwand redundant machen, weil man dafür mehrere Netzwerke zuweisen kann. So könnte man den SPOF umgehen, den der separate Switch darstellen würde. (Wenn man den denn haben will.) Gruß, Nils

Moin, nochmal: Ein DC ist kein Webserver. Und LDAPS ist nicht https. Ein Webserver soll oft unter verschiedenen Namen erreichbar sein. Das dafür nötige Zertifikatshandling ist Teil der Webserver-Software. Da kommen dann auch noch Techniken wie Host Headers, SNI usw. ins Spiel. Wenn du dich auf der Ebene auskennst, wirst du davon ja schon gehört haben. Ein DC soll gerade nicht unter verschiedenen Namen erreichbar sein. Es geht hier um die zentrale Security-Komponente eines Netzwerks. Aus genau dem Grund schreibt Microsoft (wie auch der Kerberos-Standard) ein Zertifikat mit exaktem Hostnamen vor. Und ganz sicher willst du deinen DC nicht zum Internet öffnen. Das ist ein No-go. Wenn Seafile keine andere Authentisierung für SSO ermöglicht, dann muss man dem Szenario eben auf SSO verzichten. Gruß, Nils

Moin, äh ... mir scheinen da doch ein paar Missverständnisse vorzuliegen. Wenn die ersten beiden Netzwerke, die du nennst, beide im Server-VLAN arbeiten sollen - warum siehst du dann getrennte VLANs und getrennte IP-Segmente vor? Storage wird den höchsten Traffic überhaupt erzeugen. Natürlich wirst du mit 1 GbE dort nicht glücklich werden. Da würde ich von einem 2x10-GbE-Team durchaus eine Reservierung von 50 Prozent sehen. Wenn dein Storage-Netz exklusiv ist, reicht es doch völlig aus, dass das Storage über ein eigenes IP-Segment angesprochen wird. Dann kann dort kein anderer Traffic laufen. Du willst in dem Netz kein Routing usw. haben, also richtest du auch keins ein. Wenn das der Grund ist, ist das okay und sinnvoll. Angesichts der anderen Missverständnisse wollte ich aber mal nachhaken. ;) Gruß, Nils

Moin, ich schließe mich Norbert an - meist ist eine Reparatur besser als ein Neuaufbau, weil an Letzterem i.d.R. doch wesentlich mehr Aufwand hängt, als viele denken: Benutzerprofile Berechtigungen Applikationen, insbesondere die komplexeren wie Exchange oder SharePoint Es kann außerdem durchaus sein, dass die Probleme, die die Kommunikation mit einem neuen DC verhindern, auch die Migration behindern würden, sodass du das u.U, sowieso fixen müsstest. Das Umbenennen einer Domäne sollte man sich auch gut überlegen. Welchen Konflikt gibt es denn da mit dem Domänennamen? Gruß, Nils

Moin, wie ist denn das Netzwerk aufgebaut? Gigabit? 10 GbE? Wie sind die Hosts angebunden - tatsächlich nur mit 2x1 GbE? Zu "Best Practices" würde gehören: 10 GbE mindestens einfach redundant Converged Networking auf Host-Ebene, d.h. ein Team über alle NICs, Trennung des Verkehrs über VLANs, vNICs und Bandbreitenregeln exakte Zuweisung des Traffics "Verwaltung des Hosts" bedeutet: Kontakt zum AD und WSUS, normalerweise ist das das "normale" LAN. "für den vSwitch" gibt es kein VLAN und kein IP-Segment - das ist ein Layer-2-Switch. Vermutlich ist hier das Segment für die VMs gemeint - was typischerweise auch das "normale" LAN ist. Live MIgration - OK, kann man separat machen, aber hier braucht man in kleinen und mittleren Umgebungen keine Höchstleistung - die sollen ja die VMs haben. Wie oft verschiebt man denn VMs? ... eben Storage: Hier wird es interessant. Eigenes VLAN und eigenes IP-Segment ist schon korrekt. Wenn in genau dem VLAN und dem IP-Segment auch das Storage hängt, dann solte das eigentlich schon passen. "Cluster Heartbeat" - warum ein eigener Switch? Dass aktuelle Storage-Systeme SMB 3.x nominell unterstützen, ist schon klar. Interessant wird SMB 3.x aber eigentlich erst mit den Funktionen, die der Windows-SoFS bereitstellt, und das kann m.W. kein Storage-Anbieter so wie Windows selbst. Gruß, Nils

Moin, was wird das hier? Wir haben dir gesagt, was die Voraussetzungen sind. Wir haben dir gesagt, wie du die auf einfache Weise erfüllen kannst. Wenn du weiter basteln willst, nur zu. Ich bin dann hier aber raus. Gruß, Nils