Комментарии 30
>Наши ближайшие конкуренты OpenShift и CloudFoundry уже по одному разу перепроектировали свои решения внедряя слой псевдо-контейнерной виртуализации cgroup + SElinux и Warden соответственно.
cgroups(а не cgroup) не имеют отношения к контейнерам вообще.
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?
cgroups не имеет отношения к контейнерам просто потому что контейнеры — это просто набор флажков( CLONE_NEWNET, CLONE_NEWPID etc) для вызова clone().
>Чтобы сделать использование ресурсов еще более рациональным, Jelastic использует механизм дедупликации памяти. Этот механизм собирает статистику о файлах, которые чаще всего запрашиваются контейнером, и помещает такие файлы в кэш-память.
что-то я не понял. речь про дедупликацию памяти, а в итоге речь про дисковые операции. wtf?
Спасибо. Немного изменили формулировку, надеюсь так стало понятнее. Ссылка по теме вопроса Дедупликация данных.
Данный метод обычно используется для оптимизации использования дискового пространстваВ Jelastic этот механизм используется также для оптимизации операций ввода-вывода.
>В Jelastic этот механизм используется также для оптимизации операций ввода-вывода.
>Этот механизм собирает статистику о файлах, которые чаще всего запрашиваются контейнером, и помещает такие файлы в кэш-память.
это обыкновенный prefetch.
>Этот механизм собирает статистику о файлах, которые чаще всего запрашиваются контейнером, и помещает такие файлы в кэш-память.
это обыкновенный 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), в 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 хост-машины
вы не могли бы пояснить, что значит «на внешнем уровне запрашивают»?
я где-то выше писал про 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
это и есть реальный файл.
сделайте 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
соберите вот это: 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).
А далее начинаются сложности, и рассуждения далее могут быть местами ошибочны, так как они основны на беглом прочтении кода OpenVZ патча.
Но если кратко далее алгоритм ведет себя так — если происходит попытка открытия файла, для которого у нас есть ключевая сумма в inode, мы обращаемся к таблице, где у нас содержатся все ключевые суммы уже загруженных каким-либо иным контейнером библиотек и если мы находим файл с таким же хеэшем, то просто подменяем попытку открытия на этот самый файл.
Также подобные «общие» файлы выносятся (тупо копируются) в отдельную файловую иерархию /vz/pfcache. За счет этого множественные загрузки данных бинарных файлов в память из разных контейнеров приводят к тому, что они занимают меньше места в оперативной памяти и кэшируются (в страничном кэше Linux) ровно один раз. Что дает очень весомый профит в экономии памяти и работе системы в целом. Причем, наибольшей экономии удается добиться именно в случае, когда все контейнеры максимально унифицированы по версиям ПО/дистрибутивам.
Это довольно грамотный и умный механизм, суть которой сводится к хешированию (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) ровно один раз. Что дает очень весомый профит в экономии памяти и работе системы в целом. Причем, наибольшей экономии удается добиться именно в случае, когда все контейнеры максимально унифицированы по версиям ПО/дистрибутивам.
круто! спасибо за столь детальный комментарий.
спасибо за развернутый комментарий!
сразу видно когда человек понимает о чем пишет :)
меня смутил исходный комментарий
>В Jelastic этот механизм используется также для оптимизации операций ввода-вывода.
т.к. никакой оптимизаций ввода-вывода не происходит и для чтения inode всё равно будет seek по диску.
pfcache больше похож на uksm, только оперирующий файлами(а не страницами, как uksm).
Кстати, а возможно ли лимитировать в Virtuozzo контейнер по iops'ам?
сразу видно когда человек понимает о чем пишет :)
меня смутил исходный комментарий
>В Jelastic этот механизм используется также для оптимизации операций ввода-вывода.
т.к. никакой оптимизаций ввода-вывода не происходит и для чтения inode всё равно будет seek по диску.
pfcache больше похож на uksm, только оперирующий файлами(а не страницами, как uksm).
Кстати, а возможно ли лимитировать в Virtuozzo контейнер по iops'ам?
Честно говоря, у меня почти нет опыта работы с Virtuozzo, все что я говорил из опыта работы с Parallels Cloud Server. Могу ответить про него =)
«никакой оптимизаций ввода-вывода не происходит и для чтения inode всё равно будет seek по диску» — почему, мы же не читаем блоки, inode почти всегда находится в памяти, а в блоки нам ходить не нужно. Так что в худшем случае мы чиатем лишь очень маленький айнод в начале диска, а в лучшем — читаем его прямо с памяти.
А вот с uKSM не работал, ничего сказать не могу.
Лимит по IOPS там есть, кроме того он теперь есть даже в OpenVZ.
«никакой оптимизаций ввода-вывода не происходит и для чтения inode всё равно будет seek по диску» — почему, мы же не читаем блоки, inode почти всегда находится в памяти, а в блоки нам ходить не нужно. Так что в худшем случае мы чиатем лишь очень маленький айнод в начале диска, а в лучшем — читаем его прямо с памяти.
А вот с uKSM не работал, ничего сказать не могу.
Лимит по IOPS там есть, кроме того он теперь есть даже в OpenVZ.
Называть то, что есть в Virtuozzo дедупликацией абсолютно некорректно, так как ни о какой дедупликации файлов клиента речи просто не идет.
Уплотняется (я бы скорее именно так называл этот механизм потому что весь плюс решения в том, что экономится объем ОЗУ, но не объем дисковой памяти) только системная часть — то есть бинарнные файлы, библиотеки, которые были в шаблоне ОС из которого был собран контейнер.
Но, потворюсь, если я загружу 100000 копий одного и того же файла, допустим, .html, то на диске так и будет хранится ровно миллион копий, не больше, не меньше :)
А вообще зовется оно pfcache и есть в открытом ядре OpenVZ (правда, если хотите поддержку в user space — надо ее проработать самостоятельно).
Уплотняется (я бы скорее именно так называл этот механизм потому что весь плюс решения в том, что экономится объем ОЗУ, но не объем дисковой памяти) только системная часть — то есть бинарнные файлы, библиотеки, которые были в шаблоне ОС из которого был собран контейнер.
Но, потворюсь, если я загружу 100000 копий одного и того же файла, допустим, .html, то на диске так и будет хранится ровно миллион копий, не больше, не меньше :)
А вообще зовется оно pfcache и есть в открытом ядре OpenVZ (правда, если хотите поддержку в user space — надо ее проработать самостоятельно).
Я не согласен, что cgroups не имеет отношения к конейнерам. Контейнеры — это namespace + cgroups. Конечно же, namespace можно использовать отдельно, например, для создания «надежного» chroot, но какой толк в создании контейнера без лимитов по cpu/памяти и прочим ресурсам? Да никакого, это уже будут не контейнеры, а просто «некая изоляция». Вот именно по этой причине я бы не отрывал сгрупп от контейнеров, это их неотъемлемый атрибут.
Практичный вопрос, который очень важен для нас, но никто пока что из хостеров Jelastic нам так и не смог ответить:
Для нашего веб приложения (которое деплоится как war + DB) необходимо также уметь открывать порт для подключения к нему напрямую устройств из сети. На один открытый порт может приходится порядка 10к подключений. Такое можно организовать на Jelastic?
Давно приглядываемся к elastic, но ваш сайт оставляет желать лучшего: список хостеров неполный, ссылки кое-какие битые, хостеры часто не имеют описания расценок и т.п. Путь от красивых архитектурных слайдов, до реального выбора хостера с хорошей и грамотной поддержкой — весьма тернист…
Также интересно было бы узнать порядок стоимости проекта внедрения 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, но так в итоге и не нашел в чем ее суть и примерные отчисления.
Объясните, пожалуйста :)
Текущая схема лицензирования 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, они смогут дать самую свежую информацию по ценам.
Для private cloud применяется другой подход к ценообразованию. Более привычный для enterprise сектора — лицензия за начисляется по кол-ву серверов в кластере. Кстати с 1 мая 2013 года многое изменилось по ценовой политике в лучшую сторону для партнеров/клиентов. Рекомендую обратиться в отдел продаж sales@jelastic.com, они смогут дать самую свежую информацию по ценам.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура кластера Jelastic: высокоуровневый обзор системы Platform-as-Infrastructure