ГЛАВА 1

Инициализация и развертывание

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

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

Автоматизированное развертывание

Система автоматического развертывания устанавливает и настраивает операционные системы без вмешательства после абсолютно минимального объема ручного труда, включающего размещение в стойках, привязка MAC к IP, конфигурирование мощностей и тому подобного. Обычные решения основываются на обертках (wrapper) на основе PXE загрузок и серверов TFTP для установки базовой операционной системы, передаваемой затем автоматизированным системам управления настройкой.

И Ubuntu, и Red Hat Linux содержат механизмы для настройки операционной системы, включающие установку предварительных начальных значений (preseed) и стартеры (kickstart), которые вы можете использовать после сетевой загрузки. Обычно они используются для начальной загрузки системы автоматической настройки. Кроме того можно использовать подход на основе образов для развертывания операционной системы подобный systemimager. В виртуальной инфраструктуре вы можете использовать оба этих подхода, например, в случае,когда у вас раздельно работают VM ваших управляющих служб и физической инфраструктуры.

При создании плана развертывания сосредоточьтесь на нескольких жизненно важных областях, поскольку их очень трудно изменять после развертывания.

Создание дисковых разделов и RAID

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

Вы должны выполнить следующую настройку на жестких дисках серверов:

• Создание дисковых разделов
• Добавление в массив RAID

Простейший вариант заключается в использовании одного жесткого диска с двумя разделами:

• Файловая система
• Пространство свопинга

В данной установке не используется RAID.

Данный вариант не рекомендуется для практического применения, поскольку в случае отказа диска выходит из строя весь сервер. Вместо этого мы рекомендуем использовать более одного диска. Количество дисков определяет какие типы массивов RAID могут быть построены.

Мы рекомендуем вам один из следующих вариантов с несколькими дисками:

• Вариант 1: Единообразно разбиваем на разделы все диски горизонтальным образом, как показано на следующем рисунке:
  В данном варианте вы можете назначить различные разделы различным массивам RAID. Вы можете выделить раздел 1 первого и второго диска для зеркалированного раздела загрузки (/boot). Вы можете сделать раздел 2 всех дисков зеркалированным корневым разделом (root). Вы можете использовать 3й раздел всех дисков для томов cinder-volumes разделов LVM работающих с массивом RAID 10.
  Закончив с неиспользуемыми разделами, такими как 1й раздел на третьем и четвертом дисках, вы могли бы максимально использовать дисковое пространство. Однако, производительность ввода/вывода может испытывать проблемы при использовании всех дисков для всех задач.
• Вариант 2: Добавьте все необработанные (raw) диски в один большой RAID массив на аппаратной или программной основе. Вы можете поделить этот большой массив на области загрузки, корня, свопинга и LVM. Данный вариант прост в реализации и использует все разделы. Однако может пострадать дисковый ввод/вывод.
• Вариант 3: Выделите диски целиком определенным разделам. Например, вы можете выделить один и два диска целиком для разделов загрузки, корня и свопинга под зеркалированный RAID 1. Затем выделите целиком диски 3 и 4 для раздела LVM, также под зеркалированным RAID 1. Дисковый ввод/вывод должен быть лучше, поскольку ввод/вывод сосредоточен на выделенных задачах. Однако, раздел LVM будет много меньшим.
• Вариант 4, Примечание переводчика: вы можете воспользоваться сетевой файловой системой при наличии достаточных (в отношении пропускной способности и латентности) средств коммутации. Это может быть как аппаратно реализованная SAN, так и программно настраиваемые СХД. В первом случае, как правило, для интерфейса используются протоколы SCSI/ Fibre Channel. В последнем случае можно воспользоваться как коммерческим, так и открытым ПО (подробнее: http://www.mdl.ru/Solutions/Put.htm?Nme=GPFS, http://www.mdl.ru/Solutions/Put.htm?Nme=Storage).
  В данном случае задачи оптимизации использования пространства и пропускной способности будут решать средства самой сетевой файловой системы.

Как и в случае большинства вариантов архитектуры, правильный ответ зависит от вашей среды.

Настройка сети

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

Например, обычно вы не можете настраивать сетевые адаптеры для VLAN при PXE загрузке. Кроме этого, как правило, вы не можете выполнять PXE загрузку при связанных сетевых адаптерах. Если вы работаете по такому сценарию, рассмотрите возможность использования простого 1 GB коммутатора в частной локальной сети, в которой работает ваше облако.

Автоматизация настройки

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

Эти средства также позволяют тестировать и откатывать назад изменения, поскольку они являются полностью повторяемыми. Все удобно, в данной области сообществом OpenStack был выполнен большой объем работ. Инструмент управления конфигурациями – Puppet – даже предоставляет служебные модули для OpenStack.

Неотъемлемой частью системы управления настройками являются сами управляемые ею элементы. Вы должны тщательно проанализировать все элементы, которыми вы хотите - или нет управлять автоматически.

Удаленное управление

По нашему опыту, большинство операторов не сидят в непосредственной близости от работающих в облаке серверов, а также многие из них лишены удовольствия посещать центры данных. OpenStack должен быть целиком настраиваемым удаленно, однако иногда не все идет по плану.

При подобных обстоятельствах будет благом иметь зоны доступа к компонентам работающих узлов OpenStack. Стандартом де- факто здесь является протокол IPMI, и для достижения целей центров данных без персонала настоятельно рекомендуется приобретение такого оборудования.

Кроме того, также уделите внимание удаленному управлению питанием. Хотя IPMI обычно управляет состоянием питания, наличие удаленного доступа к блоку распределения питания (PDU), к которому подключен сервер может действительно оказаться полезным для случаев, когда все кажется заклиненным.

Предисловие	Оглавление	Глава 2
Перевод: Copyright © 2014  . All rights reserved. Ссылки обязательны (Refs and links obligatory).		http://www.mdl.ru