> 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/knowledge-base/de/storage-vsan/understanding-and-explaining-unexpected-vsan-growth.md). # Unerwartetes vSAN-Wachstum verstehen und erklären Fehlerbehebungsleitfaden zur Diagnose unerwarteten vSAN-Speicherwachstums, einschließlich der Überprüfung des Tier-Verlaufs und der Identifizierung häufiger Ursachen wie Snapshots, Backups und Mandantenspeicher. Es gibt mehrere Gründe dafür, dass das vSAN schneller als erwartet zu wachsen beginnt. Administratoren sollten zunächst feststellen, wann das unerklärte Wachstum auftrat, indem sie die Wachstumshistorie der vSAN-Tiers prüfen, und dann mögliche Bereiche für unerwartetes Wachstum bewerten. ## vSAN-Tiers auf Wachstumshistorie prüfen Um unerklärtes Wachstum zu isolieren, ist es wichtig einzugrenzen, wann das Wachstum exponentiell zugenommen hat. Mit den folgenden Schritten können Administratoren das Speicherwachstum überprüfen und normales Wachstum aus dem Tagesbetrieb von Wachstumsspitzen unterscheiden, die in der Regel unerwartet sind. 1. Navigieren Sie zu **Infrastruktur** > **vSAN-Tiers** im oberen Menü. Wenn vSAN-Tiers nicht vorhanden ist, ist diese Umgebung ein Mandant eines übergeordneten Systems, und das vSAN-Tier muss im übergeordneten System überprüft werden. 2. Öffnen Sie das vSAN-Tier mit dem unerwarteten Wachstum (z. B. vSAN-Tier 0). 3. Klicken Sie im linken Navigationsmenü auf **Verlauf**. 4. Ein neues Menü wird angezeigt, das den Verlauf in verschiedenen Diagrammen zeigt. Ändern Sie den Filterzeitraum, um jedes Wachstum auf diesem Tier einzugrenzen. * Es wird empfohlen, mit einem benutzerdefinierten Filter von 1 Tag zu beginnen und das **Speichernutzung** Diagramm zu prüfen. ### Hinweise: * Wenn Sie stündlich oder einmal täglich Einbrüche und Spitzen sehen, ist dies wahrscheinlich das Ergebnis von Snapshots, die aus der Aufbewahrung herausfallen (alte laufen ab, neue werden erstellt). Beachten Sie, ob der zu Beginn des Tages verbrauchte Gesamtspeicher nahezu dem Ende des Tages entspricht. Wenn ja, erweitern Sie den benutzerdefinierten Filter auf eine Woche. * Bei der Wochenansicht prüfen Sie, ob der zu Beginn der Woche verbrauchte Gesamtspeicher dem Ende ähnlich ist. Wenn das Wachstum beispielsweise etwa 10 % beträgt, wiederholen Sie dies für die vorherige Woche. Wenn der wöchentliche Wachstumsprozentsatz konstant ist, entspricht dies Ihrer durchschnittlichen wöchentlichen Wachstumsrate, die bei der Planung einer Hardwareerweiterung helfen kann. * Filtern Sie den aktuellen Monat und prüfen Sie auf plötzliche Spitzen beim Speicherverbrauch im **Speichernutzung** Diagramm. Klicken und ziehen Sie über den betreffenden Zeitraum, um in die Daten hineinzuzoomen, und fahren Sie mit der Maus über das Diagramm, um spezifische Informationen zu Datum/Uhrzeit zu erhalten. ![vsan\_unexpected\_growth.png](https://2284512452-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQZBMFpokMv2vWTIRbFzA%2Fuploads%2Fgit-blob-217505e650e1d66261f4c837c8106256938aa1c6%2Fvsan_unexpected_growth.png?alt=media) ## Mögliche Gründe für eine Speicherzunahme Mehrere Bereiche in der VergeOS-Plattform können zu unerwartetem Speicherwachstum beitragen. Zu den häufig zu prüfenden Bereichen gehören: * **System-Snapshots**: * Navigieren Sie zu **System > System-Snapshots**. * Werden einige über ihren erwarteten Ablaufzeitpunkt hinaus aufbewahrt? * Gibt es Snapshots ohne Snapshot-Profil? Diese wurden möglicherweise manuell erstellt. Untersuchen Sie, wann und warum sie erstellt wurden. * Sind einige Snapshots auf "Nie ablaufen" gesetzt? Dies kann im Laufe der Zeit zu einem hohen Datenverbrauch führen. * **Snapshots virtueller Maschinen (VMs)**: * Navigieren Sie zum **Maschinen-Dashboard**. Das **Snapshots** Zählfeld zeigt die Anzahl der auf Maschinenebene vorhandenen Snapshots an. Klicken Sie auf dieses Feld, um alle VM-Snapshots und deren Erstellungsdatum/-uhrzeit aufzulisten. Prüfen Sie, ob einige entfernt werden können. * Navigieren Sie zu **Virtuelle Maschinen > Liste**. Sortieren Sie nach der **Snapshot-Profil** Spalte, um VMs mit Snapshots auf Maschinenebene zu identifizieren. Virtuelle Maschinen können aus System-Snapshots wiederhergestellt werden. Prüfen Sie daher, ob einzelne Snapshots notwendig sind oder entfernt werden können. * **VMware-Backup-Jobs**: * Navigieren Sie zu **Backup/DR > VMware-Dienste** und überprüfen Sie jede VMware-Service-Instanz auf den Backup-Job-Verlauf. * Klicken Sie im linken Menü auf **Backup-Jobs** um jede spezifische Instanz zu überprüfen. Prüfen Sie die **Läuft ab** Spalte für jedes Backup und prüfen Sie, ob es entfernt werden kann. * **Dateien**: * Navigieren Sie zu **Dateien** und sortieren Sie nach **Geändert**. Prüfen Sie, ob eines der Upload-Daten/-uhrzeiten mit dem Zeitraum des unerklärten Wachstums übereinstimmt. * Prüfen Sie, ob Dateien, insbesondere andere Hypervisor-Formate (z. B. .ova oder .vhdx), entfernt werden können. * **Eingehende Site-Synchronisierungen**: * Navigieren Sie zu **Backup/DR > Eingehende Synchronisierungen**. Öffnen Sie jedes Dashboard für eingehende Synchronisierung und prüfen Sie die **Empfangene Snapshots** Zählung. Untersuchen Sie die Quell- (Ursprungs-)Site auf erhöhten Speicherverbrauch, der mit dem Zeitraum übereinstimmt. * **Mandantenspeicher**: * Navigieren Sie zu **Mandanten > Dashboard jedes Mandanten**. * Prüfen Sie **Gesamter verwendeter Speicher** durch Klicken auf **Verlauf** im linken Menü. Folgen Sie demselben oben beschriebenen Verfahren, um die Wachstumshistorie zu überprüfen. * Wenn unerwartetes Wachstum gefunden wird, untersuchen Sie innerhalb des Mandanten die möglichen Ursachen der Speicherzunahme (wie oben aufgeführt) sowie gegebenenfalls innerhalb von Untermandanten. ## Verwendeter Speicher des Tiers vs. Summe der Maschinenlaufwerke Die Kennzahl für den insgesamt vom vSAN-Tier verwendeten Speicher ist in der Regel höher als die Summe des belegten Speicherplatzes, der über die einzelnen machine\_drives gemeldet wird. Diese Abweichung entsteht, weil die gemeldete belegte Kapazität jedes Maschinenlaufwerks nur die derzeit referenzierten aktiven Blöcke auf diesen Laufwerken widerspiegelt. Im Gegensatz dazu berücksichtigt die gesamte Tier-Nutzung alle zugrunde liegenden Datenblöcke der Plattform, einschließlich: * **Snapshots:** Blöcke, die ausschließlich beibehalten werden, um historische Momentaufnahmen zu erhalten. * **VMware-Dienste:** Daten, die von VMware-Backup-Instanzen aufbewahrt werden. * **Dateien:** Speicher des gemeinsamen Dateisystems, hochgeladene Medien oder Hypervisor-Images (z. B. .ova, .vhdx). * **KI-Modelle:** Lokale Modelldateien und Gewichte, die auf dem Tier gespeichert sind. ### Snapshot-Aufbewahrung Wenn andere Verbraucher (VMware-Dienste, KI-Modelle und Dateien) ausgeschlossen wurden, ist die Snapshot-Aufbewahrung fast immer der Hauptverursacher des unerwarteten Tier-Verbrauchs. Da Snapshots geänderte oder gelöschte Blöcke bewahren, die von aktiven Maschinenlaufwerken nicht mehr referenziert werden, können aggressive Snapshot-Zeitpläne oder lange Aufbewahrungsrichtlinien den Tier-Verbrauch erheblich erhöhen. {% hint style="warning" %} **Vorsicht vor dem Löschen von System-Snapshots** Bevor Sie System-Snapshots manuell entfernen, um lokalen Speicher freizugeben, prüfen Sie, ob ausstehende Snapshots in der Warteschlange stehen oder aktiv an einen Offsite-Zielstandort für die Notfallwiederherstellung synchronisiert werden: * Wenn die Offsite-Synchronisierung wesentlich ist: Vergewissern Sie sich, dass der Snapshot die Synchronisierung zum entfernten Ziel abgeschlossen hat, bevor Sie ihn lokal löschen. Das Löschen eines Snapshots während der Synchronisierung bricht die Übertragung ab; der Snapshot wird auf der Remote-Site erst verfügbar, wenn die vollständige Synchronisierung abgeschlossen ist. * Wenn der lokale Speicher kritisch knapp ist: Die sofortige Wiederherstellung von Kapazität kann Vorrang vor ausstehenden Synchronisierungsaufträgen haben, um die Workloads am Laufen zu halten. Bewerten Sie den aktuellen freien Puffer Ihres lokalen Tiers im Vergleich zu den Anforderungen an die Offsite-Wiederherstellung, bevor Sie eine Massenlöschung durchführen. {% endhint %} --- # 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/knowledge-base/de/storage-vsan/understanding-and-explaining-unexpected-vsan-growth.md?ask=&goal= ``` `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.