RHEL 8 Beta!

когда мы говорим о косяках проекта Docker

я промолчу по поводу дыркера (либо хорошее, либо ничего). предполагается ли горячая миграция для lxc из коробки?

+1 может, mv ответит тематически.

Печет или нет, нужен он был только Redhat, а сейчас он и у тебя (но не печет, ни-ни).

именно, а от «btrfs-плохо, вот вам stratis» мне печёт

от «btrfs-плохо, вот вам stratis» мне печёт

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

Почему?

потому что он в ядре и другие вендоры его юзают, а RH-у его компилять типа не охота

Технически, BtrFS - это большой кусок ядерного кода, значительная часть из которого не обязана быть в ядре.

а где должен быть драйвер фс?

И есть мнение, что BtrFS спроектирована плохо и до сих пор ненадежна.

когда он у меня сам развалится, тогда я к этим мнениям прислушаюсь :)

с btrfs, конечно, полная убунтовщина. включили в rhel 7 как девпревью, теперь выкинули... однозначно рад, что не стал нигде el 7 натягивать. промежуточная, необкатанная и недоделанная ветка. в восьмерке наконец стала явно видна новая заточка и специализация дистра.

а где должен быть драйвер фс?

Понятно.

и всё-таки?

BtrFS - это гораздо больше, чем «драйвер ФС».

Для девопсов и прочих клаудов. В ямле ансибла пишешь, что создать такой-то контейнер и отрезать ему столько-то дискового пространства.

ага, ок. то есть сейчас я в свои скрипты добавляю lvcreate, а тут буду yml писать.

Вот это реально было бы NIH.

У докера полно технологических недостатков, чтобы чесалось своё сделать. А уж сколько багов было ещё пару лет назад?..

Вот в Интел, например, над Clear Containers работали, где используется изоляция адресного пространства посредством виртуализации. Чтобы, значит, можно было гонять контейнеры разных пользователей на одной ноде и не потеть отсутствие даже базовой защищённости. NIH? Нет.

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

Чем тебе контейнеры не «базовая защищенность»?

Чем тебе контейнеры не «базовая защищенность»?

Это как после случайного секса член под краном с мылом вымыть в качестве профилактики ЗППП.

+1 может, mv ответит тематически.

Шапке нужен клауд сторидж, но со сториджем у них традиционно слабо. Покупка lvm, ceph и permabit ничего в долгосрочной стратегии не изменила: её нет.

lvm куплена rh? всегда почему-то думал, что lvm пишет некомерческая организация. permabit - решениеи по дедупликации? и при этом они выкидывают btrfs? если им так нужен сторидж, то неужели его лучше создавать из лоскутков, чем вложиться вместе с facebook. не понимаю. по какой причине btrfs выкинул («отдал сообществу») oracle тоже не понимаю.

p.s.

я не фанат бтрфс, просто не в курсе логики. система управления томами должна по идее лежать в основе облачного сториджа rh.

lvm куплена rh? всегда почему-то думал, что lvm пишет некомерческая организация.

https://en.wikipedia.org/wiki/Sistina_Software

permabit - решениеи по дедупликации? и при этом они выкидывают btrfs?

permabit - плагин к device mapper для блочного дедупа и компрессии. Дедуп на уровне файловой системы - это не то. Конечно, семантически разницы между логическими дисками со всеми современными свистелками и файловой системой уже не так много, но, всё же: гонять дисковые нагрузки через ФС - это гвоздь в гроб производительности.

если им так нужен сторидж, то неужели его лучше создавать из лоскутков, чем вложиться вместе с facebook. не понимаю. по какой причине btrfs выкинул («отдал сообществу») oracle тоже не понимаю.

У ФБ своё понятие сториджа, им чисто для клауда нужен. У Ред Хата не получилось довести дело до полноценного сторидж апплайенса. Наверное, посчитали рынок на $50 млрд/год неперспективным или перенаселённым.

я не фанат бтрфс, просто не в курсе логики. система управления томами должна по идее лежать в основе облачного сториджа rh.

Там проблемы немного другие: данные должны быть в разных availability zones, всё очень чувствительно к толщине сети, разные степени защиты нужны. Для клауда больше подходит какой-нибудь Sheepdog, чем LVM.

Там проблемы немного другие

я это понимаю, но разве мы отказываемся от volume management из-за этого.

я это понимаю, но разве мы отказываемся от volume management из-за этого.

Если к облачному блочному устройству сверху прикрутить LVM, то работать будет плохо. Если сделать наоборот: например, пул физических дисков резать на куски и пробрасывать по сети, где на них будет сидеть облачное управление, то немним лучше, но тут тоже есть много вопросов.

нет, lvm поверх сети мы делать, конечно, не будем, просто поверх блочного устройства у нас будет уже сетевая файловая система. вряд ли есть какой-то смысл избавляться от volume management'a в такой ситуации.

Дедуп на уровне файловой системы - это не то.

ZFS имеет аж несколько вариантов: и файловый дедуп, и блочный. я думал, что в btrfs также.

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

ZFS имеет аж несколько вариантов: и файловый дедуп, и блочный. я думал, что в btrfs также.

В облаках у серверов батареек нет, поэтому только direct I/O, в котором ZFS жрёт сеть и безбожно тормозит.

И ZFS-on-Linux - глюкалово.

в смысле у физических серверов? в гугле и фейсбуке? где можно много сэкономить на этом?

И ZFS-on-Linux - глюкалово.

мне скоро мигрировать с EL6+openvz и я посматриваю на freebsd. вдруг она как раз догнала линукс 10 летней давности. так что я не про ZoL. усилия по миграции сопоставимы с миграцией на rhel8.

в смысле у физических серверов? в гугле и фейсбуке? где можно много сэкономить на этом?

Везде сэкономить много можно. С батарейками постоянно проблемы, плюс data unavailable/data lost случаются даже тогда, когда батарейка признаков смерти не подавала. Мало того, что на техников дополнительная нагрузка по батарейкам, так ещё и клиенты мозг съедят и плохие отзывы будут оставлять везде.

Только direct IO.

мне скоро мигрировать с EL6+openvz и я посматриваю на freebsd. вдруг она как раз догнала линукс 10 летней давности. так что я не про ZoL. усилия по миграции сопоставимы с миграцией на rhel8.

Я пару дней смотрел в исходники ZFS - оно спроектировано по лекалам 90-х. С масштабированием проблемы, с надёжностью в масштабе даже 2-3 датацентров - совсем плохо.

С батарейками постоянно проблемы, Я пару дней смотрел в исходники ZFS

монстры вы там на вашей работе кто бы вы ни были;)

Чем тебе контейнеры не «базовая защищенность»?

Это как после случайного секса член под краном с мылом вымыть в качестве профилактики ЗППП.

Благодарю за исчерпывающе точный ответ.

а инфу про батарейки я пожалуй проверю инфу у знакомого ЦФТшника. у них достаточный объем, чтобы я мог ему верить. не слишком много (не фейсбук) и не слишком мало (не рога и копыта). скажет, что проблем с батарейками нет - значит, на их объеме и у меня не выявятся скорее всего.

вот видишь, заодно и к сексопотологу идти не надо:)

Ты путаешь сексопатолога и венеролога.

ты знаешь, это в общем хорошо говорит обо мне.;)

Ты пытаешься использовать термины, которых не понимаешь. Нет, это не говорит о тебе хорошо.

я даже не пытаюсь) просто радуюсь, что ты получил ценный совет сразу в двух областях)))

ты получил ценный совет

Не совет. Но ценный, это да.

ценная информация для размышления, позволяющая постичь корень некоторых проблем? мотивация к самосовершенствованию? или просто шокирующая новость? да называй как хочешь, главное больше не беги за мылом)

главное больше не беги за мылом)

Ты опять всё перепутал.

ТС, ты скачал? у меня по ссылке с опеннета какие-то непонятные data. где можно взять?

Да, скачал.

Поставил и тестирую.

1) Авторизируйтесь в личном кабинете

2) Нажмите «Get Started» https://access.redhat.com/products/red-hat-enterprise-linux/beta

3) На email придет письмо c инструкциями

ну или

https://developers.redhat.com/rhel8/getrhel8/

=)

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

не грузится со словами this hardware has not undergone testing и unsupported p6

вот и потестили:(

хо-хо, в rhel8 не будут networkd. в треде по systemd скинули ссылку:

https://bugzilla.redhat.com/show_bug.cgi?id=1650342

> RHEL 8 beta should support systemd-networkd since it's already shipped with
> RHEL 7.

In RHEL-7 we shipped it in Optional channel, hence it was not officially supported. We decided to remove it for a couple for reasons,
  * networkd is not mature enough and is somewhat poorly maintained upstream
  * networkd is still missing management interfaces (DBUS interface)
  * RHEL's default network configuration tool is NetworkManager and we didn't want to send mixed signals to users
  * RHEL-8 was supposed to be as small as possible in terms of packages
  * we didn't see too much networkd usage (even experimental) in RHEL-7

а) когда поттерингу красный свет давали, неужели roadmap нельзя было построить и определиться с NM

б) mixed signals, huh? а когда документацию на rhel7 и двойную систему логирования писали, так ничего... короче, продублировали почти все системные сервисы, а тут решили задний ход дать.

In rhel7 we have custom shell scripts in initrd, initscripts, NetworkManager and systemd-networkd (in optional channel), that are able to set up a network connection. And that complicates the maintenance.

We have agreed that we want to standardise on NM in all the scenarios

в) да там вообще весь тред ...

alpha, поттеринг же на зарплате у RH? почему такой дикий бардак.

* зеленый свет, конечно же

Прямо удивительно, как люди самодостаточно действовать стали: сначала сами себе чего-то напридумывают, потом пять лет с этим придуманным будут спорить, потом сами возмущаются, когда оказывается, что ими придуманное совершенно не соответствует реальности.

С чего спрашивается ты стал хоронить Network Manager? И почему ты решил что с ним кто-то «не определился»?

И какой там у тебя красно-зеленый свет?

Это не mixed signals, это каша в одной отдельно взятой голове.

ну, допустим каша у меня в голове. вопрос не про NM. так что все-таки с разработкой в RH? почему RH сначала разрабатывает networkd, потом от него отказывается. почему за время обкатки эта часть не обзавелась даже хорошей документацией (см. по ссылке). разве написание документации не является чем-то обазательным в RH? и т.д.

Это не mixed signals, это каша в одной отдельно взятой голове.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html...

Some log files are controlled by a daemon called rsyslogd. The rsyslogd daemon is an enhanced replacement for sysklogd

Log files can also be managed by the journald daemon – a component of systemd. The journald daemon captures Syslog messages,

вот ЭТО - mixed signals! именно это и приводит к каше в голове.

только почему-то в одном случае один редхатовец это признает, а в другом другой редхатовец это отрицает.:)

а у вас в компании тоже на использование NetworkManager (см. ссылку выше) на серверах перейдут?

именно это и приводит к каше в голове.

Нет, не это. А то что ты пытаешься из статьи про настройку логирования делать выводы про разработку Network Manager.

только почему-то в одном случае один редхатовец это признает, а в другом другой редхатовец это отрицает

Потому что в одном случае «это» одно, а в другом - другое, не имеющее к первому отношения. Но каша в голове, отягощенная поиском глубокого смысла и «сигналов между строк» в технических статьях, не позволяет разобраться что где.

RHEL4 был идеален. В RHEL5 был зародыш зла. Сейчас я пользуюсь RHEL6, он последний нормальный. И кроме того, до сих пор поддерживается.