[FedStor] WLCG federated storage demonstrator project (draft)

[Eygene Ryabinkin]

Доброго дня.

Mon, Feb 29, 2016 at 01:42:22PM +0300, Andrey Zarochentsev wrote:
> Я еще раз повторюсь по поводу упоминаемых в тексте схем T0-T1-T2.
> Давайте хотя бы для себя определим что они значат. Либо UI-MGM-FST либо
> FST-MGM-UI либо еще как-то.
> То, что перечислено в тексте не имеет смысла ни в каком варианте. У нас Т3
> и Т0 ни когда не будет FST , а у нас они появляются и справа и слева. У нас
> T0 может быть MGM или UI, а Т3 - только UI. И только T2 может быть чем
> угодно.
> Я не настаиваю на подробном перечислении всех схем, но я очень бы желал,
> что бы те схемы, которые представлены в тексте имели смысл. И чтобы авторы
> текста могли этот смысл объяснить.

Mon, Feb 29, 2016 at 02:05:49PM +0300, Andrey Kiryanov wrote:
> Я согласен с АКЗ. По моему мнению вообще оперирование понятиями 
> "треугольник" и "Ta-Tb-Tc" крайне сомнительно и из документа должно быть 
> убрано.

Поддерживаю предыдущих ораторов.

> То, что у нас получился треугольник на начальном этапе тестирования - 
> это случайное стечение обстоятельств, продиктованное количеством 
> доступных ресурсов. Мне кажется откровенно вредным и с научной точки 
> зрения необоснованным тестирование федерации сайтов в виде 
> "треугольников". Комбинация сайтов разного уровня неизбежна, но 
> очевидно, что такое федеративное хранилище имеет смысл базировать на 
> ресурсах сайтов уровня T2-T3, грань между которыми эфемерна, в то время 
> как T1 объединены как минимум выделенной сетью. Доступ же к ресурсам 
> федерации должен быть глобальным и вообще не зависеть от T*. Вопрос тут 
> в основном в падении эффективности работы с нарастающими сетевыми 
> издержками при "удалении" от федерации.

Да, если говорить о топологии, то у нас есть редиректоры (которых
может быть довольно много, вообще говоря; они обычно образуют дерево)
и пулы.  Решаемая задача заключается либо в оптимизации топологии
первых (редиректоров) и распределении реплик данных по вторым (пулам)
глобально, либо при ограничениях "есть сайт А, у него сетевая связность
с другими -- такая-то, а ресурсы -- вот эти".  У нас, скорее, второе,
поскольку строить новый НИИЯФ или, не дай Б-г, КИ в произвольном месте
России -- не дадут.

Mon, Feb 29, 2016 at 02:07:47PM +0300, Andrey Zarochentsev wrote:
> Для dCache  есть те же понятия менеджера - редиректора, файлового
> сервера и клиента. Можно так и называть.

Да, с точки зрения dCache и Xrootd (или HTTP) -- там то же самое.
Поэтому замена dCache на EOS с технической точки по модулю деталей
реализации -- тождественна (а у нас пока документ не доходит до
технических деталей реализации протоколов в используемом ПО).

> Т.е. я правильно понимаю, что мы просто описываем треугольник, не
> придавая в тексте значения функциональные вершинам этого
> треугольника? Тогда мы тоже подаем некоторую неоднозначность.
> Получается из текста, что мы тестируем только треуголники -
> комбинации трех сайтов-точек. Хотя реально имеет смысл и уже
> включено более , чем три сайта. Тогда надо писать что-то типа
> Т1-(Т2-Т2)-(Т3-Т3) ...Или как-то еще... Т0-Т1-..Т1-Т2..Т2 Т.е.
> понятие треугольника осмыслено , если это три функции - клиент,
> редиректор, файловый сервер. Если это не функции , а точки ,
> сервера, то надо уточнить, что треугольник у нас только в первой
> фазе, а далее мы переходим уже более сложным фигурам.

Описание того, строим ли мы треугольник (или ещё чего) так, как сейчас
есть в тексте -- это, мне кажется, оправданно только в случае, если
в документе нужно показать реальный план работ, с подробностями.
А так -- будет какая-то сеть редиректоров + где-то расположенные
пулы.  И важно про них знать то, как они с сетевой точки зрения
связаны между собой и с клиентом + доступное пространство на
каждом пуле + предполагаемый workload для всего этого федеративного
облака.  Это, конечно, в идеальном случае.


Поэтому у меня (запоздалый) вопрос: а это пишется для кого и с какой
идеей?  Что хочется показать этим документом?
-- 
Eygene Ryabinkin, National Research Centre "Kurchatov Institute"

Always code as if the guy who ends up maintaining your code will be
a violent psychopath who knows where you live.