Когда вы говорили о metro exodus, вы взяли обычную версию или enchanced версию? Т.к. между обычной и enchanced (которая запустится только на видеокартах в rt) разница существенная и она 100% будет видна, в т.ч. есть целая куча таких сравнений на том же youtube, и там сцена меняется кардинально, это невозможно не заметить.
Использовали fluentd — полностью утилизирует одно ядро, периодически перестаёт реагировать на изменения в некоторых файлах, судя по issue на github проблема встречается часто, её неоднократно фиксят, не всегда успешно.
Перешли на fluentbit, всё бы хорошо, но периодически выжирает всю доступную ему память и рестартится, по несколько раз на дню. Причём лимиты буферов стоят. Открыты issue на github, уже несколько недель как, и пока без ответа.
Я пытался как то раз перейти на Vivaldi, причем не очень давно. И оказалось что при 30+ открытых вкладках он тормозит, и чем больше вкладок, тем менее отзывчивый интерфейс. Попытался отправить описание проблемы, форма для отправки была не доступна (кажется по 500), а когда она очухалась, получил на экране надпись спасибо. И всё. Ни сообщения на почту, ни ссылки для отслеживания, ни номера, вообще ничего. Я даже не понял ушло оно куда либо или нет.
И пользоваться в таком виде им не могу, и даже сообщить об этом не могу. Весьма печально
Сколько журналов вы кладете на один ssd диск?
Задумайтесь все же о cache tiering, хотя бы в proxy режиме, это более прозрачно чем несколько журналов на одном устройств, и рисков меньше.
Зря вы взяли связку centos + jewel.
В centos достаточно старое ядро, и когда вы заходите создать rbd то кроме feature layering использовать не сможете, rbd не замаппится, а в логах увидете что то вроде unsupported feature 0x09. Потом когда вы заходите выкинуть rbd по iSCSI то вы можете получить подвисший модуль lio в ядре и полудохлую ноду. А если захотите ещё и связать это с вин кластером, да еще чтобы и таргеты дублировались, с mpio, то вам ещё понадобятся и блокировки через rbd, а это ещё и ядро суси с патчами и прикладом тянуть. То ещё веселье.
Плюс с цефом в общем то рекомендуется (http://docs.ceph.com/docs/master/start/os-recommendations/) использовать более свежее ядро если вы используете rbd или cephfs (да, конкретно сейчас это не ваш случай, но тем не менее), там цефовские модули посвежее, и со iscsi проблем меньше, и в сетевом стеке изменения, и т.д.
По поводу luminous — у вас не было бы проблем с udev, selinux, не нужно было бы прописывать guid'ы и chown'ить блочные устройства. Деплой легче, автоматическая разбивка на device classes, создать раздельные пулы на разных типах устройств в разы проще. Допилили bluestore, скорость выше. Облегчили процесс замены дисков (ceph osd destroy/purge). Сделали overwrites для erasure coded пулов через реплицируемые пулы. Ввели прозрачную компрессию. Ввели простенький, но всё же мониторинг, встроили плагины для zabbix, prometheus, etc. Cephfs наконец то поддерживает одновременную работу нескольких сервисом метадаты. По сравнению с jewel более быстрый детект неработоспособности osd (введено в релизе kraken). То есть если вы намеренно погасили ноду, то osd сразу входят в состояние down, и ваше IO не прерывается, а в случае если вы его выключили по кнопке, или упала сеть, у вас IO полностью прерывается на срок от 20 секунд и до n минут, что уже вполне хватает чтобы ваши виртуалки упали, а клиенты получили подвисший fd (в случае с rbd). В релизах kraken (11) и выше с этим дела обстоят намного лучше. Ну и других приятных и полезных изменений там хватает. Так же стоит добавить что luminous это тоже lts, что обновление с jewel (и kraken) будет не таким простым (из-за blue store в частности), и что по части багов jewel вряд ли будет сильно лучше luminous.
Ещё вам к раздумьям: цеф отвратительно балансит данные. Существует далеко не нулевая вероятность, что один диск в пуле у вас заполнен на 70% а другой на 95% и цеф вешает флаг full на кластер из-за этого, и у вас всё встаёт колом. Собственно по этому в церне написали свои хелперы на питоне, в частности для ребаланса по крону. Правда для 12 версии пришлось переписывать немного, для поддержки device class. Собственно ссылки по теме: indico.cern.ch/event/567516/contributions/2293565/attachments/1331568/2001323/050916-cephupdate.pdf github.com/cernceph/ceph-scripts
И по статье промелькнуло ssd, но нет конкретики какие вы диски используете и в каком кейсе. С cache tiering'ом тоже ведь есть свои нюансы. Не описано какую сеть вы используете (1g/10g/что-то серьезнее?), а ведь сеть для цефа критична, проблемы с ней выльются в подвисших с stuck_unclean pg, в подвисших запросах (blocked requests) и тд. Как ceph себя показывает в вашем случае двух цодов?
В основном centos. И там тот же питон в любом случае есть. И скорее всего это лучше чем городить велосипеды из череды пайпов на awk и sed.
А про минимальный вызов внешних программ, это я имел в виду скорее предостережение для тех кто хочет из perl'а grep вызывать (видел и такое).
Я очень скептически ко всему этому отношусь, но допускаю что есть люди кому это может быть полезно. Но в некоторых местах из глаз почти пошла кровь. Вы не думали это переписать на python или perl с минимальным вызовом внешних программ?
Плюс есть вещи вроде webmin, и вы могли бы написать модуль для него (или в некоторых местах использовать его)?
Centos 7 не вышел из моды, он EOL. Больше 10 лет старичку, отпустите и забудте
А зачем? Samsung pay продолжил работать с картами МИР, VISA, MasterCard.
Единственное что сломалось - оплата часами
Когда вы говорили о metro exodus, вы взяли обычную версию или enchanced версию? Т.к. между обычной и enchanced (которая запустится только на видеокартах в rt) разница существенная и она 100% будет видна, в т.ч. есть целая куча таких сравнений на том же youtube, и там сцена меняется кардинально, это невозможно не заметить.
Перешли на fluentbit, всё бы хорошо, но периодически выжирает всю доступную ему память и рестартится, по несколько раз на дню. Причём лимиты буферов стоят. Открыты issue на github, уже несколько недель как, и пока без ответа.
Я пытался как то раз перейти на Vivaldi, причем не очень давно. И оказалось что при 30+ открытых вкладках он тормозит, и чем больше вкладок, тем менее отзывчивый интерфейс. Попытался отправить описание проблемы, форма для отправки была не доступна (кажется по 500), а когда она очухалась, получил на экране надпись спасибо. И всё. Ни сообщения на почту, ни ссылки для отслеживания, ни номера, вообще ничего. Я даже не понял ушло оно куда либо или нет.
И пользоваться в таком виде им не могу, и даже сообщить об этом не могу. Весьма печально
Сколько журналов вы кладете на один ssd диск?
Задумайтесь все же о cache tiering, хотя бы в proxy режиме, это более прозрачно чем несколько журналов на одном устройств, и рисков меньше.
В centos достаточно старое ядро, и когда вы заходите создать rbd то кроме feature layering использовать не сможете, rbd не замаппится, а в логах увидете что то вроде unsupported feature 0x09. Потом когда вы заходите выкинуть rbd по iSCSI то вы можете получить подвисший модуль lio в ядре и полудохлую ноду. А если захотите ещё и связать это с вин кластером, да еще чтобы и таргеты дублировались, с mpio, то вам ещё понадобятся и блокировки через rbd, а это ещё и ядро суси с патчами и прикладом тянуть. То ещё веселье.
Плюс с цефом в общем то рекомендуется (http://docs.ceph.com/docs/master/start/os-recommendations/) использовать более свежее ядро если вы используете rbd или cephfs (да, конкретно сейчас это не ваш случай, но тем не менее), там цефовские модули посвежее, и со iscsi проблем меньше, и в сетевом стеке изменения, и т.д.
По поводу luminous — у вас не было бы проблем с udev, selinux, не нужно было бы прописывать guid'ы и chown'ить блочные устройства. Деплой легче, автоматическая разбивка на device classes, создать раздельные пулы на разных типах устройств в разы проще. Допилили bluestore, скорость выше. Облегчили процесс замены дисков (ceph osd destroy/purge). Сделали overwrites для erasure coded пулов через реплицируемые пулы. Ввели прозрачную компрессию. Ввели простенький, но всё же мониторинг, встроили плагины для zabbix, prometheus, etc. Cephfs наконец то поддерживает одновременную работу нескольких сервисом метадаты. По сравнению с jewel более быстрый детект неработоспособности osd (введено в релизе kraken). То есть если вы намеренно погасили ноду, то osd сразу входят в состояние down, и ваше IO не прерывается, а в случае если вы его выключили по кнопке, или упала сеть, у вас IO полностью прерывается на срок от 20 секунд и до n минут, что уже вполне хватает чтобы ваши виртуалки упали, а клиенты получили подвисший fd (в случае с rbd). В релизах kraken (11) и выше с этим дела обстоят намного лучше. Ну и других приятных и полезных изменений там хватает. Так же стоит добавить что luminous это тоже lts, что обновление с jewel (и kraken) будет не таким простым (из-за blue store в частности), и что по части багов jewel вряд ли будет сильно лучше luminous.
Ещё вам к раздумьям: цеф отвратительно балансит данные. Существует далеко не нулевая вероятность, что один диск в пуле у вас заполнен на 70% а другой на 95% и цеф вешает флаг full на кластер из-за этого, и у вас всё встаёт колом. Собственно по этому в церне написали свои хелперы на питоне, в частности для ребаланса по крону. Правда для 12 версии пришлось переписывать немного, для поддержки device class. Собственно ссылки по теме:
indico.cern.ch/event/567516/contributions/2293565/attachments/1331568/2001323/050916-cephupdate.pdf
github.com/cernceph/ceph-scripts
И по статье промелькнуло ssd, но нет конкретики какие вы диски используете и в каком кейсе. С cache tiering'ом тоже ведь есть свои нюансы. Не описано какую сеть вы используете (1g/10g/что-то серьезнее?), а ведь сеть для цефа критична, проблемы с ней выльются в подвисших с stuck_unclean pg, в подвисших запросах (blocked requests) и тд. Как ceph себя показывает в вашем случае двух цодов?
А про минимальный вызов внешних программ, это я имел в виду скорее предостережение для тех кто хочет из perl'а grep вызывать (видел и такое).
Плюс есть вещи вроде webmin, и вы могли бы написать модуль для него (или в некоторых местах использовать его)?