Комментарии 7
А чем iDrac родной от DELLа не устроил? В нем есть же возможность через виртуальный привод монтировать образа с локальной машины.
iDrac — Хорошая штука, но мне это не подходит по нескольким причинам: это дополнительная лицензия, дополнительные настройки. К тому же делать апгрейд старых серверов не всегда представляется возможным, а решение должно быть максимально универсальным.
По поводу кучи серверов и нахлабучивания из разносолов — виртуализация нас спасёт, много физических серверов это гемморой. 10 физически немощных сервачков лучше разместить ввиде виртуалок на 1м нормальном, и утилизация железа хорошая, и в случае смерти железки всегда можно бекапы виртуалок(а если образа дисков хранились на отдельной дисковой полочке, то считай, почти без потерь) тут же оживить в другом месте. При определенных условиях уже можно кластер поднять из нескольких нод, для пущей надежности.
PS
На деле, парк из сотен физических серверов разносольным никто не делает, конечно если они не для аренды.
PS
На деле, парк из сотен физических серверов разносольным никто не делает, конечно если они не для аренды.
Не совсем ясно за что минус, кто поставил — отпишитесь пожалуйста.
Позвольте немного уточнить мою позицию и расставить точки над «i» (наконец-то я не с телефона:))
Во-первых, iDrac никогда не заменит массовую установку через pxe. Представьте, у Вас под 200 серверов, возраст которых от 5 лет до нескольких месяцев. Изначалльно Dell не включал никакой iDrac в стандартную поставку, а сейчас включает только базовый вариант. Вам нужно обновить Windows на 10 из старых серверов. Что будет более эффективно, переставить ОС удаленно через pxe и WDS/kickstarter со всеми апдейтами или делать апгрейд сервера, устанавливая сначала iDrac, а потом монтируя ISO тысячалетней давности через сеть, устанавливая 1-2 сервера за раз, а потом полдня обновляя систему? Конечно iDrac мало пригоден в данном случае.
Во-вторых, изначально IP KVM — решение экономически более выгодное чем iDrac (сравните цены) + более гибкое (можно подключить куда угодно).
Не до конца понимаю как Вы видите мою инфраструктуру сидя за монитором, что беретесь судить о том, как «на деле»:
>На деле, парк из сотен физических серверов разносольным никто не делает
Вы почему-то рассматриваете инфраструктуру «с нуля» — только тогда есть возможность выбирать идеальное решение. К сожалению реалии жизни таковы, что работа инженера — это в первую очередь поддержка текущей инфраструктуры, и соответственно всего того, что делает деньги и что должно работать СЕЙЧАС, а уже потом ее улучшение. Возможно, если это унылый датацентр, где можно положить/переренести десяток сервисов — да, но не в моем случае.
Другая несостыковка — это не работает в среде стартапа, где темпы роста компании намного больше чем возможность оглянуться назад и сделать рефакторинг. Это роскошь, ведь те самые «первые» серверы обычно выполняют четко поставленные задачи. А дальше — рост, рост, рост. Хочется виртуализировать — некогда, нужно расти… Время бежит, модель сервера сменяется за моделью, и проект растет, и вот пора уже сервисы со старых серверов переносить — виртализировать? — нет, слишком медленно — поэтому и переносим. Сегодня картина несомненно улучшилась, и можно сделать выбор в пользу виртуализации для определенного круга сервисов, но здесь встает другой вопрос — инфраструктура уже существует и делает деньги, поэтому нужна миграция. Представьте, что у Вас высоконагруженный сайт с миллионом уникальных пользователей в день, где каждая минута простоя — тысячи $$$ упущенной выгоды. Выходит, что это перерастает в отдельный проект, который имеет свой приоритет перед другими задачами, а это уже совсем другая история. Ах да, рост, рост, рост. Понимаете о чем я? Да, все упирается во (время + деньги) = деньги ^ 2.
В-третьих, я продолжаю слышать нотки теории в Вашем комментарии. Все не так-то просто. Размещая 10 виртуалок на одном хосте Вы кладете «все яйца в одну корзину». В реальных условиях Ваши 10:1 превращается как минимум 10:2 + надежный и быстрый NAS + инфраструктура для надежной/быстрой передачи данных, а это, как минимум, 2x10Gb/s свитча стоимостью около $10 000. Все остальные конфигурации не отвечают нашим требованиям (медленно/ненадежно). Вы написали про «При определенных условиях уже можно кластер поднять» — для меня это единственное верное решение. Никаких условий для production среды нет — только так. К тому же со стороны сервиса надежность железного сервера выше чем надежность 10 виртуалок на 1м сервере, потому что на один сервис приходится один полностью, как минимум, вдвойне зарезервированный (redundant) сервер (CPU, Memory, PSU), в то время как в соотношении 10:1 на каждую виртуалку приходится только часть зарезервированного сервера, но я думаю это и так понятно что это означает.
В-четвертых, с чего Вы взяли что в моей боевой среде нужны «физически немощные сервачки»? — В реальности объем данных который обрабатывается огромен (в рамках данного сравнения), и использование виртуализации в такой системе не оправдано. Ну не заменить реальное железо и прямой доступ к IO в моем случае, никак не заменить, а с RAM — вообще беда (какой смысл слой виртуализации если 100% времени на хосте 1 виртуалка — удобство? Я лучше выберу производительность, так как именно она делает деньги. Делали тесты — знаем.
В-пятых, конечно, виртуализацию я люблю, и конечно мы ее используем, только с умом. Staging, Development и все что не требует больших ресурсов и 99.9% аптайма — все виртуализировано. OpenStack для разрабов, но там память у инстанса выставлена максимум 8GB, и это никто не использует…
Если бы сейчас мне предложили проект, который бы получил пользу от гибкости, где нужно было бы конфигурировать типовые машинки с небольшим количеством памяти и CPU — я бы с великой радостью все сделал виртуализированно НО все так же использовал бы PXE, так-как это удобно, гибко и быстро! Здесь исключение составят 100% клоны, где можно использовать шаблоны и снепшоты — вообще красота!
Еще раз повторюсь, я не идеалист, и решаю реальные проблемы в реальных ситуациях силами реальных людей и используя реальные деньги, а также реальное время. Может быть за это мне и платят реальными деньгами :)
Прошу прощения за сбивчивый русский, в России не живу уже 3 года.
Позвольте немного уточнить мою позицию и расставить точки над «i» (наконец-то я не с телефона:))
Во-первых, iDrac никогда не заменит массовую установку через pxe. Представьте, у Вас под 200 серверов, возраст которых от 5 лет до нескольких месяцев. Изначалльно Dell не включал никакой iDrac в стандартную поставку, а сейчас включает только базовый вариант. Вам нужно обновить Windows на 10 из старых серверов. Что будет более эффективно, переставить ОС удаленно через pxe и WDS/kickstarter со всеми апдейтами или делать апгрейд сервера, устанавливая сначала iDrac, а потом монтируя ISO тысячалетней давности через сеть, устанавливая 1-2 сервера за раз, а потом полдня обновляя систему? Конечно iDrac мало пригоден в данном случае.
Во-вторых, изначально IP KVM — решение экономически более выгодное чем iDrac (сравните цены) + более гибкое (можно подключить куда угодно).
Не до конца понимаю как Вы видите мою инфраструктуру сидя за монитором, что беретесь судить о том, как «на деле»:
>На деле, парк из сотен физических серверов разносольным никто не делает
Вы почему-то рассматриваете инфраструктуру «с нуля» — только тогда есть возможность выбирать идеальное решение. К сожалению реалии жизни таковы, что работа инженера — это в первую очередь поддержка текущей инфраструктуры, и соответственно всего того, что делает деньги и что должно работать СЕЙЧАС, а уже потом ее улучшение. Возможно, если это унылый датацентр, где можно положить/переренести десяток сервисов — да, но не в моем случае.
Другая несостыковка — это не работает в среде стартапа, где темпы роста компании намного больше чем возможность оглянуться назад и сделать рефакторинг. Это роскошь, ведь те самые «первые» серверы обычно выполняют четко поставленные задачи. А дальше — рост, рост, рост. Хочется виртуализировать — некогда, нужно расти… Время бежит, модель сервера сменяется за моделью, и проект растет, и вот пора уже сервисы со старых серверов переносить — виртализировать? — нет, слишком медленно — поэтому и переносим. Сегодня картина несомненно улучшилась, и можно сделать выбор в пользу виртуализации для определенного круга сервисов, но здесь встает другой вопрос — инфраструктура уже существует и делает деньги, поэтому нужна миграция. Представьте, что у Вас высоконагруженный сайт с миллионом уникальных пользователей в день, где каждая минута простоя — тысячи $$$ упущенной выгоды. Выходит, что это перерастает в отдельный проект, который имеет свой приоритет перед другими задачами, а это уже совсем другая история. Ах да, рост, рост, рост. Понимаете о чем я? Да, все упирается во (время + деньги) = деньги ^ 2.
В-третьих, я продолжаю слышать нотки теории в Вашем комментарии. Все не так-то просто. Размещая 10 виртуалок на одном хосте Вы кладете «все яйца в одну корзину». В реальных условиях Ваши 10:1 превращается как минимум 10:2 + надежный и быстрый NAS + инфраструктура для надежной/быстрой передачи данных, а это, как минимум, 2x10Gb/s свитча стоимостью около $10 000. Все остальные конфигурации не отвечают нашим требованиям (медленно/ненадежно). Вы написали про «При определенных условиях уже можно кластер поднять» — для меня это единственное верное решение. Никаких условий для production среды нет — только так. К тому же со стороны сервиса надежность железного сервера выше чем надежность 10 виртуалок на 1м сервере, потому что на один сервис приходится один полностью, как минимум, вдвойне зарезервированный (redundant) сервер (CPU, Memory, PSU), в то время как в соотношении 10:1 на каждую виртуалку приходится только часть зарезервированного сервера, но я думаю это и так понятно что это означает.
В-четвертых, с чего Вы взяли что в моей боевой среде нужны «физически немощные сервачки»? — В реальности объем данных который обрабатывается огромен (в рамках данного сравнения), и использование виртуализации в такой системе не оправдано. Ну не заменить реальное железо и прямой доступ к IO в моем случае, никак не заменить, а с RAM — вообще беда (какой смысл слой виртуализации если 100% времени на хосте 1 виртуалка — удобство? Я лучше выберу производительность, так как именно она делает деньги. Делали тесты — знаем.
В-пятых, конечно, виртуализацию я люблю, и конечно мы ее используем, только с умом. Staging, Development и все что не требует больших ресурсов и 99.9% аптайма — все виртуализировано. OpenStack для разрабов, но там память у инстанса выставлена максимум 8GB, и это никто не использует…
Если бы сейчас мне предложили проект, который бы получил пользу от гибкости, где нужно было бы конфигурировать типовые машинки с небольшим количеством памяти и CPU — я бы с великой радостью все сделал виртуализированно НО все так же использовал бы PXE, так-как это удобно, гибко и быстро! Здесь исключение составят 100% клоны, где можно использовать шаблоны и снепшоты — вообще красота!
Еще раз повторюсь, я не идеалист, и решаю реальные проблемы в реальных ситуациях силами реальных людей и используя реальные деньги, а также реальное время. Может быть за это мне и платят реальными деньгами :)
Прошу прощения за сбивчивый русский, в России не живу уже 3 года.
>Во-первых, iDrac никогда не заменит массовую установку через pxe. Представьте, у Вас под 200 серверов,
Образ готовой системы можно разворачивать как угодно, в данном случае просто поинтересовался, что так заморачивались с IPKVM, т.к. про Express лицензию iDrac ни слова в статье
>Во-вторых, изначально IP KVM
Вкурсе
>Вы почему-то рассматриваете инфраструктуру «с нуля»
Такие вещи всегда планируют, что тут обсуждать
>Не до конца понимаю как Вы видите мою инфраструктуру сидя за монитором, что беретесь судить о том, как «на деле»:
>>На деле, парк из сотен физических серверов разносольным никто не делает
Тут не о вашей инфраструктуре, а из статьи:
>В-третьих, я продолжаю слышать нотки теории в Вашем комментарии.
Это вы зря :)
>Другая несостыковка — это не работает в среде стартапа, где темпы роста компании намного больше чем возможность оглянуться назад и сделать рефакторинг.
Отлично работает, если изначально об этом подумать, виртуализация дает отличную маштабируемость и апдейт на новый сервер занимает считанные минуты(если просто замена железки, и диски виртуалок доступны для нового сервера изначально локально), достаточно развернуть гипервизор, и всё, тащи виртуалки туда и давай им больше ресурсов.
>К тому же со стороны сервиса надежность железного сервера выше чем надежность 10 виртуалок на 1м сервере, потому что на один сервис приходится один полностью, как минимум, вдвойне зарезервированный (redundant) сервер (CPU, Memory, PSU), в то время как в соотношении 10:1 на каждую виртуалку приходится только часть зарезервированного сервера, но я думаю это и так понятно что это означает.
Используйте кластеры виртуализации, либо более простое: если железка упала — включаешь всё на резервной, и ставить ничего не надо, нажал вкл и оно запустилось. Так же, надежность надежностью, а развернуть заново виртуалку можно в разы быстрее, и не важно их кол-во.
>В-четвертых, с чего Вы взяли что в моей боевой среде нужны «физически немощные сервачки»?
«Сервачок» в контексте виртуализации, это скорее сервис или задача.
>В-пятых <...> виртуализацию я люблю
и я того же мнения :)
>Если бы сейчас мне предложили проект, который бы получил пользу от гибкости, где нужно было бы конфигурировать типовые машинки с небольшим количеством памяти и CPU — я бы с великой радостью все сделал виртуализированно НО все так же использовал бы PXE,
А я бы клонировал эталонную машину :)
Образ готовой системы можно разворачивать как угодно, в данном случае просто поинтересовался, что так заморачивались с IPKVM, т.к. про Express лицензию iDrac ни слова в статье
>Во-вторых, изначально IP KVM
Вкурсе
>Вы почему-то рассматриваете инфраструктуру «с нуля»
Такие вещи всегда планируют, что тут обсуждать
>Не до конца понимаю как Вы видите мою инфраструктуру сидя за монитором, что беретесь судить о том, как «на деле»:
>>На деле, парк из сотен физических серверов разносольным никто не делает
Тут не о вашей инфраструктуре, а из статьи:
А если это 10 или 20 или 100 серверов?
>В-третьих, я продолжаю слышать нотки теории в Вашем комментарии.
Это вы зря :)
>Другая несостыковка — это не работает в среде стартапа, где темпы роста компании намного больше чем возможность оглянуться назад и сделать рефакторинг.
Отлично работает, если изначально об этом подумать, виртуализация дает отличную маштабируемость и апдейт на новый сервер занимает считанные минуты(если просто замена железки, и диски виртуалок доступны для нового сервера изначально локально), достаточно развернуть гипервизор, и всё, тащи виртуалки туда и давай им больше ресурсов.
>К тому же со стороны сервиса надежность железного сервера выше чем надежность 10 виртуалок на 1м сервере, потому что на один сервис приходится один полностью, как минимум, вдвойне зарезервированный (redundant) сервер (CPU, Memory, PSU), в то время как в соотношении 10:1 на каждую виртуалку приходится только часть зарезервированного сервера, но я думаю это и так понятно что это означает.
Используйте кластеры виртуализации, либо более простое: если железка упала — включаешь всё на резервной, и ставить ничего не надо, нажал вкл и оно запустилось. Так же, надежность надежностью, а развернуть заново виртуалку можно в разы быстрее, и не важно их кол-во.
>В-четвертых, с чего Вы взяли что в моей боевой среде нужны «физически немощные сервачки»?
«Сервачок» в контексте виртуализации, это скорее сервис или задача.
>В-пятых <...> виртуализацию я люблю
и я того же мнения :)
>Если бы сейчас мне предложили проект, который бы получил пользу от гибкости, где нужно было бы конфигурировать типовые машинки с небольшим количеством памяти и CPU — я бы с великой радостью все сделал виртуализированно НО все так же использовал бы PXE,
А я бы клонировал эталонную машину :)
Спасибо за ответ, статья давалась в большей степени как призыв к использованию системы управления конфигурациями, показать на сколько она упрощает жизнь админу.
Как я уже сказал, я совершенно не против виртуализации, но в случае моей инфраструктуры это не вариант по причине серьезных требований к производительности, к тому же данный пост покрывает установку на bare metal, что приходится делать, даже если есть виртуализированные среды.
>Это вы зря :)
Если зря — приношу извинения.
>Отлично работает, если изначально об этом подумать, виртуализация дает отличную масштабируемость и апдейт на новый сервер занимает считанные минуты(если просто замена железки, и диски виртуалок доступны для нового сервера изначально локально), достаточно развернуть гипервизор, и всё, тащи виртуалки туда и давай им больше ресурсов.
Все верно, но мир не идеален, и инфраструктуры переходят по наследству от инженера к инженеру, это тоже нужно понимать :)
>А я бы клонировал эталонную машину :)
Здесь не соглашусь, мое мнение по этому поводу — это лишает гибкости в дальнейшем. Эталонная машина — это еще одно «то» что нужно поддерживать и обновлять достаточно часто, а если начнут появляться требования в различии двух машин — еще чаще.
Господа хабравчане минусуют, но еще кроме Вас не отписался. Надеюсь все понимают, что пост — это часть одного большого целого об использовании системы управления конфигураций puppet в большой инфраструктуре, а не просто пост о том, как поставить винду :)
Как я уже сказал, я совершенно не против виртуализации, но в случае моей инфраструктуры это не вариант по причине серьезных требований к производительности, к тому же данный пост покрывает установку на bare metal, что приходится делать, даже если есть виртуализированные среды.
>Это вы зря :)
Если зря — приношу извинения.
>Отлично работает, если изначально об этом подумать, виртуализация дает отличную масштабируемость и апдейт на новый сервер занимает считанные минуты(если просто замена железки, и диски виртуалок доступны для нового сервера изначально локально), достаточно развернуть гипервизор, и всё, тащи виртуалки туда и давай им больше ресурсов.
Все верно, но мир не идеален, и инфраструктуры переходят по наследству от инженера к инженеру, это тоже нужно понимать :)
>А я бы клонировал эталонную машину :)
Здесь не соглашусь, мое мнение по этому поводу — это лишает гибкости в дальнейшем. Эталонная машина — это еще одно «то» что нужно поддерживать и обновлять достаточно часто, а если начнут появляться требования в различии двух машин — еще чаще.
Господа хабравчане минусуют, но еще кроме Вас не отписался. Надеюсь все понимают, что пост — это часть одного большого целого об использовании системы управления конфигураций puppet в большой инфраструктуре, а не просто пост о том, как поставить винду :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Развертывание сервера на Windows Server 2012 / Dell PowerEdge R420 с использованием puppet