в случае с джеластиком — это не вариант, контейнеры ведь катаются из одной железяки на другую, потому жесткая привязка к хардварной ноде — не очень хорошее решение
сделайте 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
а вот давайте проведем простой эксперимент.
вечерком обязательно попробую как доберусь домой ;)
вы не могли бы пояснить, что значит «на внешнем уровне запрашивают»?
ок, попробую пояснить:
если я нахожусь внутри контейнера и запрашиваю файл вот так:
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 вам не скажет где он используется еще
вот потому и на «внешнем уровне»
когда несколько контейнеров на внешнем уровне запрашивают один и тот же системный файл c хост-машины
что значит «на внешнем уровне»?
ведь у контейнеров общее ядро(а значит, общие page cache и dentry cache, драйвера итп).
и что, что у них общее ядро? я ведь не о модулях адра говорил, в контейнерах можно крутить разные дистрибутивы систем, при этом каждый дистрибутив будет иметь вагон своих собственных системных либ, которые будут загружены в память как совершенно разные экземпляры, если конечно эти либы разные.
Вас наверное немного запутала моя фраза «один и тот же системный файл», здесь правильнее бы конечно было бы сказать «такой же точно системный файл». Хотя в случае с виртуоззой и vzfs это таки будет один и тот же файл, т.к. эти либы будут скорее всего частью остемлейта ;)
ragus
если я не ошибаюсь, prefetcher — исключительно виндовая фича (http://en.wikipedia.org/wiki/Prefetcher), в unix системах есть аналог readahead (http://en.wikipedia.org/wiki/Readahead), и то, к системам виртуализации это не имеет никакого отношения,
которые чаще всего запрашиваются разными контейнерами
читайте внимательнее пожалуйста пост, здесь же имеют ввиду случай, когда несколько контейнеров на внешнем уровне запрашивают один и тот же системный файл c хост-машины, а не одно приложение внутри контейнера
Пытался настроить свою тайм-машину лить в их облако по webdav и частично даже получилось, правда минут через 10 бекапа тайм-машина вылетает, скорее всего связано с лимитом на размер одного файла, хотя если для бекапа использовать что-то другое (аля bacula), можно криптоконтейнер бить на мелкие куски и достойно себе бекапиться.
Вот что малость настораживает:
— если учесть, что космос начинается только на высоте около 100км над уровнем моря (линия Кармана), то высота всего в 21км — далеко не фонтан, или это уже будет полет в «недокосмос»…
Где-то что-то подобное я уже слышал, возможно кто-то вспоминит проект OLPC (http://ru.wikipedia.org/wiki/One_Laptop_Per_Child). Еще тогда, правда другая компания, обещали простые ноуты по цене в 100$, прошло много лет, но ноутбуков по 100$ так и не появилось, правда появились немного другие, цена которые была за 300$. Возмонжо у корпорации добра что-то получится, будем надеяться.
Вообще NGINX тоже умеет определять или живой бекенд, например в случае с HTTPS вот так:
check interval=3000 rise=2 fall=5 timeout=1000 type=ssl_hello;
с другой стороны, haproxy дает информацию в info-страничке о состоянии бекенда даже если на него совсем нет конектов (кроме тестовых), что несомненно тоже довольно удобно.
я даже больше того скажу, если человек купил себе XBOX (вместе со встроеным в него приводом) — он должен иметь право делать с ним ВСЕ что захочет, так как его девайс уже ЕГО, хоть красить его в красный цвет, хоть сжечь, хоть прошивать сколько угодно.
Это аналогично тому, что вы купили телевизор марки «Philips» и спустя некоторое время перекрасили его в другой цвет краской. Вопрос: какое дело компании Philips или государству к тому, что человек, собственник телевизора, его перекрасил по своему усмотрению.?
тогда я вам скажу, что вы просто никогда не работали с виртуоззой, такого эффекта, увы, не будет :)
[root@stage-hn1 ~]# chroot /vz/private/7777777/fs/root/ chroot: failed to run command `/bin/bash': Exec format errorвечерком обязательно попробую как доберусь домой ;)
ок, попробую пояснить:
если я нахожусь внутри контейнера и запрашиваю файл вот так:
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 вам не скажет где он используется еще
вот потому и на «внешнем уровне»
и что, что у них общее ядро? я ведь не о модулях адра говорил, в контейнерах можно крутить разные дистрибутивы систем, при этом каждый дистрибутив будет иметь вагон своих собственных системных либ, которые будут загружены в память как совершенно разные экземпляры, если конечно эти либы разные.
Вас наверное немного запутала моя фраза «один и тот же системный файл», здесь правильнее бы конечно было бы сказать «такой же точно системный файл». Хотя в случае с виртуоззой и vzfs это таки будет один и тот же файл, т.к. эти либы будут скорее всего частью остемлейта ;)
есть понятие харднода, но суть не в этом
сам термин «профетч» не юниксовый, вот только на этом и сделал акцент ;)
если я не ошибаюсь, prefetcher — исключительно виндовая фича (http://en.wikipedia.org/wiki/Prefetcher), в unix системах есть аналог readahead (http://en.wikipedia.org/wiki/Readahead), и то, к системам виртуализации это не имеет никакого отношения,
читайте внимательнее пожалуйста пост, здесь же имеют ввиду случай, когда несколько контейнеров на внешнем уровне запрашивают один и тот же системный файл c хост-машины, а не одно приложение внутри контейнера
— если учесть, что космос начинается только на высоте около 100км над уровнем моря (линия Кармана), то высота всего в 21км — далеко не фонтан, или это уже будет полет в «недокосмос»…
www.thg.ru/technews/images/olpc_xo-290407.jpg
в любом случае к отметке в 100$ они так и не дошли…
check interval=3000 rise=2 fall=5 timeout=1000 type=ssl_hello;
с другой стороны, haproxy дает информацию в info-страничке о состоянии бекенда даже если на него совсем нет конектов (кроме тестовых), что несомненно тоже довольно удобно.
NGINX тоже умеет балансировать TCP, причем делает это довольно хорошо
github.com/yaoweibin/nginx_tcp_proxy_module
Это аналогично тому, что вы купили телевизор марки «Philips» и спустя некоторое время перекрасили его в другой цвет краской. Вопрос: какое дело компании Philips или государству к тому, что человек, собственник телевизора, его перекрасил по своему усмотрению.?
Вобщем как обычно, маразм крепчал…