Заявление.
Автором не найдено ни одного текста на русском языке, который можно рассматривать, как инструкцию для пользователя системы 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/ToDo2005Apr21080327/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 без дополнительных действий. Если доступ к файлам производится с персонального компьютера, включённому в домен jinr.ru, на нём должен быть установлен NFS клиент (ставится по умолчанию при установке Linux), клиент dCache и смонтирована директория /pnfs/jinr.ru
Для установки клиента dCache надо скачать rpm клиента, например с http://www.dcache.org/downloads/IAgree.shtml и установить его.
Далее надо смонтировать PNFS на своём локальном компьютере командами
mkdir -p /pnfs/jinr.ru
mount -o intr,rw,noac,hard lxfs07.jinr.ru:/pnfs /pnfs/jinr.ru
после этого файлы будут доступными в директории
/pnfs/jinr.ru/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/jinr.ru/user/i/iam
и обратно
dccp /pnfs/jinr.ru/user/i/iam/two_weeks_of_simulation.001 $HOME/to_cern.001
б) если PNFS не смонтирована, файл адресуется в стиле URL (далее будем называет это url-dcap)
dccp dcap://lxfs07.jinr.ru:22125/pnfs/jinr.ru/data/cms/sourcefile \ /localpath/destinationfile
в) Если работа производится в окружении GRID, то для доступа используются gsi-ftp (Globus), при этом, разумеется, надо быть зарегистрированным в VO. Копируем туда
globus-url-copy file:/tmp/test gsiftp://lxfs07.jinr.ru:2811/pnfs/jinr.ru/data/dteam/testfile2
Копируем обратно
srmcp srm://lxfs07.jinr.ru:8443/pnfs/jinr.ru/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 lxfs07.jinr.ru:22125
gsiftp lxfs07.jinr.ru:22128
srm lxfs07.jinr.ru:22127
Этот список будет действовать ограниченное словом “пока” время. В дальнейшем каждая виртуальная организация получит свою дверь и будет через неё входить и выходить. Список дверей будет висеть на где-то на http://grid.jinr.ru/enter/
Менеджер пулов.
Любой запрос на пространство будь то PUT или GET, обрабатывается менеджером пула. Он оптимально выбирает подходящий пул и очередь запросов. Каждый пул регистрируется в менеджере с указанием класса памяти и правил доступа к нему.
Пул.
Пул отвечает за непрерывную область дисковой памяти:
следит за величиной памяти,
поддерживает список файлов, которые можно удалить,
инициирует процесс копирования файлов,
связывается с клиентом для передачи данных,
определяет оптимальное количество задачь передачи данных к конкретной области диска.
Директории pnfs, GRID.
Дерево каталогов отражает сложившееся положение и организовано следующим образом. Для доступа по dcap при смонтированной pnfs
/pnfs/jinr.ru/user/<�дальше как в AFS>
При доступе по url-dcap
/pnfs/jinr.ru/data/user/<�дальше как в AFS>
При доступе по gsi-ftp или srm
/pnfs/jinr.ru/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/jinr.ru
и смонтировать там Pnfs ЛИТ ОИЯИ
mount –o intr,hard,rw,noac lxfs07.jinr.ru:/pnfs /pnfs/jinr.ru
Внимание! Команда mount идёт достаточно медленно.
После этого можно будет посмотреть что там есть в dCache
ls /pnfs/jinr.ru/user
получается латинский алфивит, такой же как от ls /afs/jinr.ru/user
Права доступа, uid и шизофрения.
Немного технических деталей. Права в системе linux зависят грубо говоря от того, под каким именем личность вошла в систему. С доступом по dcap к смонтированным директориям или всё ясно. Пользователь должен быть зарегистрирован на ферме ЛИТ и тогда права доступа к файлу и назначение uid регулируются правилами linux. Например автор зарегистрирован как
trofimov (uid=8401)
и работает с
/pnfs/jinr.ru/user/t/trofimov
Если доступ происходит по gsi-ftp или srm, то доступ происходит сложнее. Пользователь должен иметь действительный grid proxy. Когда он обращается файлам этой виртуальной организации, то идентификация его личности производится средствами системы GRID, а вот на компьютерах фермы ОИЯИ он получает псевдоним, который говорит о его членстве в этой виртуальной организации и всё. Например автор с точки зрения GRID не кто иной как
/C=RU/O=RDIG/OU=users/OU=jinr.ru/CN=Vladimir Trofimov
для которого на компьютерах фермы ЛИТ происходир реинкарнация в
dteam001.
Пользователь dteam001 зарегистрирован на ферме ЛИТ под uid=17206. Добро пожаловать в директорию
/pnfs/jinr.ru/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
lxfs07.jinr.ru:/pnfs on /pnfs/jinr.ru type nfs (rw,intr,noac,hard,addr=159.93.39.37)
Благодаря этим двум обстоятельствам я могу узнать, что у меня в системе dCache есть файл
[tvv] /home/vtrofimov > ls -l /pnfs/jinr.ru/user/t/trofimov
total 10000
-rw-r--r-- 1 8410 500 10240000 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=jinr.ru/CN=Vladimir Trofimov/CN=proxy
issuer : /C=RU/O=RDIG/OU=users/OU=jinr.ru/CN=Vladimir Trofimov
identity : /C=RU/O=RDIG/OU=users/OU=jinr.ru/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://lxfs07.jinr.ru/pnfs/jinr.ru/data/dteam/trofimov
-rw 10240000 test_as_VO1
В дополнение к нему я бы хотел переписать файл test_as_local принадлежащий сотруднику ОИЯИ Трофимову из его директории. Для записи в принадлежащую члену VO dteam Трофимову директорию под именем test_as_VO недостаточно команды
[tvv] /opt/edg > cp /pnfs/jinr.ru/user/t/trofimov/test_as_local /pnfs/jinr.ru/dteam/trofimov/test_as_VO
cp: accessing `/pnfs/jinr.ru/dteam/trofimov/test_as_VO': Permission denied
а придётся использовать
[tvv] /opt/edg > dccp /pnfs/jinr.ru/user/t/trofimov/test_as_local - | globus-url-copy -dbg - \ gsiftp://lxfs07.jinr.ru:2811/pnfs/jinr.ru/data/dteam/trofimov/test_as_VO
debug: starting to put gsiftp://lxfs07.jinr.ru:2811/pnfs/jinr.ru/data/dteam/trofimov/test_as_VO
debug: connecting to gsiftp://lxfs07.jinr.ru:2811/pnfs/jinr.ru/data/dteam/trofimov/test_as_VO
debug: response from gsiftp://lxfs07.jinr.ru:2811/pnfs/jinr.ru/data/dteam/trofimov/test_as_VO:
220 GSI FTP Door ready
debug: authenticating with gsiftp://lxfs07.jinr.ru:2811/pnfs/jinr.ru/data/dteam/trofimov/test_as_VO
debug: response from gsiftp://lxfs07.jinr.ru:2811/pnfs/jinr.ru/data/dteam/trofimov/test_as_VO:
200 Already logged in
debug: sending command:
FEAT
debug: response from gsiftp://lxfs07.jinr.ru:2811/pnfs/jinr.ru/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://lxfs07.jinr.ru:2811/pnfs/jinr.ru/data/dteam/trofimov/test_as_VO:
200 Type set to I
debug: sending command:
PASV
debug: response from gsiftp://lxfs07.jinr.ru:2811/pnfs/jinr.ru/data/dteam/trofimov/test_as_VO:
227 OK (159,93,39,37,78,32)
debug: sending command:
STOR /pnfs/jinr.ru/data/dteam/trofimov/test_as_VO
debug: response from gsiftp://lxfs07.jinr.ru:2811/pnfs/jinr.ru/data/dteam/trofimov/test_as_VO:
150 Openning BINARY data connection for /pnfs/jinr.ru/data/dteam/trofimov/test_as_VO
debug: data callback, no error, buffer 0xb710f008, length 1048576, offset=0, eof=false
debug: data callback, no error, buffer 0xb700d008, length 1048576, offset=1048576, eof=false
debug: data callback, no error, buffer 0xb6f0c008, length 1048576, offset=2097152, eof=false
debug: data callback, no error, buffer 0xb710f008, length 1048576, offset=3145728, eof=false
debug: data callback, no error, buffer 0xb700d008, length 1048576, offset=4194304, eof=false
debug: data callback, no error, buffer 0xb6f0c008, length 1048576, offset=5242880, eof=false
debug: data callback, no error, buffer 0xb710f008, length 1048576, offset=6291456, eof=false
10240000 bytes in 19 seconds (526.32 KB/sec)
debug: data callback, no error, buffer 0xb700d008, length 1048576, offset=7340032, eof=false
debug: data callback, no error, buffer 0xb6f0c008, length 1048576, offset=8388608, eof=false
debug: data callback, no error, buffer 0xb710f008, length 802816, offset=9437184, eof=true
debug: response from gsiftp://lxfs07.jinr.ru:2811/pnfs/jinr.ru/data/dteam/trofimov/test_as_VO:
226 Transfer complete.
debug: operation complete
Вывод. Если не хочется усложнять себе жизнь или работайте как локальный пользователь и забудьте о GRID, или работайте в структуре GRID и забудьте, что у вас есть другие возможности доступа.
|
