Für wen ist dieser Artikel?
Dieser Artikel kann für Systemadministratoren von Interesse sein, die vor der Aufgabe standen, einen "einmaligen" Jobdienst zu erstellen.
Prolog
Die IT-Support-Abteilung eines jungen, sich dynamisch entwickelnden Unternehmens mit einem kleinen regionalen Netzwerk wurde gebeten, "Self-Service-Stationen" für die Nutzung durch externe Kunden zu organisieren. Die Stationsdaten sollten für die Registrierung auf den externen Portalen des Unternehmens, das Herunterladen von Daten von externen Geräten und die Arbeit mit Regierungsportalen verwendet werden.
Ein wichtiger Aspekt war die Tatsache, dass der größte Teil der Software unter MS Windows „geschärft“ wird (z. B. „Deklaration“), und trotz der Hinwendung zu offenen Formaten bleibt MS Office der dominierende Standard beim Austausch elektronischer Dokumente. Daher konnten wir MS Windows bei der Lösung dieses Problems nicht ablehnen.
Das Hauptproblem war die Möglichkeit, verschiedene Daten aus Benutzersitzungen zu sammeln, die zu deren Weitergabe an Dritte führen könnten.
Diese Situation hat den MFC bereits im Stich gelassen . Im Gegensatz zur quasi-gerichtlichen (staatlich autonomen Institution) MFC werden nichtstaatliche Organisationen für solche Mängel viel stärker bestraft. Das nächste kritische Problem war die Anforderung, mit externen Speichermedien zu arbeiten, auf denen auf jeden Fall eine Menge bösartiger Malware vorhanden sein wird. Die Wahrscheinlichkeit des Eintritts von Malware aus dem Internet wurde aufgrund der Einschränkung des Zugangs zum Internet über eine weiße Adressliste als weniger wahrscheinlich angesehen. Mitarbeiter anderer Abteilungen erarbeiteten gemeinsam die Anforderungen, stellten ihre Anforderungen und Wünsche. Die endgültigen Anforderungen sahen wie folgt aus:
IS-Anforderungen- Nach der Verwendung sollten alle Benutzerdaten (einschließlich temporärer Dateien und Registrierungsschlüssel) gelöscht werden.
- Alle vom Benutzer gestarteten Prozesse sollten am Ende der Arbeit abgeschlossen sein.
- Internetzugang über eine weiße Liste von Adressen.
- Einschränkungen bei der Ausführung von Code von Drittanbietern.
- Wenn die Sitzung länger als 5 Minuten inaktiv ist, sollte die Sitzung automatisch beendet werden und die Station sollte eine Bereinigung durchführen.
Kundenanforderungen- Die Anzahl der Client-Stationen pro Zweigstelle beträgt nicht mehr als 4.
- Die minimale Wartezeit für die Systembereitschaft, von dem Moment an, als ich mich auf einen Stuhl setzte, bis zum Beginn der Arbeit mit Client-Software.
- Die Möglichkeit, Peripheriegeräte (Scanner, Flash-Laufwerke) direkt vom Installationsort der "Self-Service-Station" aus anzuschließen.
- Kundenwünsche
- Vorführung von Werbematerialien (Bilder) zum Zeitpunkt der Schließung des Komplexes.
Mehl der Kreativität
Nachdem wir genug mit Windows LiveCD gespielt hatten, kamen wir einstimmig zu dem Schluss, dass die resultierende Lösung nicht mindestens 3 kritische Punkte erfüllt. Sie sind entweder für eine lange Zeit geladen oder nicht ganz lebendig, oder ihre Anpassung war mit wilden Schmerzen verbunden. Vielleicht haben wir schlecht gesucht, und Sie können eine Reihe von Tools empfehlen, ich werde Ihnen dankbar sein.
Weiter haben wir uns mit VDI befasst, aber für diese Aufgabe sind die meisten Lösungen entweder zu teuer oder erfordern besondere Aufmerksamkeit. Und ich wollte ein einfaches Tool mit einem Minimum an Magie, dessen Probleme größtenteils durch einen einfachen Neustart / Neustart des Dienstes gelöst werden konnten. Glücklicherweise hatten wir Serverausrüstung, Low-End-Klasse in den Filialen, aus dem stillgelegten Dienst, die wir für die technologische Basis verwenden konnten.
Was ist das Ergebnis? Aber ich kann Ihnen nicht sagen, was am Ende passiert ist, weil die NDA, aber während der Suche haben wir ein interessantes Schema entwickelt, das sich in Labortests gut gezeigt hat, obwohl es nicht in Serie ging.
Einige Haftungsausschlüsse: Der Autor behauptet nicht, dass die vorgeschlagene Lösung alle Aufgaben vollständig löst und dies freiwillig und mit dem Lied tut. Der Autor stimmt im Voraus der Aussage zu, dass Sein Englishe sprache zehr schlecht ist. Da sich die Lösung nicht mehr entwickelt, können Sie nicht mit einer Fehlerbehebung oder einer Änderung der Funktionalität rechnen. Alles liegt in Ihren Händen. Der Autor geht davon aus, dass Sie mit KVM zumindest ein wenig vertraut sind und einen Übersichtsartikel zum Spice-Protokoll gelesen haben und ein wenig mit Centos oder einer anderen GNU Linux-Distribution gearbeitet haben.
In diesem Artikel möchte ich das Rückgrat der resultierenden Lösung analysieren, nämlich die Interaktion von Client und Server und die Essenz der Prozesse im Lebenszyklus virtueller Maschinen im Rahmen der betreffenden Lösung. Wenn der Artikel für die Öffentlichkeit interessant sein soll, beschreibe ich die Details der Implementierung von Live-Images zum Erstellen von Thin Clients auf Fedora-Basis und erläutere die Details der Optimierung virtueller Maschinen und KVM-Server zur Optimierung von Leistung und Sicherheit.
Wenn Sie farbiges Papier nehmen,
Farben, Pinsel und Kleber,
Und ein bisschen mehr Geschicklichkeit ...
Sie können hundert Rubel machen!
Schema und Beschreibung des Prüfstands

Alle Geräte befinden sich im Filialnetz, nur der Internetkanal geht aus. In der Vergangenheit gab es bereits einen Proxyserver, es ist nichts Außergewöhnliches. Daraufhin wird unter anderem der Datenverkehr von virtuellen Maschinen gefiltert (Abk. VM später im Text). Nichts hindert Sie daran, diesen Dienst auf dem KVM-Server zu platzieren. Sie müssen lediglich beobachten, wie sich die Last auf dem Festplattensubsystem ändert.
Client Station - in der Tat "Self-Service-Stationen", "Front-End" unseres Service. Sind Nettops von Lenovo IdeaCentre. Wofür ist dieses Gerät gut? Ja, fast alle, besonders zufrieden mit der großen Anzahl von USB-Anschlüssen und Kartenlesern auf der Vorderseite. In unserem Schema wird eine SD-Karte mit Hardware-Schreibschutz in den Kartenleser eingelegt, auf der das modifizierte Livebild von Fedora 28 aufgezeichnet wird. Natürlich sind ein Monitor, eine Tastatur und eine Maus mit dem Nettop verbunden.
Schalter - ein unauffälliger Hardware-Schalter der zweiten Ebene, der sich im Serverraum befindet und mit Lichtern blinkt. Es ist mit keinem Netzwerk außer dem Netzwerk der „Selbstbedienungsstationen“ verbunden.
KVM_Server ist der Kern der Schaltung. In den Bench-Tests des Core 2 Quad Q9650 mit 8 GB RAM wurden sicher 3 virtuelle Windows 10-Maschinen auf sich gezogen. Festplattensubsystem - adaptec 3405 2 Laufwerke Raid 1 + SSD. In Feldversuchen des Xeon 1220 zog die ernstere LSI 9260 + SSD leicht 5-6 VMs. Wir würden den Server vom pensionierten Dienst bekommen, es würde nicht viel Kapitalkosten geben. Auf diesen Servern wird das KVM-Virtualisierungssystem mit dem Pool der virtuellen Maschine pool_Vm bereitgestellt.
VM ist eine virtuelle Maschine, das Backend unseres Service. Es ist die Arbeit des Benutzers.
Enp5s0 ist eine Netzwerkschnittstelle, die auf das Netzwerk von "Self-Service-Stationen", dhcpd, ntpd, httpd live darauf und xinetd auf den "Signal" -Port blickt.
Lo0 ist die Loopback-Pseudo-Schnittstelle. Standard.
Spice_console - Eine sehr interessante Sache ist die Tatsache, dass im Gegensatz zum klassischen RDP beim Einschalten des KVM + Spice-Protokollpakets eine zusätzliche Entität angezeigt wird - der Konsolenport der virtuellen Maschine. Wenn wir eine Verbindung zu diesem TCP-Port herstellen, erhalten wir die VM-Konsole, ohne dass eine Verbindung zu VM über die Netzwerkschnittstelle hergestellt werden muss. Alle Interaktionen mit Vm zur Signalübertragung übernimmt der Server. Das nächstgelegene Analogon in der Funktion ist IPKVM. Das heißt, Das Image des VM-Monitors wird an diesen Port übertragen, Daten zur Mausbewegung werden an diesen Port übertragen, und (was am wichtigsten ist) die Interaktion über das Spice-Protokoll ermöglicht es Ihnen, USB-Geräte nahtlos an die virtuelle Maschine umzuleiten, als ob dieses Gerät mit der VM selbst verbunden wäre. Getestet für Flash-Laufwerke, Scanner, Webcams.
Vnet0-, virbr0- und virtuelle Netzwerkkarten Vm bilden ein Netzwerk virtueller Maschinen.
Wie funktioniert es?
Von der Client Station
Die Client-Station startet im grafischen Modus vom modifizierten Live-Image von Fedora 28 und empfängt die IP-Adresse per DHCP aus dem Netzwerkadressraum 169.254.24.0/24. Während des Startvorgangs werden Firewall-Regeln erstellt, die Verbindungen zu den Server-Ports "Signal" und "Spice" ermöglichen. Nach Abschluss des Downloads wartet die Station auf die Autorisierung des Client-Benutzers. Nach der Benutzerautorisierung wird der Desktop-Manager "openbox" gestartet und das Autostart-Autostart-Skript im Namen des autorisierten Benutzers ausgeführt. Das Autorun-Skript führt unter anderem das Skript remote.sh aus.
$ HOME / .config / openbox / scripts / remote.sh /etc/client.conf server_ip=169.254.24.1 vdi_signal_port=5905 vdi_spice_port=5906 animation_folder=/usr/share/backgrounds/animation background_folder=/usr/share/backgrounds2/fedora-workstation
Beschreibung der Variablen der Datei client.conf
server_ip - Adresse KVM_Server
vdi_signal_port - Port KVM_Server, auf dem xinetd "sitzt"
vdi_spice_port - Netzwerkport KVM_Server, von dem die Verbindungsanforderung vom Remote-Viewer-Client zum Spice-Port des ausgewählten VM umgeleitet wird (Details unten).
animation_folder - Ordner, aus dem Bilder für Demonstrations-Bullshit-Animationen entnommen werden
background_folder - Der Ordner, aus dem Bilder für Standby-Präsentationen entnommen werden. Mehr zur Animation im nächsten Teil des Artikels.
Das Skript remote.sh übernimmt die Einstellungen aus der Konfigurationsdatei /etc/client.conf und verwendet nc, um eine Verbindung zum Port "vdi_signal_port" des KVM-Servers herzustellen, und empfängt einen Datenstrom vom Server, unter dem die Zeichenfolge "RULE ADDED, CONNECT NOW" erwartet wird. Wenn die gewünschte Leitung empfangen wird, startet der Remote-Viewer-Prozess im Kiosk-Modus und stellt eine Verbindung zum Server-Port "vdi_spice_port" her. Die Ausführung des Skripts wird bis zum Ende der Remote-Viewer-Ausführung angehalten.
Der Remote-Viewer, der aufgrund einer Umleitung auf der Serverseite eine Verbindung zum Port "vdi_spice_port" herstellt, gelangt zum Port "spice_console" der lo0-Schnittstelle, d. H. an die Konsole der virtuellen Maschine und die Arbeit des Benutzers erfolgt direkt. Während des Wartens auf die Verbindung wird dem Benutzer eine Bullshit-Animation in Form einer Diashow mit JPEG-Dateien angezeigt. Der Pfad zum Verzeichnis mit den Bildern wird durch den Wert der Variablen animation_folder aus der Konfigurationsdatei bestimmt.
Wenn die Verbindung zum Port "spice_console" der virtuellen Maschine unterbrochen wird, was das Herunterfahren / Neustarten der virtuellen Maschine (dh das tatsächliche Ende der Benutzersitzung) signalisiert, werden alle Prozesse, die im Auftrag des autorisierten Benutzers ausgeführt werden, beendet, was zum Neustart von lightdm führt und zum Autorisierungsbildschirm zurückkehrt .
Von der Seite des KVM-Servers
Auf dem Signalport der Netzwerkkarte wartet enp5s0 auf die xinetd-Verbindung. Nach dem Herstellen einer Verbindung zum Signal-Port führt xinetd das Skript vm_manager.sh aus, ohne Eingabeparameter zu übergeben, und leitet das Ergebnis des Skripts an die NC-Sitzung der Client Station weiter.
/etc/xinetd.d/test-server service vdi_signal { port = 5905 socket_type = stream protocol = tcp wait = no user = root server = /home/admin/scripts_vdi_new/vm_manager.sh }
/home/admin/scripts_vdi_new/vm_manager.sh /etc/vm_manager.confsrv_scripts_dir = / home / admin / scripts_vdi_new
srv_pool_size = 4
srv_start_port_pool = 5920
srv_tmp_dir = / tmp / vm_state
base_host = win10_2
input_iface = enp5s0
vdi_spice_port = 5906
count_conn_tryes = 10
Beschreibung der Variablen der Konfigurationsdatei vm_manager.conf
srv_scripts_dir - Skriptspeicherortordner vm_manager.sh, vm_connect.sh, vm_delete.sh, vm_create.sh, vm_clear.sh
srv_pool_size - Vm Poolgröße
srv_start_port_pool - der anfängliche Port, nach dem die Spice-Ports der Konsolen der virtuellen Maschine beginnen
srv_tmp_dir - Ordner für temporäre Dateien
base_host - base Vm (goldenes Bild), aus dem Vm-Klone in den Pool erstellt werden
input_iface - Die Netzwerkschnittstelle des Servers mit Blick auf Client-Stationen
vdi_spice_port - Der Netzwerkport des Servers, von dem die Verbindungsanforderung vom Remote-Viewer-Client zum Spice-Port der ausgewählten VM umgeleitet wird
count_conn_tryes - Wartezeit, nach der angenommen wird, dass die Verbindung zu Vm nicht hergestellt wurde (Einzelheiten siehe vm_connect.sh).
Das Skript vm_manager.sh liest die Konfigurationsdatei aus der Datei vm_manager.conf und wertet den Status der virtuellen Maschinen im Pool anhand verschiedener Parameter aus, nämlich: Wie viele VMs werden bereitgestellt, ob freie saubere VMs vorhanden sind. Dazu liest er die Datei clear.list, die die Anzahl der "spice_console" -Ports der "neu erstellten" (siehe VM-Erstellungszyklus unten) virtuellen Maschinen enthält, und prüft, ob eine Verbindung zu ihnen hergestellt wurde. Wenn ein Port mit einer hergestellten Netzwerkverbindung erkannt wird (was auf keinen Fall der Fall sein sollte), wird eine Warnung angezeigt und der Port wird an verschwenderisch übertragen. Wenn der erste Port aus der Datei clear.list gefunden wird, mit der derzeit keine Verbindung besteht, ruft vm_manager.sh das Skript vm_connect.sh auf und übergibt es ihm als Parameter die Nummer dieses Ports.
/home/admin/scripts_vdi_new/vm_connect.sh Das Skript vm_connect.sh führt Firewall-Regeln ein, die eine Umleitung "vdi_spice_port" des Server-Ports der enp5s0-Schnittstelle zum "spice console port" der VM auf der lo0-Serverschnittstelle erstellen, die als Startparameter übergeben wird. Der Port wird an conn_wait.list übertragen. Die VM wird als ausstehende Verbindung betrachtet. Die Zeile RULE ADDED, CONNECT NOW wird an die Client Station-Sitzung am Signalport des Servers gesendet, was von dem darauf ausgeführten Skript remote.sh erwartet wird. Ein Verbindungswartezyklus beginnt mit der Anzahl der Versuche, die durch den Wert der Variablen "count_conn_tryes" aus der Konfigurationsdatei bestimmt werden. Jede Sekunde in der NC-Sitzung wird die Zeichenfolge "REGEL HINZUGEFÜGT, JETZT VERBINDEN" angegeben und die Verbindung zum Port "spice_console" überprüft.
Wenn die Verbindung für die festgelegte Anzahl von Versuchen fehlgeschlagen ist, wird der spice_console-Port zurück an clear.list übertragen. Die Ausführung von vm_connect.sh ist abgeschlossen. Die Ausführung von vm_manager.sh wird fortgesetzt, wodurch der Reinigungszyklus gestartet wird.
Wenn die Client Station eine Verbindung zum spice_console-Port auf der lo0-Schnittstelle herstellt, werden die Firewall-Regeln, die eine Umleitung zwischen dem Spice Server-Port und dem spice_console-Port erstellen, gelöscht, und die Verbindung wird durch einen Mechanismus zum Ermitteln des Status der Firewall weiter aufrechterhalten. Im Falle einer getrennten Verbindung schlägt die erneute Verbindung zum spice_console-Port fehl. Der spice_console-Port wird in die Datei "iar.list "übertragen. Die VM wird als fehlerhaft betrachtet und kann ohne Reinigung nicht in den Pool sauberer virtueller Maschinen zurückkehren. Die Ausführung von vm_connect.sh ist abgeschlossen, die Ausführung von vm_manager.sh wird fortgesetzt, wodurch der Reinigungszyklus gestartet wird.
Der Reinigungszyklus beginnt mit einem Blick auf die Datei wash.list, in die die spice_console-Nummern der Ports der virtuellen Maschine übertragen werden, zu denen die Verbindung hergestellt wird. Das Vorhandensein einer aktiven Verbindung wird an jedem spice_console-Port aus der Liste ermittelt. Wenn keine Verbindung besteht, wird davon ausgegangen, dass die virtuelle Maschine nicht mehr verwendet wird und der Port an recycle.list übertragen wird. Der Vorgang zum Löschen der virtuellen Maschine (siehe unten), zu der dieser Port gehört, wird gestartet. Wenn am Port eine aktive Netzwerkverbindung erkannt wird, wird davon ausgegangen, dass die virtuelle Maschine verwendet wird, und es werden keine Maßnahmen ergriffen. Wenn der Port nicht abgegriffen wird, wird davon ausgegangen, dass die VM ausgeschaltet ist und nicht mehr benötigt wird. Der Port wird an recycle.list übertragen und der Vorgang zum Entfernen der virtuellen Maschine wird gestartet. Dazu wird das Skript vm_delete.sh aufgerufen, an das die Nummer "spice_console" als Parameter an den VM-Port übertragen wird, der gelöscht werden muss.
/home/admin/scripts_vdi_new/vm_delete.sh Das Entfernen einer virtuellen Maschine ist eine ziemlich triviale Operation. Das Skript vm_delete.sh bestimmt den Namen der virtuellen Maschine, der der als Startparameter übergebene Port gehört. Die VM muss angehalten werden, die VM wird aus dem Hypervisor entfernt und die virtuelle Festplatte dieser VM wird gelöscht. Der spice_console-Port wird aus der recycle.list entfernt. Die Ausführung von vm_delete.sh wird beendet, die Ausführung von vm_manager.sh wird fortgesetzt
Das Skript vm_manager.sh startet am Ende der Vorgänge zum Bereinigen nicht benötigter virtueller Maschinen aus der Liste WASTE.list den Zyklus zum Erstellen virtueller Maschinen im Pool.
Der Prozess beginnt mit der Bestimmung der für das Hosting verfügbaren spice_console-Ports. Basierend auf dem Parameter der Konfigurationsdatei "srv_start_port_pool", der den Startport für den Pool "spice_console" virtueller Maschinen festlegt, und dem Parameter "srv_pool_size", der die Begrenzung der Anzahl virtueller Maschinen festlegt, werden alle möglichen Portvarianten nacheinander aufgelistet. Für jeden bestimmten Port wird in clear.list, WASte.list, conn_wait.list, recycle.list gesucht. Wenn in einer dieser Dateien ein Port gefunden wird, wird der Port als belegt betrachtet und übersprungen. Wenn der Port in den angegebenen Dateien nicht gefunden wird, wird er in die Datei recycle.list eingegeben und der Vorgang zum Erstellen einer neuen virtuellen Maschine beginnt. Dazu wird das Skript vm_create.sh aufgerufen, an das die spice_console-Nummer des Ports übergeben wird, für den Sie eine VM erstellen möchten.
/home/admin/scripts_vdi_new/vm_create.sh Der Prozess zum Erstellen einer neuen virtuellen Maschine
Das Skript vm_create.sh liest aus der Konfigurationsdatei den Wert der Variablen "base_host", die die virtuelle Beispielmaschine bestimmt, auf deren Grundlage der Klon erstellt wird. Es entlädt die XML-Konfiguration der VM aus der Hypervisor-Datenbank, führt eine Reihe von Überprüfungen des VM-Disk-Images durch und erstellt nach erfolgreichem Abschluss die XML-Konfigurationsdatei für die neue VM und das Disk-Image des verknüpften Klons der neuen VM. Danach wird die XML-Konfiguration der neuen VM in die Hypervisor-Datenbank geladen und die VM gestartet. Der spice_console-Port wird von recycle.list nach clear.list übertragen. Die Ausführung von vm_create.sh endet und die Ausführung von vm_manager.sh endet.
Wenn Sie das nächste Mal eine Verbindung herstellen, beginnt dies von vorne.
Für Notfälle enthält das Kit ein Skript vm_clear.sh, das alle VMs aus dem Pool zwangsweise durchläuft und sie entfernt, indem die Werte der Listen auf Null gesetzt werden. Wenn Sie es beim Laden aufrufen, können Sie VDI von Grund auf neu starten.
/home/admin/scripts_vdi_new/vm_clear.sh Damit möchte ich den ersten Teil meiner Geschichte beenden. Dies sollte für Systemadministratoren ausreichen, um underVDI im Geschäftsleben zu testen. Wenn die Community dieses Thema interessant findet, werde ich im zweiten Teil über die Modifikation von livecd Fedora und deren Umwandlung in einen Kiosk sprechen.