

Amazon FSx File Gateway ist für Neukunden nicht mehr verfügbar. Bestandskunden von FSx File Gateway können den Service weiterhin normal nutzen. Informationen zu Funktionen, die FSx File Gateway ähneln, finden Sie in [diesem Blogbeitrag](https://aws.amazon.com/blogs/storage/switch-your-file-share-access-from-amazon-fsx-file-gateway-to-amazon-fsx-for-windows-file-server/).

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Behebung von Problemen mit Ihrer Storage Gateway Gateway-Bereitstellung
<a name="troubleshooting-gateway-issues"></a>

Im Folgenden finden Sie Informationen zu bewährten Methoden und zur Behebung von Problemen im Zusammenhang mit Gateways, Hostplattformen, Dateisystemen, Hochverfügbarkeit, Datenwiederherstellung und Snapshots. Die Informationen zur Fehlerbehebung bei lokalen Gateways beziehen sich auf Gateways, die auf unterstützten Virtualisierungsplattformen bereitgestellt werden. Die Informationen zur Fehlerbehebung bei Hochverfügbarkeitsproblemen beziehen sich auf Gateways, die auf der VMware vSphere High Availability (HA) -Plattform ausgeführt werden.

**Topics**
+ [Fehlerbehebung: Gateway-Offline-Probleme](troubleshooting-gateway-offline.md)- Erfahren Sie, wie Sie Probleme diagnostizieren, die dazu führen können, dass Ihr Gateway in der Storage Gateway Gateway-Konsole als offline angezeigt wird.
+ [Fehlerbehebung: Active Directory-Probleme](troubleshooting-active-directory.md)- Erfahren Sie, was zu tun ist, wenn Sie Fehlermeldungen wie`NETWORK_ERROR`, oder erhalten`TIMEOUT`, `ACCESS_DENIED` wenn Sie versuchen, Ihr File Gateway mit einer Microsoft Active Directory-Domäne zu verbinden.
+ [Fehlerbehebung: Probleme mit der Gateway-Aktivierung](troubleshooting-gateway-activation.md)- Erfahren Sie, wie Sie vorgehen, wenn Sie beim Versuch, Ihr Storage Gateway zu aktivieren, eine interne Fehlermeldung erhalten.
+ [Fehlerbehebung: Probleme mit dem lokalen Gateway](troubleshooting-on-premises-gateway-issues.md)- Erfahren Sie mehr über typische Probleme, die bei der Arbeit mit Ihren lokalen Gateways auftreten können, und darüber, wie Sie eine Verbindung zu Ihrem Gateway herstellen können Support , um Sie bei der Fehlerbehebung zu unterstützen.
+ [Fehlerbehebung: Probleme mit der Installation von Microsoft Hyper-V](troubleshooting-hyperv-setup.md)- Erfahren Sie mehr über typische Probleme, die bei der Bereitstellung von Storage Gateway auf der Microsoft Hyper-V-Plattform auftreten können.
+ [Fehlerbehebung: Probleme mit dem Amazon EC2 EC2-Gateway](troubleshooting-EC2-gateway-issues.md)- Hier finden Sie Informationen zu typischen Problemen, die bei der Arbeit mit Gateways auftreten können, die auf Amazon EC2 bereitgestellt werden.
+ [Fehlerbehebung: Probleme mit der Hardware-Appliance](troubleshooting-hardware-appliance-issues.md)- Erfahren Sie, wie Sie Probleme lösen können, die möglicherweise mit der AWS Storage Gateway Gateway-Hardware-Appliance auftreten.
+ [Fehlerbehebung: Probleme mit File Gateway](troubleshooting-file-gateway-issues.md)- Hier finden Sie Informationen, die Ihnen helfen können, die Ursache von Fehlern und Integritätsmeldungen zu verstehen, die in den CloudWatch Protokollen Ihres File Gateways erscheinen.
+ [Fehlerbehebung: Probleme mit der Hochverfügbarkeit](troubleshooting-ha-issues.md)- Erfahren Sie, wie Sie vorgehen können, wenn Probleme mit Gateways auftreten, die in einer VMware HA-Umgebung bereitgestellt werden.

# Fehlerbehebung: Gateway ist in der Storage Gateway Gateway-Konsole offline
<a name="troubleshooting-gateway-offline"></a>

Ermitteln Sie anhand der folgenden Informationen zur Fehlerbehebung, was zu tun ist, wenn die AWS Storage Gateway Konsole anzeigt, dass Ihr Gateway offline ist.

Ihr Gateway wird möglicherweise aus einem oder mehreren der folgenden Gründe als offline angezeigt:
+ Das Gateway kann die Storage Gateway-Dienstendpunkte nicht erreichen.
+ Das Gateway wurde unerwartet heruntergefahren.
+ Eine dem Gateway zugeordnete Cache-Festplatte wurde getrennt oder geändert oder ist ausgefallen.

Um Ihr Gateway wieder online zu schalten, identifizieren und beheben Sie das Problem, das dazu geführt hat, dass Ihr Gateway offline gegangen ist.

## Überprüfen Sie die zugehörige Firewall oder den zugehörigen Proxy
<a name="w2ab1c54c12c11"></a>

Wenn Sie Ihr Gateway für die Verwendung eines Proxys konfiguriert haben oder Ihr Gateway hinter einer Firewall platziert haben, überprüfen Sie die Zugriffsregeln des Proxys oder der Firewall. Der Proxy oder die Firewall muss den Datenverkehr zu und von den Netzwerkports und Dienstendpunkten zulassen, die von Storage Gateway benötigt werden. Weitere Informationen finden Sie unter [Netzwerk- und Firewallanforderungen](https://docs.aws.amazon.com/filegateway/latest/filefsxw/Requirements.html#networks) .

## Suchen Sie nach einer laufenden SSL- oder Deep-Packet-Inspektion des Datenverkehrs Ihres Gateways
<a name="w2ab1c54c12c13"></a>

Wenn derzeit eine SSL- oder Deep-Packet-Inspection für den Netzwerkverkehr zwischen Ihrem Gateway und durchgeführt wird AWS, kann Ihr Gateway möglicherweise nicht mit den erforderlichen Service-Endpunkten kommunizieren. Um Ihr Gateway wieder online zu schalten, müssen Sie die Inspektion deaktivieren.

## Überprüfen Sie die Metrik IOWait Prozent nach einem Neustart oder Softwareupdate
<a name="w2ab1c54c12c15"></a>

Prüfen Sie nach einem Neustart oder Softwareupdate, ob die `IOWaitPercent` Metrik für Ihr File Gateway 10 oder höher ist. Dies kann dazu führen, dass Ihr Gateway langsam reagiert, während es den Index-Cache im RAM neu aufbaut. Weitere Informationen finden Sie unter [Problembehandlung: Verwenden von CloudWatch Metriken](https://docs.aws.amazon.com/filegateway/latest/filefsxw/troubleshooting-file-gateway-issues.html#gateway-not-responding).

## Suchen Sie nach einem Strom- oder Hardwarefehler auf dem Hypervisor-Host
<a name="w2ab1c54c12c17"></a>

Ein Strom- oder Hardwarefehler auf dem Hypervisor-Host Ihres Gateways kann dazu führen, dass Ihr Gateway unerwartet heruntergefahren wird und nicht mehr erreichbar ist. Nachdem Sie die Stromversorgung und die Netzwerkkonnektivität wiederhergestellt haben, ist Ihr Gateway wieder erreichbar.

Nachdem Ihr Gateway wieder online ist, sollten Sie unbedingt Maßnahmen ergreifen, um Ihre Daten wiederherzustellen. Weitere Informationen finden Sie unter [Bewährte Methoden: Wiederherstellen Ihrer Daten](https://docs.aws.amazon.com/filegateway/latest/filefsxw/recover-data-from-gateway.html) .

## Suchen Sie nach Problemen mit einer zugehörigen Cache-Festplatte
<a name="w2ab1c54c12c19"></a>

Ihr Gateway kann offline gehen, wenn mindestens eine der mit Ihrem Gateway verbundenen Cache-Festplatten entfernt, geändert oder in der Größe geändert wurde oder wenn sie beschädigt ist.

**Wenn eine funktionierende Cache-Festplatte vom Hypervisor-Host entfernt wurde:**

1. Fahren Sie das Gateway herunter.

1. Fügen Sie die Festplatte erneut hinzu.
**Anmerkung**  
Stellen Sie sicher, dass Sie die Festplatte demselben Festplattenknoten hinzufügen.

1. Starten Sie Ihr Gateway neu.

**Wenn ein Cache-Laufwerk beschädigt ist, ersetzt wurde oder dessen Größe geändert wurde:**
+ Folgen Sie dem Verfahren nach **Methode 2**, das unter [Ersetzen Ihres vorhandenen S3 File Gateways durch eine neue Instanz](https://docs.aws.amazon.com/filegateway/latest/files3/migrate-data.html#replace-instance-file-gateway) beschrieben ist, um ein neues Gateway einzurichten und Cache-Festplatteninformationen erneut aus der AWS Cloud herunterzuladen.

# Fehlerbehebung: Probleme beim Verbinden des Gateways mit Active Directory
<a name="troubleshooting-active-directory"></a>

Verwenden Sie die folgenden Informationen zur Problembehandlung, um zu ermitteln, was zu tun ist, wenn Sie Fehlermeldungen wie`NETWORK_ERROR`,`TIMEOUT`, oder erhalten, `ACCESS_DENIED` wenn Sie versuchen, Ihr File Gateway mit einer Microsoft Active Directory-Domäne zu verbinden.

Führen Sie die folgenden Prüfungen und Konfigurationen durch, um diese Fehler zu beheben.

## Stellen Sie sicher, dass das Gateway den Domänencontroller erreichen kann, indem Sie einen NPING-Test ausführen
<a name="w2ab1c54c15b7"></a>

**So führen Sie einen NPING-Test durch:**

1. Stellen Sie mit Ihrer Hypervisor-Verwaltungssoftware (VMware, Hyper-V oder KVM) für lokale Gateways oder mit SSH für Amazon EC2 EC2-Gateways eine Connect zur lokalen Gateway-Konsole her.

1. Geben Sie die entsprechende Zahl ein, um die **Gateway-Konsole** auszuwählen, und geben Sie dann die Eingabetaste ein, um alle verfügbaren Befehle aufzulisten. `h` Führen Sie den folgenden Befehl aus, um die Konnektivität zwischen der virtuellen Storage Gateway Gateway-Maschine und der Domäne zu testen:

   `nping -d corp.domain.com -p 389 -c 1 -t tcp`
**Anmerkung**  
`corp.domain.com`Ersetzen Sie es durch den DNS-Namen Ihrer Active Directory-Domäne und `389` ersetzen Sie es durch den LDAP-Port für Ihre Umgebung.  
Stellen Sie sicher, dass Sie die erforderlichen Ports innerhalb Ihrer Firewall geöffnet haben.

Im Folgenden finden Sie ein Beispiel für einen erfolgreichen NPING-Test, bei dem das Gateway den Domänencontroller erreichen konnte:

```
nping -d corp.domain.com -p 389 -c 1 -t tcp

Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2022-06-30 16:24 UTC
SENT (0.0553s) TCP 10.10.10.21:9783 > 10.10.10.10:389 S ttl=64 id=730 iplen=40  seq=2597195024 win=1480 
RCVD (0.0556s) TCP 10.10.10.10:389 > 10.10.10.21:9783 SA ttl=128 id=22332 iplen=44  seq=4170716243 win=8192 <mss 8961>

Max rtt: 0.310ms | Min rtt: 0.310ms | Avg rtt: 0.310ms
Raw packets sent: 1 (40B) | Rcvd: 1 (44B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.09 seconds<br>
```

Im Folgenden finden Sie ein Beispiel für einen NPING-Test, bei dem keine Konnektivität zum Ziel besteht oder keine Antwort vom `corp.domain.com` Ziel erfolgt:

```
nping -d corp.domain.com -p 389 -c 1 -t tcp

Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2022-06-30 16:26 UTC
SENT (0.0421s) TCP 10.10.10.21:47196 > 10.10.10.10:389  S ttl=64 id=30318 iplen=40 seq=1762671338 win=1480

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 1 (40B) | Rcvd: 0 (0B) | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.07 seconds
```

## Überprüfen Sie die für die VPC Ihrer Amazon EC2 EC2-Gateway-Instance festgelegten DHCP-Optionen.
<a name="w2ab1c54c15b9"></a>

Wenn das File Gateway auf einer Amazon EC2 EC2-Instance läuft, müssen Sie sicherstellen, dass ein DHCP-Optionssatz ordnungsgemäß konfiguriert und an die Amazon Virtual Private Cloud (VPC) angehängt ist, die die Gateway-Instance enthält. Weitere Informationen finden Sie unter [DHCP-Optionssätze in Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html).

## Vergewissern Sie sich, dass das Gateway die Domain auflösen kann, indem Sie eine Dig-Abfrage ausführen
<a name="w2ab1c54c15c11"></a>

Wenn die Domäne vom Gateway nicht aufgelöst werden kann, kann das Gateway der Domäne nicht beitreten.

**Um eine Dig-Abfrage auszuführen:**

1. Stellen Sie mit Ihrer Hypervisor-Verwaltungssoftware (VMware, Hyper-V oder KVM) für lokale Gateways oder mit SSH für Amazon EC2 EC2-Gateways eine Connect zur lokalen Gateway-Konsole her.

1. Geben Sie die entsprechende Zahl ein, um die **Gateway-Konsole** auszuwählen, und geben Sie dann die Eingabetaste ein, um alle verfügbaren Befehle aufzulisten. `h` Führen Sie den folgenden Befehl aus, um zu testen, ob das Gateway die Domäne auflösen kann:

   `dig -d corp.domain.com`
**Anmerkung**  
`corp.domain.com`Ersetzen Sie es durch den DNS-Namen Ihrer Active Directory-Domäne.

Im Folgenden finden Sie ein Beispiel für eine erfolgreiche Antwort:

```
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> corp.domain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24817
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;corp.domain.com.        IN    A

;; ANSWER SECTION:
corp.domain.com.    600    IN    A    10.10.10.10
corp.domain.com.    600    IN    A    10.10.20.10
            
;; Query time: 0 msec
;; SERVER: 10.10.20.228#53(10.10.20.228)
;; WHEN: Thu Jun 30 16:36:32 UTC 2022
;; MSG SIZE  rcvd: 78
```

## Überprüfen Sie die Einstellungen und Rollen des Domänencontrollers
<a name="w2ab1c54c15c13"></a>

Vergewissern Sie sich, dass der Domänencontroller nicht schreibgeschützt ist und dass der Domänencontroller über genügend Rollen verfügt, sodass Computer diesem beitreten können. Um dies zu testen, versuchen Sie, andere Server aus demselben VPC-Subnetz wie die Gateway-VM mit der Domäne zu verbinden.

## Stellen Sie sicher, dass das Gateway mit dem nächstgelegenen Domänencontroller verbunden ist
<a name="w2ab1c54c15c15"></a>

Als bewährte Methode empfehlen wir, Ihr Gateway mit einem Domänencontroller zu verbinden, der sich geografisch in der Nähe des Gatewaygeräts befindet. Wenn das Gatewaygerät aufgrund der Netzwerklatenz nicht innerhalb von 20 Sekunden mit dem Domänencontroller kommunizieren kann, kann es beim Domänenbeitritt zu einem Timeout kommen. Beispielsweise kann es bei dem Vorgang zu einem Timeout kommen, wenn sich die Gateway-Appliance im Osten der USA (Nord-Virginia) AWS-Region und der Domänencontroller im asiatisch-pazifischen Raum (Singapur) befindet AWS-Region.

**Anmerkung**  
Um den standardmäßigen Timeoutwert von 20 Sekunden zu erhöhen, können Sie den [Befehl join-domain](https://docs.aws.amazon.com/cli/latest/reference/storagegateway/join-domain.html) in AWS Command Line Interface (AWS CLI) ausführen und die `--timeout-in-seconds` Option zur Verlängerung der Zeit hinzufügen. Sie können auch den [JoinDomain API-Aufruf](https://amazonaws.com/storagegateway/latest/APIReference/API_JoinDomain.html) verwenden und den `TimeoutInSeconds` Parameter hinzufügen, um die Zeit zu verlängern. Der maximale Timeout-Wert beträgt 3.600 Sekunden.  
Wenn Sie beim Ausführen von AWS CLI Befehlen Fehler erhalten, stellen Sie sicher, dass Sie die neueste AWS CLI Version verwenden.

## Vergewissern Sie sich, dass Active Directory neue Computerobjekte in der Standard-Organisationseinheit (OU) erstellt
<a name="w2ab1c54c15c17"></a>

Stellen Sie sicher, dass Microsoft Active Directory über keine Gruppenrichtlinienobjekte verfügt, die neue Computerobjekte an einem anderen Ort als der Standardorganisationseinheit erstellen. Bevor Sie Ihr Gateway der Active Directory-Domäne hinzufügen können, muss in der Standard-OU ein neues Computerobjekt vorhanden sein. Einige Active Directory-Umgebungen sind so angepasst, dass sie OUs für neu erstellte Objekte unterschiedlich sind. Um sicherzustellen, dass ein neues Computerobjekt für die Gateway-VM in der Standard-OU vorhanden ist, versuchen Sie, das Computerobjekt manuell auf Ihrem Domänencontroller zu erstellen, bevor Sie das Gateway der Domäne hinzufügen. Sie können den [Befehl join-domain auch mit dem ausführen](https://docs.aws.amazon.com/cli/latest/reference/storagegateway/join-domain.html). AWS CLI Geben Sie dann die Option für an. `--organizational-unit`

**Anmerkung**  
Der Prozess der Erstellung des Computerobjekts wird als Pre-Staging bezeichnet.

## Überprüfen Sie die Ereignisprotokolle Ihres Domänencontrollers
<a name="w2ab1c54c15c19"></a>

Wenn Sie das Gateway nicht mit der Domäne verbinden können, nachdem Sie alle anderen in den vorherigen Abschnitten beschriebenen Prüfungen und Konfigurationen ausprobiert haben, empfehlen wir, Ihre Domänencontroller-Ereignisprotokolle zu überprüfen. Suchen Sie in der Ereignisanzeige des Domänencontrollers nach Fehlern. Stellen Sie sicher, dass die Gatewayabfragen den Domänencontroller erreicht haben.

# Fehlerbehebung: interner Fehler bei der Gateway-Aktivierung
<a name="troubleshooting-gateway-activation"></a>

Storage Gateway Gateway-Aktivierungsanforderungen durchlaufen zwei Netzwerkpfade. Eingehende Aktivierungsanfragen, die von einem Client gesendet werden, stellen über Port 80 eine Verbindung zur virtuellen Maschine (VM) oder Amazon Elastic Compute Cloud (Amazon EC2) -Instance des Gateways her. Wenn das Gateway die Aktivierungsanfrage erfolgreich empfängt, kommuniziert das Gateway mit den Storage Gateway Gateway-Endpunkten, um einen Aktivierungsschlüssel zu erhalten. Wenn das Gateway die Storage Gateway Gateway-Endpunkte nicht erreichen kann, antwortet das Gateway dem Client mit einer internen Fehlermeldung.

Verwenden Sie die folgenden Informationen zur Fehlerbehebung, um zu ermitteln, was zu tun ist, wenn Sie beim Versuch, Ihren AWS Storage Gateway zu aktivieren, eine interne Fehlermeldung erhalten.

**Anmerkung**  
Stellen Sie sicher, dass Sie neue Gateways mit der neuesten Image-Datei für virtuelle Maschinen oder der neuesten Version von Amazon Machine Image (AMI) bereitstellen. Sie erhalten einen internen Fehler, wenn Sie versuchen, ein Gateway zu aktivieren, das ein veraltetes AMI verwendet.
Stellen Sie sicher, dass Sie den richtigen Gateway-Typ auswählen, den Sie bereitstellen möchten, bevor Sie das AMI herunterladen. Die OVA-Dateien AMIs für jeden Gateway-Typ sind unterschiedlich und nicht austauschbar.

## Beheben Sie Fehler bei der Aktivierung Ihres Gateways über einen öffentlichen Endpunkt
<a name="w2ab1c54c18b9"></a>

Um Aktivierungsfehler bei der Aktivierung Ihres Gateways über einen öffentlichen Endpunkt zu beheben, führen Sie die folgenden Prüfungen und Konfigurationen durch.

### Überprüfen Sie die erforderlichen Ports
<a name="w2ab1c54c18b9b5"></a>

Vergewissern Sie sich bei Gateways, die vor Ort bereitgestellt werden, dass die Ports auf Ihrer lokalen Firewall geöffnet sind. Überprüfen Sie bei Gateways, die auf einer Amazon EC2 EC2-Instance bereitgestellt werden, ob die Ports in der Sicherheitsgruppe der Instance geöffnet sind. Um zu überprüfen, ob die Ports geöffnet sind, führen Sie auf dem öffentlichen Endpunkt von einem Server aus einen Telnet-Befehl aus. Dieser Server muss sich im selben Subnetz wie das Gateway befinden. Mit den folgenden Telnet-Befehlen wird beispielsweise die Verbindung zu Port 443 getestet:

```
telnet d4kdq0yaxexbo.cloudfront.net 443
telnet storagegateway.region.amazonaws.com 443
telnet dp-1.storagegateway.region.amazonaws.com 443
telnet proxy-app.storagegateway.region.amazonaws.com 443
telnet client-cp.storagegateway.region.amazonaws.com 443
telnet anon-cp.storagegateway.region.amazonaws.com 443
```

Um zu überprüfen, ob das Gateway selbst den Endpunkt erreichen kann, greifen Sie auf die lokale VM-Konsole des Gateways zu (für lokal bereitgestellte Gateways). Oder Sie können eine SSH-Verbindung zur Gateway-Instance herstellen (für Gateways, die auf Amazon EC2 bereitgestellt werden). Führen Sie dann einen Netzwerkverbindungstest durch. Vergewissern Sie sich, dass der Test zurückkehrt`[PASSED]`. Weitere Informationen finden Sie unter [Testen der Netzwerkkonnektivität Ihres Gateways](https://docs.aws.amazon.com/filegateway/latest/filefsxw/manage-on-premises-fgw.html#MaintenanceTestGatewayConnectivity-fgw) .

**Anmerkung**  
Der Standard-Anmeldename für die Gateway-Konsole lautet`admin`, und das Standardkennwort ist`password`.

### Stellen Sie sicher, dass die Firewall-Sicherheit keine Pakete verändert, die vom Gateway an die öffentlichen Endpunkte gesendet werden
<a name="w2ab1c54c18b9b7"></a>

SSL-Inspektionen, Deep Packet Inspections oder andere Formen der Firewall-Sicherheit können die vom Gateway gesendeten Pakete beeinträchtigen. Der SSL-Handshake schlägt fehl, wenn das SSL-Zertifikat so geändert wird, wie es der Aktivierungsendpunkt erwartet. Um sicherzustellen, dass keine SSL-Inspektion im Gange ist, führen Sie einen OpenSSL-Befehl auf dem Hauptaktivierungsendpunkt (`anon-cp.storagegateway.region.amazonaws.com`) an Port 443 aus. Sie müssen diesen Befehl von einem Computer aus ausführen, der sich im selben Subnetz wie das Gateway befindet:

```
$ openssl s_client -connect  anon-cp.storagegateway.region.amazonaws.com:443 -servername anon-cp.storagegateway.region.amazonaws.com
```

**Anmerkung**  
Ersetze es *region* durch dein AWS-Region.

Wenn keine SSL-Überprüfung im Gange ist, gibt der Befehl eine Antwort zurück, die der folgenden ähnelt:

```
$ openssl s_client -connect anon-cp.storagegateway.us-east-2.amazonaws.com:443 -servername anon-cp.storagegateway.us-east-2.amazonaws.com
CONNECTED(00000003)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = anon-cp.storagegateway.us-east-2.amazonaws.com
verify return:1
---
Certificate chain
 0 s:/CN=anon-cp.storagegateway.us-east-2.amazonaws.com
   i:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
 1 s:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
   i:/C=US/O=Amazon/CN=Amazon Root CA 1
 2 s:/C=US/O=Amazon/CN=Amazon Root CA 1
   i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
 3 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
   i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
---
```

Wenn eine laufende SSL-Inspektion stattfindet, zeigt die Antwort eine veränderte Zertifikatskette, die der folgenden ähnelt:

```
$ openssl s_client -connect  anon-cp.storagegateway.ap-southeast-1.amazonaws.com:443 -servername anon-cp.storagegateway.ap-southeast-1.amazonaws.com
CONNECTED(00000003)
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.ap-southeast-1.amazonaws.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.ap-southeast-1.amazonaws.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/DC=com/DC=amazonaws/OU=AWS/CN=anon-cp.storagegateway.ap-southeast-1.amazonaws.com
   i:/C=IN/O=Company/CN=Admin/ST=KA/L=New town/OU=SGW/emailAddress=admin@company.com
---
```

Der Aktivierungsendpunkt akzeptiert SSL-Handshakes nur, wenn er das SSL-Zertifikat erkennt. Das bedeutet, dass der ausgehende Datenverkehr des Gateways zu den Endpunkten von Inspektionen ausgenommen werden muss, die von Firewalls in Ihrem Netzwerk durchgeführt werden. Bei diesen Inspektionen kann es sich um eine SSL-Inspektion oder eine Deep Packet Inspection handeln.

### Überprüfen Sie die Gateway-Zeitsynchronisierung
<a name="w2ab1c54c18b9b9"></a>

Übermäßige Zeitverschiebungen können zu SSL-Handshake-Fehlern führen. Bei lokalen Gateways können Sie die lokale VM-Konsole des Gateways verwenden, um die Zeitsynchronisierung Ihres Gateways zu überprüfen. Der Zeitversatz sollte nicht größer als 60 Sekunden sein. 

Die Option **System Time Management** ist auf Gateways, die auf Amazon EC2 EC2-Instances gehostet werden, nicht verfügbar. Um sicherzustellen, dass Amazon EC2 EC2-Gateways die Zeit ordnungsgemäß synchronisieren können, stellen Sie sicher, dass die Amazon EC2 EC2-Instance über die Ports UDP und TCP 123 eine Verbindung zur folgenden NTP-Serverpool-Liste herstellen kann:
+ time.aws.com
+ 0.amazon.pool.ntp.org
+ 1.amazon.pool.ntp.org
+ 2.amazon.pool.ntp.org
+ 3.amazon.pool.ntp.org

## Beheben Sie Fehler bei der Aktivierung Ihres Gateways über einen Amazon VPC-Endpunkt
<a name="w2ab1c54c18c11"></a>

Um Aktivierungsfehler bei der Aktivierung Ihres Gateways über einen Amazon Virtual Private Cloud (Amazon VPC) -Endpunkt zu beheben, führen Sie die folgenden Prüfungen und Konfigurationen durch.

### Überprüfen Sie die erforderlichen Ports
<a name="w2ab1c54c18c11b5"></a>

Stellen Sie sicher, dass die erforderlichen Ports innerhalb Ihrer lokalen Firewall (für lokal bereitgestellte Gateways) oder Sicherheitsgruppe (für in Amazon EC2 bereitgestellte Gateways) geöffnet sind. Die Ports, die für die Verbindung eines Gateways mit einem Storage Gateway Gateway-VPC-Endpunkt erforderlich sind, unterscheiden sich von denen, die für die Verbindung eines Gateways mit öffentlichen Endpunkten erforderlich sind. Die folgenden Ports sind für die Verbindung mit einem Storage Gateway Gateway-VPC-Endpunkt erforderlich:
+ TCP 443
+ TCP 1026
+ TCP 1027
+ TCP 1028
+ TCP 1031
+ TCP 2222

Weitere Informationen finden Sie unter [Erstellen eines VPC-Endpunkts für Storage Gateway](https://docs.aws.amazon.com/filegateway/latest/filefsxw/gateway-private-link.html#create-vpc-endpoint) für Storage Gateway.

Überprüfen Sie außerdem die Sicherheitsgruppe, die an Ihren Storage Gateway Gateway-VPC-Endpunkt angehängt ist. Die dem Endpunkt zugeordnete Standardsicherheitsgruppe lässt möglicherweise nicht die erforderlichen Ports zu. Erstellen Sie eine neue Sicherheitsgruppe, die Datenverkehr aus dem IP-Adressbereich Ihres Gateways über die erforderlichen Ports zulässt. Fügen Sie dann diese Sicherheitsgruppe dem VPC-Endpunkt hinzu.

**Anmerkung**  
Verwenden Sie die [Amazon VPC-Konsole](https://console.aws.amazon.com//vpc/), um die Sicherheitsgruppe zu überprüfen, die mit dem VPC-Endpunkt verbunden ist. Sehen Sie sich Ihren Storage Gateway Gateway-VPC-Endpunkt von der Konsole aus an und wählen Sie dann die Registerkarte **Sicherheitsgruppen** aus.

Um zu überprüfen, ob die erforderlichen Ports geöffnet sind, können Sie Telnet-Befehle auf dem Storage Gateway Gateway-VPC-Endpunkt ausführen. Sie müssen diese Befehle von einem Server aus ausführen, der sich im selben Subnetz wie das Gateway befindet. Sie können die Tests für den ersten DNS-Namen ausführen, der keine Availability Zone angibt. Mit den folgenden Telnet-Befehlen werden beispielsweise die erforderlichen Portverbindungen mithilfe des DNS-Namens vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com getestet:

```
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 443
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1026
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1027
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1028
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1031
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 2222
```

### Stellen Sie sicher, dass die Firewall-Sicherheit keine Pakete verändert, die vom Gateway an Ihren Storage Gateway Amazon VPC-Endpunkt gesendet werden.
<a name="w2ab1c54c18c11b7"></a>

SSL-Inspektionen, Deep Packet Inspections oder andere Formen der Firewall-Sicherheit können die vom Gateway gesendeten Pakete beeinträchtigen. Der SSL-Handshake schlägt fehl, wenn das SSL-Zertifikat so geändert wird, wie es der Aktivierungsendpunkt erwartet. Um sicherzustellen, dass keine SSL-Inspektion im Gange ist, führen Sie einen OpenSSL-Befehl auf Ihrem Storage Gateway Gateway-VPC-Endpunkt aus. Sie müssen diesen Befehl von einem Computer aus ausführen, der sich im selben Subnetz wie das Gateway befindet. Führen Sie den Befehl für jeden erforderlichen Port aus:

```
$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:443 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1026 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1028 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1031 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:2222 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
```

Wenn keine SSL-Überprüfung durchgeführt wird, gibt der Befehl eine Antwort zurück, die der folgenden ähnelt:

```
openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
CONNECTED(00000005)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = anon-cp.storagegateway.us-east-1.amazonaws.com
verify return:1
---
Certificate chain
 0 s:CN = anon-cp.storagegateway.us-east-1.amazonaws.com
   i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
 1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
   i:C = US, O = Amazon, CN = Amazon Root CA 1
 2 s:C = US, O = Amazon, CN = Amazon Root CA 1
   i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
 3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
   i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
---
```

Wenn eine laufende SSL-Inspektion stattfindet, zeigt die Antwort eine veränderte Zertifikatskette, die der folgenden ähnelt:

```
openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
CONNECTED(00000005)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.us-east-1.amazonaws.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/DC=com/DC=amazonaws/OU=AWS/CN=anon-cp.storagegateway.us-east-1.amazonaws.com
   i:/C=IN/O=Company/CN=Admin/ST=KA/L=New town/OU=SGW/emailAddress=admin@company.com
---
```

Der Aktivierungsendpunkt akzeptiert SSL-Handshakes nur, wenn er das SSL-Zertifikat erkennt. Das bedeutet, dass der ausgehende Datenverkehr des Gateways zu Ihrem VPC-Endpunkt über die erforderlichen Ports von den Inspektionen Ihrer Netzwerk-Firewalls ausgenommen ist. Bei diesen Inspektionen kann es sich um SSL-Inspektionen oder Deep-Packet-Inspektionen handeln.

### Überprüfen Sie die Gateway-Zeitsynchronisierung
<a name="w2ab1c54c18c11b9"></a>

Übermäßige Zeitverschiebungen können zu SSL-Handshake-Fehlern führen. Bei lokalen Gateways können Sie die lokale VM-Konsole des Gateways verwenden, um die Zeitsynchronisierung Ihres Gateways zu überprüfen. Der Zeitversatz sollte nicht größer als 60 Sekunden sein. 

Die Option **System Time Management** ist auf Gateways, die auf Amazon EC2 EC2-Instances gehostet werden, nicht verfügbar. Um sicherzustellen, dass Amazon EC2 EC2-Gateways die Zeit ordnungsgemäß synchronisieren können, stellen Sie sicher, dass die Amazon EC2 EC2-Instance über die Ports UDP und TCP 123 eine Verbindung zur folgenden NTP-Serverpool-Liste herstellen kann:
+ 0.amazon.pool.ntp.org
+ 1.amazon.pool.ntp.org
+ 2.amazon.pool.ntp.org
+ 3.amazon.pool.ntp.org

### Suchen Sie nach einem HTTP-Proxy und bestätigen Sie die zugehörigen Sicherheitsgruppeneinstellungen
<a name="w2ab1c54c18c11c11"></a>

Prüfen Sie vor der Aktivierung, ob Sie einen HTTP-Proxy auf Amazon EC2 auf der lokalen Gateway-VM als Squid-Proxy auf Port 3128 konfiguriert haben. Bestätigen Sie in diesem Fall Folgendes:
+ Die Sicherheitsgruppe, die an den HTTP-Proxy auf Amazon EC2 angehängt ist, muss über eine Regel für eingehenden Datenverkehr verfügen. Diese Regel für eingehenden Datenverkehr muss Squid-Proxyverkehr auf Port 3128 von der IP-Adresse der Gateway-VM aus zulassen.
+ Die Sicherheitsgruppe, die dem Amazon EC2 VPC-Endpunkt zugeordnet ist, muss Regeln für eingehenden Datenverkehr haben. Diese Regeln für eingehenden Datenverkehr müssen den Verkehr auf den Ports 1026-1028, 1031, 2222 und 443 von der IP-Adresse des HTTP-Proxys auf Amazon EC2 zulassen.

## Beheben Sie Fehler, wenn Sie Ihr Gateway über einen öffentlichen Endpunkt aktivieren und es in derselben VPC einen Storage Gateway Gateway-VPC-Endpunkt gibt
<a name="w2ab1c54c18c13"></a>

Um Fehler bei der Aktivierung Ihres Gateways über einen öffentlichen Endpunkt zu beheben, wenn sich in derselben VPC ein Amazon Virtual Private Cloud (Amazon VPC) -Endpoint befindet, führen Sie die folgenden Prüfungen und Konfigurationen durch.

### Vergewissern Sie sich, dass die Einstellung **Privaten DNS-Namen aktivieren** auf Ihrem Storage Gateway Gateway-VPC-Endpunkt nicht aktiviert ist
<a name="w2ab1c54c18c13b5"></a>

Wenn **Enable Private DNS Name** aktiviert ist, können Sie keine Gateways von dieser VPC zum öffentlichen Endpunkt aktivieren.

**Gehen Sie wie folgt vor, um die Option für private DNS-Namen zu deaktivieren:**

1. Öffnen Sie die [Amazon VPC-Konsole](https://console.aws.amazon.com//vpc/).

1. Wählen Sie im Navigationsbereich **Endpunkte** aus.

1. Wählen Sie Ihren Storage Gateway VPC-Endpunkt.

1. Wählen Sie **Aktionen**.

1. Wählen Sie **Private DNS-Namen verwalten** aus.

1. Deaktivieren **Sie für „Privaten DNS-Namen** **aktivieren“ die Option „Für diesen Endpunkt** aktivieren“.

1. Wählen Sie **Private DNS-Namen ändern**, um die Einstellung zu speichern.

# Fehlerbehebung: Probleme mit dem lokalen Gateway
<a name="troubleshooting-on-premises-gateway-issues"></a>

Im Folgenden finden Sie Informationen zu typischen Problemen, die bei der Arbeit mit Ihren lokalen Gateways auftreten können, und darüber, wie Sie eine Verbindung zu Ihrem Gateway herstellen können Support , um Sie bei der Fehlerbehebung zu unterstützen.

Die folgende Tabelle listet typische Probleme auf, die möglicherweise im Umgang mit Ihren lokalen Gateways auftreten.


| Problem | Maßnahme | 
| --- | --- | 
| Sie können die IP-Adresse Ihrer Gateway nicht ermitteln.  |  Verwenden Sie den Hypervisor-Client zum Herstellen einer Verbindung mit Ihrem Host, um die Gateway-IP-Adresse zu ermitteln. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html) Wenn Sie immer noch Probleme haben die Gateway-IP-Adresse zu ermitteln: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html)  | 
| Sie haben Netzwerk- oder Firewall-Probleme.  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html)  | 
|  Die Aktivierung des Gateways schlägt fehl, wenn Sie in der Storage-Gateway-Managementkonsole auf die Schaltfläche **Weiter zur Aktivierung** klicken.  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html)  | 
|  Sie müssen die Bandbreite zwischen Ihrem Gateway und AWS verbessern.  |  Sie können die Bandbreite zwischen Ihrem Gateway und verbessern, AWS indem Sie Ihre Internetverbindung AWS auf einem Netzwerkadapter (NIC) einrichten, der von dem Netzwerkadapter (NIC) getrennt ist, der Ihre Anwendungen und die Gateway-VM verbindet. Dieser Ansatz ist nützlich, wenn Sie über eine Verbindung mit hoher Bandbreite verfügen AWS und Bandbreitenkonflikte vermeiden möchten, insbesondere bei einer Snapshot-Wiederherstellung. Für Workloads mit hohem Durchsatz können Sie [Direct Connect](https://aws.amazon.com/directconnect/) verwenden, um eine dedizierte Netzwerkverbindung zwischen dem lokalen Gateway und AWS herzustellen. Verwenden Sie die `CloudBytesUploaded` Metriken `CloudBytesDownloaded` und des Gateways AWS, um die Bandbreite der Verbindung von Ihrem Gateway zu zu messen. Weitere Informationen zu diesem Thema finden Sie unter [Leistung und Optimierung](Performance.md). Indem Sie Ihre Internetverbindung verbessern, stellen Sie sicher, dass Ihr Upload-Puffer nicht aufgefüllt wird.  | 
|  Durchsatz zu oder von Ihrem Gateway sinkt auf Null.  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html) Sie können den Durchsatz zu und von Ihrem Gateway von der CloudWatch Amazon-Konsole aus anzeigen. Weitere Informationen zur Messung des Durchsatzes zu und von Ihrem Gateway zu AWS finden Sie unter[Leistung und Optimierung](Performance.md).  | 
|  Sie haben Schwierigkeiten mit dem Importieren (Bereitstellen) von Storage Gateway auf Microsoft Hyper-V.  |  Weitere Informationen finden Sie unter [Problembehandlung: Microsoft Hyper-V-Setup](troubleshooting-hyperv-setup.md), in dem einige der gängigen Themen der Bereitstellung einer Gateway auf Microsoft Hyper-V diskutiert werden.  | 
|  Sie erhalten die Fehlermeldung: „Die Daten, die in das Volume in Ihrem Gateway geschrieben wurden, sind nicht sicher bei AWS gespeichert.“  |  Sie erhalten diese Meldung, wenn Ihre Gateway-VM aus einem Klon oder Snapshot eine andere Gateway-VM erstellt wurde. Wenn dies nicht der Fall ist, wenden Sie sich an den Support.  | 

## Aktivieren Sie den Support Zugriff, um die Fehlerbehebung für Ihr lokal gehostetes Gateway zu erleichtern
<a name="enable-support-access-on-premises"></a>

Storage Gateway stellt eine lokale Konsole zur Verfügung, mit der Sie verschiedene Wartungsaufgaben ausführen können, einschließlich des Zugriffs auf Ihr Gateway, um Sie bei der Behebung von Gateway-Problemen zu unterstützen. Support Standardmäßig ist der Support Zugriff auf Ihr Gateway deaktiviert. Sie aktivieren diesen Zugriff über die lokale Konsole des Hosts. Um Support Zugriff auf Ihr Gateway zu gewähren, melden Sie sich zunächst bei der lokalen Konsole für den Host an, navigieren zur Konsole des Storage Gateways und stellen dann eine Verbindung zum Support-Server her.

**Um den Support Zugriff auf Ihr Gateway zu aktivieren**

1. Melden Sie sich bei der lokalen Konsole Ihres Hosts an.
   + VMware ESXi — Weitere Informationen finden Sie unter[Zugreifen auf die lokale Gateway-Konsole mit VMware ESXi](accessing-local-console.md#MaintenanceConsoleWindowVMware-common).
   + Microsoft Hyper-V: Weitere Informationen finden Sie unter [Zugreifen auf die lokale Gateway-Konsole mit Microsoft Hyper-V](accessing-local-console.md#MaintenanceConsoleWindowHyperV-common).

1. Geben Sie bei der Eingabeaufforderung die entsprechende Zahl ein, um **Gateway-Konsole** auszuwählen.

1. Geben Sie **h** ein, um die Liste der verfügbaren Befehle zu öffnen.

1. 

   Führen Sie eine der folgenden Aktionen aus:
   + Wenn Ihr Gateway einen öffentlichen Endpunkt verwendet, geben Sie im Fenster **VERFÜGBARE BEFEHLE** **open-support-channel** ein, um eine Verbindung zum Storage-Gateway-Kundensupport herzustellen. Geben Sie TCP-Port 22 frei, damit Sie einen Support-Kanal für AWSöffnen können. Wenn Sie eine Verbindung mit dem Kunden-Support herstellen, weist Ihnen Storage Gateway eine Support-Nummer zu. Notieren Sie sich Ihre Support-Nummer.
   + Wenn Ihr Gateway einen VPC-Endpunkt verwendet, geben Sie im Fenster **AVAILABLE COMMANDS (VERFÜGBARE BEFEHLE)** **open-support-channel** ein. Wenn Ihr Gateway nicht aktiviert ist, geben Sie den VPC-Endpunkt oder die IP-Adresse ein, für die eine Verbindung mit dem Storage-Gateway-Kundensupport hergestellt werden soll. Geben Sie TCP-Port 22 frei, damit Sie einen Support-Kanal für AWSöffnen können. Wenn Sie eine Verbindung mit dem Kunden-Support herstellen, weist Ihnen Storage Gateway eine Support-Nummer zu. Notieren Sie sich Ihre Support-Nummer.
**Anmerkung**  
Die Kanalnummer ist keine Portnummer (Transmission ControlProtocol/User Datagram Protocol (TCP/UDP). Stattdessen stellt das Gateway eine Secure Shell (SSH) (TCP 22)-Verbindung zu den Storage-Gateway-Servern her und stellt den Support-Kanal für die Verbindung bereit.

1. Nachdem der Support-Kanal eingerichtet wurde, geben Sie Ihre Support-Servicenummer an, Support damit wir Ihnen bei der Fehlerbehebung weiterhelfen Support können.

1. Wenn die Supportsitzung beendet ist, geben Sie **q** ein, um sie zu beenden. Schließen Sie die Sitzung erst, wenn Sie vom Amazon Web Services Support darüber informiert werden, dass die Support-Sitzung abgeschlossen ist.

1. Geben Sie **exit** ein, um sich von der Storage-Gateway-Konsole abzumelden.

1. Folgen Sie den Eingabeaufforderungen, um die lokale Konsole zu beenden.

# Problembehandlung: Microsoft Hyper-V-Setup
<a name="troubleshooting-hyperv-setup"></a>

In der folgenden Tabelle sind typische Probleme aufgeführt, die beim Bereitstellen von Storage Gateway auf der Microsoft Hyper-V-Plattform auftreten können.


| Problem | Maßnahme | 
| --- | --- | 
| Sie versuchen, ein Gateway zu importieren und erhalten die folgende Fehlermeldung: „Beim Versuch, die virtuelle Maschine zu importieren, ist ein Serverfehler aufgetreten. Der Import ist fehlgeschlagen. Die Importdateien der virtuellen Maschine konnten unter dem Speicherort [...] nicht gefunden werden. Sie können eine virtuelle Maschine nur importieren, wenn Sie sie mit Hyper-V erstellt und exportiert haben.“  |  Dieser Fehler kann aus folgenden Gründen auftreten: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/filegateway/latest/filefsxw/troubleshooting-hyperv-setup.html)  | 
|  Sie versuchen, ein Gateway zu importieren, und erhalten die folgende Fehlermeldung: „Beim Versuch, die virtuelle Maschine zu importieren, ist ein Serverfehler aufgetreten. Der Import ist fehlgeschlagen. Die Importaufgabe konnte die Datei nicht von [...] kopieren: Die Datei existiert. (0x80070050)“  |  Wenn Sie bereits ein Gateway bereitgestellt haben und Sie versuchen den Standard-Ordner wiederzuverwenden, der die virtuelle Festplatten Dateien und die virtuelle Maschinen-Konfigurationsdateien speichert, wird dieser Fehler auftreten. Um dieses Problem zu beheben, geben Sie im Bereich auf der linken Seite des Dialogfelds **Hyper-V-Einstellungen** unter **Server** neue Speicherorte an.  | 
|  Sie versuchen, ein Gateway zu importieren, und erhalten die folgende Fehlermeldung: „Beim Versuch, die virtuelle Maschine zu importieren, ist ein Serverfehler aufgetreten. Der Import ist fehlgeschlagen. Der Import ist fehlgeschlagen, da die virtuelle Maschine über eine neue ID verfügen muss. Wählen Sie eine ID und versuchen Sie erneut zu importieren.“  |  Stellen Sie beim Import des Gateways sicher, dass Sie **die Option Virtuelle Maschine kopieren** auswählen und im Dialogfeld **Virtuelle Maschine importieren** das Kontrollkästchen **Alle Dateien duplizieren** aktivieren, um eine neue eindeutige ID für die VM zu erstellen.  | 
|  Sie versuchen, eine Gateway-VM zu starten und erhalten die folgende Fehlermeldung: „Beim Versuch, die ausgewählten virtuellen Maschinen zu starten, ist ein Fehler aufgetreten. Die Prozessor-Einstellung für die untergeordnete Partition ist nicht mit der übergeordneten Partition kompatibel. 'AWS-Storage-Gateway' konnte nicht initialisiert werden. (ID der virtuellen Maschine [...])“  | Dieser Fehler wird wahrscheinlich durch eine CPU-Diskrepanz zwischen den CPUs für das Gateway erforderlichen und den CPUs auf dem Host verfügbaren Werten verursacht. Stellen Sie sicher, dass die VM-CPU-Inventur von der zugrunde liegenden Hypervisor unterstützt wird. Weitere Informationen zu den Anforderungen für Storage Gateway finden Sie unter [Setup-Anforderungen für File Gateway](Requirements.md). | 
|  Sie versuchen, eine Gateway-VM zu starten und erhalten die folgende Fehlermeldung: „Beim Versuch, die ausgewählten virtuellen Maschinen zu starten, ist ein Fehler aufgetreten. 'AWS-Storage-Gateway' konnte nicht initialisiert werden. (ID der virtuellen Maschine [...]) Partition konnte nicht erstellt werden: Es sind nicht genügend Systemressourcen vorhanden, um den angeforderten Dienst abzuschließen. (0x800705AA)“  |  Dieser Fehler wird wahrscheinlich durch eine RAM-Abweichungen zwischen dem erforderlichen RAM für das Gateway und den verfügbaren RAM auf dem Host verursacht. Weitere Informationen zu den Anforderungen für Storage Gateway finden Sie unter [Setup-Anforderungen für File Gateway](Requirements.md).  | 
|  Ihre Snapshots und Gateway-Software-Aktualisierungen treten zu geringfügig anderen Zeiten als erwartet auf.  |  Die Uhr der Gateway-VM, weicht möglicherweise von der tatsächlichen Uhrzeit ab, dies wird als Ganggenauigkeit bezeichnet. Überprüfen und korrigieren Sie die Uhrzeit der VM, indem Sie die Option Synchronisierung der lokalen Gateway-Konsole verwenden. Weitere Informationen finden Sie unter [Konfiguration eines NTP-Servers (Network Time Protocol) für Ihr Gateway](MaintenanceTimeSync-fgw.md).  | 
|  Sie müssen die entzippten Microsoft Hyper-V-Dateien für Storage Gateway im Host-Dateisystem ablegen.  |  Greifen Sie auf den Host zu wie Sie auf einen typischen Microsoft Windows Server zugreifen würden. Zum Beispiel: Wenn der Hypervisor Host-Name `hyperv-server` lautet, dann können Sie den folgenden UNC-Pfad wählen `\\hyperv-server\c$`, dieser geht davon aus, dass der Name `hyperv-server` in Ihrer lokalen Host-Datei aufgelöst oder definiert werden kann.  | 
|  Sie werden aufgefordert Anmeldeinformationen anzugeben, wenn Sie eine Verbindung zum Hypervisor herstellen.  |  Fügen Sie Ihre Benutzer-Anmeldeinformationen als lokaler Administrator für den Hypervisor-Host mithilfe des Sconfig.cmd Tool hinzu.  | 
|  Möglicherweise stellen Sie eine schlechte Netzwerkleistung fest, wenn Sie die Virtual Machine Queue (VMQ) für einen Hyper-V-Host aktivieren, der einen Broadcom-Netzwerkadapter verwendet.  |  Informationen zu einer Problemumgehung finden Sie in der Microsoft-Dokumentation unter [Schlechte Netzwerkleistung auf virtuellen Maschinen auf einem Windows Server 2012 Hyper-V-Host, wenn VMQ](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/poor-network-performance-hyper-v-host-vm) eingeschaltet ist.  | 

# Fehlerbehebung: Probleme mit dem Amazon EC2 EC2-Gateway
<a name="troubleshooting-EC2-gateway-issues"></a>

In den folgenden Abschnitten werden typische Probleme beschrieben, die bei der Arbeit mit dem auf Amazon EC2 bereitgestellten Gateway auftreten können. Weitere Informationen über den Unterschied zwischen einem On-Premises-Gateway und einem Gateway, das auf Amazon EC2 bereitgestellt ist, finden Sie unter [Stellen Sie einen Amazon EC2 EC2-Standardhost für FSx File Gateway bereitStellen Sie einen benutzerdefinierten Amazon EC2 EC2-Host für FSx File Gateway bereit](ec2-gateway-file.md).

**Topics**
+ [Die Aktivierung Ihres Gateways ist nach einigen Momenten nicht erfolgt.](#activation-issues)
+ [EC2-Gateway-Instance in der Instance-Liste nicht gefunden](#find-instance)
+ [Sie möchten sich mit Ihrer Gateway-Instance über die serielle Amazon-EC2-Konsole verbinden](#ec2-serial-console)
+ [Sie Support möchten bei der Fehlerbehebung für Ihr Amazon EC2 EC2-Gateway helfen](#EC2-EnableAWSSupportAccess)

## Die Aktivierung Ihres Gateways ist nach einigen Momenten nicht erfolgt.
<a name="activation-issues"></a>

Prüfen Sie in der Amazon-EC2-Konsole Folgendes:
+ Port 80 ist in der Sicherheitsgruppe geöffnet, die Sie der Instance zugeordnet haben. Weitere Informationen zum Hinzufügen einer Sicherheitsgruppenregel finden Sie unter [Hinzufügen einer Sicherheitsgruppenregel](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html#adding-security-group-rule) im *Amazon EC2 EC2-Benutzerhandbuch*.
+ Die Gateway-Instance ist als laufend markiert. In der Amazon-EC2-Konsole für die Instance sollte der **State**-Wert der Instance RUNNING lauten.
+ Stellen Sie sicher, dass der Typ der Amazon-EC2-Instance die unter [Speicheranforderungen](Requirements.md#requirements-storage) beschriebenen Mindestanforderungen erfüllt.

Versuchen Sie erneut, das Gateway zu aktivieren, nachdem Sie das Problem behoben haben. Öffnen Sie dazu die Storage-Gateway-Konsole, wählen Sie **Neues Gateway auf Amazon EC2 bereitstellen** aus und geben Sie die IP-Adresse der Instance erneut ein.

## EC2-Gateway-Instance in der Instance-Liste nicht gefunden
<a name="find-instance"></a>

Wenn Sie die Instance nicht mit einem Ressourcen-Tag versehen haben und viele Instances ausführt werden, ist es schwierig, die von Ihnen gestarteten Instances zu benennen. In diesem Fall können Sie die folgenden Aktionen ausführen, um die Gateway Instance zu finden:
+ Prüfen Sie den Namen des Amazon Machine Image (AMI) auf der Registerkarte **Description (Beschreibung)** der Instance. Eine Instance auf der Grundlage der Storage Gateway AMI muss mit dem Text **aws-storage-gateway-ami** beginnen.
+ Wenn Sie über mehrere Instances verfügen, die auf der Storage Gateway AMI basieren, prüfen Sie die Startzeit der Instance, um die richtige Instance zu finden.

## Sie möchten sich mit Ihrer Gateway-Instance über die serielle Amazon-EC2-Konsole verbinden
<a name="ec2-serial-console"></a>

Sie können die serielle Amazon-EC2-Konsole zur Fehlerbehebung beim Booten, bei der Netzwerkkonfiguration und anderen Problemen verwenden. Anweisungen und Tipps zur Fehlerbehebung finden Sie unter [Serielle Amazon-EC2-Konsole](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-serial-console.html) im *Benutzerhandbuch zu Amazon Elastic Compute Cloud*.

## Sie Support möchten bei der Fehlerbehebung für Ihr Amazon EC2 EC2-Gateway helfen
<a name="EC2-EnableAWSSupportAccess"></a>

Storage Gateway stellt eine lokale Konsole zur Verfügung, mit der Sie verschiedene Wartungsaufgaben ausführen können, einschließlich des Zugriffs auf Ihr Gateway, um Sie bei der Behebung von Gateway-Problemen zu unterstützen. Support Standardmäßig ist der Support Zugriff auf Ihr Gateway deaktiviert. Sie aktivieren diesen Zugriff über die lokale Amazon EC2 EC2-Konsole. Sie melden sich über Secure Shell (SSH) bei der lokalen Amazon-EC2-Konsole an. Für eine erfolgreiche Anmeldung über SSH, muss die Sicherheitsgruppe Ihrer Instance über eine Regel verfügen, die den TCP-Port 22 öffnet.

**Anmerkung**  
Wenn Sie eine neue Regel zu einer vorhandenen Sicherheitsgruppe hinzufügen, gilt die neue Regel für alle Instances, die diese Sicherheitsgruppe nutzen. Weitere Informationen zu Sicherheitsgruppen und zum Hinzufügen einer Sicherheitsgruppenregel finden Sie unter [Amazon-EC2-Sicherheitsgruppen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) im *Amazon-EC2-Benutzerhandbuch*.

Um eine Support Verbindung zu Ihrem Gateway herzustellen, melden Sie sich zunächst bei der lokalen Konsole für die Amazon EC2 EC2-Instance an, navigieren zur Storage Gateway-Konsole und gewähren dann den Zugriff.

**So aktivieren Sie den Support Zugriff für ein Gateway, das auf einer Amazon EC2 EC2-Instance bereitgestellt ist**

1. Melden Sie sich bei der lokalen Konsole für Ihre Amazon-EC2-Instance an. Weitere Informationen finden Sie unter [Herstellen einer Verbindung zu Ihrer Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) im *Amazon-EC2-Benutzerhandbuch*.

   Sie können den folgenden Befehl verwenden, um sich bei der lokalen EC2-Konsole der Instance anzumelden.

   ```
   ssh –i PRIVATE-KEY admin@INSTANCE-PUBLIC-DNS-NAME
   ```
**Anmerkung**  
Das *PRIVATE-KEY* ist die `.pem` Datei, die das private Zertifikat des EC2-Schlüsselpaars enthält, das Sie zum Starten der Amazon EC2 EC2-Instance verwendet haben. Weitere Informationen finden Sie unter [Abrufen des öffentlichen Schlüssels für Ihr Schlüsselpaar](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#retriving-the-public-key) im *Amazon-EC2-Benutzerhandbuch*.  
Das *INSTANCE-PUBLIC-DNS-NAME* ist der öffentliche DNS-Name (Domain Name System) Ihrer Amazon EC2 EC2-Instance, auf der Ihr Gateway läuft. Sie erhalten diesen öffentlichen DNS-Namen, indem Sie die Amazon-EC2-Instance in der EC2-Konsole auswählen und auf die Registerkarte **Beschreibung** klicken.

1. Geben Sie an der Eingabeaufforderung **6 - Command Prompt** ein, um die Channel-Konsole für Support zu öffnen.

1. Geben Sie **h** ein, um das Fenster **AVAILABLE COMMANDS (VERFÜGBARE BEFEHLE)** zu öffnen.

1. Führen Sie eine der folgenden Aktionen aus:
   + Wenn Ihr Gateway einen öffentlichen Endpunkt verwendet, geben Sie im Fenster **VERFÜGBARE BEFEHLE** **open-support-channel** ein, um eine Verbindung zum Storage-Gateway-Kundensupport herzustellen. Geben Sie TCP-Port 22 frei, damit Sie einen Support-Kanal für AWSöffnen können. Wenn Sie eine Verbindung mit dem Kunden-Support herstellen, weist Ihnen Storage Gateway eine Support-Nummer zu. Notieren Sie sich Ihre Support-Nummer.
   + Wenn Ihr Gateway einen VPC-Endpunkt verwendet, geben Sie im Fenster **AVAILABLE COMMANDS (VERFÜGBARE BEFEHLE)** **open-support-channel** ein. Wenn Ihr Gateway nicht aktiviert ist, geben Sie den VPC-Endpunkt oder die IP-Adresse ein, für die eine Verbindung mit dem Storage-Gateway-Kundensupport hergestellt werden soll. Geben Sie TCP-Port 22 frei, damit Sie einen Support-Kanal für AWSöffnen können. Wenn Sie eine Verbindung mit dem Kunden-Support herstellen, weist Ihnen Storage Gateway eine Support-Nummer zu. Notieren Sie sich Ihre Support-Nummer.
**Anmerkung**  
Die Kanalnummer ist keine Portnummer (Transmission ControlProtocol/User Datagram Protocol (TCP/UDP). Stattdessen stellt das Gateway eine Secure Shell (SSH) (TCP 22)-Verbindung zu den Storage-Gateway-Servern her und stellt den Support-Kanal für die Verbindung bereit.

1. Nachdem der Support-Kanal eingerichtet wurde, geben Sie Ihre Support-Servicenummer an, Support damit wir Ihnen bei der Fehlerbehebung weiterhelfen Support können.

1. Wenn die Supportsitzung beendet ist, geben Sie **q** ein, um sie zu beenden. Schließen Sie die Sitzung erst, wenn Sie vom Amazon Web Services Support darüber informiert werden, dass die Support-Sitzung abgeschlossen ist.

1. Geben Sie **exit** ein, um die Storage-Gateway-Konsole zu verlassen.

1. Verwenden Sie die Konsolenmenüs, um sich von der Storage-Gateway-Instance abzumelden.

# Fehlerbehebung: Probleme mit der Hardware-Appliance
<a name="troubleshooting-hardware-appliance-issues"></a>

**Anmerkung**  
Hinweis zum Ende der Verfügbarkeit: Ab dem 12. Mai 2025 wird die AWS Storage Gateway Hardware-Appliance nicht mehr angeboten. Bestandskunden mit der AWS Storage Gateway Hardware-Appliance können die Hardware-Appliance bis Mai 2028 weiter nutzen und Support erhalten. Alternativ können Sie den AWS Storage Gateway Service nutzen, um Ihren Anwendungen vor Ort und in der Cloud Zugriff auf praktisch unbegrenzten Cloud-Speicher zu gewähren.

In den folgenden Themen werden Probleme behandelt, die bei der AWS Storage Gateway Hardware-Appliance auftreten können, sowie Vorschläge zu deren Behebung.

**Topics**
+ [Festlegen der Service-IP-Adresse nicht möglich](#service_ip_address)
+ [Wie lässt sich eine Zurücksetzung auf die Werkseinstellungen durchführen?](#factory_reset)
+ [Wie erfolgt der Remote-Neustart?](#remote-restart)
+ [Wo erhalten Sie Dell iDRAC-Support?](#iDRAC_support)
+ [Die Seriennummer der Hardware-Appliance lässt sich nicht finden](#appliance_serial_number)
+ [Wo Sie Hardware-Appliance-Support erhalten?](#appliance_support)

## Festlegen der Service-IP-Adresse nicht möglich
<a name="service_ip_address"></a>

Wenn Sie versuchen, eine Verbindung mit Ihrem Service herzustellen, stellen Sie sicher, dass Sie die Service-IP-Adresse und nicht die Host-IP-Adresse verwenden. Konfigurieren Sie die Service-IP-Adresse in der Servicekonsole und die Host-IP-Adresse in der Hardwarekonsole. Die Hardwarekonsole wird angezeigt, wenn die Hardware-Appliance gestartet wird. Um die Servicekonsole über die Hardwarekonsole zu öffnen, wählen Sie **Open Service Console (Servicekonsole öffnen)**.

## Wie lässt sich eine Zurücksetzung auf die Werkseinstellungen durchführen?
<a name="factory_reset"></a>

Wenn Sie Ihre Appliance auf die Werkseinstellungen zurücksetzen müssen, wenden Sie sich an das AWS Storage Gateway Hardware Appliance-Team, um Unterstützung zu erhalten, wie im Abschnitt Support weiter unten beschrieben.

## Wie erfolgt der Remote-Neustart?
<a name="remote-restart"></a>

Wenn Sie einen Remote-Neustart Ihrer Appliance durchführen müssen, können Sie dazu die Dell iDRAC-Verwaltungsschnittstelle verwenden. Weitere Informationen finden Sie unter [i DRAC9 Virtueller Energiezyklus: Dell EMC PowerEdge Server aus der Ferne ein- und ausschalten](https://infohub.delltechnologies.com/en-us/p/idrac9-virtual-power-cycle-remotely-power-cycle-dell-emc-poweredge-servers/) auf der InfoHub Website von Dell Technologies.

## Wo erhalten Sie Dell iDRAC-Support?
<a name="iDRAC_support"></a>

Der Dell PowerEdge Server ist mit der Dell iDRAC-Verwaltungsschnittstelle ausgestattet. Wir empfehlen Folgendes:
+ Wenn Sie die iDRAC-Verwaltungsschnittstelle verwenden, sollten Sie das Standardkennwort ändern. Weitere Informationen zu den iDRAC-Anmeldeinformationen finden Sie unter [Dell PowerEdge — Was sind die Standardanmeldedaten](https://www.dell.com/support/article/en-us/sln306783/dell-poweredge-what-is-the-default-username-and-password-for-idrac?lang=en) für iDRAC? .
+ Stellen Sie sicher, dass die Firmware Sicherheitslücken verhindern up-to-date soll.
+ Wenn die iDRAC-Netzwerkschnittstelle an einen normalen Port (`em`) verschoben wird, kann dies zu Leistungsproblemen führen oder die normale Funktionsweise der Appliance beeinträchtigen.

## Die Seriennummer der Hardware-Appliance lässt sich nicht finden
<a name="appliance_serial_number"></a>

Sie können die Seriennummer für Ihre AWS Storage Gateway Hardware-Appliance in der Storage Gateway Gateway-Konsole finden.

**So finden Sie die Seriennummer der Hardware-Appliance:**

1. Öffnen Sie die Storage Gateway Gateway-Konsole [https://console.aws.amazon.com/storagegateway/zu Hause](https://console.aws.amazon.com/storagegateway/).

1. Wählen Sie im Navigationsmenü auf der linken Seite **Hardware** aus.

1. Wählen Sie Ihre Hardware-Appliance aus der Liste aus.

1. Suchen Sie das Feld **Seriennummer** auf der Registerkarte **Details** für Ihre Appliance.

## Wo Sie Hardware-Appliance-Support erhalten?
<a name="appliance_support"></a>

 AWS Informationen zum technischen Support für Ihre Hardware-Appliance finden Sie unter [Support](https://aws.amazon.com/contact-us).

Das Support Team bittet Sie möglicherweise, den Support-Kanal zu aktivieren, um Ihre Gateway-Probleme aus der Ferne zu beheben. Dieser Port muss für den normalen Betrieb des Gateways nicht offen sein, für die Fehlerbehebung ist dies jedoch erforderlich. Sie können den Support-Kanal über die Hardware-Konsole aktivieren, wie im folgenden Verfahren dargestellt.

**Um einen Support-Kanal zu öffnen für AWS**

1. Öffnen Sie die Hardwarekonsole.

1. Wählen Sie unten auf der Hauptseite der Hardwarekonsole die Option **Open Support Channel** aus, und drücken Sie dann`Enter`.

   Die zugewiesene Portnummer sollte innerhalb von 30 Sekunden angezeigt werden, sofern keine Probleme mit der Netzwerkkonnektivität oder der Firewall vorliegen. Beispiel:

   **Status: Auf Port 19599 geöffnet**

1. Notieren Sie sich die Portnummer und geben Sie sie an Support.

# Fehlerbehebung: Probleme mit File Gateway
<a name="troubleshooting-file-gateway-issues"></a>

Sie können Ihr File Gateway so konfigurieren, dass Protokolleinträge in eine CloudWatch Amazon-Protokollgruppe geschrieben werden. Wenn Sie dies tun, erhalten Sie Benachrichtigungen über den Status des Gateways und über alle Fehler, auf die das Gateway stößt. Informationen zu diesen Fehler- und Integritätsbenachrichtigungen finden Sie in den CloudWatch Protokollen.

In den folgenden Abschnitten finden Sie Informationen, die Ihnen helfen können, die Ursache der einzelnen Fehler- und Zustandsbenachrichtigungen zu verstehen und Probleme zu beheben.

**Topics**
+ [Fehler: FileMissing](#troubleshoot-logging-errors-filemissing)
+ [Fehler: FsxFileSystemAuthenticationFailure](#troubleshoot-logging-errors-fsxfilesystemauthenticationfailure)
+ [Fehler: FsxFileSystemConnectionFailure](#troubleshoot-logging-errors-fsxfilesystemconnectionfailure)
+ [Fehler: FsxFileSystemFull](#troubleshoot-logging-errors-fsxfilesystemfull)
+ [Fehler: GatewayClockOutOfSync](#troubleshoot-logging-errors-gatewayclockoutofsync)
+ [Fehler: InvalidFileState](#troubleshoot-logging-errors-invalidfilestate)
+ [Fehler: ObjectMissing](#troubleshoot-logging-errors-objectmissing)
+ [Fehler: DroppedNotifications](#troubleshoot-logging-errors-droppednotifications)
+ [Benachrichtigung: HardReboot](#troubleshoot-hardreboot-notification)
+ [Benachrichtigung: Reboot](#troubleshoot-reboot-notification)
+ [Fehlerbehebung: Probleme mit der Active Directory-Domäne](#troubleshooting-ad-domain)
+ [Problembehandlung: Verwendung von CloudWatch Metriken](#troubleshooting-with-cw-metrics)

## Fehler: FileMissing
<a name="troubleshoot-logging-errors-filemissing"></a>

Der `FileMissing` Fehler ähnelt dem `ObjectMissing` Fehler, und die Schritte zur Behebung des Fehlers sind identisch. Sie können eine `FileMissing` Fehlermeldung erhalten, wenn ein anderer Writer als das angegebene File Gateway die angegebene Datei aus dem Amazon FSx löscht. Alle nachfolgenden Uploads zu Amazon FSx oder Abrufe von Amazon FSx für das Objekt schlagen fehl.

**Um einen Fehler zu beheben FileMissing**

1. Speichern Sie die neueste Kopie der Datei im lokalen Dateisystem Ihres SMB-Clients (Sie benötigen diese Dateikopie in Schritt 3).

1. Löschen Sie die Datei mit Ihrem SMB-Client vom File Gateway.

1. Kopieren Sie die neueste Version der Datei, die Sie in Schritt 1 Amazon gespeichert haben, FSx mit Ihrem SMB-Client. Tun Sie dies über Ihr File Gateway.

## Fehler: FsxFileSystemAuthenticationFailure
<a name="troubleshoot-logging-errors-fsxfilesystemauthenticationfailure"></a>

Sie können eine `FsxFileSystemAuthenticationFailure` Fehlermeldung erhalten, wenn die beim Anhängen des Dateisystems angegebenen Anmeldeinformationen abgelaufen sind oder wenn die Rechte des Dateisystems entzogen wurden.

**Um einen Fehler zu beheben FsxFileSystemAuthenticationFailure**

1. Stellen Sie sicher, dass die Anmeldeinformationen, die Sie beim Anhängen des FSx Amazon-Dateisystems angegeben haben, weiterhin gültig sind.

1. Stellen Sie sicher, dass der Benutzer über alle erforderlichen Berechtigungen verfügt, wie unter [Ein Amazon FSx for Windows File Server-Dateisystem anhängen](https://docs.aws.amazon.com/filegateway/latest/filefsxw/attach-fsxw-filesystem.html) beschrieben.

## Fehler: FsxFileSystemConnectionFailure
<a name="troubleshoot-logging-errors-fsxfilesystemconnectionfailure"></a>

Sie können eine `FsxFileSystemConnectionFailure` Fehlermeldung erhalten, wenn auf den FSx Amazon-Server vom Gateway-Computer aus nicht zugegriffen werden kann.

**Um einen Fehler zu beheben FsxFileSystemConnectionFailure**

1. Stellen Sie sicher, dass alle Firewall- und VPC-Regeln die Verbindung zwischen dem Gateway-Computer und dem FSx Amazon-Server zulassen.

1. Stellen Sie sicher, dass der FSx Amazon-Server läuft.

## Fehler: FsxFileSystemFull
<a name="troubleshoot-logging-errors-fsxfilesystemfull"></a>

Sie können eine `FsxFileSystemFull` Fehlermeldung erhalten, wenn im FSx Amazon-Dateisystem nicht genügend freier Speicherplatz vorhanden ist.

**Um einen FsxFileSystemFull Fehler zu beheben**
+ Erhöhen Sie den Speicherplatz für das FSx Amazon-Dateisystem.

## Fehler: GatewayClockOutOfSync
<a name="troubleshoot-logging-errors-gatewayclockoutofsync"></a>

Sie können eine `GatewayClockOutOfSync` Fehlermeldung erhalten, wenn das Gateway eine Differenz von 5 Minuten oder mehr zwischen der lokalen Systemzeit und der von den AWS Storage Gateway Gateway-Servern gemeldeten Zeit feststellt. Probleme mit der Uhrsynchronisierung können sich negativ auf die Konnektivität zwischen dem Gateway und auswirken AWS. Wenn die Gateway-Uhr nicht synchron ist, können I/O-Fehler bei NFS- und SMB-Verbindungen auftreten, und bei SMB-Benutzern können Authentifizierungsfehler auftreten.

**Um einen Fehler zu beheben GatewayClockOutOfSync**
+ Überprüfen Sie die Netzwerkkonfiguration zwischen dem Gateway und dem NTP-Server. Weitere Informationen zum Synchronisieren der Gateway-VM-Zeit und zum Aktualisieren der NTP-Serverkonfiguration finden Sie unter [Konfigurieren eines Network Time Protocol (NTP)](https://docs.aws.amazon.com/filegateway/latest/filefsxw/manage-on-premises-fgw.html#MaintenanceTimeSync-fgw) -Servers für Ihr Gateway.

## Fehler: InvalidFileState
<a name="troubleshoot-logging-errors-invalidfilestate"></a>

Es kann zu einer `InvalidFileState` Fehlermeldung kommen, wenn ein anderer Writer als das angegebene Gateway die angegebene Datei in der angegebenen Dateifreigabe ändert. Infolgedessen stimmt der Status der Datei auf dem Gateway nicht mit dem Status in Amazon überein FSx. Alle nachfolgenden Uploads oder Abrufe der Datei von Amazon FSx könnten fehlschlagen.

**Um einen Fehler zu beheben InvalidFileState**

1. Speichern Sie die neueste Kopie der Datei im lokalen Dateisystem Ihres SMB-Clients (Sie müssen diese Datei in Schritt 4 kopieren). Wenn die Version der Datei in Amazon die neueste FSx ist, laden Sie diese Version herunter. Sie können dies tun, indem Sie mit einem beliebigen SMB-Client direkt auf die FSx Amazon-Aktie zugreifen.

1. Löschen Sie die Datei FSx direkt in Amazon.

1. Löschen Sie die Datei mit Ihrem SMB-Client vom Gateway.

1. Kopieren Sie mit Ihrem SMB-Client die neueste Version der Datei, die Sie in Schritt 1 gespeichert haben, *über Ihr File Gateway* nach Amazon FSx.

## Fehler: ObjectMissing
<a name="troubleshoot-logging-errors-objectmissing"></a>

Sie können eine `ObjectMissing` Fehlermeldung erhalten, wenn ein anderer Writer als das angegebene File Gateway die angegebene Datei aus Amazon FSx löscht. Alle nachfolgenden Uploads zu Amazon FSx oder Abrufe von Amazon FSx für das Objekt schlagen fehl.

**Um einen Fehler zu beheben ObjectMissing**

1. Speichern Sie die neueste Kopie der Datei im lokalen Dateisystem Ihres SMB-Clients (Sie benötigen diese Dateikopie in Schritt 3).

1. Löschen Sie die Datei mit Ihrem SMB-Client vom File Gateway.

1. Kopieren Sie die neueste Version der Datei, die Sie in Schritt 1 Amazon gespeichert haben, FSx mit Ihrem SMB-Client. Tun Sie dies über Ihr File Gateway.

## Fehler: DroppedNotifications
<a name="troubleshoot-logging-errors-droppednotifications"></a>

Möglicherweise wird anstelle anderer erwarteter Typen von CloudWatch Protokolleinträgen ein `DroppedNotifications` Fehler angezeigt, wenn der freie Speicherplatz auf der Root-Festplatte Ihres Gateways weniger als 1 GB beträgt oder wenn innerhalb eines Intervalls von 1 Minute mehr als 100 Integritätsbenachrichtigungen generiert werden. Unter diesen Umständen generiert das Gateway vorsichtshalber CloudWatch keine detaillierten Protokollbenachrichtigungen mehr.

**Um einen Fehler zu beheben DroppedNotifications **

1. Überprüfen Sie anhand der `Root Disk Usage` Metrik auf der Registerkarte **Überwachung** für Ihr Gateway in der Storage Gateway Gateway-Konsole, ob der verfügbare Root-Festplattenspeicher knapp wird.

1. Erhöhen Sie die Größe der Root-Speicherfestplatte des Gateways, wenn der verfügbare Speicherplatz weniger als 1 GB beträgt. Anweisungen finden Sie in der Dokumentation Ihres Hypervisors für virtuelle Maschinen.

   Informationen zur Erhöhung der Root-Festplattengröße für Amazon EC2 EC2-Gateways finden Sie unter [Änderungen an Ihren EBS-Volumes beantragen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requesting-ebs-volume-modifications.html) im *Amazon Elastic Compute Cloud-Benutzerhandbuch*.
**Anmerkung**  
Es ist nicht möglich, die Root-Festplattengröße für die AWS Storage Gateway Hardware Appliance zu erhöhen.

1. Starten Sie Ihr Gateway neu.

## Benachrichtigung: HardReboot
<a name="troubleshoot-hardreboot-notification"></a>

Sie können eine `HardReboot`-Benachrichtigung erhalten, wenn die Gateway-VM unerwartet neu gestartet wird. Ein solcher Neustart kann auf Stromausfall, einen Hardwarefehler oder ein anderes Ereignis zurückzuführen sein. Bei VMware Gateways kann ein Reset durch vSphere High Availability Application Monitoring dieses Ereignis auslösen.

Wenn Ihr Gateway in einer solchen Umgebung ausgeführt wird, überprüfen Sie, ob die `HealthCheckFailure` Benachrichtigung vorhanden ist, und lesen Sie im VMware Ereignisprotokoll für die VM nach.

## Benachrichtigung: Reboot
<a name="troubleshoot-reboot-notification"></a>

Sie können eine Neustart-Benachrichtigung erhalten, wenn die Gateway-VM neu gestartet wird. Sie können eine Gateway-VM mithilfe der VM Hypervisor-Managementkonsole oder der Storage-Gateway-Konsole neu starten. Sie können den Neustart auch mithilfe der Gateway-Software während des Wartungszyklus des Gateways ausführen.

Wenn die Zeit des Neustarts innerhalb von 10 Minuten nach der konfigurierten [Wartungsstartzeit](MaintenanceManagingUpdate-common.md) des Gateways liegt, ist dieser Neustart wahrscheinlich ein normales Ereignis und kein Anzeichen für ein Problem. Wenn der Neustart deutlich außerhalb des Wartungsfensters stattgefunden hat, überprüfen Sie, ob das Gateway manuell neu gestartet wurde.

## Fehlerbehebung: Probleme mit der Active Directory-Domäne
<a name="troubleshooting-ad-domain"></a>

FSx File Gateway generiert keine spezifischen Protokollmeldungen für Probleme mit der Active Directory-Domäne. Wenn Sie Probleme haben, Ihr Gateway mit Ihrer Active Directory-Domäne zu verbinden, gehen Sie wie folgt vor:
+ Stellen Sie sicher, dass das Gateway nicht versucht, einen schreibgeschützten Domänencontroller (RODC) zu verwenden, um der Domäne beizutreten.
+ Stellen Sie sicher, dass das Gateway für die Verwendung der richtigen DNS-Server konfiguriert ist.

  Wenn Sie beispielsweise versuchen, eine Amazon EC2 EC2-Gateway-Instance mit einem AWS-verwalteten Active Directory zu verbinden, stellen Sie sicher, dass die für Ihre EC2-VPC festgelegte DHCP-Option die AWS-verwalteten Active Directory-DNS-Server angibt.

  DNS-Server, die Sie über den VPC-DHCP-Optionssatz konfigurieren, werden allen EC2-Instances in der VPC zur Verfügung gestellt. Wenn Sie einen DNS-Server für ein einzelnes Gateway angeben möchten, können Sie dies über die lokale EC2-Konsole dieses Gateways tun.

  Für lokale Gateways geben Sie einen DNS-Server mithilfe der lokalen VM-Konsole an.
+ Überprüfen Sie die Netzwerkkonnektivität des Gateways, indem Sie die folgenden Befehle an der Eingabeaufforderung in der lokalen Konsole des Gateways ausführen. Ersetzen Sie die hervorgehobenen Variablen durch den tatsächlichen Domänennamen und die IP-Adressen aus Ihrer Bereitstellung.

  ```
  dig -d ExampleDomainName
  ncport -d ExampleDomainControllerIPAddress -p 445
  ncport -d ExampleDomainControllerIPAddress -p 389
  ```
+ Stellen Sie sicher, dass Ihr Active Directory-Dienstkonto über die erforderlichen Berechtigungen verfügt. Weitere Informationen finden Sie unter Berechtigungsanforderungen für für [Active Directory-Dienstkonten](https://docs.aws.amazon.com/filegateway/latest/filefsxw/ad-serviceaccount-permissions.html).
+ Stellen Sie sicher, dass das Gateway der richtigen Organisationseinheit (OU) beitritt.

  Durch den Beitritt zu einer Domäne wird ein Active Directory-Computerkonto im Standardcomputercontainer (der keine Organisationseinheit ist) erstellt, wobei die **Gateway-ID des Gateways** als Kontoname verwendet wird (z. B. SGW-1234ADE). Es ist nicht möglich, den Namen dieses Kontos anzupassen.

  Wenn Ihre Active Directory-Umgebung über eine festgelegte Organisationseinheit für neue Computerobjekte verfügt, müssen Sie diese Organisationseinheit angeben, wenn Sie der Domäne beitreten.

  Wenn Sie beim Versuch, der angegebenen Organisationseinheit beizutreten, auf Fehler mit Zugriff verweigert stoßen, wenden Sie sich an Ihren Active Directory-Domänenadministrator. Möglicherweise muss der Administrator das Computerkonto des Gateways vorab einrichten, bevor es der Domäne beitreten kann. Weitere Informationen finden Sie unter [Wie kann ich Probleme beim Verbinden meines Storage Gateway-File-Gateways mit einer Domäne für die Microsoft Active Directory-Authentifizierung beheben?](https://aws.amazon.com/premiumsupport/knowledge-center/storage-gateway-domain-join-error/) .
+ Stellen Sie sicher, dass der Hostname Ihres Gateways in DNS aufgelöst werden kann, indem Sie den folgenden Befehl an der Eingabeaufforderung in der lokalen Konsole des Gateways ausführen. Ersetzen Sie die hervorgehobene Variable durch den tatsächlichen Hostnamen für Ihr Gateway.

  ```
  dig -d ExampleHostName -r A
  ```

  Wenn Sie einen benutzerdefinierten Hostnamen für Ihr Gateway konfiguriert haben, müssen Sie manuell einen DNS-A-Eintrag hinzufügen, der auf seine IP-Adresse verweist.
+ Stellen Sie sicher, dass die Netzwerklatenz zwischen dem Gateway und dem Domänencontroller relativ gering ist. Bei der Anfrage zum Beitritt zu einer Domäne kann es zu einem Timeout kommen, wenn das Gateway innerhalb von 20 Sekunden keine Antwort vom Domänencontroller erhält.

  Wenn Sie das Gateway mithilfe des [JoinDomain](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_JoinDomain.html)CLI-Befehls mit der Domain verbinden, können Sie das `--timeout-in-seconds` Flag hinzufügen, um das Timeout auf maximal 3.600 Sekunden zu erhöhen.
+ Stellen Sie sicher, dass der Active Directory-Benutzer, den Sie für den Beitritt zum Gateway zur Domäne verwenden, über die dafür erforderlichen Rechte verfügt.

## Problembehandlung: Verwendung von CloudWatch Metriken
<a name="troubleshooting-with-cw-metrics"></a>

Im Folgenden finden Sie Informationen zu Maßnahmen zur Behebung von Problemen mithilfe von CloudWatch Amazon-Metriken mit Storage Gateway.

**Topics**
+ [Ihr Gateway reagiert langsam beim Durchsuchen von Verzeichnissen](#slow-gateway)
+ [Ihr Gateway reagiert nicht](#gateway-not-responding)
+ [Sie sehen keine Dateien in Ihrem FSx Amazon-Dateisystem](#files-missing-fsx)
+ [Sie sehen keine älteren Snapshots in Ihrem FSx Amazon-Dateisystem](#snapshots-missing-fsx)
+ [Ihr Gateway überträgt langsam Daten an Amazon FSx](#slow-data-transfer-to-fsx)
+ [Ihr Gateway-Backup-Job schlägt fehl oder es treten Fehler beim Schreiben auf Ihr Gateway auf](#backup-job-fails)

### Ihr Gateway reagiert langsam beim Durchsuchen von Verzeichnissen
<a name="slow-gateway"></a>

Wenn Ihr File Gateway langsam reagiert, wenn Sie den **ls** Befehl ausführen oder Verzeichnisse durchsuchen, überprüfen Sie die `IndexEviction` CloudWatch Messwerte `IndexFetch` und:
+ Wenn die `IndexFetch` Metrik größer als 0 ist, wenn Sie einen `ls` Befehl ausführen oder Verzeichnisse durchsuchen, wurde Ihr File Gateway ohne Informationen über den Inhalt des betroffenen Verzeichnisses gestartet und musste auf für Windows File Server zugreifen. Nachfolgende Versuche, den Inhalt dieses Verzeichnisses aufzulisten, sollten schneller ausgeführt werden.
+ Wenn die `IndexEviction` Metrik größer als 0 ist, bedeutet dies, dass Ihr File Gateway die Grenze dessen erreicht hat, was es zu diesem Zeitpunkt in seinem Cache verwalten kann. In diesem Fall muss Ihr File Gateway Speicherplatz aus dem Verzeichnis freigeben, auf das zuletzt zugegriffen wurde, um ein neues Verzeichnis aufzulisten. Wenn dies häufig vorkommt und die Leistung beeinträchtigt wird, wenden Sie sich an Support. 

  Diskutieren Sie mit Support dem Inhalt des zugehörigen FSx Amazon-Dateisystems und den Empfehlungen zur Leistungssteigerung auf der Grundlage Ihres Anwendungsfalls.

### Ihr Gateway reagiert nicht
<a name="gateway-not-responding"></a>

Wenn Ihr File Gateway nicht reagiert, gehen Sie wie folgt vor:
+  Wenn kürzlich ein Neustart oder ein Softwareupdate vorgenommen wurde, überprüfen Sie die Metrik `IOWaitPercent`. Diese Metrik zeigt den Prozentsatz der Zeit, in der sich die CPU im Leerlauf befindet, wenn eine I/O Festplattenanforderung aussteht. In einigen Fällen ist dieser Prozentsatz möglicherweise hoch (10 oder höher) und angestiegen, nachdem der Server neu gestartet oder aktualisiert wurde. In diesen Fällen kann es sein, dass Ihr File Gateway bei der Neuerstellung des Index-Caches in RAM durch eine langsame Root-Festplatte einen Engpass bekommt. Sie können dieses Problem beheben, indem Sie einen schnelleren physischen Datenträger für den Stamm-Datenträger verwenden.
+ Wenn die `MemUsedBytes` Metrik der Metrik entspricht oder fast der `MemTotalBytes` Metrik entspricht, geht Ihrem File Gateway der verfügbare Arbeitsspeicher aus. Stellen Sie sicher, dass Ihr File Gateway mindestens über den erforderlichen Arbeitsspeicher verfügt. Falls dies bereits der Fall ist, sollten Sie erwägen, Ihrem File Gateway je nach Arbeitslast und Anwendungsfall mehr RAM hinzuzufügen. 

  Wenn die Dateifreigabe SMB ist, kann dieses Problem auch auf die Anzahl der SMB-Clients zurückzuführen sein, die mit der Dateifreigabe verbunden sind. Überprüfen Sie die Metrik `SMBV(1/2/3)Sessions`, um die Anzahl der Clients zu sehen, die zu einem bestimmten Zeitpunkt verbunden sind. Wenn viele Clients angeschlossen sind, müssen Sie Ihrem File Gateway möglicherweise mehr RAM hinzufügen.

### Sie sehen keine Dateien in Ihrem FSx Amazon-Dateisystem
<a name="files-missing-fsx"></a>

Wenn Sie feststellen, dass Dateien auf dem Gateway nicht im FSx Amazon-Dateisystem wiedergegeben werden, überprüfen Sie die `FilesFailingUpload` Metrik. Wenn die Metrik meldet, dass einige Dateien nicht hochgeladen werden können, überprüfen Sie Ihre Statusmeldungen. Wenn Dateien nicht hochgeladen werden können, generiert das Gateway eine Statusmeldung mit weiteren Informationen zu dem Problem.

### Sie sehen keine älteren Snapshots in Ihrem FSx Amazon-Dateisystem
<a name="snapshots-missing-fsx"></a>

Einige Dateioperationen auf dem FSx File Gateway, wie z. B. das Umbenennen von Ordnern auf oberster Ebene oder Änderungen von Berechtigungen, können zu mehreren Dateivorgängen führen, die zu einer hohen I/O Belastung Ihres Dateisystems FSx für Windows File Server führen. Wenn Ihr Dateisystem nicht über genügend Leistungsressourcen für Ihre Arbeitslast verfügt, löscht das Dateisystem möglicherweise [Schattenkopien](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/shadow-copies-fsxW.html), da es der kontinuierlichen I/O Verfügbarkeit Vorrang vor der Aufbewahrung historischer Schattenkopien einräumt.

Überprüfen Sie in der FSx Amazon-Konsole auf der Seite **Überwachung und Leistung**, ob Ihr Dateisystem nicht ausreichend bereitgestellt ist. Ist dies der Fall, können Sie zu SSD-Speicher wechseln, die Durchsatzkapazität erhöhen oder die SSD-IOPS erhöhen, um Ihre Arbeitslast zu bewältigen.

### Ihr Gateway überträgt langsam Daten an Amazon FSx
<a name="slow-data-transfer-to-fsx"></a>

Wenn Ihr File Gateway Daten langsam an Amazon FSx for Windows File Server überträgt, gehen Sie wie folgt vor:
+ Wenn die `CachePercentDirty` Metrik 80 oder höher ist, schreibt Ihr File Gateway Daten schneller auf die Festplatte, als es die Daten auf Amazon FSx for Windows File Server hochladen kann. Erwägen Sie, die Bandbreite für den Upload von Ihrem File Gateway zu erhöhen, eine oder mehrere Cache-Festplatten hinzuzufügen, Client-Schreibvorgänge zu verlangsamen oder die Durchsatzkapazität für den zugehörigen Amazon FSx for Windows File Server zu erhöhen.
+ Wenn die `CachePercentDirty` Metrik niedrig ist, überprüfen Sie die `IoWaitPercent` Metrik. Wenn der `IoWaitPercent` Wert größer als 10 ist, hat Ihr File Gateway möglicherweise einen Engpass aufgrund der Geschwindigkeit des lokalen Cache-Laufwerks. Wir empfehlen lokale Solid-State-Drive-Festplatten (SSD) für Ihren Cache, vorzugsweise NVM Express (). NVMe Wenn solche Datenträger nicht verfügbar sind, verwenden Sie mehrere Cache-Datenträger von separaten physischen Datenträgern, um zu versuchen, die Leistung zu verbessern.

### Ihr Gateway-Backup-Job schlägt fehl oder es treten Fehler beim Schreiben auf Ihr Gateway auf
<a name="backup-job-fails"></a>

Wenn Ihr File Gateway-Backup-Job fehlschlägt oder Fehler beim Schreiben auf Ihr File Gateway auftreten, gehen Sie wie folgt vor:
+ Wenn die `CachePercentDirty` Metrik 90 Prozent oder mehr beträgt, kann Ihr File Gateway keine neuen Schreibvorgänge auf die Festplatte akzeptieren, da auf der Cache-Festplatte nicht genügend Speicherplatz verfügbar ist. Um zu sehen, wie schnell Ihr File Gateway auf für Windows File Server hochlädt, sehen Sie sich die `CloudBytesUploaded` Metrik an. Vergleichen Sie diese Metrik mit der `WriteBytes` Metrik, die zeigt, wie schnell der Client Dateien auf Ihr File Gateway schreibt. Wenn der SMB-Client schneller auf Ihr File Gateway schreibt, als er auf für Windows File Server hochladen kann, fügen Sie mehr Cache-Festplatten hinzu, um die Größe des Backup-Jobs mindestens abzudecken. Oder erhöhen Sie die Upload-Bandbreite.
+ Wenn eine große Dateikopie, z. B. ein Backup-Job, fehlschlägt, die `CachePercentDirty` Metrik jedoch unter 80 Prozent liegt, hat Ihr File Gateway möglicherweise ein clientseitiges Sitzungs-Timeout erreicht. Für SMB können Sie dieses Timeout mit dem Befehl erhöhen. PowerShell `Set-SmbClientConfiguration -SessionTimeout 300` Wenn Sie diesen Befehl ausführen, wird das Timeout auf 300 Sekunden festgelegt.

## High Availability-Zustandsbenachrichtigungen
<a name="troubleshooting-ha-notifications"></a>

Wenn Sie Ihr Gateway auf der VMware vSphere High Availability (HA) -Plattform ausführen, erhalten Sie möglicherweise Statusmeldungen. Weitere Informationen zu Zustandsbenachrichtigungen finden Sie unter [Fehlerbehebung: Probleme mit der Hochverfügbarkeit](troubleshooting-ha-issues.md).

# Fehlerbehebung: Probleme mit der Hochverfügbarkeit
<a name="troubleshooting-ha-issues"></a>

Im Folgenden finden Sie Informationen zu Aktionen, die Sie ausführen müssen, wenn Probleme im Zusammenhang mit der Verfügbarkeit auftreten.

**Topics**
+ [Zustandsbenachrichtigungen](#ha-health-notifications)
+ [Kennzahlen](#ha-health-notification-metrics)

## Zustandsbenachrichtigungen
<a name="ha-health-notifications"></a>

Wenn Sie Ihr Gateway auf VMware vSphere HA ausführen, senden alle Gateways die folgenden Integritätsbenachrichtigungen an Ihre konfigurierte CloudWatch Amazon-Protokollgruppe. Diese Benachrichtigungen werden in einem Protokollstream mit dem Namen `AvailabilityMonitor` erfasst.

**Topics**
+ [Benachrichtigung: Reboot](#troubleshoot-reboot-notification)
+ [Benachrichtigung: HardReboot](#troubleshoot-hardreboot-notification)
+ [Benachrichtigung: HealthCheckFailure](#troubleshoot-healthcheckfailure-notification)
+ [Benachrichtigung: AvailabilityMonitorTest](#troubleshoot-availabilitymonitortest-notification)

### Benachrichtigung: Reboot
<a name="troubleshoot-reboot-notification"></a>

Sie können eine Neustart-Benachrichtigung erhalten, wenn die Gateway-VM neu gestartet wird. Sie können eine Gateway-VM mithilfe der VM Hypervisor-Managementkonsole oder der Storage-Gateway-Konsole neu starten. Sie können den Neustart auch mithilfe der Gateway-Software während des Wartungszyklus des Gateways ausführen.

**Maßnahme**

Wenn die Zeit des Neustarts innerhalb von 10 Minuten nach der konfigurierten [Wartungsstartzeit](MaintenanceManagingUpdate-common.md) des Gateways liegt, handelt es sich wahrscheinlich um ein normales Ereignis und es deutet nicht auf ein Problem hin. Wenn der Neustart deutlich außerhalb des Wartungsfensters stattgefunden hat, überprüfen Sie, ob das Gateway manuell neu gestartet wurde.

### Benachrichtigung: HardReboot
<a name="troubleshoot-hardreboot-notification"></a>

Sie können eine `HardReboot`-Benachrichtigung erhalten, wenn die Gateway-VM unerwartet neu gestartet wird. Ein solcher Neustart kann auf Stromausfall, einen Hardwarefehler oder ein anderes Ereignis zurückzuführen sein. Bei VMware Gateways kann ein Reset durch vSphere High Availability Application Monitoring dieses Ereignis auslösen.

**Maßnahme**

Wenn Ihr Gateway in einer solchen Umgebung ausgeführt wird, überprüfen Sie, ob die `HealthCheckFailure` Benachrichtigung vorhanden ist, und lesen Sie im VMware Ereignisprotokoll für die VM nach.

### Benachrichtigung: HealthCheckFailure
<a name="troubleshoot-healthcheckfailure-notification"></a>

Für ein Gateway auf VMware vSphere HA können Sie eine `HealthCheckFailure` Benachrichtigung erhalten, wenn eine Integritätsprüfung fehlschlägt und ein VM-Neustart angefordert wird. Dieses Ereignis tritt auch während eines Tests zum Überwachen der Verfügbarkeit auf, der durch die Benachrichtigung `AvailabilityMonitorTest` angezeigt wird. In diesem Fall wird die Benachrichtigung `HealthCheckFailure` erwartet.

**Anmerkung**  
Diese Benachrichtigung gilt nur für VMware Gateways.

**Maßnahme**

Wenn dieses Ereignis wiederholt ohne die Benachrichtigung `AvailabilityMonitorTest` auftritt, überprüfen Sie die VM-Infrastruktur auf Probleme (Speicher, Arbeitsspeicher usw.). Wenn Sie zusätzliche Unterstützung benötigen, wenden Support Sie sich an. 

### Benachrichtigung: AvailabilityMonitorTest
<a name="troubleshoot-availabilitymonitortest-notification"></a>

Für ein Gateway auf VMware vSphere HA können Sie eine `AvailabilityMonitorTest` Benachrichtigung erhalten, wenn Sie [einen Test des [Verfügbarkeits- und Anwendungsüberwachungssystems](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_StartAvailabilityMonitorTest.html) in VMware ausführen](vmware-ha.md#vmware-ha-test-failover).

## Kennzahlen
<a name="ha-health-notification-metrics"></a>

Die Metrik `AvailabilityNotifications` ist auf allen Gateways verfügbar. Diese Metrik ist eine Zählung der Anzahl an Zustandsbenachrichtigungen im Zusammenhang mit der Verfügbarkeit, die vom Gateway generiert werden. Verwenden Sie die Statistik `Sum`, um zu beobachten, ob Ereignisse im Zusammenhang mit der Verfügbarkeit im Gateway auftreten. Einzelheiten zu den Ereignissen erhalten Sie von Ihrer konfigurierten CloudWatch Protokollgruppe.