Рубрика «Блог компании Webzilla»

в 8:22, , рубрики: GRE, mtu, Neutron, openstack, tcpdump, Блог компании Webzilla, Облачные вычисления, Сетевые технологии, системное администрирование, спасибо за чтение

Лирическое вступление

Когда администраторы сталкиваются с неожиданной проблемой (раньше работало, и, вдруг, после обновления, перестало), у них существует два возможных алгоритма поведения: fight or flight. То есть либо разбиратся в проблеме до победного конца, либо убежать от проблемы не вникая в её суть. В контексте обновления ПО — откатиться назад.

Откатиться после неудачного апгрейда — это, можно сказать, печальная best practice. Существуют целые руководства как готовиться к откату, как их проводить, и что делать, если откатиться не удалось. Целая индустрия трусливого поведения.

Альтернативный путь — разбираться до последнего. Это очень тяжёлый путь, в котором никто не обещает успеха, объём затраченных усилий будет несравним с результатом, а на выходе будет лишь чуть большее понимание произошедшего.

Завязка драмы

Облако «Instant Servers» Webzillа. Рутинное обновление хоста nova-compute. Новый live image (у нас используется PXE-загрузка), отработавший шеф. Всё хорошо. Внезапно, жалоба от клиента: «одна из виртуалок странно работает, вроде работает, но как начинается реальная нагрузка, так всё замирает». Инстансы клиента переносим на другую ноду, проблема клиента решена. Начинается наша проблема. Запускаем инстанс на этой ноде. Картинка: логин по ssh на Cirros успешен, на Ubuntu — зависает. ssh -v показывает, что всё останавливается на этапе «debug1: SSH2_MSG_KEXINIT sent».

Все возможные внешние методы отладки работают — метаданные получаются, DHCP-аренда инстансом обновляется. Возникает подозрение, что инстанс не получает опцию DHCP с MTU. Tcpdump показывает, что опция отправляется, но не известно, принимает ли её инстанс.

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

Если это проблема с MTU, то у нас есть внезапный помощник. Это IPv6. При том, что «белые» IPv6 мы не выделяем (извините, оно пока что не production-ready в openstack), link-local IPv6 работают.
Читать полностью »

в 10:24, , рубрики: elasticsearch, linux kernel, logstash, lucene, Блог компании Webzilla, ит-инфраструктура, Серверное администрирование, системное администрирование

Про отлов ядерных MCE (machine check error) и прочей гадости с помощью netconsole я писал недавно. Крайне полезная вещь. Одна проблема: throttling на CPU из-за локального перегрева (длительной нагрузки) фиксируется как MCE. Случается бэкап — и админам приходит страшное сообщение об MCE, которое на практике означает «чуть-чуть перегрелось» и точно не требует внимания к себе в 3 часа ночи.

Смехотворность проблемы ещё тем, что Linux фиксирует MCE после того, как throttling закончился. То есть режим 'normal', но вместо этого оно превращается MCE. Выглядит это так:

CPU0: Core temperature above threshold, cpu clock throttled (total events = 40997)
CPU4: Core temperature above threshold, cpu clock throttled (total events = 40997)
CPU4: Core temperature/speed normal
CPU0: Core temperature/speed normal
mce: [Hardware Error]: Machine check events logged

При этом мы точно хотим реагировать на нормальные MCE. Что делать?

В рамках logstash обработка сообщений предполагается stateless. Видишь сообщение — реагируешь. Внедрять же ради одного типа сообщений более сложную систему — оверкилл.

Казалось бы, есть фильтр (не путать с output) elasticsearch, который позволяет делать запросы. К сожалению, он не умеет делать 'if'ы, то есть remove_tag и add_tag будут отрабатывать вне зависимости от того, удался поиск или нет.

Грустно.
Читать полностью »

в 10:48, , рубрики: linux kernel, logstash, monitoring, nagios, shinken, Блог компании Webzilla, Настройка Linux, Серверное администрирование, системное администрирование

Предисловие

Страшная сказочка:

EDAC MC0: 1 CE read ECC error on CPU#0Channel#1_DIMM#0 (channel:1 slot:0)
EXT4-fs error: ext4_wait_block_bitmap:445: Cannot read block bitmap
Out of memory: Kill process 95 (sshd) score 31 or sacrifice child
CMCI storm detected: switching to poll mode
page allocation failure: order:1, mode:0x4020
invalid opcode: 0000 [#1] SMP

Неприятно выглядит, правда? Список может быть очень длинным очень длинный. В этой статье я расскажу как с этим жить и что мы с ним сделали.

Часть из этих сообщений в приерах выше заставит вас погрузиться в бездны современной архитектуры процессоров («CMCI storm», удачи в поиске дороги назад, из дебрей интернетов)… Cтранные вещи в ядре могут нарушать ожидания о том, как работают компьютеры, делая последующую отладку очень затруднённой. Отсутствие знания о том, что случилось может даже оставить с грустным ответом «какая-то неведомая фигня, ребутнули, вроде, прошло».Читать полностью »

в 11:48, , рубрики: CDN, LSI, raid, raid0, ssd, ucdn, webzilla, Блог компании Webzilla, Железо, системное администрирование, спасибо за чтение, СХД

Вступление

Коллеги с соседнего отдела (UCDN) обратились с довольно интересной и неожиданной проблемой: при тестировании raid0 на большом числе SSD, производительность менялась вот таким вот печальным образом:
SSD + raid0 — не всё так просто
По оси X — число дисков в массиве, по оси Y — мегабайтов в секунду.

Я начал изучать проблему. Первичный диагноз был простой — аппаратный рейд не справился с большим числом SSD и упёрся в свой собственный потолок по производительности.

После того, как аппаратный рейд выкинули и на его место поставили HBA, а диски собрали в raid0 с помощью linux-raid (его часто называют 'mdadm' по названию утилиты командной строки), ситуация улучшилась. Но не прошла полностью -цифры возросли, но всё ещё были ниже рассчётных. При этом ключевым параметром были не IOPS'ы, а многопоточная линейная запись (то есть большие куски данных, записываемых в случайные места).

Ситуация для меня была необычной — я никогда не гонялся за чистым bandwidth рейдов. IOPS'ы — наше всё. А тут — надо многомногомного в секунду и побольше.

Адские графики

Я начал с определения baseline, то есть производительности единичного диска. Делал я это, скорее, для очистки совести.

Вот график линейного чтения с одной SSD.

SSD + raid0 — не всё так просто

Увидев результат я реально взвился. Потому что это очень сильно напоминало ухищрения, на которые идут производители дешёвых USB-флешек. Они помещают быструю память в районы размещения FAT (таблицы) в FAT32 (файловой системе) и более медленную — в район хранения данных. Это позволяет чуть-чуть выиграть по производительности при работе с мелкими операциями с метаданными, при этом предполагая, что пользователи, копирующие большие файлы во-первых готовы подождать, а во вторых сами операции будут происходить крупными блоками. Подробнее про это душераздирающее явление: lwn.net/Articles/428584/
Читать полностью »

в 13:00, , рубрики: CDN, Блог компании Webzilla, Веб-разработка, динамика, спасибо за чтение, статика, хостинг

Содержимое: что такое CDN? История возникновения. Зачем она нужна? Кому она нужна, а кому нет? Порог вхождения, стоимость, издержки. Основные технологии.

CDN — сокращение от content delivery network, то есть “сеть доставки контента”. Чаще всего это множество серверов с специализированным ПО, которые ускоряют доставку (“отдачу”) контента конечному пользователю. Сервера расположены по всему миру таким образом, чтобы время ответа посетителям сайта было минимальным. Под “контентом” чаще всего подразумевают видео и статические элементы веб-сайтов (не требующие выполнения кода на сервере или запросов в базу данных, такие как css/js), но к “контенту” относятся и совсем неожиданные вещи — например, игры в Стиме (использует CDN для отдачи игр), обновления для операционных систем и т.д.

Знакомство с Content Delivery Network

Немного истории

Резкий рост Интернета в середине 90-х привёл к ситуации, что сервера тех лет не могли в одиночку выдержать нагрузку (много ли может отдать могучий двухпроцессорный сервер на базе Pentium Pro на частоте в 266 МГц с 128 мегабайтами памяти?). Лимит производительности серверов и потребность во всё большей и большей производительности породила ныне забытые слова: “ферма серверов”, “иерархическое кеширование”… Айтишный новояз удивительно чувствителен к возрасту — и слова вроде “servers farm” или “information superhighway” сейчас ассоциируются с тёплыми ламповыми CRT-мониторами, а не с прогрессом. В ходе разработки и внедрения разных решений была замечена одна важная особенность: есть два типа контента — статический и динамический.
Читать полностью »

в 11:47, , рубрики: logstash, syslog, udp, webzilla, Блог компании Webzilla, Серверное администрирование, системное администрирование, спасибо за чтение

Админская загадка: На сервере произошло три oom kill'а, а мониторинг сказал только про два. Почему?

Конфигурация

Для мониторинга всего у нас настроена связка ganglia-shinken-logstash-elasticsearch-kibana. Полное описание довольно обширно, так что ограничусь только частью, имеющей отношение к проблеме.

В logstash присылаются логи со всех серверов. Он их складывает в elasticsearch. В конфиге logstash'а настроена реакция на всякие странные сообщения, которые свидетельствуют о проблемах. Если сообщение появляется, присылается event мониторингу (shinken), который разными методами начинает беспокоить админов.

Помимо syslog'ов, которые шлют сообщения от большинства приложений, у нас настроена ещё и отправка netconsole от всех ядер. Сама технология проста до невозможности — ядро помимо dmesg'а посылает сообщения в виде UDP-датаграмм на указанный IP и mac-адрес. MAC-адрес нужен потому, что netconsole очень низкоуровневая и заниматься разгадыванием «как из IP сделать MAC» (то есть ARP) не собирается. Благодаря низкоуровневости сообщения проходят даже в ситуациях полного катаклизма. Например, если программный коммутатор перестал работать (и сеть недоступна), сообщения всё равно будут посылаться. Более того, они будут посылаться, даже если в iptables сказано -j drop_vsyo_nafig. И, самое главное и ценное, эти сообщения успешно будут отправлены, если дисковая подсистема полностью не работает. То есть для post-mortem исследований «что именно случилось с зависшим сервером» — самое оно.

Очевидным кандидатом в «плохие» сообщения является сообщение от oom-killer'а. 

[517935.914380] ntpd invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[517935.914730] Call Trace:
[517935.914807]  [<ffffffff816e14ce>] dump_header+0x83/0xbb
[517935.914877]  [<ffffffff816e155b>] oom_kill_process.part.6+0x55/0x2cf
...
с финальным торжествующим: 
[517935.951044] Out of memory: Kill process 4550 (apache2) score 247 or sacrifice child
[517935.951203] Killed process 4550 (apache2) total-vm:2610268kB, anon-rss:2012696kB, file-rss:3928kB

Итак, возвращаемся к загадке. Идёт пусконаладка, предпродакшен, как, вдруг, апач (точнее, wsgi-приложение) насасывается данных до неприличия, и его прибивают со словами «go be fat somewhere else». Админам приходит сообщение. Казалось бы всё хорошо (ну, в админском смысле «хорошо»). Но…

Случилось три oom'а, сообщения пришли о двух. Мониторинг в порядке, netconsole в порядке. Загадка? Проблемы? Симптомы таинственной неведомой фигни? Звать придворного шамана с бубном?
Читать полностью »

Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js