Haben Sie sich jemals gefragt, was ein Scanner mit einer VDI-Station macht? Zunächst sieht alles gut aus: Er wird wie ein gewöhnliches USB-Gerät durchgereicht und ist von der virtuellen Maschine aus „transparent“ sichtbar. Dann gibt der Benutzer den Befehl zum Scannen, und alles bricht zusammen. Im besten Fall ist es der Treiber des Scanners, im schlechteren Fall bringt die Scansoftware nach ein paar Minuten das System zum Stillstand, und es könnte auch andere Benutzer im Cluster beeinträchtigen. Warum? Weil es notwendig ist, um ein fünf Megabyte großes komprimiertes Bild zu erhalten, über USB 2.0 zwei- bis dreimal mehr Daten zu übertragen. Die Bandbreite des Busses beträgt 480 Mbit/s.
Es gibt drei Dinge, die getestet werden müssen: UX, Peripherie und Sicherheit – das ist unerlässlich. Es macht einen Unterschied, wie man testet. Man kann Agenten lokal auf jeder virtuellen Arbeitsstation installieren. Das ist relativ kostengünstig, zeigt jedoch nicht die Belastung des Kanals und berechnet die CPU-Last nicht ganz korrekt. Die zweite Option besteht darin, an einem anderen Ort die erforderliche Anzahl von Simulationsrobotern bereitzustellen und diese mit echten Arbeitsplätzen zu verbinden, wie echte Nutzer. Dabei kommt die Belastung durch das Protokoll zur Übertragung des Bildschirmvideostreams (genauer gesagt, geänderte Pixel) hinzu, ebenso wie die Analyse und das Senden von Netzwerkpaketen, wodurch die Belastung des Kanals klar wird. Der Kanal wird generell sehr selten überprüft.
UX ist die Geschwindigkeit, mit der Endbenutzer verschiedene Aktionen ausführen. Es gibt Testpakete, die die Installation mit hunderten von Benutzern belasten und typische Aktionen durchführen: sie starten Office-Pakete, lesen PDFs, surfen, schauen selten während der Arbeitszeit Pornos usw.
Ein recht gutes Beispiel dafür, warum solche Tests im Vorfeld wichtig sind, war bei der letzten Installation. Dort ziehen tausend Nutzer in ein VDI um; sie haben ein Büro, einen Browser und SAP. Die IT-Abteilung des Unternehmens ist gut aufgestellt, daher gibt es eine Kultur des Lasttests vor Implementierungen. Meiner Erfahrung nach muss man die Kunden normalerweise dazu überreden, da die Kosten hoch sind und der Nutzen nicht immer offensichtlich. Es gibt schließlich Berechnungen, bei denen Fehler passieren können? In der Praxis decken solche Tests die Stellen auf, wo man dachte, aber nicht überprüfen konnte.
Installation
Sechs Server, die Konfiguration ist wie folgt:
Auf die SAN des Kunden hatten wir keinen Zugriff; sie wurde bereits als Platz zum Service bereitgestellt. Aber wir wissen, dass es sich um All-Flash handelt. Welche Art von All-Flash, wissen wir nicht, aber es gibt Partitionen von jeweils 10 TB. VDI – VMware auf Wunsch des Kunden, da das IT-Team bereits mit dem Stack vertraut ist und alles gut zu einer ganzheitlichen Infrastruktur ergänzt wird. VMware ist sehr „abhängig“ von seinem Ökosystem, aber wenn das Budget für den Einkauf ausreicht – kann man über Jahre hinweg keine Probleme erfahren. Aber das ist oft ein sehr großes „wenn“. Wir haben einen guten Rabatt, und der Kunde weiß darüber Bescheid.
Wir beginnen mit den Tests, da das IT-Team fast nichts ohne Tests in die Produktion freigibt. VDI ist nicht etwas, das einfach gestartet und dann akzeptiert werden kann. Die Benutzer werden schrittweise geladen, und man kann durchaus nach sechs Monaten auf Probleme stoßen. Das möchte natürlich niemand.
450 „Benutzer“ im Test, die Last wird lokal generiert. Die Robouser führen verschiedene Aktionen gleichzeitig aus, wir messen die Dauer jeder Operation über mehrere Stunden.
Wir beobachten, wie sich die Server und das SAN verhalten. Kann VDI die erforderliche Anzahl an virtuellen Arbeitsplätzen erstellen usw. Da der Kunde sich nicht für hyperkonvergente Systeme entschieden hat, sondern ein Flash-SAN genommen hat, mussten wir auch die Richtigkeit der Dimensionierung überprüfen.
Wenn irgendwo etwas stockt, müssen die Einstellungen des VDI-Clusters geändert werden, insbesondere die Ressourcenzuteilung zwischen Benutzern unterschiedlicher Kategorien.
Peripherie
Bei der Peripherie gibt es normalerweise drei Situationen:
- Der Kunde sagt einfach, dass wir nichts anschließen sollen (außer den Headsets, die in der Regel „out of the box“ sichtbar sind). In den letzten etwa fünf Jahren habe ich sehr, sehr selten Headsets gesehen, die sich nicht selbst verbunden haben und die nicht von VMware erkannt wurden.
- Der zweite Ansatz besteht darin, im Rahmen des VDI-Einführungsprojekts die Peripheriegeräte zu wechseln: Wir verwenden getestete Geräte, die sowohl von uns als auch vom Kunden unterstützt werden. Dies ist aus verständlichen Gründen selten.
- Der dritte Ansatz ist, die vorhandene Hardware zu verwenden.
Sie wissen bereits von dem Problem mit Scannern: Es muss eine Zwischenanwendung auf dem Arbeitsplatz (Thin Client) installiert werden, die den USB-Strom empfängt, das Bild komprimiert und in VDI sendet. Aufgrund verschiedener Besonderheiten ist dies nicht immer möglich: Wenn bei Windows-Clients (Heimcomputern und Thin Clients) alles gut funktioniert, wird für *nix-Varianten normalerweise nur eine bestimmte Distribution vom VDI-Anbieter unterstützt, und es beginnt das ganze Prozedere, wie auch bei Mac-Clients. Soweit ich mich erinnere, hat kaum jemand lokale Drucker von Linux-Installationen so angeschlossen, dass sie während der Fehlersuche ohne ständige Anrufe beim Support funktionierten. Aber das ist schon besser; vor einiger Zeit hätte es sogar nur funktioniert, damit sie überhaupt laufen.
Videokonferenzen – früher oder später möchten alle Kunden, dass diese reibungslos funktionieren. Wenn die Infrastruktur gut geplant ist, läuft alles problemlos; andernfalls erleben wir während einer Audiokonferenz eine höhere Belastung des Netzwerks. Zusätzlich Schwierigkeiten mit der Bildqualität (kein Full HD, das Gesicht wird zu 9–16 Pixeln), was zu einer erheblichen Verzögerung führt, insbesondere wenn eine Schleife zwischen dem Client, der VDI-Arbeitsstation, dem VC-Server, einem zweiten VDI und einem zweiten Client entsteht. Die optimale Verbindung besteht darin, direkt vom Client zum VC-Server zu gehen, was die Installation einer zusätzlichen Komponente erfordert.
USB-Sticks – mit denen gibt es überhaupt keine Probleme, Smartcards und Ähnliches funktionieren sofort. Schwierigkeiten treten bei Barcode-Scannern, Etikettendruckern und Maschinen auf (ja, auch das gab es), sowie an Kassen. Aber das alles lässt sich lösen. Es gibt Nuancen und überraschungen, aber letztendlich finden wir eine Lösung.
Wenn ein Benutzer YouTube von einer VDI-Station aus betrachtet, ist das die schlechteste Situation sowohl für die Last als auch für die Verbindung. Die meisten Lösungen bieten eine HTML5-Video-Umleitung an. Eine komprimierte Datei wird an den Client übermittelt und dort angezeigt. Alternativ erhält der Client einen Link, um eine direkte Verbindung zwischen Browser und Videohosting herzustellen (was seltener der Fall ist).
Sicherheit
Sicherheit hat oft Probleme an den Schnittstellen der Komponenten und auf den Clientgeräten. An den Schnittstellen innerhalb eines Ökosystems sollte alles theoretisch gut funktionieren. Praktisch tritt das jedoch in etwa 90 % der Fälle auf, und es bleibt trotzdem etwas zu verbessern. In den letzten Jahren stellte sich ein weiterer Einkauf von VMware als äußerst praktisch heraus – sie haben ein MDM-System zur Verwaltung von Geräten innerhalb des Unternehmens integriert. VMware hat kürzlich interessante Netzwerkausgleichsgeräte (ehemals Avi Networks) eingeführt, die es ermöglichen, die Verteilung von Datenströmen etwa ein Jahr nach der Implementierung von VDI zu optimieren. Eine weitere spezifische VMware-Funktion ist die hervorragende Optimierung von Zweigstellen, die durch ihren jüngsten Einkauf zustande kam, als sie das Unternehmen VeloCloud übernahmen, das SD-WAN für Zweigstellennetzwerke entwickelt.
Aus der Sicht des Endbenutzers sind die Architektur und der Anbieter nahezu unsichtbar. Entscheidend ist global, dass es einen Client für jedes Gerät gibt; man kann sich von einem Tablet, Mac oder Windows-Dünnclient verbinden. Es gab sogar Clients für Fernseher, aber glücklicherweise sind die mittlerweile nicht mehr verfügbar.
Das Besondere an VDI-Installationen ist derzeit, dass der Endbenutzer zu Hause oft keinen Computer hat. Oft gibt es nur ein schwaches Android-Tablet (manchmal sogar mit Maus oder Tastatur), oder man hat Glück und erhält einen Computer mit Windows XP. Wie Sie sich denken können, wurde dieser eine lange Zeit nicht aktualisiert und wird es wahrscheinlich auch nie sein. Oder es gibt sehr schwache Maschinen, auf denen der Client nicht installiert werden kann, und die Anwendungen funktionieren nicht, sodass der Benutzer nicht arbeiten kann. Glücklicherweise sind selbst sehr schwache Geräte geeignet (nicht immer komfortabel, aber möglich), was als großer Vorteil von VDI angesehen wird. Was die Sicherheit betrifft, so müssen die Kompromittierung der Client-Systeme getestet werden. Das kommt ganz schön häufig vor.
Angesichts der Empfehlungen des Rospotrebnadzor zur Organisation der Arbeitsabläufe in Unternehmen unter dem Risiko von COVID-19 ist die Verbindung zu den Arbeitsplätzen im Büro äußerst relevant. Es scheint, dass diese Situation länger anhalten wird, und ja, falls Sie über VDI nachgedacht haben – Sie können mit den Tests beginnen. Es wird sich als nützlich erweisen. Die Empfehlungen liegen vor , die Erläuterungen . Wichtig ist, dass mit VDI auch Räumlichkeiten umgebaut werden können, um die Anforderungen zu erfüllen. Der Regulierer führt bestimmte Abstandsregeln ein. Zum Beispiel darf in einem Büro mit einer Fläche von 50 m² nicht mehr als fünf Mitarbeiter anwesend sein.
Wenn es Fragen zu VDI gibt, die nicht für die Kommentare gedacht sind – hier ist meine E-Mail: SSkryl@croc.ru.
Quelle: habr.com
