С 1991 года на компьютерном рынке России 		e-mail

т.: 676 0965, 676 0396
Москва, Сосинская ул. 43,
м. Волгоградский проспект
Реализация облачного хранилища с OpenStack Swift.

ГЛАВА 7

Настройка вашей установки Swift.

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

Тестирование производительности

Существуют различные интсрументальные средства, которые могут быть использованы для тестирования производительности вашего кластера Swift при различных определенных нагрузках. COSBench, ssbench и swift-bench являются наиболее популярными доступными средствами. В то время как swift-bench (https://pypi.python.org/pypi/swift-bench/1.0) используется как часть проекта Swift и, следовательно, является наиболее общим, используемым по умолчанию инструментом тестирования, данная глава обсуждает COSbench, принимая во внимание полноту этого средства и наличие графического интерфейса пользователя в этом инструменте.

COSBench является инструментом тестирования распределенной производительности с открытым кодом для систем хранения объектов. Она разрабатывается и поддерживается Intel. COSBench поддерживает большое разнообразие систем хранения объектов, в том числе OpenStack Swift.

Физическая конфигурация COSBench показана на следующей диаграме:

Физическая конфигурация COSBench Физическая конфигурация COSBench

Основными компонентами COSBench являются:

  • Драйвер (также называемый драйвером COSBench или генератором нагрузки):
    • Отвечает за генерацию рабочей нагрузки, выдачи операций к целям в облачном хранилище объектов и сборе статистик производительности
    • В нашем тестовом окружении драйверы были доступны через
      http://10.27.128.14:18088/driver/index.html и
      http://10.27.128.15:18088/driver/index.html
  • Контроллер (также называемый контроллером COSBench):
    • Отвечает за координацию драйверов для коллективного выполнения нагрузки, сбора и агрегирования состояний исполнения или результатов тестирования от экземпляров драйвера, а также принятия заявок на рабочую нагрузку
    • В нашем тестовом окружении доступен через
      http://10.27.128.14:19088/controller/index.html

Критическим элементом, которое мы должны держать на контроле когда мы начинаем работу с COSBench, заключается в обеспечении того, что машины драйвера и контроллера не станут по небрежности бутылочным горлышком производительности. Эти узлы должны иметь адекватные ресурсы.

Далее, параметры тестирования тесно увязаны с вашим случаем применения и онидолжны быть установлены соответствующим образом. Глава 8, Дополнительные ресурсы исследует случаи использования более детально, однако пара примеров связанных с тестированием следующие:

  • Разделение и совместное использование аудио- файлов: Это случай горячего использования данных при котором вы можете захотеть установить соотношение запросов на чтение к запросам на запись как относительно высокое, например, 80 процентов. Скорость доступа к контейнерам и объектам может быть относительно малой (десятки запросов в секунду) при относительно больших объектах (скажем, с размером в сотни МБайт или более на объект).
  • Архивирование документов: Это случай несколько прохладного использования данных, при котором вы можете захотеть относительно низким соотношение запросов на чтение к запросам на запись, например, 5 процентов. Скорость доступа к контейнерам и объектам может быть высокой (в сотнях запросов в секунду) при среднем размере объектов (скажем, с размеров 5МБайт на объект).

Запомните эти модели, поскольку мы к ним будем обращаться.

При установке нашего теста COSBench была использована операционная система Ubuntu 12.04. Система также имела JRE, unzip и cURL, установленные до установки COSBench версии 0.3.3.0 ((https://github.com/intel-cloud/cosbench/releases/tag/0.3.3.0). Установка очень легкая, как вы можете убедиться в следующих простых шагах:
unzip 0.3.3.0.zip
ln -s 0.3.3.0/ cos
cd cos
chmod +x *.sh

ПОдробнее об установке и проверке того, что программное обеспечение было установлено правильно можно узнать в руководстве пользователя COSBench, расположенной по адресу: https://github.com/intel-cloud/cosbench. При установленном COSBench пользователь имеет доступ к набору сценариев. Некоторые из этих сценариев следующие:

  • start-all.sh / stop-all.sh: Используется для запуска/останова и контроллера, и драйвера на текущем узле
  • start-controller.sh / stop-controller.sh: Используется для запуска/останова только контроллерf на текущем узле
  • start-driver.sh / stop-driver.sh: Используется только для запуска/останова драйвера на текущем узле
  • cosbench-start.sh / cosbench-stop.sh: Это сценарий для внутреннего использования, вызываемый предыдущими сценариями
  • cli.sh: Используется для манипулирования рабочей нагрузкой с использованием коммандных строк.

Контроллер может быть настроен с помощью файла conf/controller.conf, а драйвер может быть настроен с помощью файла conf/driver.conf. Драйверы могут быть запущены на всех узлах драйверов с использованием сценария start-driver.sh, в то время как контроллер может быть запущен только на узле контроллера с использованием сценария startcontroller.sh

Далее мы должны создать рабочую нагрузку. Рабочая нагрузка может рассматриваться как один полный эталонный тест. Рабочая нагрузка (workload) состоит из рабочих стадий. Каждая рабочая стадия (workstage) состоит из элементов заданий. Наконец, элементы задания (work) состоят из операций. Каждая workload может иметь более одной workstage, которые выполняются последовательно. Workstage может иметь более одного элемента work, которые выполняются одновременно.

Существуют нормальный тип (main) и четыре специальных типа (init, prepare, cleanup и dispose) work. Тип main является тем, на чем мы сосредоточим оставшееся обсуждение; основными параметрами для этой фазы являются:

  • workers для описания числа исполнителей, используемых для одновременного выполнения заданий и, таким образом, управления генерацией нагрузки
  • runtime (плюс rumpup и rumpdown), totalOps и totalBytes используются для управления другими параметрами генерируемой нагрузки, включающими то как начинать и заканчивать work

Фаза main имеет операции read, write и delete. Обычно вы хотите определить число подлежащих записи контейнеров и объектов, а также размеры объектов. Числа и размеры описываются как выражения и доступно разнообразие параметров, такое как constant, uniform и sequential (постоянный, однородный и последовательный).

Рабочая нагрузка описывается файлом XML. Сейчас мы создадим рабочую нагрузку, которая формируется после использования модели архивирования документо, обсуждавшейся ранее. Она использует отношение рабочей нагрузки 95 процентов записей и 5 процентов чтений. Драйверы будут порождать 128 исполнителей на промежуток времени в один час; размер объекта статичный в 5МБайт и будет создано 100 объектов. Рабочая нагрузка выглядит следующим образом:
<?xml version="1.0" encoding="UTF-8"?>
<workload name="LTS2-UAT-V1-128W-5MB-Baseline" description="LTS2 UAT
workload configuration">
<auth type="swauth" config=" ;password=xxxx;url= >username=8016-
2588:evault-user@evault.com https://auth.lts2.evault.com/v1.0"/
<storage type="swift" config=""/>
<workflow>
<workstage name="init" closuredelay="0">
<work name="init" type="init" workers="16" interval="20"
division="container" runtime="0" rampup="0" rampdown="0"
totalOps="1" totalBytes="0" config="containers=r(1,32)">
<operation type="init" ratio="100" division="container"
config="objects=r(0,0);sizes=c(0)B;containers=r(1,32)"
id="none"/>
</work>
</workstage>
<workstage name="prepare" closuredelay="0">
<work name="prepare" type="prepare" workers="16"
interval="20"
division="object" runtime="0" rampup="0" rampdown="0"
totalOps="1" totalBytes="0"
config="containers=r(1,32);objects=r(1,50);
sizes=u(5,5)MB">
<operation type="prepare" ratio="100" division="object"
config="createContainer=false;containers=r(1,32);
objects=r(1,50);sizes=u(5,5)MB" id="none"/>
</work>
</workstage>
<workstage name="normal" closuredelay="0">
<work name="normal" type="normal" workers="128"
interval="20"
division="none" runtime="300" rampup="100" rampdown="0"
totalOps="0" totalBytes="0">
<operation type="read" ratio="5" division="none"
config="containers=u(1,32);objects=u(1,50);" id="none"/>
<operation type="write" ratio="95" division="none"
config="containers=u(1,32);objects=u(51,100);
sizes=u(5,5)MB"
id="none"/>
</work>
</workstage>
<workstage name="cleanup" closuredelay="0">
<work name="cleanup" type="cleanup" workers="16"
interval="20"
division="object" runtime="0" rampup="0" rampdown="0"
totalOps="1" totalBytes="0"
config="containers=r(1,32);objects=r(1,100);">
< operation type="cleanup" ratio="100" division="object"
config="deleteContainer=false;containers=r(1,32);
objects=r(1,100);" id="none"/>
</work>
</workstage>
<workstage name="dispose" closuredelay="0">
<work name="dispose" type="dispose" workers="16"
interval="20"
division="container" runtime="0" rampup="0" rampdown="0"
totalOps="1" totalBytes="0" config="containers=r(1,32);">
<operation type="dispose" ratio="100"
division="container"
config="objects=r(0,0);sizes=c(0)B;containers=r(1,32);"
id="none"/>
</work>
</workstage>
</workflow>
</workload>

Результат workload является последовательностями отчетов о метриках: производительности, измеряемой в операциях/секунду, времени отклика, измеряемого средней продолжительностью между операциями запуска и останова, пропускной способности, измеряемой м МБайтах в секунду (MBps), соотношением удач (процент успешного выполнения) и других метрик. Образец не связанного с данной нагрузкой сообщения показан в приводимой ниже копии экрана:

Образец отчета Образец отчета

Если кластер Swift выдержал тестирование под вашей workload, вы выполнили задачу. Возможно вы захотите выполнить некоторые основные тонкие настройки, но это не обязательно. Однако, если кластер Swift не в состоянии справиться с workload, вам необходимо выполнить настройку.

Первый шаг заключается в определении бутылочного горлышка. Обратитесь к Глава 5, Управление Swift за инструментарием для поиска бутылочного горлышка производительности. Nagios или swift-recom могут быть особенно полезными для этой цели. Конечно, также могут быть использованы простейшие средства, такие как top. Как только вы изолируете узкое место на определенном сервере (ах) и лежащие в основе компоненты такие как производительность ЦПУ, память, ввод/вывод, пропускная способность дисков и времена откликов, мы можем перейти к следующему шагу, которым является настройка.

Настройка аппаратных средств

Глава 6, Выбор соответствующих аппаратных средств детально рассматривает аппаратные средства. Достаточно сказать, что правильный выбор аппаратных средств оказывает существенное значение на производительность, надежность, доступность и стоимость.

Настройка программного обеспечения

В Главе 2, Архитектура OpenStack Swift мы ужеговорили о том, что Swift использует два типа модулей программного обеспечения: каналы данных (обычно называемые в документации Swift WSGI server-ами) и завершающей обработкой (postprocessing, обычно называемой background daemon). Кроме того, существуют кольца. Все три полезных свойства должны рассматриваться отличными способами в терминах настройки программного обеспечения. Также мы вкраце взглянем на другие дополнительные возможности настройки.

Обзор колец

Количество разделов в кольце влияет на производительность и должно тщательно выбираться, поскольку оно не может быть легко изменено. Документация Swift рекомендует, как минимум, 100 разделов на диск для обеспечения равномерного распределения между серверами. Взяв максимальное ожидаемое количество дисков, умноженное на 100, азатем округленное доближайшей степени двух, мы получаем минимальное общее количество разделов. Использование бОльшего, чем необходимо, числа будет означать очень равномерное распределение, однако, за счет производительности, поскольку большее число разделов добавляет нагрузку на репликаторы и другие завершающие задания. Следовательно, пользователи не должны переоценивать окончательный размер кластера.

Например, предположим, что мы ожидаем, что наш кластер должен иметь 1000 узлов, причем каждыйбудет иметь 60 дисков. Это дает нам 60 x 1,000 x 100 = 6`000`000 разделов. Округляя до ближайшей степени двойки, мы получаем 223 = 8`388`608. Следовательно, значение, котороебудет использовано для создания кольца будет 23. При данных вычислениях мы не принимали в расчет размердиска, однако кластер с меньшим/ более быстрым дисками (например, 2ТБ SAS дисками) будет работать лучше чем кластер с меньшими / более медленными дисками (например, 6ТБ SATA дисками) при одноми том же количестве разделов.

Настрока программных каналов данных

Основными программными модулями канала данных являются сервера прокси, учетных записей, контейнеров и объектов. Существуют десятки параметров настройки, однако наиболее важными с точки зрения производительности являются следующие четыре:
Параметр Сервер прокси Сервер хранения
workers (по умолчанию auto) Каждый исполнитель (worker) может обрабатывать max_clients количество одновременных запросов. В идеале, большее число исполнителей означает обработку большего количества запросов без блокировки. Однако, существует верхний предел, диктуемый ЦПУ. Начните с установки max_clients равного удвоенному числу ядер. Если сервер хранения содержит серверы учетных записй, контейнеров и объектов, вы можете поэксперементировать.
max_clients (по умолчанию 1024) Поскольку мы хотим наиболее эффективно использовать емкость сети, мы желаем максимального количества одновременных запросов. Возможно, вамне придется менять установки по умолчанию. В опубликованных RedHat данных, были найдены вызовы файловой системы, которые целиком блокируют исполнителя. Это означает, что установка очень большого значения для max_clients не является полезной. Поэксперементируйте с этим параметром, и не бойтесь уменьшать его до упора, чтобы соответствовать значению threads_per_disk, или даже 1.
object_chunk_size (по умолчанию 64КБ) Принимая во внимание, что обмен этими данными осуществляется по внутренней сети Swift, установка бОльшего значения может быть эффективной. RedHat определила, что установка 2МБ оказывается более эффективной, чем значение по умолчанию при сети 10Gbps. N/A
threads_per_disk (по умолчанию 0) N/A Этот параметр определяет размер пула потоков каждого диска. Значение по умолчанию 0 означает, что дисковый пул не будет использоваться. В общем случае, документация Swift рекомендует сохранять это значение небольшим, чтобы избегатьбольшой глубины очереди, которая приводит к большим задержкам чтения. Попробуйте начать с четырех потоков на диск.

Настройка завершающего программного обеспечения

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

  • concurrency: Документация Swift (http://docs.openstack.org/developer/swift/deployment_guide.html) рекомендует устанавливать параллелизм (concurrency) большинства заданий завершающей обработки равным 1, за исключением репликаторов, где рекомендуется значение 2. Если вам требуется более высокий уровень надежности, рассмотрите возможность увеличения этого значения. Надежность, опять же, измеряется как 1-P (потеря объектов за год), где обычно размер объекта 1КБайт.
  • interval: Если вы не хотите понижать нагрузку на серверы, увеличивать надежность или уменьшать размер окна согласованности, вероятно, вы захотите придерживаться значения по умолчанию.

Дополнительные параметры настройки

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

  • memcached: Ряд служб Swift полагаются на memcached для поиска в кэше, поскольку Swift не кэширует данные. Хотя memcached может работатьна всех серверах, он должен бытьвключен на серверах прокси. Если memcached включен, убедитесь, что доступно достаточное количество ресурсов ОЗУ и ЦПУ.
  • System time (системное время): Поскольку Swift является распределенной системой, временная метка объекта используется по целому ряду причин. Следовательно, очень важно гарантировать согласованность времени между серверами. Для этой цели могут использоваться службы, подобные NTP.
  • Filesystem (файловая система): Swift является независимой от файловой системы, тем не менее, XFS является протестированной сообществом Swift файловой системой. Важно сохранять размер inode высоким, например, 1024, чтобы гарантировать, что значения по умолчанию и метаданные хранятся эффективно. Остальныепараметры могут быть установлены так, как описано в Главе 3, Установка OpenStack Swift
  • Operating system (операционная система): Общая настройка операционной системы выходит зарамки данной книги. Однако, документация Swift предполагает отключение TIME_WAIT и syn cookies, а также дублирование разрешенных conntrack в sysctl.conf. Поскольку ОС обычноустанавливается на диск, обычно не являющийся частью системы хранения, вы можете рассомтреть возможность установки небольшого SSD для увеличения времени загрузки.
  • Network stack (сетевой стек): Настройка сетевого стека также выходит за рамкиданной книги. Тем не менее, существуют некоторые дополнительные очевидные настройки, например, разрешение больших кадров (jumbo) для внутренней сети кластера хранения. Jumbo кадры также могут быть включены для сети клиента или репликаций, если такой обмен данными осуществляется в локальной сети (в случае частных облаков).
  • Logging (ведение журналов): Если не используются пользовательские обработчики журналов, то Swift делает записи непосредственно в syslog. Swift генерирует большой объем регистрационных данных и, следовательно, правильное управление этими записями очень важно. Надлежащая установка журналирования может повлиять как на производительность, так и на вашу способность диагностировать проблемы. Вы можете рассмотреть высокопроизводительные возможности, например, такие как rsyslog (http://www.rsyslog.com/) или syslog-ng (http://www.balabit.com/network-security/syslogng/opensource-logging-system).

Заключение

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

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