ГЛАВА 6

Выбор соответствующих аппаратных средств.

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

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

Список минимальной аппаратуры, требующейся для реализации Swift включает в себя:

Элемент	Описание
Серверы хранения	Это реальные сервера, на которых исполняется программное обеспечение серверов объектов, а также обычно и программное обеспечение серверов учетных записей и контейнеров. Сервера хранения требуют диски для хранения объектов.
Сервер(ы) прокси	Это реальные сервера, на которых исполняется программное обеспечение серверов прокси. Требуется по крайней мере один.
Сетевой(ые) коммутатор(ы)	Глава 3.Установка OpenStack Swift описывает различные необходимые сети. Требуется, по крайней мере, один коммутатор.

Ниже приводится список опциональных аппаратных средств, которые вы можете приобрести:

Элемент	Описание
Серверы учетных записей	Для больших установок, в которых списки контейнеров и обновления подавляют сервера хранения, могут потребоваться отдельные сервера учетных записей.
Серверы контейнеров	Для больших установок, в которых списки объектов и обновления подавляют сервера хранения, могут потребоваться отдельные сервера контейнеров.
Серверы авторизации	Для больших установок, в которых авторизация подавляет прокси сервера, могут потребоваться отдельные сервера учетных записей.
JBOD	Для установок, в которых важна большая плотность дисков, сервера хранения могут быть соединены с JBOD(just a bunch of disks, массивом независимых дисков) с использованием соединения SAS для увеличения плотности дисков.
Балансировщик нагрузки /ускорители SSL	Полезно предоставлять один IP адрес всему кластеру (существуют программные средства, реализующие такой механизм, однако его описание выходит за рамки данной книги. Прим. пер.: см., например, http://nginx.org/ru/) Функциональность SSL в балансировщике нагрузки разгружает программное обеспечение SSL прокси- сервера.
Оборудование межсетевого экрана и безопасности	Для общедоступных сетей, сетей сообществ и некоторых частных сетей, в зависимости от политики безопасности вашей компании, могут потребоваться межсетевые экраны и аппаратура обеспечения безопасности, например такая, как средства обнаружения/ предотвращения вторжений.
Локальный шлюз облака	Для адаптации приложений, пока не перенесенных пока на REST HTTP API, вам потребуется устройство преобразования протокола, которое преобразует обычные протоколы файлового и блокового обмена в REST API. Такие устройства называются шлюзами облака и являются только частью оборудования, которое может понадобиться даже для общедоступного облака.

Чтобы еще более усложнить задачу, каждый сервер имеет следующие конструктивные элементы, подлежащие настройке:

• Производительность ЦПУ: Производительность ЦПУ описывается в терминах числа процессоров и числа ядер в процессоре. Она имеет наиболее прямое влияние на производительность сервера.
• Оперативная память: Следующим важнейшим элементом рассмотрения является количество DRAM памяти (динамической памяти), которая описывается в ГигаБайтах.
• Флэш- память: Флэш- память является другим элементом, критичным для производительности и обычно находится в диапазоне ТераБайтов.
• Диски /JBOD: Для серверов хранения вы должны описать число дисков и тих типы (интерфейсы, скорости, рейтинги и т.л.). Эти диски могут находится в серверах, подключаться через JBOD-ы, или в их комбинации.
• Устройства сетевого ввода/вывода: Серверы требуют подключений сетевого ввода/вывода через LAN-on moterboard (LOM) (сетевой порт на материнской плате) или устройство расширения network interface card (NIC) (сетевую плату). Это обычно 1Gbps (Гигабит в секунду) или 10Gbps в терминах скорости передачи данных.
• Управление аппаратурой: Серверы различаются по функциям управления аппаратными средствами: начиная с исключительно рудиментарного мониторинга через средства операционной системы, независимых от операционных систем IPMI, вплоть до сложных дистанционных KVM и удаленных систем хранения.

Критерии выбора аппаратных средств

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

• Место оптимизации в вашей среде: Вам необходимо будет выбрать о чем вы будете больше заботиться: о производительности или стоимости.
• Масштаб: Масштаб также имеет огромное влияние на выбор аппаратных средств. Для простоты будем говорить о маленьком в диапазоне сотен ТераБайт, средний находится в пределах ПетаБайт и большой начинается с десятков ПетаБайт и выше. Вы должны определиться: в каком диапазоне вы находитесь.

Процесс выбора аппаратных средств следующий.

Шаг 1 - выбор конфигурации сервера хранения

Для малых и средних реализаций сервер хранения может содержать в себе программное обеспечение серверов объектов, учетных записей и контейнеров. Для больших систем мы бы рекомендовали выделить сервера учетных записей и/или контейнеров. Для оптимизируемых под производительность кластеров совокупная производительность дисковых систем должна соответствовать общей производительности других компонентов серверов (ЦПУ, оперативной памяти, флеш- памяти и систем ввода/ вывода). Для оптимизирующих стоимость кластеров, производительность дисковых систем должна должна превосходить производительность других компонентов (другими словами, экономим деньги, зажимая производительность). На самом деле, рассмотрите возможность подключения JBOD для получения на практике высокой плотности дисков.

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

Руководство по настройке OpenStack (http://docs.openstack.org/havana/install-guide/install/apt/content/object-storage-system-requirements.html) рекомендует следующую спецификацию сервера:

• Процессор: Два четырехядерных.
• Оперативная память: от 8 до 12ГБайт.
• Сетевой ввод/вывод: 1 x 1Гбит/сек (Gbps) NIC. Ограничивается доступным бюджетом, наша рекомендация будет выходить за рамки официальной рекомендации и состоит в использовании 10Gbps.

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

Наконец, ключевым фактором является тип диска: уровня предприятия или рабочего места. В рамках дисков уровня предприятия (enterprise) существуют диски с 15K, 10K или 7.2K оборотами в минуту (RPM, rotations per minute) и различными конфигурациями емкости. Для малых и средних реализаций вы можете захотеть выбрать диски уровня предприятия, поскольку они более надежны, чем диски для рабочих мест. Малые и средние системы, как правило, не настраиваются на обработку большой интенсивности отказов дисков уровня рабочих мест. Производительность и емкость, которые вы выбираете для дисков уровня предприятия, очевидно, зависят от ваших конкретных требований.

Для больших систем, которые также являются очень чувствительными к стоимости, вы можете захотеть рассмотреть возможность использования дисков уровня рабочих мест. Высокая емкость дисков уровня рабочих мест (до 6ТБ на момент написания) также вносит вклад в выгоду для больших реализаций. В дополнение к вопросам надежности, диски уровня рабочих мест не предназначены для работы в режиме 24 x 7. Это означает, что ИТ- персонал должен иметь достаточную квалификацию, чтобы справляться с большим числом отказов и/или остановов дисков для соответствия спецификации.

Шаг 2 - определение настроек регионов и зон

Далее мы должны определиться с регионами и зонами. Чило регионов произрастает из желаниязащитить данные от катастрофы или приблизить данные к источникам, потребляющим их. Как только мы определились с числом регионов, выберите число зон для каждого региона. По крайней мере, вы должны иметь такое количество зон, сколько есть реплик. Мы рекомендуем иметь не менее трех зон, а Rackspace рекомендует пять (http://docs.openstack.org/havana/install-guide/install/apt/content/example-object-storageinstallation-architecture.html). Кластеры малых размеров могут удовлетвориться четырьмя. Ознакомьтесь, пожалуйста, с Главой 2, Архитектура OpenStack Swift для уточнения определений регионов и зон.

Шаг 3 - выбор конфигурации сервера учетных записей и контейнеров

Как уже упоминалось ранее, если вы не устанавливаете большую конфигурацию, вам не следует беспокоиться об отдельных серверах учетных записей и контейнеров. Путем подбора правильных объемов оперативной памяти и флеш- памяти для отдельных серверов учетных записей и/или контейнеров вы должны убедиться, что производительность SQLite достаточна для соответствия требованиям ваших спсиков баз данных и обновлений. Руководство по настройке OpenStack рекомендует следующие спецификации (вы можете уменьшить требования на основе размера вашего кластера и требований производительности):

• Процессор: Два четырехядерных.
• Оперативная память: От 8 до 12ГБайт.
• Сетевой ввод/вывод: 1 x 1Гбит/сек (Gbps) NIC. Ограничивается доступным бюджетом, наша рекомендация будет выходить за рамки официальной рекомендации и состоит в использовании 10Gbps.
• Флеш- память: Не специфицирована. Зависит от требований производительности пользователя.

Шаг 4 - выбор конфигурации прокси- сервера

В общем случае прокси- сервер должен соответсвовать количеству запросов API. Как обсуждалось в Главе 2, Архитектура OpenStack Swift, дополнительные модули программного обеспечения промежуточного уровня могут также работать на прокси сервере. Следовательно, прокси- сервер должен удовлетворять уровню производительности, соотвествующему такой нагрузке. Использование нескольких можных прокси- серверов в противоположность большому числу "хилых" серверов более эффективно со стоимостной точки зрения, как было доказано Zmanda (http://www.zmanda.com/blogs/?p=774). Мы готовы согласиться с руководством по настройке OpenStack, которое рекомендует следующие спецификации:

• Процессор: Два четырехядерных.
• Сетевой ввод/вывод: 1 x 1Гбит/сек (Gbps) NIC. Нашей рекомендацией будет наличие по крайней мере двух NIC, одна для внутреннего кластера хранения и одна для трафика развернутого в сторону клиента (API). 1Гбит/сек - требование, вытекающее из ограничения бюджета, наша рекомендация будет выходить за рамки официальной рекомендации и состоит в использовании 10Gbps. Также ознакомьтесь со связанным с этим обсуждением SSL в разделе Шаг 7 - выбор дополнительного сетевого оборудования, которое влияет на сетевой ввод/вывод.

Если прокси- сервер выполняет большой набор программного обеспечения среднего уровня, рассмотрите перемещение некоторого объема из этого набора на выделенный сервер. Наиболее часто выносимым на отдельный сервер программным обеспечением среднего уровня является программное обеспечение авторизации.

Шаг 5 - Выбор сетевых аппаратных средств

Существует три упоминавшиеся ранее сети - развернутая в сторону клиента (API), внутренняя сеть кластера хранения и сеть репликаций. Знакомьтесь с Главой 3, Установка OpenStack Swift для понимания ахитектуры этих трех сетей. Они могут быть комбинацией 1Gbps, 10Gbps или гибридными коммутаторами ethernet 1/10Gbps. Ниже приведены некоторые методы калибровки, связанные с производительностью.

• Развернутая в сторону клиента сеть: Сетевой ввод вывод этой сети определяется требованиями пропускной способности всего кластера. Наприме, если ваш кластер имеет 10 прокси- серверов и имеет размеры, достаточные для обеспечения 10000 запросов ввода/вывода в секунду размером 1МБайт каждый, то очевидно, что каждый прокси- сервер должен иметь 10Gbps сетевые возможности ввода/вывода.
• Внутренняя сеть кластера хранения: Требования к этой сети зависят от общей пропускной способности кластера и его размера. Размер кластера имеет значение, так как кластер генерирует большой объем обмена компонентами завершающего программного обеспечения (см. Главу 2, Архитектура OpenStack Swift). Как уже упоминалось в стоимостных ограничениях, мы рекомендуем использовать 10Gbps сети.
• Сеть репликаций: Данная сеть зависит от общей пропускной способности записи и размера кластера. Например, вы ожидаете 1000 запросов на запись в секунду, причем каждый имеет размер 1КБайт, с этой работой справится сеть 10Mbps.

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

Шаг 6 - выбор соотношений между серверами различного типа

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

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

Например, предположим, что вы хотите увеличивать кластер примерно с шагом в 1ПетаБайт сырых данных с плотной конфигурацией. Вы можете рассмотреть блок аппаратуры с одним сервером прокси, 2 x 10Gbps коммутаторами, одним управляющим коммутатором и пятью серверами хранения с 60 дисками по 4ТБ каждый (т.е. 240 x 5 = 1.2ПБ). Принимая во внимание предыдущее замечание о необходимости по крайней мере двух серверов прокси, начальная установка должна иметь 2.4ПБ. При трех репликах 1.2ПБ сырых данных переводится в 400ТБ используемых данных. Данный пример не является совершенным, поскольку он может не быть кратным обему стойки, но мы приводим его с точки зрения иллюстрации

Шаг 7 - Выбор дополнительного сетевого оборудования

Окончательный шаг заключается в выборе балансировщика нагрузки, аппаратуры ускорения SSL и оборудования обеспечения безопасности. Балансировщик нагрузки требуется в том случае, если у вса есть более одного узла прокси. Более того, вы должны быть уверены, что балансировщик нагрузки не является бутылочным горлышком производительности. Аппаратура ускорения SSL требуется в случае, если большая часть сетевого обмена идет в безопасном режиме HTTP (HTTPS) и операции программного обеспечения SSL перегружают серверы прокси. Наконец, если облако находится в общедоступной сети, требуется оборудование обеспечения безопасности, подобное IPS и IDS. Аналогично балансировщику нагрузки эти дополнительные элементы оборудования должны иметь достаточную производительность, чтобы соответствовать требованиям общей производительности всех серверов прокси. Следующий рисунок обозначает дополнительное сетевое оборудование, необходимое вашему кластеру Swift:

Шаг 8 - выбор шлюза облака

Эта часть оборудования является третьм лишним. Она не требуется для построения кластера OpenStack. Вместо этого оно необходимо на входе (в случае общедоступного облака) или около приложения (в случае частного облака) в случае, если ваше приложение пока не портировано под REST HTTP API. В этом случае приложение ожидает традиционную блочную или файловую систему хранения, которая преобразуется такими шлюзами облака. Шлюз осуществляет трансляцию протокола и интерфейсы с облаком на другой стороне. Помимо трансляции протокола, шлюзы облака часто добавляют ряд других особенностей, таких как оптимизация WAN, сжатие, исключение дублирования и кодирование.

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

Дополнительные критерии выбора

В дополнение к предыдущим критериям, следующие элементы должы быть рассмотрены перед окончанием выбора аппаратных средств:

• Надежность: Надежность (долговечность) измеряет достоверность и определяется как 100 процентов минус вероятность потери объекта размером в 1КБайт за один год. Следовательно, 99.999999999 процентная надежность (проще говоря, как 11 х 9 в данном случае) будет означать, что каждый год вы, согласно статистике, вы теряете один объект если у вас есть 100 миллиардов объектов с размером 1КБайт, или, при наличии 10000 объектов, ожидаете потерб одного объекта каждые 10`000`000 лет. Вычисление надежности кластера выходит за рамки данной книги, однако выбираемое оборудование должно отвечать вашим требованиям надежности. Для пользователей, которым требуется высокая надежность предметом рассотрения являются диски корпоративного уровня с низкой плотностью, серверы с дублированной системой охлаждения и электропитаня и т.п.
• Доступность: Доступность определяется как процент времени, в течение которого запросы успешно выполняются в кластере. Доступность в основном влияет на архитектуру сети пользовательского интерфейса с точки зрения наличия единой сети (т.е. одной точки отказа) в противоположность сети с избыточным дублированием. Как уже упоминалось ранее, сети в данной зоне могут быть сетями с одной точкой отказа, если только ваш ИТ- персонал способен быстро устранять возникающие проблемы.
• Наработка на отказ: (Эксплутационная надежность, работоспособность). Исправность различных компонентов оборудования сильно зависит от вашей стратегии. Если вы выбираете обслуживание на месте (типичное для больших установок), эксплутационная надежность не является большой проблемой. Если вы выбираете стратегию ремонт/ обслуживание (что типично для малых и средних реализаций), эксплутационная надежность должна рассматриваться. Каждое устройство должно подлежать восстановлению или обслуживанию. Меньший размер системы может также побудить выбор более дорогостоящего оборудования при подборе вентиляторов с резервированием, блоков питания и тому подобного. Причина заключается в том, что в случае возникновения отказа просто может не оказаться запасных устройств доступных для выбора из кольца Swift.
• Управляемость: Как уже обсуждалось ранее, серверы поступают с самыми разнообразными особенностями когда они подключаются к системам аппаратного управления и связанного с ними программного обеспечения. Вам следует выбирать сервера с опциями управления, соответствующими вашей ИТ-стратегии.

Стратегия выбора производителя

Если вы действительно хотите стать веб- гигантом, вы должны покупать аппаратные средства у оригинальных производителей оборудования (ODM) и прочих производителей стандартного оборудования (либо непосредственно, или через системных интеграторов). Вопросы, на которые вы должны ответить сами себе следующие:

Вопрос	Да для всех вопросов	Нет хотя бы для одного вопроса
Можете ли вы определить конфигурацию каждого сервера с учетом производительности, надежности, доступности, наработки на отказ и управляемости (в противоположность необходимости помощи инженеров по продажам производителя)? Можете ли вы самостоятельно (т.е., если вы получаете вызов в 2 часа ночи, готовы ли вы определить основные причины происшествия, или вам необходима помощь производителя)? Готовы ли вы принять менее искушенные условия обслуживания, периоды освоения новой продукции, политики прекращения выпуска и прочие темины? Достаточны ли вам минимальные возможности, предоставляемые производителем на оборудование и программное обеспечение?	Вы готовы к использованию стандартного оборудования!	Вы должны использовать фирменные аппаратные средства.

Фирменное оборудование

Если вы выбрали подход оснащения фирменным оборудованием, процесс достаточно прост и включает выдачу запроса на установление цены (RFQ, requets for quotation) вашему любимому производителю серверов, такому как HP, Dell, IBM и Fujitsu или производителю сетевого оборудования такому как Cisco, Juniper и Arista с последующим выбором того, что вам понравилось.

Стандартное оборудование

Если вы идете по этому пути, то существует множество производителей, изикоторых вы можете выбирать - от тайваньских ODM и прочих специалистов по аппаратуре хранения, таких как Xyratex, Sanmina, Mdl. Возможно, наиболее интересный вариант, это поиск в движении с аппаратурой с открытым исходным кодом под названием Open Compute Platform (OCP)

Согласно их вебсайту, http://www.opencompute.org, миссия OCP состоит в разработке и предоставлении самых эффективных серверов, систем хранения и оборудования центров данных, разрабатываемых для масштабируемого компьютинга. Все участники OCP работают с open source. Множество производителей продают OCP-совместимые аппаратные средства, и подобная совместимость делает несколько более простым для пользователя выбор совместимого оборудования у большого количества произодителей.

Например, OCP Intel Motherboard Hardware v2.0 поддерживает два ЦПУ, четыре канала оперативной памяти DDR3 на ЦПУ, мини- SAS порт для потенциального расширения JBOD, 1Gbps сетевой ввод/вывод и ряд свойств управления аппаратными средствами. Он также может допускать NIC мезанинную плату PCIe для 10Gbps сетевого ввода/вывода. Такой сервер может подойти и для сервера прокси и для сервера хранения (с различными кстановленными компонентами).
(Прим. пер.: Также см., например, Примеры реализации облака на аппаратуре различных вендоров c рекомендованными к продаже ценами производителей. Другой подход: OpenPOWER).

Другой пример, OCP OpenVault JBOD является 2U шасси, которое может содержать в себе до 30 дисков. Это может сделать его удобным спутником для серверов хранения с большой плотностью. (Прим. пер.: Также см., например, СХД на 50 дисков с JBOD до 60 дисков).

Заключение

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

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