Щупал я всякие разные и разнообразные Block/File Storage с SAN'ами и был в общем-то счастлив, пока не появилась задача понять — что же такое Object Storage? И при наличии уже многих решений на рынке выбрать тот самый…
Зачем же Object Storage?
Ну, во-первых — это система хранения, специально разработанная именно для хранения объектов. И это именно и прежде всего Storage.
Во-вторых — система элегантно превращается в WORM (write once read many) и обратно.
В-третьих — достигается разделение пулов с данными для разных пользователей, гибкая настройка квотирования по пользователям, размерам пулов, количеством объектов, количеством bucket в пулах. В общем, нормальный функционал администрирования системы хранения.
В-четвертых, в-пятых и т.д. Каждый, кто знает зачем ему это нужно, уверен найдет еще не одно преймущество. А может и недостатки.
Требования к выбору объектного хранилища:
— де факто стандарт ОС — CentOS;
— нужно объектное хранилище, резервированное между ЦОД;
— по возможности быть совсем бесплатным.
Совсем такие скудные и туманные требования.
Начал я процесс поиска с обзора имеющихся:
- ScaleIO — круто, просто, но шаг в сторону — лицензия, а так хочется независимости. И с ходу не нашел возможности обеспечения отказоустойчивости конфигурации для ЦОДов;
- OpenIO — видимо начинающий проект и я не нашел описания нужного мне функционала;
- Ceph — что же, можно попробовать. Изначальным скудным требованиям удовлетворяет.
Остановив свой выбор на Ceph я встал на тропу хождения по граблям, коих оказалось достаточно, но и пройдены они были с оптимизмом.
Первое, что было сделано — это выбор версии. Последнюю Luminous ставить не стал, только-только был релиз, а мы же серьезная компания. :) Про Hammer было много нареканий. Мне по душе пришелся Jewel в stable релизе. Создал репозиторий, зарсинкал его с ceph.com, поставил задания в крон и выпустил его через nginx. Еще нам нужен будет EPEL:
# Синхронизуем репозиторий Ceph-Jewel
/usr/bin/rsync -avz --delete --exclude='repo*' rsync://download.ceph.com/ceph/rpm-jewel/el7/SRPMS/ /var/www/html/repos/ceph/ceph-jewel/el7/SRPMS/
/usr/bin/rsync -avz --delete --exclude='repo*' rsync://download.ceph.com/ceph/rpm-jewel/el7/noarch/ /var/www/html/repos/ceph/ceph-jewel/el7/noarch/
/usr/bin/rsync -avz --delete --exclude='repo*' rsync://download.ceph.com/ceph/rpm-jewel/el7/x86_64/ /var/www/html/repos/ceph/ceph-jewel/el7/x86_64/
# Синхронизуем репозиторий EPEL7
/usr/bin/rsync -avz --delete --exclude='repo*' rsync://mirror.yandex.ru/fedora-epel/7/x86_64/ /var/www/html/repos/epel/7/x86_64/
/usr/bin/rsync -avz --delete --exclude='repo*' rsync://mirror.yandex.ru/fedora-epel/7/SRPMS/ /var/www/html/repos/epel/7/SRPMS/
# Обновляем репозиторий Ceph-Jewel
/usr/bin/createrepo --update /var/www/html/repos/ceph/ceph-jewel/el7/x86_64/
/usr/bin/createrepo --update /var/www/html/repos/ceph/ceph-jewel/el7/SRPMS/
/usr/bin/createrepo --update /var/www/html/repos/ceph/ceph-jewel/el7/noarch/
# Обновляем репозиторий EPEL7
/usr/bin/createrepo --update /var/www/html/repos/epel/7/x86_64/
/usr/bin/createrepo --update /var/www/html/repos/epel/7/SRPMS/и приступил к дальнейшему планированию и установке.
Сначала необходимо нарисовать архитектуру решения, пусть даже и тестового, но которое может легко быть смаштабировано до прода, к которому мы будем стремиться. У меня получилось следующее:
— по три OSD ноды в каждом ЦОД;
— три MON ноды на трех площадках (по одной на каждой), которые будут обеспечивать большинство для кластера Ceph; (ноды-мониторы можно поднимать совместно с другими ролями, но я предпочел их сделать виртуальными и вынести вообще на VMWare)
— две ноды RGW (по одной в каждом ЦОД), которые обеспечат доступ по API к Object Storage по протоколу S3 или Swift; (ноды-RadosGW можно поднимать совместно с другими ролями, но я предпочел их сделать виртуальными и тоже вынести на VMWare)
— нода для деплоя и централизованного управления; (виртуальный сервер, который катается между ЦОД'ами в среде VMWare)
— нода мониторинга кластера и текущего/исторического перфоманса. (та же история, что и с нодой деплоя)
Спланировать сети — я же использовал одну сеть для «экосистемы» Ceph кластера. Для доступа к нодам деплоя, мониторинга и RGW нодам было проброшено две сети:
— сеть Ceph кластера, для доступа к ресурсам;
— сеть «public», для доступа «из-вне» к этим нодам.
Официальная документация рекомендует внутри кластера использовать разные сети для heartbeat и движения данных между OSD нодами, хотя та же документация гласит, что использование одной сети уменьшает latency… Я выбрал одну сеть для всего кластера.
Установка кластера начинается с базовой процедуры: подготовка серверов-нод с ОС CentOS.
— настраиваем репозитории, если они локальные. (например, как у меня) Еще нам потребуется EPEL-репозиторий;
— на всех нодах в /etc/hosts вносим информацию о всех нодах кластера. Если в инфраструктуре используется DHCP, то лучше сделать bind для адресов и все-равно заполнить /etc/hosts;
— настраиваем ntp и синхронизуем время, это критично, для корректной работы Ceph;
— создаем пользователя для управления кластером Ceph, любое имя, главное не одноименное — ceph.
Например так:
sudo useradd -d /home/cephadmin -m cephadmin
sudo passwd cephadmin
echo "cephadmin ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/cephadmin
chmod 0440 /etc/sudoers.d/cephadmin— устанавливаем ssh-сервер на ноде деплоя, генерируем ключи для созданного пользователя, копируем ключи на все ноды кластера, прописываем в sudo с опцией NOPASSWD. Нам нужно будет получить для пользователя беспарольный вход с деплой-ноды на все ноды кластера;
— у созданного пользователя в каталоге .ssh создаем файлик config, описываем все ноды и ставим права 600 на этот файл;
[cephadmin@ceph-deploy .ssh]$ cat config
Host ceph-cod1-osd-n1
Hostname ceph-cod1-osd-n1
User cephadmin
...................
Host ceph-cod2-osd-n3
Hostname ceph-cod2-osd-n3
User cephadmin— открываем порты 6789/tcp и 6800-7100/tcp в firewalld, если вы его решили оставить;
— отключаем SELinux; (хотя с версии ceph — Jewel с установкой накатываются нормальные SE-политики)
— на ноде управления кластером выполняем yum install ceph-deploy.
Вроде все готово! Переходим к установке и настройке самого кластера
В домашнем каталоге нашего пользователя создаем директорию, где будут лежать конфиги кластера. Эту папку лучше не терять, т.к. восстановить будет весьма проблематично. В процессе конфигурации кластера и прикручивания разных ролей и сервисов, эта директория будет пополняться файликами и ключиками.
Создаем первую MON ноду в нашем будущем кластере: ceph-deploy new #имя_нашей_MON_ноды. В созданной ранее директории появился файл ceph.conf, в который теперь будет вноситься описание кластера и применяться его содержимое на нужных нам нодах.
Устанавливаем сам Ceph-Jewel на всех нодах: ceph-deploy install --release=jewel --no-adjust-repos #нода1 #нода2… #нодаN. Ключ --no-adjust-repos необходимо использовать, если репозиторий для установки локальный и чтобы установочный скрипт искал путь в существующих /etc/yum.repos.d/*.repo, а не пытался прописать свой репозиторий. С версии Jewel по умолчанию ставится stable версия, если явно не указано обратное.
После успешной установки инициализируем кластер ceph-deploy mon create-initial
По завершении инициализации кластера, в файл ceph.conf записывается первоначальная конфигурация, в том числе и fsid. Если этот fsid в последствии будет изменен или потерян кластером — это приведет к его «развалу» и, как следствие, потери информации! Итак, после наличия первоначальной конфигурации в ceph.conf мы его смело открываем (сделав backup) и начинаем править и вносить те значения, которые нам нужны. При проливке по нужным нам нодам обязательно указываем опцию --overwrite-conf. Ну и примерное содержание нашего конфига:
[root@ceph-deploy ceph-cluster]# cat /home/cephadmin/ceph-cluster/ceph.conf
[global]
fsid = #что-то_там
mon_initial_members = ceph-cod1-mon-n1, ceph-cod1-mon-n2, ceph-cod2-mon-n1
mon_host = ip-adress1,ip-adress2,ip-adress3
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
#Choose reasonable numbers for number of replicas and placement groups.
osd pool default size = 2 # Write an object 2 times
osd pool default min size = 1 # Allow writing 1 copy in a degraded state
osd pool default pg num = 256
osd pool default pgp num = 256
#Choose a reasonable crush leaf type
#0 for a 1-node cluster.
#1 for a multi node cluster in a single rack
#2 for a multi node, multi chassis cluster with multiple hosts in a chassis
#3 for a multi node cluster with hosts across racks, etc.
osd crush chooseleaf type = 1
[client.rgw.ceph-cod1-rgw-n1]
host = ceph-cod1-rgw-n1
keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-cod1-rgw-n1/keyring
rgw socket path = /var/run/ceph/ceph.radosgw.ceph-cod1-rgw-n1.fastcgi.sock
log file = /var/log/ceph/client.radosgw.ceph-cod1-rgw-n1.log
rgw dns name = ceph-cod1-rgw-n1.**.*****.ru
rgw print continue = false
rgw frontends = «civetweb port=8888»
[client.rgw.ceph-cod2-rgw-n1]
host = ceph-cod2-rgw-n1
keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-cod2-rgw-n1/keyring
rgw socket path = /var/run/ceph/ceph.radosgw.ceph-cod2-rgw-n1.fastcgi.sock
log file = /var/log/ceph/client.radosgw.ceph-cod2-rgw-n1.log
rgw dns name = ceph-cod2-rgw-n1.**.*****.ru
rgw print continue = false
rgw frontends = «civetweb port=8888»Также есть пара замечаний:
— если сервис ceph-radosgw.* не стартует, то у меня была проблема с созданием файла логов. Решил это просто создав файл руками и поставив на него маску 0666;
— можно выбирать провайдера API к кластеру между civetweb, fastcgi и apache, вот что глаголит официальная дока:
As of firefly (v0.80), Ceph Object Gateway is running on Civetweb (embedded into the ceph-radosgw daemon) instead of Apache and FastCGI. Using Civetweb simplifies the Ceph Object Gateway installation and configuration.
Если вкратце, то в нашем файле я прописал глобальные переменные, правила репликации и правило «выживания» кластера, а также RGW ноды, допущенные к кластеру. Что касается параметров osd pool default pg num и osd pool default pgp num была найдена интересная заметка:
And for example a count of 64 total PGs. Honestly, protection group calculations is something that still does not convince me totally, I don’t get the reason why it should be left to the Ceph admin to be manually configured, and then often complain that is wrong. Anyway, as long as it cannot be configured automatically, the rule of thumb I’ve find out to get rid of the error is that Ceph seems to be expecting between 20 and 32 PGs per OSD. A value below 20 gives you this error, and a value above 32 gives another error.
So, since in my case there are 9 OSDs, the minimum value would be 9*20=180, and the maximum value 9*32=288. I chose 256 and configured it dinamically.
И вот эта:
PG (Placement Groups) — группа размещения или логическая коллекция объектов в Ceph, которые реплицируются в OSD. Одна группа может сохранять данные на несколько OSD, в зависимости уровня сложности системы. Формула для вычисления групп размещения для Ceph следующая:
Кол-во PG = (кол-во OSD * 100) / кол-во реплик
При этом результат должен быть округлён до ближайшей степени двойки (например, по формуле = 700, после округления = 512).
PGP (Placement Group for Placement purpose) — группы размещения для целей расположения. Количество должно быть равным общему числу групп размещения.
И на всех нодах, где есть ключ, меняем права: sudo chmod +r /etc/ceph/ceph.client.admin.keyring
До того, как OSD устройства вводить в кластер, на OSD нодах необходимо выполнить подготовительные работы:
Разбиваем диск для использования под журнал. Это должен быть SSD (но не обязательно, достаточно просто выделенного диска) и быть разделен не более чем на 4 равные партиции, т.к. партиции должны быть primary:
parted /dev/SSD
mkpart journal-1 1 15G
mkpart journal-2 15 30G
mkpart journal-3 31G 45G
mkpart journal-4 45G 60GИ форматируем в xfs. Меняем права на диски на OSD нодах, которые предназначены для журналов и которые будут управляться Ceph:
chown ceph:ceph /dev/sdb1
chown ceph:ceph /dev/sdb2
chown ceph:ceph /dev/sdb3И обязательно меняем GUID для этих партиций, чтобы корректно отрабатывал udev и приезжали правильные права на устройства после перезагрузки. Я наступил на эти грабли, когда после перезагрузки OSD нода поднялась, но сервисы были в состоянии failed. Т.к. правильно отработавший udev назначил владельца и группу по умолчанию root:root. Как говорится результат превзошел ожидания… Чтобы этого не случилось делаем так:
sgdisk -t 1:45B0969E-9B03-4F30-B4C6-B4B80CEFF106 /dev/sdb
GUID должен быть именно такойПосле с нашей деплой ноды выполняем ceph-deploy disk zap и ceph-deploy osd create. На этом базовая инсталляция кластера закончена и можно посмотреть его состояние командами ceph -w и ceph osd tree.
А как же нам обеспечить отказоустойчивость по ЦОД'ам?
Как оказалось в Ceph есть очень сильный инструмент — работа с crushmap
В этой карте можно вводить несколько уровней абстракции и я сделал до примитивного просто — я ввел понятие rack и в каждый rack разложил ноды по признаку ЦОД'а. С этого момента у меня данные были перераспределены таким образом, что, записанные в один rack имели обязательную реплику в другом rack. Т.к. алгоритм Ceph считает хранение двух реплик в одной «стойке» ненадежным. :) Вот собственно и все, причем, выключение всех нод одного ЦОД'а действительно оставило данные доступными.
[cephadmin@ceph-deploy ceph-cluster]$ ceph osd tree
ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 1.17200 root default
-8 0.58600 rack ceph-cod1
-2 0.19499 host ceph-cod1-osd-n1
0 0.04900 osd.0 up 1.00000 1.00000
1 0.04900 osd.1 up 1.00000 1.00000
2 0.04900 osd.2 up 1.00000 1.00000
3 0.04900 osd.3 up 1.00000 1.00000
-3 0.19499 host ceph-cod1-osd-n2
4 0.04900 osd.4 up 1.00000 1.00000
5 0.04900 osd.5 up 1.00000 1.00000
6 0.04900 osd.6 up 1.00000 1.00000
7 0.04900 osd.7 up 1.00000 1.00000
-4 0.19499 host ceph-cod1-osd-n3
8 0.04900 osd.8 up 1.00000 1.00000
9 0.04900 osd.9 up 1.00000 1.00000
10 0.04900 osd.10 up 1.00000 1.00000
11 0.04900 osd.11 up 1.00000 1.00000
-9 0.58600 rack ceph-cod2
-5 0.19499 host ceph-cod2-osd-n1
12 0.04900 osd.12 up 1.00000 1.00000
13 0.04900 osd.13 up 1.00000 1.00000
14 0.04900 osd.14 up 1.00000 1.00000
15 0.04900 osd.15 up 1.00000 1.00000
-6 0.19499 host ceph-cod2-osd-n2
16 0.04900 osd.16 up 1.00000 1.00000
17 0.04900 osd.17 up 1.00000 1.00000
18 0.04900 osd.18 up 1.00000 1.00000
19 0.04900 osd.19 up 1.00000 1.00000
-7 0.19499 host ceph-cod2-osd-n3
20 0.04900 osd.20 up 1.00000 1.00000
21 0.04900 osd.21 up 1.00000 1.00000
22 0.04900 osd.22 up 1.00000 1.00000
23 0.04900 osd.23 up 1.00000 1.00000P.S. Что же хочется сказать?
В принципе Ceph оправдал мои ожидания. Как объектного хранилища. Конечно есть особенности его настройки и организация пулов для такого вида хранения не совсем «книжная» — типа вот есть пул с датой, а это пул с метадатой. Об этом я еще постараюсь рассказать.
Также пробовал поиграться с блочным хранением. К сожалению «выбрасывать» блочные устройства через FC Ceph не умеет, или я не нашел как. Что до iSCSI — по мне это не true и happy way. Хотя это работает, даже с MPIO.
Три источника, которые мне показались наиболее полезными:
официальный
неофициальный
шпаргалка
Комментарии (22)
mikkisse
26.09.2017 19:14Как поведет себя Ceph, когда один ЦОД будет изолирован от других?
mpv86 Автор
26.09.2017 19:24Я на практике это не делал, кстати, спасибо за совет, в ближайшие недели попробую.
Документация же говорила о том, что для этого нам и нужно кворумное большинство. При сплите кворумное меньшинство должно прибивать службы на тех osd нодах, до которых может дотянуться.
Большинство, понятно, выживает. Какие-то объекты нужно будет перезаписать. Но это уже вопрос приклада.
onyxmaster
26.09.2017 19:27+1Ходили слухи, что перебалансировка при длительном выводе из строя некоторого количества OSD убивает сеть напрочь (собственно это одна из причин почему они рекомендуют делить control и data сети). Не знаете, починили?
mpv86 Автор
26.09.2017 19:36Ну если они допускают использование одной сети, то видимо проблем в этом уже не видят.
Сетевики не жаловались, да и данных у меня на нем пока 300gb…
Там еще есть нюанс с настройкой gc параметров. Нужно искать баланс во временном интервале выполнения collector'а. Я думаю мне это еще предстоит.
SinTeZoiD
26.09.2017 23:42+2Перевели гайд с сайта и выложили на хабр? Отличный уровень!
По существу:
А как же нам обеспечить отказоустойчивость по ЦОД'ам?
Как оказалось в Ceph есть очень сильный инструмент — работа с crushmap
Ужасно! Как уже было сказано выше сети при балансировке будет плохо.
Но и это не самое печально. Самое печальное, что вы даже не загуглили как делать RGW multi dc
Механизм уже встроен в RGW и называется federation. И не надо таскать низкоуровневые данные через узкий канал между датацентрами.
Для тех, у кого есть вопросы по ceph его настройке, проектированию кластеров и прочему — проходите в наш телеграм канал t.me/ceph_ru нас уже почти 500 человек.mpv86 Автор
26.09.2017 23:53-2Сказать то что хотели?
Или так, попиаритьсяSinTeZoiD
27.09.2017 00:40+1Сказать, что Ваше решение имеет недостатки как минимум по нагрузке на сеть, что надо гуглить best prictice перед тем как внедрять решения, что корявые внедрения отбрасывают тень на технологию, которая и так не идеальна. А пиар телеграм канала возможно убережет от ошибок следующих за вами «первопроходцев».
mpv86 Автор
27.09.2017 09:33Простите, конечно, но Ваши рассуждения так «по-нашему» бескомпромиссные. Не разобравшись в проблеме, надо сказать, что все не так.
Мне это анекдот напомнило:
49% несчастных случаев начинаются со слов «смотри, как умею»
51% — со слов «смотри как надо»
Я неплохо умею читать документацию, тем более «гуглить». И я ни в коем случае не собираюсь «отбрасывать тень» на технологию и тем более считать себя «первопроходцем». Многие полезные советы я учту и опробую. Тем более, что это, пока, далеко не продакшн.
Проблема в том, что у меня нет DR ЦОДа, они active-active. И как именно мне поможет federation при работе кластера в active-active? Я ответа не нашел, подскажите?
Что касается репликации 2 — я много читал, что не делайте так, но есть нюанс. Данные критичны с точки зрения законов РФ по хранению, при этом SLA исчисляется сутками. Мне говорят (и при том обоснованно) на тебе ленты, поднимемся из бэкапа. Кстати еще одна проблема в отсутствии federation.
При этом сейчас софт работает с блочными distributed томами — вот это дорого.
Загрузка в сутки порядка 200 файлов по 5-10Мб. Не ахти как.
Касаемо сети, мне никто не даст ее «положить». Есть, по крайней мере, rate limit для моего vlan. «Моргнуть» может по разному, и вот если будет ложиться FC, из-за initial copy, вот тут прям не знаю даже что лучше будет.
Вообще в любой книжке по архитектуре написано так: «вот так вот нужно, но вы, это, смотрите по обстоятельствам. Как бы чего не сломать.» :)SinTeZoiD
27.09.2017 11:57Не разобравшись в проблеме, надо сказать, что все не так.
Ваш гайд подталкивает к неправильной архитектуре — значит это плохой гайд. Если у вас есть нюансы, которые привели вас к такой архитектуре, то необходимо их указать, что сделано не было. Например зачем active-active между ЦОД? Как настроена балансировка RGW? Round-robin?
Загрузка в сутки порядка 200 файлов по 5-10Мб.
У меня есть подозрение, что можно было обойтись и без CEPH.mpv86 Автор
27.09.2017 12:31Да, об указании на нюансы, впредь буду больше внимания обращать.
Что касается active-active между ЦОД. Это не я решал. Более того, это было уже до меня. Так построено приложение, что работают ноды кластера в режиме active-active. В общем — это еще один де-факто.
Нет, как я понял, round-robin используется для поочередного доступа к ceph через развернутые RadosGW.
В моем случае работа узла кластера должна быть локализована в рамках ЦОД но с общим хранилищем. В каждом ЦОД свой RGW. Потом должен появиться резерв по доступу, соответственно по 2 RGW ноды на ЦОД с попарной балансировкой round-robin.
Касаемо количества файлов. Читаются они чаще, чем пишутся. Соответственно и SLA не нужно путать с QoS системы. Конечно же это не значит, что при нормальной работе все готовы ждать сутками. Тогда можно носить все дискетками и вообще не заморачиваться.
Конечно можно обойтись без ceph. Можно много без чего обходиться. Можно было поднять nfs-шару, можно две и их синкать, можно и не nfs. В общем костыли на любой вкус. :)
rumanzo
27.09.2017 08:02+1Зря вы взяли связку centos + jewel.
В centos достаточно старое ядро, и когда вы заходите создать rbd то кроме feature layering использовать не сможете, rbd не замаппится, а в логах увидете что то вроде unsupported feature 0x09. Потом когда вы заходите выкинуть rbd по iSCSI то вы можете получить подвисший модуль lio в ядре и полудохлую ноду. А если захотите ещё и связать это с вин кластером, да еще чтобы и таргеты дублировались, с mpio, то вам ещё понадобятся и блокировки через rbd, а это ещё и ядро суси с патчами и прикладом тянуть. То ещё веселье.
Плюс с цефом в общем то рекомендуется (http://docs.ceph.com/docs/master/start/os-recommendations/) использовать более свежее ядро если вы используете rbd или cephfs (да, конкретно сейчас это не ваш случай, но тем не менее), там цефовские модули посвежее, и со iscsi проблем меньше, и в сетевом стеке изменения, и т.д.
По поводу luminous — у вас не было бы проблем с udev, selinux, не нужно было бы прописывать guid'ы и chown'ить блочные устройства. Деплой легче, автоматическая разбивка на device classes, создать раздельные пулы на разных типах устройств в разы проще. Допилили bluestore, скорость выше. Облегчили процесс замены дисков (ceph osd destroy/purge). Сделали overwrites для erasure coded пулов через реплицируемые пулы. Ввели прозрачную компрессию. Ввели простенький, но всё же мониторинг, встроили плагины для zabbix, prometheus, etc. Cephfs наконец то поддерживает одновременную работу нескольких сервисом метадаты. По сравнению с jewel более быстрый детект неработоспособности osd (введено в релизе kraken). То есть если вы намеренно погасили ноду, то osd сразу входят в состояние down, и ваше IO не прерывается, а в случае если вы его выключили по кнопке, или упала сеть, у вас IO полностью прерывается на срок от 20 секунд и до n минут, что уже вполне хватает чтобы ваши виртуалки упали, а клиенты получили подвисший fd (в случае с rbd). В релизах kraken (11) и выше с этим дела обстоят намного лучше. Ну и других приятных и полезных изменений там хватает. Так же стоит добавить что luminous это тоже lts, что обновление с jewel (и kraken) будет не таким простым (из-за blue store в частности), и что по части багов jewel вряд ли будет сильно лучше luminous.
Ещё вам к раздумьям: цеф отвратительно балансит данные. Существует далеко не нулевая вероятность, что один диск в пуле у вас заполнен на 70% а другой на 95% и цеф вешает флаг full на кластер из-за этого, и у вас всё встаёт колом. Собственно по этому в церне написали свои хелперы на питоне, в частности для ребаланса по крону. Правда для 12 версии пришлось переписывать немного, для поддержки device class. Собственно ссылки по теме:
indico.cern.ch/event/567516/contributions/2293565/attachments/1331568/2001323/050916-cephupdate.pdf
github.com/cernceph/ceph-scripts
И по статье промелькнуло ssd, но нет конкретики какие вы диски используете и в каком кейсе. С cache tiering'ом тоже ведь есть свои нюансы. Не описано какую сеть вы используете (1g/10g/что-то серьезнее?), а ведь сеть для цефа критична, проблемы с ней выльются в подвисших с stuck_unclean pg, в подвисших запросах (blocked requests) и тд. Как ceph себя показывает в вашем случае двух цодов?mpv86 Автор
27.09.2017 09:43Спасибо за дельные замечания!
ssd только как журнальные устройства. Tiering нет и не предвидится. Задача не та.
Сеть 10g. По части двух цодов показывает сейчас стабильно для возложенных задач. Естественно, это пока в тестировании и еще долго в нем пробудет.
n1nj4p0w3r
27.09.2017 14:57+1Плюнуть на blue store который привносит нормальное журналирование+хеширование блоков(при том что порча блока на primary OSD равносильна порче всех реплик) не говоря об удалении лишнего оверхеда на OSD потому-что «мы серьезная компания» — это сильно.
PS: цеф не умеет не iscsi не fc, это умеет LiO, который в ближайшем будущем так-же избавится от лишнего оверхеда смены контекста, а так-же научится нормальному MPIO с VAAI для ceph с.м. tcmu-runner 1.3 находящийся в стадии RCmpv86 Автор
27.09.2017 15:33потому-что «мы серьезная компания», так, минутка юмора. Не более.
Lio пока не умеет делать fc-target из RBD. Это плохо.
YangAngel
А как построена кластерная сеть между ЦОД?
mpv86 Автор
А сеть мне отдавали сетевики :)
Т.к. я не большой спец в ip-сетях, попробую объяснить.
Я так понимаю, что vlan растянут по ЦОДам, поэтому у меня вообще не было проблем. Для меня это просто одноранговая сеть.
Но в принципе — это не имеет значения. Главное чтобы были маршруты и описание в hosts. Dhcp тоже не плохо.
YangAngel
То есть вы хотите сказать, что и OSD и MON все в одну сеть?
Тогда при отключении одного из ЦОД могут возникнуть трудности.
Канал будет забит, мониторы не смогу общаться, PG будут «стакаться» и будет не очень весело.
mpv86 Автор
Может я на эти грабли не вставал еще?
Или у меня данных на нем просто мало лежит.
Я гасил половину кластера и через 4 часа поднимал. Сеть на 15% только прогрузилась. Ну это из мониторинга нод кластера. Повторю эксперименты и подключу к ним сетевиков. Поизучаю поведение всесторонне :)
YangAngel
Лучше разделить. Правила хорошего тона.
Recovery и blackfilling будут обрабатываться по кластерной сети без опасений потерять MON.
Ну и в целом сами OSD будут между собой по ней работать.
На практике могу сказать, что при нормальной работе где-то 150-200 Mbps.
При ночных бэкапах на виртуалках + (deep) scrubbing где-то до 500-700 Mbps прыгает. RBD, 17 Tb, all flash.
mpv86 Автор
Ясно, спасибо за совет. Правила хорошего тона — несомненно must have.
All flash. Вот с последних двух забугорных слов стала понятна нагрузка.