Comments 12
Правильно ли я понял из статьи, что вы предлагаете услуги администраторов, которые используют только CentOS в связке с OpenVZ?
В целом — да. Если иные требования обоснованы, исключения обсуждаемы.
И кому это нужно?
Очень часто руководители фирм понимают что им нужен системный администратор уже тогда, когда один из программистов перестаёт справляться с нагрузкой или вообще уходит. Значит у них к тому моменту существует какая-никакая инфраструктура. И вы вот это всё сразу будете ламать?
Или же, скажем, что вы будете делать, если необходимо подключать какие-нибудь внешние модули к ядру или менять его настройки. OpenVZ накладывает существенные ограничения на это. Например, попробуйте поднять IPSEC на любой машине использующей ядро OpenVZ.
А что вы будете делать, когда какая-нибудь жизненно важная для фирмы программа начнет немеряно есть память(например, java очень любит так поступать) не взирая на ограничения.
Если уж, предлагаете услуги внешних админов, то не скупитесь на вариантах используемых технологий. Нужно исходить из того, что нужно клиенту, а не из того, что вы считаете самым удобным.
Или же, скажем, что вы будете делать, если необходимо подключать какие-нибудь внешние модули к ядру или менять его настройки. OpenVZ накладывает существенные ограничения на это. Например, попробуйте поднять IPSEC на любой машине использующей ядро OpenVZ.
А что вы будете делать, когда какая-нибудь жизненно важная для фирмы программа начнет немеряно есть память(например, java очень любит так поступать) не взирая на ограничения.
Если уж, предлагаете услуги внешних админов, то не скупитесь на вариантах используемых технологий. Нужно исходить из того, что нужно клиенту, а не из того, что вы считаете самым удобным.
> Очень часто руководители фирм понимают что им нужен системный администратор уже тогда, когда один из программистов перестаёт справляться с нагрузкой или вообще уходит. Значит у них к тому моменту существует какая-никакая инфраструктура. И вы вот это всё сразу будете ламать?
Зачем ломать? Обычно мы запускаем контейнер на отдельном сервере, настраиваем все с нуля, тестируем, тестирует клиент. Когда все хорошо работает, выполняем чистовую синхронизацию данных. Дальше или оставляем на новой железке, или приводим в порядок старую и переносим весь контейнер обратно.
> Или же, скажем, что вы будете делать, если необходимо подключать какие-нибудь внешние модули к ядру или менять его настройки. OpenVZ накладывает существенные ограничения на это. Например, попробуйте поднять IPSEC на любой машине использующей ядро OpenVZ.
В случае подобных требований, конечно проще отказаться от OpenVZ.
> А что вы будете делать, когда какая-нибудь жизненно важная для фирмы программа начнет немеряно есть память(например, java очень любит так поступать) не взирая на ограничения.
Какую роль в этом вопросе играет OpenVZ (мы не ограничиваем ресурсы в контейнерах)?
> Если уж, предлагаете услуги внешних админов, то не скупитесь на вариантах используемых технологий. Нужно исходить из того, что нужно клиенту, а не из того, что вы считаете самым удобным.
Без проблем :-)
Зачем ломать? Обычно мы запускаем контейнер на отдельном сервере, настраиваем все с нуля, тестируем, тестирует клиент. Когда все хорошо работает, выполняем чистовую синхронизацию данных. Дальше или оставляем на новой железке, или приводим в порядок старую и переносим весь контейнер обратно.
> Или же, скажем, что вы будете делать, если необходимо подключать какие-нибудь внешние модули к ядру или менять его настройки. OpenVZ накладывает существенные ограничения на это. Например, попробуйте поднять IPSEC на любой машине использующей ядро OpenVZ.
В случае подобных требований, конечно проще отказаться от OpenVZ.
> А что вы будете делать, когда какая-нибудь жизненно важная для фирмы программа начнет немеряно есть память(например, java очень любит так поступать) не взирая на ограничения.
Какую роль в этом вопросе играет OpenVZ (мы не ограничиваем ресурсы в контейнерах)?
> Если уж, предлагаете услуги внешних админов, то не скупитесь на вариантах используемых технологий. Нужно исходить из того, что нужно клиенту, а не из того, что вы считаете самым удобным.
Без проблем :-)
>Зачем ломать? Обычно мы запускаем контейнер на отдельном сервере, настраиваем все с нуля, тестируем, тестирует клиент. Когда все хорошо работает, выполняем чистовую синхронизацию данных. Дальше или оставляем на новой железке, или приводим в порядок старую и переносим весь контейнер обратно.
Вы используете свой сервер? Или арендуете где-то? Или заставляете клиента купить себе самостоятельно?
Вы используете свой сервер? Или арендуете где-то? Или заставляете клиента купить себе самостоятельно?
Это очень широкий вопрос. :-)
Нужно, например, компаниям, для которых не принципиально Debian используется или CentOS. В то же время, администрируй мы Debian (а работать проще с чем-то одним), любители CentOS задали бы этот же вопрос.
А относительно виртуализации, нужно например тем, кому не хочется при переходе на новое железо все перенастраивать как в первый раз.
Я не написал одну важную вещь — мы никак не ограничиваем ресурсы контейнеров. Виртуализация используется в целях удобства, бэкапов, переездов, масштабирования (в том числе клонирования), но не для ограничения ресурсов (впрочем, это тоже возможно, при необходимости).
Нужно, например, компаниям, для которых не принципиально Debian используется или CentOS. В то же время, администрируй мы Debian (а работать проще с чем-то одним), любители CentOS задали бы этот же вопрос.
А относительно виртуализации, нужно например тем, кому не хочется при переходе на новое железо все перенастраивать как в первый раз.
Я не написал одну важную вещь — мы никак не ограничиваем ресурсы контейнеров. Виртуализация используется в целях удобства, бэкапов, переездов, масштабирования (в том числе клонирования), но не для ограничения ресурсов (впрочем, это тоже возможно, при необходимости).
Мы выжимаем из CentOS максимум. Для достижения максимальной производительности мы тонко настраиваем сетевую подсистему, где необходимо — обновляем драйверы, подкручиваем sysctl-параметры.
Эм ШТО? Первое требуется только в совсем уж пограничных случаях. Второе весьма сомнительно с точки зрения последующих апдейтов.
Эм ШТО? Первое требуется только в совсем уж пограничных случаях. Второе весьма сомнительно с точки зрения последующих апдейтов.
А что со временем работы такое интересное? Если вечером сервер упал, то привет? :)
Sign up to leave a comment.
О компании centos-admin.ru