NilsK

Moin, das sollte in den Eigenschaften des Wartungsplans bzw. des betreffenden Steps stehen. Gruß, Nils

Moin, dann gibt es netzwerkseitig mehrere Wege zwischen den beiden Hosts (logisch in einem Cluster), und der Server entscheidet sich eben für das Management-Netz. Die IP-Adresse, die du angibst, dürfte dabei nur die initiale Verbindung herstellen, Authentisierung und SMB-Traffic geht dann über das aus Sicht des Servers bestgeeignete Netz. Das ist einer der Gründe, warum Dateikopien als Leistungstest nur selten geeignet sind. In der Praxis wirst du ja selten große Datenmengen zwischen den Hosts kopieren. Für die Live Migration etwa kannst du die zu verwendenden Netze ja direkt angeben. Da im Normalfall über das Management-Netz so gut wie keine Daten fließen (höchstens mal bei Updates), könnte man sich auch überlegen, die Konfig zu vereinfachen: Die Gigabit-Karten gar nicht nutzen und deaktivieren, das Management-Netz auch per vNIC an den "ConvergedSwitch" anschließen. (Nebenbei ist der Name nicht treffend, denn den Storage-Verkehr leitest du ja gar nicht darüber - wirklich "converged" ist das nicht.) Gruß, Nils

Moin, dazu sagst du zu wenig darüber, wie der Datenbankzugriff denn funktioniert. Befindet sich davor eine Webanwendung? Ohne das Szenario genau zu kennen, kann man auf solche Fragen keine sinnvollen Antworten geben. Gruß, Nils

Jaja, die wissen mittlerweile auch, wo der Barthel den Most holt. Dass Microsoft sich über die überzogenen Lizenzpreise von Oracle mokiert hat, ist lange her ... Gruß, Nils

Moin, ja: Die Benutzerkontensteuerung ist nicht deaktiviert. :) Gruß, Nils

Moin, das spricht dafür, dass die CALs deutlich teurer geworden sind ... es lag mal um die 400. Aber das nur am Rande. ;) Gruß, Nils

Moin, das sollte man einfach mal durchrechnen. Ist ja nicht weiter schwer. Es würde mich aber wundern, wenn schon bei 40 Usern der Break-Even erreicht wäre. Gruß, Nils

Moin, verstehe ich nicht ganz. Ihr kriegt keine Direktverbindung hin, aber jeder Standort kommt noch ins Internet? Warum macht ihr dann kein "richtiges" VPN? Schon als Fallbacklösung wäre das doch auch für den Normalbetrieb interessant. Mit Teamviewer würde ich da jedenfalls nicht rumbasteln, das ist dafür weder gedacht noch geeignet. Gruß, Nils

Moin, bei SQL Server gibt es zwei Modelle: Die Prozessor-Lizenzierung und die Server/CAL-Lizenzierung. In deiner Umgebunsgröße wird üblicherweise die Server/CAL-Variante eingesetzt, weil die Prozessor-Lizenzierung (quasi ein Pauschalpreis, der dann keine CALs mehr erfordert) sehr teuer ist. Die rechnet sich daher nur bei sehr großen Anwenderzahlen. Vielleicht hat dein Anbieter da was verwechselt. Auch im Server/CAL-Modell wird bei SQL Server 2014 die Anzahl der Cores berücksichtigt, aber damit sind die CALs dann noch nicht abgedeckt. Lass die das lieber noch mal prüfen und es dir schriftlich versichern. Gruß, Nils

Moin, eine Offline-Replikation gibt es nicht. Das Hochsetzen der Tombstone Lifetime würde das Problem nicht lösen, dafür bei Replikationsproblemen während des Änderungsvorgangs aber u.U. gravierende Probleme hervorrufen. Auf keinen Fall solltest du diese Änderung ausführen, wenn keine zuverlässige Verbindung vorhanden ist. Es gibt drei realistische Möglichkeiten: Du sorgst für eine stabile Verbindung der beiden DCs, bevor die Replikationspause die Tombstone Lifetime erreicht (rechtzeitig vorher!) Du nimmst den DC am entfernten Standort außer Betrieb (vom Netz nehmen und deinstallieren) und entfernst ihn aus dem AD Du tust nichts und lässt die Replikate auseinander laufen. Wenn dann irgendwann die Verbindung wieder zuverlässig funktioniert, versuchst du das AD um die Lingering Objects zu bereinigen. Achtung, das wird sehr wahrscheinlich zu Datenverlusten führen - die Änderungen auf dem entfernten DC nach Abbruch der Replikation wirst du verlieren Variante 3 ist am wenigsten erstrebenswert. Gruß, Nils

Moin, da diese Aufgabe ausgesprochen komplex ist, wirst du nach meiner Kenntnis nur Enterprise-Tools dafür finden. (Andere Schreibweise: Enter-Preis) Gruß, Nils

Moin, das Konzept leuchtet mir nicht ein. Zunächst finde ich die beiden separaten Hosts und die Replica-Funktion nicht einleuchtend. Und dann finde ich die Netzwerkanbindung etwas seltsam geplant: Zweimal 10 Gbit für iSCSI und für alles andere nur je 1 Gb ohne Redundanz? Ihr wolt also eure Hosts mit jeweils 24 Gbit in Summe ausstatten und alle VMs durch eine einzige, nicht redundante Gigabit-Leitung zwängen? Ich schlage als Alternative zum Nachdenken mal vor, die beiden 10-GbE-Adapter zu einem Team zusammenzufassen, über das ihr mit einem vSwitch alles laufen lasst. Die vier Gigabit-Adapter würde ich schon fast brachliegen lassen. Natürlich kann man dies ohne nähere Analyse nicht planen - mir geht es hier um eine deutlich anders gebaute Alternative, damit ihr euer Konzept noch mal prüft. Gruß, Nils

Moin, in dem Konstrukt hättest du keinen direkten Vorteil, wenn du die Daten-LUN direkt bei iSCSI in die VM einbindest. Zwar entfällt dadurch die VHDX-Ebene, was theoretisch ein Vorteil sein könnte. Dafür entfällt aber auch die Kontrolle des Hypervisors über die VHDX-Datei und die dazu gehörigen Optimierungen. Vor allem aber - was ich als ausschlaggebend ansehe - hast du bei einer iSCSI-Anbindung direkt in der VM immer den Nachteil, dass deine VM aus zwei (bzw. zwei "plus x") unabhängigen Elementen besteht. Die iSCSI-LUN unterliegt ja eben nicht der Kontrolle des Hypervisors, die musst du daher immer separat managen. Das stellt sich in vielen Umgebungen immer wieder als Problem dar, wenn auch nur in bestimmten Situationen. Der Performance-Nachteil der VHDX-Lösung ist in dem Szenario zu vernachlässigen. Gruß

Moin, du kannst bzw. solltest durchaus im Server-Management die richtige Uhrzeit oder eben noch besser einen verlässlichen NTP-Server setzen. Sofern dein Server-Management die Zeit an den Server weitergibt, kann es nämlich zu sehr hässlichen Effekten kommen, wenn diese Zeit nicht korrekt ist. Ein normal korrigiertes WIndows wird nämlich nach dem Booten die Zeot korrigieren, und wenn die vom Board falsch war, dann gibt es eben teils erhebliche Zeitsprünge. Das mag das AD nicht, und viele andere Komponenten auch nicht. Abschalten solltest du die Zeitsynchronisation des Betriebssystem deshalb aber nicht. Es ist dringend zu empfehlen, den Zeitabgleich flächendeckend und ausschließlich über das AD zu machen. Die Hyper-V-Zeitintegration nicht nur für die DCs abschalten, sondern für alle (!) Domänenmitglieder, damit das AD als maßgebende Quelle feststeht. Die Überlagerung mehrerer Zeitdienste sollte man unbedingt vermeiden, nicht nur in Hyper-V, sondern auch in VMware usw. (bei VMware gibt es dazu auch mittlerweile Best-Practice-Artikel, nur leider kann man da immer noch die Zeitsynchronisation mit dem Host nicht vollständig abschalten). Gruß, Nils

Moin, das ist zeitintensiv, aber gemacht haben das schon Leute. Es gibt eine ganze Reihe dynamischer und erweiterbarer Verwaltungstools. Nur da es eben zeitintensiv ist, kosten die dann meistens Geld. Gruß, Nils

Moin, naja. Sich mit nicht unterstützten Methoden aus den einzelnen Komponenten einer Applikation eine andere zusammensetzen, mag mit viel Aufwand vielleicht zum Erfolg führen. Mit einer dokumentierten und unterstützen Erweiterbarkeit hat das aber wenig zu tun. Solange es z.B. keine fest definierten, von außen ansprechbaren APIs gibt, kann sich mit einem Update was an der Funktion ändern, und schon funktionieren die Aufsätze nicht mehr. Da dürfte es dann schon sinnvoller sein, den Aufwand in die eigene Entwicklung eines Werkzeugs zu stecken, das auf definierte APIs (z. B. die schon erwähnten Webservices) zugreift. Das hat dann aber eben mit ADAC nichts mehr zu tun. Leider ist das ADAC nicht nur an dieser Stelle sehr lieblos gemacht. Gruß, Nils

Moin, interessanter Hinweis, den kannte ich noch nicht. Danke! Aber: Erstens nimmt das nur Anzeigespalten auf, zur Bearbeitung der Werte taugt es nicht. Und zweitens geht es hier auch um ADUC, der TO wollte aber eine Lösung für ADAC. Und da geht sowas nach aktuellem Kenntnisstand nicht. Gruß, Nils

Moin, wenn sie nicht angezeigt werden, sind sie vielleicht gar nicht mehr eingebunden. Kannst du die Datei evtl. einfach löschen? Gruß, Nils

Moin, wir hatten so eine ähnliche Frage hier kürzlich. Das Ergebnis war (und mir ist auch nichts anderes bekannt), dass man das ADAC nicht anpassen kann. Vielleicht wäre die Arbeit mit ADUC und folgendem Ansatz eine Möglichkeit: [Kostenstelle in AD integrieren | faq-o-matic.net] http://www.faq-o-matic.net/2007/02/27/kostenstelle-in-ad-integrieren/ Gruß, Nils

Moin, grundsätzlich kann man VMs auch im laufenden Betrieb sichern. Dazu sollte das eingesetzte Sicherungsprogramm die VSS-Schnittstelle ansprechen, und die Applikationen in den VMs sollten das auch tun. Das geht auch mit Windows Server Backup, aber Altaro und Veeam können das besser. Ich würde sowas aber nicht blind bzw. pauschal machen, sondern immer auf den Einzelfall schauen. Gruß, Nils

Moin, bitte keine Akrobatik mit Images und Dateikopien. Das sind prima Möglichkeiten, einem problematischen AD endgültig den Garaus zu machen. AD-Backup ist so einfach: Systemstate sichern, mindestens auf einem DC per Windows Server Backup. Wenn ein zusätzliches AD-kompatibles (!) Backupprogramm vorhanden ist, dann ergänzend (!) damit. Und zur Wiederherstellung: [Video-Tutorial: Active Directory Object Recovery | faq-o-matic.net] http://www.faq-o-matic.net/2009/09/07/video-tutorial-active-directory-object-recovery/ Gruß, Nils

Moin, wie immer, kommt es auch hier darauf an. ;) Das CPU-Überbuchungsverhältnis 1:8 war nur eine Supportgrenze, keine technische Grenze. Wenn man das überschritten hat und hatte ein Problem mit Hyper-V, konnte es sein, dass einen der MS-Support im Lauf eines Supportcalls auffordert, VMs von dem betreffenden Host wegzumigrieren. Technisch kann es sehr gut sein, dass auch bei deutlich höherer Überbuchung alles rund läuft. Umgekehrt kann es aber durchaus auch vorkommen, dass bei deutlich geringerem Verhältnis einzelne VMs nicht so laufen, wie sie sollen. Das kann etwa bei Applikationen der Fall sein, die sehr wenig Latenz vertragen. Daher gilt etwa für Exchange auch weiterhin eine Supportgrenze von 1:2 für die Hosts, auf denen Exchange-VMs laufen. Für VoIP sehen die Empfehlungen auch so aus, dass man möglichst wenig überbucht. Man kann sich sein Problem auch selbst bauen: Viele Kunden weisen pauschal allen VMs 4 vCPUs zu, auch wenn die Applikationen das nicht brauchen. Das bedeutet aber, dass jede dieser VMs nur dann versorgt werden kann, wenn gerade vier Cores gleichzeitig frei sind. Hätte der Host in einem Zyklus nur zwei Cores frei, dann kommt die VM eben nicht dran und muss noch einen Zyklus warten (vereinfacht ausgedrückt). [Hyper-V-Sizing: Virtuelle und echte CPUs | faq-o-matic.net] http://www.faq-o-matic.net/2011/01/26/hyper-v-sizing-virtuelle-und-echte-cpus/ [Virtuelle CPUs in Hyper-V: Ein Überblick | faq-o-matic.net] http://www.faq-o-matic.net/2014/10/01/virtuelle-cpus-in-hyper-v-ein-berblick/ Was heißt denn "Probleme bei der Performance"? Gibt es Hinweise darauf, dass tatsächlich die CPUs das Problem sind? Gruß, Nils

Moin, die Verzeichnisdienstwiederherstellung macht auch nichts. Sie stellt den Verzeichnsdienst nicht wieder her. Es handelt sich um einen Betriebsmodus, in dem man manuell das AD reparieren kann. Wenn du tatsächlich noch einen funktionierenden DC hast, ist es wahrscheinlich die beste Variante, den kaputten DC abzuschreiben, aus dem AD zu entfernen und neu zu installieren. Gruß, Nils

Moin, dazu gibt es eine simple Antwort: Das kommt darauf an. :D Und zwar auf die Anforderungen. Generell gilt, dass es zwei typische Engpässe in Hostsystemen gibt: RAM und Disk-IO. Was man aber "braucht", kann ohne genaue Kenntnis des Einzelfalls nicht gesagt werden. Und das ist wieder eine Sache, für die ein Forum nun mal nicht geeignet ist. Dieser umfangreiche Blogpost spiegelt eine sehr pragmatische Grundhaltung zu solchen Fragen: [42 Best Practices for Balanced Hyper-V Systems] http://www.altaro.com/hyper-v/42-best-practices-balanced-hyper-v-systems/ Für die konkrete Frage nach der Blockgröße noch die Anmerkung: In den allermeisten Umgebungen spielt das keine Rolle. Gruß, Nils

Moin, die Lösung ist dann nicht Unsinn, wenn sie zu den Anforderungen passt. Unsinn ist es, eine "Lösung" vorzuschlagen, bevor die Anforderungen geklärt sind. Darüber hinaus finde ich, dass wir hier den Bereich verlassen, in dem ein Forum sinnvoll etwas beitragen kann. Ein Forum ist gut für technische Hilfestellung. Designfragen sind dort i.d.R. prinzipbedingt nicht gut zu diskutieren. Gruß, Nils