DDN Replaces Its Rackspace Server With an Embedded Files.com Pipeline for Terabyte-Scale Diagnostics

DataDirect Networks builds the storage that much of the world's largest computing runs on. Its EXAScaler parallel file system and Infinia data intelligence platform serve HPC and AI workloads across enterprise, government, and research.

Every one of those systems runs inside a customer's environment, not DDN's. When one of them needs support, the evidence an engineer needs has to travel out of that environment first. At DDN's scale, that evidence is heavy. A diagnostic bundle from a parallel file system can run to terabytes, and single log files reach 500 GB. Before a support case can move, that data has to cross from a network DDN does not control into DDN's own support workflow.

Terabyte Diagnostics, Collected by Hand

For years, the receiving end of that crossing was a Rackspace server, and the work around it was manual. Customers sent logs however they could, and someone at DDN had to receive each file, work out which customer and which case it belonged to, and attach it to the ticket. That handling sat in the critical path of every case that needed diagnostics: between a customer with a degraded storage system and the engineer who could fix it. And it had to hold for everyone who depended on the same intake, across technical support, professional services, and L3 engineering.

The conditions made it hard to fix. The intake had to survive unreliable customer networks that drop connections partway through enormous transfers. Some customer sites run firewalls that allow outbound traffic only to explicitly approved destinations. And bundle sizes vary sharply by product line, from terabyte-scale parallel file system logs down to small product-specific dumps. A hosted file server could store whatever arrived, but it offered nowhere near the configuration and protocol range those uploads needed, and it gave DDN's engineers nothing to build on.

What DDN needed was less a destination than a programmable intake layer. Uploads had to arrive already carrying their ticket number. The platform had to speak the protocols customer environments could actually use, complete transfers of hundreds of gigabytes over unreliable links, present an address a restrictive firewall could approve, and expose an API deep enough for DDN's own engineers to build the upload path into the products themselves and wire the output into Salesforce and object storage.

DDN selected Files.com to be that layer and retired the Rackspace server.

From a Click in the Product to a Linked Salesforce Case

In several DDN products, collecting diagnostics is now a feature of the product itself. A customer opens a case and clicks "generate troubleshooting information." The product uploads the bundle directly into Files.com, stamped with the ticket number. No one at DDN asks for the file, and no one at the customer has to decide where to send it.

From there, the pipeline runs on its own. Files.com renames each bundle into the timestamp-first order DDN's engineering automation reads. Remote Server Mounts and a Files.com Automation triggered on file creation hand it to Wasabi or AWS S3, where its ticket number connects it to the Salesforce case. A scheduled files-cli sync retains a copy on an on-premises server, while support engineers retrieve the bundles from Files.com to work the case.

DDN's own staff built all of it, from the upload path inside the products to the downstream wiring, using the Files.com REST API and Python SDK.

Reaching Customer Sites DDN Does Not Control

Not every upload comes from inside a product. DDN also gives its customers Files.com Inbox upload links for sending logs and archives straight to the support team. The intake folders carry write-only permissions and a locked folder structure, so an uploader can add files to the intake path and do nothing else.

The whole intake runs on DDN's own domain with dedicated IP addresses. That matters at sites where the firewall permits outbound traffic only to approved destinations: when one customer's firewall blocked files.com itself, the dedicated addresses kept that customer's logs flowing. For the heaviest transfers, DDN pushes single files of 500 GB through files-cli from customer and internal systems, with completion over unreliable networks an explicit requirement of the design.

What Support Stopped Doing by Hand

With the pipeline in production, DDN replaced manual collection of customer diagnostics with an intake that runs itself.

• Case attachment is automatic. Bundles arrive stamped with their ticket number and land linked to the Salesforce case, so no one receives, sorts, or files a customer log by hand.
• Roughly 260 individual systems feed the platform through automated uploads.
• The intake absorbed a year of growth without changing shape: average monthly transfer volume rose from roughly 5 TB to 8 TB, and one peak month moved close to 20 TB.
• Customers behind restrictive firewalls still deliver their logs over DDN's own domain and dedicated IPs.

The pattern also compounds. Every product line writes into the same intake, whether its bundles are terabyte-scale file system logs or small product-specific dumps, so a new product or a new customer joins the pipeline by uploading to it. Growth in support volume arrives as more transfer, not more hand work.

The Case Opens With Its Evidence Attached

Today, a DDN support engineer opens a case that already has its data. Diagnostic intake and case matching no longer add manual work before investigation can begin.

The change came from treating file intake as something a product can do rather than something a person does. DDN did not put a file portal in front of its support team. It built a diagnostics pipeline into the products it ships, and Files.com is the intake layer those products write to.