Haben Sie sich jemals gefragt, was ein Scanner mit einer VDI-Station macht? Zunächst sieht alles gut aus: Er wird wie ein normales USB-Gerät durchgereicht und ist von der virtuellen Maschine aus "transparent" sichtbar. Dann gibt der Benutzer den Befehl zum Scannen, und alles fällt auseinander. Im besten Fall ist der Treiber des Scanners betroffen, im schlechteren Fall die Scansoftware nach ein paar Minuten, und möglicherweise beeinflusst es auch andere Benutzer im Cluster. Warum? Weil man, um ein fünf Megabyte großes komprimiertes Bild zu erhalten, über USB 2.0 zwei bis drei Größenordnungen mehr Daten senden muss. Die Bandbreite des Busses beträgt 480 Mbit/s.
Daher müssen drei Dinge getestet werden: UX, Peripheriegeräte und Sicherheit — unbedingt. Es macht einen Unterschied, wie man testet. Man kann Agenten lokal auf jeder virtuellen Arbeitsstation installieren. Das ist relativ kostengünstig, zeigt aber die Belastung des Kanals nicht genau und berechnet die CPU-Belastung nicht ganz korrekt. Die zweite Möglichkeit ist, sich an einem anderen Ort mit der erforderlichen Anzahl von Roboter-Emulatoren zu installieren und diese mit echten Arbeitsplätzen zu verbinden wie echte Benutzer. Die Belastung durch das Protokoll zur Übertragung des Bildschirmvideostreams (genauer gesagt, geänderte Pixel), das Analysieren und Versenden von Netzwerkpaketen wird dazukommen, und die Kanalbelastung wird deutlich werden. Der Kanal wird im Allgemeinen sehr selten überprüft.
UX ist die Geschwindigkeit, mit der verschiedene Aktionen von Endbenutzern ausgeführt werden. Es gibt Testpakete, die die Installation mit Hunderten von Benutzern belasten und typische Aktionen durchführen: sie starten Office-Pakete, lesen PDFs, browsen, schauen sehr selten in der Arbeitszeit Pornos und so weiter.
Ein ziemlich gutes Beispiel dafür, warum solche Tests im Voraus wichtig sind, gab es bei der letzten Installation. Dort ziehen tausend Benutzer in VDI um, sie haben ein Büro, einen Browser und SAP. Die IT-Abteilung im Unternehmen ist gut entwickelt, daher gibt es eine Kultur des Lasttests vor Implementierungen. Meiner Erfahrung nach muss der Kunde in der Regel überredet werden, weil die Kosten hoch sind und der Nutzen nicht immer offensichtlich ist. Es gibt Berechnungen, bei denen Fehler gemacht werden können? In der Praxis decken solche Tests jedoch Bereiche auf, die man zwar gedacht, aber nicht überprüfen konnte.
Installation
Sechs Server, die Konfiguration ist wie folgt:
Auf die Speichersysteme des Kunden hatten wir keinen Zugriff; sie wurden uns bereits in Form eines Serviceplatzes zur Verfügung gestellt. Wir wissen jedoch, dass es sich um All-Flash handelt. Welche Art von All-Flash, wissen wir nicht, aber die Partitionen sind jeweils 10 TB groß. VDI — VMware nach Wahl des Kunden, da das IT-Team bereits mit dem Stack vertraut ist, und alles recht organisch zu einer durchgehenden Infrastruktur ergänzt wird. VMware macht einen sehr „abhängig“ von seinem Ökosystem, aber wenn das Budget für die Anschaffung ausreicht, kann man jahrelang ohne Probleme arbeiten. Aber das ist häufig ein sehr großes „wenn“. Wir haben einen guten Rabatt, und das weiß der Kunde.
Wir beginnen mit den Tests, da das IT-Team fast nichts ohne Tests in den produktiven Betrieb lässt. VDI ist nicht etwas, das man einfach starten und dann akzeptieren kann. Die Benutzer werden schrittweise geladen, und man kann auch nach einem halben Jahr auf Probleme stoßen. Das möchte natürlich niemand.
450 „Benutzer“ im Test, die Last erzeugen wir lokal. Robo-User führen verschiedene Aktionen gleichzeitig aus, wir messen die Zeit jeder Operation über mehrere Stunden Arbeit:
Wir beobachten, wie sich die Server, das Speichersystem verhalten werden. Kann VDI die erforderliche Anzahl virtueller Arbeitsplätze erstellen und so weiter. Da der Kunde sich nicht für hyperkonvergente Systeme entschieden hat, sondern ein Flash-Speichersystem gewählt hat, musste auch die Richtigkeit der Größenanpassung überprüft werden.
Wenn irgendwo etwas stockt, müssen die Einstellungen der VDI-Farm geändert werden, insbesondere die Verteilung der Ressourcen zwischen Benutzern verschiedener Kategorien.
Peripherie
Mit der Peripherie gibt es normalerweise drei Situationen:
- Der Kunde sagt einfach, dass wir nichts anschließen (außer Headsets, die normalerweise „out of the box“ erkannt werden). In den letzten etwa fünf Jahren habe ich sehr selten Headsets gesehen, die sich nicht selbst verbinden und die nicht von VMware erkannt wurden.
- Der zweite Ansatz besteht darin, innerhalb des VDI-Einführungsprojekts die Peripherie zu ändern: Wir übernehmen getestete und vom Kunden unterstützte Geräte. Ein solcher Fall ist aus offensichtlichen Gründen selten.
- Der dritte Ansatz — wir integrieren die vorhandene Hardware.
Sie wissen bereits von dem Problem mit Scannern: Es ist notwendig, eine Zwischenanwendung auf der Arbeitsstation (Thin Client) zu installieren, die den USB-Datenstrom empfängt, das Bild komprimiert und an VDI sendet. Aufgrund bestimmter Besonderheiten ist dies nicht immer möglich: Während es bei Windows-Clients (Heimcomputern und Thin Clients) gut funktioniert, wird für *nix-Distributionen in der Regel nur eine bestimmte Distribution vom VDI-Anbieter unterstützt, und man muss herumtüfteln, genauso wie bei Mac-Clients. Nach meinem Wissen hat kaum jemand lokale Drucker von Linux-Installationen so angeschlossen, dass sie in der Testphase ohne ständige Anrufe beim Support funktionieren. Aber das ist schon besser, denn vor einiger Zeit funktionierte es nicht einmal einfach.
Videokonferenzen – alle Kunden möchten früher oder später, dass das funktioniert und gut läuft. Wenn die Farm richtig projektiert wurde, funktioniert es gut; wenn nicht, haben wir die Situation, dass während der Audiokonferenz die Last auf dem Kanal steigt, zusätzlich kommt das Problem dazu, dass das Bild schlecht dargestellt wird (kein Full HD, Gesichter aus 9–16 Pixeln). Es entsteht eine sehr starke zusätzliche Verzögerung, wenn eine Schleife zwischen dem Client, der VDI-Arbeitsstation, dem VKS-Server, von dort zum zweiten VDI und dem zweiten Client entsteht. Man sollte direkt vom Client zum VKS-Server verbinden, was die Installation eines weiteren zusätzlichen Components erfordert.
USB-Sticks – es gibt keinerlei Probleme damit, auch Smartcards und Ähnliches funktionieren sofort. Schwierigkeiten gibt es bei Barcode-Scannern, Etikettendruckern, Maschinen (ja, das gab es auch), Kassen. Aber alles lässt sich lösen. Mit einigen Nuancen und nicht ohne Überraschungen, aber letztendlich wird es gelöst.
Wenn ein Benutzer YouTube von einer VDI-Station aus ansieht – ist das die schlechteste Situation sowohl für die Last als auch für den Kanal. Die meisten Lösungen bieten HTML5-Videoredirigierung an. Die komprimierte Datei wird an den Client gesendet, wo sie angezeigt wird. Alternativ wird dem Client ein Link für die direkte Verbindung zwischen dem Browser und dem Video-Hosting übergeben (das ist seltener).
Sicherheit
Die Sicherheit knistert normalerweise an den Verbindungsstellen von Komponenten und an den Endgeräten. An den Schnittstellen sollte in einem Ökosystem alles gut funktionieren. In der Praxis ist das jedoch in 90 % der Fälle so, und es gibt immer etwas, das nachgebessert werden muss. In den letzten Jahren war ein weiterer Kauf von VMware besonders praktisch – sie haben ein MDM-System zur Verwaltung von Geräten im Unternehmen integriert. VMware hat kürzlich interessante Netzwerk-Balancer (ehemals Avi Networks) eingeführt, die es ermöglichen, die Lastenverteilung ein Jahr nach der Übergabe von VDI zu klären, zum Beispiel. Ein weiteres rein VMware-spezifisches Merkmal ist die gute Optimierung von Filialen durch ihren jüngsten Einkauf, als sie die Firma VeloCloud übernommen haben, die SD-WAN für Filialnetzwerke anbietet.
Aus der Sicht des Endbenutzers sind Architektur und Anbieter kaum wahrnehmbar. Global wichtig ist, dass es einen Client für jedes Gerät gibt, mit dem man sich von einem Tablet, Mac oder Windows-Dünnclient verbinden kann. Es gab sogar Clients für Fernseher, die sind jedoch glücklicherweise mittlerweile nicht mehr vorhanden.
Das Besondere an VDI-Installationen ist derzeit, dass der Endbenutzer zu Hause einfach keinen Computer hat. Oftmals gibt es ein schwaches Android-Tablet (manchmal sogar mit Maus oder Tastatur), oder man hat Glück und erhält einen Computer mit Windows XP. Der sich, wie Sie sich denken können, schon lange nicht mehr aktualisiert hat. Und niemals aktualisiert werden wird. Oder sehr schwache Maschinen, auf denen der Client nicht installiert werden kann, Anwendungen nicht funktionieren und der Benutzer nicht arbeiten kann. Glücklicherweise sind selbst sehr schwache Geräte geeignet (nicht immer komfortabel, aber geeignet), was als großer Vorteil von VDI gilt. Was die Sicherheit betrifft – man muss die Kompromittierung der Client-Systeme testen. Das passiert ziemlich häufig.
Im Lichte der Empfehlungen von Rospotrebnadzor zur Organisation der Arbeit von Unternehmen unter den Risiken von COVID-19 ist der Zugang zu den Arbeitsplätzen im Büro sehr relevant. Es scheint, dass diese Situation länger bestehen bleibt, und ja, wenn Sie über VDI nachgedacht haben – Sie können mit Tests beginnen. Das wird nützlich sein. Die Empfehlungen liegen vor , Erklärungen . Wichtig ist, dass man mit VDI auch Räumlichkeiten umgestalten kann, um die Anforderungen einzuhalten. Der Regulator führt bestimmte Abstandsregelungen ein. Zum Beispiel dürfen in einem Büro mit einer Fläche von 50 qm nicht mehr als fünf Mitarbeiter anwesend sein.
Wenn Sie Fragen zu VDI haben, die nicht für Kommentare gedacht sind, hier ist meine E-Mail: SSkryl@croc.ru.
Quelle: habr.com
