Linux в CERN: ближайшее будущее

Собери много раз. Я не понимаю в чем проблема. Вот я на работе собираю бинари самой последней версией clang и использую все самые самые свежие средства разработки, в кодовой базе самый старый код 20 летней давности, при этом мои бинари работают одинаково на всех убунтах начиная с 12 точно (такое кое-где еще осталось), а может даже и на более ранних.

Безусловно и это проблема. Вполне возможно, что так или иначе время жизни 7ки увеличат на год-другой, чтобы попасть на время остановки.

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

Проблема в том, что плана как именно грызть нет, так как это зависит от самих данных и план приходится постоянно приспосабливать под увиденное после сгрызенного. Иными словами: предсказать результат невозможно даже приблизительно. Получается то, что получается.

Это решается единым репозиторием, trunk-based разработкой, ci/cd, тестами и т.п. У меня на работе специальная команда поддержкой этого всего занимается :)

Как по твоему, например, выглядит запуск задачи вычислительном кластере?

Просто пока у меня ощущение, что ты его путаешь с предоставлением хостинга.

Как по твоему, например, выглядит запуск задачи вычислительном кластере?

По всякому бывает, например, так mpirun бинарь аргументы

Нет, это обычно не так. Просто потому, что пользователю очень редко выделяется монопольный доступ к ресурсам.

Если доступ не монопольный (да и если монопольный, то тоже), то для запуска задачи на вычислительном кластере пользователь обычно добавляет свою задачу в очередь через планировщик . Планировщик её добавит в очередь, если пользователю это разрешено на основе паспортизации задачи (где описано что за задача, сколько узлов нужно в этот раз выделить и это не отсебятина, а то, о чём планировщик в курсе и что это вообще разрешено запускать с какими ограничениями по ресурсам). Как только требуемое количество узлов освободится, тогда планировщик запустит задачу. Как только появятся свободные узлы - запустит следующую. При этом на каждом из узлов есть доступ к распределённой файловой системе, на которой хранятся данные для запуска задачи планировщиком и куда складываются данные расчёта.

Виртуализация может применяться, но обычно это делается для машин пре- и постобработки, так как на узле ядер много, а для этих задач в ряде случаев пользователю нужны не все. Тут тот можно порезвиться с выбором дистрибутива, если уж очень очень хочется.

И постоянно жонглировать дистрибутивами на расчётных узлах просто некогда - это потеря времени впустую. Так вся работа встанет по управлению очередью.

Через «mpirun параметры» разве что на машине пре- постобработки можно проверить запуск.

Нет, это обычно не так. Просто потому, что пользователю очень редко выделяется монопольный доступ к ресурсам.

Я знаю, поэтому написал, что «например».

Крайне плохой пример, не имеющий ничего общего с реальностью.

Особенно судя по качеству кода 🙄😔

Смысл от этого не меняется. В реальности вместо mpirun будет своя команда, которая отправляет бинарник на кластер и ставит операцию в очередь.

Десять лет на самом деле оценка снизу. Для атласа например симуляцию детектора когда завезли, в начале нулевых?

В клауд сразу уж. Только даже для лямбд есть ограничения / api.

Ага, «Всё тщательно перемешайте и выпейте. Через час кулебяка будет готова».

Ci/cd хорошо, когда ты пишешь прикладное по и его развиваешь, добавляя фичи.

Для вычислений интегрировать ничего не надо. Большая часть это One-off задачи. Обсчитал уравнение и больше тебе программа не нужна.

Там скорее важно eye-bolling на тему не нарушения граничных/начальных условий или не схлопывания значений (разрыв, деление на ноль, бесконечные производные и т.д.). Хотя я совсем не знаю, что/как в ЦЕРНе считают.

bullseye

Августовский релиз Деба. Под 11 номером, кажется. Речь о тестировании одного используемого нами софта на вот этом новом дистрибутиве.

CERN может организовать свое зеркало

Ну это да. Как минимум, они бы добавили мощностей к инфраструктуре, что дало бы преимущества дебу.

Ежели бы ЦЕРН направил свои ресурсы на дебиан, то конечно это было бы круто для сообщества, но только тогда ЦЕРН станет зависим от решений комитета, и я не уверен, что в ЦЕРНе этого хотят.

Впрочем, сейчас они зависят от решений межделмаша.

Я вижу так, люди 10 лет писали свои программки для обработки данных и никто особо не горит желанием заставлять их переделывать эти программки так чтобы они могли работать в контейнере, а такие изменения могут по понадобиться. А дистронезависимость хоста и текущая схема с виртуалками обеспечивает, так что это не плюс. А дистрозависимость гостя зашита в расчетном софте, который собран с либами от rh-like

Да какие репы, это космос для большинства в ФЭЧ.

Приходит бакалавр, лабает портянку на си и баше для вычитывания данных с самодельной же АЦП, всё это хранится в единственном экземпляре на хомяке студента. Его научник в лучшем случае писал для БЭСМ-6 на Фортране, поэтому про git он вообще не слышал.

В исключительных случаях эта программка действительно вычитывает данные с АЦП, а не фазу луны в 1380 году — тогда она остаётся в лабе жить своей жизнью.

Лет через десять, когда от студента и след простыл, научник решает прикрутить этот АЦП к детектору, чтобы поучаствовать в коллаборации, в его понимании программа же работала тогда, значит и сейчас будет. Находится другой студент, который пытался оживить эту программу на новой центоси, естественно драйвер уже не работает, потому что stable API is nonsense, программка тоже уже не компиляется, в итоге виноват оказывается новый студент, да.

CERN обсчеты даже на фриаутсорсинг скидывает :) проект LHC@home

хех, стандартный разрыв между «написать ПО» и «решить прикладную задачу».

Как это есть на самом деле.

CERN не заставляет сайты LCG использовать конкретный дистрибутив, в настоящее время требуется совместимость с RH7. Разнобразие на T1 сайтах нашего эксперимента не богато. Большинство используют СentOS, например в RRCKI (курчатник) - RedHat Release = CentOS Linux release 7.6.1810 (Core). Но есть и исключения, например в GRIDKA - RedHat Release = Scientific Linux release 7.9 (Nitrogen).

Сайты предоставляют экспериментам совместимость с RH7, как это реально делается не важно. Точно знаю что RAL использует Docker, какая там родная система я не знаю, никого это не беспокоит.

Как это есть на самом деле.

Данные набранные в RUN1 всё ещё используются в анализе в нашем эксперименте. Для этого необходимо сгенерить новое Монте-Карло и применить к нему триггер которые использовался в 2011-2012 годах и реконструкцию событий используемую несколько лет назад. Никто не собирается пересобирать триггерную программу на новом дистрибутиве, оригинальный бинарник запускается в SLC5 в Singularity. Реконструкция тоже идёт в соответствующем SLC и тоже в Singularity.

Фи, поручик, какой же вы пошляк!

CERN обсчеты даже на фриаутсорсинг скидывает :) проект LHC@home

Как это есть на самом деле.

Это скорее популяризация CERN чем реальная необходимость.

Мы пробовали использовать домашние ресурсы на нашем эксперименте, но это в пике составляло меньше 0.01% от наших ресурсов. Стоимость этой деятельности достаточно велика - одному человеку приходилось тратить половину рабочего времени на поддержку этой активности. У нас это 10% от человеческих ресурсов Distributed Analysis team. Пришлось отказаться.

это да :( а сексретарши на крутых современных компах пасьянсики раскладывают…

Откуда дровишки? ЕМНИП, 3.28 там. Сам ставил посмотреть.

Я работал с CentOS 7.3 или 7.4 (точно не помню) на прошлой работе. Там точно не третегном. Они гном в минорном релизе обновили?

у каждого своя работа 😉

в последней 7.9 гном 3.28
ты запамятовал, 7.0 вышел с 3.8.4:
https://vault.centos.org/7.0.1406/os/x86_64/Packages/gnome-shell-3.8.4-31.el7...

… Как вы представляете эту процедуру организованную в течении разумного промежутка времени для 170 организаций у которых куча своих насущных проблем…

Да легко, всех расстрелять, набрать новых.

Идеи умирают тогда, когда умирают их носители. Если прокатило с квантовой физикой, почему не прокатит с линуксом?

Тут же дети!!!!

надеюсь, что у них systemd на центоси этой

Адекватным людям реально пофигу, systemd там или не systemd.

согласен. Тогда почему на лоре такой бугурт вокруг системд?

Клоны RHEL также рассматриваются в качестве альтернативы, но пока не выбираются. Одна из основных проблем — это то, что возвращение наработок в основную ветку в случае клонов несколько сложнее, чем в случае CentOS Stream.

А как-же то, что на подкасте вещали разрабы Альмы, что они с ними охотно сотрудничают разрабы красношляпы, одобряют их работу, а также, что альмовцы сотрудничают с апстримом и ещё пять минуть и они будут в дёсны долбиться? Это что же, всё было такое?! Очередное бахвальство уровня Невского, известного «кореша» Шварцнегера? Да не, не может быть, бред какой-то!

Ответ: я не знаю.

Две причины:

1. Фанатизм и юношеский максимализм.
2. Чисто теоретические дискуссии на предмет того, что лучше. То есть, человеку может нравиться другая система инициализации, но это не значит, что он будет рубить с плеча и отказываться админить дистрибутив с systemd.