Комментарии 159
В комментариях хотелось бы обсудить, кто для каких целей использует контейнеры и на базе каких дистрибутивов. Если будут вопросы — задавайте, технические вопросы по OpenVZ также приветствуются, будет кому ответить! :)
Основной вопрос — обновление дистрибутива контейнера.
Плюс небольшая просьба — проведите, пожалуйста, сравнение с солярис-зонами — крайне интересно когда же линукс дойдёт до той же стадии развития контейнеризации. Сейчас, например, как я понял, нету ограничения контейнеров по ресурсам типа цпу, i/o. Так же нет аналога sparse zone и т.п.
Плюс небольшая просьба — проведите, пожалуйста, сравнение с солярис-зонами — крайне интересно когда же линукс дойдёт до той же стадии развития контейнеризации. Сейчас, например, как я понял, нету ограничения контейнеров по ресурсам типа цпу, i/o. Так же нет аналога sparse zone и т.п.
Дистрибутив контейнера обновляется так же, как обычная система. Администратор контейнера запускает yum update или apt-get update и т п
Ограничение по ресурсам есть. Да и мне кажется, что солярис зоны уже позади.
Ограничение по ресурсам есть. Да и мне кажется, что солярис зоны уже позади.
Простите, неточно выразился.
Дистрибутив не по типу rolling update, например ubuntu 12.04 server
Очень скоро предстоит обновлять контейнера до 14.04
Опишите, пожалуйста, процесс или ссылку дайте.
> Да и мне кажется, что солярис зоны уже позади.
линукс пока их даже не догнал ни по функционалу ни по управлению
жаль, что соляра сошла с ринга и оракл умертвил такие революционные технологии
Дистрибутив не по типу rolling update, например ubuntu 12.04 server
Очень скоро предстоит обновлять контейнера до 14.04
Опишите, пожалуйста, процесс или ссылку дайте.
> Да и мне кажется, что солярис зоны уже позади.
линукс пока их даже не догнал ни по функционалу ни по управлению
жаль, что соляра сошла с ринга и оракл умертвил такие революционные технологии
> линукс пока их даже не догнал ни по функционалу ни по управлению
Чтоб не быть голословными, дайте несколько примеров функциональности, которой сейчас нет в Linux, но есть в Solaris.
Чтоб не быть голословными, дайте несколько примеров функциональности, которой сейчас нет в Linux, но есть в Solaris.
Садиться анализировать самому мне не хватает ни знаний по OpenVZ ни кучи времени для хорошей статьи, уж извините.
Я задал пару вопросов чуть выше из того, что навскидку вспомнил. Например, из обще-архитектурного — sparse zone, zfs snapshots (я знаю про openzfs, но в солярисе zfs пронизывал всё насквозь, а в линуксе это пока прибито кое как сбоку со всеми вытекающими). Есть ли в линуксе аналог солярисовского CrossBow (сетевой стек), который гармонично сочетается с контейнеризацией? До сих пор в линуксе нет ничего близко напоминающего SMF, хотя это уже немного в сторону.
Я задал пару вопросов чуть выше из того, что навскидку вспомнил. Например, из обще-архитектурного — sparse zone, zfs snapshots (я знаю про openzfs, но в солярисе zfs пронизывал всё насквозь, а в линуксе это пока прибито кое как сбоку со всеми вытекающими). Есть ли в линуксе аналог солярисовского CrossBow (сетевой стек), который гармонично сочетается с контейнеризацией? До сих пор в линуксе нет ничего близко напоминающего SMF, хотя это уже немного в сторону.
Вот похоже вы знаете про солярис, я знаю про OpenVZ. Давайте ответим на этот вопрос раз и навсегда.
Снапшоты в OpenVZ есть на ploop девайсах. В апстриме они есть на BTRFS. CrossBow — это network namespace в Linux. SMF — это systemd. Продолжайте.
ps: zfs — файловая система, прямого отношения к контейнерам она не имеет.
Снапшоты в OpenVZ есть на ploop девайсах. В апстриме они есть на BTRFS. CrossBow — это network namespace в Linux. SMF — это systemd. Продолжайте.
ps: zfs — файловая система, прямого отношения к контейнерам она не имеет.
На btrfs считайте, что нет. Я попробовал однажды на боевом сервере (одном из) сделать LXC контейнеры с btrfs в качестве container store. Это была печаль. Пришлось откатываться. С теми строчками (и в том количестве), что оно пишет в dmesg, я в production жить не готов, извините.
Crossbow и SMF — это то, да не то. С виду похоже, но тем, кто с Solaris не работал, разницу замучаешься объяснять, извините снова. Это иррационально, но факт.
Crossbow и SMF — это то, да не то. С виду похоже, но тем, кто с Solaris не работал, разницу замучаешься объяснять, извините снова. Это иррационально, но факт.
А может быть подготовите обзор контейнеризации в Solaris? У меня есть такой, еще про Solaris 10 и довольно поверхностный. Тогда можно будет проще провести аналогии и Вам и нам :)
В целом с информацией по Solaris после поглащения Sun ситуация очень напряженная. Когда был Sun (произносить шепотом и с благоговением!), был чудесный ресурсы blogs.sun.com, где были представлены все ключевые разработчики ZFS, Solaris, Zones, SMF и прочих. Сейчас же ничего кроме гайдов от Oracle (от которых глаза вытекают) найти почти нереально.
Еще хуже стало с закрытием Open Solaris, тогде более-менее активное коммунити выступавшее с новыми фичами Solaris было окончательно прибито.
А сейчас за весь последний год на SlideShare ни одной толковой презентации по Solaris…
В целом с информацией по Solaris после поглащения Sun ситуация очень напряженная. Когда был Sun (произносить шепотом и с благоговением!), был чудесный ресурсы blogs.sun.com, где были представлены все ключевые разработчики ZFS, Solaris, Zones, SMF и прочих. Сейчас же ничего кроме гайдов от Oracle (от которых глаза вытекают) найти почти нереально.
Еще хуже стало с закрытием Open Solaris, тогде более-менее активное коммунити выступавшее с новыми фичами Solaris было окончательно прибито.
А сейчас за весь последний год на SlideShare ни одной толковой презентации по Solaris…
Есть OverlayFS, если очень хочется делать снепшотинг.
Я бы не сказал, что я знаю солярис, у меня есть некоторый опыт.
> Снапшоты в OpenVZ есть на ploop девайсах.
Снапшоты в линуксе это немного не то, что снапшоты zfs.
Cитуация такая: устанавливаю я пакет или обновляю систему или обновляю boot environment, перед установкой система делает снэпшот, устанавливает пакет, если мне не нравится я откачусь на совершенно то, что было до установки, всё это происходит под капотом на базе zfs. На любой чих у меня есть снапшот до, который восстанавливается одним движением. В линуксе такого нет и долго ещё не будет.
> В апстриме они есть на BTRFS.
Тут уже были обзорные статьи с попытками поиспользовать btrfs, если коротко — ужас-ужас.
> CrossBow — это network namespace в Linux.
Мне показалось, что network namespace это малая часть от CrossBow, по хорошему надо бы сесть и почитать самому, когда будет время.
> SMF — это systemd.
Вы не правы. Systemd это попытка написать свой launchd, но до SMF ему ещё очень-очень далеко.
Например обыденная задача солярис-админа — проверить из консоли всё ли работает? Решение —
> Продолжайте.
Systemd вон пишут попирает основы линукса вбирая в себя невбируемое, искривляя каноны и догматы, подменяет собой существующие кирпичики. Многим это не нравится, говорят это не linux way. Та же проблема и с zfs, котороая находясь в основе ОС решает многие задачи просто и эффективно.
> ps: zfs — файловая система, прямого отношения к контейнерам она не имеет.
Начнём с того, что zfs это больше чем просто файловая система. На zfs лежит весь солярис, фишки zfs типа snapshot, send/receive, cow, dedup и т.п. прямо влияют на эффективность работы контейнеров и работы с контейнерами. Отсутствие zfs в линуксе порождает ужасы типа lvm, ploop. Попытка создать «свой» zfs в виде btrfs провалилась с грохотом — я не верю, что btrfs станет мэйнстримом когда либо, не говоря уже про то, что btrfs ляжет в основу линукса так же гармонично как zfs положили под соляру.
> Снапшоты в OpenVZ есть на ploop девайсах.
Снапшоты в линуксе это немного не то, что снапшоты zfs.
Cитуация такая: устанавливаю я пакет или обновляю систему или обновляю boot environment, перед установкой система делает снэпшот, устанавливает пакет, если мне не нравится я откачусь на совершенно то, что было до установки, всё это происходит под капотом на базе zfs. На любой чих у меня есть снапшот до, который восстанавливается одним движением. В линуксе такого нет и долго ещё не будет.
> В апстриме они есть на BTRFS.
Тут уже были обзорные статьи с попытками поиспользовать btrfs, если коротко — ужас-ужас.
> CrossBow — это network namespace в Linux.
Мне показалось, что network namespace это малая часть от CrossBow, по хорошему надо бы сесть и почитать самому, когда будет время.
> SMF — это systemd.
Вы не правы. Systemd это попытка написать свой launchd, но до SMF ему ещё очень-очень далеко.
Например обыденная задача солярис-админа — проверить из консоли всё ли работает? Решение —
svcs -xv. В линуксе в принципе нет аналога.> Продолжайте.
Systemd вон пишут попирает основы линукса вбирая в себя невбируемое, искривляя каноны и догматы, подменяет собой существующие кирпичики. Многим это не нравится, говорят это не linux way. Та же проблема и с zfs, котороая находясь в основе ОС решает многие задачи просто и эффективно.
> ps: zfs — файловая система, прямого отношения к контейнерам она не имеет.
Начнём с того, что zfs это больше чем просто файловая система. На zfs лежит весь солярис, фишки zfs типа snapshot, send/receive, cow, dedup и т.п. прямо влияют на эффективность работы контейнеров и работы с контейнерами. Отсутствие zfs в линуксе порождает ужасы типа lvm, ploop. Попытка создать «свой» zfs в виде btrfs провалилась с грохотом — я не верю, что btrfs станет мэйнстримом когда либо, не говоря уже про то, что btrfs ляжет в основу линукса так же гармонично как zfs положили под соляру.
Adnako, почти все, что Вы говорите истинная правда, безусловно. Но мы сравниваем радикально различные вещи.
Сравнивать можно Linux и Open Solaris и вторая проиграет с треском по причине, что она почти 3 года мертва. У OpenSolaris был крутой шанс стать более-менее общеупотребительной ОС, но он был обрублен на корню компанией Oracle.
В свою очередь Oracle Solaris — это нишевой продукт и даже сам Oracle ранее рекомендовавший чуть ли не исключительно Solaris ведет активную кампанию по популяризации своего Linux и это — не с проста.
Кроме этого, стоит обратить внимание, что Oracle Solaris не допустимо использовать для коммерческих целей (только для целей разработки) без приобретения очень дорогой лицензии от Oracle.
Поэтому мы сейчас сравниваем открытый бесплатный, но при этом активно развиваемый сообществом продукт в виде Linux upstream containers и коммерческий, очень дорогой корпоративный дистрибутив ведущий свою историю из мира Unix.
В мире контейнеров тоже есть платные решения, например Parallels Cloud Server, который на голову разбивает OpenVZ по эксплуатационным качествам и предоставляет даже распределенную кластерную файловую систему, которая даже круче ZFS (но тут стоит оговориться, что это узкоспециализироавнная ФС и сравнивать ее с обычными — некорректно). А KVM в свою очередь проиграет VmWare ESXi (разумеется, с пакетом управления vCenter), если не по производительности, то по функционалу и поддержке — точо.
Согласитесь, странное сравнение?
Сравнивать можно Linux и Open Solaris и вторая проиграет с треском по причине, что она почти 3 года мертва. У OpenSolaris был крутой шанс стать более-менее общеупотребительной ОС, но он был обрублен на корню компанией Oracle.
В свою очередь Oracle Solaris — это нишевой продукт и даже сам Oracle ранее рекомендовавший чуть ли не исключительно Solaris ведет активную кампанию по популяризации своего Linux и это — не с проста.
Кроме этого, стоит обратить внимание, что Oracle Solaris не допустимо использовать для коммерческих целей (только для целей разработки) без приобретения очень дорогой лицензии от Oracle.
Поэтому мы сейчас сравниваем открытый бесплатный, но при этом активно развиваемый сообществом продукт в виде Linux upstream containers и коммерческий, очень дорогой корпоративный дистрибутив ведущий свою историю из мира Unix.
В мире контейнеров тоже есть платные решения, например Parallels Cloud Server, который на голову разбивает OpenVZ по эксплуатационным качествам и предоставляет даже распределенную кластерную файловую систему, которая даже круче ZFS (но тут стоит оговориться, что это узкоспециализироавнная ФС и сравнивать ее с обычными — некорректно). А KVM в свою очередь проиграет VmWare ESXi (разумеется, с пакетом управления vCenter), если не по производительности, то по функционалу и поддержке — точо.
Согласитесь, странное сравнение?
Сравнивать можно Linux и Open Solaris и вторая проиграет с треском по причине, что она почти 3 года мертва.
Такой какова была OpenSolaris да, мертва. Но ещё теплится Illumos на базе которого живёт пяток дистрибутивов, баги исправляются, вживляется kvm, живы репозитории с софтом, части проекта портируются во FreeBSD. Я бы не сказал, что проект OpenSolaris окончательно ушёл в бессмертные земли [сдувает пыль с сервера OpenIndiana].
У OpenSolaris был крутой шанс стать более-менее общеупотребительной ОС, но он был обрублен на корню компанией Oracle.
God, hail Larry Ellison!
В свою очередь Oracle Solaris — это нишевой продукт и даже сам Oracle ранее рекомендовавший чуть ли не исключительно Solaris ведет активную кампанию по популяризации своего Linux и это — не с проста.
Из своего там заплатки в ядро RHEL для оптимизации своей субд и красный логотип вместо шапки. Проект стал ещё более нишевым.
Кроме этого, стоит обратить внимание, что Oracle Solaris не допустимо использовать для коммерческих целей (только для целей разработки) без приобретения очень дорогой лицензии от Oracle.
OpenIndiana, NexentaStor CE, OmniOS и т.п.
А если учесть, что идеология OpenSolaris изменилась с «bleeding edge» на «крохи с барского стола», то возникает вопрос — а зачем?
Поэтому мы сейчас сравниваем открытый бесплатный, но при этом активно развиваемый сообществом продукт в виде Linux upstream containers и коммерческий, очень дорогой корпоративный дистрибутив ведущий свою историю из мира Unix.
Не, не! Ещё пока жив бесплатный production ready иллюмос в котором есть замечательные Solaris Zones. Есть люди, которые хотят понять в каком месте сейчас находится линукс с контейнерами относительно текущего положения дел в иллюмосе. Понятно, что при постановке вопроса ребром выбор падёт на живой и бьющий ключом линукс, но чисто из энтомологического интересу хочется узнать в сравнении.
В мире контейнеров тоже есть платные решения, например Parallels Cloud Server, который на голову разбивает OpenVZ по эксплуатационным качествам
Тоже неплохо бы почитать обзор реального использования, а не маркетологический булшит.
и предоставляет даже распределенную кластерную файловую систему, которая даже круче ZFS (но тут стоит оговориться, что это узкоспециализироавнная ФС и сравнивать ее с обычными — некорректно)
ZFS не создавалась распределённой, и как далее подмечено — затруднительно понять как одно может быть круче другого
А KVM в свою очередь проиграет VmWare ESXi (разумеется, с пакетом управления vCenter), если не по производительности, то по функционалу и поддержке — точо.
Интерес как раз не в поддержке, а в инструментах управления и фичах. Лично мне от инструментов управления VmWare, созданных только для одной платформы, ни жарко ни холодно. Даже скорее это сильно повлияло на выбор в качестве гипервизора KVM+OpenVZ в исполнении Proxmox с которым я дружу уже несколько лет с первых версий.
Согласитесь, странное сравнение?
Я уже уточнил, что именно хотелось увидеть в сравнении.
Продолжайте, пожалуйста, препарирование OpenVZ — с этим инструментом приходится работать и надо его знать.
почему проиграет? у KVM хватает вкусных фичеров, если сравнивать в контексте систем управления, там достаточно вещей которые vsphere не умеет, и наверное не сумеет никогда, из-за корявого легаси. и поддержка имеется, и сообщество, и база инсталляций.
Как я уже выше говорил (правда про Linux), KVM — это кирпичик для построения всей системы, а не законченый продукт. А VmWare ESXI — это продукт полного цикла, с бэкапами, миграциями, HA, FT, DRS, DS (distributed switch), vSecurity и еще двумя десятками аббревиатур с префиксом v-.
Так что KVM, пока не появится какой-то нереально крутой вендор, который сделает из него продукт полного цикла, не претендует на полное превосходство над VmWare.
Так что KVM, пока не появится какой-то нереально крутой вендор, который сделает из него продукт полного цикла, не претендует на полное превосходство над VmWare.
поэтому я и писал:
> если сравнивать в контексте систем управления
мой любимый oVirt (или платный, с поддержкой RHEV) отлично конкурирует с полноценным vsphere, с бекапами, миграциями, и прочими фичерами. При этом он намного лучше масштабируется (заявлено о 200 хостах в кластере, и между нами, это просто то число на которое у QA хватило железа не задействованого ни под что другое). Кроме того, к овирту можно подключить компоненты опенстак, и расширять функциональность еще больше. Про стоимость я даже не буду заикаться. И оптяь же — под капотом линукс а не кастрированное непонятночто, и можно самому делать все что придет в голову. Я например, таким вот образом написал полноценную интеграцию с cisco UCS, которой два года назад официально не существовало нигде кроме vmware. цискари даже адаптировали мой код и сейчас используют его для собственных плагинов под libvirt и openstack.
да, забыл о изкоробочной интеграции с gluster — очень полезная фича для тех кто не хочет покупать дорогие СХД
> если сравнивать в контексте систем управления
мой любимый oVirt (или платный, с поддержкой RHEV) отлично конкурирует с полноценным vsphere, с бекапами, миграциями, и прочими фичерами. При этом он намного лучше масштабируется (заявлено о 200 хостах в кластере, и между нами, это просто то число на которое у QA хватило железа не задействованого ни под что другое). Кроме того, к овирту можно подключить компоненты опенстак, и расширять функциональность еще больше. Про стоимость я даже не буду заикаться. И оптяь же — под капотом линукс а не кастрированное непонятночто, и можно самому делать все что придет в голову. Я например, таким вот образом написал полноценную интеграцию с cisco UCS, которой два года назад официально не существовало нигде кроме vmware. цискари даже адаптировали мой код и сейчас используют его для собственных плагинов под libvirt и openstack.
да, забыл о изкоробочной интеграции с gluster — очень полезная фича для тех кто не хочет покупать дорогие СХД
oVirt странный, с одной стороны правильный дизайн и много всего сделано по уму. С другой стороны — ему уже 3й или даже 4й год, а воз и ныне там. Усугубляет ситуацию наличие RHEV, который тоже со своими тараканами.
первый релиз был в конце 2011. и «воз» вовсю катится, если смотреть на количество вопросов и предложений приехать поработать которые я получаю, и наблюдаю в рассылках. На нем уже работают несколько европейских хостингов, университеты и просто частные фирмы. RHEV же работает в более серьезных учреждениях, и работает хорошо. Я могу накидать имена очень хорошо известных фирм с которыми лично занимался интеграцией и поддержкой RHEV, но это вряд ли так важно.
Так что я думаю дело в том, что RH — фирма хорошая, но в ней количество инженеров сильно превышает количество маркетологов, и поэтому продукты, кроме собственно RHEL, не так сильно лезут всем в глаза как продукты других фирм.
Так что я думаю дело в том, что RH — фирма хорошая, но в ней количество инженеров сильно превышает количество маркетологов, и поэтому продукты, кроме собственно RHEL, не так сильно лезут всем в глаза как продукты других фирм.
О мертвых либо хорошо, либо ничего. Я понял.
На любой чих у меня есть снапшот до, который восстанавливается одним движением. В линуксе такого нет и долго ещё не будет.
Мммм, LVM Snapshots это не оно?
Я конечно за контейнеры сказать не могу, но просто физический сервак я так бекапил, клёво и удобно получается.
Оно выглядит как утка, крякает как утка, ходит как утка, но если начать разбираться :)
Изнчально LVM это костыли впихиные в парадигму Linux.
Я не силён в LVM и особенно в их снапшотах, через это могу лишь задавать вопросы:
— насколько дорого сделать снапшот в LVM?
— является ли снапшот LVM новым файлом/директорией в плоскости фс или это некий новый объект?
— есть ли send/recevie снапшотов между томами/по сети? (rsync немного не то — лишь малая часть zfs send/recv)
— дорого ли восстанавливать том из снапшота?
— можно ли и как дорого создать новый том из снапшота?
— в zfs существует фича ".zfs" — некая виртуальная директория, где перечислены все созданные снапшоты, я делаю её видимой для пользователей и у меня нет проблем с вопросами типа — «восстанови мне вчерашний файл», есть ли такое в LVM?
Навскидку.
Изнчально LVM это костыли впихиные в парадигму Linux.
Я не силён в LVM и особенно в их снапшотах, через это могу лишь задавать вопросы:
— насколько дорого сделать снапшот в LVM?
— является ли снапшот LVM новым файлом/директорией в плоскости фс или это некий новый объект?
— есть ли send/recevie снапшотов между томами/по сети? (rsync немного не то — лишь малая часть zfs send/recv)
— дорого ли восстанавливать том из снапшота?
— можно ли и как дорого создать новый том из снапшота?
— в zfs существует фича ".zfs" — некая виртуальная директория, где перечислены все созданные снапшоты, я делаю её видимой для пользователей и у меня нет проблем с вопросами типа — «восстанови мне вчерашний файл», есть ли такое в LVM?
Навскидку.
Я ненастоящий сварщик, но всё-таки попробую ответить.
Недорого, используется Copy on Write.
Не совсем понял про новый/не новый объект. Снапшоты именуются и доступны как файлы с этими именами в дев-папке
Боюсь, не настолько владею zfs, чтобы понимать в чём отличие send от rsync. Казалось бы, есть два блочных устройства на соединённых через сеть машинах. Мы хотим их каким-то образом синхронизировать…
Полное копирование необзательно, с некоторых пор есть опция --merge для объединения снапшотов/снапшота и рабочей копии.
Хм, блочной дедупликациив LVM нет, насколько я помню, видимо копировать полностью. Вопрос об этом был?
Выше уже упоминал про папку
— насколько дорого сделать снапшот в LVM?
Недорого, используется Copy on Write.
— является ли снапшот LVM новым файлом/директорией в плоскости фс или это некий новый объект?
Не совсем понял про новый/не новый объект. Снапшоты именуются и доступны как файлы с этими именами в дев-папке
/dev/myvolumegroup/. Файлы представляются в системе как блочные устройства, их можно примонтировать и работать с содержимым (рид-онли, если я всё верно помню).— есть ли send/recevie снапшотов между томами/по сети? (rsync немного не то — лишь малая часть zfs send/recv)
Боюсь, не настолько владею zfs, чтобы понимать в чём отличие send от rsync. Казалось бы, есть два блочных устройства на соединённых через сеть машинах. Мы хотим их каким-то образом синхронизировать…
— дорого ли восстанавливать том из снапшота?
Полное копирование необзательно, с некоторых пор есть опция --merge для объединения снапшотов/снапшота и рабочей копии.
— можно ли и как дорого создать новый том из снапшота?
Хм, блочной дедупликациив LVM нет, насколько я помню, видимо копировать полностью. Вопрос об этом был?
— в zfs существует фича ".zfs" — некая виртуальная директория, где перечислены все созданные снапшоты, я делаю её видимой для пользователей и у меня нет проблем с вопросами типа — «восстанови мне вчерашний файл», есть ли такое в LVM?
Выше уже упоминал про папку
/dev/myVG. Её скорее всего можно подружить с юзерскими полномочиями, но как это сделать я сходу не скажу, извините.Вон что нашёл.
Как я понял CoW имеется в виду именно процесс создания снапшота, т.е., например, при изменении оригинала изменённые блоки уезжают в созданное блочное устройство, которое и является снапшотом?
Если всё так и есть, то уже можно прекратить обсуждать LVM и снапшоты ибо это не просто костыль, это сильно мягко выражаясь — обманка.
ну, например, инкрементальный send/recv с воссозданием абсолютно идентичной иерархии тома с его снапшотами
я не представляю сколько сил надо чтобы на rsync+block device такое запилить, в zfs — из коробки
я быстренько пробежался в гугле про принцип lvm snapshot'ов и коротко уже высказал своё мнение, простите, но это — ужас-ужас
ага, именно так, но дедупликация не при чём, вопрос в том как устроена система, в zfs создание, восстановление или клон снапшота это атомарная мгновенная операция, которую можно представить в виде перенаправления указателя актуальных данных на нужную ветку дерева
ничего готового для использования нет, я лишь про это
спасибо
Недорого, используется Copy on Write.
Как я понял CoW имеется в виду именно процесс создания снапшота, т.е., например, при изменении оригинала изменённые блоки уезжают в созданное блочное устройство, которое и является снапшотом?
Если всё так и есть, то уже можно прекратить обсуждать LVM и снапшоты ибо это не просто костыль, это сильно мягко выражаясь — обманка.
Боюсь, не настолько владею zfs, чтобы понимать в чём отличие send от rsync. Казалось бы, есть два блочных устройства на соединённых через сеть машинах. Мы хотим их каким-то образом синхронизировать…
ну, например, инкрементальный send/recv с воссозданием абсолютно идентичной иерархии тома с его снапшотами
я не представляю сколько сил надо чтобы на rsync+block device такое запилить, в zfs — из коробки
Полное копирование необзательно, с некоторых пор есть опция --merge для объединения снапшотов/снапшота и рабочей копии.
я быстренько пробежался в гугле про принцип lvm snapshot'ов и коротко уже высказал своё мнение, простите, но это — ужас-ужас
Хм, блочной дедупликациив LVM нет, насколько я помню, видимо копировать полностью. Вопрос об этом был?
ага, именно так, но дедупликация не при чём, вопрос в том как устроена система, в zfs создание, восстановление или клон снапшота это атомарная мгновенная операция, которую можно представить в виде перенаправления указателя актуальных данных на нужную ветку дерева
Её скорее всего можно подружить с юзерскими полномочиями, но как это сделать я сходу не скажу, извините.
ничего готового для использования нет, я лишь про это
спасибо
Не успел поправить:
Как я понял CoW имеется в виду именно процесс создания снапшота, т.е., например, при изменении оригинала изменяемые блоки сначала уезжают в созданное блочное устройство, которое и является снапшотом, после чего обновляются в оригинале?
Боюсь, ваша табличка — от 2006 года (судя по хедеру Last Modified). Вот правда, в ядре Линукса достаточно многое с тех пор изменилось:).
Ну а вообще, похоже, дискуссия наша с Вами имеет некоторый ЛОРовский оттенок, и потому не имеет смысла.
Мы ударяемся в обсуждение неких конкреных фич и деталей реализации, забывая о задачах, ради которых и стоит все эти снапшоты городить.
Да, я уверен что можно составить перечень фич, которые есть в zfs, но нет в LVM (ровно как и наоборот, стопудово). Далее у Вас есть полное право голословно для каждого пункта заявить, что вот без этой-то фичи lvm вообще не может считаться софтверным продуктам, и такое не надо не только Вам, но и вообще никому, что всё это несеръёзно и гибрид поделки с подделкой.
Если Вы всеръёз собираетесь что-то узнать/понять, давайте очертим условия и цели, и будем сравнивать конкретные способы их достижения при помощи zfs и LVM?
Ну а вообще, похоже, дискуссия наша с Вами имеет некоторый ЛОРовский оттенок, и потому не имеет смысла.
Мы ударяемся в обсуждение неких конкреных фич и деталей реализации, забывая о задачах, ради которых и стоит все эти снапшоты городить.
Да, я уверен что можно составить перечень фич, которые есть в zfs, но нет в LVM (ровно как и наоборот, стопудово). Далее у Вас есть полное право голословно для каждого пункта заявить, что вот без этой-то фичи lvm вообще не может считаться софтверным продуктам, и такое не надо не только Вам, но и вообще никому, что всё это несеръёзно и гибрид поделки с подделкой.
Если Вы всеръёз собираетесь что-то узнать/понять, давайте очертим условия и цели, и будем сравнивать конкретные способы их достижения при помощи zfs и LVM?
Ну а вообще, похоже, дискуссия наша с Вами имеет некоторый ЛОРовский оттенок, и потому не имеет смысла.
Я постараюсь держать себя в руках.
Мы ударяемся в обсуждение неких конкреных фич и деталей реализации, забывая о задачах, ради которых и стоит все эти снапшоты городить.
Понимаете, именно добираясь до принципов реализации каких-то фич, можно апроксимировать поведение системы в целом, очень неплохо учитывать особенности реализации для понимания того как и почему именно так работает система.
Да, я уверен что можно составить перечень фич, которые есть в zfs, но нет в LVM (ровно как и наоборот, стопудово).
Мы лишь пока про снапшоты говорим.
Далее у Вас есть полное право голословно для каждого пункта заявить, что вот без этой-то фичи lvm вообще не может считаться софтверным продуктам, и такое не надо не только Вам, но и вообще никому, что всё это несеръёзно и гибрид поделки с подделкой.
На что вам нужны объяснения? Я готов пообщаться.
Если Вы всеръёз собираетесь что-то узнать/понять, давайте очертим условия и цели, и будем сравнивать конкретные способы их достижения при помощи zfs и LVM?
Мы пытаемся обсуждать снапшоты там и там.
Мой вопрос такой — решена ли проблема с падением производительности на блочном устройстве с которого снят один или особенно несколько снапшотов?
Моё мнение такое — выбранная схема снапшотинга в лвм ужасна более чем полностью. Но я подозреваю, что остальные способы ещё хуже. Могу сообщить, что снэпшоты зфс не имеют проблем существующих у лвм.
Вам не кажется, что вы совсем разные вещи обсуждаете. Снапшоты в LVM были сделаны для консистентных бекапов. Для их создания нужен отдельный вольюм. Они только ридонли. Может я уже отстал от жизни?
LVM2 snapshots are writeable LV, we could use them to let a project go on into two different directions
Говорит нам вики Генты. Я сам несколько удивился когда это прочитал, честно говоря — вон как ридонли их ещё описываю пятью комментариями выше.
Так что в любом случае спасибо Adnako за инициирование этого диалога.
На что вам нужны объяснения? Я готов пообщаться.
У меня в жизни пока не встречалось потребность в сложной иерархии снапшотов. Если Вы просто укажете, зачем такое используется, буду благодарен за расширение горизонта.
Мой вопрос такой — решена ли проблема с падением производительности на блочном устройстве с которого снят один или особенно несколько снапшотов?
Насколько я знаю, падение производительности действительно есть, на существенно затрагивает оно именно последовательное чтение с самого снапшота, поскольку оно перестаёт быть таким уж последовательным.
Быстрый гуглёж (мы продолжаем говорить только про актуальные измерения, ладно?) нарыл только www.mysqlperformanceblog.com/2013/07/09/lvm-read-performance-during-snapshots/
Я могу и ошибаться, тут опираюсь только на свой опыт (в режиме «создать снепшот приостановив БД, забекапиться с него на offsite, удалить снепшот») и результат чтения того что нашлось по-быстрому.
Если Вы просто укажете, зачем такое используется, буду благодарен за расширение горизонта.
Я немного параноик — мне спокойнее, когда у меня на удалённом бэкап-сервере лежат не только актуальные данные, но и так же снапшоты важных томов, в зависимости от важности на каждый час/день/неделю/месяц. Пока не пригодилось :) Хватало снапшотов на боевом сервере. Но в случае, когда на основном сервере старые снапшоты уйдут в утиль из-за периодической чистки для поддержания нужного объёма свободного места, эти снапшоты останутся на бэкап-сервере значительно дольше. Могут пригодится.
Насколько я знаю, падение производительности действительно есть, на существенно затрагивает оно именно последовательное чтение с самого снапшота, поскольку оно перестаёт быть таким уж последовательным.
Насколько я понимаю проблема падения производительности как раз при записи в оригинальное блочное устройство, ибо идея снапшотов лвм такова, что при изменении блока в оригинальном устройстве сначала этот блок читается, потом переносится в созданные снапшоты и после записывается в оригинальное устройство.
По поводу вашей ссылки — я понял так, что человек бэкапит базу на том который несколько раз заснапшотен и при этом пытается измерить скорость чтения с тома. Оригинальная методика, но не понятно почему надо чесать ухо пяткой.
Я даже не могу представить где можно использовать такой алгоритм, чтобы не навредить перформансу. Получается, что часто и много делать снапшотов попросту нельзя — из-за высокого I/O умрёт любая дисковая система при уже некотором количестве снапшотов. Наличие снапшотов по итогу дорого обходится в отличии от zfs.
Ну, серию снапшотов в таком случае мне вполне заменяет www.rsnapshot.org/, (который на файловом уровне осуществляет дедупликацию хардлинками, кстати говоря).
Вот это туманная область для меня. По идее не должно, потому что
Вы не могли бы привести какую-нибудь более-менее актуальную ссылку на подобные замеры?
Если это так, то это действительно суперстранная постановка эксперимента. У меня при первом прочтении создалось впечатление, что экспериментатор делает снапшот (из-под работающей базы), потом база продолжает работать (и поэтому снапшот использует cow-буфер в тех секторах, где происходит запись), а он сам читает со снапшота (например, как и я делая offsite-backup того, что сохранилось в снимке).
Такой подход был бы объясним, падение производительности вполне может наблюдаться, но в общем с ним можно жить в большинстве случаев, клиентов оно не касается.
В тех местах, где оказывается уже ценно гнаться за актуальностью бэкапов, видимо стоит в принципе использовать что-то с уровня работающих приложений, типа WAL-shipping.
проблема падения производительности как раз при записи в оригинальное блочное устройство
Вот это туманная область для меня. По идее не должно, потому что
Вы не могли бы привести какую-нибудь более-менее актуальную ссылку на подобные замеры?
я понял так, что человек бэкапит базу на том который несколько раз заснапшотен и при этом пытается измерить скорость чтения с тома.
Если это так, то это действительно суперстранная постановка эксперимента. У меня при первом прочтении создалось впечатление, что экспериментатор делает снапшот (из-под работающей базы), потом база продолжает работать (и поэтому снапшот использует cow-буфер в тех секторах, где происходит запись), а он сам читает со снапшота (например, как и я делая offsite-backup того, что сохранилось в снимке).
Такой подход был бы объясним, падение производительности вполне может наблюдаться, но в общем с ним можно жить в большинстве случаев, клиентов оно не касается.
В тех местах, где оказывается уже ценно гнаться за актуальностью бэкапов, видимо стоит в принципе использовать что-то с уровня работающих приложений, типа WAL-shipping.
Вот это туманная область для меня. По идее не должно, потому что
Вы не могли бы привести какую-нибудь более-менее актуальную ссылку на подобные замеры?
Попробую ещё раз объяснить. Смысл LVM снапшота — на базе тома origin создать разреженное пустое блочное устройство snap1. На данные момент цена создания снэпшота крайне мала. Что происходит далее — в origin начинают изменяться блоки. LVM запоминает какие блоки изменились (метаданные), читает из origin эти ещё не изменённые блоки, записывает эти блоки в snap1, записывает новые блоки в origin, помечает в метаданных проделанную работу, после чего считается, что в origin данные записаны.
Т.е. грубо говоря вместо одной операции записи блока происходит чтение и две записи. Это serious impact to performance.
Читаю тут про thin-provisioning, похоже они как-то хотят решить эту проблему, но я ещё не понял как.
Читаю тут про thin-provisioning, похоже они как-то хотят решить эту проблему, но я ещё не понял как.
Пишут, что на thin-provisioned volum'е при наличии нескольких снапшотов происходит всего одна CoW при изменении блока.
Хотелось добавить, что LVM снапшоты требуют место на диске под данные снапшота и метаданные изменённых блоков, что тоже отличается в сторону сильно «дороже» в отличии от ZFS.
>> Ну, серию снапшотов в таком случае мне вполне заменяет www.rsnapshot.org/,
Они будут консистент o_0? Если я в файле изменю несколько байт, то тут хардлинками не обойдешься.
Они будут консистент o_0? Если я в файле изменю несколько байт, то тут хардлинками не обойдешься.
Если это так, то это действительно суперстранная постановка эксперимента.
Судя по этим фразам:
So I recorded some metrics, bi from vmstat and percent of cow space used from lvs during a backup
For this database the backup time was 11h
and it might be a good idea to reduce the number of writes during the backup.
Он занимается именно этим :)
Ну, серию снапшотов в таком случае мне вполне заменяет www.rsnapshot.org/, (который на файловом уровне осуществляет дедупликацию хардлинками, кстати говоря).
Ммм, слабо понимаю какую проблему это решает.
А можете пояснить вот эту фразу?
Взято отсюда.
Please note that snapshots are not persistent. If you unload LVM or reboot, they are gone, and need to be recreated.
Взято отсюда.
Version 0.0.2 $Date: 2000/04/28 01:27:32 $, как отмечено в оглавлении: ds9a.nl/lvm-howto/HOWTO/cvs/lvm-howto/output/lvm-howto.html
Попробуйте wiki.gentoo.org/wiki/LVM, что ли, там вроде всё актуальное (и заодно разница между LVM и LVM2 показывается там, где это актуально).
systemd — это больше чем лаунчер. Да, он ломает каноны, но там настолько опытные люди заняты в проекте, что я хочу думать, что он движется в нужную сторону.
zfs похоже действительно крута, но на линукс ее никто толком портировать не может. Я так понимаю, многие фичи присутствую в btrfs. Если все это действительно кому-то нужно, её допилят за год два.
А пока можете посмотреть в сторону контейнеров на ploop, там снапошоты больше похожи на то, что вы ожидаете увидеть, нежели то, что вы тут обсуждали в LVM. Ну и у ploop есть ряд интересных фич. Автор данного поста, намерен и о нем написать заметку.
Про netns прочтите, будут вопросы спрашивайте. Думаю это сравнимые вещи с CrossBow.
zfs похоже действительно крута, но на линукс ее никто толком портировать не может. Я так понимаю, многие фичи присутствую в btrfs. Если все это действительно кому-то нужно, её допилят за год два.
А пока можете посмотреть в сторону контейнеров на ploop, там снапошоты больше похожи на то, что вы ожидаете увидеть, нежели то, что вы тут обсуждали в LVM. Ну и у ploop есть ряд интересных фич. Автор данного поста, намерен и о нем написать заметку.
Про netns прочтите, будут вопросы спрашивайте. Думаю это сравнимые вещи с CrossBow.
systemd — это больше чем лаунчер. Да, он ломает каноны, но там настолько опытные люди заняты в проекте, что я хочу думать, что он движется в нужную сторону.
Я тоже слежу за его развитием с тех пор как Леннарт оставил в покое пульс-аудио.
Есть мнение, и не только моё, что вместо своего велосипеда было бы неплохо взять за основу открытый launchd как это уже делают некоторые люди из мира BSD. Но идеология линукса не даёт использовать лучшее из открытых разработок, принуждая к вилосипедостроению — убогий btrfs, недоделанный systemd (хотя надо отдать должное — наплевали на вой евангелистов и пытаются сделать как должно быть, а не как по писанию пророчат, поглядим во что вырастет), крайне убогий lvm, убогий gcc (по сравнению с clang+llvm), наколенный SystemTap, список длинный. Всё затраченное время на свои велосипеды можно было использовать куда более эффективно, но — увы.
zfs похоже действительно крута, но на линукс ее никто толком портировать не может.
Отчего же. Контрибьютят в нём не самые последние люди. Недавно вышел production ready релиз. Я поставил на бэкап-сервер 12.04 убунту из ppa — работает. zfs send/recv выполняется, версии zfs и zpool свежайшие, блоки по 4к и сжатие lz4 работает. Rootfs я пока ext4 оставил — нет желания возиться с грубом, но методички существуют, при желании можно перевести. Оно понятно, что zfs в линуксе не на столько глубоко интегрирована в систему, не проведены оптимизации до состояния zfs on solaris, где любой тюнинг zfs почти всегда приводит к падению производительности. Но процесс идёт, в удачном результате заинтересованы не последние силы, есть, короче говоря, надежда.
Я так понимаю, многие фичи присутствую в btrfs
Понимаете, фичи zfs есть в btrfs, вопрос в том — как они реализованы. В таком виде как btrfs готова сейчас — да ну их нафиг, действительно лучше прикрутить сбоку неродной open-zfs, чем пользоваться ванильным ортодоксальным btrfs.
А пока можете посмотреть в сторону контейнеров на ploop, там снапошоты больше похожи на то, что вы ожидаете увидеть, нежели то, что вы тут обсуждали в LVM. Ну и у ploop есть ряд интересных фич. Автор данного поста, намерен и о нем написать заметку.
Я подожду заметку, спасибо.
Про netns прочтите, будут вопросы спрашивайте. Думаю это сравнимые вещи с CrossBow.
Угу.
Посмотрите: http://osv.io, это, конечно, не контейнеры, их вряд ли стоит ожидать в виде форка, а KVM, но при этом с ZFS и прочим.
Дада, слышал, я читаю новости :)
Это, как я понял всего лишь контейнеризация джава-приложения на основе kvm/xen. Немного не то.
Меня пока устраивает мой комбайн на основе Proxmox где приложения бегут в OpenVZ контейнерах. Контейнеры лежат на NFS который экспортирует ZFS тома.
Всё что выше мною написано — своеобразный плачь Ярославны.
Это, как я понял всего лишь контейнеризация джава-приложения на основе kvm/xen. Немного не то.
Меня пока устраивает мой комбайн на основе Proxmox где приложения бегут в OpenVZ контейнерах. Контейнеры лежат на NFS который экспортирует ZFS тома.
Всё что выше мною написано — своеобразный плачь Ярославны.
не только джава, там в принципе не важно какая платформа, просто они еще не допилили под все подряд. а акцент на KVM потому что авторы OSv это авторы KVM, а до этого авторы кучи кода в Xen, короче ребята бывалые.
Основная проблема в том, что это — полная виртуализация на гипервизоре, а не контейнер в том смысле слова, что тут обсуждается. Интересна тема прямого разделения ресурсов хоста, нежели эмуляция виртуального железа.
Ну, кто даст миру полноценную, изолированную контейнеризацию на базе ZFS- like файловой системы — захватит мир :)
из моего опыта, облачные технологии все таки больше полагаются на полную виртуализацию чем на контейнеры, наверное потому что изоляция в публичном облаке очень важна, даже важнее чем на VPS хостингах. Кроме того, KVM можно довести до очень хорошей производительности, почти без потерь по сравнению с контейнерами, особенно если в нем бежит ОС специально под такую работу заточенная.
Да, пока все крупные облака работают на KVM/Xen, но, безусловно, в будущем стоит ожидать супервендора на контейнерах. Ведь все равно всем ясно и понятно, что на Amazon/GCE запускается в 99% случаев именно Linux и тем самым основной недостаток-фича контейнеров нивелируется.
насколько я знаком с этой кухней, openstack уже отлично работает с LXC. но основная масса имплементаций (овер 80% емнип) на KVM. чем обусловлен выбор? скорее всего перевесом достоинств полноценной изоляции (sVirt — штука мощная), по сравнению с экономией на железе. Во всяком случае из общения с клиентами я получал именно такой ответ.
Я считаю, что ни один гипервизор не сможет работать настолько быстро как контейнеризация. Несомненно кому то нужны толстые барьеры, но кому-то — максимальный перформанс и гибкость. Контейнеры в текущей реализации дают достаточную разумную изоляцию.
да я и не спорю, просто чем дальше, тем меньше эта разница. А насчет гибкости, можно еще поспорить, где можно больше наворотить :)
Давайте поспорим. Я могу изолировать одно приложение, оставив его на той же файловой системе и в том же сетевом стеке. Ваш ход.
А я могу запустить любую ОS :)
Могу в онлайне подруливать ресурсы память, cpu, диск спейс.
это и я могу
Память и процессор hotplug и hotunplug?
А размеры диска, вы как собираетесь менять, так чтоб без оверхеда на хосте по месту?
А размеры диска, вы как собираетесь менять, так чтоб без оверхеда на хосте по месту?
> Память и процессор hotplug и hotunplug?
вроде были проблему на уровне qemu, но их уже решили.
а размеры диска очень просто — на LVM
вроде были проблему на уровне qemu, но их уже решили.
а размеры диска очень просто — на LVM
У первого гранулярность большая и сложность реализации в операционной системе. Сейчас уменьшение в меньшую сторону практически не работает.
А с LVM — это лажа. Постепенно после нескольких таких увеличений и уменьшений, вы свои стороджи в лапшу пореже. Я уж не говорю о том, что сейчас мало кто из фс умеет сдуваться в онлайне.
Следующий ход. Могу юзать любые девайсы хоста без какой-либо аппаратной поддержки.
А с LVM — это лажа. Постепенно после нескольких таких увеличений и уменьшений, вы свои стороджи в лапшу пореже. Я уж не говорю о том, что сейчас мало кто из фс умеет сдуваться в онлайне.
Следующий ход. Могу юзать любые девайсы хоста без какой-либо аппаратной поддержки.
я не видел хостов без VT-d уже лет 5 наверное. и да, я могу использовать виртуальные девайсы, 802.1 Qbg/Qbh и могу создавать полностью симулированные девайсы и целые сети. то же самое касается дисков, как отдельно прицепленных к машине так и доступных нескольким машинам в виде кластера. Бекапы могу делать с и без memory state, через элементарную живую миграцию в файл, и мигтрировать могу с и без дисков, кстати. Еще могу строить темплейты из имиджей дисков, поднимать целые VDI системы за минуты, если СХД достаточно резвая (с XtremIO например это даже не минуты а секунды).
Я знаю, что несколько месяцев назад проброс видюх в вмки не работал толком.
честно говоря, меня они никогда не интересовали, я все больше по серверным делам…
Это был реальный фиче реквест к серверной платформе. В добавок это как бы намекает, что не любой девайс можно прокинуть в вмку. Как-то для меня спор не выглядит убедительным:).
Каждый хорош на своем месте и спорить кто круче можно до бесконечности.
Каждый хорош на своем месте и спорить кто круче можно до бесконечности.
зачем серверу проброшенная карточка? бесполезный remotefx? короче и впрямь надо заканчивать ненужный спор
Довольно нужная вещь, особенно если это карточка класса NVidia Tesla. Да и сама по себе виртуализация видео карт при их аховой мощности на вычисления долго ждать не заставит :)
делали рендер кластер в dreamworks на обычных виртуальных процессорах, никто не жаловался :) биткоины добывать — это оно конечно :)
И теряли драгоценные проценты, которые при больших инстансах превращаются в мегаватты-час! :)
давайте не будем гадать, если конечно вы там лично с калькулятором не сидели
От 3-5% не уйти никуда, еще не выпущены процессоры, которые сделают hypercall с нулевым оверхедом. Тот же кэш гарантированно получит промахи, что в свою очередь крайне критично в высокопроизводительном ПО и четко учитывается в специализированной литературе по структурам данных. Я писал про это в прошлой статей, там цифры, много цифр, очень много =)
Всё верно написали, в принципе. Те самые вещи, по которым скучаешь в Linux.
Есть ли в линуксе аналог солярисовского CrossBow (сетевой стек), который гармонично сочетается с контейнеризацией?
я достаточно давно писал про network namespaces в linux
ок, поговорим о crossbow вот в каком ключе: можно ли там иметь свой набор правил пакетного фильтра внутри зоны?
Суперская статья! Спасибо :)
Кстати, в мире «серьезных роутеров» фишка «виртуальный роутер» сейчас довольно трендовая и в принципе тоже самое можно сделать и на Linux. Вопрос лишь в том, все ли так хорошо с изоляцией network namespaces. Вот изоляция conntrack сессий — тому пример, я не видел новостей, чтобы их изолировали полностью от хост ноды. Тоже самое с syn буферами и настройками backlog…
Кстати, в мире «серьезных роутеров» фишка «виртуальный роутер» сейчас довольно трендовая и в принципе тоже самое можно сделать и на Linux. Вопрос лишь в том, все ли так хорошо с изоляцией network namespaces. Вот изоляция conntrack сессий — тому пример, я не видел новостей, чтобы их изолировали полностью от хост ноды. Тоже самое с syn буферами и настройками backlog…
Конечно может.
Не проще ли сесть и прочитать о технологии из первоисточника?
Или мне надо на каждый вопрос бегать в документацию и цитировать сюда?
Или будете верить на слово?
Тогда к чему это?
Solaris IP Filter in Shared-IP Zones
Solaris IP Filter provides stateful packet filtering and network address translation (NAT). A stateful packet filter can monitor the state of active connections and use the information obtained to determine which network packets to allow through the firewall. Solaris IP Filter also includes stateless packet filtering and the ability to create and manage address pools. See Chapter 25, Oracle Solaris IP Filter (Overview), in System Administration Guide: IP Services for additional information.
Solaris IP Filter can be enabled in non-global zones by turning on loopback filtering as described in Chapter 26, Oracle Solaris IP Filter (Tasks), in System Administration Guide: IP Services.
Solaris IP Filter is derived from open source IP Filter software.
Не проще ли сесть и прочитать о технологии из первоисточника?
Или мне надо на каждый вопрос бегать в документацию и цитировать сюда?
Или будете верить на слово?
Тогда к чему это?
во, а теперь пошли нюансы:
т.е. анализатор трафика не запустишь.
т.е. сделать неглобальную зону, через которую бегает весь трафик глобальной зоны — никак.
т.е. всё это больше похоже на venet в openvz. да, в солярисе классные утилиты управления, документация итп. но по возможностям она проигрывает.
Zones other than the global zone have restricted access to the network. The standard TCP and UDP socket interfaces are available, but SOCK_RAW socket interfaces are restricted to Internet Control Message Protocol (ICMP). ICMP is necessary for detecting and reporting network error conditions or using the ping command.
т.е. анализатор трафика не запустишь.
Oracle Solaris IP Filter can be enabled in non-global zones by turning on loopback filtering as described in Chapter 21, IP Filter (Tasks), in Oracle Solaris Administration: IP Services.
т.е. сделать неглобальную зону, через которую бегает весь трафик глобальной зоны — никак.
IP Network Multipathing in Shared-IP Zones. All network configuration is done in the global zone. You can configure IPMP in the global zone, then extend the functionality to non-global zones.
т.е. всё это больше похоже на venet в openvz. да, в солярисе классные утилиты управления, документация итп. но по возможностям она проигрывает.
А расскажите, пожалуйста, как ваши претензии кореллируют с применением в народном хозяйстве?
Не то, чтобы я пока не верю в необходимость заявленного, скорей всего хочется понять какие реальные задачи можно было бы решить, будь в CrossBow то, чего там, по вашему заявлению, нет.
Так же хотелось добавить, что неглобальные зоны могут не только Shared IP иметь. Есть ещё способ называемый — «Exclusive-IP»:
На котором скорей всего можно сделать всё что вы придумать сможете.
Не то, чтобы я пока не верю в необходимость заявленного, скорей всего хочется понять какие реальные задачи можно было бы решить, будь в CrossBow то, чего там, по вашему заявлению, нет.
Так же хотелось добавить, что неглобальные зоны могут не только Shared IP иметь. Есть ещё способ называемый — «Exclusive-IP»:
Exclusive-IP zones have separate TCP/IP stacks, so the separation reaches down to the data-link layer.
На котором скорей всего можно сделать всё что вы придумать сможете.
А расскажите, пожалуйста, как ваши претензии кореллируют с применением в народном хозяйстве?
ок. например, запустить pppoe-сервер внутри контейнера. хотя, да. в солярисе с этим же плохо. как и с пакетным фильтром.
А в OpenVZ можно запустить как OpenVPN, так и PPTP :-P
как можно запустить протокол(pptp)?
может, всё-таки речь о каком-то конкретном демоне?
может, всё-таки речь о каком-то конкретном демоне?
Не совсем, для PPP VPN требуется определенная поддержка от ядра, а также поддержка изоляции «подедржки VPN» которая буквально недавно заработала в OpenVZ: http://habrahabr.ru/company/FastVPS/blog/205162/
Отражение ФС основной системы в OpenVZ-контейнеры через nullfs, я так понимаю, нецелесообразно, и поэтому требуется в каждом контейнере запускать собственные процедуры обновления?
Если коротко — дистрибутивы разные, а так можно было бы вкушать все радости solaris sparse zones.
Если длинно, то когда я покупаю контейнер для личного пользования, как виртуальный сервер, я не хочу, чтоб он обновлялся без моего ведома. Мы же все понимаем, что апдейт — это потенциально опасная процедура, и иногда после нее что-то разваливается. Спроса на данную фичу пока нет. Нет спроса — нет реализации.
Это тоже да. Но бывают контейнеры, которые хотелось бы держать в тонусе совместно с хостом.
Тут получается аж несколько кейсов
1) Если из контейнера делается услуга для клиента — то, безусловно, лезть в него (контейнер) не надо, не наше это дело рыться в чужом контейнере. Тут поидее нафиг ничего не нужно кроме снапшотов и корректного бэкапа.
2) Если же требуется избирательная изоляция сервиса (а также лимиты по процессам), когда изолируется все, кроме файловой системы, то это уже реализуется силами systemd — http://man7.org/linux/man-pages/man5/systemd.cgroup.5.html
А так как systemd — детище Red Hat, то следующим шагом можно ожидать фичи в стиле «установить сервис в контейнер yes/no»?
1) Если из контейнера делается услуга для клиента — то, безусловно, лезть в него (контейнер) не надо, не наше это дело рыться в чужом контейнере. Тут поидее нафиг ничего не нужно кроме снапшотов и корректного бэкапа.
2) Если же требуется избирательная изоляция сервиса (а также лимиты по процессам), когда изолируется все, кроме файловой системы, то это уже реализуется силами systemd — http://man7.org/linux/man-pages/man5/systemd.cgroup.5.html
А так как systemd — детище Red Hat, то следующим шагом можно ожидать фичи в стиле «установить сервис в контейнер yes/no»?
Почему нету ограничения? :) И память, и процессор, и диск (вплоть до IOPS) отлично лимитируются, но описание у нас вышло еще на 3 листа, поэтому решили отделить до следующей публикации.
По поводу Solaris Zones — они, безусловно, вне конкуренции по части управления. Так как можно было из корневой ОС управлять конфигурацией контейнеров и в том числе обновлять их буквально в один клик.
Но в случае Solaris — это было решительно проще, так как там, условно говоря, 1 версия дистрибутива. В случае же Linux хост-машина (физический сервер) обычно на одной ос, а вот контейнеры — на других, что сильно усложняет задачу подддержки.
В проекте OpenVZ были попытки создать универсальный механизм для обновления контейнеров из хостовой ОС, но в данный момент проект, к сожаленю, закрыт http://openvz.org/Download/vzpkg/2.7.0-18, но при этом есть серьезный прогресс в данном вопросе со стороны коммерческой версии OpenVZ, но это уже другой разговор.
В общем случае контейнер обновляется отдельно от хостовой ОС, полностью аналогично том, как это выполнялось бы будь это отдельный физической сервер.
По поводу Solaris Zones — они, безусловно, вне конкуренции по части управления. Так как можно было из корневой ОС управлять конфигурацией контейнеров и в том числе обновлять их буквально в один клик.
Но в случае Solaris — это было решительно проще, так как там, условно говоря, 1 версия дистрибутива. В случае же Linux хост-машина (физический сервер) обычно на одной ос, а вот контейнеры — на других, что сильно усложняет задачу подддержки.
В проекте OpenVZ были попытки создать универсальный механизм для обновления контейнеров из хостовой ОС, но в данный момент проект, к сожаленю, закрыт http://openvz.org/Download/vzpkg/2.7.0-18, но при этом есть серьезный прогресс в данном вопросе со стороны коммерческой версии OpenVZ, но это уже другой разговор.
В общем случае контейнер обновляется отдельно от хостовой ОС, полностью аналогично том, как это выполнялось бы будь это отдельный физической сервер.
Вы делаете упор на OpenVZ контейнеры, но на этом мир не заканчивается. Можно сказать unshare -n -p -m -U -i -u bash -c '( bash; )' и будет изолированный контейнер на той же файловой системе. Засовываем его в cgroup и ограничиваем ресурсы.
А тут, боюсь, все очень печально. Есть много утилит для сборки chroot окружения, но все они со своими проблемами, так как пытаются работать в обход пакетных менеджеров (например, силами эвристики через strace/ldd) и результат обычно получается крайне печальный.
То есть способ создания набора библиотек/конфигурационных файлов для запуска определенного приложения внутри контейнера — это задача сугубо индивидуальная, требующая досконального понимания ПО, которое планируется засунуть в контейнер. Как простое решение — это использование предсозданных шаблонов (самостоятельно либо взятых от вендора) либо не использование изоляции файловых систем, а использование, например, только изоляции сети да IPC, но стоит отдавать себе отчет, что это будет небезопасно.
Я же говорю, что можно приложение изолировать в рамках одной файловой системы. lwn.net/Articles/532593/
> Почему нету ограничения? :) И память, и процессор, и диск (вплоть до IOPS) отлично лимитируются, но описание у нас вышло еще на 3 листа, поэтому решили отделить до следующей публикации.
понятно, значит ждём продолжения :)
> По поводу Solaris Zones — они, безусловно, вне конкуренции по части управления. Так как можно было из корневой ОС управлять конфигурацией контейнеров и в том числе обновлять их буквально в один клик.
С величайшим сожалением пришлось их остановить и переходить на OpenVZ, ибо — оракл.
> В общем случае контейнер обновляется отдельно от хостовой ОС, полностью аналогично том, как это выполнялось бы будь это отдельный физической сервер.
т.е. уже никаких багов с попыткой установить ядро в контейнер, обновить загрузчик и т.п. уже нету?
просто пишем
понятно, значит ждём продолжения :)
> По поводу Solaris Zones — они, безусловно, вне конкуренции по части управления. Так как можно было из корневой ОС управлять конфигурацией контейнеров и в том числе обновлять их буквально в один клик.
С величайшим сожалением пришлось их остановить и переходить на OpenVZ, ибо — оракл.
> В общем случае контейнер обновляется отдельно от хостовой ОС, полностью аналогично том, как это выполнялось бы будь это отдельный физической сервер.
т.е. уже никаких багов с попыткой установить ядро в контейнер, обновить загрузчик и т.п. уже нету?
просто пишем
sudo do-release-upgrade?Отчасти Вы парвы, отчасти — нет :) И Вы просто вынуждаете меня притаскивать часть доводов из второй части статьи.
Если максимально объективно, то одна из основных проблем контейнеров сейчас — это файловая система. В Solarise — это решается через ZFS volume, в Linux ни у кого аналога этой фиче нету, только у Btrfs. Если по другим направлениям работа идет очень активная и даже изоляции procfs можно ожидать в скором времени, то из файловых систем выбор один — Btrfs, которая даже в RHEL 7 не планируется стать стабильной, то есть можно ее ожидать не ранее чем через пару лет.
По поводу do-release-upgrade я ничего, к сожалению, не подскажу. Но могу точно сказать, что удаление ядра и grub Debian 6/7 переживает нормально и при обновлении на следующую ветку все проходит штатно, так как grub/ядро система не трогает в принципе.
В направлении дистрибутивов еще очень много работы, это, пожалуй, одно из слабых мест контейнеров.
Если максимально объективно, то одна из основных проблем контейнеров сейчас — это файловая система. В Solarise — это решается через ZFS volume, в Linux ни у кого аналога этой фиче нету, только у Btrfs. Если по другим направлениям работа идет очень активная и даже изоляции procfs можно ожидать в скором времени, то из файловых систем выбор один — Btrfs, которая даже в RHEL 7 не планируется стать стабильной, то есть можно ее ожидать не ранее чем через пару лет.
По поводу do-release-upgrade я ничего, к сожалению, не подскажу. Но могу точно сказать, что удаление ядра и grub Debian 6/7 переживает нормально и при обновлении на следующую ветку все проходит штатно, так как grub/ядро система не трогает в принципе.
В направлении дистрибутивов еще очень много работы, это, пожалуй, одно из слабых мест контейнеров.
> Отчасти Вы парвы, отчасти — нет :)
Сложно спорить :)
> И Вы просто вынуждаете меня притаскивать часть доводов из второй части статьи.
Я подожду, встретимся в камментах к следующей статье :)
> Если максимально объективно, то одна из основных проблем контейнеров сейчас — это файловая система. В Solarise — это решается через ZFS volume
Истинно так!
>, в Linux ни у кого аналога этой фиче нету, только у Btrfs.
к сожалению это — поделка уровня аспиранта, а если вспомнить мэйнтейнера, то хочется опустить руки — больше надежд на OpenZFS, чем на btrfs
> Если по другим направлениям работа идет очень активная и даже изоляции procfs можно ожидать в скором времени, то из файловых систем выбор один — Btrfs, которая даже в RHEL 7 не планируется стать стабильной, то есть можно ее ожидать не ранее чем через пару лет.
ну вот, да, как-то так
> По поводу do-release-upgrade я ничего, к сожалению, не подскажу. Но могу точно сказать, что удаление ядра и grub Debian 6/7 переживает нормально и при обновлении на следующую ветку все проходит штатно, так как grub/ядро система не трогает в принципе.
скоро апрель — буду экспериментировать, но если появится статья — «How do it right» это будет хорошим подспорьем, ибо проблема наболевшая, у меня даже есть контейнер с Ubuntu 8.04
> В направлении дистрибутивов еще очень много работы, это, пожалуй, одно из слабых мест контейнеров.
К сожалению это — слабая сторона линукса — концепция доказана, в ядро внесены патчи, написаны обвязки-утилиты, работать кое как можно. Довести до ума — почти никогда.
Сложно спорить :)
> И Вы просто вынуждаете меня притаскивать часть доводов из второй части статьи.
Я подожду, встретимся в камментах к следующей статье :)
> Если максимально объективно, то одна из основных проблем контейнеров сейчас — это файловая система. В Solarise — это решается через ZFS volume
Истинно так!
>, в Linux ни у кого аналога этой фиче нету, только у Btrfs.
к сожалению это — поделка уровня аспиранта, а если вспомнить мэйнтейнера, то хочется опустить руки — больше надежд на OpenZFS, чем на btrfs
> Если по другим направлениям работа идет очень активная и даже изоляции procfs можно ожидать в скором времени, то из файловых систем выбор один — Btrfs, которая даже в RHEL 7 не планируется стать стабильной, то есть можно ее ожидать не ранее чем через пару лет.
ну вот, да, как-то так
> По поводу do-release-upgrade я ничего, к сожалению, не подскажу. Но могу точно сказать, что удаление ядра и grub Debian 6/7 переживает нормально и при обновлении на следующую ветку все проходит штатно, так как grub/ядро система не трогает в принципе.
скоро апрель — буду экспериментировать, но если появится статья — «How do it right» это будет хорошим подспорьем, ибо проблема наболевшая, у меня даже есть контейнер с Ubuntu 8.04
> В направлении дистрибутивов еще очень много работы, это, пожалуй, одно из слабых мест контейнеров.
К сожалению это — слабая сторона линукса — концепция доказана, в ядро внесены патчи, написаны обвязки-утилиты, работать кое как можно. Довести до ума — почти никогда.
Насчет того, что Btrfs — вещь «особенная», тут я соглашусь, причем не столько с технической стороны, сколько с организацинной. ZFS, безусловно, был написан одними из крутейших инженеров в данной области и для своего времени, как и сейчас — это очень инновационная ФС, которой в Линуксе дико не хватает.
По поводу «довести до ума» — это же на задача Linux, это уже задача строителей дистрибутивов и вендоров. В Linux нельзя удовлетворить все, те же контейнеры требуются сугубо ограниченному числу людей и оно не так велико в общей массе пользователей, так что я бы не относил это к недостаткам.
Да, встретимся в следующей статье, мы планируем ее буквально через неделю опубликовать, там осталось совершенно немного работы по оформлению.
По поводу «довести до ума» — это же на задача Linux, это уже задача строителей дистрибутивов и вендоров. В Linux нельзя удовлетворить все, те же контейнеры требуются сугубо ограниченному числу людей и оно не так велико в общей массе пользователей, так что я бы не относил это к недостаткам.
Да, встретимся в следующей статье, мы планируем ее буквально через неделю опубликовать, там осталось совершенно немного работы по оформлению.
> По поводу «довести до ума» — это же на задача Linux, это уже задача строителей дистрибутивов и вендоров.
В этом и состоит так называемая «нищета» опенсорса :)
Найдётся ли толковый вендор, который напишет грамотную обвязку так, чтобы не «чужими для хищников»? Хватит ли у него таланта и ресурсов? Не выдохнется ли он через десяток лет?
Жду продолжения!
В этом и состоит так называемая «нищета» опенсорса :)
Найдётся ли толковый вендор, который напишет грамотную обвязку так, чтобы не «чужими для хищников»? Хватит ли у него таланта и ресурсов? Не выдохнется ли он через десяток лет?
Жду продолжения!
Так они уже есть :)
Например, Cloud Linux — это на 99% OpenVZ, из той же серии стоит отметить базирующийся на контейнера из Linux Upstream дистрибутив CoreOs: http://coreos.com/ .
Но наша задача шире — необходимо создание подобных подсистем во всех ведущих дистрибутивах, чем в свою очередь, например, очень активно занимается systemd, который буквально обязал все дистрибутивы перешедшие на него начать использовать контейнеры.
И это — победа! Одна из многих!
Например, Cloud Linux — это на 99% OpenVZ, из той же серии стоит отметить базирующийся на контейнера из Linux Upstream дистрибутив CoreOs: http://coreos.com/ .
Но наша задача шире — необходимо создание подобных подсистем во всех ведущих дистрибутивах, чем в свою очередь, например, очень активно занимается systemd, который буквально обязал все дистрибутивы перешедшие на него начать использовать контейнеры.
И это — победа! Одна из многих!
, из той же серии стоит отметить базирующийся на контейнера из Linux Upstream дистрибутив CoreOs: coreos.com/ .
Вот это хочется пощупать, да.
Но наша задача шире — необходимо создание подобных подсистем во всех ведущих дистрибутивах, чем в свою очередь, например, очень активно занимается systemd, который буквально обязал все дистрибутивы перешедшие на него начать использовать контейнеры.
Всех ведущих, за спинами которых торчат не уши гиков, но денежные мешки, можно пересчитать по пальцам одной руки на которой может не хватать пары пальцев.
Будем посмотреть куда это всё пойдёт.
Из CoreOS торчат уши Грега Кроа Хартмана, текущего мейнтейнера стабильной ветки Linux :) Так что бабло баблом, а без гиков в таких технологиях — ни шагу.
Я извиняюсь, что встреваю, неужели нет перспектив у zfsOnLinux/openZFS?
У нас в продакшене первый вроде бы пока работает, во всяком случае снапшоты с mongodb делать можно =)
zfs, конечно, одна из самых навороченых фс, но у неё своих граблей хватает, поэтому может не стоит её так иделаизировать?
У нас в продакшене первый вроде бы пока работает, во всяком случае снапшоты с mongodb делать можно =)
zfs, конечно, одна из самых навороченых фс, но у неё своих граблей хватает, поэтому может не стоит её так иделаизировать?
Это довольно ограниченные проекты, включить в код ядра Linux их нельзя по причине конфликта лицензий. Что в свою очередь ограничивает интерес многих к ZFS на Linux в целом. Текущие реализации также не боеле контрбуция старого кода Sun, их развитие довольно медленно и с очень непонятным вектором.
Стоп-стоп-стоп.
Зачем обязательно включать их в код ядра, никто не мешает писать модули. Что собственно разработчики проекта и сделали. И уж тем более это не может быть причиной ограничения интереса к zfs на линуксе. Например, разработку zfsonlinux ведет национальная лаборатория Министерства энергетики США ( en.wikipedia.org/wiki/Lawrence_Livermore_National_Laboratory ).
Не думаю, что они взялись от нечего делать. Конечно, было бы интересно узнать поподробнее — в чем именно ограниченность этих проектов.
По поводу медленности развития — давайте не будем, Sun-у здесь похвастаться тоже особо не чем.
В 2013 году разработчики zfsOnLinux официально объявили о production ready, ссылку найти легко. Как я говорил, у меня оно в продакшене тоже работает. Если вас не затруднит, приведите конкретные факты неготовности и ограниченности проекта, чтобы не быть голословным.
Еще не совсем понял смысл вашег высказывания про текущие реализации и «контрбуцию» — что вы имели в виду?
Зачем обязательно включать их в код ядра, никто не мешает писать модули. Что собственно разработчики проекта и сделали. И уж тем более это не может быть причиной ограничения интереса к zfs на линуксе. Например, разработку zfsonlinux ведет национальная лаборатория Министерства энергетики США ( en.wikipedia.org/wiki/Lawrence_Livermore_National_Laboratory ).
Не думаю, что они взялись от нечего делать. Конечно, было бы интересно узнать поподробнее — в чем именно ограниченность этих проектов.
По поводу медленности развития — давайте не будем, Sun-у здесь похвастаться тоже особо не чем.
В 2013 году разработчики zfsOnLinux официально объявили о production ready, ссылку найти легко. Как я говорил, у меня оно в продакшене тоже работает. Если вас не затруднит, приведите конкретные факты неготовности и ограниченности проекта, чтобы не быть голословным.
Еще не совсем понял смысл вашег высказывания про текущие реализации и «контрбуцию» — что вы имели в виду?
Модули — это все же вещь в себе. Да, конечно же, ими можно реализовать почти все что угодно. Технически. Но организационно лишь полтора-два дистрибутива (RedHat, Oracle, вроде и все) могут позволить себе поддерживать версию ядра отличную от того, что есть на Kernel.org.
Во всех других дистрибутивах поддержка ядра выглядит так:
1) Берем ядро x.y.z с kernel.org
2) Следим за патчами для ядра x.y.z и более старших на kernel.org и активно их применяем
Как видите, варианта «идем на сайт xxx yyy zzz», там берем код, адаптируем его под нужды нашей системы, вливаем. Потому что это крайне и крайне затратно, а также требует ресурс для всеобъемлющего тестирования функционала, что в свою очередь подразумевает наличие разработчиков ядра, что недешевое удовольствие.
А вот если фича попадает в ваниальное ядро (upstream), то она почти сразу же попадает во все дистрибутивы. Кроме этого, так как фича «стандартная» и есть везде, то сразу же подтягивается и user space окружение и система интегрируется везде и вся.
Отсюда и следует, что ZFS «модулем» использовать, конечно, можно, но с огромным числом «но».
Про контрибуции и развитие проекта я имел в виду, что пока был жив Sun новые версии ZFS выходили каждые несколько месяцев — ARC, ARC2, ZLOG, RAIDZ2/3. Файловая система жила!
А сейчас у нее три десятка «вендоров», которые максимум осиливают — поменять формат сжатия (FreeBSD) или, например, усилить контроль четности. Вся остальная их работа сводится к тому, что они портируют Sun'овский CDDL'ный код на новое окружение.
Я очень надеюсь, что сообщество OpenZFS решит все эти проблемы и начнет развивать файловую систему. Но тут есть ряд сложностей — нужны умы класса тех, кто создал ZFS (ксати, кто они? А вот все здесь).
Во всех других дистрибутивах поддержка ядра выглядит так:
1) Берем ядро x.y.z с kernel.org
2) Следим за патчами для ядра x.y.z и более старших на kernel.org и активно их применяем
Как видите, варианта «идем на сайт xxx yyy zzz», там берем код, адаптируем его под нужды нашей системы, вливаем. Потому что это крайне и крайне затратно, а также требует ресурс для всеобъемлющего тестирования функционала, что в свою очередь подразумевает наличие разработчиков ядра, что недешевое удовольствие.
А вот если фича попадает в ваниальное ядро (upstream), то она почти сразу же попадает во все дистрибутивы. Кроме этого, так как фича «стандартная» и есть везде, то сразу же подтягивается и user space окружение и система интегрируется везде и вся.
Отсюда и следует, что ZFS «модулем» использовать, конечно, можно, но с огромным числом «но».
Про контрибуции и развитие проекта я имел в виду, что пока был жив Sun новые версии ZFS выходили каждые несколько месяцев — ARC, ARC2, ZLOG, RAIDZ2/3. Файловая система жила!
А сейчас у нее три десятка «вендоров», которые максимум осиливают — поменять формат сжатия (FreeBSD) или, например, усилить контроль четности. Вся остальная их работа сводится к тому, что они портируют Sun'овский CDDL'ный код на новое окружение.
Я очень надеюсь, что сообщество OpenZFS решит все эти проблемы и начнет развивать файловую систему. Но тут есть ряд сложностей — нужны умы класса тех, кто создал ZFS (ксати, кто они? А вот все здесь).
Про модули я вас не понял совсем. При чем тут версии ядра, отличные от ванильного? Ядерный модуль можно загрузить в любое ядро. Драйвера чуть отдельная песня, но реализацию ФС вполне можно сделать «долгоиграющей». Это первое.
Второе. Реально дистрибутивов enterprise уровня два — RHEL/centos и Debian. Решения от IBM и was-Novell не рассматриваю в силу, обычно, сильной специфичности железа. Поэтому эта «проблема» также высосана из пальца, нет её. А все вышеперечисленные — достаточно взрослые мальчики, чтобы обеспечить поддержку нужных фич.
В общем, огромного числа «Но» я не вижу, если честно.
По поводу трех десятков вендоров — так в эту группу входят и разработчики illumos. :)
openzfs портирует на 4 довольно разных платформы, которые несколько чужеродны для zfs, понятно, быстрым процесс не будет. Но на других надежд, похоже, уже нет, «спасибо» oracle.
Zfs достаточно крута. И если порты получатся достаточно хорошие, а этому есть все основания, конкурентов просто не будет.
Второе. Реально дистрибутивов enterprise уровня два — RHEL/centos и Debian. Решения от IBM и was-Novell не рассматриваю в силу, обычно, сильной специфичности железа. Поэтому эта «проблема» также высосана из пальца, нет её. А все вышеперечисленные — достаточно взрослые мальчики, чтобы обеспечить поддержку нужных фич.
В общем, огромного числа «Но» я не вижу, если честно.
По поводу трех десятков вендоров — так в эту группу входят и разработчики illumos. :)
openzfs портирует на 4 довольно разных платформы, которые несколько чужеродны для zfs, понятно, быстрым процесс не будет. Но на других надежд, похоже, уже нет, «спасибо» oracle.
Zfs достаточно крута. И если порты получатся достаточно хорошие, а этому есть все основания, конкурентов просто не будет.
Но организационно лишь полтора-два дистрибутива (RedHat, Oracle, вроде и все) могут позволить себе поддерживать версию ядра отличную от того, что есть на Kernel.org.
вы ставите какие-то странные цели, а потом декларируете сложность их достижения.
А вот если фича попадает в ваниальное ядро (upstream), то она почти сразу же попадает во все дистрибутивы. Кроме этого, так как фича «стандартная» и есть везде, то сразу же подтягивается и user space окружение и система интегрируется везде и вся.
вы, мягко говоря, не правы. в той же 12.04 lts ядро 3.2 и поддерживаться оно будет afaik, до 2017 года.
причём, не правы как в первом утверждении(про сложность поддержки отличного от ваниллы), так и во втором(про быстроту появления фич).
А сейчас у нее три десятка «вендоров», которые максимум осиливают — поменять формат сжатия (FreeBSD) или, например, усилить контроль четности. Вся остальная их работа сводится к тому, что они портируют Sun'овский CDDL'ный код на новое окружение.
тут вы тоже не правы. смотрите:
zfsonlinux сделал фичу
фичу втащили в freebsd-head, попутно улучшив
улучшения из freebsd-head втащили в zfsonlinux
потом оно уехало в illumos(можете сами найти). так что никаких сложностей нет.
код фс общий для illumos/freebsd/linux, изменения кочуют туда-сюда.
Отвечаю на оба комментария, так как они имеют довольно близкий посыл.
Когда я деклариовал, тот или иной недостаток, я старался указывать «почему», спасибо что предоставили конкретные недостатки, поэтому предметно их обсудим.
Вы согласились, что RedHat — ключевой дистрибутив, так же согласились с тем, что Debian — тоже не лыком шит, ок, обсудим их.
Так вот, я абсолютно уверен, что RedHat никогда не добавит ZFS даже модулем, даже в отдельном пакете. Почему? По очень простой причине — пакет в почти 1000 патентов на ZFS, находящийся в руках Oracle. Я не юрист, тем более не ИТ юрист (что несказанно выше и сложне, AFAIK), но можно даже с довольно дилетантской точки зрения предположить, что бодаться с Oracle может быть весьма печально, даже для RedHat. И, к слову, это тоже одна из проблем OpenZFS. Все, кто его использовал кроме Oracle/Sun его лицензировали. И лишь вопрос времени получить суд на того, кто начнет использовать OpenZFS в особо крупном объеме. А сделать, например, ZFS в обход патентов, уверен, нереально, получится BTRFS-2 со всеми ее траблами :)
Debian — очень специфичный дистрибутив и эта специфичность растет из того, что его время жизни около 2х лет, что весьма мало. Иными словами, кто-то очень крупный должен каждые два года синхроинизироваться с версией ядра в Debian и оптимизировать под нее ZFS модули.
Ок, давайте представим текущую картину, какие усилия нужно предпринимать для поддержки ZFS как модуля во всех основных дистрибутивах, используемых сегодня:
1) CentOS/RHEL 6 — ядро 2.6.32 от RedHat
2) Debian 7 — ядро 3.2, почти ванильное
3) Ubuntu 12.04 — ядро 3.8, почти ванильное
4) CentOS/RHEL 7 (выйдет буквально в ближайшие месяцы) — ядро 3.2 от RedHat (стоит отметить, что это ядро и ядро того же Debian 7 — две огромных разницы, разница в коде межды ними, боюсь, за миллионы строк, так что это разные ядра)
5) А еще есть Fedora, с 3.12 ядром и еще много-много других дистрибутивов
Что мы имеем на выходе? А мы имеем необходимость поддержки (на уровне кода) и тщательнейшего тестирования аж 5 версий ядер: 2.6.32/rhel, 3.2/rhel, 3.2, 3.8, 3.12
Какой итог? Итог простой — для этого нужны просто фантастические ресурсы и ОЧЕНЬ много ОЧЕНЬ крутых разработчиков. Сейчас максимум, сколько ядер можно поддерживать одновременно принадлежит RedHat — три ветки, а тут нужно 5. Это чисто технические рассуждения, а не маркетинг, если считаете иначе — приведите свою точку зрения.
«zfsonlinux сделал фичу» — это не фича, это в лучшем случае «минорная» оптимизация. То, что я называю фичами (zil, raidz2, self healing) — я уже говорил, все, что сделало ZFS таким крутым.
Когда я деклариовал, тот или иной недостаток, я старался указывать «почему», спасибо что предоставили конкретные недостатки, поэтому предметно их обсудим.
Вы согласились, что RedHat — ключевой дистрибутив, так же согласились с тем, что Debian — тоже не лыком шит, ок, обсудим их.
Так вот, я абсолютно уверен, что RedHat никогда не добавит ZFS даже модулем, даже в отдельном пакете. Почему? По очень простой причине — пакет в почти 1000 патентов на ZFS, находящийся в руках Oracle. Я не юрист, тем более не ИТ юрист (что несказанно выше и сложне, AFAIK), но можно даже с довольно дилетантской точки зрения предположить, что бодаться с Oracle может быть весьма печально, даже для RedHat. И, к слову, это тоже одна из проблем OpenZFS. Все, кто его использовал кроме Oracle/Sun его лицензировали. И лишь вопрос времени получить суд на того, кто начнет использовать OpenZFS в особо крупном объеме. А сделать, например, ZFS в обход патентов, уверен, нереально, получится BTRFS-2 со всеми ее траблами :)
Debian — очень специфичный дистрибутив и эта специфичность растет из того, что его время жизни около 2х лет, что весьма мало. Иными словами, кто-то очень крупный должен каждые два года синхроинизироваться с версией ядра в Debian и оптимизировать под нее ZFS модули.
Ок, давайте представим текущую картину, какие усилия нужно предпринимать для поддержки ZFS как модуля во всех основных дистрибутивах, используемых сегодня:
1) CentOS/RHEL 6 — ядро 2.6.32 от RedHat
2) Debian 7 — ядро 3.2, почти ванильное
3) Ubuntu 12.04 — ядро 3.8, почти ванильное
4) CentOS/RHEL 7 (выйдет буквально в ближайшие месяцы) — ядро 3.2 от RedHat (стоит отметить, что это ядро и ядро того же Debian 7 — две огромных разницы, разница в коде межды ними, боюсь, за миллионы строк, так что это разные ядра)
5) А еще есть Fedora, с 3.12 ядром и еще много-много других дистрибутивов
Что мы имеем на выходе? А мы имеем необходимость поддержки (на уровне кода) и тщательнейшего тестирования аж 5 версий ядер: 2.6.32/rhel, 3.2/rhel, 3.2, 3.8, 3.12
Какой итог? Итог простой — для этого нужны просто фантастические ресурсы и ОЧЕНЬ много ОЧЕНЬ крутых разработчиков. Сейчас максимум, сколько ядер можно поддерживать одновременно принадлежит RedHat — три ветки, а тут нужно 5. Это чисто технические рассуждения, а не маркетинг, если считаете иначе — приведите свою точку зрения.
«zfsonlinux сделал фичу» — это не фича, это в лучшем случае «минорная» оптимизация. То, что я называю фичами (zil, raidz2, self healing) — я уже говорил, все, что сделало ZFS таким крутым.
Считаю, что то, что уже реализовано саном в ZFS — гигантский прорыв для индустрии, освоить бы сначала то, что есть. Ну добавление LZ4 компрессии, конечно хорошо, дефолтно 4к блоки, тоже несложно. А скажите, пожалуйста, чего ZFS не хватает так чтобы масштаба ZIL или L2ARC?
Это по поводу «недоделанности» ZFS.
По поводу «кому это надо?» и «а контрибьюторы кто?» ответы уже были, в этой системе хранения заинтересованы не только аспиранты из MIT. Деньги вливаются, код пишется, тестов — десятки тысяч, объявлен статус production ready, о чём не раз уже сказали.
Я тоже очень хочу, чтобы за спиной zfs был хозяин уровня оракла, сана или редхата, но пока имеем то, что имеем.
Это по поводу «недоделанности» ZFS.
По поводу «кому это надо?» и «а контрибьюторы кто?» ответы уже были, в этой системе хранения заинтересованы не только аспиранты из MIT. Деньги вливаются, код пишется, тестов — десятки тысяч, объявлен статус production ready, о чём не раз уже сказали.
Я тоже очень хочу, чтобы за спиной zfs был хозяин уровня оракла, сана или редхата, но пока имеем то, что имеем.
Линукс — это очень тесно связанная среда. Как Вы пониамете, те же контейнеры, про которые я уже написал 3 статьи — это вещь, которая требует глубочайшей интеграции в файловую систему.
То есть, невозможно получить полноценную изоляцию файловых иерарзий (mount namespaces), если в коде файловой системы это не обрабатывается. Насколько я помню, cgroups — можно делать модулями ядра, да, но вот namespaces — это крайне ядерный механизм и чтобы его поведение поменять в том или ином случае — нужно много правок.
Тоже самое касается подсистем обеспечения безопасности, тот же SeLinux также требует много поддрежки со стороны файловой системы, а в случае ZFS — у нее много сущностей, для которых ну просто обязательно ввести новый «тип» для SeLinux, так как в текущих ФС аналогов многому просто нет.
Итого, мы получаем, что с одной стороны — модуль позволяет добавить файловую систему в ядро, но он не обеспечит поддержки всех facility (подсистем) ядра.
А далее продолжение — тот же SeLinux требует активной поддрежки со стороны user space, также требуется активная поддержка по поводу утилит управления, которых, к слову, в ZFS больше чем в любой иной файловой системе. Так что задача сводится не только к поддержке модуля ядра для кучи версий ядер, но и поддержке набора утилит управления для тучи ядер.
Это все — был ответ на вопрос «чего не хватает ZFS» :)
Я искренее буду рад, когда ZFS будет хотя бы на каждой третьей машине, но пока, увы, я вижу слишком много преград до наступления этого события.
Да и в целом тренд индустрии такой, что какой бы крутой ФС ни была, будущее за распределенными файловыми системами.
Сейчас мы живем в мире облаков — у нас есть почти ~7 платформ для полной виртуализации (Xen, KVM, XenServer, ESXI, VirtualBox, OracleVM, Hyper-V и прочие), имеем полную поддержку контейнеров в Linux, имеем production-ready поддержку контейнеров в Solaris, имеем активноее развитие контейнеров в FreeBSD.
Но при всем этом базовой ФС многих систем остается ext4 с текущим лимитом размера ФС в смешные 16Тб (RHEL6), в свою очередь RHEL7 предоставляет killer-фичу — размер ext4 до 50Tb, что в свою очередь вопрос даже не завтрашнего дня, а вчерашнего, так как это уже довольно малые цифры. Да и на ext4 такие емкости использовать местами страшно.
То есть получается откровенная нестыковка, мы имеем полную изоляцию памяти, процессора, кучу инновационных технологий по изоляции сетей (vSwitch, DS, QFabric и прочие.), но при этом должны хранить все это дело на старых, централизованных, никак не защищенных от сбоя ФС.
Странное, согласитесь? :)
То есть, невозможно получить полноценную изоляцию файловых иерарзий (mount namespaces), если в коде файловой системы это не обрабатывается. Насколько я помню, cgroups — можно делать модулями ядра, да, но вот namespaces — это крайне ядерный механизм и чтобы его поведение поменять в том или ином случае — нужно много правок.
Тоже самое касается подсистем обеспечения безопасности, тот же SeLinux также требует много поддрежки со стороны файловой системы, а в случае ZFS — у нее много сущностей, для которых ну просто обязательно ввести новый «тип» для SeLinux, так как в текущих ФС аналогов многому просто нет.
Итого, мы получаем, что с одной стороны — модуль позволяет добавить файловую систему в ядро, но он не обеспечит поддержки всех facility (подсистем) ядра.
А далее продолжение — тот же SeLinux требует активной поддрежки со стороны user space, также требуется активная поддержка по поводу утилит управления, которых, к слову, в ZFS больше чем в любой иной файловой системе. Так что задача сводится не только к поддержке модуля ядра для кучи версий ядер, но и поддержке набора утилит управления для тучи ядер.
Это все — был ответ на вопрос «чего не хватает ZFS» :)
Я искренее буду рад, когда ZFS будет хотя бы на каждой третьей машине, но пока, увы, я вижу слишком много преград до наступления этого события.
Да и в целом тренд индустрии такой, что какой бы крутой ФС ни была, будущее за распределенными файловыми системами.
Сейчас мы живем в мире облаков — у нас есть почти ~7 платформ для полной виртуализации (Xen, KVM, XenServer, ESXI, VirtualBox, OracleVM, Hyper-V и прочие), имеем полную поддержку контейнеров в Linux, имеем production-ready поддержку контейнеров в Solaris, имеем активноее развитие контейнеров в FreeBSD.
Но при всем этом базовой ФС многих систем остается ext4 с текущим лимитом размера ФС в смешные 16Тб (RHEL6), в свою очередь RHEL7 предоставляет killer-фичу — размер ext4 до 50Tb, что в свою очередь вопрос даже не завтрашнего дня, а вчерашнего, так как это уже довольно малые цифры. Да и на ext4 такие емкости использовать местами страшно.
То есть получается откровенная нестыковка, мы имеем полную изоляцию памяти, процессора, кучу инновационных технологий по изоляции сетей (vSwitch, DS, QFabric и прочие.), но при этом должны хранить все это дело на старых, централизованных, никак не защищенных от сбоя ФС.
Странное, согласитесь? :)
Я же и говорю тут каждый раз про OpenZFS — «прибито сбоку». Но тот же KVM и тот же Xen так же начинали путь отдельными патчами. Подождём где первее издохнет — в ZFS или у Торвальдса.
Вот тут указаны затраты понесённые на встраивание в линукс, сращивание сущностей и т.п.
Далёкое будушее — возможно. Сейчас надо как-то жить в настоящем. Нету пока таких надёжных, чтобы можно было смело менять то, что есть на них. Долго ещё ждать.
Вот тут готов вам снова указать на ZFS. Её почти невозможно убить. Я пробовал. Мне продали два битых диска на 2ТБ, которые год в зеркале работали. Тормозили, долго резильвились, но, чёрт побери, оно просто работало. Когда удавалось дождаться конца скраба я знал какие именно файлы/снапшоты были повреждены. Я повторяю — оба диска в зеркале были с битыми блоками. Какое стандартное поведение стандартного софт/хард рейда? — «Всё умерло, Хозяин! Данные не спасти! Пока!». Я много наблатыкался с железными промизами с ецц памятью и батарейками, софтварный мдам просто чуть более гибче — можно в любой линукс переткнуть и пробовать восстанавливать.
В моём же случае я по-одному заменил диски на новые небитые, лишился нескольких старых снапшотов и у меня чистый
Это все — был ответ на вопрос «чего не хватает ZFS» :)
Вот тут указаны затраты понесённые на встраивание в линукс, сращивание сущностей и т.п.
Да и в целом тренд индустрии такой, что какой бы крутой ФС ни была, будущее за распределенными файловыми системами.
Далёкое будушее — возможно. Сейчас надо как-то жить в настоящем. Нету пока таких надёжных, чтобы можно было смело менять то, что есть на них. Долго ещё ждать.
никак не защищенных от сбоя ФС.
Вот тут готов вам снова указать на ZFS. Её почти невозможно убить. Я пробовал. Мне продали два битых диска на 2ТБ, которые год в зеркале работали. Тормозили, долго резильвились, но, чёрт побери, оно просто работало. Когда удавалось дождаться конца скраба я знал какие именно файлы/снапшоты были повреждены. Я повторяю — оба диска в зеркале были с битыми блоками. Какое стандартное поведение стандартного софт/хард рейда? — «Всё умерло, Хозяин! Данные не спасти! Пока!». Я много наблатыкался с железными промизами с ецц памятью и батарейками, софтварный мдам просто чуть более гибче — можно в любой линукс переткнуть и пробовать восстанавливать.
В моём же случае я по-одному заменил диски на новые небитые, лишился нескольких старых снапшотов и у меня чистый
zpool status! Все почти два терабайта данных остались живы!Но при всем этом базовой ФС многих систем остается ext4 с текущим лимитом размера ФС в смешные 16Тб (RHEL6), в свою очередь RHEL7 предоставляет killer-фичу — размер ext4 до 50Tb, что в свою очередь вопрос даже не завтрашнего дня, а вчерашнего, так как это уже довольно малые цифры. Да и на ext4 такие емкости использовать местами страшно.
XFS as default in EL7
впрочем, кто следит за развитием файловых систем в linux врядли удивился, т.к. Dave Chinner очень много сделал как для самой xfs(а работает он в redhat), так и для других файловых систем.
если кто не знает, это он в последних релизах ускорил fsync на порядок для некоторых ситуаций.
Вообще, всем стоит посмотреть вот этот его доклад на linuxconf.au 2012
По поводу XFS, есть чудесное обсуждение на LWN как раз этой новости. Там указывается на очень большое число «но», заставляющих очень сильно подумать о том, что стоит ли вообще уходить с надежной-стабильной-вечной ext3/ext4.
Другая сторона вопроса, когда доходит до реальной эксплуатации. Стоит ли заменять работающую на тысячах физических машин ext3/ext4 на XFS, суляющую в общем-то не шибко радикальные преимущества?
Другая сторона вопроса, когда доходит до реальной эксплуатации. Стоит ли заменять работающую на тысячах физических машин ext3/ext4 на XFS, суляющую в общем-то не шибко радикальные преимущества?
>Там указывается на очень большое число «но», заставляющих очень сильно подумать о том, что стоит ли вообще уходить с надежной-стабильной-вечной ext3/ext4.
стабильность и надежность ext3/ext4 — миф. ext3 — тормоз. жуткий тормоз и пережиток из прошлого.
с ext4 ситуация чуть лучше(о, там появились экстенты), но вот число inode там по-прежнему задается при создании фс, по-прежнему нужен fsck и проч-проч.
у ext4 по-прежнему проблемы с производительностью(многие операции упираются в журнал), она генерирует больше iops на одинаковых с xfs паттернах. это если не вспоминать про отсутствие средств диагностики у ext4(вот банальную фрагментацию фс как на ней посмотреть?) и лечения(да, в xfs есть онлайн-дефраг).
отдельные фишки, вроде realtime subvolume нужны единицам, но всё-таки тоже иногда надо.
у меня пара небольших стораджей на 20Тб, которые всегда заняты на 95%, там ~ 6-8млн файлов(размером от 4кб до 16Мб), бывают шквалы записи по 700-900Мб/с, чтение/запись ближе к линейному. и в таком режим оно живёт уже третий год.
там раньше была ext4 и чего я только не пытался тюнить.
но эта цифра — результат переписывания приложения с целью создания тепличных для фс условий(пишем только когда знаем конечный размер файла). не всегда есть возможность такой оптимизации.
раньше фрагментация была 30-40% и всё так же работало. ext4 в тех же условиях ставила всё колом(здравствуй jbd2 в iotop).
Ric Wheeler (who wrote the paper) is the architect/manager for Red Hat's file system team and was personally involved in choosing XFS as the default. In addition, Red Hat Storage (when Ric managed that team) followed many storage partners and mandated over a year ago already that XFS would be the only file system supported in Red Hat Storage 2.0.
стабильность и надежность ext3/ext4 — миф. ext3 — тормоз. жуткий тормоз и пережиток из прошлого.
с ext4 ситуация чуть лучше(о, там появились экстенты), но вот число inode там по-прежнему задается при создании фс, по-прежнему нужен fsck и проч-проч.
у ext4 по-прежнему проблемы с производительностью(многие операции упираются в журнал), она генерирует больше iops на одинаковых с xfs паттернах. это если не вспоминать про отсутствие средств диагностики у ext4(вот банальную фрагментацию фс как на ней посмотреть?) и лечения(да, в xfs есть онлайн-дефраг).
отдельные фишки, вроде realtime subvolume нужны единицам, но всё-таки тоже иногда надо.
Другая сторона вопроса, когда доходит до реальной эксплуатации. Стоит ли заменять работающую на тысячах физических машин ext3/ext4 на XFS, суляющую в общем-то не шибко радикальные преимущества?
у меня пара небольших стораджей на 20Тб, которые всегда заняты на 95%, там ~ 6-8млн файлов(размером от 4кб до 16Мб), бывают шквалы записи по 700-900Мб/с, чтение/запись ближе к линейному. и в таком режим оно живёт уже третий год.
там раньше была ext4 и чего я только не пытался тюнить.
xfs_db> frag
actual 1804489, ideal 1786692, fragmentation factor 0.99%
но эта цифра — результат переписывания приложения с целью создания тепличных для фс условий(пишем только когда знаем конечный размер файла). не всегда есть возможность такой оптимизации.
раньше фрагментация была 30-40% и всё так же работало. ext4 в тех же условиях ставила всё колом(здравствуй jbd2 в iotop).
Миф или нет — решает каждый сам, у меня нет выборки по XFS, зато есть выборка по >1000 физических машин с ext4 и в разы больше в виртуальном окружении, где повреждений по причинам отличным от аппаратных проблем (память, битые диски, сбои RAID) не было никогда.
Скорость — безусловно, важный показатель, но файловая система в первую очередь должна качественно и максимально надежно хранить предоставленные ей данные, ext4 с этим справляется и при этом обеспечивает приемлемую скорость.
Конечно же, инженеры RedHat заслуживают уважения, но каждый должен отдавать себе отчет, прежде чем бездумно верить умным, но все же таким же как он сам людям (которым в свою очередь свойственны ошибки).
Тут недавно не менее крутые Linux вендоры (SUSE), заявили, что Btrfs — продакшен реди, «With SUSE Linux Enterprise 11 SP2, the btrfs file system joins ext3, reiserfs, xfs and ocfs2 as commercially supported file systems.» © release notes SLES 11-SP2 А утверждение, что Btrfs — стабильна я даже комментировать отказываюсь.
Скорость — безусловно, важный показатель, но файловая система в первую очередь должна качественно и максимально надежно хранить предоставленные ей данные, ext4 с этим справляется и при этом обеспечивает приемлемую скорость.
Конечно же, инженеры RedHat заслуживают уважения, но каждый должен отдавать себе отчет, прежде чем бездумно верить умным, но все же таким же как он сам людям (которым в свою очередь свойственны ошибки).
Тут недавно не менее крутые Linux вендоры (SUSE), заявили, что Btrfs — продакшен реди, «With SUSE Linux Enterprise 11 SP2, the btrfs file system joins ext3, reiserfs, xfs and ocfs2 as commercially supported file systems.» © release notes SLES 11-SP2 А утверждение, что Btrfs — стабильна я даже комментировать отказываюсь.
> Но при всем этом базовой ФС многих систем остается ext4 с текущим лимитом размера ФС в смешные 16Тб (RHEL6)
o_0
Простите, но в «16 TiB» — TiB это НЕ террабайты… чуть побольше. На несколько порядков.
Извините, и мне трудно проследить и остальные ваши мысли, поэтому дискуссию продолжать, наверное, не станем.
o_0
Простите, но в «16 TiB» — TiB это НЕ террабайты… чуть побольше. На несколько порядков.
Извините, и мне трудно проследить и остальные ваши мысли, поэтому дискуссию продолжать, наверное, не станем.
> Простите, но в «16 TiB» — TiB это НЕ террабайты…
Ох. Тут я не прав. =(
Пошел спать.
Ох. Тут я не прав. =(
Пошел спать.
Террабайт — это земляной байт, ибо терра — земля с латыни =) А общий тренд именовать терабайты как тибибайты я не поддерживаю, он мне претит до глубины души :)
Вы говорите «на порядки», но реальная реазница между 1 Тибибайтом и 1 Терабайтом — это около 99 Гб:
Вы говорите «на порядки», но реальная реазница между 1 Тибибайтом и 1 Терабайтом — это около 99 Гб:
perl -e 'print scalar ((1024**4)-(1000**4))/1024/1024/1024'
92
Так вот, я абсолютно уверен, что RedHat никогда не добавит ZFS даже модулем, даже в отдельном пакете.
ну не добавит — и ладно. есть много различных сторонних модулей, некоторые вы вообще никогда не увидите в исходниках(вроде VxFS). какая разница, кто? важно чтобы работало.
Ок, давайте представим текущую картину, какие усилия нужно предпринимать для поддержки ZFS как модуля во всех основных дистрибутивах, используемых сегодня:
1) CentOS/RHEL 6 — ядро 2.6.32 от RedHat
2) Debian 7 — ядро 3.2, почти ванильное
3) Ubuntu 12.04 — ядро 3.8, почти ванильное
4) CentOS/RHEL 7 (выйдет буквально в ближайшие месяцы) — ядро 3.2 от RedHat (стоит отметить, что это ядро и ядро того же Debian 7 — две огромных разницы, разница в коде межды ними, боюсь, за миллионы строк, так что это разные ядра)
5) А еще есть Fedora, с 3.12 ядром и еще много-много других дистрибутивов
ок. «The kernel API changes frequently, version 0.6.2 supports 2.6.26 — 3.11 kernels.» © zfsonlinux
zfsonlinux сделан очень правильно: есть spl(solaris porting layer), абстрагирующий от ядра linux и собственно сам zfs. похожим образом zfs портирована во freebsd.
так что если даже ограничиваться поддержкой — никаких фантастических ресурсов не надо.
(да и проблем с ресурсами у LLNL, где работает Брайан особо нет).
4) CentOS/RHEL 7 (выйдет буквально в ближайшие месяцы) — ядро 3.2 от RedHat (стоит отметить, что это ядро и ядро того же Debian 7 — две огромных разницы, разница в коде межды ними, боюсь, за миллионы строк, так что это разные ядра)
я в курсе. но не 3.2, а 3.10 и проблем с zfs там, afaik, нет.
offtop: Откуда информация про 3.2 в RHEL7. Я думаю, вы сильно ошибаетесь. Версий примерно на 7-8.
Перспективы, я считаю, есть. Я уже гоняю OpenZFS на бэкап-сервере.
Перечислите, пожалуйста, «грабли», возможно это как раз нестыковки идеологий линукса и соляриса.
Из моего скромного опыта лучшего хранилища для стороджа из списка NTFS на динамических томах, ext4/xfs/etc на LVM/mdam и zpool&zfs лучшее — именно zfs. Я не трогал вафлю нетаппа или фсяческие гридфс, это немного не тот уровень.
Из повседневного использования для SOHO лучше zfs нет ничего, я проверял.
Перечислите, пожалуйста, «грабли», возможно это как раз нестыковки идеологий линукса и соляриса.
Из моего скромного опыта лучшего хранилища для стороджа из списка NTFS на динамических томах, ext4/xfs/etc на LVM/mdam и zpool&zfs лучшее — именно zfs. Я не трогал вафлю нетаппа или фсяческие гридфс, это немного не тот уровень.
Из повседневного использования для SOHO лучше zfs нет ничего, я проверял.
кстати о бекап серверах, как насчет альтернативных систем — quadstor, opendedup и т.д.? А то надо будет скоро поднимать серверок на примерно 60Тб, и очень нужна дедупликация
Всё же зависит от необходимого SLA.
У меня запросы не жизненно важные, и проще и дешевле собрать самому, чем тревожить офис NetApp. Потому я не в курсе какие там решения ещё есть на рынке.
В моём случае дедупликация существует на уровне ZFS. Но RAM под таблицу дублированных блоков надо очень много. Не хватит — будет дёргать своп и умрёт. Методики расчёта есть, полгода взад тут уже был отчёт по использованию ZFS с расчётом необходимого количества ОЗУ для включения дедупликации. У меня пока времени нет, чтобы посчитать вдумчиво и решить надо ли оно мне.
У меня запросы не жизненно важные, и проще и дешевле собрать самому, чем тревожить офис NetApp. Потому я не в курсе какие там решения ещё есть на рынке.
В моём случае дедупликация существует на уровне ZFS. Но RAM под таблицу дублированных блоков надо очень много. Не хватит — будет дёргать своп и умрёт. Методики расчёта есть, полгода взад тут уже был отчёт по использованию ZFS с расчётом необходимого количества ОЗУ для включения дедупликации. У меня пока времени нет, чтобы посчитать вдумчиво и решить надо ли оно мне.
Уже вторая статья серии вышла, а Вы еще тут, присоединяйтесь к обсуждению :)
т.е. уже никаких багов с попыткой установить ядро в контейнер, обновить загрузчик и т.п. уже нету?
просто пишем sudo do-release-upgrade?
больной, не делайте так!
я вот создавал нужные мне эталонные образы через debootstrap и никакого grub и ядра там не было.
Уважаемый комментатор, вы если владеете методикой обновления дистрибутива до актуальной версии, например, Ubuntu Server, внутри контейнера так, чтобы после обновления в контейнере не было мусора, который не нужен контейнеризуемому линуксу, и так, чтобы методика была минимально трудозатратна, вы лучше озвучьте эту методику — толку будет больше, нежели от вашего фамильярства и попыток острить с незнакомыми людьми.
Самый правильный путь, боюсь, переустановить ОС с образа подготовленного командой OpenVZ. Проблема тут не только в том, что «появится мусор», но еще и в том, что часто вносятся «хитрые» патчи (например, в inittab) в сам образ, чтобы совладать с той или иной «фичей» мешающей совместимости дистрибутива с контейнеризацией.
Но в целом обновление схемы Debian 4 — Debian 5 — Debian 6 — Debian 7 внутри контейнера было разломано только в Debian 7 — Debian unstable, по причине явного бага в Debian с системами инициализации. Так что в принципе, не все так страшное. Но с другой стороны — с Ubuntu под виртуализацией проблем ну очень много, виной тому стахановские темпы их разработки и то, что они опираются на фичи новых ядер, а тут OpenVZ поспеть не может.
Но в целом обновление схемы Debian 4 — Debian 5 — Debian 6 — Debian 7 внутри контейнера было разломано только в Debian 7 — Debian unstable, по причине явного бага в Debian с системами инициализации. Так что в принципе, не все так страшное. Но с другой стороны — с Ubuntu под виртуализацией проблем ну очень много, виной тому стахановские темпы их разработки и то, что они опираются на фичи новых ядер, а тут OpenVZ поспеть не может.
Уважаемый комментатор, вы если владеете методикой обновления дистрибутива до актуальной версии
если я вижу что-то действительно интересное — я пишу заметки на opennet.ru
но описывать очевидные вещи смысла не вижу совсем.
ваша проблема не техническая, она — административная.
У вас фирменная фотка так себе. Видно ребра жесткости;)
>> На данный момент в мире насчитывается более 25 тысяч серверов
Это те кто решил включить стучалку. К тому же тут не учитывается платная версия, где ровно те же контейнеры с рядом дополнительных фич, реализованных в дополнительных тулзах и кернельных модулях. Я бы поставил, что реально серверов на порядок больше, хотя…
Это те кто решил включить стучалку. К тому же тут не учитывается платная версия, где ровно те же контейнеры с рядом дополнительных фич, реализованных в дополнительных тулзах и кернельных модулях. Я бы поставил, что реально серверов на порядок больше, хотя…
Не нашел упоминаний о userns, который относительно недавно появился в ядре и сильно улучшил безопасность контейнеров.
Можете дать ссылку, где про это можно почитать?
Про них есть в статье, на которую я давал ссылку при описании namespaces: http://lwn.net/Articles/531114/
Честно говоря, я их опустил по причине, что в OpenVZ, как я понял, их пока нету в стабильном, а описание было общее для конетйнеров ядра и OpenVZ, а так я бы ушел в специфику OpenVZ, которая рассматривается в следующей статье.
Кстати, неплохая идея для статьи, как соорудить контейнер с помощью unshare, nsenter, pivot_root. Сразу будет +100 к понимаю контейнеров.
Спасибо, отличная статья!
Пользуясь случаем, не могу не задать офтопный вопрос, который, возможно, интересует не только меня.
Вы не планируете запустить тариф типа 200MB 1.4€? Аналогичные тарифы очень распространены в Европе (например www.bhost.net/), а в штатах всё ещё круче (http://serverdragon.com/openvz.php — 64MB за $9.99 в год — 0.6€ в месяц).
Ведь не всем же нужен LAMP, многие не отказались бы от места под iodine или что-то в этом духе.
Пользуясь случаем, не могу не задать офтопный вопрос, который, возможно, интересует не только меня.
Вы не планируете запустить тариф типа 200MB 1.4€? Аналогичные тарифы очень распространены в Европе (например www.bhost.net/), а в штатах всё ещё круче (http://serverdragon.com/openvz.php — 64MB за $9.99 в год — 0.6€ в месяц).
Ведь не всем же нужен LAMP, многие не отказались бы от места под iodine или что-то в этом духе.
Спасибо за теплый отзыв! :)
Новые тарифы мы планируем, следите за новостями, запуск тарифов будет буквально в ближайшие сутки.
Новые тарифы мы планируем, следите за новостями, запуск тарифов будет буквально в ближайшие сутки.
Давно меня интересовал вопрос про openvz, использую много где на базе proxmox. Можно ли подключиться к консоли опенвз? А то средства проксмокс почему то это не позволяют, хотя через тот же vnс легко цепляются в kvm.
Можно, но требуется OpenVZ ядро от RHEL6, так как только в нем будет работать vzctl console.
Чтобы воспользоваться vzctl console нужно по меньшей мере два окна терминала, в первом делаем:
А во втором, например, инициируем перезапуск этого контейнера:
В итоге получим примерно такую картинку:
Чтобы воспользоваться vzctl console нужно по меньшей мере два окна терминала, в первом делаем:
vzctl console 19458
Attached to CT 19458 (ESC . to detach)
А во втором, например, инициируем перезапуск этого контейнера:
vzctl restart 19458
В итоге получим примерно такую картинку:
А то средства проксмокс почему то это не позволяют,
А как же кнопка Console, которая запускает java-плагин?
Кто-нибудь сравнивал openVZ в RHEL/CentOS и Debian? Действительно ли Debian отстает от них?
Сложный вопрос Вы задаете, потому что в Debian начианая с 7й версии (Wheezy) OpenVZ отсутствует в пакетной базе. Но при этом его возможно поставить из репозитория с OpenVZ.org вот по этому руководству.
В итоге Вы получите точь-в-точь ту же версию OpenVZ ядра и всех утилит, что и на RHEL/CentOS. Разве что стоит сделать поправку, что новые OpenVZ в Debian репозитории появляются с определенной задержкой.
Но в целом от себя я рекомендую под OpenVZ использовать исключительно CentOS, так как это основная ветка разработки и используется родное для дистрибутива ядро.
В итоге Вы получите точь-в-точь ту же версию OpenVZ ядра и всех утилит, что и на RHEL/CentOS. Разве что стоит сделать поправку, что новые OpenVZ в Debian репозитории появляются с определенной задержкой.
Но в целом от себя я рекомендую под OpenVZ использовать исключительно CentOS, так как это основная ветка разработки и используется родное для дистрибутива ядро.
Спасибо за ответ.
Почему я спрашивал, потому что я на серверах использую именно Debian, за неимением средств на лицензию RHEL и урезанные репозитории (как мне кажется) в CentOS.
Плюс, в университете будем внедрять новый курс, скорее всего будет связано и с openVZ.
Поэтому с удовольствием читаю ваши статьи. Пишите еще!
Почему я спрашивал, потому что я на серверах использую именно Debian, за неимением средств на лицензию RHEL и урезанные репозитории (как мне кажется) в CentOS.
Плюс, в университете будем внедрять новый курс, скорее всего будет связано и с openVZ.
Поэтому с удовольствием читаю ваши статьи. Пишите еще!
Тогда следите за публикациями, если объединить обе части данной публикации (эту и следующую) получиться неплохое введение в курс :) А курс по OpenVZ можно сделать открытым ^_^
Я сталкивался с vz under debian 5/6 аж прям уже в продакшне. Никаких существенных отклонений (да и вообще отклонений) не обнаружено, единственное «но» это апдейты на репозиториях, которые чем дальше, тем больше отстают от ветки rhel'а. С другой стороны, с учетом дебиановской надежности без апдейтов вообще — не так и критично.
Так солидарен с автором: centos primary, но если есть уже debian, преград не вижу вообще никаких.
Так солидарен с автором: centos primary, но если есть уже debian, преград не вижу вообще никаких.
Кстати, хотел поинтересоваться: вам не доводилось сталкиваться с Virtuozzo for Windows?
К сожалению, тут ничего сказать не могу, разве что оно для Windows 2012 пока еще в бете — http://www.parallels.com/products/parallels-containers-windows/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Контейнеризация на Linux в деталях — LXC и OpenVZ. Часть 1