лытдыбр работа s3 И какой у вас план, товарищ Жюков? (С)

"""
# riak-admin cluster plan
[...]
Status Ring Pending Node
-------------------------------------------------------------------------------
valid 5.9% 5.9% 'riak@192.168.0.130'
valid 6.3% 5.9% 'riak@192.168.0.131'
valid 5.5% 5.1% 'riak@192.168.0.132'
valid 5.5% 5.1% 'riak@192.168.0.133'
valid 5.5% 5.5% 'riak@192.168.0.134'
valid 5.5% 5.5% 'riak@192.168.0.135'
valid 5.5% 5.5% 'riak@192.168.0.136'
valid 5.5% 5.1% 'riak@192.168.0.137'
valid 5.5% 5.1% 'riak@192.168.0.138'
valid 5.5% 5.1% 'riak@192.168.0.139'
valid 5.5% 5.1% 'riak@192.168.0.140'
valid 5.9% 5.9% 'riak@192.168.0.141'
valid 5.5% 5.1% 'riak@192.168.0.142'
valid 5.5% 5.1% 'riak@192.168.0.143'
valid 5.5% 5.1% 'riak@192.168.0.144'
valid 5.5% 5.1% 'riak@192.168.0.145'
valid 5.5% 5.1% 'riak@192.168.0.146'
valid 5.5% 5.1% 'riak@192.168.0.147'
valid 0.0% 5.1% 'riak@192.168.0.148'
[...]
"""

План, блин, чистый термояд.

лытдыбр работа s3 Удалили 4Тб данных из s3. Логически их не видно. А по факту — удаление из БД riak производится примерно по десятку блоков в секунду. Один блок — в пределах 15Мб, если правильно помню.
Вобщем, это надолго...

лытдыбр работа s3 Прирост общего объёма за месяц — с 19.3Тб до 21.9Тб
Однако, надо что-то делать, иначе местов не хватит.

лытдыбр работа s3 Нашел, почему riak может падать, выражаясь про "нашу базу уже кто-то юзает!"
При большой нагрузке на диск при попытке открыть файл БД делается попытка залочить. Спустя N секунд записать в файл лока не получается (нагрузка всё ж великовата) — ругаемся и выключаемся.

лытдыбр работа s3 Клиент хотел сэкономить и делал бекапы в S3. Согласен, 3 руб/Гб в месяц дешевле 5 руб/Гб.
Но есть одно но! У товарища глюкнул duply, который настраивал он, и не удалил старые файлы.
В результате за месяц вышло примерно так же, как в случае штатного резервного копирования, но с возможными проблемами при восстановлении данных (с учётом глюков — вероятность проблем повышается).

лытдыбр работа s3 Таки покормили кластер риак железом. Переваривает.

лытдыбр работа s3 Риак начал страдать падучей, а железо будет только на следующей неделе...
Однако, хреново.
Пока пытаюсь обходиться мелким тюнингом типа bitcask.max_merge_size = 50GB

лытдыбр работа s3 riak зачихал в очередной раз.
Вначале он упал одним из узлов. Причина — "а хто-то тут ещё кроме меня файлы БД юзает!"
Поднял. Через полчаса посмотрел, что как — трансфер разделов висит.
Перепнул (штатно!) оба узла, участвовавшие в трансфере — один из узлов начал сыпать ошибками "файл повреждён".
Вот какого хрена оно повреждает при штатном рестарте?! Ладно, это не файл БД, можно прибить.
Теперь перестали отдавать крупные файлы.
Помог только животворящий пинок в кластер (в смысле, перезапустил вообще все узлы по-очереди).
Чёрт знает что... Жду железа, а то его кормить нечем... Да и на ceph стоило бы переехать...

лытдыбр работа s3 Чихающий s3, который недокормили железом, почему-то за последний месяц пользуется ахренительной популярностью.
У нас что, где-то резко подскочили цены на хранилища?

лытдыбр работа s3 Обнаружил файл, который невозможно получить из хранилища, для которого невозможно узнать подробную информацию (права доступа и т.п.), но который видно на листинге бакета.
Хочу riak-cs-fsck...

лытдыбр riak работа s3 Риак — странная штука. Вот например, как он планирует распределить место в кластере после добавления ещё одного узла:

Status Ring Pending Node
-------------------------------------------------------------------------------
valid 8.6% 8.6% 'riak@192.168.0.130'
valid 8.2% 7.8% 'riak@192.168.0.131'
valid 8.2% 7.4% 'riak@192.168.0.132'
valid 8.2% 7.4% 'riak@192.168.0.133'
valid 8.2% 7.4% 'riak@192.168.0.134'
valid 8.2% 7.4% 'riak@192.168.0.135'
valid 8.2% 7.4% 'riak@192.168.0.136'
valid 8.2% 7.4% 'riak@192.168.0.137'
valid 8.2% 7.4% 'riak@192.168.0.138'
valid 8.2% 7.4% 'riak@192.168.0.139'
valid 8.2% 7.4% 'riak@192.168.0.140'
valid 9.4% 9.4% 'riak@192.168.0.141'
valid 0.0% 7.4% 'riak@192.168.0.142'
-------------------------------------------------------------------------------
Valid:13 Leaving:0 Exiting:0 Joining:0 Down:0

Обратите внимание на то, что у .141 как был самый большой процент, так и остался.

лытдыбр работа s3 Для того, чтобы riak нормально работал, его периодически (где-то ближе к 70% заполнения диска на узлах) надо подкармливать серверами.

лытдыбр цитата работа s3 Из общения с продаваном riak:
"""
We have customers putting petabytes of data in CS and not using raid, so it would be interesting to hear what your reasons for using raid are? As Raid is complex to use.
"""

Вот только на raid мы перешли как раз после потери данных

лытдыбр riak работа s3 Наблюдаю в логах riak надписи вида:
2016-02-15 09:22:07.687 [info] <0.4996.18> Merged {["/var/lib/riak/bitcask/28544953854119197621165719388989902727654932480/304.bitcask.data", ...... ,[]} in 637.526956 seconds.

При этом занятое место на диске только увеличивается. Интересно, оно совсем всё сожрёт или всё ж откатит по окончании всех мержей?

лытдыбр работа s3 В процессе повторного расширения ceph (после тестов на накрытие одного из узлов) наблюдаю:
102/2499186 objects degraded (0.004%); 766347/2499186 objects misplaced (30.664%);

При этом первое соотношение не меняется, в отличие от второго. По-моему, должно быть наоборот, так как degraded — это когда есть только одна копия и это хуже, чем когда одна из копий misplaced.
Надо поискать ручки для кручения приоритетов на сей предмет.

лытдыбр работа s3 Как и riak, ceph требует пинка при падении одного из узлов. Это нормально, везде так.
Но что мне нравится, так это перебалансировка кластера после того, как указал ему, что того узла больше нет и не будет.
Упирается в лимит по iops на вдс И при этом скорость работы с контентом меняется незначительно по сравнению с riak (на больших файлах — нет разницы с обычной работой, на мелких — деградация где-то полтора раза, причём во время работы клиентов скорость перебалансировки заметно снижается, то есть приоритет — у клиентов)

лытдыбр работа s3 Скорость ответа ceph по s3 в момент, когда он в состянии "так, давайте-ка шустренько распределим полкластера по новым серверам", примерно соответствует скорости ответа riak-cs/riak в момент, когда туда лезет ровно один клиент и в кластере больше вообще ничего не происходит.

лытдыбр работа s3 После письма в рассылку с конкретной проблемой riak в почту постучался продаван этого самого риака на предмет платной техподдержки.
Я всё понимаю, судя по объёмам данных клиент крупный и т.п. Но, блин, оно ж себя и так-то еле окупает (сопутствующий сервис), а тут вообще будет убыточным.

лытдыбр работа s3 Выяснил, что в s3 от ceph можно создать пользователей с заданными ключами.
Чтож, не понадобится править фронтенд.

лытдыбр работа s3 Краткое сравнение возможностей настройки riak+riak-cs, sx+libres3 и ceph с его rados gw:

* sx — никаких ручек для настройки, кроме как задать, сколько места можно отожрать на конкретном узле.
* riak+riak-cs — ручек для настройки много, но бОльшая часть спрятана и недокументирована. Правда, для того, чтоб загрузить терабайт хрени в кластер оно не шибко надо. Шибко надо оно, чтоб в этом терабайте был миллион-другой файлов в одном бакете...
* ceph — ручек для настройки дохрена. И все надо настраивать, иначе даже для теста получится некая хрень...