?

Log in

No account? Create an account
Cat-light

klink0v


Блохи в свитере деда Сергеича


Entries by category: работа

[sticky post]О блоге (самый верхний псто)
Cat-light
klink0v

Hello, alone wonderer!


Жила-была InnoDB
Wolfy
klink0v

Жила-была InnoDB. Её никто не трогал. Пока в один злосчастный момент в серверной не потух внезапно свет. А UPSа не отработала.

После включения выяснилось, что база "побилась". А бэкапа, как водится, нет. При попытке сделать принудительный replay transaction log-ов она вываливается с ошибкой 11 где-то на первых 13-ти процентах процесса. Если поиграться с величинами буферов-пулов, то вываливается где-то на 75%. Если сказать innodb_force_recovery=6 (SRV_FORCE_NO_LOG_REDO), то обламывается с ошибкой 6 (assertion failure in thread).

Странно, что idb-файлы вроде как консистентные. Утилита innochecksum по всем проходит и никаких ошибок не кажет. Попробовал вытащить хоть какие-то данные напрямую из них, только вот беда: при развертывании сервера параметра "innodb_file_per_table=1" в конфиге никто не прописал. А без него структуру из FRM-файлов не вытащить. При том, что "ibdata1" явно покоцаный.

Оставим морально-этический аспект в стороне. Также не будет задаваться вопросом кто, как и почему всё это настраивал. Скажу сразу: не я.

Есть тут знатоки InnoDB? Можно ли ещё предпринять хоть что-нибудь в данной ситуации? Вытянуть хоть какие крохи, плевать с какими потерями, пофигу на консистентность, хоть из каких-нибудь таблиц?

P.S. База весит 500 гигабайт...


Разведка рынка труда
Lynx
klink0v

Чё-то я решил посмотреть какие в принципе есть сейчас вакансии на рынке труда в IT. Залез на HH, да чё-то и залип там неожиданно часа на три. С большой грустью для себя обнаружил, что безнадёжно отстал от прогресса. Сейчас все повально требуют опыт работы с Docker / Kubernetes / Ansible / Ceph, в довесок ElasticSearch, Apache Tomcat и PostgreSQL. Я же с этим не сталкивался, ибо десять лет назад этого всего просто не существовало (за исключением Tomcat и Postgres разве что), а в моей мелкой конторке в подобных инструментах не было ну никакой необходимости. Дальше на сцену выходит стандартная проблема всех сисадминов: "Научитесь плавать — нальём воду". Чтобы разобраться с модными технологиями, нужны реальные задачи. Чтобы были реальные задачи, нужно куда-то трудоустроиться. Чтобы трудоустроиться, нужен опыт работы с модными технологиями. Упс!

Зато по ходу пьесы отметил для себя энное количество перлов и жира, которыми хочу поделиться. Не факт, что все эти ссылки будут работать на момент прочтения вами этого поста. Тут уж не обессудьте. Сперва ссылка на вакансию, после неё мой комментарий.  Поехали.

Смотреть / читатьCollapse )

Про OpenVPN, мультикаст и странных ISPов
Cat-dark
klink0v

Стало мне тут зело интересно, пропускает ли OpenVPN исходящие мультикасты в конфигурации "dev tun" + "server" + "topology subnet". Как выяснилось — да, пропускает. Сгенерировал эталонный multicast-поток в вакууме при помощи утилиты iperf ("iperf -c 224.1.1.1 -u -T 32 -t 3 -i 1"), натравил соответствующий статический маршрут на "dev tun0" и послушал сниффером что происходит на подключенных к серверу OpenVPN-клиентах. Таки да, трафик доходит. И замечательно доходит. Всем. Почти.

Примерно два из девяти устройств таки не получили свою порцию multicast-ов. Стал разбираться. Железо одинаковое, конфиги одинаковые, версии софта одинаковые. Что же может быть не так? Ага, двух бедолаг объединяет один провайдер. Полез глубже в отладку. Опытным путём выяснил, что проблемные клиенты не получают UDPv4-пакетов жирнее, чем 1489 байт. То есть где-то по дороге они просто молча выпиливаются. Ни ICMP там в ответ никакой не приходит, ничего. Протестировал из разных точек. Результат тот же. Устройства, подключенные к другим провайдерам, подобных симптомов не испытывают.

Вот теперь думаю, является ли непрохождение UDP-пакетов длиннее 1489 байт достаточным основанием для бодания с ISPом. Если хотите знать героя в лицо — это НьюКомПорт. Провайдер — говно, я раньше уже его обкакивал, с тех пор ничего не изменилось. Просто в том здании, где сидят наши контрагенты, никого другого нет.


HP, мать его, Enterprise
cat-updown
klink0v

Тут коллега по цеху пытается переписываться с российским подразделением HP Enterprise. У них электронные адреса выглядят как "VasyaPupkin@hpe.com".

Пришло уведомление от какой-то их автоматизированной системы обработки заявок. В тексте написано что-то вроде "Помогите нам стать лучше, отправьте ответ... бла-бла-бла". Коллега нажимает кнопку "Ответить", пишет ответ, письмо не уходит. Привлекает к вопросу меня. Я смотрю.

Оказывается, в качестве обратного адреса у них везде, и в заголовках письма, и в подписи в тексте письма, указан адрес типа "csr.russia@hpe.com", при этом буква "e" в имени хоста — кириллическая.

У меня только один вопрос. Это в HP работают такие феерические долбо**ы, или они это сделали специально, чтоб им поменьше писали?

Впрочем, в любом случае, в моих глазах HP и раньше-то был днищем. Ан-нет, сейчас вот снова снизу постучали.


Шоу
Lynx
klink0v

Жила-была одна фирмочка, которая покупала у нас услуги по IT-сопровождению. В какой-то момент их руководство решило, что наши услуги обходятся им чересчур дорого. Было принято волевое политическое решение сменить подрядчика.

Что тут поделать? Хозяин - барин. Они нашли какую-то другую типа конторку, был разработан и согласован план приёма-передачи IT-инфраструктуры, первым шагом которого значился пункт "забрать у нас один из серверов и поместить в стойку Selectel-овского датацентра".

Я уж промолчу, что все эти намерения были оформлены четыре (!) месяца тому назад, а за сервером к нам приехали только вчера. Забрали его в 19 часов вечера, а запустили на новом месте только в 0:30 следующих суток. И это при всём при том, что требуемые IP-адреса были назначены заранее; загодя до переезда сервера все службы на нём были предварительно перенастроены под нового провайдера и оттестированы. Оставалось только запихнуть сервер в стойку и воткнуть в него пять патч-кордов: три Ethernet и два силовых. Разумеется, мы предоставили наглядную бумажную схему "что куда включать" ажно с фотографиями "задницы" серванта, а также предупредили заранее о возможных сложностях и специфике подключения.

Даже если предположить, что они ехали в соседний административный округ по московским пробкам два часа (что само по себе нонсенс), то получается, что на запуск сервера им понадобилось три с половиной (!) часа. И в итоге его iLO так и не начало откликаться. Прям интересно, чем они могли так долго в датацентре заниматься?

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


Почему я не люблю HP
Lozhkin
klink0v

... и люблю собирать серваки своими руками.

Наблюдаю сегодня вот такую замечательную картину.

Под катомCollapse )