On Tue, Dec 25, 2007 at 03:26:01PM +0300, Alexey Pechnikov wrote: > > Краткий диагноз по диагонали половины субтреда: > > Алексей, Вы боитесь того, что даже не попробовали пощупать. > > В данном случае совершенно напрасно. > В определенных ситуациях
Лучше оперировать _конкретными_ ситуациями, пока опыта для обобщений недостаточно. Поверьте на слово или набейте те же шишки, но это так. > Но вопрос остается в силе - когда виртуализация _не может быть_ > использована? Например, для перегруженного сервера (с какими > параметрами?), еще в каких-то случаях. Перегруженность сервера -- зависящее от времени обстоятельство. Например, однажды нас слэшдотили (но по некоторым признакам удалось предпринять меры заранее и даже это пережить -- упёрлось в два мегабита шейпера; BTW vserver там тоже использовался). Другой пример -- постоянно перегруженный сервер обычно имеет хорошие шансы откинуть коньки по дискам. Бишь тоже является "временно перегруженным". > Где граница применимости? Думаю, в осмысленности. В коробочки а-ля "soho-маршрутизатор" или "домашний NAS" такое пихать не будут как минимум ещё довольно долго, если вообще когда-нибудь (а если запихают -- то именно для разграничения доступа и возможности восстановить корень со службами, стоя на том, куда дотянуться не так просто). В сервер с одним сервисом, который изрядно нагружен и по определению может слопать всю железку -- может быть осмысленно только в качестве уже описанного последнего довода против взлома или неконтролируемого потребления ресурсов. Во всех остальных случаях серверы я последние года три делаю просто с использованием средств виртуализации -- будь то vserver 1.x/2.x или openvz (сейчас, повторюсь, на хозяйстве осталось две машины с vserver 1.x, которые тоже запланированы к переезду). Даже если сейчас или вообще там один контейнер, средства лёгкой виртуализации дают помимо контроля возможность более гибко приспосабливать железку к задачам (например, если бы сейчас ещё хотели взгромождать sourceforge, то засунул бы дебиан в ещё один контейнер и поднимал там gforge или что бы посоветовали как более живое и уже упакованное). А также и возможность более гибко разделять привилегии и ответственность -- можно спокойно давать рута человеку, который компетентен в построении одного сервиса, но в зависимость от аккуратности и внимательности которого не хочется ставить всё остальное (особенно если этот человек -- я и есть). > > > Веб-сервера, включая пресловутый апач (если им еще кто-то > > > пользуется) тоже виртуальный хостинг поддерживают. > > Это не тот "виртуальный". > Несколько сайтов на одном ip. А тут -- несколько операционных окружений на одной физической системе. Разница чувствуется? > Вроде как было придумано для экономии ресурсов (в данном случае > ip-адресов). Сперва появились не name-based, а IP-based vhosts. И решали они как раз ту задачу, которую решают и средства виртуализации: как на одну железку (не IP!) поселить несколько веб-серверов. > Идея та же самая. На один физический сервер зарегистрировано > много сайтов, стоит себе одна железка, на ней один апач и т.п. Я как бы чуточку немного в курсе, Apache Master имени Brainbench заработал в перерыве между парами на четвёртом, что ли, курсе \m/ :) > > Пример "на пальцах" -- думаю, я подниму apache1+mod_perl+ > > mod_php4 и, скажем, apache2+mod_php5 на одном тазу, вот > > только осмысленно будет разнести их в два, а то и в три > > разных VE. И всем будет только лучше, как правило. > Возможно. Вопрос: есть N подключений к апачу 1, и M к апачу 2. > Насколько уменьшатся допустимые Nmax и Mmax после > виртуализации? Вот на столечко, если она из тех, что рекомендуются в этом треде для задач веб-хостинга. Поскольку основной вклад в разумным образом построенной системе будет всё равно не за ovz/vs. > > <провокация> > > И при этом используете Debian, а не ALT или Owl? Хех. > > </провокация> > Дебиан - понятно, а остальное, наверное, для тех, у кого нет > дебиана :-) Это было к перфекционизму по части безопасности и качества кода скорее -- в дебиане свой, но по другой части :) > > Админу писать свой -- заведомо хуже. Даже компетентному > > разработчику, как правило, полезней поискать хорошую открытую > > базу и отталкиваться от неё, возвращая свои наработки для > > общей пользы, чем городить своё. Исключение мне известно > > одно: когда мера безопасности "шоб никто не догадался" такой > > ценой считается оправданной. > В определенных областях хороших наработок не удается найти, > потому и пишется свое. Можно пример области, пути поиска наработок и ссылки на написанное, которое лучше того, что существует? Несомненно, это должны быть весьма ценные проекты. > Тут уже вопрос стоит, как интегрировать с существующими > наработками, чтоб меньше писать "с нуля". И в первую очередь > имеет смысл выбрать, с чем стоит работать, а что лучше > реализовать самому или поискать другую реализацию. Не спорю. > > > Получается, бардак растет на всех уровнях > > Вам явно противопоказано пользоваться протоколами на основе > > TCP/IP с таким обострённым чувством прекрасного... :) > Скажем так, я пытаюсь понять, как "хотели лучше" разработчики и > что у них потом получилось. И тоже стараюсь делать как лучше, а > не ориентироваться на "как всегда". Думаю, мы с Алексом Куклиным, равно как и существенная часть других подписчиков -- тоже не ратуем за "как всегда". Просто теория от практики отличается больше на практике, чем в теории. > Администрирование и разработку разделить стало очень сложно > (очень много готовых решений всех мастей) Отнюдь -- разработчик-администратор "из кубиков" занимается по сути интеграцией. Разработчик пилит или допиливает кубики, а администратор обеспечивает функционирование того, что такой вот интегратор получил. > > > И, как я вижу, навык поставить виртуальную машину и > > > запустить быдлокод в ней все увереннее заменяет собой > > > умение писать грамотный код. > > Можно поинтересоваться списком Ваших проектов и тем, > > как оценивали качество хотя бы просто кода? > Крупных решений немного - а точнее, всего два, система > мерчендайзинга и документоборот. И что по второму? Не стесняйтесь, многим нужен хороший -- особенно свободный -- документооборот. И многие оценят великолепный и продуманный код. И архитектуру. > > Про форумы всё понятно, вот только плеваться проще, чем хотя > > бы отобрать "хорошие" и советовать людям, когда спрашивают. > В рассылке периодически пробегают обсуждения в том числе и > форумов. И часть из них вполне удовлетворяют достаточно строгим > требованиям, так что выбирать есть из чего. Разумеется. > > Заказчик может хотеть немного странного и при этом в общем и > > в целом быть нормальным, вменяемым и стоящим дела. Идеальных > > (по концу работы, не по ТЗ и началу) мне ещё не встречалось. > Если вы работаете с заказчиком с момента составления ТЗ По совсем чужим ТЗ не работаем: лавка небольшая, и в ней все понимают, почём фунт техзадания. > вполне возможно сообщить, что определенные технологии и > продукты безопаснее других и привести примеры. Естественно. Или в случае предоставления хостинга -- предупредить о нежелательности применения некоторых продухтов: http://www.linux.kiev.ua/ru/devel/hosting/web/ "Категорически запрещены phpBB2, phpNuke/postNuke и доступный публично awstats." (хотя, похоже, запрет пора перенести на IPB, а в качестве отдельного форума рекомендовать какой SMF) http://ho.com.ua/ "Q: И все-таки, в чем подвох для бесплатных? A: Очень просто. Если будете сильно грузить сервер - предложим перейти на платный вариант, или сменить хостинг, если не сильно - оставайтесь бесплатно, винты нынче дешевые." (знакомые) > К разумным аргументам большинство заказчиков прислушивается. С теми, кто совсем не прислушивается -- совсем не работаем. > Другое дело, что собрать эти разумные аргументы сложно. Для этого помогает экспериментирование с потенциально интересными технологиями в песочнице или на некритичных проектах. > Как видите, очень часто на мои вопросы отвечают "это хорошая и > нужная технология, потому что я ее использую". Думаю, это следствие формы вопросов. > И только 1 (!) человек прислал результаты тестов, по которым в > самом деле можно составить мнение. Причём можно биться об заклад, что выгуглить их или эквивалентные -- дело максимум получаса при наличии элементарного интереса. Потому и предложил побольше читать, поменьше писать: пока пишешь толковый вопрос _и при этом уточняешь его по гуглю_, зачастую письмо выбрасывается или превращается в постановку проблемы и найденный ответ -- мож кому ещё пригодится. У всякого сообщества и его участников есть общий и персональный лимит времени на ответы на вопросы. Не стоит его искать. -- ---- WBR, Michael Shigorin <[EMAIL PROTECTED]> ------ Linux.Kiev http://www.linux.kiev.ua/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
