Как стать автором
Обновить

Комментарии 30

>Наши ближайшие конкуренты OpenShift и CloudFoundry уже по одному разу перепроектировали свои решения внедряя слой псевдо-контейнерной виртуализации cgroup + SElinux и Warden соответственно.

cgroups(а не cgroup) не имеют отношения к контейнерам вообще.
косвенно имеет ru.wikipedia.org/wiki/Cgroups
Одна из целей создания cgroups была предоставить единый интерфейс к целому спектру функциональности, начиная с контроля единичного процесса (а-ля nice) до полной виртуализации на уровне системы operating system-level virtualization (как у OpenVZ, Linux-VServer, LXC).

Cgroups управляются различными способами:… Косвенно через другой софт, использующий cgroups, например виртуализатор Linux Containers (LXC), libvirt, systemd, и Open Grid Scheduler/Grid Engine.
cgroups — это просто счётчики/лимиты на разные ресурсы + иерархия процессов. вот упомянутый выше systemd каждый сервис сажает в отдельную cgroup.

cgroups не имеет отношения к контейнерам просто потому что контейнеры — это просто набор флажков( CLONE_NEWNET, CLONE_NEWPID etc) для вызова clone().

>Чтобы сделать использование ресурсов еще более рациональным, Jelastic использует механизм дедупликации памяти. Этот механизм собирает статистику о файлах, которые чаще всего запрашиваются контейнером, и помещает такие файлы в кэш-память.

что-то я не понял. речь про дедупликацию памяти, а в итоге речь про дисковые операции. wtf?
Спасибо. Немного изменили формулировку, надеюсь так стало понятнее. Ссылка по теме вопроса Дедупликация данных.
Данный метод обычно используется для оптимизации использования дискового пространства
В Jelastic этот механизм используется также для оптимизации операций ввода-вывода.
>В Jelastic этот механизм используется также для оптимизации операций ввода-вывода.

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

это обыкновенный prefetch.
ragus
если я не ошибаюсь, prefetcher — исключительно виндовая фича (http://en.wikipedia.org/wiki/Prefetcher), в unix системах есть аналог readahead (http://en.wikipedia.org/wiki/Readahead), и то, к системам виртуализации это не имеет никакого отношения,
которые чаще всего запрашиваются разными контейнерами

читайте внимательнее пожалуйста пост, здесь же имеют ввиду случай, когда несколько контейнеров на внешнем уровне запрашивают один и тот же системный файл c хост-машины, а не одно приложение внутри контейнера
если я не ошибаюсь, prefetcher — исключительно виндовая фича (http://en.wikipedia.org/wiki/Prefetcher)


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

например, чем вам POSIX_FADV_WILLNEED не префетч?

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


вообще-то у контейнеров нет понятия «хост-машины».
вообще-то у контейнеров нет понятия «хост-машины».

есть понятие харднода, но суть не в этом

например, чем вам POSIX_FADV_WILLNEED не префетч?

сам термин «профетч» не юниксовый, вот только на этом и сделал акцент ;)
есть понятие харднода, но суть не в этом


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


что значит «на внешнем уровне»?
ведь у контейнеров общее ядро(а значит, общие page cache и dentry cache, драйвера итп).

сам термин «профетч» не юниксовый, вот только на этом и сделал акцент ;)


с чего бы вдруг? наберите в гугле хотя бы «zfs prefetch».
думаю, если покопаться, можно найти упоминание этого слова еще во времена SunOS, когда windows еще просто не существовало.

но это всё лирика. в конце-концов, в системе команд IA-32 есть такая инструкция :)
можете пояснить вот это:

когда несколько контейнеров на внешнем уровне запрашивают один и тот же системный файл c хост-машины


что значит «на внешнем уровне»?
ведь у контейнеров общее ядро(а значит, общие page cache и dentry cache, драйвера итп).


и что, что у них общее ядро? я ведь не о модулях адра говорил, в контейнерах можно крутить разные дистрибутивы систем, при этом каждый дистрибутив будет иметь вагон своих собственных системных либ, которые будут загружены в память как совершенно разные экземпляры, если конечно эти либы разные.
Вас наверное немного запутала моя фраза «один и тот же системный файл», здесь правильнее бы конечно было бы сказать «такой же точно системный файл». Хотя в случае с виртуоззой и vzfs это таки будет один и тот же файл, т.к. эти либы будут скорее всего частью остемлейта ;)
>и что, что у них общее ядро?

я где-то выше писал про page/dentry cache.

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

и? с таким же успехом это можно делать даже в chroot.

>Вас наверное немного запутала моя фраза «один и тот же системный файл»

нет, ни капли. меня запутала ваша фраза

>когда несколько контейнеров на внешнем уровне запрашивают один и тот же системный файл c хост-машины

вы не могли бы пояснить, что значит «на внешнем уровне запрашивают»?
вы не могли бы пояснить, что значит «на внешнем уровне запрашивают»?

ок, попробую пояснить:
если я нахожусь внутри контейнера и запрашиваю файл вот так:
CT-7777777-bash-4.1# ls -la /usr/lib/python2.6/site-packages/yum/failover.py
-rwxr-xr-x 1 root root 3372 Feb 22 2013 /usr/lib/python2.6/site-packages/yum/failover.py
я по факту запрашиваю файл /vz/private/7777777/fs/root/usr/lib/python2.6/site-packages/yum/failover.py, который физически регулярным файлом по сути не является, он есть всего лишь линком на реальный файл, если смотреть на уровне хардноды
[root@stage-hn1 ~]# more /vz/private/7777777/fs/root/usr/lib/python2.6/site-packages/yum/failover.py
////centos/6/x86_64/yum-3.2.29-40.el6.centos.noarch/usr/lib/python2.6/site-packages/yum/failover.py
но вот контейнер об этом совсем «не знает», так вот, этот файл реально могут использовать десятки и сотни контейнеров, физически же он будет одним и тем же, при этом в памяти он будет подгружен тоже ровно один раз, вот-только изнутри контейнера вы никогда об этом не знаете т.к. fd в /proc вам не скажет где он используется еще
вот потому и на «внешнем уровне»
>всего лишь линком на реальный файл

это и есть реальный файл.
сделайте chroot /vz/private/7777777/fs/root
и у вас будет практически такой же эффект.

>но вот контейнер об этом совсем «не знает»

контейнер — это логическая сущность. для ядра процессы внутри контейнера практически ничем не отличаются от процессов вне его. все эти лимиты ubc — это предок cgroups.

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

а вот давайте проведем простой эксперимент.
соберите вот это: code.google.com/p/linux-ftools/

точнее, нам понадобится только fincore & fadvise.

берем на hn создаём файл на 1Гб:
dd if=/dev/urandom of=/vz/private/7777777/fs/root/1gb bs=1M count=1024

внутри контейнера:
fincore --pages=false --summarize --only-cached /1gb
/root/1gb bs=1M count=1024

внутри контейнера:
fincore --pages=false --summarize --only-cached /1gb
fadvise /1gb POSIX_FADV_DONTNEED

на hn:
fincore --pages=false --summarize --only-cached /vz/private/7777777/fs/root/1gb

а вот давайте проведем простой эксперимент.
соберите вот это: code.google.com/p/linux-ftools/

точнее, нам понадобится только fincore & fadvise.

берем на hn создаём файл на 1Гб:
dd if=/dev/urandom of=/vz/private/7777777/fs/root/1gb bs=1M count=1024

внутри контейнера:
fincore --pages=false --summarize --only-cached /1gb
fadvise /1gb POSIX_FADV_DONTNEED
fincore --pages=false --summarize --only-cached /1gb

на hn:
fincore --pages=false --summarize --only-cached /vz/private/7777777/fs/root/1gb
fadvise /vz/private/7777777/fs/root/1gb POSIX_FADV_WILLNEED

внутри контейнера:
fincore --pages=false --summarize --only-cached /1gb
сделайте chroot /vz/private/7777777/fs/root
и у вас будет практически такой же эффект.


тогда я вам скажу, что вы просто никогда не работали с виртуоззой, такого эффекта, увы, не будет :)
[root@stage-hn1 ~]# chroot /vz/private/7777777/fs/root/ chroot: failed to run command `/bin/bash': Exec format error

а вот давайте проведем простой эксперимент.

вечерком обязательно попробую как доберусь домой ;)
Позволю себе влезть и внести немного ясности, там используется pfcache (доставшийся Jelastic от Parallels Virtuozzo).

Это довольно грамотный и умный механизм, суть которой сводится к хешированию (SHA-1) определенных файлов в папках (стандартно /bin, /lib, /lib64, /opt, /sbin, /usr источник, стр 15) внутри контейнера и сохранению их хэшей в расширенных атрибутах ext4 (xattr).

То есть схема такая:
1) Ставится ОС в контейнер
2) User space демон pfcached забегает в контейнер и прописывает SHA-1 хэши в расширенные атрибуты ext4 для всех файлов в папках /bin, /lib, /lib64, /opt, /sbin, /usr.

Тут стоит обратить внимание, что силами getfattr, setfattr хэши записанные утилитой не обнаружить pfcache, так как используется особенный формат записи аттрибутов — прямо в inode. Но их можно увидеть силами debugfs (pfcache).

[root@fps0 ~]# debugfs /dev/ploop13314p1
debugfs 1.41.12 (17-May-2010)
debugfs:  stat /bin/bash
Inode: 393301   Type: regular    Mode:  0755   Flags: 0x80000
Generation: 2197122146    Version: 0x00000000:00000001
User:     0   Group:     0   Size: 903336
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 1768
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x52d56b41:5e497ed4 -- Tue Jan 14 20:52:17 2014
 atime: 0x52f26e4d:b9948a40 -- Wed Feb  5 21:01:01 2014
 mtime: 0x51e7eb48:00000000 -- Thu Jul 18 17:19:04 2013
crtime: 0x52d56b41:544604d4 -- Tue Jan 14 20:52:17 2014
Size of extra inode fields: 28
Extended attributes stored in inode body: 
  pfcache = "54 e7 9f e6 15 63 f6 f5 d6 7e f6 9d f8 da bd 0f 0e 6c 5f 43 " (20)
EXTENTS:
(0-220): 89344-89564


А далее начинаются сложности, и рассуждения далее могут быть местами ошибочны, так как они основны на беглом прочтении кода OpenVZ патча.

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

Также подобные «общие» файлы выносятся (тупо копируются) в отдельную файловую иерархию /vz/pfcache. За счет этого множественные загрузки данных бинарных файлов в память из разных контейнеров приводят к тому, что они занимают меньше места в оперативной памяти и кэшируются (в страничном кэше Linux) ровно один раз. Что дает очень весомый профит в экономии памяти и работе системы в целом. Причем, наибольшей экономии удается добиться именно в случае, когда все контейнеры максимально унифицированы по версиям ПО/дистрибутивам.
круто! спасибо за столь детальный комментарий.
Вам спасибо, что начали дискуссию про уплотнение памяти pfcache, давно хотел собрать воедино мысли по ней :)
спасибо за развернутый комментарий!
сразу видно когда человек понимает о чем пишет :)

меня смутил исходный комментарий

>В Jelastic этот механизм используется также для оптимизации операций ввода-вывода.

т.к. никакой оптимизаций ввода-вывода не происходит и для чтения inode всё равно будет seek по диску.
pfcache больше похож на uksm, только оперирующий файлами(а не страницами, как uksm).

Кстати, а возможно ли лимитировать в Virtuozzo контейнер по iops'ам?
Честно говоря, у меня почти нет опыта работы с Virtuozzo, все что я говорил из опыта работы с Parallels Cloud Server. Могу ответить про него =)

«никакой оптимизаций ввода-вывода не происходит и для чтения inode всё равно будет seek по диску» — почему, мы же не читаем блоки, inode почти всегда находится в памяти, а в блоки нам ходить не нужно. Так что в худшем случае мы чиатем лишь очень маленький айнод в начале диска, а в лучшем — читаем его прямо с памяти.

А вот с uKSM не работал, ничего сказать не могу.

Лимит по IOPS там есть, кроме того он теперь есть даже в OpenVZ.
Называть то, что есть в Virtuozzo дедупликацией абсолютно некорректно, так как ни о какой дедупликации файлов клиента речи просто не идет.

Уплотняется (я бы скорее именно так называл этот механизм потому что весь плюс решения в том, что экономится объем ОЗУ, но не объем дисковой памяти) только системная часть — то есть бинарнные файлы, библиотеки, которые были в шаблоне ОС из которого был собран контейнер.

Но, потворюсь, если я загружу 100000 копий одного и того же файла, допустим, .html, то на диске так и будет хранится ровно миллион копий, не больше, не меньше :)

А вообще зовется оно pfcache и есть в открытом ядре OpenVZ (правда, если хотите поддержку в user space — надо ее проработать самостоятельно).
да, верно речь идет о дедупликации оперативной памяти
Я не согласен, что cgroups не имеет отношения к конейнерам. Контейнеры — это namespace + cgroups. Конечно же, namespace можно использовать отдельно, например, для создания «надежного» chroot, но какой толк в создании контейнера без лимитов по cpu/памяти и прочим ресурсам? Да никакого, это уже будут не контейнеры, а просто «некая изоляция». Вот именно по этой причине я бы не отрывал сгрупп от контейнеров, это их неотъемлемый атрибут.
ну так и cgoups используются отдельно от контейнеров :)

вообщем, «каждая селедка — рыба. но не каждая рыба — селедка».
Практичный вопрос, который очень важен для нас, но никто пока что из хостеров Jelastic нам так и не смог ответить:

Для нашего веб приложения (которое деплоится как war + DB) необходимо также уметь открывать порт для подключения к нему напрямую устройств из сети. На один открытый порт может приходится порядка 10к подключений. Такое можно организовать на Jelastic?

Давно приглядываемся к elastic, но ваш сайт оставляет желать лучшего: список хостеров неполный, ссылки кое-какие битые, хостеры часто не имеют описания расценок и т.п. Путь от красивых архитектурных слайдов, до реального выбора хостера с хорошей и грамотной поддержкой — весьма тернист…

Также интересно было бы узнать порядок стоимости проекта внедрения jelastic у среднего хостера и у компании для внутренних нужд.
Для нашего веб приложения (которое деплоится как war + DB) необходимо также уметь открывать порт для подключения к нему напрямую устройств из сети. На один открытый порт может приходится порядка 10к подключений. Такое можно организовать на Jelastic?

Вы могли бы прислать детальное описание требований к ресурсам для вашего приложения на почту info@jelastic.com? Уверен в таком случае мы сможем дать точный ответ — можно или нет.

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

ссылки кое-какие битые
Будем признательны за конкретные примеры, если не трудно (можно на этот же адрес info@jelastic.com)

Также интересно было бы узнать порядок стоимости проекта внедрения jelastic у среднего хостера и у компании для внутренних нужд.
Стоимость в разы дешевле чем у наших конкурентов. Ждем Вашего запроса с требованиями к ресурсам, далее мы вас состыкуем с отделом продаж, который предоставит полную информацию по ценам.
Извините, конечно, что лезу в технический пост с финансовыми вопросами. Но хочется прояснить ситуацию, ибо она во многом останавливает меня (и, уверен, не только меня) на пути к тестированию и использованию Jelastic.

Текущая схема лицензирования Jelastic — странна (на момент 1 мая 2013).

Почему? Потому что Вы берете не определенную цену за использование ПО (например, в зависимости от числа аккаунтов, используемой памяти и проч), а берете процент заработанной на Jelastic прибыли. На своем веку я такую схему лицензирования в ИТ вижу первый раз :)

То есть, если я делаю услугу на базе своего оборудования, своей инфраструктуры продаю ее за, например, $10/месяц, то я отдаю Вам 1$ в месяц, все более-менее ок, сумма довольно мала и будет заметная лишь низкомаржинальным компаниям.

Но если же мы делаем серьезную, мощную услугу на дорогом оборудовании и продаем ее за $100 месяц, то мы должны отдавать Вам $20, не слишком ли это круто?

Кроме этого, у Вас ужасающие контракты — аж на 2 или 3 года. Даже очень крупные компании почти никогда не заключает договоры c обязательными платежами более чем на год.

Несколько раз перечитал страницу с предположительно (?) новой схемой ценообразования docs.jelastic.com/ru/pricing-model, но так в итоге и не нашел в чем ее суть и примерные отчисления.

Объясните, пожалуйста :)
Спасибо за вопрос. Текущая модель называется Revenue Sharing. Она довольно распространена в хостинговой индустрии. Ее преимущество в том, что снижается риск для хостера на начальном этапе запуска продукта, так как лицензионные отчисления зависят от наличия «денег в кассе». Это очень удобно при запуске новой линейки продуктов. Далее если объем продаж увеличивается включаются механизмы скидок — больше объем продаж меньше процент revenue sharing. Наша ценовая политика довольно гибкая. Есть и годовые контракты. Суть в том что для более длительных контрактов более выгодные условия.

Для private cloud применяется другой подход к ценообразованию. Более привычный для enterprise сектора — лицензия за начисляется по кол-ву серверов в кластере. Кстати с 1 мая 2013 года многое изменилось по ценовой политике в лучшую сторону для партнеров/клиентов. Рекомендую обратиться в отдел продаж sales@jelastic.com, они смогут дать самую свежую информацию по ценам.
Ох, сделайте хотя бы на сайте визуализацию этой схемы с рычажком на количество продаж, а-то можно убить себе мозг пытаясь визуализировать ее на коленке :)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий