

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.

# Fehlerbehebung bei Ihrem Gateway
<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, Volumes, 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.
+ [Problembehandlung: interner Fehler bei 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 bei lokalen Gateway-Problemen](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 bei der Einrichtung 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 bei Problemen mit Amazon-EC2-Gateway](troubleshooting-EC2-gateway-issues.md)- Hier finden Sie Informationen zu typischen Problemen, die bei der Arbeit mit auf Amazon EC2 bereitgestellten Gateways auftreten können.
+ [Fehlerbehebung bei Hardware-Appliance-Problemen](troubleshooting-hardware-appliance-issues.md)- Erfahren Sie, wie Sie Probleme lösen können, die möglicherweise mit der Storage Gateway Gateway-Hardware-Appliance auftreten.
+ [Fehlerbehebung bei Volume-Problemen](troubleshoot-volume-issues.md)- Hier finden Sie Informationen zu den häufigsten Problemen, die bei der Arbeit mit Volumes auftreten können, und zu den Maßnahmen, die wir Ihnen zur Behebung dieser Probleme empfehlen.
+ [Beheben von Problemen mit Hochverfügbarkeit](troubleshooting-ha-issues.md)- Erfahren Sie, wie Sie vorgehen können, wenn Probleme mit Gateways auftreten, die in einer VMware HA-Umgebung eingesetzt werden.

# Fehlerbehebung: Gateway-Offline-Probleme
<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="w2ab1c40c12c11"></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/storagegateway/latest/vgw/Requirements.html#networks).

## Suchen Sie nach einer laufenden SSL- oder Deep-Packet-Inspektion des Datenverkehrs Ihres Gateways
<a name="w2ab1c40c12c13"></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.

## Suchen Sie nach einem Strom- oder Hardwarefehler auf dem Hypervisor-Host
<a name="w2ab1c40c12c17"></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 zur Wiederherstellung Ihrer Daten](https://docs.aws.amazon.com/storagegateway/latest/vgw/recover-data-from-gateway.html).

## Suchen Sie nach Problemen mit einer zugehörigen Cache-Festplatte
<a name="w2ab1c40c12c19"></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:**

1. Fahren Sie das Gateway herunter.

1. Setzen Sie die Cache-Festplatte zurück.

1. Konfigurieren Sie die Festplatte für den Cache-Speicher neu.

1. Starten Sie Ihr Gateway neu.

# Problembehandlung: 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="w2ab1c40c15b9"></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="w2ab1c40c15b9b5"></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 Ihrer Gateway-Verbindung zum Internet](https://docs.aws.amazon.com/storagegateway/latest/vgw/manage-on-premises-common.html#MaintenanceTestGatewayConnectivity-common).

**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="w2ab1c40c15b9b7"></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="w2ab1c40c15b9b9"></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. [Weitere Informationen finden Sie unter .](https://docs.aws.amazon.com/storagegateway/latest/vgw/MaintenanceTimeSync-hyperv.html)

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

## Beheben Sie Fehler bei der Aktivierung Ihres Gateways über einen Amazon VPC-Endpunkt
<a name="w2ab1c40c15c11"></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="w2ab1c40c15c11b5"></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 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="w2ab1c40c15c11b7"></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="w2ab1c40c15c11b9"></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. [Weitere Informationen finden Sie unter .](https://docs.aws.amazon.com/storagegateway/latest/vgw/MaintenanceTimeSync-hyperv.html)

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="w2ab1c40c15c11c11"></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="w2ab1c40c15c13"></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="w2ab1c40c15c13b5"></a>

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

**So deaktivieren Sie die Option für private DNS-Namen:**

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 bei lokalen Gateway-Problemen
<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, sowie Informationen zur Aktivierung, um Ihnen bei der Behebung von Problemen mit Ihrem Gateway Support zu helfen.

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/storagegateway/latest/vgw/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/storagegateway/latest/vgw/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/storagegateway/latest/vgw/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/storagegateway/latest/vgw/troubleshooting-on-premises-gateway-issues.html)  | 
| Entfernen Sie eine als Upload-Pufferspeicher zugewiesene Festplatte. Beispielsweise möchten Sie die Anzahl der Upload-Pufferspeicher für ein Gateway reduzieren oder eine Festplatte ersetzen, die als fehlgeschlagener Puffer verwendet wurde.  | Anweisungen zum Entfernen eines Datenträgers, der als Upload-Pufferspeicherplatz zugewiesen ist, finden Sie unter [Entfernen von Datenträgern aus dem Gateway](add-remove-disks.md).  | 
|  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 eine Verbindung mit hoher Bandbreite haben 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 [Messung der Leistung zwischen Ihrem Gateway und AWS](PerfGatewayAWS-common.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/storagegateway/latest/vgw/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 und AWS finden Sie unter [Messung der Leistung zwischen Ihrem Gateway und AWS](PerfGatewayAWS-common.md).  | 
|  Sie haben Schwierigkeiten mit dem Importieren (Bereitstellen) von Storage Gateway auf Microsoft Hyper-V.  |  Weitere Informationen finden Sie unter [Fehlerbehebung bei der Einrichtung von Microsoft Hyper-V](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.  | 

## So können Support Sie bei der Fehlerbehebung Ihres lokal gehosteten Gateways helfen
<a name="enable-support-access-on-premises"></a>

Storage Gateway bietet eine lokale Konsole, mit der Sie verschiedene Wartungsaufgaben ausführen können, einschließlich der Aktivierung Support für den Zugriff auf Ihr Gateway, um Sie bei der Behebung von Gateway-Problemen zu unterstützen. Standardmäßig ist der Support Zugriff auf Ihr Gateway deaktiviert. Dieser Zugriff wird über die lokale Host-Konsole gewährt. 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 ermöglichen**

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 ein**exit**, um sich von der Gateway-Konsole abzumelden.

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

# Fehlerbehebung bei der Einrichtung von Microsoft Hyper-V
<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/storagegateway/latest/vgw/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 [Anforderungen für die Einrichtung von Volume 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 [Anforderungen für die Einrichtung von Volume 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 [Synchronisieren Sie die VM-Zeit mit der Hyper-V- oder Linux-KVM-Hostzeit](MaintenanceTimeSync-hyperv.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 bei Problemen mit Amazon-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 eine benutzerdefinierte Amazon EC2 EC2-Instance für Volume Gateway bereit](ec2-gateway-common.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 haben ein Amazon-EBS-Volume erstellt, können es aber nicht an die EC2-Gateway-Instance anfügen](#ebs-volume-issue)
+ [Sie können keinen Initiator an ein Volume-Ziel auf dem EC2-Gateway anfügen](#initiator-issue)
+ [Beim Hinzufügen von Speicher-Volumes erhalten Sie die Meldung, dass keine Datenträger verfügbar sind](#no-disk)
+ [Sie möchten einen als Upload-Pufferspeicher zugewiesenen Datenträger entfernen, um die Größe des Upload-Pufferspeichers zu reduzieren](#uploadbuffer-issue)
+ [Durchsatz zum oder vom EC2-Gateway sinkt auf Null](#gateway-throughput-issue)
+ [Sie Support möchten bei der Fehlerbehebung Ihres EC2-Gateways helfen](#EC2-EnableAWSSupportAccess)
+ [Sie möchten sich mit Ihrer Gateway-Instance über die serielle Amazon-EC2-Konsole verbinden](#ec2-serial-console)

## 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 aktiviert, die Sie mit der Instance verknüpft 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 haben ein Amazon-EBS-Volume erstellt, können es aber nicht an die EC2-Gateway-Instance anfügen
<a name="ebs-volume-issue"></a>

Stellen Sie sicher, dass sich dieses Amazon-EBS-Volume in derselben Availability Zone wie die Gateway-Instance befindet. Falls eine Abweichung in den Availability Zones besteht, erstellen Sie ein neues Amazon-EBS-Volume, das sich in derselben Availability Zone wie die Instance befindet.

## Sie können keinen Initiator an ein Volume-Ziel auf dem EC2-Gateway anfügen
<a name="initiator-issue"></a>

Stellen Sie sicher, dass die Sicherheitsgruppe, mit der Sie die Instance gestartet haben, eine Regel enthält, die den Port zulässt, den Sie für den iSCSI-Zugriff verwenden. Der Port wird in der zu 3260 festgesetzt. Weitere Informationen zum Verbinden zu Volumes finden Sie unter [Von einem Windows-Client aus eine Verbindung zu Ihren Volumes herstellen](ConfiguringiSCSIClient.md).

## Beim Hinzufügen von Speicher-Volumes erhalten Sie die Meldung, dass keine Datenträger verfügbar sind
<a name="no-disk"></a>

Für ein neu aktiviertes Gateway ist kein Volume-Speicher definiert. Bevor Sie Volume-Speicher definieren können, müssen Sie die lokale Festplatten zum Gateway zuweisen, die Sie als Upload-Puffer und Cache-Speicher verwenden. Für ein Gateway, das auf Amazon EC2 bereitgestellt ist, entsprechen die lokalen Datenträger Amazon-EBS-Volumes, die an die Instance angefügt sind. Dieser Fehler tritt wahrscheinlich auf, weil keine Amazon-EBS-Volumes für die Instance definiert sind.

Prüfen Sie Block-Geräte, die für die Instance definiert sind, die das Gateway ausführt. Wenn es nur zwei Block-Geräte (Geräte mit der Standard-AMI) gibt, dann sollten Sie Speicher hinzufügen. Weitere Informationen zur Verfahrensweise finden Sie unter [Stellen Sie eine benutzerdefinierte Amazon EC2 EC2-Instance für Volume Gateway bereit](ec2-gateway-common.md). Nachdem Sie zwei oder mehr Amazon-EBS-Volumes angefügt haben, versuchen Sie, den Volume-Speicher im Gateway zu erstellen.

## Sie möchten einen als Upload-Pufferspeicher zugewiesenen Datenträger entfernen, um die Größe des Upload-Pufferspeichers zu reduzieren
<a name="uploadbuffer-issue"></a>

Führen Sie die Schritte unter [Bestimmen der Größe des zuzuordnenden Upload-Puffers](decide-local-disks-and-sizes.md#CachedLocalDiskUploadBufferSizing-common) aus.

## Durchsatz zum oder vom EC2-Gateway sinkt auf Null
<a name="gateway-throughput-issue"></a>

Verifizieren Sie, dass die Gateway-Instance ausgeführt wird. Wenn die Instance gestartet wird, z. B. durch einen Neustart, warten Sie, bis die Instance neu gestartet ist.

Verifizieren Sie außerdem, dass sich die Gateway-IP-Adresse nicht geändert hat. Wenn die Instance beendet wurde und anschließend neu gestartet wurde, hat sich die IP-Adresse der Instance möglicherweise geändert. In diesem Fall müssen Sie ein neues Gateway aktivieren.

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 und AWS finden Sie unter [Messung der Leistung zwischen Ihrem Gateway und AWS](PerfGatewayAWS-common.md).

## Sie Support möchten bei der Fehlerbehebung Ihres EC2-Gateways helfen
<a name="EC2-EnableAWSSupportAccess"></a>

Storage Gateway bietet eine lokale Konsole, mit der Sie verschiedene Wartungsaufgaben ausführen können, einschließlich der Aktivierung Support für den Zugriff auf Ihr Gateway, um Sie bei der Behebung von Gateway-Problemen zu unterstützen. Standardmäßig ist der Support Zugriff auf Ihr Gateway deaktiviert. Sie aktivieren diesen Zugriff über die lokale Amazon-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.

**Um den Support Zugriff auf ein Gateway zu aktivieren, das auf einer Amazon EC2 EC2-Instance bereitgestellt wird**

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 Problembehebung 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 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.

## 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*.

# Fehlerbehebung bei Hardware-Appliance-Problemen
<a name="troubleshooting-hardware-appliance-issues"></a>

In den folgenden Themen werden Probleme, die im Zusammenhang mit der Hardware-Appliance für Storage Gateway auftreten können, sowie Lösungsvorschläge beschrieben.

## 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 die Appliance auf die Werkseinstellungen zurücksetzen müssen, wenden Sie sich an das Hardware-Appliance-Team für Storage Gateway, um wie im folgenden Support-Abschnitt beschrieben Unterstützung zu erhalten.

## 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 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 bei Volume-Problemen
<a name="troubleshoot-volume-issues"></a>

Sie können Informationen über die typischsten Probleme finden, die beim Arbeiten mit Volumes auftreten können sowie Aktionen die wir vorschlagen auszuführen um diese zu beheben.

**Topics**
+ [Die Konsole behauptet, dass Ihre Volume nicht konfiguriert ist](#troubleshoot-volume-issues.VolumeNotConfigured)
+ [Die Konsole gibt an, dass Ihre Volume verloren ist](#troubleshoot-volume-issues.VolumeIrrecoverable)
+ [Ihr Cache-Gateway ist unerreichbar und Sie möchten Ihre Daten wiederherstellen](#RecoverySnapshotTroubleshooting)
+ [Die Konsole gibt an, das Ihre Volume PASS THROUGH Status hat](#troubleshoot-volume-issues.VolumePassthrough)
+ [Sie möchten Volume-Integrität überprüfen und möglicher Fehler beheben](#troubleshoot-volume-issues.VerifyIntegrity)
+ [Ihre Volume-iSCSI-Target erscheint nicht in Windows Disk Management Konsole](#troubleshoot-volume-issues.DoesNotAppear)
+ [Sie möchten den iSCSI-Volumen-Zielnamen ändern](#troubleshoot-volume-issues.ChangeISCSI)
+ [Ihr geplanter Volume Snapshot taucht nicht auf](#troubleshoot-volume-issues.NoSnapshot)
+ [Sie müssen eine Festplatte entfernen oder ersetzen, die ausgefallen ist](#troubleshoot-volume-issues.RemoveVolume)
+ [Durchsatz von Ihrer Anwendung zu einem Volume ist auf Null abgefallen](#troubleshoot-volume-issues.ThroughputZero)
+ [In einem Cache-Datenträger in Ihrem Gateway tritt ein Fehler auf](#troubleshoot-volume-issues.CacheDiskFail)
+ [Ein Volume Snapshot hat einen PENDING Status länger als erwartet](#SnapshotTroubleshooting.Pending)
+ [High Availability-Zustandsbenachrichtigungen](#troubleshooting-ha-notifications)

## Die Konsole behauptet, dass Ihre Volume nicht konfiguriert ist
<a name="troubleshoot-volume-issues.VolumeNotConfigured"></a>

Wenn die Storage-Gateway-Konsole angibt, dass Ihr Volume den Status UPLOAD BUFFER NOT CONFIGURED besitzt, fügen Sie Upload-Pufferkapazität zu Ihrem Gateway hinzu. Sie können ein Gateway nicht zum Speichern Ihrer Anwendungsdaten verwenden, wenn der Upload-Puffer für das Gateway nicht konfiguriert ist. Weitere Informationen finden Sie unter [So konfigurieren Sie zusätzlichen Upload-Puffer oder Cache-Speicher für Ihr Gateway](ConfiguringLocalDiskStorage.md#GatewayWorkingStorageCachedTaskBuffer).

## Die Konsole gibt an, dass Ihre Volume verloren ist
<a name="troubleshoot-volume-issues.VolumeIrrecoverable"></a>

Wenn die Storage-Gateway-Konsole für gespeicherte Volumes angibt, dass Ihr Volume-Status IRRECOVERABLE ist, können Sie dieses Volume nicht mehr verwenden. Sie können versuchen, das Volume in der Storage-Gateway-Konsole zu löschen. Wenn sich Daten auf dem Volume befinden, können Sie die Daten wiederherstellen, wenn Sie einen neuen Volume erstellen der auf der lokalen Festplatte der VM basiert, die ursprünglich verwendet wurde, um das Volume zu erstellen. Wenn Sie das neue Volume erstellen, wählen Sie **Vorhandene Daten behalten** aus. Stellen Sie sicher, ausstehende Snapshots des Volumes zu löschen, bevor Sie das Volume löschen. Weitere Informationen finden Sie unter [Löschen von Snapshots Ihrer Speichervolumes](DeletingASnapshot.md). Wenn das Löschen des Volumes in der Storage-Gateway-Konsole nicht funktioniert, dann wurde der Datenträger für das Volume möglicherweise nicht ordnungsgemäß aus der VM entfernt und kann nicht aus der Appliance entfernt werden.

Wenn die Storage-Gateway-Konsole für zwischengespeicherte Volumes angibt, dass der Status Ihres Volumes IRRECOVERABLE lautet, können Sie dieses Volume nicht mehr verwenden. Wenn Daten auf dem Volume liegen, können Sie einen Snapshot des Volumes erstellen und dann Ihre Daten aus dem Snapshot wiederherstellen oder Sie können die Volumes vom letzten Wiederherstellungspunkt aus klonen. Sie können das Volume löschen, nachdem Sie Ihre Daten wiederhergestellt haben. Weitere Informationen finden Sie unter [Ihr Cache-Gateway ist unerreichbar und Sie möchten Ihre Daten wiederherstellen](#RecoverySnapshotTroubleshooting).

Für gespeicherte Volumes können Sie eine neue Volume von der Festplatte erstellen, die zum Erstellen des irreparablen Volumes verwendet wurde. Weitere Informationen finden Sie unter [Ein Speichervolume erstellen](GettingStartedCreateVolumes.md). Informationen zum Volume-Status finden Sie unter [Grundlagen zu Status und Übergängen bei Volumes](StorageVolumeStatuses.md). 

## Ihr Cache-Gateway ist unerreichbar und Sie möchten Ihre Daten wiederherstellen
<a name="RecoverySnapshotTroubleshooting"></a>

Wenn Ihr Gateway nicht erreichbar ist (z. B. wenn es heruntergefahren wurde), haben Sie die Möglichkeit, entweder einen Snapshot von einem Volume-Wiederherstellungspunkt herzustellen und diesen Snapshot zu verwenden oder Sie klonen ein neues Volume anhand vom letzten Wiederherstellungpunktes für eine vorhandene Volume. Das Klonen eines Volume-Wiederherstellungspunkt ist schneller und kostengünstiger als das Erstellen eines Snapshots. Weitere Informationen zum Klonen eines Volumes finden Sie unter [Klonen eines zwischengespeicherten Volumes von einem Recovery Point](clone-volume.md). 

Storage Gateway bietet Wiederherstellungspunkte für jedes Volume in einer zwischengespeicherten Volume-Gateway-Architektur. Ein *Volume-Wiederherstellungspunkt* ist ein Zeitpunkt, zu dem alle Daten des Volumes konsistent sind und von dem Sie einen Snapshot erstellen oder ein Volume klonen können.

## Die Konsole gibt an, das Ihre Volume PASS THROUGH Status hat
<a name="troubleshoot-volume-issues.VolumePassthrough"></a>

In einigen Fällen kann die Storage-Gateway-Konsole darauf hinweisen, dass Ihr Volume den Status PASSTHROUGH aufweist. Ein Volume kann aus unterschiedlichen Gründen den Status PASSTHROUGH annehmen. Einige Gründe erfordern Aktionen, andere nicht. 

Ein Beispiel für wann Sie etwas unternehmen sollten, wenn Ihre Volume den Status PASS THROUGH hat, ist, wenn Ihr Gateway keinen Upload-Pufferspeicherplatz mehr hat. Um zu überprüfen, ob Ihr Upload-Puffer in der Vergangenheit überschritten wurde, können Sie sich die `UploadBufferPercentUsed` Metrik in der CloudWatch Amazon-Konsole ansehen. Weitere Informationen finden Sie unter[Überwachen des Upload-Puffers](PerfUploadBuffer-common.md). Wenn Ihr Gateway den Status PASS THROUGH aufweist, weil kein Upload-Pufferspeicher mehr verfügbar ist, sollten Sie Ihrem Gateway mehr Upload-Pufferspeicher zuweisen. Wenn Sie mehr Pufferspeicher hinzufügen, wechselt der Status Ihres Volumes von PASS THROUGH über BOOTSTRAPPING automatisch zu AVAILABLE. Während das Volume den Status BOOTSTRAPPING aufweist, liest das Gateway Daten vom Datenträger des Volumes, lädt diese Daten in Amazon S3 und holt nach Bedarf auf. Nachdem das Gateway wieder den gewünschten Status hat und die Volume-Daten in Amazon S3 gespeichert wurden, lautet der Volume-Status AVAILABLE und Snapshots können erneut gestartet werden. Beachten Sie, wenn Ihr Volume den PASS THROUGH oder BOOTSTRAPPING Status besitzt können Sie damit fortfahren, die Daten von der Volume Festplatte zu lesen und schreiben. Weitere Informationen zum Hinzufügen weiterer Upload-Pufferspeicher finden Sie unter [Bestimmen der Größe des zuzuordnenden Upload-Puffers](decide-local-disks-and-sizes.md#CachedLocalDiskUploadBufferSizing-common).

Um Aktionen durchzuführen bevor der Upload-Puffer überschritten wird, können Sie einen Grenzwert-Überschreitungsalarm auf dem Upload-Puffer des Gateways einstellen. Weitere Informationen finden Sie unter [So richten Sie einen Obergrenzenalarm für den Gateway-Upload-Puffer ein](PerfUploadBuffer-common.md#GatewayAlarm1-common). 

Im Gegensatz dazu ist ein Beispiel für ein Volume an der keine entsprechende Maßnahme zu ergreifen ist, wenn die Volume auf eine Bootstrap-Aktion wartet, da eine andere Volume derzeit gestartet wird. Das Gateway führt Bootstrap-Aktionen an Volumes nacheinander aus.

Selten, gibt der Status PASS THROUGH an, dass eine Festplatte die einem Upload-Puffer zugeordnet wurde fehlgeschlagen ist. In diesem Fall sollten Sie die Festplatte entfernen. Weitere Informationen finden Sie unter [Arbeiten mit Volume Gateway-Speicherressourcen](resource-volume-gateway.md). Informationen zum Volume-Status finden Sie unter [Grundlagen zu Status und Übergängen bei Volumes](StorageVolumeStatuses.md). 

## Sie möchten Volume-Integrität überprüfen und möglicher Fehler beheben
<a name="troubleshoot-volume-issues.VerifyIntegrity"></a>

Wenn Sie Volume-Integrität überprüfen möchten und mögliche Fehler beheben möchten und Ihr Gateway für die Verbindung zu seinen Volumen, Microsoft Windows Initiatoren verwendet, können Sie das Windows CHKDSK Dienstprogramm verwenden um die Integrität Ihrer Volumes zu überprüfen und jeglichen Fehler auf den Volumes beheben. Windows kann automatisch das CHKDSK-Tool ausführen, wenn auf einer Volume Beschädigungen festgestellt werden oder Sie können es selbst ausführen. 

## Ihre Volume-iSCSI-Target erscheint nicht in Windows Disk Management Konsole
<a name="troubleshoot-volume-issues.DoesNotAppear"></a>

Wenn Ihr Volume iSCSI-Ziel nicht in der Disk Management Konsole in Windows angezeigt wird, überprüfen Sie, ob der Upload-Puffer für das Gateway konfiguriert wurde. Weitere Informationen finden Sie unter [So konfigurieren Sie zusätzlichen Upload-Puffer oder Cache-Speicher für Ihr Gateway](ConfiguringLocalDiskStorage.md#GatewayWorkingStorageCachedTaskBuffer).

## Sie möchten den iSCSI-Volumen-Zielnamen ändern
<a name="troubleshoot-volume-issues.ChangeISCSI"></a>

Wenn Sie den iSCSI-Zielnamen Ihres Volumes ändern möchten, müssen Sie das Volume löschen und es noch einmal mit neuem Zielnamen hinzufügen. Wenn Sie dies durchführen, können Sie die Daten auf dem Volume beibehalten. 

## Ihr geplanter Volume Snapshot taucht nicht auf
<a name="troubleshoot-volume-issues.NoSnapshot"></a>

Wenn das geplante Snapshot eines Volumes nicht auftaucht, überprüfen Sie, ob Ihre Volume den Status PASSTHROUGH besitzt, oder ob der Gateway Upload-Puffer gerade vor dem geplanten Snapshot Uhrzeit aufgefüllt wurde. Sie können die `UploadBufferPercentUsed` Metrik für das Gateway in der CloudWatch Amazon-Konsole überprüfen und einen Alarm für diese Metrik erstellen. Weitere Informationen erhalten Sie unter [Überwachen des Upload-Puffers](PerfUploadBuffer-common.md) und [So richten Sie einen Obergrenzenalarm für den Gateway-Upload-Puffer ein](PerfUploadBuffer-common.md#GatewayAlarm1-common).

## Sie müssen eine Festplatte entfernen oder ersetzen, die ausgefallen ist
<a name="troubleshoot-volume-issues.RemoveVolume"></a>

Wenn Sie einen ausgefallenen Volume-Datenträger austauschen müssen oder ein Volume entfernen möchten, weil es nicht benötigt wird, sollten Sie das Volume zuerst mithilfe der Storage-Gateway-Konsole entfernen. Weitere Informationen finden Sie unter [So löschen Sie ein Volume](ApplicationStorageVolumesCached-Removing.md#CachedRemovingAStorageVolume). Anschließend verwenden Sie den Hypervisor-Client, um den Backup-Speicher zu entfernen:

 
+ Entfernen Sie zum VMware ESXi Beispiel den Backing-Speicher, wie unter beschrieben[Löschen von Speichervolumes](ApplicationStorageVolumesCached-Removing.md).
+ Für Microsoft Hyper-V, entfernen Sie den Backup-Speicher.

## Durchsatz von Ihrer Anwendung zu einem Volume ist auf Null abgefallen
<a name="troubleshoot-volume-issues.ThroughputZero"></a>

Wenn der Durchsatz von Ihrer Anwendung zu einem Volume auf Null abgefallen ist, versuchen Sie Folgendes:
+ Wenn Sie den VMware vSphere-Client verwenden, überprüfen Sie, ob die **Host-IP-Adresse** Ihres Volumes mit einer der Adressen übereinstimmt, die im vSphere-Client auf der Registerkarte **Zusammenfassung** angezeigt werden. Sie finden die **Host-IP**-Adresse für ein Speicher-Volume in der Storage-Gateway-Konsole auf der Registerkarte **Details** für das Volume. Unstimmigkeiten in der IP-Adresse können vorkommen, wenn Sie z. B. Ihrem Gateway eine neue statische IP-Adresse zuweisen. Wenn eine Diskrepanz vorliegt, starten Sie das Gateway über die Storage-Gateway-Konsole neu, wie in [Herunterfahren der Gateway-VM](MaintenanceShutDown-common.md) dargestellt. Nach dem Neustart sollte die **Host IP (Host-IP)**-Adresse auf der Registerkarte **ISCSI Target Info (iSCSI-Zielinformationen)** für ein Speicher-Volume mit einer IP-Adresse in dem vSphere Client auf der Registerkarte **Summary (Übersicht)** für das Gateway übereinstimmen. 
+ Wenn keine IP-Adresse im Feld **Host IP (Host-IP)** für das Volume angezeigt wird und das Gateway online ist. Dies kann auftreten, wenn Sie beispielsweise ein Volume erstellen das einer IP-Adresse eines Netzwerksadapters von einem Gateway mit zwei oder mehr Netzwerkadaptern zugeordnet ist. Wenn Sie den Netzwerkadapter entfernen oder deaktivieren, der dem Volume zugeordnet ist, wird die IP-Adresse möglicherweise nicht im Feld **Host-IP** angezeigt. Um dieses Problem zu beheben, löschen Sie das Volume und erstellen Sie es dann erneut unter Beibehaltung der vorhandenen Daten.
+ Stellen Sie sicher, dass der iSCSI-Initiator den Ihre Anwendung verwendet korrekt dem iSCSI-Ziel für das Speicher-Volume, zugeordnet ist. Weitere Informationen zum Verbinden zu Speicher Volumes finden Sie unter [Von einem Windows-Client aus eine Verbindung zu Ihren Volumes herstellen](ConfiguringiSCSIClient.md).

Sie können den Durchsatz für Volumes anzeigen und Alarme von der CloudWatch Amazon-Konsole aus erstellen. Weitere Informationen über die Messung des Durchsatzes von Ihrer Anwendung zu einer Volume, finden Sie unter [Messung der Leistung zwischen Ihrer Anwendung und dem Gateway](PerfAppGateway-common.md).

## In einem Cache-Datenträger in Ihrem Gateway tritt ein Fehler auf
<a name="troubleshoot-volume-issues.CacheDiskFail"></a>

Wenn bei einem oder mehreren Cache-Datenträgern in Ihrem Gateway ein Fehler auftritt, verhindert das Gateway Lese- und Schreiboptionen auf dem virtuellen Band im Gateway. Um die normale Funktionalität wiederherzustellen, konfigurieren Sie Ihr Gateway wie folgt neu:
+ Wenn der Cache-Datenträger nicht zugänglich oder nicht verwendbar ist, löschen Sie den Datenträger aus Ihrer Gateway-Konfiguration.
+ Wenn der Cache-Datenträger weiterhin zugänglich und nutzbar ist, verbinden Sie ihn erneut mit Ihrem Gateway.

**Anmerkung**  
Wenn Sie einen Cache-Datenträger löschen, sind Bänder oder Volumes mit bereinigten Daten (also Daten, die auf dem Cache-Datenträger und in Amazon S3 synchron sind) weiterhin verfügbar, wenn das Gateway wieder normal funktioniert. Wenn Ihr Gateway beispielsweise über drei Cache-Datenträger verfügt und Sie zwei löschen, haben Bänder oder Volumes, die unbeschrieben und fehlerfrei sind, den Status AVAILABLE. Andere Bänder und Volumes erhalten dann den Status IRRECOVERABLE.  
Wenn Sie kurzlebige Datenträger als Cache-Festplatten für Ihr Gateway verwenden oder Ihre Cache-Festplatten auf einem kurzlebigen Datenträger bereitstellen, gehen Ihre Cache-Festplatten verloren, wenn Sie das Gateway herunterfahren. Wenn Ihr Cache-Datenträger und Amazon S3 nicht synchronisiert werden, kann das Herunterfahren des Gateways zu Datenverlust führen. Aus diesem Grund raten wir von der Verwendung flüchtiger Laufwerke oder Datenträger ab.

## Ein Volume Snapshot hat einen PENDING Status länger als erwartet
<a name="SnapshotTroubleshooting.Pending"></a>

Wenn ein Volume-Snapshot länger als erwartet im Status PENDING bleibt, ist die Gateway-VM möglicherweise unerwartet abgestürzt oder der Status eines Volumes hat sich zu PASS THROUGH oder IRRECOVERABLE geändert. Wenn einer dieser Vorkommnisse der Fall ist, bleibt der Snapshot im PENDING Status und der Snapshot wird nicht vollständig ausgeführt. In diesen Fällen empfehlen wir, dass Sie den Snapshot löschen. Weitere Informationen finden Sie unter [Löschen von Snapshots Ihrer Speichervolumes](DeletingASnapshot.md).

Wenn das Volume auf den Status AVAILABLE zurückkehrt, erstellen Sie einen neuen Snapshot des Volumes. Informationen zum Volume-Status finden Sie unter [Grundlagen zu Status und Übergängen bei Volumes](StorageVolumeStatuses.md).

## 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 [Beheben von Problemen mit Hochverfügbarkeit](troubleshooting-ha-issues.md).

# Beheben von Problemen mit 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.