AppResponse 11 Storage Configuration REST API Guide =================================================== .. _appresponse-11-storage-configuration-rest-api-guide-1: Overview -------- This guide describes how to programmatically customize storage allocation sizes and data placement for analysis data using the AppResponse 11 REST API. This process allows you to script storage configuration changes across different hardware models. WARNING: Modifying storage layouts can cause data loss and affect system performance. Data area relocations may take hours to complete and involve copying terabytes of data. Resizing packet capture storage will permanently delete captured packet data. Always test configuration changes in a non-production environment first. Understanding AppResponse Storage Architecture ---------------------------------------------- AppResponse 11 uses a hierarchical storage management system with several interconnected components that work together to organize and allocate storage for different types of analysis data. Core Storage Concepts ~~~~~~~~~~~~~~~~~~~~~ **Data Modules** represent the different analysis engines and components that need to store data on the system. Think of these as the "applications" that consume storage - each one has specific requirements for how much space it needs, where that data can be stored, and how it should be managed. Examples include: - Packet trace analysis engines that store raw network traffic - Aggregation services that maintain summarized metrics over time - Transaction analysis systems that track application-level conversations - Database analysis components that monitor SQL queries and sessions **Data Sections** are the physical storage volumes where data actually lives. These correspond to RAID arrays, individual disks, or external storage units connected to your AppResponse appliance. Each data section has a specific capacity, performance characteristics, and role in the system. The system automatically detects available data sections based on your hardware configuration. **Data Areas** represent the actual allocated storage space for each data module on each data section. These are where your analysis data is physically stored. Each data area has a soft quota (a target size allocation) and tracks how much space is actually being used. The system manages these quotas cooperatively - data modules are expected to respect their allocations but the system doesn't enforce hard limits that could cause analysis failures. **Layouts** are predefined configuration templates that describe how data areas should be organized across your available data sections. They define default size allocations, which data modules can be placed on which storage volumes, and any constraints or relationships between different data areas. Data Module Reference ~~~~~~~~~~~~~~~~~~~~~ The following table lists the key data modules and their purposes: +--------------------+------------------------+------------------------------+ | **Data Module ID** | **Human-Readable | **Description** | | | Name** | | +====================+========================+==============================+ | system_data | System Data | Core system storage (not | | | | customizable) | +--------------------+------------------------+------------------------------+ | probe_data | Packet Traces (PCAP) | Raw packet trace storage | +--------------------+------------------------+------------------------------+ | probe_indexes | Packet Microflow | Packet microflow indexes for | | | Indexes | fast searching | +--------------------+------------------------+------------------------------+ | packet_capture | Capture Jobs | Active packet capture | | | | storage | +--------------------+------------------------+------------------------------+ | dba_history | DBA Aggregates | Database analysis historical | | | | aggregates | +--------------------+------------------------+------------------------------+ | npm_aggregation | ASA/UCA/WTA/CXA | Application analysis | | | Aggregates | aggregate data | +--------------------+------------------------+------------------------------+ | transactions | Transaction Data | Parent module for all | | | | transaction analysis data | +--------------------+------------------------+------------------------------+ | transactions_cache | Transaction Data Cache | ClickHouse cache for | | | | transaction data | +--------------------+------------------------+------------------------------+ Hardware Model Storage Configurations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Different AppResponse models have varying storage architectures and naming conventions: **Physical Models with Internal Storage:** - **primary_data**: Main system storage for analysis data and indexes (roles: ["data"]) - **primary_capture_data**: High-performance storage volume optimized for packet capture workloads (roles: ["data", "capture"]) **Models with Storage Unit Support:** - **primary_data**: Main system storage for analysis data and indexes (roles: ["data"]) - **secondary_data**: Internal storage that contains Transaction and Aggregates data sections. - **{prefix}{serial_number}**: External Storage Unit volumes (e.g., GF0PM000036D6, MEXPM000036D6) - **ch_cache (SCAN-8190 only)**: System-managed ClickHouse cache volume (not user-configurable) **Virtual and Cloud Appliances:** - **primary_data**: Main system storage - **primary_capture_data**: Variable-sized capture storage configured during deployment Layout Types and Naming ~~~~~~~~~~~~~~~~~~~~~~~ Different hardware models support different layout configurations: - **custom_pktprio (Packet Priority)**: Default layout optimizing for packet capture performance. Available on most models. - **custom_metprio (Metrics Priority)**: Layout optimizing for analysis data performance, typically moving analysis datasets to dedicated storage. Requires target data section specification. - **default (Default)**: Standard layout used primarily on SCAN-8190 models. Non-Customizable System Areas ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following data areas are managed exclusively by the system and cannot be modified through this API: - **system_data**: Core system storage including operating system files, logs, and system databases - **report_snapshots**: Stored report outputs and scheduled report data (child of system_data) - **sysdumps**: System diagnostic dumps and crash information (child of system_data) - **ch_cache (SCAN-8190 only)**: ClickHouse database cache storage API Workflow ------------ Authentication Requirements ~~~~~~~~~~~~~~~~~~~~~~~~~~~ All REST API operations require Bearer token authentication. You must obtain an API token through the AppResponse authentication REST API before using these endpoints. Refer to the AppResponse 11 API Authentication documentation for complete token setup procedures. All requests must include: - Authorization: Bearer {your_token} header for authentication - Content-Type: application/json header for requests with JSON payloads Step 1: Retrieve Current Storage Configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Begin by getting the current storage layout configuration. This will show you all available data sections, current data area allocations, and sizing constraints.:: curl -k -H "Authorization: Bearer {your_token}" \\ -H "Content-Type: application/json" \\ -X GET https://your_appresponse/api/npm.data_manager/2.1/layout **Expected Response Structure:**:: { "name": "custom_pktprio", "status": "idle", "data_section": "primary_data", "customized": false, "configuration": { "session_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "valid_data_sections": ["primary_data", "primary_capture_data", "MEXPM000036D6"], "data_sections": [ { "id": "primary_data", "label": "Primary System/Data Volume", "mode": "raid6", "total_space_mb": 6599653, "supports_encryption": false, "encrypted": false, "status": "active", "roles": ["data"], "primary": ["data"] }, { "id": "MEXPM000036D6", "label": "Storage Unit MEXPM000036D6", "storage_unit": "MEXPM000036D6", "model": "SU-20TB", "mode": "raid6", "total_space_mb": 45875200, "supports_encryption": true, "encrypted": false, "status": "active", "roles": ["data"], "primary": [] }, // ... additional data sections may be present ], "data_areas": [ { "data_module_name": "probe_data", "data_section_id": "primary_data", "quota_size_mb": 602112, "used_space_mb": 245830, "min_size_mb": 10, "max_size_mb": 3000000, "enabled": true, "resizable": true, "relocatable": true, "valid_data_sections": ["primary_data"], "status": "active" }, { "data_module_name": "transactions", "data_section_id": "primary_data", "quota_size_mb": 486744, "used_space_mb": 185420, "min_size_mb": 0, "max_size_mb": 20000000, "enabled": true, "resizable": true, "relocatable": true, "valid_data_sections": ["primary_data", "MEXPM000036D6"], "status": "active" }, { "data_module_name": "packet_capture", "data_section_id": "primary_capture_data", "quota_size_mb": 5120000, "used_space_mb": 3200000, "min_size_mb": 51200, "max_size_mb": 15000000, "enabled": true, "resizable": true, "relocatable": false, "valid_data_sections": ["primary_capture_data"], "status": "active" }, // ... additional data areas (typically 15-25 total entries) ] } } Space Management Considerations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ AppResponse systems typically operate near full capacity with minimal free space. When modifying quotas: - **Balanced Operations Required**: Growing one data area typically requires shrinking another by the same amount - **Total Space Verification**: Ensure total allocations do not exceed available storage capacity - **Only Parent Modules Resizable**: Transaction data contains additional automatically-managed child data areas. Only the parent Transactions data area can be resized. Step 2: Plan Your Storage Changes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Identify the data areas you want to modify and determine valid targets for any relocations. Pay special attention to these key fields: **For Size Changes:** - quota_size_mb: Current allocated size - used_space_mb: Actually consumed space - min_size_mb / max_size_mb: Allowable size range - resizable: Whether size can be changed **For Relocations:** - relocatable: Indicates whether this data area can be moved to a different data section - valid_data_sections: Provides a list of data sections where this data area can be placed - Current data_section_id: Shows where the data currently resides on your system **Key Customizable Data Modules:** +-----------------+------------------------+---------------+-----------------+----------------+ | **Data Module** | **Description** | **Resizable** | **Relocatable** | **Notes** | +=================+========================+===============+=================+================+ | probe_data | Raw packet trace | ✓ | ✗ | Size is | | | storage | | | adjustable, | | | | | | but location | | | | | | remains fixed | | | | | | on primary | | | | | | storage | +-----------------+------------------------+---------------+-----------------+----------------+ | probe_indexes | Packet microflow | ✓ | ✗ | Size is | | | indexes for fast | | | adjustable, | | | searching | | | but must | | | | | | remain on same | | | | | | storage as | | | | | | probe_data | +-----------------+------------------------+---------------+-----------------+----------------+ | packet_capture | Active packet capture | ✓ | ✓ | Both size and | | | storage | | | location can | | | (performance-critical) | | | be modified to | | | | | | optimize | | | | | | capture | | | | | | performance | +-----------------+------------------------+---------------+-----------------+----------------+ | dba_history | Database analysis | ✓ | ✓ | Both size and | | | historical aggregates | | | location can | | | | | | be modified to | | | | | | any compatible | | | | | | storage | | | | | | section | +-----------------+------------------------+---------------+-----------------+----------------+ | npm_aggregation | ASA/UCA/WTA/CXA | ✓ | ✗ | Size is | | | Aggregates | | | adjustable, | | | | | | but location | | | | | | remains fixed | | | | | | (shares | | | | | | dependencies | | | | | | with | | | | | | dba_history) | +-----------------+------------------------+---------------+-----------------+----------------+ | transactions | Parent module for all | ✓ | ✗ | Acts as a | | | transaction analysis | | | sized | | | data | | | container for | | | | | | individual | | | | | | Transactions | | | | | | data types | +-----------------+------------------------+---------------+-----------------+----------------+ Step 3: Modify Configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Create your modified configuration by updating the quota_size_mb values and optionally changing data_section_id assignments for data areas you wish to relocate. **Example: Relocating Transaction Data to Storage Unit** **Before:**:: { "data_module_name": "transactions", "data_section_id": "primary_data", // ← Currently on primary_data "quota_size_mb": 486744 // ← Current size: ~475 GB } **After (modification to submit):**:: { "name": "custom_pktprio", "data_section": "primary_data", "configuration": { "data_areas": [ { "data_module_name": "transactions", "data_section_id": "MEXPM000036D6", // ← Changed to Storage Unit "quota_size_mb": 2000000 // ← Increased to ~1.95 TB }, // ... include all other data areas with existing or modified values ] } } Transaction Module Dependencies ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When relocating data areas belonging to Transactions, a Transactions data area with non-zero allocation must exist on the target Data Section. This ensures proper parent-child relationships are maintained within the storage hierarchy and that space has been allocated to receive the data type. A Transactions quota size may be increased (even from an initial value of 0) and have a Transactions child data area assigned to it in the same step. The transaction data hierarchy includes both direct children of transactions and intermediate parent modules that themselves contain child data areas. When relocating data areas, intermediate parent data areas (such as wta, dba, voip) must be assigned to the same data section as their child data areas. **Transaction Data Hierarchy:** +-------------------+----------------------+--------------+---------------------+ | **Data Module | **Human-Readable | **Parent | **Notes** | | ID** | Name** | Module** | | +===================+======================+==============+=====================+ | tcp_flowmetrics | TCP Connections | transactions | Direct child of | | | (ASA) | | transactions | +-------------------+----------------------+--------------+---------------------+ | ssl_sessions | SSL Processed | transactions | Direct child of | | | Connections | | transactions | +-------------------+----------------------+--------------+---------------------+ | cx_analysis | Citrix | transactions | Direct child of | | | Sessions/Connections | | transactions | | | (CXA) | | | +-------------------+----------------------+--------------+---------------------+ | dns_transactions | DNS/Transactions | transactions | Direct child of | | | (DNS) | | transactions | +-------------------+----------------------+--------------+---------------------+ | wta | Web Pages/Objects | transactions | Intermediate parent | | | (WTA) | | - must be on same | | | | | data section as its | | | | | children | +-------------------+----------------------+--------------+---------------------+ | wta_pages | Web Pages (WTA) | wta | Child of wta | | | | | intermediate parent | +-------------------+----------------------+--------------+---------------------+ | wta_pageobjects | Web Page Objects | wta | Child of wta | | | (WTA) | | intermediate parent | +-------------------+----------------------+--------------+---------------------+ | dba | DB Queries/Sessions | transactions | Intermediate parent | | | (DBA) | | - must be on same | | | | | data section as its | | | | | children | +-------------------+----------------------+--------------+---------------------+ | dba_sqlqueries | DB Queries (DBA) | dba | Child of dba | | | | | intermediate parent | +-------------------+----------------------+--------------+---------------------+ | dba_sqlsessions | DB Sessions (DBA) | dba | Child of dba | | | | | intermediate parent | +-------------------+----------------------+--------------+---------------------+ | voip | Voice/Video | transactions | Intermediate parent | | | Calls/Sessions (UCA) | | - must be on same | | | | | data section as its | | | | | children | +-------------------+----------------------+--------------+---------------------+ | voip_calls | Voice/Video Calls | voip | Child of voip | | | (UCA) | | intermediate parent | +-------------------+----------------------+--------------+---------------------+ | voip_connections | Voice/Video | voip | Child of voip | | | Connections (UCA) | | intermediate parent | +-------------------+----------------------+--------------+---------------------+ | voip_rtp_channels | Voice/Video RTP | voip | Child of voip | | | Channels (UCA) | | intermediate parent | +-------------------+----------------------+--------------+---------------------+ Step 4: Validate Configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Submit your modified configuration for validation before applying it. The system will check constraints, capacity limits, and may automatically adjust values. **Important: Session ID Race Condition Prevention** The session_id field in your configuration payload serves as a concurrency control mechanism to prevent conflicting configuration changes. This value **must exactly match** the current session_id returned by the most recent GET /layout request. If another user or process modifies the storage configuration after you retrieve it, your session_id becomes outdated and the validation request will fail. If you encounter a session_id mismatch error: 1. Retrieve the current configuration again with GET /layout 2. Re-apply your modifications to the new configuration structure 3. Submit the updated configuration with the new session_id: :: curl -k -H "Authorization: Bearer {your_token}" \\ -H "Content-Type: application/json" \\ -X POST -d @payload.json \\ https://your_appresponse/api/npm.data_manager/2.1/layout/validate **Validation Response:**:: { "valid": true, "changes": { "ordering": ["move", "grow"], "move": [ { "data_area": { "data_module": "transactions", "data_section": "primary_data" }, "data_section": "MEXPM000036D6" } ], "grow": [ { "data_area": { "data_module": "transactions", "data_section": "MEXPM000036D6" }, "quota_size_mb": 2000000 } ] }, "configuration": { "session_id": "a1b2c3d4-e5f6-4789-9012-123456789abc", "valid_data_sections": ["primary_data", "primary_capture_data", "MEXPM000036D6"], "data_areas": [ // ... complete updated configuration with any system adjustments ] }, "messages": [ { "description": "Transaction data will be moved to Storage Unit MEXPM000036D6", "severity": "notice" }, { "description": "Transaction storage allocation will be increased to 2000000 MB", "severity": "info" }, { "description": "Other data areas may be automatically resized to accommodate this change", "severity": "notice" } ] } Understanding Validation Messages ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The messages array provides important information about what changes will be made and their potential impact. Pay close attention to these messages to ensure the changes are as intended: **Message Severity Levels:** - info: Informational messages about the changes being made - notice: Important warnings about potential side effects or data impacts - error: Problems that prevent the configuration from being applied **Important Message Types to Review:** - **Data Movement Notifications**: Confirm that data relocations are to the intended target data sections - **Size Change Notifications**: Verify that quota adjustments match your expectations - **Data Loss Warnings**: Understand what historical data may be automatically deleted - **Capacity Impact Warnings**: Be aware of how changes may affect other data areas **Before proceeding to Step 5, you should carefully review all validation messages to ensure:** - The changes described in the validation response match your original intentions - Any data loss warnings are acceptable and understood for your specific use case - You fully understand the timeline and potential impact of the proposed changes on system operations Step 5: Apply Configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~ If validation succeeds (valid: true) and you have reviewed the messages, submit the configuration using the exact configuration object returned by the validation step: **CRITICAL**: You must take the "configuration" object from the validation response payload and use it to replace the "configuration" property in the original layout structure obtained from your GET /layout request. Do not modify the validated configuration data - copy it exactly as returned by the validation step. **Creating the validated payload file:** 1. Take the original layout structure from your Step 1 GET request 2. Replace the "configuration" section with the "configuration" object from the validation response 3. Save this combined structure as validated_payload.json For example, if your validation response contained: :: { "valid": true, "configuration": { "session_id": "a1b2c3d4-e5f6-4789-9012-123456789abc", "valid_data_sections": ["primary_data", "MEXPM000036D6"], "data_areas": [ // ... validated data areas ] } } Create your validated_payload.json by combining the original layout structure with the validated configuration: :: { "name": "custom_pktprio", "data_section": "primary_data", "configuration": { "session_id": "a1b2c3d4-e5f6-4789-9012-123456789abc", "valid_data_sections": ["primary_data", "MEXPM000036D6"], "data_areas": [ // ... exact data_areas array from validation response ] } } **Submit the validated configuration:**:: curl -k -H "Authorization: Bearer {your_token}" \\ -H "Content-Type: application/json" \\ -X PUT -d @validated_payload.json \\ https://your_appresponse/api/npm.data_manager/2.1/layout **Important**: The application returns "status": "pending" to indicate the change has been successfully submitted for processing. Changes are applied asynchronously and may take several minutes to complete. Step 6: Verify Changes ~~~~~~~~~~~~~~~~~~~~~~ Retrieve the current configuration again to confirm changes have taken effect: :: curl -k -H "Authorization: Bearer {your_token}" \\ -H "Content-Type: application/json" \\ -X GET https://your_appresponse/api/npm.data_manager/2.1/layout **After applying changes, you should verify that the operation completed successfully:** - Confirm that data area quotas now match your expected values - Verify that data areas appear on the correct data sections (particularly important for relocations) - Check that the API response contains no error messages or warnings - Ensure that the system continues normal operation without performance issues Data Area Relocation Process ---------------------------- Moving data areas between data sections involves physical data movement and copying operations: Determining Valid Relocation Targets ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For each data area, check the valid_data_sections array and relocatable flag in the GET response. This tells you which data sections can host that particular data module. Data Movement Timeline Expectations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Data Movement Impact**: During data area relocation operations, you should be aware that: - All analysis components are temporarily shut down to ensure data safety throughout the process - You may see errors or warnings in other areas of the web interface during this time, which is normal - Operations may take anywhere from 1 to 12+ hours depending on the amount of data being moved - Other data areas may automatically shrink to make space, which can potentially cause loss of their oldest historical data - Packet capture data may show gaps if capture areas are resized during the operation Service Shutdown During Movement ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When relocating data areas, the system temporarily stops analysis services that depend on the data being moved. This ensures data integrity during the copy operation. Services automatically restart once the relocation completes successfully. Common Validation Errors ------------------------ Data Section Validation Errors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Error: Invalid data section target**:: { "valid": false, "messages": [ { "description": "Data Section MEXPM000036D6 not valid for custom_pktprio", "severity": "error" } ] } Move Conflict Errors ~~~~~~~~~~~~~~~~~~~~ **Error: Conflicting data movement operations**:: { "valid": false, "move_conflict": { "conflicting_data_section": "MEXPM000036D6", "moving_to": ["transactions"], "moving_from": ["dba_history"] }, "messages": [ { "description": "Moving data to volume 'MEXPM000036D6' must be a separate action from moving data away from volume 'MEXPM000036D6'", "severity": "error" } ] } **Understanding Move Conflicts**: This error occurs when your proposed changes would simultaneously move data both TO and FROM the same data section. The system cannot safely execute these operations in a single step because it would need to temporarily store data somewhere to make space for the moves. **Common Scenarios That Cause Move Conflicts:** Several types of operations can trigger move conflict errors: - Attempting to swap data areas between two data sections (for example, moving transactions from primary_data to MEXPM000036D6 while simultaneously moving dba_history from MEXPM000036D6 to primary_data) - Trying to relocate multiple data areas to a data section that already has other data areas being moved away from it in the same operation - Proposing complex reorganizations that involve circular data movement patterns where data needs to move through multiple sections **Resolution**: Perform the data movements in separate operations. For example, first move data away from the target data section, then move new data to it. System Processing Behavior -------------------------- Validation Phase ~~~~~~~~~~~~~~~~ During the validation phase, the system performs several important checks: - The system checks all size constraints and capacity limits across all data sections to ensure feasibility - It validates that data section assignments are legal and supported for each data module - The system verifies Storage Unit availability and accessibility before proceeding - The validation process may automatically adjust quota values to ensure system requirements are met - Validation typically completes within 10-60 seconds depending on configuration complexity - The system returns a modified configuration if any adjustments were made to your original request Configuration Application Phase ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Status Values During Reconfiguration:** - idle: No operation in progress, system ready for changes - pending: Changes accepted and queued for processing - reconfiguring: Active reconfiguration operation in progress - reboot_required: Changes complete but system restart needed to activate - failed: Configuration failed (requires investigation) **Progress Tracking**: When status is reconfiguring, the progress field shows completion percentage (0-100%) based on the number of operations completed. Note that operations may take different amounts of time, so the percentage is not an accurate estimation of time remaining. **During Reconfiguration:** - Affected analysis services are temporarily stopped - Data areas being moved show as temporarily unavailable - System performance may be reduced during data copying - Web interface may show service status warnings Monitoring Progress ~~~~~~~~~~~~~~~~~~~ Track reconfiguration progress with periodic status checks: :: curl -k -H "Authorization: Bearer {your_token}" \\ -H "Content-Type: application/json" \\ -X GET https://your_appresponse/api/npm.data_manager/2.1/layout **Status Response During Reconfiguration:**:: { "name": "custom_pktprio", "status": "reconfiguring", "progress": 65, "configuration": { "session_id": "a1b2c3d4-e5f6-4789-9012-123456789abc" // ... current target configuration } } Verification and Post-Configuration Steps ----------------------------------------- Handling Required Reboots ~~~~~~~~~~~~~~~~~~~~~~~~~ If the system status shows reboot_required, reboot the system before proceeding with verification steps. Confirming Successful Application ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Only perform verification steps after any required reboot has been completed and the system shows status: "idle". 1. **Verify Layout Status:** :: curl -k -H "Authorization: Bearer {your_token}" \\ -H "Content-Type: application/json" \\ -X GET https://your_appresponse/api/npm.data_manager/2.1/layout Confirm status field shows idle and customized shows true if you made changes from defaults. 2. **Check Individual Data Areas:** :: curl -k -H "Authorization: Bearer {your_token}" \\ -H "Content-Type: application/json" \\ -X GET https://your_appresponse/api/npm.data_manager/2.1/data_areas?data_module_name=transactions **Expected Response:**:: { "items": [ { "data_module_name": "transactions", "data_section_id": "MEXPM000036D6", "quota_size_mb": 2000000, "used_space_mb": 185420, "status": "active", "path": "/data/MEXPM000036D6/transactions" } ] } 3. **Monitor System Health:** - Check that analysis services have resumed normal operation - Verify that new data is being written to relocated data areas - Confirm web interface shows updated storage allocations Troubleshooting --------------- Configuration Stuck in "reconfiguring" Status ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Symptoms:** - Status remains reconfiguring for extended periods - Progress percentage stops advancing **Resolution:** Contact Riverbed Technical Support with current system status and progress information. Services Not Resuming After Reconfiguration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Symptoms:** - Analysis data stops updating after configuration changes - Web interface shows stale or missing data **Resolution:** If indicated on the Storage Configuration page, reboot the the system after the reconfiguration. Contact Riverbed Technical Support if the problem persists or the Storage Configuration page does not indicate that rebooting is necessary. Session ID Mismatch Error ~~~~~~~~~~~~~~~~~~~~~~~~~ **Error Message:** "The storage layout has been reconfigured; you must reload the page" **Cause:** This error occurs when the session_id in your configuration payload does not match the current session_id on the system. The session ID acts as a concurrency control mechanism to prevent conflicting storage configuration changes. When another user, process, or even the same user in a different session modifies the storage layout between the time you retrieved the configuration and when you attempted to validate or apply changes, your session ID becomes outdated. **Common Scenarios:** - Multiple users modifying storage configuration simultaneously - Multiple API scripts running concurrently - A long delay between retrieving the configuration (Step 1) and applying changes (Step 4/5) - Browser page refresh or session timeout in the web interface - System maintenance operations that reset the configuration state **Resolution:** 1. Retrieve the current storage configuration again using GET /layout 2. Note the new session_id value in the response 3. Re-apply your modifications to the newly retrieved configuration structure 4. Ensure your payload includes the new session_id value 5. Submit the updated configuration for validation and application **Prevention Tips:** - Minimize the time between configuration retrieval and application - Coordinate storage configuration changes across team members - Use the validation step to catch session ID conflicts before final application Support Escalation ~~~~~~~~~~~~~~~~~~ **Contact Riverbed Technical Support for:** - Reconfiguration operations that fail or do not complete - System status showing failed after configuration changes - Any unexpected errors during validation or application - Questions about hardware-specific configuration options **When contacting support, provide:** - Sysdump file (most important - contains comprehensive system state) - Description of the intended changes and business justification - Exact steps taken (API calls made with request/response data) - Error messages observed during validation or application - Hardware model and Storage Unit configuration details - Timeline of when issues were first observed This REST API provides advanced storage management capabilities that directly affect your AppResponse system's data retention and performance. The web UI provides additional safety checks and guided workflows for common operations. Use this programmatic API when automation or scripting is required, and always validate changes thoroughly before applying to production systems.