To Next PageTo Next Page
Need help?Do you have a question about the PureStorage FlashArray and is the answer not in the manual?
Specifies the directory paths for SRA and SRM logs on a Linux system.
Specifies the directory paths for SRA and SRM logs on a Windows system.
Confirms SRA presence in Programs and Features and checks essential files.
Search SRA logs for specific error codes and messages indicating issues.
Provides a list of common SRA error codes and their meanings.
Addresses issues like 'invalid credentials' for array managers.
This document provides a comprehensive guide to troubleshooting the Pure Storage FlashArray Storage Replication Adapter (SRA), a crucial component for integrating Pure Storage FlashArray systems with VMware Site Recovery Manager (SRM). The SRA's primary function is to enable disaster recovery and planned migration capabilities for virtualized environments by orchestrating storage replication operations between FlashArray systems under the control of VMware SRM.
The Pure Storage FlashArray SRA acts as a bridge between VMware SRM and Pure Storage FlashArray storage arrays. Its core function is to translate SRM commands into specific operations on the FlashArray, facilitating the replication of virtual machine data. This includes tasks such as discovering storage arrays, identifying replicated datastores, creating and managing replication groups, performing test failovers, actual failovers, and failback operations. By automating these storage-level actions, the SRA ensures that virtual machines can be recovered efficiently and consistently on a secondary site in the event of a disaster or for planned migrations. It manages the underlying replication technology of the FlashArray, ensuring that data synchronization is maintained and that recovery point objectives (RPOs) and recovery time objectives (RTOs) can be met. The SRA is designed to handle various replication scenarios, including one-to-one, one-to-many, and many-to-one configurations, providing flexibility for different disaster recovery architectures. It also plays a vital role in ensuring data integrity and consistency during recovery operations by coordinating with SRM to present the correct replicated volumes to the recovery site hosts.
The SRA offers several features that enhance its usability and integration with VMware SRM. It supports both Linux and Windows appliances for deployment, providing flexibility based on the user's existing infrastructure. For troubleshooting, the document details how to locate SRA and SRM logs on both operating systems, which is essential for diagnosing issues. Each SRA invocation generates a dedicated log file, allowing for a chronological review of executed commands. The SRM logs, specifically vmware-dr-##.log files, are crucial for understanding failures where the SRA responded correctly but SRM failed, or when the SRA crashed on launch. The document emphasizes the importance of quitting SRM and allowing logs to flush before collection.
Installation verification is a key usage feature, with steps provided to confirm the SRA's presence in "Programs and Features" on Windows, locate its installation path in the Registry, and verify the existence of critical files within the SRM storage/sra/purestorage folder. This includes checking for command.pl, PureSRA.exe, PureStorage.Rest.dll, and Newtonsoft.Json, among others. Users are also guided to verify the version and digital signature of PureSRA.exe and confirm the installation of .NET 3.5.
The SRA logs its environment details upon startup, including whether it's running as a 64-bit process and as an administrator, which are critical prerequisites for correct operation. During array pair configuration, the SRA logs the input received from SRM, including XML strings that define "localArray" and "peerArray" connections. This allows users to confirm that the SRA is correctly identifying the intended FlashArray systems for replication.
Error logging is a significant usage feature, with the SRA categorizing log entries by verbosity levels (Errors and Warnings). Specific error codes are provided, such as "1004" for "array unreachable," along with their meanings. The "PureExceptionMessage" within an error provides more specific details about the failure. The SRA also logs HTTP requests and response codes, which can be invaluable for advanced troubleshooting, although the document notes that some HTTP errors are benign and expected.
A tunable HTTP timeout feature allows users to adjust the default 60-second timeout for REST calls, which can be helpful in environments with network latency or slow array responses. This involves modifying a DWORD value in the Windows Registry. Another tunable feature addresses host connection on SRM failover, allowing users to disable the default behavior of prioritizing host group connections if they prefer to connect only to individual hosts.
Maintenance of the SRA primarily revolves around effective troubleshooting and configuration management. The document highlights the importance of regularly reviewing SRA and SRM logs to identify and resolve issues proactively. The detailed error codes and messages provided in the logs are essential for pinpointing the root cause of problems, such as "invalid credentials" for Error 1004, which often indicates incorrect array manager configuration.
The ability to adjust the HTTP timeout value is a maintenance feature that allows administrators to optimize SRA performance in environments where the default timeout may lead to unnecessary failures. Similarly, the option to modify host connection behavior during failover provides flexibility for administrators to align the SRA's actions with specific recovery policies or network configurations.
For deeper diagnostics, the document suggests using Fiddler to capture and analyze HTTPS traffic between the SRA and the FlashArray. This advanced debugging technique, which requires decrypting HTTPS-protected traffic, allows administrators to observe the exact communication flow and identify any anomalies or errors at the network level. The ability to save Fiddler traces for review by the development team is a valuable maintenance tool for complex issues.
The document also reminds users about the necessity of rescanning for the SRA after upgrading it, a critical step to ensure that the updated SRA is correctly recognized and integrated with SRM. This prevents potential errors that might arise from using an outdated or improperly registered SRA. Finally, the guide mentions the option to enable a higher level of logging for more detailed information during troubleshooting. However, it cautions that this should be done carefully and only for short periods to avoid filling up log storage, emphasizing the need to disable it immediately after reproducing an issue. This controlled approach to verbose logging is a key maintenance practice for efficient problem resolution without impacting system performance or storage.
General| Latency | Sub-millisecond |
|---|---|
| Power Supply | Redundant power supplies |
| Type | All-Flash Array |
| Interface | Fibre Channel, iSCSI |
| Deduplication | Yes |
| Compression | Yes |
| Encryption | Yes |
| Form Factor | Rack-mounted |
| Management | REST API, CLI |
| High Availability | Yes |
| RAID | Yes |
| NVMe Support | Yes |
| Data Reduction | Yes (Deduplication, compression, thin provisioning) |
| Data Services | Snapshots, replication, QoS |
| Capacity | Effective capacity up to multiple petabytes, depending on model and data reduction |
| Performance | High (Varies by model, e.g., millions of IOPS, low latency) |
