NilsK

Moin,

na, dann ist das aber eine ganz andere Aufgabe. Und ob da das AD wirklich die richtige Stelle ist ...

In dem Fall ist ja mindestens eine weitere Komponente beteiligt, die in den meisten Fällen wohl selbst für den größten Teil der Verzögerung verantwortlich sein dürfte. Und genau dort (z.B. an dem Webinterface zum Login) müsste man IMHO ansetzen, nicht beim AD. Wobei, wenn ich mir das noch mal erlauben darf, in dem Szenario die Praxisrelevanz des Findings noch geringer sein dürfte. Bei dem, was im Netzwerk real zwischen Angreifer und AD ist, dürften die Messergebnisse kaum etwas aussagen.

Zu dem technischen Anteil der Frage kann ich sonst aber hier nix beitragen. Spontan fiele mir MFA ein, weil da so viel Verzögerung dazu kommt, dass der Unterschied mit Sicherheit nicht mehr feststellbar ist.

Gruß, Nils

Moin,

ich sage ja gar nicht, dass das nicht relevant sein kann. Die Frage, die am Ende nur der TO bzw. seine Firma beantworten kann, bleibt aber trotzdem: Ist das im konkreten Gesamtzusammenhang relevant? Viele Firmen, deren Netzwerke ich kenne, müssten das realistisch mit "nein" beantworten, weil es auf der Liste relevanter Dinge nicht vor Position 100 auftaucht.

Und wenn das Thema weiter vorne steht - dann wäre zu prüfen, ob man das überhaupt selbst im Griff hat oder ob Microsoft das tun muss. Ich würde da im Zweifel ganz stumpf die Pentester fragen, ob ihnen ein Weg bekannt ist, wenn sie das schon testen.

Gruß, Nils

Moin,

darüber hinaus wäre die Frage zu stellen, wie relevant das "Finding" überhaupt ist. Pentester schreiben gern mal was auf, wenn sie es gefunden haben, aber das heißt noch lange nicht, dass das in der jeweiligen Situation ein Risiko wäre. Wer kommt denn überhaupt so nah an das AD ran, dass er diese Messung zuverlässig durchführen könnte? Und wenn er so nah dran ist, wie wahrscheinlich ist es, dass er diesen Weg überhaupt gehen muss?

Mir wäre nicht bekannt, dass man das steuern kann. Das heißt nicht, dass es nicht geht. Aber für mich klingt das nach etwas, was der Hersteller lösen müsste und nicht das Anwenderunternehmen.

Gruß, Nils

Moin,

Okay, aber ich bleibe trotzdem in einer Sache hartnäckig: gerade wenn es für eine Facharbeit ist, sollte dort Erwähnung finden, dass man das Storage-Netz vom "normalen" Netz trennt. Besonders, wenn es um Verfügbarkeit geht.

Gruß, Nils

Moin,

Dann solltest du aber dringend das Netzwerk passend einrichten.

Danke für die Rückmeldung zu dem Fehler.

Gruß, Nils

Moin,

Nun, diese Frage haben wir ja nun schon ausführlich diskutiert und beantwortet. Aus unserer Sicht brauchst du SR-IOV nicht und kannst die fehlerhafte Situation einfach ignorieren. 

Gibt es denn andere Fehler, die dich bei irgendwas behindern? Dann sollten wir über die sprechen. Fehler, die sich nicht auswirken, können wir hier nicht sinnvoll behandeln.

Im Englischen gibt es den Spruch: If it ain't broke don't fix it. Wenn nichts kaputt ist, dann reparier auch nicht.

Es kommt immer mal vor, dass ein Treiberpaket an einer Stelle Fehler hat, aber die grundsätzliche Funktion ohne Störung ist. Da ist dann auch nicht zu befürchten, dass es irgendwie schlimmer wird, denn ein Programmierfehler ist ja keine Krebserkrankung.

Gruß, Nils

Moin,

Dann jetzt bitte noch mal in Ruhe. Was ist das Problem, das du zu lösen versuchst?

Die SR-IOV-Vermutung ist doch gar nicht das eigentliche Problem, sondern geht darauf zurück, dass du ein anderes Problem vermutest, oder? Dann sollten wir uns auf dieses konzentrieren, sonst wird es immer wieder "abdriften".

Gruß, Nils

Moin,

dann solltest du aber das Netz-Design ändern. iSCSI (allgemein Storage-Traffic) muss vom normalen Netz getrennt sein. Mindestens per VLAN, eigentlich aber sogar über separate Switches.

Gut möglich, dass da auch das Problem liegt. Ein normales Netzwerk hat Gateways eingetragen, DNS usw., das hat in einem Storage-Netz alles nichts zu suchen. Nicht nur aus Prinzip, sondern weil es dort Fehler verursacht. Nicht umsonst hat man das früher SAN genannt, weil es eben ein völlig separates Netzwerk mit eigenen Anforderungen ist.

Gruß, Nils

Moin,

Handelt es sich um ein separates Storage-Netzwerk? Funktioniert dort überhaupt die Namensauflösung? Es ist lange her, dass ich was mit iSCSI zu tun hatte, aber ich meine, dass an der Stelle mit IP-Adressen gearbeitet wurde und nicht mit Namen.

Gruß, Nils

Moin,

Deinem Benutzernamen nach kannst du Deutsch. Da dies ein deutschsprachiges Forum ist, können wir vielleicht einfacher bei dieser Sprache bleiben.

Funktioniert die Verbindung, wenn du eine der anderen beiden Optionen versuchst?

Gruß, Nils

Moin,

zur technischen Problemlösung kann ich leider nichts beitragen. Meine Empfehlung wäre, die Replikation loszuwerden und nur mit einer einzigen Datenbank zu arbeiten. Gerade die Merge-Replikation ist ein hochkomplexes Konstrukt, das schon vom Prinzip her fehleranfällig ist. Wir sprechen hier über technische Ansätze der Neunziger - zu der Zeit war es oft noch undenkbar, von mehreren Standorten aus auf einer zentralen Datenbank zu arbeiten.

Die Entwicklungs-Datenbank könnte man dann über andere Wege herstellen, z.B. Backup/Restore. Ob das in eurem Szenario machbar wäre, weiß ich natürlich nicht. Ich würde aber in diese Richtung überlegen.

Gruß, Nils

Moin,

okay. Dann stelle ich hier aber noch mal dieselbe Frage: Welche Anforderung willst du mit der Replikation lösen? Unter anderem wegen solcher Probleme versucht man eigentlich, Replikationstechniken zu vermeiden.

Gruß, Nils

Moin,

ist dies ein anderes Problem als das im anderen Thread? Oder hängen diese zusammen?

Gruß, Nils

Moin,

kannst du das Problem bitte noch mal genauer beschreiben? So versteht man es nicht.

Welche Anforderung möchtest du mit der Replikation lösen? Allgemein ist das eine Technik, die man seit langer Zeit eher zu vermeiden versucht.

Gruß, Nils

Moin,

Du bekommst deine Fragen ja auch beantwortet, oder? Und es gibt noch den extra Service dazu, dass wir dir auch eine Einschätzung der Sinnhaftigkeit geben.

Gruß, Nils

Moin,

vor 16 Minuten schrieb firefox_i:

Nicht jeder administriert Rechenzentren mit Terabyteweise RAM und Quad-CPU Boards.

eben. Das ist ja auch völlig okay. Dann brauchst du dich aber auch nicht um Spezialthemen zu sorgen, die nur in solchen Umgebungen relevant sind. Das ist der Punkt.

Gruß, Nils

Moin,

puh ... also, um es mal bildlich zu sagen: Du bist dabei, einen VW Polo in Betrieb zu nehmen. Du machst dir aber Gedanken um Dinge, die EVENTUELL bei einem Ferrari relevant sein könnten.

Bitte nenn das Thema nicht "CPU Virtualisierung". So nennt man das nicht. Aktuell scheint man es SMT zu nennen, vor einiger Zeit nannte man es Hyper-Threading. Das sind Funktionen, die die physischen CPUs haben und die man in der Virtualisierung nutzen kann. Das hat aber nichts mit "CPU-Virtualisierung" zu tun.

Ich habe die Entwicklung an der Stelle eine Weile nicht verfolgt, aber meiner Einschätzung hat sich das Thema "im echten Leben" auch seit Jahren nicht verändert. Die kurze Antwort an der Stelle wäre aus meiner Sicht also weiterhin: Wahrscheinlich ist es Geschmackssache. Wenn du willst, probier es aus, aber sehr wahrscheinlich wirst du keinen Unterschied feststellen. Vor allem nicht mit den drei VMs, über die wir hier reden.

Einen aus meiner Sicht guten Artikel hat Eric Siron dazu geschrieben, der bei den Themen ohnehin seit 15 Jahren zu den besten Autoren zählt:

[What is the Hyper-V Core Scheduler?]
https://www.altaro.com/hyper-v/hyper-v-core-scheduler/

Da kommt am Ende auch raus: Macht es oder lasst es, wahrscheinlich bemerkt ihr keinen Unterschied. (Die Sicherheitsvorteile, die der Core Scheduler bringt, beziehen sich auch eher auf den Rechenzentrumsbetrieb - in der hier diskutierten Umgebung dürfte das zu vernachlässigen sein.)

Gruß, Nils

Moin,

also noch mal zum Mitschreiben: Bei dem, was du beschrieben hast, würde ich gar nicht erst groß feinjustieren. Da ist doch nicht mit ernsthafter Last zu rechnen.

vor 54 Minuten schrieb firefox_i:

ob Deiner Erfahrung nach die CPU Virtualisierung sinnvoll ist oder nicht?

Mit der Frage kann ich nichts anfangen. Was soll denn "CPU Virtualisierung" sein?

Gruß, Nils

Moin,

auf der allgemeinen Ebene kann man solche Fragen auch nur sehr allgemein beantworten. Generell gibt es mehrere nutzbare Verfahren. Welches "das beste" wäre, hängt davon ab, was denn die Anforderungen sind.

Geklonte Windows-Installationen musste man nicht nur unter XP und Windows 7 mit einem neuen SID versehen, sondern das galt seit Windows NT und ist heute immer noch so. Anders als viele annehmen, geht es dabei aber nicht um den Domain Join, dem ist das egal. Es geht um eine Reihe anderer Dinge in und um Windows, die sonst nicht richtig funktionieren. Da Sysprep nur wenige Minuten in Anspruch nimmt, ist das auch keine Hürde.

Viel mehr kann man dazu jetzt eigentlich nicht mehr sagen ... wenn du noch was wissen möchtest, solltest du konkreter fragen.

Gruß, Nils

Moin,

ich denke, nach fast einem halben Jahr hatte sich die Frage ohnehin erledigt.

Gruß, Nils

Moin,

wenn es eine Clusterumgebung ist, dann habt ihr vermutlich hohe Anforderungen an die Ausfallsicherheit. In dem Fall verbietet es sich, solch einen Vorgang ohne sehr gute technische Kenntnisse der Umgebung und des Systems auszuführen. Der einzig sinnvolle Rat kann also nur lauten: Holt euch kompetente Unterstützung von außen dazu.

Gruß, Nils

Moin,

allgemein solltest du in der Virtualisierung keine "einfachen" Performancetests durchführen. Die meisten davon geben keine zutreffenden Ergebnisse aus, weil sie nicht an den Stellen messen, die bei der Virtualisierung relevant sind.

Bei den beschriebenen Workloads wirst du die 4 Gbit/s, die ohne weitere Optimierung von einer 10-GbE-Karte zu erwarten sind, ohnehin nicht auslasten. Und selbst wenn - dann dauert es halt eine Sekunde länger, eine riesige Datei zu kopieren. Ich würde da noch nicht mal in Erwägung ziehen, eine der erweiterten Techniken zu nutzen, ob es nun SR-IOV ist oder VMQ oder was auch immer. 

Gruß, Nils

Moin,

vor 6 Minuten schrieb zahni:

Sie benötigen einen externen virtuellen Switch, der SR-IOV-Traffic beherrscht.

das ist Unsinn. Ein "externer virtueller Switch" ist ein Objekt in Hyper-V. Der kann gar keinen solchen Traffic beherrschen, der weiß nichts davon. Der Witz an SR-IOV ist ja gerade, dass der VM-Traffic am Hypervisor vorbeigeht.

Der Artikel ist noch aus einer Zeit, als die Technik nagelneu war, da hat man sich als Autor aus den verfügbaren Quellen was zusammengereimt. Testen konnte man es damals praktisch noch nicht. Auch in "dem Buch" hatten wir das Problem, aber Jan hat seinerzeit deutlich besser recherchiert als der CW-Autor. 

Nach meiner Kenntnis ist der physische Switch bei SR-IOV nicht beteiligt. Ist aber, wie gesagt, auch egal. Erstens funktioniert es hier ohnehin nicht und zweitens ist es unnötig.

Gruß, Nils

Moin,

nach meiner Einschätzung deutet das eher darauf hin, dass ihr es nicht richtig gemacht habt. An dieser Stelle enden meine Detailkenntnisse, als Manager muss ich das nicht genauer wissen. 

Gruß, Nils

Moin,

es scheint mir ein Missverständnis vorzuliegen, was SR-IOV überhaupt ist. Das ist kein Performancebooster für "die" Netzwerkkarte. Es ist eine Technik, um eine einzelne Hardware-Karte in mehrere virtuelle Karten aufzuteilen.

https://learn.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-single-root-i-o-virtualization--sr-iov-

Das erzeugt eine recht hohe Komplexität und ist deshalb nur in wenigen Szenarien sinnvoll. Der von dir angeführte Workload gehört nicht dazu, das ist doch sehr überschaubar. Das bekommt man mit normalen Mitteln besser und einfacher in den Griff.

Gruß, Nils

PS. ich ergänze noch: warum du die Funktion anscheinend nicht aktiviert bekommst, ist etwas rätselhaft. Wie @Nobbyaushb schon andeutet, können das durchaus Fehler in den Treibern sein. Da die Technik in der Praxis sehr selten verwendet wird, kann es dabei sein, dass die Fehler "nicht wichtig genug" sind ... das ist aus unserer Sicht aber auch egal, denn unsere Empfehlung ist, das einfach wegzulassen.