S3 Performance Test Tool

Опубликовано 21.10.2017 автор Александр Руденко — Нет комментариев ↓

Неплохая утилита для тестирования производительности AWS S3 или S3 совместимого объектного хранилища типа Ceph.
Так же ее можно использовать для нагрузочных тестов имитируя различную нагрузку.

Код проекта: https://github.com/jenshadlich/S3-Performance-Test
Утилита написана на Java и если вам как и мне не хочется возиться с Java то есть готовый Docker image: https://hub.docker.com/r/javamaster/s3pt/ Только есть одна мелочь — образ не пригоден к использованию так как не один из примеров не работает(на дату статьи перепроверил и таки да, не работает ничего 🙁 )

Поэтому я любезно пересобрал утилиту и образ в котором в отличии от оригинала все работает 🙂 https://hub.docker.com/r/fatruden/s3pt/

Ceph Object Gateway (RadosGW): performance monitoring (Zabbix)

Опубликовано 03.09.2017 автор Александр Руденко — 2 комментария ↓

Про доступные метрики производительности RadosGW(RGW) я писал отдельную заметку.
В этот раз я опишу как мы у себя собираем эти метрики в Zabbix.

Скрипт сбора метрик, user_parameters.conf и собственно шаблон для Zabbix — https://github.com/FATruden/rgw-monitoring

Ceph Object Gateway (RadosGW): performance monitoring

Опубликовано 03.09.2017 автор Александр Руденко — Нет комментариев ↓

RadosGW или RGW он же Ceph Object Gateway позволяет работать с хранилищем RADOS(он же Ceph) через REST API совместимый с S3 и Swift. RGW является прослойкой между пользователем использующим REST и хранилищем RADOS взаимодействие с которым осуществляется по алгоритму CRUSH.
У всех компонентов Ceph есть метрики позволяющие мониторить производительность и понимать, что происходит в кластере. У RGW тоже есть такие метрики и они нам сильно помогают понимать состояние системы в целом и находить проседающие места.

dmesg: page allocation failure

Опубликовано 14.08.2017 автор Александр Руденко — Нет комментариев ↓

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

Ceph Objet Storage and object versioning на практике

Опубликовано 12.07.2017 автор Александр Руденко — 3 комментария ↓

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

В моем случае, вместо оригинального черного ящика под названием AWS S3 используется Ceph и Ceph Object Gateway(RadosGW).
Ceph Object Gateway — это надстройка над довольно низкоуровневым хранилищем под названием Ceph, которая реализует AWS S3 API(REST only).
По сути это open source реализация S3-совместимого объектного хранилища.

Для работы с объектами я буду использовать awscli. Я не буду останавливаться на том как ее установить и настроить — это подробно описано в документации. Я лишь покажу как переопределить адрес для подключения к s3 если вы как и я работаете не с AWS S3 а каким то другим S3).

Случайные числа в Linux(RNG) или как «наполнить» /dev/random и /dev/urandom

Опубликовано 06.06.2017 автор Александр Руденко — Нет комментариев ↓

Пожалуй всем пользователям Linux известны такие файлы псевдо-устройств как /dev/random и /dev/urandom. Эти устройства являются интерфейсом к генератору случайных чисел ядра(RNG, random number generator).

Случайные числа(они же — не предсказуемый набор битов) очень важны в криптографии. Они являются базовыми кирпичиками для криптографических протоколов. От качества (неповторимости, не предсказуемости) этих чисел зависит стойкость всевозможных TLS-сертификатов, SSH и GPG ключей, сессионных симметричных TLS-ключей и т.д. Так же случайные числа являются основой для генерации UUID’ов, PID’ов, TCP sequence numbers и многого другого.

RNG генерит случайные числа на основе данных из пула энтропии(entropy pool) в ядре Linux. Наполнением этого пула так же занимается RNG и делается это на основе случайных событий в системе таких как: тайминги клавиатуры и дисков, движения мыши, прерывания(interrupts), сетевой трафик.

GELF, rsyslog and custom properties

Опубликовано 27.05.2017 автор Александр Руденко — Нет комментариев ↓

Для централизованного сбора и обработки логов в нашей команде используется Graylog(v2.2.3).
Отправкой логов занимается rsyslog(7.4.7-12.el7).
Все сообщения со всех серверов отправляются в Graylog следующим правилом:

*.* @;RSYSLOG_SyslogProtocol23Format

Все прекрасно, но вкусив прелести фильтрации логов с помощью stream’ов graylog нам стало не достаточно стандартных полей rsyslog.

Puppet. classes vs Defined resource types

Опубликовано 08.04.2017 автор Александр Руденко — Нет комментариев ↓

Как то на днях мой коллега озадачил меня вопросом о разнице между классами puppet и defined resources(или defined types). Я задумался, но дать нормального ответа не смог. На первый взгляд эти сущности очень похожи. И class и defined type описывают внутри себя некую логику и набор ресурсов. И class и defined type могут быть параметризованы. Но, есть существенное различие в том как они вызываются.

HashiCorp Nomad. Installation guide and example

Опубликовано 02.04.2017 автор Александр Руденко — Нет комментариев ↓

Nomad от HashiCorp это очередной scheduler для управления/ жизненным циклом различных задач запускаемых на группе серверов. Из коробки Nomad имеет драйверы для запуска Docker, rkt, LXC контейнеров и виртуальных машин QEMU-KVM. Так же поддерживается запуск отдельных процессов. Перечень драйверов и их описание.
Лично я рассматриваю Nomad как средство оркестрации Docker-контейнерами. Меня пугает монструозный Kubernetes а нативный Docker-swarm навязывает слишком много своих правил, например не всегда нужные overlay-сети и механизмы балансировки на базе LVS или dns-rr. Пока, что мы используем Puppet для деплоя docker-контейнеров описанных в yaml-файле. Puppet хорошо справляется с задачей создания\обновления\удаления контейнеров но при отказе сервера перераспределить контейнеры на другие ноды уже сложнее, это все такие не его стезя. В общем, мы периодически посматриваем на другие решения и надеемся найти, что то, что даст максимум свободы и при этом не будет иметь переусложненную архитектуру. Nomad — потенциальный кандидат 🙂

Управление группами серверов с помощью pdsh. pdsh-mod-genders

Опубликовано 27.03.2017 автор Александр Руденко — Нет комментариев ↓

Если у вас есть группа серверов в которой есть деление по ролям(серверы выполняют различные функции) или например вы используете разные дистрибутивы под разные задачи то эта заметка будет вам очень полезна).
В проекте в котором я работаю, для массового управления группами серверов есть средства собственной разработки. Это очень удобно, когда у тебя например 100 серверов и тебе нужно выполнить какое то действие на конкретных группах или на всех и ты можешь оперировать именами групп а не длинным списком из имен серверов.
Типичный кейс — запуск puppet-агента на всех серверах. Или например проверка версии некого пакета на всех серверах с CentOS 7.3.

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

Когда нужно было сделать что то на паре серверов люди делали примерно так:

pdsh -w sd01,sd05,sd06 rpm -qa kernel

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