stanislavvv: (Default)
Всё отлично работает, данные из банка получаются и ваще зашибись.
Но есть одно но: спустя несколько суток коннекта типа-защита от внешних соединений прекращает работу.
В принципе наплевать и забить, но у меня нагиос настроен ругаться на наличие связи с сим сервером доступа - в штатном режиме это означает отсутствие связи с банком.
stanislavvv: (Default)
Притащили мне токен:

и говорят человеческим голосом:
- Хотим мы получать данные из сбербанка автомагически и загружать в свою систему! А то сейчас оно через ж только руками через копипасту!

Пришлось делать.
Сделалось следующее:
1) десктоп на lxde на базе Debian/Jessie
2) поставлена неофициальная бета-версия софтины с официального форума разработчика. Поставлена неофициальным путём - после пересборки пакета.
3) поставлен сервер x2go, дабы не ходить ногами или через яву в iLO до десктопа ради единственного клика в меню.
4) сей "десктоп" об одном юните был поставлен в датацентр на белом ip.

В датацентре выяснилось, что сия софтина полностью блокирует весь обмен вне своего впн для белого ип. От слова "совсем".
Из извращений прижилось поднятие алиаса с серым ип на "десктопе" и добавление той же подсетки на целевых серверах.

Теперь данный сервер запускается так:
1) после загрузки заходим через x2goclient и вводим пин в предлагаемую форму
2) отваливаемся по таймауту, так как несмотря на галочки, софтина таки отрубает соединения
3) снова заходим через x2goclient и убеждаемся, что сбербанковский фтп доступен.

Всё. Остальным занимается крон, скрипты и sshd.
stanislavvv: (Default)
Угораздило меня поработать в банках...
Теперь любой токен несут ко мне...
stanislavvv: (Default)
Написал на работе микросервис для данных о бекапах. Рад, щаслив, горд (С)

Посмотрел, что ещё даже непонятно, куда и как их деплоить.
Уже не щаслив.

Посмотрел, сколько мест, где потребуется переписывать только с моей стороны (собственно, скрипты бекапов/восстановления как на серверах, так и на хранилищах).
Уже не рад.

Спросил у программистов, когда, они смогут заняться - аж весной. Уже не горд.
stanislavvv: (Default)
Риак - странная штука. Вот например, как он планирует распределить место в кластере после добавления ещё одного узла:

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

При этом процент распределения соответствует и тому, какая доля места в кластере занята на диске именно этого сервера.
По-моему, они что-то не доработали...
stanislavvv: (Default)
Расставил по ранжиру в разных категориях.

Urls:
ceph - http://ceph.com
sx/libres3 - http://www.skylable.com/
riak/riak-cs - http://basho.com/ (они переименовали riak в riak kv, а riak-cs в riak s2, но софт от этого не поменялся), доки - http://docs.basho.com/

Сложность архитектуры (для случая использования протокола S3):

I. ceph - три вида узлов (или четыре, если выделить админский узел в отдельный) - хранилище, монитор, шлюз, общение между собой по ключам
II-III. riak/riak-cs и sx - по два вида узлов - бекенд (riak - БД, sx - файлохранилище) и фронтенд (riak-cs - умный фронтенд, который и реализует хранение файлов, libres3 - более-менее тупой конвертер протокола s3 в протокол хранилища)

Сложность установки:

I. ceph - связано со сложностью архитектуры и некоторой запутанностью документации, которая не столько документация, сколько справочник. Плюс не всегда очевидные расчёты параметров.
II. riak/riak-cs - можно всё сделать по документации, но без расчёта некоторых параметров можно получить либо кластер, который либо не сможет полностью использовать текущее железо, либо будет расчитан на бОльшее количество узлов и будет жрать память больше, чем требуется.
III. sx - тупо apt-get install и немного ответов на вопросы в sxsetup

Возможность донастройки:

I. ceph - практически всё, что может понадобиться настроить - можно настроить.
II. riak/riak-cs - часть настроек неочевидна, часть недокументирована, мне для некоторых приходилось лазить по спискам рассылки и по эрланговским исходникам. Часть настроек, которые вообще говоря, предназначены для riak, пишутся в настройки riak-cs.
III. sx - тупо нечего настраивать в конфиге. От слова вообще. Можно перераспределить место в кластере или ещё что-нибудь такое. Но сказать "дай открыть больше соединений, будет афигительная нагрузка" - нельзя.

Требования к железу (на тестовом кластере с репликацией 2x):

I. sx - пойдёт практически на чём угодно
II. ceph - в узлах osd хочет 1Гб памяти на каждый терабайт места, остальным - просто по гигабайту достаточно (вероятно, radosgw под нагрузкой захочет большего, но не факт)
III. riak/riak-cs - жрёт память. Процессора хочет немного - не больше пары-тройки ядер на узел даже в продакшне.

Достоинства:
sx/libres3 - простота установки и конфигурации
riak/riak-cs - работает практически сразу после установки, если нет особых требований - довольно удобен.
ceph - можно настроить всё, обладает довольно-таки приличным быстродействием

Недостатки:
sx/libres3 - практически не тюнится, имеет базы sqlite в качестве бекенда, виснет на несколько минут при срабатывании gc на любом из узлов.
riak/riak-cs - жрёт память на фронтенде непонятно куда, жрёт память на бекенде, жрёт место на диске в процессе нормальной работы (потом отдаёт обратно, но если места не хватило - падает), не может посчитать статистику объёма бакета, если в бакете несколько сот тысяч файлов (у меня для рабочего кластера проблемы начинались где-то на 600-800 тысячах файлов в зависимости от нагрузки), иногда riak-cs ни с того ни с сего говорит "all workers busy" и это до его рестарта.
ceph - хранит каждый чанк/объект в отдельном файле, что на рекомендуемом ими xfs чревато проблемами, и если там всё можно настроить, то вы таки будете всё настраивать.
stanislavvv: (Default)
Поскольку Sx проиграл (во время срабатывания gc ВЕСЬ кластер стоит колом) - решили присмотреться к ceph.
Ставится оно при помощи ключей и какой-то матери, если не пользоваться ceph-deploy (делал по http://docs.ceph.com/docs/master/install/manual-deployment/#long-form - поставилось). Если пользоваться ceph-deploy - не всегда можно получить то, что хочется, судя по содержимому этого самого ceph-deploy.

Кратенько о том, на чём тестил: кластер в составе mon (монитор кластера, которых в продакшне должно быть не менее трёх), 2*osd (хранилища), radosgw (интерфейс s3/swift/etc, сделал для его объектов двукратную репликацию в хранилище, как и в риаке).
Тестил - так же, как и sx, путём копирования каталога, содержащего тыщу файлов в тыщу подкаталогов + относительно большой файл и всё это в бакет по имени s3://test

Результаты тестов:

s3cmd ls s3://test - 20 секунд (против 7 минут riak)
s3cmd du s3://test - 8 минут (riak я тут не дождался)
Запись большого файла - порядка 7Мб/сек, чтение - упёрлось в 100Мбит виртуалки radosgw.

При этом riak-cs/riak содержал три узла под riak.

После добавления третьего osd и начала перебалансировки кластера s3cmd ls s3://test стал работать 1:15-1:20, что является вполне подходящим результатом для сильно нагруженного кластера даже по сравнению с ненагруженым риак.
Скорость чтения больших файлов не изменилась (от слова вообще). Менялась скорость перебалансировки и всё.

Пожалуй, ceph как хранилище с s3 мне нравится больше, чем riak, у которого есть NN граблей, которые нельзя обойти настройками.
stanislavvv: (Default)
На работе в качестве хранилища поставлен кластер из RiakCS + Riak.
В целом работает, но кой-чего там не устраивает (в частности, скорость работы при большом количестве файлов в бакетах).
Решили протестировать связку Sx+LibreS3. Поставили два идентичных по железу кластера + по одному фронтенду и потестили.
Итоги:
1) тест с миллионом файлов в бакете.
Riak - шустренько залил миллион, но зато чтение корня бакета заняло почти 7 минут и потребовало увеличения таймаута в конфиге s3cmd
Sx - за выходные так и не залил миллион, но чтение корня бакета при 700 тысячах - порядка 30 секунд.

В процессе залития у Sx наблюдаются глобальные тормоза на несколько минут при запуске gc на одном из узлов бекенда.

2) тест с крупным файлом
Сохранение:
Riak - тихо и мирно залил на скорости 3Мбайт/сек (у виртуалок ограничение по сети - 100Мбит, так что в сеть не упиралось)
Sx - начал заливать на скорости 10Мбайт/сек, но после залития последнего чанка затупил так, что время на операцию оказалось больше, чем в случае riak.

Скачивание:
Riak - отдал на скорости 6Мбайт/сек
Sx - отдал на сокрости 10Мбайт/сек

3) поддержка ACL и политик
Riak ACL поддерживает, политики - аналогично.
Sx не поддерживает ACL вообще, но поддерживает некоторые политики. И, похоже, отсутствие поддержки ACL таки даёт бОльший результат, чем результаты тестов производительности в смысле принятия решения.

Посмотревши на документацию ceph - там с ACL аналогично, так что, скорее всего, тоже отпадёт.
stanislavvv: (Default)
Пришло время расширять кластер S3. То есть, добавить ещё 4 виртуалки к 8-и имеющимся.
Начали настраивать хост. Сделали 4 бриджа, как на остальных хостах. Однако, через N секунд перестали работать бриджи везде.
Прибили бриджи - всё восстановилось. "Ага", подумали уральские мужики, "дело в openvswitch".
Переделали на один бридж + бондинг 4-х интерфейсов на каждом из хостов.
Пока работает, трафик вроде распределяется. Ждём синхронизации кластера, ибо пока не пройдёт - будет тормозить жутко.
Но сколько геморроя в процессе...
stanislavvv: (Default)
Дочь хочет быть "либо системным администратором, либо воспитателем, либо психологом".

В кабинет подсадили товарища из техподдержки, который таки потом будет админом.
Слушая его разговор с клиентом, понял, что как минимум первое и третье тут объединяется, так как примерно половина задачи - выслушать клиента так, чтоб он успокоился и понял, что его проблема - не проблема :-)

S3

Oct. 8th, 2014 10:58 am
stanislavvv: (Default)
Добились скорости записи файла в несколько десятков Гб в 49Мбайт/сек.
Если я правильно понимаю, теоретический предел сейчас - 62Мбайт/сек, ибо у узлов кластера всего по одному гигабитному интерфейсу и при записи делается троекратное дублирование.
stanislavvv: (Default)
Запилил конфиг haproxy на предмет того, чтобы статистика снималась с того узла, на котором обсчитывается.
А то в пиках загрузки основные узлы могут и 500-й отбрыкаться, типа "мущина, вы что не видите, я занята!", а узел со статистикой всё равно занимается только ей, да хранением.
Вроде мелочь, а всё равно хорошо :-)
stanislavvv: (Default)
Похоже его настраивал какой-то ненатурал. Пришло дохрена писем от <> с содержимым вида:

The following message to <mailer-daemon-iport@megafon.ru>; was undeliverable.
The reason for the problem:
5.1.1 - Bad destination email address 'reject'

Дохрена - это одно письмо примерно каждые 2-3 секунды. Техподдержке сиё не понравилось, так как завалило весь хелпдеск.
Мы туда точно ничего не посылали. Более того, наш сервер точно не может ничего посылать на адрес reject, который отопнётся еще на этапе приёма письма.
На данный момент решили плюнуть и сделать на письма /^From:.*MAILER-DAEMON-iPort\@megafon\.ru/ DISCARD, ибо хз, когда они там починят, если вообще будут чинить, а работать надо уже сейчас.
stanislavvv: (Default)
Однако, фронтенд (riak-cs) начал жрать память. Нет, даже ЖРАТЬ. До 20Гб дело доходило, причём резидентных.
Дошло до oom, причём прибило не того, кто сожрал, а невинного демона БД (riak), который на это обиделся и после поднятия стал синхронизировать данные по всему кластеру.
Похоже, требуется сии поделия перезапускать при достижении ими этак пары Гб объёма резидентного. Можно по частям (их там по одному на каждый узел, так что рестарт/падение одного не влияет на остальных).
Заодно и производительность повышается, что не может не радовать...
stanislavvv: (Default)
Появился еще один клиент S3, который будет отдавать статику оттудова. Вначале он хотел кластер для ВСЕГО.
Содержимое этого кластера, а именно несколько Гб сайтов + полтора терабайта статики в виде картинок в несколько кб, уже недели полторы копируется со старого сервера на новый.
Поскольку кластер он хотел с синхронизацией через rsync (который на таком количестве файлов падает из-за исчерпания памяти), то было предложено а) вынести статику в DRBD, б) синхронизировать её с S3, дабы слегка разгрузить сервера. Ну а динамику - оставить по-прежнему.
Посмотрим, что выйдет... Судя по имеющейся статистике, нагрузка на сервер даже сейчас могла бы упасть процентов на 70.

А еще со следующей недели таки в отпуске. Дочь утверждает, что 13-го её надо отвезти в деревню. Посмотрим, как приберётся у себя...
Еще хотят в цирк 12-го, но тут всё зависит от того, получится ли купить билеты.
А вот на продолжение ремонта деньги ёк. Там тыщ 50 надо минимум, так что ремонт будет сильно ползучим.
stanislavvv: (Default)
Появился клиент, который переплюнул прежнего. Правда, он туда делает бекапы, а не отдаёт статику.
Итого - 3.5Тб в S3.
stanislavvv: (Default)
Соорудили возможность делать сайты прям в S3.
То есть, заливаешь контент (конечно, только статический), даешь права на него public и тыкаешь кнопку в панели управления.
Таки работает.

А еще к S3 прикручен ftp-сервер. То есть можно класть файлО по ftp, если приспичит.
К сожалению, из-за особенностей бекенда невозможно переименовывать. Только залить под новым именем и удалить старое.
Если паранойя не даёт вписывать ключи в ftp-клиента - можно сделать юзеров с ограничением на вход.
Короче, тоже работает, если надо. Лучше, конечно, родным S3-клиентом пользоваться, но если приспичит - ftp есть.
stanislavvv: (Default)
На работе недели полторы назад открыли S3-хранилище, дабы клиенты могли туда читать-писать.

За полторы недели в хранилище понапихали 1.4Тб, из них 800Гб - один клиент.
Данный клиент использует хранилище как сервер, отдающий картинки.
Не возражаем, те 10-15 запросов в секунду сильно не грузят, ибо кластер.

Остаётся вопрос: до скольки вырастет объём у данного клиента, скажем, осенью? И будет ли он больше половины от общего объёма?
stanislavvv: (Default)
В процессе обсуждения биллинга для местного стораджа родилась новая единица измерения - терабайт*час (по аналогии с квт*ч).
stanislavvv: (Default)
Решили, что нефиг юзерам мочь писать куда попало и обрезали права.
Теперь:
а) для них / - смонтирован в ro через unshare, за исключением спула постфикса (туда через /usr/sbin/sendmail письма как файлО кладутся), для рута - таки в rw.
б) на /home права 751, так как поленились извращаться с mount --bind для каждого юзера, чтоб в /home было видно только свои файлы. На /home/$USER - права обычные, иначе вебсервер не поймёт-с.
в) смонтировали /proc с опцией hidepid=2, теперь юзеры не могут видеть чужие процессы (начиная с 3.3, в дебиане - с 3.2)

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

Profile

stanislavvv: (Default)
stanislavvv

July 2017

S M T W T F S
      1
2345678
910 1112131415
1617 1819202122
23242526272829
3031     

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 21st, 2017 10:28 am
Powered by Dreamwidth Studios