> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/de/modul-2-dimensionierung-and-design/02-reference-architectures.md).

# Referenzarchitekturen

VergeOS unterstützt drei Bereitstellungsarchitekturen mit derselben Softwareinstallation. Die Wahl der richtigen hängt von der Knotenzahl, dem Wachstumsmuster und den Anforderungen an die Spezialisierung der Workloads ab. Diese Seite führt durch jedes Modell, bietet einen Entscheidungsrahmen und behandelt zwei häufige praxisnahe Szenarien: Edge-Bereitstellungen und Multi-Tenant-Umgebungen von Cloud Service Providern (CSP).

## Entscheidungsbaum für Architekturen

Verwenden Sie den folgenden Rahmen, um Ihre Empfehlung zu leiten. Die untenstehenden Knotenzahl-Bereiche sind grobe Faustregeln: HCI eignet sich für kleinere Bereitstellungen (typischerweise 2--12 Knoten), und UCI wird angewendet, wenn sich Wachstum von Rechenleistung und Speicher auseinanderentwickelt oder spezielle Hardware benötigt wird.

```mermaid
flowchart TD
    A["Wie viele Knoten wird<br/>die Bereitstellung haben?"] --> B{"2 -- 6 Knoten"}
    A --> C{"6 -- 10 Knoten"}
    A --> D{"10+ Knoten"}

    B --> E{"Werden Rechenleistung und Speicher<br/>proportional wachsen?"}
    E -->|"Ja"| F["HCI"]
    E -->|"Nein -- Rechenleistung wächst schneller"| G["HCI + Dedizierte Rechenleistung<br/>(Hybride 2-Cluster-UCI)"]
    E -->|"Unklar"| H{"Spezialisierte Hardware<br/>erforderlich? (GPU, hoher RAM-Bedarf)"}

    C --> H
    D --> I["UCI (kanonisches 3-Cluster-Modell)"]

    H -->|"Ja"| I
    H -->|"Nein"| G
    H -->|"Vielleicht in Zukunft"| G

    style F fill:#e8f5e9,stroke:#2e7d32
    style G fill:#fff3e0,stroke:#e65100
    style I fill:#f0f4ff,stroke:#336
```

**Kurze Faustregeln:**

1. **Beginnen Sie mit HCI** es sei denn, Sie haben einen konkreten Grund, es nicht zu tun.
2. **Ziehen Sie HCI + Compute in Betracht** wenn der Bedarf an Rechenleistung schneller wächst als der Speicherbedarf (6--10 Knoten).
3. **Wählen Sie UCI** für Umgebungen mit 10+ Knoten, spezialisierter Hardware oder maximaler Isolation der Leistung.
4. Sie können **sich weiterentwickeln** von HCI zu HCI + Compute zu UCI, während die Umgebung wächst -- dieselbe VergeOS-Installation unterstützt alle drei.

***

## Modell 1: HCI (Hyperkonvergente Infrastruktur)

**Knotenbereich:** 2--6 Knoten | **Cluster:** 1

In einer HCI-Bereitstellung trägt jeder Knoten **sowohl** Rechenleistung und Speicher. Die beiden Controller-Knoten tragen Tier-0- (vSAN-Metadaten) und Tier-1- (Workload-) Speicher und führen VMs aus. Scale-out-Knoten erweitern denselben Cluster um Tier-1-Speicher und Rechenkapazität.

```mermaid
graph TB
    subgraph cluster1["Cluster 1 -- HCI"]
        N1["Knoten 1 -- Controller<br/>Tier 0 + Tier 1<br/>Speicher + Rechenleistung"]
        N2["Knoten 2 -- Controller<br/>Tier 0 + Tier 1<br/>Speicher + Rechenleistung"]
        S1["Knoten 3 -- Scale-out<br/>Tier 1<br/>Speicher + Rechenleistung"]
        S2["Knoten 4 -- Scale-out<br/>Tier 1<br/>Speicher + Rechenleistung"]
    end
    subgraph fabric["Kern-Fabric"]
        CF["Core 1 + Core 2"]
    end
    N1 --- CF
    N2 --- CF
    S1 --- CF
    S2 --- CF

    style cluster1 fill:#e8f5e9,stroke:#2e7d32
    style fabric fill:#f0f4ff,stroke:#336
```

### Vorteile

* **Betriebliche Einfachheit** -- ein einzelner Cluster, eine einzige Hardware-Spezifikation, einheitliche Verwaltung.
* **Vorhersehbare Skalierung** -- jeder Knoten erweitert Speicher und Rechenleistung proportional.
* **Niedrigster Einstiegspunkt** -- ein 2-Knoten-Cluster ist die kleinste mögliche VergeOS-Bereitstellung.
* **Eine einzige Hardwarespezifikation** vereinfacht Beschaffung und Ersatzteillager.

### Einschränkungen

* Rechenleistung kann nicht unabhängig vom Speicher skaliert werden (und umgekehrt).
* Begrenzte Hardwarespezialisierung -- alle Knoten haben dieselbe Rolle.
* Empfohlene Höchstzahl von etwa 6 Knoten, bevor ein zweiter Cluster in Betracht gezogen wird.
* Mögliche Ressourcen-Konkurrenz auf Controller-Knoten, die sowohl Metadatenoperationen als auch VM-Workloads ausführen.

### Ideale Anwendungsfälle

| Szenario                                          | Warum HCI funktioniert                                          |
| ------------------------------------------------- | --------------------------------------------------------------- |
| Kleine/mittelgroße Bereitstellungen (2--6 Knoten) | Minimale Komplexität, jeder Knoten übernimmt zwei Aufgaben      |
| Ausgewogene Workloads                             | Speicher und Rechenleistung wachsen ungefähr mit derselben Rate |
| Edge-/Remote-Standorte                            | 2-Knoten-Cluster mit vollständiger HA und kleinem Footprint     |
| Evaluation und Tests                              | Schnellster Weg zu einem funktionsfähigen VergeOS-System        |

***

## Modell 2: HCI + Dedizierte Rechenleistung (Hybride 2-Cluster-UCI)

**Knotenbereich:** 6--10 Knoten | **Cluster:** 2

Dies ist die hybride 2-Cluster-Variante von UCI: Controller- und Speicherrollen bleiben in einem HCI-Cluster zusammengeführt, während die Rechenleistung in einen eigenen Cluster ausgelagert wird. Der HCI-Cluster (Cluster 1) stellt den gesamten Speicher über seine Controller und optionalen Scale-out-Knoten bereit. Der Rechencluster (Cluster 2) führt VM-Workloads aus, ohne selbst Festplatten beizusteuern.

```mermaid
graph TB
    subgraph cluster1["Cluster 1 -- HCI (Speicher + Rechenleistung)"]
        N1["Knoten 1 -- Controller<br/>Tier 0 + Tier 1"]
        N2["Knoten 2 -- Controller<br/>Tier 0 + Tier 1"]
        S1["Knoten 3 -- HCI<br/>Tier 1 (optional)"]
    end
    subgraph cluster2["Cluster 2 -- Nur Rechenleistung"]
        C1["Knoten 4 -- Rechenleistung"]
        C2["Knoten 5 -- Rechenleistung"]
        C3["Knoten 6 -- Rechenleistung"]
        C4["Knoten 7+ -- Skalierung"]
    end
    subgraph fabric["Kern-Fabric"]
        CF["Core 1 + Core 2"]
    end
    N1 --- CF
    N2 --- CF
    S1 --- CF
    C1 --- CF
    C2 --- CF
    C3 --- CF
    C4 --- CF

    style cluster1 fill:#fff3e0,stroke:#e65100
    style cluster2 fill:#e3f2fd,stroke:#1565c0
    style fabric fill:#f0f4ff,stroke:#336
```

### Wichtige Designprinzipien

### Cluster 1 -- HCI (Kombiniert)

* Enthält immer die Knoten 1 und 2 mit Tier-0-Speicher (Controller). - Kann zusätzliche HCI-Scale-out-Knoten für mehr Speicher und Rechenleistung enthalten. - Ein Cluster-Level-Schalter steuert, ob dieser Cluster auch VM-Workloads ausführt. - Alle Speicherebenen befinden sich in diesem Cluster.

### Cluster 2 -- Nur Rechenleistung

* Reine Rechenleistung -- maximale für VMs verfügbare CPU- und RAM-Kapazität. - Skaliert unabhängig je nach Rechenleistungsbedarf. - Unterstützt flexible, auf den Workload optimierte Hardware (GPU-Knoten, Knoten mit hohem Speicher). - Speicher-I/O von Rechenknoten läuft über die Kern-Fabric zu Cluster 1.

### Vorteile

* Unabhängige Skalierung der Rechenleistung ohne Kauf unerwünschten Speichers.
* Erhält die betriebliche Einfachheit von HCI für die Speicherebene.
* Kosteneffizient -- skalieren Sie nur die Ressourcenschicht, die wächst.
* Klarer Wachstumspfad zur kanonischen 3-Cluster-UCI, falls sich die Anforderungen weiterentwickeln.

### Einschränkungen

* Speicher-I/O von Rechenknoten überquert das Netzwerk (ausreichende Kern-Fabric-Bandbreite ist entscheidend).
* Komplexer als reines HCI (zwei Cluster statt eines zu verwalten).
* Erfordert eine Entscheidung, ob der HCI-Cluster auch Workloads ausführen soll.

### Ideale Anwendungsfälle

| Szenario                                                 | Warum HCI + Compute funktioniert                       |
| -------------------------------------------------------- | ------------------------------------------------------ |
| Bereitstellungen mit 6--10 Knoten                        | Genau der richtige Bereich für das Zwei-Cluster-Modell |
| Wachstum der Rechenleistung übertrifft das des Speichers | CPU/RAM hinzufügen, ohne Festplatten zu erweitern      |
| GPU- oder spezialisierte Rechenleistung                  | Dedizierter Rechencluster mit Passthrough-Hardware     |
| Kostenoptimierung                                        | Nur das skalieren, was Sie benötigen                   |

***

## Modell 3: UCI (Ultra Converged Infrastructure) -- kanonisches 3-Cluster-Modell

**Knotenbereich:** 10+ Knoten | **Cluster:** 3+

Das kanonische 3-Cluster-UCI trennt Controller, Speicher und Rechenleistung vollständig in dedizierte Cluster. Jede Ressourcenschicht ist unabhängig skalierbar und nutzt für ihre Rolle optimierte Hardware. (UCI ist ein Sammelbegriff für jede Bereitstellung mit unabhängiger Skalierung; Modell 2 oben ist die hybride 2-Cluster-Variante.)

```mermaid
graph TB
    subgraph cluster1["Cluster 1 -- Dedizierte Controller"]
        N1["Knoten 1 -- Controller<br/>Nur Tier 0 | Hoher Speicher"]
        N2["Knoten 2 -- Controller<br/>Nur Tier 0 | Hoher Speicher"]
    end
    subgraph cluster2["Cluster 2 -- Dedizierter Speicher"]
        ST1["Knoten 3 -- Speicher<br/>NVMe-dicht | Tier 1"]
        ST2["Knoten 4 -- Speicher<br/>NVMe-dicht | Tier 1"]
        ST3["Knoten 5 -- Speicher<br/>NVMe-dicht | Tier 1"]
    end
    subgraph cluster3["Cluster 3+ -- Spezialisierte Rechenleistung"]
        C1["Standard-Rechenleistung"]
        C2["GPU-Rechenleistung"]
        C3["Hoher Speicher"]
    end
    subgraph fabric["Kern-Fabric"]
        CF["Core 1 + Core 2"]
    end
    N1 --- CF
    N2 --- CF
    ST1 --- CF
    ST2 --- CF
    ST3 --- CF
    C1 --- CF
    C2 --- CF
    C3 --- CF

    style cluster1 fill:#f3e5f5,stroke:#6a1b9a
    style cluster2 fill:#e8f5e9,stroke:#2e7d32
    style cluster3 fill:#e3f2fd,stroke:#1565c0
    style fabric fill:#f0f4ff,stroke:#336
```

### Clusterspezialisierung

| Cluster                          | Rolle                                 | Optimiert für                                                                        |
| -------------------------------- | ------------------------------------- | ------------------------------------------------------------------------------------ |
| **Cluster 1 -- Controller**      | Tier-0-Metadaten, Clusterverwaltung   | Hoher Speicher (z. B. 768 GB in der Data-Science-RA), hochbelastbare NVMe für Tier 0 |
| **Cluster 2 -- Speicher**        | Gesamter Workload-Speicher (Tier 1+)  | Maximale Laufwerksdichte, NVMe oder SAS/SATA-SSD                                     |
| **Cluster 3+ -- Rechenleistung** | VM-Workloads, spezialisierte Hardware | Standard-, GPU-, High-Memory- oder benutzerdefinierte Knotentypen                    |

### Vorteile

* **Maximale Leistung** -- keine Ressourcen-Konkurrenz zwischen Speicher und Rechenleistung.
* **Vollständig unabhängige Skalierung** -- Speicher ohne Rechenleistung hinzufügen (oder umgekehrt).
* **Hardwarespezialisierung** -- Hardware passend zur Rolle dimensionieren (NVMe-dicht für Speicher, mit GPU für Rechenleistung).
* **Workload-Isolierung** -- verschiedene Rechencluster für unterschiedliche Workload-Typen.
* **Optimal für große und Multi-Tenant-Umgebungen.**

### Einschränkungen

* Höchste betriebliche Komplexität unter allen drei Architekturen.
* Mindestens 6 Knoten (abgeleitet aus dem Minimum von 2 Knoten pro Cluster × 3 Clustern: 2 Controller + 2 Speicher + 2 Rechenknoten).
* Komplexere Kapazitätsplanung über drei Clustertypen hinweg.
* Höhere Anforderungen an die Kern-Fabric-Bandbreite zwischen den Clustern.
* Für die Erstbereitstellung werden professionelle Services empfohlen.

### Ideale Anwendungsfälle

| Szenario                                      | Warum UCI funktioniert                                                     |
| --------------------------------------------- | -------------------------------------------------------------------------- |
| Unternehmensbereitstellungen mit 10+ Knoten   | Unabhängige Skalierung vermeidet Überprovisionierung                       |
| KI-/HPC-/GPU-Workloads                        | Dedizierte GPU-Rechencluster, getrennt vom Speicher                        |
| Cloud Service Provider                        | Hardwareausgaben pro Ressourcenschicht über alle Tenants hinweg optimieren |
| Speicherlastiges oder rechenlastiges Wachstum | Nur das skalieren, was wächst                                              |

***

## Architekturvergleich

| Aspekt                     | HCI               | HCI + Compute (Hybride 2-Cluster-UCI) | UCI (kanonisches 3-Cluster-Modell)                 |
| -------------------------- | ----------------- | ------------------------------------- | -------------------------------------------------- |
| **Mindestanzahl Knoten**   | 2                 | 4 (2 HCI + 2 Rechenleistung)          | 6 (2+2+2)                                          |
| **Clusteranzahl**          | 1                 | 2                                     | 3+                                                 |
| **Leistung**               | Gut               | Besser                                | Optimal                                            |
| **Hardwareflexibilität**   | Niedrig           | Mittel                                | Maximal                                            |
| **Unabhängige Skalierung** | Nein              | Teilweise (nur Rechenleistung)        | Vollständig                                        |
| **Spezialisierung**        | Keine             | Nur Rechenleistung                    | Vollständig (Controller, Speicher, Rechenleistung) |
| **Komplexität**            | Niedrig           | Mittel                                | Hoch                                               |
| **Ressourceneffizienz**    | Variabel          | Gut                                   | Maximal                                            |
| **Beste Passung**          | Klein, ausgewogen | Mittlere Größe, rechenlastig          | Groß, spezialisiert                                |

***

## Szenarien für Edge-Bereitstellungen

Edge-Cluster sind kompakte VergeOS-Bereitstellungen mit 2 Knoten, die für entfernte Standorte oder Niederlassungen konzipiert sind. Sie verwenden hardware mit niedrigem Stromverbrauch und kleinem Formfaktor und sind direkt verbunden (für die Kern-Fabric sind keine Switches erforderlich).

### Typische Edge-Konfiguration

* **2 Knoten** direkt über zwei NICs verbunden (Kern-Fabric).
* Hardware mit kleinem Formfaktor (Intel NUC, SFF-1L-PCs oder ähnlich).
* 2 TB NVMe für Workloads + 4 TB SSD für Massenspeicher pro Knoten.
* Vollständige HA und Redundanz trotz minimalem Footprint.

```mermaid
graph LR
    N1["Knoten 1<br/>Controller + Speicher + Rechenleistung"] <-->|"Kern-Fabric<br/>(Direktverbindung)"| N2["Knoten 2<br/>Controller + Speicher + Rechenleistung"]
    N1 --- EXT["Externes Netzwerk<br/>(Uplink)"]
    N2 --- EXT

    style N1 fill:#e8f5e9,stroke:#2e7d32
    style N2 fill:#e8f5e9,stroke:#2e7d32
```

### Edge-Verwaltungsmodelle

VergeOS unterstützt drei Edge-Verwaltungsszenarien mit zunehmender Komplexität:

1. **Standalone mit zentraler Verwaltung** -- 2-Knoten-Cluster an jedem Standort, zentral verwaltet über das **Sites** Dashboard. Catalog-Repositories verteilen VM-Vorlagen vom Verwaltungscluster an alle Edge-Standorte.
2. **Zentrale Sicherung und DR** -- wie oben, plus ein zentrales System im primären Rechenzentrum bietet **Site Sync** Replikation, **ioGuardian** Reparaturserver und zentralen Snapshot-Speicher für alle Niederlassungen.
3. **Mehrstufig mit Archiv** -- fügt am DR-Standort einen zweiten Archivcluster für die Langzeitaufbewahrung mit hochkapazitiven HDDs hinzu und bietet damit eine vollständige 3-2-1-Backup-Strategie.

### Wann Edge empfohlen werden sollte

* Platz- oder Strombeschränkungen an entfernten Standorten.
* Anwendungen, die Daten zentral speichern, aber lokale Rechenleistung benötigen.
* Organisationen, die 5--100+ verteilte Standorte verwalten.
* Kostensensible Bereitstellungen für Zweigstellen.

***

## CSP-/Multi-Tenant-Szenarien

Cloud Service Provider nutzen die Multi-Tenancy von VergeOS, um IaaS aus gemeinsam genutzter Infrastruktur bereitzustellen. Jeder Tenant arbeitet als isoliertes Virtuelles Rechenzentrum (VDC) mit eigener Benutzeroberfläche, eigenen Netzwerken, eigenem Speicher und eigenen Zugriffskontrollen.

### Typische CSP-Konfiguration

* **6-Knoten-HCI-Cluster** in primären Rechenzentren (Server mit hoher Dichte, 768 GB+ RAM pro Knoten).
* **Site Sync** zwischen Rechenzentren für DR.
* **ioGuardian** Reparaturserver für automatisches Blockabrufen von entfernten Standorten.
* **Globale Inline-Deduplizierung** reduziert den Speicherverbrauch über replizierte Snapshots hinweg.
* **Tenant-Rezepte** automatisieren die Bereitstellung kompletter Kundenumgebungen (Tenant, Netzwerke, Firewall-Regeln, VMs, Speicher).

### Wachstumspfad für CSPs

| Phase       | Bereitstellung                                                                        | Knoten                         |
| ----------- | ------------------------------------------------------------------------------------- | ------------------------------ |
| **Phase 1** | 2 primäre Standorte mit DR über Site Sync                                             | 6 pro Standort                 |
| **Phase 2** | 2-Knoten-Edge-Cluster in neuen Regionen hinzufügen                                    | 2 pro Region                   |
| **Phase 3** | Edge-Standorte durch Hinzufügen von Clustern ausbauen (illustrativ)                   | variiert je Standort           |
| **Phase 4** | Dedizierte Speichercluster für speicherlastige Tenants und Archivschichten hinzufügen | 2+ Speicherknoten pro Standort |

### Wichtige VergeOS-Funktionen für CSPs

* **Multi-Tenancy** mit vollständiger Isolierung zwischen Kundenumgebungen.
* **Self-Service-Verwaltung** über Web-UI und API für Tenant-Administratoren.
* **Catalog-Repositories** für zentrale Verwaltung von VM-Vorlagen.
* **OpenID-Authentifizierung** Integration mit vorhandenen Identitätsanbietern.
* **Tenant-Rezepte** für automatisiertes, wiederholbares Onboarding von Kunden.

***

## Überblick über Netzwerkdesign-Modelle

Die von Ihnen gewählte Bereitstellungsarchitektur beeinflusst Ihr Netzwerkdesign. VergeOS unterstützt mehrere Netzwerktopologien, die in [Modul 4: Netzwerke](/learn-the-platform/de/modul-4-netzwerke/04-networking.md)detailliert behandelt werden. Hier ist ein kurzer Überblick, der Ihre Architekturentscheidung unterstützt:

| Modell                              | NICs pro Knoten | Kern-Fabric                         | Externes Netzwerk                     | Am besten geeignet für                                    |
| ----------------------------------- | --------------- | ----------------------------------- | ------------------------------------- | --------------------------------------------------------- |
| **L2 statisch + dedizierter Core**  | 4               | 2 dedizierte L2                     | Gebündeltes L2 (LACP)                 | Produktionsumgebungen, VMware-Migrationen                 |
| **L3 dynamisch + dedizierter Core** | 4               | 2 dedizierte L2                     | per BGP / OSPF / EIGRP angekündigt    | Groß angelegte Umgebungen, fortgeschrittene Segmentierung |
| **L3 statisch + dedizierter Core**  | 4               | 2 dedizierte L2                     | Gebündeltes L3 (statische Routen)     | Groß angelegte Umgebungen, Layer-3-Switching              |
| **L2 statisch (2 NICs)**            | 2               | 2 gemeinsam genutzte (VLAN-getaggt) | Gemeinsam mit dem Core (VLAN-getaggt) | Edge, PoC, kleine Bereitstellungen                        |

**Wichtige Anforderungen für alle Modelle:**

* Kern-Fabric-Netzwerke müssen auf **dedizierten Layer-2-Segmenten** (voneinander isoliert).
* Jumbo-Frames (**MTU 9216+**) auf allen Switch-Ports des Core-Fabrics.
* **Keine Switch-Hops** zwischen Knoten im Core-Fabric -- alle Knoten müssen mit demselben Switching-Fabric verbunden sein.
* STP auf Core-Fabric-Ports deaktiviert.

***

{% hint style="info" %}
**VMware Bridge**

Kommen Sie von VMware? VergeOS ermöglicht es Ihnen, Storage und Compute innerhalb eines Systems unabhängig voneinander zu skalieren — reine Compute-Cluster nutzen das gemeinsam genutzte vSAN über das Core-Fabric, ohne externes SAN/NAS und ohne ein separates Storage-Produkt lizenzieren zu müssen.
{% endhint %}

{% hint style="info" %}
**Nutanix Bridge**

Kommen Sie von Nutanix? VergeOS erstellt reine Storage-Cluster und reine Compute-Cluster in einem System — Storage läuft als integrierter OS-Dienst, sodass keine CVM RAM/CPU auf einem beliebigen Knotentyp verbraucht.
{% endhint %}

## Zusammenfassung

| Konzept           | Wichtigste Erkenntnis                                                                                        |
| ----------------- | ------------------------------------------------------------------------------------------------------------ |
| **HCI**           | Jeder Knoten macht alles. Einfach, kosteneffizient im kleinen Maßstab. Hier beginnen.                        |
| **HCI + Compute** | Hybrides 2-Cluster-UCI: Controller+Storage zusammengelegt, unabhängige Compute-Skalierung.                   |
| **UCI**           | Kanonisches 3-Cluster: dedizierter Controller, Storage und Compute. Maximale Flexibilität.                   |
| **Edge**          | 2-Knoten-Direct-Connect-Cluster für entfernte Standorte, zentral verwaltet.                                  |
| **CSP**           | Mandantenfähige HCI-Bereitstellungen mit Site Sync DR und automatisierter Tenant-Rezeptur.                   |
| **Evolution**     | Dieselbe VergeOS-Installation unterstützt alle drei Modelle -- wachsen Sie im Laufe der Zeit von HCI zu UCI. |

## Nächste Schritte

* [**Kunden-Scoping**](/learn-the-platform/de/modul-2-dimensionierung-and-design/03-customer-scoping.md) -- Lernen Sie die Methodik zur Anforderungserhebung, um Kundenbedürfnisse in eine konkrete Architekturempfehlung zu übersetzen.
* [**Netzwerk**](/learn-the-platform/de/modul-4-netzwerke/04-networking.md) -- Vertiefung der oben genannten Netzwerkdesign-Modelle.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.verge.io/learn-the-platform/de/modul-2-dimensionierung-and-design/02-reference-architectures.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.