Pull to refresh

Comments 27

Мне кажется, деление на VDS/VPS как разные сущности, несколько не общепринято. Обычно их используют как 100% синонимы, то есть можно увидеть 'VDS на openvz' и 'VPS на xen'е'. Термин VPS вообще более редкий.
Статью писал давно, когда еще не успели их смешать до такой степени…
Насколько я помню, VPS и VDS всегда были синонимами, так скажем 5 лет назад, когда я работал в одной хостинговой компании — точно были. У нас было разграничение лишь в том, что для американцев привычнее понятие VPS, а для европейцев и русских в частности — VDS.
Хм. Значит, это у меня лично в голове всё смешалось. Но у меня чётко в памяти, что N лет назад я встречал их с разделением смысла.
У меня вопрос почти по теме: что такое «облако»? Почему-то для меня облака ассоциируются с неограниченными ресурсами и оплатой за фактическое использование (да, я про Селектел). Однако, всюду встречаются «cloud hostings», где доступны жесткие конфигурации (DigitalOcean как пример). Где правду искать?)
«Облако» по сути — это когда ресурсы не привязаны к жесткому физическому месту.
То есть это облачко, которое летает по небосводу, где может.

По идее HA кластер из двух машин — это уже «Облако». Только такое, бинарное…
Если совсем абстрагироваться от любой конкретики, то идеей «облака» является технологическая простота получения дополнительных ресурсов (то, что в определении называют self-serving) и сразу, как они понадобились (on-demand). А делается это скейлом виртуалки, выделения ей слотов или вообще предоставлением бареметалла (есть такая фича в openstack'е, где для инстансов выделяют реальные сервера «as is» без гипервизора) — это уже специфика конкретного решения.

Это не точная характеристика, но скорее, количественная, переходящая в качественную. Примерно как переслать пакет курьером — это не пакетная передача данных. Слать 10 пакетов в секунду по модему — уже пакетная.
echo «deb repo.psand.net/ wheezy main» > /etc/apt/sources.list.d/psand.list
curl dev.call2ru.com/vs/nss_vserver_64.tar.bz2
curl curl dev.call2ru.com/vs/vserverauth.tar.gz

Левые репозитории, левые ядра, левые какие-то пакеты, ставящиеся через маке-макеинсталл… Автор так и не написал чем это лучше/хуже openvz или lxc. Проще уж проксмокс(или ядро от него) какой-нибудь накатить поверх дебиана.
Можно как-нибудь статью облагородить?
Левые репозитории — из-за выкашивания vserver из стокового debian. До squeeze это было одно из самых положительных качеств — наличие в репе и быстрый запуск. Сейчас стало хуже.
Разницу между решениями напишу, хорошо.
aptitude install linux-image-vserver-3.13-beng util-vserver curl bzip2 # заменить 3.13 на актуальную для вас версию

Разве там нет виртуального пакета, ссылающегося на последнюю версию ядра?
Вот нету. Пока было в дебиане в стоке — было просто установить linux-image-vserver-amd64 и всё.
Хотелось бы сравнения с Docker. Я пока не вижу, чем предложенный вариант лучше решения на Docker.
>> lxc в моём понимании еще не дорос до продакшена
Если сравнивать LXC с vserver, LXC, навскидку, проигрывает в тонкости управления ресурсами, но выигрывает в тонкости управления сетью.
Расскажите, что нового в Linux-VServer за последние несколько лет?
Начали переводить отдельные подсистемы на LXC. Те же resource limit, accounting.
А так… они просто работают, работают хорошо.
Случаев выхода из песочницы, несмотря за несколько взломов и использования даже рутовых дыр ядра не было.
А вот с LXC насколько я понимаю все не так.
Последний exploit который был для ядра, давал рута с возможностью создавать блочные устройства и загружать модули
мелочи жизни :) поэтому я и использую vserver а не lxc.
жаль убрали из debian :(
Какие на текущий момент есть наработки по выходу из гостевой системы в хост (для разных систем виртуализации естественно свои), и соответственно методы защиты?

Речь идет не только о получении полного root доступа (что как я понимаю дает к примеру root доступ в гостевой системе lxc или обычного chroot) но и к примеру получение информации о хост-компьютере, с целью определить, не запускается ли приложение в нескольких копиях на одной и той же физической машине.
Так, по _выходу_ всё хорошо — это практически невозможно. В случае linux-vserver выйти за пределы chroot barrier невозможно (я такого не слышал, и так и не смог найти эксплойта, хотя искал). Выйти из просто chroot'а если ты root — можно, причем способов масса.
Узнать запущен ли ты из контейнера или на физическом железе — сложнее. Например, можно проверять доступность различных ограничений…
В любом случае, универсального решения поиска физического железа нет.
Узнать запущен ли ты из контейнера или на физическом железе — сложнее. Например, можно проверять доступность различных ограничений…

очень просто — выполнить echo b > /proc/sysrq-trigger от рута ;) в контейнере ничего не произойдет :)
кто сказал, что на руте sysfq-trigger включен в ядре?
И в каком дистрибутиве он не включен? Дженту не предлагать.
root@xxx:~# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/debian-root ro quiet sysrq=0
root@xxx:~# sysctl kernel.sysrq=0
kernel.sysrq = 0
root@xxx:~# sysctl -a | grep sysrq
kernel.sysrq = 0
root@xxx:~# echo s > /proc/sysrq-trigger
root@xxx:~# dmesg

[ 490.515566] SysRq: Emergency Sync
[ 490.517566] Emergency Sync complete
Sign up to leave a comment.

Articles