Ceph Objet Storage 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).

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

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.

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

GlusterFS — новый класс хранилищ данных

Высокопроизводительные и надежные хранилища данных были и остаются дорогим удовольствием, которое не всем по карману. Полноценное использование технологий виртуализации зачастую невозможно из-за отсутствия именно этого компонента инфраструктуры. И здесь кстати мнения расходятся. Кто то считает, что замены промышленным СХД быть не может. Я же уверен, что существуют значительно более дешевые альтернативы. Более того, мне кажется, что за подобными решениями будущее и современная тенденция, кажется, к этому все и склоняет. Ниже я расскажу и покажу что из себя представляет одна из альтернатив под названием Glus­terFS — а выбор, естественно, за вами.

Glus­terFS часть 1. Что за зверь?
Glus­terFS часть 2. Архитектура
Glus­terFS часть 3. Установка
Glus­terFS часть 4. Типы томов
Glus­terFS часть 5. Создание томов
Glus­terFS часть 6. Монтирование томов
Glus­terFS часть 7. Glus­terFS и oVirt
Glus­terFS часть 8. Тонкая настройка
Glus­terFS часть 9. Квоты

Материалы опубликованы в журнале «Системный администратор»

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

Glus­terFS часть 9. Квоты

GlusterFS. Все статьи цикла

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

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

Glus­terFS часть 8. Тонкая настройка

GlusterFS. Все статьи цикла

При создании нового тома, в рабочей директории по умолчанию (/var/lib/glusterd/vols) создается поддиректория с именем соответствующим названию тома. В этом каталоге размещается вся служебная информация о конкретном томе среди которой несколько файлов с расширением *.vol. Главный из них это trusted-<имя-тома>-fuse.vol, он описывает общие параметры тома; информацию о серверах, топологию репликации, и некоторые общие параметры используемых трансляторов. В файлах <имя-тома>-<имя-сервера>-<имя-каталога>.vol описываются параметры трансляторов серверов.

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

Glus­terFS часть 7. Glus­terFS и oVirt

GlusterFS. Все статьи цикла

Платформе виртуализации oVirt была посвящена большая статья в моем блоге. Здесь же мы рассмотрим вариант когда в роли узлов хранения выступают вычислительные узлы oVirt(Nodes). Такой сценарий полностью поддерживается. Более того, управлять томами на вычислительных узлах можно прямо в интерфейсе oVirt без погружения в консоль.

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

Glus­terFS часть 6. Монтирование томов

GlusterFS. Все статьи цикла

Наиболее популярные средства для доступа к Gluster-тому это NFS и собственный клиент(Gluster Native Client)

Подключить том по NFS можно без какой либо подготовки системы:

mount gl01:/<имя_тома> /<каталог_монтирования>

В таком случае, сервис Gluster на узлах хранения подгрузит соответствующий транслятор и будет вести себя как NFS-сервер третей версии.

А вот что бы пользоваться клиентом, придется предварительно его установить:

на Ubuntu:

apt-get install glusterfs-client

 на CentOS:

yum -y install glusterfs glusterfs-fuse

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

Glus­terFS часть 5. Создание томов

GlusterFS. Все статьи цикла

Может показаться, что управление GlusterFS — нетривиальная задача, но на практике все очень просто и практически интуитивно.

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

Если у вас два сервера, например gl01 и gl02, то на первом выполняем следующую команду;

gluster peer probe gl02 

peer probe: success.

 Если серверов больше, то тоже самое выполняем с остальными.

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

Glus­terFS часть 4. Типы томов

GlusterFS. Все статьи цикла

В следующем разделе пойдут конкретные примеры использования, поэтому будет уместно ознакомиться с типами томов.

Distributed — распределенный том. Тип тома, при котором данные распределяются равномерно (в произвольном порядке) по всем под томам. Например первый файл будет записан на первый сервер а второй файл — на третий. Тома такого типа очень хорошо и легко масштабируются, но никак не защищены средствами GlusterFS. Надежность Distributed тома необходимо обеспечить отдельно на аппаратном или программном уровне. В случае выхода из строя сервера или его дисков, данные находящиеся на нем будут не доступны. Самое интересное в этой схеме, что совершенно непредсказуемо, какие именно данные будут потеряны.

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