dCache — xранилище, где живёт ХИГГС

В последнее время было большое количество постов о ЦЕРНе и Большом Адронном Kоллайдере (БАК или LHC). Но не многие знают, что БАК производит ~20 ПБ данных в год. Порядка 50% всех данных хранится в dCache.

dCache является распределённой системой хранения данных, способной работать на обычном железе, с возможностью расширения посредсвом добавления новых узлов. Всё, что нужно для работы на узле, — это JVM (так как всё написано на джаве) и файловая система, где, собственно, и хранятся данные. Типичные инсталляции используют Linux(RHEL/SL/CentOS 6) или Solaris с XFS или ZFS, соответсвенно. В связи с натурой экспериментальных данных dCache не предусматривает изменение хранимых файлов.

dCache разрабатывается с 2000 года и с 2002 года используеться в более чем 80 научных центрах мира, включая Россию. Самые маленькие системы состоят из одного узла в несколько ТБ, самые большие состоят из ~500 узлов с суммарным дисковым пространством в 22 ПБ.



image

dCache поддерживает разные протоколы доступа к данным. Наряду с широкораспространенными стандартными протоколами WebDAV, FTP, NFSv4.1/pNFS используются а также грид протоклы SRM и GRIDFTP.

Самое простое применение dCache — это расспределённый WebDAV сервер. На его основе можно создать свой собственный Cloud Storage, тем более, что уже существует достаточное количество клиентов, использующих HTTP и WebDAV.

Мы расмотрим более банальное применение — распределенное NFSv4.1 хранилище.

Для хранения метадданных dCache использует postgresql.
Итак, приступим:
# yum install postgresql-server
# yum install java-1.7.0-openjdk
# yum install http://www.dcache.org/downloads/1.9/repo/2.6/dcache-2.6.10-1.noarch.rpm
# /etc/init.d/postgresql initdb


В /var/lib/pgsql/data/postgresql.conf включаем TCP:
listen_addresses = 'localhost'

В /var/lib/pgsql/data/pg_hba.conf добавляем
host    all         all         127.0.0.1/32          trust
# IPv6 local connections:
host    all         all         ::1/128               trust


# /etc/init.d/postgresql restart
# su postgres -c "createuser -D -R -S chimera"
# su  postgres -c "createdb -O chimera chimera"
# su  postgres -c "createlang plpgsql chimera"


Все конфигурационные файлы находятся в /etc/dcache директории. Нас интересует только один из них: /etc/dcache/layout/single.conf, где находится описание сервисов, которые должны быть запущены на данном узле.

Говорим dCache, что должно работать в /etc/dcache/layouts/single.conf:

[dCacheDomain]
[dCacheDomain/admin]
[dCacheDomain/broadcast]
[dCacheDomain/poolmanager]
[dCacheDomain/loginbroker]
[dCacheDomain/pnfsmanager]
[dCacheDomain/cleaner]
[dCacheDomain/httpd]
[dCacheDomain/topo]
[dCacheDomain/nfsv41]

Данная кофигурация создаёт dCacheDomain ( каждый домен — одна JVM, один процесс) с соответствующими сервисами.

И конфигурируем дата сервер на том же узле:
# dcache pool create /srv/dcache pool1 pool1Domain

Данная команда добавит в конфигурационный файл pool1Domain с сервисом типа дата сервер с именем pool1:
[pool1Domain]
[pool1Domain/pool]
name=pool1
path=/srv/dcache
waitForFiles=${path}/data


Создаём директорию:
# chimera-cli mkdir /data<br>
# chimera-cli chmod /data 777


И экспортируем в /etc/exports:
/data *(rw)

Запускаем dCache:
# dcache start
Лог файлы находятся в /var/log/dcache.

Так как dCache является распределённым храннилищем, нам нужен NFS клиент, который поддерживает pNFS (parallel NFS). Это RHEL/CentOS 6 или любой другой современный линукс дистрибутив:

# mount -overs=4.1 :/data /data

Чтобы добавить новый узел и, тем самым, расширить хранилище, достаточно на другом хосте поставить пакеты openjdk и dcache, создать
/etc/dcache/layouts/single.conf с одной строкой:
dcache.broker.host=и создать дата сервер:
# dcache pool create /srv/dcache pool2 pool2Domain

Важно помнить, что имена доменов и дата серверов должны быть уникальные.

To steal and contribute code

Код dCache-а находится на гитхабе и, в зависимости от компонента, распостраняется под лицензией AGPL, LGPL и BSD.

Ресурсы:

www.dcache.org
https://github.com/dCache/dcache

Буду рад, если вас интересуют более сложные конфигурации.
Поделиться публикацией
Комментарии 14
    +1
    а он данные дублирует? что будет, если один из узлов пропадет?
      +1
      Да, можно сконфигурировать так, что для каждого файла будет N копий, но не больше чем M. При этом, если нод упадёт, то новая копия будет создана. К тому-же, dCache умеет мигрировать данные на ленту и брать их обрато, если понадобится. Система изначально создавалась как фротэнд для ленточного хранилища.
      0
      У кого-нибудь есть это чудо в продакшене или хотя бы тестировании? Интересно в сравнении, например, с glusterfs.
        0
        Совсем экзотика )) Можно в GRID к ученым подключиться, например. В остальном выглядит не очень удобно. Как большая библиотека, где надо в бахиллах шепотом разговаривать, а под землей миллиарды книг ))

        Подозреваю, что файлы сюда надо складывать медленно и сравнительно нечасто, постгрес умрет без надлежащего вакуума очень быстро.

        >> В связи с натурой экспериментальных данных dCache не предусматривает изменение хранимых файлов.
        Удалить и записать заново?

        В сети не нашел ни бенчей, ни сравнений.
          +1
          Одна группа физиков, которая делает снимки структуры материи пишет 25 файлов в секунду, 6 дней в неделю ( в каждую среду останавливают ускоритель).

          Вот картинка за последние 24 часа

          image
          0
          Порядка 50% всех данных хранится в dCache.
          А остальные где?
            0
            Другие 50% это: CASTOR, DPM, EOS, StoRM, xrootd, BeStMan.
            0
            А можно в двух словах: зачем нужен dCache?
            Я помню, на заре своего существования основная задача, которю он решал была миграция файлов из места постоянного хранения в кэш ближайший к потребителю. А чем он занимается сейчас?

            P.S. Очепятка в «долее сложные конфигурации».

              0
              Основная задача dCache — это построение распределённого хранилища на основе обычного железа. Причём, все сервера видны клиентам как одна большая файловая система, размер которой можно увеличивать по мере надобности. При добавлении нового узла мы увеличиваем как дисковое пространство, так и сетевой канал, так-как клиенты пишут/читают прямо с серверов.

              P.P.S: спасибо, исправил.
                –1
                glusterFS то же самое. И Java не нужна. И всё прозрачно (FUSE, очень мало кода — если что, можно просто посмотреть как что работает). + Какая-никакая поддержка от RH, какие-то тесты, комьюнити.
                И тоже работает на любом железе. И в продакшене работает. И файлы изменять там можно. И 26 файлов в секунду — это не так уж много. Даже если 7 дней в неделю.
                Так почему нам нужен dCache? :)
                  +1
                  25 файлов — это конкретный случай и не единичный.

                  GlusterFS тоже можно использовать. Всё зависит от того что вам надо. Изначально, dCache создавался для предоставления прозрачного доступа к данным на ленте, что по сей день активно используется. dCache поддерживает WebDAV и FTP, которые на glusterFS запустить легко, а вот использовать распределённую природу glusteraFS сложно.

                  Ну а Java есть свои преимущества. Да и код не так страшен, если C читать множите.
                    –1
                    Безусловно, инструмент нужно подбирать под задачи. Вот их и пытаюсь понять.
                    Каюсь, с лентами не сталкивался, но если у «ленты» есть точка монитрования — точно также ее можно использовать в гластере, создав distributed хранилище. Никакой сложности использования распределенной природы глустера НЕТ, сказки это всё.
                    Про преимущества Java — интересно, это какие? :) Проприетарная природа? Любовь к памяти?
                    Да и не в яве как таковой вопрос, хотя от сравнения с C меня и коробит. Вопрос в том, что вы тянете минимум 2 сеьезных зависимости — JVM и БД (пусть даже любимый постгрес). И это только для организации хранилища. Любая зависимость — это ПЛОХО, использование её должно быть обосновано, давать какие-то плюшки, которых не получить без неё. Вот я плюшек-то и не вижу, только зависимости.

                    Это не наезд, мне интересна эта тема, но я не вижу ответов в статье, уж простите.
                  0
                  в сравнении с hdfs что скажете?
                  так понял что в dcache упор на заливку и распределенное хранение любых файлов +доступ по множеству протоколов, ну первое hdfs вроде бы выполняет, вот с протоколами у нее туго.
                    0
                    dCache где-то x2-x4 раза быстрее. HDFS вообще преследует другие цели, и без MR использовать как ФС не имеет смысла. В Hadoop-2.2.0 есть родной NFSv3. Может шустрее работает чем FUSE.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое