mwiederkehr

Ich habe viele Migrationen von vSphere zu Hyper-V durchgeführt und eigentlich nie ein Feature vermisst. Von daher verstehe ich den aktuellen Hype um Proxmox nicht ganz. Allerdings habe ich nie verteilte Switches oder vSAN angetroffen und auch mit Storage Spaces keine Erfahrung. Ah doch, ein Feature vermisse ich: Eine Aufzeichnung der Leistungsdaten. Im vCenter konnte man bequem historische Daten zur CPU-Nutzung etc. abrufen. Ohne SCVMM fehlt das, ausser man hilft sich mit PRTG und Konsorten. Die GUI für die iSCSI-Konfiguration ist in der Tat nicht so toll. Bei Multipath mit mehreren Initiatoren kann die Einrichtung zu regelrechten Klickorgien ausarten. Deshalb mein Tipp für die gesamte Netzwerkkonfiguration inkl. iSCSI: Per PowerShell-Script machen. So ist die Konfiguration auf jedem Host identisch und nachvollziehbar. Der Cluster-Validierungsassistent ist pingelig, aber hilfreich: Wenn der Grün zeigt, funktioniert der Bau des Clusters ohne böse Überraschungen.

Es kommt ganz auf die Anwendung an. Ich habe schon mehrere Leute zufrieden über eine Leitung mit 20 MBit/s Upload arbeiten gesehen. Es ist ein grosser Unterschied, ob eine Anwendung beim Aufruf der Kundenübersicht alle Kunden lädt oder nur so viele, wie auf den Bildschirm passen. Wenn der Hersteller keine genauen Angaben macht, hilft nur ein eigener Test.

Verwendest Du Funktionen wie ROW_NUMBER() oder Aggregatfunktionen? Vergleiche mal die Ausführungspläne. Bei Views erfolgt die Filterung erst am Schluss. Mit ROW_NUMBER() würden also alle Datensätze aufgezählt und erst danach gefiltert. Führst Du die Abfrage direkt aus, filtert der SQL Server zuerst und wendet die Funktionen erst dann an. Für Deine Anforderung eignet sich allenfalls eine Tabellenwertfunktion.

Allerdings, denn man muss ja noch arbeiten können. Ich habe einen Kunden, bei dem ich ohne Zwischenablage auskommen muss. Zum Einfügen nutze ich ein Tool, welches den Text in der Zwischenablage "eintippt", aber bei grösseren SQL-Scripts dauert das...

RDP ist ein komplexes Protokoll und bietet viele Angriffsmöglichkeiten. Nicht nur auf das Protokoll zur Bildübertragung, sondern auch auf die umgeleiteten Drucker (XPS-Interpreter), Laufwerke, Zwischenablage etc. Die Zusatzfunktionen lassen sich aber abschalten. Die einzigen mir bekannten Schwachstellen beziehen sich auf die Zwischenablage. Der Server kann die Zwischenablage des Clients mitlesen und verändern. Wenn man "harmlose.exe" in der Zwischenablage hat, könnte sie durch "virus.exe" ersetzt werden, siehe https://research.checkpoint.com/2019/reverse-rdp-attack-code-execution-on-rdp-clients/. Zudem gab es eine Lücke, die Codeausführung erlaubt hat: https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2019-0887 Also ja, ist theoretisch möglich, aber sehr unwahrscheinlich, besonders wenn Zwischenablage etc. ausgeschaltet sind. Für TeamViewer gilt das genauso. Wer will, kann Guacamole in einer VM laufen lassen und einen Browser in einer anderen VM und über die Hyper-V-Konsole auf den Browser zugreifen. Galvanische Trennung quasi.

Ich trübe ja ungerne die Freude, aber mal vorsichtig ausgedrückt: Ceph (und auch andere verteilte Speichersysteme) laufen möglicherweise nicht ganz optimal über WAN-Verbindungen, bei denen sowohl Bandbreite als auch Latenz "best effort" sind.

Traumhaft! Muss St. Peter-Ording unbedingt auf die Liste für unsere nächste Reise in den Norden nehmen. Letzten Sommer sind wir von Föhr direkt nach Hamburg. Wer hat jetzt alles Appetit auf einen Fischteller und einen Pharisäer zum Dessert? Gute Reise!

Nicht kostenlos, aber günstig, ist PDQ Deploy. Da bezahlt man pro Admin und Jahr 1575 $ und die Anzahl Clients ist unbeschränkt. Die Verteilung erfolgt per "Push", sobald ein Client erreichbar ist. VPN ist grundsätzlich kein Hindernis. Wenn ein Client während der Übertragung des Installers die Verbindung trennt, bricht die Installation ab und beginnt beim nächsten Versuch wieder von vorn.

Vielleicht geht es ganz simpel mit vier iFrames? Mit etwas JavaScript könnte man noch vier Reload-Buttons hinzufügen, falls sich die Seiten nicht automatisch aktualisieren.

Ja, es ist komplizierter geworden. Ein Kunde hat kürzlich einen DL380 Gen10 mit NVMe ausgestattet. "Die leuchten nicht und werden nicht erkannt, dabei haben sie reingepasst!"

Es gibt NVMe-SSDs für Server. Die haben Anschlüsse vom Typ U.3 und nicht M.2 und passen in die gleichen Einschübe wie SATA und SAS.

Hallo zusammen Einige VMs auf einem Hyper-V-Cluster verlieren in unregelmässigen Abständen die Netzwerkverbindung. VMs und Hosts laufen auf Windows Server 2022. Der Unterbruch passiert pro VM etwa einmal im Monat. Es kann aber auch schon nach zwei Wochen sein oder erst nach zwei Monaten. Die Netzwerkkarte ist dann weg. Es hilft nur noch, die VM aus- und wieder einzuschalten. Eine Live-Migration auf einen anderen Host hilft nicht, ein normaler Neustart scheitert, weil er beim Herunterfahren hängen bleibt. In der Ereignisanzeige sind vor einem Unterbruch keine Fehler zu sehen. Es lässt sich auch nicht eruieren, dass die Benutzer etwas Spezielles gemacht hätten. Wenn der Unterbruch passiert, wird nur eine Meldung vom Typ "Information" erzeugt: Quelle "Hyper-V-Netvsc", ID 10, Text "Die Miniport-NIC 'Microsoft Hyper-V Network Adapter" wurde unterbrochen. Die betroffenen Server waren bis jetzt ausnahmslos Terminalserver und haben Benutzerprofildisks über FSlogix eingebunden. Bei den VMs mit anderen Rollen ist das Problem noch nie aufgetreten. Ich habe im Internet ein paar Meldungen zu Netzwerkproblemen bei Azure-VMs mit FSlogix gefunden, aber leider keine Lösung. Das Problem scheint schon mehrere Jahre zu bestehen, aber es wird nur unter seltenen Umständen auftreten, sonst wäre es längst behoben. Kennt jemand eine Lösung?

Der Extremfall waren 273 zugeteilte vCPUs auf einem Host mit 32 Cores. Das ergibt eine Überbuchung von 8.5:1 bzw. 4.3:1, wenn man HT einberechnet (was ja bekanntlich nicht "voll" zählt). Auf diesen VMs konnte man zeitweise kaum arbeiten, obwohl die Auslastung weder in den VMs noch auf dem Host über 20 % war. Die "CPU Wait Time Per Dispatch" war extrem hoch (habe mir den Wert leider nicht notiert). Als man die zugeteilten vCPUs massiv reduziert hat (zwei für DCs, einen pro zwei bis vier Benutzer auf den Terminalservern etc.), war das System erheblich schneller. Wobei zu erwähnen ist, dass der Host auf Windows Server 2016 lief, bei dessen Scheduler immer alle vCPUs einer VM gleichzeitig Ausführungszeit bekommen mussten. Da dauert es halt schon, bis 24 Cores für den TS frei sind, wenn jeder Webserver auch schon 16 Cores hat... Zudem wurde durch das Überschreiten der NUMA-Grenzen Performance verschenkt.

Ich finde die Geräte interessant. Als "Heimserver" habe ich bisher auf Intel NUCs gesetzt. Der MS-01 könnte dank SFP+ und mehreren M.2-Slots ein guter Nachfolger sein. Als Hypervisor für Kunden würde ich ihn nicht einsetzen. Da fehlen mir das redundante Netzteil, Hot-Swap der SSDs, ein bewährter RAID-Controller... Und wer liefert zeitnah Ersatzteile? Horizontal zu skalieren und einen Cluster zu bauen, ist eine Möglichkeit. Der kurze Unterbruch (Neustart) der VMs bei einem Ausfall würden die Kunden wahrscheinlich akzeptieren. Das Gerät fällt hoffentlich nicht jeden Monat aus. Aber welcher kleinere Kunde bezahlt Dir die Windows-Lizenzen für einen Clusterbetrieb? Und Dir die Mehrarbeit für die Updates? Es gibt Beispiele, wie Unternehmen "Billighardware" erfolgreich professionell einsetzen. Backblaze verwendet normale SATA-Disks und die ganzen Anbieter von "Root-Servern" bauen ihre Kisten selbst zusammen. Das geht aber nur, wenn man genug gross ist, um selbst für Ersatzteile zu sorgen, also immer genügend Ersatzgeräte an Lager zu halten.

Wie Du inzwischen selbst nachgelesen hast, kann der Hyper-V mittlerweile die vCPUs nacheinander "ausführen". Jede vCPU ist ein eigener Thread. Leider halten sich die (öffentlich zugänglichen) Informationen über den Scheduler in Grenzen, so dass ich nicht weiss, wann genau das eingeführt wurde. Das "Problem" bleibt, dass die VM nicht weiss, was der Hyper-V macht. Je nach Anwendung läuft eine Berechnung auf zwei Threads, die das Gastbetriebssystem auf zwei vCPUs verteilt und weil der eine Thread auf das Resultat des anderen angewiesen ist, dauert die Berechnung länger, als wenn sie nacheinander auf einer vCPU ausgeführt worden wäre. Wobei das in den meisten Fällen eher theoretische Überlegungen sind. Bei massiver CPU-Überbuchung habe ich schon Probleme in der Praxis gesehen. Terminalserver waren so langsam, dass sogar Eingaben verzögert erschienen sind. Dabei hat der Task Manager nur wenige Prozent Auslastung angezeigt. In der Panik wurden denn noch mehr vCPUs zugeteilt...