Комментарии 94
Мне 2 часа назад пришло письмо от хостера, в котором они сообщают о ребуте VPS в связи с установкой патчей, устраняющих данную уязвимость. Оперативно!
Давно такого уровня дыр не всплывало.
Тем, у кого провайдеры «обновляли» сервера ради этой уязвимости повод задуматься либо о смене провайдера либо требовать обновления на файловую подсистему ploop, взамен старой и уже deprecated simfs.
Предвкушая вопросы почему?
Могу попробовать кратко:
1) simfs отвратительно изолирует ввод-вывод клиентов, то есть будь на физической машине десяток грузящих клиентов и Вы получаете автоматически дикие тормоза
2) simfs небезопасна (как показал баг выше), чисто теоретически это было понятно заранее, проблемы растут из-за общей файловой системы и, соотвественно, общего inode адресного пространства
3) sifms очень часто приводит к поврждению файловой системы на физическом сервере и за сим требует частых проверок/ребутов и иногда прибивает данные насмерть
4) simfs в РАЗЫ медленее бэкапится, чем ploop (а может вообще и не забэкапится)
5) simfs в очень большом числе случаев приводит к тотальному зависанию физических нод из-за того, что какой-то контейнер сделал нечто страшное с файловой системой и это утягивает за собой всю ноду
ploop при этом:
1) Дает отличную изоляцию! Каждый контейнер — отдельное полностью отделенное от кого-либо из соседей блочное устройство
2) Чудесно бэкапится (это всего 1 файл, а не 100500 миллионов мелких файлов)
3) Умеет снапшоты яки LVM, но круче :)
4) Позволяет запускать конетйнеры в разы быстрее
5) Няшный и клевый :)
Могу попробовать кратко:
1) simfs отвратительно изолирует ввод-вывод клиентов, то есть будь на физической машине десяток грузящих клиентов и Вы получаете автоматически дикие тормоза
2) simfs небезопасна (как показал баг выше), чисто теоретически это было понятно заранее, проблемы растут из-за общей файловой системы и, соотвественно, общего inode адресного пространства
3) sifms очень часто приводит к поврждению файловой системы на физическом сервере и за сим требует частых проверок/ребутов и иногда прибивает данные насмерть
4) simfs в РАЗЫ медленее бэкапится, чем ploop (а может вообще и не забэкапится)
5) simfs в очень большом числе случаев приводит к тотальному зависанию физических нод из-за того, что какой-то контейнер сделал нечто страшное с файловой системой и это утягивает за собой всю ноду
ploop при этом:
1) Дает отличную изоляцию! Каждый контейнер — отдельное полностью отделенное от кого-либо из соседей блочное устройство
2) Чудесно бэкапится (это всего 1 файл, а не 100500 миллионов мелких файлов)
3) Умеет снапшоты яки LVM, но круче :)
4) Позволяет запускать конетйнеры в разы быстрее
5) Няшный и клевый :)
позволю пару ремарок
по пункту 1 — все ок, только линуксовый шедулер предоставляет 1 (одну) политику шедулинга ио в сигруппах для блочных устройств, то есть любая доделка, связанная с, допустим, берстом, выльется в нетривиальный геморрой
по пункту 3 — пока fsfreeze не умеет всовываться в контейнер, это не совсем полноценный бекап, хоть и атомарный, жирная бд может вполне себе не восстановиться из такого бекапа при ряде доп условий
по пункту 1 — все ок, только линуксовый шедулер предоставляет 1 (одну) политику шедулинга ио в сигруппах для блочных устройств, то есть любая доделка, связанная с, допустим, берстом, выльется в нетривиальный геморрой
по пункту 3 — пока fsfreeze не умеет всовываться в контейнер, это не совсем полноценный бекап, хоть и атомарный, жирная бд может вполне себе не восстановиться из такого бекапа при ряде доп условий
Что значит 1 политика шедулинга? Для каждого отдельного блочного устройства (ploop) создается своя cgroup'е с возможностью указать, какой приоритет она имеет и даже явно зафиксировать bps/iops для этого конкретного кастомера. Что имеется в виду под «обна политику шедулинга» я не совсем понимаю. В данном случае получается почти идеально изолированный ввод-вывод по аналогии с тем, что используется в KVM, Xen и VmWare.
А кроме этого, OpenVZ даже может изолировать страничный кэш клиентов друг от друга и один клиент не скушает память ноды больше, чем ему положено.
Что значит не умеет всасываться в контейнер? Вы можете сделать снапшот с дампом памяти (по дефалту он именно так и делается). То есть, фризятся все до единого кэши (dentry, page cache, ram, kernel memory) сохраняются в файл на файловой системе и бэкапятся вместе с тушкой контейнера.
Если восстановить такой бэкап, то мало того, что все данные сохранятся, так и сразу запустится все ПО и даже uptime не будет прерван :)
А кроме этого, OpenVZ даже может изолировать страничный кэш клиентов друг от друга и один клиент не скушает память ноды больше, чем ему положено.
Что значит не умеет всасываться в контейнер? Вы можете сделать снапшот с дампом памяти (по дефалту он именно так и делается). То есть, фризятся все до единого кэши (dentry, page cache, ram, kernel memory) сохраняются в файл на файловой системе и бэкапятся вместе с тушкой контейнера.
Если восстановить такой бэкап, то мало того, что все данные сохранятся, так и сразу запустится все ПО и даже uptime не будет прерван :)
Одна политика шедулинга — можно использовать только ту логику шедулинга, которая предоставляется ядром, она, в целом, оптимальная, но может потребоваться ее кастомизация — к примеру, у вас у клиентов идут длинные берсты, которые шедулером косятся. В эмуляторе делать и поддерживать такие правки намного дешевле.
Насчет дампа — я имел в виду конкретный FIFREEZE при снятии снимка диска, насколько мне известно, его в контейнерные решения не завезли пока что. Понятно, что при снятии еще и памяти за счет приостановки всей сущности целиком снимок выйдет на сто процентов консистентным.
Насчет дампа — я имел в виду конкретный FIFREEZE при снятии снимка диска, насколько мне известно, его в контейнерные решения не завезли пока что. Понятно, что при снятии еще и памяти за счет приостановки всей сущности целиком снимок выйдет на сто процентов консистентным.
По поводу шедулера, да, ploop шарит общий с системой шедулер:
Скорее всего там забит либо noop либо тот, что на системе.
Но в целом я думаю технически реализуемо, чтобы каждый ploop имел кастомизируемую дисциплину шедулинга. Если появится кто-то с такой необходимостью, я думаю по программе платной разработки для OpenVZ, ее вполне реально получить.
По поводу того, как конкретно работает фриз, боюсь, ничего не скажу, но поидее потеряться там ничего не должно.
cat /sys/block/ploop*/queue/scheduler | sort | uniq -c
45 none
Скорее всего там забит либо noop либо тот, что на системе.
Но в целом я думаю технически реализуемо, чтобы каждый ploop имел кастомизируемую дисциплину шедулинга. Если появится кто-то с такой необходимостью, я думаю по программе платной разработки для OpenVZ, ее вполне реально получить.
По поводу того, как конкретно работает фриз, боюсь, ничего не скажу, но поидее потеряться там ничего не должно.
Если появится кто-то с такой необходимостью, я думаю по программе платной разработки для OpenVZ, ее вполне реально получить.
Ценник за разработку-поддержку будет крайне негуманным. К тому же тут есть очень интересный нюанс — контейнеры обычно набиваются на ноду, за счет отсутствия оверхеда на ОС, ksm-подобных механизмов и тому подобного очень-очень плотно, потому ограничения им придется выставлять с очень большим оверкоммитом относительно их реальной доли на ноде => легкость дудоса на бендвиз дисковой подсистемы.
Почему негуманными? Я думаю $5-10k вполне устроит ||. Там есть аналог KSM — pfcache, но он работает чутка с иной стороны — кэширует бинарики и либы.
Там чейндж на 2-10 строчек, байты выйдут платиновыми, это помимо поддержки. Поддерживать это у себя — держать ядерного разработчика в пределах доступности, проще и дешевле не пользоваться ядерным блочным шедулером вообще =).
А зачем разработчика? Его просто интегрируют в ветку OpenVZ и все — саппорт будет через bugzilla.openvz.org :) Ну вдруг кому понадобится — у всех кейсы разные))
Если это будет интегрировано с отдельной переключающей кнопкой в основную ветку — к ценнику пририсуется полнуля. В любом случае, это трата ресурсов впустую, лоуэнд недоверенный сегмент, который соответствует контейнерам массового хостинга, просто не окупит изменение даже при относительно крупной потребности в нем. У контейнерных решений доверенного сегмента (докер) совершенно другие потребности и возможности их реализовать, как правило (к примеру, подключить SDS или полку).
Почему Docker довременный, а OpenVZ нет? На мой взгляд все диаметрально наоборот.
Ну ovz в энтерпрайзе во внутренних облаках использует почти ровным счетом никто, а docker — массово. Вопрос, в первую очередь, в позиционировании и в сопутствующем софте. Если я — пользователь и про оба решения слышал одинаково мало, я выберу то, что ставится без необходимости юзать ядро со стороны и то, что проще, у энтерпрайзов примерно такая же логика.
Кто использует Docker из крупных операторов? =) Имхо, он вообще не предназначен для чего-либо чуточку сложнее запустить dev окружение.
Google/FB на своих личных облаках. DotCloud — настолько мелкий оператор, что о нем говорить даже не стоит.
Google/FB на своих личных облаках. DotCloud — настолько мелкий оператор, что о нем говорить даже не стоит.
OpenVZ тоже работает без своего ядра с 3.12 =)
не в ту ветку
О_о Вы открыли мне глаза
Ловите openvz.org/Vzctl_for_upstream_kernel Будет круто, если затестите и нарисуете десяток багрепортов в bugzilla.openvz.org
Кто использует Docker из крупных операторов?
Из операторов — никто. Контейнеры это прекрасное решение для устранения оверхеда, связанного с решедулингом, но в качестве платы — дырявы. Использовать их можно либо для хоум страничек (в недоверенном сегменте, т.е. публичный хостинг) или для всего остального во внутренней инфраструктуре. Использование хостинговыми операторами контейнеров для крупняка по этим причинам нулевое. Да, 3.12 не LTS, а шляпа еще к себе в 7 не затащила изменения вроде бы.
Вот Вы сами и ответили на свой вопрос. Реально крутое решение для изоялции это CloudLinux, потому что они взяли OpenVZ и допилили под нужды хостинга.
А вот для хоум страничек как раз я б рекомендовал вообще отдельные физические машины. Число заразы, которое пролазит с «хоум страничек», просто бесконечное. Мы вот сколько заразы выгребли.
А вот для хоум страничек как раз я б рекомендовал вообще отдельные физические машины. Число заразы, которое пролазит с «хоум страничек», просто бесконечное. Мы вот сколько заразы выгребли.
Я не думаю, что они хотя бы на волос отдалились от существующих проблем безопасности. То, что у них на главной написано — это позиционирование для продаж, а не технологическое преимущество. Речь выше шла как раз про энтерпрайзный сегмент (внутренние облака) и остальных (паблик), пользователи ovz присутствуют только во втором, а это только и исключительно мелкая розница.
Я надеюсь, это скоро изменится — поддержка апстрим OpenVZ была совершенно недавно добавлена в Docker и скоро будет, думаю, поддержка на уровне 2.6.32 :)
Пока вот это не будет выдрано с корнем, сравниваться с lxc на сетеактивных приложениях смысла нет, даже если будет поддержка и все такое.
Зачем это вырывать с корнем-то? Не нравится l3 сеть — используйте veth интерфейсы, они по производительности не особо уступают даже virtio сети в KVM.
Да и в целом по моему опыту, если не используется L2 на машине и не нужен доступ к DHCP/ARP и прочим спец фишкам — это venet рулит по всем параметрам.
Кроме этого, он отлично умеет изолировать iptables connection tracking, что сводит на нет его оверхед.
Да и в целом по моему опыту, если не используется L2 на машине и не нужен доступ к DHCP/ARP и прочим спец фишкам — это venet рулит по всем параметрам.
Кроме этого, он отлично умеет изолировать iptables connection tracking, что сводит на нет его оверхед.
veth pair/virtio — еще одна болезнь, мешающая работать высокопроизводительным решениям. Сто тысяч пакетов в секунду без mq(* 2...3 с mq-tx) makes me sad panda. У пары впрочем все на примерно сотне тысяч и заканчивается насовсем.
Ну воткните SR-IOV раз важна скорость. Он даст спокойно чистых 14 Mpps внутри KVM машины на хорошей карте класса Intel 82599.
Не пойдет, мало vf и отрывается лайв миграция, плюс это не особо чтобы фильтруется мейнстримовыми средствами в пределах ноды. Ну и 14 Mpps он все же не дает, лайн рейт на 82599 достижим только на нетмапе пожалуй. habrahabr.ru/company/performix/blog/224211/ тут я упоминал про нетлинк для фильтрации, но это непринятая никуда экзотика.
PF_RING решает, у нас оно в суровом продакшене и в синтетике выдает полные линейные скорости как раз изнутри KVM машины — github.com/FastVPSEestiOu/fastnetmon :)
64 штуки мало? 64 контейнера работающих на 10GE wire speed? :) Боюсь, что платформ перевариваюших столько без ASIC не существует — тупо PCIE шина колом встанет. Слет лайв миграции — ну надо же чем-то платить за сабсветовую скорость.
По поводу OpenFlow. У Вас кто контроллером работает? Я пока не видел стабильных открытых решений для сабжевой задачи.
64 штуки мало? 64 контейнера работающих на 10GE wire speed? :) Боюсь, что платформ перевариваюших столько без ASIC не существует — тупо PCIE шина колом встанет. Слет лайв миграции — ну надо же чем-то платить за сабсветовую скорость.
По поводу OpenFlow. У Вас кто контроллером работает? Я пока не видел стабильных открытых решений для сабжевой задачи.
Контроллер свой, все открытое неработающее до отвратительности, да. PF_RING — это аналог нетмап+пкап, никакого плюса для собственно транфера не дает, то есть если говорить о контейнерах, пока мы используем venet/pair, характеристики сетевого трафика будут очень и очень скромными. VF, вообще говоря, это не технология, которую можно раздавать в публичном сегменте, так что здесь вендор хостинга лимитирован чисто софтовыми вариантами (и да, 64 vf, особенно если машина толстая а контейнеризованные приложения имеют небольшой отпечаток в памяти, может не хватить, придется ставить вторую карточку).
Если контроллер закрытый, то это какой-то хреновый OpenFlow. Откройте — мы даже можем присоединиться к разработке :)
PF_RING не аналог pcap ни в каком виде, netmap да, безусловно близок. Но PF_RING умеет zero copy и прямой доступ к буферам сетевой через DNA, netmap — нет. Ну и есть железо под PF_RING (Arbor на нем), а под netmap нет.
PF_RING не аналог pcap ни в каком виде, netmap да, безусловно близок. Но PF_RING умеет zero copy и прямой доступ к буферам сетевой через DNA, netmap — нет. Ну и есть железо под PF_RING (Arbor на нем), а под netmap нет.
Нет смысла его открывать — он не поддерживает на сто процентов стандарт и в плане логики сцеплен с оркестровкой. Почему, нетмап умеет прекрасно весь джентльменский набор карточек, так что встроить его к себе — вопрос чисто практической потребности.
" и в плане логики сцеплен с оркестровкой" — все так говорят, когда откровенно боятся открывать свой код. Использовать OpenFlow + SDN и закрывать свой контроллер — очень странная идея.
Если у Вас есть: защита от левых DHCP, защиты от левого ARP, защиты от подмены IP — то Ваше решение уже будет пользоваться спросом. Я гарантирую это, ибо в виртуализации все прочие задачи сбоку припека.
Если у Вас есть: защита от левых DHCP, защиты от левого ARP, защиты от подмены IP — то Ваше решение уже будет пользоваться спросом. Я гарантирую это, ибо в виртуализации все прочие задачи сбоку припека.
Защита есть, конечно. Преимуществ от открытия кода под GPL ровно 0, потому что наши хотелки идут перпендикулярно потенциальным потребностям комьюнити, под BSD так вообще польза отрицательна — крупные игроки возьмут готовое решение и закроются, а потребности во внешнем багрепортинге у нас нет. К тому же, нам нет нужды поддерживать у себя стандарт на сто процентов, так что решение точно не для публики. Если мы и заопенсорсимся, то скопом.
Чтобы крупные игроки взяли решение — надо быть по меньшей мере одним из ведущих евангелистов SDN. Будь у вас миллион раз крутой код, каждая строчка которого выплакана девственницами в пололуние, то без лобби он все равно останется на полке.
GPLv3 позволит Вам использовать помощь сообщества.
Почему Вы сами воспользовались открытыми технологиями, а в ответ не хотите ничего дать? По-моему, это по меньшей мере неэтично по отношению к сообществу и кастомерам.
GPLv3 позволит Вам использовать помощь сообщества.
Почему Вы сами воспользовались открытыми технологиями, а в ответ не хотите ничего дать? По-моему, это по меньшей мере неэтично по отношению к сообществу и кастомерам.
Там, где мы ими воспользовались, ответы оплачены багрепортами в очень неплохих количествах, ну и доделки к опенсорсной части мы не закрываем. Смысл выбрасывать что-то в опенсорс есть только тогда, когда речь идет о компоненте, которая встраивается во множество инфраструктур (это суровая правда, в отличие от пропаганды опенсорса). Выкладывать полноценное инфраструктурное решение в общий доступ бессмысленно, его просто заберет крупняк и все, какого-либо значимого фидбека не возникнет. Достаточно посмотреть на текущее состояние опенстека, который уже раздробился ровно таким образом, несмотря на то. что работает, в общем, намного хуже, чем закрытые платформы. В качестве эксперимента могу предложить написать в Parallels письмо с просьбой об открытии PCS или RH об опубликовании флагов сборки пакетов — поскольку эти вещи являются существенно более нишевыми и имеют намного больше точек сопряжения с остальным софтом, начать стоит с них :).
К слову о нас и Parallels.
Буквально месяца 4 назад по оплаченному гранту компании XServers была добавлена поддержка жесткого ограничения IOPS.
Ну и за последнее время как миниум 3 серьезных функции были разработаны на наши средства/платные багрепорты.
В частности это numa флаги, возможность указания inode для контейнеров, а также во многом с нашей помощью был добавлен параллельный старт контейнеров (ускоряющий старт ноды где-то в 20 раз).
Так что тут контрибуция отлично применяется и работает на благо всех.
Буквально месяца 4 назад по оплаченному гранту компании XServers была добавлена поддержка жесткого ограничения IOPS.
Ну и за последнее время как миниум 3 серьезных функции были разработаны на наши средства/платные багрепорты.
В частности это numa флаги, возможность указания inode для контейнеров, а также во многом с нашей помощью был добавлен параллельный старт контейнеров (ускоряющий старт ноды где-то в 20 раз).
Так что тут контрибуция отлично применяется и работает на благо всех.
Это взаимодействие между заказчиком и потребителем, комьюнити получает результаты постольку, поскольку не закрывать же их от публики. К требованию открытости кода не имеет ровным счетом никакого отношения (кроме того, что если бы openvz разрабатывался закрыто, нужные куски никогда бы не попали в мастер). У нас иная модель — там, где мы используем готовые стеки, активно взаимодействуем с разработчиками на предмет устранения ошибок, а собственные стеки самодостаточны и открытие их не принесет ровным счетом ничего, кроме дополнительной конкуренции собственным же продуктом :).
Ну и пару слов о PCS — он открыт процентов на 99.5, если говорить о ядре. Если говорить о юзерспейсе — там тоже почти ничего нету такого экзотического, что нельзя реализовать руками.
Вы немножко лукавите — ключевая функциональность напрочь закрыта и открывать ее никто не будет. Безусловно, вся закрытая часть относится к юзерспейсу, поскольку поддерживать закрытый ядерный код — тяжелая и бессмысленная задача. То соотношение открытых и закрытых частей, которое достигнуто у всех вендоров, определяется не их идеологией, а только и исключительно оптимизацией расходов.
Какая ключевая функциональность у PCS, решения по виртуализации на основе контейнеризации? :)
Биллинговая логика и софт-сторедж, как примеры. Почему бы не не попросить их открыть хотя бы второе на пользу комьюнити?
В PCS нет ни капли биллинговой логики — Parallels Automation и PACI — это отдельные продукты. Сторадж тоже никто не заставляет использовать да и он в целом бесплатный для малых объемов: openvz.org/Parallels_Cloud_Storage
Вы забываете одно НО — они продают софт, Вы предоставляете услугу.
Если Вы поделитесь SDN контроллером, то это не сделает всех Ваших конкурентов сразу на голову выше Вас и мгновенно Вас разорит, потому что сервисные компании — это 90% сервиса и немного техники за редким исключением.
Мне кажется, это просто переоценка рисков, даже если выкинуть все скрипты и обвязки и всю топологию сетей, это в случае 1 на миллион может быть реально использовано кем-либо в целях против Вас.
Но Ваш код — Ваше решение. Я за здравый подход к опенсорцу, просто в Вашем случае он странный. Вы же не технологию виртуализации с 10кратным ростом плотности изобрели, чесслово.
Если Вы поделитесь SDN контроллером, то это не сделает всех Ваших конкурентов сразу на голову выше Вас и мгновенно Вас разорит, потому что сервисные компании — это 90% сервиса и немного техники за редким исключением.
Мне кажется, это просто переоценка рисков, даже если выкинуть все скрипты и обвязки и всю топологию сетей, это в случае 1 на миллион может быть реально использовано кем-либо в целях против Вас.
Но Ваш код — Ваше решение. Я за здравый подход к опенсорцу, просто в Вашем случае он странный. Вы же не технологию виртуализации с 10кратным ростом плотности изобрели, чесслово.
Но Ваш код — Ваше решение. Я за здравый подход к опенсорцу, просто в Вашем случае он странный
Я же написал, что ни один стандарт из нумерованных не поддерживается на сто процентов. Нам придется тратить усилия а) на полную поддержку стандарта, б) на обновления стандарта (вышел OF 1.5 — вперед, и так далее), в) на изобретение и поддержку дополнительной прослойки, которая бы отвязывала контроллер от оркестровки и делала бы его юзабельным для других оркестровок, в ответ же получим ранний адопшен (зачем?) и конкуренцию (зачем?). Такое себе можно позволить, если *не* являться производителем и потребителем услуги одновременно, совмещенных вариантов в мире я что-то не встречаю, да и мы не профильный вендор, чтобы вбухивать собственные деньги на поддержку публичного решения, имеющего десяток закрытых и десяток открытых аналогов.
Хорошо, тем не менее, сторедж закрыт и открываться или делиться хотя бы архитектурными идеями не спешит (кроме того, что в целом это +- отвечает Ceph/Nutanix на самом абстрактном уровне). Биллинг даже уберу из примера, это исключительно коммерческая сущность и она имеет право быть закрытой. Бесплатный для малых объемов — идеальный вариант подсадки на любой наркотик =).
И тем не менее, компаний предоставляющих аналогичный по ТТХ сторадж в мире нет :) Так что тут явный риск, да и интеллектуальная собственность.
Хотя, повторюсь, успешность данного продукта с моей точки зрения под вопросом по ряду причин. Но вовсе не технических.
Технически — это будущее файловых систем.
Хотя, повторюсь, успешность данного продукта с моей точки зрения под вопросом по ряду причин. Но вовсе не технических.
Технически — это будущее файловых систем.
И тем не менее, компаний предоставляющих аналогичный по ТТХ сторадж в мире нет :) Так что тут явный риск, да и интеллектуальная собственность.
WHAT. Если просто поставить цеф и эту систему на одно и то же железо, там будет разница в разы по суммарным бенчмаркам стораджа, и не в пользу решения от Parallels. Собственно, зачем мне завязываться на сущность, работающую через FUSE и делающую это хуже, чем опенсоурсный аналог?
Проведите тесты, докажите :) Публичных тестов я не видел и с радостью посмотрю, зато есть результаты нашего внутреннего тесирования и оно прошло просто на ура.
То, что она работает через FUSE это скорее фича и ловушка для тех, кто ожидает лагов от fuse решения. До релиза CS была хорошая артподготовка в коде ядра: lwn.net/Articles/556980/ и многие другие — поищите по LKLM, которая позволила вынести высокоскоростной I/O из ядра.
Вас же не смущает быстрый netmap (кстати, его документация редкостное нечто) или PF_RING (о моя любовь!) в user space? Почему FUSE на стероидах должен лагать? :)
То, что она работает через FUSE это скорее фича и ловушка для тех, кто ожидает лагов от fuse решения. До релиза CS была хорошая артподготовка в коде ядра: lwn.net/Articles/556980/ и многие другие — поищите по LKLM, которая позволила вынести высокоскоростной I/O из ядра.
Вас же не смущает быстрый netmap (кстати, его документация редкостное нечто) или PF_RING (о моя любовь!) в user space? Почему FUSE на стероидах должен лагать? :)
Fuse там действительно быстрый, само решение в целом дает меньшие, чем Ceph, цифры, бенчмарки я проводил для себя. Вот бенчмарков от производителя, подтверждающих обратное, я не вижу, даже ребята из гластера еще до покупки редхатом цефа нашли конфигурацию, на которой гластер работал лучше. Сравнивать то, как работает fuse, с механизмом зерокопи в упомянутых фреймворках, ну очень странно :)
Давайте предметно :) Что не дает PCS:S? Я могу ответит почти по всем вопросам, касающимся его. Но не могу здраво сравнить с Ceph на глубоком уровне. Давайте устроим сравнение :)
Ну, вопрос изначально стоял на уровне опенсорсить его или нет.
Собственно, если этот вариант отпадает (уникальности особо ни в чем нет), значит, опенсорсить в первую очередь имеет смысл такую распространенную и востребованную вещь как распределенный сторадж, а во вторую — такую узкоспециализированную, как контроллер программной сети :). Я точно не буду выкладывать сравнения, потому что формально заинтересован в том, чтобы выставить цеф в положительном свете и ссылаться на итоги для привлечения клиентов. Вариант сам намерял — сам горжусь мы не используем.
И тем не менее, компаний предоставляющих аналогичный по ТТХ сторадж в мире нет
Собственно, если этот вариант отпадает (уникальности особо ни в чем нет), значит, опенсорсить в первую очередь имеет смысл такую распространенную и востребованную вещь как распределенный сторадж, а во вторую — такую узкоспециализированную, как контроллер программной сети :). Я точно не буду выкладывать сравнения, потому что формально заинтересован в том, чтобы выставить цеф в положительном свете и ссылаться на итоги для привлечения клиентов. Вариант сам намерял — сам горжусь мы не используем.
Ну я уже сказал, что Вы вольный принимать решения самостоятельно, я же ничего не навязываю :)) А вот крутое сравнение Ceph vs PCS:S я бы с радостью нарисовал.
Можно задеплоить и то и то и прогнать fio к примеру на разных профилях из виртуалки.
Павел, а у кого-нибудь из хостеров, работающих с Паралелс, к настоящему моменту есть опыт использования PCS:S в продакшене на масштабах сотен / тысяч виртуальных серверов? Ну и вот чтобы прямо сейчас можно было зарегистрироваться и воспользоваться снепшотами, клонированием, инкрементальными бэкапами, SSD кешированием?
Вот это Вы мне отвесили =)
Безусловно, есть, но если я их назову — это будет не особо этично, потому что информация моя не из открытого источника. Я думаю, у них речь идет о сотнях тысяч виртуальных окружений.
Так что боюсь, я на Ваш вопрос ответить не смогу. Попробуйте уточнить у представителя Parallels на Хабре habrahabr.ru/company/parallels/
Безусловно, есть, но если я их назову — это будет не особо этично, потому что информация моя не из открытого источника. Я думаю, у них речь идет о сотнях тысяч виртуальных окружений.
Так что боюсь, я на Ваш вопрос ответить не смогу. Попробуйте уточнить у представителя Parallels на Хабре habrahabr.ru/company/parallels/
У нас в InfoboxCloud создано 8699 виртуальных серверов на Parallels Cloud Storage. Пробная версия.
Ну только, как вы, конечно же, знаете, нужно не забывать про батарейку на RAID контроллер. Иначе можно почти все контейнеры на ноде потерять. bugzilla.openvz.org/show_bug.cgi?id=2970
А где в багрепорте про потерю данных хотя бы слово? Там были повреждены файловые системы ext4 внутри контейнеров, но ошибки были без особых проблем испарвлены силами ploop check и запущены в продакшен.
О, раз Вы работает там, где работаете, то отдельная благодарность за оперативную интеграцию ploop в VDSmanager. Мы ее два года ждали, но так и был вынуждены переехать на другую панель управления.
> Няшный и клевый :)
Пруфпик?
Пруфпик?
К слову, уязвимости на самом деле неделя, но пока Michał Grzędzicki не ткнул носом — никто не чесался.
Ну а чего чесаться? :) simfs — давно уже в состоянии «НЕ РЕКОМЕНДОВАНА К ПРОМЫШЛЕННОМУ ИСПОЛЬЗОВАНИЮ», так что лично с моей точки зрения — это не сказать, что суперкритикал баг.
Для контейнерщиков, у кого не плуп, вышло критично, впрочем, у них и так забот хватает — обновлять ядро на каждый ядерный эксплойт с приостановкой обслуживания.
Контейнерщики пускающие в продакшен контейнеры отличные от Solaris/OpenVZ — вообще отдельная тема извращецев :)
Дело даже не в обновлении ядер, а в том, что Linux Upstream Containers дырявы настолько, что там и без багов можно либо вывести из строя либо вообще взломать хост-сервер 1000 и 1 спосбом.
Дело даже не в обновлении ядер, а в том, что Linux Upstream Containers дырявы настолько, что там и без багов можно либо вывести из строя либо вообще взломать хост-сервер 1000 и 1 спосбом.
Садятся усе. почти (с)
можно поподробнее про 1000 и 1 способ?
Поднял lxc в тестовой лабе готов тестировать способы.
Поднял lxc в тестовой лабе готов тестировать способы.
Я писал про это месяца два назад, посмотрите вот тут блок «Общие проблемы при использовании контейнеров» или лучше всю статью.
Ну и сабжевая новость как раз из серии — почему Linux Upstream контейнеры менее безопасны, чем OpenVZ в рекомендованной (simfs даааавно нерекомендованная) конфигурации.
Если у Вас ядро старее, чем 3.14, то сходу проблема, что процессы с root полномочиями в контейнере работают также от root на ноде и в случае пробоя слоя изоляции могут натворить такого, о чем лучше даже не думать.
Тоже самое касается изоляции /proc, у всех конетйнеров он системный с кучей лишней информации о соседях, которую можно использовать для атаки.
Ну и сабжевая новость как раз из серии — почему Linux Upstream контейнеры менее безопасны, чем OpenVZ в рекомендованной (simfs даааавно нерекомендованная) конфигурации.
Если у Вас ядро старее, чем 3.14, то сходу проблема, что процессы с root полномочиями в контейнере работают также от root на ноде и в случае пробоя слоя изоляции могут натворить такого, о чем лучше даже не думать.
Тоже самое касается изоляции /proc, у всех конетйнеров он системный с кучей лишней информации о соседях, которую можно использовать для атаки.
Если честно, то я надеялся на ссылочки CVE.
Из критичного ( по моему мнению ) только эти пункты
Спасибо.
Из критичного ( по моему мнению ) только эти пункты
В Linux upstream containers есть проблемы с изоляцией файловой системы /proc между контейнерами. В OpenVZ данная проблема решена.
Отсутствие встроенного решения для лимитированию скорости сетевого соединения — эта проблема затрагивает как Linux upstream containers, так и OpenVZ. Разумеется, возможно создание собственных решений на базе tc, но настолько полезная функция просто обязана быть.
Спасибо.
Ну и пункт, который я означил выше — отсутствие отделения root пользователя контейнера от ноды, что дает много лишнего доступа. /proc — также очень критично, так как зная многое о других процессах можно использовать это как пладцарм для атаки на другое приложение.
А в целом основые проблемы, разумеется, в управлении ресурсами. Например, если сделать mount --bind много тысяч раз, можно прибить ноду. Также можно забить dentry кэш или замучать страничный кэш. Или, например, забить лимит на число открых файлов/сокетов на ноде. Тоже самое можно сделать, например, через conntrack — он вообще не изолирован и приведет к тотальной смерти ноды и отбросу соединений :)
В общем список атак, которые можно реализовать на апстримовых контейнеров просто зашкаливает. Это просто by design пока очень небезопасная технология, я думаю, никакого смысла CVE писать нету, их будет тысячи. Что волне нормально, так как технология еще только в beta/developer preview и подходит для запуска лишь своего личного ПО.
А в целом основые проблемы, разумеется, в управлении ресурсами. Например, если сделать mount --bind много тысяч раз, можно прибить ноду. Также можно забить dentry кэш или замучать страничный кэш. Или, например, забить лимит на число открых файлов/сокетов на ноде. Тоже самое можно сделать, например, через conntrack — он вообще не изолирован и приведет к тотальной смерти ноды и отбросу соединений :)
В общем список атак, которые можно реализовать на апстримовых контейнеров просто зашкаливает. Это просто by design пока очень небезопасная технология, я думаю, никакого смысла CVE писать нету, их будет тысячи. Что волне нормально, так как технология еще только в beta/developer preview и подходит для запуска лишь своего личного ПО.
> процессы с root полномочиями в контейнере работают также от root на ноде
А разве user namespace появился не несколько раньше?
> у всех конетйнеров он системный с кучей лишней информации о соседях
общая информация — та, которая относится к хосту, cmdline, device tree, irq, прочее. Соседние PIDы в proc не видно.
А разве user namespace появился не несколько раньше?
> у всех конетйнеров он системный с кучей лишней информации о соседях
общая информация — та, которая относится к хосту, cmdline, device tree, irq, прочее. Соседние PIDы в proc не видно.
Товарищи из коамнды ядра подтянулись и подкинули яркий пример — вот, смотрите :)
Вот Вам способ:
Взято вот отсюда: lkml.org/lkml/2013/6/17/143
Вот Вам способ:
$ mount -t tmpfs xxx /mnt
$ mount --make-shared /mnt
$ for i in `seq 30`; do mount --bind /mnt `mktemp -d /mnt/test.XXXXXX` & done
Взято вот отсюда: lkml.org/lkml/2013/6/17/143
К автору! Добавьте, пожалуйста, workaround в новость: twitter.com/_openvz_/status/481475202304339969
For all CTs:
For all CTs:
vzctl set $CTID --capability dac_read_search:off --save --setmode restart
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Критическая уязвимость OpenVZ