Druckprozesse in VDI-Umgebungen

Lesezeit
2 Minuten
Bis jetzt gelesen

Druckprozesse in VDI-Umgebungen

19.06.2013 - 00:00
Veröffentlicht in:

Das Konzept der Desktopvirtualisierung wird immer beliebter und birgt ein beachtliches Wachstumspotential in sich. Was vielen IT-Abteilungen in diesem Rahmen Kopfschmerzen bereitet, ist die Bereitstellung von Druckfunktionen in einer VDI-Umgebung. Wer verstehen will, wie sich das Thema virtualisierte Arbeitsplätze auf das Drucken und die Verwaltung der Druckertreiber auswirkt, muss sich die Wege der Druckprozesse und die Bereitstellung der Desktops anschauen. Genau dies tut unser Fachbeitrag.

Bei der Nutzung eines PCs geht der Druckweg vom PC direkt zum lokalen Drucker oder über den Printserver zum Netzwerkdrucker. In jedem Fall entsteht der Druckjob auf dem PC. Anders bei VDI. Hier entsteht der Druckjob immer auf dem virtuellen Desktop im Rechenzentrum. Und es entstehen meist längere Wege als bei der Nutzung des physischen Desktops, da die virtuellen Maschinen (VMs) alle zentral liegen. Sitzen die Benutzer nicht im gleichen Gebäude, in denen auch die Server stehen, muss ein Druckjob über WAN-Strecken transportiert werden. Da Druckjobs schnell die zehnfache Größe der Originaldatei erreichen, wird die Bandbreite des Netzwerks erheblich belastet.

Zusammenfassend lässt sich sagen, dass Druckjobs bei physischen Desktops eher im LAN, bei VDI eher im WAN, also über längere Entfernungen und bei schmalerer Bandbreite übertragen werden. Lösungen zur Komprimierung der Druckjobs und auch zur Bandbreitenkontrolle sind aus diesen Gründen ein Muss für VDI-Umgebungen. Ohne diese Maßnahmen gerät die Übermittlung der zur Arbeit nötigen Anwendungsdaten schnell ins Stocken. Arbeitsproduktivität und Usability leiden.

Die Bereitstellung und Verwaltung der Druckertreiber
Ein wichtiger Themenkomplex in VDI-Netzwerken bezieht sich auf die Bereitstellung von Druckertreibern. Häufig legen Administratoren aus Gründen der angestrebten Arbeitserleichterung für die IT und um Speicherplatz zu sparen ein Golden Image eines virtuellen Desktops für möglichst viele Nutzergruppen an. Aus diesem Pool bedienen sich die Anwender, wenn sie eine Session aufmachen. Individuelle Daten, wie Desktophintergrund und andere Profileinstellungen liegen in einem privaten Bereich.

Das Thema Drucken wird in diesem Szenario schnell zu einer zeitaufwändigen und nervtötenden Planungsprozedur. Dies liegt daran, dass die Bereitstellung der Druckertreiber anders zu regeln ist als beim Einsatz physischer Desktops. Bei der Nutzung eines PCs ohne Desktopvirtualisierung werden die Druckertreiber auf dem PC installiert. Das gilt für lokale Drucker genauso wie für die verbundenen Netzwerkdrucker. Alle Druckertreiber, die für das Arbeiten an diesem PC benötigt werden, sind also lokal vorhanden.

Auch bei virtuellen Desktops müssen die Treiber auf dem Desktop installiert werden. Doch im Gegensatz zu dem PC-Szenario werden hier viele Mitarbeiter quasi den identischen virtualisierten PC erhalten. Müssen hier also auch alle Druckertreiber für alle Mitarbeiter an ihren verschiedenen Arbeitsplätzen lokal vorhanden sein? Es gibt mehrere Möglichkeiten, wie der Administrator in diesem Fall die Druckertreiber zur Verfügung stellen kann:

  1. Installation aller Treiber in dem Pool von Golden Images: Die ist eine sehr aufwändige Art, Druckertreiber in virtualisierten Desktopumgebungen zur Verfügung zu stellen. Wird ein Drucker ausgetauscht oder kommt ein neuer hinzu, muss vollständig nachinstalliert werden. Ebenso bei Updates. In großen, heterogenen Umgebungen wird das Image damit unnötig vergrößert.
     
  2. Installation der Treiber im Personal Space des Mitarbeiters: Mit dieser Methode kann der Anwender zwar das zentrale Template nutzen, aber mit den entsprechenden Treibern wird er über den Personal Space versorgt. Dieser Personal Space liegt – wie der virtualisierte Desktop – im Rechenzentrum. Und hier ist auch schon der Haken an dieser Art der Lösung. Ganz gewöhnliche Druckertreiber erreichen auch schnell Größen von über 70 MByte. In Anbetracht der Tatsache, dass bei diesem Lösungsansatz jeder Mitarbeiter in seinem Personal Space mehrere Treiber benötigt, wird deutlich, dass auch dies nicht die favorisierte Lösung sein kann. Die Absicht, durch VDI die Kosten zu senken, würde so schnell ad absurdum geführt.
     
  3. Installation der Druckertreiber per Point and Print: Die dritte Möglichkeit ist, bei jeder Session per Point and Print die Treiber neu installieren zu lassen. Dieser Prozess wiederholt sich quasi bei jedem Anfang einer Sitzung. Doch auch hier gibt es einen gravierenden Nachteil: Alle Einstellungen, die der Nutzer vornimmt, gehen bei Beendung der Sitzung wieder verloren und sind jedes Mal neu vorzunehmen.

 


 

 

                                                Seite 1 von 2                     Nächste Seite>>






Charlotte Künzell, CIO bei der Cortado AG/ln

 

 

 

Ähnliche Beiträge

Netzwerkverwaltung an der Medizinischen Universität Wien

Die IT-Abteilung der Medizinischen Universität Wien betreibt das Netzwerk der Universität, wozu die Betreuung von rund 10.000 Anschlüssen sowie Hunderten Endgeräten und Servern gehört. Für diese Aufgabe wurde eine neue Informations- und Planungssoftware für Kabelmanagement und Netzwerkdokumentation implementiert. Das neue Werkzeug ist flexibel, skalierbar und deckt die steigenden Sicherheitsanforderungen voll ab.

Im Test: Sunbird DCIM

Das DCIM-Werkzeug Sunbird verspricht die umfassende Verwaltung von Assets im Rechenzentrum mit vielen nützlichen Funktionen, ansprechender Oberfläche und maximalem Komfort. Dies gelingt mit der Software auch in geografisch verteilten Landschaften. Dabei liefert Sunbird wertvolle Daten zum Zustand und Energieverbrauch, und schafft somit einen guten Einblick in das RZ-Geschehen.

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (3)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Im Gegensatz dazu kommen diese Prozesse bei aktiven Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im dritten und letzten Teil gehen wir auf weitere Varianten ein, etwa die ZTP-Provisionierung ohne proprietären Server, die Boot-Loader-Variante iPXE oder das alte Verfahren AutoInstall.