Overview

So, you've been supporting DXi for years and are now asked to start supporting Stornext. You understand the Stornext filesystem to a certain degree due to supporting it on the DXi but it turns out, our Stornext offerings are quite extensive and the filesystem is only a small part of what you'll need to know to start taking SRs/Escalations. The purpose of that document is to help bridge the gap while transitioning from DXi to Stornext, or while you might be asked to support both for a time.

 

Why Stornext?

Like other Quantum offerings, Stornext solves several challenges that are faced by many companies. Primarily, it solves challenges experienced by companies who work on media files. Some of the challenges faced by professionals that work with media files:

 

• Performance
  • When files are shared on the network using NAS, latency is high and performance is poor
  • Due to the performance issues files must be copied to local drives before they can be modified. Often just this step can take hours while everyone just sits around for files to be copied to and from local drives
• Capacity/Storing
  • Local drives fill up
  • SAN storage is expensive
  • Scaling requires purchase of more servers/Direct Attached Storage
• Sharing
  • No simultaneous access
  • SMB/NFS/CIFS are all slow with many limitations
• Protection
  • Local drives aren't typically backed up so those files copied to local drives aren't protected
  • As the amount of media files increases, so does the number of disks/servers and so does the number of tape drives/backup software, etc...

 

Stornext offerings provided by Quantum resolve all of these challenges. As found in the StorageCare Learning lesson 1-4564, these issues can be broken down into the following 3 areas:

 

1. Sharing
2. Storing
3. Preserving

 

How?

This document isn't meant to describe all the details but just the basic concepts. The intent is to share just enough to allow for an intelligent conversation with a customer while you continue to learn all of the details.

 

The basic concept goes like this:

 

1. Each solution uses a server/client architecture
   1. Clients
      • SAN
        • Systems directly connected to the SAN via HBA/FC
        • Fastest/Most expensive
      • LAN
        • Systems that connect to Stornext filesystems through a gateway using our own proprietary protocol
        • Slower than SAN, less expensive than SAN, faster than NAS, more expensive than NAS
      • NAS
        • Systems that connect to Stornext filesystems via Samba
   2. Server
      • MDC
        • Server that controls all metadata and access to it
        • All clients connect to the MDC over the LAN, typically a dedicated LAN (MDC LAN) So far I've seen these using 192.168.x.x subnets.
      • DDM (Data Mover)
      • Gateway
        • Listens and hosts connections from LAN clients and NAS clients
        • This includes the snnas stack (Samba, AD, etc...)

 

 

A user on a workstation running a Stornext client will browse to the files they need. (Could be Windows, Linux or Mac). The client talks to the MDC on the LAN over a TCP socket and is then given access to the actual data requested via SAN, LAN or NAS determined by the type of client is being used.

 

Lingo

MXXX (i.e. M440, M660):   These are metadata appliances and all run MDCs in HA. Most SRs I've seen since moving from DXi include an MXXX of some kind.

QXS-XXXX:                        Fast Storage offered/sold by Quantum (Customers can also use their own SAN which is what I've seen more of since moving from DXi)

Gateway:                            Stornext server that handles connections from Stornext clients (Can be on MDC, typically only found on MDC2 in the cluster)

G3XX:                                 Gateway appliances sold by Quantum. Can run in HA configurations

Storage Manager:               Software to handle tiered storage. For example, you can create policies in Storage Manager to automate the movement of old data to tape from a QXS

DDM:                                   Distributed Data Manager. This is used to facilitate the actual movement of data based on Storage Manager policies. It improves performance when archived data is accessed regularly

Lattus:                                 Highly scalable storage with self healing algorithms. An example of Lattus would be a bunch of tiered storage being accessed by the DDM and controlled with Storage Manager

 

Examples 

After understanding why, how and some of the lingo we can look at a few examples. I'll pull some SRs randomly from Outlook and go over them here:

 

1. StorNext M-Series Escalation To SES From SPS: SR3633138, Customer:FOX NEWS CHANNEL -- M662XL / DLAN client are very slow , Serial Number: AV1433CKB00001
   1. Based on the sumary from the email subject, we know the following:
      1. The customer has a bunch of LAN clients
      2. LAN clients connect to a gateway
      3. The Gateway connects to the MDCs (M662xl)TTdffdfThe cus asdfsaf

This means that there's most likely a problem with the network between the Gateway and all the clients. If ifconfig doesn't show errors on the GW and there are no other errors in messages or other logs then the problem is most likely with the netwo