Странности с IPMI

Понедельник, 13 марта, 10:19
У нас тут странное случилось, переустанавливали ось на одном сервере по IPMI, там сначала мышка отвалилась, а потом вообще весь IPMI целиком. В смысле не просто iKVM, а вообще всё. Дальше много пытались ковырять, ipmi было мертво целиком даже после ребутов кнопкой.

Суппорт в ДЦ предложил (спасибо им) полностью выдернуть питание из сервера — после этого не только ipmi заработал, но еще и сервер стал работать в два раза быстрее. Включая, кстати, сеть — вдс-ки теперь мигрируются между серверами на 700+ мегабитах, а то я перед переустановкой оси как раз мигрировал их оттуда и с некоторым удивлением смотрел на миграцию на скоростях в 200-400 мегабит вместо привычных.

Нерешенной загадкой осталось почему сервер хронически отказывался грузиться в SATA DOM, но это я узнаю видимо уже не раньше следующих запланированных тех.работ.

Датацентры

Пятница, 10 марта, 14:53
А вот скажите, если я пишу в требованиях "порт — 1 гигабит и нормальные цены", и "стоимость сервера до 7 т.р.", а мне потом разные продажники разных датацентров пишут и предлагают поставить сервера на коло за 4500 на 100 мегабит, и еще 30 т.р. за гигабит, а во втором случае предлагают взять сервер за 14 т.р. — это вообще что?

В обоих случаях ведь прочитали требования. В обоих случаях все не с улицы, а с хостобзорной тусовки. Ну какого?

Повторяется с разными компаниями с интервалом в три месяца, и так по кругу уже несколько лет.

Ребрендинг конкурента

Вторник, 7 марта, 20:53
Был у селектела такой милый ламповый проект с дешевыми дедиками — tehnodom.com. И сайт у него был чудесный.

А тут вдруг раз и они сделали ребрендинг. Новый сайт — chipcore.com . Осторожно, глаза вытекают, не ходите туда, я предупреждал.

"Зачем они это сделали — лично я не понял." — наверное, лучший комментарий по этому поводу.

Borg — неудобности

Понедельник, 6 марта, 6:9
Минусов у Borg-а, конечно, есть. В основном всё написано в faq-е, и чувствуется, что вопросы популярные и у всех одинаковые — у меня возникли эти же вопросы примерно в этом же порядке. Это всё явно недостаток дизайна, конечно.

1) бекап нескольких серверов в один репозиторий. Мне бы его очень хотелось, потому что сотни битриксов хорошо задедуплицируются. Однако: каждый раз перебилд кеша + репозиторий лочится при записи — писать можно только в один поток. В оригинале:

"it will be most efficient if a single repository is only modified from one place. Also keep in mind that Borg will keep an exclusive lock on the repository while creating or deleting archives, which may make simultaneous backups fail."

2) взять сколько-то снапшотов из одного репозитория и закинуть в другой — штатных способов нет. Можно рсинком продублировать, замаунтить первый и добавить во второй, но только так. Учитывая пункт 1 (а именно из-за него вообще возникает сделать split репозиториев, или группу по префиксу выкинуть куда-то еще) — фича получается и ненужной.

По совокупности обоих пунктов, и учитывая, что юзеры могут переезжать между серверами — придется каждого юзера бекапить в отдельный репозиторий. Это плохо для дедупликации, конечно.

Менее очевидное:

Переменная BORG_FILES_CACHE_TTL по умолчанию = 20. Если какого-то файла нет в наборе более 20 раз — инфа о нем удаляется из кеша и при появлении файл будет залит заново в новый чанк. Так же — файлы привязаны к путям, датам и т.д. и, похоже, к инодам. Изменение пути файла приведет к его повторной загрузке. Это серьезный минус для дедупликации, но, вероятно, иначе нельзя сделать без потребления большого количества памяти как в ZFS.

Есть плохо понятный лимит количества метадаты, в который раньше все хорошо упирались, но сейчас вроде лимиты подняли так, что в реальной жизни проблемы возникать не должно.

В сравнении с альтернативами:

в bup сходу не завелись нужные фичи (поставил по доке, bup-index нету, exclude не сделать, про fuse в интернетах странное пишут и т.д.),

в zbackup странные авторы (fuse нет, авторы лучше меня знают какое мне надо сжатие, поэтому только самое медленное LZMA, нет возможность менять размер блоков/чанков, чтобы достать один файл надо распаковать всё — в моем случае, видимо, все 200 гигабайт и 15 миллионов файлов, есть больше памяти — в идеале от 512М против 64М у Borg и 10M у tar/pigz).

attic фактически умер два года назад и переродился в borg.

rsnapshot 99% времени (на миллионах файлов) создает симлинки — это всё.

duplicity сначала пишет много в /tmp и по факту я от него вообще ни разу ничего не дождался на моих объемах.

rdiff-backup — пробовали, всё было плохо, примерно как и с duplicity, очень плохо с большим количеством мелких файлов.

tartarus и backup2l, которы упоминаются в мануала хетзнера — совсем неинтересны в сравнении с Borg.

Borg backup

Понедельник, 6 марта, 2:44
Ищем альтернативу бекапам на основе tar + pigz и вот сейчас тестируем borg. У него отличная документация (хотя пока осталась пара вопросов), вот тестовый аккаунт клиента на 50 гигабайт — делаем бекап, в exclude — всевозможные кеши битрикса и подобный ненужный треш.

time borg create --compression lz4 -v --stats \
        --exclude-from=exclude.cache \
        /test.ssd/borg-test::b01 \
        /vz5/private/$ve/home/$test_user/

------------------------------------------------------------------------------
Archive name: b01
Archive fingerprint: 054749329aa1393c4fdb9248c32e42d56b866fcc9b6c16c60433232445cecaaa
Time (start): Mon, 2017-03-06 01:50:16
Time (end):   Mon, 2017-03-06 02:10:41
Duration: 20 minutes 25.22 seconds
Number of files: 437908
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:               21.13 GB             18.73 GB             14.49 GB
All archives:               21.13 GB             18.73 GB             14.49 GB

                       Unique chunks         Total chunks
Chunk index:                  273104               432909
------------------------------------------------------------------------------

real	20m28.493s
user	8m15.197s
sys	1m21.897s


Выглядит как бы и неплохо, но — тут бекап делается на локальный ссд, в продакшене у нас делается tar + pigz на sshfs в другом датацентре в другой стране через гигабит и там архив занимает 17.3 гигабайта, причем последний раз он сделался за 10 минут. Пока подозреваю, что дело в том, что у pigz 12 потоков (в сервере 48 ядер).

Далее прекрасное — ждем час и делаем еще один бекап.

Duration: 2 minutes 17.95 seconds
Number of files: 437909
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:               21.13 GB             18.73 GB             36.52 MB
All archives:               42.25 GB             37.47 GB             14.52 GB

                       Unique chunks         Total chunks
Chunk index:                  273934               865774
------------------------------------------------------------------------------

real	2m21.642s
user	1m39.310s
sys	0m17.626s



UPD: Многократные тесты в продакшене подтвердили — при копировании на удалённый сервер первый снапшот боргом происходит вдвое медленнее (20 минут borg с remote borg serve против 10 минут у tar+pigz в 12 потоков и sshfs), зато любой следующий снапшот занимает в пределах двух минут и пары мегабайт диска. Это фантастически хорошо по возможностям, которые оно даст и по количеству денег, которым нам сэкономит.