S3 ceph что это
Сeph — от «на коленке» до «production»
У нас было пять стоек, десять оптических свичей, настроенный BGP, пару десятков SSD и куча SAS дисков всех цветов и размеров, а ещё proxmox и желание засунуть всю статику в собственное S3 хранилище. Не то чтобы это всё было нужно для виртуализации, но раз начал использовать opensource — то иди в своём увлечении до конца. Единственное, что меня беспокоило — это BGP. В мире нет никого более беспомощного, безответственного и безнравственного, чем внутренняя маршртутизация по BGP. И я знал, что довольно скоро мы в это окунёмся.
Задача стояла банальная — имелся CEPH, работал не очень хорошо. Надо было сделать «хорошо».
Доставшийся мне кластер был разнородным, настроенным на скорую руку и практически не тюнингованным. Он состоял из двух групп разных нод, с одной общей сеткой выполняющей роль как cluster так и public network. Ноды были набиты четырьмя типами дисков — два типа SSD, собранными в два отдельных placement rule и два типа HDD разного размера, собранными в третью группу. Проблема с разными размерами была решена разными весами OSD.
Саму настройку разделили на две части — тюнинг операционной системы и тюнинг самого CEPH и его настроек.
Прокачка OS
Network
Высокое latency сказывалось как при записи, так и при балансировке. При записи — потому, что клиент не получит ответ об успешной записи, пока реплики данных в других плейсмент группах не подтвердят успех. Поскольку правила распределения реплик в CRUSH map у нас были по одной реплике на хост, то сеть использовалась всегда.
Потому первым делом решил слегка настроить текущую сеть, параллельно пытаясь убедить переехать на раздельные сети.
Для начала покрутил настройки сетевых карт. Начал с настройки очередей:
Видно, что current параметры далеки от maximums. Увеличил:
Руководствуясь отличной статьей
увеличил длинну очереди отправки txqueuelen с 1000 до 10 000
Ну и следуя документации самого ceph
увеличил MTU до 9000.
Добавил в /etc/network/interfaces, чтоб все вышеперечисленное грузилось при старте
После чего, следуя этой же статье, начал вдумчиво накручивать ручки ядра 4.15. Учитывая, что на нодах 128G RAM, получился некий файл конфигурации для sysctl
Сluster network была выделена на отдельных 10Gbps сетевых интерфейсах в отдельную плоскую сеть. На каждой машине были поставлены сетевые двухпортовые карты mellanox 10/25 Gbps, воткнутые в два отдельных 10Gbps свича. Агрегация осуществлялась с помощью OSPF, поскольку бондинг с lacp почему-то показал суммарную пропускную способность максимум в 16 Gbps, в то время как ospf успешно утилизировал полностью обе десятки на каждой машине. В дальнейших планах было воспользоваться ROCE на этих меланоксах, для уменьшения лэтэнси. Как настраивали эту часть сети:
Подробнее по настройке OSPF: Основная задача — агрегировать два линка и иметь fault tolerance.
два сетевых интерфейса настроены в две простых плоских сети — 10.10.10.0/24 и 10.10.20.0/24
по которым машины друг друга видят.
Следующим шагом решил оптимизировать работу дисков. Для SSD поменял планировщик на noop, для HDD — deadline. Если грубо — то NOOP работает по принципу «кто первый встал — того и тапки», что по английский звучит как «FIFO (First In, First Out)». Запросы встают в очередь по мере их поступления. DEADLINE более заточен на чтение, плюс процесс из очереди получает практически монопольный доступ к диску на момент операции. Для нашей системы это отлично подходит — ведь с каждым диском работает только один процесс — OSD daemon.
(Желающие погрузится в планировщик ввода-вывода могут почитать о нем тут:
http://www.admin-magazine.com/HPC/Articles/Linux-I-O-Schedulers
В рекомендациях по тюнингу линукса советуют так-же увеличить nr_request
nr_requests
The value of nr_requests determines the amount of I/O requests that get buffered before the I/O scheduler sends / receives data to the block device, if you are using a RAID card / Block Device that can handle a larger queue than what the I/O scheduler is set to, raising the value of nr_requests may help to improve throughout and reduce server load when large amounts of I/O occur on the server. If you are using Deadline or CFQ as the scheduler, it is suggested that you should set the nr_request value to 2 times the value of queue depth.
НО! Сами граждане разработчики CEPH убеждают нас, что их система приоритетов работает лучше
WBThrottle и/или nr_requests
Файловое хранилище использует для записи буферизованные операции ввода/ вывода; это привносит целый ряд преимуществ если журнал файлового хранения находится на более быстром носителе. Запросы клиентов получают уведомления как только данные записаны в журнал, а затем сбрасываются на сам диск данных в более позднее время пользуясь стандартной функциональностью Linux. Это делает возможным для OSD шпиндельных дисков предоставлять латентность записи аналогичную SSD при записях малыми пакетами. Такая задержанная отложенная запись также позволяет самому ядру перестраивать запросы операций ввода/ вывода к диску с надеждой либо слить их воедино, либо позволить имеющимся головкам диска выбрать некий более оптимальный путь поверх своих пластин. Конечный эффект состоит в том, что вы можете выжать слегка больше операций ввода/ вывода из каждого диска чем это было бы возможно при прямых или синхронных операциях ввода/ вывода.
Однако, возникает определённая проблема если объём приходящих записей в данный кластер Ceph будут опережать все возможности лежащих в основе дисков. При таком сценарии общее число находящихся в рассмотрении операций ввода/ вывода в ожидании записи на диск могут неконтролируемо расти и иметь результатом очереди операций ввода/ вывода, заполняющую весь диск и очереди Ceph. Запросы на чтение воздействуют в особенности плохо, так как они застревают между запросами записи, которые могут требовать нескольких секунд для сброса на основной диск.
Для победы над этой проблемой Ceph имеет встроенный в файловое хранение механизм дросселирования отложенной записи (writeback) с названием WBThrottle. Он разработан для ограничения общего объёма операций ввода/ вывода отложенной записи, которые могут выстраиваться в очередь и начинать свой процесс сброса раньше чем чем это произошло бы естественным образом за счёт включения самим ядром. К сожалению, тестирование демонстрирует, что установленные по умолчанию значения всё ещё могут не урезать имеющееся поведение до уровня, который может уменьшать такое воздействие на латентность операций чтения. Регулировка может изменить это поведение и уменьшить общие длины очередей записи и сделать возможным не сильным такое воздействие. Однако имеется некий компромисс: уменьшая общее максимальное число разрешённых к постановке в очередь записей, вы можете снизить возможность самого ядра максимизировать свою эффективность упорядочения поступающих запросов. Стоит немного задуматься что вам более необходимо для вашего конкретного случая применения, рабочих нагрузок и регулировать под соответствие им.
Чтобы управлять глубиной такой очереди отложенной записи, вы можете либо уменьшать общее максимальное количество невыполненных операций ввода/ вывода, применяя установки WBThrottle, либо уменьшая максимальное значение для невыполненных операций на самом блочном уровне своего ядра. И то, и другое могут эффективно управлять одним и тем же поведением и именно ваши предпочтения будут в основе реализации данной настройки.
Также следует отметить, что имеющаяся в Ceph система приоритетов операций является более эффективной для более коротких запросов на дисковом уровне. При сокращении общей очереди к данному диску основное местоположение нахождения в очереди перемещается в Ceph, где он имеет большее управление над тем какой приоритет имеет операция ввода/ вывода. Рассмотрим следующий пример:
COMMON
И еще несколько настроек ядра, позволяющие сделать вашу тачку мягкой и шелковистой выжать еще немного производительности из железа
Работа с объектным S3-хранилищем VK Cloud Solutions (бывш. MCS) как с файловой системой
С объектными хранилищами чаще всего работают через API. Но если очень хочется, можно сложить туда файлы и работать с ними в объектном хранилище, как в файловой системе, с иерархией каталогов.
Грубо говоря, в хранилище можно выложить фотографии и разложить их по папочкам по годам, а в каждом годе сделать папочки соответственно месту съёмки.
Само по себе объектное хранилище никакую иерархию не предоставляет, так что для имитации файловой системы используют специальные утилиты. Такая схема позволяет само хранение организовать со всеми преимуществами облака (доступ из любой локации, встроенное резервирование данных в облаке, резиновое масштабирование), но работать с объектами в логике, привычной человечеству ещё со времён Norton Commander.
Эта статья как раз про то, как настроить работу с объектным хранилищем на примере VK Cloud Solutions (бывш. MCS) как с файловой системой. Мы быстренько создадим хранилище и покажем, как подключить к нему три утилиты:
Создание хранилища
Понадобится регистрация с привязкой телефона, после которой сразу начисляется 150 бонусных рублей. Их нам для этой истории более чем хватит.
Настройка бакета
На этом этапе настройка хранилища закончена. Переходим к нашим утилитам.
Настройка работы с файлами через Диск-О
Диск-О — клиент для доступа к любым облачным хранилищам, от стандартных облачных дисков для пользователей до объектных хранилищ. Он доступен для Windows и MacOS, установим его на примере Mac OS X.
С ним можно работать, как с обычным диском: копировать, перемещать, запускать файлы. Только он не занимает места на физическом диске компьютера.
Проверка: скопируем какой-нибудь файл на подключенный диск.
Облачное объектное хранилище S3: что это такое и как подобрать тариф
ИТ-маркетплейс Market.CNews запустил поиск тарифов по облачным объектным хранилищам S3 для компаний. В рамках данной статьи мы расскажем, что такое объектное хранилище, для чего оно используется, кому нужно и как подобрать тариф.
Что такое объектное хранилище
По мере развития любой организации, ее ИТ-специалисты все чаще сталкиваются с вопросом «Как справиться с постоянно возрастающим объемом данных, которые создают и потребляют пользователи компании?». Среди различных стратегий хранения данных объектное хранилище является одним из самых эффективных решений.
Объектной системой хранения данных называется такой тип хранилища, в котором хранятся данные различного формата и объема в виде объектов с метаданными. Каждый такой объект имеет уникальный идентификатор, благодаря которому приложения находят и обращаются к данным, что значительно упрощает работу систем. Отличительной особенностью является то, что данные хранятся в так называемой плоской среде или, другими словами, на одном уровне, т.е. без использования дерева каталогов.
Для чего нужно объектное хранилище
Объектное хранилище обеспечивают высокую скорость работы с большими объемами данных и тысячами объектов. Такой тип хранилища не подразумевает работу пользователей напрямую, доступ к данным организован на уровне приложений с помощью API.
Чаще всего объектное хранилище используется для целей резервного копирования и архивированная критически важных данных. Среди объектов хранения самыми распространенными являются: статический контент (изображения, видео, аудио, файлы JS и CSS), архивы и резервные копии систем, данные корпоративных, мобильных и веб-приложений (изображений, образов, обновлений ПО), электронный документооборот.
Каким компаниям нужно объектное хранилище
Среди самых частых пользователей объектных хранилищ встречаются компании, занимающиеся проектированием и разработкой, игровые порталы, издательства и информационные агентства, организации, предоставляющие медиаконтент для широкой аудитории, маркетплейсы, социальные сети, образовательные учреждения и многие другие, обладающие большими массивами данных.
Преимущества облачных объектных хранилищ
Основными преимуществами в пользу использования объектных хранилищ являются:
Недостатки облачных объектных хранилищ
Среди замечаний, которые называют ИТ-специалисты можно выделить следующие:
Особенности интерфейса
Несмотря на то, что в целом технологии объектного хранилища развиваются уже более 20 лет, до сих пор нет какого-то одного общепринятого стандарта интерфейса. Но за это время довольно прочно закрепилась тройка самых популярных интерфейсов:
Из чего складывается стоимость услуги
Основными параметрами, от которых зависит стоимость услуги являются:
Как выбрать провайдера облачного хранилища
Для выбора провайдера облачного хранилища воспользуйтесь гибким поиском тарифа на ИТ-маркетплейсе Market.CNews. На нем представлено более десятка поставщиков данной услуги.
Чтобы подобрать подходящий тариф, определите необходимый объем хранилища, тип, частоту и количество запросов к нему и трафик. Обычно холодное хранилище стоит дешевле горячего, но запросы к нему стоят дороже, чем запросы к горячему хранилищу. Подсказка о том, холодное это хранилище или горячее, часто содержится в названии тарифа.
Выводы
Объектное хранилище позволяет хранить любые типы данных в исходном виде, обеспечивает быстрое масштабирование и оптимизирует потребление ресурсов системами компании. Такая организация хранения данных делает инфраструктуру организации более отказоустойчивой и эффективной. Объектные хранилища позволяют обеспечить надежное и продолжительное хранение неограниченного количества данных и файлов, предоставляя доступ к ним через интернет из любой точки мира.
Какая система хранения данных используется?
Мы используем открытую программную СХД Ceph и предлагаем многократное резервирование данных и высокую скорость работы дисковой подсистемы.
Что такое Ceph?
Ceph — отказоустойчивое распределенное хранилище данных, работающее по протоколу TCP. Одно из базовых свойств Ceph — масштабируемость до петабайтных размеров. Ceph предоставляет на выбор три различных абстракции для работы с хранилищем: абстракцию объектного хранилища (RADOS Gateway), блочного устройства (RADOS Block Device) или POSIX-совместимой файловой системы (CephFS).
Абстракция объектного хранилища
Абстракция объектного хранилища (RADOS Gateway, или RGW) вкупе с FastCGI-сервером позволяет использовать Ceph для хранения пользовательских объектов и предоставляет API, совместимый с S3/Swift. На Хабре уже была статья о том, как по-быстрому настроить Ceph и RGW. В режиме объектного хранилища Ceph давно и успешно используется в продакшене у ряда компаний.
Абстракция блочного устройства
Абстракция блочного устройства (в оригинале — RADOS Block Device, или RBD) предоставляет пользователю возможность создавать и использовать виртуальные блочные устройства произвольного размера. Программный интерфейс RBD позволяет работать с этими устройствами в режиме чтения/записи и выполнять служебные операции — изменение размера, клонирование, создание и возврат к снимку состояния и т.д.
Гипервизор QEMU содержит драйвер для работы с Ceph и обеспечивает виртуальным машинам доступ к блочным устройствам RBD. Поэтому Ceph сейчас поддерживается во всех популярных решениях для оркестровки облаков — OpenStack, CloudStack, ProxMox. RBD также готов к промышленному использованию.
Абстракция POSIX-совместимой файловой системы
CephFS — POSIX-совместимая файловая система, использующая Ceph в качестве хранилища. Несмотря на то, что CephFS не является production-ready и пока не имеет значимого промышленного применения, на Хабре уже есть инструкция по ее настройке.
Терминология
Ниже перечислены основные сущности Ceph:
Metadata server (MDS) — вспомогательный демон для обеспечения синхронного состояния файлов в точках монтирования CephFS. Работает по схеме активная копия + резервы, причем активная копия в пределах кластера только одна.
Mon (Monitor) — элемент инфраструктуры Ceph, который обеспечивает адресацию данных внутри кластера и хранит информацию о топологии, состоянии и распределении данных внутри хранилища. Клиент, желающий обратиться к блочному устройству rbd или к файлу на примонтированной cephfs, получает от монитора имя и положение rbd header — специального объекта, описывающего положение прочих объектов, относящихся к запрошенной абстракции (блочное устройство или файл) и далее общается со всеми OSD, участвующими в хранении файла.
Объект (Object) — блок данных фиксированного размера (по умолчанию 4 Мб). Вся информация, хранимая в Ceph, квантуется такими блоками. Чтобы избежать путаницы подчеркнём — это не пользовательские объекты из Object Storage, а объекты, используемые для внутреннего представления данных в Ceph.
OSD (object storage daemon) — сущность, которая отвечает за хранение данных, основной строительный элемент кластера Ceph. На одном физическом сервере может размещаться несколько OSD, каждая из которых имеет под собой отдельное физическое хранилище данных.
Карта OSD (OSD Map) — карта, ассоциирующая каждой плейсмент-группе набор из одной Primary OSD и одной или нескольких Replica OSD. Распределение placement groups (PG) по нодам хранилища OSD описывается срезом карты osdmap, в которой указаны положения всех PG и их реплик. Каждое изменение расположения PG в кластере сопровождается выпуском новой карты OSD, которая распространяется среди всех участников.
Плейсмент-группа (Placement Group, PG) — логическая группа, объединяющая множество объектов, предназначенная для упрощения адресации и синхронизации объектов. Каждый объект состоит лишь в одной плейсмент группе. Количество объектов, участвующих в плейсмент-группе, не регламентировано и может меняться.
Primary OSD — OSD, выбранная в качестве Primary для данной плейсмент-группы. Клиентское IO всегда обслуживается той OSD, которая является Primary для плейсмент группы, в которой находится интересующий клиента блок данных (объект). Primary OSD в асинхронном режиме реплицирует все данные на Replica OSD.
RADOS Gateway (RGW) — вспомогательный демон, исполняющий роль прокси для поддерживаемых API объектных хранилищ. Поддерживает географически разнесенные инсталляции (для разных пулов, или, в представлении Swift, регионов) и режим active-backup в пределах одного пула.
Replica OSD (Secondary) — OSD, которая не является Primary для данной плейсмент-группы и используется для репликации. Клиент никогда не общается с ними напрямую.
Фактор репликации (RF) — избыточность хранения данных. Фактор репликации является целым числом и показывает, сколько копий одного и того же объекта хранит кластер.
Архитектура Ceph
Основных типов демонов в Ceph два — мониторы (MON) и storage-ноды (OSD). RGW и MDS демоны не участвуют в распределении данных, являясь вспомогательными сервисами. Мониторы объединяются в кворум и общаются по PAXOS-подобному протоколу. Собственно, кластер является работоспособным до тех пор, пока в нем сохраняется большинство участников сконфигурированного кворума, то есть при ситуации split-brain посередине и четном количестве участников «выживет» только одна часть, поскольку предыдущие выборы в PAXOS автоматически уменьшили число активных участников до нечётного числа. При потере большинства кворума кластер «замораживается» для любых операций, предотвращая возможное рассогласование записанных или прочитанных данных до восстановления минимального кворума.
Восстановление и перебалансировка данных
Потеря из вида одной из копий объекта приводит к переходу объекта и содержащей его плейсмент-группы в состояние degraded и выпуску новой карты OSD (osdmap). Новая карта содержит новое расположение потерянной копии объекта и, если через заданное время утраченная копия не вернется, недостающая копия будет восстановлена в другом месте, чтобы сохранить число копий, определяемое фактором репликации. Операции, выполнявшиеся в момент подобной ошибки, автоматически переключатся на одну из доступных копий. В худшем случае их задержка будет измеряться единицами секунд.
Важным свойством Ceph является то, что все операции по перебалансировке кластера происходят в фоновом режиме одновременно с пользовательским I/O. Если клиент обращается к объекту, который находится в recovering состоянии, Ceph вне очереди восстановит объект и его копии, а затем выполнит запрос клиента. Такой подход обеспечивает минимальное латенси I/O даже тогда, когда восстановление кластера идёт полным ходом.
Распределение данных в кластере
Одна из самых важных особенностей Ceph — возможность тонкой настройки репликации, задаваемой правилами CRUSH — мощного и гибкого механизма, базирующегося на случайном распределении PG по группе OSD с учётом правил (вес, состояние ноды, запрет на размещение в той же группе нод). По умолчанию OSD имеют вес, базирующийся на величине свободного места в соответствующей точке монтирования в момент ввода OSD в кластер и подчиняются правилу распределения данных, запрещающему держать две копии одной PG на одной ноде. CRUSHMAP — описание распределения данных — может быть модифицирован под правила, запрещающие держать вторую копию в пределах одной стойки, тем самым обеспечивая отказоустойчивость на уровне вылета целой стойки.
Теоретически, подобный подход позволяет осуществлять в том числе гео-репликацию в реальном времени, однако на практике это можно использовать лишь в режиме Object Storage, поскольку в режимах CephFS и RBD задержки операций будут слишком велики.
Альтернативы и преимущества Ceph
Наиболее качественной и близкой по духу свободной кластерной ФС являются GlusterFS. Она поддерживается RedHat и имеет некоторые преимущества (например, локализует Primary копию данных рядом с клиентом). Однако наши тесты показали некоторое отставание GlusterFS в смысле производительности и плохую отзывчивость при перестроении. Другие серьёзные минусы — отсутствие CoW (в том числе и в прогнозируемом будущем) и низкая активность сообщества.
Преимущество Ceph перед прочими кластерными системами хранения данных состоит в отсутствии единых точек отказа и в практически нулевой стоимости обслуживания при восстановительных операциях. Избыточность и устойчивость к авариям заложена на уровне дизайна и достается даром.
Возможные замены подразделяются на два типа — кластерные фс для суперкомпьютеров(GPFS/Lustre/etc.) и дешевые централизованные решения вроде iSCSI или NFS. Первый тип достаточно сложен в обслуживании и не заточен на эксплуатацию в условиях отказавшего оборудования — «замораживание» ввода-вывода, особенно чувствительное при экспорте точки монтирования в вычислительную ноду, не позволяет использовать подобные фс в публичном сегменте. Минусы «классических» решений довольно хорошо понятны — отсутствие масштабируемости и необходимость закладывать топологию для failover на уровне железа, что приводит к увеличению стоимости.
С Ceph восстановление и перестроение кластера происходят действительно незаметно, практически не влияя на клиентское I/O. То есть деградировавший кластер для Ceph — это не экстраординарная ситуация, а всего лишь одно из рабочих состояний. Насколько нам известно, ни одна другая открытая программная СХД не имеет этого свойства, достаточного для её использования в публичном облаке, где запланированное прекращение обслуживания невозможно.
Производительность
Как указывалось в начале статьи, данные в Ceph квантуются достаточно маленькими порциями и псевдослучайно распределены по OSD. Это приводит к тому, что реальное I/O каждого клиента Ceph достаточно равномерно «размазывается» по всем дискам кластера. В результате этого:
Снижается накал борьбы между клиентами за дисковый ресурс
Растёт верхняя планка теоретически возможной интенсивности работы с блочным устройством.
Вследствие п.1 и 2 каждый клиент получает существенно большие удельные лимиты по iops и bandwidth, чем может дать классический подход за те же деньги.
Есть и другие причины быстродействия Ceph. Все операции записи сначала попадают в журнал OSD, а затем, не задерживая клиента, асинхронно переносятся в персистентное файловое хранилище. Поэтому размещение журнала на SSD, которое рекомендовано в документации Ceph, многократно ускоряет операции записи.
Цели и результаты
Несколько лет назад Ceph подкупил нас своими впечатляющими возможностями. Хотя многие из них на тот момент работали совсем не идеально, мы приняли решение строить облако именно на нём. В последующие месяцы мы столкнулись с рядом проблем, доставивших нам немало неприятных минут.
Например, сразу после публичного релиза год назад мы обнаружили, что перестроение кластера влияет на его отзывчивость больше, чем хотелось бы. Или что определенный вид операций приводит к существенному увеличению латенси последующих операций. Или что в определенных (к счастью, редких) условиях клиентская виртуальная машина может намертво зависнуть на I/O. Так или иначе, багфикс длительностью в полгода сделал свое дело, и на сегодняшний день мы абсолютно уверены в нашей СХД. Ну а в процессе устранения трудностей мы обзавелись целым рядом инструментов отладки и мониторинга. Один из них — мониторинг длительности всех без исключения операций с блочными устройствами (на данный момент кластер ежесекундно обслуживает несколько тысяч операций чтения/записи). Вот так сегодня выглядит отчет о латенси в нашей админ-панели:
Зелёным на графике отмечена минимальная длительность операций, красным — максимальная, бирюзовым — медиана. Впечатляет, не правда ли?
Хотя система хранения данных уже давно абсолютно стабильна, эти инструменты по-прежнему помогают нам в решении повседневных задач и заодно цифрами подтверждают отличное качество нашего сервиса.
В конечном счете Ceph позволил нам обеспечить:
Serveroid.com остаётся единственным в России и одним из немногих в мире хостеров, кто использует Ceph в продакшене. Благодаря Ceph у нас получилось реализовать то, о чем часто пишут в визионерских постах о будущем облаков — совместить вычислительные ноды и ноды хранилища на обычном железе и достичь показателей, близких к значениям энтерпрайзных «полок» без увеличения стоимости. Ну а поскольку сэкономленные деньги — все равно что заработанные, мы получили возможность снизить цены на услуги практически до уровня западных дискаунтеров. В этом легко убедиться, взглянув на наши тарифы.
Если вы используете выделенный хостинг в своей работе — предлагаем вам попробовать наши услуги в действии и оценить, какие преимущества дает Ceph. Платить ничего не нужно — двухнедельный пробный период и тестовый баланс в 500 рублей вы сможете активировать сразу после регистрации.