Ceph Object Gateway (radosgw): performance monitoring

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

dmesg: page allocation failure

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

Ceph Objet Gateway (radosgw) and object versioning на практике

Версионирование объектов в 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

Пожалуй всем пользователям 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

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

*.* @;RSYSLOG_SyslogProtocol23Format

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

Puppet. classes vs Defined resource types

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

Читать дальше

HashiCorp Nomad. Installation guide and example

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

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

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

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

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

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

cLVM, lvmlockd или как приручить СХД

Проблема

У вас есть много нод и общий на всех блочный сторадж(iSCSI, FC, SRP etc.). Вам нужно гибко управлять этим стораджем — создавать, удалять, ресайзить, снапшотить LUNы, при этом иметь возможность работать с любым LUN’ом на любой ноде. Типичный пример — группа хостов и множество ВМ на этих хостах к которым LUNы подключаются напрямую. Как известно, это единственный способ получить максимум производительности блочного хранилища.
Но, ваша СХД не имеет API либо делает все операции очень медленно, либо у вас нет програмистов способных реализовать управление этой СХД. Другая причина, наличие нескольких СХД и желание работать с ними одинаково. Читать дальше

GlusterFS — petabyte storage

Недавно возникла необходимость построить отказоустойчивое хранилище с полезным объемом в 1 Пб. Так как обычная репликация требует x2 по объему, хотелось использовать erasure coding который позволяет получить как минимум 2/3 от сырого пространства. Конечно, EC не такой быстрый как обычная репликация, но в данном конкретном случае он полностью удовлетворял требования к производительности.
Все это хорошо думал я, но у меня не было ранее опыта построения хранилищ такого объема. Более того, я не видел статистики подобного характера по GlusterFS. Закрались сомнения, можно ли используя EC построить хранилище на 1Пб в принципе.
Я решил написать на рассылку GlusterFS и узнать о размерах хранилищ с EC.

Читать дальше