Руководство пользователя dCache

Заявление.

Автором не найдено ни одного текста на русском языке, который можно рассматривать, как инструкцию для пользователя системы dCache, представляем

Руководство пользователя dCache.

Первоисточники.

Желающие могут посетить http://www. dcache. org/index. shtml и конспектировать оттуда, например:

http://www. dcache. org/manuals/dcache-whitepaper-light. pdf - статью, где авторы dCache на 4 страницах объясняют что это такое, или

http://www. dcache. org/manuals/Book/ - энцеклопедическую работу на 40 листах по инсталляции, настройке и использованию dCache.

Есть также очень толковый, но также несколько избыточный документ рождённый в ЦЕРНе для администраторов dCache http://wiki. gsi. de/pub/Gridadmin/ToDo2005Apr/dCache4SiteAdmins. pdf .

Вообще dCache используется в настоящее время в 35 организациях, таких как:

BNL, CNAF, DESY, FNAL, MDGF, PIC, RAL, SARA. Каждая из них имеет свой набор инструкция, например http://www-cdf. fnal. gov/upgrades/computing/dh/cdf5981/CdfIntroDCacheUseAtCdf/node1.html для FNAL, но надо учитывать, что настройки отличаются от настроек, используемых в ОИЯИ.

Толковое руководство можно также найти в http://storage. esc. rl. ac. uk/documentation/html/D-Cache-Howto/ch11.html

Что такое dCache.

dCache создавалась средство кеширования файлов на дисковых пулами при работе с большими ленточными библиотеками, но затем обрело самостоятельность, т. е. его использование не требует ленточных библиотек. Именно так dCache используется в ОИЯИ и на большинстве других TIER 2. dCache предоставляет доступ к файлам, в том числе средствами GRID, которые логически упорядочены в одно дерево, но физически находятся на разных дисках. dCache может автоматически дублировать информацию и оптимизировать размещение файлов, балансируя нагрузку на дисковые серверы. С точки зрения пользователя dCache полупрозрачная система, т. е. для доступа к файлам используется очень ограниченный набор команд, многие операции можно выполнить исключительно средствами Linux.

Что хранится в dCache

Система ориентированна на хранение больших файлов. Это значит, что помещать в dCache надо результаты экспериментов и моделирования, но никак не программы, для которых предназначена AFS; *.jpeg, *.mp3, *.mov, *.cab и другие продукты жизнедеятельности также не приветствуются.

Доступ к dCache.

Если пользователь зарегистрирован на ферме ЛИТ он может использовать dCache без дополнительных действий. Если доступ к файлам производится с персонального компьютера, включённому в домен *****, на нём должен быть установлен NFS клиент (ставится по умолчанию при установке Linux), клиент dCache и смонтирована директория /pnfs/*****

Для установки клиента dCache надо скачать rpm клиента, например с http://www. dcache. org/downloads/IAgree. shtml и установить его.

Далее надо смонтировать PNFS на своём локальном компьютере командами

mkdir - p /pnfs/*****

mount - o intr, rw, noac, hard *****:/pnfs /pnfs/*****

после этого файлы будут доступными в директории

/pnfs/*****/user/<дальше как в AFS>

Коротко и быстро. Делай как я.

Как добраться до файлов в dCache.

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

После этого могут быть использованы следующие команды:

ls, pwd, find, rm and rmdir, cd, mkdir, ln (только hard links), chown, chmod.

А вот команды которые не могут быть использованы:

cp, mv, cat, more, less, grep, head, tail, wc, od, file.

Использование mc происходит с оглядкой на вышеприведённые списки.

Итак для доступа к информации файла его надо переписать из системы dCache в свою локальную директорию:

а) команда dccp, (далее именуется доступ по dcap) если PNFS смонтирована для копирования туда

dccp $HOME/nobel_price_result. row /pnfs/*****/user/i/iam

и обратно

dccp /pnfs/*****/user/i/iam/two_weeks_of_simulation.001 $HOME/to_cern.001

б) если PNFS не смонтирована, файл адресуется в стиле URL (далее будем называет это url-dcap)

dccp dcap://*****:22125/pnfs/*****/data/cms/sourcefile \ /localpath/destinationfile

в) Если работа производится в окружении GRID, то для доступа используются gsi-ftp (Globus), при этом, разумеется, надо быть зарегистрированным в VO. Копируем туда

globus-url-copy file:/tmp/test gsiftp://*****:2811/pnfs/*****/data/dteam/testfile2

Копируем обратно

srmcp srm://*****:8443/pnfs/*****/dteam/testfile2 file:////tmp/backtest

г) Пример работы в замечательной системе ROOT приведён в http://www. uscms. org/SoftwareComputing/UserComputing/dCache/dCache. html

д) В конце концов можно написать программу используя библиотеку libcap которая предоставляет API POSIX формата. Как утверждают создатели dCache (http://www. dcache. org/manuals/libdcap. shtml) “The libdcap library provides a POSIX like open, create, read, write and lseek functions to the dCache storage.”

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

Для общего развития

Введение в dCache

dCache первоначально разрабатывалась, как интерфейс к хранилищам данных HSM; чтобы уменьшить время операций. Доступ к HSM медленный: (поиск ленты, монтирование ленту, чтение данных и т. д.). Идея заключалась в том, чтобы держать копии недавно используемых файлов на дисковом массиве, таким образом запросы к этим файлам не требовали связи с серверами лент. Потом оказалось, что dCache полезна без лент тоже, когда используются дисковые серверы с большим (десякти Тб) объёмом дискового пространства.

dCache состоит из дисковой памяти, представленной рядом узлов, возможно связанных с HSM. Узлы (так называемые пулы) - обычные дисковые серверы под управлением, по крайней мере Мы имеем дело с dCache без HSM, в этом случае она предоставляет прозрачный доступ к дисковой памяти, состоящей в действительности из нескольких отдельных серверов, предоставляющих дисковую память. Один выделенный компьютер, решает административные задачи. Эта конфигурация не является бесконечной в плане объёма памяти. На дисках в этом случае хранятся файлы для которых опять же на дисках могут быть созданы копии. Учитывая требования к надёжности хранения информации, диски для исходных файлов должны обладать высокой надёжностью, тогда как к пулам содержащим копии такого требования не выдвигатся. Как с HSM так и без, dCache предоставляет единое пространство имён файлов. Это достигается использованием файловой системы pnfs которая специально разработана для dCache. Она скрывает физическое расположение файла от пользователя, устраняя различие между обращением к оригиналу файла, его копии в дисковом кэше, или копии на ленте. dCache включает средства диагностики через www через которые можно получить информацию о пулах, очередях и т. д.
С точки зрения архитектуры система состоит из независимых перемещаемых компонент, называемых ячейками, которые поддерживают постоянную связь друг с другом и реализованных на Java.

Пространство файлов pnfs.

PNFS это виртуальная файловая система, монтируется она так же, как NFS, но не выполняет операций ввода-вывода с файлами. Она только поддерживает группировку имён файлов в дереве директорий и информацию о файлах через набор тэгов, которые хранятся в директориях.

По соображениям безопасности pnfs может быть смонтирована только на компьютерах домена jinr. ry. Для предотвращения неавторизованного доступа к файлам используется обычная авторизация UNIX.

По мнению знатоков (Беркли)

Принципиальными преимуществами безленточной конфигурации dCache являются:

·  Лучшее использование пропускной способности сети через оптимальное размещение информации

·  Возможность использования posix IO для чтения и записи, в отличие от полного копирования файлов

·  Интерфейс ROOT.

·  Не обязательно монтировать Pnfs для доступа к информации.

·  Одинаковый способ доступа к файлам как извне так и изнутри. Защита от левого доступа, через gss и gsi. Разнообразие протоколов доступа.

·  Методы доступа не зависят от физического расположения информации.

·  dCache даже при значительных объёмах предоставляет единое пространство имён и методов доступа к файлам.

·  поддерживается DESY-FNAL с гарантией продолжения развития.

Медленно и подробно

Двери

Клиент посылает запрос на файл данных в систему dCache через дверь. Дверь это сервер который производит аутентификацию пользователя, конвертирует протокол к языку понятному dCache и посылает запрос дальше менеджеру пулов. Дверь общается с остальной системой dCache по внутреннему протоколу, скрывая от пользователя все остальные детали. Дверей может быть много и каждая потенциально поддерживает разные механизмы аутентификации и работает на отдельном компутере. Или не на отдельном. Цель правильной конфигурации дверей – распределение нагрузки и защита от сбоев. Дверь идентифицируется именем компьютера и портом. Двери бывают например FTP для чтения/записи с Керберосом на входе, gridftp, dcap (в качестве родного API), FTP для чтения без Кербероса и т. д. Для зарегистрированных на ферме ЛИТ все двери открыты (по dcap). Есть несколько общих дверей (gridftp, srmcp). Каждый эксперимент может создать свою собственную дверь и ходить только через неё. Если pnfs смонтирован и доступ производится через протокол dcap сервер и порт выбирается автоматически. В остальных случах надо указывать FQDN сервера и порт. В ОИЯИ используется

url-dcap *****:22125

gsiftp *****:22128

srm *****:22127

Этот список будет действовать ограниченное словом “пока” время. В дальнейшем каждая виртуальная организация получит свою дверь и будет через неё входить и выходить. Список дверей будет висеть на где-то на http://grid. *****/enter/

Менеджер пулов.

Любой запрос на пространство будь то PUT или GET, обрабатывается менеджером пула. Он оптимально выбирает подходящий пул и очередь запросов. Каждый пул регистрируется в менеджере с указанием класса памяти и правил доступа к нему.

Пул.

Пул отвечает за непрерывную область дисковой памяти:

-  следит за величиной памяти,

-  поддерживает список файлов, которые можно удалить,

-  инициирует процесс копирования файлов,

-  связывается с клиентом для передачи данных,

-  определяет оптимальное количество задачь передачи данных к конкретной области диска.

Директории pnfs, GRID.

Дерево каталогов отражает сложившееся положение и организовано следующим образом. Для доступа по dcap при смонтированной pnfs

/pnfs/*****/user/<дальше как в AFS>

При доступе по url-dcap

/pnfs/*****/data/user/<дальше как в AFS>

При доступе по gsi-ftp или srm

/pnfs/*****/data/<каталог виртуальной организации>

С чего начать.

Установка и настройка клиента.

Устанавливаем клиент на локальном компьютере. Если AFS уже используется, то вся необходимая dCache инфраструктура (java и т. д.) установлена. Тогда надо получить или установить через yaim lcg-UI

http://grid-deployment. web. cern. ch/grid-deployment/documentation/LCG2-Manual-Install/

и экспортнуть директории

export PATH=/opt/d-cache/srm/bin:$PATH

export SRM_PATH=/opt/d-cache/srm

export GLOBUS_TCP_PORT_RANGE=20000,22000

Если доступ по протоколам grid кажется излишним, тогда скачать dCache Client посвежее, например dcache-client-1.6.6-5.i386.rpm с http://www. dcache. org/downloads/IAgree. shtml

и установить его

rpm –i dcache-client-1.6.6-5.i386.rpm

и дополнить PATH.

export PATH=/opt/d-cache/dcap/bin:$PATH

Теперь надо создать диреторию

/pnfs/*****

и смонтировать там Pnfs ЛИТ ОИЯИ

mount –o intr, hard, rw, noac *****:/pnfs /pnfs/*****

Внимание! Команда mount идёт достаточно медленно.

После этого можно будет посмотреть что там есть в dCache

ls /pnfs/*****/user

получается латинский алфивит, такой же как от ls /afs/*****/user

Права доступа, uid и шизофрения.

Немного технических деталей. Права в системе linux зависят грубо говоря от того, под каким именем личность вошла в систему. С доступом по dcap к смонтированным директориям или всё ясно. Пользователь должен быть зарегистрирован на ферме ЛИТ и тогда права доступа к файлу и назначение uid регулируются правилами linux. Например автор зарегистрирован как

trofimov (uid=8401)

и работает с

/pnfs/*****/user/t/trofimov

Если доступ происходит по gsi-ftp или srm, то доступ происходит сложнее. Пользователь должен иметь действительный grid proxy. Когда он обращается файлам этой виртуальной организации, то идентификация его личности производится средствами системы GRID, а вот на компьютерах фермы ОИЯИ он получает псевдоним, который говорит о его членстве в этой виртуальной организации и всё. Например автор с точки зрения GRID не кто иной как

/C=RU/O=RDIG/OU=users/OU=*****/CN=Vladimir Trofimov

для которого на компьютерах фермы ЛИТ происходир реинкарнация в

dteam001.

Пользователь dteam001 зарегистрирован на ферме ЛИТ под uid=17206. Добро пожаловать в директорию

/pnfs/*****/data/dteam

и никуда больше.

Из ситуации раздвоения личности два выхода. Выход номер один: пользователь в каждый момент работы осознаёт кто он есть – член виртуальной организации или сам по себе пользователь фермы ЛИТ. Выход номер два: все файлы домашнего каталога на ферме ЛИТ за исключением почты и откровенных фотографий получают

сhmod o+r, o+w

а файлы в директориях виртуальных организаций по крайней мере

сhmod o+r

Альтернативой служит решение в стиле Александра Македонского принятое, например, в НИЯФ МГУ: доступ на ферму только средствами GRID.

Игры разума

Проиллюстрируем вышесказанное. Текст компьютера маленький, а команды выделены жирным.

Сижу я на своём компьютере tvv внутри сети ОИЯИ

[tvv] /home/vtrofimov > uname - a
Linux tvv 2.4.21-32.0.1.EL. cern #1 Thu May 26 12:45:05 CEST 2005 i686 i686 i386 GNU/Linux
имея тот же uid, что и на ферме

[tvv] /home/vtrofimov > id uid=8401(vtrofimov) gid=503(vtrofimov) groups=503(vtrofimov)

и смонтированную pnfs

[tvv] /home/vtrofimov > mount | grep pnfs *****:/pnfs on /pnfs/***** type nfs (rw, intr, noac, hard, addr=159.93.39.37)

Благодаря этим двум обстоятельствам я могу узнать, что у меня в системе dCache есть файл

[tvv] /home/vtrofimov > ls - l /pnfs/*****/user/t/trofimov
total 10000
-rw-r--r--  1 8410  500  Mar 16 16:29 test_as_local

Но я не могу просто так узнать, что находится в директории у trofimov, который является членом VO dteam потому что этот член VO закрыл свою директорию от чтения посторонними.

Это я-то посторонний? У меня есть сертификат GRID,

[tvv] /home/trofimov > grid-proxy-info
subject  : /C=RU/O=RDIG/OU=users/OU=*****/CN=Vladimir Trofimov/CN=proxy
issuer  : /C=RU/O=RDIG/OU=users/OU=*****/CN=Vladimir Trofimov
identity : /C=RU/O=RDIG/OU=users/OU=*****/CN=Vladimir Trofimov
type  : full legacy globus proxy
strength : 512 bits
path  : /tmp/x509up_u500
timeleft : 8:52:21

поэтому я могу выяснить, что в директории есть файл

[tvv] /home/trofimov > /opt/edg/bin/edg-gridftp-ls –verbose \ gsiftp://*****/pnfs/*****/data/dteam/trofimov
-rw    test_as_VO1

В дополнение к нему я бы хотел переписать файл test_as_local принадлежащий сотруднику ОИЯИ Трофимову из его директории. Для записи в принадлежащую члену VO dteam Трофимову директорию под именем test_as_VO недостаточно команды

[tvv] /opt/edg > cp /pnfs/*****/user/t/trofimov/test_as_local /pnfs/*****/dteam/trofimov/test_as_VO
cp: accessing `/pnfs/*****/dteam/trofimov/test_as_VO': Permission denied

а придётся использовать

[tvv] /opt/edg > dccp /pnfs/*****/user/t/trofimov/test_as_local - | globus-url-copy - dbg - \ gsiftp://*****:2811/pnfs/*****/data/dteam/trofimov/test_as_VO
debug: starting to put gsiftp://*****:2811/pnfs/*****/data/dteam/trofimov/test_as_VO
debug: connecting to gsiftp://*****:2811/pnfs/*****/data/dteam/trofimov/test_as_VO
debug: response from gsiftp://*****:2811/pnfs/*****/data/dteam/trofimov/test_as_VO:
220 GSI FTP Door ready
 
debug: authenticating with gsiftp://*****:2811/pnfs/*****/data/dteam/trofimov/test_as_VO
debug: response from gsiftp://*****:2811/pnfs/*****/data/dteam/trofimov/test_as_VO:
200 Already logged in
 
debug: sending command:
FEAT
 
debug: response from gsiftp://*****:2811/pnfs/*****/data/dteam/trofimov/test_as_VO:
211-OK
 EOF
 PARALLEL
 SIZE
 SBUF
 ERET
 ESTO
211 End
 
debug: sending command:
TYPE I
debug: response from gsiftp://*****:2811/pnfs/*****/data/dteam/trofimov/test_as_VO:
200 Type set to I
 
debug: sending command:
PASV
 
debug: response from gsiftp://*****:2811/pnfs/*****/data/dteam/trofimov/test_as_VO:
227 OK (159,93,39,37,78,32)
 
debug: sending command:
STOR /pnfs/*****/data/dteam/trofimov/test_as_VO
 
debug: response from gsiftp://*****:2811/pnfs/*****/data/dteam/trofimov/test_as_VO:
150 Openning BINARY data connection for /pnfs/*****/data/dteam/trofimov/test_as_VO
 
debug: data callback, no error, buffer 0xb710f008, length 1 offset=0, eof=false
debug: data callback, no error, buffer 0xb700d008, length 1 offset=1 eof=false
debug: data callback, no error, buffer 0xb6f0c008, length 1 offset=2 eof=false
debug: data callback, no error, buffer 0xb710f008, length 1 offset=3 eof=false
debug: data callback, no error, buffer 0xb700d008, length 1 offset=4 eof=false
debug: data callback, no error, buffer 0xb6f0c008, length 1 offset=5 eof=false
debug: data callback, no error, buffer 0xb710f008, length 1 offset=6 eof=false
bytes in 19 seconds (526.32 KB/sec)
debug: data callback, no error, buffer 0xb700d008, length 1 offset=7 eof=false
debug: data callback, no error, buffer 0xb6f0c008, length 1 offset=8 eof=false
debug: data callback, no error, buffer 0xb710f008, length offset=9 eof=true
debug: response from gsiftp://*****:2811/pnfs/*****/data/dteam/trofimov/test_as_VO:
226 Transfer complete.
 
debug: operation complete

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