Виртуализация и не только
Про доступные метрики производительности RadosGW(RGW) я писал отдельную заметку.
В этот раз я опишу как мы у себя собираем эти метрики в Zabbix.
Скрипт сбора метрик, user_parameters.conf и собственно шаблон для Zabbix — https://github.com/FATruden/rgw-monitoring
RadosGW или RGW он же Ceph Object Gateway позволяет работать с хранилищем RADOS(он же Ceph) через REST API совместимый с S3 и Swift. RGW является прослойкой между пользователем использующим REST и хранилищем RADOS взаимодействие с которым осуществляется по алгоритму CRUSH.
У всех компонентов Ceph есть метрики позволяющие мониторить производительность и понимать, что происходит в кластере. У RGW тоже есть такие метрики и они нам сильно помогают понимать состояние системы в целом и находить проседающие места.
Эта ошибка может возникать в системах любой конфигурации. Решение можно быстро нагуглить но само по себе оно не столько интересно нежели, то дополнительное понимание о памяти в Linux которое можно получить разобравшись в проблеме.
Версионирование объектов в 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 известны такие файлы псевдо-устройств как /dev/random и /dev/urandom. Эти устройства являются интерфейсом к генератору случайных чисел ядра(RNG, random number generator).
Случайные числа(они же — не предсказуемый набор битов) очень важны в криптографии. Они являются базовыми кирпичиками для криптографических протоколов. От качества (неповторимости, не предсказуемости) этих чисел зависит стойкость всевозможных TLS-сертификатов, SSH и GPG ключей, сессионных симметричных TLS-ключей и т.д. Так же случайные числа являются основой для генерации UUID’ов, PID’ов, TCP sequence numbers и многого другого.
RNG генерит случайные числа на основе данных из пула энтропии(entropy pool) в ядре Linux. Наполнением этого пула так же занимается RNG и делается это на основе случайных событий в системе таких как: тайминги клавиатуры и дисков, движения мыши, прерывания(interrupts), сетевой трафик.
Для централизованного сбора и обработки логов в нашей команде используется Graylog(v2.2.3).
Отправкой логов занимается rsyslog(7.4.7-12.el7).
Все сообщения со всех серверов отправляются в Graylog следующим правилом:
*.* @;RSYSLOG_SyslogProtocol23Format
Все прекрасно, но вкусив прелести фильтрации логов с помощью stream’ов graylog нам стало не достаточно стандартных полей rsyslog.
Как то на днях мой коллега озадачил меня вопросом о разнице между классами puppet и defined resources(или defined types). Я задумался, но дать нормального ответа не смог. На первый взгляд эти сущности очень похожи. И class и defined type описывают внутри себя некую логику и набор ресурсов. И class и defined type могут быть параметризованы. Но, есть существенное различие в том как они вызываются.
Nomad от HashiCorp это очередной scheduler для управления/ жизненным циклом различных задач запускаемых на группе серверов. Из коробки Nomad имеет драйверы для запуска Docker, rkt, LXC контейнеров и виртуальных машин QEMU-KVM. Так же поддерживается запуск отдельных процессов. Перечень драйверов и их описание.
Лично я рассматриваю Nomad как средство оркестрации Docker-контейнерами. Меня пугает монструозный Kubernetes а нативный Docker-swarm навязывает слишком много своих правил, например не всегда нужные overlay-сети и механизмы балансировки на базе LVS или dns-rr. Пока, что мы используем Puppet для деплоя docker-контейнеров описанных в yaml-файле. Puppet хорошо справляется с задачей создания\обновления\удаления контейнеров но при отказе сервера перераспределить контейнеры на другие ноды уже сложнее, это все такие не его стезя. В общем, мы периодически посматриваем на другие решения и надеемся найти, что то, что даст максимум свободы и при этом не будет иметь переусложненную архитектуру. Nomad — потенциальный кандидат 🙂
Если у вас есть группа серверов в которой есть деление по ролям(серверы выполняют различные функции) или например вы используете разные дистрибутивы под разные задачи то эта заметка будет вам очень полезна).
В проекте в котором я работаю, для массового управления группами серверов есть средства собственной разработки. Это очень удобно, когда у тебя например 100 серверов и тебе нужно выполнить какое то действие на конкретных группах или на всех и ты можешь оперировать именами групп а не длинным списком из имен серверов.
Типичный кейс — запуск puppet-агента на всех серверах. Или например проверка версии некого пакета на всех серверах с CentOS 7.3.
Другая проблема которую решает данное средство — инвентаризация. Хочется иметь некий файл с описанием серверов их ролей и прочих атрибутов позволяющих понять предназначение серверов и управлять ими «массово».
Недавно я попал в среду, где было очень много серверов и совершенно отсутствовали средства их инвентаризации и тем более управления.
Когда нужно было сделать что то на паре серверов люди делали примерно так:
pdsh -w sd01,sd05,sd06 rpm -qa kernel
Конечно, держать имена и роли всех серверов в голове это круто само по себе но совершенно не эффективно.
Особенно когда есть такие прекрасные и простые средства для упорядочивания всего этого хозяйства.
У вас есть много нод и общий на всех блочный сторадж(iSCSI, FC, SRP etc.). Вам нужно гибко управлять этим стораджем — создавать, удалять, ресайзить, снапшотить LUNы, при этом иметь возможность работать с любым LUN’ом на любой ноде. Типичный пример — группа хостов и множество ВМ на этих хостах к которым LUNы подключаются напрямую. Как известно, это единственный способ получить максимум производительности блочного хранилища.
Но, ваша СХД не имеет API либо делает все операции очень медленно, либо у вас нет програмистов способных реализовать управление этой СХД. Другая причина, наличие нескольких СХД и желание работать с ними одинаково.