forum.lissyara.su

Доброго времени суток форумчане.
Хочется в контексте набирающей популярность виртуализации рассмотреть любимую нами ОС FreeBSD как гостевую на какой либо виртуальной машине. А конекретно транспортабельность гостевой ОС при смене хоста с разыми ЦПУ. Вцелом и конкретно мне хотелось бы уточнить следующие вопросы: 1) если ядро собрано с инструкциями процессора той машины на которой изначально готовилась виртуалка, к примеру amd3dnow, а переедет машина на хост который этот набор инструкций не поддерживает на уровне процессора, будет ли корректно работать гостевая ОС (т.е. наша фряха с собранным ядром с использованием 3dnow)? 2) насколько прибавит в скорости пересборка всего мира? разумеется в контексте виртуальной машины? 3) Какие параметры должны быть указаны в bsd.kern.mk, make.conf для того чтобы виртуальная машина (64-bit) без проблем могла быть перемещена между хостами процессоры у которых с разными наборами инструкций но разумеется имеют поддержку EM64T или AMD64! прежде всего в качестве виртуальных машин будут использованы VMware ESX 4, Workstation 6.5-7. Будет интересен любой ваш опыт

В настоящий момент передо мной стоит задача создать сервер управляющий мониторингом сети. Мой выбор остановился на следующем конфиге виртуальной машины.

FreeBSD 8.0
CPU: 1
Cores: 2
RAM: 512-1024M (возможно много но я беру с запасом)
виртуалка VMware совместимая с ESX 4.0
HDD 16-20Gb

Soft (самый основной):
Nagios 3 с возможностью строить красивые графики (т.е. будут плагины дополнительные)
Nginx+PHP-fpm в качестве вебсервера с поддержкой PHP CGI под Nagios
VSFTPd+TLS для безопасной передачи инфы от меня до сервака
И главное условие возможность транспортировки между хостами с разными процами.

Будут интересны ваши комментарии. Спасибо.

Если каких-то спец.опций не добавлять в make.conf, то между процами проблем не возникает (я по статье с сайта о pax переносил системы с celeron на sempron). Для смены архитектуры на сайте статью посмотрите. А со спец.опциями в make.conf не экспериментировал, но, думаю, не должно помереть. Попробуйте, ждем результатов

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

f_andrey писал(а):Топикстартеру, советую обновить свои знания по теме, или переформулировать задачу, иначе она смахивает на бред.

Ну не совсем бред, хотя конечно что-то есть... Я считаю, что собственное ядро и компиляция под процессор имеет смысл только если, это очень хорошо нагруженная машина или же очень слабая машина, ни того, ни другого у топикстартера нет...

snorlov писал(а):

f_andrey писал(а):Топикстартеру, советую обновить свои знания по теме, или переформулировать задачу, иначе она смахивает на бред.

Ну не совсем бред, хотя конечно что-то есть...

priest.romeo писал(а):ОС FreeBSD как гостевую на какой либо виртуальной машине

Хм.. попытаюсь сформулировать иначе.

Есть хост машина - мощный двухпроцессорный (по 4 ядра на каждом проце) сервак. На серваке стоит ESX Server 4. На нём будут крутиться виртуальные машины различного назначения одной из которых будет сервер мониторинга о котором я писал выше. Ставить BSD на виртуальную машину без пересборки ядра и с установкой пакетов по моему просто глупо и очень некрасиво т.к. будет значительная потеря в производительности. Т.е. нужны оптимизации и пересборка ядра. Если кто нибудь кто написал о топике как о бреде замечал с какими опциями происходит сборка модулей ядра, то видимо обратил внимание что там есть строчка с инструкцией -amd3dnow. Теперь представим что переносим нашу виртуалку с FreeBSD на другую хост машину с ESX'ом, у которой проц не поддерживает данную инструкцию amd3dnow и что мы имеем - модуль (в теории) не заработает т.к. был собран с данным набором инструкций!

Поэтому задача как собрать с оптимизациями систему и ядро и софт, чтобы при перезде с хоста который поддерживает ADM64 / EM64T инструкции (у нас 64-bit FBSD) на другой хост поддерживающий те же + дополнительные инструкции небыло проблем?

Ресурсы нужно экономить, поэтому и нужны оптимизации.

priest.romeo писал(а):Хм.. попытаюсь сформулировать иначе.

Есть хост машина - мощный двухпроцессорный (по 4 ядра на каждом проце) сервак. На серваке стоит ESX Server 4. На нём будут крутиться виртуальные машины различного назначения одной из которых будет сервер мониторинга о котором я писал выше. Ставить BSD на виртуальную машину без пересборки ядра и с установкой пакетов по моему просто глупо и очень некрасиво т.к. будет значительная потеря в производительности. Т.е. нужны оптимизации и пересборка ядра. Если кто нибудь кто написал о топике как о бреде замечал с какими опциями происходит сборка модулей ядра, то видимо обратил внимание что там есть строчка с инструкцией -amd3dnow. Теперь представим что переносим нашу виртуалку с FreeBSD на другую хост машину с ESX'ом, у которой проц не поддерживает данную инструкцию amd3dnow и что мы имеем - модуль (в теории) не заработает т.к. был собран с данным набором инструкций!

Поэтому задача как собрать с оптимизациями систему и ядро и софт, чтобы при перезде с хоста который поддерживает ADM64 / EM64T инструкции (у нас 64-bit FBSD) на другой хост поддерживающий те же + дополнительные инструкции небыло проблем?

Ресурсы нужно экономить, поэтому и нужны оптимизации.

мое предложение - забросить идею с пересборкой ядра подальше... в современных условиях прироста в производительности нет (ну загрузиться она у тебя на 3 секунды быстрее), но вот геморроя в обслуживании это добавляет. по поводу перемещения между хостами - если есть кластер, то vmotion не получится просто так делать между хостами с разными процами. в любом случае надо будет включать EVC (либо в ручную править маски) - соответственно процы для VM будут идентичные.

Прошу прощения моя невнимательность при сборке ядра как раз таки принудительно указывается исключение данных инструкций а не их включение. Буду думать Хочется красиво оптимизировать всё.

priest.romeo писал(а):Прошу прощения моя невнимательность при сборке ядра как раз таки принудительно указывается исключение данных инструкций а не их включение. Буду думать Хочется красиво оптимизировать всё.

ну если есть куча свободного времени - можно и позаморачиваться ))

priest.romeo писал(а):Прошу прощения моя невнимательность при сборке ядра как раз таки принудительно указывается исключение данных инструкций а не их включение. Буду думать Хочется красиво оптимизировать всё.

Время есть так вперед, моя практика показывает, незаметно все как то будет...

ерундой не занимайтесь.
что на реальных что на виртуальных машинах юзаю GENERIC, и всё работает везде.

Я не думаю что это ерунда. Вопрос не в том чтобы это работало, а в том чтобы выжить максимум не потеряв в переносимости и стабильности.

если у вас такой shortage ресурсов, лучше технологию виртуализации другую подберите. А пересборка в лучшем случае даст мизерные проценты.

priest.romeo писал(а):Ставить BSD на виртуальную машину без пересборки ядра и с установкой пакетов по моему просто глупо и очень некрасиво т.к. будет значительная потеря в производительности. Т.е. нужны оптимизации и пересборка ядра.

Для сервера мониторинга? да не смеши людей, чувак. Я понимаю, если б у тебя там нагруженный веб-сервер стоял, который бы от нагрузки дох, а тут, чтобы два раза в день графики посмотреть - пересобирать ядро?
В данном случае лучшее - враг хорошего, не получив никаких плюсов от собственного ядра ты теряешь все плюсы от виртуализации и вместо того, чтобы упростить обслуживание и поднять устойчивость системы, как раз в этом теряешь. Уже вроде десять раз обсосали, что сборка собственных ядер без реальной необходимости для продакшена - это не очень умно.

princeps писал(а):Для сервера мониторинга? да не смеши людей, чувак. Я понимаю, если б у тебя там нагруженный веб-сервер стоял, который бы от нагрузки дох, а тут, чтобы два раза в день графики посмотреть - пересобирать ядро?

ну для чуть чуть приличной сети нужен нормальный сервер мониторинга, у меня когда я перенес свои 1000 проверок с няшного восьмиядерника на обычный старенький PIV load average 5min стабильно в районе 4, другое дело что пересборкой ядра тут ничем не поможешь :}

а у тебя вмваре как установлена? проясните плз, слышал есть esxi и ее вроде как можно воткнуть без операционки...

f0s писал(а):а у тебя вмваре как установлена? проясните плз, слышал есть esxi и ее вроде как можно воткнуть без операционки...

VMWare ESX 4U1

princeps писал(а):

priest.romeo писал(а):Ставить BSD на виртуальную машину без пересборки ядра и с установкой пакетов по моему просто глупо и очень некрасиво т.к. будет значительная потеря в производительности. Т.е. нужны оптимизации и пересборка ядра.

Для сервера мониторинга? да не смеши людей, чувак. Я понимаю, если б у тебя там нагруженный веб-сервер стоял, который бы от нагрузки дох, а тут, чтобы два раза в день графики посмотреть - пересобирать ядро?
В данном случае лучшее - враг хорошего, не получив никаких плюсов от собственного ядра ты теряешь все плюсы от виртуализации и вместо того, чтобы упростить обслуживание и поднять устойчивость системы, как раз в этом теряешь. Уже вроде десять раз обсосали, что сборка собственных ядер без реальной необходимости для продакшена - это не очень умно.

Что то не совсем понимаю по поводу устойчивости системы?
- пересобираю ядро с -O -mtune=generic получаю тот же Generic (для переносимости) только без кучи лишнего хлама, который на виртуалке никогда не понадобится
- усточивость при -O оптимизации не потеряется, stress за 60 минут нагрузки никаких проблем не выдал
- производительность, при SMP выйгрыш не большой согласен, а вот при UP в 3 раза, по карйней мере так показывает sysbench (mutex test, другие не припомню), скорость загрузки выше, тоже приятно.

"Мы коммунисты не ищем лёгких путей" , я еще и мир пересобрал с теми же опциями выкинув то что считал не нужным.

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

opt1k писал(а):пытаясь выиграть 20 секунд в год как разницу во времени загрузки - вы теряете дни. Другое дело то что вы с этим ковыряетесь, то получаете бесценный опыт.
С экономической же точки зрения вы воруете рабочее время за которое вам платят

Не ворую, я делаю это после работы. Да, опыт - это всё. Да действительно теряю, но дни это круто сказано, я бы сказал что эксперименты занимают много, но сама пересборка мира и ядра заняла 3 часа примерно.

opt1k писал(а):пытаясь выиграть 20 секунд в год как разницу во времени загрузки - вы теряете дни. .....
С экономической же точки зрения вы воруете рабочее время за которое вам платят

opt1k молодец, правильно написал, я тоже так хотел, но сформулировать не смог. А то что ты этим ещё и в нерабочее время занимаешься - это уж тем более глупость. С другой стороны, если цель - прокачаться, а не работу работать, то тогда да, это может быть правильно и мудро.

priest.romeo писал(а):- пересобираю ядро с -O -mtune=generic получаю тот же Generic (для переносимости) только без кучи лишнего хлама, который на виртуалке никогда не понадобится

куча лишнего хлама понадобится, когда у тебя сгорит хост под виртуалкой и тебе придётся систему срочно перетаскивать на другой сервер. Кроме того, ты лишаешься бинарных обновлений. И всё это для того, чтобы выиграть две секунды на загрузке? имхо для реального продакшена это ни экономически, ни вообще никак не выгодно. Так, для самообразования.

Народ, у меня есть сервер на базе supermicro x7dbe, скажите, я могу установить на него esxi? есть там аппаратная поддержка? если нет, то что нужно докупить чтобы она была?

читайте листы совместимости esxi

Куча лишнего хлама понадобится, когда у тебя сгорит хост под виртуалкой и тебе придётся систему срочно перетаскивать на другой сервер.

Глупость говорите. Всё что измениться - CPU. Это касательно VMware. Любой современный камень (начиная с десктопа) имеет 2 ядра, MMX, SSE, SSE2 (это инструкции с которыми собирается Generic).