von In diesem zweiten Artikel aus der Serie „Netzwerk dokumentieren mit einfachen Mitteln“ zeige ich, wie ich die Endgeräte in der bestehenden Dokumentation darstelle.
Server und virtuelle Server
Grundsätzlich würde ich für die Darstellung von Virtualisierungsservern in Visio das Symbol für „Anwendungsserver“ verwenden. Die „gestapelten“ Server fand ich immer recht passend um die Virtualisierung zu symbolisieren. Um die auf dem Server befindlichen Server darzustellen, würde ich diese ebenfalls wieder, wie schon das Netzwerk, in einer Box bzw. in einem Kasten darstellen. Um das ganze etwas besser von einem Netzwerk unterscheidbar zu machen, nutze für den Kasten eine gestrichelte Linie. Je nach Umfang und Anzahl der Virtualisierungsserver kann es Sinn machen, in der Überschrift des Kastens bereits die Information unter zu bringen, auf welchem Server sich die virtuellen Maschinen befinden oder diesen direkt beim Virtualisierungsserver zu positionieren:
Sofern der Hauptdienst bzw. Einsatzzweck des Servers nicht bereits durch den Servernamen hervorgeht, würde ich diesen noch unter die IP-Adresse und die Betriebssystem-Version schreiben. Im Beispiel des WSUS erübrigt sich dies beispielsweise, außer man nimmt es ganz genau und schreibt dann noch „Windows Server Update Services“ noch drunter. Hier macht meiner Meinung nach aber lediglich die Angabe des Windows Servers Sinn. Ob man bei diesem Server auch noch angeben sollte, dass dort der IIS läuft dürfte Geschmackssache sein, da die WSUS-Rolle den IIS ja zwingend für die WSUS-Funktionalität nutzt. Hier muss man für sich entscheiden wie detailreich man das ganze angeht. Solche logischen Abhängigkeiten wie im Fall des WSUS würde ich aber, auch aus Platzmangel, nicht komplett aufbröseln. Sicherlich könnte man sonst bei dem anderen Beispiel auch den Apache weglassen wenn dieser für die Bereitstellung des SVNs genutzt wird. Allerdings macht es hier wiederum mehr Sinn diesen anzugeben, denn soweit ich weiß ist es z. B. auch möglich das SVN mit Hilfe eines nginx-Webservers bereit zu stellen.
Nun kann man noch überlegen, ob es Sinn macht der Funktion entsprechende Server-Icons zu verwenden. Es gibt z. B. das Icon für Webserver. Dann sähe das z. B. so aus wie rechts abgebildet. Allerdings macht auch dies meiner Meinung nach aus dem gleichen Grund keinen Sinn, wie ich es zuvor beim WSUS erwähnt habe. Denn der Server soll ja in seiner Hauptaufgabe nicht als ein Webserver dienen. Dass er auch einen Webserver beinhaltet ist in den gezeigten Fällen nur eine „Nebenaufgabe“ die nötig ist, damit der Hauptzweck erfüllt werden kann. Theoretisch wäre zumindest der WSUS sonst auch ein Datenbankserver, da hier eine MS-SQL-ähnliche interne Datenbank läuft und auch das SVN ist irgendwo mehr oder weniger eine Datenbank, wenn auch keine SQL-Datenbank.
Deshalb würden diese Icons, meiner Meinung nach, nur Sinn machen wenn es sich z. B. um einen reinen Webserver handelt, der beispielsweise die Unternehmenswebseite bereitstellt. Allerdings würde ich das Icon auch benutzen, wenn es sich um einen LAMP-Server handelt, da die dann vorhandene Datenbank wiedrrum nur dem Webserver dient.
Client-Systeme
Sofern keine unterschiedlichen Konfigurationen der Client-Computer vorliegen, würde ich es mir meistens sehr einfach machen und die Client-Computer z. B. so zusammenfassen:
Bei unterschiedlichen Konfigurationen, z. B. für verschiedene Abteilungen, würde ich das dann entsprechend pro Abteilung zusammenfassen oder weiter aufsplitten. Sofern aber nur auf Terminalservern gearbeitet wird sind die Clients eher nebensächlich.
Im nächsten Teil geht es dann um Peripheriegeräte und Sondergeschichten.
