NilsK

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, 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. 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, 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.

Moin, nur um das anzumerken: Die gibt es so pauschal nicht. Man muss bestimmte Korrespondenz aufbewahren bzw. in bestimmten Fällen nachweisen und vorlegen können. Aber es gibt keine Archivierungspflicht für Mails, schon gar nicht für alle Mails. Ist hier aber auch nicht das Thema, also sollten wir das weglassen. Gruß, Nils

Moin, ja, das liest du richtig. Die Idee ist: Microsoft ist hier der Provider des Kunden und muss für hohe Sicherheit sorgen. Wenn der Kunde aus Unkenntnis oder Nachlässigkeit nichts tut, dann schaltet MS die MFA an, um das Sicherheitsniveau zu erhöhen. Als Kunde kannst du das ausdrücklich abschalten und das auch im Voraus. Das musst du aber eben ausdrücklich und absichtlich tun. Damit ist sich Microsoft sicher - und kann das im Zweifel auch nachweisen -, dass der Kunde selbst das bewusst abgeschaltet hat. Gruß, Nils

Moin, keine angemessene Antwort in Bezug zu Hilfsbereitschaft. Gruß, Nils

Moin, du sprichst mir aus der Seele. Dass wir manchmal einer Meinung sind, haben wir ja schon mal mit Erstaunen festgestellt. Gruß, Nils PS. erwähnte ich schon, dass PKI böse ist?

Moin, hm ... so pauschal nicht. Dafür sind ja gerade die Berechtigungen da. Bei dem Satz würde ich sowas ergänzen wie: ... mit dynamischen Werten, die du nicht zu 100% kontrollieren kannst ... wenn die Berechtigungen nicht zu 100% passen Was für Sicherheitsgründe hast du im Blick? Gruß, Nils

Moin, Platt ist ja auch (jeweils) eine eigene Sprache, kein Dialekt. Da kann es leicht vorkommen, dass ein Plattsprecher einen anderen nicht versteht, wenn der aus einer anderen Region kommt. Und wer gar kein Platt spricht (so wie ich), ist in jedem Fall außen vor. Meine Theorie ist aber, dass dialektlose Norddeutsche mit allen Deutsch-Dialekten (außer dem, der als "Hochdeutsch" gilt) Schwierigkeiten haben, wobei es Dialektsprechern leichter fällt, andere Dialekte zu verstehen. Kann aber auch sein, dass das ein Irrglaube ist. Gruß, Nils