Управление Swift.

Следующий скриншот отображает данные Swift Informant в рамках мониторинга приложения Vedams Swift

Инструменты Swift dispersion

Этот инструмент завершающей обработки используется для определения общего состояния кластера Swift. Инструмент swift-dispersion-populate используется для распределения объектов и контейнеров по всему кластеру Swift таким образом, чтобы объекты и контейнеры попадали в различные разделы. Далее выполняется инструмент swift-dispersion-report для определения состояния этих объектов и контейнеров. В случае объектов, Swift делает три реплики для резервирования. Если все копии объекта созданы успешно, то состояние объекта называется хорошим; инструмент swift-dispersion-report поможет выяснить таким образом состояние всех объектов и контейнеров в кластере.

Следующий скриншот отображает данные Swift Dispersion в рамках мониторинга приложения Vedams Swift

StatsD

Службы Swift были оборудованы средствами для отправки статистик (счетчиков и регистрационных записей) непосредственно в настраиваемый сервер StatsD.

Простой демон StatsD для приема метрик может быть найден на https://github.com/etsy/statsd/

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

• log_statsd_host
• log_statsd_port
• log_statsd_default_sample_rate
• log_statsd_sample_rate_factor
• log_statsd_metric_prefix

Параметр log_statsd_sample_rate_factor может быть отрегулирован для установки необходимой частоты протоколирования. Параметр log_statsd_metric_prefix устанавливается на узле для подстановки этого префикса во все отправляемые на сервер StatsD с этого узла метрики. Если параметр log_statsd_host не установлен, то данная функциональность буде отключена.

Журналы StatsS могут пересылаться на внутренний сервер Graphite для отображения метрик в виде графиков. Следующий снимок экрана мониторинга приложения Vedams Swift представляет журналы StatsD в виде графиков:

Метрики Swift

Исходный код Swift имеет встроенные в него метрики протоколирования (счетчики, хронометражи и тому подобные). Некоторые из отправляемых на сервер StatsD из различных служб Swift метрик перечислены в следующей таблице. Они были разделены на группы на основе операций создания, чтения, обновления, удаления (CRUD, Create, Read, Update, Delete):

Create/PUT	Read/GET	Update/POST	Delete
account-server.PUT.errors.timing	account-server.GET.errors.timing	account-server.POST.errors.timing	account-server.DELETE.errors.timing
account-server.PUT.timing	account-server.GET.timing	account-server.POST.timing	account-server.DELETE.timing
container-server.PUT.errors.timing	container-server.GET.errors.timing	container-server.POST.errors.timing	container-server.DELETE.errors.timing
container-server.PUT.timing	container-server.GET.timing	container-server.POST.timing	container-server.DELETE.timing
object-server.async_pendings			object-server.async_pendings
object-server.PUT.errors.timing	object-server.GET.errors.timing	object-server.POST.errors.timing	object-server.DELETE.errors.timing
object-server.PUT.timeouts
object-server.PUT.timing	object-server.GET.timing	object-server.POST.timing	object-server.DELETE.timing
object-server.PUT.<device>.timing
proxy-server.<type>.client_timeouts
proxy-server.<type>.client_disconnects
proxy-server.<type>.<verb>.<status>.timing	proxy-server.<type>.<verb>.<status>.timing	proxy-server.<type>.<verb>.<status>.timing	proxy-server.<type>.<verb>.<status>.timing
proxy-server.<type>.<verb>.<status>.xref	proxy-server.<type>.<verb>.<status>.xref	proxy-server.<type>.<verb>.<status>.xref	proxy-server.<type>.<verb>.<status>.xref

(Прим.пер.: по сравнению с оригиналом в предыдущей таблице произведено смысловое построчное выравнивание.)

Ведение журналов с помощью rsyslog

На практике очень полезно получать журналы от различных служб Swift, что может быть достигнуто путем настройки proxy-server.conf и Rsyslog. Для того, чтобы получать журналы с прокси сервера, мы изменяем настройку файла /etc/swift/proxy-server.conf, добавив следующие строки:
log_name = name
log_facility = LOG_LOCALx
log_level = LEVEL

Опишем предыдущие записи: name может быть любым именем, которое вы хотели бы видеть в журналах. Символ X в LOG_LOCALx может быть любым числом от нуля до семи. LEVEL (параметр уровня) может быть одним из: emergency, alert, critical, error, warning, notification, informational или debug (чрезвычайная ситуация, предупреждение, критическая ситуация, ошибка, предупреждение, уведомление, информационное или отладка).

Далее изменим /etc/rsyslog.conf добавив следующую строку кода в раздел GLOBAL_DIRECTIVES
$PrivDropToGroup adm

Также мы создадим файл настройки /etc/rsyslog.d/swift.conf и добавим в него следующую строку кода:
local2.*       /var/log/swift/proxy.log

Предыдущая строка сообщает syslog, что любая регистрационная запись в устройство LOG_LOCAL2 должна быть отправлена в файл /var/log/swift/proxy.log. Затем мы предоставляем права доступа к папке /var/log/swift и перезапускаем службу прокси сервера и службу syslog.

Управление отказами

В этом разделе мы имеем дело с обнаружением сбоев и действия по устранению неисправностей. Это могут быть отказы диска, сервера, зоны, или даже региона. Как описано в Главе 2, Архитектура OpenStack Swift в ходе обсуждения теоремы CAP, Swift предназначен быть доступным и устойчивым к частичным отказам (при которых из строя могут выходить целые части кластера).

Определение дисковых отказов

Журналы ядра являются хорошим местом для поиска дисковых отказов. Дисковая система будет создавать учетные записи предостережений или ошибок, которые могут помочь администратору определить: являются ли диски плохо работающими или уже вышли из строя. На узлах хранения мы также можем создать скрипт для перехвата информации о дисковых отказах с сипользованием процесса аудита устройств, описанного в Главе 2, Архитектура OpenStack Swift выполнив следующие шаги:

1. на каждом узле хранения создайте скрипт swift-drive-audit в каталоге /etc/swift со следующим содержанием:
   [drive-audit] log_facility = LOG_LOCAL0
log_level = DEBUG
device_dir = /srv/node
minutes = 60
error_limit = 2
log_file_pattern = /var/log/kern*
regex_pattern_X = berrorb.*b(sd[a-z]{1,2}d?)b and b(sd[a-z]{1,2}d?)b.*berrorb
2. Добавьте следующую строку кода в /etc/rsyslog.d/swift.conf:
local0.* /var/log/swift/drive-audit
3. Затем перезапустите службу rsyslog с использованием следующей команды:
   # Service rsyslog restart
4. После этого перезапустите службу Swift с использованием следующей команды:
   # swift-init rest restart
5. Информация о дисковых отказах теперь будет сохраняться в файле журналов /var/log/swift/drive-audit

Обработка дисковых отказов

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

Обработка отказов узлов

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

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

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

• Для удаления устройства из кольца используйте:
  # swift-ring-builder <builder-file> remove <ip_address>/<device_name>
  Например, swift-ring-builder account.builder remove 172.168.10.52/sdb1.
• Для удаления из кольца сервера воспользуйтесь:
  # swift-ring-builder <builder-file> remove <ip_address> Например, swift-ring-builder account.builder remove 172.168.10.52.

Отказ сервера прокси

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

Отказ зоны и региона

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

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

Планирование емкости

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

Добавление новых устройств

Хотя добавление новых дисков является простым процессом, он требует тщательного планирования, так как это предполагает повторную балансировку кольца. После того, как мы решили добавить новые диски, мы добавим эти диски к определенному серверу хранения в зоне выпонив форматирование и монтирование этих дисков. Далее, мы выполним команду swift-ring-builder add для добавления этих дисков в кольцо. Наконец, для выполнения ребалансировки кольца мы запустим команду swift-ring-builder rebalance. Созданные файлы кольца .gz должны быть распространены по всем узлам серверов хранения данных. Команды для выполнения этих операций были объяснены в Главе 3. Установка OpenStack Swift, в разделах Форматирование и монтирование дисков и Установка кольца.

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

Добаваление новых систем хранения и серверов прокси

Добавление новых систем хранения и серверов прокси также является несложной операцией, при которой новые сервера должны быть подготовленыв в соответствии с инструкциями, предоставленными в Главе 3. Установка OpenStack Swift. Сервера хранения должны быть помещены в правильные зоны, а расположенные на них диски должны быть размещены в кольце. После перебалансровки и распространения файлов кольца .gz на остальные сервера хранения, новые сервера хранения становятся частью кластера. Аналогично, после установки нового прокси сервера, файлы настройки и установки балансировки нагрузки подлежат обновлению. Такой прокси сервер теперь является частью кластера и может принимать запросы от пользователей.

Миграции

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

Для обновления узла сервера хранения требуются следующие шаги:

1. Выполните следующие команды для остановки запущенных в фоновом режиме операций Swift:
   # swift-init rest stop
2. Аккуратно остановите все службы Swift с использованием следующей команды:
   # swift-init {account|container|object} shutdown
3. Выполните обновление необходимых операционной системы и пакетов системного программного обеспечения и установите/ обновите необходимые пакеты Swift. Как правило, Swift находится в рамках шестимесячного цикла обновления.
4. Затем создайте файлы настройки Swift или выполните необходимые изменения.
5. После перезагрузки сервера перезапустите все необходимые службы выполнив следующие команды:
   # swift-init {account|container|object} start
# swift-init rest start

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

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

Далее мы рассмотрим как обновлять прокси- серверы. Мы можем воспользоваться балансировкой нагрузки для изоляции прокси-сервера, который мы планируем обновить таким образом, чтобы клиентские запросы не отправлялись на данный прокси- сервер.

Для выполнения обновления прокси- сервера мы выполняем следующие шаги:

1. Аккуратно остановите все прокси- службы с использованием следующей команды:
   # swift-init proxy shutdown
2. Обновите необходимые операционную систему, пакеты системного программного обеспечения, а также установите/ обновите требующиеся пакеты Swift.
3. Далее создайте файлы настройки Swift или выполните необходимые изменения.
4. После перезагрузки сервера запустите все необходимые службы с использованием следующей команды:
   # swift-init proxy start

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

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

Заключение

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

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