Re: [Sysadmins] openvz, vserver

[Alexey Pechnikov <pechnikov@sandy.ru>]

> Краткий диагноз по диагонали половины субтреда:
> Алексей, Вы боитесь того, что даже не попробовали пощупать.
> В данном случае совершенно напрасно.

В определенных ситуациях использование виртуального сервера оправдано, я это в 
каждом сообщении говорил. Но вопрос остается в силе - когда виртуализация _не 
может быть_ использована? Например, для перегруженного сервера (с какими 
параметрами?), еще в каких-то случаях. Где граница применимости? 

>
> > Веб-сервера, включая пресловутый апач (если им еще кто-то
> > пользуется) тоже виртуальный хостинг поддерживают.
> Это не тот "виртуальный".  Примерно как сказать, что "X Windows
> -- среда для работы приложений Windows" [хотя есть rdesktop, vnc
> и wine ;].

Несколько сайтов на одном ip. Вроде как было придумано для экономии ресурсов 
(в данном случае ip-адресов). Идея та же самая. На один физический сервер 
зарегистрировано много сайтов, стоит себе одна железка, на ней один апач и 
т.п.

>
> > И т.д. Не исключаю, что может возникнуть необходимость
> > в виртуализации ОС, но не у всех и не всегда.
>
> Речь пошла не о виртуальном железе.  А о виртуальных контекстах.
> Это гораздо легче и удобнее.  Практично бывает тогда, когда
> по-хорошему задачу бы надо вынести на отдельный тазик, но его
> либо никто не даст, либо некуда поставить.
>
> Пример "на пальцах" -- думаю, я подниму apache1+mod_perl+mod_php4
> и, скажем, apache2+mod_php5 на одном тазу, вот только осмысленно
> будет разнести их в два, а то и в три разных VE.  И всем будет
> только лучше, как правило.

Возможно. Вопрос: есть N подключений к апачу 1, и M к апачу 2. Насколько 
уменьшатся допустимые Nmax и Mmax после виртуализации?

>
> Могу разве что предложить поиграться на досуге с тем же ovz,
> vserver, мож ещё чем вроде xen/qemu/virtualbox/vmware, чтоб
> по крайней мере не дезинформировать людей о том, что где полезно
> и работает, а что куда совать смысла нет.

По ovz мне тесты подсказали, уже есть что тестировать. Попробую.

> <провокация>
> И при этом используете Debian, а не ALT или Owl?  Хех.
> </провокация>

Дебиан  - понятно, а остальное, наверное, для тех, у кого нет дебиана :-)

> Админу писать свой -- заведомо хуже.  Даже компетентному
> разработчику, как правило, полезней поискать хорошую открытую
> базу и отталкиваться от неё, возвращая свои наработки для общей
> пользы, чем городить своё.  Исключение мне известно одно: когда
> мера безопасности "шоб никто не догадался" такой ценой считается
> оправданной.

В определенных областях хороших наработок не удается найти, потому и пишется 
свое. Тут уже вопрос стоит, как интегрировать с существующими наработками, 
чтоб меньше писать "с нуля". И в первую очередь имеет смысл выбрать, с чем 
стоит работать, а что лучше реализовать самому или поискать другую 
реализацию.

> Если бы из этого поделия не было так часто можно выбраться...
> Да и узнать о том, сколько оно может попытаться глотнуть
> виртуальной (sic:) памяти при каком-нить -Xmx 256m -- тоже
> отдельный прикол.
>
> > Получается, бардак растет на всех уровнях
>
> Вам явно противопоказано пользоваться протоколами на основе
> TCP/IP с таким обострённым чувством прекрасного... :)

Скажем так, я пытаюсь понять, как "хотели лучше" разработчики и что у них 
потом получилось. И тоже стараюсь делать как лучше, а не ориентироваться 
на "как всегда". Администрирование и разработку разделить стало очень сложно 
(очень много готовых решений всех мастей), потому много вопросов появляется 
именно по вопросам администрирования.

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

Крупных решений немного - а точнее, всего два, система мерчендайзинга и 
документоборот. Плюс некоторые вычислительные - восстановление трехмерного 
рельефа дна, создание дифракционных линз, еще кое-что.

Оценивал по наличию единого читаемого стиля кода и использованным алгоритмам. 
Согласен, что код форума нет необходимости оптимизировать, как, скажем, 
быстрое преобразование Фурье, но, к примеру, десятки раз вычислять одно 
значение или сто раз стучаться к БД вместо написания и вызова хранимой 
процедуры для меня достаточно, чтобы больше не вспоминать о таком ПО.

>
> Про форумы всё понятно, вот только плеваться проще, чем хотя бы
> отобрать "хорошие" и советовать людям, когда спрашивают.

В рассылке периодически пробегают обсуждения в том числе и форумов. И часть из 
них вполне удовлетворяют достаточно строгим требованиям, так что выбирать 
есть из чего.

> > >P.S. Вы, кажется, предлагаете платную поддержку debian?
>
> А мы -- платную поддержку ALT Linux.
> +1, и это ни разу не "ода быдлу".  Заказчик может хотеть немного
> странного и при этом в общем и в целом быть нормальным, вменяемым
> и стоящим дела.  Идеальных (по концу работы, не по ТЗ и началу)
> мне ещё не встречалось.

Если вы работаете с заказчиком с момента составления ТЗ, вполне возможно 
сообщить, что определенные технологии и продукты безопаснее других и привести 
примеры. К разумным аргументам большинство заказчиков прислушивается. Другое 
дело, что собрать эти разумные аргументы сложно. Как видите, очень часто на 
мои вопросы отвечают "это хорошая и нужная технология, потому что я ее 
использую". И только 1 (!) человек прислал результаты тестов, по которым в 
самом деле можно составить мнение.