/docs/MyDocs

Summary

-------

 - High speed streaming: software raid of few iSER disks (using tgt, may

 be lio/tcm in future)

 - Cluster of multiple standard nodes (no big storage nodes): Gluster

 - Single storage node and several computational nodes: iSER + OCFS2

 - Few big storage nodes: Lustre/Gluster/FhGFS ?

 

iSCSI / iSER

------------

 - According to the benchmarks on the net, iSCSI delivers performance on the

 pair with NFS. Few my tests reported about 350 MB/s on the storage capable

 of 3.5 GB/s, though I have not did any tunning. So, we are only interested

 in iSER solutions for high performance systems.

 

 - Terminology

    Target: the server part of protocol

    Initiator: the iSCSI client

 

 - According to the standard multiple initiators may share a single target.

 This is supported by most of the stacks. However, synchronization issues

 are up to the user. So, it is only possible to use with some higher level

 clustering filesystem taking care for locking (for example GFS2).

 

 Server stacks:

  ietd - no iSER support (on 28.11.2012)

  scst - re-implementation of ietd (still no iSER according to documentation)

  stgt - iSER support, but known being not that fast.

  lio/tcm - iSER support is expected in kernel 3.9

 

 Client stacks:

  openiscsi     - iSER is supported

 

  stgt

  ====

    - OpenSuSE does not include support for iSER. The package should be recompiled

    adding  ISCSI_RDMA=1 to make command

    

    List current configuration:

        tgtadm --lld iscsi --op show --mode target

    When properly configured you expected to see:

        Target 1: iqn.ipepdvcompute2.ssd3500

            Driver: iser

        LUN: 0 (this is the virtual adapter LUN)

        LUN: 1 (this is a first published disk LUN)

 

    Configuring (create interface, allow access, and create first disk):

        tgtadm --lld iser --mode target --op new --tid 1 --targetname "iqn.$(hostname).ssd3500"

        tgtadm --lld iser --mode target --op bind --tid 1 --initiator-address ALL

        tgtadm --lld iser --mode logicalunit --op new --tid 1 --lun 1 --backing-store /dev/disk/by-uuid/6eeffa6d-d61e-4157-8732-e1da39368325 --bstype aio

 

    Store current setup

         tgt-admin --dump > /etc/tgt/targets.conf

 

  tcm/lio

  =======

    - Most recent and actively developed solution. Selected for inclusion into the kernel.

    rDMA support is schedulled for integration in kernel 3.9.

    - I checked their git tree, there is no iSER as of 11.2012

 

  openiscsi

  =========

    iscsi_discovery 192.168.11.5 -t iser -f

 

  Performance

  ===========

    - There is multiple options affecting the performance of the system. 

    - LUN types: direct-store (RAW devices) or backing-store (files, etc.)

    - Backend (bs-type): rdwr (cached file access), aio (Kernel AIO), sg (Direct Access)

    - Write cache (write-cache): disabling is good idea for high speed streaming

    - Block Size (block-size): 512 - 4096 (target supports bigger sizes, but initiator not).

    With not standard size (not 512), the O_DIRECT access on the client is failing with

    errno 22.

    - Packet sizes (MaxRecvDataSegmentLength, MaxXmitDataSegmentLength, FirstBurstLength,

    MaxBurstLength) and on the client (node.conn[0].iscsi.MaxRecvDataSegmentLength, 

    node.session.iscsi.FirstBurstLength, node.session.iscsi.MaxBurstLength).

    If segment length are set bellow, the raid blocks size (strip * n_disk), the there is

    problems connecting to the target in the aio mode.

    - For high performance streaming we need: direct-store, aio backend (sg is not working

    for me, but aio gives really good speed), and big buffers

    - On the target side, the read ahead should be set to the strip size (in 512 blocks). It

    is also affects writting speed.

        blockdev --setra 65536 /dev/sdc

 

/etc/tgt/targets.conf:

    default-driver iser

 

    <target iqn.ipepdvcompute2.ssd3500>

    <direct-store /dev/disk/by-uuid/6eeffa6d-d61e-4157-8732-e1da39368325>

        bs-type aio

        MaxRecvDataSegmentLength 2097152

        MaxXmitDataSegmentLength 2097152

        FirstBurstLength 8388608

        MaxBurstLength 8388608

        block-size 512

        write-cache off

    </direct-strore>

</target>

 

 

File Systems

============

 GFS2   - Provides a shared access to a single network block device (like iSCSI,

        NBD, DRBD) to multiple clients providing access syncrhonization (with in

        kernel DLM manager). In the kernel since 2.6.19. However, userland 

        utilities are packaged only for RH.

 OCFS2  - Oracle solution to handle network block devices in cluster. 

        Installation procedure sounds simpler than for GFS. SuSE is supported.

 Lustre - Conists of Management Server (MGS) storing configuration of Lustre

        file-system, Metadata Servers (MDS) and Object Storage Servers (OSS).

        Clients are directly communicating with all these server. The file 

        system is reported to be very fast and scalable. It is developed by

        Sun and currently controlled by Oracle. Seems to have native rDMA

        support. It seems to be fastest system out there and it is specially

        optimzed for MPI IO.

        The main disadvantage it is not in the main-line kernel. The patched

        kernel and e2fsprogs are required (not possible to have just a 

        additional modules). Official patches are made only against RHEL and 

        SLES. As of 11.2012 (3.6 is long out) the latest patches are against 

        kernel 2.6.38. Also, seems to be lacking integrated fault tollerance, 

        3rd party solutions to be used bellow the OSS.

        Details: http://wiki.whamcloud.com/

 HDFS   - File system for Apache Hadoop. In many respects similar to Lustre

        but optimized use case than data nodes are compute nodes as well. 

        It is not a POSIX compatible. The mount is possible through FUSE

        module, but it is performance inoptimal.

        There is 3rd party support for rDMA implemented over JNI interface.

 Gluster- Easy to setup clustering file system. It has only storage servers,

        all meta-data is just rsynced between nodes. The location of file 

        (or chunk) is determined by file name (chunk number?). The storage

        node may declare any directory in it's file system as part of the

        file system (yes, it should not be a standalone mounted partition).

        RDMA support is included out of the box. The current version has 

        performance problems with fast storage (i.e. it is fine 

        interfacing multiple nodes with just a pair of hard drives, 

        but slow if a single node with attached Raid is used). However, 

        nothing in architecture prevents good performance. I guesss it

        is only matter of developing good AIO-based storage module.

 pNFS   - Parallel NFS (part of NFS 4.1 specifications). There is 

        client implementation ready, but no server. Actually, pNFS is 

        best considered as an access method for a real distributed 

        filesystem, not as a complete solution in and of itself. There

        ideas to wrap GFS2, etc. More details: http://linux-nfs.org

        For client to work

            modprobe.d: alias nfs-layouttype4-1 nfs_layout_nfsv41_files

            mount -o minorversion=1 server:/filesystem

         No additional steps are needed to enable pNFS; if the server 

         supports it, the client will automatically use it.

 

 

More

====

 Ceph   - Lustre-style. Has integrated fault tollerance. Automated data 

        migration to avoid hotspots. Merged in 2.6.34. RDMA seems is 

        not available at the moment. After heavy fight with authorization,

        got about 100 MB/s (quite expected without rDMA).

 

 PohmelFS - Consists of 3 components. 

        * Eliptics (a p2p-based storage manager distributing data chunks to nodes

        according to DHT tables (hash). Unlike Gluster, it is fully dynamic, the

        nodes may come and go.

        * Multiple storage backends optimized for different types of data. 

        * PohmelFS kernel module (since 2.6.30) providing a file system on top of

        eliptics. The core components here is the cache coherency management.

        It supports weak synchronization between mounted nodes in that regard, 

        that data read/written into local page cache is not synced with the storage 

        until timeout fires.

        - Eliptics is Yandex development. However, the PohmelFS in the kernel is 

        older and based on something else. It is not clear when new will hit it.

        Also, there are not known users of old a new. Why it end-up in the 

        kernel is unclear...

 

 MogileFS, WebDFS - data distributed through HTTP, metadata in stored 

        in PostgreSQL. Standard drives as storage nodes.

 

 fhgfs  - Fraunhofer file system. Quite unixish and easy to install. Management,

        Meta, and Data services. The client-side kernel module. Uses directories

        as data stores. RDMA support. Max sequential read/write 500 MB/s per 

        node (SSD raid capable of 3.5 GB/s). No complete source available,

        only kernel module and few libraries. There are builds for RHEL, 

        SLES, Debian. SLES build working with OpenSuSE 12.2

 

 GPFS   - proprietary file system from IBM in many ways similar to Lustre.

        Unlike lustre, it has distributed metadata. There is also extra

        features like snapshots, etc.