[NiTr0]

У виртуалки изначалально много интерфейсов, причем резервированных.

Угу, только при отваливании реального сервера от сети (к примеру, ребут свича) все эти виртуальные интерфейсы виртуалок становятся абсолютно бесполезными...

 

Профит в том, что у вас вместо 20-и железяк - две, которые можно поставить с двумя БП и УПС-ами, и все вместе места будет занимать четверть стойки.

И вместо вязанки проводов - десяток, с учетом всех резервирований, которые никогда не перекоммутируются.

Кто говорит о 20 железяках?

 

Если у вас 10-20% утилизации в ЧНН на боевых серверах, плюс тестовые и небоевые, то как раз 10 к одному и получиться.

И не важно, сервис на сервер, или по 3 сервиса на сервер.

Тестовые/небоевые - обкатываются в уголке на десктопах. И к стойке отношения не имеют.

 

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

Я к примеру удобства каждый раз разворачивать ось лишь для того, чтобы поднять на ней сервис, не вижу...

 

Сейчас многие системы идут уже образами виртуальными. Скачал, развернул - готово, работай! Попробовал, не понравилось - удалил, понравилось - разбираешься дальше.

Это базовые возможности. Дальше в виртуализации уже навороченно очень много. Но это потом, когда распробовали.

Что мешает пощупать виртуалку на десктопе, понравилось - развернуть софт на сервере/виртуальной машине? Или так охота плодить зоопарк из различных дистрибутивов, чтобы иметь потом головняк с его обслуживанием?

Не задумывались, что обновление софта тоже время занимает, и обновление на 5 машинах занимает меньше времени, чем обновление на 50 виртуалках?

[homeuser]

Не задумывались, что обновление софта тоже время занимает, и обновление на 5 машинах занимает меньше времени, чем обновление на 50 виртуалках?

а не задумывались ли вы что если обновление прошло не корректно (да неважно по каким причинам) то сколько сервисов может лечь сразу (или после перезагрузки)? сервис=1 виртуалка в этом плане себя уже показало, если не сталивался с аналогичным то молодец, успехов и дальше. а на винде подобное сплошь и рядом причем не обновления винды, а какойнить "шипко умной" проги. но эт так...

[agr]

512М-гиг памяти под каждую виртуалку вместо 30-100 МБ под сервис - это более полное задействование ресурсов, или их разбазаривание?

Виртуалки не откусывают выделенную под них память безвозвратно, на хост машине можно запустить виртуалок с суммарным количеством памяти больше чем есть на хост машине, они как и обычные сервисы будут конкурировать за ресурсы. А случае с openvz память занятая виртуалкой почти равна памяти занятой сервисом, оверхед на саму систему там микроскопический. Про время процессора и некомпьютерные ресурсы уже писали выше.

Да в общем-то это и отдельных ресурсов касается. Перенос конфигов рсинком - дело пары минут, апгрейд софта - аналогично, перенос за пару минут, апгрейд... Хотя для критичных сервисов - кластеризация на реальном железе только. Ибо иначе падение одной из железок = повторному старту виртуалок на второй ноде, т.е. простой в пару минут. В то время как старт сервиса и поднятие ИП занимают секунды.

А почему нельзя стартануть сервис и поднять ИП на уже работающей виртуалке? Про кластеризацию виртуалок уже писали. А еще ОС в виртуалке можно держать в режиме suspend, тогда ввод в бой сервиса путем "просыпания" может быть быстрее чем его холодный старт если сервис долго стартует.

 

Скажите, сколько на идентичных ОС занимает перенос одного сервиса? Т.е. за сколько времени rsync стянет данные? :)

Сервис - это не только данные. Если для работы сервиса требуется поставить 20 дополнительных пакетов, 40 перловых модулей и собрать чего-нибудь из исходников на 10М строк, то я боюсь rsync'ом не обойтись. А если требуемая сервисом версия библиотеки конфликтует с той, что уже используется другим сервисом?

 

Ну да ладно, о религиях вкусах не спорят.

 

Как и обещал провел тест для виртуалок xen с I/O на замапленный внутрь виртуалки физический диск. Разница есть, но не в разы.

[nuclearcat]

Мне кажется cgroups + виртуализация по типу openvz смотрится как более удобный вариант. Виртуалки нужны - если необходим не линукс или очень специфическое ядро.

[SergeiK]

У виртуалки изначалально много интерфейсов, причем резервированных.

Угу, только при отваливании реального сервера от сети (к примеру, ребут свича) все эти виртуальные интерфейсы виртуалок становятся абсолютно бесполезными...

Во первых, сервисы резервируются на второй системе :).

Во вторых, ничего не мешает включить виртуалку в два свитча. А если у вас один свитч в серверной, то все равно, виртуалка это или отдельные сервера, все упадут.

 

Профит в том, что у вас вместо 20-и железяк - две, которые можно поставить с двумя БП и УПС-ами, и все вместе места будет занимать четверть стойки.

И вместо вязанки проводов - десяток, с учетом всех резервирований, которые никогда не перекоммутируются.

Кто говорит о 20 железяках?

Если у вас всего 3 сервера, то, конечно, говорить не о чем. Но, как правило, даже у самой небольшой компании их десяток, по разным причинам.

 

Если у вас 10-20% утилизации в ЧНН на боевых серверах, плюс тестовые и небоевые, то как раз 10 к одному и получиться.

И не важно, сервис на сервер, или по 3 сервиса на сервер.

Тестовые/небоевые - обкатываются в уголке на десктопах. И к стойке отношения не имеют.

На десктопы вытаскивать вланы, откуда есть нужные доступ - отдельная засада. Но если все в одной куче, тогда нет вопросов.

 

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

Я к примеру удобства каждый раз разворачивать ось лишь для того, чтобы поднять на ней сервис, не вижу...

Её не надо разворачивать с нуля. Она уже есть в готовом образе. Надо только загрузить, назначить нужные адреса, поменять пароли и доставить пакеты, если необходимо.

Сейчас многие системы идут уже образами виртуальными. Скачал, развернул - готово, работай! Попробовал, не понравилось - удалил, понравилось - разбираешься дальше.

Это базовые возможности. Дальше в виртуализации уже навороченно очень много. Но это потом, когда распробовали.

Что мешает пощупать виртуалку на десктопе, понравилось - развернуть софт на сервере/виртуальной машине? Или так охота плодить зоопарк из различных дистрибутивов, чтобы иметь потом головняк с его обслуживанием?

Про десктоп уже писал. Можно все делать на десктопах на рабочем месте. Помню, было у нас почти у каждого 3-5 корпусов разной степени наполнености, на которых что-то, якобы, тестируется. И для них отдельные провода к рабочему месту. Да еще и доступ, нередко, специфический. Ляпота.

 

Про зоопарк - эта проблема связана не с виртуализацией, а с политикой компании. Можно и без виртуализации зоопарк развести, можно контроллировать этот вопрос в виртуализации.

Не задумывались, что обновление софта тоже время занимает, и обновление на 5 машинах занимает меньше времени, чем обновление на 50 виртуалках?

А что, с этим есть какие-то проблемы?

Помимо того, что лично я за здоровый консерватизм, и не считаю нужным обновлять unix системы без реальной необходимости, проблем здесь не вижу!

Вот Windows - там да, там отдельная песня. Но, вопрос тоже решаемый, насколько знаю.

[agr]

Мне кажется cgroups + виртуализация по типу openvz смотрится как более удобный вариант. Виртуалки нужны - если необходим не линукс или очень специфическое ядро.

 

Согласен, у нас openvz в основном и используется. Я xen приплел на предыдущей странице(где разговор зашел о том, что скорость дискового ввода/вывода на хост машине будет в разы больше) для общей картины, чтобы было больше одного типа гипервизора для сравнения.

[d1m0n]

кто-нибудь из телекома работает на Xen Cloud Platform?

Изменено 21 марта, 2013 пользователем d1m0n

[NiTr0]

а не задумывались ли вы что если обновление прошло не корректно (да неважно по каким причинам) то сколько сервисов может лечь сразу (или после перезагрузки)?

Рестарт сервисов после обновления религия не позволяет делать? :)

 

сервис=1 виртуалка в этом плане себя уже показало, если не сталивался с аналогичным то молодец, успехов и дальше. а на винде подобное сплошь и рядом причем не обновления винды, а какойнить "шипко умной" проги. но эт так...

Нафига вы виндовые привычки тянете в нормальные ОС?

 

Сервис - это не только данные. Если для работы сервиса требуется поставить 20 дополнительных пакетов, 40 перловых модулей и собрать чего-нибудь из исходников на 10М строк, то я боюсь rsync'ом не обойтись. А если требуемая сервисом версия библиотеки конфликтует с той, что уже используется другим сервисом?

Подключаются репозитории и тянутся пакеты. Никто ничего на машине не собирает, максимум - собирают пакеты, которые потом прекрасно ставятся на другие машины

Конфликт библиотек - тоже в нормальных дистрибутивах не встречается. Генту и т.п. на серверах навряд кто ставит.

 

А почему нельзя стартануть сервис и поднять ИП на уже работающей виртуалке? Про кластеризацию виртуалок уже писали

Вручную - поднять можно, только что, при падении сервера критичные сервисы ручками поднимать? А автоматом - split-brain легко случиться может. Линки из виртуальных машин посложнее будет сделать отказоустойчивыми. На досуге - добейтесь отсутствия проблем со связью между двумя виртуальными машинами на разных физических серверах при отказе свича/обрыве одного из линков между сервером и свичом, при этом чтобы флуд в сети (всякое же может случиться) не положил виртуалки. Там и поговорим.

 

А еще ОС в виртуалке можно держать в режиме suspend, тогда ввод в бой сервиса путем "просыпания" может быть быстрее чем его холодный старт если сервис долго стартует.

Запустите в suspend виртуалку БД, и обеспечьте синхронизацию данных. Удивитесь, чем окончится...

 

Во первых, сервисы резервируются на второй системе :).

Во вторых, ничего не мешает включить виртуалку в два свитча. А если у вас один свитч в серверной, то все равно, виртуалка это или отдельные сервера, все упадут.

 

Сделайте отказоустойчивый кластер. Без проброса реальных сетевух в виртуалки (иначе - сервер в дикобраза превратится).

 

Если у вас всего 3 сервера, то, конечно, говорить не о чем. Но, как правило, даже у самой небольшой компании их десяток, по разным причинам.

На данный момент - 4 боевых сервера (один - с двумя виртуальными машинами, поднятыми в целях изоляции/ограничения ресурсов публичных некритичных сервисов), полуэкспериментальный кластер из 2 нод, ну и VoIP с астериском опять же в полуэкспериментальном виде. Биллинговая система прекрасно уживается с радиус-сервером, своей веб-мордой и дхцп сервером; почтовый сервер прекрасно уживается с прокси и кактусом, на сервере с виртуалками крутится попутно и БД публичных сервисов. БД биллинга - пока отдельно. В лизкой перспективе еще выделенный сервер под бекапы.

При этом что угодно куда угодно переносится довольно быстро и безболезненно.

Если же компания плодит сервера без веских на то причин, ввиду нежелания админа включить голову/подровнять руки и таки добиться достаточной изоляции сервисов/обслуживающих их людей друг от друга - это личное горе компании.

 

На десктопы вытаскивать вланы, откуда есть нужные доступ - отдельная засада.

Элементарно. Любой влан куда угодно. Ессно, по *никсами, в винде с вланами все печально.

 

Про десктоп уже писал. Можно все делать на десктопах на рабочем месте. Помню, было у нас почти у каждого 3-5 корпусов разной степени наполнености, на которых что-то, якобы, тестируется. И для них отдельные провода к рабочему месту. Да еще и доступ, нередко, специфический. Ляпота.

Нафига помойку тянуть в стойку на боевой сервер виртуализации, если это все можно покрутить на десктопе в виртуалке?

Вот уйдет созданная экспериментальная виртуалка в глубокий своп (или просто активное дисковое i/o), и начнутся веселые тормоза у критичных сервисов. Оно вам надо?

 

Про зоопарк - эта проблема связана не с виртуализацией, а с политикой компании. Можно и без виртуализации зоопарк развести, можно контроллировать этот вопрос в виртуализации.

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

 

А что, с этим есть какие-то проблемы?

Представьте себе, обновление софта требует внимания. 5 серверов или 50 - две больших разницы.

 

Помимо того, что лично я за здоровый консерватизм, и не считаю нужным обновлять unix системы без реальной необходимости, проблем здесь не вижу!

Реальная необходимость - это когда сервер поимели через уязвимость, обнаруженную полгода назад, которую админ поленился прикрыть - "ибо никсы обновлять необязательно" (с)? :)

[Wingman]

Конфликт библиотек - тоже в нормальных дистрибутивах не встречается. Генту и т.п. на серверах навряд кто ставит.

Гы, в генту такие конфликты бывают на 10 порядков реже, чем в рпм-образных :) Фактически, я особо и не помню такого за последние несколько лет (везде держу генту :) )

[NiTr0]

Гы, в генту такие конфликты бывают на 10 порядков реже, чем в рпм-образных

Обновилась библиотека, сменилось имя сошки - и все, без revdep-rebuild никуда... Проходили, знаем.

Есличо - у меня генту и на всех домашних машинах, и пока еще на паре виртуалок. По сравнению с центосью той же (ну или другим адекватным LTS дистром) - ее поддержка намного геморнее.

[Aliech]

Ну про Генту - это уже сказки. Хороший инструмент? Да!

Не более того. Но и не менее, разумеется)

 

А с либами везде будут траблы, коли пакеты ставишь не из одного репа.

Изменено 22 марта, 2013 пользователем Aliech

[NiTr0]

А с либами везде будут траблы, коли пакеты ставишь не из одного репа.

Смотря, что за репы (вернее, насколько криволапые мэйнтейнеры). Если мэйнтэйнеру вздумается изъ**нуться и вкрячить в свое репо для LTS дистра более новую версию либы вместо адаптации софта к стандартным либам, что приведет к конфликту с версией из родных реп - это да, печально, только за такое по морде тухлой селедкой давать надо, и оперативно для подобного софта искать замену - ибо под капотом на 99.9% говнокод редкостный.

Если же имелось ввиду подключение вообще левых репозиториев (типа федоровских к центоси) - то ССЗБ.