DE:Verbindungen

From i-doit documentation

i-doit Benutzerhandbuch 0.9.x:

Stromnetze

Um in i-doit Stromnetze darzustellen benötigt man verschiedene Arten von Stromobjekten. Zum einen gibt es eigenständige Objekte vom Objekttyp Stromobjekt, zum anderen gibt es untergeordnete Objekte in der Kategorie Verbraucher eines beliebigen Objekttyps der Infrastruktur.

Die eigenständigen Stromobjekte werden wiederum in verschiedene Typen unterteilt. Die untergeordneten Objekte in anderen Objekttypen (z.B. Server) sind dagegen immer vom Typ Verbraucher. Der Stromtyp eines Objektes kann nur einmal definiert und nicht wieder geändert werden. Jedes Stromobjekt hat in Abhängigkeit seines Typus entweder ein oder mehrere Eingänge (Stecker) oder Ausgänge (Buchsen) oder beides.

Es gibt folgende Typen und Eigenschaften:

Stromversorger haben Ausgänge
USV (Unterbrechungsfreie Stromversorgung) haben Eingänge und Ausgänge
Stromverteiler haben Eingänge und Ausgänge
Sicherungskästen haben Eingänge und Ausgänge
Verbraucher haben nur Eingänge

Die Eingänge und Ausgänge werden genutzt, um Stromobjekte untereinander zu verbinden. Jeder Eingang kann jeweils nur mit einem Ausgang verbunden werden und umgekehrt. Durch diese Verknüpfungen wird ein Stromnetz aufgebaut, dass sich von der Versorgung bis zum Verbraucher zieht. Zu den jeweiligen Stromobjekten können Leistungswerte (Volt, Watt und Ampere) definiert werden. An den Buchsen und Steckern können zusätzlich Sicherungen mit der dazugehörigen Amperezahl eingetragen werden, so dass bis ins Detail dokumentiert werden kann, wieviel (nominalen) Stromverbrauch Objekte haben und ob z.B. die Sicherungen dafür ausreichend sind.

Beispielnetz: <Excel Datei>

Datennetze

Für die Abbildung von Datennetzverbindungen wird in i-doit die Kategorie Netzwerk verwendet. Dabei handelt es sich um eine Allgemeine Kategorie, die also in gleicher Ausprägung bei Servern, Switches oder Routern zum Einsatz kommt. Um diesen verschiedenen Anwendungsfällen gerecht zu werden und gleichzeitig eine einzelne Zugriffsmethode beizubehalten, wird beim Netzwerkmodell von i-doit zwischen folgenden "Instanzen" unterschieden:

Interface: kann wörtlich genommen werden und beschreibt die eigentliche Schnittstelle. Sei sie onBoard oder als PCI-Kartenausführung beim Server oder ein Modul in Router oder Switch.

Ports: können in beliebiger Anzahl auf einem Interface angelegt werden und beschreiben die physikalischen Verbindungen zu einem Datennetz.

logisches Interface: wird wie eine virtuelle Schnittstelle behandelt und kann beliebige Ports des zugrunde liegenden Objekts logisch zusammen fassen.

Mit diesem Modell können nahezu alle netzseitigen Konfigurationen abgebildet werden. Damit wird aber die Dokumentation einer 1-Port-Netzwerkkarte in einem Server mit der jetzigen i-doit Version etwas aufwendiger ("Wizards" werden hier in den Folgeversionen Abhilfe schaffen), dafür kannn aber nach dem selben Vorgehen auch ein Multi-Slot-Chassis eines Switches dokumentiert werden.

Interfaces

Wenn man innerhalb eines Objektes die Kategorie Netzwerk anwählt, kommt man automatisch in die Ansicht der Interfaces. Bei der Neuanlage werden zunächst nur Basisdaten zum Modell abgefragt. Wenn ein Interface vorhanden ist, können Ports erstellt und einem Interface zugeordnet werden. Es handelt sich beim Interface also um eine Art Containerobjekt. Wie bereits angedeutet, bei der 1-Port-Netzwerkkarte macht diese Trennung zwischen Interface und Port eigentlich nur Aufwand. Aber schon bei einem zweiten Port auf einer Netzwerkkarte beginnt der Charme dieses Verfahrens.

Damit ist es möglich, modulare Switchsysteme "originalgetreu" in i-doit abzubilden. Für jeden belegten Slot wird ein Interface angelegt und dann jeweils auf diesen die Ports. Dieses Verfahren kann analog auf Router, WLAN-APs und sonstige Systeme mit einer Netzwerkschnittstelle angewandt werden.

Ports

Ports repräsentieren physische Netzwerkanschlüsse von Systemen. Sie werden innerhalb eines Interfaces angelegt und tragen verschiedene Verbindungsinformationen. Dabei kann z.B. festgelegt werden, um welche Art von Anschluss es sich handelt (LAN, WAN, WLAN, o.a.; dass ist wichtig für die "Verbindungsfähigkeit" von Ports). Bei der Neuanlage kann darüber hinaus die Anzahl der Ports festgelegt werden, die erzeugt werden sollen und es ist ein Interface anzugeben, dem die Ports zugeordnet werden. Daneben können verschiedene technische Parameter und eine Kabelbezeichnung gepflegt werden.

An dieser Stelle kann auch die Zuordnung zu einem Netz erfolgen. Was es damit auf sich hat, erläutert der übernächste Abschnitt. Als letzter wichtiger Aspekt eines Ports sind noch die "Eigenschaften" zu nennen, die einem Port zugeordnet werden können. Dabei handelt es sich um die gängigen Protokollvarianten (IP, IPX, AT), aber auch weitere Netzparameter wie QoS, WiFi, Routing oder STP-Varianten. Jede zugeordnete Eigenschaft kann nach der Porterstellung bearbeitet und mit den entsprechenden Daten versehen werden.

Ports werden automatisch nummeriert. Wählt man als Bezeichnung "FastEth" und lässt 12 Ports erstellen, wird die Bezeichnung von 1/12-12/12 durchnummeriert. Die Vorgaben zur Nummerierung sind statisch, sollen aber in einem zukünftigen Update anpassbar sein. Darüber hinaus wird die Slotnummer aus der Interface-Definition herangezogen.

Ein ersteller Port kann dann über die Bearbeitungsfunktion mit einem beliebigen anderen Port gleichen Anschlusstyps verbunden werden.

Logische Interfaces

Ein logisches Interface bietet eine Containerfunktion für Ports wie ein Interface, dabei aber die Ausprägung eines Ports. Damit werden Konfigurationen erfüllt, wo ein Port wie viele aussehen soll (z.B. 802.1q Port Trunking) oder wo viele Ports zu einem zusammen gefasst werden (EtherChannel, Port aggregation) oder virtuelle Netze (VLAN) abgebildet werden müssen.

Es können beliebig viele logische Interfaces auf einen oder mehrere Ports zeigen. Ein logisches Interface muss mindestens einen, kann aber auch beliebig viele Ports von beliebigen Interfaces aus dem zugrunde liegenden Objekt (z.B. Server) enthalten. Diese können dann entsprechend der Anforderungen mit Eigenschaften ausgeprägt werden. Wenden wir uns damit passenderweise dem Objekttyp Netz zu.

Netz

Der Objekttyp Netz kann über den Menüeintrag "Andere" erreicht werden. Ein Netzobjekt enthält allgemeingültige Informationen über eine logische Netzkonfiguration. Aufgrund der anzutreffenden Häufigkeit soll als Beispiel das IP-Protokoll herhalten. Neben Netz, Maske und Gateway können noch weitere Informationen zu DHCP und DNS gepflegt werden. Die Netzobjekte dienen in erster Linie als Hilfsmittel innerhalb der Netzwerkabbildung. Wie bereits oben dargestellt, können Netzobjekte entweder Ports und/oder logischen Interfaces zugeordnet werden.

Nehmen wir als Beispiel die Abbildung eines VLANs:

Innerhalb des betroffenen Switches wird in der Kategorie Netzwerk ein neues Interface erzeugt.
Im nächsten Schritt werden Ports erzeugt und dem zuvor erstellten Interface zugeordnet. Dabei werden den Ports keine zusätzlichen Eigenschaften mitgegeben.
Anschliessend wird ein logisches Interface erzeugt und die im zu dokumentierenden VLAN befindlichen Ports werden diesem zugeordnet. Sofern der Switch nicht mit einer eigenen IP-Adresse Teil des VLANs ist, reicht an dieser Stelle die Zuordnung zu einem zuvor erstellten Netzobjekt.
In gleicher Weise können weitere VLANs dokumentiert werden.

Lokaler Speicher

Wie bei allen Objekten in i-doit kann auch bei lokalem Speicher und Speichernetzen die Detailtiefe vom Benutzer selbst bestimmt werden. In Bezug auf Speicher und Speichernetze heisst dies insbesondere, dass alle im Folgenden dargestellten Abhängigkeiten eingetragen werden können, jedoch nicht eingetragen werden müssen. Mit der Konsequenz, dass man z.B. durchaus eine RAID Konfiguration abbilden kann ohne einen Controller einzutragen, oder man ein logisches Laufwerke eintragen kann ohne eine Festplatte angelegt zu haben.

Lokaler Speicher definiert sich durch Subobjekte der verschiedenen Speicherkategorien eines Objektes. Die Speicherkategorien sind wie folgt definiert:

Standardkategorien:

"Controller" sind Hardwarecontroller wie z.B. ATA, SATA, SCSI oder HBA Controller
"Geräte" stehen für Hardware Geräte, in erster Linie Festplatten, aber auch CD-Roms oder Diskettenlaufwerke
"Laufwerke" definieren logische Partitionen und ihre ggf. zugehörigen Laufwerke unter einem Betriebssystem

Sonderkategorien:

FC-Ports sind ähnlich Netzwerkports und dienen zur Verbindung von SAN-Storage
SAN-Pools sind logische Zusammenfassungen von Geräten, die als SAN-Pool anderen Servern zur Verfügung stehen

Standard Speicherkonfiguration

Um eine komplette Speicher-Konfiguration abzubilden, kann man nun der Reihe nach die ersten drei Kategorien füllen und miteinander verknüpfen. Die einzelnen Subobjekte können jeweils im Editiermodus miteinander verknüpft werden.

Beispiel:

SATA-Controller ("Controller") ---> Festplatte ("Gerät") ---> Laufwerk C: ("Laufwerk")

Hardware-RAID Speicherkonfiguration

Standardgeräte können so relativ einfach abgebildet werden. Für eine RAID Konfiguration wird es etwas komplizierter. Um ein Hardware-RAID abzubilden, muss zuerst ein Dummy-Subobjekt vom Typ Hardware-RAID-Gruppe in der Kategorie Geräte gebildet werden. Hier kann auch ein RAID-Level angegeben werden. Ist dieses Subobjekt erzeugt und abgespeichert, können einzelne Geräte (Festplatten) dieser Hardware-RAID-Gruppe zugeordnet werden.

Die komplette Hardware-RAID Darstellung ist zwar hierarchisch, geschieht aber komplett innerhalb der Kategorie Gerät.

Auch hier ein Beispiel:

Raid5-Gruppe ("Gerät") hat zugewiesen HD1 ("Gerät"), HD2 ("Gerät"), HD3 ("Gerät"), HD4 ("Gerät")

Zu beachten ist bei Hardware-RAID Konfigurationen nun, daß die Abhängigkeiten zum Controller wie bei einer Standardkonfiguration von den Festplatten ausgebildet werden, so ist z.B. HD1 - HD4 jeweils mit SATA-Controller (Controller) verbunden. Die Verknüpfung nach oben zum Laufwerk jedoch wird von der RAID-Gruppe dargestellt (Raid5-Gruppe (Gerät) ---> Laufwerk C: (Laufwerk). Komplett sieht das dann so aus:

SATA-RAID-Controller ("Controller") ---> HD1 ("Gerät"), HD2 ("Gerät"), HD3 ("Gerät"), HD4 ("Gerät") ---> 
Raid5-Gruppe ("Gerät") ---> Laufwerk C: ("Laufwerk").

Software-RAID Speicherkonfiguration

Software-RAID Konfigurationen werden in der Kategorie Laufwerke dargestellt. Der Mechanismus ist quasi genau wie wie bei Hardware-RAID Konfigurationen gestaltet. Es muss zunächst ein Dummy-Subobjekte vom Typ Software-RAID-Gruppe unter der Angabe des RAID-Levels angelegt werden, diesem können dann einzelne Laufwerke zugeordnet werden. Auch hier wird die ganze Software-RAID Logik nur innerhalb der Kategorie Laufwerk abgebildet.

RAID-Konfiguration allgemein

Bei sowohl der Hardware- als auch der Software-RAID Konfiguration gilt also, dass die Subobjekte vom Typ RAID wie ganz normale Subobjekte behandelt werden, es gibt also z.B. keinen Unterschied zwischen einer Festplatte und einer RAID-Gruppe. In Konsequenz bedeutet dies, daß auch RAID-Gruppen wiederum in andere RAID-Gruppen eingefügt werden können. So können jegliche Arten von Konfigurationen abgebildet werden.

Speichernetze

In diesem Kapitel wird beschrieben, wie in i-doit Storage Area Networks (SAN) und Network Attached Storage (NAS) dokumentiert werden können. SANs unterteilen sich wiederum in FibreChannel und IP-basierte (ISCSI und FCIP) Netze.

SAN

SAN-Systeme bestehen aus mehreren Komponenten. Zum einen gibt es den Objekttyp SAN, mit dem die eigentlichen SAN-Speichersysteme mit ihren Festplatten beschrieben werden. Dann gibt es noch den Objekttyp FC-Switch, der mehrere FibreChannel SAN-Objekte miteinander verbindet. Die Clientsysteme, die auf den SAN-Speicher zugreifen, benutzen dazu die Kategorie Controller und FC-Port unter der Kategorie Storage.

Beispiel: <Excel Datei>

Objekttyp "SAN"

Der Objekttyp SAN wird verwendet um SAN-Speichersysteme zu definieren, also meistens feste Systeme mit Festplattenarrays. Um den lokalen Speicher dieser Objekte zu definieren kann in einem SAN-Objekte wie gewohnt über die Kategorien "Controller", "Geräte" und "Laufwerke" Speicher (Festplatten) zugewiesen werden.

Kategorie "SAN-Pool"

Zusätzlich zu den normalen Storagekategorien hat ein SAN-Objekt die Kategorie SAN-Pool. Hier lassen sich SAN-Pools definieren, die den Client Systemen zur Verfügung gestellt werden. Da nicht nur SAN Hardwaresysteme im Einsatz sind sondern auch normale Server z.B. SAN-Storage zur Verfügung stellen können, ist die Kategorie SAN-Pool standardmässig auch im Objekttyp "Server" vertreten. Weil verschiedene SAN-System Hersteller verschiedene Arten von Zuordnungen von SAN-Pools an die eigentliche Hardware anbieten, wird in i-doit eine genaue Zuordnung zwischen dem SAN-Pool und den eingetragenen Festplatten nicht angeboten. Es kann auch ein SAN-Pool eingetragen werden ohne überhaupt lokalen Speicher an einem SAN-Objekt zu konfigurieren.

Der Zugriff von Clients auf SAN-Pools erfolgt über die Kategorie "Gerät" innerhalb eines Objektes, z.B. ein Server. Wie auch in Realität werden in i-doit SAN-Pools auf Clientsystemen wie lokale Geräte angelegt. In der Kategorie "Gerät" muss dazu ein Subobjekt vom Typ "SAN" erstellt werden, hier kann nun ein SAN-Pool verknüpft werden. Das gespeicherte Gerät ist in dem Objekt wie alle anderen Geräte ganz normal verfügbar, es kann also auch z.B. ein Laufwerk zugeordnet werden.

FC-SAN

FibreChannel SANs zeichnen sich dadurch aus, daß sie eine eigene Glasfaser Netzwerkinfrastruktur benutzen. Diese kann komplett in i-doit abgebildet werden.

Storage Controller Typ "FC" (HBA)

Die für Verbindungen in FC-SAN Netzen notwendigen Host-Bus-Adapter (HBA) sind nicht nur Netzwerkkarte, sondern gleichzeitig auch Storagecontroller und werden deswegen innerhalb von i-doit unter der Kategorie "Controller" definiert. Um einen HBA zu definieren muss ein neues Subobjekt in der Kategorie "Controller" vom Typ "FC" erstellt werden.

Kategorie "FC-Port"

FC-Ports verhalten sich ähnlich wie Netzwerkports. Sie zeichnen sich im wesentlichen durch zwei Eigenschaften aus. Zum einen sind sie zwingend einem Storagecontroller vom Typ "FC" innerhalb eines Objektes zugeordnet, zum anderen können sie mit einem beliebigen anderen Port eines anderen Objektes verbunden werden. Erstellt man ein neues Subobjekt in der Kategorie "FC-Port", muss vorher mindestens ein Controller vom Typ "FC" erstellt sein, damit der Port zugewiesen werden kann. Nach der Erstellung des Ports kann im Editiermodus ein beliebiger anderer FC-Port mit Hilfe des Port-Browsers verknüpft werden.

Objekttyp "FC-Switch"

FC-Switche sind Netzwerkswitche für FC-SANs. Um z.B. einen 24-Port FC-Switch anzulegen erstellt man ein neues Objekt "FC-Switch" und legt dort einen Storage-Controller vom Typ "FC" an. Anschließend erstellt man einfach 24 Subobjekte vom Typ "FC-Port" und ordnet diese dem Storage Controller zu (die 24-Ports lassen sich in einem Schritt erstellen). Jeder Port einzeln kann nun mit einem beliebigen anderen FC-Port verbunden werden, sei es mit einem HBA eines SAN-Systems oder mit dem HBA eines Serves, der auf SAN-Pools zugreifen will.

Beispiel FC-Netz

iSCSI/FCIP-SAN

iSCSI/FCIP Storage ist vom der Handhabung her einfacher als FC-SAN Netze, nur daß die Netzwerkverbindungen nicht extra definiert werden müssen. Da iSCSI/FCIP über IP kommuniziert, können zur Darstellung der Netzverbindungen die normale Netzwerkkategorien genutzt werden. Um mit iSCSI/FCIP SAN-Pools zu verbinden, kann einfach in der Kategorie "Controller" ein Subobjekt vom Typ "iSCSI/FCIP" erstellt werden. Dieser dient quasi als Dummy-Objekt. Es gibt keine feste Verknüpfung zwischen den "iSCSI/FCIP" Controllern und der Netzwerkkonfiguration, da eine direkte Zuordnung nicht möglich und sinnvoll ist. Ein SAN-Pool kann wie oben beschrieben einfach über die Erstellung eines Subobjektes vom Typ "SAN" in der Kategorie "Gerät" verknüpft werden.

NAS

NAS Systeme werden nicht explizit in i-doit dokumentiert, da sie eigentlich nichts anderes als Server mit eingeschränkten Diensten sind. Um ein NAS zu dokumentieren legt man einfach ein Objekt vom typ Server an und konfiguriert dort in den "Storage" Kategorien lokalen Speicher. Die Netzwerkkonfiguration kann wie gewohnt in den "Netzwerk" Kategorien dokumentiert werden.

Schnittstellen

-

Abhängigkeiten

Siehe Allgemeine Kategorie "Abhängigkeiten"