> Очень часто руководители фирм понимают что им нужен системный администратор уже тогда, когда один из программистов перестаёт справляться с нагрузкой или вообще уходит. Значит у них к тому моменту существует какая-никакая инфраструктура. И вы вот это всё сразу будете ламать?
Зачем ломать? Обычно мы запускаем контейнер на отдельном сервере, настраиваем все с нуля, тестируем, тестирует клиент. Когда все хорошо работает, выполняем чистовую синхронизацию данных. Дальше или оставляем на новой железке, или приводим в порядок старую и переносим весь контейнер обратно.
> Или же, скажем, что вы будете делать, если необходимо подключать какие-нибудь внешние модули к ядру или менять его настройки. OpenVZ накладывает существенные ограничения на это. Например, попробуйте поднять IPSEC на любой машине использующей ядро OpenVZ.
В случае подобных требований, конечно проще отказаться от OpenVZ.
> А что вы будете делать, когда какая-нибудь жизненно важная для фирмы программа начнет немеряно есть память(например, java очень любит так поступать) не взирая на ограничения.
Какую роль в этом вопросе играет OpenVZ (мы не ограничиваем ресурсы в контейнерах)?
> Если уж, предлагаете услуги внешних админов, то не скупитесь на вариантах используемых технологий. Нужно исходить из того, что нужно клиенту, а не из того, что вы считаете самым удобным.
Нужно, например, компаниям, для которых не принципиально Debian используется или CentOS. В то же время, администрируй мы Debian (а работать проще с чем-то одним), любители CentOS задали бы этот же вопрос.
А относительно виртуализации, нужно например тем, кому не хочется при переходе на новое железо все перенастраивать как в первый раз.
Я не написал одну важную вещь — мы никак не ограничиваем ресурсы контейнеров. Виртуализация используется в целях удобства, бэкапов, переездов, масштабирования (в том числе клонирования), но не для ограничения ресурсов (впрочем, это тоже возможно, при необходимости).
Рекомендуется постепенно повышать значение thread_cache_size и наблюдать за Threads_created до тех пор, пока Threads_created будет незначительно больше Threads_cached.
Динамические данные и конфиги, которые могут в разных ветках/серверах отличаться, проще всего выносить за пределы репозитория, а в пепозиторий — класть симлинк на эти файлы/папки.
Это уже «на вкус и цвет» ;-) Попробуйте посмотреть разные варианты на ресурсах типа ispreview.
Зачем ломать? Обычно мы запускаем контейнер на отдельном сервере, настраиваем все с нуля, тестируем, тестирует клиент. Когда все хорошо работает, выполняем чистовую синхронизацию данных. Дальше или оставляем на новой железке, или приводим в порядок старую и переносим весь контейнер обратно.
> Или же, скажем, что вы будете делать, если необходимо подключать какие-нибудь внешние модули к ядру или менять его настройки. OpenVZ накладывает существенные ограничения на это. Например, попробуйте поднять IPSEC на любой машине использующей ядро OpenVZ.
В случае подобных требований, конечно проще отказаться от OpenVZ.
> А что вы будете делать, когда какая-нибудь жизненно важная для фирмы программа начнет немеряно есть память(например, java очень любит так поступать) не взирая на ограничения.
Какую роль в этом вопросе играет OpenVZ (мы не ограничиваем ресурсы в контейнерах)?
> Если уж, предлагаете услуги внешних админов, то не скупитесь на вариантах используемых технологий. Нужно исходить из того, что нужно клиенту, а не из того, что вы считаете самым удобным.
Без проблем :-)
Нужно, например, компаниям, для которых не принципиально Debian используется или CentOS. В то же время, администрируй мы Debian (а работать проще с чем-то одним), любители CentOS задали бы этот же вопрос.
А относительно виртуализации, нужно например тем, кому не хочется при переходе на новое железо все перенастраивать как в первый раз.
Я не написал одну важную вещь — мы никак не ограничиваем ресурсы контейнеров. Виртуализация используется в целях удобства, бэкапов, переездов, масштабирования (в том числе клонирования), но не для ограничения ресурсов (впрочем, это тоже возможно, при необходимости).
Подробнее на эту тему можно прочитать по адресу mysqltips.blogspot.ru/2007/03/mysql-threads-tunning.html