← All posts tagged s3

stanislavv
URL баян opennet.ru — Доступна бета-версия ОС Trident на базе Void Linux
комментарий:
"""
Ждём операционные системы Cirrus Logic, Tseng Labs, S3 Graphics и Matrox. Хотя, в обзоре компании S3 говорили, что число 3 означает третий по счёту стартап, поэтому пусть будет S4
"""

Кстати, на заре моего общения с писюками имел дело со всеми видеокартами, включая трайдент (этот вообще у меня был isa, но зато — с отличными драйверами под win3.1).
stanislavv
баян баш Сейчас в офисе:
— Ребята, не могу из трелло скачать документик. Он на S3 Амазона ссылается, а он в бане
— Скачай из репы
— Репа на Гугле хостится, тоже грустно
— Блять, что же делать?
— Скинь через телеграм, плз...
stanislavv
работа лытдыбр ВНЕЗАПНО выяснилось, что кластер elasticsearch таки надо бекапить.
Посмотрел варианты — сделать бекап даже всех виртуалок не равноценно бекапу всего кластера, так как одновременно они не начнутся и не сделаются.
Есть возможность сделать снапшот в указанное место. Указанное место может быть на общей фс либо на каком-нибудь s3.
Ни того ни другого пока предоставить не могу, ибо бекапные сервера — без nfs, а местный кластер s3 успешно выпилили.
Такое ощущение, что таки придётся создавать сильно локальный s3 на одном из серверов бекапов.
stanislavv
работа лытдыбр Отключили запись в s3 и неавторизованный доступ. Собственно, как предупреждали каждые 3 дня последний месяц.
Сразу вопросы от клиентов "а что это у нас картинки не грузятся"
stanislavv
работа лытдыбр идиоты Странные люди подали на контору в суд в связи с потерей данных в кластере s3.
Из доказательств: скриншоты с датами за пару месяцев до заключения договора и примерно за месяц до запуска(!) услуги вообще и ls -l /var/www | wc -l, показывающий "количество файлов, оставшееся в облаке"
Третьетег. И это мягко говоря.
stanislavv
работа лытдыбр 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'
[...]
"""

План, блин, чистый термояд.
stanislavv
работа лытдыбр s3 Удалили 4Тб данных из s3. Логически их не видно. А по факту — удаление из БД riak производится примерно по десятку блоков в секунду. Один блок — в пределах 15Мб, если правильно помню.
Вобщем, это надолго...
stanislavv
работа лытдыбр s3 Нашел, почему riak может падать, выражаясь про "нашу базу уже кто-то юзает!"
При большой нагрузке на диск при попытке открыть файл БД делается попытка залочить. Спустя N секунд записать в файл лока не получается (нагрузка всё ж великовата) — ругаемся и выключаемся.
stanislavv
работа лытдыбр s3 Клиент хотел сэкономить и делал бекапы в S3. Согласен, 3 руб/Гб в месяц дешевле 5 руб/Гб.
Но есть одно но! У товарища глюкнул duply, который настраивал он, и не удалил старые файлы.
В результате за месяц вышло примерно так же, как в случае штатного резервного копирования, но с возможными проблемами при восстановлении данных (с учётом глюков — вероятность проблем повышается).
stanislavv
работа лытдыбр s3 riak зачихал в очередной раз.
Вначале он упал одним из узлов. Причина — "а хто-то тут ещё кроме меня файлы БД юзает!"
Поднял. Через полчаса посмотрел, что как — трансфер разделов висит.
Перепнул (штатно!) оба узла, участвовавшие в трансфере — один из узлов начал сыпать ошибками "файл повреждён".
Вот какого хрена оно повреждает при штатном рестарте?! Ладно, это не файл БД, можно прибить.
Теперь перестали отдавать крупные файлы.
Помог только животворящий пинок в кластер (в смысле, перезапустил вообще все узлы по-очереди).
Чёрт знает что... Жду железа, а то его кормить нечем... Да и на ceph стоило бы переехать...
stanislavv
работа лытдыбр s3 Обнаружил файл, который невозможно получить из хранилища, для которого невозможно узнать подробную информацию (права доступа и т.п.), но который видно на листинге бакета.
Хочу riak-cs-fsck...
stanislavv
работа лытдыбр s3 riak Риак — странная штука. Вот например, как он планирует распределить место в кластере после добавления ещё одного узла:

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 как был самый большой процент, так и остался.