NilsK

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

Moin, machen wir es kurz: Dein Migrationskonzept wird ziemlich sicher nicht funktionieren. Das ist auch nichts, was man mal so eben im Forum macht. Hol dir jemanden ins Haus, der weiß, wie das geht. Gruß, Nils

Moin, Autodiscover ... Wobei du den Rest der Umgebung schon auch richtig konfigurieren solltest. Habt ihr denn schon ein Migrationskonzept? Wird es für den Übergang ein Hybrid-Setup geben? Gruß, Nils

Moin, ja, nennt sich Autodiscover. Sprich mit eurem Hosted-Exchange-Anbieter, der wird dir sagen, was du ändern musst - das wird sehr wahrscheinlich nur DNS sein. Gruß, Nils

Moin, ein DC ist ja nunmal auch kein Webserver ... wenn du einem Webserver, der "horst@hurz.de" heißt, ein Zertifikat für den Namen "www.tolleseite.de" gibst, dann ist das Zertifikat in dem Moment für Clients gültig, in dem sie eine Verbindung zu dem Namen "www.tolleseite.de" herstellen und diese auf den Webserver auflöst. Ein AD-Client will aber seinen DC sprechen und weiß, wie der heißt. Wenn der nun mal "DC01.firmenname.local" lautet, dann wird der Client ein Zertifikat auf den Namen "*.firmenname.de" nicht akzeptieren. Der DC im Übrigen auch nicht, er wird es dem Client gar nicht erst präsentieren, weil der Name ja nicht stimmt. Und nein, du willst deinen DC nicht zum Internet öffnen. Bezüglich des Seafile willst du dir dann lieber ansehen, ob die mittlerweile ihre SAML-Implementierung fertig haben, dann holst du dir jemanden ins Haus, der euch das per ADFS anbindet. Gruß, Nils

Moin, ich verstehe die Frage nicht ganz. Was für Einstellungen willst du warum verteilen? Hosted Exchange arbeitet doch normalerweise mit Autodiscover. Gruß, Nils