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

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

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

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

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

• Добавление в массив RAID (RAID используется для сокращения избыточного массива независимых дисков, redundant array of independent disks), основывающееся на имеющемся у вас в наличии количестве дисков, таким образом, что вы можете добавлять емкость по мере роста вашего облака. Некоторые варианты подробнее описывабтся далее по тексту.

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

• Файловой системой для хранения файлов и каталогов, в которых располагаются все данные, включая корневой раздел, который стартует и запускает систему

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

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

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

Вариант 1

Единообразно разбиваем на разделы все диски горизонтальным образом, как показано на следующем Рисунке 2.1. “Создание разделов дисков”.

В данном варианте вы можете назначить различные разделы различным массивам RAID. Вы можете выделить раздел 1 первого и второго диска для зеркалированного раздела загрузки (/boot). Вы можете сделать раздел 2 всех дисков зеркалированным корневым разделом (root). Вы можете использовать 3й раздел всех дисков для томов cinder-volumes разделов LVM работающих с массивом RAID 10.

 

Рисунок 2.1. Создание разделов дисков

Источник рисунка

Покончив с неиспользуемыми разделами, такими как 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). В данном случае задачи оптимизации использования пространства и пропускной способности будут решать средства самой сетевой файловой системы.}

	Совет
	Вы можете найти возможным полностью автоматизировать создание разделов. Например, MIT использует Fully Automatic Installation (FAI) для первоначального создания разделов на основе PXE а затем выполняет установку с применением комбинации создания разделов min/max и основанных на процентах.

Как и в случае большинства вариантов архитектуры, правильный ответ зависит от вашей среды. Если вы используете существующие аппаратные средства, вызнаете дисковую плотность своих серверов и можете определить некоторые решения на основании приведенных выше вариантов. Если вы собираетесь выполнить процесс покупки, то требования ваших пользователей также могут помочь вам определить закупаемое оборудование. Вот некоторые примеры из частного облака, предоставляемого веб- разработчикам пользовательских сред компанией AT&T. Это пример конкретной реализации, так что ваше существующее оборудование или закупка могут отличаться от него.AT&T использует три различных типа оборудования для развертывания:

• Оборудование для узлов контроллера, используется для всех служб OpenStack API без запоминания состояния. Примерно 32–64 ГБ оперативной памяти, подключенный диск маленького размера, один процессор, различное число ядер, например, 6–12.

• Оборудование для вычислительных узлов. Обычно 256 или 144 ГБ оперативной памяти, два процессора, 24 ядер. 4–6 ТБ напрямую подключаемого дискового пространства, обычно в конфигурации RAID 5.

• Оборудование для узлов хранения. Обычно для них дисковое пространство оптимизировано в отношении минимальности стоимости за ГБайт системы хранения, при сохранении эффективности в плотности стоек.

Примечание переводчика: Сопоставление рекомендуемых производителями к продаже цен (без учета возможных скидок), проведенное в августе 2014г в Москве, компанией Модуль- Проекты для типового универсального облака приложений с 68 серверами приведено в файле, доступном по адресу http://www.mdl.ru/Solutions/MdlCloud/68nodesReferences20140822.xls. Часть предлагаемой аппаратуры уже предполагает наличие процессоров Intel 2600 v3 и ОЗУ 256ГБ. Подробности и более современные предложения вы можете получить у нас по запросу.

Опять же, правильный ответ зависит от вашей среды. Вы должны принимать решение на основании компромисса между использованием пространства, простотой и производительностью операций ввода/вывода.

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

Эти средства также позволяют тестировать и откатывать назад изменения, поскольку они являются полностью повторяемыми. Все удобно, в данной области сообществом OpenStack был выполнен большой объем работ. Инструмент управления конфигурациями – Puppet – даже предоставляет служебные модули для OpenStack, известные как Stackforge. Средство управления настройкой Chef предоставляется https://github.com/stackforge/openstack-chef-repo. Дополнительные системы управления настройкой включают в себя Juju, Ansible и Salt. Также PackStack является утилитой командной строки Red Hat Enterprise Linux и производных систем, которая использует модули Puppet для поддержки быстрого развертывания OpenStack на существующих серверах поверх соединений SSH.

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

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

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

	Совет
	Для дальнейшего изучения развертывания OpenStack, изучите сопровождаемые компаниями и документированные предварительно настроенные и собранные в пакеты установщики для OpenStack от таких производителей, как Canonical, Cisco, Cloudscaling, IBM, Metacloud, Mirantis, Piston, Rackspace, Red Hat, SUSE, и SwiftStack.

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