есть: bhyve virtualbox qemu jail

был какой-то хайп пару лет назад в жежешечке

пару? лет 10 назад Шетухин там на говно исходил

мы высчитали, что 5

То что было в жж, это было высер одного бывшего сотрудника из почты, да в почте есть фряха и Ubuntu :) а в остальном везде фряха

Шетухин. Его фамилия Шетухин

1. Спорно 2.Да 3. Конешно 4. Покажите мне ZFS или любой рабочий аналог в продакшене на Линукс. Пока не вижу.

Насчет фс я бы согласился

Во чего нашёл в комментариях: 1. Сетевой стек, диспетчер памяти и файловые системы у FreeBSD медленнее линуксовых, особенно в последних ядрах линукса. 2. Нормальной явы на FreeBSD нет. И, скорее всего, не будет. 3. (как следствие 2) Нормальных средств разработки и профилирования на FreeBSD нет, маковские в большинстве случаев не годятся. Это так?

1. C памятью кстати интересно. Реально я давно не видел даже попыток сравнения. Она там совсем разная насколько я понимаю. Надо проводить тесты разносторонние и с пониманием нутра обоих систем. Т.е. это не я (ни одного нутра не знаю). Но по 10-летней давности фря медленнее писАла и сильно лучше себя вела в предельных случаях

1. Спорно 2.Да 3. Конешно 4. Покажите мне ZFS или любой рабочий аналог в продакшене на Линукс. Пока не вижу.

ZFS есть на иллюмосе

нужна, для штук типа openhab

я даже не знаю что это :)

есть: bhyve virtualbox qemu jail

virtualbox чужой и стремный qemu чужой и стремный. и кстати, есть да? jail есть и даже развивается. но он мкеня в последний раз выбесил до ухода на CentOS bhyve... ну вобщем, до qemu-kvm он не дотягивает и смысл его использовать как-то совсем потерян

1. Сетевой стек линуксу еще догонять и догонять, про файловые системы вообще не понятно чего там сравнивать. На HL все упирается всегда в железяку уже

1. Сетевой стек линуксу еще догонять и догонять, про файловые системы вообще не понятно чего там сравнивать. На HL все упирается всегда в железяку уже

Ты смотри, сейчас набежит @pragus и расскажет тебе про сетевой стек

Ты смотри, сейчас набежит @pragus и расскажет тебе про сетевой стек

ну, я просто спрошу по tcp fastopen :)

1. Сетевой стек линуксу еще догонять и догонять, про файловые системы вообще не понятно чего там сравнивать. На HL все упирается всегда в железяку уже

насчёт фс - это не так. легко можно упереться в проблемы с метаданными или же в лимит на число inodes.

Парни, а зачем elasticsearch - openjdk ?

@pragus Ну inodes это не только сабж касается

@pragus Ну inodes это не только сабж касается

у многих фс inode выделяются динамически

не тот канал ))

Мы перед фермой всякого рода вм, контейнеров держим обычно FreeBSD на которой эти моменты решаем

Мы перед фермой всякого рода вм, контейнеров держим обычно FreeBSD на которой эти моменты решаем

а чем балансируете?

nginx-ом, haproxy

Мы перед фермой всякого рода вм, контейнеров держим обычно FreeBSD на которой эти моменты решаем

самое странное применение freebsd )

смотря что

@schors почему же? :)

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

вот для виртуализации, пожалуй странно

@schors почему же? :)

ну хз.

не могу в pkg найти эластиксерч

pkg search elastic elasticsearch-1.7.5 Full-text search engine for Java

@pragus для сервисов вполне, чего смущает то? :)

@pragus для сервисов вполне, чего смущает то? :)

ну смотри, что будет если сдохнет балансер?

поднимется резервный, очевидно

вариантов достаточно много

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

quod custodiet ipsos custodes?

поднимется резервный, очевидно

я понимаю. вопрос в другом: что будет с тем что через этот балансер бегало?

в смысле, кто балансирует самих балансировщиков? :)

(я шучу, я знаю про CARP)

в смысле, кто балансирует самих балансировщиков? :)

вот тоже уместный вопрос.

в случае с балансерами ты лимитирован 10-20гбит/с

Не очень похоже, что это уже вопрос балансировки именно сервисов

Почты там, веба...

Это уже скорей L3 балансировка и тут другие методы

в случае с балансерами ты лимитирован 10-20гбит/с

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

вот да, выше про L3 сказали

Это уже скорей L3 балансировка и тут другие методы

ну у тебя ж есть состояние и со смертью балансера оно умрёт.

мы все приходим тут к очевидным вещам

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

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

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

а исходящий бегает напрямую с бэкенда.

а там, где это делать надо, как правило, до десятков гигабит не доходит

Не обязетально

а исходящий бегает напрямую с бэкенда.

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

угу. но кто балансит балансеры? :)

МАГИЯ

:)

вовов

я думаю, что не стоит балансир и HA смешивать, хоть это и очевидно

все таки задачки разные

опять же той сессии которая на вебе была упасть иногда и допустимо

что не скажешь в целом про задачу доступа

я думаю, что не стоит балансир и HA смешивать, хоть это и очевидно

это да. но они взаимосвязаны и используют схожие техники.

да, но сервисных решений больше, чем обще системных

и не факт, что хуже

для SIP свое, для HTTP свое и т.п.

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

ну, есть же http://google-opensource.blogspot.se/2016/01/seesaw-scalable-and-robust-load.html

Да много чего было, есть будет...

Главное, чтобы был Заказчик, который за это будет платить :)

Главное, чтобы был Заказчик, который за это будет платить :)

ну мы сами себе заказчики и потому бьёмся за каждый доллар экономии :)

это не противоречит тому, чтобы балансеров, было бы больше или меньше, если это все из одного и того же СПО, условно

как бы...

Я не троль. Появилась задача сделать минимальное unix окружение. Какие преимущества бзди перед линуксом? Тем же генто.

Я не троль. Появилась задача сделать минимальное unix окружение. Какие преимущества бзди перед линуксом? Тем же генто.

1. zfs 2. poudriere (обсуждали буквально выше) 3. спорное преимущество, но система портов (у генты собственно развитие этой идеи) 4. своя система стартовых скриптов, рядом с которой все эти линуксовые sysV рядом не валялись, и да, фряшникам понятнее systemd чем самим линуксоидам 4.1. в связи с этим настройка сильно легче 5. netgraph. вещь спорная, но что-то с ней делается легче 6. ipfw сильно проще iptables. но и менее функционален конечно 7. gpart - вот кстати чего нет в линуксах. разбивай диски, смотри диски, ставься на GPT и черта в ступе

1. zfs 2. poudriere (обсуждали буквально выше) 3. спорное преимущество, но система портов (у генты собственно развитие этой идеи) 4. своя система стартовых скриптов, рядом с которой все эти линуксовые sysV рядом не валялись, и да, фряшникам понятнее systemd чем самим линуксоидам 4.1. в связи с этим настройка сильно легче 5. netgraph. вещь спорная, но что-то с ней делается легче 6. ipfw сильно проще iptables. но и менее функционален конечно 7. gpart - вот кстати чего нет в линуксах. разбивай диски, смотри диски, ставься на GPT и черта в ступе

Вот когда люди говорят про нетграф я всегда спрашиваю что в нем такого особенного?

Вот когда люди говорят про нетграф я всегда спрашиваю что в нем такого особенного?

да хз. это ты человек-io :) а я вот только вижу mpd5 под freebsd и не вижу ничего подобного в linux. там всё как poudriere vs что угодно

да хз. это ты человек-io :) а я вот только вижу mpd5 под freebsd и не вижу ничего подобного в linux. там всё как poudriere vs что угодно

accel-ppp

netgraph - это когда надо собрать что-то "странное" для сети

netgraph - это когда надо собрать что-то "странное" для сети

Например?

последний раз я его использовал для того чтобы "выкусывать" специфичный траффик и отдавать в userland на анализ

последний раз я его использовал для того чтобы "выкусывать" специфичный траффик и отдавать в userland на анализ

На L2/L3?

L3

Ну это же все можно и без нетграфа

Особенно, если специфичные вещи можно описать в bpf

можно, но с tcpdump'ом (в смысле с bpf)

в целом - неэффективно, это скорее отладочная история чем продакшин

можно, но с tcpdump'ом (в смысле с bpf)

Ну есть же ng_bpf

тут скорее удобне ipfw divert -> ng, потом еще и обратно запихать можно, так тоже делал

Если бы в ipfw были bpf-матчи, то и это не надо было бы

вот настолько "соложный" анализ для netgraph'а не разу не нужен был

(типа в таком-то байте такого протокола тот флажёк стоит)

Просто я считаю netgraph идеей хорошей, но переоцененной и на которую забили

(типа в таком-то байте такого протокола тот флажёк стоит)

Я вот хартблид ради теста блочил так

Просто я считаю netgraph идеей хорошей, но переоцененной и на которую забили

так и есть

так и есть

Ну меня печалит такая фигня. И нетграф сейчас прикольно было бы скрестить с netmap

Ну меня печалит такая фигня. И нетграф сейчас прикольно было бы скрестить с netmap

жизнь несовершенна. меня тоже печалит

netgraph - хороший конструкток класса - "собери сам" по-хорошему на таких принцыпах должны основываться ядренные подсистемы, ну, как geom

netgraph - хороший конструкток класса - "собери сам" по-хорошему на таких принцыпах должны основываться ядренные подсистемы, ну, как geom

Ну да. Тот же tcp-стек надо тоже в нетграф вынести