IB in the Wide Area How can IB help solve large data problems in the transport arena

Enhanced Capabilities Near real-time access of operational data across the global filesystem –Rapid access to data means faster, more comprehensive, more accurate analysis –Reach back/forward to any data in enterprise to enhance change/pattern, I&W and critical node analysis Enables Real-time (Within Seconds) Ingestion of huge data sets Enhanced situational awareness –Enables dynamic updates to users and analysts –Search within theater data streams Upgraded local storage/caching in reduced footprint

1. Global Situational Awareness – requires dynamic access from very large, distributed data centers 2. Latest imagery streams into global services 3. OTD and Commercial applications used to visualize new imagery 4. Cross-node dynamic data sharing for collaboration

Why do we need a scalable Global File System Must support 100s of users working on thousands of large (GB and TB) file sets –There is nothing like this today with the needed information assurance features –The closest is what some in the HPC are doing on clusters –Must work on multiple transport and storage protocols to get to end users IP, IB, FC, NFS, CIFS, etc Global – Must work over long distances and multiple data centers

Storage-wise… The earlier ‘truths’ drive demand for the following capabilities 1.Capability: disaster recovery Data replication for disaster recovery 2.Capability: performance Geographic locality of data for performance reasons Caching, prefetching 3.Capability: wide area accessability All clients have access to the same datasets (+/- security reqmts) In a nutshell, you’d like to be able to inject raw information into the system from anywhere, and you’d like to provide access to both the raw information and processed data to consumers located anywhere. And, you want to be sure the data is protected and continuously accessible. That’s it!

Storage-wise… This suggests, in turn… –a data store which is globally accessible to facilitate availability and disaster recovery –a globally coherent, application level name space That means that a file identifier used by an application located anywhere in the system will always resolve to the same underlying data. This is important to enable global access to data, to simplify disaster recovery, to support highly available systems and for a host of other reasons. The idea is to make providers and consumers of information truly portable

There are at least three ways to achieve a globally coherent file-level namespace: 1.Brute force: Create a single, globally flat file system 2.Create a single global block-level name space, then force a strong binding to a consistent file-level name space among a set of distributed, federated filesystems 3.Create a consistent file-level name space among a set of distributed, federated filesystems

A globally coherent file-level namespace file system site 1 f/s 1f/s ‘n’ … f/s 1f/s ‘n’ BV site ‘n’ site 1 … site ‘n’ site 1 … site ‘n’ File I/O block I/O As long as: coherence is maintained between the federated filesystems, and as long as each f/s has access to the global data pool, there is no need to enforce a strict binding between block-level I/O and file-level I/O. Coherence at the block I/O level is neither necessary nor sufficient. Global file system Federated file system Block approach

An Idea of a Wide and Distributed Data Center Construct Core Node Components InfiniBand WAN GATEWAY ENCRYPTOR (10 Gbps) STORAGE ARRAY (Petabytes) NetworkStorageController LAN with Local Servers, Apps, & Nets InfiniBand WAN OC-192 (10 Gbps) Core VLH Other Users