Rechtstexte, FinalFlux-Überarbeitung, neue Login-Optik, Konto-Löschung-Fix, BTTF-Farbrelaunch
- Rechtsseiten: Impressum-Platzhalter + echte Nutzungsbedingungen/AGB, Datenschutz (DSGVO) und Richtlinien; LegalController/ImpressumController, Footer app-weit verlinkt, Seiten als permitAll freigegeben. - FinalFlux: 28 Themen / ~742 Fragen überarbeitet (plausible Distraktoren statt Dummy-Antworten, echte Erklärungen) + echte Lehrtexte je Seite; Netzwerktopologien mit Inline-SVG-Diagrammen (Stern/Bus/Ring/Mesh/Baum). - Login/Registrierung als kombiniertes Dual-Panel (Slide-Overlay + Neon-Hover- Button), ausgelagert nach auth.css; Register-Duplikat -> /?registerError. - Konto löschen repariert: @Transactional + Löschen von Spielständen, Achievements und Profilbild-Datei (DSGVO Art. 17). Impressum-Zurück-Link login-abhängig. - App-weiter Farb-Relaunch auf "Back to the Future"-Palette: Feuer-Amber primär + Flux-Blau sekundär, warmer Glow; Dark/Light bleiben. Spiele-Feedback ohne Grün: richtig = Blau + Haken, falsch = Rot + Kreuz (neue Tokens --success/--danger/--secondary). Legacy-Cyan in style.css auf Variablen. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
AliceDarkest
@@ -15,13 +15,103 @@
|
||||
<a href="/finalflux" class="back-link">Zurück zu FinalFlux</a>
|
||||
<h1>Backuparten</h1>
|
||||
|
||||
<section>
|
||||
<h2>Warum Datensicherung?</h2>
|
||||
<p>
|
||||
Ein <strong>Backup</strong> ist eine zusätzliche Kopie wichtiger Daten, mit der man
|
||||
nach Hardwaredefekten, Bedienfehlern, Schadsoftware oder Diebstahl den Datenbestand
|
||||
wiederherstellen kann. Das Zurückspielen dieser Kopie heißt <strong>Restore</strong>.
|
||||
Entscheidend ist: Ein Backup ist erst dann wirklich vorhanden, wenn die Wiederherstellung
|
||||
auch getestet wurde. Ungetestete Sicherungen sind im Ernstfall oft wertlos.
|
||||
</p>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Kein Backup ohne erfolgreichen Restore-Test.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Voll, differentiell, inkrementell</h2>
|
||||
<p>
|
||||
Die drei Sicherungsarten unterscheiden sich darin, <em>was</em> gesichert wird und
|
||||
<em>worauf</em> sie sich beziehen. Daraus ergeben sich Unterschiede bei Speicherbedarf,
|
||||
Sicherungsdauer und Restore-Aufwand.
|
||||
</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Vollbackup:</strong> alle Daten. Einfaches Restore, hoher Speicherbedarf.</li>
|
||||
<li><strong>Differentiell:</strong> alles seit dem letzten Vollbackup. Restore: Vollbackup + letztes differentielles Backup.</li>
|
||||
<li><strong>Inkrementell:</strong> nur Änderungen seit dem letzten Backup. Spart Speicher, Restore braucht die Kette.</li>
|
||||
<li><strong>Vollbackup:</strong> sichert alle ausgewählten Daten. Hoher Speicherbedarf
|
||||
und lange Sicherungsdauer, dafür einfachster Restore (nur ein Stand nötig).</li>
|
||||
<li><strong>Differentielles Backup:</strong> sichert alle Änderungen seit dem
|
||||
<em>letzten Vollbackup</em>. Die Sicherungen wachsen bis zum nächsten Vollbackup an.
|
||||
Restore = Vollbackup + letztes differentielles Backup.</li>
|
||||
<li><strong>Inkrementelles Backup:</strong> sichert nur die Änderungen seit der
|
||||
<em>letzten Sicherung</em> (egal ob voll oder inkrementell). Sehr sparsam und schnell,
|
||||
aber der Restore braucht das Vollbackup plus die komplette Kette aller inkrementellen
|
||||
Sicherungen.</li>
|
||||
</ul>
|
||||
<p>
|
||||
<strong>Beispiel (Woche):</strong> Sonntag ein Vollbackup, Montag bis Samstag täglich eine
|
||||
Teilsicherung. Bei <em>differentiell</em> enthält jede Sicherung alles seit Sonntag (sie
|
||||
wird Tag für Tag größer), der Restore von Donnerstag braucht nur Sonntag + Donnerstag.
|
||||
Bei <em>inkrementell</em> sichert jeder Tag nur die Änderungen zum Vortag (kleine, schnelle
|
||||
Sicherungen), der Restore von Donnerstag braucht aber Sonntag + Montag + Dienstag +
|
||||
Mittwoch + Donnerstag.
|
||||
</p>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Inkrementell spart beim Sichern,
|
||||
differentiell spart beim Restore.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Generationenprinzip (Großvater-Vater-Sohn)</h2>
|
||||
<p>
|
||||
Das <strong>Generationenprinzip</strong> staffelt Sicherungen über mehrere Zeitebenen,
|
||||
damit man auf verschieden alte Stände zurückgreifen kann und nicht nur den neuesten besitzt.
|
||||
</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Sohn:</strong> tägliche Sicherung, kurze Aufbewahrung.</li>
|
||||
<li><strong>Vater:</strong> wöchentliche Sicherung, mittlere Aufbewahrung.</li>
|
||||
<li><strong>Großvater:</strong> monatliche Sicherung, lange Aufbewahrung.</li>
|
||||
</ul>
|
||||
<p>
|
||||
So lassen sich auch ältere Fehler korrigieren, die erst spät auffallen, etwa eine vor zwei
|
||||
Wochen versehentlich gelöschte Datei. Medien werden dabei rotiert und wiederverwendet.
|
||||
</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Die 3-2-1-Regel</h2>
|
||||
<p>
|
||||
Die <strong>3-2-1-Regel</strong> ist eine einfache Faustregel gegen Datenverlust:
|
||||
</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>3</strong> Kopien der Daten (Original + 2 Sicherungen),</li>
|
||||
<li><strong>2</strong> unterschiedliche Speichermedien/-typen (z. B. Festplatte und Band oder Cloud),</li>
|
||||
<li><strong>1</strong> Kopie an einem externen Ort (außer Haus oder offline).</li>
|
||||
</ul>
|
||||
<p>
|
||||
Die externe bzw. getrennte Kopie schützt vor Ereignissen, die den Standort treffen
|
||||
(Brand, Diebstahl, Überspannung) oder das gesamte Netz erfassen (Ransomware). Besonders
|
||||
wirksam gegen Ransomware sind <em>unveränderliche</em> (immutable) oder vollständig
|
||||
vom Netz getrennte Sicherungen.
|
||||
</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>RPO und RTO</h2>
|
||||
<p>
|
||||
Zwei Kennzahlen steuern, wie ein Backup-Konzept ausgelegt sein muss:
|
||||
</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>RPO (Recovery Point Objective):</strong> maximal tolerierbarer
|
||||
<em>Datenverlust</em>, gemessen als Zeitspanne. Er bestimmt den Sicherungsabstand:
|
||||
Bei RPO = 1 Stunde muss mindestens stündlich gesichert werden.</li>
|
||||
<li><strong>RTO (Recovery Time Objective):</strong> maximal tolerierbare
|
||||
<em>Ausfall-/Wiederherstellungszeit</em>. Er bestimmt, wie schnell ein System nach
|
||||
einem Ausfall wieder laufen muss.</li>
|
||||
</ul>
|
||||
<p>
|
||||
<strong>Eselsbrücke:</strong> RP<u>O</u> blickt nach hinten (Wie viele Daten darf ich
|
||||
verlieren?), RT<u>O</u> blickt nach vorn (Wie lange darf der Ausfall dauern?).
|
||||
</p>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> RPO = Datenverlust in Zeit,
|
||||
RTO = Ausfalldauer. Beide leiten sich aus dem Geschäftsrisiko ab und bestimmen die
|
||||
Backup-Strategie.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
|
||||
@@ -25,6 +25,74 @@
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Relationale Datenbank: Tabellen und Datensätze</h2>
|
||||
<p>Eine <strong>relationale Datenbank</strong> speichert Daten in <strong>Tabellen</strong> (auch Relationen genannt). Jede Tabelle besteht aus Zeilen und Spalten und enthält gleichartige Informationen, zum Beispiel eine Tabelle für Kunden und eine weitere für Bestellungen. Verwaltet wird das Ganze von einem <strong>DBMS</strong> (Datenbankmanagementsystem) wie MySQL, MariaDB oder PostgreSQL.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Tabelle (Relation):</strong> strukturiert Daten in Zeilen und Spalten.</li>
|
||||
<li><strong>Datensatz (Zeile/Tupel):</strong> beschreibt genau ein Objekt, z. B. einen Kunden.</li>
|
||||
<li><strong>Attribut (Spalte/Feld):</strong> beschreibt eine Eigenschaft, z. B. <em>Nachname</em>.</li>
|
||||
<li><strong>DBMS:</strong> Software, die Daten, Zugriffe, Transaktionen und Rechte verwaltet.</li>
|
||||
</ul>
|
||||
<p>Beispiel einer Tabelle <em>Kunde</em>: Spalten <em>KundenID</em>, <em>Name</em>, <em>Ort</em>; eine Zeile wie <code>(1, "Meier", "Köln")</code> ist ein Datensatz.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Primär- und Fremdschlüssel</h2>
|
||||
<p>Schlüssel sorgen dafür, dass Datensätze eindeutig sind und Tabellen sauber miteinander verknüpft werden können.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Primärschlüssel (PK):</strong> identifiziert jeden Datensatz einer Tabelle <em>eindeutig</em>, ist nie leer (NULL) und kommt nur einmal vor, z. B. <em>KundenID</em>.</li>
|
||||
<li><strong>Fremdschlüssel (FK):</strong> verweist auf den Primärschlüssel einer <em>anderen</em> Tabelle und stellt so die Beziehung her, z. B. <em>KundenID</em> in der Tabelle <em>Bestellung</em>.</li>
|
||||
</ul>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Der Primärschlüssel <em>identifiziert</em> innerhalb der eigenen Tabelle, der Fremdschlüssel <em>verweist</em> auf eine andere Tabelle.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Beziehungstypen: 1:1, 1:n, n:m</h2>
|
||||
<p>Zwischen Tabellen bestehen Beziehungen, deren Typ beschreibt, wie viele Datensätze einander zugeordnet werden können.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>1:1</strong> – ein Datensatz gehört zu genau einem anderen, z. B. Mitarbeiter und Dienstausweis.</li>
|
||||
<li><strong>1:n</strong> – ein Datensatz gehört zu mehreren, z. B. ein Kunde hat viele Bestellungen (der häufigste Fall).</li>
|
||||
<li><strong>n:m</strong> – viele zu vielen, z. B. Schüler und Kurse; wird über eine <strong>Zwischentabelle</strong> in zwei 1:n-Beziehungen aufgelöst.</li>
|
||||
</ul>
|
||||
<p>Umgesetzt werden Beziehungen über Fremdschlüssel: Bei 1:n steht der Fremdschlüssel auf der „n-Seite".</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Normalisierung (1.–3. Normalform)</h2>
|
||||
<p>Die <strong>Normalisierung</strong> zerlegt Tabellen so, dass <strong>Redundanz</strong> (mehrfache Speicherung) und daraus folgende <strong>Inkonsistenzen</strong> vermieden werden.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>1. NF:</strong> Alle Werte sind atomar (unteilbar) – keine Listen oder Mehrfachwerte in einem Feld.</li>
|
||||
<li><strong>2. NF:</strong> 1. NF erfüllt und jedes Nichtschlüsselattribut hängt <em>voll</em> vom gesamten Primärschlüssel ab (relevant bei zusammengesetzten Schlüsseln).</li>
|
||||
<li><strong>3. NF:</strong> 2. NF erfüllt und keine <em>transitiven</em> Abhängigkeiten – Nichtschlüsselattribute hängen nur vom Schlüssel ab, nicht voneinander.</li>
|
||||
</ul>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> „Der Schlüssel, der ganze Schlüssel und nichts als der Schlüssel" – atomar (1. NF), ganzer Schlüssel (2. NF), nur der Schlüssel (3. NF).</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>SQL-Grundbefehle</h2>
|
||||
<p>Mit <strong>SQL</strong> (Structured Query Language) werden Daten abgefragt und verändert. Die wichtigsten Befehle für die AP1:</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>SELECT</strong> – liest Daten aus Tabellen (<code>SELECT * FROM Kunde WHERE Ort = 'Köln';</code>).</li>
|
||||
<li><strong>INSERT</strong> – fügt neue Datensätze ein.</li>
|
||||
<li><strong>UPDATE</strong> – ändert bestehende Datensätze (meist mit <code>WHERE</code>).</li>
|
||||
<li><strong>DELETE</strong> – löscht Datensätze (ohne <code>WHERE</code> die ganze Tabelle!).</li>
|
||||
<li><strong>WHERE</strong> – filtert nach Bedingungen; <strong>JOIN</strong> – verknüpft Tabellen über Schlüssel.</li>
|
||||
</ul>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> SELECT liest, INSERT legt an, UPDATE ändert, DELETE entfernt.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>ACID und Transaktionen</h2>
|
||||
<p>Eine <strong>Transaktion</strong> fasst mehrere Datenbankoperationen zu einer logischen Einheit zusammen, die nur ganz oder gar nicht ausgeführt wird (z. B. eine Überweisung). Verlässliche Transaktionen erfüllen die <strong>ACID</strong>-Eigenschaften:</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Atomicity (Atomarität):</strong> alles oder nichts – bei einem Fehler wird zurückgesetzt (Rollback).</li>
|
||||
<li><strong>Consistency (Konsistenz):</strong> die Datenbank bleibt in einem gültigen, regelkonformen Zustand.</li>
|
||||
<li><strong>Isolation:</strong> parallele Transaktionen beeinflussen sich nicht.</li>
|
||||
<li><strong>Durability (Dauerhaftigkeit):</strong> bestätigte Änderungen bleiben auch nach einem Ausfall erhalten.</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Prüfungsmodus</h2>
|
||||
<p>Dieser FluxCheck führt dich durch die wichtigsten AP1-Aspekte dieses Themas. Du kannst Antworten prüfen, Fragen überspringen und bekommst am Ende eine Auswertung nach Kategorie.</p>
|
||||
|
||||
@@ -25,6 +25,50 @@
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Was ist DSL?</h2>
|
||||
<p>DSL (Digital Subscriber Line) überträgt Daten über die vorhandene zweiadrige Kupfer-Telefonleitung. Telefonie nutzt nur einen schmalen Frequenzbereich; DSL legt die Daten in höhere, ungenutzte Frequenzen. Dadurch lassen sich Telefon und Internet gleichzeitig über dieselbe Leitung betreiben.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Download</strong>: Datenrate vom Internet zum Kunden (Empfangen).</li>
|
||||
<li><strong>Upload</strong>: Datenrate vom Kunden ins Internet (Senden).</li>
|
||||
<li><strong>Bandbreite</strong>: maximal mögliche Datenrate, meist in Mbit/s.</li>
|
||||
<li><strong>Latenz</strong>: Zeitverzögerung (Ping in ms), unabhängig von der Bandbreite.</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>DSL-Varianten</h2>
|
||||
<p>Die Varianten unterscheiden sich vor allem im Verhältnis von Down- zu Upload und in der erreichbaren Geschwindigkeit.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>ADSL (asymmetrisch)</strong>: hoher Download, kleiner Upload. Gut für klassisches Surfen und Streaming, schwächer beim Hochladen (z. B. Cloud-Backup).</li>
|
||||
<li><strong>SDSL (symmetrisch)</strong>: Download und Upload gleich groß. Sinnvoll für Server, VPN und viel Datenversand, typisch im Geschäftsumfeld.</li>
|
||||
<li><strong>VDSL (Very High Speed)</strong>: deutlich schneller als ADSL, oft mit Glasfaser bis zum Verteiler (FTTC) und nur dem letzten Stück Kupfer.</li>
|
||||
</ul>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> A wie <em>asymmetrisch</em> (ADSL), S wie <em>symmetrisch</em> (SDSL), V wie <em>viel schneller</em> (VDSL).</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Splitter und DSLAM</h2>
|
||||
<p>Zwei Geräte werden in der Prüfung gern verwechselt - sie sitzen an entgegengesetzten Enden der Leitung:</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Splitter</strong>: steht beim Kunden am Hausanschluss und trennt das Telefonsignal vom DSL-Signal. (Bei reinen IP-Anschlüssen entfällt er.)</li>
|
||||
<li><strong>DSLAM</strong>: steht beim Provider in der Vermittlungsstelle bzw. am Straßenverteiler und bündelt viele DSL-Leitungen, um sie ins Providernetz zu führen.</li>
|
||||
<li><strong>Modem/Router</strong>: das Modem wandelt das Leitungssignal um, der Router verbindet das Heimnetz mit dem Internet (oft in einem Gerät vereint).</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Was bremst die Geschwindigkeit?</h2>
|
||||
<p>Die tatsächliche Datenrate liegt oft unter dem Vertragswert. Entscheidend ist die Qualität der Kupferstrecke bis zum DSLAM:</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Leitungslänge</strong>: Je weiter es bis zur Vermittlungsstelle/zum Verteiler ist, desto geringer die mögliche Geschwindigkeit.</li>
|
||||
<li><strong>Dämpfung</strong>: Das Signal wird über die Strecke schwächer; hohe Dämpfung senkt die erreichbare Bandbreite.</li>
|
||||
<li><strong>Störungen/Rauschen</strong>: Schlechte Leitungen verursachen Paketverlust und Verbindungsabbrüche.</li>
|
||||
<li><strong>WLAN</strong>: Funkprobleme im Haus sind kein DSL-Anschlussfehler - immer per Kabel gegenprüfen.</li>
|
||||
</ul>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Mehr Leitungslänge bedeutet mehr Dämpfung - und damit weniger Geschwindigkeit.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Prüfungsmodus</h2>
|
||||
<p>Dieser FluxCheck führt dich durch die wichtigsten AP1-Aspekte dieses Themas. Du kannst Antworten prüfen, Fragen überspringen und bekommst am Ende eine Auswertung nach Kategorie.</p>
|
||||
|
||||
@@ -16,18 +16,102 @@
|
||||
<h1>OSI-Modell</h1>
|
||||
|
||||
<section>
|
||||
<h2>Die 7 Schichten</h2>
|
||||
<h2>Was ist das OSI-Modell?</h2>
|
||||
<p>
|
||||
Das OSI-Modell (Open Systems Interconnection) ist ein Referenzmodell, das
|
||||
die Kommunikation in Netzwerken in <strong>sieben aufeinander aufbauende
|
||||
Schichten</strong> gliedert. Jede Schicht hat eine klar abgegrenzte Aufgabe
|
||||
und nutzt die Dienste der darunterliegenden Schicht. Das Modell ist kein
|
||||
Produkt, sondern eine gedankliche Ordnung: Es hilft, Geräte, Protokolle und
|
||||
Fehler systematisch einzuordnen.
|
||||
</p>
|
||||
<p>
|
||||
Beim Senden wandern die Daten von oben (Anwendung) nach unten
|
||||
(Bitübertragung) und werden dabei <strong>gekapselt</strong> – jede
|
||||
Schicht ergänzt einen eigenen Header. Beim Empfänger läuft es umgekehrt: Die
|
||||
Daten werden Schicht für Schicht wieder ausgepackt (entkapselt).
|
||||
</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Die 7 Schichten und ihre Aufgaben</h2>
|
||||
<ol class="key-list">
|
||||
<li>Bitübertragung: Kabel, Funk, elektrische Signale.</li>
|
||||
<li>Sicherung: MAC-Adressen, Frames, Switches.</li>
|
||||
<li>Vermittlung: IP-Adressen, Routing.</li>
|
||||
<li>Transport: TCP, UDP, Ports.</li>
|
||||
<li>Sitzung: Verbindungen steuern.</li>
|
||||
<li>Darstellung: Formate, Kodierung, Verschlüsselung.</li>
|
||||
<li>Anwendung: HTTP, DNS, SMTP und andere Dienste.</li>
|
||||
<li><strong>Schicht 1 – Bitübertragung:</strong> physische Übertragung roher Bits über Kabel, Glasfaser oder Funk. Geräte: Kabel, Hub, Repeater.</li>
|
||||
<li><strong>Schicht 2 – Sicherung:</strong> fehlerfreie Übertragung im lokalen Netz, Adressierung über MAC-Adressen. Geräte: Switch, Bridge. Stichworte: Frames, VLAN.</li>
|
||||
<li><strong>Schicht 3 – Vermittlung:</strong> logische Adressierung und Wegewahl (Routing) zwischen Netzen. Gerät: Router. Protokolle: IP, ICMP.</li>
|
||||
<li><strong>Schicht 4 – Transport:</strong> Ende-zu-Ende-Verbindung zwischen Anwendungen, Unterscheidung über Ports. Protokolle: TCP (zuverlässig), UDP (schnell).</li>
|
||||
<li><strong>Schicht 5 – Sitzung:</strong> Auf-, Abbau und Steuerung von Sitzungen und Dialogen zwischen Systemen.</li>
|
||||
<li><strong>Schicht 6 – Darstellung:</strong> Datenformate, Zeichencodierung (z. B. UTF-8), Kompression und Verschlüsselung (z. B. TLS).</li>
|
||||
<li><strong>Schicht 7 – Anwendung:</strong> Schnittstelle zu den Anwendungen. Protokolle: HTTP, HTTPS, DNS, SMTP, FTP.</li>
|
||||
</ol>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>PDUs – Wie heißen die Daten je Schicht?</h2>
|
||||
<p>
|
||||
Die Daten heißen auf jeder Schicht anders. Diese Protokoll-Dateneinheiten
|
||||
(PDU) werden in AP1 gern abgefragt:
|
||||
</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Schicht 1:</strong> Bit</li>
|
||||
<li><strong>Schicht 2:</strong> Frame (Rahmen)</li>
|
||||
<li><strong>Schicht 3:</strong> Paket</li>
|
||||
<li><strong>Schicht 4:</strong> Segment (TCP) bzw. Datagramm (UDP)</li>
|
||||
<li><strong>Schicht 5–7:</strong> Daten</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Geräte und Protokolle richtig zuordnen</h2>
|
||||
<p>
|
||||
Die häufigste Verwechslung betrifft Schicht-Nummern. Diese Zuordnungen
|
||||
sollten sitzen:
|
||||
</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Hub / Repeater → Schicht 1</strong> (nur Signalverstärkung)</li>
|
||||
<li><strong>Switch → Schicht 2</strong> (entscheidet anhand der MAC-Adresse)</li>
|
||||
<li><strong>Router → Schicht 3</strong> (entscheidet anhand der IP-Adresse)</li>
|
||||
<li><strong>MAC-Adresse = Schicht 2, IP-Adresse = Schicht 3, Port = Schicht 4</strong></li>
|
||||
<li><strong>TCP/UDP = Schicht 4, HTTP/DNS/SMTP = Schicht 7</strong></li>
|
||||
</ul>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Von unten nach oben – <em>„Alle deutschen Studenten trinken verschiedene Sorten Bier“</em> (Anwendung, Darstellung, Sitzung, Transport, Vermittlung, Sicherung, Bitübertragung).</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Abgrenzung zum TCP/IP-Modell</h2>
|
||||
<p>
|
||||
In der Praxis wird oft das schlankere TCP/IP-Modell mit nur
|
||||
<strong>vier Schichten</strong> verwendet. Es fasst mehrere OSI-Schichten
|
||||
zusammen:
|
||||
</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Netzzugang</strong> entspricht OSI-Schicht 1–2</li>
|
||||
<li><strong>Internet</strong> entspricht OSI-Schicht 3 (IP)</li>
|
||||
<li><strong>Transport</strong> entspricht OSI-Schicht 4 (TCP/UDP)</li>
|
||||
<li><strong>Anwendung</strong> entspricht OSI-Schicht 5–7</li>
|
||||
</ul>
|
||||
<p>
|
||||
OSI ist das theoretische Lern- und Analysemodell, TCP/IP das real im
|
||||
Internet eingesetzte Modell.
|
||||
</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Fehleranalyse nach OSI</h2>
|
||||
<p>
|
||||
Bei Netzwerkproblemen prüft man typischerweise <strong>von unten nach
|
||||
oben</strong> (bottom-up): Erst die physische Verbindung, dann die
|
||||
Konfiguration, zuletzt die Anwendung.
|
||||
</p>
|
||||
<ul class="key-list">
|
||||
<li>Keine Link-LED → Schicht 1: Kabel, Port, Stecker prüfen.</li>
|
||||
<li>Link da, aber keine IP → Schicht 3: IP-Adresse, Gateway, DHCP.</li>
|
||||
<li>Ping auf IP ok, Name nicht → Schicht 7: DNS-Auflösung.</li>
|
||||
<li>Ping ok, aber Dienst nicht erreichbar → Schicht 4: Port/Firewall.</li>
|
||||
<li>HTTP 500 → Schicht 7: Anwendung bzw. Serverdienst.</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Prüfungsmodus</h2>
|
||||
<p>
|
||||
|
||||
@@ -17,14 +17,41 @@
|
||||
|
||||
<section>
|
||||
<h2>Lernfokus</h2>
|
||||
<p>Trainiere DAS, NAS, SAN sowie Dateisysteme, Blockzugriff und typische Einsatzfälle.</p>
|
||||
<p>Trainiere die drei Speicherkonzepte DAS, NAS und SAN, den Unterschied zwischen Block- und Dateizugriff sowie die wichtigsten RAID-Level. In der AP1 musst du anhand einer Situation entscheiden, welches Konzept und welcher RAID-Level zu den Anforderungen passen.</p>
|
||||
<ul class="key-list">
|
||||
<li>DAS, NAS und SAN unterscheiden.</li>
|
||||
<li>DAS, NAS und SAN sicher unterscheiden.</li>
|
||||
<li>Block- und Dateizugriff erklären.</li>
|
||||
<li>Einsatz nach Anforderungen begründen.</li>
|
||||
<li>RAID-Level 0, 1, 5, 6 und 10 mit ihren Eigenschaften kennen.</li>
|
||||
<li>Einsatz nach Anforderungen (Leistung, Kosten, Redundanz) begründen.</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>DAS, NAS und SAN</h2>
|
||||
<p>Die drei Konzepte unterscheiden sich darin, <strong>wie</strong> und <strong>worüber</strong> der Speicher angebunden ist und ob der Zugriff auf <em>Block-</em> oder <em>Datei-Ebene</em> erfolgt.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>DAS (Direct Attached Storage):</strong> Speicher ist direkt am Host angeschlossen (z. B. interne Platten, externe Platte per USB/SAS). Blockzugriff, aber nur für diesen einen Host nutzbar. Günstig und schnell, jedoch kaum gemeinsam nutzbar oder zentral verwaltbar.</li>
|
||||
<li><strong>NAS (Network Attached Storage):</strong> Eigenständiges Speichergerät im LAN, das Daten <em>dateibasiert</em> über Protokolle wie <strong>SMB</strong> (Windows) oder <strong>NFS</strong> (Unix/Linux) freigibt. Ideal für gemeinsame Dateiablagen vieler Clients.</li>
|
||||
<li><strong>SAN (Storage Area Network):</strong> Eigenes Hochleistungs-Speichernetz, das <em>blockbasierten</em> Speicher (LUNs) bereitstellt - per <strong>Fibre Channel</strong> oder <strong>iSCSI</strong> (Blockzugriff über IP). Servern erscheint der Speicher wie eine lokale Platte. Aufwendig und teuer, aber sehr leistungsfähig und skalierbar (z. B. für Datenbanken, Virtualisierung).</li>
|
||||
</ul>
|
||||
<p><strong>Block- vs. Dateizugriff:</strong> Blockspeicher (DAS, SAN) liefert rohe Blöcke, die der Host selbst partitioniert und formatiert. Dateispeicher (NAS) stellt fertige Dateien und Ordner über Freigaben bereit.</p>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> DAS = lokal am Host, NAS = Dateien übers Netz, SAN = Blöcke über ein eigenes Speichernetz.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>RAID-Level im Überblick</h2>
|
||||
<p>RAID (Redundant Array of Independent Disks) fasst mehrere Platten zu einem Verbund zusammen, um <strong>Leistung</strong> und/oder <strong>Ausfallsicherheit</strong> zu erhöhen. Wichtig: RAID ist <em>kein</em> Backup - es schützt vor Plattenausfall, nicht vor Löschen, Viren oder Standortverlust.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>RAID 0 (Striping):</strong> Daten werden auf mehrere Platten verteilt. Hohe Leistung, volle Kapazität, aber <em>keine</em> Redundanz - schon eine defekte Platte zerstört alle Daten. Min. 2 Platten.</li>
|
||||
<li><strong>RAID 1 (Spiegelung):</strong> Identische Kopie auf zwei Platten. Eine Platte darf ausfallen. Nur die halbe Bruttokapazität nutzbar. Min. 2 Platten.</li>
|
||||
<li><strong>RAID 5 (Striping + verteilte Parität):</strong> Eine Platte darf ausfallen. Nutzkapazität = (n-1) Platten. Guter Kompromiss aus Kapazität und Sicherheit. Min. 3 Platten.</li>
|
||||
<li><strong>RAID 6 (Striping + doppelte Parität):</strong> Zwei Platten dürfen gleichzeitig ausfallen. Nutzkapazität = (n-2) Platten. Sicherer als RAID 5, etwas langsamer beim Schreiben. Min. 4 Platten.</li>
|
||||
<li><strong>RAID 10 (1+0, Spiegelung + Striping):</strong> Kombiniert die Geschwindigkeit von RAID 0 mit der Sicherheit von RAID 1. Nur die halbe Kapazität, dafür sehr schnell und ausfallsicher. Min. 4 Platten.</li>
|
||||
</ul>
|
||||
<p><strong>Typische Einsatzszenarien:</strong> RAID 1 für Systemplatten kleiner Server; RAID 5 für Datei-/Archivspeicher mit gutem Kapazitäts-/Sicherheitsverhältnis; RAID 6 für große Verbünde mit vielen Platten; RAID 10 für leistungshungrige Datenbanken und virtuelle Maschinen; RAID 0 nur für unkritische Daten, bei denen Tempo zählt.</p>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> 0 = Tempo ohne Schutz, 1 = Spiegel, 5 = eine Parität (1 Platte darf gehen), 6 = doppelte Parität (2 Platten dürfen gehen), 10 = Spiegel + Tempo.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Prüfungsmodus</h2>
|
||||
<p>Dieser FluxCheck führt dich durch die wichtigsten AP1-Aspekte dieses Themas. Du kannst Antworten prüfen, Fragen überspringen und bekommst am Ende eine Auswertung nach Kategorie.</p>
|
||||
|
||||
@@ -25,6 +25,52 @@
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Was ist ein Thin Client?</h2>
|
||||
<p>Ein <strong>Thin Client</strong> ist ein bewusst schlank gehaltenes Endgerät, das selbst kaum Rechenleistung besitzt. Tastatur, Maus und Bildschirm werden lokal bedient, doch die eigentlichen Anwendungen laufen auf einem zentralen Server. Der Client überträgt nur Eingaben (Tastatur/Maus) zum Server und erhält im Gegenzug das Bildschirmbild zurück. Man spricht deshalb auch von <em>Server-based Computing</em>.</p>
|
||||
<ul class="key-list">
|
||||
<li>Rechenleistung, Programme und Daten liegen auf dem Server, nicht im Gerät.</li>
|
||||
<li>Das Endgerät benötigt nur schwache, sparsame Hardware und wenig oder keinen lokalen Speicher.</li>
|
||||
<li>Eine ständige Netzwerkverbindung zum Server ist zwingend erforderlich.</li>
|
||||
</ul>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Beim Thin Client liegt die Intelligenz im Netz - das Gerät ist nur Ein- und Ausgabe.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Abgrenzung: Fat Client, Thin Client und Zero Client</h2>
|
||||
<p>Die drei Begriffe unterscheiden sich vor allem darin, <strong>wo die Rechenleistung sitzt</strong>:</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Fat Client (Thick Client):</strong> Ein vollwertiger PC mit eigener CPU, Speicher und lokal installierter Software. Er arbeitet weitgehend unabhängig vom Server - z. B. ein klassischer Büro- oder CAD-Arbeitsplatz.</li>
|
||||
<li><strong>Thin Client:</strong> Schlankes Gerät mit minimalem Betriebssystem, das Anwendungen per Sitzung vom Server bezieht. Etwas lokale Logik (Verbindungsaufbau, Protokoll) ist vorhanden.</li>
|
||||
<li><strong>Zero Client:</strong> Noch reduzierter - praktisch ohne Betriebssystem und Konfiguration. Er stellt nur das Server-Bild dar und verbindet sich fest auf ein Protokoll. Wartung und Angriffsfläche sind dadurch minimal.</li>
|
||||
</ul>
|
||||
<p>Faustregel: Je „dünner" der Client, desto mehr verlagert sich die Arbeit auf den Server und desto stärker steigt die Abhängigkeit von Server und Netzwerk.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Server-based Computing und Terminalserver</h2>
|
||||
<p>Die Grundlage für Thin Clients ist das <strong>Server-based Computing</strong>: Ein leistungsstarker <strong>Terminalserver</strong> (z. B. mit Remote Desktop Services oder einer VDI-/Virtualisierungslösung) stellt vielen Nutzern gleichzeitig Desktops oder einzelne Anwendungen bereit. Jeder Nutzer arbeitet in einer eigenen Sitzung, die über ein Übertragungsprotokoll (z. B. RDP) an seinen Thin Client gesendet wird.</p>
|
||||
<ul class="key-list">
|
||||
<li>Software wird einmal zentral installiert und gepflegt - alle Nutzer profitieren sofort.</li>
|
||||
<li>Benutzerprofile liegen serverseitig: Der Nutzer findet seine Umgebung an jedem Client wieder.</li>
|
||||
<li>Der Server muss ausreichend dimensioniert und möglichst ausfallsicher (redundant) sein.</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Vor- und Nachteile in der Praxis</h2>
|
||||
<p>In AP1-Aufgaben sollst du Thin Clients gegen die Anforderungen eines Szenarios abwägen. Die wichtigsten Punkte:</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Administration:</strong> Vorteil - zentrale Verwaltung, einfacher Rollout über Images, schnelle Skalierung, weniger Wartung am Endgerät.</li>
|
||||
<li><strong>Sicherheit/Datenschutz:</strong> Vorteil - Daten bleiben zentral, ein gestohlenes Gerät enthält keine sensiblen Informationen, einheitliche Zugriffskontrolle.</li>
|
||||
<li><strong>Kosten:</strong> Gemischt - günstige Endgeräte und geringer Stromverbrauch, aber teure und leistungsfähige Serverinfrastruktur. Entscheidend sind die Gesamtkosten (TCO).</li>
|
||||
<li><strong>Lokale Leistung:</strong> Nachteil - rechen- oder grafikintensive Anwendungen (z. B. CAD, Video, 3D) eignen sich schlecht; hier sind Fat Clients oft besser.</li>
|
||||
<li><strong>Abhängigkeit von Netz und Server:</strong> Nachteil - ohne stabiles Netzwerk und laufenden Server kein Arbeiten; der Server wird zum Single Point of Failure, hohe Latenz stört die Bedienung.</li>
|
||||
</ul>
|
||||
<p><strong>Typische Einsatzfälle:</strong> Callcenter, Schulungsräume, Verwaltung oder Schalterarbeitsplätze - überall dort, wo viele gleichartige Arbeitsplätze mit standardisierter Software benötigt werden.</p>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Thin Clients glänzen bei vielen gleichartigen Standardarbeitsplätzen, scheitern aber an hoher lokaler Leistung und fehlender Netzverfügbarkeit.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Prüfungsmodus</h2>
|
||||
<p>Dieser FluxCheck führt dich durch die wichtigsten AP1-Aspekte dieses Themas. Du kannst Antworten prüfen, Fragen überspringen und bekommst am Ende eine Auswertung nach Kategorie.</p>
|
||||
|
||||
@@ -17,12 +17,154 @@
|
||||
|
||||
<section>
|
||||
<h2>Lernfokus</h2>
|
||||
<p>Vergleiche Bus, Stern, Ring, Mesh und Baumtopologie für AP1-Szenarien.</p>
|
||||
<p>Eine <strong>Netzwerktopologie</strong> beschreibt, wie Geräte (Knoten) und Leitungen in einem Netz angeordnet und miteinander verbunden sind. In der AP1 musst du die fünf Grundformen erkennen, ihre Vor- und Nachteile abwägen und eine passende Auswahl begründen können.</p>
|
||||
<ul class="key-list">
|
||||
<li>Topologien erkennen.</li>
|
||||
<li>Vor- und Nachteile abwägen.</li>
|
||||
<li>Ausfallsicherheit und Kosten begründen.</li>
|
||||
<li>Die Topologien Stern, Bus, Ring, Mesh und Baum erkennen und unterscheiden.</li>
|
||||
<li>Vor- und Nachteile (Kosten, Verkabelungsaufwand, Ausfallsicherheit, Erweiterbarkeit) abwägen.</li>
|
||||
<li>Ausfallverhalten begründen, insbesondere den Single Point of Failure.</li>
|
||||
</ul>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Topologie = Bauplan der Verbindungen. Sie entscheidet über Kosten, Ausfallsicherheit und Wartbarkeit eines Netzes.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Die Sterntopologie</h2>
|
||||
<p>Im Stern hat jedes Endgerät eine eigene Punkt-zu-Punkt-Leitung zu einem zentralen Koppelelement – in modernen LANs ist das ein <strong>Switch</strong>. Der gesamte Datenverkehr läuft über diese Zentrale.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Vorteil:</strong> Ein defektes Kabel betrifft nur ein Gerät; die Fehlersuche ist einfach, weil sich Störungen auf eine Leitung eingrenzen lassen.</li>
|
||||
<li><strong>Vorteil:</strong> Gut erweiterbar – neue Geräte brauchen nur einen freien Port.</li>
|
||||
<li><strong>Nachteil:</strong> Der zentrale Switch ist ein <strong>Single Point of Failure</strong>; fällt er aus, steht das ganze Netz.</li>
|
||||
<li><strong>Nachteil:</strong> Höherer Kabelaufwand, da jede Station eine eigene Leitung benötigt.</li>
|
||||
</ul>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Der Stern ist die Standardform heutiger Ethernet-LANs – ein Switch in der Mitte, sternförmige Twisted-Pair-Leitungen nach außen.</p>
|
||||
<div class="topo-grid">
|
||||
<figure class="topo-figure">
|
||||
<svg class="topo" viewBox="0 0 220 150" role="img" aria-label="Sterntopologie: zentraler Switch mit sternförmigen Leitungen zu den Endgeräten">
|
||||
<line class="link" x1="110" y1="75" x2="110" y2="18"/>
|
||||
<line class="link" x1="110" y1="75" x2="178" y2="48"/>
|
||||
<line class="link" x1="110" y1="75" x2="178" y2="102"/>
|
||||
<line class="link" x1="110" y1="75" x2="110" y2="132"/>
|
||||
<line class="link" x1="110" y1="75" x2="42" y2="102"/>
|
||||
<line class="link" x1="110" y1="75" x2="42" y2="48"/>
|
||||
<circle class="node" cx="110" cy="18" r="9"/>
|
||||
<circle class="node" cx="178" cy="48" r="9"/>
|
||||
<circle class="node" cx="178" cy="102" r="9"/>
|
||||
<circle class="node" cx="110" cy="132" r="9"/>
|
||||
<circle class="node" cx="42" cy="102" r="9"/>
|
||||
<circle class="node" cx="42" cy="48" r="9"/>
|
||||
<rect class="hub" x="92" y="63" width="36" height="24" rx="6"/>
|
||||
<text class="hlbl" x="110" y="75">SW</text>
|
||||
</svg>
|
||||
<figcaption><strong>Stern</strong> – jede Station per eigener Leitung am zentralen Switch (Single Point of Failure).</figcaption>
|
||||
</figure>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Bus- und Ringtopologie</h2>
|
||||
<p>Bei der <strong>Bustopologie</strong> hängen alle Teilnehmer an einem gemeinsamen Kabel, das an beiden Enden mit Abschlusswiderständen terminiert wird. Sie ist kabelsparend, aber ein einziger Kabelbruch oder fehlender Terminator legt das ganze Segment lahm. Außerdem teilen sich alle Stationen die Bandbreite (Kollisionen).</p>
|
||||
<p>Bei der <strong>Ringtopologie</strong> ist jeder Knoten mit genau zwei Nachbarn verbunden; die Daten werden von Station zu Station weitergereicht, bis sie das Ziel erreichen. Im einfachen Ring unterbricht der Ausfall eines Knotens oder einer Leitung den gesamten Kreis (Abhilfe schaffen Doppelringe).</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Bus:</strong> geringster Verkabelungsaufwand, aber gemeinsames Medium und schlechte Ausfallsicherheit.</li>
|
||||
<li><strong>Ring:</strong> definierter Datenfluss, aber ohne Redundanz fällt bei einer Unterbrechung das ganze Netz aus.</li>
|
||||
<li>Beide Formen sind heute weitgehend durch den Stern verdrängt; Koax-Bus und Token Ring sind historisch.</li>
|
||||
</ul>
|
||||
<div class="topo-grid">
|
||||
<figure class="topo-figure">
|
||||
<svg class="topo" viewBox="0 0 240 140" role="img" aria-label="Bustopologie: alle Stationen an einem gemeinsamen Kabel mit Abschlusswiderständen">
|
||||
<line class="bus" x1="20" y1="95" x2="220" y2="95"/>
|
||||
<rect class="term" x="12" y="87" width="9" height="16" rx="2"/>
|
||||
<rect class="term" x="219" y="87" width="9" height="16" rx="2"/>
|
||||
<line class="link" x1="50" y1="95" x2="50" y2="55"/>
|
||||
<line class="link" x1="100" y1="95" x2="100" y2="55"/>
|
||||
<line class="link" x1="150" y1="95" x2="150" y2="55"/>
|
||||
<line class="link" x1="200" y1="95" x2="200" y2="55"/>
|
||||
<circle class="node" cx="50" cy="46" r="9"/>
|
||||
<circle class="node" cx="100" cy="46" r="9"/>
|
||||
<circle class="node" cx="150" cy="46" r="9"/>
|
||||
<circle class="node" cx="200" cy="46" r="9"/>
|
||||
</svg>
|
||||
<figcaption><strong>Bus</strong> – gemeinsames Kabel, an beiden Enden terminiert; ein Kabelbruch legt das Segment lahm.</figcaption>
|
||||
</figure>
|
||||
<figure class="topo-figure">
|
||||
<svg class="topo" viewBox="0 0 160 160" role="img" aria-label="Ringtopologie: jeder Knoten mit genau zwei Nachbarn zu einem geschlossenen Kreis verbunden">
|
||||
<polygon class="link" points="80,24 128,52 128,108 80,136 32,108 32,52"/>
|
||||
<circle class="node" cx="80" cy="24" r="9"/>
|
||||
<circle class="node" cx="128" cy="52" r="9"/>
|
||||
<circle class="node" cx="128" cy="108" r="9"/>
|
||||
<circle class="node" cx="80" cy="136" r="9"/>
|
||||
<circle class="node" cx="32" cy="108" r="9"/>
|
||||
<circle class="node" cx="32" cy="52" r="9"/>
|
||||
</svg>
|
||||
<figcaption><strong>Ring</strong> – Daten werden von Knoten zu Knoten gereicht; ohne Doppelring unterbricht ein Ausfall den Kreis.</figcaption>
|
||||
</figure>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Mesh und Baum</h2>
|
||||
<p>In der <strong>vermaschten Topologie (Mesh)</strong> sind Knoten über mehrere Wege direkt miteinander verbunden. Beim Vollmesh ist jeder mit jedem verbunden – das bietet maximale <strong>Redundanz</strong> und Ausfallsicherheit, weil bei Ausfall einer Verbindung ein anderer Pfad genutzt wird. Der Preis ist ein quadratisch wachsender Verkabelungs- und Kostenaufwand. Im WLAN sorgt ein Mesh aus mehreren Access Points für lückenlose Funkabdeckung.</p>
|
||||
<p>Die <strong>Baumtopologie</strong> ist eine hierarchische Erweiterung des Sterns: Mehrere Sterne werden über übergeordnete Verteiler/Switches zu Ebenen zusammengefasst, die ein <strong>Backbone</strong> verbindet. So werden in der Praxis Etagen oder Gebäude strukturiert verkabelt.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Mesh:</strong> höchste Ausfallsicherheit durch redundante Pfade, aber teuer und aufwendig.</li>
|
||||
<li><strong>Baum:</strong> gut skalierbar und für große, strukturierte Netze geeignet.</li>
|
||||
<li>Ein höherer Verteiler im Baum kann – ähnlich wie der Switch im Stern – zum kritischen Punkt für seinen Teilbaum werden.</li>
|
||||
</ul>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Redundanz erhöht die Ausfallsicherheit, kostet aber zusätzliche Leitungen und Geräte – immer gegen Budget und Anforderung abwägen.</p>
|
||||
<div class="topo-grid">
|
||||
<figure class="topo-figure">
|
||||
<svg class="topo" viewBox="0 0 180 160" role="img" aria-label="Vermaschte Topologie: Knoten über mehrere Wege direkt miteinander verbunden">
|
||||
<line class="link" x1="90" y1="20" x2="149" y2="63"/>
|
||||
<line class="link" x1="90" y1="20" x2="126" y2="133"/>
|
||||
<line class="link" x1="90" y1="20" x2="54" y2="133"/>
|
||||
<line class="link" x1="90" y1="20" x2="31" y2="63"/>
|
||||
<line class="link" x1="149" y1="63" x2="126" y2="133"/>
|
||||
<line class="link" x1="149" y1="63" x2="54" y2="133"/>
|
||||
<line class="link" x1="149" y1="63" x2="31" y2="63"/>
|
||||
<line class="link" x1="126" y1="133" x2="54" y2="133"/>
|
||||
<line class="link" x1="126" y1="133" x2="31" y2="63"/>
|
||||
<line class="link" x1="54" y1="133" x2="31" y2="63"/>
|
||||
<circle class="node" cx="90" cy="20" r="9"/>
|
||||
<circle class="node" cx="149" cy="63" r="9"/>
|
||||
<circle class="node" cx="126" cy="133" r="9"/>
|
||||
<circle class="node" cx="54" cy="133" r="9"/>
|
||||
<circle class="node" cx="31" cy="63" r="9"/>
|
||||
</svg>
|
||||
<figcaption><strong>Mesh</strong> – redundante Pfade: fällt eine Verbindung aus, übernimmt ein anderer Weg.</figcaption>
|
||||
</figure>
|
||||
<figure class="topo-figure">
|
||||
<svg class="topo" viewBox="0 0 240 150" role="img" aria-label="Baumtopologie: hierarchische Verteiler mit Backbone, mehrere Sterne in Ebenen">
|
||||
<line class="link" x1="120" y1="30" x2="70" y2="74"/>
|
||||
<line class="link" x1="120" y1="30" x2="170" y2="74"/>
|
||||
<line class="link" x1="70" y1="74" x2="35" y2="128"/>
|
||||
<line class="link" x1="70" y1="74" x2="105" y2="128"/>
|
||||
<line class="link" x1="170" y1="74" x2="135" y2="128"/>
|
||||
<line class="link" x1="170" y1="74" x2="205" y2="128"/>
|
||||
<rect class="hub" x="102" y="18" width="36" height="24" rx="6"/>
|
||||
<text class="hlbl" x="120" y="30">SW</text>
|
||||
<rect class="hub" x="52" y="62" width="36" height="24" rx="6"/>
|
||||
<text class="hlbl" x="70" y="74">SW</text>
|
||||
<rect class="hub" x="152" y="62" width="36" height="24" rx="6"/>
|
||||
<text class="hlbl" x="170" y="74">SW</text>
|
||||
<circle class="node" cx="35" cy="128" r="9"/>
|
||||
<circle class="node" cx="105" cy="128" r="9"/>
|
||||
<circle class="node" cx="135" cy="128" r="9"/>
|
||||
<circle class="node" cx="205" cy="128" r="9"/>
|
||||
</svg>
|
||||
<figcaption><strong>Baum</strong> – mehrere Sterne hierarchisch über einen Backbone verbunden (Etagen/Gebäude).</figcaption>
|
||||
</figure>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Auswahl und heutige Praxis</h2>
|
||||
<p>In der AP1 sollst du Topologien nicht nur benennen, sondern eine begründete Auswahl treffen. Stelle dazu die Anforderungen (z. B. Hochverfügbarkeit, Budget, Erweiterbarkeit) den Eigenschaften der Topologien gegenüber.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Büro-LAN:</strong> Sterntopologie mit zentralem Switch – einfach, fehlersicher pro Leitung, gut erweiterbar.</li>
|
||||
<li><strong>Hochverfügbarkeit:</strong> redundante Verbindungen/Geräte (Mesh-Anteile, doppelte Uplinks) senken das Ausfallrisiko.</li>
|
||||
<li><strong>Große Standorte:</strong> Baum mit Backbone strukturiert mehrere Sterne über Etagen und Gebäude.</li>
|
||||
<li>Eine aktuelle <strong>Netzdokumentation</strong> (Netzplan, Portbelegung) macht die Topologie nachvollziehbar und beschleunigt Wartung und Fehlersuche.</li>
|
||||
</ul>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Argumentiere in der Prüfung immer entlang von Kosten, Ausfallsicherheit und Wartbarkeit – die heutige Standardlösung im LAN ist der Stern.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
|
||||
@@ -16,19 +16,138 @@
|
||||
<h1>USV - Unterbrechungsfreie Stromversorgung</h1>
|
||||
|
||||
<section>
|
||||
<h2>Aufgabe einer USV</h2>
|
||||
<h2>Aufgabe und Zweck einer USV</h2>
|
||||
<p>
|
||||
Eine USV überbrückt Stromausfälle kurzzeitig und schützt Systeme vor
|
||||
Spannungsschwankungen. Sie ersetzt keinen Generator, sondern schafft Zeit
|
||||
für geordnetes Herunterfahren oder Umschalten.
|
||||
Eine USV (Unterbrechungsfreie Stromversorgung, englisch UPS) versorgt
|
||||
angeschlossene Geräte bei Problemen im Stromnetz aus einer Batterie weiter.
|
||||
Ihr eigentlicher Zweck ist nicht die Dauerversorgung, sondern das
|
||||
Überbrücken kurzer Ausfälle und das Schaffen von Zeit für ein geordnetes
|
||||
Herunterfahren oder das Umschalten auf einen Notstromgenerator. Damit
|
||||
schützt sie kritische IT vor abruptem Stromverlust und den daraus
|
||||
folgenden Daten- und Hardwareschäden.
|
||||
</p>
|
||||
<p>
|
||||
Angeschlossen werden typischerweise Server, Storage und aktive
|
||||
Netzwerkkomponenten (Switches, Router) - also genau die Systeme, die
|
||||
erreichbar bleiben oder kontrolliert herunterfahren müssen. Eine USV ist
|
||||
stets nur ein Baustein im Schutzkonzept: Sie ersetzt weder ein Backup noch
|
||||
Maßnahmen gegen Angriffe oder Bedienfehler.
|
||||
</p>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Die USV überbrückt nur
|
||||
Minuten - sie kauft Zeit zum sauberen Herunterfahren, sie ist kein
|
||||
Dauer-Notstrom.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Stromstörungen, die eine USV abdecken kann</h2>
|
||||
<p>
|
||||
Welche Störungen eine USV behandelt, hängt von ihrem Typ ab. Die wichtigsten
|
||||
Netzprobleme sind:
|
||||
</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Stromausfall (Blackout):</strong> komplettes Wegfallen der Spannung.</li>
|
||||
<li><strong>Spannungseinbruch / Unterspannung (Sag, Brownout):</strong> zu niedrige Spannung über kurze oder längere Zeit.</li>
|
||||
<li><strong>Überspannung (Surge/Swell):</strong> kurzfristig oder dauerhaft zu hohe Spannung.</li>
|
||||
<li><strong>Spannungsspitzen (Spikes/Transienten):</strong> sehr kurze, hohe Spitzen, z. B. durch Schalthandlungen oder Blitzschlag.</li>
|
||||
<li><strong>Frequenzschwankungen und Oberschwingungen (Verzerrungen):</strong> Abweichungen der Netzfrequenz bzw. der Sinusform.</li>
|
||||
</ul>
|
||||
<p>
|
||||
Einfache Geräte fangen nur Ausfall und grobe Spannungsabweichungen ab,
|
||||
hochwertige Online-USVen alle genannten Störungen.
|
||||
</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>USV-Typen und ihr Schutzumfang</h2>
|
||||
<p>
|
||||
Die Norm IEC 62040-3 unterscheidet drei Klassen. Sie reichen vom einfachen,
|
||||
günstigen Ausfallschutz bis zur lückenlosen, störungsfreien Versorgung:
|
||||
</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Offline- / Standby-USV (VFD):</strong> Im Normalbetrieb wird das
|
||||
Netz direkt durchgeleitet; erst bei Ausfall schaltet das Gerät mit kurzer
|
||||
<em>Umschaltzeit</em> (wenige Millisekunden) auf Batterie. Schützt nur vor
|
||||
Ausfall und sehr groben Spannungsabweichungen. Einsatz: einzelne PCs,
|
||||
kleine Arbeitsplätze.</li>
|
||||
<li><strong>Line-Interactive-USV (VI):</strong> Zusätzlich gleicht ein
|
||||
regelbarer Transformator (AVR) Über- und Unterspannungen aus, ohne die
|
||||
Batterie zu belasten. Auch hier gibt es eine kurze Umschaltzeit. Einsatz:
|
||||
kleine Server und Netzwerktechnik.</li>
|
||||
<li><strong>Online- / Doppelwandler-USV (VFI):</strong> Die Spannung wird per
|
||||
Gleichrichter und Wechselrichter <em>ständig neu erzeugt</em>. Es gibt
|
||||
<em>keine</em> Umschaltzeit, und die Last ist auch von Frequenz- und
|
||||
Oberschwingungsproblemen entkoppelt - höchster Schutz, aber höherer
|
||||
Eigenverbrauch und mehr Abwärme. Einsatz: Rechenzentren, empfindliche
|
||||
und kritische Lasten.</li>
|
||||
</ul>
|
||||
<p>
|
||||
Merkhilfe zu den Kürzeln: <strong>VFD</strong> = Offline,
|
||||
<strong>VI</strong> = Line-Interactive (Voltage Independent),
|
||||
<strong>VFI</strong> = Online (Voltage and Frequency Independent).
|
||||
</p>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Je höher die Klasse (VFD →
|
||||
VI → VFI), desto mehr Störungen werden abgedeckt - die Online-USV
|
||||
arbeitet sogar ganz ohne Umschaltzeit.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Dimensionierung: Leistung und Überbrückungszeit</h2>
|
||||
<p>
|
||||
Eine USV muss zur Last passen. Dafür sind zwei Größen entscheidend - die
|
||||
Leistung und die Autonomiezeit:
|
||||
</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Leistung (VA und Watt):</strong> Die Scheinleistung wird in
|
||||
Voltampere (VA), die nutzbare Wirkleistung in Watt (W) angegeben. Wegen
|
||||
des Leistungsfaktors (z. B. 0,8-0,9) ist der Watt-Wert kleiner als der
|
||||
VA-Wert - beide Grenzen müssen eingehalten werden.</li>
|
||||
<li><strong>Lastermittlung:</strong> Zuerst die Leistungsaufnahme aller
|
||||
angeschlossenen Geräte summieren. Niemals dauerhaft an der
|
||||
Überlastgrenze betreiben.</li>
|
||||
<li><strong>Reserve:</strong> Rund 20-30 % Reserve für Lastspitzen,
|
||||
Batteriealterung und spätere Erweiterungen einplanen.</li>
|
||||
<li><strong>Autonomie-/Überbrückungszeit:</strong> Sie muss mindestens so
|
||||
lang sein wie die Shutdown-Zeit aller Systeme plus Puffer. Je höher die
|
||||
Last, desto kürzer die Laufzeit aus derselben Batterie.</li>
|
||||
</ul>
|
||||
<p>
|
||||
<strong>Beispiel:</strong> Zwei Server mit zusammen 600 W sollen 5 Minuten
|
||||
bis zum geordneten Shutdown überbrücken. Mit Leistungsfaktor 0,9 ergibt das
|
||||
rund 670 VA; mit 25 % Reserve wählt man also eine USV ab etwa 850-1000 VA,
|
||||
deren Batterie die 600 W mindestens 5 Minuten trägt.
|
||||
</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Betrieb, Wartung und Akku</h2>
|
||||
<p>
|
||||
Eine USV schützt nur dann zuverlässig, wenn sie überwacht und gewartet wird:
|
||||
</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Shutdown-Software:</strong> Per USB- oder Netzwerkschnittstelle
|
||||
meldet die USV den Ausfall und löst rechtzeitig das geordnete
|
||||
Herunterfahren der Server aus, bevor die Batterie leer ist.</li>
|
||||
<li><strong>Monitoring:</strong> Batteriestatus, Last und Störungen sollten
|
||||
überwacht werden, um Probleme vor dem Ernstfall zu erkennen.</li>
|
||||
<li><strong>Tests:</strong> Regelmäßige Tests prüfen, ob Überbrückung und
|
||||
Shutdown praktisch funktionieren.</li>
|
||||
<li><strong>Akku als Verschleißteil:</strong> Batterien altern; ihre
|
||||
Kapazität sinkt mit Alter und Ladezyklen. Sie müssen nach
|
||||
Herstellerangaben geprüft und ersetzt werden.</li>
|
||||
<li><strong>Nachkontrolle:</strong> Nach jedem Stromereignis Logs,
|
||||
Batteriestatus und Systemzustand prüfen.</li>
|
||||
</ul>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Eine USV ohne konfigurierte
|
||||
Shutdown-Software und ohne Akkupflege ist nur eine halbe
|
||||
Sicherheitsmaßnahme.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Prüfungsmodus</h2>
|
||||
<p>
|
||||
Dieser FluxCheck trainiert USV-Grundlagen, Dimensionierung und typische
|
||||
Betriebsfragen aus AP1-Situationen.
|
||||
Dieser FluxCheck trainiert USV-Grundlagen, Typen und Schutzumfang,
|
||||
Dimensionierung (VA/Watt, Überbrückungszeit) sowie typische Betriebs- und
|
||||
Wartungsfragen aus AP1-Situationen.
|
||||
</p>
|
||||
</section>
|
||||
|
||||
|
||||
@@ -25,6 +25,51 @@
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Was ist VDI?</h2>
|
||||
<p>VDI steht für <strong>Virtual Desktop Infrastructure</strong>. Dabei laufen die Arbeitsplatz-Desktops nicht mehr lokal auf dem PC, sondern als virtuelle Maschinen zentral im Rechenzentrum des Unternehmens (On-Premise). Eine Virtualisierungsschicht, der <strong>Hypervisor</strong> (z. B. VMware ESXi, Microsoft Hyper-V, Citrix Hypervisor), teilt die Server-Hardware in viele getrennte virtuelle Desktops auf. Der Mitarbeiter sieht auf seinem Endgerät nur Bild und Eingabe, die über ein <strong>Remote-Protokoll</strong> (RDP, PCoIP, Blast) übertragen werden.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Hypervisor:</strong> betreibt und verwaltet die virtuellen Desktops auf dem Server.</li>
|
||||
<li><strong>Zentrale Desktops:</strong> Rechenleistung liegt im Rechenzentrum, nicht am Arbeitsplatz.</li>
|
||||
<li><strong>Client/Thin Client:</strong> dient nur als Zugriffspunkt für Anzeige und Eingaben.</li>
|
||||
<li><strong>Golden Image:</strong> zentrale Vorlage, aus der die Desktops bereitgestellt werden.</li>
|
||||
</ul>
|
||||
<p>Beispiel: Eine Firma stellt 200 Mitarbeitern Windows-Desktops über zwei eigene Server bereit. Steht ein Update an, wird es einmal am Master-Image gepflegt und für alle ausgerollt.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Was ist DaaS?</h2>
|
||||
<p><strong>DaaS</strong> (Desktop as a Service) ist die Cloud-Variante von VDI. Hier betreibt nicht das Unternehmen selbst die Infrastruktur, sondern ein externer <strong>Cloud-Anbieter</strong> (z. B. Azure Virtual Desktop, Amazon WorkSpaces). Die Desktops werden als Dienst gemietet und über das Internet genutzt. Der Anbieter kümmert sich um Hardware, Hypervisor und Verfügbarkeit.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Cloud statt eigener Hardware:</strong> kein eigenes Rechenzentrum nötig.</li>
|
||||
<li><strong>Abo-/Mietmodell:</strong> laufende Gebühren (OPEX) statt großer Anfangsinvestition.</li>
|
||||
<li><strong>Flexible Skalierung:</strong> Desktops können kurzfristig dazugebucht oder reduziert werden.</li>
|
||||
<li><strong>Internetabhängig:</strong> ohne stabile Verbindung kein Zugriff.</li>
|
||||
</ul>
|
||||
<p>Beispiel: Ein Start-up bucht für 30 neue Saison-Mitarbeiter kurzfristig DaaS-Desktops und gibt sie nach der Saison wieder frei, ohne Hardware zu kaufen.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Persistent vs. non-persistent</h2>
|
||||
<p>Bei beiden Modellen unterscheidet man, ob Änderungen erhalten bleiben:</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Persistenter Desktop:</strong> fest einem Nutzer zugewiesen, persönliche Einstellungen und Daten bleiben dauerhaft erhalten. Höherer Speicherbedarf.</li>
|
||||
<li><strong>Non-persistenter Desktop:</strong> wird nach der Sitzung auf den Ausgangszustand zurückgesetzt. Sparsam und einheitlich; Nutzerdaten müssen über Profile oder Netzlaufwerke ausgelagert werden.</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Vor- und Nachteile, Abgrenzung VDI ↔ DaaS</h2>
|
||||
<p>Der Kern der AP1-Bewertung ist die Abwägung zwischen <strong>Eigenbetrieb (VDI)</strong> und <strong>zugekaufter Dienstleistung (DaaS)</strong>:</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>VDI:</strong> volle Kontrolle und Datenhoheit im eigenen Haus, aber hohe Anschaffungskosten (CAPEX), eigener Wartungsaufwand und durch eigene Hardware begrenzte Skalierung.</li>
|
||||
<li><strong>DaaS:</strong> schnell startklar, flexibel skalierbar und planbare laufende Kosten (OPEX), aber Abhängigkeit von Anbieter und Internet sowie Datenschutzfragen (Datenstandort, Auftragsverarbeitungsvertrag nach DSGVO).</li>
|
||||
<li><strong>Gemeinsam:</strong> zentrale Administration, einfacher Geräteersatz und gute Sicherheit durch zentrale Datenhaltung (Zugriffskontrolle, MFA, Richtlinien).</li>
|
||||
</ul>
|
||||
<p>Wichtige Bewertungsfaktoren für beide: Latenz und Bandbreite (Netzqualität), Performance-Bedarf (z. B. GPU für Grafikanwendungen), Kosten, Datenschutz und Nutzeranforderungen.</p>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> VDI ist der virtuelle Desktop im eigenen Rechenzentrum, DaaS derselbe Desktop als gemieteter Cloud-Dienst.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Prüfungsmodus</h2>
|
||||
<p>Dieser FluxCheck führt dich durch die wichtigsten AP1-Aspekte dieses Themas. Du kannst Antworten prüfen, Fragen überspringen und bekommst am Ende eine Auswertung nach Kategorie.</p>
|
||||
|
||||
@@ -25,6 +25,49 @@
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Was ist ein VLAN?</h2>
|
||||
<p>Ein VLAN (Virtual Local Area Network) teilt ein physisches Netzwerk logisch in mehrere getrennte Teilnetze auf. Mehrere VLANs können dieselbe Hardware - also denselben Switch und dieselbe Verkabelung - nutzen und verhalten sich trotzdem so, als wären sie vollständig voneinander getrennte Netze. Eine eigene physische Verkabelung pro Netz ist dadurch nicht mehr nötig.</p>
|
||||
<p>Entscheidend ist: Jedes VLAN bildet eine eigene Broadcast-Domäne. Ein Broadcast (z. B. eine ARP-Anfrage) eines Geräts erreicht nur Geräte im selben VLAN und wird nicht in andere VLANs weitergeleitet. So bleiben Broadcast-Bereiche klein und der Verkehr wird sauber getrennt.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Logische statt physische Trennung:</strong> getrennte Netze auf gemeinsamer Infrastruktur.</li>
|
||||
<li><strong>Eigene Broadcast-Domäne:</strong> Broadcasts bleiben innerhalb des VLANs.</li>
|
||||
<li><strong>VLAN-ID (1-4094):</strong> kennzeichnet eindeutig, zu welchem VLAN ein Port oder Frame gehört.</li>
|
||||
</ul>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Ein VLAN ist eine logische, kein physisches Netz - ein Switch, mehrere getrennte Broadcast-Domänen.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>802.1Q-Tagging</h2>
|
||||
<p>Damit ein Switch beim Weiterleiten weiß, zu welchem VLAN ein Frame gehört, wird nach dem Standard IEEE 802.1Q ein 4-Byte-Tag in den Ethernet-Frame eingefügt. Dieses Tag enthält unter anderem die VLAN-ID. Wichtig: Es handelt sich nur um eine Markierung zur Zuordnung - der Inhalt wird dabei <em>nicht</em> verschlüsselt.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Tagged:</strong> Frame mit 802.1Q-Tag, typisch auf Trunk-Leitungen zwischen Switches.</li>
|
||||
<li><strong>Untagged:</strong> Frame ohne Tag, typisch am Endgerät; das VLAN ergibt sich aus der Portkonfiguration.</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Access-Port vs. Trunk-Port</h2>
|
||||
<p>Die Unterscheidung dieser beiden Porttypen wird in der AP1 gern abgefragt - sie dürfen nicht verwechselt werden.</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Access-Port:</strong> gehört zu genau einem VLAN und gibt Frames untagged an das Endgerät (PC, Drucker, IP-Telefon) weiter.</li>
|
||||
<li><strong>Trunk-Port:</strong> transportiert mehrere VLANs gebündelt über eine Leitung und nutzt dafür 802.1Q-Tags; verbindet meist Switches untereinander oder Switch und Router.</li>
|
||||
<li><strong>Native VLAN:</strong> das VLAN, dessen Verkehr auf dem Trunk untagged läuft; aus Sicherheitsgründen (VLAN-Hopping) sollte es geändert werden und nicht VLAN 1 sein.</li>
|
||||
</ul>
|
||||
<p>Beispiel: Ein PC hängt an einem Access-Port in VLAN 10. Der Switch ist über einen Trunk mit einem zweiten Switch verbunden, über den VLAN 10, 20 und 30 getaggt laufen. Fehlt der Trunk, funktioniert VLAN 10 lokal, erreicht aber keine Geräte auf dem zweiten Switch.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>VLANs, Subnetze und Routing</h2>
|
||||
<p>In der Praxis wird jedem VLAN üblicherweise ein eigenes IP-Subnetz zugeordnet (z. B. VLAN 10 = 192.168.10.0/24, VLAN 20 = 192.168.20.0/24). Layer-2-Trennung (VLAN) und Layer-3-Adressierung (Subnetz) sind damit deckungsgleich. Da VLANs voneinander isoliert sind, benötigt die Kommunikation zwischen ihnen eine Layer-3-Funktion - einen Router oder einen Layer-3-Switch (Inter-VLAN-Routing, z. B. Router-on-a-Stick).</p>
|
||||
<ul class="key-list">
|
||||
<li><strong>Vorteile:</strong> mehr Sicherheit (isolierte Bereiche, z. B. Gastnetz), bessere Performance (kleinere Broadcast-Domänen), höhere Flexibilität (Umzug per Konfiguration statt Verkabelung).</li>
|
||||
<li><strong>Grenzen:</strong> VLANs trennen, ersetzen aber keine Firewall-Regeln für den Verkehr dazwischen.</li>
|
||||
<li><strong>DHCP:</strong> jedes VLAN braucht einen erreichbaren DHCP-Dienst, oft über ein DHCP-Relay (IP-Helper).</li>
|
||||
</ul>
|
||||
<p class="merksatz"><strong>Merksatz:</strong> Ein VLAN trennt auf Layer 2, das Routing zwischen VLANs passiert auf Layer 3.</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>Prüfungsmodus</h2>
|
||||
<p>Dieser FluxCheck führt dich durch die wichtigsten AP1-Aspekte dieses Themas. Du kannst Antworten prüfen, Fragen überspringen und bekommst am Ende eine Auswertung nach Kategorie.</p>
|
||||
|
||||
Reference in New Issue
Block a user