Инструкции для сервера Dell: Установка операционной системы на сервере PowerEdge

Сводка: На этой странице описано, как установить новую операционную систему на сервере Dell EMC (PowerEdge). Здесь представлены учебные руководства по использованию Lifecycle Controller для развертывания ОС. Свернуть На этой странице описано, как установить новую операционную систему на сервере Dell EMC (PowerEdge). Здесь представлены учебные руководства по использованию Lifecycle Controller для Развернуть

Содержание статьи

Симптомы

Причина

Разрешение

На этой странице описано, как установить новую операционную систему на сервере Dell (PowerEdge). Здесь представлены учебные руководства по использованию Lifecycle Controller для развертывания ОС.

Как работает развертывание операционной системы?

Список операционных систем, поддерживаемых Dell, меняется с учетом пакетов драйверов, которые обновляются в системе. Чтобы обновить драйверы, скачайте последний пакет драйверов ОС, относящихся к вашему серверу.

Совместимые и поддерживаемые операционные системы для PowerEdge можно проверить по таблице поддержки Dell.
Руководства по операционной системе и руководства по ее установке можно найти на веб-сайте Dell.com/OperatingSystemManuals.

Если операционная система установлена без использования контроллеров Lifecycle Controller, некоторые драйверы будут отсутствовать, и их необходимо установить вручную.

Статьи об установке операционной системы

Как установить операционную систему (Windows, Linux) на сервере Dell? SLN129177
В этой статье описано, как использовать функцию развертывания ОС для установки или переустановки поддерживаемой операционной системы на сервере.
Руководство применимо ко всем поддерживаемым ОС. В большинстве случаев поддерживаются Windows Server, RedHat, SUSE и CentOS. Дополнительные сведения о поддержке см. в таблице поддержки Dell.

Чтобы установить VMware ESXi на сервере Dell, рекомендуется непосредственно выполнить загрузку индивидуально настроенного образа Dell.
В этой статье поясняется, как загрузить образ Dell ESXi? SLN288152 на веб-сайте Dell.

Для удаленной установки ознакомьтесь со следующими двумя статьями:

• Создание загрузочного USB-носителя
• Использование виртуального носителя

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

Список доступных видеороликов

Установка Windows 2016 в режиме UEFI с помощью LifeCycle Controller

Установка VMware ESXi без LifeCycle Controller

Технические статьи по установке операционной системы

• Как загрузить драйверы PERC

При развертывании операционной системы без использования функции развертывания ОС, возможно, драйверы контроллера RAID не будут включены в мастер установки. В результате этого во время установки раздел не отображается.
Инструкции по ручной загрузке драйверов PERC во время установки Windows 2003, 2008 или 2012 описаны в этой статье.

• Как загрузить драйверы USB 3 в ОС Windows 2008 R2

Windows Server до версии 2012 (в том числе WS 2008 R2 с пакетом обновления SP1) изначально не поддерживают USB 3.0. В этой статье описано, как интегрировать драйверы USB 3.0 в Windows Server 2008 R2SP1 для использования на серверах Dell R230, R330, T30, T130, T330.

Развертывание сервера на Windows Server 2012 / Dell PowerEdge R420 с использованием puppet

Задача

Необходимо развернуть сервер со следующими требованиями:

• Массив дисков RAID-10
• Full Performance in BIOS
• Windows Server 2012 с всеми обновлениями и патчами
• Это будущий сервер приложений со службами для которых необходим .net 4.5
• Мониторинг доступности сервера, а также CPU, Памяти и свободного места на диске
• Необходимо подключить сервер к системе выкатки релизов Octopus Deploy

Сложности

Решение

Начнем с того, что все, что у меня сейчас есть — это работающий сервер, который подключен к сети. Я знаю его MAC-Адрес и будущее имя (app8). На нем нет ни операционной системы ни возможности вручную вставить диск. Да чего уж греха таить — диска с виндой у меня тоже нет!

Предстоит сделать следующее:

1. Настроить параметры производительности BIOS
2. Cоздать массив RAID-10
3. Загрузится с PXE в загрузчик pxeboot.com
4. Выбрать соответствующий загрузчик boot.wim и Выбрать требуемую операционную систему
5. Создать логические диски C:\ и D:\
6. Произвести установку операционной системы на диск C:\
7. Произвести конфигурацию сервера под требуемые задачи при помощи puppet

Перед прочтением статьи рекомендуется прочитать соответствующие статьи по подготовке классов puppet, которые используются в этой статье:

• Создание и эффективное использование образов WIM — магия Chocolatey
• Управление правами доступа к WMI через Puppet
• Puppet + Opsview: автоматический мониторинг на основе шаблонов

Наши сервера находятся на колокейшене, который физически далеко, поэтому буду использовать WDS и IP KVM. Доступ к KVM осуществляется через веб интерфейс, сам удаленный «экран» реализован при помощи java-based приложения. По большому счету IP KVM уже не обязателен, т.к. все мои развертывания происходят практически автоматически, но старая привычка наблюдать за происходящим на экране осталась, да и заводские настройки железа не всегда совпадают с требуемыми.

Заходим в BIOS (F2) и настраиваем параметры производительности. Разница между Performance и Performance Per Watt в том, что при использовании Perormance Per Watt сервер автоматически снижает энергопотребление компонентов при простое. Нам такое поведение не нужно, потому что от пониженного энергопотребления мы ничего не выигрываем, а вот от задержки производительности как раз наоборот проигрываем (в тот момент, когда сервер понимает что пора работать на полную мощность но еще не отключил пониженное энергопотребление).

При заказе серверов на сайте Dell также можно заказать сервер с требуемой конфигурацией RAID. Этот конкретный сервер пришел с RAID5, поэтому придется менять конфигурацию. Заходим в утилиту настройки RAID нажатием Ctrl+R на этапе загрузки и создаем массив RAID10 из 4х дисков по 1ТБ, что в итоге дает 2 ТБ «места» для данных. Write-Back и Adaptive Read Ahead — то что нам нужно, оставляем по умолчанию:

Также можно процесс создания верного RAID автоматизировать на этапе установки ОС, используя кастомный загрузчик (будь то WinPE или установщик Linux). Если кто это делал на DELL системах буду рад если поделитесь опытом — самому на это, к сожалению, просто нет времени.

Далее на DHCP задается ip адрес будущему серверу, дается имя. MAC Адрес мне известен, т.к. при приемке оборудования мы фиксируем эту информацию. Как вариант, MAC Адрес можно подсмотреть при загрузке сервера, либо попросить персонал NOC в ДЦ посмотреть его на самом сервере.

Перезагружаем сервер, входим в режим загрузки PXE, после чего нужно подтвердить сервер в WDS, назначить ему имя, а также можно указать загрузчик (pxeboot.com в данном случае). Это действие позволит применить правильную конфигурацию, а также внести сервер в домен, при правильной настройке unattend.xml.

Не забудьте указать в unattend.xml имя и пароль пользователя, который имеет права добавления компьютеров в домен. У меня эти права делегированы специально-созданному для этого сервисному пользователю. Раньше я вручную редактировал unattend.xml, пока не появился Windows AIK (в его предыдущих инкарнациях) — сейчас его можно скачать с официального сайта Microsoft.

После разрешения доступа сервер загружается в соотвествующий загрузчик, где происходит выбр boot образа, а затем и образа самой системы. Я выбираю обновленный образ Server 2012 Standard, который я создал здесь. Boot образ также можно выбрать на этапе подтверждения сервера (там же, где Вы выбираете файл unattend.xml). Необходимо отметить, что boot образ должен содержать соответствующие драйвера контроллера диска и сетевой карты чтобы работать корректно (для Dell — все драйвера находятся на диске OpenManage, их нужно распаковать с помощью специальной утилиты, которая находится там же). Если кому-то интересно как я это делал — дайте знать, буду рад поделиться.

Интересно заметить, у меня есть пара конфигураций с полностью unattended установкой, но я почему-то их не использую, думаю масштаб компании еще не тот, чтобы так сильно типизировать конфигурации Windows серверов — постоянно что-то отличается. (К слову, также есть kickstart конфигурации для Linux, которые использую гораздо чаще, т.к. в основном это кластерные типовые конфигурации).

Итак, настало время выбрать конфигурацию жесткого диска, я ставлю 250G на диск C а остальные 1600G на DATA раздел. Все, процесс пошел. «Можно откинуться на спинку кресла, пока Windows будет устанавливаться на Ваш компьютер» (помню как в полной темноте моя комната была освещена синим цветом света установщика Windows 98. )

Пока ставилась винда я вспомнил что в образе у меня есть сервер VNC, который запускается сразу же после инициализации сети в Windows PE. Жалко так и не смог найти нормальный syslog клиент для урезанной WindowsPE — хочу знать когда VNC стартует, может кто знает?

На этом этапе также выполняются стадии unattend.xml, в том числе регистрация агента puppet.

Итак, винда загрузилась — проверяем доступность (вручную или автоматически), не забываем перезагрузить зоны и очистить dns cache. Eсли откликается по доменному имени — то сервер добавился в домен (если нет — идем на сервер и проверяем что ему не хватет). Ну все, можно приступать к волшебству puppet, так как puppet agent уже должен быть установлен на стадии Microsoft-Windows-Deployment / RunSynchronous.

Подтверждаем сертификат на сервере puppet master, после чего видим такую картину в TheForeman:

Это означает, что наш новый сервер готов к «посвящению» и мы можем применять необходимые нам классы (packages::opsview, packages::octopus-tentacle, packages::logstash::client и любые другие). Заходим в настройки сервера в панели управления TheForeman и выбираем что необходимо:

Вся прелесть puppet в том, что это система управления конфигурации и оркестрации, то есть не важно в каком состоянии находится система сейчас, он должен сделать все, чтобы привести ее к тому состоянию, которое Вы указали. Поэтому, например, для packages::octopus-tentacle он установит необходимые фреймворки, установит пакет, а также в моем случае произведет регистрацию «агента-шупальца» (tentacle) на сервере octopus, и останется только назначить соответствующие группы/проекты на этот сервер (что будем деплоить) — все это конфигурируется Вами, но об этом в другой раз.

Если позволяет время — я люблю запускать puppet agent первый раз вручную прямо на сервере чтобы не ждать очередного puppet run:

После завершения puppet run:

• Установится агент Opsview (основан на NSClient)
• Произведется настройка сервера мониторинга Opsview (пост на хабре)
• Установится и сконфигурируется агент Logstash (ждите пост на хабре, а пока ссылка на демо)
• Установится агент Octopus Deploy и призойдет регистрация агента

Все!

Заключение

Когда я вспоминаю как проходил процесс развертывания сервера вручную — меня берет дрожь. Это CD/DVD диски, это 2 дня (если неспешно, в фоновом режиме) или 1 день (если сфокусироваться и ничего больше не делать) — вот сколько уходило времени! Каждый раз приходилось обновлять систему до актуального состояния. Ведь это работает как «установил, перезагрузил, установил, перезагрузил»… А если это 10 или 20 или 100 серверов? Про мелкие настройки и твики вообще молчу.

Я знаю что это делается проще и удобнее с MS SCCM, установка софта — через group policy, и может я бы так и сделал, если бы не смешанность среды, где Windows мирно живет с Linux под присмотром одного единственного IT отдела. Puppet — это, на мой взгляд, универсальное средство. Puppet спасает мне жизнь, а также я приучаю к его использованию наших разработчиков (а они — C# ребята). К числу преимуществ относится то, что конфигурационный манифест puppet — это программный код, который можно хранить в системе контроля версий (git, например), а также легко распространять! (дискуссии по поводу IaaC приветствуются). Я не знаю альтернатив, которые могли бы объединить всевозможные породы ОСей из гетерогенной среды в одно единое описание инфраструктуры, а Вы? Также я не знаю удобной системы от Microsoft которую можно было бы хранить под Source Control и удобно распространять. Если кто что знает — буду рад услышать в комментах.
За сим откланиваюсь, пора делать другие дела!

UPDATE: Всем минусующим — огромная просьба отписываться либо не минусовать вообще.

Читают сейчас

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Octopus Deploy. Улучшаем мир в кровавом энтерпрайзе

Конвергенция в тренде: архитектура Dell PowerEdge FX

Поколение 13, четвертая волна: серверы Dell PowerEdge начального уровня

Вакансии

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Минуточку внимания

Комментарии 7

По поводу кучи серверов и нахлабучивания из разносолов — виртуализация нас спасёт, много физических серверов это гемморой. 10 физически немощных сервачков лучше разместить ввиде виртуалок на 1м нормальном, и утилизация железа хорошая, и в случае смерти железки всегда можно бекапы виртуалок(а если образа дисков хранились на отдельной дисковой полочке, то считай, почти без потерь) тут же оживить в другом месте. При определенных условиях уже можно кластер поднять из нескольких нод, для пущей надежности.

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 года.

>Во-первых, iDrac никогда не заменит массовую установку через pxe. Представьте, у Вас под 200 серверов,
Образ готовой системы можно разворачивать как угодно, в данном случае просто поинтересовался, что так заморачивались с IPKVM, т.к. про Express лицензию iDrac ни слова в статье
>Во-вторых, изначально IP KVM
Вкурсе

>Вы почему-то рассматриваете инфраструктуру «с нуля»
Такие вещи всегда планируют, что тут обсуждать

>Не до конца понимаю как Вы видите мою инфраструктуру сидя за монитором, что беретесь судить о том, как «на деле»:
>>На деле, парк из сотен физических серверов разносольным никто не делает
Тут не о вашей инфраструктуре, а из статьи:

А если это 10 или 20 или 100 серверов?

>В-третьих, я продолжаю слышать нотки теории в Вашем комментарии.
Это вы зря 🙂

>Другая несостыковка — это не работает в среде стартапа, где темпы роста компании намного больше чем возможность оглянуться назад и сделать рефакторинг.

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

>К тому же со стороны сервиса надежность железного сервера выше чем надежность 10 виртуалок на 1м сервере, потому что на один сервис приходится один полностью, как минимум, вдвойне зарезервированный (redundant) сервер (CPU, Memory, PSU), в то время как в соотношении 10:1 на каждую виртуалку приходится только часть зарезервированного сервера, но я думаю это и так понятно что это означает.

Используйте кластеры виртуализации, либо более простое: если железка упала — включаешь всё на резервной, и ставить ничего не надо, нажал вкл и оно запустилось. Так же, надежность надежностью, а развернуть заново виртуалку можно в разы быстрее, и не важно их кол-во.

>В-четвертых, с чего Вы взяли что в моей боевой среде нужны «физически немощные сервачки»?
«Сервачок» в контексте виртуализации, это скорее сервис или задача.

>В-пятых виртуализацию я люблю
и я того же мнения 🙂

>Если бы сейчас мне предложили проект, который бы получил пользу от гибкости, где нужно было бы конфигурировать типовые машинки с небольшим количеством памяти и CPU — я бы с великой радостью все сделал виртуализированно НО все так же использовал бы PXE,

А я бы клонировал эталонную машину 🙂

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

>Это вы зря 🙂
Если зря — приношу извинения.

>Отлично работает, если изначально об этом подумать, виртуализация дает отличную масштабируемость и апдейт на новый сервер занимает считанные минуты(если просто замена железки, и диски виртуалок доступны для нового сервера изначально локально), достаточно развернуть гипервизор, и всё, тащи виртуалки туда и давай им больше ресурсов.
Все верно, но мир не идеален, и инфраструктуры переходят по наследству от инженера к инженеру, это тоже нужно понимать 🙂

>А я бы клонировал эталонную машину 🙂
Здесь не соглашусь, мое мнение по этому поводу — это лишает гибкости в дальнейшем. Эталонная машина — это еще одно «то» что нужно поддерживать и обновлять достаточно часто, а если начнут появляться требования в различии двух машин — еще чаще.

Господа хабравчане минусуют, но еще кроме Вас не отписался. Надеюсь все понимают, что пост — это часть одного большого целого об использовании системы управления конфигураций puppet в большой инфраструктуре, а не просто пост о том, как поставить винду 🙂