До чего доводит перевод ИТ-терминов или как три админа две недели охотились за привидениями

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

ЗВОНОК

В 3.30 ночи зазвонил мобильник. Не знаю, сколько он звонил, но похоже гудке на пятом я перестал храпеть и потянулся за телефоном, морально настроившись нецензурно озвучить основную мысль — «Прошу не беспокоить, я сплю!», но на телефоне определился номер начальника ИТ-департамента, и свою речь пришлось приберечь до следующего звонка.
— Не спится?
— Доброй ночи, Игорь Степанович. Вообще-то спится и очень даже хорошо.
— А зря, ты же админ, значит, как пожарный — всегда на посту! В общем, хватит дрыхнуть, руки в ноги и подключайся к офисной сети. Мне алёрт по SMS от IronPort прилетел, опять затык с CAS-сервером — мыло не проходит. Серёге я уже позвонил.
— Ладно, сейчас только кофе налью. 

«КОТИКИ НЕ ГРУЗЯТСЯ»

Проблемы с электронкой начались 11 дней назад — мы уже собирались с ребятами, админами по VM, в столовую, и вдруг прилетает тикет от пользователя — «У нас перестала работать почта». Потом еще несколько тикетов.

Поскольку их первичная обработка — это моя вотчина, я сказал парням, чтобы они мне зацепили какой-нибудь кусок еды, а я пока начну разбираться, что к чему. Первый десяток тикетов показал, что у кого-то перестала поступать входящая почта, у кого-то минут на 10 пропадал интернет. Юзеры тоже, конечно, не баловали подробностями и писали в тикетах «У меня тут всё тормозит» — приходилось тратить время еще на то, чтобы созваниваться и уточнять детали.
Доходило до маразма — то, что у них тормозила почта, некоторые не замечали, а вот то, что переставал идти фильм или затыкалось радио — они замечали. Чем они на работе занимаются? 🙂

Меня, конечно, не сильно волновали тормоза с фильмом, но прошло уже 20 минут, и в очереди уже томилось около 2000 писем. Ещё чуть-чуть и прилетит Игорь с выпученными глазами, и всем нам даст — в том числе и обедавшим — прикурить. К счастью, через 10 минут проблема пропала также внезапно, и, практически бесследно. Причины мы так и не выяснили — спам-фильтр пуст, пиковых нагрузок на процессоры не прослеживалось (только небольшой всплеск, связанный с фильтрацией накопившихся писем), на первичном CAS-сервере предельно низкий уровень нагрузки. Мне бы уже тогда обратить внимание на этот звоночек, но тут пришла еда, и мне стало не до звоночков — в бэклоге хватало других задач.

И вот, полторы недели спустя — ночной звонок.

НОЧНОЙ ДОЗОР

Когда я вышел в сеть, Серега, почтовый админ, уже был на связи через VPN, скорее всего, по обыкновению цедил кефирчик.
— Здорова, Кирилл. Тебя тоже Игорёк поднял? Бред какой-то, весь кэш на IronPort забит письмами, но связь до CAS-сервера летает.

Мы распределили зоны поиска, минут через 5 оба увидели, что на процессоре подскочила нагрузка до 100%, пошли туда — «Ага, пошла фильтрация почты». Проблема опять начала внезапно рассасываться, и через полчаса процессор «отошел на перекур».

Перед закрытием тикета мы обнаружили, что на первичном CAS-сервере опять подозрительно низкий уровень загрузки, о чем мы не преминули добавить коммент.

Я засобирался обратно в спячку, Серега тоже, но он ещё немного повисел на связи и поделился со мной приколом, который ему прислал через WhatsApp знакомый админ — тот дежурил в ночь, на суппорте.

Мы немного поговорили с Серегой и тем админом, полюбопытствовали, как обстановка на месте и чем тот занят. Тот ответил, что ничем особенным не занят, что он ковыряется с одним хостом ESX из тестовой среды, там надо кое-что апгрейдить и подшаманить, пока ночь и никто не дергает.

«Ага, понятно» — сказали мы и разошлись по своим углам.
Важный ключик к разгадке опять ускользнул от нас.

АРХИТЕКТУРА

Пожалуй, здесь стоит немного остановиться и рассказать про архитектуру нашей богадельни. Итак, в нашей системе есть IronPort, он смотрит наружу, принимает SMTP-трафик, фильтрует оный и распределяет по свободным CAS-серверам. У нас было заведено две дублирующие друг друга машины — они могли выполнять роль сервера и для CAS, и для Hub Transport. IronPort в свою очередь был настроен так, что маршрутизировал весь трафик на первичный сервер, а если тот оказывался недоступен, то на запасной, то бишь — на вторичный. В общем, план как план, ничего особенного, если бы не дюже разные по мощности машины — нынешний первичный CAS-сервер был в 4 раза мощнее прошлого первичного (который после апгрейда и стал вторичным).

ПОЖАР

В общем, выспаться мне не дали — в 9 утра проблема всплыла повторно, и нас всех вызвали в офис. Мы почесывали затылки и пожимали плечами, в глубине души надеясь, что проблема рассосется опять. Но она упрямилась. Ночной админ был в офисе и рассказал нам свою версию развития ночных событий.

После его рассказа админ эл. почты пошёл смотреть службу SMTP — там все работало, как швейцарские часы — почта из Интернета принималась. Затем полез в IronPort, тот пересылал почту, но как-то медленно и печально — накапливалась очередь, скорость обработки была в четверть от обычной. Затем Сергей подключился к первичному CAS-серверу, который в тот момент видимо тихонечко сходил с ума — все нужные CAS-службы на нём почему-то никак работали через IP, зато прекрасно работали через консоль DRAC. Ну-у, как прекрасно — мыло то все равно не приходило. В общем, пока админ почты разбирался с CAS, он вызвонил админа сети — «Приходи, тут похоже по твоей части мистика».

Придя и оценив обстановку, сетевик сказал: «Ребята, по-моему, вы занимаетесь фигней», после чего полез в шлюз сервера CAS. Там он посмотрел логи по IP-адресам и бинго: «Ну, я же говорил — у вас в сети конфликт IP-адресов». Тут как чёрт из табакерки, появился наш админ по веб-приложениям: «О, привет, мужики! Ну, что, как дела? Я, кстати, уже вторую неделю забываю вам сказать — у меня ошибка вылазила пару раз, какой-то конфликт IP-адресов». По нашему многозначительному взгляду он понял, что с уведомлением он тянул зря 🙂 .

В общем, сетевик взял MAC-адрес, посмотрел CAM-таблицы на коммутаторах, вычислил порт конфликтующей машины, сбросил его и очистил ARP-кэш на CAS-сервере — Серёга показал, что все ОК, заработал и CAS-сервер, и IronPort. Ура-ура, пожар потушен.

ОХОТНИКИ ЗА ПРИВИДЕНИЯМИ

Минут через 5 заныл ночной админ: «Я устал, хочу домой, и вообще у моего сервера ESX связь пропала». Пожарная команда переглянулась:
— Ну-ка, ну-ка, с этого места поподробнее, когда говоришь, у тебя связь пропала?
— 5 минут назад.

Нет, не может быть. Таких совпадений не бывает. Начали разбираться и вот тут, наконец-то нашлась истинная причина всех наших бед помноженная на кривую сегментацию сети и неряшливый мониторинг обоих CAS-серверов. Причина называлась — zombie VM, она же виртуальная машина-зомби, она же зомби-ВМ.

Дело в том, что при правильной сегментации сети сеть тестовой среды не должна иметь доступ к сети производственной среды, где находятся CAS-серверы. Она и не имела. Единственная лазейка была — через ACL второй сетевой карты, которая была подключена к виртуальной сети хоста ESX. Эта виртуальная сеть почти не использовалась, разве что только в крайне редких случаях для очень специфичных тестов и только под неусыпным наблюдением администраторов сети. Ночной админ и клялся, и божился, что виртуальная машина, с которой он развлекался ночью, никак не могла подключиться к производственной сети. Тогда админы полезли смотреть vCenter — сервер мониторинга виртуальных машин. Все виртуальные машины чувствовали себя прекрасно, кроме одной — она показывала, что у нее нет доступа к сети.

Раскопки показали, что эта машина была настроена на автозапуск если не при Хрущёве, то уж точно до того, как у нас появился дублирующий CAS-сервер. Её повесили на свободный IP-адрес, потом закрыли и забыли. А 3 недели назад ребята из тестовой среды два раза перезагружали сервер ESX для апгрейда — и каждый раз зомби-ВМ просыпалась и проявляла себя в той же сети, где установлен CAS-сервер. По чистой случайности, первый раз проблема быстро ушла, когда админ ESX посмотрел консоль и отключил все ВМы, которые не должны были работать.

Каждый раз, когда эта зомби-ВМ выходила в сеть, она выбивала из сети первичный CAS-сервер (тот, что помощнее), и IronPort перекидывал всю нагрузку на вторичный CAS-сервер, ну а поскольку, вторичный сервер все равно постоянно простаивал, мы его обвешали разными дополнительными службами, и когда на него наваливался еще IronPort, «бобик» с грустью впадал в летаргический сон.

ПРО ЗОМБИ И ПЕРЕВОДЫ

Итак, как вы поняли, в переводе я столкнулся с термином zombie VM.

Обычно считается, что «ломать — не строить». С зомби-ВМ все наоборот: сделать такую машину — минутное дело, а вот, когда забудешь про неё, вычислить и вычистить за ней продукты жизнедеятельности — нужно покопаться…

Конечно, это её вычисление не всегда требует такой Камасутры, как описано выше, но создаваемый ею ассортимент гадостей так же бесконечен, как список санкций США: медленная работа, перерасход памяти, мощностей, переплаты за лицензии (как за ОС, так и за приложения, серверы и БД) — и заметьте, всё исключительно в ущерб системе и без каких-либо встречных плюшек. Ну, разве что сбор бесценного опыта по коллекционированию грабель.

В любом случае, мое переводческое дело — маленькое, термин я нашел, в сути его примерно разобрался, в перевод вставил, апгрейд своего глоссария сделал — заказчик будет счастлив. Надеюсь, и вы нашли что-то полезное для себя.

Удачи вам.

С уважением,
Евгений Бартов,
переводчик, копирайтер, маркетолог.